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

Hi Paul,

On 2025-08-28 01:42, Aleksa Sarai wrote:

quoted

quoted

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.

OK, but from what I can see there's no identified possibility that
openat2 will modify the objects its arguments point to, just as there's
no identified possibility that plain openat will do so (in a
hypothetical extension to remove unnecessary slashes from its filename
argument, say).

While it is true that openat cannot be extended in this way, for
openat2 (whether or not it eventually materializes in Linux) there
already is the RFC patch series proposing CHECK_FIELDS that Aleksa
referred to earlier. And it's not just that: it has been mentioned as
a potential future direction even when the openat2 syscall was
implemented [1]. I think we should interpret this to mean that there
is indeed a possibility for openat2.

In that case it's pretty clear that glibc should mark the open_how
argument as pointer-to-const, just as glibc already marks the filename
argument.

Unless the kernel marks open_how as const, glibc marking it as const
can lead to additional maintenance complications down the line: in the
future if the kernel starts modifying open_how, glibc's openat2
wrapper will no longer align with the kernel's behavior. At that
point, glibc will either need to discard the const (which will cause
any existing users of the wrapper to fail to recompile), or glibc will
need to handle the kernel's new behavior in the wrapper (which will
lead to further divergence from the behavior of the syscall that we
would claim to wrap). Neither of these seems problem-free. On the
other hand, following the kernel's declaration will mean that should
the kernel choose to mark it const, we can easily follow suit in glibc
without breaking recompiles.

Earlier on in this thread, Aleksa mentioned sched_setattr as
establishing precedent for the kernel modifying non-const objects. It
looks like glibc actually does provide a sched_setattr wrapper since
2.41. The relevant argument hasn't been marked as const and the kernel
does modify the contents, and glibc's syscall wrapper simply passes it
through. So we already do this.

Based on all this, I feel that leaving open_how as-is is the easier
and more maintenance-friendly choice for the syscall wrapper.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fddb5d430ad9fa91b49b1d34d0202ffe2fa0e179

--
Arjun Shankar
he/him/his