Re: [PATCH] sched/fair: Clear throttle state when leaving the fair class

[Aaron Lu]

On Wed, Oct 28, 2026 at 03:24:11PM -0700, Benjamin Segall wrote:
> Daehyeon Ko <4ncienth@xxxxxxxxx> writes:
> 
> > Task-based CFS bandwidth throttling removes a task's fair sched_entity
> > while the scheduler core still considers the task queued. p->throttled
> > carries the fair-specific state across dequeue/enqueue operations.
> >
> > DEQUEUE_CLASS removes the task from cfs_rq->throttled_limbo_list
> > but retains the bit. If the last finite CFS quota is disabled while
> > the task runs in another class, it is absent from the unthrottle walk and
> > the bit survives.
> > Returning to fair while cfs_bandwidth_used() is false then performs a real
> > fair enqueue with p->throttled still set.
> >
> > After bandwidth is re-enabled, a class-change dequeue treats the
> > stale bit as limbo state and skips __dequeue_task(). p->se.on_rq therefore
> > remains set, and put_prev_task_fair() places the entity in the EEVDF tree
> > while the task moves to RT. On exit, the fair picker can select the
> > TASK_DEAD task. __schedule() then returns to do_task_dead(),
> > which hits BUG().
> >
> > Keep p->throttled across migrations and group moves, but clear it on
> > DEQUEUE_CLASS because fair-specific state must not outlive fair-class
> > membership. A later return to fair uses the normal enqueue path. That path
> > still respects a throttled cfs_rq.
> >
> > A KASAN, LOCKDEP and DEBUG_LIST v7.3 kernel reproduced the do_task_dead()
> > BUG in 3/3 root and 3/3 delegated uid-1000 runs with CapPrm=CapEff=0 and
> > RLIMIT_RTPRIO=1. The fix passed both matrices plus a 3/3 class-switch
> > control with bandwidth continuously enabled, without a scheduler warning,
> > KASAN report, lockdep splat or crash.
> >
> > An AI coding assistant analyzed the state mismatch and drafted the initial
> > reproducer, fix candidate and this changelog. The source paths, trigger,
> > controls and results were rechecked against the cited revisions.
> >
> > Fixes: e1fad12dcb66 ("sched/fair: Switch to task based throttle model")
> > Signed-off-by: Daehyeon Ko <4ncienth@xxxxxxxxx>
> > Cc: stable@xxxxxxxxxxxxxxx
> > ---
> 
> Yep, sched_class switch lets you smuggle ->throttled into
> !cfs_bandwidth_used(), and then that check on enqueue_throttled lets you
> smuggle it onto actually being enqueued, which leads to corruption.
> That's fun.
> 
> I think we need to use switched_from_fair though - if we are currently
> TASK_ON_RQ_MIGRATING, sched_class changes will skip going into
> dequeue_task_fair at all, so we will not see the DEQUEUE_CLASS.

sched class change serializes with migration I think, with task_rq_lock()
which waits for migration to settle, so this should not happen?