Re: [PATCH 09/15] sched_ext: Generalize the reject DSQ reenqueue path

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Transient failure to set a reject reason leaves the task permanently stranded on the reject DSQ.
--

--- Patch [9]: [PATCH 09/15] sched_ext: Generalize the reject DSQ reenqueue path ---
commit b71cb24d29b22c40aa0f3482e228cd8cd043d267
Author: Andrea Righi <arighi@nvidia.com>

sched_ext: Generalize the reject DSQ reenqueue path

This commit makes the reject DSQ unconditional and moves its drain path into
the core sched_ext implementation. It also records the reenqueue reason on
each parked task to support future proxy execution features.

> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c

[ ... ]

> @@ -4399,6 +4401,57 @@ static void process_deferred_reenq_users(struct rq *rq)
[ ... ]
> +static void scx_reenq_reject(struct rq *rq)
> +{
[ ... ]
> +	/*
> +	 * Move tasks to a private list so a task re-rejected by
> +	 * 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) {
> +		u32 reason = p->scx.reject_reason;
> +
> +		/* migration_pending tasks should have bypassed to local DSQ */
> +		if (WARN_ON_ONCE(p->migration_pending))
> +			continue;
> +		if (WARN_ON_ONCE(!reason))
> +			continue;

[Severity: High]
If !reason is true and this WARN_ON_ONCE triggers, will this continue
statement leave the task permanently stranded on the reject DSQ list?

Because the continue bypasses scx_dispatch_dequeue() and the subsequent
list_add_tail(), the task is never unlinked from rq->scx.reject_dsq.list.

Since the reject DSQ is just a staging list, the task won't be scheduled,
and every subsequent run of scx_reenq_reject() will hit this continue again.

Should this error path safely recover the task (perhaps by falling back to
the local DSQ) or at least unlink it instead of leaving it in an unrecoverable
hung state?

> +
> +		scx_dispatch_dequeue(rq, p);
> +		p->scx.reject_reason = SCX_TASK_REENQ_NONE;

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260728154425.1549660-1-arighi@nvidia.com?part=9