summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-11pmdomain: Merge branch fixes into nextUlf Hansson
Merge the pmdomain fixes for v7.2-rc[n] into the next branch, to allow them to get tested together with the pmdomain changes that are targeted for the next release. Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-11pmdomain: qcom: rpmhpd: Add missing MXC and MMCX power domains for ElizaAbel Vesa
MXC and MMCX were initially omitted as they were believed to have no consumers, and they were not present downstream either. The Iris video codec requires these power domains, so add MXC and MMCX along with the MXC_AO and MMCX_AO. Fixes: f387ecdd492f ("pmdomain: qcom: rpmhpd: Add Eliza RPMh Power Domains") Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-11vxlan: do not arm the ageing timer on a device that is downBaul Lee
vxlan_changelink() arms vxlan->age_timer whenever the requested ageing interval differs from the configured one: if (conf.age_interval != vxlan->cfg.age_interval) mod_timer(&vxlan->age_timer, jiffies); There is no netif_running() test, so the timer is armed even on a device that was never brought up. The only synchronous cancel in the driver is the timer_delete_sync() in vxlan_stop(), which is .ndo_stop. netif_close_many() drops devices without IFF_UP before __dev_close_many() runs, so that cancel is skipped for such a device. vxlan_setup() sets dev->needs_free_netdev = true and age_timer is a member of struct vxlan_dev, so free_netdev() releases the allocation the timer lives in while it is still queued on a timer_base. expire_timers() unlinks the entry before it loads timer->function, so the timer core writes through the freed object's list pointers: BUG: KASAN: slab-use-after-free in __run_timers+0x208/0x654 Write of size 8 at addr ffff00001adace68 by task true/192 __asan_store8+0x84/0xac __run_timers+0x208/0x654 run_timer_softirq+0x154/0x18c Allocated by task 189: alloc_netdev_mqs+0x64/0x720 rtnl_create_link+0x4ac/0x520 rtnl_newlink+0x758/0xd00 Freed by task 191: netdev_release+0x40/0x58 netdev_run_todo+0x4a4/0x8c0 rtnl_dellink+0x200/0x4e8 The rtnl operations involved are netns-scoped, so an unprivileged user can perform them in a new user and network namespace. Arming the timer on a down device never had an effect: vxlan_cleanup() returns early on !netif_running(), and vxlan_open() arms the timer for any non-zero interval once the device is brought up. Add the missing test. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com> Fixes: 40051c4dcad5 ("vxlan: Allow changing ageing time") Cc: stable@vger.kernel.org Signed-off-by: Baul Lee <baul.lee@xbow.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260809111829.78834-1-baul.lee@xbow.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-11rust: num: add Bounded::shr_exactEliot Courtney
Add `shr_exact` in the vein of `try_shrink` which shifts a bounded right only if it loses no set bits. This is useful for getting a shifted down integer while simultaneously checking that it's aligned. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260810-pramin-split-v2-3-65a00b3c7309@nvidia.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-11rust: num: reject Bounded::shr overshifts at build timeEliot Courtney
Make `shr` reject shifts of at least the type's bit width at build time, instead of panicking or masking the shift amount at runtime. [ This implies we can break the type invariant, which in turn means we can trigger UB via `Deref`, e.g.: rust_kernel: panicked at rust/kernel/num/bounded.rs:528:22: unsafe precondition(s) violated: hint::unreachable_unchecked must never be reached - Miguel ] Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Cc: stable@vger.kernel.org Fixes: c59a2d14cd24 ("rust: num: add `shr` and `shl` methods to `Bounded`") Link: https://patch.msgid.link/20260810-pramin-split-v2-2-65a00b3c7309@nvidia.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-11rust: num: use const_assert! in BoundedEliot Courtney
Convert the const-block asserts in bounded.rs to const_assert!, matching the rest of the file. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Suggested-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/rust-for-linux/DKIY9YGIPUUE.SZD2DUQM9NGK@garyguo.net/ Link: https://patch.msgid.link/20260810-pramin-split-v2-1-65a00b3c7309@nvidia.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-11PCI/ASPM: Avoid L0s for Realtek RTS525AMax Lee
The Realtek RTS525A PCIe card reader reports an AER Correctable Replay Timer Timeout storm when ASPM L0s is enabled on its link. On an affected HP ZBook Power 16 inch G11, the Root Port received tens of millions of AER interrupts from the RTS525A even when the rtsx_pci driver was blacklisted and the endpoint was not enabled by a driver. For example: pcieport 0000:00:1c.6: AER: Multiple Correctable error message received from 0000:58:00.0 rtsx_pci 0000:58:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID) rtsx_pci 0000:58:00.0: device [10ec:525a] error status/mask=00001000/00006000 rtsx_pci 0000:58:00.0: [12] Timeout pcieport 0000:00:1c.6: AER: Correctable error message received from 0000:58:00.0 Testing with OS-native AER control showed that disabling only L0s on the RTS525A link stops new AER interrupt and counter growth while leaving L1 enabled. Disabling L1, L1 substates, or Clock PM alone did not stop the storm. Prevent the broken L0s configuration by removing L0s from the RTS525A advertised ASPM capability. This avoids enabling the non-working ASPM state instead of masking the resulting AER Replay Timer Timeout reports. Signed-off-by: Max Lee <max.lee@canonical.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260707021527.639611-1-max.lee@canonical.com
2026-08-11rust: uapi: replace direct asm-generic/ioctl.h include with linux/ioctl.hMukesh Kumar Chaurasiya (IBM)
rust/uapi/uapi_helper.h was directly including <uapi/asm-generic/ioctl.h> instead of the proper <uapi/linux/ioctl.h>. On powerpc, <uapi/linux/ioctl.h> pulls in <uapi/asm/ioctl.h> first, which defines _IOC_SIZEBITS, _IOC_DIRBITS, _IOC_NONE, and _IOC_WRITE with the arch-specific values, before falling through to <asm-generic/ioctl.h>. By bypassing that chain and including <asm-generic/ioctl.h> directly, the arch-specific overrides never ran first, so when other headers in the compilation later brought in the full arch-aware chain, Clang saw those four macros being defined a second time and emitted: clang diag: arch/powerpc/include/uapi/asm/ioctl.h:5:9: warning: '_IOC_SIZEBITS' macro redefined [-Wmacro-redefined] clang diag: arch/powerpc/include/uapi/asm/ioctl.h:6:9: warning: '_IOC_DIRBITS' macro redefined [-Wmacro-redefined] clang diag: arch/powerpc/include/uapi/asm/ioctl.h:8:9: warning: '_IOC_NONE' macro redefined [-Wmacro-redefined] clang diag: arch/powerpc/include/uapi/asm/ioctl.h:10:9: warning: '_IOC_WRITE' macro redefined [-Wmacro-redefined] Fix this by replacing the direct include of <uapi/asm-generic/ioctl.h> with <uapi/linux/ioctl.h>, which is the correct arch-aware entry point and already maintains the intended include order. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202608050618.9dekfjtF-lkp@intel.com/ Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Fixes: 4e1746656839 ("rust: uapi: Add UAPI crate") Link: https://patch.msgid.link/20260811063345.685884-1-mkchauras@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-11rust: time: add Delta::as_millis_ceil()FUJITA Tomonori
Add a ceiling variant, mirroring the existing as_micros_ceil() since the existing as_millis() truncates towards zero. Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://patch.msgid.link/20260808062839.1159990-4-tomo@flapping.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-11rust: time: add jiffies time unit for DeltaFUJITA Tomonori
Add a Jiffy time unit with isize as its representation and provide Delta<Jiffy>::from_jiffies() and as_jiffies() as the unit-specific constructor and accessor, mirroring from_nanos()/as_nanos() on the nanosecond Delta. Represent the jiffies span as isize: Delta is a signed span (nanoseconds use i64) and, as a timeout, the value only needs to reach MAX_JIFFY_OFFSET ((LONG_MAX >> 1) - 1). isize is signed and matches the kernel's c_long, so it meets both. Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://patch.msgid.link/20260808062839.1159990-3-tomo@flapping.org [ Added intra-doc links. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-11rust: time: make Delta generic over its time unitFUJITA Tomonori
Delta hardcodes its value as i64 nanoseconds. A later patch adds a jiffies span, whose natural representation is isize jiffies rather than i64 nanoseconds, and a separate type per unit would duplicate the arithmetic and comparison machinery. Make Delta generic over its time unit so the jiffies span can reuse that machinery. The nanosecond Delta keeps its current representation and API via the default unit parameter, so no functional change. Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://patch.msgid.link/20260808062839.1159990-2-tomo@flapping.org [ Reworded to remove stray word. Added intra-doc links. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-11rust: time: fix as_micros_ceil() rounding near i64::MAXFUJITA Tomonori
The ceiling adjustment used saturating_add(NSEC_PER_USEC - 1) before dividing. Once the nanosecond value gets within NSEC_PER_USEC - 1 of i64::MAX the addition saturates to i64::MAX, which drops the ceiling bias and can yield a result one microsecond too small. Fixes: fae0cdc12340 ("rust: time: Introduce Delta type") Reported-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Closes: https://lore.kernel.org/rust-for-linux/CANiq72mtS0ABA2JnT5tpz6J9c_mnxY+vyPvghV_ukngWvN8F2w@mail.gmail.com/ Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Acked-by: Andreas Hindborg <a.hindborg@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260807130531.1056209-1-tomo@flapping.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-11rust: doctest: use vertical import styleAlvin Sun
Convert `use` imports to vertical layout for better readability and maintainability. Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Acked-by: David Gow <david@davidgow.net> Link: https://patch.msgid.link/20260521-miscdev-use-format-v3-7-56240ca70d0c@linux.dev Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-11Merge branch 'dpll-use-pin-owner-s-dpll-ref-for-pin-level-set-callbacks'Paolo Abeni
Ivan Vecera says: ==================== dpll: use pin owner's dpll ref for pin-level set callbacks Pin-level attributes (frequency, phase adjust, embedded sync, reference sync) are properties of the pin itself. The get callbacks already use only the pin owner's DPLL reference, but the set callbacks iterate over all registered DPLL devices, resulting in redundant HW writes for drivers that share a pin across multiple DPLLs. This series simplifies the set side to match the get side: call the set callback only through the owner's reference. Patch 1 prepares the zl3073x driver whose ref_sync_set callback had per-channel behavior (setting priority on a single DPLL channel). It now iterates all channels internally so it remains correct when invoked only once. Patch 2 drops the xa_for_each loops from dpll_pin_freq_set(), dpll_pin_esync_set(), dpll_pin_ref_sync_state_set() and dpll_pin_phase_adj_set(), along with the rollback logic and the per-ref -EOPNOTSUPP validation scan. The dpll.rst documentation is updated to reflect the new behavior. ==================== Link: https://patch.msgid.link/20260807095926.386923-1-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-11dpll: use pin owner's dpll ref for pin-level attribute settingIvan Vecera
Pin-level attributes (frequency, phase adjust, embedded sync, reference sync) are properties of the pin itself, not of a particular DPLL device. The get callbacks already use only the pin owner's DPLL reference (via dpll_pin_own_dpll_ref_first()), but the set callbacks iterate over all registered DPLL references and invoke the set operation on each one. This is redundant because a pin is a single physical entity - setting its frequency or phase adjust once through the owner's ops is sufficient. Calling set on every registered DPLL just results in duplicate HW writes for drivers that share a pin across multiple DPLL devices (e.g. ice registers each input pin with both the EEC and PPS DPLL, zl3073x registers input pins with every DPLL channel). Simplify dpll_pin_freq_set(), dpll_pin_esync_set(), dpll_pin_ref_sync_state_set() and dpll_pin_phase_adj_set() to call the set callback only through the owner's DPLL reference, matching the existing get-side behavior. This removes the xa_for_each iteration loops, the now-unnecessary rollback logic, and several local variables. The -EOPNOTSUPP validation loop, which checked ops support across all owner-matching references, is replaced with a direct check on the single owner reference returned by dpll_pin_own_dpll_ref_first(). The documentation in dpll.rst is updated to reflect that pin-level attributes are set through the pin owner's dpll reference only. No existing driver is affected: - ptp_ocp and mlx5 register each pin with a single DPLL. - ice registers input pins with two DPLLs (EEC and PPS) using identical ops and pin_priv; the set callbacks address the HW by pin index, not by DPLL, so the second call was a no-op. - zl3073x registers input pins with every DPLL channel; the set callbacks address HW by pin/ref ID regardless of DPLL. The ref_sync_set callback was the only one with per-channel behavior, addressed by the preceding patch. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20260807095926.386923-3-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-11dpll: zl3073x: update all DPLL channels on ref_sync_setIvan Vecera
zl3073x_dpll_input_pin_ref_sync_set() excludes the sync source from automatic reference selection by setting its priority to NONE, but currently only does this on the single DPLL channel whose pin_priv was passed to the callback. Since input pins are registered with every DPLL channel, the datasheet recommends covering all channels to prevent the sync source from remaining a selectable candidate on the other channels. This is a preparation for the following patch which changes the DPLL core to invoke pin-level set callbacks only through the pin owner's reference instead of iterating over all registered DPLL devices. Replace the single-channel priority write with a list_for_each_entry() loop over all DPLL channels. Each channel's lock is acquired individually for its read-modify-write sequence. The guard(mutex) is replaced with explicit mutex_lock/mutex_unlock to allow releasing the owner's lock before iterating, avoiding nested locking of the same mutex class. A change notification is sent for the sync pin if any channel's priority was actually modified. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Petr Oros <poros@redhat.com> Link: https://patch.msgid.link/20260807095926.386923-2-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-11ipv4: fix use-after-free in fib_nhc_update_mtu()Chengfeng Ye
fib_nhc_update_mtu() walks the nexthop exception table under RTNL, but RTNL does not serialize this walk with PMTU exception updates. The walk uses rcu_dereference_protected() with a constant true condition without holding fnhe_lock. The following interleaving can therefore occur: CPU 0 CPU 1 fib_nhc_update_mtu() update_or_create_fnhe() load fnhe spin_lock_bh(&fnhe_lock) fnhe_remove_oldest() unlink fnhe kfree_rcu(fnhe, rcu) <quiescent state> access fnhe after grace period KASAN reported: BUG: KASAN: slab-use-after-free in fib_nhc_update_mtu+0x3df/0x410 Read of size 8 at addr ffff888107d49000 by task poc/90 Call Trace: fib_nhc_update_mtu+0x3df/0x410 fib_sync_mtu+0x7a/0xd0 fib_netdev_event+0x229/0x3f0 netif_set_mtu_ext+0x33a/0x570 dev_set_mtu+0x88/0x120 The same walk updates fnhe_pmtu and fnhe_mtu_locked. These fields form a pair and other writers serialize them with fnhe_lock. RCU alone prevents reclamation, but would still allow concurrent writers to leave a mixed pair. Walk the table under RCU and acquire fnhe_lock only while updating each exception. RCU keeps the current entry alive while the short critical section serializes its paired PMTU fields. This avoids holding the global lock while scanning all 2048 buckets for every nexthop. Fixes: af7d6cce5369 ("net: ipv4: update fnhe_pmtu when first hop's MTU changes") Cc: stable@vger.kernel.org Suggested-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260807181710.1178747-1-nicoyip.dev@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-11timekeeping: Annotate auxiliary clock accessors with __must_checkThomas Weißschuh (Schneider Electric)
In contrast to the system time accessors, the ones for auxiliary clocks can fail. Make sure the callers check for this. Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260731-timekeeping-aux-must-check-v1-2-11ae93068497@linutronix.de
2026-08-11timekeeping: Remove the unused ktime_get_clock_ts64()Thomas Weißschuh (Schneider Electric)
The last user was removed in commit a6d799608e6a ("ptp: Switch to ktime_get_snapshot_id() for pre/post timestamps"). Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260731-timekeeping-aux-must-check-v1-1-11ae93068497@linutronix.de
2026-08-11NTB: ntb_netdev: Preserve RX queue depth on allocation failureKoichiro Den
ntb_netdev_rx_handler() hands the received skb to the network stack before allocating its replacement. If the allocation fails, nothing is reposted. Every failure therefore takes one buffer out of the RX queue while the interface remains up, and enough failures eventually stall reception. A retry path could refill the queue later, but ntb_netdev has none. Allocate the replacement first instead. If that fails, drop the packet and repost the same skb. This keeps the queue full and lets packet delivery resume as soon as memory is available again. Fixes: 548c237c0a99 ("net: Add support for NTB virtual ethernet device") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den <den@valinux.co.jp> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260806032537.3526498-1-den@valinux.co.jp Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-11selftests: net: reuseport_bpf_numa: consider cpuless numa nodeFeng Tang
reuseport_bpf_numa case failed when testing on a platform with CXL memory: #./reuseport_bpf_numa ---- IPv4 UDP ---- send node 0, receive socket 0 ./reuseport_bpf_numa: failed to pin to node: Invalid argument The root cause is that the platform has 2 numa nodes: node 0 has both cpu and memory, while node 1 is a CXL node which only has memory, and caused numa_run_on_node() to fail. Add sanity check to skip cpuless numa node for the numa binding test. Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260807002436.43991-1-feng.tang@linux.alibaba.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-11exfat: fix truncated volume labels returned by FS_IOC_GETFSLABELYang Wen
exfat_ioctl_get_volume_label() passes uniname.name_len to exfat_utf16_to_nls() as the output buffer length. However, name_len is the number of UTF-16 code units, while exfat_utf16_to_nls() expects the buffer size in bytes. As a result, volume labels that expand during charset conversion are truncated.The destination buffer is FSLABEL_MAX bytes long, so pass its actual size to the conversion helper. Signed-off-by: Yang Wen <anmuxixixi@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
2026-08-11KVM: s390: Fix memory corruption by not reinjecting CK machine checksChristian Borntraeger
Channel-subsystem damage machine checks are for the host channel subsystem. The guest channel subsystem is emulated in the userspace VMM. There is no point in forwarding such machine checks into the guest. This also simplifies the machine check reinjection and avoids kfree of a stack variable as reported by sashiko. There might be still machine checks that have the ck bit set with another bit (like instruction damage), mask out the CK bit in s390_backup_mcck_info(), like the CP and ED bits already are. Fixes: 4d62fcc0b692 ("KVM: s390: Inject machine check into the guest") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260806145835.31818-1-borntraeger@linux.ibm.com>
2026-08-11s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm()Anthony Krowiak
In vfio_ap_mdev_set_kvm(), kvm->arch.crypto.pqap_hook is set to &matrix_mdev->pqap_hook before the update locks are acquired and the mdev list is checked for a conflicting assignment. If another mdev is already attached to the same KVM instance, the function returns -EPERM without restoring the hook pointer, leaving kvm->arch.crypto.pqap_hook pointing at the failing matrix_mdev instead of the mdev that legitimately owns the KVM. Since matrix_mdev->kvm is never set on this error path, vfio_ap_mdev_unset_kvm() will not clean up the hook when matrix_mdev is later closed. If matrix_mdev is subsequently freed, any PQAP instruction executed by the guest will dereference the stale pointer through pqap_hook_rwsem, resulting in a use-after-free. Since kvm->arch.crypto.pqap_hook is only set in the vfio_ap_mdev_set_kvm() function and is cleared in the vfio_ap_mdev_unset_kvm() function, a check for 'kvm->arch.crypto.pqap_hook != NULL' is all that is needed to determine whether it belongs to another mdev. This will alleviate the need to iterate the matrix_dev->mdev_list list to see if the kvm object is assigned to another mdev.This was introduced in v3 to alleviate the need to take the mdevs_lock while iterating the list; however, this did not prevent a potential race condition. The pqap_hook_rwsem(write) is now performed inside get_update_locks_for_kvm(), which is updated to acquire pqap_hook_rwsem(write) between kvm->lock and mdevs_lock. This ordering is consistent with the PQAP intercept path, which acquires pqap_hook_rwsem in read mode while srcu is held under vcpu->mutex, establishing the dependency: kvm->lock -> vcpu->mutex -> srcu -> pqap_hook_rwsem(read). The pqap_hook_rwsem is now released inside the release_update_locks_for_kvm(), which is updated to release pqap_hook_rwsem(write) between mdevs_lock and kvm->lock. Additionally, kvm_put_kvm() in vfio_ap_mdev_unset_kvm() is moved after release_update_locks_for_kvm(). Previously it was called while kvm->lock was held; if it were ever the last reference, kvm_destroy_vm() would run under kvm->lock, which would deadlock. Fixes: 86956e70761b3 ("s390/vfio-ap: replace open coded locks for VFIO_GROUP_NOTIFY_SET_KVM notification") Cc: stable@vger.kernel.org Co-developed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260806173435.105044-1-akrowiak@linux.ibm.com>
2026-08-11KVM: s390: Fix length check __import_wp_info()Christian Borntraeger
struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: wp_info->len = bp_data->len; [...] if (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) return -EINVAL; wp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260805110455.7200-9-borntraeger@linux.ibm.com>
2026-08-11KVM: s390: Free guest debug data on vcpu destroyChristian Borntraeger
kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260805110455.7200-8-borntraeger@linux.ibm.com>
2026-08-11KVM: s390: Take srcu when importing watchpoint dataChristian Borntraeger
__import_wp_info() backs up the original guest memory contents of a watchpoint with read_guest_abs(), which is kvm_read_guest() and therefore resolves the memslot via __kvm_memslots(). That requires kvm->srcu (or kvm->slots_lock) to be held, otherwise a concurrent memslot update can free the memslots array under us once its SRCU grace period has elapsed. As this is not fast path, following lock ordering (mutex first, then srcu) take the big hammer and hold the srcu for the full import. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260805110455.7200-7-borntraeger@linux.ibm.com>
2026-08-11KVM: s390: Fix old_data leak in guest debug error pathChristian Borntraeger
__import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260805110455.7200-6-borntraeger@linux.ibm.com>
2026-08-11KVM: s390: Fix memory leak in guest debug handlingChristian Borntraeger
bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260805110455.7200-5-borntraeger@linux.ibm.com>
2026-08-11KVM: s390: Zero initialize irq in reinject_machine_checkChristian Borntraeger
kvm_s390_reinject_machine_check() fills cr14, mcic, ext_damage_code and failing_storage_address of the on-stack struct kvm_s390_irq, but struct kvm_s390_mchk_info also has a pad word and a 16 byte fixed_logout array. struct mcck_volatile_info carries no logout data, so there is nothing to copy there and both stay whatever was on the stack. __inject_mchk() then memcpy()s fixed_logout into the vcpu local interrupt state unconditionally. This will reach the guest during deliver and userspace during migration. Reflecting zeroes is the correct behaviour here, as KVM has no logout data for a reinjected machine check. This needs a host machine check while the cpu is in SIE so not trivial to trigger. Fixes: 4d62fcc0b692 ("KVM: s390: Inject machine check into the guest") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260805110455.7200-4-borntraeger@linux.ibm.com>
2026-08-11KVM: s390: Zero initialize data structures for inject_pfault_tokenChristian Borntraeger
__kvm_inject_pfault_token() only sets .type and .u.ext.ext_params2 of the on-stack struct kvm_s390_irq but the full ext substructure is copied into the cpu local variable on inject. ext_params and pad contain stale stack values. Interrupt delivery only uses ext_params2, so nothing leaks to the guest, but a host user can use the migration ioctls to get to the data. Fix by zero-initializing the irq struct. Do the same for the inti data structure. Fixes: 383d0b050106 ("KVM: s390: handle pending local interrupts via bitmap") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260805110455.7200-3-borntraeger@linux.ibm.com>
2026-08-11KVM: s390: Remove user triggerable WARN_ONChristian Borntraeger
pin_map_page() fails legitimately whenever the userspace mapping behind the adapter route has gone away, e.g. when the VMM unmaps that memory. As this can happen without a kernel programming error, remove the WARN_ON. Fixes: 1e95e3bc6b05 ("KVM: s390: Enable adapter_indicators_set to use mapped pages") Cc: Douglas Freimuth <freimuth@linux.ibm.com> Cc: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Douglas Freimuth <freimuth@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260805110455.7200-2-borntraeger@linux.ibm.com>
2026-08-11objtool/headers: Sync tools/include/linux/objtool_types.h with ↵Ingo Molnar
include/linux/objtool_types.h Sync up the kernel and tooling headers to fix this build warning: Warning: Kernel ABI header at 'tools/include/linux/objtool_types.h' differs from latest version at 'include/linux/objtool_types.h' Fixes: 6e5716b187fa ("objtool: Replace __ASSEMBLY__ with __ASSEMBLER__ in header files") Cc: Thomas Huth <thuth@redhat.com> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2026-08-11sctp: auth: propagate HMAC calculation errors to callersQing Luo
sctp_auth_calculate_hmac() can fail when building the association secret under memory pressure, but its void return silently leaves the HMAC digest zeroed. On the receive path, sctp_sf_authenticate() compares this zeroed digest against the peer-supplied one using crypto_memneq(), potentially accepting an all-zero HMAC from the peer if the allocation failed. On the send path, sctp_packet_pack() transmits a packet with a zeroed HMAC that the peer would reject. Improve error handling by making sctp_auth_calculate_hmac() return int: - sctp_sf_authenticate() returns SCTP_IERROR_NOMEM instead of accepting a zero HMAC. - sctp_packet_pack() drops the packet on failure instead of transmitting a zeroed HMAC. Update the declaration in auth.h accordingly. Assisted-by: LLM Signed-off-by: Qing Luo <luoqing@kylinos.cn> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/20260807064314.500742-1-l1138897701@163.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-11firewire: core: add KUnit tests for failure of tree buildingTakashi Sakamoto
Abdun Nihaal has reported a memory leak when tree building fails in the middle of self ID sequence enumeration. This is caused by an invalid self ID sequence and is not a common occurrence. This commit is intended to assist in fixing the issue by adding KUnit tests to show the cases in which the memory leak is triggered. The leak occurs internally in the build_tree() function, therefore it cannot be detected directly by the tests. Link: https://lore.kernel.org/r/20260810064119.410324-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2026-08-11firewire: core: add KUnit tests for successful tree buildingTakashi Sakamoto
After a bus reset, self ID sequence is captured by 1394 OHCI hardware and passed to software through SelfID DMA context. The core parses the sequence to build an internal cache of the node tree for the current generation of the bus. This is the first step in managing resources on the bus. The tree is build by the build_tree() function. This commit adds KUnit tests for the function, covering several successful scenarios. Link: https://lore.kernel.org/r/20260810064119.410324-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2026-08-11firewire: core: add KUnit test skeleton for node treeTakashi Sakamoto
Some issues have been reported in node tree management. Refactoring the topology-related code in the core is required. Adding unit tests would help ensure that the refactoring does not introduce regressions. This commit adds a KUnit test skeleton for this purpose. Link: https://lore.kernel.org/r/20260810064119.410324-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2026-08-11drm/panel: remove accidentally committed .orig fileJani Nikula
Apparently an extra file drivers/gpu/drm/drm_panel.c.orig was accidentally added and committed while committing ac3baea883da ("drm/panel: find_panel_by_fwnode() return a counted reference"). Remove it. Reported-by: Mark Brown <broonie@kernel.org> Closes: https://lore.kernel.org/r/annCRqegoQ9PBClJ@sirena.org.uk Fixes: ac3baea883da ("drm/panel: find_panel_by_fwnode() return a counted reference") Cc: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260810125204.3258447-1-jani.nikula@intel.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-08-11Merge branches 'arm/smmu/updates', 'arm/smmu/bindings', 'mediatek', ↵Joerg Roedel
'qualcomm/msm', 'rockchip', 'ti/omap', 'riscv', 'intel/vt-d', 'amd/amd-vi', 'core' and 'typos' into next
2026-08-11iommu/amd: Add SNP page mode 0 supportVasant Hegde
Newer AMD IOMMUs supports DTE[Mode]=0 for SNP-enabled system. This is detected using new feature bit (EFR2[SNP_Page_Mode_0_Sup]). If this feature is enabled, then IOMMU supports: - Passthrough mode (i.e. iommu=pt) - amd_iommu=pgtbl_v2: Forcing Linux DMA-API to use IOMMU v2 page table - Setting up device for SVA mode in the host. Signed-off-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Tested-by: Amandeep Kaur Longia <AmandeepKaur.Longia@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-11iommu/amd: Fix GN bit setting in COMPLETE_PPR_REQUEST commandVasant Hegde
The GN bit in the COMPLETE_PPR_REQUEST command indicates whether the device is operating under a guest (v2) page table. Currently, dev_data->pri_tlp is incorrectly used to derive this bit. However, pri_tlp indicates whether the device uses PRI TLP which is unrelated to page table mode. Fix this by refactoring amd_iommu_complete_ppr() into a static internal helper __amd_iommu_complete_ppr() that accepts an explicit 'gn' argument. The amd_iommu_complete_ppr() wrapper then derives the GN bit correctly from the device's active protection domain via pdom_is_v2_pgtbl_mode(). In the INVALID_PPR_REQUEST error handling path, the device's protection domain may not be accessible, so derive the GN bit directly from the EVENT_FLAG_PPR_GN flag in the event log entry instead. While at it, change the 'gn' parameter type in build_complete_ppr() from u8 to bool to better reflect its semantics. Signed-off-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Ankit Soni <Ankit.Soni@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-11iommu/amd: Rate limit INVALID_PPR_REQUEST error loggingVasant Hegde
The amd_iommu_report_ppr_err() function logs an error message for every INVALID_PPR_REQUEST event. Under certain fault conditions, a misbehaving or malicious device can flood the IOMMU event log with PPR faults, causing the kernel log to be overwhelmed with repeated error messages. Switch from dev_err() to dev_err_ratelimited() to suppress duplicate messages when INVALID_PPR_REQUEST events occur at a high rate. Signed-off-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Ankit Soni <Ankit.Soni@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-11iommu/amd: Fix missing CMD_COMPLETE_PPR response for invalid PPR requestsVasant Hegde
The AMD IOMMU spec, requires the host to respond with a CMD_COMPLETE_PPR command when an EVENT_TYPE_INV_PPR_REQ event is received with the RX bit cleared. This response was missing in the current implementation, leaving invalid PPR requests unacknowledged. Introduce amd_iommu_report_ppr_err() to handle EVENT_TYPE_INV_PPR_REQ events. The new function logs the invalid PPR request and when the RX bit is cleared, sends CMD_COMPLETE_PPR response. Reported-by: Gaultier Delbarre <Gaultier.Delbarre@amd.com> Co-developed-by: Wei Huang <wei.huang2@amd.com> Signed-off-by: Wei Huang <wei.huang2@amd.com> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Ankit Soni <Ankit.Soni@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-11iommu/amd: Introduce PPR_TAG_LAST_PAGE() macroVasant Hegde
The PPR tag field (PPRtag) encodes two distinct fields: the 9-bit tag value (bits 8-0) and the last-page indicator L bit (bit 9). Fix PPR_TAG() to mask only the 9-bit tag field and introduce PPR_TAG_LAST_PAGE to explicitly extract the L bit. This way it becomes easy to read. Cc: Wei Huang <wei.huang2@amd.com> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Ankit Soni <Ankit.Soni@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-11iommu/amd: Fix incorrect device ID in invalid PASID error messageVasant Hegde
The IO page fault notifier handler logs pdev->dev.id when reporting an invalid PASID, but pdev->dev.id is the kernel-internal device ID and not the IOMMU device ID (BDF). Use dev_data->devid instead, which reflects actual devid. Fixes: 978d626b8f1a ("iommu/amd: Add IO page fault notifier handler") Signed-off-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Ankit Soni <Ankit.Soni@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-11Revert "Merge branch 'ib-rsk7204' into devel"Linus Walleij
This reverts commit d922b54e942ee9c798b0d688b025362a24d864ea, reversing changes made to 3f0245e23a176e78f00a760291b8e4f88d01d77e. The SH maintainer has indicated that he want to carry these changes in the SH tree instead, and need more time to review and merge the changes, so reverting it out from my tree. Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-08-11ALSA: hda/realtek: Rename Line Out control to Headphone on ThinkPad X1 ↵Zhang Heng
Carbon 6th The ThinkPad X1 Carbon 6th Gen (ALC285, SSID 17aa:225c) has no physical Line Out jack. The 3.5mm headphone jack is wired to the headphone DAC, but the ALSA HDA driver names the corresponding control as "Line Out Playback Volume" (node 0x02). PipeWire's ALSA Card Profile (ACP) silences "Line Out" when headphones are activated, which incorrectly mutes the headphone output. Add a quirk to rename the control to "Headphone Playback Volume" via alc285_lenovo_dac_rename(). Tested on openSUSE Tumbleweed (kernel 7.1.5): - Control renamed successfully, no name collision with "Headphone Playback Switch" - Headphone output works across multiple PipeWire/WirePlumber restarts and port switches Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221522 Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Tested-by: Branislav Klocok <branislav.klocok@orava.sk> Link: https://patch.msgid.link/20260811062734.400512-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-08-11ALSA: pci: asihpi: use pcim_iomap for managed PCI memory mappingRosen Penev
Replace manual ioremap() calls with pcim_iomap() which uses devres for automatic cleanup. This eliminates the need for manual iounmap() in both the error path of asihpi_adapter_probe() and the asihpi_adapter_remove() function. The pcim_iomap() helper is cleaner and less error-prone since it handles unmapping automatically when the PCI device is released. Assisted-by: opencode/big-pickle Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260811042122.44923-1-rosenp@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-08-11m68k: coldfire/5441x: register mcf-rcm-reset platform deviceJean-Michel Hautbois
Add SoC-level registration of the mcf-rcm-reset platform device so the power_on_reason sysfs attribute is created on every MCF5441x board without per-board boilerplate. Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-08-11m68k/coldfire: replace linux/gpio.h inclusionsArnd Bergmann
linux/gpio.h should no longer be used, convert these instead to linux/gpio/legacy.h for coldfire. Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Ungerer <gerg@kernel.org>