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

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Aug 19, 2026 at 11:37:51AM +0200, Peter Zijlstra wrote:
> 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>
> 
> 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?

Ah, I read the follow up patches more carefully, and I think you're
dealing with that here. That and I misremembered how the re-enqueue
worked. I though it was still done in pick_task_scx() on RETRY, but we
moved that to wakeup_preempt_scx().

OK, let me go over all this once more...