On Wed, Mar 18, 2026 at 05:47:10PM +0100, Sebastian Andrzej Siewior wrote:
> 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.
We would need a lockless enqueue, which we have in llist.h.
The irq-work to actually do the call_rcu() or similar.
There would also need to be rcu_barrier() changes, for example, to
drain all the llists.
> I mean I am curious here who needs it any why ;)
You got it right above, BPF. ;-)
They currently check in_nmi() and to the irq-work step themselves.
Thanx, Paul
