Re: O_CLOEXEC use for OPEN_TREE_CLOEXEC
From: Andy Lutomirski <luto@amacapital.net>
Date: 2026-01-14 19:43:12
Also in:
linux-fsdevel, lkml
On Wed, Jan 14, 2026 at 8:09 AM Christian Brauner [off-list ref] wrote:
On Tue, Jan 13, 2026 at 11:40:55PM +0100, Florian Weimer wrote:quoted
In <linux/mount.h>, we have this: #define OPEN_TREE_CLOEXEC O_CLOEXEC /* Close the file on execve() */ This causes a few pain points for us to on the glibc side when we mirror this into <linux/mount.h> becuse O_CLOEXEC is defined in <fcntl.h>, which is one of the headers that's completely incompatible with the UAPI headers. The reason why this is painful is because O_CLOEXEC has at least three different values across architectures: 0x80000, 0x200000, 0x400000 Even for the UAPI this isn't ideal because it effectively burns three open_tree flags, unless the flags are made architecture-specific, too.I think that just got cargo-culted... A long time ago some API define as O_CLOEXEC and now a lot of APIs have done the same. I'm pretty sure we can't change that now but we can document that this shouldn't be ifdefed and instead be a separate per-syscall bit. But I think that's the best we can do right now.
How about, for future syscalls, we make CLOEXEC unconditional? If anyone wants an ofd to get inherited across exec, they can F_SETFD it themselves. --Andy