From: Omar Sandoval <osandov@xxxxxx> 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@xxxxxxxxxx> Reported-by: Chris Murphy <lists@xxxxxxxxxxxxxxxxx> Signed-off-by: Omar Sandoval <osandov@xxxxxx> --- 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. fs/btrfs/inode.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 4e024260ad71..3dacf0786428 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -3835,10 +3835,12 @@ static int btrfs_read_locked_inode(struct inode *inode) break; case S_IFDIR: inode->i_fop = &btrfs_dir_file_operations; - if (root == fs_info->tree_root) + if (root == fs_info->tree_root) { inode->i_op = &btrfs_dir_ro_inode_operations; - else + inode->i_opflags &= ~IOP_XATTR; + } else { inode->i_op = &btrfs_dir_inode_operations; + } break; case S_IFLNK: inode->i_op = &btrfs_symlink_inode_operations; @@ -5710,6 +5712,7 @@ static struct inode *new_simple_dir(struct super_block *s, inode->i_ino = BTRFS_EMPTY_SUBVOL_DIR_OBJECTID; inode->i_op = &btrfs_dir_ro_inode_operations; + inode->i_opflags &= ~IOP_XATTR; inode->i_fop = &simple_dir_operations; inode->i_mode = S_IFDIR | S_IRUGO | S_IWUSR | S_IXUGO; inode->i_mtime = current_time(inode); -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html