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

["Alexei Starovoitov" <alexei.starovoitov@xxxxxxxxx>]

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