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. 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