On Fri, May 31, 2024 at 12:16 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote: > > On Thu, May 30, 2024 at 04:17:03PM +0200, Lennart Poettering wrote: > > On Do, 30.05.24 14:18, Jiri Olsa (olsajiri@xxxxxxxxx) wrote: > > > > > > 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 > > > > Are you sure about that? To be able to handle this situation that > > userspace program whose existance you are indicating would have had to > > go the extra mile to literally handle error code 524 that is not known > > to userspace otherwise and handle it. If somebody goes the extra mile > > to do that, what makes you think that they didn't just handle it as > > equivalent to regular EOPNOSTUPP? In systemd at least that's what we > > are doing. > > cilium/ebpf [1] library is checking return values just for ENOTSUPP(524) > on multiple places, libbpf has one place to check on that value for > program type detection AFAICS > > jirka > > > [1] https://github.com/cilium/ebpf/ fwiw both libraries can be changed to check for both error codes ENOTSUPP and EOPNOTSUPP, but, as noted earlier, the problem is not limited to bpf. cilium library mentions commit cb9a19fe4aa5 ("uprobes: Introduce prepare_uprobe()") back from 2012. Where installing uprobe would return ENOTSUPP to user space. On bpf side we've switched to EOPNOTSUPP for any new code long ago, but didn't adjust old code, because the damage was done before bpf existed. $ git grep EOPNOTSUPP kernel/bpf|wc -l 56 $ git grep ENOTSUPP kernel/bpf|wc -l 61
