On 3/23/15 12:40 AM, Ingo Molnar wrote:
* Alexei Starovoitov <ast@xxxxxxxxxxxx> wrote:
BPF C program attaches to blk_mq_start_request/blk_update_request kprobe events
to calculate IO latency.
...
+/* kprobe is NOT a stable ABI
+ * This bpf+kprobe example can stop working any time.
+ */
+SEC("kprobe/blk_mq_start_request")
+int bpf_prog1(struct pt_regs *ctx)
+{
+ long rq = ctx->di;
+ u64 val = bpf_ktime_get_ns();
+
+ bpf_map_update_elem(&my_map, &rq, &val, BPF_ANY);
+ return 0;
+}
So just to make sure the original BPF instrumentation model is still
upheld: no matter in what way the kernel changes, neither the kprobe,
nor the BPF program can ever crash or corrupt the kernel, assuming the
kprobes, perf and BPF subsystem has no bugs, correct?
yes. of course. That was always #1 requirement.
So 'stops working' here means that the instrumentation data might not
be reliable if kernel internal interfaces change - but it won't ever
make the kernel unreliable in any fashion. Right?
yes. of course.
The only situations where it can 'stop working':
- in-kernel blk_mq_start_request function is renamed, so kprobe cannot
find it and cannot attach.
- arguments to blk_mq_start_request change. Then ctx->di can be
meaningless and using it as key into map is useless.
- whole logic of blk_mq_start_request/blk_update_request pair changes.
then this sample code won't be measuring any useful io latency.
In all cases kernel will never crash (barring bugs in bpf, kprobe
subsystems).
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
