Re: [PATCH] sched_ext: Hold DSQ refs for deferred reenqueues

[Hui Su <sh_def@163.com>]

Hi Andrea,

On Wed, Sep 30, 2026 at 17:26:37 +0200, Andrea Righi wrote:
> The race looks real, can you also share the test or the steps used to reproduce
> this? That would help validate the fix and assess the stable backport.

I originally observed a crash in this area on an unmodified kernel, but I
don't have a reliable natural reproducer for that schedule. To validate
the lifetime issue deterministically, I used a validation-only fixture to
force the window.

The pre-fix fixture pauses after process_deferred_reenq_users() detaches
the request, lets the DSQ be destroyed, and directly runs the reclaim
callback before the deferred path's final DSQ access. KASAN then reports
the UAF in run_deferred().

I ran it on 4-vCPU x86_64 KVM with CONFIG_KASAN_GENERIC=y and
CONFIG_SCHED_CLASS_EXT=y.

For v3, I used a separate active-cursor test. Reclamation stayed deferred
while the reenq_user() cursor was linked and completed after the cursor
was removed. KASAN and a separate PROVE_LOCKING/LOCKDEP run were clean.

> Sashiko's ordering concern looks like a false positive to me, at least on
> sched_ext/for-7.4, both this sequence and exit_dsq() list check are protected by
> deferred_reenq_lock.

> Can we avoid repeatedly queueing RCU callbacks while a detached reenqueue holds
> a reference?
>
> The callback leaves the base reference in place whenever a detached reenqueue is
> active, then starts another grace period just to check the count again. A long
> reenq_user() could make this repeat several times.
>
> Could the first callback instead drop the base reference, and have whichever
> side drops the final reference arrange the free? This would avoid polling
> through repeated RCU callbacks.

v3 follows Tejun's suggestion to avoid refcounts and leave the deferred
reenqueue hot path unchanged. The destruction-side sweep serializes with
deferred-list updates and checks whether a cursor remains. A callback may
still be retried while an active cursor remains, but that retry is
confined to DSQ destruction.

v3:
https://lore.kernel.org/lkml/20261008024753.4096008-1-sh_def@163.com/

Thanks,
Hui