Re: [PATCH 17/18] 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] Missing bounds check on `cid` returned from `cmask_next_and_set_wrap()` due to a TOCTOU race with `qa.self_cids.mask` modifications.
--

commit 564b1258b3dc07e22341c55b61be164307b61870
Author: Andrea Righi <arighi@nvidia.com>

sched_ext: scx_qmap: Add proxy execution support

Add a -X option to opt scx_qmap into queueing mutex-blocked tasks for proxy
execution. When scx_qmap receives a blocked donor, it selects an eligible cid
and dispatches the donor to that local DSQ.

> diff --git a/tools/sched_ext/scx_qmap.bpf.c b/tools/sched_ext/scx_qmap.bpf.c
> index 5bb8b90a275a3..21f8a9be9650c 100644
> --- a/tools/sched_ext/scx_qmap.bpf.c
> +++ b/tools/sched_ext/scx_qmap.bpf.c
[ ... ]
> @@ -460,6 +464,53 @@ void BPF_STRUCT_OPS(qmap_enqueue, struct task_struct *p, u64 enq_flags)
[ ... ]
> +	/*
> +	 * Insert a blocked mutex donor at the head of an eligible local DSQ with
> +	 * a fresh slice and %SCX_ENQ_PREEMPT, requesting an immediate reschedule.
> +	 * The test above guarantees that cpus_allowed intersects self_cids, but
> +	 * the donor's current cid may have been delegated to a child. Search the
> +	 * intersection starting at the current cid, preserving it when qmap still
> +	 * holds it and wrapping to another eligible self cid otherwise.
> +	 *
> +	 * A self cid may be held exclusively with SCX_CAP_ENQ or time-shared with
> +	 * only SCX_CAP_ENQ_IMMED. Add needs_immed() so either kind can accept the
> +	 * local insertion instead of rejecting and reenqueuing the donor for a
> +	 * capability miss. Once selected, the core proxy-exec path can 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) {
> +		cid = cmask_next_and_set_wrap(&taskc->cpus_allowed,
> +					      &qa.self_cids.mask,
> +					      scx_bpf_task_cid(p));
> +		scx_bpf_dsq_insert(p, SCX_DSQ_LOCAL_ON | cid, slice_ns,
> +				   enq_flags | needs_immed(cid) | SCX_ENQ_PREEMPT);
> +		return;
> +	}

[Severity: High]
Does this code risk an out-of-bounds access if the intersection becomes
empty?

In qmap_enqueue(), there is an earlier check for
cmask_intersects(&taskc->cpus_allowed, &qa.self_cids.mask).

However, if apply_partition() modifies and zeroes qa.self_cids.mask
concurrently on another CPU after the check, the intersection might become
empty before cmask_next_and_set_wrap() executes.

If this happens, cmask_next_and_set_wrap() returns the out-of-bounds
sentinel scx_bpf_nr_cids().

This out-of-bounds cid is then used without a bounds check in:

    scx_bpf_dsq_insert(p, SCX_DSQ_LOCAL_ON | cid, ...)

which can cause scx_cpu_valid() to fail and forcefully eject the BPF
scheduler. It could also lead to an out-of-bounds read in needs_immed(cid).

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