[PATCH v4] linux: Add openat2 (BZ 31664)

[Aleksa Sarai]

On 2025-08-25, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 2025-08-25 15:28, Aleksa Sarai wrote:
> > CHECK_FIELDS is an extension I proposed to most extensible-struct
> > syscalls that would let userspace query which bit patterns are valid
> 
> I don't see how such a feature would work in general. If the struct has N
> bits, there are 2**N possible bit patterns and there's no way in general to
> find out which are valid without using O(2**N) time. One cannot simply ask
> "which bits can I turn on?" because that would imply that some forbidden bit
> patterns are allowed. For example, a valid call cannot set both O_DIRECTORY
> and O_CREAT, but a simple query saying "What bits can I set?" must yield
> both those bits.

Sorry, "bit patterns" was probably a confusing term to use. What I meant
to say is that the kernel would every bit in the structure that is a
valid value. For flags, this would be all of the flag bits. For
non-flags this would usually be ~0. This would then be copied to the
user struct, and userspace can easily check for flag support by checking
if the bit is set. [1] is the patchset I sent a while ago.

The question of whether flags can be used together is not something that
this feature would tackle -- for most system calls, the userspace
program will know which flags work together and so just knowing which
flags are valid is enough information. There are cases where supported
flagsets change, and to detect that you would need to do the normal
guess-and-check approach unfortunately.

At LPC 2020 we discussed having a global API bit array[2] but I had (and
still have) doubts about the practical feasibility of that approach.

> Even if there's something along these lines that might work in the future,
> it's confusing that the read-only argument is 'struct open_how *' now.

Is removing const something we can do safely? I was under the impression
removing const from a function prototype can break building working
programs? (Even if they wouldn't be using the feature.)

> The longstanding tradition in syscalls that get and set state is to have two
> arguments, one for getting and one for setting. (I am thinking of syscalls
> like sigaction and sigprocmask.) If openat2 is intended for both getting and
> setting it should have two arguments, not one.

In general, sure. But there is precedent for the CHECK_FIELDS approach
-- sched_setattr(2) and perf_event_open(2) both write to the size field
in their struct argument so that userspace can know the kernel size of
the struct (despite it being a "read" argument).

[1]: https://lore.kernel.org/lkml/20241010-extensible-structs-check_fields-v3-0-d2833dfe6edd@cyphar.com/
[2]: https://lwn.net/Articles/830666/

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250826/15dc5011/attachment.sig>