Re: Re: [PATCH v9 tip 3/9] tracing: attach BPF programs to kprobes

(2015/03/23 3:03), Alexei Starovoitov wrote:

On 3/22/15 3:06 AM, Masami Hiramatsu wrote:

quoted

(2015/03/22 1:02), Alexei Starovoitov wrote:

quoted

On 3/21/15 5:14 AM, Masami Hiramatsu wrote:

quoted

(2015/03/21 8:30), Alexei Starovoitov wrote:

quoted

Note, kprobes are _not_ a stable kernel ABI, so bpf programs attached to
kprobes must be recompiled for every kernel version and user must supply correct
LINUX_VERSION_CODE in attr.kern_version during bpf_prog_load() call.

Would you mean that the ABI of kprobe-based BPF programs? Kprobe API/ABIs
(register_kprobe() etc.) are stable, but the code who use kprobes certainly
depends the kernel binary by design. So, if you meant it, BPF programs must
be recompiled for every kernel binaries (including configuration changes,
not only its version).

yes. I mainly meant that bpf+kprobe programs must be recompiled
for every kernel binary.

Hmm, if so, as we do in perf (and systemtap too), you'd better check
kernel's build-id instead of the kernel version when loading the
BPF program. It is safer than the KERNEL_VERSION_CODE.

It's not about safety. As I mentioned in cover letter:
"version check is not used for safety, but for enforcing 'non-ABI-ness'"
In other words it's like check-box next to 'terms and conditions'
paragraph that the user has to click before he can continue.
By providing 'kern_version' during loading the user accepts the fact
that bpf+kprobe is not a stable ABI. Nothing more and nothing less.
build-id cannot achieve that, because it cannot be checked from inside
the kernel.

Ah, I see. Hmm, I think we'd better have such interface (kernel API).

User space tools that will compile ktap/dtrace scripts into bpf might
use build-id for their own purpose, but that's a different discussion.

Agreed.
I'd like to discuss it since kprobe event interface may also have same
issue.

Thank you,


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt-FCd8Q96Dh0JBDgjK7y7TUQ@public.gmane.org