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

[Frederic Weisbecker <frederic@kernel.org>]

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.

Thanks.

-- 
Frederic Weisbecker
SUSE Labs