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. 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC4D9C636CC for ; Mon, 30 Jan 2023 09:16:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236161AbjA3JQU (ORCPT ); Mon, 30 Jan 2023 04:16:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235394AbjA3JQT (ORCPT ); Mon, 30 Jan 2023 04:16:19 -0500 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 271B91ABD4; Mon, 30 Jan 2023 01:16:19 -0800 (PST) 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 Cc: linux-fsdevel@vger.kernel.org, Christoph Hellwig , Al Viro , Seth Forshee , linux-erofs@lists.ozlabs.org, Jan Kara , linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org, ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org 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) Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org 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. 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.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (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 025B1C54EED for ; Mon, 30 Jan 2023 09:16:54 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1pMQHW-0005bG-8W; Mon, 30 Jan 2023 09:16:53 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pMQH8-0005ay-4p for linux-f2fs-devel@lists.sourceforge.net; Mon, 30 Jan 2023 09:16:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=G3kGnuF2seECswQYReilqUIUVUWzsfhznXPOaq3kkSY=; b=CujaPY5KBpbwotpRi6HKgSxU4G 8YKXSAZzdIaAVSFYPHcc9k2thZ4d9aGmfu1zHuAy/oQoIX/jaLdrCnenz/GXDGNmR2OJmY2sG3rVy fJRAciIbu7sugXiapsnw5OMnxOOTDogdPxi/Oa9XKMGi4rZartKkq74ODliOEfP+VBkA=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=G3kGnuF2seECswQYReilqUIUVUWzsfhznXPOaq3kkSY=; b=RwwWlzC1mVl385dfQxA09oGtvO Hz1o/b6dlRmGZs7MHA47eFhqM1dWXDZrz6/uSC97IVtY36m52ZVvXor5NJ+502RZ7eXdio8JVUcSj /8IxYL0iviRQiLG/IodJTeZFRvVo0NBdT4k5AGvmnXbZGqwoqg1+uNBV1mgTnU2Syk/A=; Received: from verein.lst.de ([213.95.11.211]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1pMQH5-003SY1-Il for linux-f2fs-devel@lists.sourceforge.net; Mon, 30 Jan 2023 09:16:29 +0000 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 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-Disposition: inline In-Reply-To: <20230130091052.72zglqecqvom7hin@wittgenstein> User-Agent: Mutt/1.5.17 (2007-11-01) X-Headers-End: 1pMQH5-003SY1-Il Subject: Re: [f2fs-dev] [PATCH 00/12] acl: remove remaining posix acl handlers X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net 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. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 0EBC3C54EED for ; Mon, 30 Jan 2023 18:13:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=BS9sgtzdtCooiepbl3+QT3/OcJOo734LHL7dlXjSiNY=; b=COm/UFVXpPT5u2 dTgKF6aBnJ3m1AdWumTq86rhPtQpDt7HCAO2DTu8Tx05tEf71F9mUHGNPjAaFF+Cg7M+dUmYiEo0L rsEeSwc+qiPMFL0OokI8yf4Q3zCqVC4RxsFJZIhGb6xMcMEcMH2CFos1SOAZ944xAb0zTFv1Kr0KS FRgdPiwqeQAVYqW/MumqUrQ9GDz7K/oNhjscpYuQCTJFxTwIPp6vRcQDYnbw8i2dJ3GXrn1zuRZCv O9LbmOJwwIkHQdJIVt62+jXmhOGOe/xuLWK/ahBbE46p34gwrdbodpvubhaYxebn26wI9zzufbtyE 1L1iFKvmrcqMYzJCCLSQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pMYeq-004t71-1p; Mon, 30 Jan 2023 18:13:32 +0000 Received: from verein.lst.de ([213.95.11.211]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pMYcj-004rt0-SO for linux-mtd@lists.infradead.org; Mon, 30 Jan 2023 18:11:24 +0000 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 Cc: linux-fsdevel@vger.kernel.org, Christoph Hellwig , Al Viro , Seth Forshee , linux-erofs@lists.ozlabs.org, Jan Kara , linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org, ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org 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-Disposition: inline In-Reply-To: <20230130091052.72zglqecqvom7hin@wittgenstein> User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230130_101122_116870_F6DE3AF1 X-CRM114-Status: GOOD ( 15.45 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org 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. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ 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 aib29ajc254.phx1.oracleemaildelivery.com (aib29ajc254.phx1.oracleemaildelivery.com [192.29.103.254]) (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 34030C54EAA for ; Mon, 30 Jan 2023 09:16:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=oss-phx-1109; d=oss.oracle.com; h=Date:To:From:Subject:Message-Id:MIME-Version:Sender; bh=hY8aCZHOsD+JTxyKN6EaaTZfmkp+88AOcQns5xET7d0=; b=zKOBHUM6EPmq90DLgRV3KFSgMQb/mJkZyecmXICBL66dWi6uNXeXpkcQ3dHwhKeiekfs5gfFE5Qi +Fz+HTTfYaYGUSxZ4tEN1+CGFYyDJQAc94kPHynn+wgwNckNG/UJ9FMpJX/pdAtXbxHWVKAIK0co pqnP0i7SK1kbMbBxevHxtSfPTR4j2/Ux+fz2WO4cclWKXrnYoAOrrRpOJb5DxmuvFtiNFddjcJAz Q8hJieQU+7/Z7twos9EZK4/n6F0LXkKRuiyZChhATKg+SemLziU/JgXHsbbRyMAUygUUz+XfpTT1 rTTJbessS2lUFFFNWdBsRPkLUmRQ2qauYwk1Ag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=prod-phx-20191217; d=phx1.rp.oracleemaildelivery.com; h=Date:To:From:Subject:Message-Id:MIME-Version:Sender; bh=hY8aCZHOsD+JTxyKN6EaaTZfmkp+88AOcQns5xET7d0=; b=ZBCeFDd5zPmAncNT8jw1V6+K6n6B5Q7uQGIz4UZnM/RRzdJ1qHgKYOoyD/Q1aG5ucYDudQ0Hm2Of KOeCH6mU8SyVRBxEmUP5IYlW6oRd1dekfzpesoA4PiIn14yL9pkl4GDVfNrod2D2+f80VoXvOs0v PwFwYMhsrrsxb/H7zgRvMh60SnCWgDRnQQA2KfiPCqUrleVdtTnhmi0qAMrkLOxwdLURUeByIZNQ 4wFBlsr91xFL+E4dHKIpd1EQelot7RmW1/rIqx4RwLtPz9Y1YMn4lbBgyHElkvwtmVXKFMd5M9tc IYyhWwJu928pPCYmJ6vdgMTB0weK7n6iNXY/Tw== Received: by omta-ad3-fd3-301-us-phoenix-1.omtaad3.vcndpphx.oraclevcn.com (Oracle Communications Messaging Server 8.1.0.1.20230118 64bit (built Jan 18 2023)) with ESMTPS id <0RPA00NO7KFLEV50@omta-ad3-fd3-301-us-phoenix-1.omtaad3.vcndpphx.oraclevcn.com> for ocfs2-devel@archiver.kernel.org; Mon, 30 Jan 2023 09:16:33 +0000 (GMT) Date: Mon, 30 Jan 2023 10:16:15 +0100 To: Christian Brauner 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-disposition: inline In-reply-to: <20230130091052.72zglqecqvom7hin@wittgenstein> User-Agent: Mutt/1.5.17 (2007-11-01) X-Source-IP: 213.95.11.211 X-Proofpoint-Virus-Version: vendor=nai engine=6500 definitions=10605 signatures=596816 X-Proofpoint-Spam-Details: rule=tap_notspam policy=tap score=0 malwarescore=0 phishscore=0 bulkscore=0 suspectscore=0 lowpriorityscore=0 mlxscore=0 priorityscore=0 impostorscore=0 clxscore=276 spamscore=0 mlxlogscore=723 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301300088 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, ocfs2-devel@oss.oracle.com, Al Viro Subject: Re: [Ocfs2-devel] [PATCH 00/12] acl: remove remaining posix acl handlers X-BeenThere: ocfs2-devel@oss.oracle.com X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Christoph Hellwig via Ocfs2-devel Reply-to: Christoph Hellwig Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Errors-to: ocfs2-devel-bounces@oss.oracle.com X-ServerName: verein.lst.de X-Proofpoint-SPF-Result: None X-Spam: Clean X-Proofpoint-ORIG-GUID: vfM6_VqNE1lVhAbXTJe3aqz1qbxHoPjL X-Proofpoint-GUID: vfM6_VqNE1lVhAbXTJe3aqz1qbxHoPjL Reporting-Meta: AAFURT/GarsvUEWBR6RsZduPrEty6jV5pFF9A/9U8bRjQAhwtw4cj5f20bpXVoKJ vAvBktTX6/NfFnQ0MSbdVM5juRjcqGn0dahY61eG/xeQwRecwU3QAAPcgMFR8s98 kX2K3MlQxpgzTxLsDiTDGUZzpgnPRBogOXw7XFT4rStjDNB9LvSZY0cJ2S/IoJ3h dV1VpyuvimK9quYnjzQe1P6E7ODXSmIceymumB7GQNn1h/tpVpjN+zy5y5NEFqbs FHijcQkoLHdTPuyqztXaVCj28tCPmKsebcBuAME2M+4/s4L5DtxrQIHzgqab1LXv TPAjuyLHbjlupUDsAnPHaCqE41CmsURe5ur4wAMabIxKD6rif4BtCk24RZ79cBvZ Cm9F3P274eADdGNNa9kkHLiU/5g9SqgUNaKZMjOCigmFeelLU7xHCyz9oaX2szHV fsN/y1xw5Tr9E7nVNY7qYK1jk4WdHMBawQ7jcMbOLdpyQF2y1jNbaPyhMJOcHbEd Tf/H/sJmGzH2AHhUiCnmj8MEAeIty6re8BAU/5sy1Jvx 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. _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel