Re: [PATCH 05/11] sched_ext: Fix TOCTOU race in consume_remote_task()

[Tejun Heo <tj@kernel.org>]

Hello,

On Thu, Jul 16, 2026 at 03:20:40PM +0200, Andrea Righi wrote:
> When pulling a task from a non-local DSQ, scx_consume_dispatch_q()
> filters candidates without holding the task's source rq lock;
> consume_remote_task() then unlinks the selected task, drops the DSQ and
> destination rq locks and acquires the source rq lock before migrating
> it.
> 
> Whether the task may be remotely migrated can change across this
> handoff. In particular, proxy execution allows a task to execute as
> rq->curr under another task's scheduling context while its own
> scheduling context remains on a DSQ. The task can therefore become
> on-CPU or migration disabled without dequeueing its DSQ entry or
> clearing holding_cpu.

I don't think this can happen w/o proxy execution. The task is enqueued and
can't be dequeued or start running without grabbing the DSQ lock. Before the
DSQ lock is dropped, p->scx.holding_cpu is set and if that hasn't been
cleared, we know that nothing else has touched while we were switching
locks.

If this no longer holds w/ proxy execution, adding further conditions are
fine but let's make it explicitly for and confined to proxy execution
enabled cases. The logic there is already subtle and I want to avoid adding
misleading checks.

Thanks.

-- 
tejun