>The fixes tag should probably point to 053c8e1f235dc or a subsequent patch?
>bpf_mprog_query() and tcx_prog_query() were only introduced there. >How come your userspace passes shorter uatter to query newer >BPF_TCX_EGRESS attachment? btw, If there is a strong preference for the BPF_TCX_EGRESS type, specifically, that userspace shouldn't send a size smaller than the newly added structure when using the new attchment type, I can modify my patch to limit the fix to the BPF_CGROUP_INET_INGRESS type only. I do agree newly added BPF_TCX_EGRESS and the existing BPF_CGROUP_INET_INGRESS worth a different discussion. On Fri, May 29, 2026 at 12:01 AM Yuyang Huang <[email protected]> wrote: > > >It seems you haven't convinced Alexei in that thread. > >Attached below. > > Thanks for the test program. It proves my hypothesis: you had to > manually unmap a page boundary to force that `-EFAULT`. The part that > is still under discussion is whether there is a kernel bug or not. I > think there is no question about the behavior of when the -EFAULT will > be triggered. > > > To avoid such stack corruption, you should reserve enough space for the > > query, e.g., by extracting union bpf_attr from kernel BTF vmlinux. > > I agree that your suggestion to extract the layout from BTF is good > practice when writing a new program from scratch. However, our focus > here is on maintaining backward compatibility for existing binaries. > > I think the core question is: **is a 40-byte query a valid request or not?** > > From my understanding, under the syscall ABI contract, passing a > 40-byte buffer (at least for query BPF_CGROUP_INET_INGRESS which has > been stable and supported since 2017) is 100% valid and legal. **The > kernel must never break existing userspace on a kernel upgrade**. > > One example of a syscall that maintains such backward compatibility is > openat2. The documentation notes it as follows: > > EINVAL size was smaller than **any known version of struct open_how**. > > If this bpf() syscall want to follow the same way to maintain the ABI > contract, your `mmap` test actually let kernel return -EINVAL to a > userspace program that passes a 40-byte buffer (declaring `size = > 40`), because the kernel unconditionally tries to write to offset 56, > which happens to be unmapped. > > Are you arguing that the `bpf()` syscall does not need to follow the > ABI contract to maintain backward compatibility, and that it is > expected that newer kernels can break binaries compiled against older > kernels? If you believe that all binaries must be recompiled or > dynamically updated against the latest vmlinux BTF upon every kernel > upgrade, please be explicit about it. > > Thanks, > > Yuyang
