All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Myers <bpm@sgi.com>
To: Dave Chinner <david@fromorbit.com>, Andrew Dahl <adahl@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [patch 1/2] xfs: xfs_tosspages() bug
Date: Thu, 8 Nov 2012 17:46:42 -0600	[thread overview]
Message-ID: <20121108234642.GR9783@sgi.com> (raw)
In-Reply-To: <20121108230649.GU6434@dastard>

Hey Dave,

On Fri, Nov 09, 2012 at 10:06:49AM +1100, Dave Chinner wrote:
> On Thu, Nov 08, 2012 at 04:23:16PM -0600, Andrew Dahl wrote:
> > xfs_tosspages() takes a closed interval as an argument, take 
> > this into account when rounding down to the last byte of the
> > last complete page. If the request consists of a single 
> > partial page, there will be nothing to toss. 
> > 
> > Signed-off-by: Andrew Dahl <adahl@sgi.com>
> > 
> > ---

...

> So the change is good.
> 
> However, there's a bigger issue here. We've planned to remove these
> wrappers for a long time, just never got around to doing it. Seeing
> as there is a bug in this wrapper and it needs to be fixed, now
> seems like the right time to remove it.

The removal of the wrappers would not be appropriate for -stable.  This fix
needs to go in separately from any refactoring so that it can be pulled back
within the rules outlined in Documentation/stable_kernel_rules.txt.

> Hence I'd suggest that fixing this particular bug should just
> remove xfs_tosspages() and call truncate_inode_pages_range()
> directly. There are only two calls to this function, so it should be
> a simple conversion.  That can then be followed up with more patches
> to remove the other wrappers in xfs_fs_subr.c and hence remove the
> file completely...

I have no objection to doing so in a followup series, and I don't consider it
to be a high priority either.

> >  int
> > Index: xfs/fs/xfs/xfs_vnodeops.c
> > ===================================================================
> > --- xfs.orig/fs/xfs/xfs_vnodeops.c
> > +++ xfs/fs/xfs/xfs_vnodeops.c
> > @@ -2172,7 +2172,7 @@ xfs_change_file_space(
> >  	switch (cmd) {
> >  	case XFS_IOC_ZERO_RANGE:
> >  		prealloc_type |= XFS_BMAPI_CONVERT;
> > -		xfs_tosspages(ip, startoffset, startoffset + bf->l_len, 0);
> > +		xfs_tosspages(ip, startoffset, bf->l_len ? startoffset + llen : -1, 0);
> >  		/* FALLTHRU */
> >  	case XFS_IOC_RESVSP:
> >  	case XFS_IOC_RESVSP64:
> 
> What's this hunk for? Indeed, one of the first things that the
> xfs_alloc_file_space() checks is this:
> 
>         if (len <= 0)
> 		return XFS_ERROR(EINVAL);
> 
> xfs_free_file_space() does the same check, so it is invalid to pass
> a bf_len <= 0 for any of these specific functions. Hence this change
> is wrong regardless of what the comment on the struct xfs_flock64_t
> says - preallocation and hole punch operations must have a positive
> length associated with them.

Andrew, if you agree that this second change is unnecessary go ahead and remove
it and repost.  Otherwise,

Reviewed-by: Ben Myers <bpm@sgi.com>

Welcome to the XFS community!

-Ben

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

  reply	other threads:[~2012-11-08 23:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-08 22:23 [patch 0/2] xfs: xfs_tosspages() bug adahl
2012-11-08 22:23 ` [patch 1/2] " Andrew Dahl
2012-11-08 23:06   ` Dave Chinner
2012-11-08 23:46     ` Ben Myers [this message]
2012-11-09  1:05       ` Dave Chinner
2012-11-09 17:32         ` Ben Myers
2012-11-08 22:23 ` [patch 2/2] xfstests: xfs_tosspages() test addition Andrew Dahl
2012-11-08 23:27   ` Dave Chinner
2012-11-13  1:13     ` [patch 2/2 V2] " Andrew Dahl
2012-11-14 18:00       ` Mark Tinguely
2012-11-14 18:35         ` Andrew Dahl
2012-11-14 18:57           ` [patch 2/2 V3] " Andrew Dahl
2012-11-14 20:34             ` Dave Chinner
2012-11-20 15:31             ` Mark Tinguely
2012-11-09  1:12   ` xfs_quota -x -c 'report -u /dev/sde5' shows the duplicate result yyq
2012-11-09  1:24     ` Dave Chinner
2012-11-09  3:27       ` yyq
2012-11-09  5:39         ` Dave Chinner
     [not found]           ` <509CA82F.7030103@eisoo.com>
2012-11-09  7:01             ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121108234642.GR9783@sgi.com \
    --to=bpm@sgi.com \
    --cc=adahl@sgi.com \
    --cc=david@fromorbit.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.