>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
