[PATCH v6 0/2] drm/amdgpu: fix recursive ww_mutex in devcoredump IB dump

[Mikhail Gavrilov]

This series fixes a lockdep "possible recursive locking" splat in
amdgpu_devcoredump_format() that fires on every GPU timeout once a job
with a PASID context is involved. With amdgpu.gpu_recovery=0 the timeout
handler refires every ~2 s, so the splat repeats until it drowns the
kernel ring buffer. It is also a real self-deadlock for IB BOs that
share their dma_resv with the root PD (the always-valid case).
 
The root cause: amdgpu_devcoredump_format() holds the VM root PD's
reservation and then reserves each IB BO on top of it, nesting two
reservation_ww_class_mutex acquires without a ww_acquire_ctx.
 
The fix teaches amdgpu_vm_lock_by_pasid() to lock the root PD in a
drm_exec context, so the devcoredump path can lock the root PD and all
the IB BOs together in one ww ticket. Because amdgpu_vm_lock_by_pasid()
has a second caller in the page-fault path, the series is split so each
patch builds and works on its own:
 
  1/2  Convert amdgpu_vm_lock_by_pasid() to take a drm_exec context and
       lock the root PD with drm_exec_lock_obj(). The drm_exec context
       holds the root BO reference, so the root output parameter is
       dropped. Updates the existing caller, amdgpu_vm_handle_fault().
       Pure refactor, no functional change to the page-fault path.
       (Reviewed-by Christian on v5.)
 
  2/2  Move the IB dumping into a separate helper that locks the root PD
       and every IB BO together in one drm_exec ticket. The per-IB
       amdgpu_bo_reserve() nesting is gone, along with a BO refcount
       leak on the old reserve-failure path. This is the actual bug fix
       and carries the Fixes: tag.
 
Tested on Linux 7.1-rc4 + this series, Radeon RX 7900 XTX (gfx1100),
KASAN + PROVE_LOCKING enabled, using a small libdrm_amdgpu reproducer
that submits a GFX IB chained at GPU VA 0 and waits for the hang. Before
the series the splat fires on every TDR; after it the dmesg is clean
across repeated timeouts and the devcoredump IB dump is produced
correctly.
 
v1: https://lore.kernel.org/amd-gfx/20260429143743.50743-1-mikhail.v.gavrilov@xxxxxxxxx/
v2: https://lore.kernel.org/amd-gfx/20260519161541.19994-1-mikhail.v.gavrilov@xxxxxxxxx/
v3: https://lore.kernel.org/amd-gfx/20260520151741.50575-1-mikhail.v.gavrilov@xxxxxxxxx/
v4: https://lore.kernel.org/amd-gfx/20260521104335.28978-1-mikhail.v.gavrilov@xxxxxxxxx/
v5: https://lore.kernel.org/amd-gfx/20260521150841.20625-1-mikhail.v.gavrilov@xxxxxxxxx/
 
Changes since v5 (all in patch 2, per Christian's review):
- Trim the commit message: drop the reproducer paragraph, keep the
  problem description and the solution.
- Move the IB dumping out of amdgpu_devcoredump_format() into a separate
  amdgpu_devcoredump_print_ibs() helper.
- Use goto error handling inside drm_exec_until_all_locked() instead of
  break, and drop the now-superfluous `locked` variable. drm_exec_fini()
  is called once at the end of the helper, not in the locking path.
- Patch 1 is unchanged from v5 and keeps Christian's Reviewed-by.
 
A note on one review point I couldn't fully confirm before respinning
(asked on the v5 thread [1], no reply yet): in the locking loop, when
amdgpu_vm_bo_lookup_mapping() returns no mapping for an IB, this version
treats it as non-fatal -- there is simply nothing to lock for that IB,
so the loop continues, and the content loop still emits the
"IB #N <addr>" header without a body. goto-abort is reserved for real
errors (VM not found, drm_exec_lock_obj() failure). If a missing mapping
should instead abort the whole dump, I'll change it.
 
[1] https://lore.kernel.org/amd-gfx/CABXGCsPPY3qX7Ad-a7==nmA5R7aejCTCrmWYpn-9OQQU=1eMMA@xxxxxxxxxxxxxx/
 
Changes since v4:
- Pass nr=1 to drm_exec_init() in amdgpu_vm_handle_fault() (Christian).
- Picked up Christian's Reviewed-by on patch 1.
 
Changes since v3:
- Lock the root PD with drm_exec_lock_obj() instead of
  amdgpu_vm_lock_pd(); drop the root output parameter; unlock with
  drm_exec_unlock_obj() on the VM-recheck-failed path (Christian).
- Resolves the docutils warning the kernel test robot reported on v3.
 
Changes since v2:
- Reworked along the lines Christian suggested: amdgpu_vm_lock_by_pasid()
  takes a drm_exec context directly (patch 1), devcoredump locks the
  root PD and all IB BOs in one ticket (patch 2). The v2 helper struct
  and the three collect/lock/release helpers are gone.
 
Changes since v1:
- Switched from per-IB amdgpu_bo_reserve() to drm_exec.
- Dropped the Cc: stable tag: the regression only landed in 7.1-rc1, so
  the fix reaches 7.1 via drm-fixes without a stable backport.

Mikhail Gavrilov (2):
  drm/amdgpu: convert amdgpu_vm_lock_by_pasid() to drm_exec
  drm/amdgpu: fix recursive ww_mutex acquire in
    amdgpu_devcoredump_format

 .../gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c  | 215 ++++++++++--------
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c        |  91 +++++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h        |   2 +-
 3 files changed, 184 insertions(+), 124 deletions(-)

-- 
2.54.0