Re: [PATCH v2 sched_ext/for-7.3 25/36] sched_ext: Add the SCX_CAP_ENQ_IMMED cap

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Migration-disabled tasks can stall indefinitely in a sub-scheduler because scx_bpf_sub_dispatch() skips the sub-scheduler's ops.dispatch() when SCX_CAP_BASE is missing on the CPU.
--

commit 317bac7c35f71212ef04d00c194b7f0e57676589
Author: Tejun Heo <tj@kernel.org>

sched_ext: Add the SCX_CAP_ENQ_IMMED cap

Replace the __SCX_CAP_DUMMY placeholder with SCX_CAP_ENQ_IMMED, which gates
inserting IMMED tasks onto a cid's local DSQ. An IMMED enqueue is guaranteed
to either get its task running on the cpu at once or hand it back to the
scheduler.

> diff --git a/kernel/sched/ext/sub.c b/kernel/sched/ext/sub.c
> index e79d30aba0cc0..380e6e5ea72f9 100644
> --- a/kernel/sched/ext/sub.c
> +++ b/kernel/sched/ext/sub.c

[ ... ]

> @@ -1248,6 +1248,14 @@ __bpf_kfunc bool scx_bpf_sub_dispatch(u64 cgroup_id, const struct bpf_prog_aux *
>  		return false;
>  	}
>  
> +	/*
> +	 * Skip a child that does not effectively hold the base cap on this cpu:
> +	 * its inserts would only be rejected. ecaps are synced at the top of
> +	 * balance_one() before dispatch, so this reflects the in-effect state.
> +	 */
> +	if (scx_missing_caps(child, cpu_of(this_rq), SCX_CAP_BASE))
> +		return false;

[Severity: High]
Will this optimization stall migration-disabled tasks indefinitely?

The commit message and comment assume that if SCX_CAP_BASE is missing, all
inserts will be rejected. However, looking at scx_local_or_reject_dsq(),
migration-disabled tasks are explicitly force-admitted even when caps are
missing:

kernel/sched/ext/sub.c:scx_local_or_reject_dsq() {
    ...
    /*
     * A migration-disabled task must run on this CPU. Let it run and count
     * the violation. Refuse preemptions.
     */
    if (unlikely(is_migration_disabled(p))) {
        __scx_add_event(sch, SCX_EV_SUB_FORCED_ADMIT, 1);
        *enq_flags &= ~SCX_ENQ_PREEMPT;
        return &rq->scx.local_dsq;
    }
    ...
}

If a task pinned via migrate_disable is queued internally by a
sub-scheduler, and the sub-scheduler then loses SCX_CAP_BASE on that
CPU, skipping ops.dispatch prevents the task from being dispatched
to the local DSQ where it would have been successfully admitted.

Could this cause the task to be stranded in the sub-scheduler's
internal queues and trigger the stall watchdog?

> +
>  	return scx_dispatch_sched(child, this_rq, this_rq->scx.sub_dispatch_prev,
>  				  true);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706014058.439853-1-tj@kernel.org?part=25