Re: [PATCH v3 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] The SCX_CAP_ENQ_IMMED capability inadvertently allows sub-schedulers to enqueue non-IMMED tasks to the local DSQ, breaking the CPU isolation guarantee.
--

--- Patch [25]: [PATCH v3 sched_ext/for-7.3 25/36] sched_ext: Add the SCX_CAP_ENQ_IMMED cap ---
commit a4e853c803659c3e80f2be7fcff03bb32c0a8907
Author: Tejun Heo <tj@kernel.org>
sched_ext: Add the SCX_CAP_ENQ_IMMED cap

This commit replaces the dummy placeholder with the SCX_CAP_ENQ_IMMED
capability to gate inserting IMMED tasks onto a local DSQ. It is intended
to guarantee that IMMED work gets running at once or is handed back,
preventing tasks from piling up on the CPU queue.

> diff --git a/kernel/sched/ext/sub.h b/kernel/sched/ext/sub.h
> index 51400e174cd00..f3548976800b0 100644
> --- a/kernel/sched/ext/sub.h
> +++ b/kernel/sched/ext/sub.h
[ ... ]
> @@ -106,13 +106,13 @@ 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 0;
> +	return SCX_CAP_ENQ_IMMED;
>  }

[Severity: High]
Does unconditionally returning SCX_CAP_ENQ_IMMED allow sub-schedulers to
bypass IMMED enforcement?

If a sub-scheduler calls scx_bpf_dsq_insert() or similar dispatch kfuncs
with enq_flags = 0 (omitting SCX_ENQ_IMMED) and without setting
SCX_OPS_ALWAYS_ENQ_IMMED, scx_caps_for_enq() will still return
SCX_CAP_ENQ_IMMED.

Because the sub-scheduler possesses this baseline capability, would the
check in scx_local_or_reject_dsq() pass and allow the task to be enqueued
to the local DSQ without IMMED semantics? This seems like it could allow
a sub-scheduler to swamp a shared CPU's local DSQ, breaking the isolation
guarantee that IMMED work can never pile up.

>  
>  /* map queued @p to the SCX_CAP_* bit required to stay on its local DSQ */
>  static inline u64 scx_caps_for_task(struct task_struct *p)
>  {
> -	return 0;
> +	return SCX_CAP_ENQ_IMMED;
>  }

[Severity: High]
Similarly, does unconditionally returning SCX_CAP_ENQ_IMMED for already
queued tasks fail to enforce higher capability requirements for non-IMMED
tasks?

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