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

["Paul E. McKenney" <paulmck@xxxxxxxxxx>]

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 <paulmck@xxxxxxxxxx> 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++.

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