В ядре Linux устранена следующая уязвимость:
mm/vmscan: сообщает о состояниях покоя задач RCU в Shrink_lruvec()
Я вижу некоторые зависания rcu_tasks в Мета-флоте во время восстановления. ИНФОРМАЦИЯ: rcu_tasks обнаружил зависания в задачах:
0000000088620d09: .. nvcsw: 6735/6735 удержание: 1 Idle_cpu: -1/8
задача: состояние GlobalCPUThread: R работающая задача с идентификатором: 2552016 tgid: 2524552
Отслеживание вызова:
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
Ничто не обещает прямого возврата в ограниченное время, а цикл сканирования
в Shrink_lruvec() вызывается только cond_resched(), который не работает
ВЫРЕМПЦИОННЫЕ ядра. Вынужденное прерывание не является состоянием покоя Tasks-RCU.
состояние, поэтому задача восстановления никогда не сообщает об этом и становится приостановкой.
Обновите его до cond_resched_tasks_rcu_qs(), который сообщает о состоянии покоя.
даже когда cond_resched() ничего не делает. PS: Это обсуждалось в [1]
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec() 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]