Re: [PATCH 1/6] sched/core: Handle pick_task() releasing the rq lock

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Aug 07, 2026 at 11:02:16AM -1000, Tejun Heo wrote:
> Core scheduling's pick_next_task() breaks when a ->pick_task()
> implementation can release the rq lock. The selection state derived on entry
> is only valid while the lock is held continuously. Once a pick can drop the
> lock, an interleaving selection can invalidate all of it: the single-CPU
> fast path can commit an uncookied pick although the core went cookied during
> the release, and forceidle committed by the interleaving selection skews the
> restarted pass's accounting.
> 
> Fix it by restarting the whole selection when a pick returns RETRY_TASK
> after releasing the lock: a single restart point above the state derivation
> replaces the per-loop restart labels, so a retry picks up state committed by
> interleaving selections and accounts and resets forceidle like a fresh
> selection would.
> 
> need_sync and fi_before latch across retries. Clock validity can't be
> re-derived - there is no program-ordered way to tell whether the own and
> core rq clocks are still updated after the lock was released, as other
> lockers' pin cycles may or may not have invalidated them. When restarting,
> clear core_clock_updated so that the sibling loop re-updates the core rq,
> and update the own rq clock if invalidated.
> 
> Fixes: 4c95380701f5 ("sched/ext: Fold balance_scx() into pick_task_scx()")
> Cc: stable@vger.kernel.org # v6.19+
> Signed-off-by: Tejun Heo <tj@kernel.org>

Ah, yes indeed.

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