[Top] [All Lists]

Re: [PATCH] xfs: fix remote symlinks on V5/CRC filesystems

To: Dave Chinner <david@xxxxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxx>
Subject: Re: [PATCH] xfs: fix remote symlinks on V5/CRC filesystems
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Mon, 15 Jun 2015 20:26:44 -0500
Cc: xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150615231623.GF10224@dastard>
References: <557F4E1E.8000505@xxxxxxxxxx> <20150615222157.GD10224@dastard> <557F532F.9060505@xxxxxxxxxx> <20150615224710.GE10224@dastard> <557F5693.30504@xxxxxxxxxx> <20150615231623.GF10224@dastard>
On 6/15/15 6:16 PM, Dave Chinner wrote:
> On Mon, Jun 15, 2015 at 05:49:55PM -0500, Eric Sandeen wrote:
>> On 6/15/15 5:47 PM, Dave Chinner wrote:
>>> On Mon, Jun 15, 2015 at 05:35:27PM -0500, Eric Sandeen wrote:
>>>> On 6/15/15 5:21 PM, Dave Chinner wrote:
>>>>> On Mon, Jun 15, 2015 at 05:13:50PM -0500, Eric Sandeen wrote:
>>>>>> If we create a CRC filesystem, mount it, and create a symlink with
>>>>>> a path long enough that it can't live in the inode, we get a very
>>>>>> strange result upon remount:
>>>>>> # ls -l mnt
>>>>>> total 4
>>>>>> lrwxrwxrwx. 1 root root 929 Jun 15 16:58 link -> XSLM
>>>>>> XSLM is the V5 symlink block header magic (which happens to be
>>>>>> followed by a NUL, so the string looks terminated).
>>>>>> xfs_readlink_bmap() advanced cur_chunk by the size of the header
>>>>>> for CRC filesystems, but never actually used that pointer; it
>>>>>> kept reading from bp->b_addr, which is the start of the block,
>>>>>> rather than the start of the symlink data after the header.
>>>>>> Looks like this problem goes back to v3.10.
>>>>>> Fixing this gets us reading the proper link target, again.
>>>>>> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
>>>>>> Cc: stable@xxxxxxxxxxxxxxx
>>>>>> ---
>>>>>> diff --git a/fs/xfs/xfs_symlink.c b/fs/xfs/xfs_symlink.c
>>>>>> index 3df411e..40c0765 100644
>>>>>> --- a/fs/xfs/xfs_symlink.c
>>>>>> +++ b/fs/xfs/xfs_symlink.c
>>>>>> @@ -104,7 +104,7 @@ xfs_readlink_bmap(
>>>>>>                          cur_chunk += sizeof(struct xfs_dsymlink_hdr);
>>>>>>                  }
>>>>>> -                memcpy(link + offset, bp->b_addr, byte_cnt);
>>>>>> +                memcpy(link + offset, cur_chunk, byte_cnt);
>>>>>>                  pathlen -= byte_cnt;
>>>>>>                  offset += byte_cnt;
>>>>> Looks like the correct fix, so:
>>>>> Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
>>>>> However, it raises a more disturbing question: how did we not trip
>>>>> over this until now? I though we had long symlink test coverage in
>>>>> xfstests but clearly we haven't - do you have a test that closes
>>>>> this verification hole?
>>>> It was a smaller part of a larger test harness I was using with 
>>>> xfs_metadump,
>>>> which was trying to create every type of on-disk metadata.  However, even 
>>>> with
>>>> that I only stumbled on it, because I was only verifying that the results 
>>>> were
>>>> uncorrupted and consistent with the original, not actually verifying that
>>>> what I created was still there (on the original!)
>>>> So, I don't have a test specific to this, no, but could certainly write 
>>>> one;
>>>> I suppose a quick targeted fstest for just this bug would be ok, although
>>>> a test w/ broader scope might make sense too.
>>> Sure, the metadump test is a good idea, but my question is more
>>> asking why our broader tests haven't already covered verifying
>>> MAXPATHLEN symlinks work correctly or not. Surely symlink
>>> correctness is verified *somewhere* (even outside xfstests,
>>> e.g. LTP?), and if so why haven't we seen this before now? If not,
>>> then I'd suggest we've just uncovered a potential Nest O' Bugs...
>> A) CRCs aren't default
> Yet many people have been testing them and putting them in
> production (e.g. SLES 12), so they *should* have been tested.
>> B) I bet LTP doesn't do a remount to verify on-disk persistence
> Just reading back the symlink should expose the bug, right?
> Or is it being hidden by the dentry cache or something else?

it does seem to be cached, yes.


> Cheers,
> Dave.

<Prev in Thread] Current Thread [Next in Thread>