Re: [PATCH v6 07/12] vfs: add O_CREAT|O_DIRECTORY to open*(2)

[Jori Koolstra]

> Op 01-10-2026 17:59 CEST schreef Amir Goldstein <amir73il@xxxxxxxxx>:
> 
>  
> > > Maybe I am missing something, but I think you misunderstand me.
> > > What I mean is - if directory inode has a ->atomic_open() op,
> > > bail early with -EINVAL/-EOPNOTSUPP, because this is a network
> > > filesystem that does not support atomic O_CREATE|O_DIRECTORY
> > > and in most likelihood never will support it.
> > >
> > > This gating criteria is not dependent on cache state,
> > > which is what we wanted.
> > >
> >
> > No in that case I think I've understood you (or maybe still not?) My
> > point is that we can't do that if we want to be able to individually
> > support O_CREAT|O_DIRECTORY for some ->atomic_open fs. If we bail early
> > the how can say only NFS support it at some point? You get into the
> > situation where everybody needs to have support or no one.
> >
> > Does that make sense, or do I still misunderstand you point?
> >
> 
> If we gate on an existing criteria now like ->atomic_open()
> and/or ->d_revalidate(), we keep semantics simple and it
> does not limit us to change the criteria in the future.
> 
> But I don't insist on this criteria - it's just a suggestion.
> 

Oh no, I don't think it's a bad idea. I was just trying to understand.
And like I mentioned, I don't understand the detail of ->d_revalidate()
usage.

What do you think about Neil's suggestion to keep ->atomic_open out
of directory creation for the time being with:

1. use ->atomic_open(O_DIRECTORY) for lookup, no O_CREAT bit passed in.
2. if positive then done, otherwise (on -ENOENT from atomic_open()) we
   call ->mkdir
3. open that dentry in the regular way, WARN_ON negative dentry return

But I don't know if the kind of atomicity I care about is affected by
->d_revalidate() filesystems. With O_CREAT|O_DIRECTORY we just want provide
the mechanism to ensure that the process actually did the create you get
the fd for.

Best,
Jori.