linux.git/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c, branch v7.3-rc2

drm/amdgpu/userq: dont overwrite the error of subsequent map call

2026-09-02T21:01:16+00:00

If a queue fails to map that we need to return the error code back
to the caller and not overwrite with a success specifically.

Accumulate the failure and return that.

Signed-off-by: Sunil Khatri 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
(cherry picked from commit 42a0197d10039e9518c0324c43331eb22b44d5f8)

drm/amdgpu/userq: lock and validate wptr BOs before reading their GPU offset on restore

2026-08-25T22:14:20+00:00

On resume, amdgpu_userq_vm_validate_and_restore_queue() updates each queue's
wptr GPU address via amdgpu_bo_gpu_offset().

WPTR BOs are VM-mapped, but each BO has its own reservation object and is not
implicitly covered by the VM validation path here. This can leave offset reads
without proper BO locking/placement state and trigger WARN_ONs.
  ------------[ cut here ]------------
  WARNING: amdgpu_object.c:1486 at amdgpu_bo_gpu_offset+0x75/0xa0 [amdgpu], CPU#3: kworker/3:1/116
  Workqueue: events amdgpu_userq_restore_worker [amdgpu]
  RIP: 0010:amdgpu_bo_gpu_offset+0x75/0xa0 [amdgpu]
  Call Trace:
   
   amdgpu_userq_vm_validate_and_restore_queue+0x629/0x960 [amdgpu]
   amdgpu_userq_restore_worker+0xa6/0x180 [amdgpu]
   process_scheduled_works+0xa6/0x460
   worker_thread+0x13c/0x290
   kthread+0xfb/0x140
   ret_from_fork+0x1b6/0x2b0
   ret_from_fork_asm+0x1a/0x30
   
  ---[ end trace 0000000000000000 ]---
  ------------[ cut here ]------------
  WARNING: amdgpu_object.c:1485 at amdgpu_bo_gpu_offset+0x9a/0xa0 [amdgpu], CPU#2: kworker/2:1/127
  Workqueue: events amdgpu_userq_restore_worker [amdgpu]
  RIP: 0010:amdgpu_bo_gpu_offset+0x9a/0xa0 [amdgpu]

Add each queue's WPTR BO to the drm_exec ww context and validate it to its
allowed placement before the later offset update.

v2:
- Clarify that WPTR BOs are VM-mapped (fix incorrect "not part of VM" wording). (Christian)
- Describe both parts of the fix: lock BO reservations in drm_exec and
  validate BO placement before offset reads.

Acked-by: Alex Deucher 
Signed-off-by: Jesse Zhang 
Signed-off-by: Alex Deucher

drm/amdgpu: fix hang and race in userq destroy

2026-08-19T14:12:12+00:00

When a queue is hung, the hang_detect_work is the
only way to recover it. However in amdgpu_userq_destroy(),
the hang_detect_work is cancelled too early,
resulting in amdgpu_userq_wait_for_last_fence()
may never return, leaving an uninterruptible dma_fence_wait()
hang there.

To fix this problem, this commit moves the cancelling of
hang_detect_work after amdgpu_userq_wait_for_last_fence(), and it has
to be before the unmap helper, because hang_detect_work resets the
queue, so it races with amdgpu_userq_unmap_helper() for MES operations
and queue state.

This commit splits amdgpu_userq_cleanup() into two parts:

1) amdgpu_userq_detach_doorbell(), which detaches the queue from
userq_doorbell_xa. This has to be called before the cancel, otherwise
the IRQ handlers (for example amdgpu_userq_process_fence_irq)
can re-schedule the hang_detect_work and the cancel is not final.

2) amdgpu_userq_fence_driver_free(), this has to be called after the
unmap helper, because it can release the seq64 slot that the GPU
writes fence values to.

Only one cancel_delayed_work_sync(&queue->hang_detect_work) is needed,
so other redundancies are removed.

Signed-off-by: Zhu Lingshan 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/amdgpu: validate rptr and wptr of a userq

2026-08-19T14:06:50+00:00

rptr and wptr of a userq are 8 bytes aligned, and may
not placed on a page boundary.

This commit checks whether rptr and wptr are 8 bytes
aligned, and expectes 8 bytes when validates rptr/wptr VA.

With above changes, this commit fixes an regression
in amdgpu_userq_input_va_validate, where
end_addr is caculated by:
check_add_overflow(start_addr, expected_size - 1, &end_addr).
Wptr and rptr are very likely not to be page aligned,
when validating rptr and wptr, if they are located in the last
mapped page(or only one page is mapped)
and expected_size is PAGE_SIZE, end_addr will exceed the last
mapped page, means (end_addr >> AMDGPU_GPU_PAGE_SHIFT) > va_map->last,
and causing an -EINVAL, even it is a valid VA.

Signed-off-by: Zhu Lingshan 
Acked-by: Alex Deucher 
Fixes: c0122bf2ccb1 ("drm/amdgpu: fix userq VA validation for sub-page buffers")
Signed-off-by: Alex Deucher

drm/amdgpu: ensure all userq VAs mapped before restore

