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

[Aleksa Sarai]

On 2026-05-11, Christian Brauner <brauner@xxxxxxxxxx> wrote:
> On Mon, May 04, 2026 at 07:41:15PM +0200, Jori Koolstra wrote:
> > 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
> 
> mkdirat2() is objectively the worse api. It forces userspace to use a
> separate system call without any reason whatsoever. If you can to
> O_CREAT you should also be able to to O_DIRECTORY in the same system
> call. If we support O_DIRECTORY | O_CREAT we get all the lookup
> restriction niceties RESOLVE_* for free. Plus, it is supportable both in
> openat() and openat2() because I made that combo return an errno.
> 
> UAPI design often is a nasty mix of performance (context switches),
> separation of concerns and privileges, tastefulness, and compromises you
> never thought or wanted to make.
> 
> I think here it is pretty clear that O_DIRECTORY | O_CREAT is the right
> thing to do. Instead of restructuring a bunch of codepaths so it can be
> plumbed through to the filesystems we just reuse the existing codepaths
> that give us the right context for free.

FWIW, I completely agree.

> And during LSFMM the VFS maintains all agreed to proceed with
> O_DIRECTORY | O_CREAT.

(With the caveat that we do not copy the dangling symlink behaviour from
O_CREAT, as there be dragons.)

-- 
Aleksa Sarai
https://www.cyphar.com/

Attachment: signature.asc
Description: PGP signature