From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 76F49C54EED for ; Mon, 30 Jan 2023 09:16:24 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4P52c66jcJz3cLm for ; Mon, 30 Jan 2023 20:16:22 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lst.de (client-ip=213.95.11.211; helo=verein.lst.de; envelope-from=hch@lst.de; receiver=) Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4P52c40drVz3bXv for ; Mon, 30 Jan 2023 20:16:19 +1100 (AEDT) Received: by verein.lst.de (Postfix, from userid 2407) id 524FF68BEB; Mon, 30 Jan 2023 10:16:15 +0100 (CET) Date: Mon, 30 Jan 2023 10:16:15 +0100 From: Christoph Hellwig To: Christian Brauner Subject: Re: [PATCH 00/12] acl: remove remaining posix acl handlers Message-ID: <20230130091615.GB5178@lst.de> References: <20230125-fs-acl-remove-generic-xattr-handlers-v1-0-6cf155b492b6@kernel.org> <20230130091052.72zglqecqvom7hin@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230130091052.72zglqecqvom7hin@wittgenstein> User-Agent: Mutt/1.5.17 (2007-11-01) X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: reiserfs-devel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org, Seth Forshee , Jan Kara , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-erofs@lists.ozlabs.org, Christoph Hellwig , ocfs2-devel@oss.oracle.com, Al Viro Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" 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.