On Mon, Jan 30, 2023 at 10:16:15AM +0100, Christoph Hellwig wrote: > On Mon, Jan 30, 2023 at 10:10:52AM +0100, Christian Brauner wrote: > > However, a few filesystems still rely on the ->list() method of the > > generix POSIX ACL xattr handlers in their ->listxattr() inode operation. > > This is a very limited set of filesystems. For most of them there is no > > dependence on the generic POSIX ACL xattr handler in any way. > > > > In addition, during inode initalization in inode_init_always() the > > registered xattr handlers in sb->s_xattr are used to raise IOP_XATTR in > > inode->i_opflags. > > > > With the incoming removal of the legacy POSIX ACL handlers it is at > > least possible for a filesystem to only implement POSIX ACLs but no > > other xattrs. If that were to happen we would miss to raise IOP_XATTR > > because sb->s_xattr would be NULL. While there currently is no such > > filesystem we should still make sure that this just works should it ever > > happen in the future. > > Now the real questions is: do we care? Once Posix ACLs use an > entirely separate path, nothing should rely on IOP_XATTR for them. > So instead I think we're better off auditing all users of IOP_XATTR > and making sure that nothing relies on them for ACLs, as we've very > much split the VFS concept of ACLs from that from xattrs otherwise. I had a patch like that but some filesystems create inodes that explicitly remove IOP_XATTR to prevent any xattrs from being set on specific inodes. I remember this for at least reiserfs and btrfs. So we would probably need IOP_NOACL that can be raised by a filesystem to explicitly opt out of them for specific inodes. That's probably fine and avoids having to introduce something like SB_I_XATTR.
