All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: iustin@k1024.org, xfs@oss.sgi.com
Subject: Re: [PATCH 0/9] xfs: xfs_ioctl_setxattr rework
Date: Thu, 29 Jan 2015 10:38:35 -0500	[thread overview]
Message-ID: <20150129153834.GJ17652@laptop.bfoster> (raw)
In-Reply-To: <1422328486-24661-1-git-send-email-david@fromorbit.com>

On Tue, Jan 27, 2015 at 02:14:37PM +1100, Dave Chinner wrote:
> Hi folks,
> 
> This is a series I started a few months ago when we first started
> talking about the issues with extent size hints on directories and
> the project ID inherit flags being set on regular files. The code
> is particularly nice and has no clear definition of what sort
> of changes we allow in the XFS_IOC_FSSETXATTR ioctl.
> 
> The first thing the series does is kill the FSX_* flags and separate
> out the two different use cases for the xfs_ioctl_setattr()
> function. The first is just changing a constrained set of flags via
> the xfs_ioc_setxflags(), and the second is supporting
> xfs_ioc_fssetxattr(). Factoring out the part of the code that sets
> just the inode flags appropriately allows us to kill the FSX_* flags
> completely.
> 
> The next patch then relaxes the overly defensive approach to
> restricting XFS_IOC_FSSETXATTR to only the init namespace. We really
> only need to restrict project ID changes - allowing changes to other
> parts of the inode are managed by user/group permissions which are
> already user namespace aware.
> 
> The next part of the patch set factors out the validity checking
> of extent size changes and project ID changes from the setattr
> functions, making it much clearer the separation between checks and
> actions performed by xfs_ioctl_setattr() function.
> 
> Finally, with all these changes, Iustin Pop's extent size change
> validity checking patch is ported on top. That now becomes a simple,
> obvious set of changes to an isolated function, and i've added
> comments to explain the rules allowing extent size hints to be
> changed.
> 
> Comments, thoughts, flames, etc all welcome.
> 

All in all this looks like a nice cleanup to me. By the way, you've got
"xfs; ..." in some of the patch/mail headers instead of "xfs: ..."

Brian

> - Dave.
> 
> _______________________________________________
> 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

      parent reply	other threads:[~2015-01-29 15:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-27  3:14 [PATCH 0/9] xfs: xfs_ioctl_setxattr rework Dave Chinner
2015-01-27  3:14 ` [PATCH 1/9] xfs: FSX_NONBLOCK is not used Dave Chinner
2015-01-29 15:33   ` Brian Foster
2015-01-27  3:14 ` [PATCH 2/9] xfs: separate xflags from xfs_ioctl_setattr Dave Chinner
2015-01-29 15:34   ` Brian Foster
2015-01-27  3:14 ` [PATCH 3/9] xfs: factor out xfs_ioctl_setattr transaciton preamble Dave Chinner
2015-01-29 15:34   ` Brian Foster
2015-01-27  3:14 ` [PATCH 4/9] xfs: disaggregate xfs_ioctl_setattr Dave Chinner
2015-01-29 15:34   ` Brian Foster
2015-01-27  3:14 ` [PATCH 5/9] xfs: kill xfs_ioctl_setattr behaviour mask Dave Chinner
2015-01-29 15:35   ` Brian Foster
2015-01-27  3:14 ` [PATCH 6/9] xfs: XFS_IOCTL_SETXATTR can run in user namespaces Dave Chinner
2015-01-29 15:35   ` Brian Foster
2015-01-29 23:53     ` Dave Chinner
2015-01-30  3:04       ` Brian Foster
2015-01-30  7:44         ` Dave Chinner
2015-01-27  3:14 ` [PATCH 7/9] xfs; factor extsize hint checking out of xfs_ioctl_setattr Dave Chinner
2015-01-29 15:35   ` Brian Foster
2015-01-27  3:14 ` [PATCH 8/9] xfs; factor projid " Dave Chinner
2015-01-29 15:35   ` Brian Foster
2015-01-27  3:14 ` [PATCH 9/9] xfs: fix behaviour of XFS_IOC_FSSETXATTR on directories Dave Chinner
2015-01-29 15:35   ` Brian Foster
2015-01-29 15:38 ` Brian Foster [this message]

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=20150129153834.GJ17652@laptop.bfoster \
    --to=bfoster@redhat.com \
    --cc=david@fromorbit.com \
    --cc=iustin@k1024.org \
    --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.