summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-06-04leds: trigger: netdev: don't recurse on the netdev ops lockJakub Kicinski
get_device_state() calls __ethtool_get_link_ksettings() on the trigger's netdev, which will soon take the dev's ops lock. Three of its callers already hold that lock and one doesn't, so the function would either deadlock or run unprotected depending on the path. Make get_device_state() expect the dev's ops lock held and switch to netif_get_link_ksettings(): * netdev_trig_notify() NETDEV_UP / NETDEV_CHANGE / NETDEV_CHANGENAME arrive with the dev's ops lock held (per netdevices.rst). * set_device_name() does not hold the lock, take it explicitly. Due to lock ordering we need to reshuffle the code in set_device_name() a little bit. We need to find the device earlier on, so that we can lock it before we take trigger_data->lock. Link: https://patch.msgid.link/20260603012840.2254293-10-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04net: sched: don't recurse on the netdev ops lock in qdiscsJakub Kicinski
cbs_set_port_rate() and taprio_set_picos_per_byte() are reached from two paths and both already hold the device's ops lock: *_change(), via tc_modify_qdisc() which calls netdev_lock_ops(dev) before dispatching to the qdisc ops. *_dev_notifier() on NETDEV_UP / NETDEV_CHANGE, where caller holds the ops lock across the notifier chain. Switch to netif_get_link_ksettings() to avoid deadlock once __ethtool_get_link_ksettings() starts taking the netdev lock. Link: https://patch.msgid.link/20260603012840.2254293-9-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04net: bridge: don't recurse on the port's netdev ops lockJakub Kicinski
port_cost() calls __ethtool_get_link_ksettings() on the port device, which will soon take the port's ops lock. br_port_carrier_check() is reached via the NETDEV_CHANGE notifier from linkwatch, which already holds the port's ops lock, so the call would deadlock. Make port_cost() expect the port's ops lock held and switch to netif_get_link_ksettings(). The only other caller is new_nbp(), make sure it takes the lock explicitly. Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260603012840.2254293-8-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04net: team: don't recurse on the port's netdev ops lockJakub Kicinski
__team_port_change_send() calls __ethtool_get_link_ksettings() on the port, which will soon take the port's ops lock. The notifier caller already holds it while the slave-add/del callers do not, so the function would either deadlock or run unprotected depending on the path. Make __team_port_change_send() expect the port's ops lock held and switch to netif_get_link_ksettings(). team_device_event()'s NETDEV_UP / NETDEV_CHANGE already arrive with the port's ops lock held. team_port_add() now take it explicitly. Note that NETDEV_DOWN and team_port_del() will pass false as @linkup so they will not execute netif_get_link_ksettings(). This is fortunate as NETDEV_DOWN has somewhat mixed locking right now. Link: https://patch.msgid.link/20260603012840.2254293-7-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04net: bonding: don't recurse on the slave's netdev ops lockJakub Kicinski
bond_update_speed_duplex() calls __ethtool_get_link_ksettings() on the slave, which will soon take the slave's ops lock. One of its callers already holds it and the other three don't, so the function would either deadlock or run unprotected depending on the path. Make the helper expect the slave's ops lock held and switch to netif_get_link_ksettings(). Wrap the three call sites that don't already hold it: * bond_enslave() (rtnl held; core drops the lower's ops lock around ->ndo_add_slave). * bond_miimon_commit() (rtnl_trylock'd from the mii workqueue). * bond_ethtool_get_link_ksettings() (rtnl held via ethtool layer, bond device itself is not ops locked). The call site which does already hold the ops lock is bond_slave_netdev_event() via NETDEV_UP / NETDEV_CHANGE notifiers, so it stays as-is. Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Link: https://patch.msgid.link/20260603012840.2254293-6-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04net: ethtool: add netif_get_link_ksettings() for correct ops-locked useJakub Kicinski
__ethtool_get_link_ksettings() is exported and called from sysfs and many drivers. It invokes ethtool_ops->get_link_ksettings so by our own docs it should be holding netdev lock for ops locked devices. Looks like commit 2bcf4772e45a ("net: ethtool: try to protect all callback with netdev instance lock") missed adding the ops lock here. There's a number of callers we need to fix up so let's add the netif_get_link_ksettings() helper first, without any actual locking changes (this commit is a nop). Not treating this as a fix because I don't think any driver cares at this point, but if we want to remove the rtnl_lock protection this will become critical. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260603012840.2254293-5-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04net: document NETDEV_CHANGENAME as ops lockedJakub Kicinski
NETDEV_CHANGENAME is only emitted from netif_change_name(). netif_change_name() has two callers both of which hold netdev_lock_ops() around the call site: - dev_change_name() - do_setlink() Document NETDEV_CHANGENAME as always ops locked. Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260603012840.2254293-4-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04net: ethtool: cmis_cdb: hold instance lock for ops locked devicesJakub Kicinski
FW module flashing was written so that the flashing happens without holding rtnl_lock. This allows flashing multiple modules at once. Current drivers can handle that well, but we should let drivers depend on the netdev instance lock. Instance lock is per netdev, and so is the module so we won't break parallel updates. Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260603012840.2254293-3-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04net: rename netdev_ops_assert_locked()Jakub Kicinski
Jakub suggests renaming the existing assert to match the netdev_lock_ops_compat() semantics. We want netdev_assert_locked_ops() to mean - if the driver is ops locked - check that it's holding the device lock. The existing helper check for either ops lock or rtnl_lock, which is the locking behavior of netdev_lock_ops_compat(). The reason for naming divergence is likely that netdev_ops_assert_locked() predated the _compat() helpers. Suggested-by: Jakub Sitnicki <jakub@cloudflare.com> Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260603012840.2254293-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04perf sched: Fix comp_cpus heap overflow with cross-machine recordingsArnaldo Carvalho de Melo
setup_map_cpus() allocates comp_cpus based on sysconf(_SC_NPROCESSORS_CONF), the host machine's CPU count. But map_switch_event() indexes comp_cpus using cpus_nr derived from bitmap_weight(comp_cpus_mask, MAX_CPUS), where comp_cpus_mask is declared as DECLARE_BITMAP(..., MAX_CPUS) with MAX_CPUS=4096. When analyzing a perf.data recording from a machine with more CPUs than the analysis host (e.g. 128-CPU server recording analyzed on an 8-CPU laptop), cpus_nr exceeds the allocation size, causing a heap buffer overflow. Also fix a type mismatch: comp_cpus is 'struct perf_cpu *' (2 bytes per element) but was allocated with sizeof(int) (4 bytes per element). Allocate comp_cpus with MAX_CPUS entries using the correct element size, matching the comp_cpus_mask bitmap bounds. Remove the sysconf(_SC_NPROCESSORS_CONF) initialization of max_cpu — its only consumer was the comp_cpus allocation, and max_cpu is dynamically updated from the recording's events during processing. Fix the non-compact path to use max_cpu.cpu + 1 as cpus_nr, converting from 0-based index to count — sysconf() returned a count which masked this off-by-one. Fixes: 99623c628f54 ("perf sched: Add compact display option") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-06-04Merge tag 'trace-v7.1-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fix from Steven Rostedt: - Fix CFI violation in probestub function The probestub is a function to allow tprobes to hook to a tracepoint to gain access to its parameters. The function itself is only referenced by the tracepoint structure which lives in the __tracepoint section. objtool explicitly ignores that section and when processing functions in the kernel, if it detects one that has no references it will seal it to have its ENDBR stripped on boot up. This means the probstub function will have its ENDBR stripped and if a tprobe is attached to it with IBT enabled, it will go *boom*. * tag 'trace-v7.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing: Fix CFI violation in probestub being called by tprobes
2026-06-04perf sched: Fix NULL dereference in latency_runtime_eventArnaldo Carvalho de Melo
latency_runtime_event() passes the return value of machine__findnew_thread() directly to thread_atoms_search() at line 1216, before checking for NULL at line 1220. thread_atoms_search() calls pid_cmp() which dereferences the thread pointer via thread__tid(), causing a NULL pointer dereference if the allocation fails. All other callers of thread_atoms_search() in this file (latency_switch_event, latency_wakeup_event, latency_migrate_task_event) correctly check for NULL first. Move the atoms assignment after the NULL check to match the pattern used by the other callers. Fixes: b91fc39f4ad7 ("perf machine: Protect the machine->threads with a rwlock") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-06-04perf sched: Fix thread reference leak in latency_switch_eventArnaldo Carvalho de Melo
In latency_switch_event(), after acquiring thread references for sched_out and sched_in via machine__findnew_thread(), the first add_sched_out_event() failure path does 'return -1', bypassing the out_put label that calls thread__put() on both references. The second and third add_sched_out_event() failures correctly use 'goto out_put'. Fix the first one to match. Fixes: b91fc39f4ad7 ("perf machine: Protect the machine->threads with a rwlock") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-06-04perf tools: Guard test_bit from out-of-bounds sample CPUArnaldo Carvalho de Melo
When PERF_SAMPLE_CPU is absent from a perf.data file, sample->cpu is initialized to (u32)-1 by evsel__parse_sample(). Five call sites pass this value directly to test_bit(sample->cpu, cpu_bitmap), reading massively out of bounds past the DECLARE_BITMAP(..., MAX_NR_CPUS) allocation of 4096 bits. Add a sample->cpu >= MAX_NR_CPUS guard before each test_bit() call, matching the existing safe pattern in builtin-kwork.c. This catches both the (u32)-1 sentinel and any corrupted CPU value exceeding the bitmap size. Fixes: 5d67be97f890 ("perf report/annotate/script: Add option to specify a CPU range") Cc: Anton Blanchard <anton@samba.org> Reported-by: sashiko-bot <sashiko-bot@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-06-04perf lock contention: Enable end-timestamp accounting for cgroup aggregationSuchit Karunakaran
update_lock_stat() handles lock contentions that start but never reach a contention_end event (e.g., locks still held when profiling stops), but previously treated LOCK_AGGR_CGROUP as a no-op due to missing cgroup context in userspace. Fix this by adding a cgroup_id field to struct tstamp_data, recording it at contention_begin using get_current_cgroup_id() when aggr_mode is LOCK_AGGR_CGROUP. Capturing it at contention_begin is semantically correct, the contention cost is incurred by the task that had to wait, not by whatever task happens to be running at contention_end. It is also preferable from a performance standpoint, as contention_end runs just before the task enters the critical section. Update contention_end to use pelem->cgroup_id instead of calling get_current_cgroup_id() dynamically, ensuring both complete and incomplete contention events attribute the wait time to the cgroup at wait-start time consistently. Reviewed-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Suchit Karunakaran <suchitkarunakaran@gmail.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tycho Andersen (AMD) <tycho@kernel.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-06-04perf pmu: Recognize 'default_core' as a core PMU and document matchingIan Rogers
The is_pmu_core function checks if a PMU name corresponds to a core CPU PMU. However, it currently fails to recognize "default_core" as a core PMU. When "default_core" is used, the PMU scanning fallback in pmus.c scans the "other_pmus" list. This scan is slow and always misses because "default_core" is a core PMU, leading to unnecessary overhead. Update is_pmu_core to recognize "default_core" directly. Additionally, document the different matching approaches (exact name for x86/s390, sysfs-based cpus file check for ARM/hybrid) to clarify how core PMUs are classified. Also, explicitly treat "default_core" as `all_pmus` in `setup_metric_events()` to preserve the original metric resolution behavior for this pseudo-PMU. Assisted-by: Gemini-CLI:Google Gemini 3.1 Pro Signed-off-by: Ian Rogers <irogers@google.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-06-04perf data ctf: replace libbabeltrace with babeltrace2-ctf-writerMichael Jeanson
The 1.x branch of Babeltrace has been superseded by 2.x in 2020 and has been unmaintained since 2022, efforts have started to remove it from popular distributions. Babeltrace 2.x offers a very similar 'ctf-writer' library that can be used with minimal changes for the '--to-ctf' feature and has been packaged since Debian 11 and Fedora 32. This patch replaces the 'libbabeltrace' build feature with 'babeltrace2-ctf-writer' using pkgconfig detection, adjusts the naming of the public headers and applies minor API cleanups. There is no changes to the output ctf traces, the ctf-writer API still implements version 1.8 of the CTF specification that can be read by either Babeltrace 1 / 2 or any CTF compliant reader. Also remove some ifdefs in the cli option parsing to allow printing the helpful error message with '--to-ctf' when built without babeltrace2. Reviewed-by: Ian Rogers <irogers@google.com> Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Derek Foreman <derek.foreman@collabora.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-06-04perf lock contention: Allow 'mmap_lock' in -L/--lock-filterNamhyung Kim
The -L/--lock-filter option is to specify target locks by name or address. It's basically for global locks where name or address is known and fixed. But 'mmap_lock' is a per-process lock so it cannot be used for the -L option. $ sudo perf lock con -ab -L mmap_lock ignore unknown symbol: mmap_lock libbpf: map 'addr_filter': failed to create: -EINVAL libbpf: failed to load BPF skeleton 'lock_contention_bpf': -EINVAL Failed to load lock-contention BPF skeleton lock contention BPF setup failed However, it's still a common source of contention especially in a large process so we want to use it for the -L/--lock-filter option. As there is check_lock_type() to check mmap_lock at runtime, let's used it to filter mmap_locks as a special case. Of course, this only works with -b/--use-bpf option. $ sudo perf lock con -b -L mmap_lock -- perf bench mem mmap -f demand -t 2 # Running 'mem/mmap' benchmark: # function 'demand' (Demand loaded mmap()) # Copying 1MB bytes ... 2.679184 GB/sec/thread ( +- 1.78% ) contended total wait max wait avg wait type caller 1 15.22 us 15.22 us 15.22 us rwsem:W __vm_munmap+0x7e 1 7.72 us 7.72 us 7.72 us rwsem:R lock_mm_and_find_vma+0x97 Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: James Clark <james.clark@linaro.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Suchit Karunakaran <suchitkarunakaran@gmail.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-06-04rust: sync: add #[must_use] to GlobalGuard and GlobalLock::try_lockAshutosh Desai
Guard is marked #[must_use] since dropping it releases the lock. GlobalGuard wraps Guard with identical semantics but was missing the annotation, so discarding it would silently compile without warning. Similarly, GlobalLock::try_lock was missing #[must_use]. Option<T> does not propagate #[must_use] from T, so the attribute needs to be on the function directly - same reason Lock::try_lock has it. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260502160057.3402896-1-ashutoshdesai993@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-06-04drm/amd/display: Consult MCCS FreeSync cap only if requested & supportedMichel Dänzer
When the do_mccs parameter is false, we don't call dm_helpers_read_mccs_caps, so sink->mccs_caps.freesync_supported is unlikely to be true. Fixes: 6f71d5dd3206 ("drm/amd/display: Read sink freesync support via mccs") Bug: https://gitlab.freedesktop.org/drm/amd/-/work_items/5286 Signed-off-by: Michel Dänzer <mdaenzer@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 115bf5ca318e18a3dc1888ec6271c7052774952a)
2026-06-04drm/amdkfd: Unwind debug trap enable on copy_to_user failureYongqiang Sun
If kfd_dbg_trap_enable() fails while copying runtime_info to userspace, it had already activated the trap, set debug_trap_enabled, taken an extra process reference, and opened the debug event file. Return -EFAULT without unwinding that state, leaving inconsistent trap state and a refcount imbalance that could break later DISABLE/ENABLE. On copy_to_user failure, deactivate the trap and undo the rest of the enable setup before returning. Signed-off-by: Yongqiang Sun <Yongqiang.Sun@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 01112e241e37f9ac98b6f418d93ce2e0b87b7ee0)
2026-06-04drm/amdkfd: Add bounds check for AMDKFD_IOC_WAIT_EVENTSSunday Clement
The kfd_wait_on_events ioctl passes a user-supplied num_events parameter directly to alloc_event_waiters() which calls kcalloc() without validation. This allows unprivileged users with /dev/kfd access to trigger large kernel memory allocations, potentially causing memory exhaustion and denial of service via the OOM killer. Add a check to reject num_events values exceeding KFD_SIGNAL_EVENT_LIMIT (4096), which is the maximum number of events a single process can create. Signed-off-by: Sunday Clement <Sunday.Clement@amd.com> Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 39eb6da7acee8d0cc12a8959235b590f295d7b4c)
2026-06-04drm/amdgpu: restart the CS if some parts of the VM are still invalidatedChristian König
Make sure that we only submit work with full up to date VM page tables. Backport to 7.1 and older. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 59720bfd8c6dbebeb8d5a7ab64241b007efd9213) Cc: stable@vger.kernel.org
2026-06-04drm/amdgpu/userq: Fix reading timeline points in wait ioctlDavid Rosca
Use correct u64 type. Signed-off-by: David Rosca <david.rosca@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 0ac98160dfb6ab3c6d7b38e0ff9687780beed9cb)
2026-06-04drm/amdkfd: fix SMI event cross-process information leakYongqiang Sun
kfd_smi_ev_enabled() skips the suser privilege check when pid=0. PROCESS_START, PROCESS_END, and VMFAULT events are emitted with pid=0 while carrying another process's PID and command name, so any /dev/kfd user in the render group can monitor all GPU workloads. Pass the target process PID into kfd_smi_event_add() for these events so the existing per-client filter restricts delivery to the owning process or CAP_SYS_ADMIN subscribers. Signed-off-by: Yongqiang Sun <Yongqiang.Sun@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 92a8dba246d371fe268280e5fd74b0955688e6df)
2026-06-04of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array() failsWandun Chen
The global pointer 'reserved_mem' continues to reference the reserved_mem_array which lives in __initdata if alloc_reserved_mem_array() fails. of_reserved_mem_lookup() is exported for post-init use, that would dereference freed memory and trigger a use-after-free. So reset reserved_mem_count to 0 when alloc_reserved_mem_array() fails. Fixes: 00c9a452a235 ("of: reserved_mem: Add code to dynamically allocate reserved_mem array") Signed-off-by: Wandun Chen <chenwandun@lixiang.com> Link: https://patch.msgid.link/20260604015332.3669384-1-chenwandun1@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-06-04drm/amdkfd: always resume_all after suspend_allAlex Deucher
Need to restore any good queues even if the suspend_all failed for some. Always run remove_queue as that will schedule a GPU reset is removing the queue fails. v2: move resume_all after remove Fixes: eb067d65c33e ("drm/amdkfd: Update BadOpcode Interrupt handling with MES") Reviewed-by: Amber Lin <Amber.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdgpu/gfx: move fault and EOP IRQ get/put to hw_init/hw_finiYunxiang Li
priv_reg / priv_inst / bad_op and (on v11+) userq EOP IRQs are acquired in late_init but released in hw_fini. This split forced gfx_v9_0_hw_fini() to defensively guard each put with amdgpu_irq_enabled() because hw_fini runs on paths that may not reach late_init. amdgpu_ip_block_hw_fini() only runs after hw_init returns success, and suspend / resume cycle the refs through the same path, so hw_init / hw_fini pair without any extra tracking. Move the gets there and drop the guards. While here, fix the pre-existing partial-failure leak in set_userq_eop_interrupts() (gfx11 / 12_0 / 12_1). amdgpu_irq_get() increments the refcount before calling .set, so a failure partway through the loop leaves earlier successful gets stranded. Track the loop position and roll back on the enable path. Signed-off-by: Yunxiang Li <Yunxiang.Li@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04Merge tag 's390-7.1-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Alexander Gordeev: - Enable IOMMUFD and VFIO cdev such that PCI pass-through to QEMU/KVM can optionally utilize native IOMMUFD - With HAVE_ARCH_BUG_FORMAT enabled the BUG infrastructure might misinterpret flags or fault. Fix this by moving the "format" field emission into __BUG_ENTRY() - The generic version of _THIS_IP_ is known to be brittle and may break with current and future GCC and Clang optimizations. Fix it by overriding _THIS_IP_ * tag 's390-7.1-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390: Implement _THIS_IP_ using inline asm s390/bug: Always emit format word in __BUG_ENTRY s390/configs: Enable IOMMUFD and VFIO cdev in defconfigs
2026-06-04drm/amd/display: Consult MCCS FreeSync cap only if requested & supportedMichel Dänzer
When the do_mccs parameter is false, we don't call dm_helpers_read_mccs_caps, so sink->mccs_caps.freesync_supported is unlikely to be true. Fixes: 6f71d5dd3206 ("drm/amd/display: Read sink freesync support via mccs") Bug: https://gitlab.freedesktop.org/drm/amd/-/work_items/5286 Signed-off-by: Michel Dänzer <mdaenzer@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amd/pm: Use strscpy in profile mode parsingLijo Lazar
Use strscpy to copy the buffer which makes it explicit that a valid NULL terminated string gets copied. Also, make it explicit that the source buffer can be copied safely to the temporary buffer by checking against its size. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdkfd: Fix infinite loop parsing CRAT with zero subtype lengthYongqiang Sun
Malformed ACPI CRAT tables can advertise a zero or undersized subtype length. The parser then fails to advance the cursor and loops forever while the remaining image still looks large enough for a generic header. Validate sub_type_hdr->length on each iteration before parsing or advancing. Return -EINVAL and warn when length is zero or smaller than the generic subtype header. Signed-off-by: Yongqiang Sun <Yongqiang.Sun@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdkfd: fix sysfs topology prop length on buffer truncationYongqiang Sun
sysfs_show_gen_prop() accumulated snprintf()'s return value into the offset. snprintf() reports bytes that would have been written, not bytes actually written, so a truncated sysfs show could over-report its length. Use sysfs_emit_at(), which returns only the bytes written. Signed-off-by: Yongqiang Sun <Yongqiang.Sun@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdgpu: drop retry loop in amdgpu_hmm_range_get_pagesHonglei Huang
Since commit c08972f55594 ("drm/amdgpu: fix amdgpu_hmm_range_get_pages") moved mmu_interval_read_begin() out of the per-chunk loop, the captured notifier_seq is no longer refreshed across retries. As a result, the existing -EBUSY retry path can never make progress: hmm_range_fault() returns -EBUSY only when mmu_interval_check_retry(notifier, notifier_seq) reports that the sequence is stale. Once the sequence has advanced, the stored seq will never match again, so every subsequent call within the same invocation returns -EBUSY immediately. The "goto retry" therefore degenerates into a busy spin that simply burns CPU for the full HMM_RANGE_DEFAULT_TIMEOUT (~1s) window before finally bailing out with -EAGAIN. This is pure latency with no chance of recovery, and it actively hurts the KFD userptr stack: the caller ends up blocked for a second while holding mmap_lock, only to return -EAGAIN to the restore worker (or to userspace) which would have re-driven the operation immediately anyway. Drop the retry/timeout entirely and let -EBUSY propagate straight to out_free_pfns, where it is already translated to -EAGAIN. Recovery is handled at a higher level: the KFD restore_userptr_worker reschedules itself, and the userptr ioctl path returns -EAGAIN to userspace. No functional regression: the previous behaviour on -EBUSY was already to fail with -EAGAIN after a 1s stall; we just skip the stall. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amd/pm: bound OD parameter parsing to stack array sizeCandice Li
Reject inputs once parameter_size reaches the array limit, and pass ARRAY_SIZE(parameter) into parse_input_od_command_lines() for defense in depth. Signed-off-by: Candice Li <candice.li@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amd/pm: Stop pp_od_clk_voltage emit at PAGE_SIZEAsad Kamal
Stop appending OD sections in amdgpu_get_pp_od_clk_voltage() once the sysfs page is full, instead of checking every sysfs_emit_at() in SMU helpers. This is purely defensive hardening. v2: Drop the prior series that checked sysfs_emit_at() return values in every SMU *_emit_clk_levels() helper and smu_cmn_print_*().(Kevin) v3: Update description, remove all clamping Signed-off-by: Asad Kamal <asad.kamal@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdkfd: Unwind debug trap enable on copy_to_user failureYongqiang Sun
If kfd_dbg_trap_enable() fails while copying runtime_info to userspace, it had already activated the trap, set debug_trap_enabled, taken an extra process reference, and opened the debug event file. Return -EFAULT without unwinding that state, leaving inconsistent trap state and a refcount imbalance that could break later DISABLE/ENABLE. On copy_to_user failure, deactivate the trap and undo the rest of the enable setup before returning. Signed-off-by: Yongqiang Sun <Yongqiang.Sun@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdgpu: validate the mes firmware version for gfx12.1Sunil Khatri
MES firmware should report the same version whether read from the register or from the firmware ucode binary. This is not always the case, so add a log when they mismatch. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdgpu: validate the mes firmware version for gfx12Sunil Khatri
MES firmware should report the same version whether read from the register or from the firmware ucode binary. This is not always the case, so add a log when they mismatch. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdgpu: compare MES firmware version ucode for gfx11Sunil Khatri
MES firmware should report the same version whether read from the register or from the firmware ucode binary. This is not always the case, so add a log when they mismatch. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdkfd: Add bounds check for AMDKFD_IOC_WAIT_EVENTSSunday Clement
The kfd_wait_on_events ioctl passes a user-supplied num_events parameter directly to alloc_event_waiters() which calls kcalloc() without validation. This allows unprivileged users with /dev/kfd access to trigger large kernel memory allocations, potentially causing memory exhaustion and denial of service via the OOM killer. Add a check to reject num_events values exceeding KFD_SIGNAL_EVENT_LIMIT (4096), which is the maximum number of events a single process can create. Signed-off-by: Sunday Clement <Sunday.Clement@amd.com> Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdgpu: restart the CS if some parts of the VM are still invalidatedChristian König
Make sure that we only submit work with full up to date VM page tables. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amd/display: use unsigned types for local pipe and REG_GET countersAurabindo Pillai
Two small type fixes that match how the values are actually consumed: - decide_zstate_support() iterates from 0 to pipe_count, which is unsigned. Make the loop index unsigned int. - hpo_enc401_read_state() reads HDMI_PIXEL_ENCODING and HDMI_DEEP_COLOR_DEPTH via REG_GET_2(), which internally casts the output pointer to (uint32_t *). Passing the address of an int is a strict-aliasing wart even when the sizes match. Declare the locals as uint32_t. No behavioural change since the values are only compared against small non-negative constants. Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amd/display: widen dc_hdmi_frl_flags.force_frl_rate to unsigned intAurabindo Pillai
dc_hdmi_frl_flags.force_frl_rate mirrors dc_debug_options.force_frl_rate, which was just widened to unsigned int. Match the type here too so the assignment in link_hdmi_frl.c does not narrow from unsigned to signed. All call sites in link_hdmi_frl.c only compare the value against 0, 0xF, or an hdmi_frl_link_rate enum whose values are non-negative, so the change is behaviour-preserving and does not introduce sign-compare warnings. Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdgpu/userq: Fix reading timeline points in wait ioctlDavid Rosca
Use correct u64 type. Signed-off-by: David Rosca <david.rosca@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdgpu/vcn5.0.0: enable secure submission on unified ring for VCN 5.3.0Jeevana Muthyala
Enable secure submission support on the unified ring for VCN IP version 5.3.0 by setting `secure_submission_supported = true` in vcn_v5_0_0_unified_ring_vm_funcs. Secure IB submission is supported on VCN 5.3.0 hardware/firmware, allowing protected decode workloads to bypass the common IB gate. Without this, secure playback submissions can be blocked and fail. Other VCN 5.x variants using the same vcn_v5_0_0_ip_block (e.g. IP_VERSION(5, 0, 0)) do not support secure submission on the unified ring and therefore continue using non-secure paths. This change only advertises existing hardware/firmware capability; non-secure decode paths remain unaffected. Signed-off-by: Jeevana Muthyala <Jeevana.Muthyala2@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdgpu: deprecate guilty handlingChristian König
The guilty handling tried to establish a second way of signaling problems with the GPU back to userspace. This caused quite a bunch of issue we had to work around, especially lifetime issues with the drm_sched_entity. Just drop the handling altogether and use the dma_fence based approach instead. v2: fix reversed condition in entity check (Alex) Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdgpu: Add lockdep annotations for lock ordering validationVitaly Prosyak
Add lockdep annotations to teach lockdep the correct lock hierarchy and catch ordering violations during development. This follows the pattern established by dma-resv in drivers/dma-buf/dma-resv.c. Lock ordering hierarchy (outermost to innermost): 1. userq_sch_mutex - Global userq scheduler (enforce_isolation) 2. userq_mutex - Per-context userq (held across queue create/destroy) 3. notifier_lock - MMU notifier synchronization 4. vram_lock - VRAM memory allocator 5. reset_domain->sem - GPU reset synchronization 6. reset_lock - Reset control mutex 7. srbm_mutex - SRBM register access 8. grbm_idx_mutex - GRBM index register access 9. mmio_idx_lock - MMIO index access (spinlock) The implementation provides: - Lock ordering training at module init (amdgpu_lockdep_init) - Lock class association for real driver locks (amdgpu_lockdep_set_class) Dummy locks are associated with the same class keys as real driver locks via lockdep_set_class(), ensuring lockdep connects the training ordering with actual runtime locks. Testing: Build the kernel with CONFIG_PROVE_LOCKING=y (enables CONFIG_LOCKDEP): scripts/config --enable PROVE_LOCKING scripts/config --enable DEBUG_LOCKDEP make -j$(nproc) On boot, dmesg should show: AMDGPU: Lockdep annotations initialized (9 lock levels) The companion IGT test (tests/amdgpu/amd_lockdep) exercises lock-heavy GPU code paths concurrently to trigger lockdep warnings on violations: sudo ./build/tests/amdgpu/amd_lockdep sudo dmesg | grep -A 50 "circular locking dependency" IGT subtests: concurrent-reset-and-submit - reset_sem vs submission locks concurrent-mmap-and-evict - mmap_lock vs vram_lock concurrent-userptr-and-reset - notifier_lock vs reset_sem stress-all-paths - all of the above simultaneously A clean dmesg (no "circular locking dependency" or "possible recursive locking detected" messages) confirms no lock ordering violations. For CI integration, the test should be run on kernels compiled with CONFIG_LOCKDEP=y; dmesg is scanned post-run for lockdep splats. v2: (Christian) - Move notifier_lock and vram_lock before reset locks in hierarchy. HMM invalidation holds notifier_lock and can wait for GPU reset completion, so notifier_lock must be outer to reset_domain->sem. - Associate dummy locks with lock class keys via lockdep_set_class() so lockdep connects training with real driver locks. - Update commit message to list all 9 lock levels. Requires CONFIG_PROVE_LOCKING=y to activate. Cc: Christian Konig <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Reviewed-by: Christian Konig <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdkfd: fix SMI event cross-process information leakYongqiang Sun
kfd_smi_ev_enabled() skips the suser privilege check when pid=0. PROCESS_START, PROCESS_END, and VMFAULT events are emitted with pid=0 while carrying another process's PID and command name, so any /dev/kfd user in the render group can monitor all GPU workloads. Pass the target process PID into kfd_smi_event_add() for these events so the existing per-client filter restricts delivery to the owning process or CAP_SYS_ADMIN subscribers. Signed-off-by: Yongqiang Sun <Yongqiang.Sun@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amd/display: Add DCN42B to dml21_translation_helperMatthew Stewart
Needed for DML to function with DCN42B. Signed-off-by: Matthew Stewart <Matthew.Stewart2@amd.com> Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>