linux-toradex.git/drivers/gpu, branch v7.0-rc3

Merge tag 'drm-xe-fixes-2026-03-05' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes

2026-03-06T09:45:19+00:00

Cross-subsystem Changes:
 - mm: Fix a hmm_range_fault() livelock / starvation problem (Thomas)

Core Changes:
 - Revert "drm/pagemap: Disable device-to-device migration" (Thomas)

Driver Changes:
 - Do not preempt fence signaling CS instructions (Brost)
 - Some leak and finalization fixes (Shuicheng, Tomasz, Varun, Zhanjun)
 - Workaround fix (Roper)

Signed-off-by: Dave Airlie 

From: Rodrigo Vivi 
Link: https://patch.msgid.link/aamGvvGRBRtX8-6u@intel.com

Merge tag 'drm-misc-fixes-2026-03-06' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes

2026-03-06T09:41:28+00:00

Another early drm-misc-fixes PR to revert the previous uapi fix sent in
drm-misc-fixes-2026-03-05, together with a UAF fix in TTM, an argument
order fix for panthor, a fix for the firmware getting stuck on
resource allocation error handling for amdxdna, and a few fixes for
ethosu (size calculation and reference underflows, and a validation
fix).

Signed-off-by: Dave Airlie 

From: Maxime Ripard 
Link: https://patch.msgid.link/20260306-grumpy-pegasus-of-witchcraft-6bd2db@houat

Merge tag 'drm-misc-fixes-2026-03-05' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes

2026-03-06T09:40:00+00:00

A return type fix for ttm, a display fix for solomon, several misc fixes
for amdxdna, a DSI clock rate fix for rz-du, a uapi fix for syncobj, a
possible build failure fix for dma-buf, a doc warning fix for sched, a
build failure fix for ttm tests, and a crash fix when suspended for
nouveau.

Signed-off-by: Dave Airlie 

From: Maxime Ripard 
Link: https://patch.msgid.link/20260305-ludicrous-quirky-raven-7cdafd@houat

Merge tag 'drm-intel-fixes-2026-03-05' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes

2026-03-06T07:10:02+00:00

- Fix for #7284: Lenovo T14 G7 display not refreshing

Signed-off-by: Dave Airlie 
From: Joonas Lahtinen 
Link: https://patch.msgid.link/aakz17Jx3Ye9Vqci@jlahtine-mobl

drm/panthor: Correct the order of arguments passed to gem_sync

2026-03-05T16:53:09+00:00

This commit corrects the order of arguments passed to panthor_gem_sync()
function, called when the SYNC_WAIT condition has to be evaluated for a
blocked GPU queue.

Fixes: cd2c9c3015e6 ("drm/panthor: Add flag to map GEM object Write-Back Cacheable")
Signed-off-by: Akash Goel 
Reviewed-by: Steven Price 
Reviewed-by: Boris Brezillon 
Reviewed-by: Liviu Dudau 
Link: https://patch.msgid.link/20260305110723.2871733-1-akash.goel@arm.com
Signed-off-by: Liviu Dudau

Revert "drm/syncobj: Fix handle <-> fd ioctls with dirty stack"

2026-03-05T14:16:48+00:00

This reverts commit 2e3649e237237258a08d75afef96648dd2b379f7.

The problem occurs when userspace is compiled against new headers
with new members, but don't correctly initialise those new members.

This is not a kernel problem, and should be fixed in userspace by
correctly zero'ing all members.

Cc: Rob Clark 
Cc: Julian Orth 
Cc: Christian König 
Cc: Michel Dänzer 
Reviewed-by: Christian König 
Acked-by: Julian Orth 
Link: https://patch.msgid.link/20260305113734.1309238-1-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst

drm/ttm: Fix bo resource use-after-free

2026-03-05T08:12:36+00:00

When allocating a lot of buffers and putting the TTM under memory pressure,
during swapout, it might crash the system with the stack trace below.

It turns out that ttm_bo_swapout_cb might replace bo->resource when it
moves it to system cached.

