On Mon, Aug 14, 2017 at 02:08:07PM +0200, Heiko Carstens wrote: > > 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.
