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

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

[Eric Sandeen]

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@redhat.com>
Cc: stable@vger.kernel.org
---

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;

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Dave Chinner]

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@redhat.com>
> Cc: stable@vger.kernel.org
> ---
> 
> 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@redhat.com>

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?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Eric Sandeen]

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@redhat.com>
>> Cc: stable@vger.kernel.org
>> ---
>>
>> 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@redhat.com>
> 
> 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.

-Eric


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Dave Chinner]

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@redhat.com>
> >> Cc: stable@vger.kernel.org
> >> ---
> >>
> >> 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@redhat.com>
> > 
> > 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...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Eric Sandeen]

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@redhat.com>
>>>> Cc: stable@vger.kernel.org
>>>> ---
>>>>
>>>> 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@redhat.com>
>>>
>>> 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
B) I bet LTP doesn't do a remount to verify on-disk persistence
C) ???
D) Profit!

-Eric

> Cheers,
> 
> Dave.
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Dave Chinner]

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@redhat.com>
> >>>> Cc: stable@vger.kernel.org
> >>>> ---
> >>>>
> >>>> 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@redhat.com>
> >>>
> >>> 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?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Eric Sandeen]

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@redhat.com>
>>>>>> Cc: stable@vger.kernel.org
>>>>>> ---
>>>>>>
>>>>>> 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@redhat.com>
>>>>>
>>>>> 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.

-Eric

> Cheers,
> 
> Dave.
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs