linux.git/drivers/gpu/drm/amd/amdgpu, 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: avoid integer overflow in VA range check

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

The original addition operation in 64-bit unsigned type may encounter
overflow situations. To prevent such issues and safely reject invalid
inputs, the check_add_overflow() function is used.

Signed-off-by: Ce Sun 
Reviewed-by: Tao Zhou 
Signed-off-by: Alex Deucher 
(cherry picked from commit cc768f4dd0bb9083c813683eeec44fc23921f771)

drm/amd/ras: Fix UMC error address allocation leak

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

amdgpu_umc_handle_bad_pages() allocates err_data->err_addr before
querying UMC error information. In the direct and firmware query paths,
the pointer is reassigned to a fresh allocation before the original
buffer is released, so the initial allocation is leaked on each handled
event.

Free the existing buffer before replacing it in those query paths so the
function exit cleanup only owns the active allocation.

Signed-off-by: Xiang Liu 
Reviewed-by: Stanley.Yang 
Reviewed-by: Tao Zhou 
Signed-off-by: Alex Deucher 
(cherry picked from commit 911b1bdd22c3712a22b60fcc58f7b9f2d07b0803)

drm/amdgpu: unmap all user mappings of framebuffer and doorbell before mode1 reset

2026-05-19T16:14:55+00:00

During Mode 1 reset, the ASIC undergoes a reset cycle and becomes temporarily
inaccessible via PCIe. Any attempt to access framebuffer or MMIO registers during
this window can result in uncompleted PCIe transactions, leading to NMI panics or
system hangs.

To prevent this, Unmap all of the applications mappings of the framebuffer
and doorbell BARs before mode1 reset. Also prevent new mappings from coming in
during the reset process.

v2: remove inode in kfd_dev (Christian)
v3: correct unmap offset (Felix), remove prevent new mappings part
to avoid deadlock (Christian)

Reviewed-by: Felix Kuehling 
Signed-off-by: Yifan Zhang 
Signed-off-by: Alex Deucher 
(cherry picked from commit 70cadefcc6160c575b04f763ada34c20e868d577)

drm/amdgpu: use atomic operation to achieve lockless serialization

2026-05-19T16:11:34+00:00

In amdgpu_seq64_alloc there is a possibility that two difference cores
from two separate NODES can try to and could get the same free slot.
So this fixes that race here using atomic test_and_set clear operations.

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

drm/amdgpu/vce3: Fix VCE 3 firmware size and offsets

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

The VCPU BO contains the actual FW at an offset, but
it was not calculated into the VCPU BO size.
Subtract this from the FW size to make sure there is
no out of bounds access.

This may fix VM faults when using VCE 3.

Cc: John Olender 
Fixes: e98226221467 ("drm/amdgpu: recalculate VCE firmware BO size")
Signed-off-by: Timur Kristóf 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
(cherry picked from commit 15c369257bd85f47a514744f960c5a51c867716f)

drm/amdgpu/vce2: Fix VCE 2 firmware size and offsets

2026-05-19T16:11:00+00:00

The VCPU BO contains the actual FW at an offset, but
it was not calculated into the VCPU BO size.
Subtract this from the FW size to make sure there is
no out of bounds access.

Additionally, increase the VCE_V2_0_DATA_SIZE to
have extra space after the VCE handles.

Also increase the data size used for each VCE handle.
The FW needs 23744 bytes, use 24K to be safe.

This fixes VM faults when using VCE 2.

Cc: John Olender 
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/4802
Fixes: e98226221467 ("drm/amdgpu: recalculate VCE firmware BO size")
Signed-off-by: Timur Kristóf 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
(cherry picked from commit a20d21df625548c1738c0745f753c5d6eb823bc3)

drm/amdgpu/vce1: Stop using amdgpu_vce_resume

2026-05-19T16:10:53+00:00

The VCE1 firmware works slightly differently and is already
loaded by vce_v1_0_load_fw(). It doesn't actually need to
call amdgpu_vce_resume().

Signed-off-by: Timur Kristóf 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
(cherry picked from commit 33d8951405e2dd81ac61edebc680e2dfb6b4fc9f)

drm/amdgpu/vce1: Fix VCE 1 firmware size and offsets

2026-05-19T16:10:45+00:00

The VCPU BO contains the actual FW at an offset, but
it was not calculated into the VCPU BO size.
Subtract this from the FW size to make sure there is
no out of bounds access.

Make sure the stack and data offsets are aligned to
the 32K TLB size.

Check that the FW microcode actually fits in the
space that is reserved for it.

Fixes: d4a640d4b9f3 ("drm/amdgpu/vce1: Implement VCE1 IP block (v2)")
Signed-off-by: Timur Kristóf 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
(cherry picked from commit c16fe59f622a080fc457a57b3e8f14c780699449)