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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A22A2CCFA05 for ; Fri, 7 Nov 2025 00:01:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0911A8E0008; Thu, 6 Nov 2025 19:01:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0695A8E0002; Thu, 6 Nov 2025 19:01:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E9A2D8E0008; Thu, 6 Nov 2025 19:01:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D7FA38E0002 for ; Thu, 6 Nov 2025 19:01:19 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 757C812C4BA for ; Fri, 7 Nov 2025 00:01:19 +0000 (UTC) X-FDA: 84081856278.19.AF0F908 Received: from flow-a5-smtp.messagingengine.com (flow-a5-smtp.messagingengine.com [103.168.172.140]) by imf19.hostedemail.com (Postfix) with ESMTP id 278721A0015 for ; Fri, 7 Nov 2025 00:01:17 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=ownmail.net header.s=fm3 header.b=WZYAC5pt; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="P sg2gNo"; dmarc=pass (policy=none) header.from=ownmail.net; spf=pass (imf19.hostedemail.com: domain of neilb@ownmail.net designates 103.168.172.140 as permitted sender) smtp.mailfrom=neilb@ownmail.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1762473677; a=rsa-sha256; cv=none; b=MIdqFyvlSqhT/ZzL7E5rEWqjmS5iEMwBr2rZqWmFAeSm0qamFPKo+h4t+UP3AZkbdotsg5 eQBjqsyw2KX+PfElNqTpExuESGoz8fxiIBbo+mliSZjwj15uMDZ37IVOemCFVmM4nWY+Yf APCKlus9s9AELf01A/hrZOjl/omiaM4= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=ownmail.net header.s=fm3 header.b=WZYAC5pt; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="P sg2gNo"; dmarc=pass (policy=none) header.from=ownmail.net; spf=pass (imf19.hostedemail.com: domain of neilb@ownmail.net designates 103.168.172.140 as permitted sender) smtp.mailfrom=neilb@ownmail.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1762473677; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=H6fp6wT7I155+JjI5U+YS+I+wpfi8UjlpY4LU8fjdU4=; b=oUABKOWyVLpEzvyEWulml+lVIyiKZ4U8hMue9E70Ycz95QLi+IMCmuNL7ofsbJ9UqTC0Bl pFcSGwDFK0A7vhZLP2pX0gRPRPxLsrv/Nlk8dzNOqzfTrxNDm11E1i0xnb8xxGstnhWnCF Mp+9AEzd6CGoiUA4i56miUgciZhxumM= Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailflow.phl.internal (Postfix) with ESMTP id 2F76A13801BB; Thu, 6 Nov 2025 19:01:16 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-12.internal (MEProxy); Thu, 06 Nov 2025 19:01:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:reply-to:subject:subject:to:to; s=fm3; t= 1762473676; x=1762480876; bh=H6fp6wT7I155+JjI5U+YS+I+wpfi8UjlpY4 LU8fjdU4=; b=WZYAC5ptT+JI+E3LCYQDPMrHgn2+EeezTwSX9Fj81LnO57sEIW0 r5bog5i33AtRsNThYOW5jDpkHJo5LmpOQU7UBC/WI2CsBHqkVpPTyHV/ApxUM1tN z6dVSfEJthkopAMT44s7CyEjRA2sDrA7Y2ef+eMrFuZp33UeziEFvqR18wUswgoZ 7iPlUWWsOUPV/ZTTFBfyHToZxwjR9SvGXXZHsmi76QwHLy2cwbWHeeTpiMc4d1Bx XeBUu2V3z1ClTvl5FdR+kiB+ei1mybka1yZ1GjCONTkXDJfd+mNjp5j/C8/VHSTP dThaFVWL2uE50jq2dsohAmGrZdbMqVO7Ang== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1762473676; x= 1762480876; bh=H6fp6wT7I155+JjI5U+YS+I+wpfi8UjlpY4LU8fjdU4=; b=P sg2gNosOUgNreOPGLlVE9k8r0A93bFTvKl0A1YiFCaR0/yxDdKMWNofRmX2pbv2C pRquqzDxvSlnoOFKUo3q0Ir6NiXbOSxcJH8T5/d9/oXcWZsBYNknHCW+NvYGKU2G Ni1/LdQGu7Us7ontcePjlATrS/pgRVzjGEEX7HanmFiC2g+ePTDJ5SSAtpJBah0H UWRXuHQQCAsLEu8BLIO90FsUNkSBOy8aoz2K3RYVbczfmOyGIUeyWzmqDvAPkDRA jQU6SMudoXVNKkegC9Kaz3mNZdYl5nPuZwKwE6TAABXrWOiDglM1NlGb8+vPxFje mse7RGNm/dK9IXvzGfidw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddukeekudeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurheptgfgggfhvfevufgjfhffkfhrsehtqhertddttdejnecuhfhrohhmpefpvghilheu rhhofihnuceonhgvihhlsgesohifnhhmrghilhdrnhgvtheqnecuggftrfgrthhtvghrnh epleejtdefgeeukeeiteduveehudevfeffvedutefgteduhfegvdfgtdeigeeuudejnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhlsg esohifnhhmrghilhdrnhgvthdpnhgspghrtghpthhtohepleegpdhmohguvgepshhmthhp ohhuthdprhgtphhtthhopehvihhrohesiigvnhhivhdrlhhinhhugidrohhrghdruhhkpd hrtghpthhtohepfhhrrghnkhdrlhhisehvihhvohdrtghomhdprhgtphhtthhopehlihhn uhigqdigfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugi dquhhnihhonhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhn uhigqdhnihhlfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinh hugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhig qdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuh igqdhhrghruggvnhhinhhgsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtohep lhhinhhugidqfhhsuggvvhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrgh X-ME-Proxy: Feedback-ID: iab3e480c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 6 Nov 2025 19:00:45 -0500 (EST) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: NeilBrown To: "Jeff Layton" Cc: "Eric Van Hensbergen" , "Latchesar Ionkov" , "Dominique Martinet" , "Christian Schoenebeck" , "David Sterba" , "David Howells" , "Marc Dionne" , "Alexander Viro" , "Christian Brauner" , "Jan Kara" , "Tigran A. Aivazian" , "Chris Mason" , "Xiubo Li" , "Ilya Dryomov" , "Jan Harkes" , coda@cs.cmu.edu, "Tyler Hicks" , "Jeremy Kerr" , "Ard Biesheuvel" , "Namjae Jeon" , "Sungjong Seo" , "Yuezhang Mo" , "Theodore Ts'o" , "Andreas Dilger" , "Jaegeuk Kim" , "Chao Yu" , "OGAWA Hirofumi" , "Miklos Szeredi" , "Andreas Gruenbacher" , "Viacheslav Dubeyko" , "John Paul Adrian Glaubitz" , "Yangtao Li" , "Richard Weinberger" , "Anton Ivanov" , "Johannes Berg" , "Mikulas Patocka" , "Muchun Song" , "Oscar Salvador" , "David Hildenbrand" , "David Woodhouse" , "Dave Kleikamp" , "Trond Myklebust" , "Anna Schumaker" , "Ryusuke Konishi" , "Konstantin Komarov" , "Mark Fasheh" , "Joel Becker" , "Joseph Qi" , "Bob Copeland" , "Mike Marshall" , "Martin Brandenburg" , "Amir Goldstein" , "Steve French" , "Paulo Alcantara" , "Ronnie Sahlberg" , "Shyam Prasad N" , "Tom Talpey" , "Bharath SM" , "Zhihao Cheng" , "Hans de Goede" , "Carlos Maiolino" , "Hugh Dickins" , "Baolin Wang" , "Andrew Morton" , "Kees Cook" , "Gustavo A. R. Silva" , linux-kernel@vger.kernel.org, v9fs@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-afs@lists.infradead.org, linux-btrfs@vger.kernel.org, ceph-devel@vger.kernel.org, codalist@coda.cs.cmu.edu, ecryptfs@vger.kernel.org, linux-efi@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, gfs2@lists.linux.dev, linux-um@lists.infradead.org, linux-mm@kvack.org, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, linux-nfs@vger.kernel.org, linux-nilfs@vger.kernel.org, ntfs3@lists.linux.dev, ocfs2-devel@lists.linux.dev, linux-karma-devel@lists.sourceforge.net, devel@lists.orangefs.org, linux-unionfs@vger.kernel.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-xfs@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH] vfs: remove the excl argument from the ->create() inode_operation In-reply-to: References: <20251105-create-excl-v1-1-a4cce035cc55@kernel.org>, <176237780417.634289.15818324160940255011@noble.neil.brown.name>, <6758176514cdd6e2ceacb3bd0e4d63fb8784b7c6.camel@kernel.org>, Date: Fri, 07 Nov 2025 11:00:34 +1100 Message-id: <176247363419.634289.473957828516111884@noble.neil.brown.name> Reply-To: NeilBrown X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 278721A0015 X-Stat-Signature: d8y7forjyi7fqpa1a76bhjmiccb4qew5 X-HE-Tag: 1762473677-734567 X-HE-Meta: U2FsdGVkX18iHxmfstq+Zm20rqG51jrFrQ4ii/TjcRqlfuQWlYhjs7fFSwdbPSDv6NTulhZpexVDxj+jtFZRutTzuVULGRKrpOE8V1Gv0edpRFR04V9HWQLNUYwXYJAy+lIVdBuZ1ztyqCtZiu+4kQQhoDZlvGVQGgxWEWkXc4D9E/hLRO3ZpJRFC2dn6q5AEF+E60PNusSD33d3uaKgb+91KNrDNMSb7LdIbbtv1oQ46YKAmMFMWKbXibIX6Cymc1SABEnaRc1GbGy25ZpfFuRL18qu+7pz1N5i2gXGY8AR/BFPUOeXtsrquT2vvoV5c+F8rJnPgN/aoD+RvQtnmEGMhqArRipBGrfvXzzTR3FGWe7+gJDdKw6myoo9Oi8SfVuqYlkE6HKkqJ9gGu4dTUv4qmtquMAXN+n6NQ6IPBQLhAgvArvz9BIFxKklrYLMGlZfaOfoXgn5K/0CvGaaPCKLQkXoilID4uPK0yNMUvM5A/ttkZR9YHIpwl6v+gIFVXGTYiUnbao4QOFVOS6ToVYINQBb22fTvuLk8BHWJCp41i8W+f//HKCofAcIWvKHCOL00G3OjMj0hhxs2ymK3B8Yhj9BFUbGBg0aLPigh3//coHcEMHYJNJfu0HgTva/XEUrJJq3itpL0/2fX9xyjX/qTTPjghEtXE2tejHkM+ljfNsTjIq6uT5oKn54ZtTpzxJRD+cQ7ZUonGvgA7JB+MHNkvcctFmfp35ya5wDIqRHXB942f/U7/xOqxW5cJ4n4aCqQCPmMw5P/m+Pqjuf3aWQ5CuVuFoSPa9hyrW8UelvZ2QQrcvc5quFUYcJ2+QFYK0b8Wl930W9Xtqgbs71DEqE9rWN8mrxnHnsiR8QRkE9zLPtO/KQ0S1cAa5u841m2dYlr02hMHEdS6PwHpkCb6c0UjGMBmF9snV/yGQNub7SwH5PYuVzjv6dzgge4QMSu0Sg+b81DsmW347TipY uL6fbpI1 /rkQy8Py9yNq7/sM9yQLqA915GEi913o8qn7bTcCLSm+yWoLlfRGPNClQM3zhc/mxN+qfJAYNSW+JEQbg1gKWz86bbBPhnc9EQVu82nogxZ9jMPzGzxc4vgRpds2qYU+J9qX8cQHzDTblQG1Cyam23xknW7AXVkcLJclHsu5AAK/wZeESLPQNZs3GtOQzVgJtjwb7e1n352nY3yOVvodM1Sv8vxCntJMyxCh3WfivRVLWa+eGB+oFd7rBQCCzIB1lENuR8sEscqGmyM0I5aKOGVcgMM526ydNH7JumHseIRnN7XMC0Aki4lI6+i6BfDzYLT6RIcTF0WtU76g/8xELthxH+eBrHiQ863BYaQgZKh5F5AFCZdnIXPEGi9nsbNrLrxpDkR+nD1PCyBOziZWD94ZIpYYw+oOZt4ErZ5M6cto5RkgfK9CN/Of9AkS/FMw57YoDrD7VTX4vmOgqBfwE3XwcZUx8jzA4IqeeVpKxVxAORZdkt9W8v4Syj4xJr1ZjIIPk/5jhOee767WZ8Bzpq6dJuCOLfohSj7ijyUPizCP8M+uVp3OgQnFKpxTYBosbUgNs2Hc3WnI15nhmJNwJLafTpuUNeppyFB5cdd+HPa+N5qbDhlU+JrGmTTH5m/lQHYoUJI/fkwv5L7mfrp1ZMJRl0Yi5Kq+WgkDNr3+x/UQbs1c70g6wCGdGZ/C53gHf09d4ocp2bzelgNuK8LPkQcyaTUBWYpZxfLVQlFC22N6Am4hPvnmUL0c48zQjjRTi+WhL X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, 07 Nov 2025, Jeff Layton wrote: > On Thu, 2025-11-06 at 07:07 -0500, Jeff Layton wrote: > > On Thu, 2025-11-06 at 08:23 +1100, NeilBrown wrote: > > > On Thu, 06 Nov 2025, Jeff Layton wrote: > > > > Since ce8644fcadc5 ("lookup_open(): expand the call of vfs_create()"), > > > > the "excl" argument to the ->create() inode_operation is always set to > > > > true. Remove it, and fix up all of the create implementations. > > >=20 > > > nonono > > >=20 > > >=20 > > > > @@ -3802,7 +3802,7 @@ static struct dentry *lookup_open(struct nameid= ata *nd, struct file *file, > > > > } > > > > =20 > > > > error =3D dir_inode->i_op->create(idmap, dir_inode, dentry, > > > > - mode, open_flag & O_EXCL); > > > > + mode); > > >=20 > > > "open_flag & O_EXCL" is not the same as "true". > > >=20 > > > It is true that "all calls to vfs_create() pass true for 'excl'" > > > The same is NOT true for inode_operations.create. > > >=20 > >=20 > > I don't think this is a problem, actually: > >=20 > > Almost all of the existing ->create() operations ignore the "excl" > > bool. There are only two that I found that do not: NFS and GFS2. Both > > of those have an ->atomic_open() operation though, so lookup_open() > > will never call ->create() for those filesystems. This means that - > > > create() _is_ always called with excl =3D=3D true. >=20 > How about this for a revised changelog, which makes the above clear: >=20 > vfs: remove the excl argument from the ->create() inode_operation > =20 > Since ce8644fcadc5 ("lookup_open(): expand the call of vfs_create()"), > the "excl" argument to the ->create() inode_operation is always set to > true in vfs_create(). > =20 > There is another call to ->create() in lookup_open() that can set it to > either true or false. All of the ->create() operations in the kernel > ignore the excl argument, except for NFS and GFS2. Both NFS and GFS2 > have an ->atomic_open() operation, however so lookup_open() will never > call ->create() on those filesystems. > =20 > Remove the "excl" argument from the ->create() operation, and fix up the > filesystems accordingly. Thanks, that is a substantial improvement. I see your point now and I think this is a really nice cleanup to make - thanks. I think the commit message could be improved further by leading with the detail that is central - that most ->create function ignore 'excl'. With two exceptions, ->create() methods provided by filesystems ignore the "excl" flag. Those exception are NFS and GFS2 which both also provide ->atomic_open. excl is always true when ->create is called from vfs_create() (since commit......) so the only time it can be false is when it is called by lookup_open() for filesystems that do not provide ->atomic_open. So the excl flag to ->create is either ignored or true. So we can remove it and change NFS and GFS2 to acts as though it were true. >=20 > Maybe we also need some comments or updates to Documentation/ to make > it clear that ->create() always implies O_EXCL semantics? Definitely, something in porting.rst and something in vfs.rst. I would be worth saying somewhere that if the fs needs to mediate non-exclusive creation, it must provide atomic_open(). Thanks, NeilBrown > --=20 > Jeff Layton >=20