Re: [RFC PATCH 1/2] vfs: syscalls: add mkdirat_fd()

[Aleksa Sarai]

On 2026-04-08, Jori Koolstra <jkoolstra@xxxxxxxxx> wrote:
> 
> > Op 02-04-2026 04:52 CEST schreef Aleksa Sarai <cyphar@xxxxxxxxxx>:
> > 
> > Please do not use O_* flags! O_CLOEXEC takes up 3 flag bits on different
> > architectures which makes adding new flags a nightmare.
> > 
> > I think this should take AT_* flags and (like most newer syscalls)
> > O_CLOEXEC should be automatically set. Userspace can unset it with
> > fnctl(F_SETFD) in the relatively rare case where they don't want
> > O_CLOEXEC.
> 
> And then do something like statx_lookup_flags() does to build the lookup
> flags from those AT flags?

Yeah, that is the usual pattern for *at(2) syscalls.

> But there is also no AT_ROOT_CONTAINED (or whatever you would want to
> call the RESOLVE_IN_ROOT AT-equivalent) right now.

This point about AT_* flags was a separate point to my hopes that we
could get this into openat2(2). We don't have AT_* equivalents to
RESOLVE_* flags because it would burn too many bits (at least 5,
likely more when we add RESOLVE_NO_DOTDOT and other such extensions) and
openat2(2) is actually sufficient for almost all operations in practice.

> > Alternatively, we could just bite the bullet and make
> > AT_NO_CLOEXEC a thing...
> 
> What's the bullet to bite there?

It's not a big deal but it just burns another generic AT_* flag bit for
something that userspace can do themselves with fnctl(2).

Maybe having it will encourage future syscall authors to default to
O_CLOEXEC, but we could end up with the slightly silly AT_SYMLINK_FOLLOW
/ AT_SYMLINK_NOFOLLOW situation too. Documenting it in
seemingly-rarely-read Documentation/process/adding-syscalls.rst might
end up being equally (in)effective without burning a flag bit... :/

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

Attachment: signature.asc
Description: PGP signature