В ядре Linux устранена следующая уязвимость:
drm/amdgpu: исправлено рекурсивное получение ww_mutex в amdgpu_devcoredump_format. При выгрузке содержимого IB из зависшего задания amdgpu_devcoredump_format()
получил резервирование корневого PD виртуальной машины через amdgpu_vm_lock_by_pasid() и
затем для каждого IB вызывается amdgpu_bo_reserve() на BO, поддерживающем IB. Оба резервирования являются объектами резервирования_ww_class_mutex и ни
использовал ww_acquire_ctx, который отключает блокировку:
ВНИМАНИЕ: обнаружена возможная рекурсивная блокировка.
--------------------------------------------
kworker/u128:0 пытается получить блокировку:
ffff88838b16e1f0 (reservation_ww_class_mutex){+.+.}-{4:4},
по адресу: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu]
но задача уже удерживает блокировку:
ffff8882f82681f0 (reservation_ww_class_mutex){+.+.}-{4:4},
по адресу: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu]
Возможный сценарий небезопасной блокировки:
ЦП0
----
блокировка (reservation_ww_class_mutex);
блокировка (reservation_ww_class_mutex);
*** ТУПИК ***
Возможно, это связано с отсутствием обозначения вложенности замков.
Рабочая очередь:events_unbound amdgpu_devcoredump_deferred_work [amdgpu]
Отслеживание вызова:
__ww_mutex_lock.constprop.0
ww_mutex_lock
amdgpu_bo_reserve
amdgpu_devcoredump_format+0x1594 [amdgpu]
amdgpu_devcoredump_deferred_work+0xea [amdgpu]
Два резервирования находятся на разных BO в захваченной трассировке, поэтому
splat — это предупреждение о корректности блокировки, а не наблюдаемая взаимоблокировка. Это
становится настоящим тупиком всякий раз, когда IB BO делится своим dma_resv с
корневой PD (всегда действительный случай, см. amdgpu_vm_is_bo_always_valid()):
amdgpu_bo_reserve(abo) повторно получает тот же ww_mutex без билета
и блокируется навсегда. С amdgpu.gpu_recovery=0 обработчик тайм-аута
повторяется каждые ~2 секунды, и каждый вызов производит этот всплеск, заглушая
Кольцевой буфер ядра.
Теперь, когда amdgpu_vm_lock_by_pasid() принимает контекст drm_exec, переместите IB
сброс в отдельный помощник, который блокирует корневой PD и каждый ИБ БО
вместе в одном билете drm_exec. DRM_EXEC_IGNORE_DUPLICATES обрабатывает
IB BO, которые используют общий dma_resv (например, всегда действительные BO или два IB, поддерживаемые
тем же БО). Каждый замок теперь является приобретением верхнего уровня под одним
ww_acquire_ctx, поэтому рекурсивное условие ww_mutex исчезло, и
танец amdgpu_bo_reserve()/amdgpu_bo_unref() для каждого IB, включая BO
Утечка счетчика ссылок на пути отказа amdgpu_bo_reserve() — удалена.
(вишня выбрана из коммита d6bf4242731219ee08ce54c365631e395486651e)
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format When dumping IB contents from a hung job, amdgpu_devcoredump_format() acquired the VM root PD's reservation via amdgpu_vm_lock_by_pasid() and then, for each IB, called amdgpu_bo_reserve() on the BO backing the IB. Both reservations are reservation_ww_class_mutex objects and neither used a ww_acquire_ctx, which trips lockdep: WARNING: possible recursive locking detected -------------------------------------------- kworker/u128:0 is trying to acquire lock: ffff88838b16e1f0 (reservation_ww_class_mutex){+.+.}-{4:4}, at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu] but task is already holding lock: ffff8882f82681f0 (reservation_ww_class_mutex){+.+.}-{4:4}, at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu] Possible unsafe locking scenario: CPU0 ---- lock(reservation_ww_class_mutex); lock(reservation_ww_class_mutex); *** DEADLOCK *** May be due to missing lock nesting notation Workqueue: events_unbound amdgpu_devcoredump_deferred_work [amdgpu] Call Trace: __ww_mutex_lock.constprop.0 ww_mutex_lock amdgpu_bo_reserve amdgpu_devcoredump_format+0x1594 [amdgpu] amdgpu_devcoredump_deferred_work+0xea [amdgpu] The two reservations are on different BOs in the captured trace, so the splat is a lockdep-correctness warning, not an observed deadlock. It becomes a real self-deadlock whenever the IB BO shares its dma_resv with the root PD (the always-valid case, see amdgpu_vm_is_bo_always_valid()): amdgpu_bo_reserve(abo) re-acquires the same ww_mutex without a ticket and blocks forever. With amdgpu.gpu_recovery=0 the timeout handler refires every ~2 s and each invocation produces this splat, drowning the kernel ring buffer. Now that amdgpu_vm_lock_by_pasid() takes a drm_exec context, move the IB dumping into a separate helper that locks the root PD and every IB BO together in a single drm_exec ticket. DRM_EXEC_IGNORE_DUPLICATES handles IB BOs that share a dma_resv (e.g. always-valid BOs, or two IBs backed by the same BO). Every lock is now a top-level acquire under one ww_acquire_ctx, so the recursive ww_mutex condition is gone, and the per-IB amdgpu_bo_reserve()/amdgpu_bo_unref() dance -- including a BO refcount leak on the amdgpu_bo_reserve() failure path -- is removed. (cherry picked from commit d6bf4242731219ee08ce54c365631e395486651e)