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

On Mon, Jul 20, 2026 at 11:34 PM Andrea Righi <[email protected]> wrote:
>
> Without proxy execution, the DSQ lock and holding_cpu handshake ensure
> that a task cannot be dequeued or start running during the rq-lock
> handoff without clearing holding_cpu.
>
> Proxy execution is an exception. A task can start physically executing
> as a lock owner while its own scheduling context remains on the DSQ. Its
> on-CPU or migration-disabled state can therefore change without clearing
> holding_cpu.
>
> Keep the existing lockless destination validation unchanged. After
> switching to the source rq lock, recheck only the on-CPU and
> migration-disabled states when proxy execution is enabled. If either
> changed, cancel the transfer and requeue the task on the global DSQ
> without treating the race as a BPF scheduler error.
>
> A rejected task may be requeued onto the DSQ currently being consumed.
> Snapshot the DSQ sequence and skip tasks added after the consume attempt
> started to prevent repeatedly selecting the same task. Keep this retry
> bounding confined to proxy execution so the non-proxy path remains
> unchanged.
>
> With proxy execution enabled, stress-ng --pipeherd can trigger this race
> and migrate an active execution context, leading to
> sleeping-while-atomic warnings and subsequent lockdep corruption.
>
> Signed-off-by: Andrea Righi <[email protected]>

So, I've acked the core scheduler changes, but I'm not sure I know the
sched_ext logic well enough for my ack to be very meaningful.

However, as a sign of general positivity the series, if you feel its
useful, feel free to add "Acked-by: John Stultz <[email protected]>"
to the entire series.

thanks
-john