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

On 2025-09-01 19:41, Arjun Shankar wrote:

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.

Is this the RFC Aleksa proposed last October 
<https://lkml.org/lkml/2024/10/10/25>? If so, I don't exactly see a 
rousing endorsement there.

If not, where is the later RFC? I'd like to send the critical comments 
I've already sent on this thread. These comments have not been responded 
to adequately.

Unless the kernel marks open_how as const

? The kernel doesn't mark anything as const. It merely copies in or 
copies out. And for openat2, it copies only one way.

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),

There are multiple easy ways out there. For example, glibc could 
document the argument as being pointer-to-const now, but warn that this 
may change to unrestricted pointer later, if the misguided change is 
made to the kernel. This would be similar to the already-existing 
warning in the proposed glibc patch, which warns that you can't assume 
sizeof (struct open_how) is a constant and so you can't expose it in 
library APIs. Of course people can ignore the documentation warnings but 
that's on them.

Better, though, would be to keep the API pointer-to-const. That's much 
cleaner. We can extend it later for a "give me the supported flags" 
flag, wwithout changing it the API away from pointer-to-const.

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.

Although it may be too late to change that misfeature, it's not too late 
to change this one. And even if it was a good idea for sched_setattr, 
that doesn't mean it's a good a good idea for openat2.