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] [day] [month] [year] [list]

Message-ID: <034A5D25-AAD3-4633-B90A-317762CED5D2@hammerspace.com>
Date: Thu, 20 Nov 2025 20:07:02 -0500
From: Benjamin Coddington <bcodding@...merspace.com>
To: NeilBrown <neil@...wn.name>
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 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.

> 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.

Ben