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

[email protected] Tue, 28 Jul 2026 16:00:34 +0000
Newsgroups dev.linux.lists.sched-ext
Message-ID <[email protected]>
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 permanent=
ly stranded on the reject DSQ.
--

--- Patch [9]: [PATCH 09/15] sched_ext: Generalize the reject DSQ reenqueue=
 path ---
commit b71cb24d29b22c40aa0f3482e228cd8cd043d267
Author: Andrea Righi <[email protected]>

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.n=
ode) {
> +		u32 reason =3D 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 unrecovera=
ble
hung state?

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

[ ... ]

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260728154425.1549=
[email protected]?part=3D9