Re: Next-level bug in SRCU implementation of RCU Tasks Trace + PREEMPT_RT

[Boqun Feng <boqun@kernel.org>]

On Thu, Mar 19, 2026 at 01:14:08PM -0700, Boqun Feng wrote:
[...]
> > Also, any unconditional deferral in the caller for APIs that can "hold
> > locks" to avoid all this is not without its cost.
> > 
> > The implementation of RCU knows and can stay in sync with those
> > conditions for when deferral is needed, and hide all that complexity
> > from the caller. The cost should definitely be paid by the caller if
> > we would break the API's broad contract, e.g., by trying to invoke it
> 
> The thing is, lots of the synchronization primitives existed before BPF,
> and they were not designed or implemented with "BPF safe" in mind, and
> they could be dragged into BPF core code path if we begin to use them.
> For example, irq_work may be just "happen-to-work" here, or there is a

Correction: irq_work is designed to be NMI safe (at least when queueing
on the local CPU), so it's potential the bpf_defer() I proposed.

Regards,
Boqun

> bug that we are missing. It would be rather easier or clearer if we
> design a dedicate defer mechanism with BPF core in mind, and then we use
> that for all the deferrable operations.
> 
> Regards,
> Boqun
> 
> > in NMI which it is not supposed to run in yet, in that case we already
> > handle things using irq_work. Anything more complicated than that is
> > hard to scale. All of this may also change in the future where we
> > support call_rcu_nolock() to make it work everywhere, and only defer
> > when we detect reentrancy (in the same or different context).
> > 
> > 
> > 
[..]