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

Hi Tejun,

On Thu, Jul 16, 2026 at 11:38:34AM -1000, Tejun Heo wrote:
> On Thu, Jul 16, 2026 at 11:29:37AM -1000, Tejun Heo wrote:
> > 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.
> 
> Thought a bit more about it and the only thing that can change are the
> running state and migration disabled, right? So, maybe just test those again
> after the lock switch?

Right, without proxy execution, the DSQ lock and holding_cpu handshake guarantee
that with an unchanged holding_cpu the task could not have been dequeued or
started running during the rq-lock handoff.

Proxy execution is the exception: a task can start physically executing as a
lock owner while its own scheduling context remains on the DSQ, allowing its
on-CPU or migration-disabled state to change without clearing holding_cpu.

I'll leave the existing validation unchanged and, only when proxy execution is
enabled, recheck the running and migration-disabled state after switching to the
source rq lock.

Thanks for taking a look!
-Andrea