linux-stable.git/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c, branch v7.1.11

drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format

2026-08-27T12:34:38+00:00

[ Upstream commit 7152b248dc3c8d5fa8629e99ed5655dd41b51562 ]

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.

Fixes: 7b15fc2d1f1a ("drm/amdgpu: dump job ibs in the devcoredump")
Suggested-by: Christian König 
Signed-off-by: Mikhail Gavrilov 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
(cherry picked from commit d6bf4242731219ee08ce54c365631e395486651e)
Stable-dep-of: e40ff9840fa8 ("drm/amdgpu: Allocate coredump ring buffers per ring")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix missing check in vm_flush()

2026-08-23T12:29:25+00:00

commit 47cd31185090bd1439d4587b835ac22d7ba6f1e3 upstream.

We shouldn't return early if we need to emit spm update.

Reviewed-by: David Rosca 
Signed-off-by: Alex Deucher 
(cherry picked from commit 54a118f1d7e184fcbb18f83889f48f17a767878a)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: always emit the job vm fence

2026-08-03T09:25:45+00:00

commit b2ff0595c31cce4303957dd0058e14c89eb70152 upstream.

We need the fence to reemit the gds switch or spm update
after a queue reset.

Fixes: a17ef941212b ("drm/amdgpu: rework ring reset backup and reemit v9")
Cc: timur.kristof@gmail.com
Cc: christian.koenig@amd.com
Reviewed-by: Timur Kristóf 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
(cherry picked from commit bc639a9eadc75822f7f15a4315c198a4b5513bd2)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid()

2026-08-03T09:25:43+00:00

commit 04cc4aa3617b0ed67e859f91f09de5d896a46f3a upstream.

The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only
valid while the lock is still being held. Once xa_unlock_irqrestore is
called and returned, the pointer is no longer under lock and is subject
to modification. Since, the caller still dereferences vm->task_info in
amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a
use after unlock problem.

Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid()
through removing the amdgpu_vm_get_vm_from_pasid() function from
amdgpu_vm.c and making the relevant code inline to hold the lock while
it is still in use.

Signed-off-by: Shahyan Soltani 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
(cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/userq: remove the vital queue unmap logging

2026-06-03T18:55:23+00:00

Mesa userqueues free does not wait for the free to complete and go ahead
in unmapping the vital bos while kernel is still in queue free and
corresponding cleanup.

So ideally we don't need the logging for that and hence remove the warn
message as this is expected behaviour and functionally, we are making
sure to wait for the required fences before unmap.

Signed-off-by: Sunil Khatri 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
(cherry picked from commit 758a868043dcb07eca923bc451c16da3e73dc47c)

drm/amdgpu: fix calling VM invalidation in amdgpu_hmm_invalidate_gfx

2026-05-27T16:06:26+00:00

Otherwise we don't invalidate page tables on next CS.

Signed-off-by: Christian König 
Reviewed-by: Vitaly Prosyak 
Tested-by: Vitaly Prosyak 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
(cherry picked from commit b6444d1bcbc34f6f2a31a3aab3059be082f3683e)
Cc: stable@vger.kernel.org

drm/amdgpu: userq_va_mapped should remain true once done

2026-05-19T16:15:49+00:00

Multiple queues needs these bo_va objects belonging to
the same uq_mgr. So once they are mapped lets not unmap
them as at any point of time any of the queues might be
using it.

Also userq_va_mapped should be a boolean than atomic.

Signed-off-by: Sunil Khatri 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
(cherry picked from commit 5c02889ea22575c3bcfdf212e65fac316cbc6c6a)

drm/amdgpu: fix root reservation in amdgpu_vm_handle_fault

2026-04-24T15:10:12+00:00

svm_range_restore_pages might reserve the root bo so it must
be called after unreserving it.

Fixes: 1b135c6da061 ("drm/amdgpu: extract amdgpu_vm_lock_by_pasid from amdgpu_vm_handle_fault")
Signed-off-by: Pierre-Eric Pelloux-Prayer 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
(cherry picked from commit 5cdc219fe86a1720aa4b5b4f42f11913146e6a93)

drm/amdgpu: extract amdgpu_vm_lock_by_pasid from amdgpu_vm_handle_fault

2026-04-03T18:55:07+00:00

This is tricky to implement right and we're going to need
it from the devcoredump.

Signed-off-by: Pierre-Eric Pelloux-Prayer 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/amdgpu/userq: call dma_resv_wait_timeout without test for signalled

2026-04-03T17:59:15+00:00

In function amdgpu_userq_gem_va_unmap_validate call
dma_resv_wait_timeout directly. Also since we are waiting
forever we should not be having any return value and hence
no handling needed.

Suggested-by: Christian König 
Signed-off-by: Sunil Khatri 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher