All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com
Subject: Re: [PATCH 2/2] xfs: only set extent size hint when asked
Date: Wed, 1 Oct 2014 08:13:05 +1000	[thread overview]
Message-ID: <20140930221305.GS4758@dastard> (raw)
In-Reply-To: <20140930055829.GB15186@teal.hq.k1024.org>

On Tue, Sep 30, 2014 at 07:58:29AM +0200, Iustin Pop wrote:
> On Tue, Sep 30, 2014 at 11:46:05AM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> > 
> > Currently the extent size hint is set unconditionally in
> > xfs_ioctl_setattr(), even when the FSX_EXTSIZE flag is not set. This
> > means we can set values from uninitialised stack variables. Hence
> > only set the extent size hint from userspace when both the mask
> > falg is set and the inode has the XFS_DIFLAG_EXTSIZE flag set to
> > indicate that we should have an extent size hint set on the inode.
> > 
> > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> > ---
> >  fs/xfs/xfs_ioctl.c | 16 ++++++++++++++--
> >  1 file changed, 14 insertions(+), 2 deletions(-)
> > 
> > diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> > index 87c3bd1..24c926b 100644
> > --- a/fs/xfs/xfs_ioctl.c
> > +++ b/fs/xfs/xfs_ioctl.c
> > @@ -1231,13 +1231,25 @@ xfs_ioctl_setattr(
> >  
> >  	}
> >  
> > -	if (mask & FSX_EXTSIZE)
> > -		ip->i_d.di_extsize = fa->fsx_extsize >> mp->m_sb.sb_blocklog;
> >  	if (mask & FSX_XFLAGS) {
> >  		xfs_set_diflags(ip, fa->fsx_xflags);
> >  		xfs_diflags_to_linux(ip);
> >  	}
> >  
> > +	/*
> > +	 * Only set the extent size hint if we've already determined that the
> > +	 * extent size hint should be set on the inode. If no extent size flags
> > +	 * are set on the inode then unconditionally clear the extent size hint.
> > +	 */
> > +	if (mask & FSX_EXTSIZE) {
> > +		int	extsize = 0;
> > +
> > +		if (ip->i_d.di_flags &
> > +				(XFS_DIFLAG_EXTSIZE | XFS_DIFLAG_EXTSZINHERIT))
> > +			extsize = fa->fsx_extsize >> mp->m_sb.sb_blocklog;
> > +		ip->i_d.di_extsize = extsize;
> 
> Quick question: this sounds sane, but it will have the following effect
> (if I understand things correctly): updating other flags on the inode
> (e.g. XFS_XFLAG_NOATIME) might change the recorded extent size.

That's no different to what happens before this patch. As I said in
the cover note, I'm not attempting to fix those problem with these
patches.

Besides, you're still thinking that you can just call
XFS_IOC_SETXATTR without a preceeding XFS_IOC_GETXATTR call. That's
just broken - if applications use getxattr/setxattr correctly then
this isn't an issue. i.e. do this:

	ioctl(XFS_IOC_GETXATTR, &fsx)
	fsx.fsx_xflags |= XFS_XFLAG_NOATIME;
	ioctl(XFS_IOC_SETXATTR, &fsx)

and the problem you allude to does not occur because it will set the
extent size to the same value as it currently has.

> True, it
> will correct the size if not appropriate and it will have a noop impact,
> but still it will be an unrelated inode change. Would it make sense to
> document this in the xfsctl man page then?

There's no point in documenting what *might* happen if you abuse the
interface in ways it was not intended to be used.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

  reply	other threads:[~2014-09-30 22:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-30  1:46 [PATCH 0/2] xfs: cleanup XFS_IOC_SETXATTR behaviour Dave Chinner
2014-09-30  1:46 ` [PATCH 1/2] xfs: project id inheritance is a directory only flag Dave Chinner
2014-10-01 11:58   ` Brian Foster
2014-09-30  1:46 ` [PATCH 2/2] xfs: only set extent size hint when asked Dave Chinner
2014-09-30  5:58   ` Iustin Pop
2014-09-30 22:13     ` Dave Chinner [this message]
2014-10-01 11:59   ` Brian Foster
2014-10-01 23:21     ` Dave Chinner
2014-09-30  5:55 ` [PATCH 0/2] xfs: cleanup XFS_IOC_SETXATTR behaviour Iustin Pop

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=20140930221305.GS4758@dastard \
    --to=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.