From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from submarine.notk.org (submarine.notk.org [62.210.214.84]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3C6062701B6; Sat, 8 Nov 2025 06:13:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.210.214.84 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762582384; cv=none; b=iPzYmA+lZKCUBE/PiNwFfD9nluJyytp0PYKiyDWTcecN/+7TnLP396qkfoEoNVUy8fty/4sqglVWdd4hyX6s0R7yxHNr67M5iy+0TVxLpcC0qvKE3j9JGI0e44jDhYhzqStdZR4sP7PCSESQ6crEhW9ekj7OBPfK+81HXWo9k6g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762582384; c=relaxed/simple; bh=DgH5GUT7j3a/+liLaMLDQ+ppgc87s/ERzvidbBqi8Oc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=B4RPBhxHZ0xrl6mOyeugKqBR+wSbpsP/Ea10zMrXW4ruyoz3kY1Uxt14kcHxjePtIG9Cr40qnOC4lI56mhvRyCWqoUIHlw7ETFo7BwQ6EcAIJ9L9ruFmCZJeAHqP00VapMQ1q1YiEFhlVCpmJJtW+zZ26BXuHxP9EF7rvFdOfgs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codewreck.org; spf=pass smtp.mailfrom=codewreck.org; dkim=pass (2048-bit key) header.d=codewreck.org header.i=@codewreck.org header.b=B+D3byKt; arc=none smtp.client-ip=62.210.214.84 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codewreck.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=codewreck.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=codewreck.org header.i=@codewreck.org header.b="B+D3byKt" Received: from gaia.codewreck.org (localhost [127.0.0.1]) by submarine.notk.org (Postfix) with ESMTPS id A419014C2D3; Sat, 8 Nov 2025 07:12:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1762582373; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LTM5LkyL3mfB0IbHJeS1oRharyj4iNDNdaZ7y5irjmg=; b=B+D3byKtJ5aLyRiu2rooP0B2TJlyh9NnWKaBHKY3oGl5WrI9R/ZTOokRqfrmQkRjA4d6PF hVA+2jtaIxDHKJVm19YOlIu00RJFzbMjiJ2IJMY5v8SjTtfCjEZWBxEPfRtzuPasj++KiY 8Sahe5eVbfmwmhQeo5uzL3Rp7AKK7Nzr7m3ipU5qmaiTEStLej1x9iBcfVqKnY9WidAi8X rwVB6qqUGBZMEcUSkoPWBbqf240gmgWcLbAb7B4RNHuho0O1rPy72OuweBfiXGGrgaJqO1 amO1aDXHVrMyRWIApKs7c+o9NFvUODZZvMkcXugNCGdZ2S65dzPgh2BACKmoHA== Received: from localhost (gaia.codewreck.org [local]) by gaia.codewreck.org (OpenSMTPD) with ESMTPA id 26a2c8b4; Sat, 8 Nov 2025 06:12:25 +0000 (UTC) Date: Sat, 8 Nov 2025 15:12:10 +0900 From: Dominique Martinet To: Jeff Layton Cc: Eric Van Hensbergen , Latchesar Ionkov , 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" , Jonathan Corbet , "Matthew Wilcox (Oracle)" , NeilBrown , 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, linux-doc@vger.kernel.org Subject: Re: [PATCH v2] vfs: remove the excl argument from the ->create() inode_operation Message-ID: References: <20251107-create-excl-v2-1-f678165d7f3f@kernel.org> Precedence: bulk X-Mailing-List: ocfs2-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20251107-create-excl-v2-1-f678165d7f3f@kernel.org> Jeff Layton wrote on Fri, Nov 07, 2025 at 10:05:03AM -0500: > With two exceptions, ->create() methods provided by filesystems ignore > the "excl" flag. Those exception are NFS and GFS2 which both also > provide ->atomic_open. > > 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(). The ->create() call in lookup_open() sets it > according to the O_EXCL open flag, but is never called if the filesystem > provides ->atomic_open(). > > The excl flag is therefore always either ignored or true. Remove it, > and change NFS and GFS2 to act as if it were always true. > > Signed-off-by: Jeff Layton Good cleanup, just one whitespace nitpick below but: Reviewed-by: Dominique Martinet > diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst > index 4f13b01e42eb5e2ad9d60cbbce7e47d09ad831e6..7a55e491e0c87a0d18909bd181754d6d68318059 100644 > --- a/Documentation/filesystems/vfs.rst > +++ b/Documentation/filesystems/vfs.rst > @@ -505,7 +505,10 @@ otherwise noted. > if you want to support regular files. The dentry you get should > not have an inode (i.e. it should be a negative dentry). Here > you will probably call d_instantiate() with the dentry and the > - newly created inode > + newly created inode. This operation should always provide O_EXCL This and the block below change halfway from tab (old text) to spaces (your patch) Looks like the file has a few space-indented sections though so it won't be the first if that goes in as is, the html-rendering doesn't seem to care :) Cheers, -- Dominique Martinet | Asmadeus