When commit c06da4b3573a ("drm/ttm: Tidy usage of local variables a little
bit") used a local variable for bo->resource, it used the freed resource
later in the function, leading to a UAF.

Move back to using bo->resource in all cases in that function instead of a
local variable.

[  604.814275] BUG: kernel NULL pointer dereference, address: 0000000000000000
[  604.814284] #PF: supervisor read access in kernel mode
[  604.814288] #PF: error_code(0x0000) - not-present page
[  604.814291] PGD 0 P4D 0
[  604.814296] Oops: Oops: 0000 [#1] SMP NOPTI
[  604.814303] CPU: 2 UID: 0 PID: 4408 Comm: vulkan Tainted: G        W           7.0.0-rc2-00001-gc50a051e6aca #21 PREEMPT(full)  aef6eb0c02036a7c8a5e62e0c84a30c2be90688d
[  604.814309] Tainted: [W]=WARN
[  604.814311] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0133 08/05/2024
[  604.814314] RIP: 0010:ttm_resource_move_to_lru_tail+0x100/0x160 [ttm]
[  604.814329] Code: 5b 5d e9 83 b4 1b cb 48 63 d2 48 c1 e0 04 48 8b 4e 40 48 8d 7e 40 48 8b ac d3 d8 00 00 00 48 89 c3 48 8d 54 05 68 48 8b 46 48 <48> 3b 38 0f 85 b3 3b 00 00 48 3b 79 08 0f 85 a9 3b 00 00 48 89 41
[  604.814332] RSP: 0018:ffffcfe54e3d7578 EFLAGS: 00010256
[  604.814336] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8cf09eced300
[  604.814339] RDX: 0000000000000068 RSI: ffff8cf1d4c1fc00 RDI: ffff8cf1d4c1fc40
[  604.814341] RBP: 0000000000000000 R08: ffff8cf09eced300 R09: 0000000000000000
[  604.814344] R10: 0000000000000000 R11: 0000000000000016 R12: ffff8cf1d4c1fc00
[  604.814346] R13: 0000000000000400 R14: ffff8cf096289c00 R15: ffff8cf084c8f688
[  604.814349] FS:  00007f00531b7780(0000) GS:ffff8cf4217a0000(0000) knlGS:0000000000000000
[  604.814352] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  604.814355] CR2: 0000000000000000 CR3: 000000018e3df000 CR4: 0000000000350ef0
[  604.814358] Call Trace:
[  604.814362]  
[  604.814368]  ttm_bo_swapout_cb+0x24c/0x280 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302]
[  604.814380]  ttm_lru_walk_for_evict+0xac/0x1d0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302]
[  604.814394]  ttm_bo_swapout+0x5b/0x80 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302]
[  604.814405]  ttm_global_swapout+0x63/0x100 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302]
[  604.814415]  ttm_tt_populate+0x82/0x130 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302]
[  604.814424]  ttm_bo_populate+0x37/0xa0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302]
[  604.814433]  ttm_bo_handle_move_mem+0x157/0x170 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302]
[  604.814443]  ttm_bo_validate+0xd9/0x180 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302]
[  604.814453]  ttm_bo_init_reserved+0xa0/0x1b0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302]
[  604.814461]  ? srso_return_thunk+0x5/0x5f
[  604.814469]  amdgpu_bo_create+0x1f5/0x500 [amdgpu 361516226706227f4403914dbfdd3f90996136ca]
[  604.814855]  ? __pfx_amdgpu_bo_user_destroy+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca]
[  604.815182]  amdgpu_bo_create_user+0x3d/0x70 [amdgpu 361516226706227f4403914dbfdd3f90996136ca]
[  604.815504]  amdgpu_gem_create_ioctl+0x16c/0x3b0 [amdgpu 361516226706227f4403914dbfdd3f90996136ca]
[  604.815830]  ? __pfx_amdgpu_bo_user_destroy+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca]
[  604.816155]  ? __pfx_amdgpu_gem_create_ioctl+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca]
[  604.816478]  drm_ioctl_kernel+0xae/0x100
[  604.816486]  drm_ioctl+0x283/0x510
[  604.816491]  ? __pfx_amdgpu_gem_create_ioctl+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca]
[  604.816819]  amdgpu_drm_ioctl+0x4a/0x80 [amdgpu 361516226706227f4403914dbfdd3f90996136ca]
[  604.817135]  __x64_sys_ioctl+0x96/0xe0
[  604.817142]  do_syscall_64+0x11b/0x7e0
[  604.817148]  ? srso_return_thunk+0x5/0x5f
[  604.817152]  ? srso_return_thunk+0x5/0x5f
[  604.817156]  ? walk_system_ram_range+0xb0/0x110
[  604.817161]  ? srso_return_thunk+0x5/0x5f
[  604.817165]  ? __pte_offset_map+0x1b/0xb0
[  604.817170]  ? srso_return_thunk+0x5/0x5f
[  604.817174]  ? pte_offset_map_lock+0x87/0xf0
[  604.817179]  ? srso_return_thunk+0x5/0x5f
[  604.817183]  ? insert_pfn+0x9f/0x1f0
[  604.817188]  ? srso_return_thunk+0x5/0x5f
[  604.817192]  ? vmf_insert_pfn_prot+0x97/0x190
[  604.817197]  ? srso_return_thunk+0x5/0x5f
[  604.817201]  ? ttm_bo_vm_fault_reserved+0x1a6/0x3f0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302]
[  604.817213]  ? srso_return_thunk+0x5/0x5f
[  604.817217]  ? amdgpu_gem_fault+0xe2/0x100 [amdgpu 361516226706227f4403914dbfdd3f90996136ca]
[  604.817542]  ? srso_return_thunk+0x5/0x5f
[  604.817546]  ? __do_fault+0x33/0x180
[  604.817550]  ? srso_return_thunk+0x5/0x5f
[  604.817554]  ? do_fault+0x178/0x610
[  604.817559]  ? srso_return_thunk+0x5/0x5f
[  604.817562]  ? __handle_mm_fault+0x9be/0x1120
[  604.817567]  ? srso_return_thunk+0x5/0x5f
[  604.817574]  ? srso_return_thunk+0x5/0x5f
[  604.817578]  ? count_memcg_events+0xc4/0x160
[  604.817583]  ? srso_return_thunk+0x5/0x5f
[  604.817587]  ? handle_mm_fault+0x1d7/0x2e0
[  604.817593]  ? srso_return_thunk+0x5/0x5f
[  604.817596]  ? do_user_addr_fault+0x173/0x660
[  604.817602]  ? srso_return_thunk+0x5/0x5f
[  604.817607]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[  604.817612] RIP: 0033:0x7f00532cef4d
[  604.817617] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
[  604.817620] RSP: 002b:00007ffd69ab0650 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[  604.817624] RAX: ffffffffffffffda RBX: 00007ffd69ab07d0 RCX: 00007f00532cef4d
[  604.817627] RDX: 00007ffd69ab0700 RSI: 00000000c0206440 RDI: 0000000000000005
[  604.817629] RBP: 00007ffd69ab06a0 R08: 00007f00533a0ac0 R09: 0000000000000000
[  604.817632] R10: 00007ffd69ab07c0 R11: 0000000000000246 R12: 00007ffd69ab0700
[  604.817634] R13: 00000000c0206440 R14: 0000000000000005 R15: 0000000000000243
[  604.817642]  

