Merge branch 'sleepable uprobe support'
authorAlexei Starovoitov <ast@kernel.org>
Fri, 17 Jun 2022 02:27:30 +0000 (19:27 -0700)
committerAlexei Starovoitov <ast@kernel.org>
Fri, 17 Jun 2022 02:27:37 +0000 (19:27 -0700)
commit88bf18581375aa9b891e390aaf134b30d94232b3
treebc5e33450d2453b1449a83b0fe21ce943145f4d3
parent3e6fe5ce4d4860c3a111c246fddc6f31492f4fb0
parentcb3f4a4a462b46eb5487ad806d58e34824c49044
Merge branch 'sleepable uprobe support'

Delyan Kratunov says:

====================

This series implements support for sleepable uprobe programs.
Key work is in patches 2 and 3, the rest is plumbing and tests.

The main observation is that the only obstacle in the way of sleepable uprobe
programs is not the uprobe infrastructure, which already runs in a user-like
context, but the rcu usage around bpf_prog_array.

Details are in patch 2 but the tl;dr is that we chain trace_tasks and normal rcu
grace periods when releasing to array to accommodate users of either rcu type.
This introduces latency for non-sleepable users (kprobe, tp) but that's deemed
acceptable, given recent benchmarks by Andrii [1]. We're a couple of orders of
magnitude under the rate of bpf_prog_array churn that would raise flags (~1MM/s per Paul).

  [1]: https://lore.kernel.org/bpf/CAEf4BzbpjN6ca7D9KOTiFPOoBYkciYvTz0UJNp5c-_3ptm=Mrg@mail.gmail.com/

v3 -> v4:
 * Fix kdoc and inline issues
 * Rebase

v2 -> v3:
 * Inline uprobe_call_bpf into trace_uprobe.c, it's just a bpf_prog_run_array_sleepable call now.
 * Do not disable preemption for uprobe non-sleepable programs.
 * Add acks.

v1 -> v2:
 * Fix lockdep annotations in bpf_prog_run_array_sleepable
 * Chain rcu grace periods only for perf_event-attached programs. This limits
   the additional latency on the free path to use cases where we know it won't
   be a problem.
 * Add tests calling helpers only available in sleepable programs.
 * Remove kprobe.s support from libbpf.
====================

Signed-off-by: Alexei Starovoitov <ast@kernel.org>