Re: [PATCH sched_ext/for-7.3 27/32] sched_ext: Gate kicks on SCX_CAP_BASE and preemption on SCX_CAP_PREEMPT

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Inconsistent capability enforcement when a sub-scheduler dispatches a descendant's task to a local DSQ using SCX_ENQ_PREEMPT.
--

commit 35cbaaff89094ffe7ebdd01799138d2095bbc3dd
Author: Tejun Heo <tj@kernel.org>

sched_ext: Gate kicks on SCX_CAP_BASE and preemption on SCX_CAP_PREEMPT

A kick forces a scheduling event on the target cpu, and a preemption also
evicts the running task. Gate both on caps. Any kick requires baseline
access on the cid, and preempting a task the sub-sched does not own -
whether by a SCX_ENQ_PREEMPT insert or a SCX_KICK_PREEMPT kick - requires
the new SCX_CAP_PREEMPT.

> diff --git a/kernel/sched/ext/sub.c b/kernel/sched/ext/sub.c
> index 2f1e19db8e72c..67ba352828e05 100644
> --- a/kernel/sched/ext/sub.c
> +++ b/kernel/sched/ext/sub.c
[ ... ]
> @@ -222,7 +225,12 @@ struct scx_dispatch_q *scx_local_or_reject_dsq(struct scx_sched *sch, struct rq
>  					       struct task_struct *p, u64 *enq_flags)
>  {
>  	s32 cid = __scx_cpu_to_cid(cpu_of(rq));
> -	u64 missing = scx_missing_caps(sch, cpu_of(rq), scx_caps_for_enq(*enq_flags));
> +	u64 needed = scx_caps_for_enq(*enq_flags);
> +	u64 missing;
> +
> +	if (*enq_flags & SCX_ENQ_PREEMPT)
> +		needed |= scx_caps_for_preempt(sch, rq);
> +	missing = scx_missing_caps(sch, cpu_of(rq), needed);

[Severity: High]
This isn't a bug introduced by this patch, but the newly added SCX_CAP_PREEMPT
check seems to expose a pre-existing context loss issue.

Can this lead to spurious preemption failures when a sub-scheduler dispatches a
descendant's task remotely?

When a sub-scheduler (e.g., A) dispatches a descendant's task (e.g., owned by
B) to a remote CPU using SCX_ENQ_PREEMPT, dispatch_to_local_dsq() delegates to
move_remote_task_to_local_dsq(), which doesn't pass the active scheduler
context (A).

Later, when the task is activated on the remote CPU:

enqueue_task_scx() {
    ...
    struct scx_sched *sch = scx_task_sched(p);
    ...
}

This reconstructs the scheduler context from the task itself, yielding B
instead of A.

When execution reaches scx_local_or_reject_dsq(), the needed capabilities are
checked against B instead of A. Could this incorrectly reject the task, moving
it to the reject_dsq and creating an infinite scheduling loop that triggers the
sched_ext watchdog?

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