Re: [PATCH 06/12] sched_ext: Fix proxy-exec race in consume_remote_task()

[Tejun Heo <tj@kernel.org>]

Hello, Andrea.

On Tue, Jul 21, 2026 at 08:31:27AM +0200, Andrea Righi wrote:
> +		/*
> +		 * Proxy execution may have changed @p's running or migration-disabled
> +		 * state while switching rq locks without clearing holding_cpu. This is
> +		 * a kernel-side race, not an invalid BPF placement request, so don't
> +		 * abort the scheduler on failure. Fall back to the global DSQ, where
> +		 * normal consumption filters can select a valid destination.
> +		 */
> +		if (unlikely(!task_can_move_from_locked_rq(p))) {
> +			p->scx.dsq = NULL;
> +			p->scx.holding_cpu = -1;
> +			scx_dispatch_enqueue(sch, src_rq,
> +					     find_global_dsq(sch, task_cpu(p)), p,
> +					     enq_flags | SCX_ENQ_CLEAR_OPSS |
> +					     SCX_ENQ_GDSQ_FALLBACK);
> +			if (sched_class_above(p->sched_class,
> +					      src_rq->donor->sched_class))
> +				resched_curr(src_rq);
> +			switch_rq_lock(src_rq, this_rq);
> +			return false;
> +		}

I don't think bouncing the rejected task to the global DSQ is the right
thing to do. Unlike the existing GDSQ_FALLBACK cases, this fires on plain
mutex contention with proxy execution enabled, so userspace can trigger it
routinely, and the bounce bypasses the BPF scheduler's placement. It also
breaks sub-scheduler containment - when a host consumes the bypass DSQ for
its bypassing descendants, @sch is the host and a descendant's task lands on
the host's global DSQ outside its cap grants.

How about parking the rejected task on the reject DSQ and bouncing it back
through the reenqueue path so that the owning scheduler re-places it? The
two rejection reasons want different timings:

1. A migration-disabled donor can be reenqueued right away. The forced-admit
   path in scx_local_or_reject_dsq() covers pinned admission and the
   deferred irq_work wakes up an idle target CPU.

2. An on-CPU proxy owner should stay parked until it's switched out, or the
   reenqueue can just cycle back to rejection. This needs a callout at proxy
   resolution - the owner is still rq->curr when balance runs for the pick
   that switches it out, so draining from balance alone isn't enough.

That'd make the scan_seq tracking, the resched_curr() and the repeated
consume attempts against an in-flight proxy section unnecessary. The reject
DSQ and scx_reenq_reject() are currently sub-sched only and would need
generalizing.

> +		/*
> +		 * consume_remote_task() may drop @dsq->lock and requeue a
> +		 * rejected task onto this same DSQ. Don't reconsider tasks queued
> +		 * after this consume attempt started. This bounds the retry loop
> +		 * even when the rejected task remains on-CPU.
> +		 */
> +		if (proxy_exec &&
> +		    unlikely(u32_before(scan_seq, p->scx.dsq_seq)))
> +			continue;

If the requeue approach stays, the comment should mention when a task can
get bounced back - proxy execution turning it on-CPU or migration-disabled
while its context is still queued. Also, the condition fits on one line,
ditto the sched_class_above() one above.

Thanks.

-- 
tejun