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

[Joel Fernandes <joelagnelf@nvidia.com>]

On 3/24/2026 7:27 AM, Frederic Weisbecker 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.

Sure, but there is a valid point I think by those who say that "This was
working before the RCU change". So in that sense, we ought to have this
(possibly short-term fix).