sched_ext: Fix stall when a task enqueued with SCX_ENQ_LAST lands back on its CPU's local DSQ
Impact
In the Linux kernel, the following vulnerability has been resolved:
Source excerpt · LinuxAffected packages
Affected products
Vendor version evidence. Product records are separate from automatic dependency matching.
Linux · Linux
Other versions: unaffected
| Version / range | Source status |
|---|---|
| f0e1a0643a59bf1f922fa209cec86a170b784f3f to before 8d891c218016b6145993e082e7f732cb69dd0e29 | affected |
| f0e1a0643a59bf1f922fa209cec86a170b784f3f to before 396ba6f04da3fd1fb5a3d1c9535bef3f967f4e59 | affected |
| f0e1a0643a59bf1f922fa209cec86a170b784f3f to before 7a9df76679633cf26e0fea882a684012c6ec245a | affected |
Linux · Linux
Other versions: affected
| Version / range | Source status |
|---|---|
| 6.12 | affected |
| 0 to before 6.12 | unaffected |
| 6.18.59 through 6.18.* (inclusive) | unaffected |
| 7.2.13 through 7.2.* (inclusive) | unaffected |
| 7.3 through * (inclusive) | unaffected |
Original source description
In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Fix stall when a task enqueued with SCX_ENQ_LAST lands back on its CPU's local DSQ
With SCX_OPS_ENQ_LAST, the last runnable task on a CPU is passed to ops.enqueue() instead of being kept running. Exiting tasks without SCX_OPS_ENQ_EXITING, migration disabled tasks without SCX_OPS_ENQ_MIGRATION_DISABLED and tasks on an offline rq skip ops.enqueue() and go straight to the local DSQ. This happens in put_prev_task_scx() after the pick has settled on idle, so nothing reschedules the CPU, which idles with the task queued until an unrelated wakeup lands on it or the watchdog fires.
scx_mitosis, which sets SCX_OPS_ENQ_LAST without SCX_OPS_ENQ_EXITING, hit this during mass cgroup teardown: exiting tasks stuck in exit_mmap() for over 40 seconds.
A task put on the local DSQ runs, as anywhere else. If the SCX_ENQ_LAST enqueue left the task on this CPU's local DSQ, set need_resched on the task being switched in, as proxy_resched_idle() does. resched_curr() would flag the task being put instead, and __schedule() clears that right after the pick.