Re: [RFC PATCH v2 1/2] vfs: syscalls: add mkdirat2() that returns an O_DIRECTORY fd

[Jori Koolstra]

> Op 27-04-2026 17:48 CEST schreef Christian Brauner <brauner@xxxxxxxxxx>:
> 
> So definitely a patchset worthing doing but this will be hairy. And
> Mateusz is right. As written this doesn't work. The canonical pattern
> how e.g., dentry_open() does it is to preallocate the file.
> 

Is this because of Mateusz point that we should fail as soon as possible
to prevent any fs changes from taking effect?

But like Mateusz points out, this is not really happening for open() with
O_CREAT either. So is there any policy for what we do and do not tolerate?
(although I agree we should definitely preallocate the file; thanks for
pointing that pattern out).

> I do wonder though whether we shouldn't just make O_CREAT | O_DIRECTORY
> work. I remember that I had a vague comment about this in [1] a few
> years ago (cf. [1]). It might even be less hairy to get that one right
> as all the thinking for O_CREAT is already there.
> 
> What was the rationale for mkdirat2() instead of threading this through
> openat()/openat2() with O_CREAT?
> 

Because of Mateusz' objection, but I agree with Aleksa (and you in 2023)
that this is intuitive and you mentioned POSIX allows for it.

But a more general issue, that also applies to this mkdirat2 patch,
is Linus' objection in that same thread.[1] However, the use-case of
the UAPI request is different. Still, do we have any concrete examples
of programs that need to do such permissions/ownership/labels
/timestamps/acls/xattrs changes concurrently with another process
that has delete and create permissions in the same folder, and that
currently relies on the fstat() workaround?

> And side-question: @Jeff, can nfs atomic open deal with O_CREAT |
> O_DIRECTORY?
> 
> [1]: 43b450632676 ("open: return EINVAL for O_DIRECTORY | O_CREAT")


[1]: https://lore.kernel.org/lkml/CAHk-=wgLimhZ8px+BxTvkonBGHr9oFcjrk4tmE2-_mmd3vBGdg@xxxxxxxxxxxxxx/