Re: Fwd: struct pt_regs missing in /usr/include/ tree for eBPF program compile
From: Alexei Starovoitov <hidden>
Date: 2017-08-23 05:01:17
Also in:
lkml
On Mon, Aug 14, 2017 at 02:08:07PM +0200, Heiko Carstens wrote:
quoted
Now, I would like to avoid going down that road to pull in kernel internal headers into test_verifier.c, could we instead add a bpf_ptregs.h helper in tools/testing/selftests/bpf/, where s390 and arm64 would put a definition to fallback when otherwise not available? Admittedly, it's a bit of a hack if exporting them is not an option, but 'normal' tracing progs would consult kernel headers anyway. Thoughts?I really don't think that struct pt_regs is part of uapi and should be exported. We did change the layout of the pt_regs structure more than once and would like to be able to do so in the future as well.
I think Daniel's suggestion above it the best solution and doesn't prevent future modification to pt_regs on s390.
We could add the hack you outlined above, but I'd like to have the same API for all architectures. Otherwise we keep adding special cases for architectures which don't export pt_regs via uapi (which I think is wrong).
I don't see any other choice but to make this hack for s390/arm64 The programs need to be able to access the registers in the format that kernel keeps, since the programs are attached to kprobe and perf_events and are walking in-kernel data structures. It's already well understood that kprobe+bpf is unstable api, so having pt_regs being unstable on s390/arm64 doesn't make it any worse.