linux.git/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c, branch v7.1-rc4

drm/amdgpu: fix userq hang detection and reset

2026-05-11T21:47:11+00:00

Fix lock inversions pointed out by Prike and Sunil. The hang detection
timeout *CAN'T* grab locks under which we wait for fences, especially
not the userq_mutex lock.

Then instead of this completely broken handling with the
hang_detect_fence just cancel the work when fences are processed and
re-start if necessary.

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

drm/amdgpu: remove almost all calls to amdgpu_userq_detect_and_reset_queues

2026-05-11T21:47:04+00:00

Well the reset handling seems broken on multiple levels.

As first step of fixing this remove most calls to the hang detection.
That function should only be called after we run into a timeout! And *NOT*
as random check spread over the code in multiple places.

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

drm/amdgpu: rework amdgpu_userq_signal_ioctl v3

2026-05-11T21:46:43+00:00

This one was fortunately not looking so bad as the wait ioctl path, but
there were still a few things which could be fixed/improved:

1. Allocating with GFP_ATOMIC was quite unnecessary, we can do that
   before taking the userq_lock.
2. Use a new mutex as protection for the fence_drv_xa so that we can do
   memory allocations while holding it.
3. Starting the reset timer is unnecessary when the fence is already
   signaled when we create it.
4. Cleanup error handling, avoid trying to free the queue when we don't
   even got one.

v2: fix incorrect usage of xa_find, destroy the new mutex on error
v3: cleanup ref ordering

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

drm/amdgpu: remove deadlocks from amdgpu_userq_pre_reset

2026-05-11T21:46:34+00:00

The purpose of a GPU reset is to make sure that fence can be signaled
again and the signal and resume workers can make progress again.

So waiting for the resume worker or any fence in the GPU reset path is
just utterly nonsense.

Signed-off-by: Christian König 
Reviewed-by: Prike Liang 
Signed-off-by: Alex Deucher 
(cherry picked from commit fcd5f065eab46993af43442fd77ee8d9eb9c5bdf)

drm/amdgpu: clean up the userq unmap error handler

2026-04-28T19:51:18+00:00

amdgpu_userq_unmap_helper() already handles the unmap error case.

Signed-off-by: Prike Liang 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
(cherry picked from commit 66cb6579990b633ccc7300c27011d837b9a58da0)

drm/amdgpu: rework userq fence signal processing

2026-04-28T19:43:57+00:00

Move more code into a common userq function.

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

drm/amdgpu: avoid double drm_exec_fini() in userq validate

2026-04-24T15:08:58+00:00

When new_addition is true, amdgpu_userq_vm_validate() calls
drm_exec_fini(&exec) before iterating over the collected HMM ranges and
calling amdgpu_ttm_tt_get_user_pages().

If amdgpu_ttm_tt_get_user_pages() fails in that path, the code jumps to
unlock_all and calls drm_exec_fini(&exec) a second time on the same
exec object. drm_exec_fini() is not idempotent: it frees exec->objects
and may also drop exec->contended and finalize the ww acquire context.

Route that error path directly to the range cleanup once exec has
already been finalized.

Fixes: 42f148788469 ("drm/amdgpu/userqueue: validate userptrs for userqueues")
Issue found using a prototype static analysis tool
and confirmed by code review.

Reviewed-by: Christian König 
Signed-off-by: Hongyan Xu 
Signed-off-by: Slavin Liu <220245772@seu.edu.cn>
Signed-off-by: Alex Deucher 
(cherry picked from commit 2802952e4a07306da6ebe813ff1acacc5691851a)

drm/amdgpu/userq: unpin and unref doorbell and wptr outside mutex

2026-04-17T19:41:12+00:00

In amdgpu_userq_destroy once unmap_helpder is called within mutex
there is no need to hold mutex.

This helps in avoiding a deadlock between doorbell and wptr ww mutex
and we could unpin and unref these bos outside mutex safely.

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

drm/amdgpu/userq: use pm_runtime_resume_and_get and fix err handling

2026-04-17T19:41:12+00:00

Use pm_runtime_resume_and_get instead of pm_runtime_get_sync as it
return error but put the reference in the function itself.

In goto statements we need to drop the pm reference too.

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

drm/amdgpu/userq: unmap_helper dont return the queue state

2026-04-17T19:41:12+00:00

We check for return value of amdgpu_userq_unmap_helper and
compare it against the queue->state which is logically
wrong and we should just check for failure and do the needfull.

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