Re: [PATCH 10/11] sched_ext: scx_qmap: Add proxy execution support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Infinite re-enqueue loop (hard lockup) for blocked tasks when CPU capability is revoked.
--

--- Patch [10]: [PATCH 10/11] sched_ext: scx_qmap: Add proxy execution support ---
commit 330898ee3998dc8e218d6fe5b7b813cf89e4a38d
Author: Andrea Righi <arighi@nvidia.com>

sched_ext: scx_qmap: Add proxy execution support
    
Add a -B option to opt scx_qmap into queueing mutex-blocked tasks for
proxy execution. Blocked donors are dispatched directly to the local DSQ 
of their current cid with a fresh slice and SCX_ENQ_PREEMPT.

> diff --git a/tools/sched_ext/scx_qmap.bpf.c b/tools/sched_ext/scx_qmap.bpf.c
> index 09aee49120c28..dd308d1c89e2e 100644
> --- a/tools/sched_ext/scx_qmap.bpf.c
> +++ b/tools/sched_ext/scx_qmap.bpf.c

[ ... ]

> @@ -451,6 +451,22 @@ void BPF_STRUCT_OPS(qmap_enqueue, struct task_struct *p, u64 enq_flags)
>  	 */
>  	taskc->core_sched_seq = qa.core_sched_tail_seqs[idx]++;
>  
> +	/*
> +	 * Insert a blocked mutex donor at the head of its current cid's local
> +	 * DSQ with a fresh slice and %SCX_ENQ_PREEMPT, requesting an immediate
> +	 * reschedule. Once selected, the core proxy-exec path can immediately
> +	 * run the mutex owner using the donor's scheduling context.
> +	 *
> +	 * This policy is intentionally unfair and can strongly prioritize tasks
> +	 * using contended mutexes; scx_qmap is a demonstration scheduler and
> +	 * this behavior makes proxy-exec support easy to observe.
> +	 */
> +	if (enq_flags & SCX_ENQ_BLOCKED) {
> +		scx_bpf_dsq_insert(p, SCX_DSQ_LOCAL_ON | scx_bpf_task_cid(p),
> +				   slice_ns, enq_flags | SCX_ENQ_PREEMPT);
> +		return;
> +	}

[Severity: High]
Can this cause a hard lockup if a sub-scheduler dynamically loses CPU
capability?

When a sub-scheduler is used (via the -c option) and loses capability on the
task's current CPU, the kernel routes the task to the reject DSQ and
re-enqueues it with the SCX_ENQ_REENQ flag.

Since this check unconditionally handles SCX_ENQ_BLOCKED and returns early,
won't it bypass the SCX_ENQ_REENQ fallback logic later in qmap_enqueue
that normally routes rejected tasks to SHARED_DSQ?

If the sub-scheduler still lacks capability, the kernel will reject it
again. Because balance_scx() processes the reject DSQ synchronously until
empty, won't this create an infinite re-enqueue loop?

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