On Wed, May 29, 2024 at 12:08:34PM +0200, Lennart Poettering wrote: > Hi! > > It seems that the bpf code in the kernel sometimes leaks > kernel-internal error codes, i.e. those from include/linux/errno.h > into userspace (as opposed to those from > include/uapi/asm-generic/errno.h which are public userspace facing > API). > > According to the comments from that internal header file: "These > should never be seen by user programs." > > Specifically, this is about ENOTSUPP, which userspace simply cannot > handle, there's no error 524 defined in glibc or anywhere else. > > We ran into this in systemd recently: > > https://github.com/systemd/systemd/issues/32170#issuecomment-2076928761 > > (a google search reveals others were hit by this too) > > We commited a work-around for this for now: > > https://github.com/systemd/systemd/pull/33067 > > But it really sucks to work around this in userspace, this is a kernel > internal definition after all, conflicting with userspace (where > ENOTSUPP is just an alias for EOPNOTSUPP), hence not really fixable. > > ENOSUPP is kinda useless anyway, since EOPNOTSUPP is pretty much > equally expressive, and something userspace can actually handle. > > Various kernel subsystems have been fixed over the years in similar > situations. For example: > > https://patchwork.kernel.org/project/linux-wireless/patch/20231211085121.3841b71c867d.Idf2ad01d9dfe8d6d6c352bf02deb06e49701ad1d@changeid/ > > or > > https://patchwork.kernel.org/project/linux-media/patch/af5b2e8ac6695383111328267a689bcf1c0ecdb1.1702369869.git.sean@xxxxxxxx/ > > or > > https://patchwork.ozlabs.org/project/linux-mtd/patch/20231129064311.272422-1-acelan.kao@xxxxxxxxxxxxx/ > > I think BPF should really fix that, too. hm, I don't think we can change that, user space already depends on those values and we'd break it with new value it's unfortunate, but I don't think we can do much about that, other than enforcing EOPNOTSUPP for new code jirka > > Or if you insist on leaking internals to userspace then please move > the definition to the public "uapi" headers, but yikes you are in for > some pain then given the conflicting userspace definitions. > > Lennart >
