Thread (3 messages) 3 messages, 3 authors, 2017-08-23

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help