Re: [PATCH v4 sched_ext/for-7.3 32/40] sched_ext: Add the SCX_CAP_ENQ cap

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Tasks with carried-in IMMED state are spuriously rejected during internal movements (like RESTORE) if the scheduler lacks SCX_CAP_ENQ.
--

--- Patch [32]: [PATCH v4 sched_ext/for-7.3 32/40] sched_ext: Add the SCX_CAP_ENQ cap ---
commit ff6a1550bc7578cdbaff320215c7593bfdd63815
Author: Tejun Heo <tj@kernel.org>

sched_ext: Add the SCX_CAP_ENQ cap

This commit adds SCX_CAP_ENQ, which gates inserting tasks onto a cid's local
DSQ. Unlike IMMED enqueue, plain enqueues can pile up, so ENQ is the stronger
cap and implies ENQ_IMMED.

> diff --git a/kernel/sched/ext/sub.h b/kernel/sched/ext/sub.h
> index e4c645dfbf7b5..1d278c0d16026 100644
> --- a/kernel/sched/ext/sub.h
> +++ b/kernel/sched/ext/sub.h
[ ... ]
> @@ -106,18 +106,26 @@ static inline u64 scx_missing_caps(struct scx_sched *sch, s32 cpu, u64 needed)
>  /* map @enq_flags to the SCX_CAP_* bit required for the local-DSQ insert */
>  static inline u64 scx_caps_for_enq(u64 enq_flags)
>  {
> -	return SCX_CAP_ENQ_IMMED;
> +	if (enq_flags & SCX_ENQ_IMMED)
> +		return SCX_CAP_ENQ_IMMED;
> +	return SCX_CAP_ENQ;
>  }

[Severity: High]
Does this code incorrectly reject tasks with a carried-in IMMED state during
internal movements?

When an internal scheduling movement like ENQUEUE_RESTORE occurs for a
running IMMED task, scx_do_enqueue_task() preserves the task's SCX_TASK_IMMED
flag by jumping to the local_norefill path.

However, the enq_flags passed to scx_dispatch_enqueue() and subsequently
scx_local_or_reject_dsq() do not have SCX_ENQ_IMMED set.

Since this function only checks enq_flags, it evaluates the requirement as
SCX_CAP_ENQ when called from scx_local_or_reject_dsq():

kernel/sched/ext/sub.c:scx_local_or_reject_dsq() {
    ...
    u64 missing = scx_missing_caps(sch, cpu_of(rq), scx_caps_for_enq(*enq_flags));
    ...
}

If the sub-scheduler holds SCX_CAP_ENQ_IMMED but not SCX_CAP_ENQ, the capability
check fails. This causes the task to be evicted to the reject DSQ and stripped
of its IMMED protection.

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