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.

Previous work on commit fb70bf124b05 ("NFSD: Instantiate a struct file when
creating a regular NFSv4 file") addressed most of the atomicity issues, but
there are still a few gaps on network filesystems.

The problem was noticed on a test that did open O_CREAT with mode 0 which
will succeed in creating the file but will return -EACCES from vfs_open() -
this specific test is mentioned in 3/3 description.

Also, Trond notes that independently of the permissions issues, atomic_open
also solves races in open(O_CREAT|O_TRUNC). The NFS client now uses it for
both NFSv4 and NFSv3 for that reason.  See commit 7c6c5249f061 "NFS: add
atomic_open for NFSv3 to handle O_TRUNC correctly."

Changes on v4:
	- ensure we pass O_EXCL for NFS4_CREATE_EXCLUSIVE and
  NFS4_CREATE_EXCLUSIVE4_1, thanks to Neil Brown

Changes on v3:
	- rebased onto v6.18-rc7
	- R-b on 3/3 thanks to Chuck Lever

Changes on v2:
	- R-b thanks to Jeff Layton
	- improvements to patch descriptions thanks to Chuck Lever, Neil
  Brown, and Trond Myklebust
	- improvements to dentry_create()'s doc comment to clarify dentry
  handling thanks to Mike Snitzer

Thanks for any additional comment and critique.  gobble gobble


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         | 86 ++++++++++++++++++++++++++++++++++++++++++----
 fs/nfsd/nfs4proc.c | 11 ++++--
 fs/open.c          | 41 ----------------------
 include/linux/fs.h |  2 +-
 4 files changed, 88 insertions(+), 52 deletions(-)

-- 
2.50.1

On Thu, 27 Nov 2025 11:02:02 -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.
> 
> [...]

Applied to the vfs-6.20.atomic_open branch of the vfs/vfs.git tree.
Patches in the vfs-6.20.atomic_open branch should appear in linux-next soon.

Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.

It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.

Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs-6.20.atomic_open

[1/3] VFS: move dentry_create() from fs/open.c to fs/namei.c
      https://git.kernel.org/vfs/vfs/c/a79d83bd9f03
[2/3] VFS: Prepare atomic_open() for dentry_create()
      https://git.kernel.org/vfs/vfs/c/d52955ba68d6
[3/3] VFS/knfsd: Teach dentry_create() to use atomic_open()
      https://git.kernel.org/vfs/vfs/c/01584c2bcb06

Hi Chuck, Christian, Al,

Comments have died down.  I have some review on this one, and quite a lot of
testing in-house.  What else can I do to get this into linux-next on this
cycle?

Ben

On 27 Nov 2025, at 11:02, 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.
>
> Previous work on commit fb70bf124b05 ("NFSD: Instantiate a struct file when
> creating a regular NFSv4 file") addressed most of the atomicity issues, but
> there are still a few gaps on network filesystems.
>
> The problem was noticed on a test that did open O_CREAT with mode 0 which
> will succeed in creating the file but will return -EACCES from vfs_open() -
> this specific test is mentioned in 3/3 description.
>
> Also, Trond notes that independently of the permissions issues, atomic_open
> also solves races in open(O_CREAT|O_TRUNC). The NFS client now uses it for
> both NFSv4 and NFSv3 for that reason.  See commit 7c6c5249f061 "NFS: add
> atomic_open for NFSv3 to handle O_TRUNC correctly."
>
> Changes on v4:
> 	- ensure we pass O_EXCL for NFS4_CREATE_EXCLUSIVE and
>   NFS4_CREATE_EXCLUSIVE4_1, thanks to Neil Brown
>
> Changes on v3:
> 	- rebased onto v6.18-rc7
> 	- R-b on 3/3 thanks to Chuck Lever
>
> Changes on v2:
> 	- R-b thanks to Jeff Layton
> 	- improvements to patch descriptions thanks to Chuck Lever, Neil
>   Brown, and Trond Myklebust
> 	- improvements to dentry_create()'s doc comment to clarify dentry
>   handling thanks to Mike Snitzer
>
> Thanks for any additional comment and critique.  gobble gobble
>
>
> 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         | 86 ++++++++++++++++++++++++++++++++++++++++++----
>  fs/nfsd/nfs4proc.c | 11 ++++--
>  fs/open.c          | 41 ----------------------
>  include/linux/fs.h |  2 +-
>  4 files changed, 88 insertions(+), 52 deletions(-)
>
> -- 
> 2.50.1

On 12/4/25 10:05 AM, Benjamin Coddington wrote:
> Hi Chuck, Christian, Al,
> 
> Comments have died down.  I have some review on this one, and quite a lot of
> testing in-house.  What else can I do to get this into linux-next on this
> cycle?
The merge window is open right now, so any new work like this will be
targeted for the next kernel, not v6.19-rc.

I assume that since you sent To: Al/Christian, they would be taking this
through one of the VFS trees; hence my R-b.

If you're going only for linux-next, you can open your own kernel.org
account and set up a git repo there, then Stephen can pull from that
repo into linux-next and fs-next.


> Ben
> 
> On 27 Nov 2025, at 11:02, 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.
>>
>> Previous work on commit fb70bf124b05 ("NFSD: Instantiate a struct file when
>> creating a regular NFSv4 file") addressed most of the atomicity issues, but
>> there are still a few gaps on network filesystems.
>>
>> The problem was noticed on a test that did open O_CREAT with mode 0 which
>> will succeed in creating the file but will return -EACCES from vfs_open() -
>> this specific test is mentioned in 3/3 description.
>>
>> Also, Trond notes that independently of the permissions issues, atomic_open
>> also solves races in open(O_CREAT|O_TRUNC). The NFS client now uses it for
>> both NFSv4 and NFSv3 for that reason.  See commit 7c6c5249f061 "NFS: add
>> atomic_open for NFSv3 to handle O_TRUNC correctly."
>>
>> Changes on v4:
>> 	- ensure we pass O_EXCL for NFS4_CREATE_EXCLUSIVE and
>>   NFS4_CREATE_EXCLUSIVE4_1, thanks to Neil Brown
>>
>> Changes on v3:
>> 	- rebased onto v6.18-rc7
>> 	- R-b on 3/3 thanks to Chuck Lever
>>
>> Changes on v2:
>> 	- R-b thanks to Jeff Layton
>> 	- improvements to patch descriptions thanks to Chuck Lever, Neil
>>   Brown, and Trond Myklebust
>> 	- improvements to dentry_create()'s doc comment to clarify dentry
>>   handling thanks to Mike Snitzer
>>
>> Thanks for any additional comment and critique.  gobble gobble
>>
>>
>> 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         | 86 ++++++++++++++++++++++++++++++++++++++++++----
>>  fs/nfsd/nfs4proc.c | 11 ++++--
>>  fs/open.c          | 41 ----------------------
>>  include/linux/fs.h |  2 +-
>>  4 files changed, 88 insertions(+), 52 deletions(-)
>>
>> -- 
>> 2.50.1


-- 
Chuck Lever

On 4 Dec 2025, at 12:33, Chuck Lever wrote:

> On 12/4/25 10:05 AM, Benjamin Coddington wrote:
>> Hi Chuck, Christian, Al,
>>
>> Comments have died down.  I have some review on this one, and quite a lot of
>> testing in-house.  What else can I do to get this into linux-next on this
>> cycle?
> The merge window is open right now, so any new work like this will be
> targeted for the next kernel, not v6.19-rc.

Yes indeed, too late for v6.19.

> I assume that since you sent To: Al/Christian, they would be taking this
> through one of the VFS trees; hence my R-b.

Thanks for that - usually there's some discussion on which tree would take
this which I didn't see yet.  Hope Al/Christian will pick it up.

> If you're going only for linux-next, you can open your own kernel.org
> account and set up a git repo there, then Stephen can pull from that
> repo into linux-next and fs-next.

I do need to get that done.

Ben

On Thu, Dec 04, 2025 at 12:36:31PM -0500, Benjamin Coddington wrote:
> On 4 Dec 2025, at 12:33, Chuck Lever wrote:
> 
> > On 12/4/25 10:05 AM, Benjamin Coddington wrote:
> >> Hi Chuck, Christian, Al,
> >>
> >> Comments have died down.  I have some review on this one, and quite a lot of
> >> testing in-house.  What else can I do to get this into linux-next on this
> >> cycle?
> > The merge window is open right now, so any new work like this will be
> > targeted for the next kernel, not v6.19-rc.
> 
> Yes indeed, too late for v6.19.

I've taken it into vfs-6.20.atomic_open and rebased this onto current
master and will do a final rebase after -rc1. Let me know if I messed
something up. Thanks for pinging.

On 5 Dec 2025, at 4:31, Christian Brauner wrote:

> On Thu, Dec 04, 2025 at 12:36:31PM -0500, Benjamin Coddington wrote:
>> On 4 Dec 2025, at 12:33, Chuck Lever wrote:
>>
>>> On 12/4/25 10:05 AM, Benjamin Coddington wrote:
>>>> Hi Chuck, Christian, Al,
>>>>
>>>> Comments have died down.  I have some review on this one, and quite a lot of
>>>> testing in-house.  What else can I do to get this into linux-next on this
>>>> cycle?
>>> The merge window is open right now, so any new work like this will be
>>> targeted for the next kernel, not v6.19-rc.
>>
>> Yes indeed, too late for v6.19.
>
> I've taken it into vfs-6.20.atomic_open and rebased this onto current
> master and will do a final rebase after -rc1. Let me know if I messed
> something up. Thanks for pinging.

Thanks Christian!  Looks good, I'll put another eye on it after the rebase.

Ben

On 12/4/25 12:36 PM, Benjamin Coddington wrote:
>> I assume that since you sent To: Al/Christian, they would be taking this
>> through one of the VFS trees; hence my R-b.
> Thanks for that - usually there's some discussion on which tree would take
> this which I didn't see yet.  Hope Al/Christian will pick it up.

There hasn't been any discussion, so you didn't miss anything. I just
assumed, based on the To: line.

I'm happy to take these if Al & Christian feel that's more appropriate.


-- 
Chuck Lever