5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Breno Leitao commit 25f52e81216884a7444bf07a606691feb09a94e3 upstream. I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO: rcu_tasks detected stalls on tasks: 0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8 task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), 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 cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1] Link: https://lore.kernel.org/20260810-rcu_task_shrink_lruvec-v1-1-4d9f7d5251cb@debian.org Link: https://lore.kernel.org/all/amdWVTs0WKOxguxP@gmail.com/ [1] Signed-off-by: Breno Leitao Reviewed-by: Paul E. McKenney Acked-by: Johannes Weiner Acked-by: Shakeel Butt Cc: Axel Rasmussen Cc: Barry Song Cc: David Hildenbrand Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Wei Xu Cc: Yuanchu Xie Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- mm/vmscan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2484,7 +2484,7 @@ static void shrink_lruvec(struct lruvec } } - cond_resched(); + cond_resched_tasks_rcu_qs(); if (nr_reclaimed < nr_to_reclaim || proportional_reclaim) continue;