All of lore.kernel.org
 help / color / mirror / Atom feed
From: Omar Sandoval <osandov@osandov.com>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: linux-btrfs@vger.kernel.org,
	Chris Murphy <lists@colorremedies.com>,
	kernel-team@fb.com
Subject: Re: [PATCH] Btrfs: disable xattr operations on subvolume directories
Date: Wed, 25 Jan 2017 15:46:33 -0800	[thread overview]
Message-ID: <20170125234633.GA19099@vader> (raw)
In-Reply-To: <CAHc6FU50-m5v4X-n+_=HK8Bu1gYEO=1R7nrgAhhY+Mk54mFYrg@mail.gmail.com> <CAHc6FU7ubp4-A-oF+0nuKf27QJMeG_UtQx0pjdL7uVS+UwX6uw@mail.gmail.com>

On Wed, Jan 25, 2017 at 01:28:21PM +0100, Andreas Gruenbacher wrote:
> Omar,
> 
> On Wed, Jan 25, 2017 at 3:38 AM, Omar Sandoval <osandov@osandov.com> wrote:
> > From: Omar Sandoval <osandov@fb.com>
> >
> > When you snapshot a subvolume containing a subvolume, you get a
> > placeholder read-only directory where the subvolume would be. These
> > directory inodes have ->i_ops set to btrfs_dir_ro_inode_operations.
> > Previously, this didn't include the xattr operation callbacks. The
> > conversion to xattr_handlers missed this case, leading to bogus attempts
> > to set xattrs on these inodes. This manifested itself as failures when
> > running delayed inodes.
> >
> > To fix this, clear the IOP_XATTR in ->i_opflags on these inodes.
> >
> > Fixes: 6c6ef9f26e59 ("xattr: Stop calling {get,set,remove}xattr inode operations")
> > Cc: Andreas Gruenbacher <agruenba@redhat.com>
> > Reported-by: Chris Murphy <lists@colorremedies.com>
> > Signed-off-by: Omar Sandoval <osandov@fb.com>
> > ---
> > Applies to v4.10-rc4. Chris, this fixes the issue for me, could you please test
> > it out? Andreas, does this make sense? I'll try to cook up an xfstest for this.
> 
> this change looks good.
> 
> Are those directories really read-only though? They have the S_IWUSR
> permission set, and an update_time iop.

Hm, so these inodes don't have an on-disk [mca]time, it's only in
memory. ->update_time() just updates the in-memory time stamp, which is
kind of weird. Not sure why these even have S_IWUSR; they don't have a
->create() iop either. 0555 really makes more sense here. I wonder if
anyone would care if we made that change...

> Also, the get_acl and set_acl iops seem dead: they were not called
> before because the xattr iops were not defined in
> btrfs_dir_ro_inode_operations, and they are not called now because
> IOP_XATTR is cleared. Could you please check that as well?

Yeah, those shouldn't be there, either. I'll get rid of them in v2.

On Wed, Jan 25, 2017 at 01:29:51PM +0100, Andreas Gruenbacher wrote:
> On Wed, Jan 25, 2017 at 3:38 AM, Omar Sandoval <osandov@osandov.com> wrote:
> > Forgot to cc stable, but 4.9 needs this.
> 
> Huh, stable not CCed again?

I was hoping Dave would add it when he applied it, but since I'm going
to send out a v2, I'll just do it then.

  parent reply	other threads:[~2017-01-25 23:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-26  1:06 [PATCH] Btrfs: disable xattr operations on subvolume directories Omar Sandoval
2017-01-25  2:38 ` Omar Sandoval
2017-01-25 12:28 ` Andreas Gruenbacher
     [not found]   ` <CAHc6FU7ubp4-A-oF+0nuKf27QJMeG_UtQx0pjdL7uVS+UwX6uw@mail.gmail.com>
2017-01-25 23:46     ` Omar Sandoval [this message]
2017-01-26  1:06 ` [PATCH v2 0/3] " Omar Sandoval
2017-01-26  1:06   ` [PATCH v2 1/3] Btrfs: remove old tree_root case in btrfs_read_locked_inode() Omar Sandoval
2017-01-26 17:19     ` David Sterba
2017-01-26  1:06   ` [PATCH v2 2/3] Btrfs: disable xattr operations on subvolume directories Omar Sandoval
2017-01-26 17:19     ` David Sterba
2017-01-26  1:06   ` [PATCH v2 3/3] Btrfs: remove ->{get,set}_acl() from btrfs_dir_ro_inode_operations Omar Sandoval
2017-01-26 17:18     ` David Sterba
2017-01-26 23:45   ` [PATCH v2 0/3] Btrfs: disable xattr operations on subvolume directories Chris Mason
2017-01-26  1:08 ` [PATCH] " Omar Sandoval

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=20170125234633.GA19099@vader \
    --to=osandov@osandov.com \
    --cc=agruenba@redhat.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.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.