Re: [PATCH v1 0/3] Allow knfsd to use atomic_open()

[Benjamin Coddington]

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