[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <cover.1763483341.git.bcodding@hammerspace.com>
Date: Tue, 18 Nov 2025 11:33:56 -0500
From: Benjamin Coddington <bcodding@...merspace.com>
To: Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
Jan Kara <jack@...e.cz>,
Chuck Lever <chuck.lever@...cle.com>,
Jeff Layton <jlayton@...nel.org>,
NeilBrown <neil@...wn.name>,
Olga Kornievskaia <okorniev@...hat.com>,
Dai Ngo <Dai.Ngo@...cle.com>,
Tom Talpey <tom@...pey.com>
Cc: linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-nfs@...r.kernel.org,
Trond Myklebust <trondmy@...nel.org>,
Mike Snitzer <snitzer@...nel.org>
Subject: [PATCH v1 0/3] Allow knfsd to use atomic_open()
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(-)
--
2.50.1
Powered by blists - more mailing lists