Re: [PATCH v2] rcu: Use an intermediate irq_work to start process_srcu()

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

On Tue, Mar 24, 2026 at 4:27 AM Frederic Weisbecker <frederic@kernel.org> wrote:
>
> Le Fri, Mar 20, 2026 at 03:29:16PM -0700, Boqun Feng a écrit :
> > Since commit c27cea4416a3 ("rcu: Re-implement RCU Tasks Trace in terms
> > of SRCU-fast") we switched to SRCU in BPF. However as BPF instrument can
> > happen basically everywhere (including where a scheduler lock is held),
> > call_srcu() now needs to avoid acquiring scheduler lock because
> > otherwise it could cause deadlock [1]. Fix this by following what the
> > previous RCU Tasks Trace did: using an irq_work to delay the queuing of
> > the work to start process_srcu().
> >
> > [boqun: Apply Joel's feedback]
> > [boqun: Apply Andrea's test feedback]
> >
> > Reported-by: Andrea Righi <arighi@nvidia.com>
> > Closes: https://lore.kernel.org/all/abjzvz_tL_siV17s@gpd4/
> > Fixes: commit c27cea4416a3 ("rcu: Re-implement RCU Tasks Trace in terms of SRCU-fast")
> > Link: https://lore.kernel.org/rcu/3c4c5a29-24ea-492d-aeee-e0d9605b4183@nvidia.com/ [1]
> > Suggested-by: Zqiang <qiang.zhang@linux.dev>
> > Tested-by: Andrea Righi <arighi@nvidia.com>
> > Signed-off-by: Boqun Feng <boqun@kernel.org>
>
> I have the feeling that this problem should be solved at the BPF
> level. Tracepoints can fire at any time, in that sense they are like NMIs,
> and NMIs shouldn't acquire locks, let alone call call_rcu_*()
>
> BPF should arrange for delaying such operations to more appropriate contexts.
>
> I understand this is a regression trigerred by an RCU change but to me it
> rather reveals a hidden design issue rather than an API breakage.

You all are still missing that rcu_tasks_trace was developed
exclusively for bpf with bpf requirements.
Then srcu_fast was introduced and then it looked like that
task_trace can be replaced with srcu_fast and that's where the problems
discovered. So either task_trace need to be resurrected
or srcu_fast needs to be fixed.
Let's punt to bpf subsystem isn't an option.
At this rate we will have rcu_bpf. Which rcu_tasks_trace effectively was.