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

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

On 2026-03-18 09:32:07 [-0700], Paul E. McKenney wrote:
> > What remains?
> 
> With that patch, we no longer have call_srcu() directly acquiring a
> non-raw spinlock, but as you say, we still have the wakeup problem.

Isn't this is just srcu_funnel_gp_start()? And where you could ensure
that it is always a delayed worked (delay always 1+) that is scheduled
so that it always setups a timer and never does a direct wake.

> > Popular? Okay. Keep me posted, please.
> 
> Will do.  Just out of curiosity, what are your concerns?

We don't have many NMI code paths and the possibilities are quite dense.
I would imagine having this possibility would lead to things that
wouldn't be needed otherwise. I mean we don't even allow allocating
memory from hardirq (except for _nolock() variant which I think is used
by bpf for $reasons) but need to call rcu_free from NMI.
This would require to remove an item from some kind of data structure
without regular locking. Unless RCU is used to get a delayed invocation
of some sorts.
I mean I am curious here who needs it any why ;)

> 							Thanx, Paul

Sebastian