Re: [PATCH 08/18] sched_ext: Fix a cpu idling with a runnable rescuee

[Tejun Heo <tj@kernel.org>]

Hello,

On Tue, Oct 27, 2026 at 12:34:25AM +0000, sashiko-bot@kernel.org wrote:
> [Severity: Medium]
> Can calling scx_rescue_keep() inside dispatch_one() restore prev->scx.slice
> prematurely when the pick is subsequently retried or aborted?
...
> Should the slice restoration via scx_rescue_keep() be deferred to the
> verdict == SCX_DSP_PREV && !p->scx.slice block in do_pick_task_scx(), with
> dispatch_one() only checking whether the rescuee can be kept (for example,
> scx_rescue_slice_remaining(rq) > 0 && !scx_bypassing(prev_sch, cpu))?

Neither case is wrong. The scheduler zeroing the slice only guarantees a
pass through the dispatch path. That pass happened, the scheduler had
nothing, and the rescuee got its slice back afterwards.

If something puts a task on the local DSQ while the rq lock is dropped,
whether it runs before or after the rescuee doesn't matter. A task that
can't wait on the local DSQ should have IMMED set, and dispatch already
schedules the IMMED reenqueue when it keeps prev. Without IMMED, there's
no guarantee about position on the local DSQ anyway. Left as is.

Thanks.

--
tejun