On Sat, Sep 12, 2026 at 3:28 PM Paul E. McKenney <[email protected]> wrote: > > On Sat, Sep 12, 2026 at 12:40:55PM -0700, Alexei Starovoitov wrote: > > On Sat Sep 12, 2026 at 11:03 AM PDT, Paul E. McKenney wrote: > > > > > > In the old kernels, yes, we have current->trc_reader_nesting++. > > > In the newer kernels, Tasks Trace RCU is instead implemented in terms > > > of SRCU-fast, which instead increments per-CPU counters. Which among > > > other thins is a bit faster and does not need to hook into the scheduler. > > > > old kernels? I'm confused. > > rcu_read_lock_trace() in bpf-next is doing t->trc_reader_nesting++ > > and then calls __srcu_read_lock_fast(). > > > > Are you talking about some RCU branch that you target for next merge window? > > No, I was thinking of rcu_read_lock_tasks_trace(), forgetting that > rcu_read_lock_trace() is still used. (For good reason, just be clear.) > Your comments are quite correct for rcu_read_lock_trace(). > > Hmmm... Josep's using t->trc_reader_nesting would break for > partially overlapping RCU Tasks and rcu_read_lock_trace() readers. > > But yes, your #5 makes sense: Deprecate RCU Tasks, upgrade RCU Tasks > Trace to check for preemption from within trampolines, and move RCU > Tasks users over to the rcu_read_lock_trace() variant of RCU Tasks Trace. > (Or am I still missing your point?)
Pretty much. This way bpf trampoline stays as-is. No extra overhead there. rcu tasks users (faultable tracepoints and what else ? ) switch to rcu_read_lock_trace(). The only difference for faultable tracepoints is extra t->trc_reader_nesting++. I have studied the rest of the patches in the series, so this proposal can be completely off the mark.