Cc: Tvrtko Ursulin 
Cc: Christian König 
Fixes: c06da4b3573a ("drm/ttm: Tidy usage of local variables a little bit")
Signed-off-by: Thadeu Lima de Souza Cascardo 
Reviewed-by: Tvrtko Ursulin 
Signed-off-by: Tvrtko Ursulin 
Link: https://lore.kernel.org/r/20260304-ttm_bo_res_uaf-v1-1-43f20125b67f@igalia.com

nouveau/dpcd: return EBUSY for aux xfer if the device is asleep

2026-03-04T21:08:01+00:00

If we have runtime suspended, and userspace wants to use /dev/drm_dp_*
then just tell it the device is busy instead of crashing in the GSP
code.

WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy)
Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024
RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]

This is a simple fix to get backported. We should probably engineer a
proper power domain solution to wake up devices and keep them awake
while fw updates are happening.

Cc: stable@vger.kernel.org
Fixes: 8894f4919bc4 ("drm/nouveau: register a drm_dp_aux channel for each dp connector")
Reviewed-by: Lyude Paul 
Signed-off-by: Dave Airlie 
Link: https://patch.msgid.link/20260224031750.791621-1-airlied@gmail.com
Signed-off-by: Danilo Krummrich

drm/amdgpu/userq: refcount userqueues to avoid any race conditions

2026-03-04T18:15:00+00:00

To avoid race condition and avoid UAF cases, implement kref
based queues and protect the below operations using xa lock
a. Getting a queue from xarray
b. Increment/Decrement it's refcount

Every time some one want to access a queue, always get via
amdgpu_userq_get to make sure we have locks in place and get
the object if active.

A userqueue is destroyed on the last refcount is dropped which
typically would be via IOCTL or during fini.

v2: Add the missing drop in one the condition in the signal ioclt [Alex]

v3: remove the queue from the xarray first in the free queue ioctl path
    [Christian]

- Pass queue to the amdgpu_userq_put directly.
- make amdgpu_userq_put xa_lock free since we are doing put for each get
  only and final put is done via destroy and we remove the queue from xa
  with lock.
- use userq_put in fini too so cleanup is done fully.

v4: Use xa_erase directly rather than doing load and erase in free
    ioctl. Also remove some of the error logs which could be exploited
    by the user to flood the logs [Christian]

Signed-off-by: Sunil Khatri 
Reviewed-by: Christian König 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
(cherry picked from commit 4952189b284d4d847f92636bb42dd747747129c0)
Cc:  # 048c1c4e5171: drm/amdgpu/userq: Consolidate wait ioctl exit path
Cc:

drm/amdgpu/userq: Consolidate wait ioctl exit path

2026-03-04T18:15:00+00:00

If we gate the fence destruction with a check telling us whether there are
valid pointers in there we can eliminate the need for dual, basically
identical, exit paths.

Reviewed-by: Alex Deucher 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Alex Deucher 
(cherry picked from commit bea29bb0dd29012949cd44fdb122465a9fd5cf91)