Re: [PATCH sched_ext/for-7.3 21/32] sched_ext: Add reject DSQ for cap-rejected dispatches

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Infinite loop of deferred requeues for exiting tasks or tasks on offline CPUs when the sub-scheduler lacks capabilities.
- [High] Tasks undergoing migration (with p->migration_pending set) are incorrectly rejected to reject_dsq and then skipped during reenqueuing, leaving them stranded indefinitely.
--

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

sched_ext: Add reject DSQ for cap-rejected dispatches

When a sub-scheduler dispatches a task to a CPU it lacks the required
capability on, the task must be rejected rather than allowed to run.
This patch adds a reject DSQ to divert these tasks and hand them back
to the BPF scheduler to re-decide.

> diff --git a/kernel/sched/ext/sub.c b/kernel/sched/ext/sub.c
> index 55437f1d1965f..aea63484edc5a 100644
> --- a/kernel/sched/ext/sub.c
> +++ b/kernel/sched/ext/sub.c

[ ... ]

> @@ -204,6 +204,116 @@ void scx_init_root_caps(struct scx_sched *sch)
>  	}
>  }
>  
> +struct scx_dispatch_q *scx_local_or_reject_dsq(struct scx_sched *sch, struct rq *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));
> +
> +	/* requirements met */
> +	if (likely(!missing))
> +		return &rq->scx.local_dsq;
> +
> +	/*
> +	 * A migration-disabled task must run on this CPU. Let it run and count
> +	 * the violation.
> +	 */
> +	if (unlikely(is_migration_disabled(p))) {
> +		__scx_add_event(sch, SCX_EV_SUB_FORCED_ADMIT, 1);
> +		return &rq->scx.local_dsq;
> +	}

[Severity: High]
Could this create an infinite loop of deferred requeues for exiting tasks
or tasks on offline CPUs?

If a task is exiting (PF_EXITING) or enqueued on an offline CPU while
the sub-scheduler lacks capabilities on that CPU, scx_do_enqueue_task()
routes it directly to the local DSQ:

scx_do_enqueue_task() {
    if (!(sch->ops.flags & SCX_OPS_ENQ_EXITING) &&
        unlikely(p->flags & PF_EXITING)) {
        __scx_add_event(sch, SCX_EV_ENQ_SKIP_EXITING, 1);
        goto local;
    }
}

Since these tasks aren't forcefully admitted here in scx_local_or_reject_dsq()
like migration-disabled tasks are, they are diverted to the reject_dsq.

Then scx_reenq_reject() attempts to re-enqueue them, which triggers the
same goto local path in scx_do_enqueue_task(), resulting in an endless cycle.

> +
> +	p->scx.reenq_reason_caps = missing;
> +	p->scx.reenq_reason_cid = cid;

[ ... ]

> +void scx_reenq_reject(struct rq *rq)
> +{
> +	LIST_HEAD(tasks);
> +	struct task_struct *p, *n;
> +
> +	lockdep_assert_rq_held(rq);
> +
> +	if (list_empty(&rq->scx.reject_dsq.list))
> +		return;
> +
> +	/*
> +	 * Move to a private list so a task re-rejected by the
> +	 * scx_do_enqueue_task() below isn't revisited this round.
> +	 */
> +	list_for_each_entry_safe(p, n, &rq->scx.reject_dsq.list, scx.dsq_list.node) {
> +		/* migration_pending tasks should have bypassed to local DSQ */
> +		if (WARN_ON_ONCE(p->migration_pending))
> +			continue;

[Severity: High]
Are we permanently stranding tasks that have p->migration_pending set?

During an active migration, a task with p->migration_pending might be
routed to a new CPU. If the sub-scheduler lacks capabilities on that CPU,
scx_local_or_reject_dsq() does not forcefully admit it, and instead
diverts the task to the reject_dsq.

When this list is processed here, the task triggers this warning and is
skipped via the continue statement, meaning it never gets re-enqueued
and is left stranded indefinitely.

> +
> +		scx_dispatch_dequeue(rq, p);
> +
> +		if (WARN_ON_ONCE(p->scx.flags & SCX_TASK_REENQ_REASON_MASK))

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