Re: [PATCH 13/17] sched_ext: Fix bypassed tasks stalling when the host lacks SCX_CAP_BASE

[Tejun Heo <tj@kernel.org>]

Hello,

On Fri, Oct 23, 2026 at 07:02:35PM +0000, sashiko-bot@kernel.org wrote:
> [Severity: High]
> When bypass_enq_target_dsq() diverts a bypassed task p owned by sch into
> rescue on behalf of host = scx_exec_sched(sch, cpu_of(rq)), can rescue
> overload accounting and watchdog stall attribution still blame sch instead of
> host?
...
> Since host has no rescue_avg charged for those bypassed tasks, won't
> scx_rescue_check_overload() either fail to find a victim and leave host
> unejected, or eject an unrelated sub-scheduler on that CPU?

The overload ejection not working while the owner exits is fine. Left as
is.

> If sch is already exiting, __scx_exit() becomes a no-op via scx_claim_exit()
> while timed_out = true stops both the rq scan and scx_watchdog_workfn()'s
> CPU scan without ejecting host. Should scx_rescue_charge() and
> check_rq_for_timeouts() resolve through scx_exec_sched() when the task's
> scheduler is bypassing on that CPU?

The watchdog taking no action is a problem. If the parent isn't processing
the bypassed tasks right, the child may not be able to exit. Fixed by
"[PATCH 19/17] sched_ext: Fix the stall watchdog blaming a bypassing owner
for a stuck task", posted in this thread, which blames the host for a stuck
task whose owner is bypassing.

> [Severity: Critical]
> Can admitting a bypassed task into rescue here also leave a dangling
> rq->scx.rescue.curr pointer if the task is in state SCX_TASK_NONE?

Right. Fixed by "[PATCH 18/17] sched_ext: Fix use-after-free of a NONE
rescuee leaving sched_ext", also in this thread. switched_from_scx() now
ends the slice for a NONE task.

Thanks.

--
tejun