CVE-2026-89753: mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec()
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: report RCU-tasks quiescent states in shrinklruvec()
I am seeing some rcutasks stalls in the Meta fleet during reclaim.
INFO: rcutasks detected stalls on tasks: 0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idlecpu: -1/8 task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrinklruvec memcgroupiter shrinknode dotrytofreepages trytofreepages allocfrozenpagesnoprof allocpagesnoprof pteallocone ptealloc handlemmfault
Nothing promises direct reclaim returns in bounded time, and the scan loop in shrinklruvec() only calls condresched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout.
Upgrade it to condreschedtasksrcuqs(), which reports a quiescent state even when condresched() does nothing.
PS: This has been discussed in [1]
Affected Software
Event History
Frequently Asked Questions
Which systems are most likely to encounter this issue?
Systems using PREEMPTION kernels are affected when a task spends a prolonged period in direct memory reclaim through shrink_lruvec(). In that configuration, cond_resched() can be a no-op and does not report the required Tasks-RCU quiescent state.
How can I tell whether this is occurring on a system?
Look for RCU-tasks stall reports identifying a task as a holdout, with a call trace that includes shrink_lruvec(), mem_cgroup_iter(), shrink_node(), and direct reclaim paths such as do_try_to_free_pages() or try_to_free_pages().
What can be done if the system is affected?
Apply a kernel update containing the change that replaces cond_resched() in the shrink_lruvec() scan loop with cond_resched_tasks_rcu_qs(). No alternative mitigation is described in the provided information.