* [PATCH] xfs: fix remote symlinks on V5/CRC filesystems @ 2015-06-15 22:13 Eric Sandeen 2015-06-15 22:21 ` Dave Chinner 0 siblings, 1 reply; 7+ messages in thread From: Eric Sandeen @ 2015-06-15 22:13 UTC (permalink / raw) To: xfs-oss 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] xfs: fix remote symlinks on V5/CRC filesystems 2015-06-15 22:13 [PATCH] xfs: fix remote symlinks on V5/CRC filesystems Eric Sandeen @ 2015-06-15 22:21 ` Dave Chinner 2015-06-15 22:35 ` Eric Sandeen 0 siblings, 1 reply; 7+ messages in thread From: Dave Chinner @ 2015-06-15 22:21 UTC (permalink / raw) To: Eric Sandeen; +Cc: xfs-oss 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] xfs: fix remote symlinks on V5/CRC filesystems 2015-06-15 22:21 ` Dave Chinner @ 2015-06-15 22:35 ` Eric Sandeen 2015-06-15 22:47 ` Dave Chinner 0 siblings, 1 reply; 7+ messages in thread From: Eric Sandeen @ 2015-06-15 22:35 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs-oss 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] xfs: fix remote symlinks on V5/CRC filesystems 2015-06-15 22:35 ` Eric Sandeen @ 2015-06-15 22:47 ` Dave Chinner 2015-06-15 22:49 ` Eric Sandeen 0 siblings, 1 reply; 7+ messages in thread From: Dave Chinner @ 2015-06-15 22:47 UTC (permalink / raw) To: Eric Sandeen; +Cc: xfs-oss 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] xfs: fix remote symlinks on V5/CRC filesystems 2015-06-15 22:47 ` Dave Chinner @ 2015-06-15 22:49 ` Eric Sandeen 2015-06-15 23:16 ` Dave Chinner 0 siblings, 1 reply; 7+ messages in thread From: Eric Sandeen @ 2015-06-15 22:49 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs-oss 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] xfs: fix remote symlinks on V5/CRC filesystems 2015-06-15 22:49 ` Eric Sandeen @ 2015-06-15 23:16 ` Dave Chinner 2015-06-16 1:26 ` Eric Sandeen 0 siblings, 1 reply; 7+ messages in thread From: Dave Chinner @ 2015-06-15 23:16 UTC (permalink / raw) To: Eric Sandeen; +Cc: xfs-oss 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] xfs: fix remote symlinks on V5/CRC filesystems 2015-06-15 23:16 ` Dave Chinner @ 2015-06-16 1:26 ` Eric Sandeen 0 siblings, 0 replies; 7+ messages in thread From: Eric Sandeen @ 2015-06-16 1:26 UTC (permalink / raw) To: Dave Chinner, Eric Sandeen; +Cc: xfs-oss 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-06-16 1:26 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-06-15 22:13 [PATCH] xfs: fix remote symlinks on V5/CRC filesystems Eric Sandeen 2015-06-15 22:21 ` Dave Chinner 2015-06-15 22:35 ` Eric Sandeen 2015-06-15 22:47 ` Dave Chinner 2015-06-15 22:49 ` Eric Sandeen 2015-06-15 23:16 ` Dave Chinner 2015-06-16 1:26 ` Eric Sandeen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox