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

[Peter Zijlstra]

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@xxxxxxxxxxxxxxx # v6.19+
> Signed-off-by: Tejun Heo <tj@xxxxxxxxxx>

Suppose the SMT siblings CPU0 and CPU1; this core sched pick nonsense
runs on CPU0 and does that multi pick thing.

For CPU0 it pulls a task from the global DSQ, places it in the local
DSQ, and returns that as the pick. No retry, all good.

Then for CPU1 it does the same, but hits a RETRY, so it stuffs the task
back on the global DSQ and return RETRY.

Then on retry we find a FIFO task on CPU0, because lock-break and all
that.

Now we pick the FIFO task, but have not had an opportunity to put the
CPU0 task back into the global DSQ.

This is still possible, right?