xfs
[Top] [All Lists]

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

To: Eric Sandeen <sandeen@xxxxxxxxxx>
Subject: Re: [PATCH] xfs: fix remote symlinks on V5/CRC filesystems
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 16 Jun 2015 08:47:10 +1000
Cc: xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <557F532F.9060505@xxxxxxxxxx>
References: <557F4E1E.8000505@xxxxxxxxxx> <20150615222157.GD10224@dastard> <557F532F.9060505@xxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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...

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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