Linux mm/vmscan: direct reclaim never reports an RCU-tasks quiescent state, stalling rcu_tasks under memory pressure

Impact

Nothing bounds how long direct reclaim runs, and the scan loop in shrink_lruvec() only called cond_resched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so a task reclaiming inside a page fault never reports one and becomes an rcu_tasks holdout. The reporter observed these stalls in the Meta fleet, with the holdout task sitting in shrink_lruvec under handle_mm_fault. Tasks-RCU is what gates tracepoint and BPF trampoline teardown, so a stall there hangs observability and BPF-attached tooling on a node that is already under memory pressure - exactly the moment an operator is trying to see what is happening on a GPU host packed to its memory limit. The fix upgrades the call to cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing.

Who can reach it

No attacker required. Any workload that drives sustained direct reclaim on a PREEMPTION kernel reproduces it, including an ordinary tenant filling memory in their own cgroup.

What to do

Patch the host kernel to a stable release containing the cond_resched_tasks_rcu_qs() change and reboot the node. No configuration mitigates it; reducing memory pressure so direct reclaim is short-lived avoids the stall in practice. Watch for 'rcu_tasks detected stalls on tasks' in dmesg with shrink_lruvec in the call trace to identify affected nodes.

References

Related entries

• Microsoft Hyper-V: vmswitch fails to validate guest OID requestsCVE-2021-28476 · Microsoft Hyper-VCritical
• Incus: instance snapshots bypass restricted.containers.lowlevel, giving command execution on the hostCVE-2026-48751 · Incus (instance snapshots ignore restricted.containers.lowlevel)Critical
• VMware ESXi (OpenSLP): Use-after-free in OpenSLP on port 427 - unauthenticated remote code execution on the hypervisorCVE-2020-3992 · VMware ESXi (OpenSLP)Critical
• Linux kernel mlx5_core kTLS RX offload: TLS RX resync list corruption: entries are moved by the resync handlerCVE-2021-47215 · Linux kernel mlx5_core kTLS RX offloadCritical
• Linux kernel (drivers/nvme/host): The NVMe/RDMA initiator destroys the queue pair before the connection manager ID, soCVE-2021-47378 · Linux kernel (drivers/nvme/host)Critical
• Linux kernel (net/tls): KTLS stored a negative errno into the socket error field where a positive value is expected. ACVE-2021-47496 · Linux kernel (net/tls)Critical