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.
