summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-06-04drivers/char/mem: eliminate unnecessary use of success_hookLorenzo Stoakes
Patch series "remove mmap_action success, error hooks", v3. The mmap_action->success_hook was a strange beast added to enable code which appeared to absolutely require access to a VMA pointer to work correctly. Primarily this was for hugetlb, however a different approach will be taken there, as clearly more work is required to figure out a sensible way of converting hugetlb to use mmap_prepare. The other user was the memory char driver, specifically /dev/zero which has the unusual property of explicitly setting file-backed VMAs anonymous. Providing the success hook was always foolish, as it allowed drivers a way to workaround the restriction that they should not access a pointer to a not-yet-correctly-initialised VMA - which defeats the purpose of the mmap_prepare work. We can achieve the same thing in memory char driver without needing the success hook, so this series removes that, then removes the success hook altogether. The error hook is also unnecessary - the motivation for this was for functions which need to override the error code when performing an mmap action in order to avoid breaking userspace. We can achieve this by just providing a field for the error code. Doing this means we don't have to worry about the hook doing anything odd. We also add a check to ensure the error code is in fact valid. Again the memory char driver is the only current user of this, so this series updates it to use that. After this change mmap_action has no custom hooks at all, which seems rather more cromulent than before. This patch (of 3): /dev/zero, uniquely, marks memory mapped there as anonymous. This is currently achieved using the mmap_action->success_hook. However this hook circumvents the abstraction of VMA initialisation so it's preferable to do things a different way. To achieve this, this patch firstly defaults the VMA descriptor's vm_ops field to the dummy VMA operations, which is what file-backed VMAs default this field to. That way, we can detect whether a driver sets this field to NULL in order to mark it anonymous. We then introduce vma_desc_set_anonymous() to do this explicitly, and invoke it in mmap_zero_prepare(). This way, any driver which does not explicitly set desc->vm_ops, retains the dummy vm_ops as they would previously. We also update set_vma_user_defined_fields() to make clear that we are either setting vma->vm_ops to what is provided by the driver (or defaulting to dummy_vm_ops if not set), or setting the VMA anonymous. This lays the groundwork for removing the success hook. Link: https://lore.kernel.org/cover.1780397980.git.ljs@kernel.org Link: https://lore.kernel.org/010579cca6787cf7bb057ab1f7228978b10601c8.1780397980.git.ljs@kernel.org Signed-off-by: Lorenzo Stoakes <ljs@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jann Horn <jannh@google.com> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-06-04Merge tag 'net-7.1-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from Netfilter, wireless and Bluetooth. Current release - fix to a fix: - Bluetooth: MGMT: fix backward compatibility with bluetoothd which adds stray bytes to MGMT_OP_ADD_EXT_ADV_DATA Previous releases - regressions: - af_unix: fix inq_len update inaccuracy on partial read - eth: fec: fix pinctrl default state restore order on resume - wifi: iwlwifi: - mvm: don't support the reset handshake for old firmwares - pcie: simplify the resume flow if fast resume is not used, work around NIC access failures Previous releases - always broken: - Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig - sctp: fix a couple of bugs in COOKIE_ECHO processing - sched: fix pedit partial COW leading to page cache corruption - wifi: nl80211: reject oversized EMA RNR lists - netfilter: - conntrack_irc: fix possible out-of-bounds read - bridge: make ebt_snat ARP rewrite writable - appletalk: zero-initialize aarp_entry to prevent heap info leak - ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options - mptcp: fix number of bugs reported by AI scans and discovered during NVMe over MPTCP testing" * tag 'net-7.1-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (85 commits) Reapply "bnxt_en: bring back rtnl_lock() in the bnxt_open() path" udp: clear skb->dev before running a sockmap verdict sctp: purge outqueue on stale COOKIE-ECHO handling bonding: annotate data-races arcound churn variables net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr rtase: Avoid sleeping in get_stats64() ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() ipv6: mcast: Fix use-after-free when processing MLD queries selftests: net: add vxlan vnifilter notification test vxlan: vnifilter: fix spurious notification on VNI update vxlan: vnifilter: send notification on VNI add rtase: Reset TX subqueue when clearing TX ring octeontx2-af: npc: Fix CPT channel mask in npc_install_flow dt-bindings: ethernet: eswin: fix hsp-sp-csr backward compatibility sctp: validate cached peer INIT chunk length in COOKIE_ECHO processing net/sched: fix pedit partial COW leading to page cache corruption vsock/vmci: fix sk_ack_backlog leak on failed handshake net: bonding: fix NULL pointer dereference in bond_do_ioctl() geneve: fix length used in GRO hint UDP checksum adjustment net: ethernet: mtk_eth_soc: Fix use-after-free in metadata dst teardown ...
2026-06-05Merge tag 'drm-xe-fixes-2026-06-04' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes - Revert removing support for unpublished NVL-S GuC (Daniele) - Suspend fixes related to multi-queue (Niranjana) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/aiHPGiPrAyHgwBZl@intel.com
2026-06-04drm/panel: novatek-nt36672a: Inline panel init sequencesChintan Patel
Inline the panel initialization command sequences and remove the table-based command abstraction used by the NT36672A panel driver. Replace the nt36672a_panel_cmd tables and nt36672a_send_cmds() helper with explicit initialization functions using mipi_dsi_dcs_write_seq_multi() and mipi_dsi_dcs_write_var_seq_multi() directly. This improves readability by making the panel programming sequence explicit in code and allows future sharing of common command subsequences between panels. It also removes an unnecessary wrapper around the MIPI DSI helpers. Additionally, compress repeated register writes into small loops where appropriate to reduce duplication in the initialization sequences. Add: tianma_fhd_video_send_init_cmds_1() tianma_fhd_video_send_init_cmds_2() tianma_fhd_video_send_deinit_cmds() Update nt36672a_panel_desc to use function pointers for panel init sequences and invoke them directly from prepare/unprepare paths. Signed-off-by: Chintan Patel <chintanlike@gmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260523035734.6602-1-chintanlike@gmail.com
2026-06-04scsi: fcoe: don't recurse on the netdev's ops lockJakub Kicinski
fcoe_link_speed_update() calls __ethtool_get_link_ksettings() on the lport's netdev, which will soon take the dev's ops lock. Some notifier callers already arrive with this lock held. Switch to netif_get_link_ksettings() and adjust the explicit call sites to take the netdev lock explicitly. Within fcoe_device_notification() try to only query the link speed from notifiers which announce link state change (UP / CHANGE), DOWN / GOING_DOWN notifiers are slightly sketchy when it comes to ops locking right now, and the code already special-cases those by maintaining the local link_possible variable. Also take the lock in bnx2fc_net_config(), even though I think that bnx2fc call sites are largely irrelevant since it's not an ops-locked driver. Link: https://patch.msgid.link/20260603012840.2254293-11-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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: 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: 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-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-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>
2026-06-04drm/amd/display: Fix DCN42B version detectionMatthew Stewart
In resource_parse_asic_id, the check for GC_11_0_4 was unbounded, which caused it to override the detection of 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>
2026-06-04drm/amdgpu: Fix user-triggerable BUG()/BUG_ON() callsCe Sun
Replace BUG()/BUG_ON() with error logs and safe returns in several places where they can be triggered by invalid userspace input, preventing DoS via kernel panic. Signed-off-by: Ce Sun <cesun102@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04rpmsg: char: Fix use-after-free on probe error pathYuho Choi
rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL. Fixes: bc69d1066569 ("rpmsg: char: Introduce the "rpmsg-raw" channel") Signed-off-by: Yuho Choi <dbgh9129@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260601183247.1962010-1-dbgh9129@gmail.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-06-04net/mlx5: convert miss_list allocation to kvmalloc_array()William Theesfeld
dr_icm_buddy_init_ste_cache() allocates the per-buddy miss_list using the open-coded kvmalloc(n * sizeof(*p), ...) form. The neighbouring allocations in the same function already use the kvcalloc()/ kvzalloc_objs() forms; switch this last one to kvmalloc_array() for consistency and for the size_mul overflow check that kvmalloc_array() performs. The semantics are unchanged: kvmalloc_array() returns a non-zeroed buffer, just like the previous kvmalloc() call. Existing callers of buddy->miss_list initialise each list_head before use. Signed-off-by: William Theesfeld <william@theesfeld.net> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260601193758.626537-1-william@theesfeld.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04power: supply: add support for Samsung S2M series PMIC charger deviceKaustabh Chakraborty
Add a driver for charger controllers found in certain Samsung S2M series PMICs. The driver has very basic support for the device, with only charger online reporting working, and USB 2.0 device negotiations working. The driver includes initial support for the S2MU005 PMIC charger. Co-developed-by: Łukasz Lebiedziński <kernel@lvkasz.us> Signed-off-by: Łukasz Lebiedziński <kernel@lvkasz.us> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Link: https://patch.msgid.link/20260516-s2mu005-pmic-v7-10-73f9702fb461@disroot.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-06-04Reapply "bnxt_en: bring back rtnl_lock() in the bnxt_open() path"Jakub Kicinski
This reverts commit 850d9248d2eac662f869c766a598c877690c74e5. This reapplies commit 325eb217e41f ("bnxt_en: bring back rtnl_lock() in the bnxt_open() path"). Breno reports a lockdep warning in bnxt. During FW reset the driver may end up calling netif_set_real_num_tx_queues() (if queue count changes), so calls to bnxt_open() still require rtnl_lock. net/sched/sch_generic.c:1416 suspicious rcu_dereference_protected() usage! dev_qdisc_change_real_num_tx+0x54/0xe0 netif_set_real_num_tx_queues+0x4ed/0xa80 __bnxt_open_nic+0x9cb/0x3490 bnxt_open+0x1cb/0x370 bnxt_fw_reset_task+0x80d/0x1e80 process_scheduled_works+0x9c1/0x13b0 The reverted commit was just an optimization / experiment so let's go back to taking the lock. Reported-by: Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/ah726OtFX-Qw3U-R@gmail.com Fixes: 850d9248d2ea ("Revert "bnxt_en: bring back rtnl_lock() in the bnxt_open() path"") Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260603195845.2574426-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04regulator: bq257xx: drop confusing configuration of_nodeJohan Hovold
The driver reuses the OF node of the parent multi-function device but still sets the of_node field of the regulator configuration to any prior OF node. Since the MFD child device does not have an OF node set until probe is called, this field is set to NULL on first probe and to the reused OF node if the driver is later rebound. As the device_set_of_node_from_dev() helper drops a reference to any prior OF node before taking a reference to the new one this can apparently also confuse LLMs like Sashiko which flags it as a potential use-after-free (which it is not). Drop the confusing and redundant configuration of_node assignment. Link: https://sashiko.dev/#/patchset/20260408073055.5183-1-johan%40kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260604115912.2734074-1-johan@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-04bonding: annotate data-races arcound churn variablesEric Dumazet
These fields are updated asynchronously by the bonding state machine in ad_churn_machine() while holding bond->mode_lock. bond_info_show_slave() and bond_fill_slave_info() read them without bond->mode_lock being held, we need to add READ_ONCE() and WRITE_ONCE() annotations. Note that AD_CHURN_MONITOR, AD_CHURN, and AD_NO_CHURN are defined exclusively in (kernel private) include/net/bond_3ad.h header. They should be moved to include/uapi/linux/if_bonding.h or userspace tools will have to hardcode their values. Fixes: 4916f2e2f3fc ("bonding: print churn state via netlink") Fixes: 14c9551a32eb ("bonding: Implement port churn-machine (AD standard 43.4.17).") Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260603123514.388226-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04rtase: Avoid sleeping in get_stats64()Justin Lai
The .ndo_get_stats64 callback must not sleep because it can be called when reading /proc/net/dev. rtase_get_stats64() calls rtase_dump_tally_counter(), which polls the tally counter dump bit with read_poll_timeout(). This may sleep while waiting for the hardware counter dump to complete. Use read_poll_timeout_atomic() instead to avoid sleeping in the get_stats64() path. Fixes: 079600489960 ("rtase: Implement net_device_ops") Cc: stable@vger.kernel.org Signed-off-by: Justin Lai <justinlai0215@realtek.com> Link: https://patch.msgid.link/20260603061816.31356-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04vxlan: vnifilter: fix spurious notification on VNI updateAndy Roulin
When a VNI is re-added with the same attributes (e.g. same group or no group), vxlan_vni_update() sends a spurious RTM_NEWTUNNEL notification even though nothing changed. The bug is that 'if (changed)' tests whether the pointer is non-NULL, not the bool value it points to. Since every caller passes a valid pointer, the condition is always true and the notification fires unconditionally. Fix by dereferencing the pointer: 'if (*changed)'. Reproducer: # ip link add vxlan100 type vxlan dstport 4789 local 10.0.0.1 \ nolearning external vnifilter # ip link set vxlan100 up # bridge monitor vni & # bridge vni add vni 1000 dev vxlan100 # bridge vni add vni 1000 dev vxlan100 # spurious notification Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device") Signed-off-by: Andy Roulin <aroulin@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Link: https://patch.msgid.link/20260602185138.253265-3-aroulin@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04vxlan: vnifilter: send notification on VNI addAndy Roulin
When a new VNI is added to a vxlan device with vnifilter enabled, no RTM_NEWTUNNEL notification is sent to userspace. This means 'bridge monitor vni' never shows VNI add events, even though VNI delete events are reported correctly. The bug is in vxlan_vni_add(), where the notification is guarded by 'if (changed)'. The 'changed' flag is set by vxlan_vni_update_group() only when the multicast group or remote IP is modified, but for a new VNI added without a group (e.g. in L3 VxLAN interface scenarios), the function returns early without setting changed=true. Since this is a new VNI, the notification should be sent unconditionally. The notification is not guarded by the return value of vxlan_vni_update_group() because, at this point, the VNI has already been inserted into the hash table and list with no rollback on error. The VNI will be visible in 'bridge vni show' regardless, so userspace should be informed. This is consistent with vxlan_vni_del() which also notifies unconditionally. The 'if (changed)' guard remains correct in vxlan_vni_update(), which handles the case where a VNI already exists and is being re-added -- there, we only want to notify if the group/remote actually changed. Reproducer: # ip link add vxlan100 type vxlan dstport 4789 local 10.0.0.1 \ nolearning external vnifilter # ip link set vxlan100 up # bridge monitor vni & # bridge vni add vni 1000 dev vxlan100 # no notification # bridge vni delete vni 1000 dev vxlan100 # notification received Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device") Reported-by: Chirag Shah <chirag@nvidia.com> Signed-off-by: Andy Roulin <aroulin@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Link: https://patch.msgid.link/20260602185138.253265-2-aroulin@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>