On Sun, Jan 11, 2026 at 2:09 PM Steven Rostedt <[email protected]> wrote: > > On Sun, 11 Jan 2026 12:04:51 -0800 > Alexei Starovoitov <[email protected]> wrote: > > > The diff has nothing to do with bpf needs and/or bpf internals. > > It's really about being a good citizen of PREEMP_RT. > > bpf side already does migrate_disable, > > rcu_read_lock, srcu_fast/task_trace when necessary. > > Most of the time we don't rely on any external preempt state or rcu/srcu. > > Removing guard(preempt_notrace)(); from tracepoint invocation > > would be just fine for bpf. Simple remove will trigger bug > > on cant_sleep(), but that's a trivial fix. > > Oh, so you are OK replacing the preempt_disable in the tracepoint > callbacks with fast SRCU?
yes, but.. > Then I guess we can simply do that. Would it be fine to do that for > both RT and non-RT? That will simplify the code quite a bit. Agree. perf needs preempt_disable in their callbacks (as this patch does) and bpf side needs to add migrate_disable in __bpf_trace_run for now. Though syscall tracepoints are sleepable we don't take advantage of that on the bpf side. Eventually we will, and then rcu_lock inside __bpf_trace_run will become srcu_fast_lock. The way to think about generic infrastructure like tracepoints is to minimize their overhead no matter what out-of-tree and in-tree users' assumptions are today, so why do we need preempt_disable or srcu_fast there? I think today it's there because all callbacks (perf, ftrace, bpf) expect preemption to be disabled, but can we just remove it from tp side? and move preempt_disable to callbacks that actually need it? I'm looking at release_probes(). It's fine as-is, no?
