Re: [PATCH RFC v2 08/15] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline

On Sat, Sep 12, 2026 at 04:59:02PM -0700, Alexei Starovoitov wrote:

On Sat, Sep 12, 2026 at 3:28 PM Paul E. McKenney [off-list ref] wrote:

quoted

On Sat, Sep 12, 2026 at 12:40:55PM -0700, Alexei Starovoitov wrote:

quoted

On Sat Sep 12, 2026 at 11:03 AM PDT, Paul E. McKenney wrote:

quoted

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++.

Let's see what the other tracing guys think.

I have studied the rest of the patches in the series,
so this proposal can be completely off the mark.

This last is highly ambiguous.  Help?  ;-)

							Thanx, Paul