2026-08-19T14:03:04+00:00

amdgpu_userq_buffer_vas_mapped() checks whether all VAs
of a queue are mapped before restoring it.
So that HW won't access any invalid addresses.

Currently, this function assumes all VAs are mapped if
any VA of a queue has been mapped, which is wrong.

This commit fixes this problem by examining all VAs of
a queue and reporting false if any of them is not mapped.

Signed-off-by: Zhu Lingshan 
Reviewed-by: Sunil Khatri 
Signed-off-by: Alex Deucher

drm/amdgpu: keep PRT mappings off the vm_bo state lists

2026-08-12T13:44:16+00:00

A PRT/sparse mapping has no backing BO, so its bo_va->base.bo is NULL.
amdgpu_vm_bo_base_init() deliberately keeps such a bo_va off the vm_bo
state lists, but the tail of amdgpu_vm_bo_update() unconditionally called
amdgpu_vm_bo_idle() for the !always_valid case, putting the NULL-bo PRT
bo_va onto the individual.idle list.

On a GPU reset amdgpu_vm_bo_reset_state_machine() moves individual.idle
to individual.needs_update with moved=true, and amdgpu_vm_handle_moved()
then dereferences bo_va->base.bo to read its reservation object,
crashing on the NULL bo (e.g. the userq eviction restore worker running
during a reset while a user queue is torn down):

  BUG: kernel NULL pointer dereference, address: 0000000000000158
  RIP: 0010:amdgpu_vm_handle_moved+0x17a/0x200 [amdgpu]
  Call Trace:
   amdgpu_userq_vm_validate_and_restore_queue+0x2ce/0x920 [amdgpu]
   amdgpu_userq_restore_worker+0xce/0x210 [amdgpu]

Skip amdgpu_vm_bo_idle() when bo is NULL so a PRT mapping never lands on
a state list in the first place, and refresh the PRT page tables
explicitly in the userq restore path (as the CS path already does) so
sparse mappings survive a VRAM-lost reset. Because the PRT bo_va is off
the state lists, its PTE update fence lands in prt_va->last_pt_update
rather than vm->last_update, so wait on it explicitly before restarting
the queues (mirroring how the CS path syncs that fence).

v2:
 - keep the PRT bo_va off the vm_bo state lists instead of NULL-guarding
   bo inside amdgpu_vm_handle_moved(); a PRT mapping should never be on
   the moved list in the first place (Christian)

v3:
 - the PRT PTEs are updated separately, so their fence is in
   prt_va->last_pt_update, not vm->last_update; wait on it in the userq
   restore path before restarting queues, otherwise the queues could
   restart before the sparse PTEs are written (Christian)

Suggested-by: Christian König 
Reviewed-by: Christian König 
Signed-off-by: Jesse Zhang 
Signed-off-by: Alex Deucher

drm/amdgpu/mes: refactor the amdgpu_mes_alloc/free_proc|gang()

2026-08-06T16:44:50+00:00

- Unify amdgpu_mes_alloc/free_proc|gang_ctx_index to provide
  centralized RS64mem bitmap management for both KGD and KFD.
- Retrieve the bitmap bit for userq contex index based on a
  per process granularity.

Signed-off-by: Prike Liang 
Reviewed-by: Michael Chen 
Signed-off-by: Alex Deucher

drm/amdgpu/userq: serialize queue map against GPU reset

2026-08-06T13:46:13+00:00

Creating a user queue can race with a GPU reset. While recovery holds
reset_domain->sem for write, MES is unresponsive, so the ADD_QUEUE from
amdgpu_userq_map_helper() times out (-110) and an otherwise valid queue
create fails:

  amdgpu: MES(0) failed to respond to msg=ADD_QUEUE
  [drm:mes_userq_map [amdgpu]] *ERROR* Failed to map queue in HW, err (-110)
  amdgpu: [drm] *ERROR* ... Failed to map Queue
  amdgpu: [drm] *ERROR* ... Failed to create usermode queue

Take reset_domain->sem for read around the map so it runs only once MES
is back up. This mirrors amdgpu_userq_cleanup() and honors the
userq_mutex -> reset_domain->sem order; the reset path never takes
userq_mutex, so there is no deadlock.

Reviewed-by: Alex Deucher 
Signed-off-by: Jesse Zhang 
Signed-off-by: Alex Deucher

drm/amdgpu: fix userq VA validation for sub-page buffers

2026-08-06T13:26:21+00:00

amdgpu_userq_input_va_validate() converts expected_size to page count
with a plain right shift. For expected_size smaller than one GPU page,
the computed size becomes 0 and the range check is effectively bypassed.

This allows sub-page userq buffers (e.g. EOP/CSA) to pass validation
as long as the start VA is mapped, without verifying the full span.

Fix it by rejecting zero expected_size, checking overflow when
computing end address, and deriving page span from [start_addr,
end_addr] inclusive.

Signed-off-by: Candice Li 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/amdgpu: dont pin wptr bo instead use eviction fence

2026-07-16T22:27:31+00:00

Instead of pinning the wptr bo attach the eviction fence to
the bo to make sure it remains valid all the time.

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