linux-kernel - Re: [PATCH v1 0/3] Allow knfsd to use atomic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <176419077220.634289.8903814965587480932@noble.neil.brown.name>
Date: Thu, 27 Nov 2025 07:59:32 +1100
From: NeilBrown <neilb@...mail.net>
To: "Benjamin Coddington" <bcodding@...merspace.com>
Cc: "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>,
 "Olga Kornievskaia" <okorniev@...hat.com>, "Dai Ngo" <Dai.Ngo@...cle.com>,
 "Tom Talpey" <tom@...pey.com>, 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: Re: [PATCH v1 0/3] Allow knfsd to use atomic_open()

On Fri, 21 Nov 2025, Benjamin Coddington wrote:
> On 20 Nov 2025, at 17:26, NeilBrown wrote:
> 
> > On Wed, 19 Nov 2025, Benjamin Coddington wrote:
> >
> >> Ah, it's true.  I did not validate knfsd's behaviors, only its interface with
> >> VFS.  IIUC knfsd gets around needing to pass O_EXCL by holding the directory
> >> inode lock over the create, and since it doesn't need to do lookup because
> >> it already has a filehandle, I think O_EXCL is moot.
> >
> > Holding the directory lock is sufficient for providing O_EXCL for local
> > filesystems which will be blocked from creating while that lock is held.
> > It is *not* sufficient for remote filesystems which are precisely those
> > which provide ->atomic_open.
> >
> > The fact that you are adding support for atomic_open means that O_EXCL
> > isn't moot.
> 
> I mean to say: knfsd doesn't need to pass O_EXCL because its already taking
> care to produce an exclusive open via nfsv4 semantics.

Huh?

The interesting circumstance here is an NFS re-export of an NFS
filesystem - is that right?

The only way that an exclusive create can be achieved on the target
filesystem is if an NFS4_CREATE_EXCLUSIVE4_1 (or similar) create request
is sent to the ultimate sever.  There is nothing knfsd can do to
produce exclusive open semantics on a remote NFS serve except to
explicitly request them.

> 
> > I don't know what you mean by "since it doesn't need to do lookup because
> > it already has a filehandle".  What filehandle does it already have?
> 
> The client has sent along the filehandle of the parent directory, and knfsd
> has already done lookup_one() on the child name, and we pass along that
> negative dentry thet we looked up while holding the directory's inode lock.

This (holding the directory's inode lock) works perfectly well for local
filesystems (which don't implement ->atomic_open).  It has no effect on
remote filesystems (which is why we have ->atomic_open).

Thanks,
NeilBrown