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

[Tejun Heo]

Hello,

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

Yes, that's possible but it's not different from the task being dispatched
and starts running and then getting preempted by a FIFO task or the CPU just
losing to the sibling's pick. Tasks being staged on local DSQs doesn't
really break anything. There's the question of whether we're triggering
reenqueue reliably for SCX_ENQ_IMMED tasks for all siblings, which I don't
think we do for core-sched path but we can get to that later. That's an a
lot less severe problem than oopsing at least.

Thanks.

-- 
tejun