On Tue, Jul 28, 2026 at 11:39:33AM +0100, Matt Fleming wrote:
> On Mon, Jul 13, 2026 at 11:12:45AM +0100, Matt Fleming wrote:
> > From: Matt Fleming <[email protected]>
> >
> > call_rcu_tasks_generic() can be invoked with IRQs disabled, and on
> > older kernels this exposed an ABBA deadlock against the scheduler
> > runqueue lock via sched_ext's task-storage teardown path:
> >
> > CPU 0 CPU 1
> > ----- -----
> > sched_ext_free()
> > task_rq_lock()
> > raw_spin_lock(rq->lock)
> > rcu_tasks_one_gp()
> > raw_spin_lock(cbs_gbl_lock)
> > scx_exit_task()
> > bpf_task_storage_delete()
> > call_rcu_tasks_generic()
> > raw_spin_lock(cbs_gbl_lock)
> > <blocks>
> > _printk()
> > console_unlock()
> > try_to_wake_up()
> > raw_spin_lock(rq->lock)
> > <blocks>
>
> Hey Paul, it looks like this didn't get picked up and now won't apply
> cleanly to your tree. Should I submit a v2?
Apologies for the delay!!!
It turns out that there are "interesting" relationships to certain BPF
programs and the CPU hotplugs being unearthed in the discussions of this
patch's call_rcu() and call_srcu(). Which we *might* be getting to the
bottom of.
And that these affect call_rcu_tasks() as well. And which are sadly
off-list, otherwise, I would invite you to join in. :-(
If you would be willing to do a v2, one piece of feedback that does not
depend on the discussions is that RCU Tasks can sometimes have multiple
callback queues, and when that happens, rcu_barrier_tasks_generic()
must drain all of them.
Alternatively, please do feel free to hold off until we get the public
posting of the call_rcu() and call_srcu() deferral patch series.
It will likely provide a helper function that you can use. To your
credit, your initial definition of the irqsoff local variable within
call_rcu_tasks_generic() is what we seem to be settling on. It should
also clarify what needs to happen when a CPU goes offline with deferred
callbacks.
Again, please accept my apologies for being slow!
Thanx, Paul
