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

[Jori Koolstra]

> Op 25-09-2026 17:26 EDT schreef NeilBrown <neilb@xxxxxxxxxxx>:
> 
> The current proposal leaves all ->atomic_open using filesystems as not
> supporting O_CREAT|O_DIRECTORY and I think that is reasonable.  Getting
> them all done in the one release is probably unrealistic.
> But that is a slightly different issue to kernfs/tracefs.
> 

Exactly, we're not going to get 100% support in a single release anyway.

> I wonder *why* those two filesystems don't do the lookup to instantiate
> the dentry after mkdir.  If it was just "unnecessary" then we can safely
> change it.  If it was "there is a common use-case where mkdir isn't
> followed by a lookup, and we can avoid cluttering the icache/dcache",
> then we probably don't want to.
> 

Yes, I'd rather fix this there if possible, but we first need to know the idea
behind the curious choice not to instantiate the dentry. Otherwise, we can go
the ->atomic_open route as you suggested.

> 
> At this stage I think I would lean towards O_CREAT|O_DIRECTORY not
> working on these two filesystems.  Neither support a .create
> inode_operation, so providing a .atomic_open would be quite easy: just

Wait, so an O_CREAT opens already return an error on kernf/tracefs? They
only support directories? I have to read up on these a bit over the weekend.

> do a ->lookup and pass the result to finish_no_open, but return an
> appropriate error if O_CREAT was requested but no inode was found.  That
> would then treat these like other atomic_open filesystems in that
> O_CREAT|O_DIRECTORY wouldn't work until the fs maintainer accepted a
> patch for it.
> 

This sounds good to me.

Best,
Jori.

PS. @Neil, will you be at Plumbers by chance?