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

On 2025-08-27, Paul Eggert [off-list ref] wrote:

On 2025-08-27 15:48, Aleksa Sarai wrote:

quoted

On 2025-08-27, Paul Eggert [off-list ref] wrote:

quoted

What specific scenario would make the "give me supported flags" flag worth
the hassle of supporting and documenting and testing such a flag?

"Just try it" leads to programs that have to test dozens of flag
combinations for syscalls at startup,

Although that sort of thing can indeed be a problem in general, I don't see
how it's a problem for openat2 in particular.

While O_* and RESOLVE_* flags are trivial to detect (since you can
always pass -EBADF to force a non-EINVAL error), my goal was to have a
unified interface for extensible-struct syscalls in this department.

The issue here is whether openat2's API should reflect current behavior
(where the HOW argument is pointer-to-const) or a potential future behavior
(where the kernel might modify the struct that HOW points to, if some
hypothetical future flag is set in that struct). I am skeptical that this
hypothetical situation is so plausible that it justifies the maintenance
hassle of a glibc API that doesn't correspond to how openat2 currently
behaves.

I mean, the kernel definition doesn't mark the syscall argument as
"const" so making it const in glibc also means maintaining a divergence
from the kernel. Of course, glibc does this for plenty of other
syscalls so it's not my place to say which is better.

My intention was just to say that this *was* intentiona (which was how I
understood the initial question that I was Cc'd onl, and if you feel
that intention is misguided / doesn't mesh with what glibc wants then
that's your call.

quoted

A simple example would be mounts -- if MOUNT_BENEATH is not supported

I don't understand this example. Are you talking about <linux/mount.h>'s
MOVE_MOUNT_BENEATH? That's a move_mount flag, and I don't see what that has
to do with openat2. Or are you saying that openat2 might not support
<linux/openat2.h>'s RESOLVE_BENEATH flag? Under what conditions might that
be, exactly? Can you give some plausible user code to illustrate the openat2
example you're thinking of?

I was just giving it as an example where "just try it" is not really
ideal for userspace today. clone3(2) is an extensible-struct syscall
that needs this.

I still fail to understand how a hypothetical "give me the supported flags"
openat2 flag would be useful enough to justify complicating the openat2 API
today.

My only concern is that it would break recompiles if/when we change it
back. If that is not a concern for glibc as a project then you are of
course free to do whatever makes sense for glibc.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/