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

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

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?

>
> So we have several ways forward:
>
> 1.	Revert the implementation of RCU Tasks Trace in terms of
> 	SRCU-fast, and use the existing current->trc_reader_nesting++,
> 	as you suggest.
>
> 2.	Deprecate RCU Tasks Trace entirely in favor of RCU Tasks
> 	augmented by rcu_tasks_trampoline_enter() and friends, as
> 	I was suggesting.
>
> 3.	Implement rcu_tasks_trampoline_enter() in terms of SRCU-fast,
> 	keeping the speedup, and put a synchronize_srcu() in the
> 	RCU Tasks grace-period mechanism.  This again deprecates
> 	RCU Tasks Trace entirely in favor of the augmented RCU Tasks.
>
> 4.	It is always good to explicitly state the apparent status quo,
> 	which involves redundant trampoline entry/exit overhead.
>
> 5.	As always, your additional ideas here!
>
> 							Thanx, Paul