Scheduler race drops wakeups, leaves runnable tasks stranded idle

Linux kernel developers have fixed a scheduler race that could leave a fully runnable task stranded while its CPU went idle, surfacing as RCU CPU stall warnings under heavy rcutorture load.

Paul E. McKenney reported the failure on both x86 and arm64 when running the TREE01 rcutorture scenario with RCU priority boosting enabled but without the full boost self-test configuration. Reader kthreads were preempted onto idle CPUs and stayed that way for tens of seconds. Overcommitting vCPUs accelerated the failure, though the same lost wakeup also appeared, more rarely, without overcommit.

The race lived in the path that finishes a scheduling-class change for a task that is queued on a runqueue but not currently running. Promoting such a task (for example from fair to realtime) did not update the runqueue's notion of the highest class present or force a reschedule. A concurrent idle-balance pass could therefore finish, clear need-resched, and switch to the idle thread even though an RT task remained runnable.

K Prateek Nayak of AMD reconstructed the window and, with Peter Zijlstra, settled on treating any queued task's class promotion like a wakeup: re-evaluate preemption so the runqueue notices the higher class. Demotion only matters for the task that is actually running. Vincent Guittot helped refine that distinction.

McKenney's follow-up runs accumulated well over a thousand CPU-hours on x86 and substantial arm64 time without reproducing the stalls, clearing the way for the fix. The bug was a regression from earlier rework that replaced a broader queue-change mask with the next-class tracking used today.

Joel Fernandes raised a theoretical livelock concern around repeated RT pull retries during newidle balance; Nayak noted the same pattern was already possible before the fix and remains unlikely in practice.