* [PATCH] xfs: Fix rounding in xfs_alloc_fix_len() @ 2014-06-04 9:48 Jan Kara 2014-06-04 13:35 ` Brian Foster 0 siblings, 1 reply; 4+ messages in thread From: Jan Kara @ 2014-06-04 9:48 UTC (permalink / raw) To: xfs; +Cc: Jan Kara Rounding in xfs_alloc_fix_len() is wrong. As the comment states, the result should be a number of a form (k*prod+mod) however due to sign mistake the result is different. As a result allocations on raid arrays could be misaligned in some cases. This also seems to fix occasional assertion failure: XFS_WANT_CORRUPTED_GOTO(rlen <= flen, error0) in xfs_alloc_ag_vextent_size(). Signed-off-by: Jan Kara <jack@suse.cz> --- fs/xfs/xfs_alloc.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/fs/xfs/xfs_alloc.c b/fs/xfs/xfs_alloc.c index c1cf6a336a72..6a0281b16451 100644 --- a/fs/xfs/xfs_alloc.c +++ b/fs/xfs/xfs_alloc.c @@ -257,14 +257,12 @@ xfs_alloc_fix_len( k = rlen % args->prod; if (k == args->mod) return; - if (k > args->mod) { - if ((int)(rlen = rlen - k - args->mod) < (int)args->minlen) - return; - } else { - if ((int)(rlen = rlen - args->prod - (args->mod - k)) < - (int)args->minlen) - return; - } + if (k > args->mod) + rlen = rlen - (k - args->mod); + else + rlen = rlen - args->prod + (args->mod - k); + if ((int)rlen < (int)args->minlen) + return; ASSERT(rlen >= args->minlen); ASSERT(rlen <= args->maxlen); args->len = rlen; -- 1.8.1.4 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] xfs: Fix rounding in xfs_alloc_fix_len() 2014-06-04 9:48 [PATCH] xfs: Fix rounding in xfs_alloc_fix_len() Jan Kara @ 2014-06-04 13:35 ` Brian Foster 2014-06-04 15:10 ` Jan Kara 0 siblings, 1 reply; 4+ messages in thread From: Brian Foster @ 2014-06-04 13:35 UTC (permalink / raw) To: Jan Kara; +Cc: xfs On Wed, Jun 04, 2014 at 11:48:13AM +0200, Jan Kara wrote: > Rounding in xfs_alloc_fix_len() is wrong. As the comment states, the > result should be a number of a form (k*prod+mod) however due to sign > mistake the result is different. As a result allocations on raid arrays > could be misaligned in some cases. > > This also seems to fix occasional assertion failure: > XFS_WANT_CORRUPTED_GOTO(rlen <= flen, error0) > in xfs_alloc_ag_vextent_size(). > Do you happen to have a reproducer for this? The meaning of args->prod (the structure definition comment calls it the prod value) is not clear to me. I see that we set it to an extent size hint if one exists (in xfs_bmap_btalloc()), so I'll go with that. args->mod then becomes the modulo of the file offset against that alignment hint. > Signed-off-by: Jan Kara <jack@suse.cz> > --- > fs/xfs/xfs_alloc.c | 14 ++++++-------- > 1 file changed, 6 insertions(+), 8 deletions(-) > > diff --git a/fs/xfs/xfs_alloc.c b/fs/xfs/xfs_alloc.c > index c1cf6a336a72..6a0281b16451 100644 > --- a/fs/xfs/xfs_alloc.c > +++ b/fs/xfs/xfs_alloc.c > @@ -257,14 +257,12 @@ xfs_alloc_fix_len( We get here and take the extent length, mod against the alignment and compare to the mod of the offset. > k = rlen % args->prod; > if (k == args->mod) > return; > - if (k > args->mod) { > - if ((int)(rlen = rlen - k - args->mod) < (int)args->minlen) > - return; > - } else { > - if ((int)(rlen = rlen - args->prod - (args->mod - k)) < > - (int)args->minlen) > - return; > - } > + if (k > args->mod) > + rlen = rlen - (k - args->mod); If the length mod is greater than the offset mod, reduce the length by the delta of the mods. > + else > + rlen = rlen - args->prod + (args->mod - k); Otherwise (length mod is less than offset mod), reduce by a full alignment size and add back the difference to match the offset mod. This seems correct to me. > + if ((int)rlen < (int)args->minlen) > + return; > ASSERT(rlen >= args->minlen); > ASSERT(rlen <= args->maxlen); The rlen >= minlen assert seems kind of pointless here, but what about changing both instances of these two asserts to the following: ASSERT(rlen >= args->minlen && rlen <= args->maxlen); ... and add a new one after the length adjustment along the lines of: ASSERT((rlen % args->prod) == args->mod); Thoughts? Would this have caught the problem you've found earlier? Brian > args->len = rlen; > -- > 1.8.1.4 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] xfs: Fix rounding in xfs_alloc_fix_len() 2014-06-04 13:35 ` Brian Foster @ 2014-06-04 15:10 ` Jan Kara 2014-06-04 15:54 ` Brian Foster 0 siblings, 1 reply; 4+ messages in thread From: Jan Kara @ 2014-06-04 15:10 UTC (permalink / raw) To: Brian Foster; +Cc: Jan Kara, xfs On Wed 04-06-14 09:35:51, Brian Foster wrote: > On Wed, Jun 04, 2014 at 11:48:13AM +0200, Jan Kara wrote: > > Rounding in xfs_alloc_fix_len() is wrong. As the comment states, the > > result should be a number of a form (k*prod+mod) however due to sign > > mistake the result is different. As a result allocations on raid arrays > > could be misaligned in some cases. > > > > This also seems to fix occasional assertion failure: > > XFS_WANT_CORRUPTED_GOTO(rlen <= flen, error0) > > in xfs_alloc_ag_vextent_size(). > > Do you happen to have a reproducer for this? No, IBM triggered this during their testing on powerPC. I can ask them if they can share the test if you are interested. > The meaning of args->prod (the structure definition comment calls it the > prod value) is not clear to me. I see that we set it to an extent > size hint if one exists (in xfs_bmap_btalloc()), so I'll go with that. > args->mod then becomes the modulo of the file offset against that > alignment hint. > > > Signed-off-by: Jan Kara <jack@suse.cz> > > --- > > fs/xfs/xfs_alloc.c | 14 ++++++-------- > > 1 file changed, 6 insertions(+), 8 deletions(-) > > > > diff --git a/fs/xfs/xfs_alloc.c b/fs/xfs/xfs_alloc.c > > index c1cf6a336a72..6a0281b16451 100644 > > --- a/fs/xfs/xfs_alloc.c > > +++ b/fs/xfs/xfs_alloc.c > > @@ -257,14 +257,12 @@ xfs_alloc_fix_len( > > We get here and take the extent length, mod against the alignment and > compare to the mod of the offset. > > > k = rlen % args->prod; > > if (k == args->mod) > > return; > > - if (k > args->mod) { > > - if ((int)(rlen = rlen - k - args->mod) < (int)args->minlen) > > - return; > > - } else { > > - if ((int)(rlen = rlen - args->prod - (args->mod - k)) < > > - (int)args->minlen) > > - return; > > - } > > + if (k > args->mod) > > + rlen = rlen - (k - args->mod); > > If the length mod is greater than the offset mod, reduce the length by > the delta of the mods. > > > + else > > + rlen = rlen - args->prod + (args->mod - k); > > Otherwise (length mod is less than offset mod), reduce by a full > alignment size and add back the difference to match the offset mod. > > This seems correct to me. > > > + if ((int)rlen < (int)args->minlen) > > + return; > > ASSERT(rlen >= args->minlen); > > ASSERT(rlen <= args->maxlen); > > The rlen >= minlen assert seems kind of pointless here, but what about > changing both instances of these two asserts to the following: Well, rlen has been decreased so rlen >= minlen makes sense. rlen <= maxlen seems to be the obvious one to me. > ASSERT(rlen >= args->minlen && rlen <= args->maxlen); > > ... and add a new one after the length adjustment along the lines of: > > ASSERT((rlen % args->prod) == args->mod); > > Thoughts? Would this have caught the problem you've found earlier? Yes, this would have caught the bug. Should I add this assertion an resend? Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] xfs: Fix rounding in xfs_alloc_fix_len() 2014-06-04 15:10 ` Jan Kara @ 2014-06-04 15:54 ` Brian Foster 0 siblings, 0 replies; 4+ messages in thread From: Brian Foster @ 2014-06-04 15:54 UTC (permalink / raw) To: Jan Kara; +Cc: xfs On Wed, Jun 04, 2014 at 05:10:34PM +0200, Jan Kara wrote: > On Wed 04-06-14 09:35:51, Brian Foster wrote: > > On Wed, Jun 04, 2014 at 11:48:13AM +0200, Jan Kara wrote: > > > Rounding in xfs_alloc_fix_len() is wrong. As the comment states, the > > > result should be a number of a form (k*prod+mod) however due to sign > > > mistake the result is different. As a result allocations on raid arrays > > > could be misaligned in some cases. > > > > > > This also seems to fix occasional assertion failure: > > > XFS_WANT_CORRUPTED_GOTO(rlen <= flen, error0) > > > in xfs_alloc_ag_vextent_size(). > > > > Do you happen to have a reproducer for this? > No, IBM triggered this during their testing on powerPC. I can ask them if > they can share the test if you are interested. > I think it would be generally interesting, particularly to see if we could create an xfstests test..? > > The meaning of args->prod (the structure definition comment calls it the > > prod value) is not clear to me. I see that we set it to an extent > > size hint if one exists (in xfs_bmap_btalloc()), so I'll go with that. > > args->mod then becomes the modulo of the file offset against that > > alignment hint. > > > > > Signed-off-by: Jan Kara <jack@suse.cz> > > > --- > > > fs/xfs/xfs_alloc.c | 14 ++++++-------- > > > 1 file changed, 6 insertions(+), 8 deletions(-) > > > > > > diff --git a/fs/xfs/xfs_alloc.c b/fs/xfs/xfs_alloc.c > > > index c1cf6a336a72..6a0281b16451 100644 > > > --- a/fs/xfs/xfs_alloc.c > > > +++ b/fs/xfs/xfs_alloc.c > > > @@ -257,14 +257,12 @@ xfs_alloc_fix_len( > > > > We get here and take the extent length, mod against the alignment and > > compare to the mod of the offset. > > > > > k = rlen % args->prod; > > > if (k == args->mod) > > > return; > > > - if (k > args->mod) { > > > - if ((int)(rlen = rlen - k - args->mod) < (int)args->minlen) > > > - return; > > > - } else { > > > - if ((int)(rlen = rlen - args->prod - (args->mod - k)) < > > > - (int)args->minlen) > > > - return; > > > - } > > > + if (k > args->mod) > > > + rlen = rlen - (k - args->mod); > > > > If the length mod is greater than the offset mod, reduce the length by > > the delta of the mods. > > > > > + else > > > + rlen = rlen - args->prod + (args->mod - k); > > > > Otherwise (length mod is less than offset mod), reduce by a full > > alignment size and add back the difference to match the offset mod. > > > > This seems correct to me. > > > > > + if ((int)rlen < (int)args->minlen) > > > + return; > > > ASSERT(rlen >= args->minlen); > > > ASSERT(rlen <= args->maxlen); > > > > The rlen >= minlen assert seems kind of pointless here, but what about > > changing both instances of these two asserts to the following: > Well, rlen has been decreased so rlen >= minlen makes sense. rlen <= > maxlen seems to be the obvious one to me. > That was more a commentary on the fact that the assert now immediately follows a check for the negation of the assert, where we return. The assert below seems a bit more generic and just makes it stand out a little less (to me). Not really a big deal. > > ASSERT(rlen >= args->minlen && rlen <= args->maxlen); > > > > ... and add a new one after the length adjustment along the lines of: > > > > ASSERT((rlen % args->prod) == args->mod); > > > > Thoughts? Would this have caught the problem you've found earlier? > Yes, this would have caught the bug. Should I add this assertion an > resend? Yeah, if you don't mind. I think that one is definitely beneficial. Brian > > Honza > > -- > Jan Kara <jack@suse.cz> > SUSE Labs, CR _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-06-04 15:54 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-06-04 9:48 [PATCH] xfs: Fix rounding in xfs_alloc_fix_len() Jan Kara 2014-06-04 13:35 ` Brian Foster 2014-06-04 15:10 ` Jan Kara 2014-06-04 15:54 ` Brian Foster
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox