[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 at redhat.com>
> >>>> Cc: stable at 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 at 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 at fromorbit.com