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

From: Masami Hiramatsu
Date: Sun Mar 22 2015 - 22:17:36 EST

(2015/03/23 3:03), Alexei Starovoitov wrote:
> On 3/22/15 3:06 AM, Masami Hiramatsu wrote:
>> (2015/03/22 1:02), Alexei Starovoitov wrote:
>>> On 3/21/15 5:14 AM, Masami Hiramatsu wrote:
>>>> (2015/03/21 8:30), Alexei Starovoitov wrote:
>>>>> 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.

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

Thank you,

Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at