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

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-03-19 09:48:16 [-0700], Boqun Feng wrote:
> I agree it's not RCU's fault ;-)

I never claimed it is anyone's fault. I just see that BPF should be able
to do things which kgdb would not be allowed to.

> 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.

I would prefer something substantial before we rush to get a quick fix
and move on.

If we could get that irq_work() part only for BPF where it is required
then it would be already a step forward.

Long term it would be nice if we could avoid calling this while locks
are held. I think call_rcu() can't be used under rq/pi lock, but timers
should be fine.

Is this rq/pi locking originating from "regular" BPF code or sched_ext?

> Regars,
> Boqun
> 
> > > Regards,
> > > Boqun

Sebastian