summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
40 hoursMerge tag 'driver-core-7.4-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core Pull driver core updates from Danilo Krummrich: "Core: - Add TAINT_FORCED_BIND to taint the kernel and driver module before manual sysfs bind/unbind operations; make add_taint_module() available to driver core and update taint decoding tools and documentation - Constify device_show/store_*() attribute parameters and adapt x86 MCE and perf users to prepare for const dev_ext_attribute instances - Fix UAF in NUMA access node registration failure handling by dropping the device reference with put_device() instead of directly freeing the node debugfs: - Make debugfs_create_str() read-only to eliminate double-free races between concurrent writers; reject writable modes; convert interconnect and SoundWire users to local file operations with mutex-protected strings kobject: - Fix out-of-bounds access in kobject_action_type() when parsing action strings containing embedded NUL bytes - Fix the kobject_set_name() reference in kset_register() kernel-doc Rust: - DMA: - Tie Coherent, CoherentBox and CoherentHandle to the device's bound lifetime to prevent retaining DMA allocations beyond driver unbind; propagate the lifetime through nova-core and the DMA sample driver - I/O: - Require explicit base types for registers and replace relative registers with typed subregion projections; reimplement register!() as a proc macro, support registers using existing types without inline bitfields, and convert nova-core, Tyr and the PCI sample; add AsRepr/AsReprMut and transmute helpers with deferred size checks for representation conversions - Wrap ResourceSize in a transparent newtype with explicit conversions, including checked conversion to usize - PCI: - Add typed PCIe extended capability lookup and SR-IOV accessors for the First VF Offset and decoded VF BAR addresses and widths, keeping raw SR-IOV registers private to preserve PCI core ownership of their state - scatterlist: - Honor the device's maximum segment size as well as the DMA mapping limit when constructing SG tables - Return u32 from SGEntry::dma_len() to match the C segment length type - misc: - Validate auxiliary DeviceId name length explicitly to improve compile-time diagnostics for oversized device ID table entries - Drop unnecessary 'static bounds from debugfs ScopedDir file creation methods to support data containing non-'static references, including DMA buffers Misc: - Add Johan Hovold as driver core maintainer - Simplify platform_device_alloc() by returning early on allocation failure - Fix typos in driver core and kernfs comments" * tag 'driver-core-7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: (41 commits) rust: pci: add extended capability and SR-IOV support kobject: Fix the kobj_set_name reference in kset_register() kernel-doc rust: io: convert ResourceSize into a transparent newtype rust: scatterlist: return u32 from SGEntry::dma_len() MAINTAINERS: add myself as driver core maintainer debugfs: make debugfs_create_str() read-only soundwire: debugfs: replace writable string helper interconnect: debugfs: replace writable string helper docs: admin-guide: Handle TAINT_FORCED_BIND when parsing /proc/sys/kernel/tainted driver core: platform: Simplify platform_device_alloc() kobject: fix out-of-bounds access in kobject_action_type() rust: scatterlist: honor the device's maximum segment size driver core: add TAINT_FORCED_BIND for when userspace manually messes with devices and drivers module: fix up documentation for add_taint() and add_taint_module() module: pull out add_taint_module() to be public driver core: Constify the signature of device_show/store_*() drivers: perf: Use __DEVICE_ATTR() macro to initialize dev_ext_attribute x86/mce: Use __DEVICE_ATTR() macro to initialize dev_ext_attribute rust: auxiliary: validate DeviceId name length driver core: fix typos in comments ...
2 daysMerge __{get,put}_user() removal branchLinus Torvalds
This is long over-due: the __get_user() and __put_user() functions are entirely historical, and are never the rigth thing to use any more. And when mis-used (read: every case) they are not only slower than the right thing, but also insecure because they don't check the user address range. Most of the usage sites have been converted long ago, but various left-overs remained. So this started out as a single patch that I wrote as a "show people how to convert __{get,put}_user() to modern code". In particular, Thomas last year implemented the very nice new scoped user access region helpers (see commit e497310b4ffb: "uaccess: Provide scoped user access regions") that makes the modern interfaces particularly easy to use and really removes any excuse for the old horrors. That small example patch then grew to this, partly using Claude as a glorified coccinelle script to apply the pattern to other places. There were a few different reasons for using __put_user() and __get_user() rather than the alternatives, but the original historical one was performance: when doing multiple accesses off the same base pointer, doing a single range check followed by multiple non-checked accesses used to create smaller and faster code. The keyword here is "used to". It hasn't been true for years, because the range check isn't actually the real cost these days. The real cost of user accesses on modern hardware is turning the user accesses on and off in the first place (on x86, using the STAC/CLAC instructions). Those sequences get turned into 'scoped_user_read_access() { }' blocks, see for example that first patch in the series: "signal: use scoped user access for old-style sigaction". Another, historical reason for using __get_user() and friends is that you actually want to do a kernel pointer access, but the pointer might not be entirely reliable (typically during fault handling), so you want to have exception handling for the kernel access. The modern way to do that kind of non-faulting kernel access is using "get_kernel_nofault()", but some code predates that helper existing at all, and used __get_user() as a way to just get a memory access with exception handling. For that pattern, see for example "alpha: use get_kernel_nofault() in dik_show_code()" A third bad reason for using __get_user() and friends was that the proper get_user() had a "might_fault()" in it, and code that ran in atomic regions but hadn't disabled page faults would result in a warning. That kind of code needs to explicitly disable page faults, because "atomic region" is not well defined at run-time and can be invisible (eg a preempt-off region in a non-preemptible kernel). See "vdpa_sim: disable page faults around vringh_need_notify_iotlb()" for an example of that pattern, where the local_bh_disable() now also grows a pagefault_disable(), which makes the normal get_user() no longer warn about the user access in non-process context, because it can see that the potential page fault will not cause problems. And finally, the really nasty reason to use __get_user() and friends: pointers that can be either kernel pointers or user pointers. We've gotten rid of almost all such cases, but a couple remained. See for example "x86/sev: Use explicit user-or-kernel accessors for #VC memory operands". NOTE! This series removes all __get/put_user() calls from generic code but only does the final removal of the whole interface on x86. Other architectures have not been entirely converted, for a variety of reasons: - arm64 makes __{get,put}_user() be exactly the same as {get,put}_user() so it's harmless and didn't have the dangers of the legacy use cases. - any architecture that uses <asm-generic/uaccess.h> will still use __{get,put}_user as the underlying helper function name - several architectures had some legacy uses that weren't entirely trivial and I didn't want to extend this patch series to things that I don't know and that don't really matter. but I did do a couple of the obvious "follows the exact same pattern" just because it could be done mindlessly and automatically. Let's see if I broke anything, but we should have done this years ago. * uaccess-cleanups: (48 commits) drm/i915/gem: ignore errors on presumed_offset write-back powerpc/align: use get_user_instr() for a user-mode instruction powerpc/signal64: use scoped user access in setup_trampoline() powerpc/signal64: use get_user() for the single context reads powerpc/signal32: use get_user() for the single context reads KVM: PPC: Book3S HV: use get_user()/put_user() for the HPT fd powerpc/powernv: use get_user()/put_user() in the LPC debugfs files s390: use get_user()/put_user() instead of the unchecked variants ARM: OABI: use scoped user access in epoll_put_uevent() ARM: signal: stop using __put_user() for the signal frame ARM: signal: check the FDPIC function descriptor address alpha: split the prefetch check in do_page_fault() by mode openrisc: use get_kernel_nofault() in show_registers() alpha: use get_kernel_nofault() in dik_show_code() nios2: use scoped user access for the signal frame nios2: check the signal frame address before writing to it hexagon: use scoped user access for the signal frame alpha: use scoped user access when setting up signal frames alpha: use scoped user access in the sigreturn path alpha: use scoped user access in osf_sigaction() ...
2 daysdrm/i915/gem: ignore errors on presumed_offset write-backLinus Torvalds
It appears that the crazy "don't check for errors" code in the i915 relocation code was intentional, but not visible in the code as such. See commit 97a37c919f62 ("drm/i915/gem: Ignore readonly failures when updating relocs"). Quoting that commit: "Be damned if you do, and damned if you don't." So disable the error check again, but leave it around visibly for posterity as documentation for why it's not there. Fixes: 03c19e449ac6 ("drm/i915/gem: Don't fault on presumed_offset write-back") Reported-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
3 daysMerge tag 'configfs-7.4-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/leitao/linux Pull configfs updates from Breno Leitao: - Attribute structures can now be const (Thomas Weißschuh) - The first selftests for the configfs userspace interface, plus a sample subsystem that accepts symlinks to test against. They include a race of symlink(2) against rmdir of the target, which exercises the use-after-free fixed in v7.3-rc3. - Rust bindings, merged from Andreas Hindborg's signed tag: fix the data offset calculation in subsystem callbacks (marked for stable), add the missing Send and Sync bounds, and correct a safety comment. * tag 'configfs-7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/leitao/linux: samples: configfs: constify the configfs_attribute structures configfs: Allow the registration of const struct configfs_attribute configfs: Constify configfs_bin_attribute configfs: Treat attribute structures as const internally configfs: Constify is_visible/is_visible_bin in configfs_group_operations rust: configfs: remove mutability from some field initializers selftests/configfs: race symlink against rmdir of the target selftests/configfs: cover symlink and unlink samples/configfs: add a subsystem that accepts symlinks selftests/configfs: add tests for the userspace interface rust: configfs: fix data offset calculation for subsystem callbacks rust: configfs: require thread-safe callback data rust: configfs: fix release safety documentation
3 daysdrm/i915/gem: Use get_user()/put_user() where no locks are heldLinus Torvalds
execbuffer prefaults the relocation array and reads timeline fence values one element at a time with __get_user(), after checking each array with access_ok() up front. Each of those accesses enables and disables user access on its own, so the up-front check saves nothing. Both run with no object locks held: the prefault between dropping and retaking the ww locks, the fence parsing before the ww context exists. Use get_user(). The access_ok() checks stay, since they also decide how a bad array fails. The gem mman selftests use the unchecked variants on addresses they got from their own mmaps, with no check at all. Convert those too. This is part of getting rid of __get_user() and __put_user() entirely. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
3 daysdrm/i915/gem: Don't fault on presumed_offset write-backLinus Torvalds
The execbuffer relocation fast path writes each updated presumed_offset back to the user's relocation array with __put_user(), ignoring any failure. It does that while holding the objects' dma_resv locks, and with page faults enabled unless the relocation cache happens to have an atomic mapping active. So if that write faults, for example on a copy-on-write page after a fork(), the fault handler takes mmap_lock under dma_resv. That is the opposite of the order the i915 fault handler uses, which takes the object lock under mmap_lock. The comment above it claimed this could not happen, because "we did previously check if the relocations were writable (access_ok)". access_ok() is purely a range check. The comment dates from when this was access_ok(VERIFY_WRITE), and that only ever made a difference on the original i386, whose write-protect bit did not stop supervisor writes. So nothing has made sure the array was writable for decades. Do the write with page faults disabled, and if it fails, fall back to the slow path exactly as we already do when reading the relocations fails part-way through. We cannot just ignore the failure: the object has already been relocated, and a stale presumed_offset could later match again and skip a relocation that is needed. The slow path prefaults and retries. If the write still fails, it copies the relocations and marks every presumed_offset invalid with faults allowed and no locks held, which breaks copy-on-write as needed. One user-visible change: a relocation array in genuinely read-only memory used to get through the fast path, silently losing the presumed_offset updates. It now gets -EFAULT from the slow path, as it already did whenever anything else sent execbuffer there. The uapi has the kernel updating presumed_offset, so the array is expected to be writable. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
4 daysMerge tag 'vfs-7.4-rc1.file' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull file table updates from Christian Brauner: "This annotates struct fdtable's fd array with __counted_by_ptr so KASAN and the fortified functions can bounds check it against max_fds and adds a KUnit suite for fdtable. A follow-up uses __struct_size() in the test since sparse doesn't know __builtin_dynamic_object_size(). FD_PREPARE() is simplified. It was built as an ACQUIRE-style guard on infrastructure that was never needed. The ACQUIRE machinery and CLASS_INIT() go away, the variable is declared with __cleanup() directly, struct fd_prepare loses its err field since the fd either holds the descriptor or the error, and callers get a const pointer to the guard behind a UNIQUE_ID() name so they can't shadow it. Code generation is identical" * tag 'vfs-7.4-rc1.file' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: file: make struct fd_prepare const and kill its err field cleanup: remove CLASS_INIT() file: declare the FD_PREPARE() variable with __cleanup() directly file: simplify FD_PREPARE() vfs: use __struct_size() in the fdtable KUnit test vfs: Add KUnit tests for fdtable vfs: Annotate struct fdtable's fd field with __counted_by_ptr
7 daysconfigfs: Constify is_visible/is_visible_bin in configfs_group_operationsThomas Weißschuh
These callbacks are never meant to modify their configfs_attribute structure. Enforce this in the type system. As there are only two implementers of these callbacks, adapt them right away, avoiding a phased transition. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Breno Leitao <leitao@debian.org> Acked-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://patch.msgid.link/20260716-configfs-const-base-v1-2-c545a4053cb5@weissschuh.net Signed-off-by: Breno Leitao <leitao@debian.org>
8 daysMerge tag 'amd-drm-fixes-7.3-2026-10-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes amd-drm-fixes-7.3-2026-10-15: amdgpu: - UVD fix - TTM sched entity fixes - SMU 14 fix - Userptr leak fixes - Runpm ref count fix - CRIU fix - UserQ fixes - USB4 fix - SDMA 3 fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20261015221002.1728931-1-alexander.deucher@amd.com
8 daysMerge tag 'drm-xe-fixes-2026-10-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes An OA uAPI fix by zeroing OA buffer at allocation, and other 3 small fixes around eviction and shrinker. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/atDNMV-Aohu6s0gE@intel.com
8 daysMerge tag 'drm-misc-fixes-2026-10-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A revert for the blend mode property patch being applied twice and a patch to reset the device when frozen in virtio, a power state fix for vc4, a Kconfig fix for amdxdna, an error handling, reference counting, and a null pointer dereference fix for rocket, a revert for dma-buf for a commit introducing a dangling reference, a locking fix for exec, and a fix for panthor to handle 10-core GPUs. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/atCZfcTvshZx6mcA@houat
8 daysdrm/amdgpu/sdma3: Work around POLL_REGMEM / FENCE hangTimur Kristóf
SDMA can randomly hang on Polaris 10. Hard to reproduce, but has been occurring sporadically in the Mesa CI on the RADV Polaris 10 job even when Mesa isn't using the SDMA engine. When Mesa actually uses the SDMA on Polaris, the hang becomes more frequent and the reproduction rate goes up significantly in the CI system. We don't know why the hangs occur, but it seems that inserting a single NOP packet before each POLL_REGMEM and FENCE packet works around it. At the moment it's unclear which GPUs are affected, so let's apply this to SDMA 3.x for now. Note that this issue is not documented or acknowledged by AMD. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c343a27ed90823d08de125f7c447d96d056b75d9) Cc: stable@vger.kernel.org
8 daysdrm/amdgpu: keep the eviction fence until the last handle is closedJesse Zhang
amdgpu_gem_object_close() detaches the user queue eviction fence from the BO before it checks bo_va->ref_count, so closing any handle of a BO removes the fence, even when the file still has another handle to the BO and the bo_va with its GPU mappings stays. The BO can then be evicted without suspending the user queues of the file, which keep accessing it through mappings that are only marked for update. Seen on navi31 with a SDMA user queue: a BO opened twice in the same file (GEM_FLINK + GEM_OPEN) loses its eviction fence when the second handle is closed (traced attach/detach of the fence): attach bo=ffff8c78a6c84c00 GEM_CLOSE handle=7 detach bo=ffff8c78a6c84c00 while handle 6 and the mapping are still in use. Only detach the fence when the last reference to the bo_va goes away, matching amdgpu_gem_object_open(), which attaches it only when the bo_va is created. With this the fence stays until the file is closed. Fixes: 31f7efcdca4d ("drm/amdgpu: enable eviction fence") Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8387982f03d4026b7dc11b0b5e3118298eee4d6a) Cc: stable@vger.kernel.org
8 daysdrm/amd/display: Fix NULL sink dereference in USB4 bandwidth functionsSrinivasan Shanmugam
allocate_usb4_bandwidth_for_stream() and allocate_usb4_bandwidth() both use ASSERT(stream->sink) before dereferencing stream->sink->link. ASSERT is compiled out in production builds, so a NULL stream->sink causes a NULL pointer dereference. link_set_dpms_off() already guards two earlier accesses to stream->sink with explicit NULL checks, confirming that stream->sink can legitimately be NULL. The subsequent call to deallocate_usb4_bandwidth() had no equivalent guard. Replace the ASSERT() calls with proper NULL checks that return false early, and add a matching stream->sink guard at the call site in link_set_dpms_off() consistent with the surrounding pattern. v2: Keep the existing ASSERT() calls for diagnostics (to report unexpected NULL sink), and add explicit NULL checks that return false before dereferencing stream->sink. Also add a matching stream->sink guard at the deallocation call site in link_set_dpms_off(). (Alex) Fixes: 8fa813b7fd1e ("drm/amd/display: Remove sink usage from DPMS") Reported-by: Dan Carpenter <error27@gmail.com> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Dominik Kaszewski <dominik.kaszewski@amd.com> Cc: George Zhang <george.zhang@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Roman Li <Roman.Li@amd.com> Cc: Ivan Lipski <ivan.lipski@amd.com> Cc: Dan Wheeler <daniel.wheeler@amd.com> Cc: Alex Hung <alex.hung@amd.com> Cc: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 98029a0ce61feb52c563f65349dd9b25f672e355) Cc: stable@vger.kernel.org
8 daysdrm/amdgpu/userq: actually validate userq BOsBenjamin Cheng
This was supposed to loop over the individual evicted list, as the kernel and always_valid evicted lists were already handled in amdgpu_vm_validate. Without this, BOs that were created and evicted before a userq was made would never end up in an eviction fence rearm. Also add the missing ref to the BO before drm_exec locks and refs it. Fixes: 4cdbba5a16aa ("drm/amdgpu: restructure VM state machine v4") Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 18decfc9e8cc0fa70b6de9944cc27a37729edfbd) Cc: stable@vger.kernel.org
8 daysdrm/amdgpu: report the BO alignment in bytes in GEM_LIST_HANDLESJesse Zhang
The uapi documents drm_amdgpu_gem_list_handles_entry.alignment as "physical start_addr alignment in bytes", and GEM_OP GET_GEM_CREATE_INFO returns the same value in bytes, but GEM_LIST_HANDLES returns tbo.page_alignment, which is in pages. For a BO created with a 64 KiB alignment on navi31: GET_GEM_CREATE_INFO: alignment=65536 GEM_LIST_HANDLES: alignment=16 so a user such as CRIU that recreates BOs from this list uses the wrong alignment. Convert it to bytes. Fixes: f9db1fc52ceb ("drm/amdgpu: Add ioctl to get all gem handles for a process") Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit aa4493ae949c13e79aba0731394dd7a7e431342b) Cc: stable@vger.kernel.org
8 daysdrm/amdgpu: free the userptr ranges when a CS fails after parser_bosJesse Zhang
amdgpu_cs_parser_bos() allocates an HMM range for every userptr entry of the BO list and looks up the user pages. Those ranges are only freed when amdgpu_cs_parser_bos() itself fails or when amdgpu_cs_submit() checks them under the notifier lock. If amdgpu_cs_patch_jobs(), amdgpu_cs_vm_handling(), amdgpu_cs_sync_rings() or the early part of amdgpu_cs_submit() fails, nothing frees them: neither amdgpu_cs_parser_fini() nor amdgpu_bo_list_free() touch e->range. Each such CS then leaks the range, its hmm_pfns array (8 bytes per page of the userptr BO) and the BO reference the range holds. An IB on a ring that patches the CS in place (e.g. VCN) with an unmapped va_start fails in amdgpu_cs_patch_ibs() and takes this path. Free the ranges on those error paths. Ranges amdgpu_cs_submit() already dropped are NULL, so freeing them again is a no-op. Fixes: fec8fdb54e8f ("drm/amdgpu: fix userptr HMM range handling v2") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c52a9542ed7cfd527feb938bd0accada2ac8d267) Cc: stable@vger.kernel.org
8 daysdrm/amdgpu: don't drop the runtime PM reference twice in amdgpu_gprJesse Zhang
amdgpu_debugfs_gpr_read() drops its runtime PM reference right after reading the wave registers. When copying them to userspace fails, it jumps to the err label, which drops the reference a second time. A read into a bad buffer on Navi31 either steals a reference somebody else holds (power/runtime_usage goes from 1 to 0) or underflows the count: amdgpu 0000:03:00.0: Runtime PM usage count underflow! The registers are already in the kernel buffer at that point, so finish the hardware access first and copy the buffer with a single copy_to_user() instead of the put_user() loop with its own error path. Fixes: 9eee152aab56 ("drm/amdgpu/debugfs: fix ref count leak when pm_runtime_get_sync fails") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 31035bbd74f7c3e10c163db875b8e67f8b50ee6a) Cc: stable@vger.kernel.org
8 daysdrm/amdgpu: fix GEM object leak on ENOMEM in userptr ioctlPerry Yuan
When amdgpu_hmm_range_alloc() fails amdgpu_gem_userptr_ioctl() returns -ENOMEM right away and skips the cleanup every other error path goes through. The GEM object, the bo->parent reference on the VM root and the MMU notifier registration are all left behind. Use release_object here, not user_pages_done, range is still NULL at this point. Fixes: e095b55155ef ("drm/amdgpu: use user provided hmm_range buffer in amdgpu_ttm_tt_get_user_pages") Signed-off-by: Perry Yuan <perry.yuan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit bbe739e407a542073ec1a7872b14843566b4919e) Cc: stable@vger.kernel.org
8 daysdrm/amd/pm: add zero fan stop temperature support on smu 14.0.2Kenneth Feng
add zero fan stop temperature support on smu 14.0.2 Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5905 Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Kevin Wang <kevin.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f990c94a2633d0ead477eb1b174e254a6d292e66) Cc: stable@vger.kernel.org
8 daysdrm/amdgpu: destroy mutex when tearing down ttm buffer entityPerry Yuan
Pair mutex_init() with mutex_destroy() on the GART window allocation failure path and in amdgpu_ttm_buffer_entity_fini(). This is a no-op without CONFIG_DEBUG_MUTEXES, but it keeps lockdep from seeing a live mutex after the entity is freed or re-initialized. Signed-off-by: Perry Yuan <perry.yuan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 03ac40aeed034a0a0d5824ad26f8fbe1f6463698) Cc: stable@vger.kernel.org
8 daysdrm/amdgpu: fix sched entity leak in ttm buffer entity initPerry Yuan
amdgpu_ttm_buffer_entity_init() checks num_gart_windows after drm_sched_entity_init() has already attached the entity to a scheduler run-queue. Returning -EINVAL from that check leaks the entity. Move the ARRAY_SIZE() check before any resources are acquired. Fixes: 2c3725572561 ("drm/amdgpu: statically assign gart windows to ttm entities") Signed-off-by: Perry Yuan <perry.yuan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 4000d1cdd1eacd3422267d6c8b4f1c9333b0317e) Cc: stable@vger.kernel.org
8 daysdrm/amdgpu/uvd3.1: Fix checking whether UVD firmware keyselect was already setTimur Kristóf
The PASS_MASK is for a different register not for UVD_FW_START. It was a mistake to check this flag. It should be enough to check that the register is non-zero. Fixes: 889a2cfd889c ("drm/amdgpu/uvd3.1: Don't validate the firmware when already validated") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20261006211607.75407-1-timur.kristof@gmail.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 9dee462c83259ca769aa1bf82228adee9831685c) Cc: stable@vger.kernel.org
9 daysdrm/panthor: fix immortalis conditionErik Faye-Lund
Exactly 10 cores is also valid for an Immortalis configuration, according to the public documentation: https://support.arm.com/compute-ip/immortalis-g715 So let's report this G715 with 10 cores as Immortalis as well, as long as it supports the ray-intersection feature. This matches what we do for more recent GPUs as well. Fixes: 3b1dc21d6d80 ("drm/panthor: Add support for Mali-Gx15 family of GPUs") Signed-off-by: Erik Faye-Lund <erik.faye-lund@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20261014070902.169273-1-erik.faye-lund@arm.com Signed-off-by: Steven Price <steven.price@arm.com>
9 daysdrm/i915/cx0_phy: Fix ARL-S host bridge detectionDnyaneshwar Bhadane
Fix is_arrowlake_s_by_host_bridge() which always returned false. The while loop always exits with pdev as NULL, so the return condition was always false, causing the wrong tx_misc value to be used. Check the host bridge ID inside the loop body. Once found early exit from the loop release the pci reference "pdev" and return true. v2: - Update commit message (Chaitanya) Bspec:74165,74491 Suggested-by: Jani Nikula <jani.nikula@intel.com> Cc: <stable@vger.kernel.org> Fixes: 3630a47b700e ("drm/i915/cx0_phy: Update HDMI TMDS C20 algorithm value") Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Link: https://patch.msgid.link/20260921090226.946472-1-dnyaneshwar.bhadane@intel.com (cherry picked from commit 0507cc5a476af0b6d037b19248bdd20dbe27487d) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
9 daysdrm/i915/dmc: Add sanity check for DMC load addressDibin Moolakadan Subrahmanian
For DMC firmware header version 3, the firmware load address is stored in dmc_info->start_mmioaddr and later used by dmc_load_program(). Unlike the MMIO address table, the firmware load address is not validated. Add a sanity check to ensure it is within the valid range. BSpec: 69671, 68378 Fixes: 3d5928a168a9 ("drm/i915/xelpd: Pipe A DMC plugging") Cc: stable@vger.kernel.org Assisted-by: Claude-Code:Sonnet-5 Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com> Reviewed-by: Mitul Golani<mitulkumar.ajitkumar.golani@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260922133535.3180973-6-dibin.moolakadan.subrahmanian@intel.com (cherry picked from commit 5e47ee5c76ca9becde8df4ad5202845b7ffcbc4c) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
9 daysdrm/i915/dmc: Harden DMC firmware payload parsingDibin Moolakadan Subrahmanian
Validate the conversion of the DMC firmware size from dwords to bytes using check_mul_overflow() before calculating the firmware payload size. Reject zero-length payloads and zero MMIO counts in the DMC firmware header so malformed firmware is caught early. Also set dmc_fw_size only after the payload allocation succeeds. Fixes: eb805623d8b1 ("drm/i915/skl: Add support to load SKL CSR firmware.") Cc: stable@vger.kernel.org Assisted-by: Claude-Code:Sonnet-5 Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com> Reviewed-by: Mitul Golani<mitulkumar.ajitkumar.golani@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260922133535.3180973-5-dibin.moolakadan.subrahmanian@intel.com (cherry picked from commit efde6601a1f1daedfe3dcc2816c934ddb44e3eef) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
9 daysdrm/exec: don't immediately add prelocked obj to array of locked objsChristian König
When a contention is detected the drm_exec object grabs a reference to the contended object, unlocks all other objects and pre-locks the contended one before anything else. The problem is that it is possible that this pre-locked object was about to be destroyed and drm_exec is now holding the last reference to it. So we never actually see this pre-locked object again to be explicitly locked and so also never reserve a slot for a dma_fence object on it. Should the driver now use drm_exec_for_each_locked_object() to add a new fence to all locked objects we eventually see a warning or even a BUG_ON() to prevent random memory corruption. Fix this by keeping the prelocked object out of the array of locked objs until it was explicitly mentioned by the driver again. If the prelocked object is never mentioned again by the driver just unlock and drop the reference at the end of the locking loop. Signed-off-by: Christian König <christian.koenig@amd.com> Reported-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Reviewed-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7") CC: stable@vger.kernel.org # v6.6+ Link: https://lore.kernel.org/r/20261007124657.9664-1-christian.koenig@amd.com
10 daysdrm/virtio: Reset device before deleting virtqueues on freezeYuho Choi
virtgpu_freeze() waits for the control and cursor queues to drain and then deletes the virtqueues, but nothing tells the device to stop first. del_vqs() frees the vring backing, but does not provide a generic device quiesce operation. In particular, modern virtio-pci keeps enabled queues active until the device is reset, so the device is left DRIVER_OK with its queues pointing at memory that has been freed and may be reused while the guest is suspended. virtio_device_restore() only resets the device later, on resume. Reset the device before deleting the virtqueues, the way virtio_gpu_deinit() already does on removal. Fixes: cad6a879a7fb ("drm/virtio: Freeze and restore hooks to support suspend and resume") Cc: stable@vger.kernel.org Signed-off-by: Yuho Choi <oss.patchbox@gmail.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20260926202040.1313385-1-oss.patchbox@gmail.com
10 daysdrm/xe: Bump LRU for external objects on exec and rebindThomas Hellström
The VM's private BOs get their LRU position refreshed in bulk via ttm_lru_bulk_move_tail() on vm->lru_bulk_move, both after a successful non-LR exec and after the LR preempt-fence rebind worker runs. External objects (BOs potentially shared across VMs) are never added to that per-VM bulk move list, so their LRU position is never refreshed by either path. This makes external objects in active use look more evictable than they are. Add xe_vm_bump_lru(), which, under a single lru_lock critical section, performs the bulk move of the VM's private BOs and bumps each external object locked by the drm_exec transaction. Use it from both the non-LR exec path and the LR rebind worker, replacing the open-coded bulk move. Fixes: d490ecf57790 ("drm/xe: Rework xe_exec and the VM rebind worker to use the drm_exec helper") Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Assisted-by: LLM Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20261012132607.21387-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 324ba30cca180c2e1d02090743dd78ccb15b9e4a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
10 daysdrm/xe/oa: Zero OA buffer at allocationBommu Krishnaiah
ttm_bo_type_kernel BOs are not guaranteed to be zeroed on allocation and may contain data from previously freed pages. Since the OA buffer is mmap'able by userspace, this can expose stale kernel memory contents. Streams opened with DRM_XE_OA_PROPERTY_OA_DISABLED allocate the OA buffer without calling xe_oa_init_oa_buffer(). Zero the buffer at allocation to prevent information disclosure through mmap. The existing zeroing in xe_oa_init_oa_buffer() remains necessary for zero report-id/timestamp detection on enable/re-enable. Fixes: 392bf22238ff ("drm/xe/oa/uapi: OA buffer mmap") Assisted-by: LLM Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Ghimiray, Himal Prasad <himal.prasad.ghimiray@intel.com> Signed-off-by: Bommu Krishnaiah <krishnaiah.bommu@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patch.msgid.link/20261006020314.2711762-1-krishnaiah.bommu@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit 126c4c5388f9311a390b9b254a835b0cf0f55331) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
10 daysdrm/xe: skip eviction of a BO with no resourceNiranjana Vishwanathapura
xe_evict_flags() switches on tbo->resource->mem_type to choose an eviction placement. An xe BO can reach eviction with no ttm.resource, e.g. an imported dma-buf BO whose resource was freed during teardown while its attachment is still live: the exporter then invalidates it via xe_dma_buf_move_notify() -> xe_bo_evict(), and the switch dereferences a NULL resource and faults. A BO with no resource has nothing placed or mapped, so there is nothing to evict. Return an empty placement (num_placement = 0), mirroring the handling already used for non-xe scatter-gather BOs just above; ttm_bo_validate() then takes the pipeline-gutting path and returns 0. Without the fix the xe_dma_buf@xe_test_dmabuf_move_notify_no_resource dynamic live selftest will fail with below stack. BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:xe_evict_flags+0xf4/0x140 [xe] Call Trace: <TASK> xe_bo_evict+0x40/0xa0 [xe] ? ttm_bo_pipeline_gutting+0x71/0x180 [ttm] xe_test_dmabuf_move_notify_no_resource+0x182/0x440 [xe] xe_dma_buf_kunit+0x387/0x580 [xe] v2: Add Fixes tag and failure info in commit text (Matt Brost) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Assisted-by: GitHub-Copilot:claude-opus-4.8 Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patch.msgid.link/20261012215014.1495677-5-niranjana.vishwanathapura@intel.com (cherry picked from commit dbcfaac6331f1fcb0c2fe3ad3e9adb1e5d43ec0c) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
11 daysdrm/xe: Don't transfer shrinker pages for pinned bos on purgeable state changeThomas Hellström
Pinned bos have their pages removed from the shrinker's shrinkable / purgeable counts on pin, and added back on unpin according to the bo's purgeable state at that time. However, xe_bo_set_purgeable_shrinker() unconditionally transfers pages between the shrinkable and purgeable counts. If the purgeable state of a pinned bo changes, for example by userspace madvising DONTNEED on a VMA of a bo that is also pinned as a scanout buffer, this underflows one count and, after unpin, leaves the other one permanently inflated. Only update the purgeable flag for pinned bos, and leave the page accounting to unpin. Fixes: 536a2ead3a8f ("drm/xe/bo: Add purgeable shrinker state helpers") Cc: Arvind Yadav <arvind.yadav@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: intel-xe@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v7.1+ Assisted-by: LLM Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20261009070053.7790-1-thomas.hellstrom@linux.intel.com (cherry picked from commit afe6bc012034123fd838328668e609bf57e46bd3) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
11 daysdrm/vc4: hdmi: Move packet RAM enable to PM runtimeDave Stevenson
Audio can be triggered by the HPD handler and start up before video has been restored, calling vc4_hdmi_write_infoframe() for the audio infoframe. vc4_hdmi_write_infoframe() needs Packet RAM to be on to store the infoframe, however, if the video hasn't been enabled, vc4_hdmi_encoder_post_crtc_enable() hasn't been called and therefore, the Packet RAM can be disabled by the time vc4_hdmi_write_infoframe() executes, causing the following splat: [ 201.570266] ------------[ cut here ]------------ [ 201.570293] Packet RAM has to be on to store the packet. [ 201.570367] WARNING: drivers/gpu/drm/vc4/vc4_hdmi.c:683 at vc4_hdmi_write_infoframe+0x404/0x494 [vc4], CPU#0: wireplumber/1606 [...] [ 201.658650] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 201.758499] Call trace: [ 201.760967] vc4_hdmi_write_infoframe+0x404/0x494 [vc4] (P) [ 201.766607] vc4_hdmi_write_audio_infoframe+0x1c/0x28 [vc4] [ 201.772247] write_infoframe+0xbc/0x140 [drm_display_helper] [ 201.777975] drm_atomic_helper_connector_hdmi_update_audio_infoframe+0x80/0xdc [drm_display_helper] [ 201.787140] vc4_hdmi_audio_prepare+0x4ac/0x570 [vc4] [ 201.792252] drm_connector_hdmi_audio_prepare+0x24/0x30 [drm_display_helper] [ 201.799390] hdmi_codec_prepare+0x100/0x160 [snd_soc_hdmi_codec] [ 201.805471] snd_soc_pcm_dai_prepare+0xd4/0x100 [snd_soc_core] [ 201.811375] __soc_pcm_prepare+0x60/0x12c [snd_soc_core] [ 201.816752] soc_pcm_prepare+0x34/0x58 [snd_soc_core] [ 201.821863] snd_pcm_do_prepare+0x70/0x8c [snd_pcm] [ 201.826798] snd_pcm_action_nonatomic+0xe4/0x174 [snd_pcm] [ 201.832350] snd_pcm_prepare+0xc8/0xd8 [snd_pcm] [ 201.837021] snd_pcm_common_ioctl+0x458/0x614 [snd_pcm] [ 201.842308] snd_pcm_ioctl+0x30/0x48 [snd_pcm] [ 201.846802] __arm64_sys_ioctl+0x88/0xd8 [ 201.850769] invoke_syscall+0x48/0xf4 [ 201.854470] el0_svc_common+0x80/0xd8 [ 201.858171] do_el0_svc+0x1c/0x28 [ 201.861520] el0_svc+0x3c/0xb0 [ 201.864605] el0t_64_sync_handler+0x68/0xdc [ 201.868834] el0t_64_sync+0x198/0x19c [ 201.872536] ---[ end trace 0000000000000000 ]--- Considering that Packet RAM enable is essentially a power management configuration, move its enabling/disabling to the Runtime PM hooks. Note that post_crtc_disable() still stops all infoframes, but keeps Packet RAM enabled, leaving it to be disabled by runtime suspend. Link: https://github.com/raspberrypi/linux/issues/7069 Fixes: b47a72f30768 ("drm/vc4: hdmi: Switch to HDMI connector") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20261002-vc4-hdmi-packet-ram-fix-v1-1-3d73148096c9@igalia.com Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
12 daysRevert "drm/virtio: Add pixel blend mode property to cursor plane"Dmitry Osipenko
The cursor blending mode was added twice because the same change was applied by accident from different patches. Revert the second patch. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/dri-devel/ce84d3d2-e78b-4939-aecf-9ef7267bd42a@samsung.com/ Fixes: 6947b78df4d2 ("drm/virtio: Add pixel blend mode property to cursor plane") Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://patch.msgid.link/20261007222244.295186-1-dmitry.osipenko@collabora.com
13 daysMerge tag 'drm-misc-fixes-2026-10-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A pointer assignment fix for gud, a reference fix and a preallocation size fix for imagination, a suspend fix and an allocation fix when idle for vc4, and a hardware variant fix for nouveau. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <self@mripard.dev> Link: https://patch.msgid.link/asjkbknTHg2t8JGy@houat
13 daysMerge tag 'amd-drm-fixes-7.3-2026-10-08' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes amd-drm-fixes-7.3-2026-10-08: amdgpu: - Fix direct scanout alpha on some DRM_FORMATs - UserQ fixes - Fix tearing flips with PSR - GPU reset vblank fix - Debugfs register interface fix - Fix display mode patching - Expand Mac reserved memory workaround amdkfd: - SDMA doorbell fix - Fix dma-buf reference leak in error path Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20261008174658.2506431-1-alexander.deucher@amd.com
13 daysMerge tag 'drm-xe-fixes-2026-10-08' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Fixes on: - i2c removal (Fan) - system Controller Maibox header handling (Mallesh) - two bo pin/unpin accounting bugs (Thomas) - not emitting a w/a twice (Tvrtko) - xe_mmio_wait32() to honor delay/sleep maximums (Alan) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/asfEfgbIjs0GJ-RF@intel.com
2026-10-08drm/nouveau: Skip the Turing CE workaround object for non-GR channelsMary Guillemard
This workaround is here for the old Gallium driver and predate async CE and NVDEC. Instead of only skipping it for NVDEC, let's only apply it in case of GR channels. This should make async CE work properly on Turing by stopping the assign of a GRCE. (here CE0) Signed-off-by: Mary Guillemard <mary@mary.zone> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20261007-turing-async-ce-fix-v1-1-12ee6ccd1a3c@mary.zone
2026-10-08drm/vc4: Fix binner slot allocation failing on an idle GPUMaíra Canal
A job's binner slots are returned to bin_alloc_used by vc4_complete_exec(), which runs from the job_done workqueue, but the seqno vc4_v3d_get_bin_slot() waits on is incremented earlier, in the function vc4_irq_finish_render_job(). Therefore, a waiter can wake, retry, and still find the pool full because the worker has not run. By then, the job might have left the render_job_list, so no seqno remains to wait on and the allocation fails returning -ENOMEM. This scenario can be reproduced on a Raspberry Pi 3 by using a burst of small jobs (e.g. Piglit's `quick_gl` suite), with userspace seeing a rejected submit for a pool about to become free. Note that the slots are held from validation until the render completes, so the pool can also be exhausted by jobs still queued on bin_job_list, leaving render_job_list empty and nothing to wait on. Release the slots from the FRDONE handler and wait on the pool instead of on one job's seqno. This bounds the wait to the actual resource. Also, by claiming the slot inside the wait condition, another submit is unable to take the slot between the wakeup and the retry. vc4_complete_exec() keeps clearing the slots for jobs that never completed, and now wakes the waiters too. Note that the wait takes a deadline, since the two callers need different ones. The submit path is a user task and can be interrupted, so it waits without one. On the other hand, vc4_overflow_mem_work() runs on a worker and never sees a signal, so it needs a deadline. During a reset, vc4_irq_disable() masks V3D_DRIVER_IRQS before draining the worker, and with those masked nothing can release a slot. This deadlocks: the worker would wait for slots that only the reset can free, while the reset waits in cancel_work_sync() for the worker. Fixes: 553c942f8b2c ("drm/vc4: Allow using more than 256MB of CMA memory.") Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260930182204.1877361-1-mcanal@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-10-08drm/vc4: Disable the V3D interrupt across runtime suspendMaíra Canal
vc4_irq_disable() masks the V3D interrupt sources and then calls synchronize_irq() before the V3D is powered down. However, by itself, this is not enough to quiesce the interrupt handler. synchronize_irq() waits for handlers that have already set IRQD_IRQ_INPROGRESS, and for irqchips reporting IRQCHIP_STATE_ACTIVE. A GIC interrupt chip is able to mark an interrupt active as soon as a CPU acknowledges it, so there these checks cover the whole dispatch path. On RPi 0-3, however, the interrupt controller is ARMCTRL, which has no active state. A CPU that has read the hwirq out of the pending register but has not yet reached handle_level_irq() stays invisible to synchronize_irq(). During a power transition, vc4_irq() may therefore run after the power domain is off, where every V3D register read will return 0xdeadbeef. 0xdeadbeef has FLDONE, FRDONE and OUTOMEM set. This problem doesn't trigger NULL pointer dereference issues only because the functions vc4_irq_finish_bin_job() and vc4_irq_finish_render_job() return early when there is no job pointer, but OUTOMEM is still able to schedule vc4_overflow_mem_work() after vc4_irq_disable() has already cancelled it. Therefore, fix the spurious interrupts by disabling the interrupt line across the PM transition. To preserve the enable/disable balance, move vc4_irq_install() and request the IRQ line disabled before the first runtime resume. Fixes: 9b6f461582e6 ("drm/vc4: v3d: Stop disabling interrupts") Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260925191318.541938-1-mcanal@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-10-09Merge tag 'drm-intel-fixes-2026-10-08' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes drm/i915 fixes for v7.3-rc7: - Fix a GT park race that could trigger spurious RPM wakelock warnings - Fix execbuffer relocation cleanup to avoid out-of-bounds free Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/49ac4a9f496e1dadbf71740eb0d1f443598b2632@intel.com
2026-10-08drm/imagination: Size page table preallocation by device addressGyeyoung Baek
Commit 0a8224058a58 ("drm/imagination: Fix page count for page table for map() interface") passed the device address to pvr_mmu_op_context_create(), but the preallocation is still sized from device_addr + sgt_offset with an exclusive end. The offset into the object's pages has no place in a device-virtual range, and the exclusive end allocates one table too many when the range ends on a table boundary. Count the tables from device_addr and the inclusive end of the range. The new calculation does not take page table indices into account. This fixes another issue with the previous implementation, where the difference between start and end indices could underflow when a mapping crossed a page table boundary. This would lead to the driver preallocating a huge number of MMU pages, exhausting system memory and triggering an out of memory panic. Fixes: 0a8224058a58 ("drm/imagination: Fix page count for page table for map() interface") Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Signed-off-by: Gyeyoung Baek <gye976@gmail.com> Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Cc: stable@vger.kernel.org [Alessio: add paragraph to point out OOM bug being fixed, cc stable] Link: https://patch.msgid.link/20261001-pvr-fixes-a-v2-2-f58254e5dfb8@gmail.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-10-08drm/imagination: Fix reference and vm_bo handling in remap()Gyeyoung Baek
When a map overlaps part of an existing mapping, pvr_vm_gpuva_remap() splits the mapping into prev/next parts covering what the request did not take, instead of creating something new. It gets two things wrong. - A GEM reference is taken for each part but it's never needed and never dropped, so it leaks one reference per split (remap-next-in-2m in tests/imagination/pvr_vm_map.c): CRITICAL: 33558528 bytes of shmem still held after close - The parts still belong to the original object being split, but pvr_vm_gpuva_remap() links them to ctx->gpuvm_bo, the new object's vm_bo: prev_va --obj--> BO_A BO_B <--obj-- vm_bo (ctx->gpuvm_bo) \___________link___________/ (mismatch: BO_A != BO_B) drm_gpuva_link() catches the mismatch: WARNING: drivers/gpu/drm/drm_gpuvm.c:2108 at drm_gpuva_link+0x2ec/0x310 drm_WARN_ON(obj != vm_bo->obj) Call trace: drm_gpuva_link pvr_vm_gpuva_remap __drm_gpuvm_sm_map pvr_vm_map pvr_ioctl_vm_map Link them to op->remap.unmap->va->vm_bo instead. The locking of the GPUVA lists of the other objects touched by a split is not addressed here; it is handled by switching the GPUVM to immediate mode. Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Signed-off-by: Gyeyoung Baek <gye976@gmail.com> Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Link: https://patch.msgid.link/20261001-pvr-fixes-a-v2-1-f58254e5dfb8@gmail.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-10-07drm/amdgpu: make Mac FB workaround genericAlex Deucher
Rather than adding a case of every chip where this is seen just check if the FB is at 0 and the ssid is apple. This should cover all chips which fall into this case. Tested-by: Ayhan Çiçek <ayhancicek@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c54e4d10507722398dc90cf3c532e50b86cf425a) Cc: stable@vger.kernel.org
2026-10-07drm/amdkfd: fix dma_buf reference leak in get_dmabuf_infoHaojie Li
When kzalloc fails for metadata_buffer in amdgpu_amdkfd_get_dmabuf_info(), the function returns -ENOMEM directly without calling dma_buf_put(), leaking the dma_buf reference obtained earlier via dma_buf_get(). Fix both issues by: - Adding an error check after the first amdgpu_bo_get_metadata() call - Replacing the direct return with r = -ENOMEM and goto out_put to ensure dma_buf_put() is called on all error paths Fixes: f54ce9e8cbd3 ("drm/amdkfd: Let driver decide buffer size at AMDKFD_IOC_GET_DMABUF_INFO ioctl") Signed-off-by: Haojie Li <lihaojie@kylinos.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ffa699553332f8caf8688d312279ddcea9e3c141) Cc: stable@vger.kernel.org
2026-10-07drm/amd/display: Don't replace a sink mode that shares the native totalsAdrian Betschart
decide_crtc_timing_for_drm_display_mode() copies the native mode's CRTC timing into the requested mode when clock, htotal and vtotal match. That is meant for the modes amdgpu inserts itself: amdgpu_dm_create_common_mode() duplicates the native mode and changes only hdisplay and vdisplay, so those are sent with the native timing and scaled. A sink can also offer a real mode with the same clock and totals as its native mode. CTA-861 VIC 102 (4096x2160@60) and VIC 97 (3840x2160@60) both use 594 MHz and 4400x2250. With 3840x2160@60 as the preferred mode, a 4096x2160@60 request goes out with the 3840x2160 timing and the framebuffer scaled into it (dst 3840x2025 at y=67), while the AVI InfoFrame still carries VIC 102. A JVC projector then reports 3840x2160 and shows a corrupted right edge. 4096x2160@24, whose totals differ, is sent and displayed correctly. Inserted modes keep the native sync positions; a real mode with its own active width does not. Compare those too, so only inserted modes are patched. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Signed-off-by: Adrian Betschart <adrian.betschart@cinemaone.ch> Assisted-by: Claude-Code:claude-opus-5-5 Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 22f9a2da101c37f821cd00954f81dc598754f4d5) Cc: stable@vger.kernel.org
2026-10-07drm/amdkfd: align SDMA doorbell base for shader doorbell writesSaleel Kudchadker
On GC 9.4.3, 9.4.4 and 9.5.0, doorbell writes issued from shaders are routed to an SDMA engine at 32-byte (4 doorbell index) granularity. SDMA engine doorbell ranges are 10 indices apart, so the range of every odd engine starts 2 indices into a 4-index block that begins in the previous engine's range. A shader ringing the doorbell of a queue on an odd engine therefore rings the previous engine instead. The intended queue never sees the doorbell, so its work stalls and the application hangs. Align the per-engine doorbell base up to a 4-index boundary on these ASICs. Each engine only uses 4 of its 10 indices, so the aligned base plus the queue offset stays within the engine's range. Even engines are already aligned, so only the doorbell IDs of odd-engine queues change. Only doorbells rung by the device itself are routed this way. Doorbell writes from the host, including the kernel's own SDMA rings, are not affected. The doorbell ID of an SDMA queue is saved in CRIU checkpoints and checked again on restore. A checkpoint taken before this change that contains an SDMA queue on an odd engine will fail to restore with -EINVAL. This is intentional: the restored process still holds the old doorbell address, so accepting the stale ID would bring back the same stall. Tested on MI300X with a shader-rung SDMA doorbell test: queues on odd engines hung before this change and complete with it. v2: use u32 instead of uint32_t for the new locals (checkpatch) v3: name the routing granularity, use dev->node_id, document the layout invariants, describe impact v4: express the granularity in doorbell indices, drop unrelated cleanups, explain the CRIU restore behavior, add test note Fixes: 6df442a03d1a ("drm/amdgpu: add new doorbell assignment table for aqua_vanjaram") Signed-off-by: Saleel Kudchadker <Saleel.Kudchadker@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ee1379e6d7da47bdf7a8d5b89c2d1b28473701fb) Cc: stable@vger.kernel.org
2026-10-07drm/amdgpu: copy debugfs register data outside the GRBM/SRBM locksMikhail Gavrilov
Reading or writing a register through the amdgpu_regs2 debugfs file with GRBM bank selection, which umr does for every banked access (a single "umr -b x x x -r <reg>" is enough, as is the wave dump with "-O halt_waves"), makes lockdep report a circular locking dependency, after which lockdep stays off until reboot: WARNING: possible circular locking dependency detected umr/63306 is trying to acquire lock: ffff8882cf4b8350 (&mm->mmap_lock){++++}-{4:4}, at: __might_fault+0x9b/0x140 but task is already holding lock: ffff8881aec010d0 (&amdgpu_grbm_lock_key){+.+.}-{4:4}, at: amdgpu_debugfs_regs2_op.isra.0+0x20d/0xd00 [amdgpu] ... Chain exists of: &mm->mmap_lock --> &amdgpu_srbm_lock_key --> &amdgpu_grbm_lock_key ... __might_fault+0xc5/0x140 amdgpu_debugfs_regs2_op.isra.0+0x441/0xd00 [amdgpu] full_proxy_write+0x10e/0x1d0 vfs_write+0x1d0/0xf50 ksys_write+0x116/0x250 amdgpu_debugfs_regs2_op() and amdgpu_debugfs_process_reg_op() call get_user()/put_user() for every dword while holding grbm_idx_mutex or srbm_mutex, and pm.mutex if requested, so a fault there takes mmap_lock inside those locks. The lock hierarchy in amdgpu_lockdep.c puts srbm_mutex and grbm_idx_mutex below notifier_lock, which amdgpu_cs_submit() takes with the BO reservations held, and dma_resv_lockdep() orders the reservations inside mmap_lock. So mmap_lock is outside grbm_idx_mutex and srbm_mutex, and these two debugfs paths nest it the other way round. The copies under the locks are as old as the bank selection in both files; commit 1d0f5838b126 ("drm/amdgpu: Add lockdep annotations for lock ordering validation") only made them visible to lockdep. Copy the user buffer in before any of the locks is taken and the result out after all of them are dropped, as amdgpu_debugfs_wave_read(), amdgpu_debugfs_gpr_read() and amdgpu_debugfs_gprwave_read() already do. The buffer is sized by the count passed to read() or write(), so an access larger than PAGE_SIZE is now rejected with -EINVAL; umr reads and writes one register at a time. A fault on the user buffer of a write now fails with -EFAULT before any register is written, instead of after a partial write. Fixes: 566281595037 ("drm/amd/amdgpu: Add bank selection for MMIO debugfs (v3)") Fixes: 37df9560cd3e ("drm/amd/amdgpu: New debugfs interface for MMIO registers (v5)") Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ccf9e35ed6811f2c25ba6368e7dc6481da17159d) Cc: stable@vger.kernel.org
2026-10-07drm/amdgpu: serialize vblank counter reads against GPU resetVitaly Prosyak
The vblank counter callback reads display registers and scanout position without holding reset_domain->sem. During GPU recovery, display commit work can call the callback while reset owns the semaphore for writing. The hardware access then triggers the lockdep_assert_held() in amdgpu_device_skip_hw_access() and sets TAINT_WARN when lockdep is enabled. Try to acquire the reset semaphore for reading before accessing the hardware, and hold it across the counter and scanout-position reads. If reset is already in progress, return DRM's cached software vblank count instead. This avoids blocking behind reset and avoids accessing display hardware while it is being reset. The cached count is less accurate than the hardware count, but is used only when reset prevents a safe hardware read. This addresses the reset-time warning from this vblank path; it does not suppress or fix unrelated lockdep warnings. Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Sunpeng Li <sunpeng.li@amd.com> Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Reviewed-by: Sunpeng Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 51a4359f7431a4be5e42803c8bdaf7e0e5be2934) Cc: stable@vger.kernel.org