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

[Boqun Feng <boqun@kernel.org>]

On Thu, Mar 19, 2026 at 05:33:50PM +0100, Sebastian Andrzej Siewior wrote:
> On 2026-03-19 09:27:59 [-0700], Boqun Feng wrote:
> > On Thu, Mar 19, 2026 at 10:03:15AM +0100, Sebastian Andrzej Siewior wrote:
> > > Please just use the queue_delayed_work() with a delay >0.
> > > 
> > 
> > That doesn't work since queue_delayed_work() with a positive delay will
> > still acquire timer base lock, and we can have BPF instrument with timer
> > base lock held i.e. calling call_srcu() with timer base lock.
> > 
> > irq_work on the other hand doesn't use any locking.
> 
> Could we please restrict BPF somehow so it does roam free? It is
> absolutely awful to have irq_work() in call_srcu() just because it
> might acquire locks.
> 

I agree it's not RCU's fault ;-)

I guess it'll be difficult to restrict BPF, however maybe BPF can call
call_srcu() in irq_work instead? Or a more systematic defer mechanism
that allows BPF to defer any lock holding functions to a different
context. (We have a similar issue that BPF cannot call kfree_rcu() in
some cases IIRC).

But we need to fix this in v7.0, so this short-term fix is still needed.

Regars,
Boqun

> > Regards,
> > Boqun
> > 
> Sebastian