Re: [PATCH 2/6] sched/core: Make core-sched flips wait for in-flight selections

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Aug 07, 2026 at 11:02:17AM -1000, Tejun Heo wrote:
> Core scheduling's pick_next_task() operates on all sibling rqs under one
> acquisition of the shared core-wide lock. A ->pick_task() that releases the
> rq lock leaves every sibling __lock momentarily free, letting
> __sched_core_flip(false) complete mid-selection and rebind rq_lockp() under
> it. The selection resumes on the split locks, touching sibling state it no
> longer protects, and __schedule() finally releases a lock that was never
> taken while leaking the one that was.
> 
> Count in-flight core-wide selections in the leader's rq->core_pick_in_flight
> and make __sched_core_flip() wait for the count to drain. The count only
> changes under the shared lock, which the flip holds while sampling, so no
> other ordering is needed. The wait can repeat while selections overlap, but
> the flip backs off between samples and flips are rare cookie-lifetime
> events.
> 
> sched_core_cpu_deactivate() moves the count to the new leader - a stale copy
> left behind would bias it forever if that CPU later returns as its own
> leader.
> 
> Fixes: 4c95380701f5 ("sched/ext: Fold balance_scx() into pick_task_scx()")

I'm not entirely sure this is the right commit. I suspect this was a
problem right from the beginning. This pick_next_task() always had a
prev_balance() call that could drop the locks IIRC.

Also yuck :/ this is rather prone to starvation, and it will leave the
flip spinning ad-infinitum. But yes, this is the simplest fix I suppose.
It is not like anybody is going to be toggling this on and off very
often.  And if they are, they can bloody well keep the pieces.

Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>