All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Benjamin Coddington <bcodding@hammerspace.com>,
	Alexander Viro	 <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	Chuck Lever <chuck.lever@oracle.com>, NeilBrown <neil@brown.name>,
	 Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	 linux-nfs@vger.kernel.org, Trond Myklebust <trondmy@kernel.org>,
	Mike Snitzer	 <snitzer@kernel.org>
Subject: Re: [PATCH v1 0/3] Allow knfsd to use atomic_open()
Date: Tue, 18 Nov 2025 16:31:47 -0500	[thread overview]
Message-ID: <7d4eb6d36fe1266620076cfb77394f0cf837acec.camel@kernel.org> (raw)
In-Reply-To: <cover.1763483341.git.bcodding@hammerspace.com>

On Tue, 2025-11-18 at 11:33 -0500, Benjamin Coddington wrote:
> We have workloads that will benefit from allowing knfsd to use atomic_open()
> in the open/create path.  There are two benefits; the first is the original
> matter of correctness: when knfsd must perform both vfs_create() and
> vfs_open() in series there can be races or error results that cause the
> caller to receive unexpected results.  The second benefit is that for some
> network filesystems, we can reduce the number of remote round-trip
> operations by using a single atomic_open() path which provides a performance
> benefit. 
> 
> I've implemented this with the simplest possible change - by modifying
> dentry_create() which has a single user: knfsd.  The changes cause us to
> insert ourselves part-way into the previously closed/static atomic_open()
> path, so I expect VFS folks to have some good ideas about potentially
> superior approaches.
> 
> Thanks for any comment and critique.
> 
> Benjamin Coddington (3):
>   VFS: move dentry_create() from fs/open.c to fs/namei.c
>   VFS: Prepare atomic_open() for dentry_create()
>   VFS/knfsd: Teach dentry_create() to use atomic_open()
> 
>  fs/namei.c         | 84 ++++++++++++++++++++++++++++++++++++++++++----
>  fs/nfsd/nfs4proc.c |  8 +++--
>  fs/open.c          | 41 ----------------------
>  include/linux/fs.h |  2 +-
>  4 files changed, 83 insertions(+), 52 deletions(-)

Nice work, Ben. This looks pretty reasonable to me, and I agree that
using atomic_open is desirable for preventing races.

Reviewed-by: Jeff Layton <jlayton@kernel.org>

  parent reply	other threads:[~2025-11-18 21:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-18 16:33 [PATCH v1 0/3] Allow knfsd to use atomic_open() Benjamin Coddington
2025-11-18 16:33 ` [PATCH v1 1/3] VFS: move dentry_create() from fs/open.c to fs/namei.c Benjamin Coddington
2025-11-18 16:33 ` [PATCH v1 2/3] VFS: Prepare atomic_open() for dentry_create() Benjamin Coddington
2025-11-18 16:33 ` [PATCH v1 3/3] VFS/knfsd: Teach dentry_create() to use atomic_open() Benjamin Coddington
2025-11-18 18:01   ` Mike Snitzer
2025-11-18 18:39     ` Benjamin Coddington
2025-11-18 16:58 ` [PATCH v1 0/3] Allow knfsd " Chuck Lever
2025-11-18 17:17   ` Benjamin Coddington
2025-11-18 17:45   ` Trond Myklebust
2025-11-18 21:31 ` Jeff Layton [this message]
2025-11-19  1:23 ` NeilBrown
2025-11-19 12:46   ` Benjamin Coddington
2025-11-20 22:26     ` NeilBrown
2025-11-21  1:07       ` Benjamin Coddington
2025-11-26 20:59         ` NeilBrown
2025-11-26 22:06           ` Benjamin Coddington
2025-11-27  0:36             ` NeilBrown
2025-11-27 13:18               ` Benjamin Coddington
2025-11-19  1:32 ` [PATCH v1 2/3] VFS: Prepare atomic_open() for dentry_create() NeilBrown
2025-11-19 13:11   ` Benjamin Coddington
2025-11-19  1:41 ` [PATCH v1 3/3] VFS/knfsd: Teach dentry_create() to use atomic_open() NeilBrown
2025-11-19 13:02   ` Benjamin Coddington

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7d4eb6d36fe1266620076cfb77394f0cf837acec.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=bcodding@hammerspace.com \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=snitzer@kernel.org \
    --cc=tom@talpey.com \
    --cc=trondmy@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.