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

drm/amdgpu: fix handling in amdgpu_userq_create

2026-05-19T16:25:32+00:00

Well mostly the same issues the other code had as well:

1. Memory allocation while holding the userq_mutex lock is forbidden!
2. Things were created/started/published in the wrong order.
3. The reset lock was taken in the wrong order and seems to be
   unecessary in the first place.
4. Error messages on invalid input parameters can spam the logs.
5. Error messages on memory allocation failures are usually superflous
   as well.

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

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: remove va cursors for all mappings

2026-05-19T16:09:01+00:00

va_cursor struct needs to be cleaned even if the mapping
has been removed already.

Also simplify it by make it a void function as return value
check isn't needed as its called during tear down.

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

drm/amdgpu/userq: update the vm task info during signal ioctl

2026-05-19T16:08:02+00:00

Pagefaults does not have process information correctly populated
as vm->task is not set during vm_init but should be updated while
real submission. So setting that up during signal_ioctl to get
the correct submission process details.

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

drm/amdgpu/userq: cancel reset work while tear down in progress

2026-05-19T16:07:52+00:00

While tear down of a userq_mgr is happening when all the queues
are free we should cancel any reset work if pending before exiting.

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

drm/amdgpu: rework userq reset work handling

2026-05-19T16:07:42+00:00

It is illegal to schedule reset work from another reset work!

Fix this by scheduling the userq reset work directly on the work queue
of the reset domain.

Not fully tested, I leave that to the IGT test cases.

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

drm/amdgpu/userq: pin mqd and fw object bo to avoid eviction

2026-05-19T16:07:36+00:00

mqd and fw objects are queue core objects which should remain
valid and never be unmapped and evicted for user queues to work
properly.

During eviction if these buffers are evicted the hw continue to
use the invalid addresses and caused page faults and system hung.

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

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)