On Thu, Oct 15, 2020 at 11:03 PM Jiada Tu <jtu3@...> wrote:

Thanks a lot, Yonghong. From your response:

In your case, the bpf program is to influence io scheduling decisions.
You could implement in a way to do kernel data structure write in
kernel but have a hook to a bpf program to make decision and based on
bpf program return value, kernel can decide what to schedule.

1. How can I make a kernel function use the return value of a eBPF program/function?

e.g., in kernel/events/core.c, for perf event overflow handler, we have

rcu_read_lock();
ret = BPF_PROG_RUN(event->prog, &ctx);
rcu_read_unlock();
out:
__this_cpu_dec(bpf_prog_active);
if (!ret)
return;

event->orig_overflow_handler(event, data, regs);

The above `ret` is the return value from the bpf program.

2. An KProbes related question: from an old article https://lwn.net/Articles/132196/ which was written in 2005, it said:
```
The current KProbes implementation, however, introduces some latency of its own in handling probes. The cause behind this latency is the single kprobe_lock which serializes the execution of probes across all CPUs on a SMP machine.
```
I read it as "functions (e.g., eBPF functions) attached to KProbes are executed in serial, i.e., the same eBPF function can not be run by multiple threads at the same time". As eBPF programs frequently use KProbes to hook to kernel functions, do you know if it's true currently that the calling of a eBPF function/program is single-threaded?

The article is 2005, I am not sure whether this serialization of
kprobes across all CPUs still true or not. bpf subsystem won't prevent
from executing on all cpus in parallelism if kprobe subsystem allows
it.

We recently have kfunc based probing, this is trampoline based, much
faster and does not have this restriction.

Thank you very much, Yonghong! Those are very helpful.