commit 17e9266e1aff69de51dbd554c8dad36c4cfef0bd Author: Greg Kroah-Hartman Date: Wed Oct 15 12:04:23 2025 +0200 Linux 6.17.3 Link: https://lore.kernel.org/r/20251013144411.274874080@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Brett A C Sheffield Tested-by: Florian Fainelli Tested-by: Salvatore Bonaccorso Tested-by: Peter Schneider Tested-by: Takeshi Ogasawara Tested-by: Linux Kernel Functional Testing Tested-by: Pascal Ernster Tested-by: Dileep Malepu Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Miguel Ojeda Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman commit 300a901dc2cfc70b953a24e50d2e0683cb29b03d Author: Lijo Lazar Date: Tue Aug 5 17:40:09 2025 +0530 drm/amdgpu/vcn: Fix double-free of vcn dump buffer commit 1a0e57eb96c3fca338665ffd7d9b59f351e5fea7 upstream. The buffer is already freed as part of amdgpu_vcn_reg_dump_fini(). The issue is introduced by below patch series. Fixes: de55cbff5ce9 ("drm/amdgpu/vcn: Add regdump helper functions") Signed-off-by: Lijo Lazar Reviewed-by: Sathishkumar S Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3bd9391fe32640ebe0fdbc6811a99ed4f155bc64 Author: Marek Szyprowski Date: Mon Sep 29 13:27:30 2025 +0200 scsi: ufs: core: Fix PM QoS mutex initialization commit 0ba7a254afd037cfc2b656f379c54b43c6e574e8 upstream. hba->pm_qos_mutex is used very early as a part of ufshcd_init(), so it need to be initialized before that call. This fixes the following warning: ------------[ cut here ]------------ DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: kernel/locking/mutex.c:577 at __mutex_lock+0x268/0x894, CPU#4: kworker/u32:4/72 Modules linked in: CPU: 4 UID: 0 PID: 72 Comm: kworker/u32:4 Not tainted 6.17.0-rc7-next-20250926+ #11223 PREEMPT Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mutex_lock+0x268/0x894 lr : __mutex_lock+0x268/0x894 ... Call trace: __mutex_lock+0x268/0x894 (P) mutex_lock_nested+0x24/0x30 ufshcd_pm_qos_update+0x30/0x78 ufshcd_setup_clocks+0x2d4/0x3c4 ufshcd_init+0x234/0x126c ufshcd_pltfrm_init+0x62c/0x82c ufs_qcom_probe+0x20/0x58 platform_probe+0x5c/0xac really_probe+0xbc/0x298 __driver_probe_device+0x78/0x12c driver_probe_device+0x40/0x164 __device_attach_driver+0xb8/0x138 bus_for_each_drv+0x80/0xdc __device_attach+0xa8/0x1b0 device_initial_probe+0x14/0x20 bus_probe_device+0xb0/0xb4 deferred_probe_work_func+0x8c/0xc8 process_one_work+0x208/0x60c worker_thread+0x244/0x388 kthread+0x150/0x228 ret_from_fork+0x10/0x20 irq event stamp: 57267 hardirqs last enabled at (57267): [] _raw_spin_unlock_irqrestore+0x74/0x78 hardirqs last disabled at (57266): [] clk_enable_lock+0x7c/0xf0 softirqs last enabled at (56270): [] handle_softirqs+0x4c4/0x4dc softirqs last disabled at (56265): [] __do_softirq+0x14/0x20 ---[ end trace 0000000000000000 ]--- Fixes: 79dde5f7dc7c ("scsi: ufs: core: Fix data race in CPU latency PM QoS request handling") Signed-off-by: Marek Szyprowski Reviewed-by: Bart Van Assche Message-Id: <20250929112730.3782765-1-m.szyprowski@samsung.com> Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 534be87a958b008e7ee1182acbd73d9dcf4f3849 Author: Miaoqian Lin Date: Wed Sep 3 22:16:13 2025 +0800 usb: cdns3: cdnsp-pci: remove redundant pci_disable_device() call commit e9c206324eeb213957a567a9d066bdeb355c7491 upstream. The cdnsp-pci driver uses pcim_enable_device() to enable a PCI device, which means the device will be automatically disabled on driver detach through the managed device framework. The manual pci_disable_device() call in the error path is therefore redundant. Found via static anlaysis and this is similar to commit 99ca0b57e49f ("thermal: intel: int340x: processor: Fix warning during module unload"). Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20250903141613.2535472-1-linmq006@gmail.com Signed-off-by: Greg Kroah-Hartman commit 8d5f3bbc03d1768dc5f3090484bc82da32f6d80f Author: Konrad Dybcio Date: Tue Jul 8 12:28:42 2025 +0200 arm64: dts: qcom: qcm2290: Disable USB SS bus instances in park mode commit 27f94b71532203b079537180924023a5f636fca1 upstream. 2290 was found in the field to also require this quirk, as long & high-bandwidth workloads (e.g. USB ethernet) are consistently able to crash the controller otherwise. The same change has been made for a number of SoCs in [1], but QCM2290 somehow escaped the list (even though the very closely related SM6115 was there). Upon a controller crash, the log would read: xhci-hcd.12.auto: xHCI host not responding to stop endpoint command xhci-hcd.12.auto: xHCI host controller not responding, assume dead xhci-hcd.12.auto: HC died; cleaning up Add snps,parkmode-disable-ss-quirk to the DWC3 instance in order to prevent the aforementioned breakage. [1] https://lore.kernel.org/all/20240704152848.3380602-1-quic_kriskura@quicinc.com/ Cc: stable@vger.kernel.org Reported-by: Rob Clark Fixes: a64a0192b70c ("arm64: dts: qcom: Add initial QCM2290 device tree") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250708-topic-2290_usb-v1-1-661e70a63339@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 36b7b266517df8dc9edbba718fd106af48ba39d2 Author: Sven Peter Date: Sun Sep 14 12:56:06 2025 +0000 usb: typec: tipd: Clear interrupts first commit be5ae730ffa6fd774a00a4705c1e11e078b08ca1 upstream. Right now the interrupt handler first reads all updated status registers and only then clears the interrupts. It's possible that a duplicate interrupt for a changed register or plug state comes in after the interrupts have been processed but before they have been cleared: * plug is inserted, TPS_REG_INT_PLUG_EVENT is set * TPS_REG_INT_EVENT1 is read * tps6598x_handle_plug_event() has run and registered the plug * plug is removed again, TPS_REG_INT_PLUG_EVENT is set (again) * TPS_REG_INT_CLEAR1 is written, TPS_REG_INT_PLUG_EVENT is cleared We then have no plug connected and no pending interrupt but the tipd core still thinks there is a plug. It's possible to trigger this with e.g. a slightly broken Type-C to USB A converter. Fix this by first clearing the interrupts and only then reading the updated registers. Fixes: 45188f27b3d0 ("usb: typec: tipd: Add support for Apple CD321X") Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers") Cc: stable@kernel.org Reviewed-by: Heikki Krogerus Reviewed-by: Neal Gompa Signed-off-by: Sven Peter Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-1-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 9d8bcaf6fae1bd82bc27ec09a2694497e6f6c4b4 Author: Oleksij Rempel Date: Sun Oct 5 10:12:03 2025 +0200 net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock commit 3d3c4cd5c62f24bb3cb4511b7a95df707635e00a upstream. Prevent USB runtime PM (autosuspend) for AX88772* in bind. usbnet enables runtime PM (autosuspend) by default, so disabling it via the usb_driver flag is ineffective. On AX88772B, autosuspend shows no measurable power saving with current driver (no link partner, admin up/down). The ~0.453 W -> ~0.248 W drop on v6.1 comes from phylib powering the PHY off on admin-down, not from USB autosuspend. The real hazard is that with runtime PM enabled, ndo_open() (under RTNL) may synchronously trigger autoresume (usb_autopm_get_interface()) into asix_resume() while the USB PM lock is held. Resume paths then invoke phylink/phylib and MDIO, which also expect RTNL, leading to possible deadlocks or PM lock vs MDIO wake issues. To avoid this, keep the device runtime-PM active by taking a usage reference in ax88772_bind() and dropping it in unbind(). A non-zero PM usage count blocks runtime suspend regardless of userspace policy (.../power/control - pm_runtime_allow/forbid), making this approach robust against sysfs overrides. Holding a runtime-PM usage ref does not affect system-wide suspend; system sleep/resume callbacks continue to run as before. Fixes: 4a2c7217cd5a ("net: usb: asix: ax88772: manage PHY PM from MAC") Reported-by: Hubert Wiśniewski Closes: https://lore.kernel.org/all/DCGHG5UJT9G3.2K1GHFZ3H87T0@gmail.com Tested-by: Hubert Wiśniewski Reported-by: Marek Szyprowski Closes: https://lore.kernel.org/all/b5ea8296-f981-445d-a09a-2f389d7f6fdd@samsung.com Cc: stable@vger.kernel.org Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20251005081203.3067982-1-o.rempel@pengutronix.de Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit df8462f0fc045b4475dc494a5787a03c972ba2a2 Author: Dominique Martinet Date: Sun Jun 22 22:39:56 2025 +0900 net/9p: Fix buffer overflow in USB transport layer commit c04db81cd0288dfc68b7a0f7d09bd49b40bba451 upstream. A buffer overflow vulnerability exists in the USB 9pfs transport layer where inconsistent size validation between packet header parsing and actual data copying allows a malicious USB host to overflow heap buffers. The issue occurs because: - usb9pfs_rx_header() validates only the declared size in packet header - usb9pfs_rx_complete() uses req->actual (actual received bytes) for memcpy This allows an attacker to craft packets with small declared size (bypassing validation) but large actual payload (triggering overflow in memcpy). Add validation in usb9pfs_rx_complete() to ensure req->actual does not exceed the buffer capacity before copying data. Reported-by: Yuhao Jiang Closes: https://lkml.kernel.org/r/20250616132539.63434-1-danisjiang@gmail.com Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport") Cc: stable@vger.kernel.org Message-ID: <20250622-9p-usb_overflow-v3-1-ab172691b946@codewreck.org> Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit 2ead548473f58c7960b6b939b79503c4a0a2c0bd Author: Salah Triki Date: Mon Aug 25 10:34:35 2025 +0100 bus: fsl-mc: Check return value of platform_get_resource() commit 25f526507b8ccc6ac3a43bc094d09b1f9b0b90ae upstream. platform_get_resource() returns NULL in case of failure, so check its return value and propagate the error in order to prevent NULL pointer dereference. Fixes: 6305166c8771 ("bus: fsl-mc: Add ACPI support for fsl-mc") Cc: stable@vger.kernel.org Signed-off-by: Salah Triki Acked-by: Ioana Ciornei Link: https://lore.kernel.org/r/aKwuK6TRr5XNYQ8u@pc Signed-off-by: Christophe Leroy Signed-off-by: Greg Kroah-Hartman commit b7e0535060a60cc99eafc19cc665d979714cd73a Author: Bartosz Golaszewski Date: Tue Sep 2 13:59:10 2025 +0200 pinctrl: check the return value of pinmux_ops::get_function_name() commit 4002ee98c022d671ecc1e4a84029e9ae7d8a5603 upstream. While the API contract in docs doesn't specify it explicitly, the generic implementation of the get_function_name() callback from struct pinmux_ops - pinmux_generic_get_function_name() - can fail and return NULL. This is already checked in pinmux_check_ops() so add a similar check in pinmux_func_name_to_selector() instead of passing the returned pointer right down to strcmp() where the NULL can get dereferenced. This is normal operation when adding new pinfunctions. Cc: stable@vger.kernel.org Tested-by: Neil Armstrong Signed-off-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 6a7874ab814ce12003c46a92f7afc9b035c8e8e9 Author: Jens Wiklander Date: Fri Sep 19 10:48:31 2025 +0200 tee: fix register_shm_helper() commit d5cf5b37064b1699d946e8b7ab4ac7d7d101814c upstream. In register_shm_helper(), fix incorrect error handling for a call to iov_iter_extract_pages(). A case is missing for when iov_iter_extract_pages() only got some pages and return a number larger than 0, but not the requested amount. This fixes a possible NULL pointer dereference following a bad input from ioctl(TEE_IOC_SHM_REGISTER) where parts of the buffer isn't mapped. Cc: stable@vger.kernel.org Reported-by: Masami Ichikawa Closes: https://lore.kernel.org/op-tee/CACOXgS-Bo2W72Nj1_44c7bntyNYOavnTjJAvUbEiQfq=u9W+-g@mail.gmail.com/ Tested-by: Masami Ichikawa Fixes: 7bdee4157591 ("tee: Use iov_iter to better support shared buffer registration") Signed-off-by: Jens Wiklander Signed-off-by: Greg Kroah-Hartman commit c07923f6a8729fc27ee652221a51702ff6654097 Author: Duoming Zhou Date: Tue Sep 23 13:13:57 2025 +0800 thunderbolt: Fix use-after-free in tb_dp_dprx_work commit 67600ccfc4f38ebd331b9332ac94717bfbc87ea7 upstream. The original code relies on cancel_delayed_work() in tb_dp_dprx_stop(), which does not ensure that the delayed work item tunnel->dprx_work has fully completed if it was already running. This leads to use-after-free scenarios where tb_tunnel is deallocated by tb_tunnel_put(), while tunnel->dprx_work remains active and attempts to dereference tb_tunnel in tb_dp_dprx_work(). A typical race condition is illustrated below: CPU 0 | CPU 1 tb_dp_tunnel_active() | tb_deactivate_and_free_tunnel()| tb_dp_dprx_start() tb_tunnel_deactivate() | queue_delayed_work() tb_dp_activate() | tb_dp_dprx_stop() | tb_dp_dprx_work() //delayed worker cancel_delayed_work() | tb_tunnel_put(tunnel); | | tunnel = container_of(...); //UAF | tunnel-> //UAF Replacing cancel_delayed_work() with cancel_delayed_work_sync() is not feasible as it would introduce a deadlock: both tb_dp_dprx_work() and the cleanup path acquire tb->lock, and cancel_delayed_work_sync() would wait indefinitely for the work item that cannot proceed. Instead, implement proper reference counting: - If cancel_delayed_work() returns true (work is pending), we release the reference in the stop function. - If it returns false (work is executing or already completed), the reference is released in delayed work function itself. This ensures the tb_tunnel remains valid during work item execution while preventing memory leaks. This bug was found by static analysis. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Duoming Zhou Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 57f7fb0d1ac28540c0f6405c829bb9c3b89d8dba Author: Shin'ichiro Kawasaki Date: Tue Sep 16 11:57:56 2025 +0900 PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release commit 85afa9ea122dd9d4a2ead104a951d318975dcd25 upstream. The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be NULL even after EPF initialization. Then it is prudent to check that they have non-NULL values before releasing the channels. Add the checks in pci_epf_test_clean_dma_chan(). Without the checks, NULL pointer dereferences happen and they can lead to a kernel panic in some cases: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Call trace: dma_release_channel+0x2c/0x120 (P) pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test] pci_epc_deinit_notify+0x74/0xc0 tegra_pcie_ep_pex_rst_irq+0x250/0x5d8 irq_thread_fn+0x34/0xb8 irq_thread+0x18c/0x2e8 kthread+0x14c/0x210 ret_from_fork+0x10/0x20 Fixes: 8353813c88ef ("PCI: endpoint: Enable DMA tests for endpoints with DMA capabilities") Fixes: 5ebf3fc59bd2 ("PCI: endpoint: functions/pci-epf-test: Add DMA support to transfer data") Signed-off-by: Shin'ichiro Kawasaki [mani: trimmed the stack trace] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Damien Le Moal Reviewed-by: Krzysztof Wilczyński Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250916025756.34807-1-shinichiro.kawasaki@wdc.com Signed-off-by: Greg Kroah-Hartman commit f0164d89950120281f2446be9687cffa1e43dbcc Author: Zhen Ni Date: Tue Sep 23 19:21:09 2025 +0800 remoteproc: pru: Fix potential NULL pointer dereference in pru_rproc_set_ctable() commit d41e075b077142bb9ae5df40b9ddf9fd7821a811 upstream. pru_rproc_set_ctable() accessed rproc->priv before the IS_ERR_OR_NULL check, which could lead to a null pointer dereference. Move the pru assignment, ensuring we never dereference a NULL rproc pointer. Fixes: 102853400321 ("remoteproc: pru: Add pru_rproc_set_ctable() function") Cc: stable@vger.kernel.org Signed-off-by: Zhen Ni Link: https://lore.kernel.org/r/20250923112109.1165126-1-zhen.ni@easystack.cn Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 41683624cbff0a26bb7e0627f4a7e1b51a8779a8 Author: Breno Leitao Date: Mon Sep 29 02:15:47 2025 -0700 PCI/AER: Avoid NULL pointer dereference in aer_ratelimit() commit deb2f228388ff3a9d0623e3b59a053e9235c341d upstream. When platform firmware supplies error information to the OS, e.g., via the ACPI APEI GHES mechanism, it may identify an error source device that doesn't advertise an AER Capability and therefore dev->aer_info, which contains AER stats and ratelimiting data, is NULL. pci_dev_aer_stats_incr() already checks dev->aer_info for NULL, but aer_ratelimit() did not, leading to NULL pointer dereferences like this one from the URL below: {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0 {1}[Hardware Error]: event severity: corrected {1}[Hardware Error]: device_id: 0000:00:00.0 {1}[Hardware Error]: vendor_id: 0x8086, device_id: 0x2020 {1}[Hardware Error]: aer_cor_status: 0x00001000, aer_cor_mask: 0x00002000 BUG: kernel NULL pointer dereference, address: 0000000000000264 RIP: 0010:___ratelimit+0xc/0x1b0 pci_print_aer+0x141/0x360 aer_recover_work_func+0xb5/0x130 [8086:2020] is an Intel "Sky Lake-E DMI3 Registers" device that claims to be a Root Port but does not advertise an AER Capability. Add a NULL check in aer_ratelimit() to avoid the NULL pointer dereference. Note that this also prevents ratelimiting these events from GHES. Fixes: a57f2bfb4a5863 ("PCI/AER: Ratelimit correctable and non-fatal error logging") Link: https://lore.kernel.org/r/buduna6darbvwfg3aogl5kimyxkggu3n4romnmq6sozut6axeu@clnx7sfsy457/ Signed-off-by: Breno Leitao [bhelgaas: add crash details to commit log] Signed-off-by: Bjorn Helgaas Reviewed-by: Kuppuswamy Sathyanarayanan Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250929-aer_crash_2-v1-1-68ec4f81c356@debian.org Signed-off-by: Greg Kroah-Hartman commit ab9a70cd2386a0d70c164b0905dd66bc9af52e77 Author: Lei Lu Date: Mon Aug 11 21:58:48 2025 +0800 sunrpc: fix null pointer dereference on zero-length checksum commit 6df164e29bd4e6505c5a2e0e5f1e1f6957a16a42 upstream. In xdr_stream_decode_opaque_auth(), zero-length checksum.len causes checksum.data to be set to NULL. This triggers a NPD when accessing checksum.data in gss_krb5_verify_mic_v2(). This patch ensures that the value of checksum.len is not less than XDR_UNIT. Fixes: 0653028e8f1c ("SUNRPC: Convert gss_verify_header() to use xdr_stream") Cc: stable@kernel.org Signed-off-by: Lei Lu Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit f5e1f3b85aadce74268c46676772c3e9fa79897e Author: Zhen Ni Date: Sun Sep 28 14:37:37 2025 +0800 Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak commit d3366a04770eea807f2826cbdb96934dd8c9bf79 upstream. Struct ff_effect_compat is embedded twice inside uinput_ff_upload_compat, contains internal padding. In particular, there is a hole after struct ff_replay to satisfy alignment requirements for the following union member. Without clearing the structure, copy_to_user() may leak stack data to userspace. Initialize ff_up_compat to zero before filling valid fields. Fixes: 2d56f3a32c0e ("Input: refactor evdev 32bit compat to be shareable with uinput") Cc: stable@vger.kernel.org Signed-off-by: Zhen Ni Link: https://lore.kernel.org/r/20250928063737.74590-1-zhen.ni@easystack.cn Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit f652c7036bdea82fd978fe685604be5065cf12b9 Author: Marek Vasut Date: Sun Oct 5 04:33:10 2025 +0200 Input: atmel_mxt_ts - allow reset GPIO to sleep commit c7866ee0a9ddd9789faadf58cdac6abd7aabf045 upstream. The reset GPIO is not toggled in any critical section where it couldn't sleep, allow the reset GPIO to sleep. This allows the driver to operate reset GPIOs connected to I2C GPIO expanders. Signed-off-by: Marek Vasut Link: https://lore.kernel.org/r/20251005023335.166483-1-marek.vasut@mailbox.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit f3f59bab68e9bc714f757ab22f3fb36153014043 Author: Ling Xu Date: Fri Sep 12 14:12:36 2025 +0100 misc: fastrpc: Skip reference for DMA handles commit 10df039834f84a297c72ec962c0f9b7c8c5ca31a upstream. If multiple dma handles are passed with same fd over a remote call the kernel driver takes a reference and expects that put for the map will be called as many times to free the map. But DSP only updates the fd one time in the fd list when the DSP refcount goes to zero and hence kernel make put call only once for the fd. This can cause SMMU fault issue as the same fd can be used in future for some other call. Fixes: 35a82b87135d ("misc: fastrpc: Add dma handle implementation") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta Signed-off-by: Ekansh Gupta Signed-off-by: Ling Xu Reviewed-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250912131236.303102-5-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit c000f65f0ac93d9f9cc69a230d372f6ca93e4879 Author: Ling Xu Date: Fri Sep 12 14:12:35 2025 +0100 misc: fastrpc: fix possible map leak in fastrpc_put_args commit da1ba64176e0138f2bfa96f9e43e8c3640d01e1e upstream. copy_to_user() failure would cause an early return without cleaning up the fdlist, which has been updated by the DSP. This could lead to map leak. Fix this by redirecting to a cleanup path on failure, ensuring that all mapped buffers are properly released before returning. Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta Signed-off-by: Ekansh Gupta Signed-off-by: Ling Xu Reviewed-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250912131236.303102-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 1986bba9597b3d97d3e80530dc457a1cd1994e22 Author: Ling Xu Date: Fri Sep 12 14:12:34 2025 +0100 misc: fastrpc: Fix fastrpc_map_lookup operation commit 9031626ade38b092b72638dfe0c6ffce8d8acd43 upstream. Fastrpc driver creates maps for user allocated fd buffers. Before creating a new map, the map list is checked for any already existing maps using map fd. Checking with just map fd is not sufficient as the user can pass offsetted buffer with less size when the map is created and then a larger size the next time which could result in memory issues. Check for dma_buf object also when looking up for the map. Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta Signed-off-by: Ekansh Gupta Signed-off-by: Ling Xu Reviewed-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250912131236.303102-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 19ea9b234e2c9462230922f08b1b3b2dec37578d Author: Ling Xu Date: Fri Sep 12 14:12:33 2025 +0100 misc: fastrpc: Save actual DMA size in fastrpc_map structure commit 8b5b456222fd604079b5cf2af1f25ad690f54a25 upstream. For user passed fd buffer, map is created using DMA calls. The map related information is stored in fastrpc_map structure. The actual DMA size is not stored in the structure. Store the actual size of buffer and check it against the user passed size. Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method") Cc: stable@kernel.org Reviewed-by: Dmitry Baryshkov Co-developed-by: Ekansh Gupta Signed-off-by: Ekansh Gupta Signed-off-by: Ling Xu Reviewed-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250912131236.303102-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8aea9d512c65eed0dad98b8d65ce74fe77c01b34 Author: Guangshuo Li Date: Thu Sep 25 14:44:48 2025 +0800 nvdimm: ndtest: Return -ENOMEM if devm_kcalloc() fails in ndtest_probe() commit a9e6aa994917ee602798bbb03180a194b37865bb upstream. devm_kcalloc() may fail. ndtest_probe() allocates three DMA address arrays (dcr_dma, label_dma, dimm_dma) and later unconditionally uses them in ndtest_nvdimm_init(), which can lead to a NULL pointer dereference under low-memory conditions. Check all three allocations and return -ENOMEM if any allocation fails, jumping to the common error path. Do not emit an extra error message since the allocator already warns on allocation failure. Fixes: 9399ab61ad82 ("ndtest: Add dimms to the two buses") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Alison Schofield Reviewed-by: Ira Weiny Reviewed-by: Dave Jiang Signed-off-by: Ira Weiny Signed-off-by: Greg Kroah-Hartman commit 170cec233eabe721affc91466d7ecd172cc657e7 Author: Lance Yang Date: Wed Sep 17 21:31:37 2025 +0800 selftests/mm: skip soft-dirty tests when CONFIG_MEM_SOFT_DIRTY is disabled commit 0389c305ef56cbadca4cbef44affc0ec3213ed30 upstream. The madv_populate and soft-dirty kselftests currently fail on systems where CONFIG_MEM_SOFT_DIRTY is disabled. Introduce a new helper softdirty_supported() into vm_util.c/h to ensure tests are properly skipped when the feature is not enabled. Link: https://lkml.kernel.org/r/20250917133137.62802-1-lance.yang@linux.dev Fixes: 9f3265db6ae8 ("selftests: vm: add test for Soft-Dirty PTE bit") Signed-off-by: Lance Yang Acked-by: David Hildenbrand Suggested-by: David Hildenbrand Cc: Lorenzo Stoakes Cc: Shuah Khan Cc: Gabriel Krisman Bertazi Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c6096f3947f68f96defedb8764b3b1ca4cf3469f Author: Yang Shi Date: Mon Sep 29 13:24:02 2025 -0700 mm: hugetlb: avoid soft lockup when mprotect to large memory area commit f52ce0ea90c83a28904c7cc203a70e6434adfecb upstream. When calling mprotect() to a large hugetlb memory area in our customer's workload (~300GB hugetlb memory), soft lockup was observed: watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916] CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7 Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025 pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mte_clear_page_tags+0x14/0x24 lr : mte_sync_tags+0x1c0/0x240 sp : ffff80003150bb80 x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000 x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458 x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000 x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2c x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000 x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000 Call trace:   mte_clear_page_tags+0x14/0x24   set_huge_pte_at+0x25c/0x280   hugetlb_change_protection+0x220/0x430   change_protection+0x5c/0x8c   mprotect_fixup+0x10c/0x294   do_mprotect_pkey.constprop.0+0x2e0/0x3d4   __arm64_sys_mprotect+0x24/0x44   invoke_syscall+0x50/0x160   el0_svc_common+0x48/0x144   do_el0_svc+0x30/0xe0   el0_svc+0x30/0xf0   el0t_64_sync_handler+0xc4/0x148   el0t_64_sync+0x1a4/0x1a8 Soft lockup is not triggered with THP or base page because there is cond_resched() called for each PMD size. Although the soft lockup was triggered by MTE, it should be not MTE specific. The other processing which takes long time in the loop may trigger soft lockup too. So add cond_resched() for hugetlb to avoid soft lockup. Link: https://lkml.kernel.org/r/20250929202402.1663290-1-yang@os.amperecomputing.com Fixes: 8f860591ffb2 ("[PATCH] Enable mprotect on huge pages") Signed-off-by: Yang Shi Tested-by: Carl Worth Reviewed-by: Christoph Lameter (Ampere) Reviewed-by: Catalin Marinas Acked-by: David Hildenbrand Acked-by: Oscar Salvador Reviewed-by: Anshuman Khandual Reviewed-by: Dev Jain Cc: Muchun Song Cc: Will Deacon Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b6ff0d8de8452ec0e18e5bd7394c2a23e7ff7353 Author: Janne Grunau Date: Mon Sep 15 08:36:41 2025 +0200 fbdev: simplefb: Fix use after free in simplefb_detach_genpds() commit da1bb9135213744e7ec398826c8f2e843de4fb94 upstream. The pm_domain cleanup can not be devres managed as it uses struct simplefb_par which is allocated within struct fb_info by framebuffer_alloc(). This allocation is explicitly freed by unregister_framebuffer() in simplefb_remove(). Devres managed cleanup runs after the device remove call and thus can no longer access struct simplefb_par. Call simplefb_detach_genpds() explicitly from simplefb_destroy() like the cleanup functions for clocks and regulators. Fixes an use after free on M2 Mac mini during aperture_remove_conflicting_devices() using the downstream asahi kernel with Debian's kernel config. For unknown reasons this started to consistently dereference an invalid pointer in v6.16.3 based kernels. [ 6.736134] BUG: KASAN: slab-use-after-free in simplefb_detach_genpds+0x58/0x220 [ 6.743545] Read of size 4 at addr ffff8000304743f0 by task (udev-worker)/227 [ 6.750697] [ 6.752182] CPU: 6 UID: 0 PID: 227 Comm: (udev-worker) Tainted: G S 6.16.3-asahi+ #16 PREEMPTLAZY [ 6.752186] Tainted: [S]=CPU_OUT_OF_SPEC [ 6.752187] Hardware name: Apple Mac mini (M2, 2023) (DT) [ 6.752189] Call trace: [ 6.752190] show_stack+0x34/0x98 (C) [ 6.752194] dump_stack_lvl+0x60/0x80 [ 6.752197] print_report+0x17c/0x4d8 [ 6.752201] kasan_report+0xb4/0x100 [ 6.752206] __asan_report_load4_noabort+0x20/0x30 [ 6.752209] simplefb_detach_genpds+0x58/0x220 [ 6.752213] devm_action_release+0x50/0x98 [ 6.752216] release_nodes+0xd0/0x2c8 [ 6.752219] devres_release_all+0xfc/0x178 [ 6.752221] device_unbind_cleanup+0x28/0x168 [ 6.752224] device_release_driver_internal+0x34c/0x470 [ 6.752228] device_release_driver+0x20/0x38 [ 6.752231] bus_remove_device+0x1b0/0x380 [ 6.752234] device_del+0x314/0x820 [ 6.752238] platform_device_del+0x3c/0x1e8 [ 6.752242] platform_device_unregister+0x20/0x50 [ 6.752246] aperture_detach_platform_device+0x1c/0x30 [ 6.752250] aperture_detach_devices+0x16c/0x290 [ 6.752253] aperture_remove_conflicting_devices+0x34/0x50 ... [ 6.752343] [ 6.967409] Allocated by task 62: [ 6.970724] kasan_save_stack+0x3c/0x70 [ 6.974560] kasan_save_track+0x20/0x40 [ 6.978397] kasan_save_alloc_info+0x40/0x58 [ 6.982670] __kasan_kmalloc+0xd4/0xd8 [ 6.986420] __kmalloc_noprof+0x194/0x540 [ 6.990432] framebuffer_alloc+0xc8/0x130 [ 6.994444] simplefb_probe+0x258/0x2378 ... [ 7.054356] [ 7.055838] Freed by task 227: [ 7.058891] kasan_save_stack+0x3c/0x70 [ 7.062727] kasan_save_track+0x20/0x40 [ 7.066565] kasan_save_free_info+0x4c/0x80 [ 7.070751] __kasan_slab_free+0x6c/0xa0 [ 7.074675] kfree+0x10c/0x380 [ 7.077727] framebuffer_release+0x5c/0x90 [ 7.081826] simplefb_destroy+0x1b4/0x2c0 [ 7.085837] put_fb_info+0x98/0x100 [ 7.089326] unregister_framebuffer+0x178/0x320 [ 7.093861] simplefb_remove+0x3c/0x60 [ 7.097611] platform_remove+0x60/0x98 [ 7.101361] device_remove+0xb8/0x160 [ 7.105024] device_release_driver_internal+0x2fc/0x470 [ 7.110256] device_release_driver+0x20/0x38 [ 7.114529] bus_remove_device+0x1b0/0x380 [ 7.118628] device_del+0x314/0x820 [ 7.122116] platform_device_del+0x3c/0x1e8 [ 7.126302] platform_device_unregister+0x20/0x50 [ 7.131012] aperture_detach_platform_device+0x1c/0x30 [ 7.136157] aperture_detach_devices+0x16c/0x290 [ 7.140779] aperture_remove_conflicting_devices+0x34/0x50 ... Reported-by: Daniel Huhardeaux Cc: stable@vger.kernel.org Fixes: 92a511a568e44 ("fbdev/simplefb: Add support for generic power-domains") Signed-off-by: Janne Grunau Reviewed-by: Hans de Goede Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit da2a3c231f7f2a5ac146d972b8c1d7d84aff6d70 Author: Sean Christopherson Date: Tue Aug 5 12:05:09 2025 -0700 KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid commit 0910dd7c9ad45a2605c45fd2bf3d1bcac087687c upstream. Skip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIP isn't valid, e.g. because KVM is running with nrips=false. SVM must decode and emulate to skip the instruction if the CPU doesn't provide the next RIP, and getting the instruction bytes to decode requires reading guest memory. Reading guest memory through the emulator can fault, i.e. can sleep, which is disallowed since the fastpath handlers run with IRQs disabled. BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 30580 hardirqs last enabled at (30579): [] vcpu_run+0x1787/0x1db0 [kvm] hardirqs last disabled at (30580): [] __schedule+0x1e2/0xed0 softirqs last enabled at (30570): [] fpu_swap_kvm_fpstate+0x44/0x210 softirqs last disabled at (30568): [] fpu_swap_kvm_fpstate+0x44/0x210 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE Tainted: [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025 Call Trace: dump_stack_lvl+0x7d/0xb0 __might_resched+0x271/0x290 __might_fault+0x28/0x80 kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm] kvm_fetch_guest_virt+0x92/0xc0 [kvm] __do_insn_fetch_bytes+0xf3/0x1e0 [kvm] x86_decode_insn+0xd1/0x1010 [kvm] x86_emulate_instruction+0x105/0x810 [kvm] __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd] handle_fastpath_invd+0xc4/0x1a0 [kvm] vcpu_run+0x11a1/0x1db0 [kvm] kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm] kvm_vcpu_ioctl+0x578/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x8a/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f479d57a94b Note, this is essentially a reapply of commit 5c30e8101e8d ("KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"), but with different justification (KVM now grabs SRCU when skipping the instruction for other reasons). Fixes: b439eb8ab578 ("Revert "KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250805190526.1453366-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 1d73b52d2099de5b51e9d89810ef7e663456262a Author: Jan Kara Date: Thu Sep 25 14:30:39 2025 +0200 ext4: fix checks for orphan inodes commit acf943e9768ec9d9be80982ca0ebc4bfd6b7631e upstream. When orphan file feature is enabled, inode can be tracked as orphan either in the standard orphan list or in the orphan file. The first can be tested by checking ei->i_orphan list head, the second is recorded by EXT4_STATE_ORPHAN_FILE inode state flag. There are several places where we want to check whether inode is tracked as orphan and only some of them properly check for both possibilities. Luckily the consequences are mostly minor, the worst that can happen is that we track an inode as orphan although we don't need to and e2fsck then complains (resulting in occasional ext4/307 xfstest failures). Fix the problem by introducing a helper for checking whether an inode is tracked as orphan and use it in appropriate places. Fixes: 4a79a98c7b19 ("ext4: Improve scalability of ext4 orphan file handling") Cc: stable@kernel.org Signed-off-by: Jan Kara Reviewed-by: Zhang Yi Message-ID: <20250925123038.20264-2-jack@suse.cz> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 00110f3cfc9b34b2dfee2a6c9e55a0ae6df125ae Author: Baokun Li Date: Mon Aug 25 11:38:30 2025 +0800 ext4: fix potential null deref in ext4_mb_init() commit 3c3fac6bc0a9c00dbe65d8dc0d3a282afe4d3188 upstream. In ext4_mb_init(), ext4_mb_avg_fragment_size_destroy() may be called when sbi->s_mb_avg_fragment_size remains uninitialized (e.g., if groupinfo slab cache allocation fails). Since ext4_mb_avg_fragment_size_destroy() lacks null pointer checking, this leads to a null pointer dereference. ================================================================== EXT4-fs: no memory for groupinfo slab cache BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0002 [#1] SMP PTI CPU:2 UID: 0 PID: 87 Comm:mount Not tainted 6.17.0-rc2 #1134 PREEMPT(none) RIP: 0010:_raw_spin_lock_irqsave+0x1b/0x40 Call Trace: xa_destroy+0x61/0x130 ext4_mb_init+0x483/0x540 __ext4_fill_super+0x116d/0x17b0 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 do_new_mount+0x197/0x300 __x64_sys_mount+0x116/0x150 do_syscall_64+0x50/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore, add necessary null check to ext4_mb_avg_fragment_size_destroy() to prevent this issue. The same fix is also applied to ext4_mb_largest_free_orders_destroy(). Reported-by: syzbot+1713b1aa266195b916c2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1713b1aa266195b916c2 Cc: stable@kernel.org Fixes: f7eaacbb4e54 ("ext4: convert free groups order lists to xarrays") Signed-off-by: Baokun Li Reviewed-by: Zhang Yi Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 985bfd3b4ec8eeb79a9d41fe0002dab21e5cf0db Author: Namjae Jeon Date: Wed Oct 1 09:25:35 2025 +0900 ksmbd: add max ip connections parameter commit d8b6dc9256762293048bf122fc11c4e612d0ef5d upstream. This parameter set the maximum number of connections per ip address. The default is 8. Cc: stable@vger.kernel.org Fixes: c0d41112f1a5 ("ksmbd: extend the connection limiting mechanism to support IPv6") Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b229c11723eddf825a55f23c1701fc89f1a0a9a0 Author: Matvey Kovalev Date: Thu Sep 25 15:12:34 2025 +0300 ksmbd: fix error code overwriting in smb2_get_info_filesystem() commit 88daf2f448aad05a2e6df738d66fe8b0cf85cee0 upstream. If client doesn't negotiate with SMB3.1.1 POSIX Extensions, then proper error code won't be returned due to overwriting. Return error immediately. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: e2f34481b24db ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: Matvey Kovalev Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6bd7e0e55dcea2cf0d391bbc21c2eb069b4be3e1 Author: Yunseong Kim Date: Mon Sep 15 22:44:09 2025 +0000 ksmbd: Fix race condition in RPC handle list access commit 305853cce379407090a73b38c5de5ba748893aee upstream. The 'sess->rpc_handle_list' XArray manages RPC handles within a ksmbd session. Access to this list is intended to be protected by 'sess->rpc_lock' (an rw_semaphore). However, the locking implementation was flawed, leading to potential race conditions. In ksmbd_session_rpc_open(), the code incorrectly acquired only a read lock before calling xa_store() and xa_erase(). Since these operations modify the XArray structure, a write lock is required to ensure exclusive access and prevent data corruption from concurrent modifications. Furthermore, ksmbd_session_rpc_method() accessed the list using xa_load() without holding any lock at all. This could lead to reading inconsistent data or a potential use-after-free if an entry is concurrently removed and the pointer is dereferenced. Fix these issues by: 1. Using down_write() and up_write() in ksmbd_session_rpc_open() to ensure exclusive access during XArray modification, and ensuring the lock is correctly released on error paths. 2. Adding down_read() and up_read() in ksmbd_session_rpc_method() to safely protect the lookup. Fixes: a1f46c99d9ea ("ksmbd: fix use-after-free in ksmbd_session_rpc_open") Fixes: b685757c7b08 ("ksmbd: Implements sess->rpc_handle_list as xarray") Cc: stable@vger.kernel.org Signed-off-by: Yunseong Kim Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 76385629f45740b7888f8fcd83bde955b10f61fe Author: Jakub Acs Date: Wed Oct 1 09:03:52 2025 +0000 mm/ksm: fix flag-dropping behavior in ksm_madvise commit f04aad36a07cc17b7a5d5b9a2d386ce6fae63e93 upstream. syzkaller discovered the following crash: (kernel BUG) [ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460 [ 44.617726] Call Trace: [ 44.617926] [ 44.619284] userfaultfd_release+0xef/0x1b0 [ 44.620976] __fput+0x3f9/0xb60 [ 44.621240] fput_close_sync+0x110/0x210 [ 44.622222] __x64_sys_close+0x8f/0x120 [ 44.622530] do_syscall_64+0x5b/0x2f0 [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227 Kernel panics because it detects UFFD inconsistency during userfaultfd_release_all(). Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags. The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags. Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VM_MERGEABLE assignment. VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value. Fix it by changing `VM_MERGEABLE` constant to unsigned long, using the BIT() macro. Note: other VM_* flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_* flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s. Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place: [ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067 but the root-cause (flag-drop) remains the same. [akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel] Link: https://lore.kernel.org/oe-kbuild-all/202510030449.VfSaAjvd-lkp@intel.com/ Link: https://lkml.kernel.org/r/20251001090353.57523-2-acsjakub@amazon.de Fixes: 7677f7fd8be7 ("userfaultfd: add minor fault registration mode") Signed-off-by: Jakub Acs Signed-off-by: Miguel Ojeda Acked-by: David Hildenbrand Acked-by: SeongJae Park Tested-by: Alice Ryhl Tested-by: Miguel Ojeda Cc: Xu Xin Cc: Chengming Zhou Cc: Peter Xu Cc: Axel Rasmussen Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8cb75d920e787e788dad77ac8f1b1717f8b00e3d Author: Huacai Chen Date: Thu Oct 2 22:39:52 2025 +0800 LoongArch: BPF: Fix uninitialized symbol 'retval_off' commit 7b6c2d172d023d344527d3cb4516d0d6b29f4919 upstream. In __arch_prepare_bpf_trampoline(), retval_off is meaningful only when save_ret is not 0, so the current logic is correct. But it may cause a build warning: arch/loongarch/net/bpf_jit.c:1547 __arch_prepare_bpf_trampoline() error: uninitialized symbol 'retval_off'. So initialize retval_off unconditionally to fix it. Cc: stable@vger.kernel.org Fixes: f9b6b41f0cf3 ("LoongArch: BPF: Add basic bpf trampoline support") Closes: https://lore.kernel.org/r/202508191020.PBBh07cK-lkp@intel.com/ Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 49fde129d9270cb2953426e992e58cef43066a4b Author: Hengqi Chen Date: Thu Oct 2 22:39:52 2025 +0800 LoongArch: BPF: Remove duplicated flags check commit 909d3e3f51b1bc00f33a484ce0d41b42fed01965 upstream. The check for (BPF_TRAMP_F_ORIG_STACK | BPF_TRAMP_F_SHARE_IPMODIFY) is duplicated in __arch_prepare_bpf_trampoline(). Remove it. While at it, make sure stack_size and nargs are initialized once. Cc: stable@vger.kernel.org Tested-by: Vincent Li Signed-off-by: Hengqi Chen Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 7ad3d6a3c96184e74a739fa18e9ffbd639889905 Author: Hengqi Chen Date: Thu Oct 2 22:39:52 2025 +0800 LoongArch: BPF: No text_poke() for kernel text commit 3d770bd11b943066db11dba7be0b6f0d81cb5d50 upstream. The current implementation of bpf_arch_text_poke() requires 5 nops at patch site which is not applicable for kernel/module functions. Because LoongArch reserves ONLY 2 nops at the function entry. With CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS=y, this can be done by ftrace instead. See the following commit for details: * commit b91e014f078e ("bpf: Make BPF trampoline use register_ftrace_direct() API") * commit 9cdc3b6a299c ("LoongArch: ftrace: Add direct call support") Cc: stable@vger.kernel.org Tested-by: Vincent Li Signed-off-by: Hengqi Chen Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 1232e91c0abc83158447ac989cfee3ed1f68ad30 Author: Hengqi Chen Date: Thu Oct 2 22:39:52 2025 +0800 LoongArch: BPF: Remove duplicated bpf_flush_icache() commit b0f50dc09bf008b2e581d5e6ad570d325725881c upstream. The bpf_flush_icache() is called by bpf_arch_text_copy() already. So remove it. This has been done in arm64 and riscv. Cc: stable@vger.kernel.org Tested-by: Vincent Li Signed-off-by: Hengqi Chen Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 5c3fc72bf4715c30b3762e5009f4999813035626 Author: Hengqi Chen Date: Thu Oct 2 22:39:53 2025 +0800 LoongArch: BPF: Make error handling robust in arch_prepare_bpf_trampoline() commit de2c0b7788648850b68b75f7cc8698b2749dd31e upstream. Bail out instead of trying to perform a bpf_arch_text_copy() if __arch_prepare_bpf_trampoline() failed. Cc: stable@vger.kernel.org Tested-by: Vincent Li Signed-off-by: Hengqi Chen Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 31bc07df75c191b04ab559f22aa7317d3d33fdb0 Author: Hengqi Chen Date: Thu Oct 2 22:39:52 2025 +0800 LoongArch: BPF: Make trampoline size stable commit ea645cfd3d5f74a2bd40a60003f113b3c467975d upstream. When attach fentry/fexit BPF programs, __arch_prepare_bpf_trampoline() is called twice with different `struct bpf_tramp_image *im`: bpf_trampoline_update() -> arch_bpf_trampoline_size() -> __arch_prepare_bpf_trampoline() -> arch_prepare_bpf_trampoline() -> __arch_prepare_bpf_trampoline() Use move_imm() will emit unstable instruction sequences, so let's use move_addr() instead to prevent subtle bugs. (I observed this while debugging other issues with printk.) Cc: stable@vger.kernel.org Tested-by: Vincent Li Signed-off-by: Hengqi Chen Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 40cfed5204200760113c5cc33bee7d8fe81759d2 Author: Hengqi Chen Date: Thu Oct 2 22:39:52 2025 +0800 LoongArch: BPF: Don't align trampoline size commit a04731cbee6e981afa4263289a0c0059c8b2e7b9 upstream. Currently, arch_alloc_bpf_trampoline() use bpf_prog_pack_alloc() which will pack multiple trampolines into a huge page. So, no need to assume the trampoline size is page aligned. Cc: stable@vger.kernel.org Tested-by: Vincent Li Signed-off-by: Hengqi Chen Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit d1158559315143e11bfaabcd4b2bea98c7ed1be9 Author: Hengqi Chen Date: Thu Oct 2 22:39:52 2025 +0800 LoongArch: BPF: No support of struct argument in trampoline programs commit e82406c7cbdd368c5459b8a45e118811d2ba0794 upstream. The current implementation does not support struct argument. This causes a oops when running bpf selftest: $ ./test_progs -a tracing_struct Oops[#1]: CPU -1 Unable to handle kernel paging request at virtual address 0000000000000018, era == 9000000085bef268, ra == 90000000844f3938 rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: 1-...0: (19 ticks this GP) idle=1094/1/0x4000000000000000 softirq=1380/1382 fqs=801 rcu: (detected by 0, t=5252 jiffies, g=1197, q=52 ncpus=4) Sending NMI from CPU 0 to CPUs 1: rcu: rcu_preempt kthread starved for 2495 jiffies! g1197 f0x0 RCU_GP_DOING_FQS(6) ->state=0x0 ->cpu=2 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. rcu: RCU grace-period kthread stack dump: task:rcu_preempt state:I stack:0 pid:15 tgid:15 ppid:2 task_flags:0x208040 flags:0x00000800 Stack : 9000000100423e80 0000000000000402 0000000000000010 90000001003b0680 9000000085d88000 0000000000000000 0000000000000040 9000000087159350 9000000085c2b9b0 0000000000000001 900000008704a000 0000000000000005 00000000ffff355b 00000000ffff355b 0000000000000000 0000000000000004 9000000085d90510 0000000000000000 0000000000000002 7b5d998f8281e86e 00000000ffff355c 7b5d998f8281e86e 000000000000003f 9000000087159350 900000008715bf98 0000000000000005 9000000087036000 900000008704a000 9000000100407c98 90000001003aff80 900000008715c4c0 9000000085c2b9b0 00000000ffff355b 9000000085c33d3c 00000000000000b4 0000000000000000 9000000007002150 00000000ffff355b 9000000084615480 0000000007000002 ... Call Trace: [<9000000085c2a868>] __schedule+0x410/0x1520 [<9000000085c2b9ac>] schedule+0x34/0x190 [<9000000085c33d38>] schedule_timeout+0x98/0x140 [<90000000845e9120>] rcu_gp_fqs_loop+0x5f8/0x868 [<90000000845ed538>] rcu_gp_kthread+0x260/0x2e0 [<900000008454e8a4>] kthread+0x144/0x238 [<9000000085c26b60>] ret_from_kernel_thread+0x28/0xc8 [<90000000844f20e4>] ret_from_kernel_thread_asm+0xc/0x88 rcu: Stack dump where RCU GP kthread last ran: Sending NMI from CPU 0 to CPUs 2: NMI backtrace for cpu 2 skipped: idling at idle_exit+0x0/0x4 Reject it for now. Cc: stable@vger.kernel.org Fixes: f9b6b41f0cf3 ("LoongArch: BPF: Add basic bpf trampoline support") Tested-by: Vincent Li Signed-off-by: Hengqi Chen Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 9f3169bb3c2967166b4f4433cf152a84f3eb95d0 Author: Hengqi Chen Date: Thu Oct 2 22:39:53 2025 +0800 LoongArch: BPF: Sign-extend struct ops return values properly commit 8b51b11b3d81c1ed48a52f87da9256d737b723a0 upstream. The ns_bpf_qdisc selftest triggers a kernel panic: Oops[#1]: CPU 0 Unable to handle kernel paging request at virtual address 0000000000741d58, era == 90000000851b5ac0, ra == 90000000851b5aa4 CPU: 0 UID: 0 PID: 449 Comm: test_progs Tainted: G OE 6.16.0+ #3 PREEMPT(full) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 pc 90000000851b5ac0 ra 90000000851b5aa4 tp 90000001076b8000 sp 90000001076bb600 a0 0000000000741ce8 a1 0000000000000001 a2 90000001076bb5c0 a3 0000000000000008 a4 90000001004c4620 a5 9000000100741ce8 a6 0000000000000000 a7 0100000000000000 t0 0000000000000010 t1 0000000000000000 t2 9000000104d24d30 t3 0000000000000001 t4 4f2317da8a7e08c4 t5 fffffefffc002f00 t6 90000001004c4620 t7 ffffffffc61c5b3d t8 0000000000000000 u0 0000000000000001 s9 0000000000000050 s0 90000001075bc800 s1 0000000000000040 s2 900000010597c400 s3 0000000000000008 s4 90000001075bc880 s5 90000001075bc8f0 s6 0000000000000000 s7 0000000000741ce8 s8 0000000000000000 ra: 90000000851b5aa4 __qdisc_run+0xac/0x8d8 ERA: 90000000851b5ac0 __qdisc_run+0xc8/0x8d8 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) BADV: 0000000000741d58 PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)] Process test_progs (pid: 449, threadinfo=000000009af02b3a, task=00000000e9ba4956) Stack : 0000000000000000 90000001075bc8ac 90000000869524a8 9000000100741ce8 90000001075bc800 9000000100415300 90000001075bc8ac 0000000000000000 900000010597c400 900000008694a000 0000000000000000 9000000105b59000 90000001075bc800 9000000100741ce8 0000000000000050 900000008513000c 9000000086936000 0000000100094d4c fffffff400676208 0000000000000000 9000000105b59000 900000008694a000 9000000086bf0dc0 9000000105b59000 9000000086bf0d68 9000000085147010 90000001075be788 0000000000000000 9000000086bf0f98 0000000000000001 0000000000000010 9000000006015840 0000000000000000 9000000086be6c40 0000000000000000 0000000000000000 0000000000000000 4f2317da8a7e08c4 0000000000000101 4f2317da8a7e08c4 ... Call Trace: [<90000000851b5ac0>] __qdisc_run+0xc8/0x8d8 [<9000000085130008>] __dev_queue_xmit+0x578/0x10f0 [<90000000853701c0>] ip6_finish_output2+0x2f0/0x950 [<9000000085374bc8>] ip6_finish_output+0x2b8/0x448 [<9000000085370b24>] ip6_xmit+0x304/0x858 [<90000000853c4438>] inet6_csk_xmit+0x100/0x170 [<90000000852b32f0>] __tcp_transmit_skb+0x490/0xdd0 [<90000000852b47fc>] tcp_connect+0xbcc/0x1168 [<90000000853b9088>] tcp_v6_connect+0x580/0x8a0 [<90000000852e7738>] __inet_stream_connect+0x170/0x480 [<90000000852e7a98>] inet_stream_connect+0x50/0x88 [<90000000850f2814>] __sys_connect+0xe4/0x110 [<90000000850f2858>] sys_connect+0x18/0x28 [<9000000085520c94>] do_syscall+0x94/0x1a0 [<9000000083df1fb8>] handle_syscall+0xb8/0x158 Code: 4001ad80 2400873f 2400832d <240073cc> 001137ff 001133ff 6407b41f 001503cc 0280041d ---[ end trace 0000000000000000 ]--- The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer is treated as a 32bit value and sign extend to 64bit in epilogue. This behavior is right for most bpf prog types but wrong for struct ops which requires LoongArch ABI. So let's sign extend struct ops return values according to the LoongArch ABI ([1]) and return value spec in function model. [1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html Cc: stable@vger.kernel.org Fixes: 6abf17d690d8 ("LoongArch: BPF: Add struct ops support for trampoline") Signed-off-by: Hengqi Chen Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 366dff8a4003d74b3d4668f90c5f0575d78bbaa3 Author: Xi Ruoyao Date: Sat Aug 16 18:49:05 2025 +0800 pwm: loongson: Fix LOONGSON_PWM_FREQ_DEFAULT commit 75604e9a5b60707722028947d6dc6bdacb42282e upstream. Per the 7A1000 and 7A2000 user manual, the clock frequency of their PWM controllers is 50 MHz, not 50 kHz. Fixes: 2b62c89448dd ("pwm: Add Loongson PWM controller support") Signed-off-by: Xi Ruoyao Reviewed-by: Binbin Zhou Reviewed-by: Huacai Chen Link: https://lore.kernel.org/r/20250816104904.4779-2-xry111@xry111.site Cc: stable@vger.kernel.org Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit e53ef27ffa9ea5e70987e4aa87c10408331ed4d2 Author: Youling Tang Date: Thu Oct 2 22:39:08 2025 +0800 LoongArch: Automatically disable kaslr if boot from kexec_file commit c8168b4faf1d62cbb320a3e518ad31cdd567cb05 upstream. Automatically disable kaslr when the kernel loads from kexec_file. kexec_file loads the secondary kernel image to a non-linked address, inherently providing KASLR-like randomization. However, on LoongArch where System RAM may be non-contiguous, enabling KASLR for the second kernel may relocate it to an invalid memory region and cause a boot failure. Thus, we disable KASLR when "kexec_file" is detected in the command line. To ensure compatibility with older kernels loaded via kexec_file, this patch should be backported to stable branches. Cc: stable@vger.kernel.org Signed-off-by: Youling Tang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 331c2dd8ca8bad1a3ac10cce847ffb76158eece4 Author: Zheng Qixing Date: Tue Aug 26 15:42:04 2025 +0800 dm: fix NULL pointer dereference in __dm_suspend() commit 8d33a030c566e1f105cd5bf27f37940b6367f3be upstream. There is a race condition between dm device suspend and table load that can lead to null pointer dereference. The issue occurs when suspend is invoked before table load completes: BUG: kernel NULL pointer dereference, address: 0000000000000054 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50 Call Trace: blk_mq_quiesce_queue+0x2c/0x50 dm_stop_queue+0xd/0x20 __dm_suspend+0x130/0x330 dm_suspend+0x11a/0x180 dev_suspend+0x27e/0x560 ctl_ioctl+0x4cf/0x850 dm_ctl_ioctl+0xd/0x20 vfs_ioctl+0x1d/0x50 __se_sys_ioctl+0x9b/0xc0 __x64_sys_ioctl+0x19/0x30 x64_sys_call+0x2c4a/0x4620 do_syscall_64+0x9e/0x1b0 The issue can be triggered as below: T1 T2 dm_suspend table_load __dm_suspend dm_setup_md_queue dm_mq_init_request_queue blk_mq_init_allocated_queue => q->mq_ops = set->ops; (1) dm_stop_queue / dm_wait_for_completion => q->tag_set NULL pointer! (2) => q->tag_set = set; (3) Fix this by checking if a valid table (map) exists before performing request-based suspend and waiting for target I/O. When map is NULL, skip these table-dependent suspend steps. Even when map is NULL, no I/O can reach any target because there is no table loaded; I/O submitted in this state will fail early in the DM layer. Skipping the table-dependent suspend logic in this case is safe and avoids NULL pointer dereferences. Fixes: c4576aed8d85 ("dm: fix request-based dm's use of dm_wait_for_completion") Cc: stable@vger.kernel.org Signed-off-by: Zheng Qixing Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 92c0f3d728c143a7915153a526d866794b925788 Author: Zheng Qixing Date: Tue Aug 26 15:42:03 2025 +0800 dm: fix queue start/stop imbalance under suspend/load/resume races commit 7f597c2cdb9d3263a6fce07c4fc0a9eaa8e8fc43 upstream. When suspend and load run concurrently, before q->mq_ops is set in blk_mq_init_allocated_queue(), __dm_suspend() skip dm_stop_queue(). As a result, the queue's quiesce depth is not incremented. Later, once table load has finished and __dm_resume() runs, which triggers q->quiesce_depth ==0 warning in blk_mq_unquiesce_queue(): Call Trace: dm_start_queue+0x16/0x20 [dm_mod] __dm_resume+0xac/0xb0 [dm_mod] dm_resume+0x12d/0x150 [dm_mod] do_resume+0x2c2/0x420 [dm_mod] dev_suspend+0x30/0x130 [dm_mod] ctl_ioctl+0x402/0x570 [dm_mod] dm_ctl_ioctl+0x23/0x30 [dm_mod] Fix this by explicitly tracking whether the request queue was stopped in __dm_suspend() via a new DMF_QUEUE_STOPPED flag. Only call dm_start_queue() in __dm_resume() if the queue was actually stopped. Fixes: e70feb8b3e68 ("blk-mq: support concurrent queue quiesce/unquiesce") Cc: stable@vger.kernel.org Signed-off-by: Zheng Qixing Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit ecff148e9cd70c14bac2cee84a7c89f0a6a13a6a Author: Steven Rostedt Date: Sat Oct 11 11:20:32 2025 -0400 tracing: Stop fortify-string from warning in tracing_mark_raw_write() commit 54b91e54b113d4f15ab023a44f508251db6e22e7 upstream. The way tracing_mark_raw_write() records its data is that it has the following structure: struct { struct trace_entry; int id; char buf[]; }; But memcpy(&entry->id, buf, size) triggers the following warning when the size is greater than the id: ------------[ cut here ]------------ memcpy: detected field-spanning write (size 6) of single field "&entry->id" at kernel/trace/trace.c:7458 (size 4) WARNING: CPU: 7 PID: 995 at kernel/trace/trace.c:7458 write_raw_marker_to_buffer.isra.0+0x1f9/0x2e0 Modules linked in: CPU: 7 UID: 0 PID: 995 Comm: bash Not tainted 6.17.0-test-00007-g60b82183e78a-dirty #211 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:write_raw_marker_to_buffer.isra.0+0x1f9/0x2e0 Code: 04 00 75 a7 b9 04 00 00 00 48 89 de 48 89 04 24 48 c7 c2 e0 b1 d1 b2 48 c7 c7 40 b2 d1 b2 c6 05 2d 88 6a 04 01 e8 f7 e8 bd ff <0f> 0b 48 8b 04 24 e9 76 ff ff ff 49 8d 7c 24 04 49 8d 5c 24 08 48 RSP: 0018:ffff888104c3fc78 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000006 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 1ffffffff6b363b4 RDI: 0000000000000001 RBP: ffff888100058a00 R08: ffffffffb041d459 R09: ffffed1020987f40 R10: 0000000000000007 R11: 0000000000000001 R12: ffff888100bb9010 R13: 0000000000000000 R14: 00000000000003e3 R15: ffff888134800000 FS: 00007fa61d286740(0000) GS:ffff888286cad000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000560d28d509f1 CR3: 00000001047a4006 CR4: 0000000000172ef0 Call Trace: tracing_mark_raw_write+0x1fe/0x290 ? __pfx_tracing_mark_raw_write+0x10/0x10 ? security_file_permission+0x50/0xf0 ? rw_verify_area+0x6f/0x4b0 vfs_write+0x1d8/0xdd0 ? __pfx_vfs_write+0x10/0x10 ? __pfx_css_rstat_updated+0x10/0x10 ? count_memcg_events+0xd9/0x410 ? fdget_pos+0x53/0x5e0 ksys_write+0x182/0x200 ? __pfx_ksys_write+0x10/0x10 ? do_user_addr_fault+0x4af/0xa30 do_syscall_64+0x63/0x350 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fa61d318687 Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff RSP: 002b:00007ffd87fe0120 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fa61d286740 RCX: 00007fa61d318687 RDX: 0000000000000006 RSI: 0000560d28d509f0 RDI: 0000000000000001 RBP: 0000560d28d509f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000006 R13: 00007fa61d4715c0 R14: 00007fa61d46ee80 R15: 0000000000000000 ---[ end trace 0000000000000000 ]--- This is because fortify string sees that the size of entry->id is only 4 bytes, but it is writing more than that. But this is OK as the dynamic_array is allocated to handle that copy. The size allocated on the ring buffer was actually a bit too big: size = sizeof(*entry) + cnt; But cnt includes the 'id' and the buffer data, so adding cnt to the size of *entry actually allocates too much on the ring buffer. Change the allocation to: size = struct_size(entry, buf, cnt - sizeof(entry->id)); and the memcpy() to unsafe_memcpy() with an added justification. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Andrew Morton Link: https://lore.kernel.org/20251011112032.77be18e4@gandalf.local.home Fixes: 64cf7d058a00 ("tracing: Have trace_marker use per-cpu data to read user space") Reported-by: syzbot+9a2ede1643175f350105@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68e973f5.050a0220.1186a4.0010.GAE@google.com/ Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 48f3bf612e74d09e59c68466206e7d75fa93d6f3 Author: Steven Rostedt Date: Fri Oct 10 23:51:42 2025 -0400 tracing: Fix tracing_mark_raw_write() to use buf and not ubuf commit bda745ee8fbb63330d8f2f2ea4157229a5df959e upstream. The fix to use a per CPU buffer to read user space tested only the writes to trace_marker. But it appears that the selftests are missing tests to the trace_maker_raw file. The trace_maker_raw file is used by applications that writes data structures and not strings into the file, and the tools read the raw ring buffer to process the structures it writes. The fix that reads the per CPU buffers passes the new per CPU buffer to the trace_marker file writes, but the update to the trace_marker_raw write read the data from user space into the per CPU buffer, but then still used then passed the user space address to the function that records the data. Pass in the per CPU buffer and not the user space address. TODO: Add a test to better test trace_marker_raw. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Link: https://lore.kernel.org/20251011035243.386098147@kernel.org Fixes: 64cf7d058a00 ("tracing: Have trace_marker use per-cpu data to read user space") Reported-by: syzbot+9a2ede1643175f350105@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68e973f5.050a0220.1186a4.0010.GAE@google.com/ Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 3ceb52b70aacf22a4d6933e94ad5039fd2ba8be0 Author: Steven Rostedt Date: Wed Oct 8 12:45:10 2025 -0400 tracing: Have trace_marker use per-cpu data to read user space commit 64cf7d058a005c5c31eb8a0b741f35dc12915d18 upstream. It was reported that using __copy_from_user_inatomic() can actually schedule. Which is bad when preemption is disabled. Even though there's logic to check in_atomic() is set, but this is a nop when the kernel is configured with PREEMPT_NONE. This is due to page faulting and the code could schedule with preemption disabled. Link: https://lore.kernel.org/all/20250819105152.2766363-1-luogengkun@huaweicloud.com/ The solution was to change the __copy_from_user_inatomic() to copy_from_user_nofault(). But then it was reported that this caused a regression in Android. There's several applications writing into trace_marker() in Android, but now instead of showing the expected data, it is showing: tracing_mark_write: After reverting the conversion to copy_from_user_nofault(), Android was able to get the data again. Writes to the trace_marker is a way to efficiently and quickly enter data into the Linux tracing buffer. It takes no locks and was designed to be as non-intrusive as possible. This means it cannot allocate memory, and must use pre-allocated data. A method that is actively being worked on to have faultable system call tracepoints read user space data is to allocate per CPU buffers, and use them in the callback. The method uses a technique similar to seqcount. That is something like this: preempt_disable(); cpu = smp_processor_id(); buffer = this_cpu_ptr(&pre_allocated_cpu_buffers, cpu); do { cnt = nr_context_switches_cpu(cpu); migrate_disable(); preempt_enable(); ret = copy_from_user(buffer, ptr, size); preempt_disable(); migrate_enable(); } while (!ret && cnt != nr_context_switches_cpu(cpu)); if (!ret) ring_buffer_write(buffer); preempt_enable(); It's a little more involved than that, but the above is the basic logic. The idea is to acquire the current CPU buffer, disable migration, and then enable preemption. At this moment, it can safely use copy_from_user(). After reading the data from user space, it disables preemption again. It then checks to see if there was any new scheduling on this CPU. If there was, it must assume that the buffer was corrupted by another task. If there wasn't, then the buffer is still valid as only tasks in preemptable context can write to this buffer and only those that are running on the CPU. By using this method, where trace_marker open allocates the per CPU buffers, trace_marker writes can access user space and even fault it in, without having to allocate or take any locks of its own. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Luo Gengkun Cc: Wattson CI Cc: Linus Torvalds Link: https://lore.kernel.org/20251008124510.6dba541a@gandalf.local.home Fixes: 3d62ab32df065 ("tracing: Fix tracing_marker may trigger page fault during preempt_disable") Reported-by: Runping Lai Tested-by: Runping Lai Closes: https://lore.kernel.org/linux-trace-kernel/20251007003417.3470979-2-runpinglai@google.com/ Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit afc0f246e0ba0f508b398ba3978df20e6d2c6051 Author: Steven Rostedt Date: Wed Oct 8 11:49:43 2025 -0400 tracing: Fix irqoff tracers on failure of acquiring calltime commit c834a97962c708ff5bb8582ca76b0e1225feb675 upstream. The functions irqsoff_graph_entry() and irqsoff_graph_return() both call func_prolog_dec() that will test if the data->disable is already set and if not, increment it and return. If it was set, it returns false and the caller exits. The caller of this function must decrement the disable counter, but misses doing so if the calltime fails to be acquired. Instead of exiting out when calltime is NULL, change the logic to do the work if it is not NULL and still do the clean up at the end of the function if it is NULL. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://lore.kernel.org/20251008114943.6f60f30f@gandalf.local.home Fixes: a485ea9e3ef3 ("tracing: Fix irqsoff and wakeup latency tracers when using function graph") Reported-by: Sasha Levin Closes: https://lore.kernel.org/linux-trace-kernel/20251006175848.1906912-2-sashal@kernel.org/ Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 5d52012ce95353c90e78652d4721f0e97c056d67 Author: Steven Rostedt Date: Wed Oct 8 11:48:35 2025 -0400 tracing: Fix wakeup tracers on failure of acquiring calltime commit 4f7bf54b07e5acf79edd58dafede4096854776cd upstream. The functions wakeup_graph_entry() and wakeup_graph_return() both call func_prolog_preempt_disable() that will test if the data->disable is already set and if not, increment it and disable preemption. If it was set, it returns false and the caller exits. The caller of this function must decrement the disable counter, but misses doing so if the calltime fails to be acquired. Instead of exiting out when calltime is NULL, change the logic to do the work if it is not NULL and still do the clean up at the end of the function if it is NULL. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://lore.kernel.org/20251008114835.027b878a@gandalf.local.home Fixes: a485ea9e3ef3 ("tracing: Fix irqsoff and wakeup latency tracers when using function graph") Reported-by: Sasha Levin Closes: https://lore.kernel.org/linux-trace-kernel/20251006175848.1906912-1-sashal@kernel.org/ Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 5ebea6561649d30ec7a18fea23d7f76738dae916 Author: Yuan Chen Date: Wed Oct 1 03:20:25 2025 +0100 tracing: Fix race condition in kprobe initialization causing NULL pointer dereference commit 9cf9aa7b0acfde7545c1a1d912576e9bab28dc6f upstream. There is a critical race condition in kprobe initialization that can lead to NULL pointer dereference and kernel crash. [1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000 ... [1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO) [1135630.269239] pc : kprobe_perf_func+0x30/0x260 [1135630.277643] lr : kprobe_dispatcher+0x44/0x60 [1135630.286041] sp : ffffaeff4977fa40 [1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400 [1135630.302837] x27: 0000000000000000 x26: 0000000000000000 [1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528 [1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50 [1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50 [1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000 [1135630.349985] x17: 0000000000000000 x16: 0000000000000000 [1135630.359285] x15: 0000000000000000 x14: 0000000000000000 [1135630.368445] x13: 0000000000000000 x12: 0000000000000000 [1135630.377473] x11: 0000000000000000 x10: 0000000000000000 [1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000 [1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000 [1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000 [1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006 [1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000 [1135630.429410] Call trace: [1135630.434828] kprobe_perf_func+0x30/0x260 [1135630.441661] kprobe_dispatcher+0x44/0x60 [1135630.448396] aggr_pre_handler+0x70/0xc8 [1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0 [1135630.462435] brk_handler+0xbc/0xd8 [1135630.468437] do_debug_exception+0x84/0x138 [1135630.475074] el1_dbg+0x18/0x8c [1135630.480582] security_file_permission+0x0/0xd0 [1135630.487426] vfs_write+0x70/0x1c0 [1135630.493059] ksys_write+0x5c/0xc8 [1135630.498638] __arm64_sys_write+0x24/0x30 [1135630.504821] el0_svc_common+0x78/0x130 [1135630.510838] el0_svc_handler+0x38/0x78 [1135630.516834] el0_svc+0x8/0x1b0 kernel/trace/trace_kprobe.c: 1308 0xffff3df8995039ec : ldr x21, [x24,#120] include/linux/compiler.h: 294 0xffff3df8995039f0 : ldr x1, [x21,x0] kernel/trace/trace_kprobe.c 1308: head = this_cpu_ptr(call->perf_events); 1309: if (hlist_empty(head)) 1310: return 0; crash> struct trace_event_call -o struct trace_event_call { ... [120] struct hlist_head *perf_events; //(call->perf_event) ... } crash> struct trace_event_call ffffaf015340e528 struct trace_event_call { ... perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0 ... } Race Condition Analysis: The race occurs between kprobe activation and perf_events initialization: CPU0 CPU1 ==== ==== perf_kprobe_init perf_trace_event_init tp_event->perf_events = list;(1) tp_event->class->reg (2)← KPROBE ACTIVE Debug exception triggers ... kprobe_dispatcher kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE) head = this_cpu_ptr(call->perf_events)(3) (perf_events is still NULL) Problem: 1. CPU0 executes (1) assigning tp_event->perf_events = list 2. CPU0 executes (2) enabling kprobe functionality via class->reg() 3. CPU1 triggers and reaches kprobe_dispatcher 4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed) 5. CPU1 calls kprobe_perf_func() and crashes at (3) because call->perf_events is still NULL CPU1 sees that kprobe functionality is enabled but does not see that perf_events has been assigned. Add pairing read and write memory barriers to guarantee that if CPU1 sees that kprobe functionality is enabled, it must also see that perf_events has been assigned. Link: https://lore.kernel.org/all/20251001022025.44626-1-chenyuan_fl@163.com/ Fixes: 50d780560785 ("tracing/kprobes: Add probe handler dispatcher to support perf and ftrace concurrent use") Cc: stable@vger.kernel.org Signed-off-by: Yuan Chen Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 8da2138409dcdeb773dc0c4eff7a8f51c8a0c137 Author: Sasha Levin Date: Mon Sep 29 07:32:38 2025 -0400 tracing: Fix lock imbalance in s_start() memory allocation failure path commit 61e19cd2e5c5235326a13a68df1a2f8ec4eeed7b upstream. When s_start() fails to allocate memory for set_event_iter, it returns NULL before acquiring event_mutex. However, the corresponding s_stop() function always tries to unlock the mutex, causing a lock imbalance warning: WARNING: bad unlock balance detected! 6.17.0-rc7-00175-g2b2e0c04f78c #7 Not tainted ------------------------------------- syz.0.85611/376514 is trying to release lock (event_mutex) at: [] traverse.part.0.constprop.0+0x2c4/0x650 fs/seq_file.c:131 but there are no more locks to release! The issue was introduced by commit b355247df104 ("tracing: Cache ':mod:' events for modules not loaded yet") which added the kzalloc() allocation before the mutex lock, creating a path where s_start() could return without locking the mutex while s_stop() would still try to unlock it. Fix this by unconditionally acquiring the mutex immediately after allocation, regardless of whether the allocation succeeded. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20250929113238.3722055-1-sashal@kernel.org Fixes: b355247df104 ("tracing: Cache ":mod:" events for modules not loaded yet") Signed-off-by: Sasha Levin Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit d7c7b38a3014db8084f563cb45989f8bd00ea39a Author: Bartosz Golaszewski Date: Mon Aug 11 15:36:16 2025 +0200 mfd: vexpress-sysreg: Check the return value of devm_gpiochip_add_data() commit 1efbee6852f1ff698a9981bd731308dd027189fb upstream. Commit 974cc7b93441 ("mfd: vexpress: Define the device as MFD cells") removed the return value check from the call to gpiochip_add_data() (or rather gpiochip_add() back then and later converted to devres) with no explanation. This function however can still fail, so check the return value and bail-out if it does. Cc: stable@vger.kernel.org Fixes: 974cc7b93441 ("mfd: vexpress: Define the device as MFD cells") Signed-off-by: Bartosz Golaszewski Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20250811-gpio-mmio-mfd-conv-v1-1-68c5c958cf80@linaro.org Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 8a2ca33ed56a7e5c6619e9e44e946cb927011557 Author: Hans de Goede Date: Mon Aug 4 15:32:40 2025 +0200 mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config flag commit 64e0d839c589f4f2ecd2e3e5bdb5cee6ba6bade9 upstream. Testing has shown that reading multiple registers at once (for 10-bit ADC values) does not work. Set the use_single_read regmap_config flag to make regmap split these for us. This should fix temperature opregion accesses done by drivers/acpi/pmic/intel_pmic_chtdc_ti.c and is also necessary for the upcoming drivers for the ADC and battery MFD cells. Fixes: 6bac0606fdba ("mfd: Add support for Cherry Trail Dollar Cove TI PMIC") Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20250804133240.312383-1-hansg@kernel.org Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 3ecf627da8ddf2f62ec526e17c8d0789af7ff7bd Author: Cosmin Tanislav Date: Wed Sep 10 20:59:06 2025 +0300 mfd: rz-mtu3: Fix MTU5 NFCR register offset commit da32b0e82c523b76265ba1ad25d7ea74f0ece402 upstream. The NFCR register for MTU5 is at 0x1a95 offset according to Datasheet Page 725, Table 16.4. The address of all registers is offset by 0x1200, making the proper address of MTU5 NFCR register be 0x895. Cc: stable@vger.kernel.org Fixes: 654c293e1687 ("mfd: Add Renesas RZ/G2L MTU3a core driver") Signed-off-by: Cosmin Tanislav Reviewed-by: Biju Das Link: https://lore.kernel.org/r/20250910175914.12956-1-cosmin-gabriel.tanislav.xa@renesas.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit c395d1e548cc68e84584ffa2e3ca9796a78bf7b9 Author: Deepak Sharma Date: Thu Sep 25 18:58:46 2025 +0530 net: nfc: nci: Add parameter validation for packet data commit 9c328f54741bd5465ca1dc717c84c04242fac2e1 upstream. Syzbot reported an uninitialized value bug in nci_init_req, which was introduced by commit 5aca7966d2a7 ("Merge tag 'perf-tools-fixes-for-v6.17-2025-09-16' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools"). This bug arises due to very limited and poor input validation that was done at nic_valid_size(). This validation only validates the skb->len (directly reflects size provided at the userspace interface) with the length provided in the buffer itself (interpreted as NCI_HEADER). This leads to the processing of memory content at the address assuming the correct layout per what opcode requires there. This leads to the accesses to buffer of `skb_buff->data` which is not assigned anything yet. Following the same silent drop of packets of invalid sizes at `nic_valid_size()`, add validation of the data in the respective handlers and return error values in case of failure. Release the skb if error values are returned from handlers in `nci_nft_packet` and effectively do a silent drop Possible TODO: because we silently drop the packets, the call to `nci_request` will be waiting for completion of request and will face timeouts. These timeouts can get excessively logged in the dmesg. A proper handling of them may require to export `nci_request_cancel` (or propagate error handling from the nft packets handlers). Reported-by: syzbot+740e04c2a93467a0f8c8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=740e04c2a93467a0f8c8 Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation") Tested-by: syzbot+740e04c2a93467a0f8c8@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Deepak Sharma Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20250925132846.213425-1-deepak.sharma.472935@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 459404f858213967ccfff336c41747d8dd186d38 Author: Larshin Sergey Date: Mon Sep 22 16:13:58 2025 +0300 fs: udf: fix OOB read in lengthAllocDescs handling commit 3bd5e45c2ce30e239d596becd5db720f7eb83c99 upstream. When parsing Allocation Extent Descriptor, lengthAllocDescs comes from on-disk data and must be validated against the block size. Crafted or corrupted images may set lengthAllocDescs so that the total descriptor length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer, leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and trigger a KASAN use-after-free read. BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60 Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309 CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60 udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261 udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179 extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46 udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106 udf_release_file+0xc1/0x120 fs/udf/file.c:185 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Validate the computed total length against epos->bh->b_size. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Reported-by: syzbot+8743fca924afed42f93e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8743fca924afed42f93e Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Larshin Sergey Link: https://patch.msgid.link/20250922131358.745579-1-Sergey.Larshin@kaspersky.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 999d00a7aed82affa9ca639e03a2703dd4ed3cb7 Author: Kai Vehmanen Date: Thu Oct 2 10:47:16 2025 +0300 ASoC: SOF: ipc4-pcm: fix start offset calculation for chain DMA commit bace10b59624e6bd8d68bc9304357f292f1b3dcf upstream. Assumption that chain DMA module starts the link DMA when 1ms of data is available from host is not correct. Instead the firmware chain DMA module fills the link DMA with initial buffer of zeroes and the host and link DMAs are started at the same time. This results in a small error in delay calculation. This can become a more severe problem if host DMA has delays that exceed 1ms. This results in negative delay to be calculated and bogus values reported to applications. This can confuse some applications like alsa_conformance_test. Fix the issue by correctly calculating the firmware chain DMA preamble size and initializing the start offset to this value. Cc: stable@vger.kernel.org Fixes: a1d203d390e0 ("ASoC: SOF: ipc4-pcm: Enable delay reporting for ChainDMA streams") Signed-off-by: Kai Vehmanen Reviewed-by: Péter Ujfalusi Reviewed-by: Bard Liao Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20251002074719.2084-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3e8e9fb1c814b64e8fdbb79946b2688f58dad8ba Author: Kai Vehmanen Date: Thu Oct 2 10:47:15 2025 +0300 ASoC: SOF: ipc4-pcm: fix delay calculation when DSP resamples commit bcd1383516bb5a6f72b2d1e7f7ad42c4a14837d1 upstream. When the sampling rates going in (host) and out (dai) from the DSP are different, the IPC4 delay reporting does not work correctly. Add support for this case by scaling the all raw position values to a common timebase before calculating real-time delay for the PCM. Cc: stable@vger.kernel.org Fixes: 0ea06680dfcb ("ASoC: SOF: ipc4-pcm: Correct the delay calculation") Signed-off-by: Kai Vehmanen Reviewed-by: Péter Ujfalusi Reviewed-by: Bard Liao Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20251002074719.2084-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 88e6763084a2a0c59260481cd5790a2703ea050a Author: Srinivas Kandagatla Date: Tue Sep 9 13:19:43 2025 +0100 ASoC: codecs: wcd937x: make stub functions inline commit c4bb62eb594418a6bd05ff03bb9072ee1fef29c2 upstream. For some reason we ended up with stub functions that are not inline, this can result in build error if its included multiple places, as we will be redefining the same function Fixes: c99a515ff153 ("ASoC: codecs: wcd937x-sdw: add SoundWire driver") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20250909121954.225833-3-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1a1ca38392e7e896075afc8905ddaea525ed30f7 Author: Srinivas Kandagatla Date: Tue Sep 9 13:19:42 2025 +0100 ASoC: codecs: wcd937x: set the comp soundwire port correctly commit 66a940b1bf48a7095162688332d725ba160154eb upstream. For some reason we endup with setting soundwire port for HPHL_COMP and HPHR_COMP as zero, this can potentially result in a memory corruption due to accessing and setting -1 th element of port_map array. Fixes: 82be8c62a38c ("ASoC: codecs: wcd937x: add basic controls") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Reviewed-by: Alexey Klimov Link: https://patch.msgid.link/20250909121954.225833-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2df948ef07b579b0b3b2dfa5c8502b2a405180e2 Author: Ranjani Sridharan Date: Thu Oct 2 10:31:25 2025 +0300 ASoC: SOF: ipc3-topology: Fix multi-core and static pipelines tear down commit 59abe7bc7e7c70e9066b3e46874d1b7e6a13de14 upstream. In the case of static pipelines, freeing the widgets in the pipelines that were not suspended after freeing the scheduler widgets results in errors because the secondary cores are powered off when the scheduler widgets are freed. Fix this by tearing down the leftover pipelines before powering off the secondary cores. Cc: stable@vger.kernel.org Fixes: d7332c4a4f1a ("ASoC: SOF: ipc3-topology: Fix pipeline tear down logic") Signed-off-by: Ranjani Sridharan Reviewed-by: Péter Ujfalusi Reviewed-by: Kai Vehmanen Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20251002073125.32471-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d2e95ab7b570f898e34b7db70f77c3b638de8bc9 Author: Ma Ke Date: Tue Sep 23 14:52:12 2025 +0800 ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data() commit 4e65bda8273c938039403144730923e77916a3d7 upstream. wcd934x_codec_parse_data() contains a device reference count leak in of_slim_get_device() where device_find_child() increases the reference count of the device but this reference is not properly decreased in the success path. Add put_device() in wcd934x_codec_parse_data() and add devm_add_action_or_reset() in the probe function, which ensures that the reference count of the device is correctly managed. Memory leak in regmap_init_slimbus() as the allocated regmap is not released when the device is removed. Using devm_regmap_init_slimbus() instead of regmap_init_slimbus() to ensure automatic regmap cleanup on device removal. Calling path: of_slim_get_device() -> of_find_slim_device() -> device_find_child(). As comment of device_find_child() says, 'NOTE: you will need to drop the reference with put_device() after use.'. Found by code review. Cc: stable@vger.kernel.org Fixes: a61f3b4f476e ("ASoC: wcd934x: add support to wcd9340/wcd9341 codec") Signed-off-by: Ma Ke Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20250923065212.26660-1-make24@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8bcc9eaf1b19f1a7029cba19f6bd4122b40f6c4f Author: Pavel Begunkov Date: Wed Oct 8 13:38:06 2025 +0100 io_uring/zcrx: fix overshooting recv limit commit 09cfd3c52ea76f43b3cb15e570aeddf633d65e80 upstream. It's reported that sometimes a zcrx request can receive more than was requested. It's caused by io_zcrx_recv_skb() adjusting desc->count for all received buffers including frag lists, but then doing recursive calls to process frag list skbs, which leads to desc->count double accounting and underflow. Reported-and-tested-by: Matthias Jasny Fixes: 6699ec9a23f85 ("io_uring/zcrx: add a read limit to recvzc requests") Cc: stable@vger.kernel.org Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3e2205db2f0608898d535da1964e1b376aacfdaa Author: Jens Axboe Date: Tue Oct 7 07:46:00 2025 -0600 io_uring/waitid: always prune wait queue entry in io_waitid_wait() commit 2f8229d53d984c6a05b71ac9e9583d4354e3b91f upstream. For a successful return, always remove our entry from the wait queue entry list. Previously this was skipped if a cancelation was in progress, but this can race with another invocation of the wait queue entry callback. Cc: stable@vger.kernel.org Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support") Reported-by: syzbot+b9e83021d9c642a33d8c@syzkaller.appspotmail.com Tested-by: syzbot+b9e83021d9c642a33d8c@syzkaller.appspotmail.com Link: https://lore.kernel.org/io-uring/68e5195e.050a0220.256323.001f.GAE@google.com/ Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c15e20a219bd28bf6263b4b25187a5f2a3c9f726 Author: Miaoqian Lin Date: Mon Sep 1 16:18:08 2025 +0800 hisi_acc_vfio_pci: Fix reference leak in hisi_acc_vfio_debug_init commit eaba58355ecd124b4a8c91df7335970ad9fe2624 upstream. The debugfs_lookup() function returns a dentry with an increased reference count that must be released by calling dput(). Fixes: b398f91779b8 ("hisi_acc_vfio_pci: register debugfs for hisilicon migration driver") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin Reviewed-by: Longfang Liu Link: https://lore.kernel.org/r/20250901081809.2286649-1-linmq006@gmail.com Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit e29587c07537929684faa365027f4b0d87521e1b Author: Naman Jain Date: Thu Aug 28 10:12:00 2025 +0530 uio_hv_generic: Let userspace take care of interrupt mask commit b15b7d2a1b09ef5428a8db260251897405a19496 upstream. Remove the logic to set interrupt mask by default in uio_hv_generic driver as the interrupt mask value is supposed to be controlled completely by the user space. If the mask bit gets changed by the driver, concurrently with user mode operating on the ring, the mask bit may be set when it is supposed to be clear, and the user-mode driver will miss an interrupt which will cause a hang. For eg- when the driver sets inbound ring buffer interrupt mask to 1, the host does not interrupt the guest on the UIO VMBus channel. However, setting the mask does not prevent the host from putting a message in the inbound ring buffer. So let’s assume that happens, the host puts a message into the ring buffer but does not interrupt. Subsequently, the user space code in the guest sets the inbound ring buffer interrupt mask to 0, saying “Hey, I’m ready for interrupts”. User space code then calls pread() to wait for an interrupt. Then one of two things happens: * The host never sends another message. So the pread() waits forever. * The host does send another message. But because there’s already a message in the ring buffer, it doesn’t generate an interrupt. This is the correct behavior, because the host should only send an interrupt when the inbound ring buffer transitions from empty to not-empty. Adding an additional message to a ring buffer that is not empty is not supposed to generate an interrupt on the guest. Since the guest is waiting in pread() and not removing messages from the ring buffer, the pread() waits forever. This could be easily reproduced in hv_fcopy_uio_daemon if we delay setting interrupt mask to 0. Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1, there’s a race condition. Once user space empties the inbound ring buffer, but before user space sets interrupt_mask to 0, the host could put another message in the ring buffer but it wouldn’t interrupt. Then the next pread() would hang. Fix these by removing all instances where interrupt_mask is changed, while keeping the one in set_event() unchanged to enable userspace control the interrupt mask by writing 0/1 to /dev/uioX. Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus") Suggested-by: John Starks Signed-off-by: Naman Jain Cc: stable@vger.kernel.org Reviewed-by: Michael Kelley Reviewed-by: Long Li Reviewed-by: Tianyu Lan Tested-by: Tianyu Lan Link: https://lore.kernel.org/r/20250828044200.492030-1-namjain@linux.microsoft.com Signed-off-by: Greg Kroah-Hartman commit 91b99db7a92e57ff48a96a1b10fddfd2547e7f53 Author: Phillip Lougher Date: Fri Sep 19 00:33:08 2025 +0100 Squashfs: fix uninit-value in squashfs_get_parent commit 74058c0a9fc8b2b4d5f4a0ef7ee2cfa66a9e49cf upstream. Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug. This is caused by open_by_handle_at() being called with a file handle containing an invalid parent inode number. In particular the inode number is that of a symbolic link, rather than a directory. Squashfs_get_parent() gets called with that symbolic link inode, and accesses the parent member field. unsigned int parent_ino = squashfs_i(inode)->parent; Because non-directory inodes in Squashfs do not have a parent value, this is uninitialised, and this causes an uninitialised value access. The fix is to initialise parent with the invalid inode 0, which will cause an EINVAL error to be returned. Regular inodes used to share the parent field with the block_list_start field. This is removed in this commit to enable the parent field to contain the invalid inode number 0. Link: https://lkml.kernel.org/r/20250918233308.293861-1-phillip@squashfs.org.uk Fixes: 122601408d20 ("Squashfs: export operations") Signed-off-by: Phillip Lougher Reported-by: syzbot+157bdef5cf596ad0da2c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68cc2431.050a0220.139b6.0001.GAE@google.com/ Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 895b06eb062a244aef0b554bbcf7796ca208dac4 Author: Takashi Iwai Date: Sat Sep 27 11:47:23 2025 +0200 ALSA: hda/realtek: Add quirk for HP Spectre 14t-ea100 commit 50a098e3e9b1bb30cefc43cdfba3c7b9b32e14a7 upstream. HP-Spectre 14t-ea100 model has no speaker output unless booting previously from Windows on dual boot, a reboot while on Linux will stop the speakers working. Applying the existing quirk for HP Spectre X360 EU0xxx seems fixing this speaker problem. Reported-by: Kaden Berger Cc: Link: https://lore.kernel.org/aMxdGAmfOQ6VPNU8@archlinux Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 909c9cd14d43446fadbb289d17d6535555f5a260 Author: Steven 'Steve' Kendall Date: Mon Sep 29 21:33:34 2025 +0000 ALSA: hda/hdmi: Add pin fix for HP ProDesk model commit 74662f9f92b67c0ca55139c5aa392da0f0a26c08 upstream. The HP ProDesk 400 (SSID 103c:83f3) also needs a quirk for enabling HDMI outputs. This patch adds the required quirk entry. Signed-off-by: Steven 'Steve' Kendall Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1bbf47539b2e38b8dcd0f2b39d0396b1c2ce7783 Author: Jarkko Sakkinen Date: Mon Aug 25 23:32:23 2025 +0300 tpm: Disable TPM2_TCG_HMAC by default commit 4bddf4587c131d7b8ce8952cd32b284dcda0dd1f upstream. After reading all the feedback, right now disabling the TPM2_TCG_HMAC is the right call. Other views discussed: A. Having a kernel command-line parameter or refining the feature otherwise. This goes to the area of improvements. E.g., one example is my own idea where the null key specific code would be replaced with a persistent handle parameter (which can be *unambigously* defined as part of attestation process when done correctly). B. Removing the code. I don't buy this because that is same as saying that HMAC encryption cannot work at all (if really nitpicking) in any form. Also I disagree on the view that the feature could not be refined to something more reasoable. Also, both A and B are worst options in terms of backporting. Thuss, this is the best possible choice. Cc: stable@vger.kernel.or # v6.10+ Fixes: d2add27cf2b8 ("tpm: Add NULL primary creation") Suggested-by: Chris Fenner Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 21167bf70dbe400563e189ac632258d35eda38b5 Author: Yazhou Tang Date: Tue Sep 30 23:04:33 2025 +0800 bpf: Reject negative offsets for ALU ops [ Upstream commit 55c0ced59fe17dee34e9dfd5f7be63cbab207758 ] When verifying BPF programs, the check_alu_op() function validates instructions with ALU operations. The 'offset' field in these instructions is a signed 16-bit integer. The existing check 'insn->off > 1' was intended to ensure the offset is either 0, or 1 for BPF_MOD/BPF_DIV. However, because 'insn->off' is signed, this check incorrectly accepts all negative values (e.g., -1). This commit tightens the validation by changing the condition to '(insn->off != 0 && insn->off != 1)'. This ensures that any value other than the explicitly permitted 0 and 1 is rejected, hardening the verifier against malformed BPF programs. Co-developed-by: Shenghao Yuan Signed-off-by: Shenghao Yuan Co-developed-by: Tianci Cao Signed-off-by: Tianci Cao Signed-off-by: Yazhou Tang Acked-by: Yonghong Song Fixes: ec0e2da95f72 ("bpf: Support new signed div/mod instructions.") Link: https://lore.kernel.org/r/tencent_70D024BAE70A0A309A4781694C7B764B0608@qq.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit b9ef4963227246b9222e1559ddeec8e7af63e6c6 Author: Brahmajit Das Date: Thu Oct 2 00:47:38 2025 +0530 bpf: Skip scalar adjustment for BPF_NEG if dst is a pointer [ Upstream commit 34904582b502a86fdb4d7984b12cacd2faabbe0d ] In check_alu_op(), the verifier currently calls check_reg_arg() and adjust_scalar_min_max_vals() unconditionally for BPF_NEG operations. However, if the destination register holds a pointer, these scalar adjustments are unnecessary and potentially incorrect. This patch adds a check to skip the adjustment logic when the destination register contains a pointer. Reported-by: syzbot+d36d5ae81e1b0a53ef58@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d36d5ae81e1b0a53ef58 Fixes: aced132599b3 ("bpf: Add range tracking for BPF_NEG") Suggested-by: KaFai Wan Suggested-by: Eduard Zingerman Signed-off-by: Brahmajit Das Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20251001191739.2323644-2-listout@listout.xyz Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit c0dcd83aadcb31b60cb70ca1912f2252f92fab53 Author: Jiri Olsa Date: Wed Oct 1 14:22:23 2025 +0200 selftests/bpf: Fix realloc size in bpf_get_addrs [ Upstream commit 0c342bfc9949dffeaa83ebdde3b4b0ce59009348 ] We will segfault once we call realloc in bpf_get_addrs due to wrong size argument. Fixes: 6302bdeb91df ("selftests/bpf: Add a kprobe_multi subtest to use addrs instead of syms") Signed-off-by: Jiri Olsa Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a4427120c26ddf0b15702fb35df3be05aa9f1b01 Author: Menglong Dong Date: Thu Sep 4 10:10:09 2025 +0800 selftests/bpf: move get_ksyms and get_addrs to trace_helpers.c [ Upstream commit 8bad31edf5490a38dc26163502cd7005a033ee05 ] We need to get all the kernel function that can be traced sometimes, so we move the get_syms() and get_addrs() in kprobe_multi_test.c to trace_helpers.c and rename it to bpf_get_ksyms() and bpf_get_addrs(). Signed-off-by: Menglong Dong Link: https://lore.kernel.org/r/20250904021011.14069-2-dongml2@chinatelecom.cn Signed-off-by: Alexei Starovoitov Stable-dep-of: 0c342bfc9949 ("selftests/bpf: Fix realloc size in bpf_get_addrs") Signed-off-by: Sasha Levin commit deaffa5e62eb25a827d45f625488301e38d23b72 Author: Shubham Sharma Date: Tue Aug 26 18:27:46 2025 +0530 selftests/bpf: Fix typos and grammar in test sources [ Upstream commit d3abefe897408718799ae3bd06295b89b870a38e ] Fix spelling typos and grammar errors in BPF selftests source code. Signed-off-by: Shubham Sharma Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250826125746.17983-1-slopixelz@gmail.com Stable-dep-of: 0c342bfc9949 ("selftests/bpf: Fix realloc size in bpf_get_addrs") Signed-off-by: Sasha Levin commit cfa0654402c06d086201a9ff167eb95da5844fc3 Author: zhang jiao Date: Wed Sep 10 17:17:38 2025 +0800 vhost: vringh: Modify the return value check [ Upstream commit 82a8d0fda55b35361ee7f35b54fa2b66d7847d2b ] The return value of copy_from_iter and copy_to_iter can't be negative, check whether the copied lengths are equal. Fixes: 309bba39c945 ("vringh: iterate on iotlb_translate to handle large translations") Cc: "Stefano Garzarella" Signed-off-by: zhang jiao Message-Id: <20250910091739.2999-1-zhangjiao2@cmss.chinamobile.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 0928ebbfc98e569411dce940b81612bf88435dd5 Author: Bo Sun Date: Tue Sep 30 14:12:36 2025 +0800 octeontx2-pf: fix bitmap leak [ Upstream commit 92e9f4faffca70c82126e59552f6e8ff8f95cc65 ] The bitmap allocated with bitmap_zalloc() in otx2_probe() was not released in otx2_remove(). Unbinding and rebinding the driver therefore triggers a kmemleak warning: unreferenced object (size 8): backtrace: bitmap_zalloc otx2_probe Call bitmap_free() in the remove path to fix the leak. Fixes: efabce290151 ("octeontx2-pf: AF_XDP zero copy receive support") Signed-off-by: Bo Sun Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ddb13c000182070c85ce5d4a3cec0f24f2e3e6e4 Author: Bo Sun Date: Tue Sep 30 14:12:35 2025 +0800 octeontx2-vf: fix bitmap leak [ Upstream commit cd9ea7da41a449ff1950230a35990155457b9879 ] The bitmap allocated with bitmap_zalloc() in otx2vf_probe() was not released in otx2vf_remove(). Unbinding and rebinding the driver therefore triggers a kmemleak warning: unreferenced object (size 8): backtrace: bitmap_zalloc otx2vf_probe Call bitmap_free() in the remove path to fix the leak. Fixes: efabce290151 ("octeontx2-pf: AF_XDP zero copy receive support") Signed-off-by: Bo Sun Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a97bf1a0cdc88126b0222ec6ad1822e78a67c610 Author: Mike Snitzer Date: Fri Sep 19 10:36:26 2025 -0400 nfs/localio: avoid issuing misaligned IO using O_DIRECT [ Upstream commit 25ba2b84c38f624151a3ba36e56d41c39b9223ad ] Add nfsd_file_dio_alignment and use it to avoid issuing misaligned IO using O_DIRECT. Any misaligned DIO falls back to using buffered IO. Because misaligned DIO is now handled safely, remove the nfs modparam 'localio_O_DIRECT_semantics' that was added to require users opt-in to the requirement that all O_DIRECT be properly DIO-aligned. Also, introduce nfs_iov_iter_aligned_bvec() which is a variant of iov_iter_aligned_bvec() that also verifies the offset associated with an iov_iter is DIO-aligned. NOTE: in a parallel effort, iov_iter_aligned_bvec() is being removed along with iov_iter_is_aligned(). Lastly, add pr_info_ratelimited if underlying filesystem returns -EINVAL because it was made to try O_DIRECT for IO that is not DIO-aligned (shouldn't happen, so its best to be louder if it does). Fixes: 3feec68563d ("nfs/localio: add direct IO enablement with sync and async IO support") Signed-off-by: Mike Snitzer Reviewed-by: Jeff Layton Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 45e0e1ec14fd2af6c5d912cbed192f3b8727ce42 Author: Mike Snitzer Date: Mon Sep 29 11:56:41 2025 -0400 NFSD: filecache: add STATX_DIOALIGN and STATX_DIO_READ_ALIGN support [ Upstream commit d11f6cd1bb4a416b4515702d020a7480ac667f0f ] Use STATX_DIOALIGN and STATX_DIO_READ_ALIGN to get DIO alignment attributes from the underlying filesystem and store them in the associated nfsd_file. This is done when the nfsd_file is first opened for each regular file. Signed-off-by: Mike Snitzer Reviewed-by: Jeff Layton Reviewed-by: NeilBrown Signed-off-by: Chuck Lever Acked-by: Chuck Lever Signed-off-by: Anna Schumaker Stable-dep-of: 25ba2b84c38f ("nfs/localio: avoid issuing misaligned IO using O_DIRECT") Signed-off-by: Sasha Levin commit a4c80cc0e36196c4f95795744be5b8f640bdd2ae Author: Jakub Kicinski Date: Mon Sep 29 11:15:29 2025 -0700 Revert "net/mlx5e: Update and set Xon/Xoff upon MTU set" [ Upstream commit 6f5dacf88a32b3fd8b52c8ea781bf188c42aaa95 ] This reverts commit ceddedc969f0532b7c62ca971ee50d519d2bc0cb. Commit in question breaks the mapping of PGs to pools for some SKUs. Specifically multi-host NICs seem to be shipped with a custom buffer configuration which maps the lossy PG to pool 4. But the bad commit overrides this with pool 0 which does not have sufficient buffer space reserved. Resulting in ~40% packet loss. The commit also breaks BMC / OOB connection completely (100% packet loss). Revert, similarly to commit 3fbfe251cc9f ("Revert "net/mlx5e: Update and set Xon/Xoff upon port speed set""). The breakage is exactly the same, the only difference is that quoted commit would break the NIC immediately on boot, and the currently reverted commit only when MTU is changed. Note: "good" kernels do not restore the configuration, so downgrade isn't enough to recover machines. A NIC power cycle seems to be necessary to return to a healthy state (or overriding the relevant registers using a custom patch). Fixes: ceddedc969f0 ("net/mlx5e: Update and set Xon/Xoff upon MTU set") Signed-off-by: Jakub Kicinski Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20250929181529.1848157-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1daf67217b0d0bf88ef7208d7fbeefe2378c6590 Author: Guixin Liu Date: Thu Sep 25 13:47:30 2025 +0800 iommufd: Register iommufd mock devices with fwspec [ Upstream commit 2a918911ed3d0841923525ed0fe707762ee78844 ] Since the bus ops were retired the iommu subsystem changed to using fwspec to match the iommu driver to the iommu device. If a device has a NULL fwspec then it is matched to the first iommu driver with a NULL fwspec, effectively disabling support for systems with more than one non-fwspec iommu driver. Thus, if the iommufd selfest are run in an x86 system that registers a non-fwspec iommu driver they fail to bind their mock devices to the mock iommu driver. Fix this by allocating a software fwnode for mock iommu driver's iommu_device, and set it to the device which mock iommu driver created. This is done by adding a new helper iommu_mock_device_add() which abuses the internals of the fwspec system to establish a fwspec before the device is added and is careful not to leak it. A matching dummy fwspec is automatically added to the mock iommu driver. Test by "make -C toosl/testing/selftests TARGETS=iommu run_tests": PASSED: 229 / 229 tests passed. In addition, this issue is also can be found on amd platform, and also tested on a amd machine. Link: https://patch.msgid.link/r/20250925054730.3877-1-kanie@linux.alibaba.com Fixes: 17de3f5fdd35 ("iommu: Retire bus ops") Signed-off-by: Guixin Liu Reviewed-by: Lu Baolu Tested-by: Qinyun Tan Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit aa34f7c03bad72ccc0d87adb269b109aa47d3dcb Author: Wei Fang Date: Fri Sep 26 09:39:53 2025 +0800 net: enetc: initialize SW PIR and CIR based HW PIR and CIR values [ Upstream commit 2aff4420efc2910e905ee5b000e04e87422aebc4 ] Software can only initialize the PIR and CIR of the command BD ring after a FLR, and these two registers can only be set to 0. But the reset values of these two registers are 0, so software does not need to update them. If there is no a FLR and PIR and CIR are not 0, resetting them to 0 or other values by software will cause the command BD ring to work abnormally. This is because of an internal context in the ring prefetch logic that will retain the state from the first incarnation of the ring and continue prefetching from the stale location when the ring is reinitialized. The internal context can only be reset by the FLR. In addition, there is a logic error in the implementation, next_to_clean indicates the software CIR and next_to_use indicates the software PIR. But the current driver uses next_to_clean to set PIR and use next_to_use to set CIR. This does not cause a problem in actual use, because the current command BD ring is only initialized after FLR, and the initial values of next_to_use and next_to_clean are both 0. Therefore, this patch removes the initialization of PIR and CIR. Instead, next_to_use and next_to_clean are initialized by reading the values of PIR and CIR. Fixes: 4701073c3deb ("net: enetc: add initial netc-lib driver to support NTMP") Signed-off-by: Wei Fang Link: https://patch.msgid.link/20250926013954.2003456-1-wei.fang@nxp.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a1e045066a50db6b30c84291df39c2aaac93a822 Author: Hangbin Liu Date: Thu Sep 25 02:33:03 2025 +0000 bonding: fix xfrm offload feature setup on active-backup mode [ Upstream commit 5b66169f6be4847008c0aea50885ff0632151479 ] The active-backup bonding mode supports XFRM ESP offload. However, when a bond is added using command like `ip link add bond0 type bond mode 1 miimon 100`, the `ethtool -k` command shows that the XFRM ESP offload is disabled. This occurs because, in bond_newlink(), we change bond link first and register bond device later. So the XFRM feature update in bond_option_mode_set() is not called as the bond device is not yet registered, leading to the offload feature not being set successfully. To resolve this issue, we can modify the code order in bond_newlink() to ensure that the bond device is registered first before changing the bond link parameters. This change will allow the XFRM ESP offload feature to be correctly enabled. Fixes: 007ab5345545 ("bonding: fix feature flag setting at init time") Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20250925023304.472186-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4a61b68abd2788db0364c9a0b6a39f1699fea440 Author: Enzo Matsumiya Date: Thu Sep 25 12:10:33 2025 -0300 smb: client: fix crypto buffers in non-linear memory [ Upstream commit 998a67b954680f26f3734040aeeed08642d49721 ] The crypto API, through the scatterlist API, expects input buffers to be in linear memory. We handle this with the cifs_sg_set_buf() helper that converts vmalloc'd memory to their corresponding pages. However, when we allocate our aead_request buffer (@creq in smb2ops.c::crypt_message()), we do so with kvzalloc(), which possibly puts aead_request->__ctx in vmalloc area. AEAD algorithm then uses ->__ctx for its private/internal data and operations, and uses sg_set_buf() for such data on a few places. This works fine as long as @creq falls into kmalloc zone (small requests) or vmalloc'd memory is still within linear range. Tasks' stacks are vmalloc'd by default (CONFIG_VMAP_STACK=y), so too many tasks will increment the base stacks' addresses to a point where virt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when that happens. In practice: too many parallel reads and writes on an encrypted mount will trigger this bug. To fix this, always alloc @creq with kmalloc() instead. Also drop the @sensitive_size variable/arguments since kfree_sensitive() doesn't need it. Backtrace: [ 945.272081] ------------[ cut here ]------------ [ 945.272774] kernel BUG at include/linux/scatterlist.h:209! [ 945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary) [ 945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 [ 945.276877] Workqueue: writeback wb_workfn (flush-cifs-2) [ 945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220 [ 945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b [ 945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246 [ 945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030 [ 945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070 [ 945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000 [ 945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070 [ 945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010 [ 945.284407] FS: 0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000 [ 945.285262] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0 [ 945.286683] Call Trace: [ 945.286952] [ 945.287184] ? crypt_message+0x33f/0xad0 [cifs] [ 945.287719] crypto_gcm_encrypt+0x36/0xe0 [ 945.288152] crypt_message+0x54a/0xad0 [cifs] [ 945.288724] smb3_init_transform_rq+0x277/0x300 [cifs] [ 945.289300] smb_send_rqst+0xa3/0x160 [cifs] [ 945.289944] cifs_call_async+0x178/0x340 [cifs] [ 945.290514] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs] [ 945.291177] smb2_async_writev+0x3e3/0x670 [cifs] [ 945.291759] ? find_held_lock+0x32/0x90 [ 945.292212] ? netfs_advance_write+0xf2/0x310 [ 945.292723] netfs_advance_write+0xf2/0x310 [ 945.293210] netfs_write_folio+0x346/0xcc0 [ 945.293689] ? __pfx__raw_spin_unlock_irq+0x10/0x10 [ 945.294250] netfs_writepages+0x117/0x460 [ 945.294724] do_writepages+0xbe/0x170 [ 945.295152] ? find_held_lock+0x32/0x90 [ 945.295600] ? kvm_sched_clock_read+0x11/0x20 [ 945.296103] __writeback_single_inode+0x56/0x4b0 [ 945.296643] writeback_sb_inodes+0x229/0x550 [ 945.297140] __writeback_inodes_wb+0x4c/0xe0 [ 945.297642] wb_writeback+0x2f1/0x3f0 [ 945.298069] wb_workfn+0x300/0x490 [ 945.298472] process_one_work+0x1fe/0x590 [ 945.298949] worker_thread+0x1ce/0x3c0 [ 945.299397] ? __pfx_worker_thread+0x10/0x10 [ 945.299900] kthread+0x119/0x210 [ 945.300285] ? __pfx_kthread+0x10/0x10 [ 945.300729] ret_from_fork+0x119/0x1b0 [ 945.301163] ? __pfx_kthread+0x10/0x10 [ 945.301601] ret_from_fork_asm+0x1a/0x30 [ 945.302055] Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list") Signed-off-by: Enzo Matsumiya Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 094de9c6bb8da12be4dc72b0a9de44facae787ad Author: Moshe Shemesh Date: Mon Sep 29 00:02:09 2025 +0300 net/mlx5: fw reset, add reset timeout work [ Upstream commit 5cfbe7ebfa42fd3c517a701dab5bd73524da9088 ] Add sync reset timeout to stop poll_sync_reset in case there was no reset done or abort event within timeout. Otherwise poll sync reset will just continue and in case of fw fatal error no health reporting will be done. Fixes: 38b9f903f22b ("net/mlx5: Handle sync reset request event") Signed-off-by: Moshe Shemesh Reviewed-by: Shay Drori Signed-off-by: Tariq Toukan Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c6a2c7b661b1ea0f6661a745f98397a3bbb99332 Author: Shay Drory Date: Mon Sep 29 00:02:08 2025 +0300 net/mlx5: pagealloc: Fix reclaim race during command interface teardown [ Upstream commit 79a0e32b32ac4e4f9e4bb22be97f371c8c116c88 ] The reclaim_pages_cmd() function sends a command to the firmware to reclaim pages if the command interface is active. A race condition can occur if the command interface goes down (e.g., due to a PCI error) while the mlx5_cmd_do() call is in flight. In this case, mlx5_cmd_do() will return an error. The original code would propagate this error immediately, bypassing the software-based page reclamation logic that is supposed to run when the command interface is down. Fix this by checking whether mlx5_cmd_do() returns -ENXIO, which mark that command interface is down. If this is the case, fall through to the software reclamation path. If the command failed for any another reason, or finished successfully, return as before. Fixes: b898ce7bccf1 ("net/mlx5: cmdif, Avoid skipping reclaim pages if FW is not accessible") Signed-off-by: Shay Drory Reviewed-by: Moshe Shemesh Signed-off-by: Tariq Toukan Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ecf91620b115860617a067d849d14a56101404e0 Author: Moshe Shemesh Date: Mon Sep 29 00:02:07 2025 +0300 net/mlx5: Stop polling for command response if interface goes down [ Upstream commit b1f0349bd6d320c382df2e7f6fc2ac95c85f2b18 ] Stop polling on firmware response to command in polling mode if the command interface got down. This situation can occur, for example, if a firmware fatal error is detected during polling. This change halts the polling process when the command interface goes down, preventing unnecessary waits. Fixes: b898ce7bccf1 ("net/mlx5: cmdif, Avoid skipping reclaim pages if FW is not accessible") Signed-off-by: Moshe Shemesh Reviewed-by: Shay Drori Signed-off-by: Tariq Toukan Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fd7b6b2c920d7fd370a612be416a904d6e1ebe55 Author: Yeounsu Moon Date: Mon Sep 29 04:01:24 2025 +0900 net: dlink: handle copy_thresh allocation failure [ Upstream commit 8169a6011c5fecc6cb1c3654c541c567d3318de8 ] The driver did not handle failure of `netdev_alloc_skb_ip_align()`. If the allocation failed, dereferencing `skb->protocol` could lead to a NULL pointer dereference. This patch tries to allocate `skb`. If the allocation fails, it falls back to the normal path. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Jakub Kicinski Tested-on: D-Link DGE-550T Rev-A3 Signed-off-by: Yeounsu Moon Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250928190124.1156-1-yyyynoom@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c1a9445b934785a86428349b0e28e41c0998346c Author: Kohei Enju Date: Mon Sep 29 14:02:22 2025 +0900 net: ena: return 0 in ena_get_rxfh_key_size() when RSS hash key is not configurable [ Upstream commit f017156aea60db8720e47591ed1e041993381ad2 ] In EC2 instances where the RSS hash key is not configurable, ethtool shows bogus RSS hash key since ena_get_rxfh_key_size() unconditionally returns ENA_HASH_KEY_SIZE. Commit 6a4f7dc82d1e ("net: ena: rss: do not allocate key when not supported") added proper handling for devices that don't support RSS hash key configuration, but ena_get_rxfh_key_size() has been unchanged. When the RSS hash key is not configurable, return 0 instead of ENA_HASH_KEY_SIZE to clarify getting the value is not supported. Tested on m5 instance families. Without patch: # ethtool -x ens5 | grep -A 1 "RSS hash key" RSS hash key: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 With patch: # ethtool -x ens5 | grep -A 1 "RSS hash key" RSS hash key: Operation not supported Fixes: 6a4f7dc82d1e ("net: ena: rss: do not allocate key when not supported") Signed-off-by: Kohei Enju Link: https://patch.msgid.link/20250929050247.51680-1-enjuk@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1f7f4ee81db37cdae8d8927d91555af613545d0b Author: Kohei Enju Date: Mon Sep 29 14:42:15 2025 +0900 nfp: fix RSS hash key size when RSS is not supported [ Upstream commit 8425161ac1204d2185e0a10f5ae652bae75d2451 ] The nfp_net_get_rxfh_key_size() function returns -EOPNOTSUPP when devices don't support RSS, and callers treat the negative value as a large positive value since the return type is u32. Return 0 when devices don't support RSS, aligning with the ethtool interface .get_rxfh_key_size() that requires returning 0 in such cases. Fixes: 9ff304bfaf58 ("nfp: add support for reporting CRC32 hash function") Signed-off-by: Kohei Enju Link: https://patch.msgid.link/20250929054230.68120-1-enjuk@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f575d6d7938040d08442c38f5a4f2694e316f509 Author: Eric Dumazet Date: Sat Sep 27 09:28:27 2025 +0000 tcp: use skb->len instead of skb->truesize in tcp_can_ingest() [ Upstream commit f017c1f768b670bced4464476655b27dfb937e67 ] Some applications are stuck to the 20th century and still use small SO_RCVBUF values. After the blamed commit, we can drop packets especially when using LRO/hw-gro enabled NIC and small MSS (1500) values. LRO/hw-gro NIC pack multiple segments into pages, allowing tp->scaling_ratio to be set to a high value. Whenever the receive queue gets full, we can receive a small packet filling RWIN, but with a high skb->truesize, because most NIC use 4K page plus sk_buff metadata even when receiving less than 1500 bytes of payload. Even if we refine how tp->scaling_ratio is estimated, we could have an issue at the start of the flow, because the first round of packets (IW10) will be sent based on the initial tp->scaling_ratio (1/2) Relax tcp_can_ingest() to use skb->len instead of skb->truesize, allowing the peer to use final RWIN, assuming a 'perfect' scaling_ratio of 1. Fixes: 1d2fbaad7cd8 ("tcp: stronger sk_rcvbuf checks") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20250927092827.2707901-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f653b133f799c366a1f8d4be6afbaa8b4b4e1ee2 Author: Alok Tiwari Date: Thu Sep 25 11:02:10 2025 -0700 idpf: fix mismatched free function for dma_alloc_coherent [ Upstream commit b9bd25f47eb79c9eb275e3d9ac3983dc88577dd4 ] The mailbox receive path allocates coherent DMA memory with dma_alloc_coherent(), but frees it with dmam_free_coherent(). This is incorrect since dmam_free_coherent() is only valid for buffers allocated with dmam_alloc_coherent(). Fix the mismatch by using dma_free_coherent() instead of dmam_free_coherent Fixes: e54232da1238 ("idpf: refactor idpf_recv_mb_msg") Signed-off-by: Alok Tiwari Reviewed-by: Simon Horman Reviewed-by: Aleksandr Loktionov Reviewed-by: Jacob Keller Reviewed-by: Madhu Chittim Link: https://patch.msgid.link/20250925180212.415093-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3edd4c28e5b91f98892a16bf252508695db37302 Author: Alok Tiwari Date: Fri Sep 5 14:14:34 2025 -0700 PCI: j721e: Fix incorrect error message in probe() [ Upstream commit cfcd6cab2f33c24a68517f9e3131480b4000c2be ] The probe() function prints "pm_runtime_get_sync failed" when j721e_pcie_ctrl_init() returns an error. This is misleading since the failure is not from pm_runtime, but from the controller init routine. Update the error message to correctly reflect the source. No functional changes. Fixes: f3e25911a430 ("PCI: j721e: Add TI J721E PCIe driver") Signed-off-by: Alok Tiwari Signed-off-by: Manivannan Sadhasivam Reviewed-by: Siddharth Vadapalli Link: https://patch.msgid.link/20250905211436.3048282-1-alok.a.tiwari@oracle.com Signed-off-by: Sasha Levin commit 979d6fc878e70225bac48143efa9e1483ff4363d Author: Erick Karanja Date: Mon Sep 22 14:07:27 2025 +0300 mtd: rawnand: atmel: Fix error handling path in atmel_nand_controller_add_nands [ Upstream commit 8ed4728eb9f10b57c3eb02e0f6933a89ffcb8a91 ] In case of a jump to the err label due to atmel_nand_create() or atmel_nand_controller_add_nand() failure, the reference to nand_np need to be released Use for_each_child_of_node_scoped() to fix the issue. Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver") Signed-off-by: Erick Karanja Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 01118321e0c8a5f3ece57d0d377bfc92d83cd210 Author: Chao Yu Date: Sun Sep 28 18:24:22 2025 +0800 f2fs: fix UAF issue in f2fs_merge_page_bio() [ Upstream commit edf7e9040fc52c922db947f9c6c36f07377c52ea ] As JY reported in bugzilla [1], Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 pc : [0xffffffe51d249484] f2fs_is_cp_guaranteed+0x70/0x98 lr : [0xffffffe51d24adbc] f2fs_merge_page_bio+0x520/0x6d4 CPU: 3 UID: 0 PID: 6790 Comm: kworker/u16:3 Tainted: P B W OE 6.12.30-android16-5-maybe-dirty-4k #1 5f7701c9cbf727d1eebe77c89bbbeb3371e895e5 Tainted: [P]=PROPRIETARY_MODULE, [B]=BAD_PAGE, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Workqueue: writeback wb_workfn (flush-254:49) Call trace: f2fs_is_cp_guaranteed+0x70/0x98 f2fs_inplace_write_data+0x174/0x2f4 f2fs_do_write_data_page+0x214/0x81c f2fs_write_single_data_page+0x28c/0x764 f2fs_write_data_pages+0x78c/0xce4 do_writepages+0xe8/0x2fc __writeback_single_inode+0x4c/0x4b4 writeback_sb_inodes+0x314/0x540 __writeback_inodes_wb+0xa4/0xf4 wb_writeback+0x160/0x448 wb_workfn+0x2f0/0x5dc process_scheduled_works+0x1c8/0x458 worker_thread+0x334/0x3f0 kthread+0x118/0x1ac ret_from_fork+0x10/0x20 [1] https://bugzilla.kernel.org/show_bug.cgi?id=220575 The panic was caused by UAF issue w/ below race condition: kworker - writepages - f2fs_write_cache_pages - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_merge_page_bio - add_inu_page : cache page #1 into bio & cache bio in io->bio_list - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_merge_page_bio - add_inu_page : cache page #2 into bio which is linked in io->bio_list write - f2fs_write_begin : write page #1 - f2fs_folio_wait_writeback - f2fs_submit_merged_ipu_write - f2fs_submit_write_bio : submit bio which inclues page #1 and #2 software IRQ - f2fs_write_end_io - fscrypt_free_bounce_page : freed bounced page which belongs to page #2 - inc_page_count( , WB_DATA_TYPE(data_folio), false) : data_folio points to fio->encrypted_page the bounced page can be freed before accessing it in f2fs_is_cp_guarantee() It can reproduce w/ below testcase: Run below script in shell #1: for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \ -c "pwrite 0 32k" -c "fdatasync" Run below script in shell #2: for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \ -c "pwrite 0 32k" -c "fdatasync" So, in f2fs_merge_page_bio(), let's avoid using fio->encrypted_page after commit page into internal ipu cache. Fixes: 0b20fcec8651 ("f2fs: cache global IPU bio") Reported-by: JY Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit bfa54d8f9d375f6e2d14c7251b72cdaa239fb297 Author: Donet Tom Date: Thu Sep 18 11:11:44 2025 +0530 drivers/base/node: fix double free in register_one_node() [ Upstream commit 0efdedfa537eb534c251a5b4794caaf72cc55869 ] When device_register() fails in register_node(), it calls put_device(&node->dev). This triggers node_device_release(), which calls kfree(to_node(dev)), thereby freeing the entire node structure. As a result, when register_node() returns an error, the node memory has already been freed. Calling kfree(node) again in register_one_node() leads to a double free. This patch removes the redundant kfree(node) from register_one_node() to prevent the double free. Link: https://lkml.kernel.org/r/20250918054144.58980-1-donettom@linux.ibm.com Fixes: 786eb990cfb7 ("drivers/base/node: handle error properly in register_one_node()") Signed-off-by: Donet Tom Acked-by: David Hildenbrand Acked-by: Oscar Salvador Cc: Alison Schofield Cc: Chris Mason Cc: Danilo Krummrich Cc: Dave Jiang Cc: Greg Kroah-Hartman Cc: Hiroyouki Kamezawa Cc: Joanthan Cameron Cc: "Ritesh Harjani (IBM)" Cc: Yury Norov (NVIDIA) Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 892f41e12c8689130d552a9eb2b77bafd26484ab Author: Dan Carpenter Date: Tue Sep 23 14:26:07 2025 +0300 ocfs2: fix double free in user_cluster_connect() [ Upstream commit 8f45f089337d924db24397f55697cda0e6960516 ] user_cluster_disconnect() frees "conn->cc_private" which is "lc" but then the error handling frees "lc" a second time. Set "lc" to NULL on this path to avoid a double free. Link: https://lkml.kernel.org/r/aNKDz_7JF7aycZ0k@stanley.mountain Fixes: c994c2ebdbbc ("ocfs2: use the new DLM operation callbacks while requesting new lockspace") Signed-off-by: Dan Carpenter Reviewed-by: Joseph Qi Reviewed-by: Goldwyn Rodrigues Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 64dfd595d3eb83ee3dff040092d879f08c7cebb1 Author: Alistair Popple Date: Tue Sep 23 10:53:33 2025 +1000 cramfs: fix incorrect physical page address calculation [ Upstream commit 20a8e0454d833d80d0c0cae304841a50a2a126bd ] Commit 21aa65bf82a7 ("mm: remove callers of pfn_t functionality") incorrectly replaced the pfn with the physical address when calling vmf_insert_mixed(). Instead the phys_to_pfn_t() call should have been replaced with PHYS_PFN(). Found by inspection after a similar issue was noted in fuse virtio_fs. Link: https://lkml.kernel.org/r/20250923005333.3165032-1-apopple@nvidia.com Fixes: 21aa65bf82a7 ("mm: remove callers of pfn_t functionality") Signed-off-by: Alistair Popple Reviewed-by: Dev Jain Reviewed-by: David Hildenbrand Cc: Haiyue Wang Cc: Nicolas Pitre Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 55a70e1de75e5ff5f961c79a2cdc6a4468cc2bf2 Author: Nishanth Menon Date: Fri Sep 19 08:20:02 2025 -0500 hwrng: ks-sa - fix division by zero in ks_sa_rng_init [ Upstream commit 612b1dfeb414dfa780a6316014ceddf9a74ff5c0 ] Fix division by zero in ks_sa_rng_init caused by missing clock pointer initialization. The clk_get_rate() call is performed on an uninitialized clk pointer, resulting in division by zero when calculating delay values. Add clock initialization code before using the clock. Fixes: 6d01d8511dce ("hwrng: ks-sa - Add minimum sleep time before ready-polling") Signed-off-by: Nishanth Menon drivers/char/hw_random/ks-sa-rng.c | 7 +++++++ 1 file changed, 7 insertions(+) Reviewed-by: Alexander Sverdlin Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 84ac7daf58301dbc41ce7d1a62192d4299564ba5 Author: Fan Wu Date: Mon Sep 15 21:15:50 2025 +0000 KEYS: X.509: Fix Basic Constraints CA flag parsing [ Upstream commit 5851afffe2ab323a53e184ba5a35fddf268f096b ] Fix the X.509 Basic Constraints CA flag parsing to correctly handle the ASN.1 DER encoded structure. The parser was incorrectly treating the length field as the boolean value. Per RFC 5280 section 4.1, X.509 certificates must use ASN.1 DER encoding. According to ITU-T X.690, a DER-encoded BOOLEAN is represented as: Tag (0x01), Length (0x01), Value (0x00 for FALSE, 0xFF for TRUE) The basicConstraints extension with CA:TRUE is encoded as: SEQUENCE (0x30) | Length | BOOLEAN (0x01) | Length (0x01) | Value (0xFF) ^-- v[2] ^-- v[3] ^-- v[4] The parser was checking v[3] (the length field, always 0x01) instead of v[4] (the actual boolean value, 0xFF for TRUE in DER encoding). Also handle the case where the extension is an empty SEQUENCE (30 00), which is valid for CA:FALSE when the default value is omitted as required by DER encoding rules (X.690 section 11.5). Per ITU-T X.690-0207: - Section 11.5: Default values must be omitted in DER - Section 11.1: DER requires TRUE to be encoded as 0xFF Link: https://datatracker.ietf.org/doc/html/rfc5280 Link: https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf Fixes: 30eae2b037af ("KEYS: X.509: Parse Basic Constraints for CA") Signed-off-by: Fan Wu Reviewed-by: Lukas Wunner Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7a73febfa108c5d2bebd44f65d671a19d0ac8288 Author: Luiz Augusto von Dentz Date: Fri Sep 19 12:30:05 2025 -0400 Bluetooth: hci_sync: Fix using random address for BIG/PA advertisements [ Upstream commit 03ddb4ac251463ec5b7b069395d9ab89163dd56c ] When creating an advertisement for BIG the address shall not be non-resolvable since in case of acting as BASS/Broadcast Assistant the address must be the same as the connection in order to use the PAST method and even when PAST/BASS are not in the picture a Periodic Advertisement can still be synchronized thus the same argument as to connectable advertisements still stand. Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections") Signed-off-by: Luiz Augusto von Dentz Reviewed-by: Paul Menzel Signed-off-by: Sasha Levin commit 38e095509f37ff747e5b24c6d29fbcc934a5333b Author: Pauli Virtanen Date: Mon Sep 22 21:11:22 2025 +0300 Bluetooth: ISO: don't leak skb in ISO_CONT RX [ Upstream commit 5bf863f4c5da055c1eb08887ae4f26d99dbc4aac ] For ISO_CONT RX, the data from skb is copied to conn->rx_skb, but the skb is leaked. Free skb after copying its data. Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ec2387951f7613ccd300e368a637650bfb102250 Author: Pauli Virtanen Date: Mon Sep 22 21:11:21 2025 +0300 Bluetooth: ISO: free rx_skb if not consumed [ Upstream commit 6ba85da5804efffe15c89b03742ea868f20b4172 ] If iso_conn is freed when RX is incomplete, free any leftover skb piece. Fixes: dc26097bdb86 ("Bluetooth: ISO: Use kref to track lifetime of iso_conn") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c92ad1a155ccfa38b87bd1d998287e1c0a24248d Author: Luiz Augusto von Dentz Date: Mon Sep 22 16:27:51 2025 -0400 Bluetooth: ISO: Fix possible UAF on iso_conn_free [ Upstream commit 9950f095d6c875dbe0c9ebfcf972ec88fdf26fc8 ] This attempt to fix similar issue to sco_conn_free where if the conn->sk is not set to NULL may lead to UAF on iso_conn_free. Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 33f94b750dc6c1e6f3e1fa70e064bb3ceeaa9f2d Author: Luiz Augusto von Dentz Date: Wed Aug 20 08:50:12 2025 -0400 Bluetooth: MGMT: Fix not exposing debug UUID on MGMT_OP_READ_EXP_FEATURES_INFO [ Upstream commit 79e562a52adea4afa0601a15964498fae66c823c ] The debug UUID was only getting set if MGMT_OP_READ_EXP_FEATURES_INFO was not called with a specific index which breaks the likes of bluetoothd since it only invokes MGMT_OP_READ_EXP_FEATURES_INFO when an adapter is plugged, so instead of depending hdev not to be set just enable the UUID on any index like it was done with iso_sock_uuid. Fixes: e625e50ceee1 ("Bluetooth: Introduce debug feature when dynamic debug is disabled") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 0358fb3b22d5b002a5f567c621318f68c67f065a Author: Kiran K Date: Wed Aug 6 12:18:49 2025 +0530 Bluetooth: btintel_pcie: Refactor Device Coredump [ Upstream commit 58fddb364dd5c4e9bf223a2113a42538d9c040de ] As device coredumps are not HCI traces, maintain the device coredump at the driver level and eliminate the dependency on hdev_devcd*() Signed-off-by: Kiran K Fixes: 07e6bddb54b4 ("Bluetooth: btintel_pcie: Add support for device coredump") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 982a4d9a2e12b693f684eff943043a607628d871 Author: Théo Lebrun Date: Tue Sep 23 18:00:26 2025 +0200 net: macb: single dma_alloc_coherent() for DMA descriptors [ Upstream commit 78d901897b3cae06b38f54e48a2378cf9da21175 ] Move from 2*NUM_QUEUES dma_alloc_coherent() for DMA descriptor rings to 2 calls overall. Issue is with how all queues share the same register for configuring the upper 32-bits of Tx/Rx descriptor rings. Taking Tx, notice how TBQPH does *not* depend on the queue index: #define GEM_TBQP(hw_q) (0x0440 + ((hw_q) << 2)) #define GEM_TBQPH(hw_q) (0x04C8) queue_writel(queue, TBQP, lower_32_bits(queue->tx_ring_dma)); #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT if (bp->hw_dma_cap & HW_DMA_CAP_64B) queue_writel(queue, TBQPH, upper_32_bits(queue->tx_ring_dma)); #endif To maximise our chances of getting valid DMA addresses, we do a single dma_alloc_coherent() across queues. This improves the odds because alloc_pages() guarantees natural alignment. Other codepaths (IOMMU or dev/arch dma_map_ops) don't give high enough guarantees (even page-aligned isn't enough). Two consideration: - dma_alloc_coherent() gives us page alignment. Here we remove this constraint meaning each queue's ring won't be page-aligned anymore. - This can save some tiny amounts of memory. Fewer allocations means (1) less overhead (constant cost per alloc) and (2) less wasted bytes due to alignment constraints. Example for (2): 4 queues, default ring size (512), 64-bit DMA descriptors, 16K pages: - Before: 8 allocs of 8K, each rounded to 16K => 64K wasted. - After: 2 allocs of 32K => 0K wasted. Fixes: 02c958dd3446 ("net/macb: add TX multiqueue support for gem") Reviewed-by: Sean Anderson Acked-by: Nicolas Ferre Tested-by: Nicolas Ferre # on sam9x75 Signed-off-by: Théo Lebrun Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250923-macb-fixes-v6-4-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d8d1601b3fac139406feae7f0ed3e0b92fa1f997 Author: Théo Lebrun Date: Tue Sep 23 18:00:25 2025 +0200 net: macb: move ring size computation to functions [ Upstream commit 92d4256fafd8d0a14d3aaa10452ac771bf9b597c ] The tx/rx ring size calculation is somewhat complex and partially hidden behind a macro. Move that out of the {RX,TX}_RING_BYTES() macros and macb_{alloc,free}_consistent() functions into neat separate functions. In macb_free_consistent(), we drop the size variable and directly call the size helpers in the arguments list. In macb_alloc_consistent(), we keep the size variable that is used by netdev_dbg() calls. Acked-by: Nicolas Ferre Signed-off-by: Théo Lebrun Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250923-macb-fixes-v6-3-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski Stable-dep-of: 78d901897b3c ("net: macb: single dma_alloc_coherent() for DMA descriptors") Signed-off-by: Sasha Levin commit f786bdf0fc9073711b35dc71e9efa93879682e25 Author: Théo Lebrun Date: Tue Sep 23 18:00:24 2025 +0200 net: macb: remove illusion about TBQPH/RBQPH being per-queue [ Upstream commit fca3dc859b200ca4dcdd2124beaf3bb2ab80b0f7 ] The MACB driver acts as if TBQPH/RBQPH are configurable on a per queue basis; this is a lie. A single register configures the upper 32 bits of each DMA descriptor buffers for all queues. Concrete actions: - Drop GEM_TBQPH/GEM_RBQPH macros which have a queue index argument. Only use MACB_TBQPH/MACB_RBQPH constants. - Drop struct macb_queue->TBQPH/RBQPH fields. - In macb_init_buffers(): do a single write to TBQPH and RBQPH for all queues instead of a write per queue. - In macb_tx_error_task(): drop the write to TBQPH. - In macb_alloc_consistent(): if allocations give different upper 32-bits, fail. Previously, it would have lead to silent memory corruption as queues would have used the upper 32 bits of the alloc from queue 0 and their own low 32 bits. - In macb_suspend(): if we use the tie off descriptor for suspend, do the write once for all queues instead of once per queue. Fixes: fff8019a08b6 ("net: macb: Add 64 bit addressing support for GEM") Fixes: ae1f2a56d273 ("net: macb: Added support for many RX queues") Reviewed-by: Sean Anderson Acked-by: Nicolas Ferre Signed-off-by: Théo Lebrun Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250923-macb-fixes-v6-2-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 68aac2b335d474b938d154b9c95cbc58838cb2ce Author: Michael S. Tsirkin Date: Thu Sep 25 02:04:08 2025 -0400 vhost: vringh: Fix copy_to_iter return value check [ Upstream commit 439263376c2c4e126cac0d07e4987568de4eaba5 ] The return value of copy_to_iter can't be negative, check whether the copied length is equal to the requested length instead of checking for negative values. Cc: zhang jiao Link: https://lore.kernel.org/all/20250910091739.2999-1-zhangjiao2@cmss.chinamobile.com Signed-off-by: Michael S. Tsirkin Reviewed-by: Simon Horman Fixes: 309bba39c945 ("vringh: iterate on iotlb_translate to handle large translations") Link: https://patch.msgid.link/cd637504a6e3967954a9e80fc1b75e8c0978087b.1758723310.git.mst@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 35ce5f163889dbce88eda1df661b357a09bbed87 Author: I Viswanath Date: Thu Sep 25 21:29:08 2025 +0530 ptp: Add a upper bound on max_vclocks [ Upstream commit e9f35294e18da82162004a2f35976e7031aaf7f9 ] syzbot reported WARNING in max_vclocks_store. This occurs when the argument max is too large for kcalloc to handle. Extend the guard to guard against values that are too large for kcalloc Reported-by: syzbot+94d20db923b9f51be0df@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=94d20db923b9f51be0df Tested-by: syzbot+94d20db923b9f51be0df@syzkaller.appspotmail.com Fixes: 73f37068d540 ("ptp: support ptp physical/virtual clocks conversion") Signed-off-by: I Viswanath Acked-by: Richard Cochran Link: https://patch.msgid.link/20250925155908.5034-1-viswanathiyyappan@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9d72df7f5eac946f853bf49c428c4e87a17d91da Author: I Viswanath Date: Wed Sep 24 19:13:50 2025 +0530 net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast [ Upstream commit 958baf5eaee394e5fd976979b0791a875f14a179 ] syzbot reported WARNING in rtl8150_start_xmit/usb_submit_urb. This is the sequence of events that leads to the warning: rtl8150_start_xmit() { netif_stop_queue(); usb_submit_urb(dev->tx_urb); } rtl8150_set_multicast() { netif_stop_queue(); netif_wake_queue(); <-- wakes up TX queue before URB is done } rtl8150_start_xmit() { netif_stop_queue(); usb_submit_urb(dev->tx_urb); <-- double submission } rtl8150_set_multicast being the ndo_set_rx_mode callback should not be calling netif_stop_queue and notif_start_queue as these handle TX queue synchronization. The net core function dev_set_rx_mode handles the synchronization for rtl8150_set_multicast making it safe to remove these locks. Reported-and-tested-by: syzbot+78cae3f37c62ad092caa@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=78cae3f37c62ad092caa Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Tested-by: Michal Pecio Signed-off-by: I Viswanath Link: https://patch.msgid.link/20250924134350.264597-1-viswanathiyyappan@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f0e4731166060fe76f8ac2c99ce6686cdbed7eea Author: Claudiu Manoil Date: Wed Sep 24 16:27:55 2025 +0800 net: enetc: Fix probing error message typo for the ENETCv4 PF driver [ Upstream commit c35cf24a69b00b7f54f2f19838f2b82d54480b0f ] Blamed commit wrongly indicates VF error in case of PF probing error. Fixes: 99100d0d9922 ("net: enetc: add preliminary support for i.MX95 ENETC PF") Signed-off-by: Claudiu Manoil Signed-off-by: Wei Fang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250924082755.1984798-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f8e2e723c71e20be20b0f18a1bb968161fe52286 Author: Bernard Metzler Date: Tue Sep 23 16:45:36 2025 +0200 RDMA/siw: Always report immediate post SQ errors [ Upstream commit fdd0fe94d68649322e391c5c27dd9f436b4e955e ] In siw_post_send(), any immediate error encountered during processing of the work request list must be reported to the caller, even if previous work requests in that list were just accepted and added to the send queue. Not reporting those errors confuses the caller, which would wait indefinitely for the failing and potentially subsequently aborted work requests completion. This fixes a case where immediate errors were overwritten by subsequent code in siw_post_send(). Fixes: 303ae1cdfdf7 ("rdma/siw: application interface") Link: https://patch.msgid.link/r/20250923144536.103825-1-bernard.metzler@linux.dev Suggested-by: Stefan Metzmacher Signed-off-by: Bernard Metzler Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit aadc266c09cebd09cf61b5cb5216962c6e1c557d Author: Alessandro Zanni Date: Wed Sep 24 19:16:28 2025 +0200 iommu/selftest: prevent use of uninitialized variable [ Upstream commit 1d235d8494259b588bc3b7d29bc73ce34bf885bc ] Fix to avoid the usage of the `res` variable uninitialized in the following macro expansions. It solves the following warning: In function ‘iommufd_viommu_vdevice_alloc’, inlined from ‘wrapper_iommufd_viommu_vdevice_alloc’ at iommufd.c:2889:1: ../kselftest_harness.h:760:12: warning: ‘ret’ may be used uninitialized [-Wmaybe-uninitialized] 760 | if (!(__exp _t __seen)) { \ | ^ ../kselftest_harness.h:513:9: note: in expansion of macro ‘__EXPECT’ 513 | __EXPECT(expected, #expected, seen, #seen, ==, 1) | ^~~~~~~~ iommufd_utils.h:1057:9: note: in expansion of macro ‘ASSERT_EQ’ 1057 | ASSERT_EQ(0, _test_cmd_trigger_vevents(self->fd, dev_id, nvevents)) | ^~~~~~~~~ iommufd.c:2924:17: note: in expansion of macro ‘test_cmd_trigger_vevents’ 2924 | test_cmd_trigger_vevents(dev_id, 3); | ^~~~~~~~~~~~~~~~~~~~~~~~ The issue can be reproduced, building the tests, with the command: make -C tools/testing/selftests TARGETS=iommu Link: https://patch.msgid.link/r/20250924171629.50266-1-alessandro.zanni87@gmail.com Fixes: 97717a1f283f ("iommufd/selftest: Add IOMMU_VEVENTQ_ALLOC test coverage") Signed-off-by: Alessandro Zanni Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 8d096ce0e87bdc361f0b25d7943543bc53aa0b9e Author: Lu Baolu Date: Fri Sep 26 10:41:30 2025 +0800 iommu/vt-d: Disallow dirty tracking if incoherent page walk [ Upstream commit 57f55048e564dedd8a4546d018e29d6bbfff0a7e ] Dirty page tracking relies on the IOMMU atomically updating the dirty bit in the paging-structure entry. For this operation to succeed, the paging- structure memory must be coherent between the IOMMU and the CPU. In another word, if the iommu page walk is incoherent, dirty page tracking doesn't work. The Intel VT-d specification, Section 3.10 "Snoop Behavior" states: "Remapping hardware encountering the need to atomically update A/EA/D bits in a paging-structure entry that is not snooped will result in a non- recoverable fault." To prevent an IOMMU from being incorrectly configured for dirty page tracking when it is operating in an incoherent mode, mark SSADS as supported only when both ecap_slads and ecap_smpwc are supported. Fixes: f35f22cc760e ("iommu/vt-d: Access/Dirty bit support for SS domains") Signed-off-by: Lu Baolu Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20250924083447.123224-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit eed38dd549471987cc432175145254d10432cec3 Author: Dmitry Baryshkov Date: Wed Sep 24 22:34:02 2025 +0300 ASoC: qcom: sc8280xp: use sa8775p/ subdir for QCS9100 / QCS9075 [ Upstream commit ba0c67d3c4b0ce5ec5e6de35e6433b22eecb1f6a ] All firmware for the Lemans platform aka QCS9100 aka QCS9075 is for historical reasons located in the qcom/sa8775p/ subdir inside linux-firmware. The only exceptions to this rule are audio topology files. While it's not too late, change the subdir to point to the sa8775p/ subdir, so that all firmware for that platform is present at the same location. Fixes: 5b5bf5922f4c ("ASoC: qcom: sc8280xp: Add sound card support for QCS9100 and QCS9075") Signed-off-by: Dmitry Baryshkov Reviewed-by: Srinivas Kandagatla Link: https://patch.msgid.link/20250924-lemans-evk-topo-v2-1-7d44909a5758@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7d38fec1704cf7ab4b75452e5bf907b514b27fee Author: Marek Vasut Date: Tue Sep 16 01:58:40 2025 +0200 PCI: rcar-gen4: Fix inverted break condition in PHY initialization [ Upstream commit 2bdf1d428f48e1077791bb7f88fd00262118256d ] R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr. 21, 2025 page 4581 Figure 104.3b Initial Setting of PCIEC(example), third quarter of the figure indicates that register 0xf8 should be polled until bit 18 becomes set to 1. Register 0xf8, bit 18 is 0 immediately after write to PCIERSTCTRL1 and is set to 1 in less than 1 ms afterward. The current readl_poll_timeout() break condition is inverted and returns when register 0xf8, bit 18 is set to 0, which in most cases means immediately. In case CONFIG_DEBUG_LOCK_ALLOC=y, the timing changes just enough for the first readl_poll_timeout() poll to already read register 0xf8, bit 18 as 1 and afterward never read register 0xf8, bit 18 as 0, which leads to timeout and failure to start the PCIe controller. Fix this by inverting the poll condition to match the reference manual initialization sequence. Fixes: faf5a975ee3b ("PCI: rcar-gen4: Add support for R-Car V4H") Signed-off-by: Marek Vasut Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Geert Uytterhoeven Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20250915235910.47768-1-marek.vasut+renesas@mailbox.org Signed-off-by: Sasha Levin commit 8b7707e29d562c2c1dd059f9efe3ad6e1b118c2a Author: Marek Vasut Date: Wed Sep 24 02:55:45 2025 +0200 PCI: rcar-gen4: Assure reset occurs before DBI access [ Upstream commit 0056d29f8c1b13d7e60d60cdb159767ac8f6a883 ] Assure the reset is latched and the core is ready for DBI access. On R-Car V4H, the PCIe reset is asynchronous and does not take effect immediately, but needs a short time to complete. In case DBI access happens in that short time, that access generates an SError. Make sure that condition can never happen, read back the state of the reset, which should turn the asynchronous reset into a synchronous one, and wait a little over 1ms to add additional safety margin. Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode") Signed-off-by: Marek Vasut Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Geert Uytterhoeven Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20250924005610.96484-1-marek.vasut+renesas@mailbox.org Signed-off-by: Sasha Levin commit 5436e7d378697a6201a8ac27cd00d08a7ce971d8 Author: Marek Vasut Date: Fri Sep 19 15:45:58 2025 +0200 PCI: rcar-gen4: Add missing 1ms delay after PWR reset assertion [ Upstream commit 8795b70581770657cd5ead3c965348f05242580f ] R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr. 21, 2025 page 585 Figure 9.3.2 Software Reset flow (B) indicates that for peripherals in HSC domain, after reset has been asserted by writing a matching reset bit into register SRCR, it is mandatory to wait 1ms. Because it is the controller driver which can determine whether or not the controller is in HSC domain based on its compatible string, add the missing delay in the controller driver. This 1ms delay is documented on R-Car V4H and V4M; it is currently unclear whether S4 is affected as well. This patch does apply the extra delay on R-Car S4 as well. Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode") Suggested-by: Geert Uytterhoeven Signed-off-by: Marek Vasut [mani: added the missing r-b tag from Krzysztof] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Geert Uytterhoeven Reviewed-by: Krzysztof Wilczyński Link: https://patch.msgid.link/20250919134644.208098-1-marek.vasut+renesas@mailbox.org Signed-off-by: Sasha Levin commit 4664e01f9f3766f4f420cf731d2b85a2e588340b Author: Cristian Ciocaltea Date: Tue Sep 2 15:15:46 2025 +0300 usb: vhci-hcd: Prevent suspending virtually attached devices [ Upstream commit e40b984b6c4ce3f80814f39f86f87b2a48f2e662 ] The VHCI platform driver aims to forbid entering system suspend when at least one of the virtual USB ports are bound to an active USB/IP connection. However, in some cases, the detection logic doesn't work reliably, i.e. when all devices attached to the virtual root hub have been already suspended, leading to a broken suspend state, with unrecoverable resume. Ensure the virtually attached devices do not enter suspend by setting the syscore PM flag. Note this is currently limited to the client side only, since the server side doesn't implement system suspend prevention. Fixes: 04679b3489e0 ("Staging: USB/IP: add client driver") Signed-off-by: Cristian Ciocaltea Acked-by: Shuah Khan Link: https://lore.kernel.org/r/20250902-vhci-hcd-suspend-fix-v3-1-864e4e833559@collabora.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 970ceb1bdc3d6c2af9245d6eca38606e74fcb6b8 Author: Ranjan Kumar Date: Mon Sep 22 15:21:10 2025 +0530 scsi: mpt3sas: Fix crash in transport port remove by using ioc_info() [ Upstream commit 1703fe4f8ae50d1fb6449854e1fcaed1053e3a14 ] During mpt3sas_transport_port_remove(), messages were logged with dev_printk() against &mpt3sas_port->port->dev. At this point the SAS transport device may already be partially unregistered or freed, leading to a crash when accessing its struct device. Using ioc_info(), which logs via the PCI device (ioc->pdev->dev), guaranteed to remain valid until driver removal. [83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI [83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G OE 6.16.0-rc1+ #1 PREEMPT(voluntary) [83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024 [83428.295799] RIP: 0010:__dev_printk+0x1f/0x70 [83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff [83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206 [83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32 [83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845 [83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8 [83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000 [83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30 [83428.295833] FS: 00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000 [83428.295837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0 [83428.295844] PKRU: 55555554 [83428.295846] Call Trace: [83428.295848] [83428.295850] _dev_printk+0x5c/0x80 [83428.295857] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.295863] mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas] [83428.295882] _scsih_remove_device+0x21b/0x280 [mpt3sas] [83428.295894] ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas] [83428.295906] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.295910] mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas] [83428.295921] _scsih_expander_node_remove+0x129/0x140 [mpt3sas] [83428.295933] _scsih_expander_node_remove+0x6a/0x140 [mpt3sas] [83428.295944] scsih_remove+0x3f0/0x4a0 [mpt3sas] [83428.295957] pci_device_remove+0x3b/0xb0 [83428.295962] device_release_driver_internal+0x193/0x200 [83428.295968] driver_detach+0x44/0x90 [83428.295971] bus_remove_driver+0x69/0xf0 [83428.295975] pci_unregister_driver+0x2a/0xb0 [83428.295979] _mpt3sas_exit+0x1f/0x300 [mpt3sas] [83428.295991] __do_sys_delete_module.constprop.0+0x174/0x310 [83428.295997] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.296000] ? __x64_sys_getdents64+0x9a/0x110 [83428.296005] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.296009] ? syscall_trace_enter+0xf6/0x1b0 [83428.296014] do_syscall_64+0x7b/0x2c0 [83428.296019] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.296023] entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS") Signed-off-by: Ranjan Kumar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d9df61afb8d23c475f1be3c714da2c34c156ab01 Author: Zhongqiu Han Date: Wed Sep 17 17:41:43 2025 +0800 scsi: ufs: core: Fix data race in CPU latency PM QoS request handling [ Upstream commit 79dde5f7dc7c038eec903745dc1550cd4139980e ] The cpu_latency_qos_add/remove/update_request interfaces lack internal synchronization by design, requiring the caller to ensure thread safety. The current implementation relies on the 'pm_qos_enabled' flag, which is insufficient to prevent concurrent access and cannot serve as a proper synchronization mechanism. This has led to data races and list corruption issues. A typical race condition call trace is: [Thread A] ufshcd_pm_qos_exit() --> cpu_latency_qos_remove_request() --> cpu_latency_qos_apply(); --> pm_qos_update_target() --> plist_del <--(1) delete plist node --> memset(req, 0, sizeof(*req)); --> hba->pm_qos_enabled = false; [Thread B] ufshcd_devfreq_target --> ufshcd_devfreq_scale --> ufshcd_scale_clks --> ufshcd_pm_qos_update <--(2) pm_qos_enabled is true --> cpu_latency_qos_update_request --> pm_qos_update_target --> plist_del <--(3) plist node use-after-free Introduces a dedicated mutex to serialize PM QoS operations, preventing data races and ensuring safe access to PM QoS resources, including sysfs interface reads. Fixes: 2777e73fc154 ("scsi: ufs: core: Add CPU latency QoS support for UFS driver") Signed-off-by: Zhongqiu Han Reviewed-by: Bart Van Assche Tested-by: Huan Tang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 18986319edb07086ebc7ddc53a8c5e81c1184436 Author: Eric Dumazet Date: Wed Sep 24 07:27:09 2025 +0000 netfilter: nf_conntrack: do not skip entries in /proc/net/nf_conntrack [ Upstream commit c5ba345b2d358b07cc4f07253ba1ada73e77d586 ] ct_seq_show() has an opportunistic garbage collector : if (nf_ct_should_gc(ct)) { nf_ct_kill(ct); goto release; } So if one nf_conn is killed there, next time ct_get_next() runs, we skip the following item in the bucket, even if it should have been displayed if gc did not take place. We can decrement st->skip_elems to tell ct_get_next() one of the items was removed from the chain. Fixes: 58e207e4983d ("netfilter: evict stale entries when user reads /proc/net/nf_conntrack") Signed-off-by: Eric Dumazet Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 8736a4b5afc7546d794c7382726e3a5d2495c643 Author: Fernando Fernandez Mancera Date: Fri Sep 19 14:40:43 2025 +0200 netfilter: nfnetlink: reset nlh pointer during batch replay [ Upstream commit 09efbac953f6f076a07735f9ba885148d4796235 ] During a batch replay, the nlh pointer is not reset until the parsing of the commands. Since commit bf2ac490d28c ("netfilter: nfnetlink: Handle ACK flags for batch messages") that is problematic as the condition to add an ACK for batch begin will evaluate to true even if NLM_F_ACK wasn't used for batch begin message. If there is an error during the command processing, netlink is sending an ACK despite that. This misleads userspace tools which think that the return code was 0. Reset the nlh pointer to the original one when a replay is triggered. Fixes: bf2ac490d28c ("netfilter: nfnetlink: Handle ACK flags for batch messages") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit a343811ef138a265407167294275201621e9ebb2 Author: Slavin Liu Date: Fri Sep 12 01:57:59 2025 +0800 ipvs: Defer ip_vs_ftp unregister during netns cleanup [ Upstream commit 134121bfd99a06d44ef5ba15a9beb075297c0821 ] On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp before connections with valid cp->app pointers are flushed, leading to a use-after-free. Fix this by introducing a global `exiting_module` flag, set to true in ip_vs_ftp_exit() before unregistering the pernet subsystem. In __ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns cleanup (when exiting_module is false) and defer it to __ip_vs_cleanup_batch(), which unregisters all apps after all connections are flushed. If called during module exit, unregister ip_vs_ftp immediately. Fixes: 61b1ab4583e2 ("IPVS: netns, add basic init per netns.") Suggested-by: Julian Anastasov Signed-off-by: Slavin Liu Signed-off-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit aec4d4fa0516e8915a1da5cd0b588a27384344d5 Author: Vadim Fedorenko Date: Mon Sep 22 16:19:24 2025 -0700 net: ethtool: tsconfig: set command must provide a reply [ Upstream commit e8ab231782e92bc26e5eb605263525636a2f7ae7 ] Timestamping configuration through ethtool has inconsistent behavior of skipping the reply for set command if configuration was not changed. Fix it be providing reply in any case. Fixes: 6e9e2eed4f39d ("net: ethtool: Add support for tsconfig command to get/set hwtstamp config") Signed-off-by: Vadim Fedorenko Reviewed-by: Kory Maincent Link: https://patch.msgid.link/20250922231924.2769571-1-vadfed@meta.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ff8c370a3b59ee91e715ab382a6050031e31142d Author: Anthony Iliopoulos Date: Wed Aug 13 11:00:46 2025 +0200 NFSv4.1: fix backchannel max_resp_sz verification check [ Upstream commit 191512355e520dfc45c8bc3b56d4de59c3ade33e ] When the client max_resp_sz is larger than what the server encodes in its reply, the nfs4_verify_back_channel_attrs() check fails and this causes nfs4_proc_create_session() to fail, in cases where the client page size is larger than that of the server and the server does not want to negotiate upwards. While this is not a problem with the linux nfs server that will reflect the proposed value in its reply irrespective of the local page size, other nfs server implementations may insist on their own max_resp_sz value, which could be smaller. Fix this by accepting smaller max_resp_sz values from the server, as this does not violate the protocol. The server is allowed to decrease but not increase proposed the size, and as such values smaller than the client-proposed ones are valid. Fixes: 43c2e885be25 ("nfs4: fix channel attribute sanity-checks") Signed-off-by: Anthony Iliopoulos Reviewed-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 9688b66d0a5e0eecf44f6286b8d9f7a161264035 Author: Lin Yujun Date: Mon Sep 8 20:20:22 2025 +0800 coresight: Fix incorrect handling for return value of devm_kzalloc [ Upstream commit 70714eb7243eaf333d23501d4c7bdd9daf011c01 ] The return value of devm_kzalloc could be an null pointer, use "!desc.pdata" to fix incorrect handling return value of devm_kzalloc. Fixes: 4277f035d227 ("coresight: trbe: Add a representative coresight_platform_data for TRBE") Signed-off-by: Lin Yujun Reviewed-by: James Clark Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250908122022.1315399-1-linyujun809@h-partners.com Signed-off-by: Sasha Levin commit d0b7172e45a9cba104afdc20399b3e6dbe1f07c6 Author: Jie Gan Date: Sat Sep 6 07:53:04 2025 +0800 coresight: tpda: fix the logic to setup the element size [ Upstream commit 43e0a92c04de7c822f6104abc73caa4a857b4a02 ] Some TPDM devices support both CMB and DSB datasets, requiring the system to enable the port with both corresponding element sizes. Currently, the logic treats tpdm_read_element_size as successful if the CMB element size is retrieved correctly, regardless of whether the DSB element size is obtained. This behavior causes issues when parsing data from TPDM devices that depend on both element sizes. To address this, the function should explicitly fail if the DSB element size cannot be read correctly. Fixes: e6d7f5252f73 ("coresight-tpda: Add support to configure CMB element") Reviewed-by: James Clark Signed-off-by: Jie Gan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250906-fix_element_size_issue-v2-1-dbb0ac2541a9@oss.qualcomm.com Signed-off-by: Sasha Levin commit f505a165f1c7cd37b4cb6952042a5984693a4067 Author: Leo Yan Date: Thu Sep 4 15:13:52 2025 +0100 coresight: trbe: Return NULL pointer for allocation failures [ Upstream commit 8a55c161f7f9c1aa1c70611b39830d51c83ef36d ] When the TRBE driver fails to allocate a buffer, it currently returns the error code "-ENOMEM". However, the caller etm_setup_aux() only checks for a NULL pointer, so it misses the error. As a result, the driver continues and eventually causes a kernel panic. Fix this by returning a NULL pointer from arm_trbe_alloc_buffer() on allocation failures. This allows that the callers can properly handle the failure. Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") Reported-by: Tamas Zsoldos Signed-off-by: Leo Yan Reviewed-by: James Clark Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250904-cs_etm_auxsetup_fix_error_handling-v2-1-a502d0bafb95@arm.com Signed-off-by: Sasha Levin commit 63287a1e893a29e90ca48af0787aff29214c4f17 Author: Leo Yan Date: Thu Jul 31 13:23:42 2025 +0100 coresight: Avoid enable programming clock duplicately [ Upstream commit d091c6312561821f216ced63a7ad17c946b6d335 ] The programming clock is enabled by AMBA bus driver before a dynamic probe. As a result, a CoreSight driver may redundantly enable the same clock. To avoid this, add a check for device type and skip enabling the programming clock for AMBA devices. The returned NULL pointer will be tolerated by the drivers. Fixes: 73d779a03a76 ("coresight: etm4x: Change etm4_platform_driver driver for MMIO devices") Reviewed-by: Anshuman Khandual Reviewed-by: Yeoreum Yun Tested-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250731-arm_cs_fix_clock_v4-v6-6-1dfe10bb3f6f@arm.com Signed-off-by: Sasha Levin commit 331b31bfe76e07f88f3e788dcff9117bffc934d1 Author: Leo Yan Date: Thu Jul 31 13:23:41 2025 +0100 coresight: Appropriately disable trace bus clocks [ Upstream commit a8f2d480f19d912f15dbac7038cd578d6b8b4d74 ] Some CoreSight components have trace bus clocks 'atclk' and are enabled using clk_prepare_enable(). These clocks are not disabled when modules exit. As atclk is optional, use devm_clk_get_optional_enabled() to manage it. The benefit is the driver model layer can automatically disable and release clocks. Check the returned value with IS_ERR() to detect errors but leave the NULL pointer case if the clock is not found. And remove the error handling codes which are no longer needed. Fixes: d1839e687773 ("coresight: etm: retrieve and handle atclk") Reviewed-by: Anshuman Khandual Reviewed-by: Yeoreum Yun Tested-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250731-arm_cs_fix_clock_v4-v6-5-1dfe10bb3f6f@arm.com Signed-off-by: Sasha Levin commit da4203acbda4614e636d3993b6e1b2f661b1a27b Author: Leo Yan Date: Thu Jul 31 13:23:40 2025 +0100 coresight: Appropriately disable programming clocks [ Upstream commit 1abc1b212effe920f4729353880c8e03f1d76b4b ] Some CoreSight components have programming clocks (pclk) and are enabled using clk_get() and clk_prepare_enable(). However, in many cases, these clocks are not disabled when modules exit and only released by clk_put(). To fix the issue, this commit refactors programming clock by replacing clk_get() and clk_prepare_enable() with devm_clk_get_optional_enabled() for enabling APB clock. If the "apb_pclk" clock is not found, a NULL pointer is returned, and the function proceeds to attempt enabling the "apb" clock. Since ACPI platforms rely on firmware to manage clocks, returning a NULL pointer in this case leaves clock management to the firmware rather than the driver. This effectively avoids a clock imbalance issue during module removal - where the clock could be disabled twice: once during the ACPI runtime suspend and again during the devm resource release. Callers are updated to reuse the returned error value. With the change, programming clocks are managed as resources in driver model layer, allowing clock cleanup to be handled automatically. As a result, manual cleanup operations are no longer needed and are removed from the Coresight drivers. Fixes: 73d779a03a76 ("coresight: etm4x: Change etm4_platform_driver driver for MMIO devices") Reviewed-by: Yeoreum Yun Tested-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250731-arm_cs_fix_clock_v4-v6-4-1dfe10bb3f6f@arm.com Signed-off-by: Sasha Levin commit 8116e7a2eaa5a496739fd3ae46ecd831b56b7f1d Author: Leo Yan Date: Thu Jul 31 13:23:39 2025 +0100 coresight: etm4x: Support atclk [ Upstream commit 40c0cdc9cbbebae9f43bef1cab9ce152318d0cce ] The atclk is an optional clock for the CoreSight ETMv4, but the driver misses to initialize it. This change enables atclk in probe of the ETMv4 driver, and dynamically control the clock during suspend and resume. No need to check the driver data and clock pointer in the runtime suspend and resume, so remove checks. And add error handling in the resume function. Add a minor fix to the comment format when adding the atclk field. Fixes: 2e1cdfe184b5 ("coresight-etm4x: Adding CoreSight ETM4x driver") Reviewed-by: Anshuman Khandual Reviewed-by: Yeoreum Yun Tested-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250731-arm_cs_fix_clock_v4-v6-3-1dfe10bb3f6f@arm.com Signed-off-by: Sasha Levin commit 06a418c1a221307ca5c1f40ea719f534bf137f5c Author: Leo Yan Date: Thu Jul 31 13:23:38 2025 +0100 coresight: catu: Support atclk [ Upstream commit 5483624effea2e893dc0df6248253a6a2a085451 ] The atclk is an optional clock for the CoreSight CATU, but the driver misses to initialize it. This change enables atclk in probe of the CATU driver, and dynamically control the clock during suspend and resume. The checks for driver data and clocks in suspend and resume are not needed, remove them. Add error handling in the resume function. Fixes: fcacb5c154ba ("coresight: Introduce support for Coresight Address Translation Unit") Reviewed-by: Anshuman Khandual Reviewed-by: Yeoreum Yun Tested-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250731-arm_cs_fix_clock_v4-v6-2-1dfe10bb3f6f@arm.com Signed-off-by: Sasha Levin commit b95887fc15e694a74161a8c7c92c6398033d485f Author: Leo Yan Date: Thu Jul 31 13:23:37 2025 +0100 coresight: tmc: Support atclk [ Upstream commit 8a79026926b329d4ab0c6d0921373a80ec8aab6e ] The atclk is an optional clock for the CoreSight TMC, but the driver misses to initialize it. In most cases, TMC shares the atclk clock with other CoreSight components. Since these components enable the clock before the TMC device is initialized, the TMC continues properly, which is why we don’t observe any lockup issues. This change enables atclk in probe of the TMC driver. Given the clock is optional, it is possible to return NULL if the clock does not exist. IS_ERR() is tolerant for this case. Dynamically disable and enable atclk during suspend and resume. The clock pointers will never be error values if the driver has successfully probed, and the case of a NULL pointer case will be handled by the clock core layer. The driver data is always valid after probe. Therefore, remove the related checks. Also in the resume flow adds error handling. Fixes: bc4bf7fe98da ("coresight-tmc: add CoreSight TMC driver") Reviewed-by: Anshuman Khandual Reviewed-by: Yeoreum Yun Tested-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250731-arm_cs_fix_clock_v4-v6-1-1dfe10bb3f6f@arm.com Signed-off-by: Sasha Levin commit c0dd36df9e489026300745e9f30f8f7c2f7ecab9 Author: Yuanfang Zhang Date: Tue Aug 12 01:24:45 2025 -0700 coresight-etm4x: Conditionally access register TRCEXTINSELR [ Upstream commit dcdc42f5dcf9b9197c51246c62966e2d54a033d8 ] The TRCEXTINSELR is only implemented if TRCIDR5.NUMEXTINSEL > 0. To avoid invalid accesses, introduce a check on numextinsel (derived from TRCIDR5[11:9]) before reading or writing to this register. Fixes: f5bd523690d2 ("coresight: etm4x: Convert all register accesses") Signed-off-by: Yuanfang Zhang Reviewed-by: James Clark Reviewed-by: Mike Leach Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250812-trcextinselr_issue-v2-1-e6eb121dfcf4@oss.qualcomm.com Signed-off-by: Sasha Levin commit b3e4da1cb82ad36d20bfc3a07558696fa38baf22 Author: Yeoreum Yun Date: Wed Jun 11 11:30:25 2025 +0100 coresight: fix indentation error in cscfg_remove_owned_csdev_configs() [ Upstream commit 21dd3f8bc24b6adc57f09fff5430b0039dd00492 ] Fix wrong indentation in cscfg_remove_owned_csdev_configs() Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202506102238.XQfScl5x-lkp@intel.com/ Fixes: 53b9e2659719 ("coresight: holding cscfg_csdev_lock while removing cscfg from csdev") Signed-off-by: Yeoreum Yun Reviewed-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250611103025.939020-1-yeoreum.yun@arm.com Signed-off-by: Sasha Levin commit 14179a1690a951a4bf3c28f2f53158bdf8cf9fd5 Author: Ivan Abramov Date: Tue Sep 9 23:22:38 2025 +0300 dm vdo: return error on corrupted metadata in start_restoring_volume functions [ Upstream commit 9ddf6d3fcbe0b96e318da364cf7e6b59cd4cb5a2 ] The return values of VDO_ASSERT calls that validate metadata are not acted upon. Return UDS_CORRUPT_DATA in case of an error. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a4eb7e255517 ("dm vdo: implement the volume index") Signed-off-by: Ivan Abramov Reviewed-by: Matthew Sakai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 2feef19cd9a9d632cbb31b1db3592591ad9baee6 Author: Ryder Lee Date: Mon Sep 22 22:19:08 2025 +0000 wifi: cfg80211: fix width unit in cfg80211_radio_chandef_valid() [ Upstream commit 17f34ab55a8518ecbd5dcacec48e6ee903f7c1d0 ] The original code used nl80211_chan_width_to_mhz(), which returns the width in MHz. However, the expected unit is KHz. Fixes: 510dba80ed66 ("wifi: cfg80211: add helper for checking if a chandef is valid on a radio") Signed-off-by: Ryder Lee Link: https://patch.msgid.link/df54294e6c4ed0f3ceff6e818b710478ddfc62c0.1758579480.git.Ryder%20Lee%20ryder.lee@mediatek.com/ Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 7da4876b3f84af687fe76d1340a0aa1a24fa3b07 Author: Nithyanantham Paramasivam Date: Wed Aug 6 16:47:49 2025 +0530 wifi: ath12k: Fix flush cache failure during RX queue update [ Upstream commit 5e32edc6942570429d9c64d0641fc2addbf92be1 ] Flush cache failures were observed after RX queue update for TID delete. This occurred because the queue was invalid during flush. Set the VLD bit in the RX queue update command for TID delete. This ensures the queue remains valid during the flush cache process. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Nithyanantham Paramasivam Reviewed-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250806111750.3214584-7-nithyanantham.paramasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit c868b94f720c7f37a6d7921f93c6d43c9ef5455c Author: Nithyanantham Paramasivam Date: Wed Aug 6 16:47:45 2025 +0530 wifi: ath12k: Refactor RX TID deletion handling into helper function [ Upstream commit 7c32476253f11210ac24c7818ca07e19bc032521 ] Refactor RX TID deletion handling by moving the REO command setup and send sequence into a new helper function: ath12k_dp_rx_tid_delete_handler(). This improves code readability and modularity, and prepares the codebase for potential reuse of the REO command logic in other contexts where RX TID deletion is required. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Nithyanantham Paramasivam Reviewed-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250806111750.3214584-3-nithyanantham.paramasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson Stable-dep-of: 5e32edc69425 ("wifi: ath12k: Fix flush cache failure during RX queue update") Signed-off-by: Sasha Levin commit ee150acd273aded01a726ce39b1f6128200799e6 Author: Stephan Gerhold Date: Wed Aug 20 18:02:35 2025 +0200 remoteproc: qcom: pas: Shutdown lite ADSP DTB on X1E [ Upstream commit 142964960c7c35de5c5f7bdd61c32699de693630 ] The ADSP firmware on X1E has separate firmware binaries for the main firmware and the DTB. The same applies for the "lite" firmware loaded by the boot firmware. When preparing to load the new ADSP firmware we shutdown the lite_pas_id for the main firmware, but we don't shutdown the corresponding lite pas_id for the DTB. The fact that we're leaving it "running" forever becomes obvious if you try to reuse (or just access) the memory region used by the "lite" firmware: The &adsp_boot_mem is accessible, but accessing the &adsp_boot_dtb_mem results in a crash. We don't support reusing the memory regions currently, but nevertheless we should not keep part of the lite firmware running. Fix this by adding the lite_dtb_pas_id and shutting it down as well. We don't have a way to detect if the lite firmware is actually running yet, so ignore the return status of qcom_scm_pas_shutdown() for now. This was already the case before, the assignment to "ret" is not used anywhere. Fixes: 62210f7509e1 ("remoteproc: qcom_q6v5_pas: Unload lite firmware on ADSP") Reviewed-by: Dmitry Baryshkov Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20250820-rproc-qcom-q6v5-fixes-v2-3-910b1a3aff71@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit af53dcdc036edc588dfceb4bd3da342126035f77 Author: Stephan Gerhold Date: Wed Aug 20 18:02:33 2025 +0200 remoteproc: qcom: q6v5: Avoid disabling handover IRQ twice [ Upstream commit 110be46f5afe27b66caa2d12473a84cd397b1925 ] enable_irq() and disable_irq() are reference counted, so we must make sure that each enable_irq() is always paired with a single disable_irq(). If we call disable_irq() twice followed by just a single enable_irq(), the IRQ will remain disabled forever. For the error handling path in qcom_q6v5_wait_for_start(), disable_irq() will end up being called twice, because disable_irq() also happens in qcom_q6v5_unprepare() when rolling back the call to qcom_q6v5_prepare(). Fix this by dropping disable_irq() in qcom_q6v5_wait_for_start(). Since qcom_q6v5_prepare() is the function that calls enable_irq(), it makes more sense to have the rollback handled always by qcom_q6v5_unprepare(). Fixes: 3b415c8fb263 ("remoteproc: q6v5: Extract common resource handling") Reviewed-by: Dmitry Baryshkov Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20250820-rproc-qcom-q6v5-fixes-v2-1-910b1a3aff71@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6287576ff71a018230ac4240ac8a99b6bc3dcd85 Author: Nagarjuna Kristam Date: Thu Sep 11 11:30:22 2025 +0200 PCI: tegra194: Fix duplicate PLL disable in pex_ep_event_pex_rst_assert() [ Upstream commit 4f152338e384a3a47dd61909e1457539fa93f5a4 ] During PERST# assertion tegra_pcie_bpmp_set_pll_state() is currently called twice. pex_ep_event_pex_rst_assert() should do the opposite of pex_ep_event_pex_rst_deassert(), so it is obvious that the duplicate tegra_pcie_bpmp_set_pll_state() is a mistake, and that the duplicate tegra_pcie_bpmp_set_pll_state() call should instead be a call to tegra_pcie_bpmp_set_ctrl_state(). With this, the uninitialization sequence also matches that of tegra_pcie_unconfig_controller(). Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support") Signed-off-by: Nagarjuna Kristam [cassel: improve commit log] Signed-off-by: Niklas Cassel Link: https://patch.msgid.link/20250911093021.1454385-2-cassel@kernel.org [mani: added Fixes tag] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin commit a5296e9c2644669c534eaa8d823d850cac688bb6 Author: Fedor Pchelkin Date: Sat Sep 20 00:08:50 2025 +0300 wifi: rtw89: avoid circular locking dependency in ser_state_run() [ Upstream commit 570f94511766f9236d3462dfb8a3c719c2b54c23 ] Lockdep gives a splat [1] when ser_hdl_work item is executed. It is scheduled at mac80211 workqueue via ieee80211_queue_work() and takes a wiphy lock inside. However, this workqueue can be flushed when e.g. closing the interface and wiphy lock is already taken in that case. Choosing wiphy_work_queue() for SER is likely not suitable. Back on to the global workqueue. [1]: WARNING: possible circular locking dependency detected 6.17.0-rc2 #17 Not tainted ------------------------------------------------------ kworker/u32:1/61 is trying to acquire lock: ffff88811bc00768 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ser_state_run+0x5e/0x180 [rtw89_core] but task is already holding lock: ffffc9000048fd30 ((work_completion)(&ser->ser_hdl_work)){+.+.}-{0:0}, at: process_one_work+0x7b5/0x1450 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 ((work_completion)(&ser->ser_hdl_work)){+.+.}-{0:0}: process_one_work+0x7c6/0x1450 worker_thread+0x49e/0xd00 kthread+0x313/0x640 ret_from_fork+0x221/0x300 ret_from_fork_asm+0x1a/0x30 -> #1 ((wq_completion)phy0){+.+.}-{0:0}: touch_wq_lockdep_map+0x8e/0x180 __flush_workqueue+0x129/0x10d0 ieee80211_stop_device+0xa8/0x110 ieee80211_do_stop+0x14ce/0x2880 ieee80211_stop+0x13a/0x2c0 __dev_close_many+0x18f/0x510 __dev_change_flags+0x25f/0x670 netif_change_flags+0x7b/0x160 do_setlink.isra.0+0x1640/0x35d0 rtnl_newlink+0xd8c/0x1d30 rtnetlink_rcv_msg+0x700/0xb80 netlink_rcv_skb+0x11d/0x350 netlink_unicast+0x49a/0x7a0 netlink_sendmsg+0x759/0xc20 ____sys_sendmsg+0x812/0xa00 ___sys_sendmsg+0xf7/0x180 __sys_sendmsg+0x11f/0x1b0 do_syscall_64+0xbb/0x360 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&rdev->wiphy.mtx){+.+.}-{4:4}: __lock_acquire+0x124c/0x1d20 lock_acquire+0x154/0x2e0 __mutex_lock+0x17b/0x12f0 ser_state_run+0x5e/0x180 [rtw89_core] rtw89_ser_hdl_work+0x119/0x220 [rtw89_core] process_one_work+0x82d/0x1450 worker_thread+0x49e/0xd00 kthread+0x313/0x640 ret_from_fork+0x221/0x300 ret_from_fork_asm+0x1a/0x30 other info that might help us debug this: Chain exists of: &rdev->wiphy.mtx --> (wq_completion)phy0 --> (work_completion)(&ser->ser_hdl_work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&ser->ser_hdl_work)); lock((wq_completion)phy0); lock((work_completion)(&ser->ser_hdl_work)); lock(&rdev->wiphy.mtx); *** DEADLOCK *** 2 locks held by kworker/u32:1/61: #0: ffff888103835148 ((wq_completion)phy0){+.+.}-{0:0}, at: process_one_work+0xefa/0x1450 #1: ffffc9000048fd30 ((work_completion)(&ser->ser_hdl_work)){+.+.}-{0:0}, at: process_one_work+0x7b5/0x1450 stack backtrace: CPU: 0 UID: 0 PID: 61 Comm: kworker/u32:1 Not tainted 6.17.0-rc2 #17 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025 Workqueue: phy0 rtw89_ser_hdl_work [rtw89_core] Call Trace: dump_stack_lvl+0x5d/0x80 print_circular_bug.cold+0x178/0x1be check_noncircular+0x14c/0x170 __lock_acquire+0x124c/0x1d20 lock_acquire+0x154/0x2e0 __mutex_lock+0x17b/0x12f0 ser_state_run+0x5e/0x180 [rtw89_core] rtw89_ser_hdl_work+0x119/0x220 [rtw89_core] process_one_work+0x82d/0x1450 worker_thread+0x49e/0xd00 kthread+0x313/0x640 ret_from_fork+0x221/0x300 ret_from_fork_asm+0x1a/0x30 Found by Linux Verification Center (linuxtesting.org). Fixes: ebfc9199df05 ("wifi: rtw89: add wiphy_lock() to work that isn't held wiphy_lock() yet") Signed-off-by: Fedor Pchelkin Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250919210852.823912-5-pchelkin@ispras.ru Signed-off-by: Sasha Levin commit 547432ee1db97d16060ab4766fd22d6593ece41a Author: Fedor Pchelkin Date: Sat Sep 20 00:08:49 2025 +0300 wifi: rtw89: fix leak in rtw89_core_send_nullfunc() [ Upstream commit a9f0064f4716b0fd97085015ea1dd398bdfdc946 ] If there is no rtwsta_link found in rtw89_core_send_nullfunc(), allocated skb is leaked. Free it on the error handling path. Found by Linux Verification Center (linuxtesting.org). Fixes: a8ba4acab7db ("wifi: rtw89: send nullfunc based on the given link") Signed-off-by: Fedor Pchelkin Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250919210852.823912-4-pchelkin@ispras.ru Signed-off-by: Sasha Levin commit 2c9876a402c9bf753552e220d255ec30e5b70f0e Author: Chunyu Hu Date: Fri Sep 12 09:37:11 2025 +0800 selftests/mm: fix va_high_addr_switch.sh failure on x86_64 [ Upstream commit c56325259abc026205c98964616dcc0df5648912 ] The test will fail as below on x86_64 with cpu la57 support (will skip if no la57 support). Note, the test requries nr_hugepages to be set first. # running bash ./va_high_addr_switch.sh # ------------------------------------- # mmap(addr_switch_hint - pagesize, pagesize): 0x7f55b60fa000 - OK # mmap(addr_switch_hint - pagesize, (2 * pagesize)): 0x7f55b60f9000 - OK # mmap(addr_switch_hint, pagesize): 0x800000000000 - OK # mmap(addr_switch_hint, 2 * pagesize, MAP_FIXED): 0x800000000000 - OK # mmap(NULL): 0x7f55b60f9000 - OK # mmap(low_addr): 0x40000000 - OK # mmap(high_addr): 0x1000000000000 - OK # mmap(high_addr) again: 0xffff55b6136000 - OK # mmap(high_addr, MAP_FIXED): 0x1000000000000 - OK # mmap(-1): 0xffff55b6134000 - OK # mmap(-1) again: 0xffff55b6132000 - OK # mmap(addr_switch_hint - pagesize, pagesize): 0x7f55b60fa000 - OK # mmap(addr_switch_hint - pagesize, 2 * pagesize): 0x7f55b60f9000 - OK # mmap(addr_switch_hint - pagesize/2 , 2 * pagesize): 0x7f55b60f7000 - OK # mmap(addr_switch_hint, pagesize): 0x800000000000 - OK # mmap(addr_switch_hint, 2 * pagesize, MAP_FIXED): 0x800000000000 - OK # mmap(NULL, MAP_HUGETLB): 0x7f55b5c00000 - OK # mmap(low_addr, MAP_HUGETLB): 0x40000000 - OK # mmap(high_addr, MAP_HUGETLB): 0x1000000000000 - OK # mmap(high_addr, MAP_HUGETLB) again: 0xffff55b5e00000 - OK # mmap(high_addr, MAP_FIXED | MAP_HUGETLB): 0x1000000000000 - OK # mmap(-1, MAP_HUGETLB): 0x7f55b5c00000 - OK # mmap(-1, MAP_HUGETLB) again: 0x7f55b5a00000 - OK # mmap(addr_switch_hint - pagesize, 2*hugepagesize, MAP_HUGETLB): 0x800000000000 - FAILED # mmap(addr_switch_hint , 2*hugepagesize, MAP_FIXED | MAP_HUGETLB): 0x800000000000 - OK # [FAIL] addr_switch_hint is defined as DFEFAULT_MAP_WINDOW in the failed test (for x86_64, DFEFAULT_MAP_WINDOW is defined as (1UL<<47) - pagesize) in 64 bit. Before commit cc92882ee218 ("mm: drop hugetlb_get_unmapped_area{_*} functions"), for x86_64 hugetlb_get_unmapped_area() is handled in arch code arch/x86/mm/hugetlbpage.c and addr is checked with map_address_hint_valid() after align with 'addr &= huge_page_mask(h)' which is a round down way, and it will fail the check because the addr is within the DEFAULT_MAP_WINDOW but (addr + len) is above the DFEFAULT_MAP_WINDOW. So it wil go through the hugetlb_get_unmmaped_area_top_down() to find an area within the DFEFAULT_MAP_WINDOW. After commit cc92882ee218 ("mm: drop hugetlb_get_unmapped_area{_*} functions"). The addr hint for hugetlb_get_unmmaped_area() will be rounded up and aligned to hugepage size with ALIGN() for all arches. And after the align, the addr will be above the default MAP_DEFAULT_WINDOW, and the map_addresshint_valid() check will pass because both aligned addr (addr0) and (addr + len) are above the DEFAULT_MAP_WINDOW, and the aligned hint address (0x800000000000) is returned as an suitable gap is found there, in arch_get_unmapped_area_topdown(). To still cover the case that addr is within the DEFAULT_MAP_WINDOW, and addr + len is above the DFEFAULT_MAP_WINDOW, change to choose the last hugepage aligned address within the DEFAULT_MAP_WINDOW as the hint addr, and the addr + len (2 hugepages) will be one hugepage above the DEFAULT_MAP_WINDOW. An aligned address won't be affected by the page round up or round down from kernel, so it's determistic. Link: https://lkml.kernel.org/r/20250912013711.3002969-4-chuhu@redhat.com Fixes: cc92882ee218 ("mm: drop hugetlb_get_unmapped_area{_*} functions") Signed-off-by: Chunyu Hu Suggested-by: David Hildenbrand Acked-by: David Hildenbrand Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 660b6959c4170637f5db2279d1f71af33a49e49b Author: Gui-Dong Han Date: Fri Sep 19 02:52:12 2025 +0000 RDMA/rxe: Fix race in do_task() when draining [ Upstream commit 8ca7eada62fcfabf6ec1dc7468941e791c1d8729 ] When do_task() exhausts its iteration budget (!ret), it sets the state to TASK_STATE_IDLE to reschedule, without a secondary check on the current task->state. This can overwrite the TASK_STATE_DRAINING state set by a concurrent call to rxe_cleanup_task() or rxe_disable_task(). While state changes are protected by a spinlock, both rxe_cleanup_task() and rxe_disable_task() release the lock while waiting for the task to finish draining in the while(!is_done(task)) loop. The race occurs if do_task() hits its iteration limit and acquires the lock in this window. The cleanup logic may then proceed while the task incorrectly reschedules itself, leading to a potential use-after-free. This bug was introduced during the migration from tasklets to workqueues, where the special handling for the draining case was lost. Fix this by restoring the original pre-migration behavior. If the state is TASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to force a new loop iteration. This allows the task to finish its work, so that a subsequent iteration can reach the switch statement and correctly transition the state to TASK_STATE_DRAINED, stopping the task as intended. Fixes: 9b4b7c1f9f54 ("RDMA/rxe: Add workqueue support for rxe tasks") Reviewed-by: Zhu Yanjun Signed-off-by: Gui-Dong Han Link: https://patch.msgid.link/20250919025212.1682087-1-hanguidong02@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 0bde883063cfcb4dfc8570531c436551d524a8aa Author: Dmitry Baryshkov Date: Sun Jul 6 17:47:08 2025 +0300 remoteproc: qcom_q6v5_mss: support loading MBN file on msm8974 [ Upstream commit 581e3dea0ece4b59cf714c9dfe195a178d3ae13b ] On MSM8974 / APQ8074, MSM8226 and MSM8926 the MSS requires loading raw MBA image instead of the ELF file. Skip the ELF headers if mba.mbn was specified as the firmware image. Fixes: a5a4e02d083d ("remoteproc: qcom: Add support for parsing fw dt bindings") Signed-off-by: Dmitry Baryshkov Signed-off-by: Dmitry Baryshkov Tested-by: Luca Weiss # msm8974pro-fairphone-fp2 Link: https://lore.kernel.org/r/20250706-msm8974-fix-mss-v4-1-630907dbd898@oss.qualcomm.com [bjorn: Unwrapped the long memcpy line, to taste] Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 579f4ea106cf9fed5071093162d0efc4ecbb2f77 Author: Barnabás Czémán Date: Fri Jul 25 22:02:58 2025 +0200 rpmsg: qcom_smd: Fix fallback to qcom,ipc parse [ Upstream commit 09390ed9af37ed612dd0967ff2b0d639872b8776 ] mbox_request_channel() returning value was changed in case of error. It uses returning value of of_parse_phandle_with_args(). It is returning with -ENOENT instead of -ENODEV when no mboxes property exists. Fixes: 24fdd5074b20 ("mailbox: use error ret code of of_parse_phandle_with_args()") Reviewed-by: Dmitry Baryshkov Reviewed-by: Stephan Gerhold Tested-by: Stephan Gerhold # msm8939 Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20250725-fix-qcom-smd-v2-1-e4e43613f874@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit da64eb2da76ce5626238a951fdf3e81810454427 Author: Hari Chandrakanthan Date: Thu Jul 24 09:35:52 2025 +0530 wifi: ath12k: Fix peer lookup in ath12k_dp_mon_rx_deliver_msdu() [ Upstream commit 7ca61ed8b3f3fc9a7decd68039cb1d7d1238c566 ] In ath12k_dp_mon_rx_deliver_msdu(), peer lookup fails because rxcb->peer_id is not updated with a valid value. This is expected in monitor mode, where RX frames bypass the regular RX descriptor path that typically sets rxcb->peer_id. As a result, the peer is NULL, and link_id and link_valid fields in the RX status are not populated. This leads to a WARN_ON in mac80211 when it receives data frame from an associated station with invalid link_id. Fix this potential issue by using ppduinfo->peer_id, which holds the correct peer id for the received frame. This ensures that the peer is correctly found and the associated link metadata is updated accordingly. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: bd00cc7e8a4c ("wifi: ath12k: replace the usage of rx desc with rx_info") Signed-off-by: Hari Chandrakanthan Signed-off-by: Aishwarya R Reviewed-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250724040552.1170642-1-aishwarya.r@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 7226a0650ad5705bd8d39a11be270fa21ed1e6a5 Author: Chenghai Huang Date: Sat Sep 13 18:57:54 2025 +0800 crypto: hisilicon/qm - set NULL to qm->debug.qm_diff_regs [ Upstream commit f0cafb02de883b3b413d34eb079c9680782a9cc1 ] When the initialization of qm->debug.acc_diff_reg fails, the probe process does not exit. However, after qm->debug.qm_diff_regs is freed, it is not set to NULL. This can lead to a double free when the remove process attempts to free it again. Therefore, qm->debug.qm_diff_regs should be set to NULL after it is freed. Fixes: 8be091338971 ("crypto: hisilicon/debugfs - Fix debugfs uninit process issue") Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 779d3b6f2d32c5f1da6163e959abe1e1ffe2945b Author: Dan Moulding Date: Mon Sep 8 10:12:43 2025 -0600 crypto: comp - Use same definition of context alloc and free ops [ Upstream commit f75f66683ded09f7135aef2e763c245a07c8271a ] In commit 42d9f6c77479 ("crypto: acomp - Move scomp stream allocation code into acomp"), the crypto_acomp_streams struct was made to rely on having the alloc_ctx and free_ctx operations defined in the same order as the scomp_alg struct. But in that same commit, the alloc_ctx and free_ctx members of scomp_alg may be randomized by structure layout randomization, since they are contained in a pure ops structure (containing only function pointers). If the pointers within scomp_alg are randomized, but those in crypto_acomp_streams are not, then the order may no longer match. This fixes the problem by removing the union from scomp_alg so that both crypto_acomp_streams and scomp_alg will share the same definition of alloc_ctx and free_ctx, ensuring they will always have the same layout. Signed-off-by: Dan Moulding Suggested-by: Herbert Xu Fixes: 42d9f6c77479 ("crypto: acomp - Move scomp stream allocation code into acomp") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c6f7d1f357328d8991aaed7e67ba6232033b016d Author: Zilin Guan Date: Sat Sep 13 15:31:54 2025 +0000 vfio/pds: replace bitmap_free with vfree [ Upstream commit acb59a4bb8ed34e738a4c3463127bf3f6b5e11a9 ] host_seq_bmp is allocated with vzalloc but is currently freed with bitmap_free, which uses kfree internally. This mismach prevents the resource from being released properly and may result in memory leaks or other issues. Fix this by freeing host_seq_bmp with vfree to match the vzalloc allocation. Fixes: f232836a9152 ("vfio/pds: Add support for dirty page tracking") Signed-off-by: Zilin Guan Reviewed-by: Brett Creeley Link: https://lore.kernel.org/r/20250913153154.1028835-1-zilin@seu.edu.cn Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit ccdbebbde4d9d42052a25e7368359597542c606c Author: Michael Karcher Date: Fri Sep 5 00:03:34 2025 +0200 sparc: fix accurate exception reporting in copy_{from,to}_user for M7 [ Upstream commit 936fb512752af349fc30ccbe0afe14a2ae6d7159 ] The referenced commit introduced exception handlers on user-space memory references in copy_from_user and copy_to_user. These handlers return from the respective function and calculate the remaining bytes left to copy using the current register contents. This commit fixes a couple of bad calculations. This will fix the return value of copy_from_user and copy_to_user in the faulting case. The behaviour of memcpy stays unchanged. Fixes: 34060b8fffa7 ("arch/sparc: Add accurate exception reporting in M7memcpy") Tested-by: John Paul Adrian Glaubitz # on Oracle SPARC S7 Tested-by: Tony Rodriguez # S7, see https://lore.kernel.org/r/98564e2e68df2dda0e00c67a75c7f7dfedb33c7e.camel@physik.fu-berlin.de Signed-off-by: Michael Karcher Reviewed-by: Andreas Larsson Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-5-1ca72dda195b@mkarcher.dialup.fu-berlin.de Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit 82df73a7c2afd48d7d08554be98d0ab60cf55fee Author: Michael Karcher Date: Fri Sep 5 00:03:33 2025 +0200 sparc: fix accurate exception reporting in copy_to_user for Niagara 4 [ Upstream commit 5a746c1a2c7980de6c888b6373299f751ad7790b ] The referenced commit introduced exception handlers on user-space memory references in copy_from_user and copy_to_user. These handlers return from the respective function and calculate the remaining bytes left to copy using the current register contents. This commit fixes a bad calculation. This will fix the return value of copy_to_user in a specific faulting case. The behaviour of memcpy stays unchanged. Fixes: 957077048009 ("sparc64: Convert NG4copy_{from,to}_user to accurate exception reporting.") Tested-by: John Paul Adrian Glaubitz # on Oracle SPARC T4-1 Signed-off-by: Michael Karcher Reviewed-by: Andreas Larsson Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-4-1ca72dda195b@mkarcher.dialup.fu-berlin.de Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit 088c5098ec6d6b0396edfbf3dad3e81de8469c1c Author: Michael Karcher Date: Fri Sep 5 00:03:32 2025 +0200 sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara [ Upstream commit 0b67c8fc10b13a9090340c5f8a37d308f4e1571c ] The referenced commit introduced exception handlers on user-space memory references in copy_from_user and copy_to_user. These handlers return from the respective function and calculate the remaining bytes left to copy using the current register contents. This commit fixes a couple of bad calculations and a broken epilogue in the exception handlers. This will prevent crashes and ensure correct return values of copy_from_user and copy_to_user in the faulting case. The behaviour of memcpy stays unchanged. Fixes: 7ae3aaf53f16 ("sparc64: Convert NGcopy_{from,to}_user to accurate exception reporting.") Tested-by: John Paul Adrian Glaubitz # on SPARC T4 with modified kernel to use Niagara 1 code Tested-by: Magnus Lindholm # on Sun Fire T2000 Signed-off-by: Michael Karcher Tested-by: Ethan Hawke # on Sun Fire T2000 Tested-by: Ken Link # on Sun Fire T1000 Reviewed-by: Andreas Larsson Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-3-1ca72dda195b@mkarcher.dialup.fu-berlin.de Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit e50377c6b3f278c9f3ef017ffce17f5fcc9dace4 Author: Michael Karcher Date: Fri Sep 5 00:03:31 2025 +0200 sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III [ Upstream commit 47b49c06eb62504075f0f2e2227aee2e2c2a58b3 ] Anthony Yznaga tracked down that a BUG_ON in ext4 code with large folios enabled resulted from copy_from_user() returning impossibly large values greater than the size to be copied. This lead to __copy_from_iter() returning impossible values instead of the actual number of bytes it was able to copy. The BUG_ON has been reported in https://lore.kernel.org/r/b14f55642207e63e907965e209f6323a0df6dcee.camel@physik.fu-berlin.de The referenced commit introduced exception handlers on user-space memory references in copy_from_user and copy_to_user. These handlers return from the respective function and calculate the remaining bytes left to copy using the current register contents. The exception handlers expect that %o2 has already been masked during the bulk copy loop, but the masking was performed after that loop. This will fix the return value of copy_from_user and copy_to_user in the faulting case. The behaviour of memcpy stays unchanged. Fixes: ee841d0aff64 ("sparc64: Convert U3copy_{from,to}_user to accurate exception reporting.") Tested-by: John Paul Adrian Glaubitz # on Sun Netra 240 Reviewed-by: Anthony Yznaga Tested-by: René Rebe # on UltraSparc III+ and UltraSparc IIIi Signed-off-by: Michael Karcher Reviewed-by: Andreas Larsson Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-2-1ca72dda195b@mkarcher.dialup.fu-berlin.de Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit 57c278500fce3cd4e1c540700c0b05426a958393 Author: Michael Karcher Date: Fri Sep 5 00:03:30 2025 +0200 sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC [ Upstream commit 4fba1713001195e59cfc001ff1f2837dab877efb ] The referenced commit introduced exception handlers on user-space memory references in copy_from_user and copy_to_user. These handlers return from the respective function and calculate the remaining bytes left to copy using the current register contents. This commit fixes a couple of bad calculations. This will fix the return value of copy_from_user and copy_to_user in the faulting case. The behaviour of memcpy stays unchanged. Fixes: cb736fdbb208 ("sparc64: Convert U1copy_{from,to}_user to accurate exception reporting.") Tested-by: John Paul Adrian Glaubitz # on QEMU 10.0.3 Tested-by: René Rebe # on Ultra 5 UltraSparc IIi Tested-by: Jonathan 'theJPster' Pallant # on Sun Netra T1 Signed-off-by: Michael Karcher Reviewed-by: Andreas Larsson Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-1-1ca72dda195b@mkarcher.dialup.fu-berlin.de Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit a5416c0fc9e77b69f853dfb1e78bc05a7c06a789 Author: Richard Fitzgerald Date: Fri Sep 19 15:02:35 2025 +0100 ASoC: Intel: sof_sdw: Prevent jump to NULL add_sidecar callback [ Upstream commit 87cab86925b7fa4c1c977bc191ac549a3b23f0ea ] In create_sdw_dailink() check that sof_end->codec_info->add_sidecar is not NULL before calling it. The original code assumed that if include_sidecar is true, the codec on that link has an add_sidecar callback. But there could be other codecs on the same link that do not have an add_sidecar callback. Fixes: da5244180281 ("ASoC: Intel: sof_sdw: Add callbacks to register sidecar devices") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20250919140235.1071941-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7009aca1943f17fbe274b9a01ed11f7470b15a3d Author: Aditya Kumar Singh Date: Wed Sep 17 12:42:03 2025 +0530 wifi: mac80211: fix Rx packet handling when pubsta information is not available [ Upstream commit 32d340ae675800672e1219444a17940a8efe5cca ] In ieee80211_rx_handle_packet(), if the caller does not provide pubsta information, an attempt is made to find the station using the address 2 (source address) field in the header. Since pubsta is missing, link information such as link_valid and link_id is also unavailable. Now if such a situation comes, and if a matching ML station entry is found based on the source address, currently the packet is dropped due to missing link ID in the status field which is not correct. Hence, to fix this issue, if link_valid is not set and the station is an ML station, make an attempt to find a link station entry using the source address. If a valid link station is found, derive the link ID and proceed with packet processing. Otherwise, drop the packet as per the existing flow. Fixes: ea9d807b5642 ("wifi: mac80211: add link information in ieee80211_rx_status") Suggested-by: Vasanthakumar Thiagarajan Signed-off-by: Aditya Kumar Singh Link: https://patch.msgid.link/20250917-fix_data_packet_rx_with_mlo_and_no_pubsta-v1-1-8cf971a958ac@oss.qualcomm.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit df2bf759a0bdb71f13e327d7527260d09facc055 Author: Vineeth Pillai (Google) Date: Thu Sep 18 13:01:59 2025 +0800 iommu/vt-d: debugfs: Fix legacy mode page table dump logic [ Upstream commit fbe6070c73badca726e4ff7877320e6c62339917 ] In legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR maybe uninitialized or zero in that case and may cause oops like: Oops: general protection fault, probably for non-canonical address 0xf00087d3f000f000: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 RIP: 0010:pgtable_walk_level+0x98/0x150 RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206 RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000 RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000 R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98 FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: pgtable_walk_level+0x88/0x150 domain_translation_struct_show.isra.0+0x2d9/0x300 dev_domain_translation_struct_show+0x20/0x40 seq_read_iter+0x12d/0x490 ... Avoid walking the page table if TT is not 00b or 01b. Fixes: 2b437e804566 ("iommu/vt-d: debugfs: Support dumping a specified page table") Signed-off-by: Vineeth Pillai (Google) Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20250814163153.634680-1-vineeth@bitbyteword.org Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 85ef57bc230fe3cbe4a91550aa67c77391f08adb Author: Baochen Qiang Date: Mon Aug 11 17:26:45 2025 +0800 wifi: ath10k: avoid unnecessary wait for service ready message [ Upstream commit 51a73f1b2e56b0324b4a3bb8cebc4221b5be4c7a ] Commit e57b7d62a1b2 ("wifi: ath10k: poll service ready message before failing") works around the failure in waiting for the service ready message by active polling. Note the polling is triggered after initial wait timeout, which means that the wait-till-timeout can not be avoided even the message is ready. A possible fix is to do polling once before wait as well, however this can not handle the race that the message arrives right after polling. So the solution is to do periodic polling until timeout. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00309-QCARMSWPZ-1 Fixes: e57b7d62a1b2 ("wifi: ath10k: poll service ready message before failing") Reported-by: Paul Menzel Closes: https://lore.kernel.org/all/97a15967-5518-4731-a8ff-d43ff7f437b0@molgen.mpg.de Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250811-ath10k-avoid-unnecessary-wait-v1-1-db2deb87c39b@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit f987488845169423cc6d820a599b8db357848ee9 Author: Baochen Qiang Date: Fri Aug 15 09:44:57 2025 +0800 wifi: ath12k: fix wrong logging ID used for CE [ Upstream commit 43746f13fec67f6f223d64cfe96c095c9b468e70 ] ATH12K_DBG_AHB is used for CE logging which is not proper. Add ATH12K_DBG_CE and replace ATH12K_DBG_AHB with it. Compile tested only. Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250815-ath-dont-warn-on-ce-enqueue-fail-v1-2-f955ddc3ba7a@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit feeae76d7d4d9ff962e6057f4ecf5b210a53d440 Author: Sriram R Date: Thu Jul 24 00:36:51 2025 +0530 wifi: ath12k: Add fallback for invalid channel number in PHY metadata [ Upstream commit 26f8fc0b24fd1a9dba1000bc9b5f2b199b7775a0 ] Currently, ath12k_dp_rx_h_ppdu() determines the band and frequency based on the channel number and center frequency from the RX descriptor's PHY metadata. However, in rare cases, it is observed that frequency retrieved from the metadata may be invalid or unexpected especially for 6 GHz frames. This can result in a NULL sband, which prevents proper frequency assignment in rx_status and potentially leading to incorrect RX packet classification. To fix this potential issue, add a fallback mechanism that uses ar->rx_channel to populate the band and frequency when the derived sband is invalid or missing. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Sriram R Co-developed-by: Vinith Kumar R Signed-off-by: Vinith Kumar R Signed-off-by: Aishwarya R Reviewed-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250723190651.699828-1-aishwarya.r@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 4030ec7a677c52047b17d645ec2267516762941d Author: Kang Yang Date: Tue Jul 22 17:59:34 2025 +0800 wifi: ath12k: fix the fetching of combined rssi [ Upstream commit 7695fa71c1d50a375e54426421acbc8d457bc5a3 ] Currently, host fetches combined rssi from rssi_comb in struct hal_rx_phyrx_rssi_legacy_info. rssi_comb is 8th to 15th bits of the second to last variable. rssi_comb_ppdu is the 0th to 7th of the last variable. When bandwidth = 20MHz, rssi_comb = rssi_comb_ppdu. But when bandwidth > 20MHz, rssi_comb < rssi_comb_ppdu because rssi_comb only includes power of primary 20 MHz while rssi_comb_ppdu includes power of active RUs/subchannels. So should fetch combined rssi from rssi_comb_ppdu. Also related macro definitions are too long, rename them. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Kang Yang Reviewed-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250722095934.67-4-kang.yang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit b45392d73224120987732f5573a5a565a22d7b38 Author: Kang Yang Date: Tue Jul 22 17:59:33 2025 +0800 wifi: ath12k: fix HAL_PHYRX_COMMON_USER_INFO handling in monitor mode [ Upstream commit 6b46e85129185ec076f9c3bd2813dfd2f968522b ] Current monitor mode will parse TLV HAL_PHYRX_OTHER_RECEIVE_INFO with struct hal_phyrx_common_user_info. Obviously, they do not match. The original intention here was to parse HAL_PHYRX_COMMON_USER_INFO. So fix it by correctly parsing HAL_PHYRX_COMMON_USER_INFO instead. Also add LTF parsing and report to radiotap along with GI. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: d939919a36f4 ("wifi: ath12k: Add HAL_PHYRX_OTHER_RECEIVE_INFO TLV parsing support") Signed-off-by: Kang Yang Reviewed-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250722095934.67-3-kang.yang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 96323fec3016f9ae51a1a5fda9374f40eb9f1108 Author: Kang Yang Date: Tue Jul 22 17:59:32 2025 +0800 wifi: ath12k: fix signal in radiotap for WCN7850 [ Upstream commit cf412ae7b7124e2b3bfe472616ec24b117b6008a ] Currently host will add ATH12K_DEFAULT_NOISE_FLOOR to rssi_comb to convert RSSI from dB to dBm. For WCN7850, this conversion is unnecessary because the RSSI value is already reported in dBm units. No longer convert for those firmware that already support dBM conversion. This patch won't affect QCN chips. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Kang Yang Reviewed-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250722095934.67-2-kang.yang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 0dd04c02eebfbc4feba13272cacf85993f7d4b62 Author: Baochen Qiang Date: Mon Aug 4 11:03:11 2025 +0800 wifi: ath12k: fix overflow warning on num_pwr_levels [ Upstream commit ea2b0af4c9e3f7187b5be4b7fc1511ea239046c0 ] In ath12k_mac_parse_tx_pwr_env(), for the non-PSD case num_pwr_levels is limited by ATH12K_NUM_PWR_LEVELS which is 16: if (tpc_info->num_pwr_levels > ATH12K_NUM_PWR_LEVELS) tpc_info->num_pwr_levels = ATH12K_NUM_PWR_LEVELS; Then it is used to iterate entries in local_non_psd->power[] and reg_non_psd->power[]: for (i = 0; i < tpc_info->num_pwr_levels; i++) { tpc_info->tpe[i] = min(local_non_psd->power[i], reg_non_psd->power[i]) / 2; Since the two array are of size 5, Smatch warns: drivers/net/wireless/ath/ath12k/mac.c:9812 ath12k_mac_parse_tx_pwr_env() error: buffer overflow 'local_non_psd->power' 5 <= 15 drivers/net/wireless/ath/ath12k/mac.c:9812 ath12k_mac_parse_tx_pwr_env() error: buffer overflow 'reg_non_psd->power' 5 <= 15 This is a false positive as there is already implicit limitation: tpc_info->num_pwr_levels = max(local_non_psd->count, reg_non_psd->count); meaning it won't exceed 5. However, to make robot happy, add explicit limit there. Also add the same to the PSD case, although no warning due to ATH12K_NUM_PWR_LEVELS equals IEEE80211_TPE_PSD_ENTRIES_320MHZ. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Fixes: cccbb9d0dd6a ("wifi: ath12k: add parse of transmit power envelope element") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202505180703.Kr9OfQRP-lkp@intel.com/ Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250804-ath12k-fix-smatch-warning-on-6g-vlp-v1-2-56f1e54152ab@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5c2470f9f8ae72d8de7303f61350836b278e9d9c Author: Baochen Qiang Date: Mon Aug 4 11:03:10 2025 +0800 wifi: ath12k: initialize eirp_power before use [ Upstream commit bba2f9faf41ee9607c78fcd669527b7654543cfe ] Currently, at the end of ath12k_mac_fill_reg_tpc_info(), the reg_tpc_info struct is populated, including the following: reg_tpc_info->is_psd_power = is_psd_power; reg_tpc_info->eirp_power = eirp_power; Kernel test robot complains on uninitialized symbol: drivers/net/wireless/ath/ath12k/mac.c:10069 ath12k_mac_fill_reg_tpc_info() error: uninitialized symbol 'eirp_power' This is because there are some code paths that never set eirp_power, so the assignment of reg_tpc_info->eirp_power can come from an uninitialized variable. Functionally this is OK since the eirp_power only has meaning when is_psd_power is true, and all code paths which set is_psd_power to true also set eirp_power. However, to keep the robot happy, always initialize eirp_power before use. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Fixes: aeda163bb0c7 ("wifi: ath12k: fill parameters for vdev set TPC power WMI command") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202505180927.tbNWr3vE-lkp@intel.com/ Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250804-ath12k-fix-smatch-warning-on-6g-vlp-v1-1-56f1e54152ab@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit f6c620076b16a28a74667b823f5c1479ad0646c1 Author: Richard Fitzgerald Date: Tue Aug 19 17:05:25 2025 +0100 ASoC: SOF: ipc4-pcm: Fix incorrect comparison with number of tdm_slots [ Upstream commit 62a7b3bbb6b873fdcc85a37efbd0102d66c8a73e ] In ipc4_ssp_dai_config_pcm_params_match() when comparing params_channels() against hw_config->tdm_slots the comparison should be a <= not a ==. The number of TDM slots must be enough for the number of required channels. But it can be greater. There are various reason why a I2S/TDM link has more TDM slots than a particular audio stream needs. The original comparison would fail on systems that had more TDM slots. Signed-off-by: Richard Fitzgerald Fixes: 8a07944a77e9 ("ASoC: SOF: ipc4-pcm: Look for best matching hw_config for SSP") Link: https://patch.msgid.link/20250819160525.423416-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f96b118a229017717d2ee382e2ba1bb543c92219 Author: Bagas Sanjaya Date: Tue Sep 16 12:42:01 2025 +0700 Documentation: trace: historgram-design: Separate sched_waking histogram section heading and the following diagram [ Upstream commit 8c716e87ea33519920811338100d6d8a7fb32456 ] Section heading for sched_waking histogram is shown as normal paragraph instead due to codeblock marker for the following diagram being in the same line as the section underline. Separate them. Fixes: daceabf1b494 ("tracing/doc: Fix ascii-art in histogram-design.rst") Reviewed-by: Tom Zanussi Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Bagas Sanjaya Acked-by: Steven Rostedt (Google) Signed-off-by: Jonathan Corbet Message-ID: <20250916054202.582074-5-bagasdotme@gmail.com> Signed-off-by: Sasha Levin commit f1f966a45e5e717afa44e7f44ead0a7822e14dac Author: Vlad Dumitrescu Date: Tue Sep 16 19:31:12 2025 +0300 IB/sa: Fix sa_local_svc_timeout_ms read race [ Upstream commit 1428cd764cd708d53a072a2f208d87014bfe05bc ] When computing the delta, the sa_local_svc_timeout_ms is read without ib_nl_request_lock held. Though unlikely in practice, this can cause a race condition if multiple local service threads are managing the timeout. Fixes: 2ca546b92a02 ("IB/sa: Route SA pathrecord query through netlink") Signed-off-by: Vlad Dumitrescu Reviewed-by: Mark Zhang Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20250916163112.98414-1-edwards@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit dea904aa39ca4bba228969578c863c75e967ce44 Author: Parav Pandit Date: Tue Sep 16 14:11:01 2025 +0300 RDMA/core: Resolve MAC of next-hop device without ARP support [ Upstream commit 200651b9b8aadfbbec852f0e5d042d9abe75e2ab ] Currently, if the next-hop netdevice does not support ARP resolution, the destination MAC address is silently set to zero without reporting an error. This leads to incorrect behavior and may result in packet transmission failures. Fix this by deferring MAC resolution to the IP stack via neighbour lookup, allowing proper resolution or error reporting as appropriate. Fixes: 7025fcd36bd6 ("IB: address translation to map IP toIB addresses (GIDs)") Signed-off-by: Parav Pandit Reviewed-by: Vlad Dumitrescu Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20250916111103.84069-3-edwards@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ad17c65f3a6c62f157ff3eb34b3814293a368dae Author: Michal Pecio Date: Thu Sep 18 00:07:20 2025 +0300 Revert "usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running" [ Upstream commit 08fa726e66039dfa80226dfa112931f60ad4c898 ] This reverts commit 28a76fcc4c85dd39633fb96edb643c91820133e3. No actual HW bugs are known where Endpoint Context shows Running state but Stop Endpoint fails repeatedly with Context State Error and leaves the endpoint state unchanged. Stop Endpoint retries on Running EPs have been performed since early 2021 with no such issues reported so far. Trying to handle this hypothetical case brings a more realistic danger: if Stop Endpoint fails on an endpoint which hasn't yet started after a doorbell ring and enough latency occurs before this completion event is handled, the driver may time out and begin removing cancelled TDs from a running endpoint, even though one more retry would stop it reliably. Such high latency is rare but not impossible, and removing TDs from a running endpoint can cause more damage than not giving back a cancelled URB (which wasn't happening anyway). So err on the side of caution and revert to the old policy of always retrying if the EP appears running. [Remove stable tag as we are dealing with theoretical cases -Mathias] Fixes: 28a76fcc4c85d ("usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running") Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250917210726.97100-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cc976ec9e38bb79409de3261ba1dbb6868e2a53e Author: Kuniyuki Iwashima Date: Tue Sep 16 21:47:25 2025 +0000 mptcp: Use __sk_dst_get() and dst_dev_rcu() in mptcp_active_enable(). [ Upstream commit 893c49a78d9f85e4b8081b908fb7c407d018106a ] mptcp_active_enable() is called from subflow_finish_connect(), which is icsk->icsk_af_ops->sk_rx_dst_set() and it's not always under RCU. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Fixes: 27069e7cb3d1 ("mptcp: disable active MPTCP in case of blackhole") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Matthieu Baerts (NGI0) Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20250916214758.650211-8-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0a14dbd8a2cb9b4033548e233f894ed4e7498654 Author: Kuniyuki Iwashima Date: Tue Sep 16 21:47:24 2025 +0000 mptcp: Call dst_release() in mptcp_active_enable(). [ Upstream commit 108a86c71c93ff28087994e6107bc99ebe336629 ] mptcp_active_enable() calls sk_dst_get(), which returns dst with its refcount bumped, but forgot dst_release(). Let's add missing dst_release(). Cc: stable@vger.kernel.org Fixes: 27069e7cb3d1 ("mptcp: disable active MPTCP in case of blackhole") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Matthieu Baerts (NGI0) Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20250916214758.650211-7-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 893c49a78d9f ("mptcp: Use __sk_dst_get() and dst_dev_rcu() in mptcp_active_enable().") Signed-off-by: Sasha Levin commit feb474ddbf26b51f462ae2e60a12013bdcfc5407 Author: Kuniyuki Iwashima Date: Tue Sep 16 21:47:23 2025 +0000 tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock(). [ Upstream commit c65f27b9c3be2269918e1cbad6d8884741f835c5 ] get_netdev_for_sock() is called during setsockopt(), so not under RCU. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the only ->ndo_sk_get_lower_dev() user is bond_sk_get_lower_dev(), which uses RCU. Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20250916214758.650211-6-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f6adf7a18049c0cbcf281fa503c19173ab006afa Author: Kuniyuki Iwashima Date: Tue Sep 16 21:47:22 2025 +0000 smc: Use __sk_dst_get() and dst_dev_rcu() in smc_vlan_by_tcpsk(). [ Upstream commit 0b0e4d51c6554e5ecc3f8cc73c2eaf12da21249a ] smc_vlan_by_tcpsk() fetches sk_dst_get(sk)->dev before RTNL and passes it to netdev_walk_all_lower_dev(), which is illegal. Also, smc_vlan_by_tcpsk_walk() does not require RTNL at all. Let's use __sk_dst_get(), dst_dev_rcu(), and netdev_walk_all_lower_dev_rcu(). Note that the returned value of smc_vlan_by_tcpsk() is not used in the caller. Fixes: 0cfdd8f92cac ("smc: connection and link group creation") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20250916214758.650211-5-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d26e80f7fb62d77757b67a1b94e4ac756bc9c658 Author: Kuniyuki Iwashima Date: Tue Sep 16 21:47:21 2025 +0000 smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match(). [ Upstream commit 235f81045c008169cc4e1955b4a64e118eebe61b ] smc_clc_prfx_match() is called from smc_listen_work() and not under RCU nor RTNL. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the returned value of smc_clc_prfx_match() is not used in the caller. Fixes: a046d57da19f ("smc: CLC handshake (incl. preparation steps)") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20250916214758.650211-4-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0736993bfe5c7a9c744ae3fac62d769dfdae54e1 Author: Kuniyuki Iwashima Date: Tue Sep 16 21:47:20 2025 +0000 smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set(). [ Upstream commit 935d783e5de9b64587f3adb25641dd8385e64ddb ] smc_clc_prfx_set() is called during connect() and not under RCU nor RTNL. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock() after kernel_getsockname(). Note that the returned value of smc_clc_prfx_set() is not used in the caller. While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu() not to touch dst there. Fixes: a046d57da19f ("smc: CLC handshake (incl. preparation steps)") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20250916214758.650211-3-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 233927b645cb7a14bb98d23ac72e4c7243a9f0d9 Author: Kuniyuki Iwashima Date: Tue Sep 16 21:47:19 2025 +0000 smc: Fix use-after-free in __pnet_find_base_ndev(). [ Upstream commit 3d3466878afd8d43ec0ca2facfbc7f03e40d0f79 ] syzbot reported use-after-free of net_device in __pnet_find_base_ndev(), which was called during connect(). [0] smc_pnet_find_ism_resource() fetches sk_dst_get(sk)->dev and passes down to pnet_find_base_ndev(), where RTNL is held. Then, UAF happened at __pnet_find_base_ndev() when the dev is first used. This means dev had already been freed before acquiring RTNL in pnet_find_base_ndev(). While dev is going away, dst->dev could be swapped with blackhole_netdev, and the dev's refcnt by dst will be released. We must hold dev's refcnt before calling smc_pnet_find_ism_resource(). Also, smc_pnet_find_roce_resource() has the same problem. Let's use __sk_dst_get() and dst_dev_rcu() in the two functions. [0]: BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609 CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline] smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline] smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154 smc_find_ism_device net/smc/af_smc.c:1030 [inline] smc_find_proposal_devices net/smc/af_smc.c:1115 [inline] __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545 smc_connect+0x877/0xd90 net/smc/af_smc.c:1715 __sys_connect_file net/socket.c:2086 [inline] __sys_connect+0x313/0x440 net/socket.c:2105 __do_sys_connect net/socket.c:2111 [inline] __se_sys_connect net/socket.c:2108 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2108 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f47cbf8eba9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9 RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000b RBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8 The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bac flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000 raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as freed page last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [inline] get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416 ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kvmalloc_node_noprof+0x6d/0x5f0 mm/slub.c:5067 alloc_netdev_mqs+0xa3/0x11b0 net/core/dev.c:11812 tun_set_iff+0x532/0xef0 drivers/net/tun.c:2775 __tun_chr_ioctl+0x788/0x1df0 drivers/net/tun.c:3085 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f page last free pid 18610 tgid 18608 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1395 [inline] __free_frozen_pages+0xbc4/0xd30 mm/page_alloc.c:2895 free_large_kmalloc+0x13a/0x1f0 mm/slub.c:4820 device_release+0x99/0x1c0 drivers/base/core.c:-1 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 netdev_run_todo+0xd2e/0xea0 net/core/dev.c:11513 rtnl_unlock net/core/rtnetlink.c:157 [inline] rtnl_net_unlock include/linux/rtnetlink.h:135 [inline] rtnl_dellink+0x537/0x710 net/core/rtnetlink.c:3563 rtnetlink_rcv_msg+0x7cc/0xb70 net/core/rtnetlink.c:6946 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 ____sys_sendmsg+0x505/0x830 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Memory state around the buggy address: ffff888036bac200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888036bac280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888036bac300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888036bac380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888036bac400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Fixes: 0afff91c6f5e ("net/smc: add pnetid support") Fixes: 1619f770589a ("net/smc: add pnetid support for SMC-D and ISM") Reported-by: syzbot+ea28e9d85be2f327b6c6@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/68c237c7.050a0220.3c6139.0036.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20250916214758.650211-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7ac6040dcaa3793d782a099d582a21125b1ca6bb Author: wangzijie Date: Wed Sep 17 10:36:21 2025 +0800 f2fs: fix zero-sized extent for precache extents [ Upstream commit 8175c864391753b210f3dcfae1aeed686a226ebb ] Script to reproduce: f2fs_io write 1 0 1881 rand dsync testfile f2fs_io fallocate 0 7708672 4096 testfile f2fs_io write 1 1881 1 rand buffered testfile fsync testfile umount mount f2fs_io precache_extents testfile When the data layout is something like this: dnode1: dnode2: [0] A [0] NEW_ADDR [1] A+1 [1] 0x0 ... [1016] A+1016 [1017] B (B!=A+1017) [1017] 0x0 During precache_extents, we map the last block(valid blkaddr) in dnode1: map->m_flags |= F2FS_MAP_MAPPED; map->m_pblk = blkaddr(valid blkaddr); map->m_len = 1; then we goto next_dnode, meet the first block in dnode2(hole), goto sync_out: map->m_flags & F2FS_MAP_MAPPED == true, and we make zero-sized extent: map->m_len = 1 ofs = start_pgofs - map->m_lblk = 1882 - 1881 = 1 ei.fofs = start_pgofs = 1882 ei.len = map->m_len - ofs = 1 - 1 = 0 Rebased on patch[1], this patch can cover these cases to avoid zero-sized extent: A,B,C is valid blkaddr case1: dnode1: dnode2: [0] A [0] NEW_ADDR [1] A+1 [1] 0x0 ... .... [1016] A+1016 [1017] B (B!=A+1017) [1017] 0x0 case2: dnode1: dnode2: [0] A [0] C (C!=B+1) [1] A+1 [1] C+1 ... .... [1016] A+1016 [1017] B (B!=A+1017) [1017] 0x0 case3: dnode1: dnode2: [0] A [0] C (C!=B+2) [1] A+1 [1] C+1 ... .... [1015] A+1015 [1016] B (B!=A+1016) [1017] B+1 [1017] 0x0 [1] https://lore.kernel.org/linux-f2fs-devel/20250912081250.44383-1-chao@kernel.org/ Fixes: c4020b2da4c9 ("f2fs: support F2FS_IOC_PRECACHE_EXTENTS") Signed-off-by: wangzijie Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 347a13f8a6e3b6c60106dcf7257f7ed0ae0b58c4 Author: Benjamin Tissoires Date: Fri Sep 12 18:58:51 2025 +0200 HID: hidraw: tighten ioctl command parsing [ Upstream commit 75d5546f60b36900051d75ee623fceccbeb6750c ] The handling for variable-length ioctl commands in hidraw_ioctl() is rather complex and the check for the data direction is incomplete. Simplify this code by factoring out the various ioctls grouped by dir and size, and using a switch() statement with the size masked out, to ensure the rest of the command is correctly matched. Fixes: 9188e79ec3fd ("HID: add phys and name ioctls to hidraw") Reported-by: Arnd Bergmann Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 14fa71379b2ae133c5857bd8c752c01b68cf129e Author: Qianfeng Rong Date: Fri Sep 5 15:54:45 2025 +0800 scsi: qla2xxx: Fix incorrect sign of error code in qla_nvme_xmt_ls_rsp() [ Upstream commit 9877c004e9f4d10e7786ac80a50321705d76e036 ] Change the error code EAGAIN to -EAGAIN in qla_nvme_xmt_ls_rsp() to align with qla2x00_start_sp() returning negative error codes or QLA_SUCCESS, preventing logical errors. Fixes: 875386b98857 ("scsi: qla2xxx: Add Unsolicited LS Request and Response Support for NVMe") Signed-off-by: Qianfeng Rong Message-ID: <20250905075446.381139-4-rongqianfeng@vivo.com> Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1482819dddda61e1f6cdb8703241bec85bc3c505 Author: Qianfeng Rong Date: Fri Sep 5 15:54:44 2025 +0800 scsi: qla2xxx: Fix incorrect sign of error code in START_SP_W_RETRIES() [ Upstream commit 1f037e3acda79639a78f096355f2c308a3d45492 ] Change the error code EAGAIN to -EAGAIN in START_SP_W_RETRIES() to align with qla2x00_start_sp() returning negative error codes or QLA_SUCCESS, preventing logical errors. Additionally, the '_rval' variable should store negative error codes to conform to Linux kernel error code conventions. Fixes: 9803fb5d2759 ("scsi: qla2xxx: Fix task management cmd failure") Signed-off-by: Qianfeng Rong Message-ID: <20250905075446.381139-3-rongqianfeng@vivo.com> Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d67dd01daa95d53bbd62b1355f1abee48098ae7f Author: Qianfeng Rong Date: Fri Sep 5 15:54:43 2025 +0800 scsi: qla2xxx: edif: Fix incorrect sign of error code [ Upstream commit 066b8f3fa85c1be7fb7dbae202231e131d38f7bc ] Change the error code EAGAIN to -EAGAIN in qla24xx_sadb_update() and qla_edif_process_els() to align with qla2x00_start_sp() returning negative error codes or QLA_SUCCESS, preventing logical errors. Fixes: 0b3f3143d473 ("scsi: qla2xxx: edif: Add retry for ELS passthrough") Signed-off-by: Qianfeng Rong Message-ID: <20250905075446.381139-2-rongqianfeng@vivo.com> Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 689cfd92aa1598bd6fdc118bb1e9e20b4d0ed800 Author: Colin Ian King Date: Tue Sep 2 12:45:18 2025 +0100 ACPI: NFIT: Fix incorrect ndr_desc being reportedin dev_err message [ Upstream commit d1a599a8136b16522b5afebd122395524496d549 ] There appears to be a cut-n-paste error with the incorrect field ndr_desc->numa_node being reported for the target node. Fix this by using ndr_desc->target_node instead. Fixes: f060db99374e ("ACPI: NFIT: Use fallback node id when numa info in NFIT table is incorrect") Signed-off-by: Colin Ian King Reviewed-by: Ira Weiny Signed-off-by: Ira Weiny Signed-off-by: Sasha Levin commit 3969b6193cb7a45aa5fb4ec68f215e9e7f93d39a Author: Sebastian Andrzej Siewior Date: Mon Sep 15 17:28:51 2025 +0200 ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RT [ Upstream commit 9fc4a3da9a0259a0500848b5d8657918efde176b ] snd_pcm_group_lock_irq() acquires a spinlock_t and disables interrupts via spin_lock_irq(). This also implicitly disables the handling of softirqs such as TIMER_SOFTIRQ. On PREEMPT_RT softirqs are preemptible and spin_lock_irq() does not disable them. That means a timer can be invoked during spin_lock_irq() on the same CPU. Due to synchronisations reasons local_bh_disable() has a per-CPU lock named softirq_ctrl.lock which synchronizes individual softirq against each other. syz-bot managed to trigger a lockdep report where softirq_ctrl.lock is acquired in hrtimer_cancel() in addition to hrtimer_run_softirq(). This is a possible deadlock. The softirq_ctrl.lock can not be made part of spin_lock_irq() as this would lead to too much synchronisation against individual threads on the system. To avoid the possible deadlock, softirqs must be manually disabled before the lock is acquired. Disable softirqs before the lock is acquired on PREEMPT_RT. Reported-by: syzbot+10b4363fb0f46527f3f3@syzkaller.appspotmail.com Fixes: d2d6422f8bd1 ("x86: Allow to enable PREEMPT_RT.") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d00b61cd37f4c183ce0edbc9f8ccf6d5430ea357 Author: Fangyu Yu Date: Thu Aug 21 10:25:40 2025 -0400 RISC-V: KVM: Write hgatp register with valid mode bits [ Upstream commit 2b351e3d04be9e1533f26c3464f1e44a5beace30 ] According to the RISC-V Privileged Architecture Spec, when MODE=Bare is selected,software must write zero to the remaining fields of hgatp. We have detected the valid mode supported by the HW before, So using a valid mode to detect how many vmid bits are supported. Fixes: fd7bb4a251df ("RISC-V: KVM: Implement VMID allocator") Reviewed-by: Nutty Liu Reviewed-by: Troy Mitchell Reviewed-by: Guo Ren (Alibaba DAMO Academy) Signed-off-by: Fangyu Yu Signed-off-by: Guo Ren (Alibaba DAMO Academy) Link: https://lore.kernel.org/r/20250821142542.2472079-2-guoren@kernel.org Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit 9239611af7e01cbdd8ed3f91924c893fc9574b57 Author: Chao Yu Date: Tue Sep 16 10:47:09 2025 +0800 f2fs: fix to mitigate overhead of f2fs_zero_post_eof_page() [ Upstream commit c2f7c32b254006ad48f8e4efb2e7e7bf71739f17 ] f2fs_zero_post_eof_page() may cuase more overhead due to invalidate_lock and page lookup, change as below to mitigate its overhead: - check new_size before grabbing invalidate_lock - lookup and invalidate pages only in range of [old_size, new_size] Fixes: ba8dac350faf ("f2fs: fix to zero post-eof page") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit eec1589be36fcf7440755703e4faeee2c01e360b Author: Chao Yu Date: Mon Sep 1 10:04:15 2025 +0800 f2fs: fix to avoid migrating empty section [ Upstream commit d625a2b08c089397d3a03bff13fa8645e4ec7a01 ] It reports a bug from device w/ zufs: F2FS-fs (dm-64): Inconsistent segment (173822) type [1, 0] in SSA and SIT F2FS-fs (dm-64): Stopped filesystem due to reason: 4 Thread A Thread B - f2fs_expand_inode_data - f2fs_allocate_pinning_section - f2fs_gc_range - do_garbage_collect w/ segno #x - writepage - f2fs_allocate_data_block - new_curseg - allocate segno #x The root cause is: fallocate on pinning file may race w/ block allocation as above, result in do_garbage_collect() from fallocate() may migrate segment which is just allocated by a log, the log will update segment type in its in-memory structure, however GC will get segment type from on-disk SSA block, once segment type changes by log, we can detect such inconsistency, then shutdown filesystem. In this case, on-disk SSA shows type of segno #173822 is 1 (SUM_TYPE_NODE), however segno #173822 was just allocated as data type segment, so in-memory SIT shows type of segno #173822 is 0 (SUM_TYPE_DATA). Change as below to fix this issue: - check whether current section is empty before gc - add sanity checks on do_garbage_collect() to avoid any race case, result in migrating segment used by log. - btw, it fixes misc issue in printed logs: "SSA and SIT" -> "SIT and SSA". Fixes: 9703d69d9d15 ("f2fs: support file pinning for zoned devices") Cc: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 3b0c8908faa18cded84d64822882a830ab1f4d26 Author: Chao Yu Date: Wed Sep 10 16:40:24 2025 +0800 f2fs: fix to truncate first page in error path of f2fs_truncate() [ Upstream commit 9251a9e6e871cb03c4714a18efa8f5d4a8818450 ] syzbot reports a bug as below: loop0: detected capacity change from 0 to 40427 F2FS-fs (loop0): Wrong SSA boundary, start(3584) end(4096) blocks(3072) F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock F2FS-fs (loop0): invalid crc value F2FS-fs (loop0): f2fs_convert_inline_folio: corrupted inline inode ino=3, i_addr[0]:0x1601, run fsck to fix. ------------[ cut here ]------------ kernel BUG at fs/inode.c:753! RIP: 0010:clear_inode+0x169/0x190 fs/inode.c:753 Call Trace: evict+0x504/0x9c0 fs/inode.c:810 f2fs_fill_super+0x5612/0x6fa0 fs/f2fs/super.c:5047 get_tree_bdev_flags+0x40e/0x4d0 fs/super.c:1692 vfs_get_tree+0x8f/0x2b0 fs/super.c:1815 do_new_mount+0x2a2/0x9e0 fs/namespace.c:3808 do_mount fs/namespace.c:4136 [inline] __do_sys_mount fs/namespace.c:4347 [inline] __se_sys_mount+0x317/0x410 fs/namespace.c:4324 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f During f2fs_evict_inode(), clear_inode() detects that we missed to truncate all page cache before destorying inode, that is because in below path, we will create page #0 in cache, but missed to drop it in error path, let's fix it. - evict - f2fs_evict_inode - f2fs_truncate - f2fs_convert_inline_inode - f2fs_grab_cache_folio : create page #0 in cache - f2fs_convert_inline_folio : sanity check failed, return -EFSCORRUPTED - clear_inode detects that inode->i_data.nrpages is not zero Fixes: 92dffd01790a ("f2fs: convert inline_data when i_size becomes large") Reported-by: syzbot+90266696fe5daacebd35@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/68c09802.050a0220.3c6139.000e.GAE@google.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit a198668c3bbfc4371f86773ddc88937b627e04d6 Author: Chao Yu Date: Fri Sep 12 16:12:50 2025 +0800 f2fs: fix to update map->m_next_extent correctly in f2fs_map_blocks() [ Upstream commit 869833f54e8306326b85ca3ed08979b7ad412a4a ] Script to reproduce: mkfs.f2fs -O extra_attr,compression /dev/vdb -f mount /dev/vdb /mnt/f2fs -o mode=lfs,noextent_cache cd /mnt/f2fs f2fs_io write 1 0 1024 rand dsync testfile xfs_io testfile -c "fsync" f2fs_io write 1 0 512 rand dsync testfile xfs_io testfile -c "fsync" cd / umount /mnt/f2fs mount /dev/vdb /mnt/f2fs f2fs_io precache_extents /mnt/f2fs/testfile umount /mnt/f2fs Tracepoint output: f2fs_update_read_extent_tree_range: dev = (253,16), ino = 4, pgofs = 0, len = 512, blkaddr = 1055744, c_len = 0 f2fs_update_read_extent_tree_range: dev = (253,16), ino = 4, pgofs = 513, len = 351, blkaddr = 17921, c_len = 0 f2fs_update_read_extent_tree_range: dev = (253,16), ino = 4, pgofs = 864, len = 160, blkaddr = 18272, c_len = 0 During precache_extents, there is off-by-one issue, we should update map->m_next_extent to pgofs rather than pgofs + 1, if last blkaddr is valid and not contiguous to previous extent. Fixes: c4020b2da4c9 ("f2fs: support F2FS_IOC_PRECACHE_EXTENTS") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 419f8b904a4d1a3bfc650176d1c8ce358299662a Author: Timur Kristóf Date: Tue Sep 9 16:49:35 2025 +0200 drm/amdgpu: Fix allocating extra dwords for rings (v2) [ Upstream commit ae5c2bee1680436d9bf8bfaca7416496adff0ee0 ] Rename extra_dw to extra_bytes and document what it's for. The value is already used as if it were bytes in vcn_v4_0.c and in amdgpu_ring_init. Just adjust the dword count in jpeg_v1_0.c so that it becomes a byte count. v2: Rename extra_dw to extra_bytes as discussed during review. Fixes: c8c1a1d2ef04 ("drm/amdgpu: define and add extra dword for jpeg ring") Signed-off-by: Timur Kristóf Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d9ae3a91c4c14bdd5c199a3d4b2833d68fc08332 Author: Zqiang Date: Thu Sep 11 20:51:55 2025 +0800 srcu/tiny: Remove preempt_disable/enable() in srcu_gp_start_if_needed() [ Upstream commit e6a43aeb71852a39432332dcc3a6d11bb464b075 ] Currently, the srcu_gp_start_if_needed() is always be invoked in preempt disable's critical section, this commit therefore remove redundant preempt_disable/enable() in srcu_gp_start_if_needed() and adds a call to lockdep_assert_preemption_disabled() in order to enable lockdep to diagnose mistaken invocations of this function from preempts-enabled code. Fixes: 65b4a59557f6 ("srcu: Make Tiny SRCU explicitly disable preemption") Signed-off-by: Zqiang Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 2f3f888d0de377a840f1eed2b8f5513a4ef10981 Author: Bard Liao Date: Mon Sep 15 10:48:53 2025 +0800 ASoC: Intel: hda-sdw-bpt: set persistent_buffer false [ Upstream commit 8b184c34806e5da4d4847fabd3faeff38b47e70a ] The persistent_buffer agreement is false when hda_cl_prepare() is called. We should use the same value when hda_cl_cleanup() is called. Fixes: 5d5cb86fb46ea ("ASoC: SOF: Intel: hda-sdw-bpt: add helpers for SoundWire BPT DMA") Signed-off-by: Bard Liao Reviewed-by: Péter Ujfalusi Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20250915024853.1153518-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 22602c7976e69d1f6a79e68f4663f9feefeaff79 Author: Felix Fietkau Date: Mon Sep 15 09:58:56 2025 +0200 wifi: mt76: mt7996: remove redundant per-phy mac80211 calls during restart [ Upstream commit 0a5df0ec47f7edc04957925a9644101682041d27 ] There is only one wiphy, so extra calls must be removed. For calls that need to remain per-wiphy, use mt7996_for_each_phy Fixes: 69d54ce7491d ("wifi: mt76: mt7996: switch to single multi-radio wiphy") Link: https://patch.msgid.link/20250915075910.47558-1-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 4bd0594d53fd116f97bf6fb9c15e45476eba25e0 Author: Zhi-Jun You Date: Tue Sep 9 14:48:24 2025 +0800 wifi: mt76: mt7915: fix mt7981 pre-calibration [ Upstream commit 2b660ee10a0c25b209d7fda3c41b821b75dd85d9 ] In vendor driver, size of group cal and dpd cal for mt7981 includes 6G although the chip doesn't support it. mt76 doesn't take this into account which results in reading from the incorrect offset. For devices with precal, this would lead to lower bitrate. Fix this by aligning groupcal size with vendor driver and switch to freq_list_v2 in mt7915_dpd_freq_idx in order to get the correct offset. Below are iwinfo of the test device with two clients connected (iPhone 16, Intel AX210). Before : Mode: Master Channel: 36 (5.180 GHz) HT Mode: HE80 Center Channel 1: 42 2: unknown Tx-Power: 23 dBm Link Quality: 43/70 Signal: -67 dBm Noise: -92 dBm Bit Rate: 612.4 MBit/s Encryption: WPA3 SAE (CCMP) Type: nl80211 HW Mode(s): 802.11ac/ax/n Hardware: embedded [MediaTek MT7981] After: Mode: Master Channel: 36 (5.180 GHz) HT Mode: HE80 Center Channel 1: 42 2: unknown Tx-Power: 23 dBm Link Quality: 43/70 Signal: -67 dBm Noise: -92 dBm Bit Rate: 900.6 MBit/s Encryption: WPA3 SAE (CCMP) Type: nl80211 HW Mode(s): 802.11ac/ax/n Hardware: embedded [MediaTek MT7981] Tested-on: mt7981 20240823 Fixes: 19a954edec63 ("wifi: mt76: mt7915: add mt7986, mt7916 and mt7981 pre-calibration") Signed-off-by: Zhi-Jun You Link: https://patch.msgid.link/20250909064824.16847-1-hujy652@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 417b0f520eceb4fffb69bbaffe60829b1370ce10 Author: Lorenzo Bianconi Date: Tue Sep 9 11:45:19 2025 +0200 wifi: mt76: mt7996: Convert mt7996_wed_rro_addr to LE [ Upstream commit 809054a60d613ccca6e7f243bc68966b58044163 ] Do not use bitmask in mt7996_wed_rro_addr DMA descriptor in order to not break endianness Fixes: 950d0abb5cd94 ("wifi: mt76: mt7996: add wed rx support") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20250909-mt7996-rro-rework-v5-11-7d66f6eb7795@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit fabb57c09ce945b6150cc64507d03da696b4248d Author: Lorenzo Bianconi Date: Tue Sep 9 11:45:17 2025 +0200 wifi: mt76: mt7996: Fix RX packets configuration for primary WED device [ Upstream commit cffed52dbf0ddd0db11f9df63f9976fe58ac9628 ] In order to properly set the number of rx packets for primary WED device if hif device is available, move hif pointer initialization before running mt7996_mmio_wed_init routine. Fixes: 83eafc9251d6d ("wifi: mt76: mt7996: add wed tx support") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20250909-mt7996-rro-rework-v5-9-7d66f6eb7795@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit caa9c9669e0c21ffafadde2623afe3d2c67d98d5 Author: Lorenzo Bianconi Date: Tue Sep 9 11:45:16 2025 +0200 wifi: mt76: mt7996: Fix tx-queues initialization for second phy on mt7996 [ Upstream commit 77ff8caf3b17626ad91568cef63d75e288aa4052 ] Fix the second phy tx queue initialization if hif device is not available for MT7990 chipset. Fixes: 83eafc9251d6d ("wifi: mt76: mt7996: add wed tx support") Co-developed-by: Sujuan Chen Signed-off-by: Sujuan Chen Co-developed-by: Benjamin Lin Signed-off-by: Benjamin Lin Co-developed-by: Rex Lu Signed-off-by: Rex Lu Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20250909-mt7996-rro-rework-v5-8-7d66f6eb7795@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 2e671536c1c3c7bcad95d408a4ab42e2e54d1882 Author: Lorenzo Bianconi Date: Sat Aug 30 00:26:47 2025 +0200 wifi: mt76: mt7996: Check phy before init msta_link in mt7996_mac_sta_add_links() [ Upstream commit fe5fffadc6c77c56f122cf1042dc830f59e904bf ] In order to avoid a possible NULL pointer dereference in mt7996_mac_sta_init_link routine, move the phy pointer check before running mt7996_mac_sta_init_link() in mt7996_mac_sta_add_links routine. Fixes: dd82a9e02c054 ("wifi: mt76: mt7996: Rely on mt7996_sta_link in sta_add/sta_remove callbacks") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20250830-mt7996_mac_sta_add_links-fix-v1-1-4219fb8755ee@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 32b83a47bddcee5c9e4bd084a13a55fc0ccb288a Author: Lorenzo Bianconi Date: Mon Sep 1 00:14:37 2025 +0200 wifi: mt76: mt7996: Use proper link_id in link_sta_rc_update callback [ Upstream commit afff4325548f0cf872e404df2856bf8bd9581c7e ] Do not always use deflink_id in link_sta_rc_update mac80211 callback but use the proper link_id provided by mac80211. Fixes: 0762bdd30279f ("wifi: mt76: mt7996: rework mt7996_mac_sta_rc_work to support MLO") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20250901-mt7996-fix-link_sta_rc_update-callback-v1-1-e24caf196222@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7c5b985bb1137ddd8f68ea7267d1269a0af11df9 Author: Abdun Nihaal Date: Wed Jul 9 20:25:30 2025 +0530 wifi: mt76: fix potential memory leak in mt76_wmac_probe() [ Upstream commit 42754b7de2b1a2cf116c5e3f1e8e78392f4ed700 ] In mt76_wmac_probe(), when the mt76_alloc_device() call succeeds, memory is allocated for both struct ieee80211_hw and a workqueue. However, on the error path, the workqueue is not freed. Fix that by calling mt76_free_device() on the error path. Fixes: c8846e101502 ("mt76: add driver for MT7603E and MT7628/7688") Signed-off-by: Abdun Nihaal Reviewed-by: Jiri Slaby Link: https://patch.msgid.link/20250709145532.41246-1-abdun.nihaal@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 4ad4f18595630d857fc76dd2f50a56101c77555b Author: Lorenzo Bianconi Date: Thu Jul 10 10:26:19 2025 +0200 wifi: mt76: mt7996: Fix mt7996_mcu_bss_mld_tlv routine [ Upstream commit ed01c310eca96453c11b59db46c855aa593cffdd ] Update mt7996_mcu_bss_mld_tlv routine to properly support MLO configuring the BSS. Fixes: 98686cd21624c ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20250710-mt7996-mlo-fixes-v3-v1-1-e7595b089f2c@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 83c65485fb7d0b15e81f2b436bc568f6eb163095 Author: Lorenzo Bianconi Date: Tue Jul 8 09:12:05 2025 +0200 wifi: mt76: mt7996: Fix mt7996_mcu_sta_ba wcid configuration [ Upstream commit fe219a41adaf5354c59e75ebb642b8cb8a851d38 ] Fix the wcid pointer used in mt7996_mcu_sta_ba routine to properly support MLO scenario. Fixes: 98686cd21624c ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20250708-mt7996-mlo-fixes-v2-v1-2-f2682818a8a3@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit beb0f1c5b2fa6025e57a6e33303c95142a7968ff Author: Håkon Bugge Date: Fri Sep 12 12:05:20 2025 +0200 RDMA/cm: Rate limit destroy CM ID timeout error message [ Upstream commit 2bbe1255fcf19c5eb300efb6cb5ad98d66fdae2e ] When the destroy CM ID timeout kicks in, you typically get a storm of them which creates a log flooding. Hence, change pr_err() to pr_err_ratelimited() in cm_destroy_id_wait_timeout(). Fixes: 96d9cbe2f2ff ("RDMA/cm: add timeout to cm_destroy_id wait") Signed-off-by: Håkon Bugge Link: https://patch.msgid.link/20250912100525.531102-1-haakon.bugge@oracle.com Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 4c70f94dbb6353aa69a1ab1e6aefc32bac781b07 Author: Donet Tom Date: Fri Aug 22 14:18:45 2025 +0530 drivers/base/node: handle error properly in register_one_node() [ Upstream commit 786eb990cfb78aab94eb74fb32a030e14723a620 ] If register_node() returns an error, it is not handled correctly. The function will proceed further and try to register CPUs under the node, which is not correct. So, in this patch, if register_node() returns an error, we return immediately from the function. Link: https://lkml.kernel.org/r/20250822084845.19219-1-donettom@linux.ibm.com Fixes: 76b67ed9dce6 ("[PATCH] node hotplug: register cpu: remove node struct") Signed-off-by: Donet Tom Acked-by: David Hildenbrand Cc: Alison Schofield Cc: Danilo Krummrich Cc: Dave Jiang Cc: Donet Tom Cc: Greg Kroah-Hartman Cc: Hiroyouki Kamezawa Cc: Joanthan Cameron Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Yury Norov (NVIDIA) Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit b3172ec3ab2d2755b188bbf8ef2050f5d5efa27b Author: Niklas Cassel Date: Mon Sep 8 18:19:42 2025 +0200 PCI: endpoint: pci-epf-test: Fix doorbell test support [ Upstream commit f272210b28d050df56ec7dfaecb9fa3bebca6419 ] The doorbell feature temporarily overrides the inbound translation to point to the address stored in epf_test->db_bar.phys_addr, i.e., it calls set_bar() twice without ever calling clear_bar(), as calling clear_bar() would clear the BAR's PCI address assigned by the host. Thus, when disabling the doorbell, restore the inbound translation to point to the memory allocated for the BAR. Without this, running the PCI endpoint kselftest doorbell test case more than once would fail. Fixes: eff0c286aa91 ("PCI: endpoint: pci-epf-test: Add doorbell test support") Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20250908161942.534799-2-cassel@kernel.org Signed-off-by: Sasha Levin commit ad09d55b52a6d92437f2984f1d8aff6c1e94c5f2 Author: Christophe Leroy Date: Tue Aug 12 14:51:26 2025 +0200 watchdog: mpc8xxx_wdt: Reload the watchdog timer when enabling the watchdog [ Upstream commit 7dfd80f70ef00d871df5af7c391133f7ba61ad9b ] When the watchdog gets enabled with this driver, it leaves enough time for the core watchdog subsystem to start pinging it. But when the watchdog is already started by hardware or by the boot loader, little time remains before it fires and it happens that the core watchdog subsystem doesn't have time to start pinging it. Until commit 19ce9490aa84 ("watchdog: mpc8xxx: use the core worker function") pinging was managed by the driver itself and the watchdog was immediately pinged by setting the timer expiry to 0. So restore similar behaviour by pinging it when enabling it so that if it was already enabled the watchdog timer counter is reloaded. Fixes: 19ce9490aa84 ("watchdog: mpc8xxx: use the core worker function") Signed-off-by: Christophe Leroy Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 88fbc3bfd0cc07a4d5fd0c37ab3d7f856e4bfc0b Author: Guenter Roeck Date: Sun Aug 17 07:48:17 2025 -0700 watchdog: intel_oc_wdt: Do not try to write into const memory [ Upstream commit bdbb4a2d2aeae3d115bbdc402adac72aec071492 ] The code tries to update the intel_oc_wdt_info data structure if the watchdog is locked. That data structure is marked as const and can not be written into. Copy it into struct intel_oc_wdt and modify it there to fix the problem. Reported-by: Petar Kulić Cc: Diogo Ivo Fixes: 535d1784d8a9 ("watchdog: Add driver for Intel OC WDT") Signed-off-by: Guenter Roeck Reviewed-by: Diogo Ivo Tested-by: Diogo Ivo Link: https://lore.kernel.org/linux-watchdog/20250818031838.3359-1-diogo.ivo@tecnico.ulisboa.pt/T/#t Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 69a5d59e97fb8de41c245c8d5448b39b76e3d002 Author: Jiri Kosina Date: Fri Sep 12 16:27:35 2025 +0200 HID: steelseries: Fix STEELSERIES_SRWS1 handling in steelseries_remove() [ Upstream commit 2910913ef87dd9b9ce39e844c7295e1896b3b039 ] srws1_remove label can be only reached only if LEDS subsystem is enabled. To avoid putting horryfing ifdef second time around the label, just perform the cleanup and exit immediately directly. Fixes: a84eeacbf9325 ("HID: steelseries: refactor probe() and remove()") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202509090334.76D4qGtW-lkp@intel.com/ Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit ffaf14cd802bdb022e4037fb012a458f83a62268 Author: Zhang Tengfei Date: Mon Sep 1 21:46:54 2025 +0800 ipvs: Use READ_ONCE/WRITE_ONCE for ipvs->enable [ Upstream commit 944b6b216c0387ac3050cd8b773819ae360bfb1c ] KCSAN reported a data-race on the `ipvs->enable` flag, which is written in the control path and read concurrently from many other contexts. Following a suggestion by Julian, this patch fixes the race by converting all accesses to use `WRITE_ONCE()/READ_ONCE()`. This lightweight approach ensures atomic access and acts as a compiler barrier, preventing unsafe optimizations where the flag is checked in loops (e.g., in ip_vs_est.c). Additionally, the `enable` checks in the fast-path hooks (`ip_vs_in_hook`, `ip_vs_out_hook`, `ip_vs_forward_icmp`) are removed. These are unnecessary since commit 857ca89711de ("ipvs: register hooks only with services"). The `enable=0` condition they check for can only occur in two rare and non-fatal scenarios: 1) after hooks are registered but before the flag is set, and 2) after hooks are unregistered on cleanup_net. In the worst case, a single packet might be mishandled (e.g., dropped), which does not lead to a system crash or data corruption. Adding a check in the performance-critical fast-path to handle this harmless condition is not a worthwhile trade-off. Fixes: 857ca89711de ("ipvs: register hooks only with services") Reported-by: syzbot+1651b5234028c294c339@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1651b5234028c294c339 Suggested-by: Julian Anastasov Link: https://lore.kernel.org/lvs-devel/2189fc62-e51e-78c9-d1de-d35b8e3657e3@ssi.bg/ Signed-off-by: Zhang Tengfei Acked-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit aecd80fae8dbe50c4de8364d9d63423e7c484d94 Author: Zhen Ni Date: Fri Aug 29 16:36:21 2025 +0800 netfilter: ipset: Remove unused htable_bits in macro ahash_region [ Upstream commit ba941796d7cd1e81f51eed145dad1b47240ff420 ] Since the ahash_region() macro was redefined to calculate the region index solely from HTABLE_REGION_BITS, the htable_bits parameter became unused. Remove the unused htable_bits argument and its call sites, simplifying the code without changing semantics. Fixes: 8478a729c046 ("netfilter: ipset: fix region locking in hash types") Signed-off-by: Zhen Ni Reviewed-by: Phil Sutter Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 5beca7388bb9a738fb7e21a020bd7424ff1b3e81 Author: Edward Srouji Date: Sun Aug 24 17:48:39 2025 +0300 RDMA/mlx5: Fix page size bitmap calculation for KSM mode [ Upstream commit 372fdb5c75b61f038f4abf596abdcf01acbdb7af ] When using KSM (Key Scatter-gather Memory) access mode, the HW requires the IOVA to be aligned to the selected page size. Without this alignment, the HW may not function correctly. Currently, mlx5_umem_mkc_find_best_pgsz() does not filter out page sizes that would result in misaligned IOVAs for KSM mode. This can lead to selecting page sizes that are incompatible with the given IOVA. Fix this by filtering the page size bitmap when in KSM mode, keeping only page sizes to which the IOVA is aligned to. Fixes: fcfb03597b7d ("RDMA/mlx5: Align mkc page size capability check to PRM") Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20250824144839.154717-1-edwards@nvidia.com Reviewed-by: Michael Guralnik Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f6ca78b7536116dba14e87abcca2197b70548b6b Author: Matthieu Baerts (NGI0) Date: Tue Sep 9 23:07:47 2025 +0200 tools: ynl: fix undefined variable name [ Upstream commit 7a3aaaa9fce710938c3557e5708ba5b00dd38226 ] This variable used in the error path was not defined according to Ruff. msg_format.attr_set is used instead, presumably the one that was supposed to be used originally. This is linked to Ruff error F821 [1]: An undefined name is likely to raise NameError at runtime. Fixes: 1769e2be4baa ("tools/net/ynl: Add 'sub-message' attribute decoding to ynl") Link: https://docs.astral.sh/ruff/rules/undefined-name/ [1] Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Donald Hunter Reviewed-by: Asbjørn Sloth Tønnesen Link: https://patch.msgid.link/20250909-net-next-ynl-ruff-v1-1-238c2bccdd99@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cc93a995e446cccf46c3bdc30f539baa77c24c62 Author: Kuan-Wei Chiu Date: Tue Aug 26 14:23:14 2025 +0800 mm/slub: Fix cmp_loc_by_count() to return 0 when counts are equal [ Upstream commit e1c4350327b39c9cad27b6c5779b3754384f26c8 ] The comparison function cmp_loc_by_count() used for sorting stack trace locations in debugfs currently returns -1 if a->count > b->count and 1 otherwise. This breaks the antisymmetry property required by sort(), because when two counts are equal, both cmp(a, b) and cmp(b, a) return 1. This can lead to undefined or incorrect ordering results. Fix it by updating the comparison logic to explicitly handle the case when counts are equal, and use cmp_int() to ensure the comparison function adheres to the required mathematical properties of antisymmetry. Fixes: 553c0369b3e1 ("mm/slub: sort debugfs output by frequency of stack traces") Reviewed-by: Joshua Hahn Signed-off-by: Kuan-Wei Chiu Reviewed-by: Harry Yoo Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin commit c783bf7345e1c310aba6dc5b308e9f9c2a3c4a4c Author: Hans de Goede Date: Sun Aug 31 12:48:21 2025 +0200 iio: consumers: Fix offset handling in iio_convert_raw_to_processed() [ Upstream commit 33f5c69c4daff39c010b3ea6da8ebab285f4277b ] Fix iio_convert_raw_to_processed() offset handling for channels without a scale attribute. The offset has been applied to the raw64 value not to the original raw value. Use the raw64 value so that the offset is taken into account. Fixes: 14b457fdde38 ("iio: inkern: apply consumer scale when no channel scale is available") Cc: Liam Beguin Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20250831104825.15097-3-hansg@kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 80e31551819f1aa4aa6e294fa81eed3124ab6a93 Author: Hans de Goede Date: Sun Aug 31 12:48:20 2025 +0200 iio: consumers: Fix handling of negative channel scale in iio_convert_raw_to_processed() [ Upstream commit 0f85406bf830eb8747dd555ab53c9d97ee4af293 ] There is an issue with the handling of negative channel scales in iio_convert_raw_to_processed_unlocked() when the channel-scale is of the IIO_VAL_INT_PLUS_[MICRO|NANO] type: Things work for channel-scale values > -1.0 and < 0.0 because of the use of signed values in: *processed += div_s64(raw64 * (s64)scale_val2 * scale, 1000000LL); Things will break however for scale values < -1.0. Lets for example say that raw = 2, (caller-provided)scale = 10 and (channel)scale_val = -1.5. The result should then be 2 * 10 * -1.5 = -30. channel-scale = -1.5 means scale_val = -1 and scale_val2 = 500000, now lets see what gets stored in processed: 1. *processed = raw64 * scale_val * scale; 2. *processed += raw64 * scale_val2 * scale / 1000000LL; 1. Sets processed to 2 * -1 * 10 = -20 2. Adds 2 * 500000 * 10 / 1000000 = 10 to processed And the end result is processed = -20 + 10 = -10, which is not correct. Fix this by always using the abs value of both scale_val and scale_val2 and if either is negative multiply the end-result by -1. Note there seems to be an unwritten rule about negative IIO_VAL_INT_PLUS_[MICRO|NANO] values that: i. values > -1.0 and < 0.0 are written as val=0 val2=-xxx ii. values <= -1.0 are written as val=-xxx val2=xxx But iio_format_value() will also correctly display a third option: iii. values <= -1.0 written as val=-xxx val2=-xxx Since iio_format_value() uses abs(val) when val2 < 0. This fix also makes iio_convert_raw_to_processed() properly handle channel-scales using this third option. Fixes: 48e44ce0f881 ("iio:inkern: Add function to read the processed value") Cc: Matteo Martelli Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20250831104825.15097-2-hansg@kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 039ddf353cc33f6546a87ec1ac3210637d714bec Author: Moon Hee Lee Date: Tue Jul 22 10:40:16 2025 -0700 fs/ntfs3: reject index allocation if $BITMAP is empty but blocks exist [ Upstream commit 0dc7117da8f92dd5fe077d712a756eccbe377d40 ] Index allocation requires at least one bit in the $BITMAP attribute to track usage of index entries. If the bitmap is empty while index blocks are already present, this reflects on-disk corruption. syzbot triggered this condition using a malformed NTFS image. During a rename() operation involving a long filename (which spans multiple index entries), the empty bitmap allowed the name to be added without valid tracking. Subsequent deletion of the original entry failed with -ENOENT, due to unexpected index state. Reject such cases by verifying that the bitmap is not empty when index blocks exist. Reported-by: syzbot+b0373017f711c06ada64@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b0373017f711c06ada64 Fixes: d99208b91933 ("fs/ntfs3: cancle set bad inode after removing name fails") Tested-by: syzbot+b0373017f711c06ada64@syzkaller.appspotmail.com Signed-off-by: Moon Hee Lee Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 5aa5799d162ad1b8e8b699d48b6218143c695a78 Author: Vitaly Grigoryev Date: Mon Aug 25 13:08:55 2025 +0300 fs: ntfs3: Fix integer overflow in run_unpack() [ Upstream commit 736fc7bf5f68f6b74a0925b7e072c571838657d2 ] The MFT record relative to the file being opened contains its runlist, an array containing information about the file's location on the physical disk. Analysis of all Call Stack paths showed that the values of the runlist array, from which LCNs are calculated, are not validated before run_unpack function. The run_unpack function decodes the compressed runlist data format from MFT attributes (for example, $DATA), converting them into a runs_tree structure, which describes the mapping of virtual clusters (VCN) to logical clusters (LCN). The NTFS3 subsystem also has a shortcut for deleting files from MFT records - in this case, the RUN_DEALLOCATE command is sent to the run_unpack input, and the function logic provides that all data transferred to the runlist about file or directory is deleted without creating a runs_tree structure. Substituting the runlist in the $DATA attribute of the MFT record for an arbitrary file can lead either to access to arbitrary data on the disk bypassing access checks to them (since the inode access check occurs above) or to destruction of arbitrary data on the disk. Add overflow check for addition operation. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Signed-off-by: Vitaly Grigoryev Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 394047c49db63440ca8e9db9b01436dcbf785803 Author: Sarika Sharma Date: Thu Sep 4 16:10:54 2025 +0530 wifi: mac80211: fix reporting of all valid links in sta_set_sinfo() [ Upstream commit eebccbfea4184feb758c104783b870ec4ddb6aec ] Currently, sta_set_sinfo() fails to populate link-level station info when sinfo->valid_links is initially 0 and sta->sta.valid_links has bits set for links other than link 0. This typically occurs when association happens on a non-zero link or link 0 deleted dynamically. In such cases, the for_each_valid_link(sinfo, link_id) loop only executes for link 0 and terminates early, since sinfo->valid_links remains 0. As a result, only MLD-level information is reported to userspace. Hence to fix, initialize sinfo->valid_links with sta->sta.valid_links before entering the loop to ensure loop executes for each valid link. During iteration, mask out invalid links from sinfo->valid_links if any of sta->link[link_id], sdata->link[link_id], or sinfo->links[link_id] are not present, to report only valid link information. Fixes: 505991fba9ec ("wifi: mac80211: extend support to fill link level sinfo structure") Signed-off-by: Sarika Sharma Link: https://patch.msgid.link/20250904104054.790321-1-quic_sarishar@quicinc.com [clarify comment] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit aa48597cb2bc4d63833dfcc67ee8ee959686f1be Author: Qianfeng Rong Date: Tue Aug 26 17:20:45 2025 +0800 drm/msm/dpu: fix incorrect type for ret [ Upstream commit 88ec0e01a880e3326794e149efae39e3aa4dbbec ] Change 'ret' from unsigned long to int, as storing negative error codes in an unsigned long makes it never equal to -ETIMEDOUT, causing logical errors. Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback") Signed-off-by: Qianfeng Rong Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/671100/ Link: https://lore.kernel.org/r/20250826092047.224341-1-rongqianfeng@vivo.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 87aff6d08f3b13bfad66df7c13af5f3a3548d5b9 Author: Akhil P Oommen Date: Tue Sep 2 17:20:00 2025 +0530 drm/msm: Fix bootup splat with separate_gpu_drm modparam [ Upstream commit f028bcafb6dfb4c2bb656cbff9e6a66222d3d3d7 ] The drm_gem_for_each_gpuvm_bo() call from lookup_vma() accesses drm_gem_obj.gpuva.list, which is not initialized when the drm driver does not support DRIVER_GEM_GPUVA feature. Enable it for msm_kms drm driver to fix the splat seen when msm.separate_gpu_drm=1 modparam is set: [ 9.506020] Unable to handle kernel paging request at virtual address fffffffffffffff0 [ 9.523160] Mem abort info: [ 9.523161] ESR = 0x0000000096000006 [ 9.523163] EC = 0x25: DABT (current EL), IL = 32 bits [ 9.523165] SET = 0, FnV = 0 [ 9.523166] EA = 0, S1PTW = 0 [ 9.523167] FSC = 0x06: level 2 translation fault [ 9.523169] Data abort info: [ 9.523170] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 9.523171] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 9.523172] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 9.523174] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000ad370f000 [ 9.523176] [fffffffffffffff0] pgd=0000000000000000, p4d=0000000ad4787403, pud=0000000ad4788403, pmd=0000000000000000 [ 9.523184] Internal error: Oops: 0000000096000006 [#1] SMP [ 9.592968] CPU: 9 UID: 0 PID: 448 Comm: (udev-worker) Not tainted 6.17.0-rc4-assorted-fix-00005-g0e9bb53a2282-dirty #3 PREEMPT [ 9.592970] Hardware name: Qualcomm CRD, BIOS 6.0.240718.BOOT.MXF.2.4-00515-HAMOA-1 07/18/2024 [ 9.592971] pstate: a1400005 (NzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 9.592973] pc : lookup_vma+0x28/0xe0 [msm] [ 9.592996] lr : get_vma_locked+0x2c/0x128 [msm] [ 9.763632] sp : ffff800082dab460 [ 9.763666] Call trace: [ 9.763668] lookup_vma+0x28/0xe0 [msm] (P) [ 9.763688] get_vma_locked+0x2c/0x128 [msm] [ 9.763706] msm_gem_get_and_pin_iova_range+0x68/0x11c [msm] [ 9.763723] msm_gem_get_and_pin_iova+0x18/0x24 [msm] [ 9.763740] msm_fbdev_driver_fbdev_probe+0xd0/0x258 [msm] [ 9.763760] __drm_fb_helper_initial_config_and_unlock+0x288/0x528 [drm_kms_helper] [ 9.763771] drm_fb_helper_initial_config+0x44/0x54 [drm_kms_helper] [ 9.763779] drm_fbdev_client_hotplug+0x84/0xd4 [drm_client_lib] [ 9.763782] drm_client_register+0x58/0x9c [drm] [ 9.763806] drm_fbdev_client_setup+0xe8/0xcf0 [drm_client_lib] [ 9.763809] drm_client_setup+0xb4/0xd8 [drm_client_lib] [ 9.763811] msm_drm_kms_post_init+0x2c/0x3c [msm] [ 9.763830] msm_drm_init+0x1a8/0x22c [msm] [ 9.763848] msm_drm_bind+0x30/0x3c [msm] [ 9.919273] try_to_bring_up_aggregate_device+0x168/0x1d4 [ 9.919283] __component_add+0xa4/0x170 [ 9.919286] component_add+0x14/0x20 [ 9.919288] msm_dp_display_probe_tail+0x4c/0xac [msm] [ 9.919315] msm_dp_auxbus_done_probe+0x14/0x20 [msm] [ 9.919335] dp_aux_ep_probe+0x4c/0xf0 [drm_dp_aux_bus] [ 9.919341] really_probe+0xbc/0x298 [ 9.919345] __driver_probe_device+0x78/0x12c [ 9.919348] driver_probe_device+0x40/0x160 [ 9.919350] __driver_attach+0x94/0x19c [ 9.919353] bus_for_each_dev+0x74/0xd4 [ 9.919355] driver_attach+0x24/0x30 [ 9.919358] bus_add_driver+0xe4/0x208 [ 9.919360] driver_register+0x60/0x128 [ 9.919363] __dp_aux_dp_driver_register+0x24/0x30 [drm_dp_aux_bus] [ 9.919365] atana33xc20_init+0x20/0x1000 [panel_samsung_atna33xc20] [ 9.919370] do_one_initcall+0x6c/0x1b0 [ 9.919374] do_init_module+0x58/0x234 [ 9.919377] load_module+0x19cc/0x1bd4 [ 9.919380] init_module_from_file+0x84/0xc4 [ 9.919382] __arm64_sys_finit_module+0x1b8/0x2cc [ 9.919384] invoke_syscall+0x48/0x110 [ 9.919389] el0_svc_common.constprop.0+0xc8/0xe8 [ 9.919393] do_el0_svc+0x20/0x2c [ 9.919396] el0_svc+0x34/0xf0 [ 9.919401] el0t_64_sync_handler+0xa0/0xe4 [ 9.919403] el0t_64_sync+0x198/0x19c [ 9.919407] Code: eb0000bf 54000480 d100a003 aa0303e2 (f8418c44) [ 9.919410] ---[ end trace 0000000000000000 ]--- Fixes: 217ed15bd399 ("drm/msm: enable separate binding of GPU and display devices") Signed-off-by: Akhil P Oommen Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/672257/ Link: https://lore.kernel.org/r/20250902-assorted-sept-1-v1-1-f3ec9baed513@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 4e9ce29286f2a88346a44fcecaf0531e9c41a5c4 Author: Eric Dumazet Date: Fri Sep 5 16:58:07 2025 +0000 ipv6: snmp: do not track per idev ICMP6_MIB_RATELIMITHOST [ Upstream commit 2fab94bcf313480336b0a41eb45a24ffd5087490 ] Blamed commit added a critical false sharing on a single atomic_long_t under DOS, like receiving UDP packets to closed ports. Per netns ICMP6_MIB_RATELIMITHOST tracking uses per-cpu storage and is enough, we do not need per-device and slow tracking. Fixes: d0941130c9351 ("icmp: Add counters for rate limits") Signed-off-by: Eric Dumazet Cc: Jamie Bainbridge Cc: Abhishek Rawal Link: https://patch.msgid.link/20250905165813.1470708-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b6295474c07b8d9b4da7edda5eb3f07e9b7892eb Author: Eric Dumazet Date: Fri Sep 5 16:58:06 2025 +0000 ipv6: snmp: do not use SNMP_MIB_SENTINEL anymore [ Upstream commit ceac1fb2290d230eb83aff3761058c559440de13 ] Use ARRAY_SIZE(), so that we know the limit at compile time. Following patch needs this preliminary change. Signed-off-by: Eric Dumazet Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20250905165813.1470708-3-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 2fab94bcf313 ("ipv6: snmp: do not track per idev ICMP6_MIB_RATELIMITHOST") Signed-off-by: Sasha Levin commit c60f269c123210a6846d6d1367de0eaa402c10b0 Author: Takashi Iwai Date: Tue Sep 2 19:18:21 2025 +0200 ASoC: Intel: bytcr_rt5651: Fix invalid quirk input mapping [ Upstream commit 4336efb59ef364e691ef829a73d9dbd4d5ed7c7b ] When an invalid value is passed via quirk option, currently bytcr_rt5640 driver just ignores and leaves as is, which may lead to unepxected results like OOB access. This patch adds the sanity check and corrects the input mapping to the certain default value if an invalid value is passed. Fixes: 64484ccee7af ("ASoC: Intel: bytcr_rt5651: Set card long_name based on quirks") Signed-off-by: Takashi Iwai Message-ID: <20250902171826.27329-4-tiwai@suse.de> Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 48880f3cdf2b6d8dcd91219c5b5c8a7526411322 Author: Takashi Iwai Date: Tue Sep 2 19:18:20 2025 +0200 ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mapping [ Upstream commit fba404e4b4af4f4f747bb0e41e9fff7d03c7bcc0 ] When an invalid value is passed via quirk option, currently bytcr_rt5640 driver only shows an error message but leaves as is. This may lead to unepxected results like OOB access. This patch corrects the input mapping to the certain default value if an invalid value is passed. Fixes: 063422ca2a9d ("ASoC: Intel: bytcr_rt5640: Set card long_name based on quirks") Signed-off-by: Takashi Iwai Message-ID: <20250902171826.27329-3-tiwai@suse.de> Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cfefa574cb7f0782e35c444b4b3c69367f70e586 Author: Takashi Iwai Date: Tue Sep 2 19:18:19 2025 +0200 ASoC: Intel: bytcht_es8316: Fix invalid quirk input mapping [ Upstream commit b20eb0e8de383116f1e1470d74da2a3c83c4e345 ] When an invalid value is passed via quirk option, currently bytcht_es8316 driver just ignores and leaves as is, which may lead to unepxected results like OOB access. This patch adds the sanity check and corrects the input mapping to the certain default value if an invalid value is passed. Fixes: 249d2fc9e55c ("ASoC: Intel: bytcht_es8316: Set card long_name based on quirks") Signed-off-by: Takashi Iwai Message-ID: <20250902171826.27329-2-tiwai@suse.de> Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f981d155e0d1f139f7bd35f16dff190b1192266d Author: Alexander Lobakin Date: Tue Aug 26 17:54:56 2025 +0200 idpf: fix Rx descriptor ready check barrier in splitq [ Upstream commit c20edbacc0295fd36f5f634b3421647ce3e08fd7 ] No idea what the current barrier position was meant for. At that point, nothing is read from the descriptor, only the pointer to the actual one is fetched. The correct barrier usage here is after the generation check, so that only the first qword is read if the descriptor is not yet ready and we need to stop polling. Debatable on coherent DMA as the Rx descriptor size is <= cacheline size, but anyway, the current barrier position only makes the codegen worse. Fixes: 3a8845af66ed ("idpf: add RX splitq napi poll support") Reviewed-by: Maciej Fijalkowski Signed-off-by: Alexander Lobakin Tested-by: Ramu R Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 85830b65244fb4afd534051ebde87fbe250f1a3d Author: Dmitry Baryshkov Date: Wed Sep 3 13:51:50 2025 +0300 drm/msm: stop supporting no-IOMMU configuration [ Upstream commit c94fc6d35685587aa0cb9a8d7d7062c73ab04d89 ] With the switch to GPUVM the msm driver no longer supports the no-IOMMU configurations (even without the actual GPU). Return an error in case we face the lack of the IOMMU. Fixes: 111fdd2198e6 ("drm/msm: drm_gpuvm conversion") Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/672559/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 71e34a5b5f0669bee13eb453ef4019aa1f18a15e Author: Dmitry Baryshkov Date: Wed Sep 3 13:51:49 2025 +0300 drm/msm/mdp4: stop supporting no-IOMMU configuration [ Upstream commit cc64568b522b64fb8f8c607da9eb4e2d9f72d0cf ] With the switch to GPUVM the msm driver no longer supports the no-IOMMU configurations (even without the actual GPU). Return an error in case we face the lack of the IOMMU for an MDP4 device. Fixes: 111fdd2198e6 ("drm/msm: drm_gpuvm conversion") Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/672557/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 0f34fb9e058c4348f8d256e4336e88b7e2a24640 Author: Liao Yuanhong Date: Tue Aug 19 20:11:51 2025 +0800 wifi: iwlwifi: Remove redundant header files [ Upstream commit b4b34ba66443696cc5f3e95493f9d7597259b728 ] The header file "fw/img.h" is already included on line 9. Remove the redundant include. Fixes: 2594e4d9e1a2d ("wifi: iwlwifi: prepare for reading SAR tables from UEFI") Signed-off-by: Liao Yuanhong Link: https://patch.msgid.link/20250819121201.608770-2-liaoyuanhong@vivo.com Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 1c444932dd1e68d407314faca92b3dddee17fbf6 Author: Rob Clark Date: Wed Aug 20 17:04:26 2025 -0700 drm/msm: Fix missing VM_BIND offset/range validation [ Upstream commit 3a3bef68a6c15d079646a964ebc4dc8bb0aedb06 ] We need to reject the MAP op if offset+range is larger than the BO size. Reported-by: Connor Abbott Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") Signed-off-by: Rob Clark Tested-by: Connor Abbott Patchwork: https://patchwork.freedesktop.org/patch/669781/ Signed-off-by: Sasha Levin commit 2b512909a291a964cfcf6b58de13256ab3e848c4 Author: Rob Clark Date: Wed Aug 20 17:04:25 2025 -0700 drm/msm: Fix obj leak in VM_BIND error path [ Upstream commit 278f8904434aa96055e793936b5977c010549e28 ] If we fail a handle-lookup part way thru, we need to drop the already obtained obj references. Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") Signed-off-by: Rob Clark Tested-by: Connor Abbott Patchwork: https://patchwork.freedesktop.org/patch/669784/ Signed-off-by: Sasha Levin commit 0f97564a1fb62f34b3b498e2f12caffbe99c004a Author: Wang Liang Date: Sat Aug 30 15:50:23 2025 +0800 pps: fix warning in pps_register_cdev when register device fail [ Upstream commit b0531cdba5029f897da5156815e3bdafe1e9b88d ] Similar to previous commit 2a934fdb01db ("media: v4l2-dev: fix error handling in __video_register_device()"), the release hook should be set before device_register(). Otherwise, when device_register() return error and put_device() try to callback the release function, the below warning may happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4760 at drivers/base/core.c:2567 device_release+0x1bd/0x240 drivers/base/core.c:2567 Modules linked in: CPU: 1 UID: 0 PID: 4760 Comm: syz.4.914 Not tainted 6.17.0-rc3+ #1 NONE RIP: 0010:device_release+0x1bd/0x240 drivers/base/core.c:2567 Call Trace: kobject_cleanup+0x136/0x410 lib/kobject.c:689 kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0xe9/0x130 lib/kobject.c:737 put_device+0x24/0x30 drivers/base/core.c:3797 pps_register_cdev+0x2da/0x370 drivers/pps/pps.c:402 pps_register_source+0x2f6/0x480 drivers/pps/kapi.c:108 pps_tty_open+0x190/0x310 drivers/pps/clients/pps-ldisc.c:57 tty_ldisc_open+0xa7/0x120 drivers/tty/tty_ldisc.c:432 tty_set_ldisc+0x333/0x780 drivers/tty/tty_ldisc.c:563 tiocsetd drivers/tty/tty_io.c:2429 [inline] tty_ioctl+0x5d1/0x1700 drivers/tty/tty_io.c:2728 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl fs/ioctl.c:584 [inline] __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x5f/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e Before commit c79a39dc8d06 ("pps: Fix a use-after-free"), pps_register_cdev() call device_create() to create pps->dev, which will init dev->release to device_create_release(). Now the comment is outdated, just remove it. Thanks for the reminder from Calvin Owens, 'kfree_pps' should be removed in pps_register_source() to avoid a double free in the failure case. Link: https://lore.kernel.org/all/20250827065010.3208525-1-wangliang74@huawei.com/ Fixes: c79a39dc8d06 ("pps: Fix a use-after-free") Signed-off-by: Wang Liang Reviewed-By: Calvin Owens Link: https://lore.kernel.org/r/20250830075023.3498174-1-wangliang74@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6a7d643510dd6274509d13ce41e82e540830eaaf Author: Colin Ian King Date: Tue Sep 2 12:37:12 2025 +0100 misc: genwqe: Fix incorrect cmd field being reported in error [ Upstream commit 6b26053819dccc664120e07c56f107fb6f72f3fa ] There is a dev_err message that is reporting the value of cmd->asiv_length when it should be reporting cmd->asv_length instead. Fix this. Fixes: eaf4722d4645 ("GenWQE Character device and DDCB queue") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20250902113712.2624743-1-colin.i.king@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c5a2791a7f11939f05f95c01f0aec0c55bbf28d5 Author: Seppo Takalo Date: Wed Aug 27 15:26:56 2025 +0300 tty: n_gsm: Don't block input queue by waiting MSC [ Upstream commit 3cf0b3c243e56bc43be560617416c1d9f301f44c ] Currently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue. Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used. Fixes: 48473802506d ("tty: n_gsm: fix missing update of modem controls after DLCI open") Signed-off-by: Seppo Takalo Link: https://lore.kernel.org/r/20250827123221.1148666-1-seppo.takalo@nordicsemi.no Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bd72b648bd5771c4cc6de780790b6e4e53936990 Author: William Wu Date: Fri Aug 22 11:36:09 2025 +0800 usb: gadget: configfs: Correctly set use_os_string at bind [ Upstream commit e271cc0d25015f4be6c88bd7731444644eb352c2 ] Once the use_os_string flag is set to true for some functions (e.g. adb/mtp) which need to response the OS string, and then if we re-bind the ConfigFS gadget to use the other functions (e.g. hid) which should not to response the OS string, however, because the use_os_string flag is still true, so the usb gadget response the OS string descriptor incorrectly, this can cause the USB device to be unrecognizable on the Windows system. An example of this as follows: echo 1 > os_desc/use ln -s functions/ffs.adb configs/b.1/function0 start adbd echo "" > UDC #succeed stop adbd rm configs/b.1/function0 echo 0 > os_desc/use ln -s functions/hid.gs0 configs/b.1/function0 echo "" > UDC #fail to connect on Windows This patch sets the use_os_string flag to false at bind if the functions not support OS Descriptors. Signed-off-by: William Wu Fixes: 87213d388e92 ("usb: gadget: configfs: OS String support") Link: https://lore.kernel.org/r/1755833769-25434-1-git-send-email-william.wu@rock-chips.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b8f0623b72855df914cc543757719876185a8498 Author: Xichao Zhao Date: Fri Aug 22 17:22:24 2025 +0800 usb: phy: twl6030: Fix incorrect type for ret [ Upstream commit b570b346ddd727c4b41743a6a2f49e7217c5317f ] In the twl6030_usb_probe(), the variable ret is declared as a u32 type. However, since ret may receive -ENODEV when accepting the return value of omap_usb2_set_comparator().Therefore, its type should be changed to int. Fixes: 0e98de67bacba ("usb: otg: make twl6030_usb as a comparator driver to omap_usb2") Signed-off-by: Xichao Zhao Link: https://lore.kernel.org/r/20250822092224.30645-1-zhao.xichao@vivo.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 52ba4bc4ca3e85e2f222599746f2b24c287b8d1a Author: Qianfeng Rong Date: Thu Sep 4 20:36:46 2025 +0800 drm/amdkfd: Fix error code sign for EINVAL in svm_ioctl() [ Upstream commit cbda64f3f58027f68211dda8ea94d52d7e493995 ] Use negative error code -EINVAL instead of positive EINVAL in the default case of svm_ioctl() to conform to Linux kernel error code conventions. Fixes: 42de677f7999 ("drm/amdkfd: register svm range") Signed-off-by: Qianfeng Rong Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 73ce2a774ad6497cbd48dc4f8a5d699bc417f3fa Author: Anderson Nascimento Date: Thu Sep 4 16:09:13 2025 +0200 fanotify: Validate the return value of mnt_ns_from_dentry() before dereferencing [ Upstream commit 62e59ffe8787b5550ccff70c30b6f6be6a3ac3dd ] The function do_fanotify_mark() does not validate if mnt_ns_from_dentry() returns NULL before dereferencing mntns->user_ns. This causes a NULL pointer dereference in do_fanotify_mark() if the path is not a mount namespace object. Fix this by checking mnt_ns_from_dentry()'s return value before dereferencing it. Before the patch $ gcc fanotify_nullptr.c -o fanotify_nullptr $ mkdir A $ ./fanotify_nullptr Fanotify fd: 3 fanotify_mark: Operation not permitted $ unshare -Urm Fanotify fd: 3 Killed int main(void){ int ffd; ffd = fanotify_init(FAN_CLASS_NOTIF | FAN_REPORT_MNT, 0); if(ffd < 0){ perror("fanotify_init"); exit(EXIT_FAILURE); } printf("Fanotify fd: %d\n",ffd); if(fanotify_mark(ffd, FAN_MARK_ADD | FAN_MARK_MNTNS, FAN_MNT_ATTACH, AT_FDCWD, "A") < 0){ perror("fanotify_mark"); exit(EXIT_FAILURE); } return 0; } After the patch $ gcc fanotify_nullptr.c -o fanotify_nullptr $ mkdir A $ ./fanotify_nullptr Fanotify fd: 3 fanotify_mark: Operation not permitted $ unshare -Urm Fanotify fd: 3 fanotify_mark: Invalid argument [ 25.694973] BUG: kernel NULL pointer dereference, address: 0000000000000038 [ 25.695006] #PF: supervisor read access in kernel mode [ 25.695012] #PF: error_code(0x0000) - not-present page [ 25.695017] PGD 109a30067 P4D 109a30067 PUD 142b46067 PMD 0 [ 25.695025] Oops: Oops: 0000 [#1] SMP NOPTI [ 25.695032] CPU: 4 UID: 1000 PID: 1478 Comm: fanotify_nullpt Not tainted 6.17.0-rc4 #1 PREEMPT(lazy) [ 25.695040] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 [ 25.695049] RIP: 0010:do_fanotify_mark+0x817/0x950 [ 25.695066] Code: 04 00 00 e9 45 fd ff ff 48 8b 7c 24 48 4c 89 54 24 18 4c 89 5c 24 10 4c 89 0c 24 e8 b3 11 fc ff 4c 8b 54 24 18 4c 8b 5c 24 10 <48> 8b 78 38 4c 8b 0c 24 49 89 c4 e9 13 fd ff ff 8b 4c 24 28 85 c9 [ 25.695081] RSP: 0018:ffffd31c469e3c08 EFLAGS: 00010203 [ 25.695104] RAX: 0000000000000000 RBX: 0000000001000000 RCX: ffff8eb48aebd220 [ 25.695110] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8eb4835e8180 [ 25.695115] RBP: 0000000000000111 R08: 0000000000000000 R09: 0000000000000000 [ 25.695142] R10: ffff8eb48a7d56c0 R11: ffff8eb482bede00 R12: 00000000004012a7 [ 25.695148] R13: 0000000000000110 R14: 0000000000000001 R15: ffff8eb48a7d56c0 [ 25.695154] FS: 00007f8733bda740(0000) GS:ffff8eb61ce5f000(0000) knlGS:0000000000000000 [ 25.695162] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 25.695170] CR2: 0000000000000038 CR3: 0000000136994006 CR4: 00000000003706f0 [ 25.695201] Call Trace: [ 25.695209] [ 25.695215] __x64_sys_fanotify_mark+0x1f/0x30 [ 25.695222] do_syscall_64+0x82/0x2c0 ... Fixes: 58f5fbeb367f ("fanotify: support watching filesystems and mounts inside userns") Link: https://patch.msgid.link/CAPhRvkw4ONypNsJrCnxbKnJbYmLHTDEKFC4C_num_5sVBVa8jg@mail.gmail.com Signed-off-by: Anderson Nascimento Reviewed-by: Christian Brauner Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 5eb76d12834b98e5ebad8e372a10e4cef799d13d Author: Eric Dumazet Date: Wed Sep 3 08:47:18 2025 +0000 tcp: fix __tcp_close() to only send RST when required [ Upstream commit 5f9238530970f2993b23dd67fdaffc552a2d2e98 ] If the receive queue contains payload that was already received, __tcp_close() can send an unexpected RST. Refine the code to take tp->copied_seq into account, as we already do in tcp recvmsg(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Neal Cardwell Reviewed-by: Kuniyuki Iwashima Reviewed-by: Jason Xing Link: https://patch.msgid.link/20250903084720.1168904-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e4ed50b0dc2999772f1ac6908a3e7660dc6c936f Author: Ziyue Zhang Date: Thu Sep 4 14:52:23 2025 +0800 PCI: qcom: Add equalization settings for 8.0 GT/s and 32.0 GT/s [ Upstream commit 37bf0f4e39de9b53bc6f8d3702b021e2c6b5bae3 ] Add lane equalization setting for 8.0 GT/s and 32.0 GT/s to enhance link stability and avoid AER Correctable Errors reported on some platforms (eg. SA8775P). 8.0 GT/s, 16.0 GT/s and 32.0 GT/s require the same equalization setting. This setting is programmed into a group of shadow registers, which can be switched to configure equalization for different speeds by writing 00b, 01b and 10b to `RATE_SHADOW_SEL`. Hence, program equalization registers in a loop using link speed as index, so that equalization setting can be programmed for 8.0 GT/s, 16.0 GT/s and 32.0 GT/s. Fixes: 489f14be0e0a ("arm64: dts: qcom: sa8775p: Add pcie0 and pcie1 nodes") Co-developed-by: Qiang Yu Signed-off-by: Qiang Yu Signed-off-by: Ziyue Zhang [mani: wrapped the warning to fit 100 columns, used post-increment for loop] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20250904065225.1762793-2-ziyue.zhang@oss.qualcomm.com Signed-off-by: Sasha Levin commit db28bf40d34b44545ceb865819807a3eb84323d5 Author: Aditya Kumar Singh Date: Tue Aug 12 12:53:30 2025 +0530 wifi: mac80211: consider links for validating SCAN_FLAG_AP in scan request during MLO [ Upstream commit 36b75dcb1e25739a3a0975699208c98f4b55d012 ] Commit 78a7a126dc5b ("wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO") introduced a check that rejects scan requests if any link is already beaconing. This works fine when all links share the same radio, but breaks down in multi-radio setups. Consider a scenario where a 2.4 GHz link is beaconing and a scan is requested on a 5 GHz link, each backed by a different physical radio. The current logic still blocks the scan, even though it should be allowed. As a result, interface bring-up fails unnecessarily in valid configurations. Fix this by checking whether the scan is being requested on the same underlying radio as the beaconing link. Only reject the scan if it targets a link that is already beaconing and the NL80211_FEATURE_AP_SCAN is not set. This ensures correct behavior in multi-radio environments and avoids false rejections. Fixes: 78a7a126dc5b ("wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO") Signed-off-by: Aditya Kumar Singh Link: https://patch.msgid.link/20250812-fix_scan_ap_flag_requirement_during_mlo-v4-3-383ffb6da213@oss.qualcomm.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ebbbeda212ed8631f3420ff6f5bcb2e271c4e001 Author: Alok Tiwari Date: Tue Aug 19 08:04:08 2025 -0700 PCI: tegra: Fix devm_kcalloc() argument order for port->phys allocation [ Upstream commit e1a8805e5d263453ad76a4f50ab3b1c18ea07560 ] Fix incorrect argument order in devm_kcalloc() when allocating port->phys. The original call used sizeof(phy) as the number of elements and port->lanes as the element size, which is reversed. While this happens to produce the correct total allocation size with current pointer size and lane counts, the argument order is wrong. Fixes: 6fe7c187e026 ("PCI: tegra: Support per-lane PHYs") Signed-off-by: Alok Tiwari [mani: added Fixes tag] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20250819150436.3105973-1-alok.a.tiwari@oracle.com Signed-off-by: Sasha Levin commit f1dbb3eedb7db4cad45d2619edb1cce6041f79e3 Author: Jun Nie Date: Tue Aug 19 09:30:55 2025 +0800 drm/msm: Do not validate SSPP when it is not ready [ Upstream commit 6fc616723bb5fd4289d7422fa013da062b44ae55 ] Current code will validate current plane and previous plane to confirm they can share a SSPP with multi-rect mode. The SSPP is already allocated for previous plane, while current plane is not associated with any SSPP yet. Null pointer is referenced when validating the SSPP of current plane. Skip SSPP validation for current plane. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000888ac3000 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 4 UID: 0 PID: 1891 Comm: modetest Tainted: G S 6.15.0-rc2-g3ee3f6e1202e #335 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: SM8650 EV1 rev1 4slam 2et (DT) pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : dpu_plane_is_multirect_capable+0x68/0x90 lr : dpu_assign_plane_resources+0x288/0x410 sp : ffff800093dcb770 x29: ffff800093dcb770 x28: 0000000000002000 x27: ffff000817c6c000 x26: ffff000806b46368 x25: ffff0008013f6080 x24: ffff00080cbf4800 x23: ffff000810842680 x22: ffff0008013f1080 x21: ffff00080cc86080 x20: ffff000806b463b0 x19: ffff00080cbf5a00 x18: 00000000ffffffff x17: 707a5f657a696c61 x16: 0000000000000003 x15: 0000000000002200 x14: 00000000ffffffff x13: 00aaaaaa00aaaaaa x12: 0000000000000000 x11: ffff000817c6e2b8 x10: 0000000000000000 x9 : ffff80008106a950 x8 : ffff00080cbf48f4 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000438 x3 : 0000000000000438 x2 : ffff800082e245e0 x1 : 0000000000000008 x0 : 0000000000000000 Call trace: dpu_plane_is_multirect_capable+0x68/0x90 (P) dpu_crtc_atomic_check+0x5bc/0x650 drm_atomic_helper_check_planes+0x13c/0x220 drm_atomic_helper_check+0x58/0xb8 msm_atomic_check+0xd8/0xf0 drm_atomic_check_only+0x4a8/0x968 drm_atomic_commit+0x50/0xd8 drm_atomic_helper_update_plane+0x140/0x188 __setplane_atomic+0xfc/0x148 drm_mode_setplane+0x164/0x378 drm_ioctl_kernel+0xc0/0x140 drm_ioctl+0x20c/0x500 __arm64_sys_ioctl+0xbc/0xf8 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x48/0xf8 do_el0_svc+0x28/0x40 el0_svc+0x30/0xd0 el0t_64_sync_handler+0x144/0x168 el0t_64_sync+0x198/0x1a0 Code: b9402021 370fffc1 f9401441 3707ff81 (f94010a1) ---[ end trace 0000000000000000 ]--- Fixes: 3ed12a3664b36 ("drm/msm/dpu: allow sharing SSPP between planes") Signed-off-by: Jun Nie Patchwork: https://patchwork.freedesktop.org/patch/669224/ Link: https://lore.kernel.org/r/20250819-v6-16-rc2-quad-pipe-upstream-v15-1-2c7a85089db8@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 4365e22333438ca675524605ec6df9d9a4f4c3c4 Author: Gokul Sivakumar Date: Thu Jul 24 15:41:36 2025 +0530 wifi: brcmfmac: fix 43752 SDIO FWVID incorrectly labelled as Cypress (CYW) [ Upstream commit 74e2ef72bd4b25ce21c8f309d4f5b91b5df9ff5b ] Cypress(Infineon) is not the vendor for this 43752 SDIO WLAN chip, and so has not officially released any firmware binary for it. It is incorrect to maintain this WLAN chip with firmware vendor ID as "CYW". So relabel the chip's firmware Vendor ID as "WCC" as suggested by the maintainer. Fixes: d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization") Fixes: f74f1ec22dc2 ("wifi: brcmfmac: add support for Cypress firmware api") Signed-off-by: Gokul Sivakumar Acked-by: Arend van Spriel Link: https://patch.msgid.link/20250724101136.6691-1-gokulkumar.sivakumar@infineon.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c404b28f17097852c225a7e2005517e80d48ba00 Author: Stefan Kerkmann Date: Mon Aug 4 16:16:59 2025 +0200 wifi: mwifiex: send world regulatory domain to driver [ Upstream commit 56819d00bc2ebaa6308913c28680da5d896852b8 ] The world regulatory domain is a restrictive subset of channel configurations which allows legal operation of the adapter all over the world. Changing to this domain should not be prevented. Fixes: dd4a9ac05c8e1 ("mwifiex: send regulatory domain info to firmware only if alpha2 changed") changed Signed-off-by: Stefan Kerkmann Reviewed-by: Jeff Chen Link: https://patch.msgid.link/20250804-fix-mwifiex-regulatory-domain-v1-1-e4715c770c4d@pengutronix.de Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9d1ce4bdf5f20b166430c7ae8458c03568e8b15b Author: Lorenzo Bianconi Date: Tue Aug 26 13:54:31 2025 +0200 wifi: mac80211: Make CONNECTION_MONITOR optional for MLO sta [ Upstream commit ac36daa83650c26fd55dee1a6ee5144769239911 ] Since commit '1bc892d76a6f ("wifi: mac80211: extend connection monitoring for MLO")' mac80211 supports connection monitor for MLO client interfaces. Remove the CONNECTION_MONITOR requirement in ieee80211_register_hw routine. Fixes: 1bc892d76a6f ("wifi: mac80211: extend connection monitoring for MLO") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20250826-remove-conn-mon-check-ieee80211_register_hw-v2-1-5a1e2f038245@kernel.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 63499c7ed46f9aa227ea292e4fab8936c8164497 Author: Timur Kristóf Date: Thu Aug 28 17:11:10 2025 +0200 drm/amd/pm: Disable SCLK switching on Oland with high pixel clocks (v3) [ Upstream commit 7009e3af0474aca5f64262b3c72fb6e23b232f9b ] Port of commit 227545b9a08c ("drm/radeon/dpm: Disable sclk switching on Oland when two 4K 60Hz monitors are connected") This is an ad-hoc DPM fix, necessary because we don't have proper bandwidth calculation for DCE 6. We define "high pixelclock" for SI as higher than necessary for 4K 30Hz. For example, 4K 60Hz and 1080p 144Hz fall into this category. When two high pixel clock displays are connected to Oland, additionally disable shader clock switching, which results in a higher voltage, thereby addressing some visible flickering. v2: Add more comments. v3: Split into two commits for easier review. Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)") Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ff53d18d5fd2ce98cd69b1c787a5cbc2321e7458 Author: Timur Kristóf Date: Thu Aug 28 17:11:09 2025 +0200 drm/amd/pm: Disable MCLK switching with non-DC at 120 Hz+ (v2) [ Upstream commit ed3803533c7bf7df88bc3fc9f70bd317e1228ea8 ] According to pp_pm_compute_clocks the non-DC display code has "issues with mclk switching with refresh rates over 120 hz". The workaround is to disable MCLK switching in this case. Do the same for legacy DPM. Fixes: 6ddbd37f1074 ("drm/amd/pm: optimize the amdgpu_pm_compute_clocks() implementations") Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f9b6a52e9b11ec853ce5f247d292cde584c12634 Author: Timur Kristóf Date: Thu Aug 28 17:11:08 2025 +0200 drm/amd/pm: Treat zero vblank time as too short in si_dpm (v3) [ Upstream commit 9003a0746864f39a0ef72bd45f8e1ad85d930d67 ] Some parts of the code base expect that MCLK switching is turned off when the vblank time is set to zero. According to pp_pm_compute_clocks the non-DC code has issues with MCLK switching with refresh rates over 120 Hz. v3: Add code comment to explain this better. Add an if statement instead of changing the switch_limit. Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)") Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit abcd976c3f863ad39f831e2d56a895f66002a209 Author: Timur Kristóf Date: Thu Aug 28 17:11:07 2025 +0200 drm/amd/pm: Adjust si_upload_smc_data register programming (v3) [ Upstream commit ce025130127437dc884c84c254170e27b2ce9309 ] Based on some comments in dm_pp_display_configuration above the crtc_index and line_time fields, these values are programmed to the SMC to work around an SMC hang when it switches MCLK. According to Alex, the Windows driver programs them to: mclk_change_block_cp_min = 200 / line_time mclk_change_block_cp_max = 100 / line_time Let's use the same for the sake of consistency. Previously we used the watermark values, but it seemed buggy as the code was mixing up low/high and A/B watermarks, and was not saving a low watermark value on DCE 6, so mclk_change_block_cp_max would be always zero previously. Split this change off from the previous si_upload_smc_data to make it easier to bisect, in case it causes any issues. Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)") Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0de1225cda5f88452169bebf10932c491922a73a Author: Timur Kristóf Date: Thu Aug 28 17:11:06 2025 +0200 drm/amd/pm: Fix si_upload_smc_data (v3) [ Upstream commit a43b2cec04b02743338aa78f837ee0bdf066a6d5 ] The si_upload_smc_data function uses si_write_smc_soft_register to set some register values in the SMC, and expects the result to be PPSMC_Result_OK which is 1. The PPSMC_Result_OK / PPSMC_Result_Failed values are used for checking the result of a command sent to the SMC. However, the si_write_smc_soft_register actually doesn't send any commands to the SMC and returns zero on success, so this check was incorrect. Fix that by not checking the return value, just like other calls to si_write_smc_soft_register. v3: Additionally, when no display is plugged in, there is no need to restrict MCLK switching, so program the registers to zero. Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)") Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cc3a83bba9aff0ff6ce1906fa951ef141456918d Author: Timur Kristóf Date: Thu Aug 28 17:11:04 2025 +0200 drm/amd/pm: Disable ULV even if unsupported (v3) [ Upstream commit 3a0c3a4035f995e1f993dfaf4d63dc19e9b4bc1c ] Always send PPSMC_MSG_DisableULV to the SMC, even if ULV mode is unsupported, to make sure it is properly turned off. v3: Simplify si_disable_ulv further. Always check the return value of amdgpu_si_send_msg_to_smc. Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)") Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f301840778046435bb83442c17cf3538b4fd6ada Author: Timur Kristóf Date: Thu Aug 28 17:11:03 2025 +0200 drm/amdgpu: Power up UVD 3 for FW validation (v2) [ Upstream commit c661219cd7be75bb5599b525f16a455a058eb516 ] Unlike later versions, UVD 3 has firmware validation. For this to work, the UVD should be powered up correctly. When DPM is enabled and the display clock is off, the SMU may choose a power state which doesn't power the UVD, which can result in failure to initialize UVD. v2: Add code comments to explain about the UVD power state and how UVD clock is turned on/off. Fixes: b38f3e80ecec ("drm amdgpu: SI UVD v3_1 (v2)") Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9ca1f214a37647bc02b3fa01a551c4a9013a5a38 Author: Yuanfang Zhang Date: Mon Jun 30 18:26:19 2025 +0800 coresight: Only register perf symlink for sinks with alloc_buffer [ Upstream commit 12d9a9dd9d8a4f1968073e7f34515896d1e22b78 ] Ensure that etm_perf_add_symlink_sink() is only called for devices that implement the alloc_buffer operation. This prevents invalid symlink creation for dummy sinks that do not implement alloc_buffer. Without this check, perf may attempt to use a dummy sink that lacks alloc_buffer operationsu to initialise perf's ring buffer, leading to runtime failures. Fixes: 9d3ba0b6c0569 ("Coresight: Add coresight dummy driver") Signed-off-by: Yuanfang Zhang Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250630-etm_perf_sink-v1-1-e4a7211f9ad7@quicinc.com Signed-off-by: Sasha Levin commit ebbb891f634c8a74e530febaf4afcf5d355fac39 Author: James Clark Date: Mon Jul 7 10:55:27 2025 +0100 coresight: Fix missing include for FIELD_GET [ Upstream commit 08d24e076d0fb9f90522ef69bf6cdae06e0919de ] Include the header for FIELD_GET which is only sometimes transitively included on some configs and kernel releases. Reported-by: Linux Kernel Functional Testing Closes: https://lists.linaro.org/archives/list/lkft-triage@lists.linaro.org/thread/6GKMK52PPRJVEYMEUHJP6BXF4CJAXOFL/ Fixes: a4e65842e114 ("coresight: Only check bottom two claim bits") Signed-off-by: James Clark Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250707-james-coresight-bitfield-include-v1-1-aa0f4220ecfd@linaro.org Signed-off-by: Sasha Levin commit 471f4ece207e9342946827ebc73aac5bb765371f Author: James Clark Date: Mon Jun 9 11:19:05 2025 +0100 coresight: trbe: Add ISB after TRBLIMITR write [ Upstream commit 52c0164b2526bce7013fca193e076f6d9eec9c95 ] DEN0154 states that hardware will be allowed to ignore writes to TRB* registers while the trace buffer is enabled. Add an ISB to ensure that it's disabled before clearing the other registers. This is purely defensive because it's expected that arm_trbe_disable() would be called before teardown which has the required ISB. Fixes: a2b579c41fe9 ("coresight: trbe: Remove redundant disable call") Signed-off-by: James Clark Reviewed-by: Yeoreum Yun Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250609-james-cs-trblimitr-isb-v1-1-3a2aa4ee6770@linaro.org Signed-off-by: Sasha Levin commit cc345a21147df3c02a2c760986826d11f59ec36d Author: Nathan Lynch Date: Tue Aug 26 11:07:38 2025 -0500 dmaengine: Fix dma_async_tx_descriptor->tx_submit documentation [ Upstream commit 7ea95d55e63176899eb96f7aaa34a5646f501b2c ] Commit 790fb9956eea ("linux/dmaengine.h: fix a few kernel-doc warnings") inserted new documentation for @desc_free in the middle of @tx_submit's description. Put @tx_submit's description back together, matching the indentation style of the rest of the documentation for dma_async_tx_descriptor. Fixes: 790fb9956eea ("linux/dmaengine.h: fix a few kernel-doc warnings") Reviewed-by: Dave Jiang Signed-off-by: Nathan Lynch Link: https://lore.kernel.org/r/20250826-dma_async_tx_desc-tx_submit-doc-fix-v1-1-18a4b51697db@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 3e751e21a8557d47e8119c7b2affb7802677eee5 Author: Eric Dumazet Date: Fri Aug 29 15:30:51 2025 +0000 inet: ping: check sock_net() in ping_get_port() and ping_lookup() [ Upstream commit 59f26d86b2a16f1406f3b42025062b6d1fba5dd5 ] We need to check socket netns before considering them in ping_get_port(). Otherwise, one malicious netns could 'consume' all ports. Add corresponding check in ping_lookup(). Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Reviewed-by: Yue Haibing Link: https://patch.msgid.link/20250829153054.474201-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 854da2b0df1654d63963d587b12fec6068d89643 Author: Weili Qian Date: Thu Aug 21 09:38:08 2025 +0800 crypto: hisilicon/qm - request reserved interrupt for virtual function [ Upstream commit 9228facb308157ac0bdd264b873187896f7a9c7a ] The device interrupt vector 3 is an error interrupt for physical function and a reserved interrupt for virtual function. However, the driver has not registered the reserved interrupt for virtual function. When allocating interrupts, the number of interrupts is allocated based on powers of two, which includes this interrupt. When the system enables GICv4 and the virtual function passthrough to the virtual machine, releasing the interrupt in the driver triggers a warning. The WARNING report is: WARNING: CPU: 62 PID: 14889 at arch/arm64/kvm/vgic/vgic-its.c:852 its_free_ite+0x94/0xb4 Therefore, register a reserved interrupt for VF and set the IRQF_NO_AUTOEN flag to avoid that warning. Fixes: 3536cc55cada ("crypto: hisilicon/qm - support get device irq information from hardware registers") Signed-off-by: Weili Qian Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 353ec77ee3927cd4cdf67c94ce9378868d07fb33 Author: Zhushuai Yin Date: Thu Aug 21 09:38:07 2025 +0800 crypto: hisilicon/qm - check whether the input function and PF are on the same device [ Upstream commit 6a2c9164b52e6bc134127fd543461fdef95cc8ec ] Function rate limiting is set through physical function driver. Users configure by providing function information and rate limit values. Before configuration, it is necessary to check whether the provided function and PF belong to the same device. Fixes: 22d7a6c39cab ("crypto: hisilicon/qm - add pci bdf number check") Signed-off-by: Zhushuai Yin Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 54dbdbc25e961063606c7cc066f90ebe50b40592 Author: Weili Qian Date: Thu Aug 21 09:38:06 2025 +0800 crypto: hisilicon - check the sva module status while enabling or disabling address prefetch [ Upstream commit 1f9128f121a872f27251be60ccccfd98c136d72e ] After enabling address prefetch, check the sva module status. If all previous prefetch requests from the sva module are not completed, then disable the address prefetch to ensure normal execution of new task operations. After disabling address prefetch, check if all requests from the sva module have been completed. Fixes: a5c164b195a8 ("crypto: hisilicon/qm - support address prefetching") Signed-off-by: Weili Qian Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5af2d502a090c2309e62145ee8a37a7e8b0fb358 Author: Chenghai Huang Date: Thu Aug 21 09:38:05 2025 +0800 crypto: hisilicon - re-enable address prefetch after device resuming [ Upstream commit 0dcd21443d9308ed88909d35aa0490c3fc680a47 ] When the device resumes from a suspended state, it will revert to its initial state and requires re-enabling. Currently, the address prefetch function is not re-enabled after device resuming. Move the address prefetch enable to the initialization process. In this way, the address prefetch can be enabled when the device resumes by calling the initialization process. Fixes: 607c191b371d ("crypto: hisilicon - support runtime PM for accelerator device") Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f440c1fc32e16f16535d5d6b6800cd0bcf2e0848 Author: Chenghai Huang Date: Thu Aug 21 09:38:04 2025 +0800 crypto: hisilicon/zip - remove unnecessary validation for high-performance mode configurations [ Upstream commit d4e081510471e79171c4e0a11f6cb608e49bc082 ] When configuring the high-performance mode register, there is no need to verify whether the register has been successfully enabled, as there is no possibility of a write failure for this register. Fixes: a9864bae1806 ("crypto: hisilicon/zip - add zip comp high perf mode configuration") Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 923e0734c386984d45de508528a7a7ad91d791cc Author: Eric Dumazet Date: Thu Aug 28 19:58:23 2025 +0000 ipv4: start using dst_dev_rcu() [ Upstream commit 6ad8de3cefdb6ffa6708b21c567df0dbf82c43a8 ] Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF. Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(), ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu(). Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20250828195823.3958522-9-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 07613a95326ebad2d1b88d883cd72546025a4f3e Author: Eric Dumazet Date: Thu Aug 28 19:58:21 2025 +0000 tcp_metrics: use dst_dev_net_rcu() [ Upstream commit 50c127a69cd6285300931853b352a1918cfa180f ] Replace three dst_dev() with a lockdep enabled helper. Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20250828195823.3958522-7-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a805729c0091073d8f0415cfa96c7acd1bc17a48 Author: Eric Dumazet Date: Thu Aug 28 19:58:20 2025 +0000 net: use dst_dev_rcu() in sk_setup_caps() [ Upstream commit 99a2ace61b211b0be861b07fbaa062fca4b58879 ] Use RCU to protect accesses to dst->dev from sk_setup_caps() and sk_dst_gso_max_size(). Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(), and ip_dst_mtu_maybe_forward(). ip4_dst_hoplimit() can use dst_dev_net_rcu(). Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20250828195823.3958522-6-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0393f85c3241c19ba8550f04a812e7d19f6b3082 Author: Eric Dumazet Date: Thu Aug 28 19:58:19 2025 +0000 ipv6: use RCU in ip6_output() [ Upstream commit 11709573cc4e48dc34c80fc7ab9ce5b159e29695 ] Use RCU in ip6_output() in order to use dst_dev_rcu() to prevent possible UAF. We can remove rcu_read_lock()/rcu_read_unlock() pairs from ip6_finish_output2(). Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20250828195823.3958522-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f7f9e924f23684b4b23cd9f976cceab24a968e34 Author: Eric Dumazet Date: Thu Aug 28 19:58:18 2025 +0000 ipv6: use RCU in ip6_xmit() [ Upstream commit 9085e56501d93af9f2d7bd16f7fcfacdde47b99c ] Use RCU in ip6_xmit() in order to use dst_dev_rcu() to prevent possible UAF. Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20250828195823.3958522-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dc05e32cb3e53b90ee0714c688b8e3bb7b9bbc6a Author: Eric Dumazet Date: Thu Aug 28 19:58:17 2025 +0000 ipv6: start using dst_dev_rcu() [ Upstream commit b775ecf1655cedbc465fd6699ab18a2bc4e7a352 ] Refactor icmpv6_xrlim_allow() and ip6_dst_hoplimit() so that we acquire rcu_read_lock() a bit longer to be able to use dst_dev_rcu() instead of dst_dev(). __ip6_rt_update_pmtu() and rt6_do_redirect can directly use dst_dev_rcu() in sections already holding rcu_read_lock(). Small changes to use dst_dev_net_rcu() in ip6_default_advmss(), ipv6_sock_ac_join(), ip6_mc_find_dev() and ndisc_send_skb(). Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20250828195823.3958522-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 219b1aed7b753f7e2fab6991320611c0b7e19276 Author: Yue Haibing Date: Fri Aug 22 14:40:51 2025 +0800 ipv6: mcast: Add ip6_mc_find_idev() helper [ Upstream commit 60c481d4caa569001c708d4e9622d19650b6bedc ] Extract the same code logic from __ipv6_sock_mc_join() and ip6_mc_find_dev(), also add new helper ip6_mc_find_idev() to reduce redundancy and enhance readability. No functional changes intended. Signed-off-by: Yue Haibing Reviewed-by: Dawid Osuchowski Link: https://patch.msgid.link/20250822064051.2991480-1-yuehaibing@huawei.com Signed-off-by: Jakub Kicinski Stable-dep-of: b775ecf1655c ("ipv6: start using dst_dev_rcu()") Signed-off-by: Sasha Levin commit 0001408c902a9020f3ac8590cd8d5a938009694d Author: Eric Dumazet Date: Thu Aug 28 19:58:16 2025 +0000 net: dst: introduce dst->dev_rcu [ Upstream commit caedcc5b6df1b2e2b5f39079e3369c1d4d5c5f50 ] Followup of commit 88fe14253e18 ("net: dst: add four helpers to annotate data-races around dst->dev"). We want to gradually add explicit RCU protection to dst->dev, including lockdep support. Add an union to alias dst->dev_rcu and dst->dev. Add dst_dev_net_rcu() helper. Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20250828195823.3958522-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 67608dce2fda67aa05b4f9526d79e91428807a4b Author: Geert Uytterhoeven Date: Tue Aug 12 15:54:29 2025 +0200 efi: Explain OVMF acronym in OVMF_DEBUG_LOG help text [ Upstream commit 05e75ac35ee9e38f96bbfebf1830ec2cace2e7f8 ] People not very intimate with EFI may not know the meaning of the OVMF acronym. Write it in full, to help users with making good decisions when configuring their kernels. Fixes: f393a761763c5427 ("efi: add ovmf debug log driver") Signed-off-by: Geert Uytterhoeven Reviewed-by: Richard Lyu Acked-by: Gerd Hoffmann Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 8e0a18d6ee733f4fc77bc05d73f28dba33914ccb Author: Qianfeng Rong Date: Thu Aug 28 11:39:17 2025 +0800 accel/amdxdna: Use int instead of u32 to store error codes [ Upstream commit 24de3daf6179bce3710527b8292d7ee6f1b56393 ] Change the 'ret' variable from u32 to int to store -EINVAL. Storing the negative error codes in unsigned type, doesn't cause an issue at runtime but it's ugly as pants. Additionally, assigning -EINVAL to u32 ret (i.e., u32 ret = -EINVAL) may trigger a GCC warning when the -Wsign-conversion flag is enabled. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Signed-off-by: Qianfeng Rong Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://lore.kernel.org/r/20250828033917.113364-1-rongqianfeng@vivo.com Signed-off-by: Sasha Levin commit b39dd76f118c45b421f9810c19eb54ad83b2efb6 Author: Lijo Lazar Date: Thu Aug 14 13:52:50 2025 +0530 drm/amdgpu: Check vcn state before profile switch [ Upstream commit 9c0442286f84a5036958b3d8eb00bf0bb070dbd1 ] The patch uses power state of VCN instances for requesting video profile. In idle worker of a vcn instance, when there is no outstanding submisssion or fence, the instance is put to power gated state. When all instances are powered off that means video profile is no longer required. A request is made to turn off video profile. A job submission starts with begin_use of ring, and at that time vcn instance state is changed to power on. Subsequently a check is made for active video profile, and if not active, a request is made. Fixes: 3b669df92c85 ("drm/amdgpu/vcn: adjust workload profile handling") Signed-off-by: Lijo Lazar Reviewed-by: Sathishkumar S Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 374a2b13029721bf0535f3b248539f453f554e06 Author: Sathishkumar S Date: Tue Aug 5 21:35:10 2025 +0530 drm/amdgpu/vcn: Hold pg_lock before vcn power off [ Upstream commit 111821e4b5a3105c42c7c99f4abd4d8af9f64248 ] Acquire vcn_pg_lock before changes to vcn power state and release it after power off in idle work handler. Signed-off-by: Sathishkumar S Reviewed-by: Leo Liu Signed-off-by: Alex Deucher Stable-dep-of: 9c0442286f84 ("drm/amdgpu: Check vcn state before profile switch") Signed-off-by: Sasha Levin commit a1dd75cdcb71e21a3eec16020a0efdfaa61124f9 Author: Sathishkumar S Date: Thu Jul 17 11:30:52 2025 +0530 drm/amdgpu/vcn: Add regdump helper functions [ Upstream commit de55cbff5ce93c316b0113535752e43079761f2c ] Add generic helper functions for vcn devcoredump support which can be re-used for all vcn versions. Signed-off-by: Sathishkumar S Acked-by: Leo Liu Signed-off-by: Alex Deucher Stable-dep-of: 9c0442286f84 ("drm/amdgpu: Check vcn state before profile switch") Signed-off-by: Sasha Levin commit 1d4f9925992f4810b5a46a4d0e0f4b82da5d9dc7 Author: Arnd Bergmann Date: Tue Jun 10 11:31:56 2025 +0200 media: st-delta: avoid excessive stack usage [ Upstream commit 5954ad7d1af92cb6244c5f31216e43af55febbb7 ] Building with a reduced stack warning limit shows that delta_mjpeg_decode() copies a giant structure to the stack each time but only uses three of its members: drivers/media/platform/st/sti/delta/delta-mjpeg-dec.c: In function 'delta_mjpeg_decode': drivers/media/platform/st/sti/delta/delta-mjpeg-dec.c:427:1: error: the frame size of 1296 bytes is larger than 1280 bytes [-Werror=frame-larger-than=] Open-code the passing of the structure members that are actually used here. Fixes: 433ff5b4a29b ("[media] st-delta: add mjpeg support") Signed-off-by: Arnd Bergmann Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 5e6ebfc78c11ff4ffe01aed73555a6c97c866300 Author: Qianfeng Rong Date: Thu Aug 28 16:13:10 2025 +0800 ALSA: lx_core: use int type to store negative error codes [ Upstream commit 4ef353d546cda466fc39b7daca558d7bcec21c09 ] Change the 'ret' variable from u16 to int to store negative error codes or zero returned by lx_message_send_atomic(). Storing the negative error codes in unsigned type, doesn't cause an issue at runtime but it's ugly as pants. Additionally, assigning negative error codes to unsigned type may trigger a GCC warning when the -Wsign-conversion flag is enabled. No effect on runtime. Fixes: 02bec4904508 ("ALSA: lx6464es - driver for the digigram lx6464es interface") Signed-off-by: Qianfeng Rong Link: https://patch.msgid.link/20250828081312.393148-1-rongqianfeng@vivo.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 04c6b9a573c3a94e17e0c0a0a30d5e689840489d Author: Dan Carpenter Date: Wed Aug 27 15:57:31 2025 +0300 HID: i2c-hid: Fix test in i2c_hid_core_register_panel_follower() [ Upstream commit 5c76c794bf29399394ebacaa5af8436b8bed0d46 ] Bitwise AND was intended instead of OR. With the current code the condition is always true. Fixes: cbdd16b818ee ("HID: i2c-hid: Make elan touch controllers power on after panel is enabled") Signed-off-by: Dan Carpenter Reviewed-by: Douglas Anderson Reviewed-by: Pin-yen Lin Acked-by: Jiri Kosina Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/aK8Au3CgZSTvfEJ6@stanley.mountain Signed-off-by: Sasha Levin commit ab6cfdfd8bd76367828cc952d57120436a076258 Author: Nirmoy Das Date: Mon Aug 25 14:46:42 2025 -0700 PCI/ACPI: Fix pci_acpi_preserve_config() memory leak [ Upstream commit fac679df7580979174c90303f004b09cdc6f086f ] pci_acpi_preserve_config() leaks memory by returning early without freeing the ACPI object on success. Fix that by always freeing the obj, which is not needed by the caller. Fixes: 9d7d5db8e78e ("PCI: Move PRESERVE_BOOT_CONFIG _DSM evaluation to pci_register_host_bridge()") Signed-off-by: Nirmoy Das Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20250825214642.142135-1-nirmoyd@nvidia.com Signed-off-by: Sasha Levin commit db05b70c5d4c34c748e25697bf7489b909d1d71a Author: Nipun Gupta Date: Tue Aug 26 10:08:51 2025 +0530 cdx: don't select CONFIG_GENERIC_MSI_IRQ [ Upstream commit ab1d8dda32e9507ca3bfb6b43661aeaa27f7bd82 ] x86 does not use CONFIG_GENERIC_MSI_IRQ, and trying to enable it anyway results in a build failure: In file included from include/linux/ssb/ssb.h:10, from drivers/ssb/pcihost_wrapper.c:18: include/linux/gpio/driver.h:41:33: error: field 'msiinfo' has incomplete type 41 | msi_alloc_info_t msiinfo; | ^~~~~~~ In file included from include/linux/kvm_host.h:19, from arch/x86/events/intel/core.c:17: include/linux/msi.h:528:33: error: field 'alloc_info' has incomplete type 528 | msi_alloc_info_t alloc_info; Change the driver to actually build without this symbol and remove the incorrect 'select' statements. Fixes: e8b18c11731d ("cdx: Fix missing GENERIC_MSI_IRQ on compile test") Reviewed-by: Robin Murphy Reviewed-by: Nikhil Agarwal Signed-off-by: Arnd Bergmann Signed-off-by: Nipun Gupta Link: https://lore.kernel.org/r/20250826043852.2206008-1-nipun.gupta@amd.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 03f3cd82ec4d88905e53ed60ece681266d54c000 Author: Krishna Chaitanya Chundru Date: Tue Aug 26 16:32:55 2025 +0530 PCI: qcom: Restrict port parsing only to PCIe bridge child nodes [ Upstream commit 45df22935bdc6bbddf87f38a57ae7257244cf3cf ] The qcom_pcie_parse_ports() function currently iterates over all available child nodes of the PCIe controller's device tree node. This includes unrelated nodes such as OPP (Operating Performance Points) nodes, which do not contain the expected 'reset' and 'phy' properties. As a result, parsing fails and the driver falls back to the legacy method of parsing the controller node directly. However, this fallback also fails when properties are shifted to the Root Port node, leading to probe failure. Fix this by restricting the parsing logic to only consider child nodes with device_type = "pci", which is the expected and required property for PCIe bridge nodes as per the pci-bus-common.yaml dtschema. Fixes: a2fbecdbbb9d ("PCI: qcom: Add support for parsing the new Root Port binding") Signed-off-by: Krishna Chaitanya Chundru [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20250826-pakala-v3-3-721627bd5bb0@oss.qualcomm.com Signed-off-by: Sasha Levin commit ca677681afc8a32a366bb969917f2c69a36b95a4 Author: Joanne Koong Date: Tue May 20 13:16:54 2025 -0700 fuse: remove unneeded offset assignment when filling write pages [ Upstream commit 6fd26f50857698c6f07a9e6b149247925fadb8fd ] With the change in aee03ea7ff98 ("fuse: support large folios for writethrough writes"), this old line for setting ap->descs[0].offset is now obsolete and unneeded. This should have been removed as part of aee03ea7ff98. Signed-off-by: Joanne Koong Fixes: aee03ea7ff98 ("fuse: support large folios for writethrough writes") Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit e8e21aaf5d34015901cd271053a67a62b4204526 Author: Claudiu Beznea Date: Sat Aug 9 17:44:47 2025 +0300 PCI: rcar-host: Pass proper IRQ domain to generic_handle_domain_irq() [ Upstream commit d3fee10e40a938331e2aae34348691136db31304 ] Starting with commit dd26c1a23fd5 ("PCI: rcar-host: Switch to msi_create_parent_irq_domain()"), the MSI parent IRQ domain is NULL because the object of type struct irq_domain_info passed to: msi_create_parent_irq_domain() -> irq_domain_instantiate()() -> __irq_domain_instantiate() has no reference to the parent IRQ domain. Using msi->domain->parent as an argument for generic_handle_domain_irq() leads to below error: "Unable to handle kernel NULL pointer dereference at virtual address" This error was identified while switching the upcoming RZ/G3S PCIe host controller driver to msi_create_parent_irq_domain() (which was using a similar pattern to handle MSIs (see link section)), but it was not tested on hardware using the pcie-rcar-host controller driver due to lack of hardware. Fixes: dd26c1a23fd5 ("PCI: rcar-host: Switch to msi_create_parent_irq_domain()") Signed-off-by: Claudiu Beznea [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Nam Cao Link: https://lore.kernel.org/all/20250704161410.3931884-6-claudiu.beznea.uj@bp.renesas.com Link: https://patch.msgid.link/20250809144447.3939284-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Sasha Levin commit 999d89cd998740f7bbbf802974cfbe5a796365eb Author: Christian Marangi Date: Sat Aug 23 15:44:29 2025 +0200 net: phy: as21xxx: better handle PHY HW reset on soft-reboot [ Upstream commit b4d5cd20507b252c746fa6971d82ac96f3b3e5b7 ] On soft-reboot, with a reset GPIO defined for an Aeonsemi PHY, the special match_phy_device fails to correctly identify that the PHY needs to load the firmware again. This is caused by the fact that PHY ID is read BEFORE the PHY reset GPIO (if present) is asserted, so we can be in the scenario where the phydev have the previous PHY ID (with the PHY firmware loaded) but after reset the generic AS21xxx PHY is present in the PHY ID registers. To better handle this, skip reading the PHY ID register only for the PHY that are not AS21xxx (by matching for the Aeonsemi Vendor) and always read the PHY ID for the other case to handle both firmware already loaded or an HW reset. Fixes: 830877d89edc ("net: phy: Add support for Aeonsemi AS21xxx PHYs") Signed-off-by: Christian Marangi Link: https://patch.msgid.link/20250823134431.4854-2-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ac48447b5bc4eefa5b8373e1f33470b6538f8041 Author: Christian Marangi Date: Sat Aug 23 15:44:28 2025 +0200 net: phy: introduce phy_id_compare_vendor() PHY ID helper [ Upstream commit 1abe21ef1adf0c5b6dbb5878c2fa4573df8d29fc ] Introduce phy_id_compare_vendor() PHY ID helper to compare a PHY ID with the PHY ID Vendor using the generic PHY ID Vendor mask. While at it also rework the PHY_ID_MATCH macro and move the mask to dedicated define so that PHY driver can make use of the mask if needed. Signed-off-by: Christian Marangi Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250823134431.4854-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: b4d5cd20507b ("net: phy: as21xxx: better handle PHY HW reset on soft-reboot") Signed-off-by: Sasha Levin commit d837d4c72bf94a88187fa014a8fdc9cd97ee33ce Author: Bitterblue Smith Date: Tue Aug 19 21:46:02 2025 +0300 wifi: rtw88: Use led->brightness_set_blocking for PCI too [ Upstream commit fce6fee0817b8899e0ee38ab6b98f0d7e939ceed ] Commit 26a8bf978ae9 ("wifi: rtw88: Lock rtwdev->mutex before setting the LED") made rtw_led_set() sleep, but that's not allowed. Fix it by using the brightness_set_blocking member of struct led_classdev for PCI devices too. This one is allowed to sleep. bad: scheduling from the idle thread! nix kernel: CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Tainted: G W O 6.16.0 #1-NixOS PREEMPT(voluntary) nix kernel: Tainted: [W]=WARN, [O]=OOT_MODULE nix kernel: Hardware name: [REDACTED] nix kernel: Call Trace: nix kernel: nix kernel: dump_stack_lvl+0x63/0x90 nix kernel: dequeue_task_idle+0x2d/0x50 nix kernel: __schedule+0x191/0x1310 nix kernel: ? xas_load+0x11/0xd0 nix kernel: schedule+0x2b/0xe0 nix kernel: schedule_preempt_disabled+0x19/0x30 nix kernel: __mutex_lock.constprop.0+0x3fd/0x7d0 nix kernel: rtw_led_set+0x27/0x60 [rtw_core] nix kernel: led_blink_set_nosleep+0x56/0xb0 nix kernel: led_trigger_blink+0x49/0x80 nix kernel: ? __pfx_tpt_trig_timer+0x10/0x10 [mac80211] nix kernel: call_timer_fn+0x2f/0x140 nix kernel: ? __pfx_tpt_trig_timer+0x10/0x10 [mac80211] nix kernel: __run_timers+0x21a/0x2b0 nix kernel: run_timer_softirq+0x8e/0x100 nix kernel: handle_softirqs+0xea/0x2c0 nix kernel: ? srso_alias_return_thunk+0x5/0xfbef5 nix kernel: __irq_exit_rcu+0xdc/0x100 nix kernel: sysvec_apic_timer_interrupt+0x7c/0x90 nix kernel: nix kernel: nix kernel: asm_sysvec_apic_timer_interrupt+0x1a/0x20 nix kernel: RIP: 0010:cpuidle_enter_state+0xcc/0x450 nix kernel: Code: 00 e8 08 7c 2e ff e8 d3 ee ff ff 49 89 c6 0f 1f 44 00 00 31 ff e8 c4 d1 2c ff 80 7d d7 00 0f 85 5d 02 00 00 fb 0f 1f 44 00 00 <45> 85 ff 0f 88 a0 01 00 00 49 63 f7 4c 89 f2 48 8d 0> nix kernel: RSP: 0018:ffffd579801c7e68 EFLAGS: 00000246 nix kernel: RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 nix kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 nix kernel: RBP: ffffd579801c7ea0 R08: 0000000000000000 R09: 0000000000000000 nix kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffff8eab0462a400 nix kernel: R13: ffffffff9a7d7a20 R14: 00000003aebe751d R15: 0000000000000003 nix kernel: ? cpuidle_enter_state+0xbc/0x450 nix kernel: cpuidle_enter+0x32/0x50 nix kernel: do_idle+0x1b1/0x210 nix kernel: cpu_startup_entry+0x2d/0x30 nix kernel: start_secondary+0x118/0x140 nix kernel: common_startup_64+0x13e/0x141 nix kernel: Fixes: 26a8bf978ae9 ("wifi: rtw88: Lock rtwdev->mutex before setting the LED") Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/ad8a49ef-4f2d-4a61-8292-952db9c4eb65@gmail.com Signed-off-by: Sasha Levin commit b931a0305854f375d1ac2f7b8edae4fa043b0c9f Author: Patrisious Haddad Date: Wed Aug 13 15:41:19 2025 +0300 RDMA/mlx5: Fix vport loopback forcing for MPV device [ Upstream commit 08aae7860450c89eebbc6fd4d38416e53c7a33d2 ] Previously loopback for MPV was supposed to be permanently enabled, however other driver flows were able to over-ride that configuration and disable it. Add force_lb parameter that indicates that loopback should always be enabled which prevents all other driver flows from disabling it. Fixes: a9a9e68954f2 ("RDMA/mlx5: Fix vport loopback for MPV device") Link: https://patch.msgid.link/r/cfc6b1f0f99f8100b087483cc14da6025317f901.1755088808.git.leon@kernel.org Signed-off-by: Patrisious Haddad Reviewed-by: Mark Bloch Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 60fee0f40a4fa1d4389a199315cb3a9fe4ccc0d5 Author: Or Har-Toov Date: Wed Aug 13 15:39:56 2025 +0300 RDMA/mlx5: Better estimate max_qp_wr to reflect WQE count [ Upstream commit 1a7c18c485bf17ef408d5ebb7f83e1f8ef329585 ] The mlx5 driver currently derives max_qp_wr directly from the log_max_qp_sz HCA capability: props->max_qp_wr = 1 << MLX5_CAP_GEN(mdev, log_max_qp_sz); However, this value represents the number of WQEs in units of Basic Blocks (see MLX5_SEND_WQE_BB), not actual number of WQEs. Since the size of a WQE can vary depending on transport type and features (e.g., atomic operations, UMR, LSO), the actual number of WQEs can be significantly smaller than the WQEBB count suggests. This patch introduces a conservative estimation of the worst-case WQE size — considering largest segments possible with 1 SGE and no inline data or special features. It uses this to derive a more accurate max_qp_wr value. Fixes: 938fe83c8dcb ("net/mlx5_core: New device capabilities handling") Link: https://patch.msgid.link/r/7d992c9831c997ed5c33d30973406dc2dcaf5e89.1755088725.git.leon@kernel.org Reported-by: Chuck Lever Closes: https://lore.kernel.org/all/20250506142202.GJ2260621@ziepe.ca/ Signed-off-by: Or Har-Toov Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 9440830b1d19ed7a267d3cc6842dcc082ceebc11 Author: Pin-yen Lin Date: Mon Aug 18 19:49:34 2025 +0800 HID: i2c-hid: Make elan touch controllers power on after panel is enabled [ Upstream commit cbdd16b818eef876dd2de9d503fe7397a0666cbe ] Introduce a new HID quirk to indicate that this device has to be enabled after the panel's backlight is enabled, and update the driver data for the elan devices to enable this quirk. This cannot be a I2C HID quirk because the kernel needs to acknowledge this before powering up the device and read the VID/PID. When this quirk is enabled, register .panel_enabled()/.panel_disabling() instead for the panel follower. Also rename the *panel_prepare* functions into *panel_follower* because they could be called in other situations now. Fixes: bd3cba00dcc63 ("HID: i2c-hid: elan: Add support for Elan eKTH6915 i2c-hid touchscreens") Fixes: d06651bebf99e ("HID: i2c-hid: elan: Add elan-ekth6a12nay timing") Reviewed-by: Douglas Anderson Signed-off-by: Pin-yen Lin Acked-by: Jiri Kosina Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20250818115015.2909525-2-treapking@chromium.org Signed-off-by: Sasha Levin commit 2ca40698d2d78da82b6450968ab6a8b606a90304 Author: Pin-yen Lin Date: Mon Aug 18 19:49:33 2025 +0800 drm/panel: Allow powering on panel follower after panel is enabled [ Upstream commit 2eb22214c132374e11e681c44d7879c91f67f614 ] Some touch controllers have to be powered on after the panel's backlight is enabled. To support these controllers, introduce .panel_enabled() and .panel_disabling() to panel_follower_funcs and use them to power on the device after the panel and its backlight are enabled. Signed-off-by: Pin-yen Lin Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20250818115015.2909525-1-treapking@chromium.org Stable-dep-of: cbdd16b818ee ("HID: i2c-hid: Make elan touch controllers power on after panel is enabled") Signed-off-by: Sasha Levin commit 9f427da8f87cd2b17233b6ae17ce8b04151c4bbd Author: Benjamin Mugnier Date: Mon Aug 18 15:50:58 2025 +0200 media: i2c: vd55g1: Fix duster register address [ Upstream commit ba4b8886c22a3e8c3f41c6dd373b177d7d41bcf8 ] The duster register needs to be disabled on test patterns. While the code is correctly doing so, the register address contained a typo, thus not disabling the duster correctly. Fix the typo. Fixes: e56616d7b23c ("media: i2c: Add driver for ST VD55G1 camera sensor") Signed-off-by: Benjamin Mugnier Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 8261d43c4e3f55c8569bc04cefa03bab1a901d1e Author: Bingbu Cao Date: Fri Aug 15 17:20:37 2025 +0800 media: staging/ipu7: cleanup the MMU correctly in IPU7 driver release [ Upstream commit 01a80b6649e69e4889b8521de022d3ee4bc5cb6f ] IPU7 ISYS and PSYS auxiliary devices are released after ipu7_bus_del_devices(), so driver can not reference the MMU devices from ISYS and PSYS auxiliary devices, so move the MMUs cleanup before releasing the auxiliary devices. Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver") Signed-off-by: Bingbu Cao [Sakari Ailus: Drop extra newline.] Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit d798f21be9e9c63861936ef0ca9b728bc693d54a Author: Bingbu Cao Date: Fri Aug 15 17:20:36 2025 +0800 media: staging/ipu7: Don't set name for IPU7 PCI device [ Upstream commit 8abb489f9aa181882ece7c24712ad39cbb9dab81 ] Driver better not dev_set_name() to change the PCI device name, so remove it. Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver") Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 8c5773a155b9f56b528094361e1c8e7fa4190748 Author: Bingbu Cao Date: Fri Aug 15 17:20:35 2025 +0800 media: staging/ipu7: convert to use pci_alloc_irq_vectors() API [ Upstream commit 283f7638c26c0f36e4ef5e147884e241b24fbebd ] pci_enable_msi() is a deprecated API, thus switch to use modern pci_alloc_irq_vectors(). Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver") Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a6f2c16d186ca8c2793e8ba43d14ddf7e5f7ab39 Author: Zhang Shurong Date: Tue Jun 24 16:27:24 2025 +0800 media: rj54n1cb0c: Fix memleak in rj54n1_probe() [ Upstream commit fda55673ecdabf25f5ecc61b5ab17239257ac252 ] rj54n1_probe() won't clean all the allocated resources in fail path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to prevent memleak. Fixes: f187352dcd45 ("media: i2c: Copy rj54n1cb0c soc_camera sensor driver") Signed-off-by: Zhang Shurong Reviewed-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 6f9cffca6153df00ad79d8eaac8204d433ee16a7 Author: Xaver Hugl Date: Fri Aug 22 17:28:49 2025 +0200 drm: re-allow no-op changes on non-primary planes in async flips [ Upstream commit b065bd213caf6d35b57c5089d6507d7e8598a586 ] Commit fd40a63c63a1 ("drm/atomic: Let drivers decide which planes to async flip") unintentionally disallowed no-op changes on non-primary planes that the driver doesn't allow async flips on. This broke async flips for compositors that disable the cursor plane in every async atomic commit. To fix that, change drm_atomic_set_property to again only run atomic_async_check if the plane would actually be changed by the atomic commit. Fixes: fd40a63c63a1 ("drm/atomic: Let drivers decide which planes to async flip") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4263 Signed-off-by: Xaver Hugl Reviewed-by: André Almeida Link: https://lore.kernel.org/r/20250822152849.87843-1-xaver.hugl@kde.org [andrealmeid: fix checkpatch warning] Signed-off-by: André Almeida Signed-off-by: Sasha Levin commit 373c12d1b58aa96710f64cf7ac7fc673dbdf18e8 Author: Thorsten Blum Date: Mon Aug 11 11:24:57 2025 +0200 crypto: octeontx2 - Call strscpy() with correct size argument [ Upstream commit 361fa7f813e7056cecdb24f3582ab0ad4a088e4e ] In otx2_cpt_dl_custom_egrp_create(), strscpy() is called with the length of the source string rather than the size of the destination buffer. This is fine as long as the destination buffer is larger than the source string, but we should still use the destination buffer size instead to call strscpy() as intended. And since 'tmp_buf' is a fixed-size buffer, we can safely omit the size argument and let strscpy() infer it using sizeof(). Fixes: d9d7749773e8 ("crypto: octeontx2 - add apis for custom engine groups") Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit caf720cb1573f784ccde00b9086d8b08fe59651b Author: Val Packett Date: Sun Jul 6 17:42:24 2025 -0300 drm/dp: drm_edp_backlight_set_level: do not always send 3-byte commands [ Upstream commit 4aa8961b1b9c7498550b41168a91cf1558133dd3 ] At least some panels using the LSB register are not happy with the unconditional increase of the command buffer to 3 bytes. With the BOE NE14QDM in my Dell Latitude 7455, the recent patches for luminance based brightness have introduced a regression: the brightness range stopped being contiguous and became nonsensical (it probably was interpreting the last 2 bytes of the buffer and not the first 2). Change from using a fixed sizeof() to a length variable that's only set to 3 when luminance is used. Let's leave the default as 2 even for the single-byte version, since that's how it worked before. Fixes: f2db78e37fe7 ("drm/dp: Modify drm_edp_backlight_set_level") Signed-off-by: Val Packett Tested-by: Abel Vesa Reviewed-by: Suraj Kandpal Link: https://lore.kernel.org/r/20250706204446.8918-1-val@packett.cool Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit c663f9e38ad8682f96f59a28b095a97c92f080d7 Author: Chao Yu Date: Mon Aug 18 10:09:39 2025 +0800 f2fs: fix to allow removing qf_name [ Upstream commit ff11d8701b77e303593fd86cf9ef74ef3ac4048e ] The mount behavior changed after commit d18535132523 ("f2fs: separate the options parsing and options checking"), let's fix it. [Scripts] mkfs.f2fs -f /dev/vdb mount -t f2fs -o usrquota /dev/vdb /mnt/f2fs quotacheck -uc /mnt/f2fs umount /mnt/f2fs mount -t f2fs -o usrjquota=aquota.user,jqfmt=vfsold /dev/vdb /mnt/f2fs mount|grep f2fs mount -t f2fs -o remount,usrjquota=,jqfmt=vfsold /dev/vdb /mnt/f2fs mount|grep f2fs dmesg [Before commit] mount#1: ...,quota,jqfmt=vfsold,usrjquota=aquota.user,... mount#2: ...,quota,jqfmt=vfsold,... kmsg: no output [After commit] mount#1: ...,quota,jqfmt=vfsold,usrjquota=aquota.user,... mount#2: ...,quota,jqfmt=vfsold,usrjquota=aquota.user,... kmsg: "user quota file already specified" [After patch] mount#1: ...,quota,jqfmt=vfsold,usrjquota=aquota.user,... mount#2: ...,quota,jqfmt=vfsold,... kmsg: "remove qf_name aquota.user" Fixes: d18535132523 ("f2fs: separate the options parsing and options checking") Cc: Hongbo Li Signed-off-by: Chao Yu Reviewed-by: Hongbo Li Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 3f3458852bbfe79c60f2412b8b04677b96688b6e Author: Chao Yu Date: Mon Aug 18 10:09:38 2025 +0800 f2fs: fix to avoid NULL pointer dereference in f2fs_check_quota_consistency() [ Upstream commit 930a9a6ee8e7ffa20af4bffbfc2bbd21d83bf81c ] syzbot reported a f2fs bug as below: Oops: gen[ 107.736417][ T5848] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 5848 Comm: syz-executor263 Tainted: G W 6.17.0-rc1-syzkaller-00014-g0e39a731820a #0 PREEMPT_{RT,(full)} RIP: 0010:strcmp+0x3c/0xc0 lib/string.c:284 Call Trace: f2fs_check_quota_consistency fs/f2fs/super.c:1188 [inline] f2fs_check_opt_consistency+0x1378/0x2c10 fs/f2fs/super.c:1436 __f2fs_remount fs/f2fs/super.c:2653 [inline] f2fs_reconfigure+0x482/0x1770 fs/f2fs/super.c:5297 reconfigure_super+0x224/0x890 fs/super.c:1077 do_remount fs/namespace.c:3314 [inline] path_mount+0xd18/0xfe0 fs/namespace.c:4112 do_mount fs/namespace.c:4133 [inline] __do_sys_mount fs/namespace.c:4344 [inline] __se_sys_mount+0x317/0x410 fs/namespace.c:4321 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The direct reason is f2fs_check_quota_consistency() may suffer null-ptr-deref issue in strcmp(). The bug can be reproduced w/ below scripts: mkfs.f2fs -f /dev/vdb mount -t f2fs -o usrquota /dev/vdb /mnt/f2fs quotacheck -uc /mnt/f2fs/ umount /mnt/f2fs mount -t f2fs -o usrjquota=aquota.user,jqfmt=vfsold /dev/vdb /mnt/f2fs mount -t f2fs -o remount,usrjquota=,jqfmt=vfsold /dev/vdb /mnt/f2fs umount /mnt/f2fs So, before old_qname and new_qname comparison, we need to check whether they are all valid pointers, fix it. Reported-by: syzbot+d371efea57d5aeab877b@syzkaller.appspotmail.com Fixes: d18535132523 ("f2fs: separate the options parsing and options checking") Closes: https://lore.kernel.org/linux-f2fs-devel/689ff889.050a0220.e29e5.0037.GAE@google.com Cc: Hongbo Li Signed-off-by: Chao Yu Reviewed-by: Hongbo Li Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit f162fb42ab2a6f56b8128f4c692fc3d59ca09108 Author: Chao Yu Date: Thu Aug 7 09:48:35 2025 +0800 f2fs: fix to clear unusable_cap for checkpoint=enable [ Upstream commit 2e8f4c2b2bb12fc3d40762f1bb778e95c6ddbc93 ] mount -t f2fs -o checkpoint=disable:10% /dev/vdb /mnt/f2fs/ mount -t f2fs -o remount,checkpoint=enable /dev/vdb /mnt/f2fs/ kernel log: F2FS-fs (vdb): Adjust unusable cap for checkpoint=disable = 204440 / 10% If we has assigned checkpoint=enable mount option, unusable_cap{,_perc} parameters of checkpoint=disable should be reset, then calculation and log print could be avoid in adjust_unusable_cap_perc(). Fixes: 1ae18f71cb52 ("f2fs: fix checkpoint=disable:%u%%") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit f1f565f3e94f988c1c522965c1e51c5eca5d35c5 Author: Thomas Fourier Date: Fri Jul 25 10:31:06 2025 +0200 scsi: myrs: Fix dma_alloc_coherent() error check [ Upstream commit edb35b1ffc686fd9b5a91902f034eb9f4d2c9f6b ] Check for NULL return value with dma_alloc_coherent(), because DMA address is not always set by dma_alloc_coherent() on failure. Fixes: 77266186397c ("scsi: myrs: Add Mylex RAID controller (SCSI interface)") Signed-off-by: Thomas Fourier Link: https://lore.kernel.org/r/20250725083112.43975-2-fourier.thomas@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8102fd165c220c5b0b3bfd948c225e1cc00b93c9 Author: Kuniyuki Iwashima Date: Fri Aug 15 20:16:09 2025 +0000 mptcp: Fix up subflow's memcg when CONFIG_SOCK_CGROUP_DATA=n. [ Upstream commit 68889dfd547bd8eabc5a98b58475d7b901cf5129 ] When sk_alloc() allocates a socket, mem_cgroup_sk_alloc() sets sk->sk_memcg based on the current task. MPTCP subflow socket creation is triggered from userspace or an in-kernel worker. In the latter case, sk->sk_memcg is not what we want. So, we fix it up from the parent socket's sk->sk_memcg in mptcp_attach_cgroup(). Although the code is placed under #ifdef CONFIG_MEMCG, it is buried under #ifdef CONFIG_SOCK_CGROUP_DATA. The two configs are orthogonal. If CONFIG_MEMCG is enabled without CONFIG_SOCK_CGROUP_DATA, the subflow's memory usage is not charged correctly. Let's move the code out of the wrong ifdef guard. Note that sk->sk_memcg is freed in sk_prot_free() and the parent sk holds the refcnt of memcg->css here, so we don't need to use css_tryget(). Fixes: 3764b0c5651e3 ("mptcp: attach subflow socket to parent cgroup") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Acked-by: Matthieu Baerts (NGI0) Acked-by: Shakeel Butt Link: https://patch.msgid.link/20250815201712.1745332-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bfaa56caca55811432de6d3bfdbca891c3f84e73 Author: Niklas Cassel Date: Thu Aug 14 19:32:24 2025 +0200 scsi: pm80xx: Fix pm8001_abort_task() for chip_8006 when using an expander [ Upstream commit ad70c6bc776b53e61c8db6533c833aff0ff5da8b ] For a direct attached device, attached_phy contains the local phy id. For a device behind an expander, attached_phy contains the remote phy id, not the local phy id. The pm8001_ha->phy array only contains the phys of the HBA. It does not contain the phys of the expander. Thus, you cannot use attached_phy to index the pm8001_ha->phy array, without first verifying that the device is directly attached. Use the pm80xx_get_local_phy_id() helper to make sure that we use the local phy id to index the array, regardless if the device is directly attached or not. Fixes: 869ddbdcae3b ("scsi: pm80xx: corrected SATA abort handling sequence.") Reviewed-by: Igor Pylypiv Signed-off-by: Niklas Cassel Link: https://lore.kernel.org/r/20250814173215.1765055-21-cassel@kernel.org Reviewed-by: Damien Le Moal Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c96740e80265166f9add52e2a2cd3e0fd052a10e Author: Niklas Cassel Date: Thu Aug 14 19:32:23 2025 +0200 scsi: pm80xx: Add helper function to get the local phy id [ Upstream commit b4ec98303f9fc9b1da0053106716db6a7e002d8b ] Avoid duplicated code by adding a helper to get the local phy id. No functional changes intended. Signed-off-by: Niklas Cassel Link: https://lore.kernel.org/r/20250814173215.1765055-20-cassel@kernel.org Reviewed-by: Damien Le Moal Signed-off-by: Martin K. Petersen Stable-dep-of: ad70c6bc776b ("scsi: pm80xx: Fix pm8001_abort_task() for chip_8006 when using an expander") Signed-off-by: Sasha Levin commit 8754bffc8d6a846c8fbbd698d8be2834fd781b70 Author: Niklas Cassel Date: Thu Aug 14 19:32:22 2025 +0200 scsi: pm80xx: Use dev_parent_is_expander() helper [ Upstream commit 35e388696c3f3b6bf70e2010873c5e0c1d37d579 ] Make use of the dev_parent_is_expander() helper. Signed-off-by: Niklas Cassel Link: https://lore.kernel.org/r/20250814173215.1765055-19-cassel@kernel.org Reviewed-by: Damien Le Moal Reviewed-by: John Garry Reviewed-by: Igor Pylypiv Acked-by: Jack Wang Signed-off-by: Martin K. Petersen Stable-dep-of: ad70c6bc776b ("scsi: pm80xx: Fix pm8001_abort_task() for chip_8006 when using an expander") Signed-off-by: Sasha Levin commit 7a2719b1222db910188ee1e085d319a9f1555b43 Author: Niklas Cassel Date: Thu Aug 14 19:32:18 2025 +0200 scsi: libsas: Add dev_parent_is_expander() helper [ Upstream commit e5eb72c92eb724aa14c50c7d92d1a576dd50d7e6 ] Many libsas drivers check if the parent of the device is an expander. Create a helper that the libsas drivers will use in follow up commits. Suggested-by: Damien Le Moal Signed-off-by: Niklas Cassel Link: https://lore.kernel.org/r/20250814173215.1765055-15-cassel@kernel.org Reviewed-by: Damien Le Moal Reviewed-by: John Garry Reviewed-by: Jason Yan Signed-off-by: Martin K. Petersen Stable-dep-of: ad70c6bc776b ("scsi: pm80xx: Fix pm8001_abort_task() for chip_8006 when using an expander") Signed-off-by: Sasha Levin commit 83ced3c206c292458e47c7fac54223abc7141585 Author: Niklas Cassel Date: Thu Aug 14 19:32:17 2025 +0200 scsi: pm80xx: Fix array-index-out-of-of-bounds on rmmod [ Upstream commit 251be2f6037fb7ab399f68cd7428ff274133d693 ] Since commit f7b705c238d1 ("scsi: pm80xx: Set phy_attached to zero when device is gone") UBSAN reports: UBSAN: array-index-out-of-bounds in drivers/scsi/pm8001/pm8001_sas.c:786:17 index 28 is out of range for type 'pm8001_phy [16]' on rmmod when using an expander. For a direct attached device, attached_phy contains the local phy id. For a device behind an expander, attached_phy contains the remote phy id, not the local phy id. I.e. while pm8001_ha will have pm8001_ha->chip->n_phy local phys, for a device behind an expander, attached_phy can be much larger than pm8001_ha->chip->n_phy (depending on the amount of phys of the expander). E.g. on my system pm8001_ha has 8 phys with phy ids 0-7. One of the ports has an expander connected. The expander has 31 phys with phy ids 0-30. The pm8001_ha->phy array only contains the phys of the HBA. It does not contain the phys of the expander. Thus, it is wrong to use attached_phy to index the pm8001_ha->phy array for a device behind an expander. Thus, we can only clear phy_attached for devices that are directly attached. Fixes: f7b705c238d1 ("scsi: pm80xx: Set phy_attached to zero when device is gone") Reviewed-by: Igor Pylypiv Signed-off-by: Niklas Cassel Link: https://lore.kernel.org/r/20250814173215.1765055-14-cassel@kernel.org Reviewed-by: Damien Le Moal Tested-by: Damien Le Moal Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9d1a2d33a9023400f6a7ebd1ba8b8ff082c25d9c Author: Niklas Cassel Date: Thu Aug 14 19:32:16 2025 +0200 scsi: pm80xx: Restore support for expanders [ Upstream commit eeee1086073e0058243c8554738271561bde81f1 ] Commit 0f630c58e31a ("scsi: pm80xx: Do not use libsas port ID") broke support for expanders. After the commit, devices behind an expander are no longer detected. Simply reverting the commit restores support for devices behind an expander. Instead of reverting the commit (and reintroducing a helper to get the port), get the port directly from the lldd_port pointer in struct asd_sas_port. Fixes: 0f630c58e31a ("scsi: pm80xx: Do not use libsas port ID") Suggested-by: Igor Pylypiv Reviewed-by: Igor Pylypiv Signed-off-by: Niklas Cassel Link: https://lore.kernel.org/r/20250814173215.1765055-13-cassel@kernel.org Reviewed-by: Damien Le Moal Tested-by: Damien Le Moal Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a765b393b95b1d54dc611cc3bf278e9b5222fac5 Author: Akhilesh Patil Date: Sat Aug 16 11:49:54 2025 +0530 fwctl/mlx5: Fix memory alloc/free in mlx5ctl_fw_rpc() [ Upstream commit 7f059e47326746ceebe2a984bd6124459df3b458 ] Use kvfree() to free memory allocated by kvzalloc() instead of kfree(). Avoid potential memory management issue considering kvzalloc() can internally choose to use either kmalloc() or vmalloc() based on memory request and current system memory state. Hence, use more appropriate kvfree() which automatically determines correct free method to avoid potential hard to debug memory issues. Fix this issue discovered by running spatch static analysis tool using coccinelle script - scripts/coccinelle/api/kfree_mismatch.cocci Fixes: 52929c2142041 ("fwctl/mlx5: Support for communicating with mlx5 fw") Link: https://patch.msgid.link/r/aKAjCoF9cT3VEbSE@bhairav-test.ee.iitb.ac.in Signed-off-by: Akhilesh Patil Reviewed-by: Dave Jiang Reviewed-by: Alison Schofield Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 6d32a730e9ab7a2f8200cb6e78cb45e452a8823c Author: Jorge Marques Date: Mon Aug 18 16:44:23 2025 +0200 docs: iio: ad3552r: Fix malformed code-block directive [ Upstream commit 788c57f4766bd5802af9918ea350053a91488c60 ] Missing required double dot and line break. Fixes: ede84c455659 ("docs: iio: add documentation for ad3552r driver") Signed-off-by: Jorge Marques Reviewed-by: David Lechner Link: https://patch.msgid.link/20250818-docs-ad3552r-code-block-fix-v1-1-4430cbc26676@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 9b8b9716cd554d35fa8dac9982b7cbcaed44afcd Author: Arnd Bergmann Date: Tue Jul 29 17:28:00 2025 +0200 hwrng: nomadik - add ARM_AMBA dependency [ Upstream commit efaa2d815a0e4d1c06750e587100f6f7f4ee5497 ] Compile-testing this driver is only possible when the AMBA bus driver is available in the kernel: x86_64-linux-ld: drivers/char/hw_random/nomadik-rng.o: in function `nmk_rng_remove': nomadik-rng.c:(.text+0x67): undefined reference to `amba_release_regions' x86_64-linux-ld: drivers/char/hw_random/nomadik-rng.o: in function `nmk_rng_probe': nomadik-rng.c:(.text+0xee): undefined reference to `amba_request_regions' x86_64-linux-ld: nomadik-rng.c:(.text+0x18d): undefined reference to `amba_release_regions' The was previously implied by the 'depends on ARCH_NOMADIK', but needs to be specified for the COMPILE_TEST case. Fixes: d5e93b3374e4 ("hwrng: Kconfig - Add helper dependency on COMPILE_TEST") Signed-off-by: Arnd Bergmann Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 702460e06a431e3fd1409afb1b56caf5266a3ce4 Author: Thomas Fourier Date: Mon Jul 28 14:03:30 2025 +0200 crypto: keembay - Add missing check after sg_nents_for_len() [ Upstream commit 4e53be21dd0315c00eaf40cc8f8c0facd4d9a6b2 ] sg_nents_for_len() returns an int which is negative in case of error. Fixes: 472b04444cd3 ("crypto: keembay - Add Keem Bay OCS HCU driver") Signed-off-by: Thomas Fourier Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 01e793e7d4d402c473f1a61ca5824f086693be65 Author: Srinivasan Shanmugam Date: Wed Aug 13 12:14:01 2025 +0530 drm/amd/display: Add NULL pointer checks in dc_stream cursor attribute functions [ Upstream commit bf4e4b97d0fdc66f04fc19d807e24dd8421b8f11 ] The function dc_stream_set_cursor_attributes() currently dereferences the `stream` pointer and nested members `stream->ctx->dc->current_state` without checking for NULL. All callers of these functions, such as in `dcn30_apply_idle_power_optimizations()` and `amdgpu_dm_plane_handle_cursor_update()`, already perform NULL checks before calling these functions. Fixes below: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:336 dc_stream_program_cursor_attributes() error: we previously assumed 'stream' could be null (see line 334) drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c 327 bool dc_stream_program_cursor_attributes( 328 struct dc_stream_state *stream, 329 const struct dc_cursor_attributes *attributes) 330 { 331 struct dc *dc; 332 bool reset_idle_optimizations = false; 333 334 dc = stream ? stream->ctx->dc : NULL; ^^^^^^ The old code assumed stream could be NULL. 335 --> 336 if (dc_stream_set_cursor_attributes(stream, attributes)) { ^^^^^^ The refactor added an unchecked dereference. drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c 313 bool dc_stream_set_cursor_attributes( 314 struct dc_stream_state *stream, 315 const struct dc_cursor_attributes *attributes) 316 { 317 bool result = false; 318 319 if (dc_stream_check_cursor_attributes(stream, stream->ctx->dc->current_state, attributes)) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here. This function used to check for if stream as NULL and return false at the start. Probably we should add that back. Fixes: 4465dd0e41e8 ("drm/amd/display: Refactor SubVP cursor limiting logic") Reported-by: Dan Carpenter Cc: Alex Hung Cc: Alvin Lee Cc: Ray Wu Cc: Dillon Varone Cc: Aurabindo Pillai Cc: Roman Li Cc: ChiaHsuan Chung Cc: Harry Wentland Cc: Daniel Wheeler Cc: Tom Chung Cc: Wenjing Liu Cc: Jun Lei Signed-off-by: Srinivasan Shanmugam Reviewed-by: Dillon Varone Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3e9e5c91abfd248f3d6001a9bbc222e9c2b6def0 Author: Liao Yuanhong Date: Tue Aug 12 15:50:14 2025 +0800 drm/amd/display: Remove redundant semicolons [ Upstream commit 90b810dd859c0df9db2290da1ac5842e5f031267 ] Remove unnecessary semicolons. Fixes: dda4fb85e433 ("drm/amd/display: DML changes for DCN32/321") Signed-off-by: Liao Yuanhong Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d98ac1e1a7130dda960cd355a1a0948c43939537 Author: Dan Carpenter Date: Thu Aug 7 18:54:37 2025 +0300 serial: max310x: Add error checking in probe() [ Upstream commit 672a37ba8af1f2ebcedeb94aea2cdd047f805f30 ] Check if devm_i2c_new_dummy_device() fails. Fixes: 2e1f2d9a9bdb ("serial: max310x: implement I2C support") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/aJTMPZiKqeXSE-KM@stanley.mountain Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6df3687922570f753574c40b35e83b26b32292d0 Author: Dan Carpenter Date: Fri Aug 1 20:03:35 2025 +0300 misc: pci_endpoint_test: Fix array underflow in pci_endpoint_test_ioctl() [ Upstream commit 1ad82f9db13d85667366044acdfb02009d576c5a ] Commit eefb83790a0d ("misc: pci_endpoint_test: Add doorbell test case") added NO_BAR (-1) to the pci_barno enum which, in practical terms, changes the enum from an unsigned int to a signed int. If the user passes a negative number in pci_endpoint_test_ioctl() then it results in an array underflow in pci_endpoint_test_bar(). Fixes: eefb83790a0d ("misc: pci_endpoint_test: Add doorbell test case") Signed-off-by: Dan Carpenter Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/aIzzZ4vc6ZrmM9rI@suswa Signed-off-by: Sasha Levin commit 77732c58fef6247b71493dc3997af0ec0aaad5c7 Author: Geert Uytterhoeven Date: Wed Aug 13 17:56:25 2025 +0200 PCI/pwrctrl: Fix double cleanup on devm_add_action_or_reset() failure [ Upstream commit ab81f2f79c683c94bac622aafafbe8232e547159 ] When devm_add_action_or_reset() fails, it calls the passed cleanup function. Hence the caller must not repeat that cleanup. Replace the "goto err_regulator_free" by the actual freeing, as there will never be a need again for a second user of this label. Fixes: 75996c92f4de309f ("PCI/pwrctrl: Add pwrctrl driver for PCI slots") Signed-off-by: Geert Uytterhoeven Signed-off-by: Bjorn Helgaas Tested-by: Marek Vasut # V4H Sparrow Hawk Reviewed-by: Manivannan Sadhasivam Reviewed-by: Marek Vasut Acked-by: Bartosz Golaszewski Link: https://patch.msgid.link/7b1386e6162e70e6d631c87f6323d2ab971bc1c5.1755100324.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 6efbc14fe0bcf7c58eee99c1b7bbea88844f5aca Author: Komal Bajaj Date: Thu Jul 31 14:31:32 2025 +0530 usb: misc: qcom_eud: Access EUD_MODE_MANAGER2 through secure calls [ Upstream commit c0485e864a2eaa1d5a84c71e573dd236d0e885ae ] EUD_MODE_MANAGER2 register is mapped to a memory region that is marked as read-only for operating system running at EL1, enforcing access restrictions that prohibit direct memory-mapped writes via writel(). Attempts to write to this region from HLOS can result in silent failures or memory access violations, particularly when toggling EUD (Embedded USB Debugger) state. To ensure secure register access, modify the driver to use qcom_scm_io_writel(), which routes the write operation to Qualcomm Secure Channel Monitor (SCM). SCM has the necessary permissions to access protected memory regions, enabling reliable control over EUD state. SC7280, the only user of EUD is also affected, indicating that this could never have worked on a properly fused device. Fixes: 9a1bf58ccd44 ("usb: misc: eud: Add driver support for Embedded USB Debugger(EUD)") Signed-off-by: Melody Olvera Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Souradeep Chowdhury Signed-off-by: Komal Bajaj Link: https://lore.kernel.org/r/20250731-eud_mode_manager_secure_access-v8-1-4a5dcbb79f41@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b682ce44bf20ada752a2f6ce70d5a575c56f6a35 Author: Dan Carpenter Date: Thu Aug 7 18:55:00 2025 +0300 usb: host: max3421-hcd: Fix error pointer dereference in probe cleanup [ Upstream commit 186e8f2bdba551f3ae23396caccd452d985c23e3 ] The kthread_run() function returns error pointers so the max3421_hcd->spi_thread pointer can be either error pointers or NULL. Check for both before dereferencing it. Fixes: 05dfa5c9bc37 ("usb: host: max3421-hcd: fix "spi_rd8" uses dynamic stack allocation warning") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/aJTMVAPtRe5H6jug@stanley.mountain Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0be34e72e2f4887599685f1a88d4212f540d6dfc Author: Aradhya Bhatia Date: Wed Jul 23 13:05:07 2025 +0300 drm/bridge: cdns-dsi: Fix the _atomic_check() [ Upstream commit 04864af849d9ae0dd020798f5b3632d9cf26fa03 ] Use the "adjusted_mode" for the dsi configuration check, as that is the more appropriate display_mode for validation, and later bridge enable. Also, fix the mode_valid_check parameter from false to true, as the dsi configuration check is taking place during the check-phase, and the crtc_* mode values are not expected to be populated yet. Fixes: a53d987756ea ("drm/bridge: cdns-dsi: Move DSI mode check to _atomic_check()") Signed-off-by: Aradhya Bhatia Reviewed-by: Tomi Valkeinen Tested-by: Jayesh Choudhary Reviewed-by: Devarsh Thakkar Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-1-e61cc06074c2@ideasonboard.com Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 0e55a977182ca542e7c3eb7f555d476d52405c59 Author: Jonas Karlman Date: Wed Jul 23 07:23:22 2025 +0000 phy: rockchip: naneng-combphy: Enable U3 OTG port for RK3568 [ Upstream commit 7bb14b61b7d03db770b7e8871493f5b9b2be2b79 ] The boot firmware may disable the U3 port early during boot and leave it up to the controller or PHY driver to re-enable U3 when needed. The Rockchip USBDP PHY driver currently does this for RK3576 and RK3588, something the Rockchip Naneng Combo PHY driver never does for RK3568. This may result in USB 3.0 ports being limited to only using USB 2.0 or in special cases not working at all on RK3568. Write to PIPE_GRF USB3OTGx_CON1 reg to ensure the U3 port is enabled when a PHY with PHY_TYPE_USB3 mode is used. Fixes: 7160820d742a ("phy: rockchip: add naneng combo phy for RK3568") Signed-off-by: Jonas Karlman Link: https://lore.kernel.org/r/20250723072324.2246498-1-jonas@kwiboo.se Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 478dc813ae48823c9789d71937f32fe4695ab6bf Author: Jacopo Mondi Date: Sun Aug 10 04:30:15 2025 +0300 media: zoran: Remove zoran_fh structure [ Upstream commit dc322d13cf417552b59e313e809a6da40b8b36ef ] The zoran_fh structure is a wrapper around v4l2_fh. Its usage has been mostly removed by commit 83f89a8bcbc3 ("media: zoran: convert to vb2"), but the structure stayed by mistake. It is now used in a single location, assigned from a void pointer and then recast to a void pointer, without being every accessed. Drop it. Fixes: 83f89a8bcbc3 ("media: zoran: convert to vb2") Signed-off-by: Jacopo Mondi Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit ffb344b83a0a3847dfc7e9446e4913d3c4fed379 Author: Jeongjun Park Date: Thu Jul 17 20:26:43 2025 +0900 HID: steelseries: refactor probe() and remove() [ Upstream commit a84eeacbf9325fd7f604b80f246aaba157730cd5 ] steelseries_srws1_probe() still does not use devm_kzalloc() and devm_led_classdev_register(), so there is a lot of code to safely manage heap, which reduces readability and may cause memory leaks due to minor patch mistakes in the future. Therefore, it should be changed to use devm_kzalloc() and devm_led_classdev_register() to easily and safely manage heap. Also, the current steelseries driver mainly checks sd->quriks to determine which product a specific HID device is, which is not the correct way. remove(), unlike probe(), does not receive struct hid_device_id as an argument, so it must check hdev unconditionally to know which product it is. However, since struct steelseries_device and struct steelseries_srws1_data have different structures, if SRWS1 is removed in remove(), converts hdev->dev, which is initialized to struct steelseries_srws1_data, to struct steelseries_device and uses it. This causes various memory-related bugs as completely unexpected values exist in member variables of the structure. Therefore, in order to modify probe() and remove() to work properly, Arctis 1, 9 should be added to HID_USB_DEVICE and some functions should be modified to check hdev->product when determining HID device product. Fixes: a0c76896c3fb ("HID: steelseries: Add support for Arctis 1 XBox") Signed-off-by: Jeongjun Park Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit c058133771df0bfe1973d5924ec8a1d20421003a Author: Bitterblue Smith Date: Fri Aug 1 23:08:24 2025 +0300 wifi: rtw88: Lock rtwdev->mutex before setting the LED [ Upstream commit 26a8bf978ae9cd7688af1d08bc8760674d372e22 ] Some users report that the LED blinking breaks AP mode somehow. Most likely the LED code and the dynamic mechanism are trying to access the hardware registers at the same time. Fix it by locking rtwdev->mutex before setting the LED and unlocking it after. Fixes: 4b6652bc6d8d ("wifi: rtw88: Add support for LED blinking") Closes: https://github.com/lwfinger/rtw88/issues/305 Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/ed69fa07-8678-4a40-af44-65e7b1862197@gmail.com Signed-off-by: Sasha Levin commit f24dd254bde1252220fa2c1c008f7f2b6d081f9a Author: Chia-I Wu Date: Tue Jun 10 16:58:25 2025 -0700 drm/bridge: it6505: select REGMAP_I2C [ Upstream commit 21b137f651cf9d981e22d2c60a2a8105f50a6361 ] Fix aarch64-linux-gnu-ld: drivers/gpu/drm/bridge/ite-it6505.o: in function `it6505_i2c_probe': ite-it6505.c:(.text+0x754): undefined reference to `__devm_regmap_init_i2c' Signed-off-by: Chia-I Wu Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver") Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/20250610235825.3113075-1-olvaffe@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit fa4bc117636a1f87be72555218a712de28c408a9 Author: Chao Yu Date: Wed Aug 6 14:11:06 2025 +0800 f2fs: fix to zero data after EOF for compressed file correctly [ Upstream commit 0b2cd5092139f499544c77b5107a74e5fdb3a386 ] generic/091 may fail, then it bisects to the bad commit ba8dac350faf ("f2fs: fix to zero post-eof page"). What will cause generic/091 to fail is something like below Testcase #1: 1. write 16k as compressed blocks 2. truncate to 12k 3. truncate to 20k 4. verify data in range of [12k, 16k], however data is not zero as expected Script of Testcase #1 mkfs.f2fs -f -O extra_attr,compression /dev/vdb mount -t f2fs -o compress_extension=* /dev/vdb /mnt/f2fs dd if=/dev/zero of=/mnt/f2fs/file bs=12k count=1 dd if=/dev/random of=/mnt/f2fs/file bs=4k count=1 seek=3 conv=notrunc sync truncate -s $((12*1024)) /mnt/f2fs/file truncate -s $((20*1024)) /mnt/f2fs/file dd if=/mnt/f2fs/file of=/mnt/f2fs/data bs=4k count=1 skip=3 od /mnt/f2fs/data umount /mnt/f2fs Analisys: in step 2), we will redirty all data pages from #0 to #3 in compressed cluster, and zero page #3, in step 3), f2fs_setattr() will call f2fs_zero_post_eof_page() to drop all page cache post eof, includeing dirtied page #3, in step 4) when we read data from page #3, it will decompressed cluster and extra random data to page #3, finally, we hit the non-zeroed data post eof. However, the commit ba8dac350faf ("f2fs: fix to zero post-eof page") just let the issue be reproduced easily, w/o the commit, it can reproduce this bug w/ below Testcase #2: 1. write 16k as compressed blocks 2. truncate to 8k 3. truncate to 12k 4. truncate to 20k 5. verify data in range of [12k, 16k], however data is not zero as expected Script of Testcase #2 mkfs.f2fs -f -O extra_attr,compression /dev/vdb mount -t f2fs -o compress_extension=* /dev/vdb /mnt/f2fs dd if=/dev/zero of=/mnt/f2fs/file bs=12k count=1 dd if=/dev/random of=/mnt/f2fs/file bs=4k count=1 seek=3 conv=notrunc sync truncate -s $((8*1024)) /mnt/f2fs/file truncate -s $((12*1024)) /mnt/f2fs/file truncate -s $((20*1024)) /mnt/f2fs/file echo 3 > /proc/sys/vm/drop_caches dd if=/mnt/f2fs/file of=/mnt/f2fs/data bs=4k count=1 skip=3 od /mnt/f2fs/data umount /mnt/f2fs Anlysis: in step 2), we will redirty all data pages from #0 to #3 in compressed cluster, and zero page #2 and #3, in step 3), we will truncate page #3 in page cache, in step 4), expand file size, in step 5), hit random data post eof w/ the same reason in Testcase #1. Root Cause: In f2fs_truncate_partial_cluster(), after we truncate partial data block on compressed cluster, all pages in cluster including the one post eof will be dirtied, after another tuncation, dirty page post eof will be dropped, however on-disk compressed cluster is still valid, it may include non-zero data post eof, result in exposing previous non-zero data post eof while reading. Fix: In f2fs_truncate_partial_cluster(), let change as below to fix: - call filemap_write_and_wait_range() to flush dirty page - call truncate_pagecache() to drop pages or zero partial page post eof - call f2fs_do_truncate_blocks() to truncate non-compress cluster to last valid block Fixes: 3265d3db1f16 ("f2fs: support partial truncation on compressed inode") Reported-by: Jan Prusakowski Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 57d3381dfb97ff73ddd18601017fec21cca80985 Author: Chao Yu Date: Tue Aug 5 14:29:10 2025 +0800 f2fs: fix to avoid overflow while left shift operation [ Upstream commit 0fe1c6bec54ea68ed8c987b3890f2296364e77bb ] Should cast type of folio->index from pgoff_t to loff_t to avoid overflow while left shift operation. Fixes: 3265d3db1f16 ("f2fs: support partial truncation on compressed inode") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 14b99102f9f2caa3c03c5be23b21d5763b06a8ce Author: Chao Yu Date: Thu Jul 31 14:03:38 2025 +0800 f2fs: fix condition in __allow_reserved_blocks() [ Upstream commit e75ce117905d2830976a289e718470f3230fa30a ] If reserve_root mount option is not assigned, __allow_reserved_blocks() will return false, it's not correct, fix it. Fixes: 7e65be49ed94 ("f2fs: add reserved blocks for root user") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 9e5e22c1e31011fa8bd6e05afb19a07c4de57f5d Author: Brahmajit Das Date: Mon Aug 11 14:51:25 2025 +0530 drm/radeon/r600_cs: clean up of dead code in r600_cs [ Upstream commit 260dcf5b06d519bcf27a5dfdb5c626821a55c170 ] GCC 16 enables -Werror=unused-but-set-variable= which results in build error with the following message. drivers/gpu/drm/radeon/r600_cs.c: In function ‘r600_texture_size’: drivers/gpu/drm/radeon/r600_cs.c:1411:29: error: variable ‘level’ set but not used [-Werror=unused-but-set-variable=] 1411 | unsigned offset, i, level; | ^~~~~ cc1: all warnings being treated as errors make[6]: *** [scripts/Makefile.build:287: drivers/gpu/drm/radeon/r600_cs.o] Error 1 level although is set, but in never used in the function r600_texture_size. Thus resulting in dead code and this error getting triggered. Fixes: 60b212f8ddcd ("drm/radeon: overhaul texture checking. (v3)") Acked-by: Christian König Signed-off-by: Brahmajit Das Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4d08d2afdbba1848c572453360f2b9c4f301410c Author: Dan Carpenter Date: Fri Aug 1 16:34:37 2025 +0300 PCI: xgene-msi: Return negative -EINVAL in xgene_msi_handler_setup() [ Upstream commit b26fc701a25195134ff0327709a0421767c4c7b2 ] There is a typo so we accidentally return positive EINVAL instead of negative -EINVAL. Add the missing '-' character. Fixes: 6aceb36f17ab ("PCI: xgene-msi: Restructure handler setup/teardown") Signed-off-by: Dan Carpenter Signed-off-by: Manivannan Sadhasivam Acked-by: Marc Zyngier Link: https://patch.msgid.link/aIzCbVd93ivPinne@stanley.mountain Signed-off-by: Sasha Levin commit 325ad20f85191b8198c6a8efcad7a4687698779e Author: Dan Carpenter Date: Fri Aug 1 16:34:45 2025 +0300 PCI: endpoint: pci-ep-msi: Fix NULL vs IS_ERR() check in pci_epf_write_msi_msg() [ Upstream commit 57a75fa9d56e310e883e4377205690e88c05781b ] The pci_epc_get() function returns error pointers. It never returns NULL. Update the check to match. Fixes: 1c3b002c6bf6 ("PCI: endpoint: Add RC-to-EP doorbell support using platform MSI controller") Signed-off-by: Dan Carpenter Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Link: https://patch.msgid.link/aIzCdV8jyBeql-Oa@stanley.mountain Signed-off-by: Sasha Levin commit e6ac2b8e1365d73b80f6ffd73a3f7c44a5ff896d Author: Xiang Liu Date: Thu Jul 31 14:54:50 2025 +0800 drm/amdgpu: Fix vcn v4.0.3 poison irq call trace on sriov guest [ Upstream commit 58364f01db4a155356f92cce1474761d7a0eda3d ] Sriov guest side doesn't init ras feature hence the poison irq shouldn't be put during hw fini. [25209.468816] Call Trace: [25209.468817] [25209.468818] ? srso_alias_return_thunk+0x5/0x7f [25209.468820] ? show_trace_log_lvl+0x28e/0x2ea [25209.468822] ? show_trace_log_lvl+0x28e/0x2ea [25209.468825] ? vcn_v4_0_3_hw_fini+0xaf/0xe0 [amdgpu] [25209.468936] ? show_regs.part.0+0x23/0x29 [25209.468939] ? show_regs.cold+0x8/0xd [25209.468940] ? amdgpu_irq_put+0x9e/0xc0 [amdgpu] [25209.469038] ? __warn+0x8c/0x100 [25209.469040] ? amdgpu_irq_put+0x9e/0xc0 [amdgpu] [25209.469135] ? report_bug+0xa4/0xd0 [25209.469138] ? handle_bug+0x39/0x90 [25209.469140] ? exc_invalid_op+0x19/0x70 [25209.469142] ? asm_exc_invalid_op+0x1b/0x20 [25209.469146] ? amdgpu_irq_put+0x9e/0xc0 [amdgpu] [25209.469241] vcn_v4_0_3_hw_fini+0xaf/0xe0 [amdgpu] [25209.469343] amdgpu_ip_block_hw_fini+0x34/0x61 [amdgpu] [25209.469511] amdgpu_device_fini_hw+0x3b3/0x467 [amdgpu] Fixes: 4c4a89149608 ("drm/amdgpu: Register aqua vanjaram vcn poison irq") Signed-off-by: Xiang Liu Reviewed-by: Stanley.Yang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 75d739334ea952231bd417b1d535352d0c0becf4 Author: Xiang Liu Date: Thu Jul 31 14:28:26 2025 +0800 drm/amdgpu: Fix jpeg v4.0.3 poison irq call trace on sriov guest [ Upstream commit d3d73bdb02e8cc4a1b2b721a42908504cd18ebf9 ] Sriov guest side doesn't init ras feature hence the poison irq shouldn't be put during hw fini. [25209.467154] Call Trace: [25209.467156] [25209.467158] ? srso_alias_return_thunk+0x5/0x7f [25209.467162] ? show_trace_log_lvl+0x28e/0x2ea [25209.467166] ? show_trace_log_lvl+0x28e/0x2ea [25209.467171] ? jpeg_v4_0_3_hw_fini+0x6f/0x90 [amdgpu] [25209.467300] ? show_regs.part.0+0x23/0x29 [25209.467303] ? show_regs.cold+0x8/0xd [25209.467304] ? amdgpu_irq_put+0x9e/0xc0 [amdgpu] [25209.467403] ? __warn+0x8c/0x100 [25209.467407] ? amdgpu_irq_put+0x9e/0xc0 [amdgpu] [25209.467503] ? report_bug+0xa4/0xd0 [25209.467508] ? handle_bug+0x39/0x90 [25209.467511] ? exc_invalid_op+0x19/0x70 [25209.467513] ? asm_exc_invalid_op+0x1b/0x20 [25209.467518] ? amdgpu_irq_put+0x9e/0xc0 [amdgpu] [25209.467613] ? amdgpu_irq_put+0x5f/0xc0 [amdgpu] [25209.467709] jpeg_v4_0_3_hw_fini+0x6f/0x90 [amdgpu] [25209.467805] amdgpu_ip_block_hw_fini+0x34/0x61 [amdgpu] [25209.467971] amdgpu_device_fini_hw+0x3b3/0x467 [amdgpu] Fixes: 1b2231de4163 ("drm/amdgpu: Register aqua vanjaram jpeg poison irq") Signed-off-by: Xiang Liu Reviewed-by: Stanley.Yang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit aac1e37aacf1022238ef39c68a40ffb8d417aa31 Author: Arnd Bergmann Date: Mon Jul 14 10:16:25 2025 +0200 drm/amdgpu: fix link error for !PM_SLEEP [ Upstream commit 4d22db6d070ed3934f02ed15391283f6feb258ad ] When power management is not enabled in the kernel build, the newly added hibernation changes cause a link failure: arm-linux-gnueabi-ld: drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o: in function `amdgpu_pmops_thaw': amdgpu_drv.c:(.text+0x1514): undefined reference to `pm_hibernate_is_recovering' Make the power management code in this driver conditional on CONFIG_PM and CONFIG_PM_SLEEP Fixes: 530694f54dd5 ("drm/amdgpu: do not resume device in thaw for normal hibernation") Signed-off-by: Arnd Bergmann Reviewed-by: Mario Limonciello Link: https://lore.kernel.org/r/20250714081635.4071570-1-arnd@kernel.org Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 738b014c94e90f9b944a2f87522a0efff03d6f49 Author: Brigham Campbell Date: Wed Jul 30 21:23:41 2025 -0600 drm/panel: novatek-nt35560: Fix invalid return value [ Upstream commit 125459e19ec654924e472f3ff5aeea40358dbebf ] Fix bug in nt35560_set_brightness() which causes the function to erroneously report an error. mipi_dsi_dcs_write() returns either a negative value when an error occurred or a positive number of bytes written when no error occurred. The buggy code reports an error under either condition. Fixes: 8152c2bfd780 ("drm/panel: Add driver for Sony ACX424AKP panel") Reviewed-by: Douglas Anderson Reviewed-by: Neil Armstrong Signed-off-by: Brigham Campbell Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250731032343.1258366-2-me@brighamcampbell.com Signed-off-by: Sasha Levin commit 87d0402cad3d05c434822e843a28a7b516901f34 Author: Srinivasan Shanmugam Date: Thu Jul 24 13:02:18 2025 +0530 drm/amd/display: Reduce Stack Usage by moving 'audio_output' into 'stream_res' v4 [ Upstream commit 1cf1205ef2685cf43db3785706b017d1e54e0bec ] The function `dp_retrain_link_dp_test` currently allocates a large audio_output array on the stack, causing the stack frame size to exceed the compiler limit (1080 bytes > 1024 bytes). This change prevents stack overflow issues: amdgpu/../display/dc/link/accessories/link_dp_cts.c:65:13: warning: stack frame size (1080) exceeds limit (1024) in 'dp_retrain_link_dp_test' [-Wframe-larger-than] static void dp_retrain_link_dp_test(struct dc_link *link, v2: Move audio-related data like `audio_output` is kept "per pipe" to manage the audio for that specific display pipeline/display output path (stream). (Wenjing) v3: Update in all the places where `build_audio_output` is currently called with a separate audio_output variable on the stack & wherever `audio_output` is passed to other functions `dce110_apply_single_controller_ctx_to_hw()` & `dce110_setup_audio_dto()` (like `az_configure`, `wall_dto_setup`) replace with usage of `pipe_ctx->stream_res.audio_output` to centralize audio data per pipe. v4: Remove empty lines before `build_audio_output`. (Alex) Fixes: 9c6669c2e21a ("drm/amd/display: Fix Link Override Sequencing When Switching Between DIO/HPO") Cc: Wayne Lin Cc: George Shen Cc: Michael Strauss Cc: Alvin Lee Cc: Ray Wu Cc: Wenjing Liu Cc: Harry Wentland Cc: Tom Chung Cc: Roman Li Cc: Alex Hung Cc: Aurabindo Pillai Signed-off-by: Srinivasan Shanmugam Reviewed-by: Wenjing Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit dcf6b540f2e24c4e38f08d14b3370bfa19158585 Author: Colin Ian King Date: Mon Jun 23 23:35:26 2025 +0100 drm/vmwgfx: fix missing assignment to ts [ Upstream commit 33f8f321e7aa7715ce19560801ee5223ba8b9a7d ] The assignment to ts is missing on the call to ktime_to_timespec64. Fix this by adding the missing assignment. Fixes: db6a94b26354 ("drm/vmwgfx: Implement dma_fence_ops properly") Signed-off-by: Colin Ian King Reviewed-by: Ian Forbes Signed-off-by: Zack Rusin Link: https://lore.kernel.org/r/20250623223526.281398-1-colin.i.king@gmail.com Signed-off-by: Sasha Levin commit 7844ad4a1c71f65a9c9c73f5457aa3fd1ae7b12b Author: Langyan Ye Date: Wed Jul 23 15:25:13 2025 +0800 drm/panel-edp: Add 50ms disable delay for four panels [ Upstream commit 1511d3c4d2bb30f784924a877f3cef518bb73077 ] Add 50ms disable delay for NV116WHM-N49, NV122WUM-N41, and MNC207QS1-1 to satisfy T9+T10 timing. Add 50ms disable delay for MNE007JA1-2 as well, since MNE007JA1-2 copies the timing of MNC207QS1-1. Specifically, it should be noted that the MNE007JA1-2 panel was added by someone who did not have the panel documentation, so they simply copied the timing from the MNC207QS1-1 panel. Adding an extra 50 ms of delay should be safe. Fixes: 0547692ac146 ("drm/panel-edp: Add several generic edp panels") Fixes: 50625eab3972 ("drm/edp-panel: Add panel used by T14s Gen6 Snapdragon") Signed-off-by: Langyan Ye Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20250723072513.2880369-1-yelangyan@huaqin.corp-partner.google.com Signed-off-by: Sasha Levin commit 3a6802fe3706871e89493bfd7a31772c98568ef9 Author: Dmitry Baryshkov Date: Sat Jul 19 13:58:13 2025 +0300 drm/display: bridge-connector: correct CEC bridge pointers in drm_bridge_connector_init [ Upstream commit 92e34a5241ddf4b084df20e6953275d16f156aa8 ] The bridge used in drm_bridge_connector_init() for CEC init does not correctly point to the required HDMI CEC bridge, which can lead to errors during CEC initialization. Fixes: 65a2575a68e4 ("drm/display: bridge-connector: hook in CEC notifier support") Fixes: a74288c8ded7 ("drm/display: bridge-connector: handle CEC adapters") Reported-by: Luca Ceresoli Closes: http://lore.kernel.org/r/20250718164156.194702d9@booty/ Reviewed-by: Luca Ceresoli Link: https://lore.kernel.org/r/20250719-fix-cec-bridges-v1-1-a60b1333c87d@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 9e3618dd579b0dcc9d6694d75856218a9b3cebb8 Author: Langyan Ye Date: Mon Jul 21 14:16:27 2025 +0800 drm/panel-edp: Add disable to 100ms for MNB601LS1-4 [ Upstream commit 9b3700b15cb581d748c3d46e7eb30ffced1642e8 ] For the MNB601LS1-4 panel, the T9+T10 timing does not meet the requirements of the specification, so disable is set to 100ms. Fixes: 9d8e91439fc3 ("drm/panel-edp: Add CSW MNB601LS1-4") Signed-off-by: Langyan Ye Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20250721061627.3816612-1-yelangyan@huaqin.corp-partner.google.com Signed-off-by: Sasha Levin commit c0a9f4322d50c99732f3aaf457e288b0d1a9f3bb Author: Tvrtko Ursulin Date: Wed Jul 16 09:48:17 2025 +0100 drm/sched: Fix a race in DRM_GPU_SCHED_STAT_NO_HANG test [ Upstream commit 2650bc4007c15e05f995f472b4fc89e793162bc4 ] The "skip reset" test waits for the timeout handler to run for the duration of 2 * MOCK_TIMEOUT, and because the mock scheduler opted to remove the "skip reset" flag once it fires, this gives opportunity for the timeout handler to run twice. Second time the job will be removed from the mock scheduler job list and the drm_mock_sched_advance() call in the test will fail. Fix it by making the "don't reset" flag persist for the lifetime of the job and add a new flag to verify that the code path had executed as expected. Signed-off-by: Tvrtko Ursulin Fixes: 1472e7549f84 ("drm/sched: Add new test for DRM_GPU_SCHED_STAT_NO_HANG") Cc: Maíra Canal Cc: Philipp Stanner Reviewed-by: Maíra Canal Signed-off-by: Philipp Stanner Link: https://lore.kernel.org/r/20250716084817.56797-1-tvrtko.ursulin@igalia.com Signed-off-by: Sasha Levin commit f74032d51f93114e361f17d9919d12d6036f3687 Author: Dzmitry Sankouski Date: Tue Sep 9 21:23:07 2025 +0300 mfd: max77705: Setup the core driver as an interrupt controller [ Upstream commit 605c9820e44de2da7d67acf66484136561da63a2 ] Current implementation describes only MFD's own topsys interrupts. However, max77705 has a register which indicates interrupt source, i.e. it acts as an interrupt controller. There's 4 interrupt sources in max77705: topsys, charger, fuelgauge, usb type-c manager. Setup max77705 MFD parent as an interrupt controller. Delete topsys interrupts because currently unused. Remove shared interrupt flag, because we're are an interrupt controller now, and subdevices should request interrupts from us. Fixes: c8d50f029748 ("mfd: Add new driver for MAX77705 PMIC") Signed-off-by: Dzmitry Sankouski Link: https://lore.kernel.org/r/20250909-max77705-fix_interrupt_handling-v3-1-233c5a1a20b5@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 0e5f297900660810a0824f6890de32a7809f7157 Author: Arnd Bergmann Date: Wed Sep 24 22:18:33 2025 +0200 i3c: fix big-endian FIFO transfers [ Upstream commit d6ddd9beb1a5c32acb9b80f5c2cd8b17f41371d1 ] Short MMIO transfers that are not a multiple of four bytes in size need a special case for the final bytes, however the existing implementation is not endian-safe and introduces an incorrect byteswap on big-endian kernels. This usually does not cause problems because most systems are little-endian and most transfers are multiple of four bytes long, but still needs to be fixed to avoid the extra byteswap. Change the special case for both i3c_writel_fifo() and i3c_readl_fifo() to use non-byteswapping writesl() and readsl() with a single element instead of the byteswapping writel()/readl() that are meant for individual MMIO registers. As data is copied between a FIFO and a memory buffer, the writesl()/readsl() loops are typically based on __raw_readl()/ __raw_writel(), resulting in the order of bytes in the FIFO to match the order in the buffer, regardless of the CPU endianess. The earlier versions in the dw-i3c and i3c-master-cdns had a correct implementation, but the generic version that was recently added broke it. Fixes: 733b439375b4 ("i3c: master: Add inline i3c_readl_fifo() and i3c_writel_fifo()") Cc: Manikanta Guntupalli Signed-off-by: Arnd Bergmann Reviewed-by: Jorge Marques Link: https://lore.kernel.org/r/20250924201837.3691486-1-arnd@kernel.org Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit c1ad19b5d8e23123503dcaf2d4342e1b90b923ad Author: Daniel Borkmann Date: Fri Sep 26 19:12:00 2025 +0200 bpf: Enforce expected_attach_type for tailcall compatibility [ Upstream commit 4540aed51b12bc13364149bf95f6ecef013197c0 ] Yinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object. The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls. The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT. In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible(). Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and cpu_map_bpf_prog_run*() which set up a new environment / context and therefore these situations are not prone to this issue. Fixes: 5e43f899b03a ("bpf: Check attach type at prog load time") Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Reviewed-by: Dongliang Mu Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20250926171201.188490-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 3b6a86058efc692227f47860b425bfc04d1627c5 Author: D. Wythe Date: Fri Sep 26 15:17:51 2025 +0800 libbpf: Fix error when st-prefix_ops and ops from differ btf [ Upstream commit 0cc114dc358cf8da2ca23a366e761e89a46ca277 ] When a module registers a struct_ops, the struct_ops type and its corresponding map_value type ("bpf_struct_ops_") may reside in different btf objects, here are four possible case: +--------+---------------+-------------+---------------------------------+ | |bpf_struct_ops_| xxx_ops | | +--------+---------------+-------------+---------------------------------+ | case 0 | btf_vmlinux | btf_vmlinux | be used and reg only in vmlinux | +--------+---------------+-------------+---------------------------------+ | case 1 | btf_vmlinux | mod_btf | INVALID | +--------+---------------+-------------+---------------------------------+ | case 2 | mod_btf | btf_vmlinux | reg in mod but be used both in | | | | | vmlinux and mod. | +--------+---------------+-------------+---------------------------------+ | case 3 | mod_btf | mod_btf | be used and reg only in mod | +--------+---------------+-------------+---------------------------------+ Currently we figure out the mod_btf by searching with the struct_ops type, which makes it impossible to figure out the mod_btf when the struct_ops type is in btf_vmlinux while it's corresponding map_value type is in mod_btf (case 2). The fix is to use the corresponding map_value type ("bpf_struct_ops_") as the lookup anchor instead of the struct_ops type to figure out the `btf` and `mod_btf` via find_ksym_btf_id(), and then we can locate the kern_type_id via btf__find_by_name_kind() with the `btf` we just obtained from find_ksym_btf_id(). With this change the lookup obtains the correct btf and mod_btf for case 2, preserves correct behavior for other valid cases, and still fails as expected for the invalid scenario (case 1). Fixes: 590a00888250 ("bpf: libbpf: Add STRUCT_OPS support") Signed-off-by: D. Wythe Signed-off-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20250926071751.108293-1-alibuda@linux.alibaba.com Signed-off-by: Sasha Levin commit a9e1f54d718b2eec7878422b011cf1301c4239e0 Author: Kunihiko Hayashi Date: Thu Jul 24 13:22:11 2025 +0900 i2c: designware: Add disabling clocks when probe fails [ Upstream commit c149841b069ccc6e480b00e11f35a57b5d88c7bb ] After an error occurs during probing state, dw_i2c_plat_pm_cleanup() is called. However, this function doesn't disable clocks and the clock-enable count keeps increasing. Should disable these clocks explicitly. Fixes: 7272194ed391f ("i2c-designware: add minimal support for runtime PM") Co-developed-by: Kohei Ito Signed-off-by: Kohei Ito Signed-off-by: Kunihiko Hayashi Acked-by: Jarkko Nikula Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit cc61bbea06618b2fc4317c0ec7ad5475e86c3494 Author: Kunihiko Hayashi Date: Thu Jul 24 13:22:10 2025 +0900 i2c: designware: Fix clock issue when PM is disabled [ Upstream commit 70e633bedeeb4a7290d3b1dd9d49cc2bae25a46f ] When the driver is removed, the clocks are first enabled by calling pm_runtime_get_sync(), and then disabled with pm_runtime_put_sync(). If CONFIG_PM=y, clocks for this controller are disabled when it's in the idle state. So the clocks are properly disabled when the driver exits. Othewise, the clocks are always enabled and the PM functions have no effect. Therefore, the driver exits without disabling the clocks. # cat /sys/kernel/debug/clk/clk-pclk/clk_enable_count 18 # echo 1214a000.i2c > /sys/bus/platform/drivers/i2c_designware/bind # cat /sys/kernel/debug/clk/clk-pclk/clk_enable_count 20 # echo 1214a000.i2c > /sys/bus/platform/drivers/i2c_designware/unbind # cat /sys/kernel/debug/clk/clk-pclk/clk_enable_count 20 To ensure that the clocks can be disabled correctly even without CONFIG_PM=y, should add the following fixes: - Replace with pm_runtime_put_noidle(), which only decrements the runtime PM usage count. - Call i2c_dw_prepare_clk(false) to explicitly disable the clocks. Fixes: 7272194ed391f ("i2c-designware: add minimal support for runtime PM") Co-developed-by: Kohei Ito Signed-off-by: Kohei Ito Signed-off-by: Kunihiko Hayashi Tested-by: Jarkko Nikula Acked-by: Jarkko Nikula Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit d116241569a7ab8ea3a985c9e07e7090d3a2b5f9 Author: Troy Mitchell Date: Thu Sep 25 10:02:29 2025 +0800 i2c: spacemit: ensure SDA is released after bus reset [ Upstream commit 0de61943244dec418d396633a587adca1c350b55 ] After performing a conditional bus reset, the controller must ensure that the SDA line is actually released. Previously, the reset routine only performed a single check, which could leave the bus in a locked state in some situations. This patch introduces a loop that toggles the reset cycle and issues a reset request up to SPACEMIT_BUS_RESET_CLK_CNT_MAX times, checking SDA after each attempt. If SDA is released before the maximum count, the function returns early. Otherwise, a warning is emitted. This change improves bus recovery reliability. Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC") Signed-off-by: Troy Mitchell Reviewed-by: Aurelien Jarno Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 3109d76b9592c31648573b4cf6f6538a5d152f69 Author: Troy Mitchell Date: Thu Sep 25 10:02:28 2025 +0800 i2c: spacemit: check SDA instead of SCL after bus reset [ Upstream commit db7720ef50e0103be70a3887bc66e9c909933ad9 ] After calling spacemit_i2c_conditionally_reset_bus(), the controller should ensure that the SDA line is release before proceeding. Previously, the driver checked the SCL line instead, which does not guarantee that the bus is truly idle. This patch changes the check to verify SDA. This ensures proper bus recovery and avoids potential communication errors after a conditional reset. Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC") Reviewed-by: Aurelien Jarno Signed-off-by: Troy Mitchell Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit ae5035b3752813961461c32a5f6c553b42579a63 Author: Troy Mitchell Date: Thu Sep 25 10:02:27 2025 +0800 i2c: spacemit: disable SDA glitch fix to avoid restart delay [ Upstream commit 11f40684ccd84e792eced110f0a5d3d6adbdf90d ] The K1 I2C controller has an SDA glitch fix that introduces a small delay on restart signals. While this feature can suppress glitches on SDA when SCL = 0, it also delays the restart signal, which may cause unexpected behavior in some transfers. The glitch itself does not affect normal I2C operation, because the I2C specification allows SDA to change while SCL is low. To ensure correct transmission for every message, we disable the SDA glitch fix by setting the RCR.SDA_GLITCH_NOFIX bit during initialization. This guarantees that restarts are issued promptly without unintended delays. Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC") Reviewed-by: Aurelien Jarno Signed-off-by: Troy Mitchell Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit abc9829e4c89011a0f6a94e6ffbd36daed68a4ab Author: Troy Mitchell Date: Thu Sep 25 10:02:26 2025 +0800 i2c: spacemit: remove stop function to avoid bus error [ Upstream commit 445522fe7aad6131b2747ae8c76f77266054cd84 ] Previously, STOP handling was split into two separate steps: 1) clear TB/STOP/START/ACK bits 2) issue STOP by calling spacemit_i2c_stop() This left a small window where the control register was updated twice, which can confuse the controller. While this race has not been observed with interrupt-driven transfers, it reliably causes bus errors in PIO mode. Inline the STOP sequence into the IRQ handler and ensure that control register bits are updated atomically in a single writel(). Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC") Signed-off-by: Troy Mitchell Reviewed-by: Aurelien Jarno Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit b39876f0fe8822c5222073a3c245ef32dcf215d3 Author: Troy Mitchell Date: Thu Sep 25 10:02:25 2025 +0800 i2c: spacemit: ensure bus release check runs when wait_bus_idle() fails [ Upstream commit 41d6f90ef5dc2841bdd09817c63a3d6188473b9b ] spacemit_i2c_wait_bus_idle() only returns 0 on success or a negative error code on failure. Since 'ret' can never be positive, the final 'else' branch was unreachable, and spacemit_i2c_check_bus_release() was never called. This commit guarantees we attempt to release the bus whenever waiting for an idle bus fails. Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC") Reviewed-by: Aurelien Jarno Signed-off-by: Troy Mitchell Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 96052a465dd619506da958e2c30173d84a17307c Author: Leilk.Liu Date: Sat Sep 6 16:24:06 2025 +0800 i2c: mediatek: fix potential incorrect use of I2C_MASTER_WRRD [ Upstream commit b492183652808e0f389272bf63dc836241b287ff ] The old IC does not support the I2C_MASTER_WRRD (write-then-read) function, but the current code’s handling of i2c->auto_restart may potentially lead to entering the I2C_MASTER_WRRD software flow, resulting in unexpected bugs. Instead of repurposing the auto_restart flag, add a separate flag to signal I2C_MASTER_WRRD operations. Also fix handling of msgs. If the operation (i2c->op) is I2C_MASTER_WRRD, then the msgs pointer is incremented by 2. For all other operations, msgs is simply incremented by 1. Fixes: b2ed11e224a2 ("I2C: mediatek: Add driver for MediaTek MT8173 I2C controller") Signed-off-by: Leilk.Liu Suggested-by: Chen-Yu Tsai Reviewed-by: Chen-Yu Tsai Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit ae9f0eb7f53a61a420acb48842e06093910639c4 Author: Dmitry Baryshkov Date: Mon Jul 28 15:18:24 2025 +0300 thermal/drivers/qcom/lmh: Add missing IRQ includes [ Upstream commit b50b2c53f98fcdb6957e184eb488c16502db9575 ] As reported by LKP, the Qualcomm LMH driver needs to include several IRQ-related headers, which decrlare necessary IRQ functionality. Currently driver builds on ARM64 platforms, where the headers are pulled in implicitly by other headers, but fails to build on other platforms. Fixes: 53bca371cdf7 ("thermal/drivers/qcom: Add support for LMh driver") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202507270042.KdK0KKht-lkp@intel.com/ Signed-off-by: Dmitry Baryshkov Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20250728-lmh-scm-v2-2-33bc58388ca5@oss.qualcomm.com Signed-off-by: Sasha Levin commit 4a59c96fe74afeacab8b0d40c35241115c47381d Author: Dmitry Baryshkov Date: Mon Jul 28 15:18:23 2025 +0300 thermal/drivers/qcom: Make LMH select QCOM_SCM [ Upstream commit 57eda47bd14b0c2876f2db42e757c57b7a671965 ] The QCOM_SCM symbol is not user-visible, so it makes little sense to depend on it. Make LMH driver select QCOM_SCM as all other drivers do and, as the dependecy is now correctly handled, enable || COMPILE_TEST in order to include the driver into broader set of build tests. Fixes: 9e5a4fb84230 ("thermal/drivers/qcom/lmh: make QCOM_LMH depends on QCOM_SCM") Signed-off-by: Dmitry Baryshkov Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20250728-lmh-scm-v2-1-33bc58388ca5@oss.qualcomm.com Signed-off-by: Sasha Levin commit 1939abb5f846f8e00b318c08bc2cd11a09f626ee Author: André Almeida Date: Thu Sep 25 11:14:23 2025 -0300 tools/nolibc: add stdbool.h to nolibc includes [ Upstream commit 2d965c1ae4135ed6f505661458f6dabd39488dac ] Otherwise tests compiled with only "-include nolibc.h" will fail with "error: unknown type name 'bool'", even though a stdbool.h is available from nolibc. Fixes: ae1f550efc11 ("tools/nolibc: add stdbool.h header") Fixes: f2662ec26b26 ("selftests: kselftest: Create ksft_print_dbg_msg()") Reported-by: Mark Brown Closes: https://lore.kernel.org/lkml/833f5ae5-190e-47ec-9ad9-127ad166c80c@sirena.org.uk/ Signed-off-by: André Almeida [Thomas: add Fixes tags and massage commit message a bit] Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit 50dad5e75ccb913a3da897f0c236e655984b099b Author: Vadim Pasternak Date: Mon Jan 13 10:48:58 2025 +0200 hwmon: (mlxreg-fan) Separate methods of fan setting coming from different subsystems [ Upstream commit c02e4644f8ac9c501077ef5ac53ae7fc51472d49 ] Distinct between fan speed setting request coming for hwmon and thermal subsystems. There are fields 'last_hwmon_state' and 'last_thermal_state' in the structure 'mlxreg_fan_pwm', which respectively store the cooling state set by the 'hwmon' and 'thermal' subsystem. The purpose is to make arbitration of fan speed setting. For example, if fan speed required to be not lower than some limit, such setting is to be performed through 'hwmon' subsystem, thus 'thermal' subsystem will not set fan below this limit. Currently, the 'last_thermal_state' is also be updated by 'hwmon' causing cooling state to never be set to a lower value. Eliminate update of 'last_thermal_state', when request is coming from 'hwmon' subsystem. Fixes: da74944d3a46 ("hwmon: (mlxreg-fan) Use pwm attribute for setting fan speed low limit") Signed-off-by: Vadim Pasternak Link: https://lore.kernel.org/r/20250113084859.27064-2-vadimp@nvidia.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 2b1266854e2a2a843fa30af2a5afc7e84f3a2db8 Author: Qi Xi Date: Tue Sep 9 19:29:10 2025 +0800 once: fix race by moving DO_ONCE to separate section [ Upstream commit edcc8a38b5ac1a3dbd05e113a38a25b937ebefe5 ] The commit c2c60ea37e5b ("once: use __section(".data.once")") moved DO_ONCE's ___done variable to .data.once section, which conflicts with DO_ONCE_LITE() that also uses the same section. This creates a race condition when clear_warn_once is used: Thread 1 (DO_ONCE) Thread 2 (DO_ONCE) __do_once_start read ___done (false) acquire once_lock execute func __do_once_done write ___done (true) __do_once_start release once_lock // Thread 3 clear_warn_once reset ___done read ___done (false) acquire once_lock execute func schedule once_work __do_once_done once_deferred: OK write ___done (true) static_branch_disable release once_lock schedule once_work once_deferred: BUG_ON(!static_key_enabled) DO_ONCE_LITE() in once_lite.h is used by WARN_ON_ONCE() and other warning macros. Keep its ___done flag in the .data..once section and allow resetting by clear_warn_once, as originally intended. In contrast, DO_ONCE() is used for functions like get_random_once() and relies on its ___done flag for internal synchronization. We should not reset DO_ONCE() by clear_warn_once. Fix it by isolating DO_ONCE's ___done into a separate .data..do_once section, shielding it from clear_warn_once. Fixes: c2c60ea37e5b ("once: use __section(".data.once")") Reported-by: Hulk Robot Signed-off-by: Qi Xi Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 9a47177ddbfa144ac9ab4b6bacf255514f6c09ff Author: Andrea Righi Date: Wed Sep 24 10:14:26 2025 +0200 bpf: Mark kfuncs as __noclone [ Upstream commit d4680a11e14c7baf683cb8453d91d71d2e0b9d3e ] Some distributions (e.g., CachyOS) support building the kernel with -O3, but doing so may break kfuncs, resulting in their symbols not being properly exported. In fact, with gcc -O3, some kfuncs may be optimized away despite being annotated as noinline. This happens because gcc can still clone the function during IPA optimizations, e.g., by duplicating or inlining it into callers, and then dropping the standalone symbol. This breaks BTF ID resolution since resolve_btfids relies on the presence of a global symbol for each kfunc. Currently, this is not an issue for upstream, because we don't allow building the kernel with -O3, but it may be safer to address it anyway, to prevent potential issues in the future if compilers become more aggressive with optimizations. Therefore, add __noclone to __bpf_kfunc to ensure kfuncs are never cloned and remain distinct, globally visible symbols, regardless of the optimization level. Fixes: 57e7c169cd6af ("bpf: Add __bpf_kfunc tag for marking kernel functions as kfuncs") Acked-by: David Vernet Acked-by: Yonghong Song Signed-off-by: Andrea Righi Link: https://lore.kernel.org/r/20250924081426.156934-1-arighi@nvidia.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 587f535cce0f1737d2b80fe2532cae798db606b6 Author: Arnd Bergmann Date: Fri Jun 20 13:19:35 2025 +0200 clocksource/drivers/tegra186: Avoid 64-bit division [ Upstream commit 409f8fe03e08f92bf5be96cedbcd7a3e8fb2eeaf ] The newly added function causes a build failure on 32-bit targets with older compiler version such as gcc-10: arm-linux-gnueabi-ld: drivers/clocksource/timer-tegra186.o: in function `tegra186_wdt_get_timeleft': timer-tegra186.c:(.text+0x3c2): undefined reference to `__aeabi_uldivmod' The calculation can trivially be changed to avoid the division entirely, as USEC_PER_SEC is a multiple of 5. Change both such calculation for consistency, even though gcc apparently managed to optimize the other one properly already. [dlezcano : Fixed conflict with 20250614175556.922159-2-linux@roeck-us.net ] Fixes: 28c842c8b0f5 ("clocksource/drivers/timer-tegra186: Add WDIOC_GETTIMELEFT support") Signed-off-by: Arnd Bergmann Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20250620111939.3395525-1-arnd@kernel.org Signed-off-by: Sasha Levin commit 0ba03ca70b7c34435b84979a3e5b71ecf911bfde Author: Guenter Roeck Date: Sat Jun 14 10:55:55 2025 -0700 clocksource/drivers/timer-tegra186: Avoid 64-bit divide operation [ Upstream commit 916aa36042db8ee230543ffe0d192f900e8b8c9f ] Building the driver on xtensa fails with tensa-linux-ld: drivers/clocksource/timer-tegra186.o: in function `tegra186_timer_remove': timer-tegra186.c:(.text+0x350): undefined reference to `__udivdi3' Avoid the problem by rearranging the offending code to avoid the 64-bit divide operation. Fixes: 28c842c8b0f5 ("clocksource/drivers/timer-tegra186: Add WDIOC_GETTIMELEFT support") Signed-off-by: Guenter Roeck Signed-off-by: Daniel Lezcano Reviewed-by: Jon Hunter Cc: Pohsun Su Cc: Robert Lin Link: https://lore.kernel.org/r/20250614175556.922159-1-linux@roeck-us.net Signed-off-by: Sasha Levin commit b1e7756b652cd0f3b6cebcf1c5640808650838a8 Author: Jonas Gorski Date: Mon Sep 15 20:37:19 2025 +0200 spi: fix return code when spi device has too many chipselects [ Upstream commit 188f63235bcdd207646773a8739387d85347ed76 ] Don't return a positive value when there are too many chipselects. Fixes: 4d8ff6b0991d ("spi: Add multi-cs memories support in SPI core") Signed-off-by: Jonas Gorski Link: https://patch.msgid.link/20250915183725.219473-2-jonas.gorski@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c1e019958206e89d3dc48c80f087bdd3aeb929eb Author: Zhouyi Zhou Date: Fri Sep 19 01:46:43 2025 +0000 tools/nolibc: make time_t robust if __kernel_old_time_t is missing in host headers [ Upstream commit 0ff52df6b32a6b04a7c9dfe3d7a387aff215b482 ] Commit d5094bcb5bfd ("tools/nolibc: define time_t in terms of __kernel_old_time_t") made nolibc use the kernel's time type so that `time_t` matches `timespec::tv_sec` on all ABIs (notably x32). But since __kernel_old_time_t is fairly new, notably from 2020 in commit 94c467ddb273 ("y2038: add __kernel_old_timespec and __kernel_old_time_t"), nolibc builds that rely on host headers may fail. Switch to __kernel_time_t, which is the same as __kernel_old_time_t and has existed for longer. Tested in PPC VM of Open Source Lab of Oregon State University (./tools/testing/selftests/rcutorture/bin/mkinitrd.sh) Fixes: d5094bcb5bfd ("tools/nolibc: define time_t in terms of __kernel_old_time_t") Signed-off-by: Zhouyi Zhou [Thomas: Reformat commit and its message a bit] Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit e39988a7cc0dbddb55db8773db471fd739958661 Author: Dzmitry Sankouski Date: Thu Sep 18 20:06:51 2025 +0300 power: supply: max77705_charger: rework interrupts [ Upstream commit 12a1185a06e3377af777e792ba7436862f8e528a ] Current implementation uses handle_post_irq to actually handle chgin irq. This is not how things are meant to work in regmap-irq. Remove handle_post_irq, and request a threaded interrupt for chgin. Fixes: a6a494c8e3ce ("power: supply: max77705: Add charger driver for Maxim 77705") Signed-off-by: Dzmitry Sankouski Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 9265a8385dd11ffb32feecd380502e51577e283d Author: Dzmitry Sankouski Date: Thu Sep 18 20:06:48 2025 +0300 power: supply: max77705_charger: use regfields for config registers [ Upstream commit ef1e734dbe257ce8bc42383b9977b5558f061288 ] Using regfields allows to cleanup masks and register offset definition, allowing to access register info by it's functional name. Signed-off-by: Dzmitry Sankouski Signed-off-by: Sebastian Reichel Stable-dep-of: 12a1185a06e3 ("power: supply: max77705_charger: rework interrupts") Signed-off-by: Sasha Levin commit 054aa9f7b39dfc2437d156be885e591489f0cbbb Author: Dzmitry Sankouski Date: Thu Sep 18 20:06:47 2025 +0300 power: supply: max77705_charger: refactoring: rename charger to chg [ Upstream commit d84510db8c1414b67167cdc452103c1f429588cc ] Rename struct max77705_charger_data variable to chg for consistency. Signed-off-by: Dzmitry Sankouski Signed-off-by: Sebastian Reichel Stable-dep-of: 12a1185a06e3 ("power: supply: max77705_charger: rework interrupts") Signed-off-by: Sasha Levin commit adbd84514a0edee8bd325ea2f21ad71141c80f7c Author: Dzmitry Sankouski Date: Thu Sep 18 20:06:46 2025 +0300 mfd: max77705: max77705_charger: move active discharge setting to mfd parent [ Upstream commit c24928ac69be2390cdf456d126b464af079c57ef ] Active discharge setting is a part of MFD top level i2c device, hence cannot be controlled by charger. Writing to MAX77705_PMIC_REG_MAINCTRL1 register from charger driver is a mistake. Move active discharge setting to MFD parent driver. Fixes: a6a494c8e3ce ("power: supply: max77705: Add charger driver for Maxim 77705") Signed-off-by: Dzmitry Sankouski Acked-by: Lee Jones Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 359097d70972b71fce8ed618c64d9dc7e1d97e30 Author: Rafael J. Wysocki Date: Tue Sep 9 13:44:14 2025 +0200 smp: Fix up and expand the smp_call_function_many() kerneldoc [ Upstream commit ccf09357ffef2ab472369ab9cdf470c9bc9b821a ] The smp_call_function_many() kerneldoc comment got out of sync with the function definition (bool parameter "wait" is incorrectly described as a bitmask in it), so fix it up by copying the "wait" description from the smp_call_function() kerneldoc and add information regarding the handling of the local CPU to it. Fixes: 49b3bd213a9f ("smp: Fix all kernel-doc warnings") Signed-off-by: Rafael J. Wysocki Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit a8933a19c39b4d11d97360881d0d5ef50b0dbaac Author: Thomas Weißschuh Date: Thu Sep 18 11:56:36 2025 +0200 selftests: always install UAPI headers to the correct directory [ Upstream commit 2c55daf7de07158df2ab3835321086beca25a691 ] Currently the UAPI headers are always installed into the source directory. When building out-of-tree this doesn't work, as the include path will be wrong and it dirties the source tree, leading to complains by kbuild. Make sure the 'headers' target installs the UAPI headers in the correctly. The real target directory can come from multiple places. To handle them all extract the target directory from KHDR_INCLUDES. Link: https://lore.kernel.org/r/20250918-kselftest-uapi-out-of-tree-v1-1-f4434f28adcd@linutronix.de Reported-by: Jason Gunthorpe Closes: https://lore.kernel.org/lkml/20250917153209.GA2023406@nvidia.com/ Fixes: 1a59f5d31569 ("selftests: Add headers target") Signed-off-by: Thomas Weißschuh Reviewed-by: Jason Gunthorpe Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 1e6e29aaac1a86e22ddcbe7b6e6e3ac8215a34c1 Author: Janne Grunau Date: Sun Sep 14 21:38:45 2025 +0200 arm64: dts: apple: Add ethernet0 alias for J375 template [ Upstream commit 6313115c55f44f7bee3f469c91d3de60d724eabd ] The alias is used by the boot loader to fill the MAC address. Fixes: aaa1d42a4ce3 ("arm64: dts: apple: Add J375 devicetrees") Reviewed-by: Neal Gompa Signed-off-by: Janne Grunau Reviewed-by: Sven Peter Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit d4560e6b9a45b69d84b606d367aa826a6d80f709 Author: Hector Martin Date: Sat Aug 23 11:49:46 2025 +0200 arm64: dts: apple: t600x: Add bluetooth device nodes [ Upstream commit c34e2ec6a84ea3f7a01d8fcd3073f858c4f47605 ] Add bluetooth PCIe device nodes to specify per device brcm,board-type and provide the bootloader filled "local-bd-address" and calibration data. Signed-off-by: Hector Martin Reviewed-by: Neal Gompa Reviewed-by: Sven Peter Signed-off-by: Janne Grunau Link: https://lore.kernel.org/r/20250823-apple-dt-sync-6-17-v2-3-6dc0daeb4786@jannau.net Signed-off-by: Sven Peter Stable-dep-of: 6313115c55f4 ("arm64: dts: apple: Add ethernet0 alias for J375 template") Signed-off-by: Sasha Levin commit 5e1c464f06210a27ada044a00915ac3ce2fab7db Author: Hector Martin Date: Sat Aug 23 11:49:45 2025 +0200 arm64: dts: apple: t600x: Add missing WiFi properties [ Upstream commit 3050713d84f58d2e4ba463c5474092fa6738c527 ] Add compatible and antenna-sku properties to the shared node and brcm,board-type property to individuall board device trees. Signed-off-by: Hector Martin Reviewed-by: Neal Gompa Reviewed-by: Sven Peter Signed-off-by: Janne Grunau Link: https://lore.kernel.org/r/20250823-apple-dt-sync-6-17-v2-2-6dc0daeb4786@jannau.net Signed-off-by: Sven Peter Stable-dep-of: 6313115c55f4 ("arm64: dts: apple: Add ethernet0 alias for J375 template") Signed-off-by: Sasha Levin commit f355d7a62ecb54256ccb63ef935fa003cf0f273d Author: Hengqi Chen Date: Tue Sep 16 23:26:53 2025 +0000 bpf, arm64: Call bpf_jit_binary_pack_finalize() in bpf_jit_free() [ Upstream commit 6ff4a0fa3e1b2b9756254b477fb2f0fbe04ff378 ] The current implementation seems incorrect and does NOT match the comment above, use bpf_jit_binary_pack_finalize() instead. Fixes: 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management") Acked-by: Puranjay Mohan Signed-off-by: Hengqi Chen Acked-by: Song Liu Acked-by: Puranjay Mohan Link: https://lore.kernel.org/r/20250916232653.101004-1-hengqi.chen@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 3861e7c4324aa20a632fb74eb3904114f6afdb57 Author: Eduard Zingerman Date: Tue Sep 16 14:22:50 2025 -0700 bpf: dont report verifier bug for missing bpf_scc_visit on speculative path [ Upstream commit a3c73d629ea1373af3c0c954d41fd1af555492e3 ] Syzbot generated a program that triggers a verifier_bug() call in maybe_exit_scc(). maybe_exit_scc() assumes that, when called for a state with insn_idx in some SCC, there should be an instance of struct bpf_scc_visit allocated for that SCC. Turns out the assumption does not hold for speculative execution paths. See example in the next patch. maybe_scc_exit() is called from update_branch_counts() for states that reach branch count of zero, meaning that path exploration for a particular path is finished. Path exploration can finish in one of three ways: a. Verification error is found. In this case, update_branch_counts() is called only for non-speculative paths. b. Top level BPF_EXIT is reached. Such instructions are never a part of an SCC, so compute_scc_callchain() in maybe_scc_exit() will return false, and maybe_scc_exit() will return early. c. A checkpoint is reached and matched. Checkpoints are created by is_state_visited(), which calls maybe_enter_scc(), which allocates bpf_scc_visit instances for checkpoints within SCCs. Hence, for non-speculative symbolic execution paths, the assumption still holds: if maybe_scc_exit() is called for a state within an SCC, bpf_scc_visit instance must exist. This patch removes the verifier_bug() call for speculative paths. Fixes: c9e31900b54c ("bpf: propagate read/precision marks over state graph backedges") Reported-by: syzbot+3afc814e8df1af64b653@syzkaller.appspotmail.com Closes: https://lore.kernel.org/bpf/68c85acd.050a0220.2ff435.03a4.GAE@google.com/ Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20250916212251.3490455-1-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7c9f89165e3f5d1c0b9221123b44747f5d059adb Author: Sebastian Andrzej Siewior Date: Mon Sep 15 23:26:30 2025 +0200 selftest/futex: Compile also with libnuma < 2.0.16 [ Upstream commit ed323aeda5e09fa1ab95946673939c8c425c329c ] After using numa_set_mempolicy_home_node() the test fails to compile on systems with libnuma library versioned lower than 2.0.16. In order to allow lower library version add a pkg-config related check and exclude that part of the code. Without the proper MPOL setup it can't be tested. Make a total number of tests two. The first one is the first batch and the second is the MPOL related one. The goal is to let the user know if it has been skipped due to library limitation. Remove test_futex_mpol(), it was unused and it is now complained by the compiler if the part is not compiled. Fixes: 0ecb4232fc65e ("selftests/futex: Set the home_node in futex_numa_mpol") Closes: https://lore.kernel.org/oe-lkp/202507150858.bedaf012-lkp@intel.com Reported-by: kernel test robot Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Sasha Levin commit 298daa1e9c8d914576b6e651c5fe19020e3290be Author: André Almeida Date: Mon Sep 15 23:26:28 2025 +0200 selftest/futex: Make the error check more precise for futex_numa_mpol [ Upstream commit c1c863457780adfb2e29fa9a85897179ad3903e6 ] Instead of just checking if the syscall failed as expected, check as well if the returned error code matches the expected error code. [ bigeasy: reword the commmit message ] Signed-off-by: André Almeida Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Waiman Long Stable-dep-of: ed323aeda5e0 ("selftest/futex: Compile also with libnuma < 2.0.16") Signed-off-by: Sasha Levin commit 096c5dbc5733e16570c8e9df0267e479093ea28f Author: Dan Carpenter Date: Wed Aug 27 15:00:11 2025 +0200 selftests/futex: Fix futex_wait() for 32bit ARM [ Upstream commit 237bfb76c90b184f57bb18fe35ff366c19393dc8 ] On 32bit ARM systems gcc-12 will use 32bit timestamps while gcc-13 and later will use 64bit timestamps. The problem is that SYS_futex will continue pointing at the 32bit system call. This makes the futex_wait test fail like this: waiter failed errno 110 not ok 1 futex_wake private returned: 0 Success waiter failed errno 110 not ok 2 futex_wake shared (page anon) returned: 0 Success waiter failed errno 110 not ok 3 futex_wake shared (file backed) returned: 0 Success Instead of compiling differently depending on the gcc version, use the -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 options to ensure that 64bit timestamps are used. Then use ifdefs to make SYS_futex point to the 64bit system call. Signed-off-by: Dan Carpenter Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Borislav Petkov (AMD) Reviewed-by: André Almeida Tested-by: Anders Roxell Link: https://lore.kernel.org/20250827130011.677600-6-bigeasy@linutronix.de Stable-dep-of: ed323aeda5e0 ("selftest/futex: Compile also with libnuma < 2.0.16") Signed-off-by: Sasha Levin commit 665b80380bf6d8473895f41d8dcbd0d9ae1d2f79 Author: Mikko Rapeli Date: Mon Sep 15 11:33:16 2025 +0300 mmc: select REGMAP_MMIO with MMC_LOONGSON2 [ Upstream commit 67da3f16e5f97a864a0beb4f9758d09e1890a76e ] COMPILE_TEST with MMC_LOONGSON2 failed to link due to undeclared dependency: ERROR: modpost: "__devm_regmap_init_mmio_clk" [drivers/mmc/host/loongson2-mmc.ko] undefined! Fixes: 2115772014bd ("mmc: loongson2: Add Loongson-2K SD/SDIO controller driver") Suggested-by: Arnd Bergmann Suggested-by: Binbin Zhou Signed-off-by: Mikko Rapeli Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit ad8b4fe5617e3c85fc23267f02500c4f3bf0ff69 Author: Paul Chaignon Date: Wed Sep 17 10:08:00 2025 +0200 bpf: Explicitly check accesses to bpf_sock_addr [ Upstream commit 6fabca2fc94d33cdf7ec102058983b086293395f ] Syzkaller found a kernel warning on the following sock_addr program: 0: r0 = 0 1: r2 = *(u32 *)(r1 +60) 2: exit which triggers: verifier bug: error during ctx access conversion (0) This is happening because offset 60 in bpf_sock_addr corresponds to an implicit padding of 4 bytes, right after msg_src_ip4. Access to this padding isn't rejected in sock_addr_is_valid_access and it thus later fails to convert the access. This patch fixes it by explicitly checking the various fields of bpf_sock_addr in sock_addr_is_valid_access. I checked the other ctx structures and is_valid_access functions and didn't find any other similar cases. Other cases of (properly handled) padding are covered in new tests in a subsequent patch. Fixes: 1cedee13d25a ("bpf: Hooks for sys_sendmsg") Reported-by: syzbot+136ca59d411f92e821b7@syzkaller.appspotmail.com Signed-off-by: Paul Chaignon Signed-off-by: Daniel Borkmann Acked-by: Eduard Zingerman Acked-by: Daniel Borkmann Closes: https://syzkaller.appspot.com/bug?extid=136ca59d411f92e821b7 Link: https://lore.kernel.org/bpf/b58609d9490649e76e584b0361da0abd3c2c1779.1758094761.git.paul.chaignon@gmail.com Signed-off-by: Sasha Levin commit 76c6babc71005be50207cf3c47dbd8ca6df6a3f4 Author: Yu Kuai Date: Wed Sep 17 15:55:39 2025 +0800 blk-throttle: fix throtl_data leak during disk release [ Upstream commit 336aec7b06be860477be80a4299263a2e9355789 ] Tightening the throttle activation check in blk_throtl_activated() to require both q->td presence and policy bit set introduced a memory leak during disk release: blkg_destroy_all() clears the policy bit first during queue deactivation, causing subsequent blk_throtl_exit() to skip throtl_data cleanup when blk_throtl_activated() fails policy check. Idealy we should avoid modifying blk_throtl_exit() activation check because it's intuitive that blk-throtl start from blk_throtl_init() and end in blk_throtl_exit(). However, call blk_throtl_exit() before blkg_destroy_all() will make a long term deadlock problem easier to trigger[1], hence fix this problem by checking if q->td is NULL from blk_throtl_exit(), and remove policy deactivation as well since it's useless. [1] https://lore.kernel.org/all/CAHj4cs9p9H5yx+ywsb3CMUdbqGPhM+8tuBvhW=9ADiCjAqza9w@mail.gmail.com/#t Fixes: bd9fd5be6bc0 ("blk-throttle: fix access race during throttle policy activation") Reported-by: Yi Zhang Closes: https://lore.kernel.org/all/CAHj4cs-p-ZwBEKigBj7T6hQCOo-H68-kVwCrV6ZvRovrr9Z+HA@mail.gmail.com/ Signed-off-by: Yu Kuai Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8e00ca22130eea821e83d9f68154afcbba67fa01 Author: Yi Lai Date: Tue Sep 9 16:26:19 2025 +0800 selftests/kselftest_harness: Add harness-selftest.expected to TEST_FILES [ Upstream commit 3e23a3f688b457288c37899f8898180cc231ff97 ] The harness-selftest.expected is not installed in INSTALL_PATH. Attempting to execute harness-selftest.sh shows warning: diff: ./kselftest_harness/harness-selftest.expected: No such file or directory Add harness-selftest.expected to TEST_FILES. Link: https://lore.kernel.org/r/20250909082619.584470-1-yi1.lai@intel.com Fixes: df82ffc5a3c1 ("selftests: harness: Add kselftest harness selftest") Signed-off-by: Yi Lai Reviewed-by: Thomas Weißschuh Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit c5e39246889ea75388e38d02f6478cf8e61bbc25 Author: Akhilesh Patil Date: Sun Sep 14 20:58:41 2025 +0530 selftests: watchdog: skip ping loop if WDIOF_KEEPALIVEPING not supported [ Upstream commit e8cfc524eaf3c0ed88106177edb6961e202e6716 ] Check if watchdog device supports WDIOF_KEEPALIVEPING option before entering keep_alive() ping test loop. Fix watchdog-test silently looping if ioctl based ping is not supported by the device. Exit from test in such case instead of getting stuck in loop executing failing keep_alive() watchdog_info: identity: m41t93 rtc Watchdog firmware_version: 0 Support/Status: Set timeout (in seconds) Support/Status: Watchdog triggers a management or other external alarm not a reboot Watchdog card disabled. Watchdog timeout set to 5 seconds. Watchdog ping rate set to 2 seconds. Watchdog card enabled. WDIOC_KEEPALIVE not supported by this device without this change Watchdog card disabled. Watchdog timeout set to 5 seconds. Watchdog ping rate set to 2 seconds. Watchdog card enabled. Watchdog Ticking Away! (Where test stuck here forver silently) Updated change log at commit time: Shuah Khan Link: https://lore.kernel.org/r/20250914152840.GA3047348@bhairav-test.ee.iitb.ac.in Fixes: d89d08ffd2c5 ("selftests: watchdog: Fix ioctl SET* error paths to take oneshot exit path") Signed-off-by: Akhilesh Patil Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 17fd1dd9f523f2ebbc3faa40c6844aa9378e4d5f Author: John Garry Date: Mon Sep 15 10:34:59 2025 +0000 block: fix stacking of atomic writes when atomics are not supported [ Upstream commit f2d8c5a2f79c28569edf4948b611052253b5e99a ] Atomic writes support may not always be possible when stacking devices which support atomic writes. Such as case is a different atomic write boundary between stacked devices (which is not supported). In the case that atomic writes cannot supported, the top device queue HW limits are set to 0. However, in blk_stack_atomic_writes_limits(), we detect that we are stacking the first bottom device by checking the top device atomic_write_hw_max value == 0. This get confused with the case of atomic writes not supported, above. Make the distinction between stacking the first bottom device and no atomics supported by initializing stacked device atomic_write_hw_max = UINT_MAX and checking that for stacking the first bottom device. Fixes: d7f36dc446e8 ("block: Support atomic writes limits for stacked devices") Signed-off-by: John Garry Reviewed-by: Martin K. Petersen Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8f192ff4d501c439e1d85f9d1904233868f82ad4 Author: John Garry Date: Mon Sep 15 10:34:58 2025 +0000 block: update validation of atomic writes boundary for stacked devices [ Upstream commit bfd4037296bd7e1f95394a2e3daf8e3c1796c3b3 ] In commit 63d092d1c1b1 ("block: use chunk_sectors when evaluating stacked atomic write limits"), it was missed to use a chunk sectors limit check in blk_stack_atomic_writes_boundary_head(), so update that function to do the proper check. Fixes: 63d092d1c1b1 ("block: use chunk_sectors when evaluating stacked atomic write limits") Signed-off-by: John Garry Reviewed-by: Martin K. Petersen Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3ef5e106a3441616e75565840fbf0858a3d78104 Author: Stanley Chu Date: Fri Aug 29 09:23:09 2025 +0800 i3c: master: svc: Recycle unused IBI slot [ Upstream commit 3448a934ba6f803911ac084d05a2ffce507ea6c6 ] In svc_i3c_master_handle_ibi(), an IBI slot is fetched from the pool to store the IBI payload. However, when an error condition is encountered, the function returns without recycling the IBI slot, resulting in an IBI slot leak. Fixes: c85e209b799f ("i3c: master: svc: fix ibi may not return mandatory data byte") Signed-off-by: Stanley Chu Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250829012309.3562585-3-yschu@nuvoton.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 015ec7e1e69999774073d50ca31158584d7d4561 Author: Stanley Chu Date: Fri Aug 29 09:23:08 2025 +0800 i3c: master: svc: Use manual response for IBI events [ Upstream commit a7869b0a2540fd122eccec00ae7d4243166b0a60 ] Driver wants to nack the IBI request when the target is not in the known address list. In below code, svc_i3c_master_nack_ibi() will cause undefined behavior when using AUTOIBI with auto response rule, because hw always auto ack the IBI request. switch (ibitype) { case SVC_I3C_MSTATUS_IBITYPE_IBI: dev = svc_i3c_master_dev_from_addr(master, ibiaddr); if (!dev || !is_events_enabled(master, SVC_I3C_EVENT_IBI)) svc_i3c_master_nack_ibi(master); ... break; AutoIBI has another issue that the controller doesn't quit AutoIBI state after IBIWON polling timeout when there is a SDA glitch(high->low->high). 1. SDA high->low: raising an interrupt to execute IBI ISR 2. SDA low->high 3. Driver writes an AutoIBI request 4. AutoIBI process does not start because SDA is not low 5. IBIWON polling times out 6. Controller reamins in AutoIBI state and doesn't accept EmitStop request Emitting broadcast address with IBIRESP_MANUAL avoids both issues. Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver") Signed-off-by: Stanley Chu Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250829012309.3562585-2-yschu@nuvoton.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 33ca432b4ecc58e6b327d447c38b542278bbcaad Author: Martin George Date: Tue Sep 9 16:05:09 2025 +0530 nvme-tcp: send only permitted commands for secure concat [ Upstream commit df4666a4908a6d883f628f93a3e6c80981332035 ] In addition to sending permitted commands such as connect/auth over the initial unencrypted admin connection as part of secure channel concatenation, the host also sends commands such as Property Get and Identify on the same. This is a spec violation leading to secure concat failures. Fix this by ensuring these additional commands are avoided on this connection. Fixes: 104d0e2f6222 ("nvme-fabrics: reset admin connection for secure concatenation") Signed-off-by: Martin George Reviewed-by: Hannes Reinecke Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 2cf857075bcc8e83c4aa5fe7d8f1efd6af51e04e Author: Daniel Wagner Date: Tue Sep 2 12:22:02 2025 +0200 nvmet-fcloop: call done callback even when remote port is gone [ Upstream commit 10c165af35d225eb033f4edc7fcc699a8d2d533d ] When the target port is gone, it's not possible to access any of the request resources. The function should just silently drop the response. The comment is misleading in this regard. Though it's still necessary to call the driver via the ->done callback so the driver is able to release all resources. Reported-by: Yi Zhang Closes: https://lore.kernel.org/all/CAHj4cs-OBA0WMt5f7R0dz+rR4HcEz19YLhnyGsj-MRV3jWDsPg@mail.gmail.com/ Fixes: 84eedced1c5b ("nvmet-fcloop: drop response if targetport is gone") Reviewed-by: Hannes Reinecke Signed-off-by: Daniel Wagner Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 7a619f8c869117ffed08365b377f66b7e1d941b4 Author: Daniel Wagner Date: Tue Sep 2 12:22:00 2025 +0200 nvmet-fc: move lsop put work to nvmet_fc_ls_req_op [ Upstream commit db5a5406fb7e5337a074385c7a3e53c77f2c1bd3 ] It’s possible for more than one async command to be in flight from __nvmet_fc_send_ls_req. For each command, a tgtport reference is taken. In the current code, only one put work item is queued at a time, which results in a leaked reference. To fix this, move the work item to the nvmet_fc_ls_req_op struct, which already tracks all resources related to the command. Fixes: 710c69dbaccd ("nvmet-fc: avoid deadlock on delete association path") Reviewed-by: Hannes Reinecke Signed-off-by: Daniel Wagner Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit e11fba024004411d7ff60e3a96cd009f1a8a019f Author: Martin George Date: Mon Sep 15 17:19:21 2025 +0530 nvme-auth: update bi_directional flag [ Upstream commit 6ff1bd7846680dfdaafc68d7fcd0ab7e3bcbc4a0 ] While setting chap->s2 to zero as part of secure channel concatenation, the host missed out to disable the bi_directional flag to indicate that controller authentication is not requested. Fix the same. Fixes: e88a7595b57f ("nvme-tcp: request secure channel concatenation") Signed-off-by: Martin George Reviewed-by: Hannes Reinecke Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 918a399501e28e0cc36dbd1fcfb4208f8aa1e4d1 Author: Hengqi Chen Date: Mon Sep 8 01:24:48 2025 +0000 riscv, bpf: Sign extend struct ops return values properly [ Upstream commit fd2e08128944a7679e753f920e9eda72057e427c ] The ns_bpf_qdisc selftest triggers a kernel panic: Unable to handle kernel paging request at virtual address ffffffffa38dbf58 Current test_progs pgtable: 4K pagesize, 57-bit VAs, pgdp=0x00000001109cc000 [ffffffffa38dbf58] pgd=000000011fffd801, p4d=000000011fffd401, pud=000000011fffd001, pmd=0000000000000000 Oops [#1] Modules linked in: bpf_testmod(OE) xt_conntrack nls_iso8859_1 [...] [last unloaded: bpf_testmod(OE)] CPU: 1 UID: 0 PID: 23584 Comm: test_progs Tainted: G W OE 6.17.0-rc1-g2465bb83e0b4 #1 NONE Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2024.01+dfsg-1ubuntu5.1 01/01/2024 epc : __qdisc_run+0x82/0x6f0 ra : __qdisc_run+0x6e/0x6f0 epc : ffffffff80bd5c7a ra : ffffffff80bd5c66 sp : ff2000000eecb550 gp : ffffffff82472098 tp : ff60000096895940 t0 : ffffffff8001f180 t1 : ffffffff801e1664 t2 : 0000000000000000 s0 : ff2000000eecb5d0 s1 : ff60000093a6a600 a0 : ffffffffa38dbee8 a1 : 0000000000000001 a2 : ff2000000eecb510 a3 : 0000000000000001 a4 : 0000000000000000 a5 : 0000000000000010 a6 : 0000000000000000 a7 : 0000000000735049 s2 : ffffffffa38dbee8 s3 : 0000000000000040 s4 : ff6000008bcda000 s5 : 0000000000000008 s6 : ff60000093a6a680 s7 : ff60000093a6a6f0 s8 : ff60000093a6a6ac s9 : ff60000093140000 s10: 0000000000000000 s11: ff2000000eecb9d0 t3 : 0000000000000000 t4 : 0000000000ff0000 t5 : 0000000000000000 t6 : ff60000093a6a8b6 status: 0000000200000120 badaddr: ffffffffa38dbf58 cause: 000000000000000d [] __qdisc_run+0x82/0x6f0 [] __dev_queue_xmit+0x4c0/0x1128 [] neigh_resolve_output+0xd0/0x170 [] ip6_finish_output2+0x226/0x6c8 [] ip6_finish_output+0x10c/0x2a0 [] ip6_output+0x5e/0x178 [] ip6_xmit+0x29a/0x608 [] inet6_csk_xmit+0xe6/0x140 [] __tcp_transmit_skb+0x45c/0xaa8 [] tcp_connect+0x9ce/0xd10 [] tcp_v6_connect+0x4ac/0x5e8 [] __inet_stream_connect+0xd8/0x318 [] inet_stream_connect+0x3e/0x68 [] __sys_connect_file+0x50/0x88 [] __sys_connect+0x96/0xc8 [] __riscv_sys_connect+0x20/0x30 [] do_trap_ecall_u+0x256/0x378 [] handle_exception+0x14a/0x156 Code: 892a 0363 1205 489c 8bc1 c7e5 2d03 084a 2703 080a (2783) 0709 ---[ end trace 0000000000000000 ]--- The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer is treated as a 32bit value and sign extend to 64bit in epilogue. This behavior is right for most bpf prog types but wrong for struct ops which requires RISC-V ABI. So let's sign extend struct ops return values according to the function model and RISC-V ABI([0]). [0]: https://riscv.org/wp-content/uploads/2024/12/riscv-calling.pdf Fixes: 25ad10658dc1 ("riscv, bpf: Adapt bpf trampoline to optimized riscv ftrace framework") Signed-off-by: Hengqi Chen Signed-off-by: Daniel Borkmann Tested-by: Pu Lehui Reviewed-by: Pu Lehui Link: https://lore.kernel.org/bpf/20250908012448.1695-1-hengqi.chen@gmail.com Signed-off-by: Sasha Levin commit c9bcd64427d61488ebe0ffb150e72db0816fb780 Author: Dmitry Antipov Date: Fri Sep 12 22:03:16 2025 +0200 ACPICA: Fix largest possible resource descriptor index [ Upstream commit 8ca944fea4d6d9019e01f2d6f6e766f315a9d73f ] ACPI_RESOURCE_NAME_LARGE_MAX should be equal to the last actually used resource descriptor index (ACPI_RESOURCE_NAME_CLOCK_INPUT). Otherwise 'resource_index' in 'acpi_ut_validate_resource()' may be clamped incorrectly and resulting value may issue an out-of-bounds access for 'acpi_gbl_resource_types' array. Compile tested only. Fixes: 520d4a0ee5b6 ("ACPICA: add support for ClockInput resource (v6.5)") Link: https://github.com/acpica/acpica/commit/cf00116c Link: https://marc.info/?l=linux-acpi&m=175449676131260&w=2 Signed-off-by: Dmitry Antipov Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 89718d87b377de24528cc7ff6775e113bd3b6dcb Author: Ahmed Salem Date: Fri Sep 12 21:55:35 2025 +0200 ACPICA: Apply ACPI_NONSTRING [ Upstream commit 12fd607554c4efb4856959f0e5823f541bc0e701 ] Add ACPI_NONSTRING for destination char arrays without a terminating NUL character. This is a follow-up to commit 2b82118845e0 ("ACPICA: Apply ACPI_NONSTRING") where a few more destination arrays were missed. Link: https://github.com/acpica/acpica/commit/f359e5ed Fixes: 2b82118845e0 ("ACPICA: Apply ACPI_NONSTRING") Signed-off-by: Ahmed Salem Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d248fa86d52098cda6c209f387d4223e3b0da7c5 Author: Uwe Kleine-König Date: Mon Aug 11 18:01:02 2025 +0200 pwm: tiehrpwm: Fix corner case in clock divisor calculation [ Upstream commit 00f83f0e07e44e2f1fb94b223e77ab7b18ee2d7d ] The function set_prescale_div() is responsible for calculating the clock divisor settings such that the input clock rate is divided down such that the required period length is at most 0x10000 clock ticks. If period_cycles is an integer multiple of 0x10000, the divisor period_cycles / 0x10000 is good enough. So round up in the calculation of the required divisor and compare it using >= instead of >. Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM") Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/85488616d7bfcd9c32717651d0be7e330e761b9c.1754927682.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit bde386b6c4280e9e3dfa27254b56902a7bb84674 Author: Uwe Kleine-König Date: Mon Aug 11 18:01:01 2025 +0200 pwm: tiehrpwm: Fix various off-by-one errors in duty-cycle calculation [ Upstream commit bc7ce5bfc504eea9eac0eb0215017b9fcfc62c59 ] In Up-Count Mode the timer is reset to zero one tick after it reaches TBPRD, so the period length is (TBPRD + 1) * T_TBCLK. This matches both the documentation and measurements. So the value written to the TBPRD has to be one less than the calculated period_cycles value. A complication here is that for a 100% relative duty-cycle the value written to the CMPx register has to be TBPRD + 1 which might overflow if TBPRD is 0xffff. To handle that the calculation of the AQCTLx register has to be moved to ehrpwm_pwm_config() and the edge at CTR = CMPx has to be skipped. Additionally the AQCTL_PRD register field has to be 0 because that defines the hardware's action when the maximal counter value is reached, which is (as above) one clock tick before the period's end. The period start edge has to happen when the counter is reset and so is defined in the AQCTL_ZRO field. Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM") Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/dc818c69b7cf05109ecda9ee6b0043a22de757c1.1754927682.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit bea4cf33b3b902b8bacbf7606c4588eafe4fee6e Author: Uwe Kleine-König Date: Mon Aug 11 18:01:00 2025 +0200 pwm: tiehrpwm: Make code comment in .free() more useful [ Upstream commit 878dbfc12cc52b17d79d205560c0fafcf5332b13 ] Instead of explaining trivia to everyone who can read C describe the higher-level effect of setting pc->period_cycles[pwm->hwpwm] to zero. Fixes: 01b2d4536f02 ("pwm: pwm-tiehrpwm: Fix conflicting channel period setting") Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/4c38dd119a77d7017115318a3f2c50bde62a6f21.1754927682.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit bd8875758e140a917f3d16328511b55d3e59fc86 Author: Uwe Kleine-König Date: Mon Aug 11 18:00:59 2025 +0200 pwm: tiehrpwm: Don't drop runtime PM reference in .free() [ Upstream commit 21a5e91fda50fc662ce1a12bd0aae9d103455b43 ] The pwm driver calls pm_runtime_get_sync() when the hardware becomes enabled and pm_runtime_put_sync() when it becomes disabled. The PWM's state is kept when a consumer goes away, so the call to pm_runtime_put_sync() in the .free() callback is unbalanced resulting in a non-functional device and a reference underlow for the second consumer. The easiest fix for that issue is to just not drop the runtime PM reference in .free(), so do that. Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM") Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/bbb089c4b5650cc1f7b25cf582d817543fd25384.1754927682.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit ce8f43034bb04cad3b70d12e139e24c98e39fa00 Author: Chen-Yu Tsai Date: Sat Sep 13 18:24:50 2025 +0800 arm64: dts: allwinner: t527: orangepi-4a: hook up external 32k crystal [ Upstream commit bd1ce7ef6aef4ee7349eb3124166e712693650ce ] When the board was added, its external 32.768 KHz crystal was described but not hooked up correctly. This meant the device had to fall back to the SoC's internal oscillator or divide a 32 KHz clock from the main oscillator, neither of which are accurate for the RTC. As a result the RTC clock will drift badly. Hook the crystal up to the RTC block and request the correct clock rate. Fixes: de713ccb9934 ("arm64: dts: allwinner: t527: Add OrangePi 4A board") Acked-by: Jernej Skrabec Link: https://patch.msgid.link/20250913102450.3935943-3-wens@kernel.org Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit ad8b40851e73f8130bc4915a801121648ebab574 Author: Chen-Yu Tsai Date: Sat Sep 13 18:24:49 2025 +0800 arm64: dts: allwinner: t527: avaota-a1: hook up external 32k crystal [ Upstream commit 3d5e1ba00af8dd34ae1e573c2c07e00b5ec65267 ] When the board was added, its external 32.768 KHz crystal was described but not hooked up correctly. This meant the device had to fall back to the SoC's internal oscillator or divide a 32 KHz clock from the main oscillator, neither of which are accurate for the RTC. As a result the RTC clock will drift badly. Hook the crystal up to the RTC block and request the correct clock rate. Fixes: dbe54efa32af ("arm64: dts: allwinner: a523: add Avaota-A1 router support") Acked-by: Jernej Skrabec Link: https://patch.msgid.link/20250913102450.3935943-2-wens@kernel.org Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit a5be513fc56fdcae6cdfc35234ae847e818acb82 Author: Chen-Yu Tsai Date: Sat Sep 13 18:24:48 2025 +0800 arm64: dts: allwinner: a527: cubie-a5e: Drop external 32.768 KHz crystal [ Upstream commit 9f01e1e14e71defefcb4d6823b8476a15f3cf04a ] The Radxa Cubie A5E has empty pads for a 32.768 KHz crystal, but it is left unpopulated, as per the schematics and seen on board images. A dead give away is the RTC's LOSC auto switch register showing the external OSC to be abnormal. Drop the external crystal from the device tree. It was not referenced anyway. Fixes: c2520cd032ae ("arm64: dts: allwinner: a523: add Radxa A5E support") Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20250913102450.3935943-1-wens@kernel.org Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit f969258d1626e8e6332ac7788b98a2d439d0bb65 Author: Chen-Yu Tsai Date: Wed Aug 13 01:59:27 2025 +0800 arm64: dts: allwinner: a527: cubie-a5e: Add LEDs [ Upstream commit 4184f0190792aea06553af963741a24cc9b47689 ] The Radxa Cubie A5E has a 3-color LED. The green and blue LEDs are wired to GPIO pins on the SoC, and the green one is lit by default to serve as a power indicator. The red LED is wired to the M.2 slot. Add device nodes for the green and blue LEDs. A default "heartbeat" trigger is set for the green power LED, though in practice it might be better if it were inverted, i.e. lit most of the time. Acked-by: Jernej Skrabec Link: https://patch.msgid.link/20250812175927.2199219-1-wens@kernel.org Signed-off-by: Chen-Yu Tsai Stable-dep-of: 9f01e1e14e71 ("arm64: dts: allwinner: a527: cubie-a5e: Drop external 32.768 KHz crystal") Signed-off-by: Sasha Levin commit 45d109b7b6c695b20a306d28a9c0fabd9741dc45 Author: AngeloGioacchino Del Regno Date: Thu Jul 24 10:39:14 2025 +0200 arm64: dts: mediatek: mt8516-pumpkin: Fix machine compatible [ Upstream commit ffe6a5d1dd4d4d8af0779526cf4e40522647b25f ] This devicetree contained only the SoC compatible but lacked the machine specific one: add a "mediatek,mt8516-pumpkin" compatible to the list to fix dtbs_check warnings. Fixes: 9983822c8cf9 ("arm64: dts: mediatek: add pumpkin board dts") Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Fei Shao Link: https://lore.kernel.org/r/20250724083914.61351-39-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit d72890c2984587dc1eeb208815ed91eed523701a Author: AngeloGioacchino Del Regno Date: Thu Jul 24 10:39:13 2025 +0200 arm64: dts: mediatek: mt8395-kontron-i1200: Fix MT6360 regulator nodes [ Upstream commit 09a1e9c973973aff26e66a5673c19442d91b9e3d ] All of the MT6360 regulator nodes were wrong and would not probe because the regulator names are supposed to be lower case, but they are upper case in this devicetree. Change all nodes to be lower case to get working regulators. Fixes: 94aaf79a6af5 ("arm64: dts: mediatek: add Kontron 3.5"-SBC-i1200") Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Fei Shao Link: https://lore.kernel.org/r/20250724083914.61351-38-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 5c44f000fdb9aa4eb0e7f14e4d0c0e97124eb856 Author: AngeloGioacchino Del Regno Date: Thu Jul 24 10:38:59 2025 +0200 arm64: dts: mediatek: mt7986a: Fix PCI-Express T-PHY node address [ Upstream commit 6b3fff78c13f1a2ba5a355a101fa1ca0a13054ad ] The PCIe TPHY is under the soc bus, which provides MMIO, and all nodes under that must use the bus, otherwise those would clearly be out of place. Add ranges to the PCIe tphy and assign the address to the main node to silence a dtbs_check warning, and fix the children to use the MMIO range of t-phy. Fixes: 963c3b0c47ec ("arm64: dts: mediatek: fix t-phy unit name") Fixes: 918aed7abd2d ("arm64: dts: mt7986: add pcie related device nodes") Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Fei Shao Link: https://lore.kernel.org/r/20250724083914.61351-24-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit c5fb0da0b2a6b1e0a62433d5e8236d78a9d43b3b Author: AngeloGioacchino Del Regno Date: Thu Jul 24 10:38:56 2025 +0200 arm64: dts: mediatek: mt6795-xperia-m5: Fix mmc0 latch-ck value [ Upstream commit 236681fb64102f25ed11df55999e6985c1bc2f7d ] Change the latch-ck value from 0x14 to 4: as only bits [0-3] are actually used, the final value that gets written to the register field for DAT_LATCH_CK_SEL is just 0x4. This also fixes dtbs_check warnings. Fixes: 5a65dcccf483 ("arm64: dts: mediatek: mt6795-xperia-m5: Add eMMC, MicroSD slot, SDIO") Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20250724083914.61351-21-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 0d0dd5484be4415f54760c71989b011ebb3f45f8 Author: Bean Huo Date: Thu Sep 11 23:06:05 2025 +0200 mmc: core: Fix variable shadowing in mmc_route_rpmb_frames() [ Upstream commit 072755cca7e743c28a273fcb69b0e826109473d7 ] Rename the inner 'frm' variable to 'resp_frm' in the write path of mmc_route_rpmb_frames() to avoid shadowing the outer 'frm' variable. The function declares 'frm' at function scope pointing to the request frame, but then redeclares another 'frm' variable inside the write block pointing to the response frame. This shadowing makes the code confusing and error-prone. Using 'resp_frm' for the response frame makes the distinction clear and improves code readability. Fixes: 7852028a35f0 ("mmc: block: register RPMB partition with the RPMB subsystem") Reviewed-by: Avri Altman Reviewed-by: Jens Wiklander Signed-off-by: Bean Huo Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit d61d2f55ac7458ab9f1d63366ab2646777410fcf Author: AngeloGioacchino Del Regno Date: Thu Jul 24 10:38:52 2025 +0200 arm64: dts: mediatek: mt6331: Fix pmic, regulators, rtc, keys node names [ Upstream commit 98967109c9c0e2de4140827628c63f96314099ab ] The node names for "pmic", "regulators", "rtc", and "keys" are dictated by the PMIC MFD binding: change those to adhere to it. Fixes: aef783f3e0ca ("arm64: dts: mediatek: Add MT6331 PMIC devicetree") Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Fei Shao Link: https://lore.kernel.org/r/20250724083914.61351-17-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 09fb759de4202bd3e4b6ac272d306e47b824995f Author: Biju Das Date: Sun Aug 17 15:51:30 2025 +0100 arm64: dts: renesas: r9a09g047e57-smarc: Fix gpio key's pin control node [ Upstream commit 3e5df910b592d47734b6dcd03d57498d4766bf6c ] Adding pin control node to the child won't parse the pins during driver bind. Fix the issue by moving it to parent node. This issue is observed while adding Schmitt input enable for PS0 pin on later patch. Currently the reset value of the PIN is set to NMI function and hence there is no breakage. Fixes: 9e95446b0cf9 ("arm64: dts: renesas: r9a09g047e57-smarc: Add gpio keys") Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20250817145135.166591-2-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 2907a08e3f0fee3e5bf4146dfaf7cb708c6983e0 Author: Akashdeep Kaur Date: Tue Sep 9 10:11:08 2025 +0530 arm64: dts: ti: k3-pinctrl: Fix the bug in existing macros [ Upstream commit 2e79ee4d64e9ba4a3fc90e91dfd715407efab16d ] Currently, DS_IO_OVERRIDE_EN_SHIFT macro is not defined anywhere but used for defining other macro. Replace this undefined macro with valid macro. Rename the existing macro to reflect the actual behavior. Fixes: 325aa0f6b36e ("arm64: dts: ti: k3-pinctrl: Introduce deep sleep macros") Reviewed-by: Kendall Willis Reviewed-by: Dhruva Gole Reviewed-by: Vignesh Raghavendra Signed-off-by: Akashdeep Kaur Fixes: 325aa0f6b36e ("arm64: dts: ti: k3-pinctrl: Introduce deep sleep macros") Link: https://patch.msgid.link/20250909044108.2541534-5-a-kaur@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit e7b12aaa3a842a736e992c5655015f6aa7518b57 Author: Chen-Yu Tsai Date: Tue Aug 12 17:01:34 2025 +0800 arm64: dts: mediatek: mt8186-tentacruel: Fix touchscreen model [ Upstream commit 0370911565869384f19b35ea9e71ee7a57b48a33 ] The touchscreen controller used with the original Krabby design is the Elan eKTH6918, which is in the same family as eKTH6915, but supporting a larger screen size with more sense lines. OTOH, the touchscreen controller that actually shipped on the Tentacruel devices is the Elan eKTH6A12NAY. A compatible string was added for it specifically because it has different power sequencing timings. Fix up the touchscreen nodes for both these. This also includes adding a previously missing reset line. Also add "no-reset-on-power-off" since the power is always on, and putting it in reset would consume more power. Fixes: 8855d01fb81f ("arm64: dts: mediatek: Add MT8186 Krabby platform based Tentacruel / Tentacool") Signed-off-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20250812090135.3310374-1-wenst@chromium.org Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 166332c2a067d1b96faafa2dfa94731f490b4fb5 Author: Chen-Yu Tsai Date: Tue Jun 10 14:34:30 2025 +0800 arm64: dts: mediatek: mt8188: Change efuse fallback compatible to mt8186 [ Upstream commit c881d1c37b2c159d908203dba5c4920bc776046f ] The efuse block in the MT8188 contains the GPU speed bin cell, and like the MT8186 one, has the same conversion scheme to work with the GPU OPP binding. This was reflected in a corresponding change to the efuse DT binding. Change the fallback compatible of the MT8188's efuse block from the generic one to the MT8186 one. This also makes GPU DVFS work properly. Fixes: d39aacd1021a ("arm64: dts: mediatek: mt8188: add lvts definitions") Fixes: 50e7592cb696 ("arm64: dts: mediatek: mt8188: Add GPU speed bin NVMEM cells") Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20250610063431.2955757-3-wenst@chromium.org Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 6b4eacd05f6b96dabc2d26b753f2bc4e39094f82 Author: Beleswar Padhi Date: Mon Sep 8 19:58:14 2025 +0530 Revert "arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations" [ Upstream commit 932424a925ce79cbed0a93d36c5f1b69a0128de1 ] This reverts commit 1a314099b7559690fe23cdf3300dfff6e830ecb1. The C6x carveouts are reversed intentionally. This is due to the requirement to keep the DMA memory region as non-cached, however the minimum granular cache region for C6x is 16MB. So, C66x_0 marks the entire C66x_1 16MB memory carveouts as non-cached, and uses the DMA memory region of C66x_1 as its own, and vice-versa. This was also called out in the original commit which introduced these reversed carveouts: "The minimum granularity on the Cache settings on C66x DSP cores is 16MB, so the DMA memory regions are chosen such that they are in separate 16MB regions for each DSP, while reserving a total of 16 MB for each DSP and not changing the overall DSP remoteproc carveouts." Fixes: 1a314099b755 ("arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations") Signed-off-by: Beleswar Padhi Acked-by: Andrew Davis Link: https://patch.msgid.link/20250908142826.1828676-23-b-padhi@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 7a4348825d86b895572fe996df0c023de5243bff Author: Beleswar Padhi Date: Mon Sep 8 19:58:13 2025 +0530 Revert "arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations" [ Upstream commit 79a1778c7819c8491cdbdc1f7e46d478cb84d5cf ] This reverts commit 9f3814a7c06b7c7296cf8c1622078ad71820454b. The C6x carveouts are reversed intentionally. This is due to the requirement to keep the DMA memory region as non-cached, however the minimum granular cache region for C6x is 16MB. So, C66x_0 marks the entire C66x_1 16MB memory carveouts as non-cached, and uses the DMA memory region of C66x_1 as its own, and vice-versa. This was also called out in the original commit which introduced these reversed carveouts: "The minimum granularity on the Cache settings on C66x DSP cores is 16MB, so the DMA memory regions are chosen such that they are in separate 16MB regions for each DSP, while reserving a total of 16 MB for each DSP and not changing the overall DSP remoteproc carveouts." Fixes: 9f3814a7c06b ("arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations") Signed-off-by: Beleswar Padhi Acked-by: Andrew Davis Link: https://patch.msgid.link/20250908142826.1828676-22-b-padhi@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit f0bea70a5c56c82a652f32e5f5be6182079e6038 Author: Beleswar Padhi Date: Mon Sep 8 19:58:05 2025 +0530 arm64: dts: ti: k3: Rename rproc reserved-mem nodes to 'memory@addr' [ Upstream commit aee0678597c63e5427e91b2e49a6c5ed4951f277 ] Currently, the reserved memory carveouts used by remote processors are named like 'rproc-name--memory-region@addr'. While it is descriptive, the node label already serves that purpose. Rename reserved memory nodes to generic 'memory@addr' to align with the device tree specifications. This is done for all TI K3 based boards. Signed-off-by: Beleswar Padhi Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20250908142826.1828676-14-b-padhi@ti.com Signed-off-by: Nishanth Menon Stable-dep-of: 79a1778c7819 ("Revert "arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations"") Signed-off-by: Sasha Levin commit ef700e0c3e230e4bfd4caa0dc58ac073bb561d28 Author: Beleswar Padhi Date: Sat Aug 23 22:01:11 2025 +0530 arm64: dts: ti: k3-j742s2-mcu-wakeup: Override firmware-name for MCU R5F cores [ Upstream commit 00c8fdc2809f05422d919809106f54c23de3cba3 ] The J742S2 SoC reuses the common k3-j784s4-j742s2-mcu-wakeup-common.dtsi for its MCU domain, but it does not override the firmware-name property for its R5F cores. This causes the wrong firmware binaries to be referenced. Introduce a new k3-j742s2-mcu-wakeup.dtsi file to override the firmware-name property with correct names for J742s2. Fixes: 38fd90a3e1ac ("arm64: dts: ti: Introduce J742S2 SoC family") Signed-off-by: Beleswar Padhi Reviewed-by: Udit Kumar Link: https://patch.msgid.link/20250823163111.2237199-1-b-padhi@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit db184d4fe0caf060f80eca143e79e8793696e677 Author: Sebastian Reichel Date: Wed Sep 10 15:54:51 2025 +0200 arm64: dts: rockchip: Fix network on rk3576 evb1 board [ Upstream commit 843367c7ed196bd0806c8776cba108aaf6923b82 ] The RK3576 EVB1 has a RTL8211F PHY for each GMAC interface with a dedicated reset line and the 25MHz clock provided by the SoC. The current description results in non-working Ethernet as the clocks are only enabled by the PHY driver, but probing the right PHY driver currently requires that the PHY ID register can be read for automatic identification. This fixes up the network description to get the network functionality working reliably and cleans up usage of deprecated DT properties while at it. Fixes: f135a1a07352 ("arm64: dts: rockchip: Add rk3576 evb1 board") Signed-off-by: Sebastian Reichel Link: https://lore.kernel.org/r/20250910-rk3576-evb-network-v1-1-68ed4df272a2@collabora.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit a89446507960e35fb2a9abfb59a5bc090021998c Author: Alexey Charkov Date: Wed Aug 13 00:30:24 2025 +0400 arm64: dts: rockchip: Add WiFi on rk3576-evb1-v10 [ Upstream commit ebf8183ad08afc4fcabe1379a5098354829d950d ] Add device tree nodes to enable the onboard Ampak AP6275P WiFi chip connected over a PCIe link on Rockchip RK3576 EVB1. It takes an external 32 kHz clock from the RTC chip and requires the WIFI_REG_ON signal to be enabled before the bus is enumerated to initialize properly. Tested-by: Pavel Zhovner Signed-off-by: Alexey Charkov Link: https://lore.kernel.org/r/20250813-evb1-rtcwifibt-v1-2-d13c83422971@gmail.com Signed-off-by: Heiko Stuebner Stable-dep-of: 843367c7ed19 ("arm64: dts: rockchip: Fix network on rk3576 evb1 board") Signed-off-by: Sasha Levin commit eff044d4ca10d226ebb4818e3661bb343a2b218c Author: Alexey Charkov Date: Wed Aug 13 00:30:23 2025 +0400 arm64: dts: rockchip: Add RTC on rk3576-evb1-v10 [ Upstream commit 0adaae77862932a19cc14c086d7fd15ec0ef7703 ] Add the I2C connected RTC chip to the Rockchip RK3576 EVB1 board. Apart from the realtime clock functionality, it also provides a 32 kHz clock source for the onboard WiFi chip. Tested-by: Pavel Zhovner Signed-off-by: Alexey Charkov Link: https://lore.kernel.org/r/20250813-evb1-rtcwifibt-v1-1-d13c83422971@gmail.com Signed-off-by: Heiko Stuebner Stable-dep-of: 843367c7ed19 ("arm64: dts: rockchip: Fix network on rk3576 evb1 board") Signed-off-by: Sasha Levin commit 9938a66f65e0a59bb94061367a41e45311fd2f7c Author: Chen-Yu Tsai Date: Tue Sep 9 02:10:57 2025 +0800 arm64: dts: allwinner: t527: avaota-a1: Add ethernet PHY reset setting [ Upstream commit 8dc3f973b2ff7ea19f7637983c11b005daa8fe45 ] The external Ethernet PHY has a reset pin that is connected to the SoC. It is missing from the original submission. Add it to complete the description. Fixes: c6800f15998b ("arm64: dts: allwinner: t527: add EMAC0 to Avaota-A1 board") Acked-by: Jernej Skrabec Link: https://patch.msgid.link/20250908181059.1785605-9-wens@kernel.org Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 405711bd96927db122ab6b6af978a4398f3d7b40 Author: Chen-Yu Tsai Date: Tue Sep 9 02:10:55 2025 +0800 arm64: dts: allwinner: a527: cubie-a5e: Add ethernet PHY reset setting [ Upstream commit a15f095b590bcc1968fbf2ced8fe87fbd8d012e0 ] The external Ethernet PHY has a reset pin that is connected to the SoC. It is missing from the original submission. Add it to complete the description. Fixes: acca163f3f51 ("arm64: dts: allwinner: a527: add EMAC0 to Radxa A5E board") Acked-by: Jernej Skrabec Link: https://patch.msgid.link/20250908181059.1785605-7-wens@kernel.org Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 8d26acf8477174d8ef690eb6affe13a630f586ae Author: Yu Kuai Date: Wed Sep 10 16:04:43 2025 +0800 blk-mq: fix potential deadlock while nr_requests grown [ Upstream commit b86433721f46d934940528f28d49c1dedb690df1 ] Allocate and free sched_tags while queue is freezed can deadlock[1], this is a long term problem, hence allocate memory before freezing queue and free memory after queue is unfreezed. [1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/ Fixes: e3a2b3f931f5 ("blk-mq: allow changing of queue depth through sysfs") Signed-off-by: Yu Kuai Reviewed-by: Nilay Shroff Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b75c7a80205073601b213dc523ad91c00b8a3a5c Author: Yu Kuai Date: Wed Sep 10 16:04:42 2025 +0800 blk-mq-sched: add new parameter nr_requests in blk_mq_alloc_sched_tags() [ Upstream commit 6293e336f6d7d3f3415346ce34993b3398846166 ] This helper only support to allocate the default number of requests, add a new parameter to support specific number of requests. Prepare to fix potential deadlock in the case nr_requests grow. Signed-off-by: Yu Kuai Reviewed-by: Nilay Shroff Signed-off-by: Jens Axboe Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown") Signed-off-by: Sasha Levin commit fc0328336cfaa25497aff8174b38ca053d733a39 Author: Yu Kuai Date: Wed Sep 10 16:04:41 2025 +0800 blk-mq: split bitmap grow and resize case in blk_mq_update_nr_requests() [ Upstream commit e63200404477456ec60c62dd8b3b1092aba2e211 ] No functional changes are intended, make code cleaner and prepare to fix the grow case in following patches. Signed-off-by: Yu Kuai Reviewed-by: Nilay Shroff Signed-off-by: Jens Axboe Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown") Signed-off-by: Sasha Levin commit 64cb378502fbca246ff7103386afbba0b8ae1e54 Author: Yu Kuai Date: Wed Sep 10 16:04:40 2025 +0800 blk-mq: cleanup shared tags case in blk_mq_update_nr_requests() [ Upstream commit 7f2799c546dba9e12f9ff4d07936601e416c640d ] For shared tags case, all hctx->sched_tags/tags are the same, it doesn't make sense to call into blk_mq_tag_update_depth() multiple times for the same tags. Signed-off-by: Yu Kuai Reviewed-by: Nilay Shroff Signed-off-by: Jens Axboe Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown") Signed-off-by: Sasha Levin commit b1b9ba3c2ea2e6b09f8b23ae0cf54a3b5c63c288 Author: Yu Kuai Date: Wed Sep 10 16:04:39 2025 +0800 blk-mq: convert to serialize updating nr_requests with update_nr_hwq_lock [ Upstream commit 626ff4f8ebcb7207f01e7810acb85812ccf06bd8 ] request_queue->nr_requests can be changed by: a) switch elevator by updating nr_hw_queues b) switch elevator by elevator sysfs attribute c) configue queue sysfs attribute nr_requests Current lock order is: 1) update_nr_hwq_lock, case a,b 2) freeze_queue 3) elevator_lock, case a,b,c And update nr_requests is seriablized by elevator_lock() already, however, in the case c, we'll have to allocate new sched_tags if nr_requests grow, and do this with elevator_lock held and queue freezed has the risk of deadlock. Hence use update_nr_hwq_lock instead, make it possible to allocate memory if tags grow, meanwhile also prevent nr_requests to be changed concurrently. Signed-off-by: Yu Kuai Reviewed-by: Nilay Shroff Signed-off-by: Jens Axboe Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown") Signed-off-by: Sasha Levin commit 10bc65a048477ee906a6c6a8b85c167098f04f9a Author: Yu Kuai Date: Wed Sep 10 16:04:38 2025 +0800 blk-mq: check invalid nr_requests in queue_requests_store() [ Upstream commit b46d4c447db76e36906ed59ebb9b3ef8f3383322 ] queue_requests_store() is the only caller of blk_mq_update_nr_requests(), and blk_mq_update_nr_requests() is the only caller of blk_mq_tag_update_depth(), however, they all have checkings for nr_requests input by user. Make code cleaner by moving all the checkings to the top function: 1) nr_requests > reserved tags; 2) if there is elevator, 4 <= nr_requests <= 2048; 3) if elevator is none, 4 <= nr_requests <= tag_set->queue_depth; Meanwhile, case 2 is the only case tags can grow and -ENOMEM might be returned. Signed-off-by: Yu Kuai Reviewed-by: Nilay Shroff Signed-off-by: Jens Axboe Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown") Signed-off-by: Sasha Levin commit 5ae84131b0fee48dcd49d8a1f73e9d8f837d429f Author: Yu Kuai Date: Wed Sep 10 16:04:37 2025 +0800 blk-mq: remove useless checkings in blk_mq_update_nr_requests() [ Upstream commit 8bd7195fea6d9662aa3b32498a3828bfd9b63185 ] 1) queue_requests_store() is the only caller of blk_mq_update_nr_requests(), where queue is already freezed, no need to check mq_freeze_depth; 2) q->tag_set must be set for request based device, and queue_is_mq() is already checked in blk_mq_queue_attr_visible(), no need to check q->tag_set. Signed-off-by: Yu Kuai Reviewed-by: Nilay Shroff Signed-off-by: Jens Axboe Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown") Signed-off-by: Sasha Levin commit fa6a3dd139d2b4db53e421d59bf2ebb98a5d70b8 Author: Yu Kuai Date: Wed Sep 10 14:30:55 2025 +0800 block: fix ordering of recursive split IO [ Upstream commit b2f5974079d82a4761f002e80601064d4e39a81f ] Currently, split bio will be chained to original bio, and original bio will be resubmitted to the tail of current->bio_list, waiting for split bio to be issued. However, if split bio get split again, the IO order will be messed up. This problem, on the one hand, will cause performance degradation, especially for mdraid with large IO size; on the other hand, will cause write errors for zoned block devices[1]. For example, in raid456 IO will first be split by max_sector from md_submit_bio(), and then later be split again by chunksize for internal handling: For example, assume max_sectors is 1M, and chunksize is 512k 1) issue a 2M IO: bio issuing: 0+2M current->bio_list: NULL 2) md_submit_bio() split by max_sector: bio issuing: 0+1M current->bio_list: 1M+1M 3) chunk_aligned_read() split by chunksize: bio issuing: 0+512k current->bio_list: 1M+1M -> 512k+512k 4) after first bio issued, __submit_bio_noacct() will contuine issuing next bio: bio issuing: 1M+1M current->bio_list: 512k+512k bio issued: 0+512k 5) chunk_aligned_read() split by chunksize: bio issuing: 1M+512k current->bio_list: 512k+512k -> 1536k+512k bio issued: 0+512k 6) no split afterwards, finally the issue order is: 0+512k -> 1M+512k -> 512k+512k -> 1536k+512k This behaviour will cause large IO read on raid456 endup to be small discontinuous IO in underlying disks. Fix this problem by placing split bio to the head of current->bio_list. Test script: test on 8 disk raid5 with 64k chunksize dd if=/dev/md0 of=/dev/null bs=4480k iflag=direct Test results: Before this patch 1) iostat results: Device r/s rMB/s rrqm/s %rrqm r_await rareq-sz aqu-sz %util md0 52430.00 3276.87 0.00 0.00 0.62 64.00 32.60 80.10 sd* 4487.00 409.00 2054.00 31.40 0.82 93.34 3.68 71.20 2) blktrace G stage: 8,0 0 486445 11.357392936 843 G R 14071424 + 128 [dd] 8,0 0 486451 11.357466360 843 G R 14071168 + 128 [dd] 8,0 0 486454 11.357515868 843 G R 14071296 + 128 [dd] 8,0 0 486468 11.357968099 843 G R 14072192 + 128 [dd] 8,0 0 486474 11.358031320 843 G R 14071936 + 128 [dd] 8,0 0 486480 11.358096298 843 G R 14071552 + 128 [dd] 8,0 0 486490 11.358303858 843 G R 14071808 + 128 [dd] 3) io seek for sdx: Noted io seek is the result from blktrace D stage, statistic of: ABS((offset of next IO) - (offset + len of previous IO)) Read|Write seek cnt 55175, zero cnt 25079 >=(KB) .. <(KB) : count ratio |distribution | 0 .. 1 : 25079 45.5% |########################################| 1 .. 2 : 0 0.0% | | 2 .. 4 : 0 0.0% | | 4 .. 8 : 0 0.0% | | 8 .. 16 : 0 0.0% | | 16 .. 32 : 0 0.0% | | 32 .. 64 : 12540 22.7% |##################### | 64 .. 128 : 2508 4.5% |##### | 128 .. 256 : 0 0.0% | | 256 .. 512 : 10032 18.2% |################# | 512 .. 1024 : 5016 9.1% |######### | After this patch: 1) iostat results: Device r/s rMB/s rrqm/s %rrqm r_await rareq-sz aqu-sz %util md0 87965.00 5271.88 0.00 0.00 0.16 61.37 14.03 90.60 sd* 6020.00 658.44 5117.00 45.95 0.44 112.00 2.68 86.50 2) blktrace G stage: 8,0 0 206296 5.354894072 664 G R 7156992 + 128 [dd] 8,0 0 206305 5.355018179 664 G R 7157248 + 128 [dd] 8,0 0 206316 5.355204438 664 G R 7157504 + 128 [dd] 8,0 0 206319 5.355241048 664 G R 7157760 + 128 [dd] 8,0 0 206333 5.355500923 664 G R 7158016 + 128 [dd] 8,0 0 206344 5.355837806 664 G R 7158272 + 128 [dd] 8,0 0 206353 5.355960395 664 G R 7158528 + 128 [dd] 8,0 0 206357 5.356020772 664 G R 7158784 + 128 [dd] 3) io seek for sdx Read|Write seek cnt 28644, zero cnt 21483 >=(KB) .. <(KB) : count ratio |distribution | 0 .. 1 : 21483 75.0% |########################################| 1 .. 2 : 0 0.0% | | 2 .. 4 : 0 0.0% | | 4 .. 8 : 0 0.0% | | 8 .. 16 : 0 0.0% | | 16 .. 32 : 0 0.0% | | 32 .. 64 : 7161 25.0% |############## | BTW, this looks like a long term problem from day one, and large sequential IO read is pretty common case like video playing. And even with this patch, in this test case IO is merged to at most 128k is due to block layer plug limit BLK_PLUG_FLUSH_SIZE, increase such limit can get even better performance. However, we'll figure out how to do this properly later. [1] https://lore.kernel.org/all/e40b076d-583d-406b-b223-005910a9f46f@acm.org/ Fixes: d89d87965dcb ("When stacked block devices are in-use (e.g. md or dm), the recursive calls") Reported-by: Tie Ren Closes: https://lore.kernel.org/all/7dro5o7u5t64d6bgiansesjavxcuvkq5p2pok7dtwkav7b7ape@3isfr44b6352/ Signed-off-by: Yu Kuai Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 14d4f1eaa6a55f8df04746239293a521f3f13585 Author: Yu Kuai Date: Wed Sep 10 14:30:54 2025 +0800 block: skip unnecessary checks for split bio [ Upstream commit 0b64682e78f7a53ea863e368b1aa66f05767858d ] Lots of checks are already done while submitting this bio the first time, and there is no need to check them again when this bio is resubmitted after split. Hence open code should_fail_bio() and blk_throtl_bio() that are still necessary from submit_bio_split_bioset(). Signed-off-by: Yu Kuai Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Stable-dep-of: b2f5974079d8 ("block: fix ordering of recursive split IO") Signed-off-by: Sasha Levin commit 9f7b1537e3b317c19a24e11d48bee6b19db0df9f Author: Yu Kuai Date: Wed Sep 10 14:30:46 2025 +0800 block: factor out a helper bio_submit_split_bioset() [ Upstream commit e37b5596a19be9a150cb194ec32e78f295a3574b ] No functional changes are intended, some drivers like mdraid will split bio by internal processing, prepare to unify bio split codes. Signed-off-by: Yu Kuai Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Stable-dep-of: b2f5974079d8 ("block: fix ordering of recursive split IO") Signed-off-by: Sasha Levin commit 8668afa4d697e0f1309a8dc70b54b74013102b7b Author: Yu Kuai Date: Wed Sep 10 14:30:42 2025 +0800 block: initialize bio issue time in blk_mq_submit_bio() [ Upstream commit 1f963bdd6420b6080bcfd0ee84a75c96f35545a6 ] bio->issue_time_ns is only used by blk-iolatency, which can only be enabled for rq-based disk, hence it's not necessary to initialize the time for bio-based disk. Meanwhile, if bio is split by blk_crypto_fallback_split_bio_if_needed(), the issue time is not initialized for new split bio, this can be fixed as well. Noted the next patch will optimize better that bio issue time will only be used when blk-iolatency is really enabled by the disk. Fixes: 488f6682c832 ("block: blk-crypto-fallback for Inline Encryption") Signed-off-by: Yu Kuai Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e7f67fe190692efed89ebc6326f90f142deff14e Author: Yu Kuai Date: Wed Sep 10 14:30:41 2025 +0800 block: cleanup bio_issue [ Upstream commit 1733e88874838ddebf7774440c285700865e6b08 ] Now that bio->bi_issue is only used by blk-iolatency to get bio issue time, replace bio_issue with u64 time directly and remove bio_issue to make code cleaner. Signed-off-by: Yu Kuai Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Stable-dep-of: 1f963bdd6420 ("block: initialize bio issue time in blk_mq_submit_bio()") Signed-off-by: Sasha Levin commit 0f9bc379d7dd1c87b1b4b931da3668d81c25a630 Author: Johan Hovold Date: Mon Sep 8 17:22:12 2025 +0200 cpuidle: qcom-spm: fix device and OF node leaks at probe [ Upstream commit cdc06f912670c8c199d5fa9e78b64b7ed8e871d0 ] Make sure to drop the reference to the saw device taken by of_find_device_by_node() after retrieving its driver data during probe(). Also drop the reference to the CPU node sooner to avoid leaking it in case there is no saw node or device. Fixes: 60f3692b5f0b ("cpuidle: qcom_spm: Detach state machine from main SPM handling") Signed-off-by: Johan Hovold Reviewed-by: Konrad Dybcio Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit fa6a4c82040fe32f6ac1e3ba392f92f7d559a2d7 Author: Johan Hovold Date: Tue Sep 9 11:56:51 2025 +0200 soc: mediatek: mtk-svs: fix device leaks on mt8192 probe failure [ Upstream commit f1a68ba5739e42353609438e27a83b08d7f5cfd6 ] Make sure to drop the references taken by of_find_device_by_node() when looking up the thermal sensor and opp devices during probe on probe failure (e.g. probe deferral) and on driver unbind. Fixes: 0bbb09b2af9d ("soc: mediatek: SVS: add mt8192 SVS GPU driver") Cc: Roger Lu Signed-off-by: Johan Hovold Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20250909095651.5530-3-johan@kernel.org Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 6e10986131aef707c5a6f69feae090b7abb91072 Author: Johan Hovold Date: Tue Sep 9 11:56:50 2025 +0200 soc: mediatek: mtk-svs: fix device leaks on mt8183 probe failure [ Upstream commit 6ab4f79ea92324f7f2eb22692054a34bbba7cf35 ] Make sure to drop the references taken by of_find_device_by_node() when looking up the thermal sensor and opp devices during probe on probe failure (e.g. probe deferral) and on driver unbind. Fixes: 681a02e95000 ("soc: mediatek: SVS: introduce MTK SVS engine") Cc: Roger Lu Signed-off-by: Johan Hovold Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20250909095651.5530-2-johan@kernel.org Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 7de879af7a7a1a095c65ab4e1de10101748909ee Author: Xianwei Zhao Date: Thu Jul 17 17:29:54 2025 +0800 dts: arm: amlogic: fix pwm node for c3 [ Upstream commit f8c9fabf2f3d87773613734a8479d0ef9b662b11 ] Fix reg address for c3 pwm node. Fixes: be90cd4bd422 ("arm64: dts: amlogic: Add Amlogic C3 PWM") Signed-off-by: Xianwei Zhao Reviewed-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20250717-fix-pwm-node-v2-1-7365ac7d5320@amlogic.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit ff32bb4a0308b7ad3563da671f271f9c6202ac01 Author: Johan Hovold Date: Fri Jul 25 09:54:29 2025 +0200 firmware: firmware: meson-sm: fix compile-test default [ Upstream commit 0454346d1c5f7fccb3ef6e3103985de8ab3469f3 ] Enabling compile testing should not enable every individual driver (we have "allyesconfig" for that). Fixes: 4a434abc40d2 ("firmware: meson-sm: enable build as module") Signed-off-by: Johan Hovold Reviewed-by: Neil Armstrong Reviewed-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20250725075429.10056-1-johan@kernel.org Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 03f90e4f05cb6360ec9abd3f98a3ebea14934add Author: Nicolas Frattaroli Date: Fri May 30 15:38:08 2025 +0200 PM / devfreq: rockchip-dfi: double count on RK3588 [ Upstream commit f89c7fb83ae95578e355bed1a7aeea5f3ca5a067 ] On RK3588 with LPDDR4X memory, the cycle count as returned by perf stat -a -e rockchip_ddr/cycles/ sleep 1 consistently reads half as much as what the actual DDR frequency is at. For a LPDDR4X module running at 2112MHz, I get more like 1056059916 cycles per second, which is almost bang-on half what it should be. No, I'm not mixing up megatransfers and megahertz. Consulting the downstream driver, this appears to be because the RK3588 hardware specifically (and RK3528 as well, for future reference) needs a multiplier of 2 to get to the correct frequency with everything but LPDDR5. The RK3588's actual memory bandwidth measurements in MB/s are correct however, as confirmed with stress-ng --stream. This makes me think the access counters are not affected in the same way. This tracks with the vendor kernel not multiplying the access counts either. Solve this by adding a new member to the dfi struct, which each SoC can set to whatever they want, but defaults to 1 if left unset by the SoC init functions. The event_get_count op can then use this multiplier if the cycle count is requested. The cycle multiplier is not used in rockchip_dfi_get_event because the vendor driver doesn't use it there either, and we don't do other actual bandwidth unit conversion stuff in there anyway. Fixes: 481d97ba61e1 ("PM / devfreq: rockchip-dfi: add support for RK3588") Signed-off-by: Nicolas Frattaroli Signed-off-by: Chanwoo Choi Link: https://lore.kernel.org/lkml/20250530-rk3588-dfi-improvements-v1-1-6e077c243a95@collabora.com/ Signed-off-by: Sasha Levin commit 808e2335bc1cf2293b9e36ccc94c267c81509c71 Author: Eric Dumazet Date: Tue Sep 9 13:22:43 2025 +0000 nbd: restrict sockets to TCP and UDP [ Upstream commit 9f7c02e031570e8291a63162c6c046dc15ff85b0 ] Recently, syzbot started to abuse NBD with all kinds of sockets. Commit cf1b2326b734 ("nbd: verify socket is supported during setup") made sure the socket supported a shutdown() method. Explicitely accept TCP and UNIX stream sockets. Fixes: cf1b2326b734 ("nbd: verify socket is supported during setup") Reported-by: syzbot+e1cd6bd8493060bd701d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/CANn89iJ+76eE3A_8S_zTpSyW5hvPRn6V57458hCZGY5hbH_bFA@mail.gmail.com/T/#m081036e8747cd7e2626c1da5d78c8b9d1e55b154 Signed-off-by: Eric Dumazet Cc: Mike Christie Cc: Richard W.M. Jones Cc: Jens Axboe Cc: Yu Kuai Cc: linux-block@vger.kernel.org Cc: nbd@other.debian.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ff412930cf17ad613ad86efcbf3666e907dbe840 Author: Rob Herring (Arm) Date: Tue Jul 22 12:11:52 2025 -0500 arm64: dts: mediatek: mt8183: Fix out of range pull values [ Upstream commit 0aeb7ed4bcb244862a35f880053cd64d28c6fb04 ] A value of 10 is not valid for "mediatek,pull-down-adv" and "mediatek,pull-up-adv" properties which have defined values of 0-3. It appears the "10" was written as a binary value. The driver only looks at the lowest 2 bits, so the value "10" decimal works out the same as if "2" was used. Fixes: cd894e274b74 ("arm64: dts: mt8183: Add krane-sku176 board") Fixes: 19b6403f1e2a ("arm64: dts: mt8183: add mt8183 pumpkin board") Signed-off-by: Rob Herring (Arm) Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20250722171152.58923-2-robh@kernel.org Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 2588c4985ddbd671b090a5fa64a7c10beb1eab6d Author: Guoqing Jiang Date: Mon Jul 21 17:59:59 2025 +0800 arm64: dts: mediatek: mt8195: Remove suspend-breaking reset from pcie0 [ Upstream commit 3374b5fb26b300809ecd6aed9f414987dd17c313 ] When test suspend resume with 6.8 based kernel, system can't resume and I got below error which can be also reproduced with 6.16 rc6+ kernel. mtk-pcie-gen3 112f0000.pcie: PCIe link down, current LTSSM state: detect.quiet (0x0) mtk-pcie-gen3 112f0000.pcie: PM: dpm_run_callback(): genpd_resume_noirq returns -110 mtk-pcie-gen3 112f0000.pcie: PM: failed to resume noirq: error -110 After investigation, looks pcie0 has the same problem as pcie1 as decribed in commit 3d7fdd8e38aa ("arm64: dts: mediatek: mt8195: Remove suspend-breaking reset from pcie1"). Fixes: ecc0af6a3fe6 ("arm64: dts: mt8195: Add pcie and pcie phy nodes") Signed-off-by: Guoqing Jiang Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Macpaul Lin Link: https://lore.kernel.org/r/20250721095959.57703-1-guoqing.jiang@canonical.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit f1c3bb6b4063ea81e77fb3e8129bec931c5c38b9 Author: Bibo Mao Date: Sat Sep 6 14:49:51 2025 +0800 tick: Do not set device to detached state in tick_shutdown() [ Upstream commit fe2a449a45b13df1562419e0104b4777b6ea5248 ] tick_shutdown() sets the state of the clockevent device to detached first and the invokes clockevents_exchange_device(), which in turn invokes clockevents_switch_state(). But clockevents_switch_state() returns without invoking the device shutdown callback as the device is already in detached state. As a consequence the timer device is not shutdown when a CPU goes offline. tick_shutdown() does this because it was originally invoked on a online CPU and not on the outgoing CPU. It therefore could not access the clockevent device of the already offlined CPU and just set the state. Since commit 3b1596a21fbf tick_shutdown() is called on the outgoing CPU, so the hardware device can be accessed. Remove the state set before calling clockevents_exchange_device(), so that the subsequent clockevents_switch_state() handles the state transition and invokes the shutdown callback of the clockevent device. [ tglx: Massaged change log ] Fixes: 3b1596a21fbf ("clockevents: Shutdown and unregister current clockevents at CPUHP_AP_TICK_DYING") Signed-off-by: Bibo Mao Signed-off-by: Thomas Gleixner Reviewed-by: Frederic Weisbecker Link: https://lore.kernel.org/all/20250906064952.3749122-2-maobibo@loongson.cn Signed-off-by: Sasha Levin commit c4fa8cf7ce0ef558e00a88af9b594d425bc2f150 Author: Dan Carpenter Date: Mon Sep 8 10:27:45 2025 +0200 irqchip/gic-v5: Fix error handling in gicv5_its_irq_domain_alloc() [ Upstream commit a186120c780e21e4cfd186a925e34f718e30de88 ] Code in gicv5_its_irq_domain_alloc() has two issues: - it checks the wrong return value/variable when calling gicv5_alloc_lpi() - The cleanup code does not take previous loop iterations into account Fix both issues at once by adding the right gicv5_alloc_lpi() variable check and by reworking the function cleanup code to take into account current and previous iterations. [ lpieralisi: Reworded commit message ] Fixes: 57d72196dfc8 ("irqchip/gic-v5: Add GICv5 ITS support") Signed-off-by: Dan Carpenter Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Reviewed-by: Zenghui Yu Link: https://lore.kernel.org/all/20250908082745.113718-4-lpieralisi@kernel.org Signed-off-by: Sasha Levin commit a859e8b8d10a4ee2297fdcd5fd0b7e00caa0abf6 Author: Dan Carpenter Date: Mon Sep 8 10:27:44 2025 +0200 irqchip/gic-v5: Fix loop in gicv5_its_create_itt_two_level() cleanup path [ Upstream commit bfcd1fdaae92faa8cae880eb4c3aaaa60c54bf0d ] The "i" variable in gicv5_its_create_itt_two_level() needs to be signed otherwise it can cause a forever loop in the function's cleanup path. [ lpieralisi: Reworded commit message ] Fixes: 57d72196dfc8 ("irqchip/gic-v5: Add GICv5 ITS support") Signed-off-by: Dan Carpenter Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Reviewed-by: Zenghui Yu Link: https://lore.kernel.org/all/20250908082745.113718-3-lpieralisi@kernel.org Signed-off-by: Sasha Levin commit 9421ebf190374142c0a1448ba2a72b2de923d6f9 Author: Thomas Weißschuh Date: Tue Aug 12 07:39:03 2025 +0200 selftests: vDSO: vdso_test_abi: Correctly skip whole test with missing vDSO [ Upstream commit 4b59a9f7628fd82b24f2148f62cf327a84d26555 ] If AT_SYSINFO_EHDR is missing the whole test needs to be skipped. Currently this results in the following output: TAP version 13 1..16 # AT_SYSINFO_EHDR is not present! This output is incorrect, as "1..16" still requires the subtest lines to be printed, which isn't done however. Switch to the correct skipping functions, so the output now correctly indicates that no subtests are being run: TAP version 13 1..0 # SKIP AT_SYSINFO_EHDR is not present! Fixes: 693f5ca08ca0 ("kselftest: Extend vDSO selftest") Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250812-vdso-tests-fixes-v2-2-90f499dd35f8@linutronix.de Signed-off-by: Sasha Levin commit 3e90ead2e7d651a2e7ee0e01e8bb4ad55df98e6e Author: Thomas Weißschuh Date: Tue Aug 12 07:39:02 2025 +0200 selftests: vDSO: Fix -Wunitialized in powerpc VDSO_CALL() wrapper [ Upstream commit 9f15e0f9ef514b8e1a80707931f6d07362e8ebc4 ] The _rval register variable is meant to be an output operand of the asm statement but is instead used as input operand. clang 20.1 notices this and triggers -Wuninitialized warnings: tools/testing/selftests/timers/auxclock.c:154:10: error: variable '_rval' is uninitialized when used here [-Werror,-Wuninitialized] 154 | return VDSO_CALL(self->vdso_clock_gettime64, 2, clockid, ts); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ tools/testing/selftests/timers/../vDSO/vdso_call.h:59:10: note: expanded from macro 'VDSO_CALL' 59 | : "r" (_rval) \ | ^~~~~ tools/testing/selftests/timers/auxclock.c:154:10: note: variable '_rval' is declared here tools/testing/selftests/timers/../vDSO/vdso_call.h:47:2: note: expanded from macro 'VDSO_CALL' 47 | register long _rval asm ("r3"); \ | ^ It seems the list of input and output operands have been switched around. However as the argument registers are not always initialized they can not be marked as pure inputs as that would trigger -Wuninitialized warnings. Adding _rval as another input and output operand does also not work as it would collide with the existing _r3 variable. Instead reuse _r3 for both the argument and the return value. Fixes: 6eda706a535c ("selftests: vDSO: fix the way vDSO functions are called for powerpc") Reported-by: kernel test robot Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Reviewed-by: Christophe Leroy Link: https://lore.kernel.org/all/20250812-vdso-tests-fixes-v2-1-90f499dd35f8@linutronix.de Closes: https://lore.kernel.org/oe-kbuild-all/202506180223.BOOk5jDK-lkp@intel.com/ Signed-off-by: Sasha Levin commit 6a0c394300a7b0c05504596685de8a46707171fc Author: Han Guangjiang Date: Fri Sep 5 18:24:11 2025 +0800 blk-throttle: fix access race during throttle policy activation [ Upstream commit bd9fd5be6bc0836820500f68fff144609fbd85a9 ] On repeated cold boots we occasionally hit a NULL pointer crash in blk_should_throtl() when throttling is consulted before the throttle policy is fully enabled for the queue. Checking only q->td != NULL is insufficient during early initialization, so blkg_to_pd() for the throttle policy can still return NULL and blkg_to_tg() becomes NULL, which later gets dereferenced. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000156 ... pc : submit_bio_noacct+0x14c/0x4c8 lr : submit_bio_noacct+0x48/0x4c8 sp : ffff800087f0b690 x29: ffff800087f0b690 x28: 0000000000005f90 x27: ffff00068af393c0 x26: 0000000000080000 x25: 000000000002fbc0 x24: ffff000684ddcc70 x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 x20: 0000000000080000 x19: ffff000684ddcd08 x18: ffffffffffffffff x17: 0000000000000000 x16: ffff80008132a550 x15: 0000ffff98020fff x14: 0000000000000000 x13: 1fffe000d11d7021 x12: ffff000688eb810c x11: ffff00077ec4bb80 x10: ffff000688dcb720 x9 : ffff80008068ef60 x8 : 00000a6fb8a86e85 x7 : 000000000000111e x6 : 0000000000000002 x5 : 0000000000000246 x4 : 0000000000015cff x3 : 0000000000394500 x2 : ffff000682e35e40 x1 : 0000000000364940 x0 : 000000000000001a Call trace: submit_bio_noacct+0x14c/0x4c8 verity_map+0x178/0x2c8 __map_bio+0x228/0x250 dm_submit_bio+0x1c4/0x678 __submit_bio+0x170/0x230 submit_bio_noacct_nocheck+0x16c/0x388 submit_bio_noacct+0x16c/0x4c8 submit_bio+0xb4/0x210 f2fs_submit_read_bio+0x4c/0xf0 f2fs_mpage_readpages+0x3b0/0x5f0 f2fs_readahead+0x90/0xe8 Tighten blk_throtl_activated() to also require that the throttle policy bit is set on the queue: return q->td != NULL && test_bit(blkcg_policy_throtl.plid, q->blkcg_pols); This prevents blk_should_throtl() from accessing throttle group state until policy data has been attached to blkgs. Fixes: a3166c51702b ("blk-throttle: delay initialization until configuration") Co-developed-by: Liang Jie Signed-off-by: Liang Jie Signed-off-by: Han Guangjiang Reviewed-by: Yu Kuai Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4f3cc1e7d54e10ae2e5cc93dd2f72c50abdce2fb Author: Genjian Zhang Date: Fri Aug 15 17:07:32 2025 +0800 null_blk: Fix the description of the cache_size module argument [ Upstream commit 7942b226e6b84df13b46b76c01d3b6e07a1b349e ] When executing modinfo null_blk, there is an error in the description of module parameter mbps, and the output information of cache_size is incomplete.The output of modinfo before and after applying this patch is as follows: Before: [...] parm: cache_size:ulong [...] parm: mbps:Cache size in MiB for memory-backed device. Default: 0 (none) (uint) [...] After: [...] parm: cache_size:Cache size in MiB for memory-backed device. Default: 0 (none) (ulong) [...] parm: mbps:Limit maximum bandwidth (in MiB/s). Default: 0 (no limit) (uint) [...] Fixes: 058efe000b31 ("null_blk: add module parameters for 4 options") Signed-off-by: Genjian Zhang Reviewed-by: Damien Le Moal Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 61a9491f63b9696f608d97962e61965a376929c0 Author: Yulin Lu Date: Wed Sep 3 17:19:15 2025 +0800 pinctrl: eswin: Fix regulator error check and Kconfig dependency [ Upstream commit a6a2f50ab1721343ee2d5d2be888709aa886e3aa ] Smatch reported the following warning in eic7700_pinctrl_probe(): drivers/pinctrl/pinctrl-eic7700.c:638 eic7700_pinctrl_probe() warn: passing zero to 'PTR_ERR' The root cause is that devm_regulator_get() may return NULL when CONFIG_REGULATOR is disabled. In such case, IS_ERR_OR_NULL() triggers PTR_ERR(NULL) which evaluates to 0, leading to passing a success code as an error. However, this driver cannot work without a regulator. To fix this: - Change the check from IS_ERR_OR_NULL() to IS_ERR() - Update Kconfig to explicitly select REGULATOR and REGULATOR_FIXED_VOLTAGE, ensuring that the regulator framework is always available. This resolves the Smatch warning and enforces the correct dependency. Suggested-by: Dan Carpenter Fixes: 5b797bcc00ef ("pinctrl: eswin: Add EIC7700 pinctrl driver") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-gpio/aKRGiZ-fai0bv0tG@stanley.mountain/ Signed-off-by: Yulin Lu Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 861fd09a7a36e27b141674d686905e4e3b1cecba Author: Qianfeng Rong Date: Sun Aug 31 16:49:58 2025 +0800 pinctrl: renesas: Use int type to store negative error codes [ Upstream commit 9f062fc5b0ff44550088912ab89f9da40226a826 ] Change the 'ret' variable in sh_pfc_pinconf_group_set() from unsigned int to int, as it needs to store either negative error codes or zero returned by sh_pfc_pinconf_set(). No effect on runtime. Signed-off-by: Qianfeng Rong Fixes: d0593c363f04ccc4 ("pinctrl: sh-pfc: Propagate errors on group config") Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250831084958.431913-4-rongqianfeng@vivo.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 036efdc9ea46a1e5cf211b472209d9e1481654ee Author: Eugene Shalygin Date: Tue Aug 5 22:31:48 2025 +0200 hwmon: (asus-ec-sensors) Narrow lock for X870E-CREATOR WIFI [ Upstream commit 3aa72cf03924d04c8d20f8b319df8f73550dd26c ] Use mutex from the SIO device rather than the global lock. Signed-off-by: Eugene Shalygin Fixes: 3e538b52157b ("hwmon: (asus-ec-sensors) add ProArt X870E-CREATOR WIFI") Link: https://lore.kernel.org/r/20250805203157.18446-1-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 9927fafee0b8aed9fb36b53bf8a7c74c938e7b21 Author: Andy Yan Date: Mon Aug 18 20:32:59 2025 +0800 power: supply: cw2015: Fix a alignment coding style issue [ Upstream commit def5612170a8c6c4c6a3ea5bd6c3cfc8de6ba4b1 ] Fix the checkpatch warning: CHECK: Alignment should match open parenthesis Fixes: 0cb172a4918e ("power: supply: cw2015: Use device managed API to simplify the code") Signed-off-by: Andy Yan Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 24d61b6e23d2c7291c528dd43a0bf76b5c05c8f0 Author: Dan Carpenter Date: Thu Aug 7 18:58:23 2025 +0300 PM / devfreq: mtk-cci: Fix potential error pointer dereference in probe() [ Upstream commit fc33bf0e097c6834646b98a7b3da0ae5b617f0f9 ] The drv->sram_reg pointer could be set to ERR_PTR(-EPROBE_DEFER) which would lead to a error pointer dereference. Use IS_ERR_OR_NULL() to check that the pointer is valid. Fixes: e09bd5757b52 ("PM / devfreq: mtk-cci: Handle sram regulator probe deferral") Signed-off-by: Dan Carpenter Signed-off-by: Chanwoo Choi Link: https://patchwork.kernel.org/project/linux-pm/patch/aJTNHz8kk8s6Q2os@stanley.mountain/ Signed-off-by: Sasha Levin commit 07d8d3b1ad44656bcf5adf9e6fe6dd8d3a45464e Author: Jihed Chaibi Date: Sat Aug 30 23:59:57 2025 +0200 ARM: dts: omap: am335x-cm-t335: Remove unused mcasp num-serializer property [ Upstream commit 27322753c8b913fba05250e7b5abb1da31e6ed23 ] The dtbs_check validation for am335x-cm-t335.dtb flags an error for an unevaluated 'num-serializer' property in the mcasp0 node. This property is obsolete; it is not defined in the davinci-mcasp-audio schema and is not used by the corresponding (or any) driver. Remove this unused property to fix the schema validation warning. Fixes: 48ab364478e77 ("ARM: dts: cm-t335: add audio support") Signed-off-by: Jihed Chaibi Link: https://lore.kernel.org/r/20250830215957.285694-1-jihed.chaibi.dev@gmail.com Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit ead80fb02dc4d2871ff05116e2a54fa7e02db7bd Author: Jihed Chaibi Date: Sat Aug 23 00:50:52 2025 +0200 ARM: dts: ti: omap: omap3-devkit8000-lcd: Fix ti,keep-vref-on property to use correct boolean syntax in DTS [ Upstream commit 5af5b85505bc859adb338fe5d6e4842e72cdf932 ] The ti,keep-vref-on property, defined as a boolean flag in the Device Tree schema, was incorrectly assigned a value (<1>) in the DTS file, causing a validation error: "size (4) error for type flag". Remove the value to match the schema and ensure compatibility with the driver using device_property_read_bool(). This fixes the dtbs_check error. Fixes: ed05637c30e6 ("ARM: dts: omap3-devkit8000: Add ADS7846 Touchscreen support") Signed-off-by: Jihed Chaibi Link: https://lore.kernel.org/r/20250822225052.136919-1-jihed.chaibi.dev@gmail.com Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit c6bc1a612b17fb9cd22c11e74e5b9220a111c8ed Author: Jihed Chaibi Date: Sat Aug 23 00:25:30 2025 +0200 ARM: dts: ti: omap: am335x-baltos: Fix ti,en-ck32k-xtal property in DTS to use correct boolean syntax [ Upstream commit 9658a92fad1889ff92fa4bd668cd61052687245a ] The ti,en-ck32k-xtal property, defined as a boolean in the Device Tree schema, was incorrectly assigned a value (<1>) in the DTS file, causing a validation error: "size (4) error for type flag". The driver uses of_property_read_bool(), expecting a boolean. Remove the value to fix the dtbs_check error. Fixes: 262178b6b8e5 ("ARM: dts: split am335x-baltos-ir5221 into dts and dtsi files") Signed-off-by: Jihed Chaibi Link: https://lore.kernel.org/all/20250822222530.113520-1-jihed.chaibi.dev@gmail.com/ Link: https://lore.kernel.org/r/20250822222530.113520-1-jihed.chaibi.dev@gmail.com Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit 6f48d5f1fca2b87beabec9ab42ca2c5ff82e6e58 Author: Thomas Weißschuh Date: Fri Aug 15 12:41:10 2025 +0200 vdso: Add struct __kernel_old_timeval forward declaration to gettime.h [ Upstream commit 437054b1bbe11be87ab0a522b8ccbae3f785c642 ] The prototype of __vdso_gettimeofday() uses this struct. However gettime.h's own includes do not provide a definition for it. Add a forward declaration, similar to other used structs. Fixes: 42874e4eb35b ("arch: vdso: consolidate gettime prototypes") Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250815-vdso-sparc64-generic-2-v2-1-b5ff80672347@linutronix.de Signed-off-by: Sasha Levin commit ba51132ae0ccab06888ef0098bb526ccde8b3510 Author: Yu Kuai Date: Thu Aug 21 14:06:11 2025 +0800 blk-mq: fix elevator depth_updated method [ Upstream commit 7d337eef4affc5e26e0570513168c69ddbc40f92 ] Current depth_updated has some problems: 1) depth_updated() will be called for each hctx, while all elevators will update async_depth for the disk level, this is not related to hctx; 2) In blk_mq_update_nr_requests(), if previous hctx update succeed and this hctx update failed, q->nr_requests will not be updated, while async_depth is already updated with new nr_reqeuests in previous depth_updated(); 3) All elevators are using q->nr_requests to calculate async_depth now, however, q->nr_requests is still the old value when depth_updated() is called from blk_mq_update_nr_requests(); Those problems are first from error path, then mq-deadline, and recently for bfq and kyber, fix those problems by: - pass in request_queue instead of hctx; - move depth_updated() after q->nr_requests is updated in blk_mq_update_nr_requests(); - add depth_updated() call inside init_sched() method to initialize async_depth; - remove init_hctx() method for mq-deadline and bfq that is useless now; Fixes: 77f1e0a52d26 ("bfq: update internal depth state when queue depth changes") Fixes: 39823b47bbd4 ("block/mq-deadline: Fix the tag reservation code") Fixes: 42e6c6ce03fd ("lib/sbitmap: convert shallow_depth from one word to the whole sbitmap") Signed-off-by: Yu Kuai Reviewed-by: Hannes Reinecke Reviewed-by: Li Nan Reviewed-by: Nilay Shroff Link: https://lore.kernel.org/r/20250821060612.1729939-2-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5c40f501f75f521f8c8146b58b5d6ea2279480d3 Author: Rafael J. Wysocki Date: Tue Sep 2 15:55:45 2025 +0200 PM: sleep: core: Clear power.must_resume in noirq suspend error path [ Upstream commit be82483d1b60baf6747884bd74cb7de484deaf76 ] If system suspend is aborted in the "noirq" phase (for instance, due to an error returned by one of the device callbacks), power.is_noirq_suspended will not be set for some devices and device_resume_noirq() will return early for them. Consequently, noirq resume callbacks will not run for them at all because the noirq suspend callbacks have not run for them yet. If any of them has power.must_resume set and late suspend has been skipped for it (due to power.smart_suspend), early resume should be skipped for it either, or its state may become inconsistent (for instance, if the early resume assumes that it will always follow noirq resume). Make that happen by clearing power.must_resume in device_resume_noirq() for devices with power.is_noirq_suspended clear that have been left in suspend by device_suspend_late(), which will subsequently cause device_resume_early() to leave the device in suspend and avoid changing its state. Fixes: 0d4b54c6fee8 ("PM / core: Add LEAVE_SUSPENDED driver flag") Link: https://lore.kernel.org/linux-pm/5d692b81-6f58-4e86-9cb0-ede69a09d799@rowland.harvard.edu/ Signed-off-by: Rafael J. Wysocki Reviewed-by: Ulf Hansson Link: https://patch.msgid.link/3381776.aeNJFYEL58@rafael.j.wysocki Signed-off-by: Sasha Levin commit 5569fadd00f064948129595273d466a0ba9f0da6 Author: Thomas Weißschuh Date: Tue Aug 26 08:17:04 2025 +0200 vdso/datastore: Gate time data behind CONFIG_GENERIC_GETTIMEOFDAY [ Upstream commit 7c0c01a216e6d9e1d169c0f6f3b5522e6da708ed ] When the generic vDSO does not provide time functions, as for example on riscv32, then the time data store is not necessary. Avoid allocating these time data pages when not used. Fixes: df7fcbefa710 ("vdso: Add generic time data storage") Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250826-vdso-cleanups-v1-1-d9b65750e49f@linutronix.de Signed-off-by: Sasha Levin commit 39051d7c9d6eb6c4210895c36ae50ce1a92f999d Author: Ricardo B. Marlière Date: Fri Aug 29 16:33:49 2025 -0300 selftests/bpf: Fix count write in testapp_xdp_metadata_copy() [ Upstream commit c9110e6f7237f4a314e2b87b75a8a158b9877a7b ] Commit 4b302092553c ("selftests/xsk: Add tail adjustment tests and support check") added a new global to xsk_xdp_progs.c, but left out the access in the testapp_xdp_metadata_copy() function. Since bpf_map_update_elem() will write to the whole bss section, it gets truncated. Fix by writing to skel_rx->bss->count directly. Fixes: 4b302092553c ("selftests/xsk: Add tail adjustment tests and support check") Signed-off-by: Ricardo B. Marlière Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250829-selftests-bpf-xsk_regression_fix-v1-1-5f5acdb9fe6b@suse.com Signed-off-by: Sasha Levin commit 6df16e7cebb1df37bb3a1ba923770aa7576081f1 Author: Brian Norris Date: Fri Aug 22 11:59:07 2025 -0700 genirq/test: Ensure CPU 1 is online for hotplug test [ Upstream commit 8ad25ebfa70e86860559b306bbc923c7db4fcac6 ] It's possible to run these tests on platforms that think they have a hotpluggable CPU1, but for whatever reason, CPU1 is not online and can't be brought online: # irq_cpuhotplug_test: EXPECTATION FAILED at kernel/irq/irq_test.c:210 Expected remove_cpu(1) == 0, but remove_cpu(1) == 1 (0x1) CPU1: failed to boot: -38 # irq_cpuhotplug_test: EXPECTATION FAILED at kernel/irq/irq_test.c:214 Expected add_cpu(1) == 0, but add_cpu(1) == -38 (0xffffffffffffffda) Check that CPU1 is actually online before trying to run the test. Fixes: 66067c3c8a1e ("genirq: Add kunit tests for depth counts") Reported-by: Guenter Roeck Signed-off-by: Brian Norris Signed-off-by: Thomas Gleixner Tested-by: Guenter Roeck Reviewed-by: David Gow Link: https://lore.kernel.org/all/20250822190140.2154646-7-briannorris@chromium.org Signed-off-by: Sasha Levin commit 63e444e45ce00337f078c98bf41e56ceb543db60 Author: Brian Norris Date: Fri Aug 22 11:59:06 2025 -0700 genirq/test: Drop CONFIG_GENERIC_IRQ_MIGRATION assumptions [ Upstream commit add03fdb9d52411cabb3872fb7692df6f4c67586 ] Not all platforms use the generic IRQ migration code, even if they select GENERIC_IRQ_MIGRATION. (See, for example, powerpc / pseries_cpu_disable().) If such platforms don't perform managed shutdown the same way, the interrupt may not actually shut down, and these tests fail: [ 4.357022][ T101] # irq_cpuhotplug_test: EXPECTATION FAILED at kernel/irq/irq_test.c:211 [ 4.357022][ T101] Expected irqd_is_activated(data) to be false, but is true [ 4.358128][ T101] # irq_cpuhotplug_test: EXPECTATION FAILED at kernel/irq/irq_test.c:212 [ 4.358128][ T101] Expected irqd_is_started(data) to be false, but is true [ 4.375558][ T101] # irq_cpuhotplug_test: EXPECTATION FAILED at kernel/irq/irq_test.c:216 [ 4.375558][ T101] Expected irqd_is_activated(data) to be false, but is true [ 4.376088][ T101] # irq_cpuhotplug_test: EXPECTATION FAILED at kernel/irq/irq_test.c:217 [ 4.376088][ T101] Expected irqd_is_started(data) to be false, but is true [ 4.377851][ T1] # irq_cpuhotplug_test: pass:0 fail:1 skip:0 total:1 [ 4.377901][ T1] not ok 4 irq_cpuhotplug_test [ 4.378073][ T1] # irq_test_cases: pass:3 fail:1 skip:0 total:4 Rather than test that PowerPC performs migration the same way as the unterrupt core, just drop the state checks. The point of the test was to ensure that the code kept |depth| balanced, which still can be tested for. Fixes: 66067c3c8a1e ("genirq: Add kunit tests for depth counts") Reported-by: Guenter Roeck Signed-off-by: Brian Norris Signed-off-by: Thomas Gleixner Tested-by: Guenter Roeck Reviewed-by: David Gow Link: https://lore.kernel.org/all/20250822190140.2154646-6-briannorris@chromium.org Signed-off-by: Sasha Levin commit 6a45d1874a955432781cc0c5d28e64234c831a30 Author: Brian Norris Date: Fri Aug 22 11:59:05 2025 -0700 genirq/test: Depend on SPARSE_IRQ [ Upstream commit 0c888bc86d672e551ce5c58b891c8b44f8967643 ] Some architectures have a static interrupt layout, with a limited number of interrupts. Without SPARSE_IRQ, the test may not be able to allocate any fake interrupts, and the test will fail. (This occurs on ARCH=m68k, for example.) Additionally, managed-affinity is only supported with CONFIG_SPARSE_IRQ=y, so irq_shutdown_depth_test() and irq_cpuhotplug_test() would fail without it. Add a 'SPARSE_IRQ' dependency to avoid these problems. Many architectures 'select SPARSE_IRQ', so this is easy to miss. Notably, this also excludes ARCH=um from running any of these tests, even though some of them might work. Fixes: 66067c3c8a1e ("genirq: Add kunit tests for depth counts") Reported-by: Guenter Roeck Signed-off-by: Brian Norris Signed-off-by: Thomas Gleixner Tested-by: Guenter Roeck Reviewed-by: David Gow Link: https://lore.kernel.org/all/20250822190140.2154646-5-briannorris@chromium.org Signed-off-by: Sasha Levin commit da665a5b16e323d9007d6e4873fe2892e2fdc06f Author: Brian Norris Date: Fri Aug 22 11:59:02 2025 -0700 genirq/test: Select IRQ_DOMAIN [ Upstream commit f8a44f9babd054ff19e20a30cab661d716ad5459 ] These tests use irq_domain_alloc_descs() and so require CONFIG_IRQ_DOMAIN. Fixes: 66067c3c8a1e ("genirq: Add kunit tests for depth counts") Reported-by: Guenter Roeck Signed-off-by: Brian Norris Signed-off-by: Thomas Gleixner Tested-by: Guenter Roeck Reviewed-by: David Gow Link: https://lore.kernel.org/all/20250822190140.2154646-2-briannorris@chromium.org Closes: https://lore.kernel.org/lkml/ded44edf-eeb7-420c-b8a8-d6543b955e6e@roeck-us.net/ Signed-off-by: Sasha Levin commit d60990c8540f9a6b934eda1f9775488652eae684 Author: David Gow Date: Sat Aug 16 17:45:28 2025 +0800 genirq/test: Fix depth tests on architectures with NOREQUEST by default. [ Upstream commit c9163915a93d40e32c4e4aeb942c0adcb190d72e ] The new irq KUnit tests fail on some architectures (notably PowerPC and 32-bit ARM), as the request_irq() call fails due to the ARCH_IRQ_INIT_FLAGS containing IRQ_NOREQUEST, yielding the following errors: [10:17:45] # irq_free_disabled_test: EXPECTATION FAILED at kernel/irq/irq_test.c:88 [10:17:45] Expected ret == 0, but [10:17:45] ret == -22 (0xffffffffffffffea) [10:17:45] # irq_free_disabled_test: EXPECTATION FAILED at kernel/irq/irq_test.c:90 [10:17:45] Expected desc->depth == 0, but [10:17:45] desc->depth == 1 (0x1) [10:17:45] # irq_free_disabled_test: EXPECTATION FAILED at kernel/irq/irq_test.c:93 [10:17:45] Expected desc->depth == 1, but [10:17:45] desc->depth == 2 (0x2) By clearing IRQ_NOREQUEST from the interrupt descriptor, these tests now pass on ARM and PowerPC. Fixes: 66067c3c8a1e ("genirq: Add kunit tests for depth counts") Signed-off-by: David Gow Signed-off-by: Thomas Gleixner Tested-by: Guenter Roeck Tested-by: Brian Norris Reviewed-by: Brian Norris Link: https://lore.kernel.org/all/20250816094528.3560222-2-davidgow@google.com Signed-off-by: Sasha Levin commit 47daa86dcaba81699a5b96a5296f0b23d41de723 Author: Rob Herring (Arm) Date: Thu Aug 21 17:21:33 2025 -0500 dt-bindings: vendor-prefixes: Add undocumented vendor prefixes [ Upstream commit 4ed46073274a5b23baf0b992c459762e28faf549 ] Add various vendor prefixes which are in use in compatible strings already. These were found by modifying vendor-prefixes.yaml into a schema to check compatible strings. The added prefixes doesn't include various duplicate prefixes in use such as "lge". Link: https://lore.kernel.org/r/20250821222136.1027269-1-robh@kernel.org Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 7444154cec56a0d1ea18f7915393c6cfe5e5b799 Author: Jihed Chaibi Date: Sun Aug 31 00:51:15 2025 +0200 ARM: dts: stm32: stm32mp151c-plyaqm: Use correct dai-format property [ Upstream commit 0b367e60c73c05721cf2156fe8fe077320115ffd ] The stm32-i2s binding inherits from the standard audio-graph-port schema for its 'port' subnode, audio-graph-port requires the use of the 'dai-format' property. The stm32mp151c-plyaqm dts file was using the non-standard name 'format'. Correct the property name to 'dai-format' to fix the dtbs_check validation error. Fixes: 9365fa46be358 ("ARM: dts: stm32: Add Plymovent AQM devicetree") Signed-off-by: Jihed Chaibi Link: https://lore.kernel.org/r/20250830225115.303663-1-jihed.chaibi.dev@gmail.com Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 9e3fe3b69677097c5eb562e4fba52a90df3f3cf5 Author: Qianfeng Rong Date: Tue Sep 2 21:09:30 2025 +0800 block: use int to store blk_stack_limits() return value [ Upstream commit b0b4518c992eb5f316c6e40ff186cbb7a5009518 ] Change the 'ret' variable in blk_stack_limits() from unsigned int to int, as it needs to store negative value -1. Storing the negative error codes in unsigned type, or performing equality comparisons (e.g., ret == -1), doesn't cause an issue at runtime [1] but can be confusing. Additionally, assigning negative error codes to unsigned type may trigger a GCC warning when the -Wsign-conversion flag is enabled. No effect on runtime. Link: https://lore.kernel.org/all/x3wogjf6vgpkisdhg3abzrx7v7zktmdnfmqeih5kosszmagqfs@oh3qxrgzkikf/ #1 Signed-off-by: Qianfeng Rong Reviewed-by: John Garry Fixes: fe0b393f2c0a ("block: Correct handling of bottom device misaligment") Reviewed-by: Bart Van Assche Link: https://lore.kernel.org/r/20250902130930.68317-1-rongqianfeng@vivo.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 93563a898533708f674a9db0fc92855f42e73401 Author: Inochi Amaoto Date: Thu Aug 28 07:09:42 2025 +0800 PCI/MSI: Check MSI_FLAG_PCI_MSI_MASK_PARENT in cond_[startup|shutdown]_parent() [ Upstream commit 727e914bbfbbda9e6efa5cb1abe4e96a949d576f ] For MSI controllers which only support MSI_FLAG_PCI_MSI_MASK_PARENT, the newly added callback irq_startup() and irq_shutdown() for pci_msi[x]_template will not unmask or mask the interrupt when startup() resp. shutdown() is invoked. This prevents the interrupt from being enabled resp. disabled. Invoke irq_[un]mask_parent() in cond_[startup|shutdown]_parent(), when the interrupt has the MSI_FLAG_PCI_MSI_MASK_PARENT flag set. Fixes: 54f45a30c0d0 ("PCI/MSI: Add startup/shutdown for per device domains") Reported-by: Linux Kernel Functional Testing Reported-by: Nathan Chancellor Reported-by: Wei Fang Signed-off-by: Inochi Amaoto Signed-off-by: Thomas Gleixner Tested-by: Nathan Chancellor Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Wei Fang Tested-by: Chen Wang # Pioneerbox/SG2042 Acked-by: Bjorn Helgaas Link: https://lore.kernel.org/all/20250827230943.17829-1-inochiama@gmail.com Closes: https://lore.kernel.org/regressions/aK4O7Hl8NCVEMznB@monster/ Closes: https://lore.kernel.org/regressions/20250826220959.GA4119563@ax162/ Closes: https://lore.kernel.org/all/20250827093911.1218640-1-wei.fang@nxp.com/ Signed-off-by: Sasha Levin commit 029d1324011c4b1c42a510ac16474368be9f2f44 Author: Andrei Lalaev Date: Wed Aug 20 10:47:12 2025 +0200 leds: leds-lp55xx: Use correct address for memory programming [ Upstream commit d6058316d16ee0d1861c0550051b2492efb54b79 ] Memory programming doesn't work for devices without page support. For example, LP5562 has 3 engines but doesn't support pages, the start address is changed depending on engine number. According to datasheet [1], the PROG MEM register addresses for each engine are as follows: Engine 1: 0x10 Engine 2: 0x30 Engine 3: 0x50 However, the current implementation incorrectly calculates the address of PROG MEM register using the engine index starting from 1: prog_mem_base = 0x10 LP55xx_BYTES_PER_PAGE = 0x20 Engine 1: 0x10 + 0x20 * 1 = 0x30 Engine 2: 0x10 + 0x20 * 2 = 0x50 Engine 3: 0x10 + 0x20 * 3 = 0x70 This results in writing to the wrong engine memory, causing pattern programming to fail. To correct it, the engine index should be decreased: Engine 1: 0x10 + 0x20 * 0 = 0x10 Engine 2: 0x10 + 0x20 * 1 = 0x30 Engine 3: 0x10 + 0x20 * 2 = 0x50 1 - https://www.ti.com/lit/ds/symlink/lp5562.pdf Fixes: 31379a57cf2f ("leds: leds-lp55xx: Generalize update_program_memory function") Signed-off-by: Andrei Lalaev Link: https://lore.kernel.org/r/20250820-lp5562-prog-mem-address-v1-1-8569647fa71d@anton-paar.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 4dbe9119de0f8417867ee8fb689229da2c47674b Author: Benjamin Berg Date: Thu Jul 31 22:12:22 2025 +0200 selftests/nolibc: fix EXPECT_NZ macro [ Upstream commit 6d33ce3634f99e0c6c9ce9fc111261f2c411cb48 ] The expect non-zero macro was incorrect and never used. Fix its definition. Fixes: 362aecb2d8cfa ("selftests/nolibc: add basic infrastructure to ease creation of nolibc tests") Signed-off-by: Benjamin Berg Link: https://lore.kernel.org/r/20250731201225.323254-2-benjamin@sipsolutions.net Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit d69f5129f169820538be5af236b35907458b2b70 Author: Thomas Weißschuh Date: Wed Aug 20 10:29:27 2025 +0200 tools/nolibc: avoid error in dup2() if old fd equals new fd [ Upstream commit d1ff0e2d13d6ac3a15be7870e15216726b0a809a ] dup2() allows both 'old' and 'new' to have the same value, which dup3() does not. If libc dup2() is implemented through the dup3() system call, then it would incorrectly fail in this case. Avoid the error by handling old == new explicitly. Fixes: 30ca20517ac1 ("tools headers: Move the nolibc header from rcutorture to tools/include/nolibc/") Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Link: https://lore.kernel.org/r/20250820-nolibc-dup2-einval-v2-1-807185a45c56@linutronix.de Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit eec602bb0fd8ea02602fe3ad6be203b6bfb6d063 Author: Waiman Long Date: Wed Aug 27 15:00:08 2025 +0200 selftests/futex: Fix some futex_numa_mpol subtests [ Upstream commit d8e2f919997b14665e4509ef9a5278f291598d6e ] The "Memory out of range" subtest of futex_numa_mpol assumes that memory access outside of the mmap'ed area is invalid. That may not be the case depending on the actual memory layout of the test application. When that subtest was run on an x86-64 system with latest upstream kernel, the test passed as an error was returned from futex_wake(). On another PowerPC system, the same subtest failed because futex_wake() returned 0. Bail out! futex2_wake(64, 0x86) should fail, but didn't Looking further into the passed subtest on x86-64, it was found that an -EINVAL was returned instead of -EFAULT. The -EINVAL error was returned because the node value test with FLAGS_NUMA set failed with a node value of 0x7f7f. IOW, the futex memory was accessible and futex_wake() failed because the supposed node number wasn't valid. If that memory location happens to have a very small value (e.g. 0), the test will pass and no error will be returned. Since this subtest is non-deterministic, drop it unless a guard page beyond the mmap region is explicitly set. The other problematic test is the "Memory too small" test. The futex_wake() function returns the -EINVAL error code because the given futex address isn't 8-byte aligned, not because only 4 of the 8 bytes are valid and the other 4 bytes are not. So change the name of this subtest to "Mis-aligned futex" to reflect the reality. [ bp: Massage commit message. ] Fixes: 3163369407ba ("selftests/futex: Add futex_numa_mpol") Signed-off-by: Waiman Long Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Sebastian Andrzej Siewior Link: https://lore.kernel.org/20250827130011.677600-3-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 5c44ac57c6242752499ee91028ce6944d7856d0c Author: Qianfeng Rong Date: Fri Aug 29 18:14:11 2025 +0800 regulator: scmi: Use int type to store negative error codes [ Upstream commit 9d35d068fb138160709e04e3ee97fe29a6f8615b ] Change the 'ret' variable from u32 to int to store negative error codes or zero returned by of_property_read_u32(). Storing the negative error codes in unsigned type, doesn't cause an issue at runtime but it's ugly as pants. Additionally, assigning negative error codes to unsigned type may trigger a GCC warning when the -Wsign-conversion flag is enabled. No effect on runtime. Signed-off-by: Qianfeng Rong Reviewed-by: Sudeep Holla Fixes: 0fbeae70ee7c ("regulator: add SCMI driver") Link: https://patch.msgid.link/20250829101411.625214-1-rongqianfeng@vivo.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ce5210d33540016b07aee82507ddcf6699adda76 Author: Janne Grunau Date: Sat Aug 23 11:49:44 2025 +0200 arm64: dts: apple: t8103-j457: Fix PCIe ethernet iommu-map [ Upstream commit 6e08cdd604edcec2c277af17c7d36caf827057ff ] PCIe `port01` of t8103-j457 (iMac, M1, 2 USB-C ports, 2021) is unused and disabled. Linux' PCI subsystem assigns the ethernet nic from `port02` to bus 02. This results into assigning `pcie0_dart_1` from the disabled port as iommu. The `pcie0_dart_1` instance is disabled and probably fused off (it is on the M2 Pro Mac mini which has a disabled PCIe port as well). Without iommu the ethernet nic is not expected work. Adjusts the "bus-range" and the PCIe devices "reg" property to PCI subsystem's bus number. Fixes: 7c77ab91b33d ("arm64: dts: apple: Add missing M1 (t8103) devices") Reviewed-by: Neal Gompa Reviewed-by: Sven Peter Signed-off-by: Janne Grunau Link: https://lore.kernel.org/r/20250823-apple-dt-sync-6-17-v2-1-6dc0daeb4786@jannau.net Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit 5843cfdb1440204984d2d76d1ac2bbeff4363bf4 Author: Nicolas Ferre Date: Wed Aug 27 16:54:26 2025 +0200 ARM: at91: pm: fix MCKx restore routine [ Upstream commit 296302d3d81360e09fa956e9be9edc8223b69a12 ] The at91_mckx_ps_restore() assembly function is responsible for setting back MCKx system bus clocks after exiting low power modes. Fix a typo and use tmp3 variable instead of tmp2 to correctly set MCKx to previously saved state. Tmp2 was used without the needed changes in CSS and DIV. Moreover the required bit 7, telling that MCR register's content is to be changed (CMD/write), was not set. Fix function comment to match tmp variables actually used. Signed-off-by: Nicolas Ferre Fixes: 28eb1d40fe57 ("ARM: at91: pm: add support for MCK1..4 save/restore for ulp modes") Link: https://lore.kernel.org/r/20250827145427.46819-3-nicolas.ferre@microchip.com Reviewed-by: Alexandre Belloni [claudiu.beznea: s/sate/state in commit description] Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit 17dae893035886f14fb002632f66ec1127a7e3b9 Author: Sebastian Andrzej Siewior Date: Wed Aug 27 15:00:07 2025 +0200 selftests/futex: Remove the -g parameter from futex_priv_hash [ Upstream commit 2e62688d583809e832433f461194334408b10817 ] The -g parameter was meant to the test the immutable global hash instead of the private hash which has been made immutable. The global hash is tested as part at the end of the regular test. The immutable private hash been removed. Remove last traces of the immutable private hash. Fixes: 16adc7f136dc1 ("selftests/futex: Remove support for IMMUTABLE") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Borislav Petkov (AMD) Reviewed-by: André Almeida Link: https://lore.kernel.org/20250827130011.677600-2-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit d5ddd76ee52bdc16e9f8b1e7791291e785dab032 Author: Li Nan Date: Tue Aug 26 16:48:54 2025 +0800 blk-mq: check kobject state_in_sysfs before deleting in blk_mq_unregister_hctx [ Upstream commit 4c7ef92f6d4d08a27d676e4c348f4e2922cab3ed ] In __blk_mq_update_nr_hw_queues() the return value of blk_mq_sysfs_register_hctxs() is not checked. If sysfs creation for hctx fails, later changing the number of hw_queues or removing disk will trigger the following warning: kernfs: can not remove 'nr_tags', no directory WARNING: CPU: 2 PID: 637 at fs/kernfs/dir.c:1707 kernfs_remove_by_name_ns+0x13f/0x160 Call Trace: remove_files.isra.1+0x38/0xb0 sysfs_remove_group+0x4d/0x100 sysfs_remove_groups+0x31/0x60 __kobject_del+0x23/0xf0 kobject_del+0x17/0x40 blk_mq_unregister_hctx+0x5d/0x80 blk_mq_sysfs_unregister_hctxs+0x94/0xd0 blk_mq_update_nr_hw_queues+0x124/0x760 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x92/0x120 [null_blk] kobjct_del() was called unconditionally even if sysfs creation failed. Fix it by checkig the kobject creation statusbefore deleting it. Fixes: 477e19dedc9d ("blk-mq: adjust debugfs and sysfs register when updating nr_hw_queues") Signed-off-by: Li Nan Reviewed-by: Yu Kuai Link: https://lore.kernel.org/r/20250826084854.1030545-1-linan666@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3950803cf1516530a26c1f2d9d124ca7c2f7b374 Author: Da Xue Date: Thu Aug 21 19:33:34 2025 -0400 pinctrl: meson-gxl: add missing i2c_d pinmux [ Upstream commit d8c2a9edd181f0cc4a66eec954b3d8f6a1d954a7 ] Amlogic GXL has 4 I2C attached to gpio-periphs. I2C_D is on GPIOX_10/11. Add the relevant func 3 pinmux per the datasheet for S805X/S905X/S905D. Fixes: 0f15f500ff2c ("pinctrl: meson: Add GXL pinctrl definitions") Signed-off-by: Da Xue Link: https://lore.kernel.org/20250821233335.1707559-1-da@libre.computer Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit b499406552834d5bbf798ff3525f1b6f3f983dc0 Author: Sneh Mankad Date: Mon Aug 25 11:53:50 2025 +0530 soc: qcom: rpmh-rsc: Unconditionally clear _TRIGGER bit for TCS [ Upstream commit f87412d18edb5b8393eb8cb1c2d4a54f90185a21 ] Unconditionally clear the TCS_AMC_MODE_TRIGGER bit when a transaction completes. Previously this bit was only cleared when a wake TCS was borrowed as an AMC TCS but not for dedicated AMC TCS. Leaving this bit set for AMC TCS and entering deeper low power modes can generate a false completion IRQ. Prevent this scenario by always clearing the TCS_AMC_MODE_TRIGGER bit upon receiving a completion IRQ. Fixes: 15b3bf61b8d4 ("soc: qcom: rpmh-rsc: Clear active mode configuration for wake TCS") Signed-off-by: Sneh Mankad Link: https://lore.kernel.org/r/20250825-rpmh_rsc_change-v1-1-138202c31bf6@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 79cb6fb85833f6308b4d1d29b679ba4149beb149 Author: Vlastimil Babka Date: Mon Aug 25 17:00:37 2025 +0200 scripts/misc-check: update export checks for EXPORT_SYMBOL_FOR_MODULES() [ Upstream commit 0354e81b7bd629f9c3379c9524e988ebc504fa25 ] The module export checks are looking for EXPORT_SYMBOL_GPL_FOR_MODULES() which was renamed to EXPORT_SYMBOL_FOR_MODULES(). Update the checks. Fixes: 6d3c3ca4c77e ("module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES") Signed-off-by: Vlastimil Babka Reviewed-by: Daniel Gomez Reviewed-by: Nicolas Schier Link: https://lore.kernel.org/r/20250825-export_modules_fix-v1-1-5c331e949538@suse.cz Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit bb968a57b07294ef052b35658ad53754ecd30605 Author: Inochi Amaoto Date: Thu Aug 14 07:28:33 2025 +0800 irqchip/sg2042-msi: Fix broken affinity setting [ Upstream commit 9d8c41816bac518b4824f83b346ae30a1be83f68 ] When using NVME on SG2044, the NVME drvier always complains about "I/O tag XXX (XXX) QID XX timeout, completion polled", which is caused by the broken affinity setting mechanism of the sg2042-msi driver. The PLIC driver can only the set the affinity when enabled, but the sg2042-msi driver invokes the affinity setter in disabled state, which causes the change to be lost. Cure this by implementing the irq_startup()/shutdown() callbacks, which allow to startup (enabled) the underlying PLIC first. Fixes: e96b93a97c90 ("irqchip/sg2042-msi: Add the Sophgo SG2044 MSI interrupt controller") Reported-by: Han Gao Suggested-by: Thomas Gleixner Signed-off-by: Inochi Amaoto Signed-off-by: Thomas Gleixner Tested-by: Chen Wang # Pioneerbox Reviewed-by: Chen Wang Link: https://lore.kernel.org/all/20250813232835.43458-4-inochiama@gmail.com Signed-off-by: Sasha Levin commit b6baa72f10737f1092d50388e290d287d35a3eeb Author: Inochi Amaoto Date: Thu Aug 14 07:28:32 2025 +0800 PCI/MSI: Add startup/shutdown for per device domains [ Upstream commit 54f45a30c0d0153d2be091ba2d683ab6db6d1d5b ] As the RISC-V PLIC cannot apply affinity settings without invoking irq_enable(), it will make the interrupt unavailble when used as an underlying interrupt chip for the MSI controller. Implement the irq_startup() and irq_shutdown() callbacks for the PCI MSI and MSI-X templates. For chips that specify MSI_FLAG_PCI_MSI_STARTUP_PARENT, the parent startup and shutdown functions are invoked. That allows the interrupt on the parent chip to be enabled if the interrupt has not been enabled during allocation. This is necessary for MSI controllers which use PLIC as underlying parent interrupt chip. Suggested-by: Thomas Gleixner Signed-off-by: Inochi Amaoto Signed-off-by: Thomas Gleixner Tested-by: Chen Wang # Pioneerbox Reviewed-by: Chen Wang Acked-by: Bjorn Helgaas Link: https://lore.kernel.org/all/20250813232835.43458-3-inochiama@gmail.com Stable-dep-of: 9d8c41816bac ("irqchip/sg2042-msi: Fix broken affinity setting") Signed-off-by: Sasha Levin commit 23b79aad169d2105d30f99fded902206cbec3281 Author: Inochi Amaoto Date: Thu Aug 14 07:28:31 2025 +0800 genirq: Add irq_chip_(startup/shutdown)_parent() [ Upstream commit 7a721a2fee2bce01af26699a87739db8ca8ea3c8 ] As the MSI controller on SG2044 uses PLIC as the underlying interrupt controller, it needs to call irq_enable() and irq_disable() to startup/shutdown interrupts. Otherwise, the MSI interrupt can not be startup correctly and will not respond any incoming interrupt. Introduce irq_chip_startup_parent() and irq_chip_shutdown_parent() to allow the interrupt controller to call the irq_startup()/irq_shutdown() callbacks of the parent interrupt chip. In case the irq_startup()/irq_shutdown() callbacks are not implemented for the parent interrupt chip, this will fallback to irq_chip_enable_parent() or irq_chip_disable_parent(). Suggested-by: Thomas Gleixner Signed-off-by: Inochi Amaoto Signed-off-by: Thomas Gleixner Tested-by: Chen Wang # Pioneerbox Reviewed-by: Chen Wang Link: https://lore.kernel.org/all/20250813232835.43458-2-inochiama@gmail.com Link: https://lore.kernel.org/lkml/20250722224513.22125-1-inochiama@gmail.com/ Stable-dep-of: 9d8c41816bac ("irqchip/sg2042-msi: Fix broken affinity setting") Signed-off-by: Sasha Levin commit d760948a0f27359d8d957a94528b8f749503f5e6 Author: Huisong Li Date: Mon Jul 28 15:06:11 2025 +0800 ACPI: processor: idle: Fix memory leak when register cpuidle device failed [ Upstream commit 11b3de1c03fa9f3b5d17e6d48050bc98b3704420 ] The cpuidle device's memory is leaked when cpuidle device registration fails in acpi_processor_power_init(). Free it as appropriate. Fixes: 3d339dcbb56d ("cpuidle / ACPI : move cpuidle_device field out of the acpi_processor_power structure") Signed-off-by: Huisong Li Link: https://patch.msgid.link/20250728070612.1260859-2-lihuisong@huawei.com [ rjw: Changed the order of the new statements, added empty line after if () ] [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 5d9bc981873718c297cdc3d7de775761486131b5 Author: Tao Chen Date: Tue Aug 19 20:56:38 2025 +0800 bpf: Remove preempt_disable in bpf_try_get_buffers [ Upstream commit 4223bf833c8495e40ae2886acbc0ecbe88fa6306 ] Now BPF program will run with migration disabled, so it is safe to access this_cpu_inc_return(bpf_bprintf_nest_level). Fixes: d9c9e4db186a ("bpf: Factorize bpf_trace_printk and bpf_seq_printf") Signed-off-by: Tao Chen Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250819125638.2544715-1-chen.dylane@linux.dev Signed-off-by: Sasha Levin commit e8c693a8060193f146c8327e7ebea949b96ad933 Author: Joy Zou Date: Mon Aug 18 09:25:31 2025 +0800 arm64: dts: imx95: Correct the lpuart7 and lpuart8 srcid [ Upstream commit 6fdaf3b1839c861931db0dd11747c056a76b68f9 ] According to the imx95 RM, the lpuart7 rx and tx DMA's srcid are 88 and 87, and the lpuart8 rx and tx DMA's srcid are 90 and 89. So correct them. Fixes: 915fd2e127e8 ("arm64: dts: imx95: add edma[1..3] nodes") Signed-off-by: Joy Zou Signed-off-by: Peng Fan Reviewed-by: Frank Li Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 7ff719167b90a6023a7a80a69b6fb7a2b3498448 Author: Frieder Schrempf Date: Mon Jul 21 12:05:46 2025 +0200 arm64: dts: imx93-kontron: Fix USB port assignment [ Upstream commit c94737568b290e0547bff344046f02df49ed6373 ] The assignment of the USB ports is wrong and needs to be swapped. The OTG (USB-C) port is on the first port and the host port with the onboard hub is on the second port. Signed-off-by: Frieder Schrempf Fixes: 2b52fd6035b7 ("arm64: dts: Add support for Kontron i.MX93 OSM-S SoM and BL carrier board") Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 1a105ca8ba70fedb2747f0101e0ada6ea16ad3e7 Author: Annette Kobou Date: Mon Jul 21 12:05:45 2025 +0200 arm64: dts: imx93-kontron: Fix GPIO for panel regulator [ Upstream commit f3e011388dd08d15e0414e3b6b974f946305e7af ] The regulator uses the wrong GPIO. Fix this. Signed-off-by: Annette Kobou Signed-off-by: Frieder Schrempf Fixes: 2b52fd6035b7 ("arm64: dts: Add support for Kontron i.MX93 OSM-S SoM and BL carrier board") Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 554d66c9f9cbf65abc3c95d4fdd80e28850e6d93 Author: Junnan Wu Date: Tue Aug 12 15:53:43 2025 +0800 firmware: arm_scmi: Mark VirtIO ready before registering scmi_virtio_driver [ Upstream commit e8faa8a466f61f4ae07069ed6b0872f602f1cba9 ] After commit 20bda12a0ea0 (“firmware: arm_scmi: Make VirtIO transport a standalone driver”), the VirtIO transport probes independently. During scmi_virtio_probe, scmi_probe() is called, which intune invokes scmi_protocol_acquire() that sends a message over the virtqueue and waits for a reply. Previously, DRIVER_OK was only set after scmi_vio_probe, in the core virtio via virtio_dev_probe(). According to the Virtio spec (3.1 Device Initialization): | The driver MUST NOT send any buffer available notifications to the | device before setting DRIVER_OK. Some type-1 hypervisors block available-buffer notifications until the driver is marked OK. In such cases, scmi_vio_probe stalls in scmi_wait_for_reply(), and the probe never completes. Resolve this by setting DRIVER_OK immediately after the device-specific setup, so scmi_probe() can safely send notifications. Note after splitting the transports into modules, the probe sequence changed a bit. We can no longer rely on virtio_device_ready() being called by the core in virtio_dev_probe(), because scmi_vio_probe() doesn’t complete until the core SCMI stack runs scmi_probe(), which immediately issues the initial BASE protocol exchanges. Fixes: 20bda12a0ea0 ("firmware: arm_scmi: Make VirtIO transport a standalone driver") Signed-off-by: Junnan Wu Message-Id: <20250812075343.3201365-1-junnan01.wu@samsung.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit ee9d40eb5825f1e2e4410c44d7ff124b3fc11290 Author: Mykyta Yatsenko Date: Tue Aug 19 22:51:19 2025 +0100 libbpf: Export bpf_object__prepare symbol [ Upstream commit 2693227c1150d58bf82ef45a394a554373be5286 ] Add missing LIBBPF_API macro for bpf_object__prepare function to enable its export. libbpf.map had bpf_object__prepare already listed. Fixes: 1315c28ed809 ("libbpf: Split bpf object load into prepare/load") Signed-off-by: Mykyta Yatsenko Signed-off-by: Daniel Borkmann Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20250819215119.37795-1-mykyta.yatsenko5@gmail.com Signed-off-by: Sasha Levin commit 4cc434e820f84624df7efa7773b10263bf575b5a Author: Marek Vasut Date: Wed Aug 6 21:28:04 2025 +0200 arm64: dts: renesas: sparrow-hawk: Set VDDQ18_25_AVB voltage on EVTB1 [ Upstream commit 7d1e3aa2826a22f68f1850c31ac96348272fa356 ] The Retronix R-Car V4H Sparrow Hawk EVTB1 uses 1V8 IO voltage supply for VDDQ18_25_AVB power rail. Update the AVB0 pinmux to reflect the change in IO voltage. Since the VDDQ18_25_AVB power rail is shared, all four AVB0, AVB1, AVB2, TSN0 PFC/GPIO POC[7..4] registers have to be configured the same way. As the EVTA1 boards are from a limited run and generally not available, update the DT to make it compatible with EVTB1 IO voltage settings. Fixes: a719915e76f2 ("arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support") Signed-off-by: Marek Vasut Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250806192821.133302-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 42da90cbbac01e27379c0d33443e1472838cfedd Author: Marek Vasut Date: Mon Jul 28 01:58:11 2025 +0200 arm64: dts: renesas: sparrow-hawk: Invert microSD voltage selector on EVTB1 [ Upstream commit ae95807b00e1639b3f6ab94eb2cd887266e4f766 ] Invert the polarity of microSD voltage selector on Retronix R-Car V4H Sparrow Hawk board. The voltage selector was not populated on prototype EVTA1 boards, and is implemented slightly different on EVTB1 boards. As the EVTA1 boards are from a limited run and generally not available, update the DT to make it compatible with EVTB1 microSD voltage selector. Fixes: a719915e76f2 ("arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support") Signed-off-by: Marek Vasut Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250727235905.290427-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 0a809dc0ff691b49e21fe4adf821e9646f8d8608 Author: Florian Fainelli Date: Mon Aug 18 08:50:48 2025 -0700 cpufreq: scmi: Account for malformed DT in scmi_dev_used_by_cpus() [ Upstream commit cd5d4621ba846dad9b2e6b0c2d1518d083fcfa13 ] Broadcom STB platforms were early adopters (2017) of the SCMI framework and as a result, not all deployed systems have a Device Tree entry where SCMI protocol 0x13 (PERFORMANCE) is declared as a clock provider, nor are the CPU Device Tree node(s) referencing protocol 0x13 as their clock provider. This was clarified in commit e11c480b6df1 ("dt-bindings: firmware: arm,scmi: Extend bindings for protocol@13") in 2023. For those platforms, we allow the checks done by scmi_dev_used_by_cpus() to continue, and in the event of not having done an early return, we key off the documented compatible string and give them a pass to continue to use scmi-cpufreq. Fixes: 6c9bb8692272 ("cpufreq: scmi: Skip SCMI devices that aren't used by the CPUs") Signed-off-by: Florian Fainelli Reviewed-by: Sudeep Holla Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 9c4ddd6523a9cb1c91f556a029121ce688b6df30 Author: Ilya Leoshkevich Date: Wed Aug 13 14:06:30 2025 +0200 s390/bpf: Write back tail call counter for BPF_TRAMP_F_CALL_ORIG [ Upstream commit bc3905a71f02511607d3ccf732360580209cac4c ] The tailcall_bpf2bpf_hierarchy_fentry test hangs on s390. Its call graph is as follows: entry() subprog_tail() trampoline() fentry() the rest of subprog_tail() # via BPF_TRAMP_F_CALL_ORIG return to entry() The problem is that the rest of subprog_tail() increments the tail call counter, but the trampoline discards the incremented value. This results in an astronomically large number of tail calls. Fix by making the trampoline write the incremented tail call counter back. Fixes: 528eb2cb87bc ("s390/bpf: Implement arch_prepare_bpf_trampoline()") Signed-off-by: Ilya Leoshkevich Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20250813121016.163375-4-iii@linux.ibm.com Signed-off-by: Sasha Levin commit fb66892d9130307c9dfebc5c56ac0db2d31c6959 Author: Ilya Leoshkevich Date: Wed Aug 13 14:06:29 2025 +0200 s390/bpf: Write back tail call counter for BPF_PSEUDO_CALL [ Upstream commit c861a6b147137d10b5ff88a2c492ba376cd1b8b0 ] The tailcall_bpf2bpf_hierarchy_1 test hangs on s390. Its call graph is as follows: entry() subprog_tail() bpf_tail_call_static(0) -> entry + tail_call_start subprog_tail() bpf_tail_call_static(0) -> entry + tail_call_start entry() copies its tail call counter to the subprog_tail()'s frame, which then increments it. However, the incremented result is discarded, leading to an astronomically large number of tail calls. Fix by writing the incremented counter back to the entry()'s frame. Fixes: dd691e847d28 ("s390/bpf: Implement bpf_jit_supports_subprog_tailcalls()") Signed-off-by: Ilya Leoshkevich Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20250813121016.163375-3-iii@linux.ibm.com Signed-off-by: Sasha Levin commit 49aba499474548d56531fe3bd440648b2d89345c Author: Ilya Leoshkevich Date: Wed Aug 13 14:06:28 2025 +0200 s390/bpf: Do not write tail call counter into helper and kfunc frames [ Upstream commit eada40e057fc1842358d9daca3abe5cacb21e8a1 ] Only BPF functions make use of the tail call counter; helpers and kfuncs ignore and most likely also clobber it. Writing it into these functions' frames is pointless and misleading, so do not do it. Fixes: dd691e847d28 ("s390/bpf: Implement bpf_jit_supports_subprog_tailcalls()") Signed-off-by: Ilya Leoshkevich Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20250813121016.163375-2-iii@linux.ibm.com Signed-off-by: Sasha Levin commit c0e4490cbf5ea61e7248e71d9114bc800514bb32 Author: Fenglin Wu Date: Tue Jul 29 12:51:22 2025 +0800 leds: flash: leds-qcom-flash: Update torch current clamp setting [ Upstream commit 5974e8f6c3e47ab097c3dd8ece7324d1f88fe739 ] There is a register to clamp the flash current per LED channel when safety timer is disabled. It needs to be updated according to the maximum torch LED current setting to ensure the torch current won't be clamped unexpectedly. Fixes: 96a2e242a5dc ("leds: flash: Add driver to support flash LED module in QCOM PMICs") Signed-off-by: Fenglin Wu Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250729-fix-torch-clamp-issue-v2-1-9b83816437a3@oss.qualcomm.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit dee28f1a389f907e55a7bebdce8387cbd515ccd4 Author: Len Bao Date: Sun Jul 27 07:56:45 2025 +0000 leds: max77705: Function return instead of variable assignment [ Upstream commit 6e3779e3c6f9dcc9267bf98bef70773a0b13dcbb ] Coverity noticed that assigning value -EINVAL to 'ret' in the if statement is useless because 'ret' is overwritten a few lines later. However, after inspect the code, this warning reveals that we need to return -EINVAL instead of the variable assignment. So, fix it. Coverity-id: 1646104 Fixes: aebb5fc9a0d8 ("leds: max77705: Add LEDs support") Signed-off-by: Len Bao Link: https://lore.kernel.org/r/20250727075649.34496-1-len.bao@gmx.us Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 630c3506d375641354b50818c4677d8584f94cd9 Author: Geert Uytterhoeven Date: Fri Jun 27 15:49:48 2025 +0200 ARM: dts: renesas: porter: Fix CAN pin group [ Upstream commit 287066b295051729fb08c3cff12ae17c6fe66133 ] According to the schematics, the CAN transceiver is connected to pins GP7_3 and GP7_4, which correspond to CAN0 data group B. Fixes: 0768fbad7fba1d27 ("ARM: shmobile: porter: add CAN0 DT support") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/70ad9bc44d6cea92197c42eedcad6b3d0641d26a.1751032025.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 5ff994fcd18134d11bf6b72186a4a98af787ede3 Author: Thomas Weißschuh Date: Thu Jul 31 10:00:31 2025 +0200 tools/nolibc: fix error return value of clock_nanosleep() [ Upstream commit 1201f6fb5bfdbd10985ac3c8f49ef8f4f88b5c94 ] clock_nanosleep() returns a positive error value. Unlike other libc functions it *does not* return -1 nor set errno. Fix the return value and also adapt nanosleep(). Fixes: 7c02bc4088af ("tools/nolibc: add support for clock_nanosleep() and nanosleep()") Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Link: https://lore.kernel.org/r/20250731-nolibc-clock_nanosleep-ret-v1-1-9e4af7855e61@linutronix.de Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit 6737bc841ab4d56702b9b5bdedfb785490265227 Author: Yureka Lilian Date: Thu Aug 14 20:01:12 2025 +0200 libbpf: Fix reuse of DEVMAP [ Upstream commit 6c6b4146deb12d20f42490d5013f2043df942161 ] Previously, re-using pinned DEVMAP maps would always fail, because get_map_info on a DEVMAP always returns flags with BPF_F_RDONLY_PROG set, but BPF_F_RDONLY_PROG being set on a map during creation is invalid. Thus, ignore the BPF_F_RDONLY_PROG flag in the flags returned from get_map_info when checking for compatibility with an existing DEVMAP. The same problem is handled in a third-party ebpf library: - https://github.com/cilium/ebpf/issues/925 - https://github.com/cilium/ebpf/pull/930 Fixes: 0cdbb4b09a06 ("devmap: Allow map lookups from eBPF") Signed-off-by: Yureka Lilian Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250814180113.1245565-3-yuka@yuka.dev Signed-off-by: Sasha Levin commit af3cfb0998bcf7d945a7cdfb1d0d309c31723043 Author: Tao Chen Date: Thu Aug 14 20:14:29 2025 +0800 bpf: Remove migrate_disable in kprobe_multi_link_prog_run [ Upstream commit abdaf49be5424db74e19d167c10d7dad79a0efc2 ] Graph tracer framework ensures we won't migrate, kprobe_multi_link_prog_run called all the way from graph tracer, which disables preemption in function_graph_enter_regs, as Jiri and Yonghong suggested, there is no need to use migrate_disable. As a result, some overhead may will be reduced. And add cant_sleep check for __this_cpu_inc_return. Fixes: 0dcac2725406 ("bpf: Add multi kprobe link") Signed-off-by: Tao Chen Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250814121430.2347454-1-chen.dylane@linux.dev Signed-off-by: Sasha Levin commit 95a4abb534ced42ea99c11d20fc6a808ec5e3fb4 Author: Matt Bobrowski Date: Fri Aug 15 12:12:14 2025 +0000 bpf/selftests: Fix test_tcpnotify_user [ Upstream commit c80d79720647ed77ebc0198abd5a0807efdaff0b ] Based on a bisect, it appears that commit 7ee988770326 ("timers: Implement the hierarchical pull model") has somehow inadvertently broken BPF selftest test_tcpnotify_user. The error that is being generated by this test is as follows: FAILED: Wrong stats Expected 10 calls, got 8 It looks like the change allows timer functions to be run on CPUs different from the one they are armed on. The test had pinned itself to CPU 0, and in the past the retransmit attempts also occurred on CPU 0. The test had set the max_entries attribute for BPF_MAP_TYPE_PERF_EVENT_ARRAY to 2 and was calling bpf_perf_event_output() with BPF_F_CURRENT_CPU, so the entry was likely to be in range. With the change to allow timers to run on other CPUs, the current CPU tasked with performing the retransmit might be bumped and in turn fall out of range, as the event will be filtered out via __bpf_perf_event_output() using: if (unlikely(index >= array->map.max_entries)) return -E2BIG; A possible change would be to explicitly set the max_entries attribute for perf_event_map in test_tcpnotify_kern.c to a value that's at least as large as the number of CPUs. As it turns out however, if the field is left unset, then the libbpf will determine the number of CPUs available on the underlying system and update the max_entries attribute accordingly in map_set_def_max_entries(). A further problem with the test is that it has a thread that continues running up until the program exits. The main thread cleans up some LIBBPF data structures, while the other thread continues to use them, which inevitably will trigger a SIGSEGV. This can be dealt with by telling the thread to run for as long as necessary and doing a pthread_join on it before exiting the program. Finally, I don't think binding the process to CPU 0 is meaningful for this test any more, so get rid of that. Fixes: 435f90a338ae ("selftests/bpf: add a test case for sock_ops perf-event notification") Signed-off-by: Matt Bobrowski Signed-off-by: Martin KaFai Lau Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/aJ8kHhwgATmA3rLf@google.com Signed-off-by: Sasha Levin commit ffe015e8e3f681ca59694da4e56ab873ebd092e3 Author: Baptiste Lepers Date: Tue Aug 12 16:42:11 2025 +0200 rust: cpumask: Mark CpumaskVar as transparent [ Upstream commit 23fca458f6ab18927e50c2134fb7b60297f18b4e ] Unsafe code in CpumaskVar's methods assumes that the type has the same layout as `bindings::cpumask_var_t`. This is not guaranteed by the default struct representation in Rust, but requires specifying the `transparent` representation. Fixes: 8961b8cb3099a ("rust: cpumask: Add initial abstractions") Signed-off-by: Baptiste Lepers Reviewed-by: Alice Ryhl Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit b39970581c6b0a7ad72b19307769b7cf3c2ee932 Author: Amery Hung Date: Tue Aug 12 10:50:39 2025 -0700 selftests/bpf: Copy test_kmods when installing selftest [ Upstream commit 07866544e410e4c895a729971e4164861b41fad5 ] Commit d6212d82bf26 ("selftests/bpf: Consolidate kernel modules into common directory") consolidated the Makefile of test_kmods. However, since it removed test_kmods from TEST_GEN_PROGS_EXTENDED, the kernel modules required by bpf selftests are now missing from kselftest_install when "make install". Fix it by adding test_kmod to TEST_GEN_FILES. Fixes: d6212d82bf26 ("selftests/bpf: Consolidate kernel modules into common directory") Signed-off-by: Amery Hung Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250812175039.2323570-1-ameryhung@gmail.com Signed-off-by: Sasha Levin commit bef2cbf8161f2f3cbbef87586812cfa92e896c99 Author: Geert Uytterhoeven Date: Wed Aug 13 15:07:18 2025 +0200 regmap: Remove superfluous check for !config in __regmap_init() [ Upstream commit 5c36b86d2bf68fbcad16169983ef7ee8c537db59 ] The first thing __regmap_init() do is check if config is non-NULL, so there is no need to check for this again later. Fixes: d77e745613680c54 ("regmap: Add bulk read/write callbacks into regmap_config") Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/a154d9db0f290dda96b48bd817eb743773e846e1.1755090330.git.geert+renesas@glider.be Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ed61d8a0510d0de5a066f014f63ddbcf99e4c6ef Author: Paul Chaignon Date: Mon Aug 11 20:58:20 2025 +0200 bpf: Tidy verifier bug message [ Upstream commit c93c59baa5ab57e94b874000cec56e26611b7a23 ] Yonghong noticed that error messages for potential verifier bugs often have a '(1)' at the end. This is happening because verifier_bug_if(cond, env, fmt, args...) prints "(" #cond ")\n" as part of the message and verifier_bug() is defined as: #define verifier_bug(env, fmt, args...) verifier_bug_if(1, env, fmt, ##args) Hence, verifier_bug() always ends up displaying '(1)'. This small patch fixes it by having verifier_bug_if conditionally call verifier_bug instead of the other way around. Fixes: 1cb0f56d9618 ("bpf: WARN_ONCE on verifier bugs") Reported-by: Yonghong Song Signed-off-by: Paul Chaignon Signed-off-by: Andrii Nakryiko Tested-by: Eduard Zingerman Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/aJo9THBrzo8jFXsh@mail.gmail.com Signed-off-by: Sasha Levin commit 26be98b3880844ecea77de4adec997fb8dccef51 Author: Biju Das Date: Fri Aug 1 13:19:53 2025 +0100 arm64: dts: renesas: rzg2lc-smarc: Disable CAN-FD channel0 [ Upstream commit ae014fbc99c7f986ee785233e7a5336834e39af4 ] On RZ/G2LC SMARC EVK, CAN-FD channel0 is not populated, and currently we are deleting a wrong and nonexistent node. Fixing the wrong node would invoke a dtb warning message, as channel0 is a required property. Disable CAN-FD channel0 instead of deleting the node. Fixes: 46da632734a5 ("arm64: dts: renesas: rzg2lc-smarc: Enable CANFD channel 1") Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250801121959.267424-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 730d23a5b8edfe5a1f6b230a5297309a5ef9beb0 Author: Lad Prabhakar Date: Wed Jul 9 17:08:13 2025 +0100 pinctrl: renesas: rzg2l: Fix invalid unsigned return in rzg3s_oen_read() [ Upstream commit 8912b2862b9b74a0dc4e3ea1aacdec2f8abd7e1d ] rzg3s_oen_read() returns a u32 value, but previously propagated a negative error code from rzg3s_pin_to_oen_bit(), resulting in an unintended large positive value due to unsigned conversion. This caused incorrect output-enable reporting for certain pins. Without this patch, pins P1_0-P1_4 and P7_0-P7_4 are incorrectly reported as "output enabled" in the pinconf-pins debugfs file. With this fix, only P1_0-P1_1 and P7_0-P7_1 are shown as "output enabled", which matches the hardware manual. Fix this by returning 0 when the OEN bit lookup fails, treating the pin as output-disabled by default. Fixes: a9024a323af2 ("pinctrl: renesas: rzg2l: Clean up and refactor OEN read/write functions") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250709160819.306875-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 3ea252a5c48dd3a4e1f7d0c53d3b0f7b648becc9 Author: Qu Wenruo Date: Mon Sep 15 14:29:42 2025 +0930 btrfs: fix symbolic link reading when bs > ps [ Upstream commit 67378b754608a3524d125bfa5744508a49fe48be ] [BUG DURING BS > PS TEST] When running the following script on a btrfs whose block size is larger than page size, e.g. 8K block size and 4K page size, it will trigger a kernel BUG: # mkfs.btrfs -s 8k $dev # mount $dev $mnt # mkdir $mnt/dir # ln -s dir $mnt/link # ls $mnt/link The call trace looks like this: BTRFS warning (device dm-2): support for block size 8192 with page size 4096 is experimental, some features may be missing BTRFS info (device dm-2): checking UUID tree BTRFS info (device dm-2): enabling ssd optimizations BTRFS info (device dm-2): enabling free space tree ------------[ cut here ]------------ kernel BUG at /home/adam/linux/include/linux/highmem.h:275! Oops: invalid opcode: 0000 [#1] SMP CPU: 8 UID: 0 PID: 667 Comm: ls Tainted: G OE 6.17.0-rc4-custom+ #283 PREEMPT(full) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:zero_user_segments.constprop.0+0xdc/0xe0 [btrfs] Call Trace: btrfs_get_extent.cold+0x85/0x101 [btrfs 7453c70c03e631c8d8bfdd4264fa62d3e238da6f] btrfs_do_readpage+0x244/0x750 [btrfs 7453c70c03e631c8d8bfdd4264fa62d3e238da6f] btrfs_read_folio+0x9c/0x100 [btrfs 7453c70c03e631c8d8bfdd4264fa62d3e238da6f] filemap_read_folio+0x37/0xe0 do_read_cache_folio+0x94/0x3e0 __page_get_link.isra.0+0x20/0x90 page_get_link+0x16/0x40 step_into+0x69b/0x830 path_lookupat+0xa7/0x170 filename_lookup+0xf7/0x200 ? set_ptes.isra.0+0x36/0x70 vfs_statx+0x7a/0x160 do_statx+0x63/0xa0 __x64_sys_statx+0x90/0xe0 do_syscall_64+0x82/0xae0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Please note bs > ps support is still under development and the enablement patch is not even in btrfs development branch. [CAUSE] Btrfs reuses its data folio read path to handle symbolic links, as the symbolic link target is stored as an inline data extent. But for newly created inodes, btrfs only set the minimal order if the target inode is a regular file. Thus for above newly created symbolic link, it doesn't properly respect the minimal folio order, and triggered the above crash. [FIX] Call btrfs_set_inode_mapping_order() unconditionally inside btrfs_create_new_inode(). For symbolic links this will fix the crash as now the folio will meet the minimal order. For regular files this brings no change. For directory/bdev/char and all the other types of inodes, they won't go through the data read path, thus no effect either. Fixes: cc38d178ff33 ("btrfs: enable large data folio support under CONFIG_BTRFS_EXPERIMENTAL") Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 01e852a53cb4d2ee564b10164ae8af836dc6c096 Author: Qu Wenruo Date: Thu Sep 18 08:40:45 2025 +0930 btrfs: return any hit error from extent_writepage_io() [ Upstream commit 2d83ed6c6c4607b42ee7927e92a9d2fa31d6f30b ] Since the support of bs < ps support, extent_writepage_io() will submit multiple blocks inside the folio. But if we hit error submitting one sector, but the next sector can still be submitted successfully, the function extent_writepage_io() will still return 0. This will make btrfs to silently ignore the error without setting error flag for the filemap. Fix it by recording the first error hit, and always return that value. Fixes: 8bf334beb349 ("btrfs: fix double accounting race when extent_writepage_io() failed") Reviewed-by: Daniel Vacek Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 44cd990ff390e11f559630ec6ef11cb3e1e19564 Author: Chen Ridong Date: Fri Sep 19 01:12:26 2025 +0000 cpuset: fix failure to enable isolated partition when containing isolcpus [ Upstream commit 216217ebee16afc4d79c3e86a736d87175c18e68 ] The 'isolcpus' parameter specified at boot time can be assigned to an isolated partition. While it is valid put the 'isolcpus' in an isolated partition, attempting to change a member cpuset to an isolated partition will fail if the cpuset contains any 'isolcpus'. For example, the system boots with 'isolcpus=9', and the following configuration works correctly: # cd /sys/fs/cgroup/ # mkdir test # echo 1 > test/cpuset.cpus # echo isolated > test/cpuset.cpus.partition # cat test/cpuset.cpus.partition isolated # echo 9 > test/cpuset.cpus # cat test/cpuset.cpus.partition isolated # cat test/cpuset.cpus 9 However, the following steps to convert a member cpuset to an isolated partition will fail: # cd /sys/fs/cgroup/ # mkdir test # echo 9 > test/cpuset.cpus # echo isolated > test/cpuset.cpus.partition # cat test/cpuset.cpus.partition isolated invalid (partition config conflicts with housekeeping setup) The issue occurs because the new partition state (new_prs) is used for validation against housekeeping constraints before it has been properly updated. To resolve this, move the assignment of new_prs before the housekeeping validation check when enabling a root partition. Fixes: 4a74e418881f ("cgroup/cpuset: Check partition conflict with housekeeping setup") Signed-off-by: Chen Ridong Reviewed-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 1341b78de3e6b51cc5494a26b88f3db6909661fb Author: Randy Dunlap Date: Sun Aug 24 15:28:00 2025 -0700 lsm: CONFIG_LSM can depend on CONFIG_SECURITY [ Upstream commit 54d94c422fed9575b74167333c1757847a4e6899 ] When CONFIG_SECURITY is not set, CONFIG_LSM (builtin_lsm_order) does not need to be visible and settable since builtin_lsm_order is defined in security.o, which is only built when CONFIG_SECURITY=y. So make CONFIG_LSM depend on CONFIG_SECURITY. Fixes: 13e735c0e953 ("LSM: Introduce CONFIG_LSM") Signed-off-by: Randy Dunlap [PM: subj tweak] Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 788bfdb55866beb0ddf0610f92ed1ed4928b8f05 Author: Peter Zijlstra Date: Mon Aug 25 12:02:44 2025 +0000 sched/fair: Get rid of sched_domains_curr_level hack for tl->cpumask() [ Upstream commit 661f951e371cc134ea31c84238dbdc9a898b8403 ] Leon [1] and Vinicius [2] noted a topology_span_sane() warning during their testing starting from v6.16-rc1. Debug that followed pointed to the tl->mask() for the NODE domain being incorrectly resolved to that of the highest NUMA domain. tl->mask() for NODE is set to the sd_numa_mask() which depends on the global "sched_domains_curr_level" hack. "sched_domains_curr_level" is set to the "tl->numa_level" during tl traversal in build_sched_domains() calling sd_init() but was not reset before topology_span_sane(). Since "tl->numa_level" still reflected the old value from build_sched_domains(), topology_span_sane() for the NODE domain trips when the span of the last NUMA domain overlaps. Instead of replicating the "sched_domains_curr_level" hack, get rid of it entirely and instead, pass the entire "sched_domain_topology_level" object to tl->cpumask() function to prevent such mishap in the future. sd_numa_mask() now directly references "tl->numa_level" instead of relying on the global "sched_domains_curr_level" hack to index into sched_domains_numa_masks[]. The original warning was reproducible on the following NUMA topology reported by Leon: $ sudo numactl -H available: 5 nodes (0-4) node 0 cpus: 0 1 node 0 size: 2927 MB node 0 free: 1603 MB node 1 cpus: 2 3 node 1 size: 3023 MB node 1 free: 3008 MB node 2 cpus: 4 5 node 2 size: 3023 MB node 2 free: 3007 MB node 3 cpus: 6 7 node 3 size: 3023 MB node 3 free: 3002 MB node 4 cpus: 8 9 node 4 size: 3022 MB node 4 free: 2718 MB node distances: node 0 1 2 3 4 0: 10 39 38 37 36 1: 39 10 38 37 36 2: 38 38 10 37 36 3: 37 37 37 10 36 4: 36 36 36 36 10 The above topology can be mimicked using the following QEMU cmd that was used to reproduce the warning and test the fix: sudo qemu-system-x86_64 -enable-kvm -cpu host \ -m 20G -smp cpus=10,sockets=10 -machine q35 \ -object memory-backend-ram,size=4G,id=m0 \ -object memory-backend-ram,size=4G,id=m1 \ -object memory-backend-ram,size=4G,id=m2 \ -object memory-backend-ram,size=4G,id=m3 \ -object memory-backend-ram,size=4G,id=m4 \ -numa node,cpus=0-1,memdev=m0,nodeid=0 \ -numa node,cpus=2-3,memdev=m1,nodeid=1 \ -numa node,cpus=4-5,memdev=m2,nodeid=2 \ -numa node,cpus=6-7,memdev=m3,nodeid=3 \ -numa node,cpus=8-9,memdev=m4,nodeid=4 \ -numa dist,src=0,dst=1,val=39 \ -numa dist,src=0,dst=2,val=38 \ -numa dist,src=0,dst=3,val=37 \ -numa dist,src=0,dst=4,val=36 \ -numa dist,src=1,dst=0,val=39 \ -numa dist,src=1,dst=2,val=38 \ -numa dist,src=1,dst=3,val=37 \ -numa dist,src=1,dst=4,val=36 \ -numa dist,src=2,dst=0,val=38 \ -numa dist,src=2,dst=1,val=38 \ -numa dist,src=2,dst=3,val=37 \ -numa dist,src=2,dst=4,val=36 \ -numa dist,src=3,dst=0,val=37 \ -numa dist,src=3,dst=1,val=37 \ -numa dist,src=3,dst=2,val=37 \ -numa dist,src=3,dst=4,val=36 \ -numa dist,src=4,dst=0,val=36 \ -numa dist,src=4,dst=1,val=36 \ -numa dist,src=4,dst=2,val=36 \ -numa dist,src=4,dst=3,val=36 \ ... [ prateek: Moved common functions to include/linux/sched/topology.h, reuse the common bits for s390 and ppc, commit message ] Closes: https://lore.kernel.org/lkml/20250610110701.GA256154@unreal/ [1] Fixes: ccf74128d66c ("sched/topology: Assert non-NUMA topology masks don't (partially) overlap") # ce29a7da84cd, f55dac1dafb3 Signed-off-by: Peter Zijlstra (Intel) Reported-by: Leon Romanovsky Signed-off-by: K Prateek Nayak Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider Reviewed-by: Shrikanth Hegde Tested-by: Valentin Schneider # x86 Tested-by: Shrikanth Hegde # powerpc Link: https://lore.kernel.org/lkml/a3de98387abad28592e6ab591f3ff6107fe01dc1.1755893468.git.tim.c.chen@linux.intel.com/ [2] Signed-off-by: Sasha Levin commit 3aef8ed912b99dca1708733733b0b0d6e0621add Author: Michal Koutný Date: Wed Aug 27 17:53:00 2025 +0200 selftests: cgroup: Make test_pids backwards compatible [ Upstream commit 3b0dec689a6301845761681b852f9538cb75a1d2 ] The predicates in test expect event counting from 73e75e6fc352b ("cgroup/pids: Separate semantics of pids.events related to pids.max") and the test would fail on older kernels. We want to have one version of tests for all, so detect the feature and skip the test on old kernels. (The test could even switch to check v1 semantics based on the flag but keep it simple for now.) Fixes: 9f34c566027b6 ("selftests: cgroup: Add basic tests for pids controller") Signed-off-by: Michal Koutný Tested-by: Sebastian Chlad Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit abee6d32c917ad769e396bd52c48a88fc0ed2879 Author: Uros Bizjak Date: Mon Jun 16 11:52:57 2025 +0200 x86/vdso: Fix output operand size of RDPID [ Upstream commit ac9c408ed19d535289ca59200dd6a44a6a2d6036 ] RDPID instruction outputs to a word-sized register (64-bit on x86_64 and 32-bit on x86_32). Use an unsigned long variable to store the correct size. LSL outputs to 32-bit register, use %k operand prefix to always print the 32-bit name of the register. Use RDPID insn mnemonic while at it as the minimum binutils version of 2.30 supports it. [ bp: Merge two patches touching the same function into a single one. ] Fixes: ffebbaedc861 ("x86/vdso: Introduce helper functions for CPU and node number") Signed-off-by: Uros Bizjak Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/20250616095315.230620-1-ubizjak@gmail.com Signed-off-by: Sasha Levin commit c6cca4213b618c92e4972919ee568f0fb87313b1 Author: Dapeng Mi Date: Wed Aug 20 10:30:27 2025 +0800 perf/x86/intel: Fix IA32_PMC_x_CFG_B MSRs access error [ Upstream commit 43796f30507802d93ead2dc44fc9637f34671a89 ] When running perf_fuzzer on PTL, sometimes the below "unchecked MSR access error" is seen when accessing IA32_PMC_x_CFG_B MSRs. [ 55.611268] unchecked MSR access error: WRMSR to 0x1986 (tried to write 0x0000000200000001) at rIP: 0xffffffffac564b28 (native_write_msr+0x8/0x30) [ 55.611280] Call Trace: [ 55.611282] [ 55.611284] ? intel_pmu_config_acr+0x87/0x160 [ 55.611289] intel_pmu_enable_acr+0x6d/0x80 [ 55.611291] intel_pmu_enable_event+0xce/0x460 [ 55.611293] x86_pmu_start+0x78/0xb0 [ 55.611297] x86_pmu_enable+0x218/0x3a0 [ 55.611300] ? x86_pmu_enable+0x121/0x3a0 [ 55.611302] perf_pmu_enable+0x40/0x50 [ 55.611307] ctx_resched+0x19d/0x220 [ 55.611309] __perf_install_in_context+0x284/0x2f0 [ 55.611311] ? __pfx_remote_function+0x10/0x10 [ 55.611314] remote_function+0x52/0x70 [ 55.611317] ? __pfx_remote_function+0x10/0x10 [ 55.611319] generic_exec_single+0x84/0x150 [ 55.611323] smp_call_function_single+0xc5/0x1a0 [ 55.611326] ? __pfx_remote_function+0x10/0x10 [ 55.611329] perf_install_in_context+0xd1/0x1e0 [ 55.611331] ? __pfx___perf_install_in_context+0x10/0x10 [ 55.611333] __do_sys_perf_event_open+0xa76/0x1040 [ 55.611336] __x64_sys_perf_event_open+0x26/0x30 [ 55.611337] x64_sys_call+0x1d8e/0x20c0 [ 55.611339] do_syscall_64+0x4f/0x120 [ 55.611343] entry_SYSCALL_64_after_hwframe+0x76/0x7e On PTL, GP counter 0 and 1 doesn't support auto counter reload feature, thus it would trigger a #GP when trying to write 1 on bit 0 of CFG_B MSR which requires to enable auto counter reload on GP counter 0. The root cause of causing this issue is the check for auto counter reload (ACR) counter mask from user space is incorrect in intel_pmu_acr_late_setup() helper. It leads to an invalid ACR counter mask from user space could be set into hw.config1 and then written into CFG_B MSRs and trigger the MSR access warning. e.g., User may create a perf event with ACR counter mask (config2=0xcb), and there is only 1 event created, so "cpuc->n_events" is 1. The correct check condition should be "i + idx >= cpuc->n_events" instead of "i + idx > cpuc->n_events" (it looks a typo). Otherwise, the counter mask would traverse twice and an invalid "cpuc->assign[1]" bit (bit 0) is set into hw.config1 and cause MSR accessing error. Besides, also check if the ACR counter mask corresponding events are ACR events. If not, filter out these counter mask. If a event is not a ACR event, it could be scheduled to an HW counter which doesn't support ACR. It's invalid to add their counter index in ACR counter mask. Furthermore, remove the WARN_ON_ONCE() since it's easily triggered as user could set any invalid ACR counter mask and the warning message could mislead users. Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/20250820023032.17128-3-dapeng1.mi@linux.intel.com Signed-off-by: Sasha Levin commit 55eeb8e974fb1a24118e74c1bf72a6c2c1a2c34b Author: Dapeng Mi Date: Wed Aug 20 10:30:26 2025 +0800 perf/x86/intel: Use early_initcall() to hook bts_init() [ Upstream commit d9cf9c6884d21e01483c4e17479d27636ea4bb50 ] After the commit 'd971342d38bf ("perf/x86/intel: Decouple BTS initialization from PEBS initialization")' is introduced, x86_pmu.bts would initialized in bts_init() which is hooked by arch_initcall(). Whereas init_hw_perf_events() is hooked by early_initcall(). Once the core PMU is initialized, nmi watchdog initialization is called immediately before bts_init() is called. It leads to the BTS buffer is not really initialized since bts_init() is not called and x86_pmu.bts is still false at that time. Worse, BTS buffer would never be initialized then unless all core PMU events are freed and reserve_ds_buffers() is called again. Thus aligning with init_hw_perf_events(), use early_initcall() to hook bts_init() to ensure x86_pmu.bts is initialized before nmi watchdog initialization. Fixes: d971342d38bf ("perf/x86/intel: Decouple BTS initialization from PEBS initialization") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/20250820023032.17128-2-dapeng1.mi@linux.intel.com Signed-off-by: Sasha Levin commit c20da24272f1ac79e9f9083bba577d049cd02bbb Author: Qiuxu Zhuo Date: Wed Aug 6 14:57:07 2025 +0800 EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller [ Upstream commit 2e6fe1bbefd9c059c3787d1c620fe67343a94dff ] When loading the i10nm_edac driver on some Intel Granite Rapids servers, a call trace may appear as follows: UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16 shift exponent -66 is negative ... __ubsan_handle_shift_out_of_bounds+0x1e3/0x390 skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common] i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac] skx_register_mci+0x159/0x220 [skx_edac_common] i10nm_init+0xcb0/0x1ff0 [i10nm_edac] ... This occurs because some BIOS may disable a memory controller if there aren't any memory DIMMs populated on this memory controller. The DIMMMTR register of this disabled memory controller contains the invalid value ~0, resulting in the call trace above. Fix this call trace by skipping DIMM enumeration on a disabled memory controller. Fixes: ba987eaaabf9 ("EDAC/i10nm: Add Intel Granite Rapids server support") Reported-by: Jose Jesus Ambriz Meza Reported-by: Chia-Lin Kao (AceLan) Closes: https://lore.kernel.org/all/20250730063155.2612379-1-acelan.kao@canonical.com/ Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Tested-by: Chia-Lin Kao (AceLan) Link: https://lore.kernel.org/r/20250806065707.3533345-1-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 367e0a75521639a9f9c7c610cce509d66beee78b Author: Stefan Metzmacher Date: Wed Aug 20 15:34:58 2025 +0200 smb: server: fix IRD/ORD negotiation with the client [ Upstream commit fad988a2158d743da7971884b93482a73735b25e ] Already do real negotiation in smb_direct_handle_connect_request() where we see the requested initiator_depth and responder_resources from the client. We should detect legacy iwarp clients using MPA v1 with the custom IRD/ORD negotiation. We need to send the custom IRD/ORD in big endian, but we need to try to let clients with broken requests using little endian (older cifs.ko) to work. Note the reason why this uses u8 for initiator_depth and responder_resources is that the rdma layer also uses it. Acked-by: Namjae Jeon Cc: Steve French Cc: Tom Talpey Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Cc: linux-rdma@vger.kernel.org Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Sasha Levin commit bcc41cc9bcb869743b91f8987c021f6cf80f1849 Author: Stefan Metzmacher Date: Wed Aug 20 11:25:06 2025 +0200 smb: client: fix sending the iwrap custom IRD/ORD negotiation messages [ Upstream commit ef71f1e046489c77a2f7d012edc762fba0a7aadc ] Do a real negotiation and check the servers initiator_depth and responder_resources. This should use big endian in order to be useful. I have captures of windows clients showing this. The fact that we used little endian up to now means that we sent very large numbers and the negotiation with the server truncated them to the server limits. Note the reason why this uses u8 for initiator_depth and responder_resources is that the rdma layer also uses it. The inconsitency regarding the initiator_depth and responder_resources values being reversed for iwarp devices in RDMA_CM_EVENT_ESTABLISHED should also be fixed later, but for now we should fix it. Cc: Steve French Cc: Tom Talpey Cc: Long Li Acked-by: Namjae Jeon Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Cc: linux-rdma@vger.kernel.org Fixes: c7398583340a ("CIFS: SMBD: Implement RDMA memory registration") Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Sasha Levin commit f9e69b33fd5b236639edb704f9c4b10b99133387 Author: Gao Xiang Date: Tue Sep 16 16:48:51 2025 +0800 erofs: avoid reading more for fragment maps [ Upstream commit 334c0e493c2aa3e843a80bb9f3862bb50360cb36 ] Since all real encoded extents (directly handled by the decompression subsystem) have a sane, limited maximum decoded length (Z_EROFS_PCLUSTER_MAX_DSIZE), and the read-more policy is only applied if needed. However, it makes no sense to read more for non-encoded maps, such as fragment extents, since such extents can be huge (up to i_size) and there is no benefit to reading more at this layer. For normal images, it does not really matter, but for crafted images generated by syzbot, excessively large fragment extents can cause read-more to run for an overly long time. Reported-and-tested-by: syzbot+1a9af3ef3c84c5e14dcc@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/68c8583d.050a0220.2ff435.03a3.GAE@google.com Fixes: b44686c8391b ("erofs: fix large fragment handling") Fixes: b15b2e307c3a ("erofs: support on-disk compressed fragments data") Reviewed-by: Hongbo Li Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit e516cfd19b0f4c774a57b17fb43a7f41991f0735 Author: Leo Yan Date: Wed Sep 17 18:41:39 2025 +0100 perf: arm_spe: Prevent overflow in PERF_IDX2OFF() [ Upstream commit a29fea30dd93da16652930162b177941abd8c75e ] Cast nr_pages to unsigned long to avoid overflow when handling large AUX buffer sizes (>= 2 GiB). Fixes: d5d9696b0380 ("drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension") Signed-off-by: Leo Yan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 637f28a25b1b840dfbc704d2543c7dcb63126239 Author: Leo Yan Date: Wed Sep 17 18:41:38 2025 +0100 coresight: trbe: Prevent overflow in PERF_IDX2OFF() [ Upstream commit 105f56877f2d5f82d71e20b45eb7be7c24c3d908 ] Cast nr_pages to unsigned long to avoid overflow when handling large AUX buffer sizes (>= 2 GiB). Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") Signed-off-by: Leo Yan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit a64fa670fadac591cf583b855313e2623c0d6dc4 Author: Chunyan Zhang Date: Fri Jul 18 15:27:07 2025 +0800 raid6: riscv: Clean up unused header file inclusion [ Upstream commit f8a03516a530cc36bc9015c84ba7540ee3e8d7bd ] These two C files don't reference things defined in simd.h or types.h so remove these redundant #inclusions. Fixes: 6093faaf9593 ("raid6: Add RISC-V SIMD syndrome and recovery calculations") Reviewed-by: Alexandre Ghiti Signed-off-by: Chunyan Zhang Reviewed-by: Nutty Liu Link: https://lore.kernel.org/r/20250718072711.3865118-2-zhangchunyan@iscas.ac.cn Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 7aa71979325dd8593a51daed5e4f1623e62b798c Author: Jeremy Linton Date: Sun Aug 24 22:34:21 2025 -0500 uprobes: uprobe_warn should use passed task [ Upstream commit ba1afc94deb849eab843a372b969444581add2c9 ] uprobe_warn() is passed a task structure, yet its using current. For the most part this shouldn't matter, but since a task structure is provided, lets use it. Fixes: 248d3a7b2f10 ("uprobes: Change uprobe_copy_process() to dup return_instances") Signed-off-by: Jeremy Linton Reviewed-by: Catalin Marinas Acked-by: Oleg Nesterov Acked-by: Masami Hiramatsu (Google) Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 51ef689814fd9fc6c0c9a6ef183505c698f0972e Author: Joe Lawrence Date: Fri Sep 12 10:27:39 2025 -0400 powerpc64/modules: correctly iterate over stubs in setup_ftrace_ool_stubs [ Upstream commit f6b4df37ebfeb47e50e27780500d2d06b4d211bd ] CONFIG_PPC_FTRACE_OUT_OF_LINE introduced setup_ftrace_ool_stubs() to extend the ppc64le module .stubs section with an array of ftrace_ool_stub structures for each patchable function. Fix its ppc64_stub_entry stub reservation loop to properly write across all of the num_stubs used and not just the first entry. Fixes: eec37961a56a ("powerpc64/ftrace: Move ftrace sequence out of line") Signed-off-by: Joe Lawrence Acked-by: Naveen N Rao (AMD) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250912142740.3581368-3-joe.lawrence@redhat.com Signed-off-by: Sasha Levin commit 77d54506fb6689045fa21c56785cbaa0c60ff0c5 Author: Joe Lawrence Date: Fri Sep 12 10:27:38 2025 -0400 powerpc/ftrace: ensure ftrace record ops are always set for NOPs [ Upstream commit 5337609a314828aa2474ac359db615f475c4a4d2 ] When an ftrace call site is converted to a NOP, its corresponding dyn_ftrace record should have its ftrace_ops pointer set to ftrace_nop_ops. Correct the powerpc implementation to ensure the ftrace_rec_set_nop_ops() helper is called on all successful NOP initialization paths. This ensures all ftrace records are consistent before being handled by the ftrace core. Fixes: eec37961a56a ("powerpc64/ftrace: Move ftrace sequence out of line") Suggested-by: Naveen N Rao Signed-off-by: Joe Lawrence Acked-by: Naveen N Rao (AMD) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250912142740.3581368-2-joe.lawrence@redhat.com Signed-off-by: Sasha Levin commit d5cd6ff51ed7b2ba038f2a09cdc781a922289402 Author: Christophe Leroy Date: Thu Aug 21 08:30:18 2025 +0200 powerpc/603: Really copy kernel PGD entries into all PGDIRs [ Upstream commit f2863371f017eb03c230addc253783fa4c7e90f5 ] Commit 82ef440f9a38 ("powerpc/603: Copy kernel PGD entries into all PGDIRs and preallocate execmem page tables") was supposed to extend to powerpc 603 the copy of kernel PGD entries into all PGDIRs implemented in a previous patch on the 8xx. But 603 is book3s/32 and uses a duplicate of pgd_alloc() defined in another header. So really do the copy at the correct place for the 603. Fixes: 82ef440f9a38 ("powerpc/603: Copy kernel PGD entries into all PGDIRs and preallocate execmem page tables") Signed-off-by: Christophe Leroy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/752ab7514cae089a2dd7cc0f3d5e35849f76adb9.1755757797.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 0b8e4e9e0d798f0e8e486cc0c6881619b189f7fa Author: Christophe Leroy Date: Sat Aug 16 18:33:26 2025 +0200 powerpc/8xx: Remove left-over instruction and comments in DataStoreTLBMiss handler [ Upstream commit d9e46de4bf5c5f987075afd5f240bb2a8a5d71ed ] Commit ac9f97ff8b32 ("powerpc/8xx: Inconditionally use task PGDIR in DTLB misses") removed the test that needed the valeur in SPRN_EPN but failed to remove the read. Remove it. And remove related comments, including the very same comment in InstructionTLBMiss that should have been removed by commit 33c527522f39 ("powerpc/8xx: Inconditionally use task PGDIR in ITLB misses"). Also update the comment about absence of a second level table which has been handled implicitely since commit 5ddb75cee5af ("powerpc/8xx: remove tests on PGDIR entry validity"). Fixes: ac9f97ff8b32 ("powerpc/8xx: Inconditionally use task PGDIR in DTLB misses") Signed-off-by: Christophe Leroy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/5811c8d1d6187f280ad140d6c0ad6010e41eeaeb.1755361995.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 10648e179cfbcb3ff68d5602b2194df11cfda146 Author: Andreas Gruenbacher Date: Mon Jul 7 14:31:41 2025 +0200 gfs2: Add proper lockspace locking [ Upstream commit 6ab26555c9ffef96c56ca16356e55ac5ab61ec93 ] GFS2 has been calling functions like dlm_lock() even after the lockspace that these functions operate on has been released with dlm_release_lockspace(). It has always assumed that those functions would return -EINVAL in that case, but that was never guaranteed, and it certainly is no longer the case since commit 4db41bf4f04f ("dlm: remove ls_local_handle from struct dlm_ls"). To fix that, add proper lockspace locking. Fixes: 3e11e5304150 ("GFS2: ignore unlock failures after withdraw") Signed-off-by: Andreas Gruenbacher Reviewed-by: Andrew Price Signed-off-by: Sasha Levin commit f955c063f69bb4d4b3d7341ede4503bb655ecc12 Author: Andreas Gruenbacher Date: Tue Jul 8 19:13:32 2025 +0200 gfs2: do_xmote cleanup [ Upstream commit 2309a01351e56446f43c89e200d643647d47e739 ] Check for asynchronous completion and clear the GLF_PENDING_REPLY flag earlier in do_xmote(). This will make future changes more readable. Signed-off-by: Andreas Gruenbacher Reviewed-by: Andrew Price Stable-dep-of: 6ab26555c9ff ("gfs2: Add proper lockspace locking") Signed-off-by: Sasha Levin commit 7d8569f57ca7e043061516b5573468d54ab18d70 Author: Andreas Gruenbacher Date: Fri Aug 8 23:26:12 2025 +0200 gfs2: Get rid of GLF_INVALIDATE_IN_PROGRESS [ Upstream commit bddb53b776fb7ce81dfba7c24884d9f2c0c68e50 ] Get rid of the GLF_INVALIDATE_IN_PROGRESS flag: it was originally used to indicate to add_to_queue() that the ->go_sync() and ->go_invalid() operations were in progress, but as we have established in commit "gfs2: Fix LM_FLAG_TRY* logic in add_to_queue", add_to_queue() has no need to know. Commit d99724c3c36a describes a race in which GLF_INVALIDATE_IN_PROGRESS is used to serialize two processes which are both in do_xmote() at the same time. That analysis is wrong: the serialization happens via the GLF_LOCK flag, which ensures that at most one glock operation can be active at any time. Fixes: d99724c3c36a ("gfs2: Close timing window with GLF_INVALIDATE_IN_PROGRESS") Signed-off-by: Andreas Gruenbacher Reviewed-by: Andrew Price Signed-off-by: Sasha Levin commit de50f8bbd02554c8241d25e2642a52db402bf873 Author: Andreas Gruenbacher Date: Fri Aug 8 23:18:45 2025 +0200 gfs2: Remove duplicate check in do_xmote [ Upstream commit 9b54770b68ae793a3a8d378be4cda2bb7be6c8cc ] In do_xmote(), remove the duplicate check for the ->go_sync and ->go_inval glock operations. They are either both defined, or none of them are. Signed-off-by: Andreas Gruenbacher Reviewed-by: Andrew Price Stable-dep-of: bddb53b776fb ("gfs2: Get rid of GLF_INVALIDATE_IN_PROGRESS") Signed-off-by: Sasha Levin commit d6474a63dc9b3328def7967eee9d9db4e9f63c30 Author: Andreas Gruenbacher Date: Fri Aug 8 22:31:59 2025 +0200 gfs2: Fix LM_FLAG_TRY* logic in add_to_queue [ Upstream commit 0c23e24164d83086e75581b0cf930f4e161636d6 ] The logic in add_to_queue() for determining whether a LM_FLAG_TRY or LM_FLAG_TRY_1CB holder should be queued does not make any sense: we are interested in wether or not the new operation will block behind an existing or future holder in the queue, but the current code checks for ongoing locking or ->go_inval() operations, which has little to do with that. Replace that code with something more sensible, remove the incorrect add_to_queue() function annotations, remove the similarly misguided do_error(gl, 0) call in do_xmote(), and add a missing comment to the same call in do_promote(). Signed-off-by: Andreas Gruenbacher Reviewed-by: Andrew Price Stable-dep-of: bddb53b776fb ("gfs2: Get rid of GLF_INVALIDATE_IN_PROGRESS") Signed-off-by: Sasha Levin commit b53e44eb339ff54240ce450bb6ebd972ded58354 Author: Andreas Gruenbacher Date: Thu Aug 7 10:21:33 2025 +0200 gfs2: Further sanitize lock_dlm.c [ Upstream commit fd70ab7155c4b92a9747d42c02791a0793ab9c66 ] The gl_req field and GLF_BLOCKING flag are only relevant to gdlm_lock(), its callback gdlm_ast(), and their helpers, so set and clear them inside lock_dlm.c. Also, the LM_FLAG_ANY flag is relevant to gdlm_lock(), but do_xmote() doesn't pass that flag down to gdlm_lock() as it should. Fix that by passing down all the flags. In addition, document the effect of the LM_FLAG_ANY flag on locks held in EX mode locally. Signed-off-by: Andreas Gruenbacher Reviewed-by: Andrew Price Stable-dep-of: bddb53b776fb ("gfs2: Get rid of GLF_INVALIDATE_IN_PROGRESS") Signed-off-by: Sasha Levin commit 1bb09326c4793d4e83ab8ec8afac1786c9e1277d Author: Colin Ian King Date: Tue Jul 29 12:36:38 2025 +0100 gfs2: Remove space before newline [ Upstream commit aa94ad9ab230d08741e6630a20fd1296b52c1009 ] There is an extraneous space before a newline in a fs_err message. Remove it Signed-off-by: Colin Ian King Signed-off-by: Andreas Gruenbacher Reviewed-by: Andrew Price Stable-dep-of: bddb53b776fb ("gfs2: Get rid of GLF_INVALIDATE_IN_PROGRESS") Signed-off-by: Sasha Levin commit 559bbcdb23862f60e105794fe330e389860a4fbf Author: Andreas Gruenbacher Date: Sat Aug 2 23:57:24 2025 +0200 gfs2: Fix GLF_INVALIDATE_IN_PROGRESS flag clearing in do_xmote [ Upstream commit 061df28b82af6b22fb5fa529a8f2ef00474ee004 ] Commit 865cc3e9cc0b ("gfs2: fix a deadlock on withdraw-during-mount") added a statement to do_xmote() to clear the GLF_INVALIDATE_IN_PROGRESS flag a second time after it has already been cleared. Fix that. Fixes: 865cc3e9cc0b ("gfs2: fix a deadlock on withdraw-during-mount") Signed-off-by: Andreas Gruenbacher Reviewed-by: Andrew Price Signed-off-by: Sasha Levin commit 857aefc70d4ae3b9bf1ae67434d27d0f79f80c9e Author: Kang Chen Date: Tue Sep 9 11:13:16 2025 +0800 hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc() [ Upstream commit bea3e1d4467bcf292c8e54f080353d556d355e26 ] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290 CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x5f0 mm/kasan/report.c:482 kasan_report+0xca/0x100 mm/kasan/report.c:595 hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe0e9fae16d Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3 RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000 RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000 Allocated by task 14290: kasan_save_stack+0x24/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4333 [inline] __kmalloc_noprof+0x219/0x540 mm/slub.c:4345 kmalloc_noprof include/linux/slab.h:909 [inline] hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21 hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f When hfsplus_uni2asc is called from hfsplus_listxattr, it actually passes in a struct hfsplus_attr_unistr*. The size of the corresponding structure is different from that of hfsplus_unistr, so the previous fix (94458781aee6) is insufficient. The pointer on the unicode buffer is still going beyond the allocated memory. This patch introduces two warpper functions hfsplus_uni2asc_xattr_str and hfsplus_uni2asc_str to process two unicode buffers, struct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively. When ustrlen value is bigger than the allocated memory size, the ustrlen value is limited to an safe size. Fixes: 94458781aee6 ("hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()") Signed-off-by: Kang Chen Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20250909031316.1647094-1-k.chen@smail.nju.edu.cn Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 2714a1ead2448616e2126e94974bb39574655b3c Author: Thomas Weißschuh Date: Thu Aug 21 17:13:02 2025 +0200 kselftest/arm64/gcs: Correctly check return value when disabling GCS [ Upstream commit 740cdafd0d998903c1faeee921028a8a78698be5 ] The return value was not assigned to 'ret', so the check afterwards does not do anything. Fixes: 3d37d4307e0f ("kselftest/arm64: Add very basic GCS test program") Signed-off-by: Thomas Weißschuh Reviewed-by: Mark Brown Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 8262b855cb717ab39218b532c55ad9b77f294fd8 Author: Bala-Vignesh-Reddy Date: Thu Aug 7 17:12:29 2025 +0530 selftests: arm64: Fix -Waddress warning in tpidr2 test [ Upstream commit 50af02425afc72b1b47c4a0a0b9c9bdaa1a1b347 ] Thanks to -Waddress, the compiler warns that the ksft_test_result() invocations in the arm64 tpidr2 selftest are always true. Oops. Fix the test by, err, actually running the test functions. Fixes: 6d80cb73131d ("kselftest/arm64: Convert tpidr2 test to use kselftest.h") Signed-off-by: Bala-Vignesh-Reddy Reviewed-by: Anshuman Khandual Reviewed-by: Mark Brown Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 281a6ef42885a692356f67795c9721f2154efd4d Author: Bala-Vignesh-Reddy Date: Fri Aug 8 13:38:30 2025 +0530 selftests: arm64: Check fread return value in exec_target [ Upstream commit a679e5683d3eef22ca12514ff8784b2b914ebedc ] Fix -Wunused-result warning generated when compiled with gcc 13.3.0, by checking fread's return value and handling errors, preventing potential failures when reading from stdin. Fixes compiler warning: warning: ignoring return value of 'fread' declared with attribute 'warn_unused_result' [-Wunused-result] Fixes: 806a15b2545e ("kselftests/arm64: add PAuth test for whether exec() changes keys") Signed-off-by: Bala-Vignesh-Reddy Reviewed-by: Mark Brown Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit f55dfbdce49955cc29cd855a4bde62b239992fa5 Author: Kienan Stewart Date: Tue Feb 18 15:26:39 2025 -0500 kbuild: Add missing $(objtree) prefix to powerpc crtsavres.o artifact [ Upstream commit 46104a7d3ccd2acfe508e661393add0615c27a22 ] In the upstream commit 214c0eea43b2ea66bcd6467ea57e47ce8874191b ("kbuild: add $(objtree)/ prefix to some in-kernel build artifacts") artifacts required for building out-of-tree kernel modules had $(objtree) prepended to them to prepare for building in other directories. When building external modules for powerpc, arch/powerpc/lib/crtsavres.o is required for certain configurations. This artifact is missing the prepended $(objtree). Fixes: 13b25489b6f8 ("kbuild: change working directory to external module directory with M=") Acked-by: Masahiro Yamada Reviewed-by: Nicolas Schier Tested-by: Nicolas Schier Signed-off-by: Kienan Stewart Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250218-buildfix-extmod-powerpc-v2-1-1e78fcf12b56@efficios.com Signed-off-by: Sasha Levin commit 7724b4cc5e8bcdfc9eea65e6d556ddc6d1bd34cb Author: Johannes Nixdorf Date: Fri Jul 25 18:31:18 2025 +0200 seccomp: Fix a race with WAIT_KILLABLE_RECV if the tracer replies too fast [ Upstream commit cce436aafc2abad691fdd37de63ec8a4490b42ce ] Normally the tracee starts in SECCOMP_NOTIFY_INIT, sends an event to the tracer, and starts to wait interruptibly. With SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV, if the tracer receives the message (SECCOMP_NOTIFY_SENT is reached) while the tracee was waiting and is subsequently interrupted, the tracee begins to wait again uninterruptibly (but killable). This fails if SECCOMP_NOTIFY_REPLIED is reached before the tracee is interrupted, as the check only considered SECCOMP_NOTIFY_SENT as a condition to begin waiting again. In this case the tracee is interrupted even though the tracer already acted on its behalf. This breaks the assumption SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV wanted to ensure, namely that the tracer can be sure the syscall is not interrupted or restarted on the tracee after it is received on the tracer. Fix this by also considering SECCOMP_NOTIFY_REPLIED when evaluating whether to switch to uninterruptible waiting. With the condition changed the loop in seccomp_do_user_notification() would exit immediately after deciding that noninterruptible waiting is required if the operation already reached SECCOMP_NOTIFY_REPLIED, skipping the code that processes pending addfd commands first. Prevent this by executing the remaining loop body one last time in this case. Fixes: c2aa2dfef243 ("seccomp: Add wait_killable semantic to seccomp user notifier") Reported-by: Ali Polatel Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220291 Signed-off-by: Johannes Nixdorf Link: https://lore.kernel.org/r/20250725-seccomp-races-v2-1-cf8b9d139596@nixdorf.dev Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 5cd2217774476d7e6c85d55f3bf1a9cd4e730a3c Author: Linus Torvalds Date: Mon Sep 29 08:54:12 2025 -0700 Fix CC_HAS_ASM_GOTO_OUTPUT on non-x86 architectures [ Upstream commit fde0ab43b9a30d08817adc5402b69fec83a61cb8 ] There's a silly problem with the CC_HAS_ASM_GOTO_OUTPUT test: even with a working compiler it will fail on some architectures simply because it uses the mnemonic "jmp" for testing the inline asm. And as reported by Geert, not all architectures use that mnemonic, so the test fails spuriously on such platforms (including arm and riscv, but also several other architectures). This issue avoided any obvious test failures because the build still works thanks to falling back on the old non-asm-goto code, which just generates worse code. Just use an empty asm statement instead. Reported-and-tested-by: Geert Uytterhoeven Suggested-by: Peter Zijlstra Fixes: e2ffa15b9baa ("kbuild: Disable CC_HAS_ASM_GOTO_OUTPUT on clang < 17") Cc: Nathan Chancellor Cc: Thomas Gleixner Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9ad318d8655d26293cc23ad3fced185c61861dab Author: Christian Göttsche Date: Wed Sep 10 21:26:05 2025 +0200 pid: use ns_capable_noaudit() when determining net sysctl permissions [ Upstream commit b9cb7e59ac4ae68940347ebfc41e0436d32d3c6e ] The capability check should not be audited since it is only being used to determine the inode permissions. A failed check does not indicate a violation of security policy but, when an LSM is enabled, a denial audit message was being generated. The denial audit message can either lead to the capability being unnecessarily allowed in a security policy, or being silenced potentially masking a legitimate capability check at a later point in time. Similar to commit d6169b0206db ("net: Use ns_capable_noaudit() when determining net sysctl permissions") Fixes: 7863dcc72d0f ("pid: allow pid_max to be set per pid namespace") CC: Christian Brauner CC: linux-security-module@vger.kernel.org CC: selinux@vger.kernel.org Signed-off-by: Christian Göttsche Acked-by: Serge Hallyn Reviewed-by: Paul Moore Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 92a8931b1ed854239eca3dad824710f0735141c5 Author: Geert Uytterhoeven Date: Mon Sep 15 09:11:05 2025 +0200 init: INITRAMFS_PRESERVE_MTIME should depend on BLK_DEV_INITRD [ Upstream commit 74792608606a525a0e0df7e8d48acd8000561389 ] INITRAMFS_PRESERVE_MTIME is only used in init/initramfs.c and init/initramfs_test.c. Hence add a dependency on BLK_DEV_INITRD, to prevent asking the user about this feature when configuring a kernel without initramfs support. Fixes: 1274aea127b2e8c9 ("initramfs: add INITRAMFS_PRESERVE_MTIME Kconfig option") Signed-off-by: Geert Uytterhoeven Reviewed-by: Martin Wilck Reviewed-by: David Disseldorp Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 7cbdf35384dae1fcceb6319c2f9cbd0e5ce89fa5 Author: Jeff Layton Date: Wed Sep 3 11:23:33 2025 -0400 filelock: add FL_RECLAIM to show_fl_flags() macro [ Upstream commit c593b9d6c446510684da400833f9d632651942f0 ] Show the FL_RECLAIM flag symbolically in tracepoints. Fixes: bb0a55bb7148 ("nfs: don't allow reexport reclaims") Signed-off-by: Jeff Layton Link: https://lore.kernel.org/20250903-filelock-v1-1-f2926902962d@kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit e0d6fb7923c538e279a3433ef441032de2c516f4 Author: Simon Schuster Date: Mon Sep 1 15:09:52 2025 +0200 arch: copy_thread: pass clone_flags as u64 [ Upstream commit bbc46b23af5bb934cd1cf066ef4342cee457a24e ] With the introduction of clone3 in commit 7f192e3cd316 ("fork: add clone3") the effective bit width of clone_flags on all architectures was increased from 32-bit to 64-bit, with a new type of u64 for the flags. However, for most consumers of clone_flags the interface was not changed from the previous type of unsigned long. While this works fine as long as none of the new 64-bit flag bits (CLONE_CLEAR_SIGHAND and CLONE_INTO_CGROUP) are evaluated, this is still undesirable in terms of the principle of least surprise. Thus, this commit fixes all relevant interfaces of the copy_thread function that is called from copy_process to consistently pass clone_flags as u64, so that no truncation to 32-bit integers occurs on 32-bit architectures. Signed-off-by: Simon Schuster Link: https://lore.kernel.org/20250901-nios2-implement-clone3-v2-3-53fcf5577d57@siemens-energy.com Fixes: c5febea0956fd387 ("fork: Pass struct kernel_clone_args into copy_thread") Acked-by: Guo Ren (Alibaba Damo Academy) Acked-by: Andreas Larsson # sparc Acked-by: David Hildenbrand Acked-by: Geert Uytterhoeven # m68k Reviewed-by: Arnd Bergmann Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin