Author: Thorsten Blum <[email protected]> Date: Wed Aug 21 01:10:28 2024 +0200 accel/habanalabs/gaudi2: Use kvfree() for memory allocated with kvcalloc() commit a44458dfd5bc0c79c6739c3f4c658361d3a5126b upstream. Use kvfree() to fix the following Coccinelle/coccicheck warning reported by kfree_mismatch.cocci: WARNING kvmalloc is used to allocate this memory at line 10398 Fixes: f728c17fc97a ("accel/habanalabs/gaudi2: move HMMU page tables to device memory") Reported-by: Qianfeng Rong <[email protected]> Closes: https://patch.msgid.link/[email protected] Signed-off-by: Thorsten Blum <[email protected]> [lukas: acknowledge Qianfeng, adjust Thorsten's domain, add Fixes tag] Signed-off-by: Lukas Wunner <[email protected]> Reviewed-by: Tomer Tayar <[email protected]> Cc: [email protected] # v6.9+ Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Thu Aug 14 07:11:57 2025 +0200 ACPI: APEI: EINJ: Fix resource leak by remove callback in .exit.text commit b21d1fbb97c814c76ffa392cd603f8cd3ecc0355 upstream. The .remove() callback is also used during error handling in faux_probe(). As einj_remove() was marked with __exit it's not linked into the kernel if the driver is built-in, potentially resulting in resource leaks. Also remove the comment justifying the __exit annotation which doesn't apply any more since the driver was converted to the faux device interface. Fixes: 6cb9441bfe8d ("ACPI: APEI: EINJ: Transition to the faux device interface") Signed-off-by: Uwe Kleine-König <[email protected]> Cc: 6.16+ <[email protected]> # 6.16+ Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chen Yu <[email protected]> Date: Tue Jul 22 22:32:33 2025 +0800 ACPI: pfr_update: Fix the driver update version check commit 8151320c747efb22d30b035af989fed0d502176e upstream. The security-version-number check should be used rather than the runtime version check for driver updates. Otherwise, the firmware update would fail when the update binary had a lower runtime version number than the current one. Fixes: 0db89fa243e5 ("ACPI: Introduce Platform Firmware Runtime Update device driver") Cc: 5.17+ <[email protected]> # 5.17+ Reported-by: "Govindarajulu, Hariganesh" <[email protected]> Signed-off-by: Chen Yu <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Evgeniy Harchenko <[email protected]> Date: Fri Aug 15 12:58:14 2025 +0300 ALSA: hda/realtek: Add support for HP EliteBook x360 830 G6 and EliteBook 830 G6 commit eafae0fdd115a71b3a200ef1a31f86da04bac77f upstream. The HP EliteBook x360 830 G6 and HP EliteBook 830 G6 have Realtek HDA codec ALC215. It needs the ALC285_FIXUP_HP_GPIO_LED quirk to enable the mute LED. Cc: <[email protected]> Signed-off-by: Evgeniy Harchenko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Wed Aug 20 07:19:01 2025 +0200 ALSA: hda: tas2781: Fix wrong reference of tasdevice_priv commit 3f4422e7c9436abf81a00270be7e4d6d3760ec0e upstream. During the conversion to unify the calibration data management, the reference to tasdevice_priv was wrongly set to h->hda_priv instead of h->priv. This resulted in memory corruption and crashes eventually. Unfortunately it's a void pointer, hence the compiler couldn't know that it's wrong. Fixes: 4fe238513407 ("ALSA: hda/tas2781: Move and unified the calibrated-data getting function for SPI and I2C into the tas2781_hda lib") Link: https://bugzilla.suse.com/show_bug.cgi?id=1248270 Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dewei Meng <[email protected]> Date: Thu Aug 21 09:43:17 2025 +0800 ALSA: timer: fix ida_free call while not allocated [ Upstream commit 5003a65790ed66be882d1987cc2ca86af0de3db1 ] In the snd_utimer_create() function, if the kasprintf() function return NULL, snd_utimer_put_id() will be called, finally use ida_free() to free the unallocated id 0. the syzkaller reported the following information: ------------[ cut here ]------------ ida_free called for id=0 which is not allocated. WARNING: CPU: 1 PID: 1286 at lib/idr.c:592 ida_free+0x1fd/0x2f0 lib/idr.c:592 Modules linked in: CPU: 1 UID: 0 PID: 1286 Comm: syz-executor164 Not tainted 6.15.8 #3 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014 RIP: 0010:ida_free+0x1fd/0x2f0 lib/idr.c:592 Code: f8 fc 41 83 fc 3e 76 69 e8 70 b2 f8 (...) RSP: 0018:ffffc900007f79c8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 1ffff920000fef3b RCX: ffffffff872176a5 RDX: ffff88800369d200 RSI: 0000000000000000 RDI: ffff88800369d200 RBP: 0000000000000000 R08: ffffffff87ba60a5 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f6f1abc1740(0000) GS:ffff8880d76a0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6f1ad7a784 CR3: 000000007a6e2000 CR4: 00000000000006f0 Call Trace: <TASK> snd_utimer_put_id sound/core/timer.c:2043 [inline] [snd_timer] snd_utimer_create+0x59b/0x6a0 sound/core/timer.c:2184 [snd_timer] snd_utimer_ioctl_create sound/core/timer.c:2202 [inline] [snd_timer] __snd_timer_user_ioctl.isra.0+0x724/0x1340 sound/core/timer.c:2287 [snd_timer] snd_timer_user_ioctl+0x75/0xc0 sound/core/timer.c:2298 [snd_timer] vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x198/0x200 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x7b/0x160 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] The utimer->id should be set properly before the kasprintf() function, ensures the snd_utimer_put_id() function will free the allocated id. Fixes: 37745918e0e75 ("ALSA: timer: Introduce virtual userspace-driven timers") Signed-off-by: Dewei Meng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Mon Aug 18 12:59:45 2025 +0300 ALSA: usb-audio: Fix size validation in convert_chmap_v3() [ Upstream commit 89f0addeee3cb2dc49837599330ed9c4612f05b0 ] The "p" pointer is void so sizeof(*p) is 1. The intent was to check sizeof(*cs_desc), which is 3, instead. Fixes: ecfd41166b72 ("ALSA: usb-audio: Validate UAC3 cluster segment descriptors") Signed-off-by: Dan Carpenter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Thu Aug 21 17:08:34 2025 +0200 ALSA: usb-audio: Use correct sub-type for UAC3 feature unit validation [ Upstream commit 8410fe81093ff231e964891e215b624dabb734b0 ] The entry of the validators table for UAC3 feature unit is defined with a wrong sub-type UAC_FEATURE (= 0x06) while it should have been UAC3_FEATURE (= 0x07). This patch corrects the entry value. Fixes: 57f8770620e9 ("ALSA: usb-audio: More validations of descriptor units") Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xaver Hugl <[email protected]> Date: Fri Aug 1 00:49:51 2025 +0200 amdgpu/amdgpu_discovery: increase timeout limit for IFWI init commit 928587381b54b1b6c62736486b1dc6cb16c568c2 upstream. With a timeout of only 1 second, my rx 5700XT fails to initialize, so this increases the timeout to 2s. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3697 Signed-off-by: Xaver Hugl <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 9ed3d7bdf2dcdf1a1196630fab89a124526e9cc2) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Helge Deller <[email protected]> Date: Sat May 31 17:08:21 2025 +0200 apparmor: Fix 8-byte alignment for initial dfa blob streams commit c567de2c4f5fe6e079672e074e1bc6122bf7e444 upstream. The dfa blob stream for the aa_dfa_unpack() function is expected to be aligned on a 8 byte boundary. The static nulldfa_src[] and stacksplitdfa_src[] arrays store the initial apparmor dfa blob streams, but since they are declared as an array-of-chars the compiler and linker will only ensure a "char" (1-byte) alignment. Add an __aligned(8) annotation to the arrays to tell the linker to always align them on a 8-byte boundary. This avoids runtime warnings at startup on alignment-sensitive platforms like parisc such as: Kernel: unaligned access to 0x7f2a584a in aa_dfa_unpack+0x124/0x788 (iir 0xca0109f) Kernel: unaligned access to 0x7f2a584e in aa_dfa_unpack+0x210/0x788 (iir 0xca8109c) Kernel: unaligned access to 0x7f2a586a in aa_dfa_unpack+0x278/0x788 (iir 0xcb01090) Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] Fixes: 98b824ff8984 ("apparmor: refcount the pdb") Signed-off-by: John Johansen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nick Chan <[email protected]> Date: Fri Jun 20 18:35:36 2025 +0800 arm64: dts: apple: t8012-j132: Include touchbar framebuffer node commit ef68a0e1087882850628000f28078e1c4df917ee upstream. Apple T2 MacBookPro15,2 (j132) has a touchbar so include the framebuffer node. Cc: [email protected] Fixes: 4efbcb623e9bc ("arm64: dts: apple: Add T2 devices") Signed-off-by: Nick Chan <[email protected]> Link: https://lore.kernel.org/stable/20250620-j132-fb-v1-1-bc6937baf0b9%40gmail.com Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sven Peter <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kaustabh Chakraborty <[email protected]> Date: Thu Jun 26 13:02:58 2025 +0530 arm64: dts: exynos7870-j6lte: reduce memory ranges to base amount commit 49a27c6c392dec46c826ee586f7ec8973acaeed7 upstream. The device is available in multiple variants with differing RAM capacities. The memory range defined in the 0x80000000 bank exceeds the address range of the memory controller, which eventually leads to ARM SError crashes. Reduce the bank size to a value which is available to all devices. The bootloader must be responsible for identifying the RAM capacity and editing the memory node accordingly. Fixes: d6f3a7f91fdb ("arm64: dts: exynos: add initial devicetree support for exynos7870") Cc: [email protected] # v6.16 Signed-off-by: Kaustabh Chakraborty <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kaustabh Chakraborty <[email protected]> Date: Thu Jun 26 13:02:57 2025 +0530 arm64: dts: exynos7870-on7xelte: reduce memory ranges to base amount commit 2bdfa35a7bb6e3a319e7a290baa44720bc96e5e4 upstream. The device is available in multiple variants with differing RAM capacities. The memory range defined in the 0x80000000 bank exceeds the address range of the memory controller, which eventually leads to ARM SError crashes. Reduce the bank size to a value which is available to all devices. The bootloader must be responsible for identifying the RAM capacity and editing the memory node accordingly. Fixes: d6f3a7f91fdb ("arm64: dts: exynos: add initial devicetree support for exynos7870") Cc: [email protected] # v6.16 Signed-off-by: Kaustabh Chakraborty <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kaustabh Chakraborty <[email protected]> Date: Thu Jun 26 13:02:56 2025 +0530 arm64: dts: exynos7870: add quirk to disable USB2 LPM in gadget mode commit e9355e894aebcbeacffd284644749190cc5f33a4 upstream. In gadget mode, USB connections are sluggish. The device won't send packets to the host unless the host sends packets to the device. For instance, SSH-ing through the USB network would apparently not work unless you're flood-pinging the device's IP. Add the property snps,usb2-gadget-lpm-disable to the dwc3 node, which seems to solve this issue. Fixes: d6f3a7f91fdb ("arm64: dts: exynos: add initial devicetree support for exynos7870") Cc: [email protected] # v6.16 Signed-off-by: Kaustabh Chakraborty <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Peter Griffin <[email protected]> Date: Fri Mar 14 15:38:02 2025 +0000 arm64: dts: exynos: gs101: ufs: add dma-coherent property commit 4292564c71cffd8094abcc52dd4840870d05cd30 upstream. ufs-exynos driver configures the sysreg shareability as cacheable for gs101 so we need to set the dma-coherent property so the descriptors are also allocated cacheable. This fixes the UFS stability issues we have seen with the upstream UFS driver on gs101. Fixes: 4c65d7054b4c ("arm64: dts: exynos: gs101: Add ufs and ufs-phy dt nodes") Cc: [email protected] Suggested-by: Will McVicker <[email protected]> Signed-off-by: Peter Griffin <[email protected]> Tested-by: Will McVicker <[email protected]> Tested-by: André Draszik <[email protected]> Reviewed-by: André Draszik <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cristian Ciocaltea <[email protected]> Date: Thu Jun 12 00:47:49 2025 +0300 arm64: dts: rockchip: Add HDMI PHY PLL clock source to VOP2 on rk3576 commit 4ab8b8ac952fb08d03655e1da0cfee07589e428f upstream. Since commit c871a311edf0 ("phy: rockchip: samsung-hdptx: Setup TMDS char rate via phy_configure_opts_hdmi"), the workaround of passing the rate from DW HDMI QP bridge driver via phy_set_bus_width() became partially broken, as it cannot reliably handle mode switches anymore. Attempting to fix this up at PHY level would not only introduce additional hacks, but it would also fail to adequately resolve the display issues that are a consequence of the system CRU limitations. Instead, proceed with the solution already implemented for RK3588: make use of the HDMI PHY PLL as a better suited DCLK source for VOP2. This will not only address the aforementioned problem, but it should also facilitate the proper operation of display modes up to 4K@60Hz. It's worth noting that anything above 4K@30Hz still requires high TMDS clock ratio and scrambling support, which hasn't been mainlined yet. Fixes: d74b842cab08 ("arm64: dts: rockchip: Add vop for rk3576") Cc: [email protected] Signed-off-by: Cristian Ciocaltea <[email protected]> Tested-By: Detlev Casanova <[email protected]> Tested-by: Nicolas Frattaroli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cristian Ciocaltea <[email protected]> Date: Thu Jun 12 00:47:48 2025 +0300 arm64: dts: rockchip: Enable HDMI PHY clk provider on rk3576 commit aba7987a536cee67fb0cb724099096fd8f8f5350 upstream. As with the RK3588 SoC, the HDMI PHY PLL on RK3576 can be used as a more accurate pixel clock source for VOP2, which is actually mandatory to ensure proper support for display modes handling. Add the missing #clock-cells property to allow using the clock provider functionality of HDMI PHY. Fixes: ad0ea230ab2a ("arm64: dts: rockchip: Add hdmi for rk3576") Cc: [email protected] Signed-off-by: Cristian Ciocaltea <[email protected]> Tested-by: Nicolas Frattaroli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sam Edwards <[email protected]> Date: Sun Jun 8 11:48:55 2025 -0700 arm64: dts: rockchip: Remove workaround that prevented Turing RK1 GPU power regulator control commit de5b39d16318f9345f1ba7c1b684ba0c1cb6fdad upstream. The RK3588 GPU power domain cannot be activated unless the external power regulator is already on. When GPU support was added to this DT, we had no way to represent this requirement, so `regulator-always-on` was added to the `vdd_gpu_s0` regulator in order to ensure stability. A later patch series (see "Fixes:" commit) resolved this shortcoming, but that commit left the workaround -- and rendered the comment above it no longer correct. Remove the workaround to allow the GPU power regulator to power off, now that the DT includes the necessary information to power it back on correctly. Fixes: f94500eb7328b ("arm64: dts: rockchip: Add GPU power domain regulator dependency for RK3588") Signed-off-by: Sam Edwards <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Judith Mendez <[email protected]> Date: Mon Jul 7 14:08:30 2025 -0500 arm64: dts: ti: k3-am62*: Move eMMC pinmux to top level board file commit a0b8da04153eb61cc2eaeeea5cc404e91e557f6b upstream. This moves pinmux child nodes for sdhci0 node from k3-am62x-sk-common to each top level board file. This is needed since we require internal pullups for AM62x SK and not for AM62 LP SK since it has external pullups on DATA 1-7. Internal pulls are required for AM62 SK as per JESD84 spec recommendation to prevent unconnected lines floating. Fixes: d19a66ae488a ("arm64: dts: ti: k3-am625-sk: Enable on board peripherals") Cc: [email protected] Signed-off-by: Judith Mendez <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vignesh Raghavendra <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Judith Mendez <[email protected]> Date: Mon Jul 7 14:12:50 2025 -0500 arm64: dts: ti: k3-am62-main: Remove eMMC High Speed DDR support commit 265f70af805f33a0dfc90f50cc0f116f702c3811 upstream. For eMMC, High Speed DDR mode is not supported [0], so remove mmc-ddr-1_8v flag which adds the capability. [0] https://www.ti.com/lit/gpn/am625 Fixes: c37c58fdeb8a ("arm64: dts: ti: k3-am62: Add more peripheral nodes") Cc: [email protected] Signed-off-by: Judith Mendez <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vignesh Raghavendra <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Emanuele Ghidoli <[email protected]> Date: Wed May 28 13:07:37 2025 +0200 arm64: dts: ti: k3-am62-verdin: Enable pull-ups on I2C buses commit bdf4252f736cc1d2a8e3e633c70fe6c728f0756e upstream. Enable internal bias pull-ups on the SoC-side I2C buses that do not have external pull resistors populated on the SoM. This ensures proper default line levels. Cc: [email protected] Fixes: 316b80246b16 ("arm64: dts: ti: add verdin am62") Signed-off-by: Emanuele Ghidoli <[email protected]> Reviewed-by: Francesco Dolcini <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vignesh Raghavendra <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hong Guan <[email protected]> Date: Mon Jul 7 11:55:13 2025 -0500 arm64: dts: ti: k3-am62a7-sk: fix pinmux for main_uart1 commit 8e44ac61abaae56fc6eb537a04ed78b458c5b984 upstream. main_uart1 reserved for TIFS firmware traces is routed to the onboard FT4232 via a FET switch which is connected to pin A21 and B21 of the SoC and not E17 and C17. Fix it. Fixes: cf39ff15cc01a ("arm64: dts: ti: k3-am62a7-sk: Describe main_uart1 and wkup_uart") Cc: [email protected] Signed-off-by: Hong Guan <[email protected]> [[email protected]: expanded commit message] Signed-off-by: Bryan Brattlof <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vignesh Raghavendra <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexander Sverdlin <[email protected]> Date: Tue Jul 1 12:54:35 2025 +0200 arm64: dts: ti: k3-pinctrl: Enable Schmitt Trigger by default commit 5b272127884bded21576a6ddceca13725a351c63 upstream. Switch Schmitt Trigger functions for PIN_INPUT* macros by default. This is HW PoR configuration, the slew rate requirements without ST enabled are pretty tough for these devices. We've noticed spurious GPIO interrupts even with noise-free edges but not meeting slew rate requirements (3.3E+6 V/s for 3.3v LVCMOS). It's not obvious why one might want to disable the PoR-enabled ST on any pin. Just enable it by default. As it's not possible to provide OR-able macros to disable the ST, shall anyone require it, provide a set of new macros with _NOST suffix. Fixes: fe49f2d776f7 ("arm64: dts: ti: Use local header for pinctrl register values") Cc: [email protected] Signed-off-by: Alexander Sverdlin <[email protected]> Link: https://lore.kernel.org/r/[email protected] [[email protected]: Add Fixes tag] Signed-off-by: Vignesh Raghavendra <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Richard Fitzgerald <[email protected]> Date: Wed Aug 20 15:22:01 2025 +0100 ASoC: cs35l56: Handle new algorithms IDs for CS35L63 [ Upstream commit 8dadc11b67d4b83deff45e4889b3b5540b9c0a7f ] CS35L63 uses different algorithm IDs from CS35L56. Add a new mechanism to handle different alg IDs between parts in the CS35L56 driver. Fixes: 978858791ced ("ASoC: cs35l56: Add initial support for CS35L63 for I2C and SoundWire") Signed-off-by: Richard Fitzgerald <[email protected]> Signed-off-by: Stefan Binding <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Binding <[email protected]> Date: Wed Aug 20 15:22:02 2025 +0100 ASoC: cs35l56: Remove SoundWire Clock Divider workaround for CS35L63 [ Upstream commit 8d13d1bdb59d0a2c526869ee571ec51a3a887463 ] Production silicon for CS36L63 has some small differences compared to pre-production silicon. Remove soundwire clock workaround as no longer necessary. We don't want to do tricks with low-level clocking controls if we don't need to. Fixes: 978858791ced ("ASoC: cs35l56: Add initial support for CS35L63 for I2C and SoundWire") Signed-off-by: Stefan Binding <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Binding <[email protected]> Date: Wed Aug 20 15:22:00 2025 +0100 ASoC: cs35l56: Update Firmware Addresses for CS35L63 for production silicon [ Upstream commit f135fb24ef29335b94921077588cae445bc7f099 ] Production silicon for CS36L63 has some small differences compared to pre-production silicon. Update firmware addresses, which are different. No product was ever released with pre-production silicon so there is no need for the driver to include support for it. Fixes: 978858791ced ("ASoC: cs35l56: Add initial support for CS35L63 for I2C and SoundWire") Signed-off-by: Stefan Binding <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Muhammad Usama Anjum <[email protected]> Date: Sat Jul 26 00:02:54 2025 +0500 ASoC: SOF: amd: acp-loader: Use GFP_KERNEL for DMA allocations in resume context commit eb3bb145280b6c857a748731a229698e4a7cf37b upstream. Replace GFP_ATOMIC with GFP_KERNEL for dma_alloc_coherent() calls. This change improves memory allocation reliability during firmware loading, particularly during system resume when memory pressure is high. Because of using GFP_KERNEL, reclaim can happen which can reduce the probability of failure. Fixes memory allocation failures observed during system resume with fragmented memory conditions. snd_sof_amd_vangogh 0000:04:00.5: error: failed to load DSP firmware after resume -12 Fixes: 145d7e5ae8f4e ("ASoC: SOF: amd: add option to use sram for data bin loading") Fixes: 7e51a9e38ab20 ("ASoC: SOF: amd: Add fw loader and renoir dsp ops to load firmware") Cc: [email protected] Signed-off-by: Muhammad Usama Anjum <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Damien Le Moal <[email protected]> Date: Wed Jun 18 16:25:19 2025 +0900 ata: Fix SATA_MOBILE_LPM_POLICY description in Kconfig commit ed62a62a18bc144f73eadf866ae46842e8f6606e upstream. Improve the description of the possible default SATA link power management policies and add the missing description for policy 5. No functional changes. Fixes: a5ec5a7bfd1f ("ata: ahci: Support state with min power but Partial low power state") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Niklas Cassel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Damien Le Moal <[email protected]> Date: Tue Jul 29 18:28:07 2025 +0900 ata: libata-scsi: Fix ata_to_sense_error() status handling commit cf3fc037623c54de48d2ec1a1ee686e2d1de2d45 upstream. Commit 8ae720449fca ("libata: whitespace fixes in ata_to_sense_error()") inadvertantly added the entry 0x40 (ATA_DRDY) to the stat_table array in the function ata_to_sense_error(). This entry ties a failed qc which has a status filed equal to ATA_DRDY to the sense key ILLEGAL REQUEST with the additional sense code UNALIGNED WRITE COMMAND. This entry will be used to generate a failed qc sense key and sense code when the qc is missing sense data and there is no match for the qc error field in the sense_table array of ata_to_sense_error(). As a result, for a failed qc for which we failed to get sense data (e.g. read log 10h failed if qc is an NCQ command, or REQUEST SENSE EXT command failed for the non-ncq case, the user very often end up seeing the completely misleading "unaligned write command" error, even if qc was not a write command. E.g.: sd 0:0:0:0: [sda] tag#12 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s sd 0:0:0:0: [sda] tag#12 Sense Key : Illegal Request [current] sd 0:0:0:0: [sda] tag#12 Add. Sense: Unaligned write command sd 0:0:0:0: [sda] tag#12 CDB: Read(10) 28 00 00 00 10 00 00 00 08 00 I/O error, dev sda, sector 4096 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 Fix this by removing the ATA_DRDY entry from the stat_table array so that we default to always returning ABORTED COMMAND without any additional sense code, since we do not know any better. The entry 0x08 (ATA_DRQ) is also removed since signaling ABORTED COMMAND with a parity error is also misleading (as a parity error would likely be signaled through a bus error). So for this case, also default to returning ABORTED COMMAND without any additional sense code. With this, the previous example error case becomes: sd 0:0:0:0: [sda] tag#17 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s sd 0:0:0:0: [sda] tag#17 Sense Key : Aborted Command [current] sd 0:0:0:0: [sda] tag#17 Add. Sense: No additional sense information sd 0:0:0:0: [sda] tag#17 CDB: Read(10) 28 00 00 00 10 00 00 00 08 00 I/O error, dev sda, sector 4096 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 Together with these fixes, refactor stat_table to make it more readable by putting the entries comments in front of the entries and using the defined status bits macros instead of hardcoded values. Reported-by: Lorenz Brun <[email protected]> Reported-by: Brandon Schwartz <[email protected]> Fixes: 8ae720449fca ("libata: whitespace fixes in ata_to_sense_error()") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Igor Pylypiv <[email protected]> Date: Wed Aug 13 19:22:56 2025 -0700 ata: libata-scsi: Fix CDL control commit 58768b0563916ddcb73d8ed26ede664915f8df31 upstream. Delete extra checks for the ATA_DFLAG_CDL_ENABLED flag that prevent SET FEATURES command from being issued to a drive when NCQ commands are active. ata_mselect_control_ata_feature() sets / clears the ATA_DFLAG_CDL_ENABLED flag during the translation of MODE SELECT to SET FEATURES. If SET FEATURES gets deferred due to outstanding NCQ commands, the original MODE SELECT command will be re-queued. When the re-queued MODE SELECT goes through the ata_mselect_control_ata_feature() translation again, SET FEATURES will not be issued because ATA_DFLAG_CDL_ENABLED has been already set or cleared by the initial translation of MODE SELECT. The ATA_DFLAG_CDL_ENABLED checks in ata_mselect_control_ata_feature() are safe to remove because scsi_cdl_enable() implements a similar logic that avoids enabling CDL if it has been enabled already. Fixes: 17e897a45675 ("ata: libata-scsi: Improve CDL control") Cc: [email protected] Signed-off-by: Igor Pylypiv <[email protected]> Reviewed-by: Niklas Cassel <[email protected]> Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Damien Le Moal <[email protected]> Date: Tue Jul 29 19:37:12 2025 +0900 ata: libata-scsi: Return aborted command when missing sense and result TF commit d2be9ea9a75550a35c5127a6c2633658bc38c76b upstream. ata_gen_ata_sense() is always called for a failed qc missing sense data so that a sense key, code and code qualifier can be generated using ata_to_sense_error() from the qc status and error fields of its result task file. However, if the qc does not have its result task file filled, ata_gen_ata_sense() returns early without setting a sense key. Improve this by defaulting to returning ABORTED COMMAND without any additional sense code, since we do not know the reason for the failure. The same fix is also applied in ata_gen_passthru_sense() with the additional check that the qc failed (qc->err_mask is set). Fixes: 816be86c7993 ("ata: libata-scsi: Check ATA_QCFLAG_RTF_FILLED before using result_tf") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ming Lei <[email protected]> Date: Fri Aug 15 21:17:37 2025 +0800 blk-mq: fix lockdep warning in __blk_mq_update_nr_hw_queues [ Upstream commit 2d82f3bd8910eb65e30bb2a3c9b945bfb3b6d661 ] Commit 5989bfe6ac6b ("block: restore two stage elevator switch while running nr_hw_queue update") reintroduced a lockdep warning by calling blk_mq_freeze_queue_nomemsave() before switching the I/O scheduler. The function blk_mq_elv_switch_none() calls elevator_change_done(). Running this while the queue is frozen causes a lockdep warning. Fix this by reordering the operations: first, switch the I/O scheduler to 'none', and then freeze the queue. This ensures that elevator_change_done() is not called on an already frozen queue. And this way is safe because elevator_set_none() does freeze queue before switching to none. Also we still have to rely on blk_mq_elv_switch_back() for switching back, and it has to cover unfrozen queue case. Cc: Nilay Shroff <[email protected]> Cc: Yu Kuai <[email protected]> Fixes: 5989bfe6ac6b ("block: restore two stage elevator switch while running nr_hw_queue update") Signed-off-by: Ming Lei <[email protected]> Reviewed-by: Yu Kuai <[email protected]> Reviewed-by: Nilay Shroff <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nilay Shroff <[email protected]> Date: Thu Aug 14 13:54:59 2025 +0530 block: avoid cpu_hotplug_lock depedency on freeze_lock [ Upstream commit 370ac285f23aecae40600851fb4a1a9e75e50973 ] A recent lockdep[1] splat observed while running blktest block/005 reveals a potential deadlock caused by the cpu_hotplug_lock dependency on ->freeze_lock. This dependency was introduced by commit 033b667a823e ("block: blk-rq-qos: guard rq-qos helpers by static key"). That change added a static key to avoid fetching q->rq_qos when neither blk-wbt nor blk-iolatency is configured. The static key dynamically patches kernel text to a NOP when disabled, eliminating overhead of fetching q->rq_qos in the I/O hot path. However, enabling a static key at runtime requires acquiring both cpu_hotplug_lock and jump_label_mutex. When this happens after the queue has already been frozen (i.e., while holding ->freeze_lock), it creates a locking dependency from cpu_hotplug_lock to ->freeze_lock, which leads to a potential deadlock reported by lockdep [1]. To resolve this, replace the static key mechanism with q->queue_flags: QUEUE_FLAG_QOS_ENABLED. This flag is evaluated in the fast path before accessing q->rq_qos. If the flag is set, we proceed to fetch q->rq_qos; otherwise, the access is skipped. Since q->queue_flags is commonly accessed in IO hotpath and resides in the first cacheline of struct request_queue, checking it imposes minimal overhead while eliminating the deadlock risk. This change avoids the lockdep splat without introducing performance regressions. [1] https://lore.kernel.org/linux-block/4fdm37so3o4xricdgfosgmohn63aa7wj3ua4e5vpihoamwg3ui@fq42f5q5t5ic/ Reported-by: Shinichiro Kawasaki <[email protected]> Closes: https://lore.kernel.org/linux-block/4fdm37so3o4xricdgfosgmohn63aa7wj3ua4e5vpihoamwg3ui@fq42f5q5t5ic/ Fixes: 033b667a823e ("block: blk-rq-qos: guard rq-qos helpers by static key") Tested-by: Shin'ichiro Kawasaki <[email protected]> Signed-off-by: Nilay Shroff <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nilay Shroff <[email protected]> Date: Thu Aug 14 13:54:58 2025 +0530 block: decrement block_rq_qos static key in rq_qos_del() [ Upstream commit ade1beea1c27657712aa8f594226d461639382ff ] rq_qos_add() increments the block_rq_qos static key when a QoS policy is attached. When a QoS policy is removed via rq_qos_del(), we must symmetrically decrement the static key. If this removal drops the last QoS policy from the queue (q->rq_qos becomes NULL), the static branch can be disabled and the jump label patched to a NOP, avoiding overhead on the hot path. This change ensures rq_qos_add()/rq_qos_del() keep the block_rq_qos static key balanced and prevents leaving the branch permanently enabled after the last policy is removed. Fixes: 033b667a823e ("block: blk-rq-qos: guard rq-qos helpers by static key") Signed-off-by: Nilay Shroff <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nilay Shroff <[email protected]> Date: Wed Jul 30 13:16:08 2025 +0530 block: fix lockdep warning caused by lock dependency in elv_iosched_store [ Upstream commit f5a6604f7a4405450e4a1f54e5430f47290c500f ] Recent lockdep reports [1] have revealed a potential deadlock caused by a lock dependency between the percpu allocator lock and the elevator lock. This issue can be avoided by ensuring that the allocation and release of scheduler tags (sched_tags) are performed outside the elevator lock. Furthermore, the queue does not need to be remain frozen during these operations. To address this, move all sched_tags allocations and deallocations outside of both the ->elevator_lock and the ->freeze_lock. Since the lifetime of the elevator queue and its associated sched_tags is closely tied, the allocated sched_tags are now stored in the elevator queue structure. Then, during the actual elevator switch (which runs under ->freeze_lock and ->elevator_lock), the pre-allocated sched_tags are assigned to the appropriate q->hctx. Once the elevator switch is complete and the locks are released, the old elevator queue and its associated sched_tags are freed. This commit specifically addresses the allocation/deallocation of sched_ tags during elevator switching. Note that sched_tags may also be allocated in other contexts, such as during nr_hw_queues updates. Supporting that use case will require batch allocation/deallocation, which will be handled in a follow-up patch. This restructuring ensures that sched_tags memory management occurs entirely outside of the ->elevator_lock and ->freeze_lock context, eliminating the lock dependency problem seen during scheduler updates. [1] https://lore.kernel.org/all/[email protected]/ Reported-by: Stefan Haberland <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Nilay Shroff <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Stable-dep-of: 2d82f3bd8910 ("blk-mq: fix lockdep warning in __blk_mq_update_nr_hw_queues") Signed-off-by: Sasha Levin <[email protected]>
Author: Nilay Shroff <[email protected]> Date: Wed Jul 30 13:16:09 2025 +0530 block: fix potential deadlock while running nr_hw_queue update [ Upstream commit 04225d13aef11b2a539014def5e47d8c21fd74a5 ] Move scheduler tags (sched_tags) allocation and deallocation outside both the ->elevator_lock and ->freeze_lock when updating nr_hw_queues. This change breaks the dependency chain from the percpu allocator lock to the elevator lock, helping to prevent potential deadlocks, as observed in the reported lockdep splat[1]. This commit introduces batch allocation and deallocation helpers for sched_tags, which are now used from within __blk_mq_update_nr_hw_queues routine while iterating through the tagset. With this change, all sched_tags memory management is handled entirely outside the ->elevator_lock and the ->freeze_lock context, thereby eliminating the lock dependency that could otherwise manifest during nr_hw_queues updates. [1] https://lore.kernel.org/all/[email protected]/ Reported-by: Stefan Haberland <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Nilay Shroff <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Stable-dep-of: 2d82f3bd8910 ("blk-mq: fix lockdep warning in __blk_mq_update_nr_hw_queues") Signed-off-by: Sasha Levin <[email protected]>
Author: Nilay Shroff <[email protected]> Date: Wed Jul 30 13:16:07 2025 +0530 block: move elevator queue allocation logic into blk_mq_init_sched [ Upstream commit 49811586be373e26a3ab52f54e0dfa663c02fddd ] In preparation for allocating sched_tags before freezing the request queue and acquiring ->elevator_lock, move the elevator queue allocation logic from the elevator ops ->init_sched callback into blk_mq_init_sched. As elevator_alloc is now only invoked from block layer core, we don't need to export it, so unexport elevator_alloc function. This refactoring provides a centralized location for elevator queue initialization, which makes it easier to store pre-allocated sched_tags in the struct elevator_queue during later changes. Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Nilay Shroff <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Stable-dep-of: 2d82f3bd8910 ("blk-mq: fix lockdep warning in __blk_mq_update_nr_hw_queues") Signed-off-by: Sasha Levin <[email protected]>
Author: Julian Sun <[email protected]> Date: Tue Aug 12 23:42:57 2025 +0800 block: restore default wbt enablement commit 8f5845e0743bf3512b71b3cb8afe06c192d6acc4 upstream. The commit 245618f8e45f ("block: protect wbt_lat_usec using q->elevator_lock") protected wbt_enable_default() with q->elevator_lock; however, it also placed wbt_enable_default() before blk_queue_flag_set(QUEUE_FLAG_REGISTERED, q);, resulting in wbt failing to be enabled. Moreover, the protection of wbt_enable_default() by q->elevator_lock was removed in commit 78c271344b6f ("block: move wbt_enable_default() out of queue freezing from sched ->exit()"), so we can directly fix this issue by placing wbt_enable_default() after blk_queue_flag_set(QUEUE_FLAG_REGISTERED, q);. Additionally, this issue also causes the inability to read the wbt_lat_usec file, and the scenario is as follows: root@q:/sys/block/sda/queue# cat wbt_lat_usec cat: wbt_lat_usec: Invalid argument root@q:/data00/sjc/linux# ls /sys/kernel/debug/block/sda/rqos cannot access '/sys/kernel/debug/block/sda/rqos': No such file or directory root@q:/data00/sjc/linux# find /sys -name wbt /sys/kernel/debug/tracing/events/wbt After testing with this patch, wbt can be enabled normally. Signed-off-by: Julian Sun <[email protected]> Cc: [email protected] Fixes: 245618f8e45f ("block: protect wbt_lat_usec using q->elevator_lock") Reviewed-by: Nilay Shroff <[email protected]> Reviewed-by: Yu Kuai <[email protected]> Reviewed-by: Ming Lei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nilay Shroff <[email protected]> Date: Thu Aug 14 13:54:57 2025 +0530 block: skip q->rq_qos check in rq_qos_done_bio() [ Upstream commit 275332877e2fa9d6efa7402b1e897f6c6ee695bb ] If a bio has BIO_QOS_THROTTLED or BIO_QOS_MERGED set, it implicitly guarantees that q->rq_qos is present. Avoid re-checking q->rq_qos in this case and call __rq_qos_done_bio() directly as a minor optimization. Suggested-by : Yu Kuai <[email protected]> Signed-off-by: Nilay Shroff <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Stable-dep-of: 370ac285f23a ("block: avoid cpu_hotplug_lock depedency on freeze_lock") Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Li <[email protected]> Date: Thu Jul 10 18:52:47 2025 +0800 Bluetooth: Add PA_LINK to distinguish BIG sync and PA sync connections [ Upstream commit a7bcffc673de219af2698fbb90627016233de67b ] Currently, BIS_LINK is used for both BIG sync and PA sync connections, which makes it impossible to distinguish them when searching for a PA sync connection. Adding PA_LINK will make the distinction clearer and simplify future extensions for PA-related features. Signed-off-by: Yang Li <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Stable-dep-of: 9d4b01a0bf8d ("Bluetooth: hci_core: Fix not accounting for BIS/CIS/PA links separately") Signed-off-by: Sasha Levin <[email protected]>
Author: Jiande Lu <[email protected]> Date: Thu Jul 24 16:51:17 2025 +0800 Bluetooth: btmtk: Fix wait_on_bit_timeout interruption during shutdown [ Upstream commit 099799fa9b76c5c02b49e07005a85117a25b01ea ] During the shutdown process, an interrupt occurs that prematurely terminates the wait for the expected event. This change replaces TASK_INTERRUPTIBLE with TASK_UNINTERRUPTIBLE in the wait_on_bit_timeout call to ensure the shutdown process completes as intended without being interrupted by signals. Fixes: d019930b0049 ("Bluetooth: btmtk: move btusb_mtk_hci_wmt_sync to btmtk.c") Signed-off-by: Jiande Lu <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sergey Shtylyov <[email protected]> Date: Tue Aug 5 22:14:51 2025 +0300 Bluetooth: hci_conn: do return error from hci_enhanced_setup_sync() [ Upstream commit 0eaf7c7e85da7495c0e03a99375707fc954f5e7b ] The commit e07a06b4eb41 ("Bluetooth: Convert SCO configure_datapath to hci_sync") missed to update the *return* statement under the *case* of BT_CODEC_TRANSPARENT in hci_enhanced_setup_sync(), which led to returning success (0) instead of the negative error code (-EINVAL). However, the result of hci_enhanced_setup_sync() seems to be ignored anyway, since NULL gets passed to hci_cmd_sync_queue() as the last argument in that case and the only function interested in that result is specified by that argument. Fixes: e07a06b4eb41 ("Bluetooth: Convert SCO configure_datapath to hci_sync") Signed-off-by: Sergey Shtylyov <[email protected]> Reviewed-by: Paul Menzel <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Thu Aug 14 11:57:19 2025 -0400 Bluetooth: hci_core: Fix not accounting for BIS/CIS/PA links separately [ Upstream commit 9d4b01a0bf8d2163ae129c9c537cb0753ad5a2aa ] This fixes the likes of hci_conn_num(CIS_LINK) returning the total of ISO connection which includes BIS_LINK as well, so this splits the iso_num into each link type and introduces hci_iso_num that can be used in places where the total number of ISO connection still needs to be used. Fixes: 23205562ffc8 ("Bluetooth: separate CIS_LINK and BIS_LINK link types") Fixes: a7bcffc673de ("Bluetooth: Add PA_LINK to distinguish BIG sync and PA sync connections") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Mon Aug 4 14:05:03 2025 -0400 Bluetooth: hci_core: Fix using ll_privacy_capable for current settings [ Upstream commit 3dcf7175f2c04bd3a7d50db3fa42a0bd933b6e23 ] ll_privacy_capable only indicates that the controller supports the feature but it doesnt' check that LE is enabled so it end up being marked as active in the current settings when it shouldn't. Fixes: ad383c2c65a5 ("Bluetooth: hci_sync: Enable advertising when LL privacy is enabled") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Mon Aug 4 09:54:05 2025 -0400 Bluetooth: hci_core: Fix using {cis,bis}_capable for current settings [ Upstream commit 709788b154caf042874d765628ffa860f0bb0d1e ] {cis,bis}_capable only indicates the controller supports the feature since it doesn't check that LE is enabled so it shall not be used for current setting, instead this introduces {cis,bis}_enabled macros that can be used to indicate that these features are currently enabled. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections") Fixes: ae7533613133 ("Bluetooth: Check for ISO support in controller") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Sat Aug 9 11:36:20 2025 +0300 Bluetooth: hci_event: fix MTU for BN == 0 in CIS Established [ Upstream commit 0b3725dbf61b51e7c663834811b3691157ae17d6 ] BN == 0x00 in CIS Established means no isochronous data for the corresponding direction (Core v6.1 pp. 2394). In this case SDU MTU should be 0. However, the specification does not say the Max_PDU_C_To_P or P_To_C are then zero. Intel AX210 in Framed CIS mode sets nonzero Max_PDU for direction with zero BN. This causes failure later when we try to LE Setup ISO Data Path for disabled direction, which is disallowed (Core v6.1 pp. 2750). Fix by setting SDU MTU to 0 if BN == 0. Fixes: 2be22f1941d5f ("Bluetooth: hci_event: Fix parsing of CIS Established Event") Signed-off-by: Pauli Virtanen <[email protected]> Reviewed-by: Paul Menzel <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Thu Jul 24 16:43:18 2025 -0400 Bluetooth: hci_sync: Fix scan state after PA Sync has been established [ Upstream commit ca88be1a2725a42f8dbad579181611d9dcca8e88 ] Passive scanning is used to program the address of the peer to be synchronized, so once HCI_EV_LE_PA_SYNC_ESTABLISHED is received it needs to be updated after clearing HCI_PA_SYNC then call hci_update_passive_scan_sync to return it to its original state. Fixes: 6d0417e4e1cf ("Bluetooth: hci_conn: Fix not setting conn_timeout for Broadcast Receiver") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Li <[email protected]> Date: Thu Aug 7 15:56:03 2025 +0800 Bluetooth: hci_sync: Prevent unintended PA sync when SID is 0xFF [ Upstream commit 4d19cd228bbe8ff84a63fe7b11bc756b4b4370c7 ] After LE Extended Scan times out, conn->sid remains 0xFF, so the PA sync creation process should be aborted. Btmon snippet from PA sync with SID=0xFF: < HCI Command: LE Set Extended.. (0x08|0x0042) plen 6 #74726 [hci0] 863.107927 Extended scan: Enabled (0x01) Filter duplicates: Enabled (0x01) Duration: 0 msec (0x0000) Period: 0.00 sec (0x0000) > HCI Event: Command Complete (0x0e) plen 4 #74727 [hci0] 863.109389 LE Set Extended Scan Enable (0x08|0x0042) ncmd 1 Status: Success (0x00) < HCI Command: LE Periodic Ad.. (0x08|0x0044) plen 14 #74728 [hci0] 865.141168 Options: 0x0000 Use advertising SID, Advertiser Address Type and address Reporting initially enabled SID: 0xff Adv address type: Random (0x01) Adv address: 0D:D7:2C:E7:42:46 (Non-Resolvable) Skip: 0x0000 Sync timeout: 20000 msec (0x07d0) Sync CTE type: 0x0000 > HCI Event: Command Status (0x0f) plen 4 #74729 [hci0] 865.143223 LE Periodic Advertising Create Sync (0x08|0x0044) ncmd 1 Status: Success (0x00) Fixes: e2d471b7806b ("Bluetooth: ISO: Fix not using SID from adv report") Signed-off-by: Yang Li <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Chan <[email protected]> Date: Sat Aug 16 11:38:50 2025 -0700 bnxt_en: Fix lockdep warning during rmmod [ Upstream commit 4611d88a37cfc18cbabc6978aaf7325d1ae3f53a ] The commit under the Fixes tag added a netdev_assert_locked() in bnxt_free_ntp_fltrs(). The lock should be held during normal run-time but the assert will be triggered (see below) during bnxt_remove_one() which should not need the lock. The netdev is already unregistered by then. Fix it by calling netdev_assert_locked_or_invisible() which will not assert if the netdev is unregistered. WARNING: CPU: 5 PID: 2241 at ./include/net/netdev_lock.h:17 bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en] Modules linked in: rpcrdma rdma_cm iw_cm ib_cm configfs ib_core bnxt_en(-) bridge stp llc x86_pkg_temp_thermal xfs tg3 [last unloaded: bnxt_re] CPU: 5 UID: 0 PID: 2241 Comm: rmmod Tainted: G S W 6.16.0 #2 PREEMPT(voluntary) Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017 RIP: 0010:bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en] Code: 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 8b 47 60 be ff ff ff ff 48 8d b8 28 0c 00 00 e8 d0 cf 41 c3 85 c0 0f 85 2e ff ff ff <0f> 0b e9 27 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa92082387da0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff9e5b593d8000 RCX: 0000000000000001 RDX: 0000000000000001 RSI: ffffffff83dc9a70 RDI: ffffffff83e1a1cf RBP: ffff9e5b593d8c80 R08: 0000000000000000 R09: ffffffff8373a2b3 R10: 000000008100009f R11: 0000000000000001 R12: 0000000000000001 R13: ffffffffc01c4478 R14: dead000000000122 R15: dead000000000100 FS: 00007f3a8a52c740(0000) GS:ffff9e631ad1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055bb289419c8 CR3: 000000011274e001 CR4: 00000000003706f0 Call Trace: <TASK> bnxt_remove_one+0x57/0x180 [bnxt_en] pci_device_remove+0x39/0xc0 device_release_driver_internal+0xa5/0x130 driver_detach+0x42/0x90 bus_remove_driver+0x61/0xc0 pci_unregister_driver+0x38/0x90 bnxt_exit+0xc/0x7d0 [bnxt_en] Fixes: 004b5008016a ("eth: bnxt: remove most dependencies on RTNL") Reviewed-by: Pavan Chebbi <[email protected]> Signed-off-by: Michael Chan <[email protected]> Reviewed-by: Vadim Fedorenko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hangbin Liu <[email protected]> Date: Fri Aug 15 06:19:59 2025 +0000 bonding: send LACPDUs periodically in passive mode after receiving partner's LACPDU [ Upstream commit 0599640a21e98f0d6a3e9ff85c0a687c90a8103b ] When `lacp_active` is set to `off`, the bond operates in passive mode, meaning it only "speaks when spoken to." However, the current kernel implementation only sends an LACPDU in response when the partner's state changes. As a result, once LACP negotiation succeeds, the actor stops sending LACPDUs until the partner times out and sends an "expired" LACPDU. This causes continuous LACP state flapping. According to IEEE 802.1AX-2014, 6.4.13 Periodic Transmission machine. The values of Partner_Oper_Port_State.LACP_Activity and Actor_Oper_Port_State.LACP_Activity determine whether periodic transmissions take place. If either or both parameters are set to Active LACP, then periodic transmissions occur; if both are set to Passive LACP, then periodic transmissions do not occur. To comply with this, we remove the `!bond->params.lacp_active` check in `ad_periodic_machine()`. Instead, we initialize the actor's port's `LACP_STATE_LACP_ACTIVITY` state based on `lacp_active` setting. Additionally, we avoid setting the partner's state to `LACP_STATE_LACP_ACTIVITY` in the EXPIRED state, since we should not assume the partner is active by default. This ensures that in passive mode, the bond starts sending periodic LACPDUs after receiving one from the partner, and avoids flapping due to inactivity. Fixes: 3a755cd8b7c6 ("bonding: add new option lacp_active") Signed-off-by: Hangbin Liu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hangbin Liu <[email protected]> Date: Fri Aug 15 06:19:58 2025 +0000 bonding: update LACP activity flag after setting lacp_active [ Upstream commit b64d035f77b1f02ab449393342264b44950a75ae ] The port's actor_oper_port_state activity flag should be updated immediately after changing the lacp_active option to reflect the current mode correctly. Fixes: 3a755cd8b7c6 ("bonding: add new option lacp_active") Signed-off-by: Hangbin Liu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Filipe Manana <[email protected]> Date: Mon Aug 18 20:38:40 2025 -0400 btrfs: abort transaction on unexpected eb generation at btrfs_copy_root() [ Upstream commit 33e8f24b52d2796b8cfb28c19a1a7dd6476323a8 ] If we find an unexpected generation for the extent buffer we are cloning at btrfs_copy_root(), we just WARN_ON() and don't error out and abort the transaction, meaning we allow to persist metadata with an unexpected generation. Instead of warning only, abort the transaction and return -EUCLEAN. CC: [email protected] # 6.1+ Reviewed-by: Daniel Vacek <[email protected]> Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Filipe Manana <[email protected]> Date: Mon Aug 18 21:15:29 2025 -0400 btrfs: add comment for optimization in free_extent_buffer() [ Upstream commit 2697b6159744e5afae0f7715da9f830ba6f9e45a ] There's this special atomic compare and exchange logic which serves to avoid locking the extent buffers refs_lock spinlock and therefore reduce lock contention, so add a comment to make it more obvious. Reviewed-by: Boris Burkov <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Stable-dep-of: ad580dfa388f ("btrfs: fix subpage deadlock in try_release_subpage_extent_buffer()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qu Wenruo <[email protected]> Date: Thu Aug 21 23:35:15 2025 -0400 btrfs: add comments on the extra btrfs specific subpage bitmaps [ Upstream commit 1e17738d6b76cdc76d240d64de87fa66ba2365f7 ] Unlike the iomap_folio_state structure, the btrfs_subpage structure has a lot of extra sub-bitmaps, namely: - writeback sub-bitmap - locked sub-bitmap iomap_folio_state uses an atomic for writeback tracking, while it has no per-block locked tracking. This is because iomap always locks a single folio, and submits dirty blocks with that folio locked. But btrfs has async delalloc ranges (for compression), which are queued with their range locked, until the compression is done, then marks the involved range writeback and unlocked. This means a range can be unlocked and marked writeback at seemingly random timing, thus it needs the extra tracking. This needs a huge rework on the lifespan of async delalloc range before we can remove/simplify these two sub-bitmaps. - ordered sub-bitmap - checked sub-bitmap These are for COW-fixup, but as I mentioned in the past, the COW-fixup is not really needed anymore and these two flags are already marked deprecated, and will be removed in the near future after comprehensive tests. Add related comments to indicate we're actively trying to align the sub-bitmaps to the iomap ones. Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Stable-dep-of: b1511360c8ac ("btrfs: subpage: keep TOWRITE tag until folio is cleaned") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Filipe Manana <[email protected]> Date: Mon Aug 18 20:16:39 2025 -0400 btrfs: always abort transaction on failure to add block group to free space tree [ Upstream commit 1f06c942aa709d397cf6bed577a0d10a61509667 ] Only one of the callers of __add_block_group_free_space() aborts the transaction if the call fails, while the others don't do it and it's either never done up the call chain or much higher in the call chain. So make sure we abort the transaction at __add_block_group_free_space() if it fails, which brings a couple benefits: 1) If some call chain never aborts the transaction, we avoid having some metadata inconsistency because BLOCK_GROUP_FLAG_NEEDS_FREE_SPACE is cleared when we enter __add_block_group_free_space() and therefore __add_block_group_free_space() is never called again to add the block group items to the free space tree, since the function is only called when that flag is set in a block group; 2) If the call chain already aborts the transaction, then we get a better trace that points to the exact step from __add_block_group_free_space() which failed, which is better for analysis. So abort the transaction at __add_block_group_free_space() if any of its steps fails. CC: [email protected] # 6.6+ Reviewed-by: Boris Burkov <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kyoji Ogasawara <[email protected]> Date: Wed Jul 23 00:38:37 2025 +0900 btrfs: fix incorrect log message for nobarrier mount option commit edf842abe4368ce3c423343cf4b23b210fcf1622 upstream. Fix a wrong log message that appears when the "nobarrier" mount option is unset. When "nobarrier" is unset, barrier is actually enabled. However, the log incorrectly stated "turning off barriers". Fixes: eddb1a433f26 ("btrfs: add reconfigure callback for fs_context") CC: [email protected] # 6.12+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Kyoji Ogasawara <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kyoji Ogasawara <[email protected]> Date: Wed Aug 13 03:00:07 2025 +0900 btrfs: fix printing of mount info messages for NODATACOW/NODATASUM commit 74857fdc5dd2cdcdeb6e99bdf26976fd9299d2bb upstream. The NODATASUM message was printed twice by mistake and the NODATACOW was missing from the 'unset' part. Fix the duplication and make the output look the same. Fixes: eddb1a433f26 ("btrfs: add reconfigure callback for fs_context") CC: [email protected] # 6.8+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Kyoji Ogasawara <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Leo Martins <[email protected]> Date: Mon Aug 18 21:15:31 2025 -0400 btrfs: fix subpage deadlock in try_release_subpage_extent_buffer() [ Upstream commit ad580dfa388fabb52af033e3f8cc5d04be985e54 ] There is a potential deadlock that can happen in try_release_subpage_extent_buffer() because the irq-safe xarray spin lock fs_info->buffer_tree is being acquired before the irq-unsafe eb->refs_lock. This leads to the potential race: // T1 (random eb->refs user) // T2 (release folio) spin_lock(&eb->refs_lock); // interrupt end_bbio_meta_write() btrfs_meta_folio_clear_writeback() btree_release_folio() folio_test_writeback() //false try_release_extent_buffer() try_release_subpage_extent_buffer() xa_lock_irq(&fs_info->buffer_tree) spin_lock(&eb->refs_lock); // blocked; held by T1 buffer_tree_clear_mark() xas_lock_irqsave() // blocked; held by T2 I believe that the spin lock can safely be replaced by an rcu_read_lock. The xa_for_each loop does not need the spin lock as it's already internally protected by the rcu_read_lock. The extent buffer is also protected by the rcu_read_lock so it won't be freed before we take the eb->refs_lock and check the ref count. The rcu_read_lock is taken and released every iteration, just like the spin lock, which means we're not protected against concurrent insertions into the xarray. This is fine because we rely on folio->private to detect if there are any ebs remaining in the folio. There is already some precedent for this with find_extent_buffer_nolock, which loads an extent buffer from the xarray with only rcu_read_lock. lockdep warning: ===================================================== WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected 6.16.0-0_fbk701_debug_rc0_123_g4c06e63b9203 #1 Tainted: G E N ----------------------------------------------------- kswapd0/66 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: ffff000011ffd600 (&eb->refs_lock){+.+.}-{3:3}, at: try_release_extent_buffer+0x18c/0x560 and this task is already holding: ffff0000c1d91b88 (&buffer_xa_class){-.-.}-{3:3}, at: try_release_extent_buffer+0x13c/0x560 which would create a new lock dependency: (&buffer_xa_class){-.-.}-{3:3} -> (&eb->refs_lock){+.+.}-{3:3} but this new dependency connects a HARDIRQ-irq-safe lock: (&buffer_xa_class){-.-.}-{3:3} ... which became HARDIRQ-irq-safe at: lock_acquire+0x178/0x358 _raw_spin_lock_irqsave+0x60/0x88 buffer_tree_clear_mark+0xc4/0x160 end_bbio_meta_write+0x238/0x398 btrfs_bio_end_io+0x1f8/0x330 btrfs_orig_write_end_io+0x1c4/0x2c0 bio_endio+0x63c/0x678 blk_update_request+0x1c4/0xa00 blk_mq_end_request+0x54/0x88 virtblk_request_done+0x124/0x1d0 blk_mq_complete_request+0x84/0xa0 virtblk_done+0x130/0x238 vring_interrupt+0x130/0x288 __handle_irq_event_percpu+0x1e8/0x708 handle_irq_event+0x98/0x1b0 handle_fasteoi_irq+0x264/0x7c0 generic_handle_domain_irq+0xa4/0x108 gic_handle_irq+0x7c/0x1a0 do_interrupt_handler+0xe4/0x148 el1_interrupt+0x30/0x50 el1h_64_irq_handler+0x14/0x20 el1h_64_irq+0x6c/0x70 _raw_spin_unlock_irq+0x38/0x70 __run_timer_base+0xdc/0x5e0 run_timer_softirq+0xa0/0x138 handle_softirqs.llvm.13542289750107964195+0x32c/0xbd0 ____do_softirq.llvm.17674514681856217165+0x18/0x28 call_on_irq_stack+0x24/0x30 __irq_exit_rcu+0x164/0x430 irq_exit_rcu+0x18/0x88 el1_interrupt+0x34/0x50 el1h_64_irq_handler+0x14/0x20 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 do_idle+0x1a0/0x3b8 cpu_startup_entry+0x60/0x80 rest_init+0x204/0x228 start_kernel+0x394/0x3f0 __primary_switched+0x8c/0x8958 to a HARDIRQ-irq-unsafe lock: (&eb->refs_lock){+.+.}-{3:3} ... which became HARDIRQ-irq-unsafe at: ... lock_acquire+0x178/0x358 _raw_spin_lock+0x4c/0x68 free_extent_buffer_stale+0x2c/0x170 btrfs_read_sys_array+0x1b0/0x338 open_ctree+0xeb0/0x1df8 btrfs_get_tree+0xb60/0x1110 vfs_get_tree+0x8c/0x250 fc_mount+0x20/0x98 btrfs_get_tree+0x4a4/0x1110 vfs_get_tree+0x8c/0x250 do_new_mount+0x1e0/0x6c0 path_mount+0x4ec/0xa58 __arm64_sys_mount+0x370/0x490 invoke_syscall+0x6c/0x208 el0_svc_common+0x14c/0x1b8 do_el0_svc+0x4c/0x60 el0_svc+0x4c/0x160 el0t_64_sync_handler+0x70/0x100 el0t_64_sync+0x168/0x170 other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&eb->refs_lock); local_irq_disable(); lock(&buffer_xa_class); lock(&eb->refs_lock); <Interrupt> lock(&buffer_xa_class); *** DEADLOCK *** 2 locks held by kswapd0/66: #0: ffff800085506e40 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0xe8/0xe50 #1: ffff0000c1d91b88 (&buffer_xa_class){-.-.}-{3:3}, at: try_release_extent_buffer+0x13c/0x560 Link: https://www.kernel.org/doc/Documentation/locking/lockdep-design.rst#:~:text=Multi%2Dlock%20dependency%20rules%3A Fixes: 19d7f65f032f ("btrfs: convert the buffer_radix to an xarray") CC: [email protected] # 6.16+ Reviewed-by: Boris Burkov <[email protected]> Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Leo Martins <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Sterba <[email protected]> Date: Mon Aug 18 20:16:38 2025 -0400 btrfs: move transaction aborts to the error site in add_block_group_free_space() [ Upstream commit b63c8c1ede4407835cb8c8bed2014d96619389f3 ] Transaction aborts should be done next to the place the error happens, which was not done in add_block_group_free_space(). Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: David Sterba <[email protected]> Stable-dep-of: 1f06c942aa70 ("btrfs: always abort transaction on failure to add block group to free space tree") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qu Wenruo <[email protected]> Date: Thu Aug 21 23:35:16 2025 -0400 btrfs: rename btrfs_subpage structure [ Upstream commit 582cd4bad4332cca95c578e99442eb148366eb82 ] With the incoming large data folios support, the structure name btrfs_subpage is no longer correct, as for we can have multiple blocks inside a large folio, and the block size is still page size. So to follow the schema of iomap, rename btrfs_subpage to btrfs_folio_state, along with involved enums. There are still exported functions with "btrfs_subpage_" prefix, and I believe for metadata the name "subpage" will stay forever as we will never allocate a folio larger than nodesize anyway. The full cleanup of the word "subpage" will happen in much smaller steps in the future. Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Stable-dep-of: b1511360c8ac ("btrfs: subpage: keep TOWRITE tag until folio is cleaned") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Filipe Manana <[email protected]> Date: Mon Aug 18 21:15:28 2025 -0400 btrfs: reorganize logic at free_extent_buffer() for better readability [ Upstream commit 71c086b30d4373a01bd5627f54516a72891a026a ] It's hard to read the logic to break out of the while loop since it's a very long expression consisting of a logical or of two composite expressions, each one composed by a logical and. Further each one is also testing for the EXTENT_BUFFER_UNMAPPED bit, making it more verbose than necessary. So change from this: if ((!test_bit(EXTENT_BUFFER_UNMAPPED, &eb->bflags) && refs <= 3) || (test_bit(EXTENT_BUFFER_UNMAPPED, &eb->bflags) && refs == 1)) break; To this: if (test_bit(EXTENT_BUFFER_UNMAPPED, &eb->bflags)) { if (refs == 1) break; } else if (refs <= 3) { break; } At least on x86_64 using gcc 9.3.0, this doesn't change the object size. Reviewed-by: Boris Burkov <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Stable-dep-of: ad580dfa388f ("btrfs: fix subpage deadlock in try_release_subpage_extent_buffer()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kyoji Ogasawara <[email protected]> Date: Wed Aug 13 03:00:06 2025 +0900 btrfs: restore mount option info messages during mount commit b435ab556bea875c088485f271ef2709ca1d75f5 upstream. After the fsconfig migration in 6.8, mount option info messages are no longer displayed during mount operations because btrfs_emit_options() is only called during remount, not during initial mount. Fix this by calling btrfs_emit_options() in btrfs_fill_super() after open_ctree() succeeds. Additionally, prevent log duplication by ensuring btrfs_check_options() handles validation with warn-level and err-level messages, while btrfs_emit_options() provides info-level messages. Fixes: eddb1a433f26 ("btrfs: add reconfigure callback for fs_context") CC: [email protected] # 6.8+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Kyoji Ogasawara <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Naohiro Aota <[email protected]> Date: Thu Aug 21 23:35:17 2025 -0400 btrfs: subpage: keep TOWRITE tag until folio is cleaned [ Upstream commit b1511360c8ac882b0c52caa263620538e8d73220 ] btrfs_subpage_set_writeback() calls folio_start_writeback() the first time a folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tag even if there are still dirty blocks in the folio. This can break ordering guarantees, such as those required by btrfs_wait_ordered_extents(). That ordering breakage leads to a real failure. For example, running generic/464 on a zoned setup will hit the following ASSERT. This happens because the broken ordering fails to flush existing dirty pages before the file size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: <TASK> ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode or for compressed writes, it locks several folios for delalloc and starts writing them out. Let's call the last locked folio folio X. Suppose the write range only partially covers folio X, leaving some pages dirty. Process A calls btrfs_subpage_set_writeback() when building a bio. This function call clears the TOWRITE tag of folio X, whose size = 8K and the block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range. Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. It calls tag_pages_for_writeback() to tag dirty folios with PAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then, B collects tagged folios using filemap_get_folios_tag() and must wait for folio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE) However, between tagging and collecting, process A may call btrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY) As a result, process B won't see folio X in its batch, and returns without waiting for it. This breaks the WB_SYNC_ALL ordering requirement. Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retains the TOWRITE tag. We now manually clear the tag only after the folio becomes clean, via the xas operation. Fixes: 3470da3b7d87 ("btrfs: subpage: introduce helpers for writeback status") CC: [email protected] # 6.12+ Reviewed-by: Qu Wenruo <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Filipe Manana <[email protected]> Date: Mon Aug 18 21:15:30 2025 -0400 btrfs: use refcount_t type for the extent buffer reference counter [ Upstream commit b769777d927af168b1389388392bfd7dc4e38399 ] Instead of using a bare atomic, use the refcount_t type, which despite being a structure that contains only an atomic, has an API that checks for underflows and other hazards. This doesn't change the size of the extent_buffer structure. This removes the need to do things like this: WARN_ON(atomic_read(&eb->refs) == 0); if (atomic_dec_and_test(&eb->refs)) { (...) } And do just: if (refcount_dec_and_test(&eb->refs)) { (...) } Since refcount_dec_and_test() already triggers a warning when we decrement a ref count that has a value of 0 (or below zero). Reviewed-by: Boris Burkov <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Stable-dep-of: ad580dfa388f ("btrfs: fix subpage deadlock in try_release_subpage_extent_buffer()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Naohiro Aota <[email protected]> Date: Wed Jul 16 16:59:53 2025 +0900 btrfs: zoned: fix data relocation block group reservation [ Upstream commit daa0fde322350b467bc62bc1b141bf62df6123f8 ] btrfs_zoned_reserve_data_reloc_bg() is called on mount and at that point, all data block groups belong to the primary data space_info. So, we don't find anything in the data relocation space_info. Also, the condition "bg->used > 0" can select a block group with full of zone_unusable bytes for the candidate. As we cannot allocate from the block group, it is useless to reserve it as the data relocation block group. Furthermore, because of the space_info separation, we need to migrate the selected block group to the data relocation space_info. If not, the extent allocator cannot use the block group to do the allocation. This commit fixes these three issues. Fixes: e606ff985ec7 ("btrfs: zoned: reserve data_reloc block group on mount") Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Naohiro Aota <[email protected]> Date: Wed Jul 16 16:59:54 2025 +0900 btrfs: zoned: fix write time activation failure for metadata block group commit 5c4b93f4c8e5c53574c1a48d66a27a2c68b414af upstream. Since commit 13bb483d32ab ("btrfs: zoned: activate metadata block group on write time"), we activate a metadata block group at the write time. If the zone capacity is small enough, we can allocate the entire region before the first write. Then, we hit the btrfs_zoned_bg_is_full() in btrfs_zone_activate() and the activation fails. For a data block group, we activate it at the allocation time and we should check the fullness condition in the caller side. Add, a WARN to check the fullness condition. For a metadata block group, we don't need the fullness check because we activate it at the write time. Instead, activating it once it is written should be invalid. Catch that with a WARN too. Fixes: 13bb483d32ab ("btrfs: zoned: activate metadata block group on write time") CC: [email protected] # 6.6+ Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Youssef Samir <[email protected]> Date: Mon Jul 14 18:30:39 2025 +0200 bus: mhi: host: Detect events pointing to unexpected TREs commit 5bd398e20f0833ae8a1267d4f343591a2dd20185 upstream. When a remote device sends a completion event to the host, it contains a pointer to the consumed TRE. The host uses this pointer to process all of the TREs between it and the host's local copy of the ring's read pointer. This works when processing completion for chained transactions, but can lead to nasty results if the device sends an event for a single-element transaction with a read pointer that is multiple elements ahead of the host's read pointer. For instance, if the host accesses an event ring while the device is updating it, the pointer inside of the event might still point to an old TRE. If the host uses the channel's xfer_cb() to directly free the buffer pointed to by the TRE, the buffer will be double-freed. This behavior was observed on an ep that used upstream EP stack without 'commit 6f18d174b73d ("bus: mhi: ep: Update read pointer only after buffer is written")'. Where the device updated the events ring pointer before updating the event contents, so it left a window where the host was able to access the stale data the event pointed to, before the device had the chance to update them. The usual pattern was that the host received an event pointing to a TRE that is not immediately after the last processed one, so it got treated as if it was a chained transaction, processing all of the TREs in between the two read pointers. This commit aims to harden the host by ensuring transactions where the event points to a TRE that isn't local_rp + 1 are chained. Fixes: 1d3173a3bae7 ("bus: mhi: core: Add support for processing events from client device") Signed-off-by: Youssef Samir <[email protected]> [mani: added stable tag and reworded commit message] Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Jeff Hugo <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexander Wilhelm <[email protected]> Date: Mon May 19 16:58:37 2025 +0200 bus: mhi: host: Fix endianness of BHI vector table commit f471578e8b1a90623674433a01a8845110bc76ce upstream. On big endian platform like PowerPC, the MHI bus (which is little endian) does not start properly. The following example shows the error messages by using QCN9274 WLAN device with ath12k driver: ath12k_pci 0001:01:00.0: BAR 0: assigned [mem 0xc00000000-0xc001fffff 64bit] ath12k_pci 0001:01:00.0: MSI vectors: 1 ath12k_pci 0001:01:00.0: Hardware name: qcn9274 hw2.0 ath12k_pci 0001:01:00.0: failed to set mhi state: POWER_ON(2) ath12k_pci 0001:01:00.0: failed to start mhi: -110 ath12k_pci 0001:01:00.0: failed to power up :-110 ath12k_pci 0001:01:00.0: failed to create soc core: -110 ath12k_pci 0001:01:00.0: failed to init core: -110 ath12k_pci: probe of 0001:01:00.0 failed with error -110 The issue seems to be with the incorrect DMA address/size used for transferring the firmware image over BHI. So fix it by converting the DMA address and size of the BHI vector table to little endian format before sending them to the device. Fixes: 6cd330ae76ff ("bus: mhi: core: Add support for ringing channel/event ring doorbells") Signed-off-by: Alexander Wilhelm <[email protected]> [mani: added stable tag and reworded commit message] Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Jeff Hugo <[email protected]> Reviewed-by: Krishna Chaitanya Chundru <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Wed Aug 6 11:05:09 2025 +0200 cdx: Fix off-by-one error in cdx_rpmsg_probe() commit 300a0cfe9f375b2843bcb331bcfa7503475ef5dd upstream. In cdx_rpmsg_probe(), strscpy() is incorrectly called with the length of the source string (excluding the NUL terminator) rather than the size of the destination buffer. This results in one character less being copied from 'cdx_rpmsg_id_table[0].name' to 'chinfo.name'. Use the destination buffer size instead to ensure the name is copied correctly. Cc: stable <[email protected]> Fixes: 2a226927d9b8 ("cdx: add rpmsg communication channel for CDX") Signed-off-by: Thorsten Blum <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Waiman Long <[email protected]> Date: Wed Aug 6 13:24:29 2025 -0400 cgroup/cpuset: Fix a partition error with CPU hotplug [ Upstream commit 150e298ae0ccbecff2357a72fbabd80f8849ea6e ] It was found during testing that an invalid leaf partition with an empty effective exclusive CPU list can become a valid empty partition with no CPU afer an offline/online operation of an unrelated CPU. An empty partition root is allowed in the special case that it has no task in its cgroup and has distributed out all its CPUs to its child partitions. That is certainly not the case here. The problem is in the cpumask_subsets() test in the hotplug case (update with no new mask) of update_parent_effective_cpumask() as it also returns true if the effective exclusive CPU list is empty. Fix that by addding the cpumask_empty() test to root out this exception case. Also add the cpumask_empty() test in cpuset_hotplug_update_tasks() to avoid calling update_parent_effective_cpumask() for this special case. Fixes: 0c7f293efc87 ("cgroup/cpuset: Add cpuset.cpus.exclusive.effective for v2") Signed-off-by: Waiman Long <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Waiman Long <[email protected]> Date: Wed Aug 6 13:24:28 2025 -0400 cgroup/cpuset: Use static_branch_enable_cpuslocked() on cpusets_insane_config_key [ Upstream commit 65f97cc81b0adc5f49cf6cff5d874be0058e3f41 ] The following lockdep splat was observed. [ 812.359086] ============================================ [ 812.359089] WARNING: possible recursive locking detected [ 812.359097] -------------------------------------------- [ 812.359100] runtest.sh/30042 is trying to acquire lock: [ 812.359105] ffffffffa7f27420 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_enable+0xe/0x20 [ 812.359131] [ 812.359131] but task is already holding lock: [ 812.359134] ffffffffa7f27420 (cpu_hotplug_lock){++++}-{0:0}, at: cpuset_write_resmask+0x98/0xa70 : [ 812.359267] Call Trace: [ 812.359272] <TASK> [ 812.359367] cpus_read_lock+0x3c/0xe0 [ 812.359382] static_key_enable+0xe/0x20 [ 812.359389] check_insane_mems_config.part.0+0x11/0x30 [ 812.359398] cpuset_write_resmask+0x9f2/0xa70 [ 812.359411] cgroup_file_write+0x1c7/0x660 [ 812.359467] kernfs_fop_write_iter+0x358/0x530 [ 812.359479] vfs_write+0xabe/0x1250 [ 812.359529] ksys_write+0xf9/0x1d0 [ 812.359558] do_syscall_64+0x5f/0xe0 Since commit d74b27d63a8b ("cgroup/cpuset: Change cpuset_rwsem and hotplug lock order"), the ordering of cpu hotplug lock and cpuset_mutex had been reversed. That patch correctly used the cpuslocked version of the static branch API to enable cpusets_pre_enable_key and cpusets_enabled_key, but it didn't do the same for cpusets_insane_config_key. The cpusets_insane_config_key can be enabled in the check_insane_mems_config() which is called from update_nodemask() or cpuset_hotplug_update_tasks() with both cpu hotplug lock and cpuset_mutex held. Deadlock can happen with a pending hotplug event that tries to acquire the cpu hotplug write lock which will block further cpus_read_lock() attempt from check_insane_mems_config(). Fix that by switching to use static_branch_enable_cpuslocked(). Fixes: d74b27d63a8b ("cgroup/cpuset: Change cpuset_rwsem and hotplug lock order") Signed-off-by: Waiman Long <[email protected]> Reviewed-by: Juri Lelli <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: JP Kobryn <[email protected]> Date: Wed Aug 6 17:33:50 2025 -0700 cgroup: avoid null de-ref in css_rstat_exit() commit eea51c6e3f6675b795f6439eaa960eb2948d6905 upstream. css_rstat_exit() may be called asynchronously in scenarios where preceding calls to css_rstat_init() have not completed. One such example is this sequence below: css_create(...) { ... init_and_link_css(css, ...); err = percpu_ref_init(...); if (err) goto err_free_css; err = cgroup_idr_alloc(...); if (err) goto err_free_css; err = css_rstat_init(css, ...); if (err) goto err_free_css; ... err_free_css: INIT_RCU_WORK(&css->destroy_rwork, css_free_rwork_fn); queue_rcu_work(cgroup_destroy_wq, &css->destroy_rwork); return ERR_PTR(err); } If any of the three goto jumps are taken, async cleanup will begin and css_rstat_exit() will be invoked on an uninitialized css->rstat_cpu. Avoid accessing the unitialized field by returning early in css_rstat_exit() if this is the case. Signed-off-by: JP Kobryn <[email protected]> Suggested-by: Michal Koutný <[email protected]> Fixes: 5da3bfa029d68 ("cgroup: use separate rstat trees for each subsystem") Cc: [email protected] # v6.16 Reported-by: [email protected] Acked-by: Shakeel Butt <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Howells <[email protected]> Date: Tue Aug 19 16:27:36 2025 +0100 cifs: Fix oops due to uninitialised variable [ Upstream commit 453a6d2a68e54a483d67233c6e1e24c4095ee4be ] Fix smb3_init_transform_rq() to initialise buffer to NULL before calling netfs_alloc_folioq_buffer() as netfs assumes it can append to the buffer it is given. Setting it to NULL means it should start a fresh buffer, but the value is currently undefined. Fixes: a2906d3316fc ("cifs: Switch crypto buffer to use a folio_queue rather than an xarray") Signed-off-by: David Howells <[email protected]> cc: Steve French <[email protected]> cc: Paulo Alcantara <[email protected]> cc: [email protected] cc: [email protected] Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Abbott <[email protected]> Date: Fri Jul 25 13:53:24 2025 +0100 comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl() commit 3cd212e895ca2d58963fdc6422502b10dd3966bb upstream. syzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`. A kernel buffer is allocated to hold `insn->n` samples (each of which is an `unsigned int`). For some instruction types, `insn->n` samples are copied back to user-space, unless an error code is being returned. The problem is that not all the instruction handlers that need to return data to userspace fill in the whole `insn->n` samples, so that there is an information leak. There is a similar syzbot report for `do_insnlist_ioctl()`, although it does not have a reproducer for it at the time of writing. One culprit is `insn_rw_emulate_bits()` which is used as the handler for `INSN_READ` or `INSN_WRITE` instructions for subdevices that do not have a specific handler for that instruction, but do have an `INSN_BITS` handler. For `INSN_READ` it only fills in at most 1 sample, so if `insn->n` is greater than 1, the remaining `insn->n - 1` samples copied to userspace will be uninitialized kernel data. Another culprit is `vm80xx_ai_insn_read()` in the "vm80xx" driver. It never returns an error, even if it fails to fill the buffer. Fix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making sure that uninitialized parts of the allocated buffer are zeroed before handling each instruction. Thanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`. That fix replaced the call to `kmalloc_array()` with `kcalloc()`, but it is not always necessary to clear the whole buffer. Fixes: ed9eccbe8970 ("Staging: add comedi core") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=a5e45f768aab5892da5d Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=fb4362a104d45ab09cf9 Cc: stable <[email protected]> # 5.13+ Cc: Arnaud Lecomte <[email protected]> Signed-off-by: Ian Abbott <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ian Abbott <[email protected]> Date: Fri Jul 25 15:10:34 2025 +0100 comedi: Make insn_rw_emulate_bits() do insn->n samples commit 7afba9221f70d4cbce0f417c558879cba0eb5e66 upstream. The `insn_rw_emulate_bits()` function is used as a default handler for `INSN_READ` instructions for subdevices that have a handler for `INSN_BITS` but not for `INSN_READ`. Similarly, it is used as a default handler for `INSN_WRITE` instructions for subdevices that have a handler for `INSN_BITS` but not for `INSN_WRITE`. It works by emulating the `INSN_READ` or `INSN_WRITE` instruction handling with a constructed `INSN_BITS` instruction. However, `INSN_READ` and `INSN_WRITE` instructions are supposed to be able read or write multiple samples, indicated by the `insn->n` value, but `insn_rw_emulate_bits()` currently only handles a single sample. For `INSN_READ`, the comedi core will copy `insn->n` samples back to user-space. (That triggered KASAN kernel-infoleak errors when `insn->n` was greater than 1, but that is being fixed more generally elsewhere in the comedi core.) Make `insn_rw_emulate_bits()` either handle `insn->n` samples, or return an error, to conform to the general expectation for `INSN_READ` and `INSN_WRITE` handlers. Fixes: ed9eccbe8970 ("Staging: add comedi core") Cc: stable <[email protected]> # 5.13+ Signed-off-by: Ian Abbott <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Edward Adam Davis <[email protected]> Date: Mon Jul 7 20:39:58 2025 +0800 comedi: pcl726: Prevent invalid irq number commit 96cb948408b3adb69df7e451ba7da9d21f814d00 upstream. The reproducer passed in an irq number(0x80008000) that was too large, which triggered the oob. Added an interrupt number check to prevent users from passing in an irq number that was too large. If `it->options[1]` is 31, then `1 << it->options[1]` is still invalid because it shifts a 1-bit into the sign bit (which is UB in C). Possible solutions include reducing the upper bound on the `it->options[1]` value to 30 or lower, or using `1U << it->options[1]`. The old code would just not attempt to request the IRQ if the `options[1]` value were invalid. And it would still configure the device without interrupts even if the call to `request_irq` returned an error. So it would be better to combine this test with the test below. Fixes: fff46207245c ("staging: comedi: pcl726: enable the interrupt support code") Cc: stable <[email protected]> # 5.13+ Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=5cd373521edd68bebcb3 Tested-by: [email protected] Signed-off-by: Edward Adam Davis <[email protected]> Reviewed-by: Ian Abbott <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jan Beulich <[email protected]> Date: Mon Apr 14 16:41:07 2025 +0200 compiler: remove __ADDRESSABLE_ASM{_STR,}() again commit 8ea815399c3fcce1889bd951fec25b5b9a3979c1 upstream. __ADDRESSABLE_ASM_STR() is where the necessary stringification happens. As long as "sym" doesn't contain any odd characters, no quoting is required for its use with .quad / .long. In fact the quotation gets in the way with gas 2.25; it's only from 2.26 onwards that quoted symbols are half-way properly supported. However, assembly being different from C anyway, drop __ADDRESSABLE_ASM_STR() and its helper macro altogether. A simple .global directive will suffice to get the symbol "declared", i.e. into the symbol table. While there also stop open-coding STATIC_CALL_TRAMP() and STATIC_CALL_KEY(). Fixes: 0ef8047b737d ("x86/static-call: provide a way to do very early static-call updates") Signed-off-by: Jan Beulich <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Cc: [email protected] Signed-off-by: Juergen Gross <[email protected]> Message-ID: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Tue Jul 1 17:30:01 2025 -0500 cpufreq: armada-8k: Fix off by one in armada_8k_cpufreq_free_table() commit 4a26df233266a628157d7f0285451d8655defdfc upstream. The freq_tables[] array has num_possible_cpus() elements so, to avoid an out of bounds access, this loop should be capped at "< nb_cpus" instead of "<= nb_cpus". The freq_tables[] array is allocated in armada_8k_cpufreq_init(). Cc: [email protected] Fixes: f525a670533d ("cpufreq: ap806: add cpufreq driver for Armada 8K") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Wed Aug 13 12:25:58 2025 +0200 cpuidle: governors: menu: Avoid selecting states with too much latency commit 779b1a1cb13ae17028aeddb2fbbdba97357a1e15 upstream. Occasionally, the exit latency of the idle state selected by the menu governor may exceed the PM QoS CPU wakeup latency limit. Namely, if the scheduler tick has been stopped already and predicted_ns is greater than the tick period length, the governor may return an idle state whose exit latency exceeds latency_req because that decision is made before checking the current idle state's exit latency. For instance, say that there are 3 idle states, 0, 1, and 2. For idle states 0 and 1, the exit latency is equal to the target residency and the values are 0 and 5 us, respectively. State 2 is deeper and has the exit latency and target residency of 200 us and 2 ms (which is greater than the tick period length), respectively. Say that predicted_ns is equal to TICK_NSEC and the PM QoS latency limit is 20 us. After the first two iterations of the main loop in menu_select(), idx becomes 1 and in the third iteration of it the target residency of the current state (state 2) is greater than predicted_ns. State 2 is not a polling one and predicted_ns is not less than TICK_NSEC, so the check on whether or not the tick has been stopped is done. Say that the tick has been stopped already and there are no imminent timers (that is, delta_tick is greater than the target residency of state 2). In that case, idx becomes 2 and it is returned immediately, but the exit latency of state 2 exceeds the latency limit. Address this issue by modifying the code to compare the exit latency of the current idle state (idle state i) with the latency limit before comparing its target residency with predicted_ns, which allows one more exit_latency_ns check that becomes redundant to be dropped. However, after the above change, latency_req cannot take the predicted_ns value any more, which takes place after commit 38f83090f515 ("cpuidle: menu: Remove iowait influence"), because it may cause a polling state to be returned prematurely. In the context of the previous example say that predicted_ns is 3000 and the PM QoS latency limit is still 20 us. Additionally, say that idle state 0 is a polling one. Moving the exit_latency_ns check before the target_residency_ns one causes the loop to terminate in the second iteration, before the target_residency_ns check, so idle state 0 will be returned even though previously state 1 would be returned if there were no imminent timers. For this reason, remove the assignment of the predicted_ns value to latency_req from the code. Fixes: 5ef499cd571c ("cpuidle: menu: Handle stopped tick more aggressively") Cc: 4.17+ <[email protected]> # 4.17+ Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Christian Loehle <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Tue Jul 8 17:59:54 2025 -0700 crypto: acomp - Fix CFI failure due to type punning commit 962ddc5a7a4b04c007bba0f3e7298cda13c62efd upstream. To avoid a crash when control flow integrity is enabled, make the workspace ("stream") free function use a consistent type, and call it through a function pointer that has that same type. Fixes: 42d9f6c77479 ("crypto: acomp - Move scomp stream allocation code into acomp") Cc: [email protected] Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Herbert Xu <[email protected]> [Giovanni: Backport to 6.16.y. Removed logic in crypto/zstd.c as commit f5ad93ffb541 ("crypto: zstd - convert to acomp") is not going to be backported to stable.] Signed-off-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: John Ernberg <[email protected]> Date: Wed Jun 11 11:38:08 2025 +0000 crypto: caam - Prevent crash on suspend with iMX8QM / iMX8ULP commit 5ffc47feddcf8eb4d8ac7b42111a02c8e8146512 upstream. Since the CAAM on these SoCs is managed by another ARM core, called the SECO (Security Controller) on iMX8QM and Secure Enclave on iMX8ULP, which also reserves access to register page 0 suspend operations cannot touch this page. This is similar to when running OPTEE, where OPTEE will reserve page 0. Track this situation using a new state variable no_page0, reflecting if page 0 is reserved elsewhere, either by other management cores in SoC or by OPTEE. Replace the optee_en check in suspend/resume with the new check. optee_en cannot go away as it's needed elsewhere to gate OPTEE specific situations. Fixes the following splat at suspend: Internal error: synchronous external abort: 0000000096000010 [#1] SMP Hardware name: Freescale i.MX8QXP ACU6C (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : readl+0x0/0x18 lr : rd_reg32+0x18/0x3c sp : ffffffc08192ba20 x29: ffffffc08192ba20 x28: ffffff8025190000 x27: 0000000000000000 x26: ffffffc0808ae808 x25: ffffffc080922338 x24: ffffff8020e89090 x23: 0000000000000000 x22: ffffffc080922000 x21: ffffff8020e89010 x20: ffffffc080387ef8 x19: ffffff8020e89010 x18: 000000005d8000d5 x17: 0000000030f35963 x16: 000000008f785f3f x15: 000000003b8ef57c x14: 00000000c418aef8 x13: 00000000f5fea526 x12: 0000000000000001 x11: 0000000000000002 x10: 0000000000000001 x9 : 0000000000000000 x8 : ffffff8025190870 x7 : ffffff8021726880 x6 : 0000000000000002 x5 : ffffff80217268f0 x4 : ffffff8021726880 x3 : ffffffc081200000 x2 : 0000000000000001 x1 : ffffff8020e89010 x0 : ffffffc081200004 Call trace: readl+0x0/0x18 caam_ctrl_suspend+0x30/0xdc dpm_run_callback.constprop.0+0x24/0x5c device_suspend+0x170/0x2e8 dpm_suspend+0xa0/0x104 dpm_suspend_start+0x48/0x50 suspend_devices_and_enter+0x7c/0x45c pm_suspend+0x148/0x160 state_store+0xb4/0xf8 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x38/0x48 kernfs_fop_write_iter+0xb4/0x178 vfs_write+0x118/0x178 ksys_write+0x6c/0xd0 __arm64_sys_write+0x14/0x1c invoke_syscall.constprop.0+0x64/0xb0 do_el0_svc+0x90/0xb0 el0_svc+0x18/0x44 el0t_64_sync_handler+0x88/0x124 el0t_64_sync+0x150/0x154 Code: 88dffc21 88dffc21 5ac00800 d65f03c0 (b9400000) Fixes: d2835701d93c ("crypto: caam - i.MX8ULP donot have CAAM page0 access") Cc: [email protected] # v6.10+ Signed-off-by: John Ernberg <[email protected]> Reviewed-by: Peng Fan <[email protected]> Reviewed-by: Frank Li <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ashish Kalra <[email protected]> Date: Mon Jun 16 21:50:27 2025 +0000 crypto: ccp - Fix SNP panic notifier unregistration commit ab8b9fd39c45b7760093528cbef93e7353359d82 upstream. Panic notifiers are invoked with RCU read lock held and when the SNP panic notifier tries to unregister itself from the panic notifier callback itself it causes a deadlock as notifier unregistration does RCU synchronization. Code flow for SNP panic notifier: snp_shutdown_on_panic() -> __sev_firmware_shutdown() -> __sev_snp_shutdown_locked() -> atomic_notifier_chain_unregister(.., &snp_panic_notifier) Fix SNP panic notifier to unregister itself during SNP shutdown only if panic is not in progress. Reviewed-by: Tom Lendacky <[email protected]> Cc: [email protected] Fixes: 19860c3274fb ("crypto: ccp - Register SNP panic notifier only if SNP is enabled") Signed-off-by: Ashish Kalra <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Herbert Xu <[email protected]> Date: Thu Jul 31 09:41:47 2025 +0800 crypto: hash - Increase HASH_MAX_DESCSIZE for hmac(sha3-224-s390) commit 9d9b193ed73a65ec47cf1fd39925b09da8216461 upstream. The value of HASH_MAX_DESCSIZE is off by one for hmac(sha3-224-s390). Fix this so that hmac(sha3-224-s390) can be registered. Reported-by: Ingo Franzki <[email protected]> Reported-by: Eric Biggers <[email protected]> Fixes: 6f90ba706551 ("crypto: s390/sha3 - Use API partial block handling") Cc: <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bharat Bhushan <[email protected]> Date: Thu May 22 15:36:25 2025 +0530 crypto: octeontx2 - Fix address alignment issue on ucode loading commit b7b88b4939e71ef2aed8238976a2bbabcb63a790 upstream. octeontx2 crypto driver allocates memory using kmalloc/kzalloc, and uses this memory for dma (does dma_map_single()). It assumes that kmalloc/kzalloc will return 128-byte aligned address. But kmalloc/kzalloc returns 8-byte aligned address after below changes: "9382bc44b5f5 arm64: allow kmalloc() caches aligned to the smaller cache_line_size()" Completion address should be 32-Byte alignment when loading microcode. Signed-off-by: Bharat Bhushan <[email protected]> Cc: <[email protected]> # v6.5+ Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bharat Bhushan <[email protected]> Date: Thu May 22 15:36:26 2025 +0530 crypto: octeontx2 - Fix address alignment on CN10K A0/A1 and OcteonTX2 commit 2e13163b43e6bb861182ea999a80dd1d893c0cbf upstream. octeontx2 crypto driver allocates memory using kmalloc/kzalloc, and uses this memory for dma (does dma_map_single()). It assumes that kmalloc/kzalloc will return 128-byte aligned address. But kmalloc/kzalloc returns 8-byte aligned address after below changes: "9382bc44b5f5 arm64: allow kmalloc() caches aligned to the smaller cache_line_size() Memory allocated are used for following purpose: - Input data or scatter list address - 8-Byte alignment - Output data or gather list address - 8-Byte alignment - Completion address - 32-Byte alignment. This patch ensures all addresses are aligned as mentioned above. Signed-off-by: Bharat Bhushan <[email protected]> Cc: <[email protected]> # v6.5+ Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bharat Bhushan <[email protected]> Date: Thu May 22 15:36:27 2025 +0530 crypto: octeontx2 - Fix address alignment on CN10KB and CN10KA-B0 commit a091a58b8a1eba2f243b0c05bcc82bdc2a4a338d upstream. octeontx2 crypto driver allocates memory using kmalloc/kzalloc, and uses this memory for dma (does dma_map_single()). It assumes that kmalloc/kzalloc will return 128-byte aligned address. But kmalloc/kzalloc returns 8-byte aligned address after below changes: "9382bc44b5f5 arm64: allow kmalloc() caches aligned to the smaller cache_line_size() Memory allocated are used for following purpose: - Input data or scatter list address - 8-Byte alignment - Output data or gather list address - 8-Byte alignment - Completion address - 32-Byte alignment. This patch ensures all addresses are aligned as mentioned above. Signed-off-by: Bharat Bhushan <[email protected]> Cc: <[email protected]> # v6.8+ Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Giovanni Cabiddu <[email protected]> Date: Fri Jul 11 13:27:43 2025 +0100 crypto: qat - flush misc workqueue during device shutdown commit 3d4df408ba9bad2b205c7fb8afc1836a6a4ca88a upstream. Repeated loading and unloading of a device specific QAT driver, for example qat_4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains loaded. Since the driver uses a shared workqueue (`qat_misc_wq`) across all devices and owned by intel_qat.ko, a deferred routine from the device-specific driver may still be pending in the queue. If this routine executes after the driver is unloaded, it can dereference freed memory, resulting in a page fault and kernel crash like the following: BUG: unable to handle page fault for address: ffa000002e50a01c #PF: supervisor read access in kernel mode RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat] Call Trace: pm_bh_handler+0x1d2/0x250 [intel_qat] process_one_work+0x171/0x340 worker_thread+0x277/0x3a0 kthread+0xf0/0x120 ret_from_fork+0x2d/0x50 To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded. Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability. Fixes: e5745f34113b ("crypto: qat - enable power management for QAT GEN4") Signed-off-by: Giovanni Cabiddu <[email protected]> Cc: [email protected] Reviewed-by: Ahsan Atta <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Giovanni Cabiddu <[email protected]> Date: Fri Jun 13 11:32:27 2025 +0100 crypto: qat - lower priority for skcipher and aead algorithms commit 8024774190a5ef2af2c5846f60a50b23e0980a32 upstream. Most kernel applications utilizing the crypto API operate synchronously and on small buffer sizes, therefore do not benefit from QAT acceleration. Reduce the priority of QAT implementations for both skcipher and aead algorithms, allowing more suitable alternatives to be selected by default. Signed-off-by: Giovanni Cabiddu <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Cc: [email protected] Acked-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Tue Jul 8 12:38:29 2025 -0700 crypto: x86/aegis - Add missing error checks commit 3d9eb180fbe8828cce43bce4c370124685b205c3 upstream. The skcipher_walk functions can allocate memory and can fail, so checking for errors is necessary. Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS implementations") Cc: [email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Tue Jul 8 12:38:28 2025 -0700 crypto: x86/aegis - Fix sleeping when disallowed on PREEMPT_RT commit c7f49dadfcdf27e1f747442e874e9baa52ab7674 upstream. skcipher_walk_done() can call kfree(), which takes a spinlock, which makes it incorrect to call while preemption is disabled on PREEMPT_RT. Therefore, end the kernel-mode FPU section before calling skcipher_walk_done(), and restart it afterwards. Moreover, pass atomic=false to skcipher_walk_aead_encrypt() instead of atomic=true. The point of atomic=true was to make skcipher_walk_done() safe to call while in a kernel-mode FPU section, but that does not actually work. So just use the usual atomic=false. Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS implementations") Cc: [email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Charalampos Mitrodimas <[email protected]> Date: Sat Aug 16 14:14:37 2025 +0000 debugfs: fix mount options not being applied commit ba6cc29351b1fa0cb9adce91b88b9f3c3cbe9c46 upstream. Mount options (uid, gid, mode) are silently ignored when debugfs is mounted. This is a regression introduced during the conversion to the new mount API. When the mount API conversion was done, the parsed options were never applied to the superblock when it was reused. As a result, the mount options were ignored when debugfs was mounted. Fix this by following the same pattern as the tracefs fix in commit e4d32142d1de ("tracing: Fix tracefs mount options"). Call debugfs_reconfigure() in debugfs_get_tree() to apply the mount options to the superblock after it has been created or reused. As an example, with the bug the "mode" mount option is ignored: $ mount -o mode=0666 -t debugfs debugfs /tmp/debugfs_test $ mount | grep debugfs_test debugfs on /tmp/debugfs_test type debugfs (rw,relatime) $ ls -ld /tmp/debugfs_test drwx------ 25 root root 0 Aug 4 14:16 /tmp/debugfs_test With the fix applied, it works as expected: $ mount -o mode=0666 -t debugfs debugfs /tmp/debugfs_test $ mount | grep debugfs_test debugfs on /tmp/debugfs_test type debugfs (rw,relatime,mode=666) $ ls -ld /tmp/debugfs_test drw-rw-rw- 37 root root 0 Aug 2 17:28 /tmp/debugfs_test Fixes: a20971c18752 ("vfs: Convert debugfs to use the new mount API") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220406 Cc: stable <[email protected]> Reviewed-by: Eric Sandeen <[email protected]> Signed-off-by: Charalampos Mitrodimas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jedrzej Jagielski <[email protected]> Date: Sun Aug 24 20:30:13 2025 -0700 devlink: let driver opt out of automatic phys_port_name generation [ Upstream commit c5ec7f49b480db0dfc83f395755b1c2a7c979920 ] Currently when adding devlink port, phys_port_name is automatically generated within devlink port initialization flow. As a result adding devlink port support to driver may result in forced changes of interface names, which breaks already existing network configs. This is an expected behavior but in some scenarios it would not be preferable to provide such limitation for legacy driver not being able to keep 'pre-devlink' interface name. Add flag no_phys_port_name to devlink_port_attrs struct which indicates if devlink should not alter name of interface. Suggested-by: Jiri Pirko <[email protected]> Link: https://lore.kernel.org/all/nbwrfnjhvrcduqzjl4a2jafnvvud6qsbxlvxaxilnryglf4j7r@btuqrimnfuly/ Signed-off-by: Jedrzej Jagielski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Cc: [email protected] # 6.16 Tested-By: Calvin Owens <[email protected]> Signed-off-by: Calvin Owens <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Damien Le Moal <[email protected]> Date: Wed Jun 25 18:33:27 2025 +0900 dm: Check for forbidden splitting of zone write operations commit 409f9287dab3b53bffe8d28d883a529028aa6a42 upstream. DM targets must not split zone append and write operations using dm_accept_partial_bio() as doing so is forbidden for zone append BIOs, breaks zone append emulation using regular write BIOs and potentially creates deadlock situations with queue freeze operations. Modify dm_accept_partial_bio() to add missing BUG_ON() checks for all these cases, that is, check that the BIO is a write or write zeroes operation. This change packs all the zone related checks together under a static_branch_unlikely(&zoned_enabled) and done only if the target is a zoned device. Fixes: f211268ed1f9 ("dm: Use the block layer zone append emulation") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Mikulas Patocka <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Damien Le Moal <[email protected]> Date: Wed Jun 25 18:33:26 2025 +0900 dm: dm-crypt: Do not partially accept write BIOs with zoned targets commit e549663849e5bb3b985dc2d293069f0d9747ae72 upstream. Read and write operations issued to a dm-crypt target may be split according to the dm-crypt internal limits defined by the max_read_size and max_write_size module parameters (default is 128 KB). The intent is to improve processing time of large BIOs by splitting them into smaller operations that can be parallelized on different CPUs. For zoned dm-crypt targets, this BIO splitting is still done but without the parallel execution to ensure that the issuing order of write operations to the underlying devices remains sequential. However, the splitting itself causes other problems: 1) Since dm-crypt relies on the block layer zone write plugging to handle zone append emulation using regular write operations, the reminder of a split write BIO will always be plugged into the target zone write plugged. Once the on-going write BIO finishes, this reminder BIO is unplugged and issued from the zone write plug work. If this reminder BIO itself needs to be split, the reminder will be re-issued and plugged again, but that causes a call to a blk_queue_enter(), which may block if a queue freeze operation was initiated. This results in a deadlock as DM submission still holds BIOs that the queue freeze side is waiting for. 2) dm-crypt relies on the emulation done by the block layer using regular write operations for processing zone append operations. This still requires to properly return the written sector as the BIO sector of the original BIO. However, this can be done correctly only and only if there is a single clone BIO used for processing the original zone append operation issued by the user. If the size of a zone append operation is larger than dm-crypt max_write_size, then the orginal BIO will be split and processed as a chain of regular write operations. Such chaining result in an incorrect written sector being returned to the zone append issuer using the original BIO sector. This in turn results in file system data corruptions using xfs or btrfs. Fix this by modifying get_max_request_size() to always return the size of the BIO to avoid it being split with dm_accpet_partial_bio() in crypt_map(). get_max_request_size() is renamed to get_max_request_sectors() to clarify the unit of the value returned and its interface is changed to take a struct dm_target pointer and a pointer to the struct bio being processed. In addition to this change, to ensure that crypt_alloc_buffer() works correctly, set the dm-crypt device max_hw_sectors limit to be at most BIO_MAX_VECS << PAGE_SECTORS_SHIFT (1 MB with a 4KB page architecture). This forces DM core to split write BIOs before passing them to crypt_map(), and thus guaranteeing that dm-crypt can always accept an entire write BIO without needing to split it. This change does not have any effect on the read path of dm-crypt. Read operations can still be split and the BIO fragments processed in parallel. There is also no impact on the performance of the write path given that all zone write BIOs were already processed inline instead of in parallel. This change also does not affect in any way regular dm-crypt block devices. Fixes: f211268ed1f9 ("dm: Use the block layer zone append emulation") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Mikulas Patocka <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yang Wang <[email protected]> Date: Thu Jul 24 15:16:18 2025 +0800 drm/amd/amdgpu: fix missing lock for cper.ring->rptr/wptr access commit 8e0d1edb5c16732b695eaf4bd7096b1569817cf0 upstream. Add lock protection for 'ring->wptr'/'ring->rptr' to ensure the correct execution. Fixes: 8652920d2c00 ("drm/amdgpu: add mutex lock for cper ring") Signed-off-by: Yang Wang <[email protected]> Reviewed-by: Tao Zhou <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chenyuan Yang <[email protected]> Date: Wed Jul 23 21:36:41 2025 -0500 drm/amd/display: Add null pointer check in mod_hdcp_hdcp1_create_session() [ Upstream commit 7a2ca2ea64b1b63c8baa94a8f5deb70b2248d119 ] The function mod_hdcp_hdcp1_create_session() calls the function get_first_active_display(), but does not check its return value. The return value is a null pointer if the display list is empty. This will lead to a null pointer dereference. Add a null pointer check for get_first_active_display() and return MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null. This is similar to the commit c3e9826a2202 ("drm/amd/display: Add null pointer check for get_first_active_display()"). Fixes: 2deade5ede56 ("drm/amd/display: Remove hdcp display state with mst fix") Signed-off-by: Chenyuan Yang <[email protected]> Reviewed-by: Alex Hung <[email protected]> Tested-by: Dan Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893) Signed-off-by: Sasha Levin <[email protected]>
Author: Michel Dänzer <[email protected]> Date: Wed Jul 30 10:09:02 2025 +0200 drm/amd/display: Add primary plane to commits for correct VRR handling commit 3477c1b0972dc1c8a46f78e8fb1fa6966095b5ec upstream. amdgpu_dm_commit_planes calls update_freesync_state_on_stream only for the primary plane. If a commit affects a CRTC but not its primary plane, it would previously not trigger a refresh cycle or affect LFC, violating current UAPI semantics. Fixes e.g. atomic commits affecting only the cursor plane being limited to the minimum refresh rate. Don't do this for the legacy cursor ioctls though, it would break the UAPI semantics for those. Suggested-by: Xaver Hugl <[email protected]> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3034 Signed-off-by: Michel Dänzer <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit cc7bfba95966251b254cb970c21627124da3b7f4) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Thu Jul 31 11:43:47 2025 +0200 drm/amd/display: Adjust DCE 8-10 clock, don't overclock by 15% [ Upstream commit 1fc931be2f47fde23ca5aff6f19421375c312fb2 ] Adjust the nominal (and performance) clocks for DCE 8-10, and set them to 625 MHz, which is the value used by the legacy display code in amdgpu_atombios_get_clock_info. This was tested with Hawaii, Tonga and Fiji. These GPUs can output 4K 60Hz (10-bit depth) at 625 MHz. The extra 15% clock was added as a workaround for a Polaris issue which uses DCE 11, and should not have been used on DCE 8-10 which are already hardcoded to the highest possible display clock. Unfortunately, the extra 15% was mistakenly copied and kept even on code paths which don't affect Polaris. This commit fixes that and also adds a check to make sure not to exceed the maximum DCE 8-10 display clock. Fixes: 8cd61c313d8b ("drm/amd/display: Raise dispclk value for Polaris") Fixes: dc88b4a684d2 ("drm/amd/display: make clk mgr soc specific") Signed-off-by: Timur Kristóf <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Reviewed-by: Alex Hung <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 1ae45b5d4f371af8ae51a3827d0ec9fe27eeb867) Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Thu Jul 24 15:00:43 2025 -0500 drm/amd/display: Avoid a NULL pointer dereference commit 07b93a5704b0b72002f0c4bd1076214af67dc661 upstream. [WHY] Although unlikely drm_atomic_get_new_connector_state() or drm_atomic_get_old_connector_state() can return NULL. [HOW] Check returns before dereference. Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Hung <[email protected]> Tested-by: Dan Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Thu Jul 31 11:43:46 2025 +0200 drm/amd/display: Don't overclock DCE 6 by 15% commit cb7b7ae53b557d168b4af5cd8549f3eff920bfb5 upstream. The extra 15% clock was added as a workaround for a Polaris issue which uses DCE 11, and should not have been used on DCE 6 which is already hardcoded to the highest possible display clock. Unfortunately, the extra 15% was mistakenly copied and kept even on code paths which don't affect Polaris. This commit fixes that and also adds a check to make sure not to exceed the maximum DCE 6 display clock. Fixes: 8cd61c313d8b ("drm/amd/display: Raise dispclk value for Polaris") Fixes: dc88b4a684d2 ("drm/amd/display: make clk mgr soc specific") Fixes: 3ecb3b794e2c ("drm/amd/display: dc/clk_mgr: add support for SI parts (v2)") Signed-off-by: Timur Kristóf <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Reviewed-by: Alex Hung <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 427980c1cbd22bb256b9385f5ce73c0937562408) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Tue Jul 22 17:58:29 2025 +0200 drm/amd/display: Don't overwrite dce60_clk_mgr commit 4db9cd554883e051df1840d4d58d636043101034 upstream. dc_clk_mgr_create accidentally overwrites the dce60_clk_mgr with the dce_clk_mgr, causing incorrect behaviour on DCE6. Fix it by removing the extra dce_clk_mgr_construct. Fixes: 62eab49faae7 ("drm/amd/display: hide VGH asic specific structs") Reviewed-by: Rodrigo Siqueira <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Timur Kristóf <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit bbddcbe36a686af03e91341b9bbfcca94bd45fb6) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Thu Jul 31 11:43:51 2025 +0200 drm/amd/display: Don't print errors for nonexistent connectors [ Upstream commit f14ee2e7a86c5e57295b48b8e198cae7189b3b93 ] When getting the number of connectors, the VBIOS reports the number of valid indices, but it doesn't say which indices are valid, and not every valid index has an actual connector. If we don't find a connector on an index, that is not an error. Considering these are not actual errors, don't litter the logs. Fixes: 60df5628144b ("drm/amd/display: handle invalid connector indices") Signed-off-by: Timur Kristóf <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Reviewed-by: Alex Hung <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 249d4bc5f1935f04bb45b3b63c0f8922565124f7) Signed-off-by: Sasha Levin <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Thu Jul 31 11:43:49 2025 +0200 drm/amd/display: Fill display clock and vblank time in dce110_fill_display_configs commit 7d07140d37f792f01cfdb8ca9a6a792ab1d29126 upstream. Also needed by DCE 6. This way the code that gathers this info can be shared between different DCE versions and doesn't have to be repeated. Signed-off-by: Timur Kristóf <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Reviewed-by: Alex Hung <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 8107432dff37db26fcb641b6cebeae8981cd73a0) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Thu Jul 31 11:43:48 2025 +0200 drm/amd/display: Find first CRTC and its line time in dce110_fill_display_configs commit 669f73a26f6112eedbadac53a2f2707ac6d0b9c8 upstream. dce110_fill_display_configs is shared between DCE 6-11, and finding the first CRTC and its line time is relevant to DCE 6 too. Move the code to find it from DCE 11 specific code. Signed-off-by: Timur Kristóf <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Reviewed-by: Alex Hung <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 4ab09785f8d5d03df052827af073d5c508ff5f63) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Siyang Liu <[email protected]> Date: Fri Jul 4 11:16:22 2025 +0800 drm/amd/display: fix a Null pointer dereference vulnerability commit 1bcf63a44381691d6192872801f830ce3250e367 upstream. [Why] A null pointer dereference vulnerability exists in the AMD display driver's (DC module) cleanup function dc_destruct(). When display control context (dc->ctx) construction fails (due to memory allocation failure), this pointer remains NULL. During subsequent error handling when dc_destruct() is called, there's no NULL check before dereferencing the perf_trace member (dc->ctx->perf_trace), causing a kernel null pointer dereference crash. [How] Check if dc->ctx is non-NULL before dereferencing. Link: https://lore.kernel.org/r/[email protected] Co-developed-by: Mario Limonciello <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> (Updated commit text and removed unnecessary error message) Signed-off-by: Siyang Liu <[email protected]> Signed-off-by: Roman Li <[email protected]> Reviewed-by: Alex Hung <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Tue Jul 22 17:58:30 2025 +0200 drm/amd/display: Fix DCE 6.0 and 6.4 PLL programming. commit 1c8dc3e088e09531bcdfc9fe348204abc3decb6c upstream. Apparently, both DCE 6.0 and 6.4 have 3 PLLs, but PLL0 can only be used for DP. Make sure to initialize the correct amount of PLLs in DC for these DCE versions and use PLL0 only for DP. Also, on DCE 6.0 and 6.4, the PLL0 needs to be powered on at initialization as opposed to DCE 6.1 and 7.x which use a different clock source for DFS. The following functions were used as reference from the old radeon driver implementation of DCE 6.x: - radeon_atom_pick_pll - atombios_crtc_set_disp_eng_pll Reviewed-by: Rodrigo Siqueira <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Timur Kristóf <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 35222b5934ec8d762473592ece98659baf6bc48e) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Sat Aug 2 17:51:53 2025 +0200 drm/amd/display: Fix DP audio DTO1 clock source on DCE 6. commit 297a4833a68aac3316eb808b4123eb016ef242d7 upstream. On DCE 6, DP audio was not working. However, it worked when an HDMI monitor was also plugged in. Looking at dce_aud_wall_dto_setup it seems that the main difference is that we use DTO1 when only DP is plugged in. When programming DTO1, it uses audio_dto_source_clock_in_khz which is set from get_dp_ref_freq_khz The dce60_get_dp_ref_freq_khz implementation looks incorrect, because DENTIST_DISPCLK_CNTL seems to be always zero on DCE 6, so it isn't usable. I compared dce60_get_dp_ref_freq_khz to the legacy display code, specifically dce_v6_0_audio_set_dto, and it turns out that in case of DCE 6, it needs to use the display clock. With that, DP audio started working on Pitcairn, Oland and Cape Verde. However, it still didn't work on Tahiti. Despite having the same DCE version, Tahiti seems to have a different audio device. After some trial and error I realized that it works with the default display clock as reported by the VBIOS, not the current display clock. The patch was tested on all four SI GPUs: * Pitcairn (DCE 6.0) * Oland (DCE 6.4) * Cape Verde (DCE 6.0) * Tahiti (DCE 6.0 but different) The testing was done on Samsung Odyssey G7 LS28BG700EPXEN on each of the above GPUs, at the following settings: * 4K 60 Hz * 1080p 60 Hz * 1080p 144 Hz Acked-by: Alex Deucher <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Timur Kristóf <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 645cc7863da5de700547d236697dffd6760cf051) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Thu Jul 31 11:43:52 2025 +0200 drm/amd/display: Fix fractional fb divider in set_pixel_clock_v3 commit 10507478468f165ea681605d133991ed05cdff62 upstream. For later VBIOS versions, the fractional feedback divider is calculated as the remainder of dividing the feedback divider by a factor, which is set to 1000000. For reference, see: - calculate_fb_and_fractional_fb_divider - calc_pll_max_vco_construct However, in case of old VBIOS versions that have set_pixel_clock_v3, they only have 1 byte available for the fractional feedback divider, and it's expected to be set to the remainder from dividing the feedback divider by 10. For reference see the legacy display code: - amdgpu_pll_compute - amdgpu_atombios_crtc_program_pll This commit fixes set_pixel_clock_v3 by dividing the fractional feedback divider passed to the function by 100000. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Signed-off-by: Timur Kristóf <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Reviewed-by: Alex Hung <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 027e7acc7e17802ebf28e1edb88a404836ad50d6) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lauri Tirkkonen <[email protected]> Date: Mon Jul 21 09:59:40 2025 +0900 drm/amd/display: fix initial backlight brightness calculation commit 9c2883057b3c861879b647f34e8bc448954e8729 upstream. DIV_ROUND_CLOSEST(x, 100) returns either 0 or 1 if 0<x<=100, so the division needs to be performed after the multiplication and not the other way around, to properly scale the value. Fixes: 8b5f3a229a70 ("drm/amd/display: Fix default DC and AC levels") Signed-off-by: Lauri Tirkkonen <[email protected]> Cc: [email protected] Reviewed-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tom Chung <[email protected]> Date: Fri Jul 18 18:25:08 2025 +0800 drm/amd/display: Fix Xorg desktop unresponsive on Replay panel commit 66af73a1c319336694a8610fe4c2943f7b33066c upstream. [WHY & HOW] IPS & self-fresh feature can cause vblank counter resets between vblank disable and enable. It may cause system stuck due to wait the vblank counter. Call the drm_crtc_vblank_restore() during vblank enable to estimate missed vblanks by using timestamps and update the vblank counter in DRM. It can make the vblank counter increase smoothly and resolve this issue. Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Reviewed-by: Sun peng (Leo) Li <[email protected]> Signed-off-by: Tom Chung <[email protected]> Signed-off-by: Alex Hung <[email protected]> Tested-by: Dan Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 34d66bc7ff10e146a4cec76cf286979740a10954) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Thu May 15 15:16:17 2025 -0500 drm/amd/display: Pass up errors for reset GPU that fails to init HW commit 2b6943df54136f40aff8a6d7ba7c26724d89a0bd upstream. [Why] If a GPU is in reset and the hardware fails to initialize the rest of the resume sequence shouldn't be run. [How] Pass error code up to caller of dm_resume(). Reviewed-by: Alex Hung <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Ivan Lipski <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Sun Jul 20 23:39:41 2025 -0500 drm/amd/display: Revert "drm/amd/display: Fix AMDGPU_MAX_BL_LEVEL value" commit 8e6a18cbf3ee2c1e3d0afd8d3debd0ba8738ad0c upstream. This reverts commit 66abb996999de0d440a02583a6e70c2c24deab45. This broke custom brightness curves but it wasn't obvious because of other related changes. Custom brightness curves are always from a 0-255 input signal. The correct fix was to fix the default value which was done by [1]. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4412 Link: https://lore.kernel.org/amd-gfx/[email protected]/T/#m69f875a7e69aa22df3370b3e3a9e69f4a61fdaf2 Reviewed-by: Alex Hung <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Roman Li <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 6ec8a5cbec751625133461600d0d4950ffd3a214) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Sat Aug 23 09:16:47 2025 -0400 drm/amd: Restore cached manual clock settings during resume [ Upstream commit 796ff8a7e01bd18738d3bb4111f9d6f963145d29 ] If the SCLK limits have been set before S3 they will not be restored. The limits are however cached in the driver and so they can be restored by running a commit sequence during resume. Acked-by: Alex Deucher <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 4e9526924d09057a9ba854305e17eded900ced82) Cc: [email protected] [ Adjust context ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Thu Jul 24 22:12:21 2025 -0500 drm/amd: Restore cached power limit during resume commit ed4efe426a49729952b3dc05d20e33b94409bdd1 upstream. The power limit will be cached in smu->current_power_limit but if the ASIC goes into S3 this value won't be restored. Restore the value during SMU resume. Acked-by: Alex Deucher <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 26a609e053a6fc494403e95403bc6a2470383bec) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Wed Jul 30 11:16:05 2025 -0400 drm/amdgpu/discovery: fix fw based ip discovery commit 514678da56da089b756b4d433efd964fa22b2079 upstream. We only need the fw based discovery table for sysfs. No need to parse it. Additionally parsing some of the board specific tables may result in incorrect data on some boards. just load the binary and don't parse it on those boards. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4441 Fixes: 80a0e8282933 ("drm/amdgpu/discovery: optionally use fw based ip discovery") Reviewed-by: Mario Limonciello (AMD) <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 62eedd150fa11aefc2d377fc746633fdb1baeb55) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Fri Aug 8 13:12:07 2025 -0400 drm/amdgpu/swm14: Update power limit logic commit 79e25cd06e85105c75701ef1773c6c64bb304091 upstream. Take into account the limits from the vbios. Ported from the SMU13 code. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4352 Reviewed-by: Jesse Zhang <[email protected]> Reviewed-by: Kenneth Feng <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 203cc7f1dd86f2c8de5c3c6182f19adac7c9c206) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Frank Min <[email protected]> Date: Wed Jun 4 21:39:34 2025 +0800 drm/amdgpu: add kicker fws loading for gfx12/smu14/psp14 commit 0395cde08e1f7eee810b5799466e41635a21e599 upstream. 1. Add kicker firmwares loading for gfx12/smu14/psp14 2. Register additional MODULE_FIRMWARE entries for kicker fws - gc_12_0_1_rlc_kicker.bin - gc_12_0_1_imu_kicker.bin - psp_14_0_3_sos_kicker.bin - psp_14_0_3_ta_kicker.bin - smu_14_0_3_kicker.bin Signed-off-by: Frank Min <[email protected]> Reviewed-by: Gui Chengming <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Mon Aug 4 11:40:20 2025 -0400 drm/amdgpu: add missing vram lost check for LEGACY RESET commit 81699fe81b0be287fb28b6210324db48e8458d9f upstream. Legacy resets reset the memory controllers so VRAM contents may be unreliable after reset. Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit aae94897b6661a2a4b1de2d328090fc388b3e0af) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gang Ba <[email protected]> Date: Tue Jul 8 14:36:13 2025 -0400 drm/amdgpu: Avoid extra evict-restore process. commit 1f02f2044bda1db1fd995bc35961ab075fa7b5a2 upstream. If vm belongs to another process, this is fclose after fork, wait may enable signaling KFD eviction fence and cause parent process queue evicted. [677852.634569] amdkfd_fence_enable_signaling+0x56/0x70 [amdgpu] [677852.634814] __dma_fence_enable_signaling+0x3e/0xe0 [677852.634820] dma_fence_wait_timeout+0x3a/0x140 [677852.634825] amddma_resv_wait_timeout+0x7f/0xf0 [amdkcl] [677852.634831] amdgpu_vm_wait_idle+0x2d/0x60 [amdgpu] [677852.635026] amdgpu_flush+0x34/0x50 [amdgpu] [677852.635208] filp_flush+0x38/0x90 [677852.635213] filp_close+0x14/0x30 [677852.635216] do_close_on_exec+0xdd/0x130 [677852.635221] begin_new_exec+0x1da/0x490 [677852.635225] load_elf_binary+0x307/0xea0 [677852.635231] ? srso_alias_return_thunk+0x5/0xfbef5 [677852.635235] ? ima_bprm_check+0xa2/0xd0 [677852.635240] search_binary_handler+0xda/0x260 [677852.635245] exec_binprm+0x58/0x1a0 [677852.635249] bprm_execve.part.0+0x16f/0x210 [677852.635254] bprm_execve+0x45/0x80 [677852.635257] do_execveat_common.isra.0+0x190/0x200 Suggested-by: Christian König <[email protected]> Signed-off-by: Gang Ba <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Peter Shkenev <[email protected]> Date: Thu Jul 17 23:48:17 2025 +0300 drm/amdgpu: check if hubbub is NULL in debugfs/amdgpu_dm_capabilities commit b4a69f7f29c8a459ad6b4d8a8b72450f1d9fd288 upstream. HUBBUB structure is not initialized on DCE hardware, so check if it is NULL to avoid null dereference while accessing amdgpu_dm_capabilities file in debugfs. Signed-off-by: Peter Shkenev <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Liu01 Tong <[email protected]> Date: Mon Aug 11 14:52:37 2025 +0800 drm/amdgpu: fix task hang from failed job submission during process kill commit aa5fc4362fac9351557eb27c745579159a2e4520 upstream. During process kill, drm_sched_entity_flush() will kill the vm entities. The following job submissions of this process will fail, and the resources of these jobs have not been released, nor have the fences been signalled, causing tasks to hang and timeout. Fix by check entity status in amdgpu_vm_ready() and avoid submit jobs to stopped entity. v2: add amdgpu_vm_ready() check before amdgpu_vm_clear_freed() in function amdgpu_cs_vm_handling(). Fixes: 1f02f2044bda ("drm/amdgpu: Avoid extra evict-restore process.") Signed-off-by: Liu01 Tong <[email protected]> Signed-off-by: Lin.Cao <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit f101c13a8720c73e67f8f9d511fbbeda95bcedb1) Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Tue Jul 15 16:50:22 2025 -0700 drm/amdgpu: Initialize data to NULL in imu_v12_0_program_rlc_ram() commit c90f2e1172c51fa25492471dc9910e2d7c1444b9 upstream. After a recent change in clang to expose uninitialized warnings from const variables and pointers [1], there is a warning in imu_v12_0_program_rlc_ram() because data is passed uninitialized to program_imu_rlc_ram(): drivers/gpu/drm/amd/amdgpu/imu_v12_0.c:374:30: error: variable 'data' is uninitialized when used here [-Werror,-Wuninitialized] 374 | program_imu_rlc_ram(adev, data, (const u32)size); | ^~~~ As this warning happens early in clang's frontend, it does not realize that due to the assignment of r to -EINVAL, program_imu_rlc_ram() is never actually called, and even if it were, data would not be dereferenced because size is 0. Just initialize data to NULL to silence the warning, as the commit that added program_imu_rlc_ram() mentioned it would eventually be used over the old method, at which point data can be properly initialized and used. Cc: [email protected] Closes: https://github.com/ClangBuiltLinux/linux/issues/2107 Fixes: 56159fffaab5 ("drm/amdgpu: use new method to program rlc ram") Link: https://github.com/llvm/llvm-project/commit/2464313eef01c5b1edf0eccf57a32cdee01472c7 [1] Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: YuanShang <[email protected]> Date: Wed Jul 23 16:44:49 2025 +0800 drm/amdgpu: Retain job->vm in amdgpu_job_prepare_job commit c00d8b79fd2167c6ac65e096619535acdf8678d5 upstream. The field job->vm is used in function amdgpu_job_run to get the page table re-generation counter and decide whether the job should be skipped. Specifically, function amdgpu_vm_generation checks if the VM is valid for this job to use. For instance, if a gfx job depends on a cancelled sdma job from entity vm->delayed, then the gfx job should be skipped. Fixes: 26c95e838e63 ("drm/amdgpu: set the VM pointer to NULL in amdgpu_job_prepare") Signed-off-by: YuanShang <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit ed76936c6b10b547c6df4ca75412331e9ef6d339) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Tue Jun 24 11:22:26 2025 -0400 drm/amdgpu: track whether a queue is a kernel queue in amdgpu_mqd_prop commit 284d4dfe850e665f0e7d4dfaf4d3d3da76d11fb0 upstream. Used to to set the MQD appropriately for each queue type. Kernel queues have additional privileges. Acked-by: Christian König <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.16.x Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lijo Lazar <[email protected]> Date: Fri Jul 25 10:21:10 2025 +0530 drm/amdgpu: Update external revid for GC v9.5.0 commit 05c8b690511854ba31d8d1bff7139a13ec66b9e7 upstream. Use different external revid for GC v9.5.0 SOCs. Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Reviewed-by: Asad Kamal <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 21c6764ed4bfaecad034bc4fd15dd64c5a436325) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Fri Jul 18 15:52:04 2025 -0400 drm/amdgpu: update mmhub 3.0.1 client id mappings commit 0bae62cc989fa99ac9cb564eb573aad916d1eb61 upstream. Update the client id mapping so the correct clients get printed when there is a mmhub page fault. Reviewed-by: David (Ming Qiang) Wu <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 2a2681eda73b99a2c1ee8cdb006099ea5d0c2505) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Fri Jul 18 15:53:21 2025 -0400 drm/amdgpu: update mmhub 3.3 client id mappings commit 9f9bddfa31d87b084700a6e9eca1a8b4f8ddcdf6 upstream. Update the client id mapping so the correct clients get printed when there is a mmhub page fault. v2: fix typos spotted by David Wu. v3: fix additional typo spotted by David. Reviewed-by: David (Ming Qiang) Wu <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit e932f4779a2d329841bb9ca70bb80a4bb2d707b6) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Fri Jul 18 15:53:54 2025 -0400 drm/amdgpu: update mmhub 4.1.0 client id mappings commit a0b34e4c8663b13e45c78267b4de3004b1a72490 upstream. Update the client id mapping so the correct clients get printed when there is a mmhub page fault. Tested-by: David (Ming Qiang) Wu <[email protected]> Reviewed-by: David (Ming Qiang) Wu <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lijo Lazar <[email protected]> Date: Tue Jul 8 13:17:18 2025 +0530 drm/amdgpu: Update supported modes for GC v9.5.0 commit 389d79a195a9f71a103b39097ee8341a7ca60927 upstream. For GC v9.5.0 SOCs, both CPX and QPX compute modes are also supported in NPS2 mode. Signed-off-by: Lijo Lazar <[email protected]> Acked-by: Mangesh Gadre <[email protected]> Reviewed-by: Asad Kamal <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 9d1ac25c7f830e0132aa816393b1e9f140e71148) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Amber Lin <[email protected]> Date: Thu Jul 31 20:45:00 2025 -0400 drm/amdkfd: Destroy KFD debugfs after destroy KFD wq commit 2e58401a24e7b2d4ec619104e1a76590c1284a4c upstream. Since KFD proc content was moved to kernel debugfs, we can't destroy KFD debugfs before kfd_process_destroy_wq. Move kfd_process_destroy_wq prior to kfd_debugfs_fini to fix a kernel NULL pointer problem. It happens when /sys/kernel/debug/kfd was already destroyed in kfd_debugfs_fini but kfd_process_destroy_wq calls kfd_debugfs_remove_process. This line debugfs_remove_recursive(entry->proc_dentry); tries to remove /sys/kernel/debug/kfd/proc/<pid> while /sys/kernel/debug/kfd is already gone. It hangs the kernel by kernel NULL pointer. Signed-off-by: Amber Lin <[email protected]> Reviewed-by: Eric Huang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 0333052d90683d88531558dcfdbf2525cc37c233) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Yat Sin <[email protected]> Date: Wed Jul 16 22:04:28 2025 +0000 drm/amdkfd: Fix checkpoint-restore on multi-xcc commit f6c0f3d24478a0792e50a64c2eba9f34d65519f2 upstream. GPUs with multi-xcc have multiple MQDs per queue. This patch saves and restores all the MQDs within the partition. Signed-off-by: David Yat Sin <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit a578f2a58c3ab38f0643b1b6e7534af860233cb1) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Imre Deak <[email protected]> Date: Sat Aug 23 08:56:25 2025 -0400 drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS [ Upstream commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f ] Reading DPCD registers has side-effects in general. In particular accessing registers outside of the link training register range (0x102-0x106, 0x202-0x207, 0x200c-0x200f, 0x2216) is explicitly forbidden by the DP v2.1 Standard, see 3.6.5.1 DPTX AUX Transaction Handling Mandates 3.6.7.4 128b/132b DP Link Layer LTTPR Link Training Mandates Based on my tests, accessing the DPCD_REV register during the link training of an UHBR TBT DP tunnel sink leads to link training failures. Solve the above by using the DP_LANE0_1_STATUS (0x202) register for the DPCD register access quirk. Cc: <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Jani Nikula <[email protected]> Acked-by: Jani Nikula <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ DP_TRAINING_PATTERN_SET => DP_LANE0_1_STATUS ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Baihan Li <[email protected]> Date: Wed Aug 13 17:42:34 2025 +0800 drm/hisilicon/hibmc: fix dp and vga cannot show together [ Upstream commit 3271faf42d135bcf569c3ff6af55c21858eec212 ] If VGA and DP connected together, there will be only one can get crtc. Add encoder possible_clones to support two connectors enable. Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq feature") Signed-off-by: Baihan Li <[email protected]> Signed-off-by: Yongbang Shi <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baihan Li <[email protected]> Date: Wed Aug 13 17:42:30 2025 +0800 drm/hisilicon/hibmc: fix irq_request()'s irq name variable is local [ Upstream commit 8bed4ec42a4e0dc8113172696ff076d1eb6d8bcb ] The local variable is passed in request_irq (), and there will be use after free problem, which will make request_irq failed. Using the global irq name instead of it to fix. Fixes: b11bc1ae4658 ("drm/hisilicon/hibmc: Add MSI irq getting and requesting for HPD") Signed-off-by: Baihan Li <[email protected]> Signed-off-by: Yongbang Shi <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baihan Li <[email protected]> Date: Wed Aug 13 17:42:32 2025 +0800 drm/hisilicon/hibmc: fix rare monitors cannot display problem [ Upstream commit 9f98b429ba67d430b873e06bcfb90afa22888978 ] In some case, the dp link training success at 8.1Gbps, but the sink's maximum supported rate is less than 8.1G. So change the default 8.1Gbps link rate to the rate that reads from devices' capabilities. Fixes: 54063d86e036 ("drm/hisilicon/hibmc: add dp link moduel in hibmc drivers") Signed-off-by: Baihan Li <[email protected]> Signed-off-by: Yongbang Shi <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baihan Li <[email protected]> Date: Wed Aug 13 17:42:31 2025 +0800 drm/hisilicon/hibmc: fix the hibmc loaded failed bug [ Upstream commit 93a08f856fcc5aaeeecad01f71bef3088588216a ] When hibmc loaded failed, the driver use hibmc_unload to free the resource, but the mutexes in mode.config are not init, which will access an NULL pointer. Just change goto statement to return, because hibnc_hw_init() doesn't need to free anything. Fixes: b3df5e65cc03 ("drm/hibmc: Drop drm_vblank_cleanup") Signed-off-by: Baihan Li <[email protected]> Signed-off-by: Yongbang Shi <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baihan Li <[email protected]> Date: Wed Aug 13 17:42:28 2025 +0800 drm/hisilicon/hibmc: fix the i2c device resource leak when vdac init failed [ Upstream commit e5f48bfa2ae0806d5f51fb8061afc619a73599a7 ] Currently the driver missed to clean the i2c adapter when vdac init failed. It may cause resource leak. Fixes: a0d078d06e516 ("drm/hisilicon: Features to support reading resolutions from EDID") Signed-off-by: Baihan Li <[email protected]> Signed-off-by: Yongbang Shi <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sebastian Brzezinka <[email protected]> Date: Mon Aug 11 09:12:31 2025 +0000 drm/i915/gt: Relocate compression repacking WA for JSL/EHL commit 8236820fd767f400d1baefb71bc7e36e37730a1e upstream. CACHE_MODE_0 registers should be saved and restored as part of the context, not during engine reset. Move the related workaround (Disable Repacking for Compression) from rcs_engine_wa_init() to icl_ctx_workarounds_init() for Jasper Lake and Elkhart Lake platforms. This ensures the WA is applied during context initialisation. BSPEC: 11322 Fixes: 0ddae025ab6c ("drm/i915: Disable compression tricks on JSL") Closes: Fixes: 0ddae025ab6c ("drm/i915: Disable compression tricks on JSL") Signed-off-by: Sebastian Brzezinka <[email protected]> Cc: [email protected] # v6.13+ Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Krzysztof Karas <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/4feaa24094e019e000ceb6011d8cd419b0361b3f.1754902406.git.sebastian.brzezinka@intel.com (cherry picked from commit c9932f0d604e4c8f2c6018e598a322acb43c68a2) Signed-off-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Imre Deak <[email protected]> Date: Mon Aug 11 11:01:49 2025 +0300 drm/i915/icl+/tc: Cache the max lane count value commit 5fd35236546abe780eaadb7561e09953719d4fc3 upstream. The PHY's pin assignment value in the TCSS_DDI_STATUS register - as set by the HW/FW based on the connected DP-alt sink's TypeC/PD pin assignment negotiation - gets cleared by the HW/FW on LNL+ as soon as the sink gets disconnected, even if the PHY ownership got acquired already by the driver (and hence the PHY itself is still connected and used by the display). This is similar to how the PHY Ready flag gets cleared on LNL+ in the same register. To be able to query the max lane count value on LNL+ - which is based on the above pin assignment - at all times even after the sink gets disconnected, the max lane count must be determined and cached during the PHY's HW readout and connect sequences. Do that here, leaving the actual use of the cached value to a follow-up change. v2: Don't read out the pin configuration if the PHY is disconnected. Cc: [email protected] # v6.8+ Reported-by: Charlton Lin <[email protected]> Tested-by: Khaled Almahallawy <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 3e32438fc406761f81b1928d210b3d2a5e7501a0) Signed-off-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Imre Deak <[email protected]> Date: Mon Aug 11 11:01:52 2025 +0300 drm/i915/icl+/tc: Convert AUX powered WARN to a debug message commit d7fa5754e83cd36c4327eb2d806064e598a72ff6 upstream. The BIOS can leave the AUX power well enabled on an output, even if this isn't required (on platforms where the AUX power is only needed for an AUX access). This was observed at least on PTL. To avoid the WARN which would be triggered by this during the HW readout, convert the WARN to a debug message. Cc: [email protected] # v6.8+ Reported-by: Charlton Lin <[email protected]> Tested-by: Khaled Almahallawy <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 6cb52cba474b2bec1a3018d3dbf75292059a29a1) Signed-off-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Imre Deak <[email protected]> Date: Mon Aug 11 11:01:48 2025 +0300 drm/i915/lnl+/tc: Fix handling of an enabled/disconnected dp-alt sink commit f52d6aa98379842fc255d93282655566f2114e0c upstream. The TypeC PHY HW readout during driver loading and system resume determines which TypeC mode the PHY is in (legacy/DP-alt/TBT-alt) and whether the PHY is connected, based on the PHY's Owned and Ready flags. For the PHY to be in DP-alt or legacy mode and for the PHY to be in the connected state in these modes, both the Owned (set by the BIOS/driver) and the Ready (set by the HW) flags should be set. On ICL-MTL the HW kept the PHY's Ready flag set after the driver connected the PHY by acquiring the PHY ownership (by setting the Owned flag), until the driver disconnected the PHY by releasing the PHY ownership (by clearing the Owned flag). On LNL+ this has changed, in that the HW clears the Ready flag as soon as the sink gets disconnected, even if the PHY ownership was acquired already and hence the PHY is being used by the display. When inheriting the HW state from BIOS for a PHY connected in DP-alt mode on which the sink got disconnected - i.e. in a case where the sink was connected while BIOS/GOP was running and so the sink got enabled connecting the PHY, but the user disconnected the sink by the time the driver loaded - the PHY Owned but not Ready state must be accounted for on LNL+ according to the above. Do that by assuming on LNL+ that the PHY is connected in DP-alt mode whenever the PHY Owned flag is set, regardless of the PHY Ready flag. This fixes a problem on LNL+, where the PHY TypeC mode / connected state was detected incorrectly for a DP-alt sink, which got connected and then disconnected by the user in the above way. v2: Rename tc_phy_in_legacy_or_dp_alt_mode() to tc_phy_owned_by_display(). (Luca, Jani) Cc: Jani Nikula <[email protected]> Cc: [email protected] # v6.8+ Reported-by: Charlton Lin <[email protected]> Tested-by: Khaled Almahallawy <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Reviewed-by: Luca Coelho <[email protected]> [Imre: Add one-liner function documentation for tc_phy_owned_by_display()] Signed-off-by: Imre Deak <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 89f4b196ee4b056e0e8c179b247b29d4a71a4e7e) Signed-off-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Imre Deak <[email protected]> Date: Mon Aug 11 11:01:50 2025 +0300 drm/i915/lnl+/tc: Fix max lane count HW readout commit c87514a0bb0a64507412a2d98264060dc0c1562a upstream. On LNL+ for a disconnected sink the pin assignment value gets cleared by the HW/FW as soon as the sink gets disconnected, even if the PHY ownership got acquired already by the BIOS/driver (and hence the PHY itself is still connected and used by the display). During HW readout this can result in detecting the PHY's max lane count as 0 - matching the above cleared aka NONE pin assignment HW state. For a connected PHY the driver in general (outside of intel_tc.c) expects the max lane count value to be valid for the video mode enabled on the corresponding output (1, 2 or 4). Ensure this by setting the max lane count to 4 in this case. Note, that it doesn't matter if this lane count happened to be more than the max lane count with which the PHY got connected and enabled, since the only thing the driver can do with such an output - where the DP-alt sink is disconnected - is to disable the output. v2: Rebased on change reading out the pin configuration only if the PHY is connected. Cc: [email protected] # v6.8+ Reported-by: Charlton Lin <[email protected]> Tested-by: Khaled Almahallawy <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 33cf70bc0fe760224f892bc1854a33665f27d482) Signed-off-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Imre Deak <[email protected]> Date: Mon Aug 11 11:01:51 2025 +0300 drm/i915/lnl+/tc: Use the cached max lane count value commit c5c2b4b3841666be3a45346d0ffa96b4b143504e upstream. Use the cached max lane count value on LNL+, to account for scenarios where this value is queried after the HW cleared the corresponding pin assignment value in the TCSS_DDI_STATUS register after the sink got disconnected. For consistency, follow-up changes will use the cached max lane count value on other platforms as well and will also cache the pin assignment value in a similar way. Cc: [email protected] # v6.8+ Reported-by: Charlton Lin <[email protected]> Tested-by: Khaled Almahallawy <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit afc4e84388079f4d5ba05271632b7a4d8d85165c) Signed-off-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jani Nikula <[email protected]> Date: Tue Aug 5 14:56:56 2025 +0300 drm/i915: silence rpm wakeref asserts on GEN11_GU_MISC_IIR access commit ff646d033783068cc5b38924873cab4a536b17c1 upstream. Commit 8d9908e8fe9c ("drm/i915/display: remove small micro-optimizations in irq handling") not only removed the optimizations, it also enabled wakeref asserts for the GEN11_GU_MISC_IIR access. Silence the asserts by wrapping the access inside intel_display_rpm_assert_{block,unblock}(). Reported-by: "Jason A. Donenfeld" <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Fixes: 8d9908e8fe9c ("drm/i915/display: remove small micro-optimizations in irq handling") Cc: [email protected] # v6.13+ Suggested-by: Ville Syrjälä <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jani Nikula <[email protected]> (cherry picked from commit cbd3baeffbc08052ce7dc53f11bf5524b4411056) Signed-off-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qianfeng Rong <[email protected]> Date: Wed Aug 13 20:54:04 2025 +0800 drm/nouveau/gsp: fix mismatched alloc/free for kvmalloc() commit 989fe6771266bdb82a815d78802c5aa7c918fdfd upstream. Replace kfree() with kvfree() for memory allocated by kvmalloc(). Compile-tested only. Cc: [email protected] Fixes: 8a8b1ec5261f ("drm/nouveau/gsp: split rpc handling out on its own") Signed-off-by: Qianfeng Rong <[email protected]> Reviewed-by: Timur Tabi <[email protected]> Acked-by: Zhi Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Fanhua Li <[email protected]> Date: Mon Jul 28 19:50:27 2025 +0800 drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor(). [ Upstream commit bb8aeaa3191b617c6faf8ae937252e059673b7ea ] When the nvif_vmm_type is invalid, we will return error directly without freeing the args in nvif_vmm_ctor(), which leading a memory leak. Fix it by setting the ret -EINVAL and goto done. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Fixes: 6b252cf42281 ("drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm") Signed-off-by: Fanhua Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jocelyn Falempe <[email protected]> Date: Fri Jun 27 14:38:19 2025 +0200 drm/panic: Add a u64 divide by 10 for arm32 [ Upstream commit 9af8f2b469c0438620832f3729a3c5c03853b56b ] On 32bits ARM, u64 divided by a constant is not optimized to a multiply by inverse by the compiler [1]. So do the multiply by inverse explicitly for this architecture. Link: https://github.com/llvm/llvm-project/issues/37280 [1] Reported-by: Andrei Lalaev <[email protected]> Closes: https://lore.kernel.org/dri-devel/[email protected]/ Fixes: 675008f196ca ("drm/panic: Use a decimal fifo to avoid u64 by u64 divide") Reviewed-by: Alice Ryhl <[email protected]> Signed-off-by: Jocelyn Falempe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Mon Jun 16 10:37:04 2025 +0200 drm/tests: Do not use drm_fb_blit() in format-helper tests [ Upstream commit 5a4856e0e38109ba994f369962f054ecb445c098 ] Export additional helpers from the format-helper library and open-code drm_fb_blit() in tests. Prepares for the removal of drm_fb_blit(). Only sysfb drivers use drm_fb_blit(). The function will soon be removed from format helpers and be refactored within sysfb helpers. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: José Expósito <[email protected]> Acked-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: 05663d88fd0b ("drm/tests: Fix drm_test_fb_xrgb8888_to_xrgb2101010() on big-endian") Signed-off-by: Sasha Levin <[email protected]>
Author: José Expósito <[email protected]> Date: Mon Jun 30 11:00:54 2025 +0200 drm/tests: Fix drm_test_fb_xrgb8888_to_xrgb2101010() on big-endian [ Upstream commit 05663d88fd0b8ee1c54ab2d5fb36f9b6a3ed37f7 ] Fix failures on big-endian architectures on tests cases single_pixel_source_buffer, single_pixel_clip_rectangle, well_known_colors and destination_pitch. Fixes: 15bda1f8de5d ("drm/tests: Add calls to drm_fb_blit() on supported format conversion tests") Signed-off-by: José Expósito <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: José Expósito <[email protected]> Date: Mon Jun 30 11:00:53 2025 +0200 drm/tests: Fix endian warning [ Upstream commit d28b9d2925b4f773adb21b1fc20260ddc370fb13 ] When compiling with sparse enabled, this warning is thrown: warning: incorrect type in argument 2 (different base types) expected restricted __le32 const [usertype] *buf got unsigned int [usertype] *[assigned] buf Add a cast to fix it. Fixes: 453114319699 ("drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_xrgb2101010()") Signed-off-by: José Expósito <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Vodapalli, Ravi Kumar <[email protected]> Date: Fri Jul 4 16:05:27 2025 +0530 drm/xe/bmg: Add one additional PCI ID commit ccfb15b8158c11a8304204aeac354c7b1cfb18a3 upstream. One additional PCI ID is added in Bspec for BMG, Add it so that driver recognizes this device with this new ID. Bspec: 68090 Cc: [email protected] # v6.12+ Signed-off-by: Vodapalli, Ravi Kumar <[email protected]> Reviewed-by: Shekhar Chauhan <[email protected]> Acked-by: Matthew Auld <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Piotr Piórkowski <[email protected]> Date: Mon Aug 11 12:43:57 2025 +0200 drm/xe: Assign ioctl xe file handler to vm in xe_vm_create [ Upstream commit 658a1c8e0a66d0777e0e37a11ba19f27a81e77f4 ] In several code paths, such as xe_pt_create(), the vm->xef field is used to determine whether a VM originates from userspace or the kernel. Previously, this handler was only assigned in xe_vm_create_ioctl(), after the VM was created by xe_vm_create(). However, xe_vm_create() triggers page table creation, and that function assumes vm->xef should be already set. This could lead to incorrect origin detection. To fix this problem and ensure consistency in the initialization of the VM object, let's move the assignment of this handler to xe_vm_create. v2: - take reference to the xe file object only when xef is not NULL - release the reference to the xe file object on the error path (Matthew) Fixes: 7f387e6012b6 ("drm/xe: add XE_BO_FLAG_PINNED_LATE_RESTORE") Signed-off-by: Piotr Piórkowski <[email protected]> Cc: Matthew Auld <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michał Winiarski <[email protected]> (cherry picked from commit 9337166fa1d80f7bb7c7d3a8f901f21c348c0f2a) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Hellström <[email protected]> Date: Tue Aug 5 09:48:42 2025 +0200 drm/xe: Defer buffer object shrinker write-backs and GPU waits commit 2dd7a47669ae6c1da18c55f8e89c4a44418c7006 upstream. When the xe buffer-object shrinker allows GPU waits and write-back, (typically from kswapd), perform multiple passes, skipping subsequent passes if the shrinker number of scanned objects target is reached. 1) Without GPU waits and write-back 2) Without write-back 3) With both GPU-waits and write-back This is to avoid stalls and costly write- and readbacks unless they are really necessary. v2: - Don't test for scan completion twice. (Stuart Summers) - Update tags. Reported-by: melvyn <[email protected]> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5557 Cc: Summers Stuart <[email protected]> Fixes: 00c8efc3180f ("drm/xe: Add a shrinker for xe bos") Cc: <[email protected]> # v6.15+ Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Stuart Summers <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 80944d334182ce5eb27d00e2bf20a88bfc32dea1) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christoph Manszewski <[email protected]> Date: Wed Aug 13 12:12:30 2025 +0200 drm/xe: Fix vm_bind_ioctl double free bug [ Upstream commit 111fb43a557726079a67ce3ab51f602ddbf7097e ] If the argument check during an array bind fails, the bind_ops are freed twice as seen below. Fix this by setting bind_ops to NULL after freeing. ================================================================== BUG: KASAN: double-free in xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] Free of addr ffff88813bb9b800 by task xe_vm/14198 CPU: 5 UID: 0 PID: 14198 Comm: xe_vm Not tainted 6.16.0-xe-eudebug-cmanszew+ #520 PREEMPT(full) Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS ADLPFWI1.R00.2411.A02.2110081023 10/08/2021 Call Trace: <TASK> dump_stack_lvl+0x82/0xd0 print_report+0xcb/0x610 ? __virt_addr_valid+0x19a/0x300 ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] kasan_report_invalid_free+0xc8/0xf0 ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] check_slab_allocation+0x102/0x130 kfree+0x10d/0x440 ? should_fail_ex+0x57/0x2f0 ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] ? __lock_acquire+0xab9/0x27f0 ? lock_acquire+0x165/0x300 ? drm_dev_enter+0x53/0xe0 [drm] ? find_held_lock+0x2b/0x80 ? drm_dev_exit+0x30/0x50 [drm] ? drm_ioctl_kernel+0x128/0x1c0 [drm] drm_ioctl_kernel+0x128/0x1c0 [drm] ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] ? find_held_lock+0x2b/0x80 ? __pfx_drm_ioctl_kernel+0x10/0x10 [drm] ? should_fail_ex+0x57/0x2f0 ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] drm_ioctl+0x352/0x620 [drm] ? __pfx_drm_ioctl+0x10/0x10 [drm] ? __pfx_rpm_resume+0x10/0x10 ? do_raw_spin_lock+0x11a/0x1b0 ? find_held_lock+0x2b/0x80 ? __pm_runtime_resume+0x61/0xc0 ? rcu_is_watching+0x20/0x50 ? trace_irq_enable.constprop.0+0xac/0xe0 xe_drm_ioctl+0x91/0xc0 [xe] __x64_sys_ioctl+0xb2/0x100 ? rcu_is_watching+0x20/0x50 do_syscall_64+0x68/0x2e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fa9acb24ded Fixes: b43e864af0d4 ("drm/xe/uapi: Add DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR") Cc: Matthew Brost <[email protected]> Cc: Himal Prasad Ghimiray <[email protected]> Cc: Thomas Hellström <[email protected]> Signed-off-by: Christoph Manszewski <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit a01b704527c28a2fd43a17a85f8996b75ec8492a) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Piotr Piórkowski <[email protected]> Date: Mon Aug 11 12:43:58 2025 +0200 drm/xe: Move ASID allocation and user PT BO tracking into xe_vm_create [ Upstream commit 8a30114073639fd97f2c7390abbc34fb8711327a ] Currently, ASID assignment for user VMs and page-table BO accounting for client memory tracking are performed in xe_vm_create_ioctl. To consolidate VM object initialization, move this logic to xe_vm_create. v2: - removed unnecessary duplicate BO tracking code - using the local variable xef to verify whether the VM is being created by userspace Fixes: 658a1c8e0a66 ("drm/xe: Assign ioctl xe file handler to vm in xe_vm_create") Suggested-by: Matthew Auld <[email protected]> Signed-off-by: Piotr Piórkowski <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michał Winiarski <[email protected]> (cherry picked from commit 30e0c3f43a414616e0b6ca76cf7f7b2cd387e1d4) Signed-off-by: Rodrigo Vivi <[email protected]> [Rodrigo: Added fixes tag] Signed-off-by: Sasha Levin <[email protected]>
Author: Miguel Ojeda <[email protected]> Date: Thu Jul 24 18:54:41 2025 +0200 drm: nova-drm: fix 32-bit arm build [ Upstream commit db2e7bcee11cd57f95fef3c6cbb562d0577eb84a ] In 32-bit arm, the build fails with: error[E0308]: mismatched types --> drivers/gpu/drm/nova/file.rs:42:28 | 42 | getparam.set_value(value); | --------- ^^^^^ expected `u64`, found `u32` | | | arguments to this method are incorrect | note: method defined here --> drivers/gpu/drm/nova/uapi.rs:29:12 | 29 | pub fn set_value(&self, v: u64) { | ^^^^^^^^^ ------ help: you can convert a `u32` to a `u64` | 42 | getparam.set_value(value.into()); | +++++++ The reason is that `Getparam::set_value` takes a `u64` (from the UAPI), but `pci::Device::resource_len()` returns a `resource_size_t`, which is a `phys_addr_t`, which may be 32- or 64-bit. Thus add an `into()` call to support the 32-bit case, while allowing the Clippy lint that complains in the 64-bit case where the type is the same. Fixes: cdeaeb9dd762 ("drm: nova-drm: add initial driver skeleton") Signed-off-by: Miguel Ojeda <[email protected]> Reviewed-by: Christian Schrefl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Sun Jul 20 14:30:04 2025 +0200 dt-bindings: display: sprd,sharkl3-dpu: Fix missing clocks constraints commit 934da599e694d476f493d3927a30414e98a81561 upstream. 'minItems' alone does not impose upper bound, unlike 'maxItems' which implies lower bound. Add missing clock constraint so the list will have exact number of items (clocks). Fixes: 8cae15c60cf0 ("dt-bindings: display: add Unisoc's dpu bindings") Cc: [email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Sun Jul 20 14:30:05 2025 +0200 dt-bindings: display: sprd,sharkl3-dsi-host: Fix missing clocks constraints commit 2558df8c13ae3bd6c303b28f240ceb0189519c91 upstream. 'minItems' alone does not impose upper bound, unlike 'maxItems' which implies lower bound. Add missing clock constraint so the list will have exact number of items (clocks). Fixes: 2295bbd35edb ("dt-bindings: display: add Unisoc's mipi dsi controller bindings") Cc: [email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cristian Ciocaltea <[email protected]> Date: Thu Jun 12 00:47:47 2025 +0300 dt-bindings: display: vop2: Add optional PLL clock property for rk3576 commit 3832dc42aed9b047ccecebf5917d008bd2dac940 upstream. As with the RK3588 SoC, RK3576 also allows the use of HDMI PHY PLL as an alternative and more accurate pixel clock source for VOP2. Document the optional PLL clock property. Moreover, given that this is part of a series intended to address some recent display problems, provide the appropriate tags to facilitate backporting. Fixes: c3b7c5a4d7c1 ("dt-bindings: display: vop2: Add rk3576 support") Cc: [email protected] Signed-off-by: Cristian Ciocaltea <[email protected]> Reviewed-by: "Rob Herring (Arm)" <[email protected]> Tested-by: Nicolas Frattaroli <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Wed Jul 30 14:44:49 2025 +0200 erofs: Do not select tristate symbols from bool symbols commit 74da24f0ac9b8aabfb8d7feeba6c32ddff3065e0 upstream. The EROFS filesystem has many configurable options, controlled through boolean Kconfig symbols. When enabled, these options may need to enable additional library functionality elsewhere. Currently this is done by selecting the symbol for the additional functionality. However, if EROFS_FS itself is modular, and the target symbol is a tristate symbol, the additional functionality is always forced built-in. Selecting tristate symbols from a tristate symbol does keep modular transitivity. Hence fix this by moving selects of tristate symbols to the main EROFS_FS symbol. Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Gao Xiang <[email protected]> Link: https://lore.kernel.org/r/da1b899e511145dd43fd2d398f64b2e03c6a39e7.1753879351.git.geert+renesas@glider.be Signed-off-by: Gao Xiang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bo Liu (OpenAnolis) <[email protected]> Date: Thu Jul 17 23:30:39 2025 -0400 erofs: fix build error with CONFIG_EROFS_FS_ZIP_ACCEL=y commit 5e0bf36fd156b8d9b09f8481ee6daa6cdba1b064 upstream. fix build err: ld.lld: error: undefined symbol: crypto_req_done referenced by decompressor_crypto.c fs/erofs/decompressor_crypto.o:(z_erofs_crypto_decompress) in archive vmlinux.a referenced by decompressor_crypto.c fs/erofs/decompressor_crypto.o:(z_erofs_crypto_decompress) in archive vmlinux.a ld.lld: error: undefined symbol: crypto_acomp_decompress referenced by decompressor_crypto.c fs/erofs/decompressor_crypto.o:(z_erofs_crypto_decompress) in archive vmlinux.a ld.lld: error: undefined symbol: crypto_alloc_acomp referenced by decompressor_crypto.c fs/erofs/decompressor_crypto.o:(z_erofs_crypto_enable_engine) in archive vmlinux.a Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: b4a29efc5146 ("erofs: support DEFLATE decompression by using Intel QAT") Signed-off-by: Bo Liu (OpenAnolis) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Gao Xiang <[email protected]> Signed-off-by: Gao Xiang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andreas Dilger <[email protected]> Date: Wed Jul 16 19:36:42 2025 -0600 ext4: check fast symlink for ea_inode correctly commit b4cc4a4077268522e3d0d34de4b2dc144e2330fa upstream. The check for a fast symlink in the presence of only an external xattr inode is incorrect. If a fast symlink does not have an xattr block (i_file_acl == 0), but does have an external xattr inode that increases inode i_blocks, then the check for a fast symlink will incorrectly fail and __ext4_iget()->ext4_ind_check_inode() will report the inode is corrupt when it "validates" i_data[] on the next read: # ln -s foo /mnt/tmp/bar # setfattr -h -n trusted.test \ -v "$(yes | head -n 4000)" /mnt/tmp/bar # umount /mnt/tmp # mount /mnt/tmp # ls -l /mnt/tmp ls: cannot access '/mnt/tmp/bar': Structure needs cleaning total 4 ? l?????????? ? ? ? ? ? bar # dmesg | tail -1 EXT4-fs error (device dm-8): __ext4_iget:5098: inode #24578: block 7303014: comm ls: invalid block (note that "block 7303014" = 0x6f6f66 = "foo" in LE order). ext4_inode_is_fast_symlink() should check the superblock EXT4_FEATURE_INCOMPAT_EA_INODE feature flag, not the inode EXT4_EA_INODE_FL, since the latter is only set on the xattr inode itself, and not on the inode that uses this xattr. Cc: [email protected] Fixes: fc82228a5e38 ("ext4: support fast symlinks from ext3 file systems") Signed-off-by: Andreas Dilger <[email protected]> Reviewed-by: Li Dongyang <[email protected]> Reviewed-by: Alex Zhuravlev <[email protected]> Reviewed-by: Oleg Drokin <[email protected]> Reviewed-on: https://review.whamcloud.com/59879 Lustre-bug-id: https://jira.whamcloud.com/browse/LU-19121 Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Theodore Ts'o <[email protected]> Date: Thu Aug 7 09:35:20 2025 -0400 ext4: don't try to clear the orphan_present feature block device is r/o commit c5e104a91e7b6fa12c1dc2d8bf84abb7ef9b89ad upstream. When the file system is frozen in preparation for taking an LVM snapshot, the journal is checkpointed and if the orphan_file feature is enabled, and the orphan file is empty, we clear the orphan_present feature flag. But if there are pending inodes that need to be removed the orphan_present feature flag can't be cleared. The problem comes if the block device is read-only. In that case, we can't process the orphan inode list, so it is skipped in ext4_orphan_cleanup(). But then in ext4_mark_recovery_complete(), this results in the ext4 error "Orphan file not empty on read-only fs" firing and the file system mount is aborted. Fix this by clearing the needs_recovery flag in the block device is read-only. We do this after the call to ext4_load_and_init-journal() since there are some error checks need to be done in case the journal needs to be replayed and the block device is read-only, or if the block device containing the externa journal is read-only, etc. Cc: [email protected] Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1108271 Cc: [email protected] Fixes: 02f310fcf47f ("ext4: Speedup ext4 orphan inode handling") Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ojaswin Mujoo <[email protected]> Date: Tue Aug 5 14:00:30 2025 +0530 ext4: fix fsmap end of range reporting with bigalloc commit bae76c035bf0852844151e68098c9b7cd63ef238 upstream. With bigalloc enabled, the logic to report last extent has a bug since we try to use cluster units instead of block units. This can cause an issue where extra incorrect entries might be returned back to the user. This was flagged by generic/365 with 64k bs and -O bigalloc. ** Details of issue ** The issue was noticed on 5G 64k blocksize FS with -O bigalloc which has only 1 bg. $ xfs_io -c "fsmap -d" /mnt/scratch 0: 253:48 [0..127]: static fs metadata 128 /* sb */ 1: 253:48 [128..255]: special 102:1 128 /* gdt */ 3: 253:48 [256..383]: special 102:3 128 /* block bitmap */ 4: 253:48 [384..2303]: unknown 1920 /* flex bg empty space */ 5: 253:48 [2304..2431]: special 102:4 128 /* inode bitmap */ 6: 253:48 [2432..4351]: unknown 1920 /* flex bg empty space */ 7: 253:48 [4352..6911]: inodes 2560 8: 253:48 [6912..538623]: unknown 531712 9: 253:48 [538624..10485759]: free space 9947136 The issue can be seen with: $ xfs_io -c "fsmap -d 0 3" /mnt/scratch 0: 253:48 [0..127]: static fs metadata 128 1: 253:48 [384..2047]: unknown 1664 Only the first entry was expected to be returned but we get 2. This is because: ext4_getfsmap_datadev() first_cluster, last_cluster = 0 ... info->gfi_last = true; ext4_getfsmap_datadev_helper(sb, end_ag, last_cluster + 1, 0, info); fsb = C2B(1) = 16 fslen = 0 ... /* Merge in any relevant extents from the meta_list */ list_for_each_entry_safe(p, tmp, &info->gfi_meta_list, fmr_list) { ... // since fsb = 16, considers all metadata which starts before 16 blockno iter 1: error = ext4_getfsmap_helper(sb, info, p); // p = sb (0,1), nop info->gfi_next_fsblk = 1 iter 2: error = ext4_getfsmap_helper(sb, info, p); // p = gdt (1,2), nop info->gfi_next_fsblk = 2 iter 3: error = ext4_getfsmap_helper(sb, info, p); // p = blk bitmap (2,3), nop info->gfi_next_fsblk = 3 iter 4: error = ext4_getfsmap_helper(sb, info, p); // p = ino bitmap (18,19) if (rec_blk > info->gfi_next_fsblk) { // (18 > 3) // emits an extra entry ** BUG ** } } Fix this by directly calling ext4_getfsmap_datadev() with a dummy record that has fmr_physical set to (end_fsb + 1) instead of last_cluster + 1. By using the block instead of cluster we get the correct behavior. Replacing ext4_getfsmap_datadev_helper() with ext4_getfsmap_helper() is okay since the gfi_lastfree and metadata checks in ext4_getfsmap_datadev_helper() are anyways redundant when we only want to emit the last allocated block of the range, as we have already taken care of emitting metadata and any last free blocks. Cc: [email protected] Reported-by: Disha Goel <[email protected]> Fixes: 4a622e4d477b ("ext4: fix FS_IOC_GETFSMAP handling") Signed-off-by: Ojaswin Mujoo <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Link: https://patch.msgid.link/e7472c8535c9c5ec10f425f495366864ea12c9da.1754377641.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhang Yi <[email protected]> Date: Mon Aug 11 14:45:32 2025 +0800 ext4: fix hole length calculation overflow in non-extent inodes commit 02c7f7219ac0e2277b3379a3a0e9841ef464b6d4 upstream. In a filesystem with a block size larger than 4KB, the hole length calculation for a non-extent inode in ext4_ind_map_blocks() can easily exceed INT_MAX. Then it could return a zero length hole and trigger the following waring and infinite in the iomap infrastructure. ------------[ cut here ]------------ WARNING: CPU: 3 PID: 434101 at fs/iomap/iter.c:34 iomap_iter_done+0x148/0x190 CPU: 3 UID: 0 PID: 434101 Comm: fsstress Not tainted 6.16.0-rc7+ #128 PREEMPT(voluntary) Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : iomap_iter_done+0x148/0x190 lr : iomap_iter+0x174/0x230 sp : ffff8000880af740 x29: ffff8000880af740 x28: ffff0000db8e6840 x27: 0000000000000000 x26: 0000000000000000 x25: ffff8000880af830 x24: 0000004000000000 x23: 0000000000000002 x22: 000001bfdbfa8000 x21: ffffa6a41c002e48 x20: 0000000000000001 x19: ffff8000880af808 x18: 0000000000000000 x17: 0000000000000000 x16: ffffa6a495ee6cd0 x15: 0000000000000000 x14: 00000000000003d4 x13: 00000000fa83b2da x12: 0000b236fc95f18c x11: ffffa6a4978b9c08 x10: 0000000000001da0 x9 : ffffa6a41c1a2a44 x8 : ffff8000880af5c8 x7 : 0000000001000000 x6 : 0000000000000000 x5 : 0000000000000004 x4 : 000001bfdbfa8000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000004004030000 x0 : 0000000000000000 Call trace: iomap_iter_done+0x148/0x190 (P) iomap_iter+0x174/0x230 iomap_fiemap+0x154/0x1d8 ext4_fiemap+0x110/0x140 [ext4] do_vfs_ioctl+0x4b8/0xbc0 __arm64_sys_ioctl+0x8c/0x120 invoke_syscall+0x6c/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x38/0x120 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x1a0 ---[ end trace 0000000000000000 ]--- Cc: [email protected] Fixes: facab4d9711e ("ext4: return hole from ext4_map_blocks()") Reported-by: Qu Wenruo <[email protected]> Closes: https://lore.kernel.org/linux-ext4/[email protected]/ Tested-by: Qu Wenruo <[email protected]> Signed-off-by: Zhang Yi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ojaswin Mujoo <[email protected]> Date: Tue Aug 5 14:00:31 2025 +0530 ext4: fix reserved gdt blocks handling in fsmap commit 3ffbdd1f1165f1b2d6a94d1b1aabef57120deaf7 upstream. In some cases like small FSes with no meta_bg and where the resize doesn't need extra gdt blocks as it can fit in the current one, s_reserved_gdt_blocks is set as 0, which causes fsmap to emit a 0 length entry, which is incorrect. $ mkfs.ext4 -b 65536 -O bigalloc /dev/sda 5G $ mount /dev/sda /mnt/scratch $ xfs_io -c "fsmap -d" /mnt/scartch 0: 253:48 [0..127]: static fs metadata 128 1: 253:48 [128..255]: special 102:1 128 2: 253:48 [256..255]: special 102:2 0 <---- 0 len entry 3: 253:48 [256..383]: special 102:3 128 Fix this by adding a check for this case. Cc: [email protected] Fixes: 0c9ec4beecac ("ext4: support GETFSMAP ioctls") Signed-off-by: Ojaswin Mujoo <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Link: https://patch.msgid.link/08781b796453a5770112aa96ad14c864fbf31935.1754377641.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Baokun Li <[email protected]> Date: Thu Jul 3 15:39:03 2025 +0800 ext4: preserve SB_I_VERSION on remount commit f2326fd14a224e4cccbab89e14c52279ff79b7ec upstream. IMA testing revealed that after an ext4 remount, file accesses triggered full measurements even without modifications, instead of skipping as expected when i_version is unchanged. Debugging showed `SB_I_VERSION` was cleared in reconfigure_super() during remount due to commit 1ff20307393e ("ext4: unconditionally enable the i_version counter") removing the fix from commit 960e0ab63b2e ("ext4: fix i_version handling on remount"). To rectify this, `SB_I_VERSION` is always set for `fc->sb_flags` in ext4_init_fs_context(), instead of `sb->s_flags` in __ext4_fill_super(), ensuring it persists across all mounts. Cc: [email protected] Fixes: 1ff20307393e ("ext4: unconditionally enable the i_version counter") Signed-off-by: Baokun Li <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Liao Yuanhong <[email protected]> Date: Mon Aug 11 20:58:16 2025 +0800 ext4: use kmalloc_array() for array space allocation commit 76dba1fe277f6befd6ef650e1946f626c547387a upstream. Replace kmalloc(size * sizeof) with kmalloc_array() for safer memory allocation and overflow prevention. Cc: [email protected] Signed-off-by: Liao Yuanhong <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chao Yu <[email protected]> Date: Thu Jul 17 21:26:33 2025 +0800 f2fs: fix to avoid out-of-boundary access in dnode page commit 77de19b6867f2740cdcb6c9c7e50d522b47847a4 upstream. As Jiaming Zhang reported: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x1c1/0x2a0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x17e/0x800 mm/kasan/report.c:480 kasan_report+0x147/0x180 mm/kasan/report.c:593 data_blkaddr fs/f2fs/f2fs.h:3053 [inline] f2fs_data_blkaddr fs/f2fs/f2fs.h:3058 [inline] f2fs_get_dnode_of_data+0x1a09/0x1c40 fs/f2fs/node.c:855 f2fs_reserve_block+0x53/0x310 fs/f2fs/data.c:1195 prepare_write_begin fs/f2fs/data.c:3395 [inline] f2fs_write_begin+0xf39/0x2190 fs/f2fs/data.c:3594 generic_perform_write+0x2c7/0x910 mm/filemap.c:4112 f2fs_buffered_write_iter fs/f2fs/file.c:4988 [inline] f2fs_file_write_iter+0x1ec8/0x2410 fs/f2fs/file.c:5216 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x546/0xa90 fs/read_write.c:686 ksys_write+0x149/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x3d0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is in the corrupted image, there is a dnode has the same node id w/ its inode, so during f2fs_get_dnode_of_data(), it tries to access block address in dnode at offset 934, however it parses the dnode as inode node, so that get_dnode_addr() returns 360, then it tries to access page address from 360 + 934 * 4 = 4096 w/ 4 bytes. To fix this issue, let's add sanity check for node id of all direct nodes during f2fs_get_dnode_of_data(). Cc: [email protected] Reported-by: Jiaming Zhang <[email protected]> Closes: https://groups.google.com/g/syzkaller/c/-ZnaaOOfO3M Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Bertschinger <[email protected]> Date: Thu Aug 14 17:54:28 2025 -0600 fhandle: do_handle_open() should get FD with user flags [ Upstream commit b5ca88927e353185b3d9ac4362d33e5aeb25771f ] In f07c7cc4684a, do_handle_open() was switched to use the automatic cleanup method for getting a FD. In that change it was also switched to pass O_CLOEXEC unconditionally to get_unused_fd_flags() instead of passing the user-specified flags. I don't see anything in that commit description that indicates this was intentional, so I am assuming it was an oversight. With this fix, the FD will again be opened with, or without, O_CLOEXEC according to what the user requested. Fixes: f07c7cc4684a ("fhandle: simplify error handling") Signed-off-by: Thomas Bertschinger <[email protected]> Link: https://lore.kernel.org/[email protected] Reviewed-by: Amir Goldstein <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xu Yilun <[email protected]> Date: Wed Aug 6 15:06:05 2025 +0800 fpga: zynq_fpga: Fix the wrong usage of dma_map_sgtable() commit 1ca61060de92a4320d73adfe5dc8d335653907ac upstream. dma_map_sgtable() returns only 0 or the error code. Read sgt->nents to get the number of mapped segments. Fixes: 37e00703228a ("zynq_fpga: use sgtable-based scatterlist wrappers") Reported-by: Pavel Pisa <[email protected]> Closes: https://lore.kernel.org/linux-fpga/[email protected]/ Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Marek Szyprowski <[email protected]> Signed-off-by: Xu Yilun <[email protected]> Tested-by: Pavel Pisa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ye Bin <[email protected]> Date: Mon Aug 11 22:18:30 2025 +0800 fs/buffer: fix use-after-free when call bh_read() helper [ Upstream commit 7375f22495e7cd1c5b3b5af9dcc4f6dffe34ce49 ] There's issue as follows: BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110 Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0 CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x2c/0x390 print_report+0xb4/0x270 kasan_report+0xb8/0xf0 end_buffer_read_sync+0xe3/0x110 end_bio_bh_io_sync+0x56/0x80 blk_update_request+0x30a/0x720 scsi_end_request+0x51/0x2b0 scsi_io_completion+0xe3/0x480 ? scsi_device_unbusy+0x11e/0x160 blk_complete_reqs+0x7b/0x90 handle_softirqs+0xef/0x370 irq_exit_rcu+0xa5/0xd0 sysvec_apic_timer_interrupt+0x6e/0x90 </IRQ> Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQ ntfs_fill_super read_cache_page do_read_cache_folio filemap_read_folio mpage_read_folio do_mpage_readpage ntfs_get_block_vbo bh_read submit_bh wait_on_buffer(bh); blk_complete_reqs scsi_io_completion scsi_end_request blk_update_request end_bio_bh_io_sync end_buffer_read_sync __end_buffer_read_notouch unlock_buffer wait_on_buffer(bh);--> return will return to caller put_bh --> trigger stack-out-of-bounds In the mpage_read_folio() function, the stack variable 'map_bh' is passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and wait_on_buffer() returns to continue processing, the stack variable is likely to be reclaimed. Consequently, during the end_buffer_read_sync() process, calling put_bh() may result in stack overrun. If the bh is not allocated on the stack, it belongs to a folio. Freeing a buffer head which belongs to a folio is done by drop_buffers() which will fail to free buffers which are still locked. So it is safe to call put_bh() before __end_buffer_read_notouch(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ye Bin <[email protected]> Link: https://lore.kernel.org/[email protected] Reviewed-by: Matthew Wilcox (Oracle) <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yuntao Wang <[email protected]> Date: Mon Aug 11 13:24:26 2025 +0800 fs: fix incorrect lflags value in the move_mount syscall [ Upstream commit 593d9e4c3d634c370f226f55453c376bf43b3684 ] The lflags value used to look up from_path was overwritten by the one used to look up to_path. In other words, from_path was looked up with the wrong lflags value. Fix it. Fixes: f9fde814de37 ("fs: support getname_maybe_null() in move_mount()") Signed-off-by: Yuntao Wang <[email protected]> Link: https://lore.kernel.org/[email protected] [Christian Brauner <[email protected]>: massage patch] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Steven Rostedt <[email protected]> Date: Fri Aug 22 18:36:06 2025 -0400 ftrace: Also allocate and copy hash for reading of filter files commit bfb336cf97df7b37b2b2edec0f69773e06d11955 upstream. Currently the reader of set_ftrace_filter and set_ftrace_notrace just adds the pointer to the global tracer hash to its iterator. Unlike the writer that allocates a copy of the hash, the reader keeps the pointer to the filter hashes. This is problematic because this pointer is static across function calls that release the locks that can update the global tracer hashes. This can cause UAF and similar bugs. Allocate and copy the hash for reading the filter files like it is done for the writers. This not only fixes UAF bugs, but also makes the code a bit simpler as it doesn't have to differentiate when to free the iterator's hash between writers and readers. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Linus Torvalds <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: c20489dad156 ("ftrace: Assign iter->hash to filter or notrace hashes on seq read") Closes: https://lore.kernel.org/all/[email protected]/ Closes: https://lore.kernel.org/all/20250822192437.GA458494@ax162/ Reported-by: Tengda Wu <[email protected]> Tested-by: Tengda Wu <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jordan Rhee <[email protected]> Date: Mon Aug 18 14:12:45 2025 -0700 gve: prevent ethtool ops after shutdown [ Upstream commit 75a9a46d67f46d608205888f9b34e315c1786345 ] A crash can occur if an ethtool operation is invoked after shutdown() is called. shutdown() is invoked during system shutdown to stop DMA operations without performing expensive deallocations. It is discouraged to unregister the netdev in this path, so the device may still be visible to userspace and kernel helpers. In gve, shutdown() tears down most internal data structures. If an ethtool operation is dispatched after shutdown(), it will dereference freed or NULL pointers, leading to a kernel panic. While graceful shutdown normally quiesces userspace before invoking the reboot syscall, forced shutdowns (as observed on GCP VMs) can still trigger this path. Fix by calling netif_device_detach() in shutdown(). This marks the device as detached so the ethtool ioctl handler will skip dispatching operations to the driver. Fixes: 974365e51861 ("gve: Implement suspend/resume/shutdown") Signed-off-by: Jordan Rhee <[email protected]> Signed-off-by: Jeroen de Borst <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tim Harvey <[email protected]> Date: Fri Jul 18 13:02:59 2025 -0700 hwmon: (gsc-hwmon) fix fan pwm setpoint show functions commit 9c62e2282900332c8b711d9f9e37af369a8ef71b upstream. The Linux hwmon sysfs API values for pwmX_auto_pointY_pwm represent an integer value between 0 (0%) to 255 (100%) and the pwmX_auto_pointY_temp represent millidegrees Celcius. Commit a6d80df47ee2 ("hwmon: (gsc-hwmon) fix fan pwm temperature scaling") properly addressed the incorrect scaling in the pwm_auto_point_temp_store implementation but erroneously scaled the pwm_auto_point_pwm_show (pwm value) instead of the pwm_auto_point_temp_show (temp value) resulting in: # cat /sys/class/hwmon/hwmon0/pwm1_auto_point6_pwm 25500 # cat /sys/class/hwmon/hwmon0/pwm1_auto_point6_temp 4500 Fix the scaling of these attributes: # cat /sys/class/hwmon/hwmon0/pwm1_auto_point6_pwm 255 # cat /sys/class/hwmon/hwmon0/pwm1_auto_point6_temp 45000 Fixes: a6d80df47ee2 ("hwmon: (gsc-hwmon) fix fan pwm temperature scaling") Cc: [email protected] Signed-off-by: Tim Harvey <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kathiravan Thirumoorthy <[email protected]> Date: Tue May 13 16:38:33 2025 +0530 i2c: qcom-geni: fix I2C frequency table to achieve accurate bus rates commit 85c34532849dae0fdcf880900ac9d7718a73fd1b upstream. Update the I2C frequency table to match the recommended values specified in the I2C hardware programming guide. In the current IPQ5424 configuration where 32MHz is the source clock, the I2C bus frequencies do not meet expectations—for instance, 363KHz is achieved instead of the expected 400KHz. Fixes: 506bb2ab0075 ("i2c: qcom-geni: Support systems with 32MHz serial engine clock") Signed-off-by: Kathiravan Thirumoorthy <[email protected]> Cc: <[email protected]> # v6.13+ Reviewed-by: Mukesh Kumar Savaliya <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sven Eckelmann <[email protected]> Date: Sun Aug 10 20:05:16 2025 +0200 i2c: rtl9300: Add missing count byte for SMBus Block Ops commit 82b350dd8185ce790e61555c436f90b6501af23c upstream. The expected on-wire format of an SMBus Block Write is S Addr Wr [A] Comm [A] Count [A] Data [A] Data [A] ... [A] Data [A] P Everything starting from the Count byte is provided by the I2C subsystem in the array data->block. But the driver was skipping the Count byte (data->block[0]) when sending it to the RTL93xx I2C controller. Only the actual data could be seen on the wire: S Addr Wr [A] Comm [A] Data [A] Data [A] ... [A] Data [A] P This wire format is not SMBus Block Write compatible but matches the format of an I2C Block Write. Simply adding the count byte to the buffer for the I2C controller is enough to fix the transmission. This also affects read because the I2C controller must receive the count byte + $count * data bytes. Fixes: c366be720235 ("i2c: Add driver for the RTL9300 I2C controller") Signed-off-by: Sven Eckelmann <[email protected]> Cc: <[email protected]> # v6.13+ Reviewed-by: Chris Packham <[email protected]> Tested-by: Chris Packham <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Harshal Gohel <[email protected]> Date: Sun Aug 10 20:05:14 2025 +0200 i2c: rtl9300: Fix multi-byte I2C write commit d67b740b9edfa46310355e2b68050f79ebf05a4c upstream. The RTL93xx I2C controller has 4 32 bit registers to store the bytes for the upcoming I2C transmission. The first byte is stored in the least-significant byte of the first register. And the last byte in the most significant byte of the last register. A map of the transferred bytes to their order in the registers is: reg 0: 0x04_03_02_01 reg 1: 0x08_07_06_05 reg 2: 0x0c_0b_0a_09 reg 3: 0x10_0f_0e_0d The i2c_read() function basically demonstrates how the hardware would pick up bytes from this register set. But the i2c_write() function was just pushing bytes one after another to the least significant byte of a register AFTER shifting the last one to the next more significant byte position. If you would then have tried to send a buffer with numbers 1-11 using i2c_write(), you would have ended up with following register content: reg 0: 0x01_02_03_04 reg 1: 0x05_06_07_08 reg 2: 0x00_09_0a_0b reg 3: 0x00_00_00_00 On the wire, you would then have seen: Sr Addr Wr [A] 04 A 03 A 02 A 01 A 08 A 07 A 06 A 05 A 0b A 0a A 09 A P But the correct data transmission was expected to be Sr Addr Wr [A] 01 A 02 A 03 A 04 A 05 A 06 A 07 A 08 A 09 A 0a A 0b A P Because of this multi-byte ordering problem, only single byte i2c_write() operations were executed correctly (on the wire). By shifting the byte directly to the correct end position in the register, it is possible to avoid this incorrect byte ordering and fix multi-byte transmissions. The second initialization (to 0) of vals was also be dropped because this array is initialized to 0 on the stack by using `= {};`. This makes the fix a lot more readable. Fixes: c366be720235 ("i2c: Add driver for the RTL9300 I2C controller") Signed-off-by: Harshal Gohel <[email protected]> Cc: <[email protected]> # v6.13+ Co-developed-by: Sven Eckelmann <[email protected]> Signed-off-by: Sven Eckelmann <[email protected]> Reviewed-by: Chris Packham <[email protected]> Tested-by: Chris Packham <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Guo <[email protected]> Date: Sun Aug 10 20:05:13 2025 +0200 i2c: rtl9300: Fix out-of-bounds bug in rtl9300_i2c_smbus_xfer commit 57f312b955938fc4663f430cb57a71f2414f601b upstream. The data->block[0] variable comes from user. Without proper check, the variable may be very large to cause an out-of-bounds bug. Fix this bug by checking the value of data->block[0] first. 1. commit 39244cc75482 ("i2c: ismt: Fix an out-of-bounds bug in ismt_access()") 2. commit 92fbb6d1296f ("i2c: xgene-slimpro: Fix out-of-bounds bug in xgene_slimpro_i2c_xfer()") Fixes: c366be720235 ("i2c: Add driver for the RTL9300 I2C controller") Signed-off-by: Alex Guo <[email protected]> Cc: <[email protected]> # v6.13+ Reviewed-by: Chris Packham <[email protected]> Tested-by: Chris Packham <[email protected]> Reviewed-by: Wolfram Sang <[email protected]> Signed-off-by: Sven Eckelmann <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sven Eckelmann <[email protected]> Date: Sun Aug 10 20:05:15 2025 +0200 i2c: rtl9300: Increase timeout for transfer polling commit ceee7776c010c5f09d30985c9e5223b363a6172a upstream. The timeout for transfers was only set to 2ms. Because of this relatively low limit, 12-byte read operations to the frontend MCU of a RTL8239 POE PSE chip cluster was consistently resulting in a timeout. The original OpenWrt downstream driver [1] was not using any timeout limit at all. This is also possible by setting the timeout_us parameter of regmap_read_poll_timeout() to 0. But since the driver currently implements the ETIMEDOUT error, it is more sensible to increase the timeout in such a way that communication with the (quite common) Realtek I2C-connected POE management solution is possible. [1] https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/realtek/files-6.12/drivers/i2c/busses/i2c-rtl9300.c;h=c4d973195ef39dc56d6207e665d279745525fcac#l202 Fixes: c366be720235 ("i2c: Add driver for the RTL9300 I2C controller") Signed-off-by: Sven Eckelmann <[email protected]> Cc: <[email protected]> # v6.13+ Reviewed-by: Chris Packham <[email protected]> Tested-by: Chris Packham <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: ValdikSS <[email protected]> Date: Tue Aug 19 15:19:59 2025 -0700 igc: fix disabling L1.2 PCI-E link substate on I226 on init [ Upstream commit 1468c1f97cf32418e34dbb40b784ed9333b9e123 ] Device ID comparison in igc_is_device_id_i226 is performed before the ID is set, resulting in always failing check on init. Before the patch: * L1.2 is not disabled on init * L1.2 is properly disabled after suspend-resume cycle With the patch: * L1.2 is properly disabled both on init and after suspend-resume How to test: Connect to the 1G link with 300+ mbit/s Internet speed, and run the download speed test, such as: curl -o /dev/null http://speedtest.selectel.ru/1GB Without L1.2 disabled, the speed would be no more than ~200 mbit/s. With L1.2 disabled, the speed would reach 1 gbit/s. Note: it's required that the latency between your host and the remote be around 3-5 ms, the test inside LAN (<1 ms latency) won't trigger the issue. Link: https://lore.kernel.org/intel-wired-lan/[email protected] Fixes: 0325143b59c6 ("igc: disable L1.2 PCI-E link substate to avoid performance issue") Signed-off-by: ValdikSS <[email protected]> Reviewed-by: Vitaly Lifshits <[email protected]> Reviewed-by: Paul Menzel <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Lechner <[email protected]> Date: Wed Jul 23 10:29:12 2025 -0500 iio: accel: sca3300: fix uninitialized iio scan data commit 4e5b705cc6147f0b9173c6219079f41416bdd3c0 upstream. Fix potential leak of uninitialized stack data to userspace by ensuring that the `channels` array is zeroed before use. Fixes: edeb67fbbf4b ("iio: accel: sca3300: use IIO_DECLARE_BUFFER_WITH_TS") Signed-off-by: David Lechner <[email protected]> Link: https://patch.msgid.link/20250723-iio-accel-sca3300-fix-uninitialized-iio-scan-data-v1-1-12dbfb3307b7@baylibre.com Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Lechner <[email protected]> Date: Sat Jul 26 11:28:48 2025 -0500 iio: adc: ad7124: fix channel lookup in syscalib functions commit 197e299aae42ffa19028eaea92b2f30dd9fb8445 upstream. Fix possible incorrect channel lookup in the syscalib functions by using the correct channel address instead of the channel number. In the ad7124 driver, the channel field of struct iio_chan_spec is the input pin number of the positive input of the channel. This can be, but is not always the same as the index in the channels array. The correct index in the channels array is stored in the address field (and also scan_index). We use the address field to perform the correct lookup. Fixes: 47036a03a303 ("iio: adc: ad7124: Implement internal calibration at probe time") Signed-off-by: David Lechner <[email protected]> Reviewed-by: Nuno Sá <[email protected]> Link: https://patch.msgid.link/20250726-iio-adc-ad7124-fix-channel-lookup-in-syscalib-v1-1-b9d14bb684af@baylibre.com Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Lechner <[email protected]> Date: Tue Jul 8 20:38:33 2025 -0500 iio: adc: ad7173: fix calibration channel commit 1d9a21ffb43b6fd326ead98f0d0afd6d104b739a upstream. Fix the channel index values passed to ad_sd_calibrate() in ad7173_calibrate_all(). ad7173_calibrate_all() expects these values to be that of the CHANNELx register assigned to the channel, not the datasheet INPUTx number of the channel. The incorrect values were causing register writes to fail for some channels because they set the WEN bit that must always be 0 for register access and set the R/W bit to read instead of write. For other channels, the channel number was just wrong because the CHANNELx registers are generally assigned in reverse order and so almost never match the INPUTx numbers. Fixes: 031bdc8aee01 ("iio: adc: ad7173: add calibration support") Signed-off-by: David Lechner <[email protected]> Reviewed-by: Nuno Sá <[email protected]> Link: https://patch.msgid.link/20250708-iio-adc-ad7313-fix-calibration-channel-v1-1-e6174e2c7cbf@baylibre.com Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Lechner <[email protected]> Date: Thu Jul 3 14:51:17 2025 -0500 iio: adc: ad7173: fix channels index for syscalib_mode commit 0eb8d7b25397330beab8ee62c681975b79f37223 upstream. Fix the index used to look up the channel when accessing the syscalib_mode attribute. The address field is a 0-based index (same as scan_index) that it used to access the channel in the ad7173_channels array throughout the driver. The channels field, on the other hand, may not match the address field depending on the channel configuration specified in the device tree and could result in an out-of-bounds access. Fixes: 031bdc8aee01 ("iio: adc: ad7173: add calibration support") Signed-off-by: David Lechner <[email protected]> Link: https://patch.msgid.link/20250703-iio-adc-ad7173-fix-channels-index-for-syscalib_mode-v1-1-7fdaedb9cac0@baylibre.com Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Lechner <[email protected]> Date: Sun Jul 6 13:53:08 2025 -0500 iio: adc: ad7173: fix num_slots commit 92c247216918fcaa64244248ee38a0f1d342278c upstream. Fix the num_slots value for most chips in the ad7173 driver. The correct value is the number of CHANNELx registers on the chip. In commit 4310e15b3140 ("iio: adc: ad7173: don't make copy of ad_sigma_delta_info struct"), we refactored struct ad_sigma_delta_info to be static const data instead of being dynamically populated during driver probe. However, there was an existing bug in commit 76a1e6a42802 ("iio: adc: ad7173: add AD7173 driver") where num_slots was incorrectly set to the number of CONFIGx registers instead of the number of CHANNELx registers. This bug was partially propagated to the refactored code in that the 16-channel chips were only given 8 slots instead of 16 although we did managed to fix the 8-channel chips and one of the 4-channel chips in that commit. However, we botched two of the 4-channel chips and ended up incorrectly giving them 8 slots during the refactoring. This patch fixes that mistake on the 4-channel chips and also corrects the 16-channel chips to have 16 slots. Fixes: 4310e15b3140 ("iio: adc: ad7173: don't make copy of ad_sigma_delta_info struct") Signed-off-by: David Lechner <[email protected]> Reviewed-by: Nuno Sá <[email protected]> Link: https://patch.msgid.link/20250706-iio-adc-ad7173-fix-num_slots-on-most-chips-v3-1-d1f5453198a7@baylibre.com Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Lechner <[email protected]> Date: Thu Jul 10 15:43:40 2025 -0500 iio: adc: ad7173: fix setting ODR in probe commit 6fa908abd19cc35c205f343b79c67ff38dbc9b76 upstream. Fix the setting of the ODR register value in the probe function for AD7177. The AD7177 chip has a different ODR value after reset than the other chips (0x7 vs. 0x0) and 0 is a reserved value on that chip. The driver already has this information available in odr_start_value and uses it when checking valid values when writing to the sampling_frequency attribute, but failed to set the correct initial value in the probe function. Fixes: 37ae8381ccda ("iio: adc: ad7173: add support for additional models") Signed-off-by: David Lechner <[email protected]> Link: https://patch.msgid.link/20250710-iio-adc-ad7173-fix-setting-odr-in-probe-v1-1-78a100fec998@baylibre.com Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Lechner <[email protected]> Date: Tue Jul 22 14:20:07 2025 -0500 iio: adc: ad7173: prevent scan if too many setups requested commit 1cfb22c277c7274f54babaa5b416dfbc00181e16 upstream. Add a check to ad7173_update_scan_mode() to ensure that we didn't exceed the maximum number of unique channel configurations. In the AD7173 family of chips, there are some chips that have 16 CHANNELx registers but only 8 setups (combination of CONFIGx, FILTERx, GAINx and OFFSETx registers). Since commit 92c247216918 ("iio: adc: ad7173: fix num_slots"), it is possible to have more than 8 channels enabled in a scan at the same time, so it is possible to get a bad configuration when more than 8 channels are using unique configurations. This happens because the algorithm to allocate the setup slots only takes into account which slot has been least recently used and doesn't know about the maximum number of slots available. Since the algorithm to allocate the setup slots is quite complex, it is simpler to check after the fact if the current state is valid or not. So this patch adds a check in ad7173_update_scan_mode() after setting up all of the configurations to make sure that the actual setup still matches the requested setup for each enabled channel. If not, we prevent the scan from being enabled and return an error. The setup comparison in ad7173_setup_equal() is refactored to a separate function since we need to call it in two places now. Fixes: 92c247216918 ("iio: adc: ad7173: fix num_slots") Signed-off-by: David Lechner <[email protected]> Link: https://patch.msgid.link/20250722-iio-adc-ad7173-fix-setup-use-limits-v2-1-8e96bdb72a9c@baylibre.com Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Lechner <[email protected]> Date: Mon Aug 11 13:32:31 2025 -0500 iio: adc: ad7380: fix missing max_conversion_rate_hz on adaq4381-4 commit b04e4551893fb8a06106a175ed7055d41a9279c4 upstream. Add max_conversion_rate_hz to the chip info for "adaq4381-4". Without this, the driver fails to probe because it tries to set the initial sample rate to 0 Hz, which is not valid. Fixes: bbeaec81a03e ("iio: ad7380: add support for SPI offload") Signed-off-by: David Lechner <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://patch.msgid.link/20250811-iio-adc-ad7380-fix-missing-max_conversion_rate_hs-on-ad4381-4-v1-1-ffb728d7a71c@baylibre.com Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Lechner <[email protected]> Date: Thu Jul 3 16:07:44 2025 -0500 iio: adc: ad_sigma_delta: change to buffer predisable commit 66d4374d97f85516b5a22418c5e798aed2606dec upstream. Change the buffer disable callback from postdisable to predisable. This balances the existing posteanble callback. Using postdisable with posteanble can be problematic, for example, if update_scan_mode fails, it would call postdisable without ever having called posteanble, so the drivers using this would be in an unexpected state when postdisable was called. Fixes: af3008485ea0 ("iio:adc: Add common code for ADI Sigma Delta devices") Signed-off-by: David Lechner <[email protected]> Reviewed-by: Nuno Sá <[email protected]> Link: https://patch.msgid.link/20250703-iio-adc-ad_sigma_delta-buffer-predisable-v1-1-f2ab85138f1f@baylibre.com Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matti Vaittinen <[email protected]> Date: Wed Aug 13 12:16:06 2025 +0300 iio: adc: bd79124: Add GPIOLIB dependency commit 8a6ededaad2d2dcaac8e545bffee1073dca9db95 upstream. The bd79124 has ADC inputs which can be muxed to be GPIOs. The driver supports this by registering a GPIO-chip for channels which aren't used as ADC. The Kconfig entry does not handle the dependency to GPIOLIB, which causes errors: ERROR: modpost: "devm_gpiochip_add_data_with_key" [drivers/iio/adc/rohm-bd79124.ko] undefined! ERROR: modpost: "gpiochip_get_data" [drivers/iio/adc/rohm-bd79124.ko] undefined! at linking phase if GPIOLIB is not configured to be used. Fix this by adding dependency to the GPIOLIB. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 3f57a3b9ab74 ("iio: adc: Support ROHM BD79124 ADC") Signed-off-by: Matti Vaittinen <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Link: https://patch.msgid.link/6837249bddf358924e67566293944506206d2d62.1755076369.git.mazziesaccount@gmail.com Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Claudiu Beznea <[email protected]> Date: Sun Aug 10 15:33:27 2025 +0300 iio: adc: rzg2l: Cleanup suspend/resume path commit a3c6eabe3bbd6b0e7124d68b2d3bc32fed17362e upstream. There is no need to manually track the runtime PM status in the driver. The pm_runtime_force_suspend() and pm_runtime_force_resume() functions already call pm_runtime_status_suspended() to check the runtime PM state. Additionally, avoid calling pm_runtime_put_autosuspend() during the suspend/resume path, as this would decrease the usage counter of a potential user that had the ADC open before the suspend/resume cycle. Fixes: 563cf94f9329 ("iio: adc: rzg2l_adc: Add suspend/resume support") Reviewed-by: Ulf Hansson <[email protected]> Reviewed-by: Lad Prabhakar <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Claudiu Beznea <[email protected]> Date: Sun Aug 10 15:33:28 2025 +0300 iio: adc: rzg2l_adc: Set driver data before enabling runtime PM commit c69e13965f26b8058f538ea8bdbd2d7718cf1fbe upstream. When stress-testing the system by repeatedly unbinding and binding the ADC device in a loop, and the ADC is a supplier for another device (e.g., a thermal hardware block that reads temperature through the ADC), it may happen that the ADC device is runtime-resumed immediately after runtime PM is enabled, triggered by its consumer. At this point, since drvdata is not yet set and the driver's runtime PM callbacks rely on it, a crash can occur. To avoid this, set drvdata just after it was allocated. Fixes: 89ee8174e8c8 ("iio: adc: rzg2l_adc: Simplify the runtime PM code") Signed-off-by: Claudiu Beznea <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Lechner <[email protected]> Date: Wed Jul 9 21:20:00 2025 -0500 iio: imu: bno055: fix OOB access of hw_xlate array commit 399b883ec828e436f1a721bf8551b4da8727e65b upstream. Fix a potential out-of-bounds array access of the hw_xlate array in bno055.c. In bno055_get_regmask(), hw_xlate was iterated over the length of the vals array instead of the length of the hw_xlate array. In the case of bno055_gyr_scale, the vals array is larger than the hw_xlate array, so this could result in an out-of-bounds access. In practice, this shouldn't happen though because a match should always be found which breaks out of the for loop before it iterates beyond the end of the hw_xlate array. By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be sure we are iterating over the correct length. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 4aefe1c2bd0c ("iio: imu: add Bosch Sensortec BNO055 core driver") Signed-off-by: David Lechner <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jean-Baptiste Maneyrol <[email protected]> Date: Sun Aug 24 09:01:36 2025 -0400 iio: imu: inv_icm42600: change invalid data error to -EBUSY [ Upstream commit dfdc31e7ccf3ac1d5ec01d5120c71e14745e3dd8 ] Temperature sensor returns the temperature of the mechanical parts of the chip. If both accel and gyro are off, the temperature sensor is also automatically turned off and returns invalid data. In this case, returning -EBUSY error code is better then -EINVAL and indicates userspace that it needs to retry reading temperature in another context. Fixes: bc3eb0207fb5 ("iio: imu: inv_icm42600: add temperature sensor support") Signed-off-by: Jean-Baptiste Maneyrol <[email protected]> Cc: [email protected] Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Sean Nyekjaer <[email protected]> Link: https://patch.msgid.link/20250808-inv-icm42600-change-temperature-error-code-v1-1-986fbf63b77d@tdk.com Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andy Shevchenko <[email protected]> Date: Sun Aug 24 09:01:35 2025 -0400 iio: imu: inv_icm42600: Convert to uXX and sXX integer types [ Upstream commit a4135386fa49c2a170b89296da12c4a3be2089d9 ] The driver code is full of intXX_t and uintXX_t types which is not the pattern we use in the IIO subsystem. Switch the driver to use kernel internal types for that. No functional changes. Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Jean-Baptiste Maneyrol <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]> Stable-dep-of: dfdc31e7ccf3 ("iio: imu: inv_icm42600: change invalid data error to -EBUSY") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Lechner <[email protected]> Date: Sun Aug 24 09:01:34 2025 -0400 iio: imu: inv_icm42600: use = { } instead of memset() [ Upstream commit 352112e2d9aab6a156c2803ae14eb89a9fd93b7d ] Use { } instead of memset() to zero-initialize stack memory to simplify the code. Signed-off-by: David Lechner <[email protected]> Reviewed-by: Nuno Sá <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://patch.msgid.link/20250611-iio-zero-init-stack-with-instead-of-memset-v1-16-ebb2d0a24302@baylibre.com Signed-off-by: Jonathan Cameron <[email protected]> Stable-dep-of: dfdc31e7ccf3 ("iio: imu: inv_icm42600: change invalid data error to -EBUSY") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jonathan Cameron <[email protected]> Date: Sat Aug 2 17:44:21 2025 +0100 iio: light: as73211: Ensure buffer holes are zeroed commit 433b99e922943efdfd62b9a8e3ad1604838181f2 upstream. Given that the buffer is copied to a kfifo that ultimately user space can read, ensure we zero it. Fixes: 403e5586b52e ("iio: light: as73211: New driver") Reviewed-by: Matti Vaittinen <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Salah Triki <[email protected]> Date: Mon Aug 18 10:27:30 2025 +0100 iio: pressure: bmp280: Use IS_ERR() in bmp280_common_probe() commit 43c0f6456f801181a80b73d95def0e0fd134e1cc upstream. `devm_gpiod_get_optional()` may return non-NULL error pointer on failure. Check its return value using `IS_ERR()` and propagate the error if necessary. Fixes: df6e71256c84 ("iio: pressure: bmp280: Explicitly mark GPIO optional") Signed-off-by: Salah Triki <[email protected]> Reviewed-by: David Lechner <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Lechner <[email protected]> Date: Tue Jul 22 15:54:21 2025 -0500 iio: proximity: isl29501: fix buffered read on big-endian systems commit de18e978d0cda23e4c102e18092b63a5b0b3a800 upstream. Fix passing a u32 value as a u16 buffer scan item. This works on little- endian systems, but not on big-endian systems. A new local variable is introduced for getting the register value and the array is changed to a struct to make the data layout more explicit rather than just changing the type and having to recalculate the proper length needed for the timestamp. Fixes: 1c28799257bc ("iio: light: isl29501: Add support for the ISL29501 ToF sensor.") Signed-off-by: David Lechner <[email protected]> Link: https://patch.msgid.link/20250722-iio-use-more-iio_declare_buffer_with_ts-7-v2-1-d3ebeb001ed3@baylibre.com Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Lechner <[email protected]> Date: Mon Jul 21 18:04:04 2025 -0500 iio: temperature: maxim_thermocouple: use DMA-safe buffer for spi_read() commit ae5bc07ec9f73a41734270ef3f800c5c8a7e0ad3 upstream. Replace using stack-allocated buffers with a DMA-safe buffer for use with spi_read(). This allows the driver to be safely used with DMA-enabled SPI controllers. The buffer array is also converted to a struct with a union to make the usage of the memory in the buffer more clear and ensure proper alignment. Fixes: 1f25ca11d84a ("iio: temperature: add support for Maxim thermocouple chips") Signed-off-by: David Lechner <[email protected]> Reviewed-by: Nuno Sá <[email protected]> Link: https://patch.msgid.link/20250721-iio-use-more-iio_declare_buffer_with_ts-3-v2-1-0c68d41ccf6c@baylibre.com Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jens Axboe <[email protected]> Date: Thu Aug 21 13:23:21 2025 -0600 io_uring/futex: ensure io_futex_wait() cleans up properly on failure commit 508c1314b342b78591f51c4b5dadee31a88335df upstream. The io_futex_data is allocated upfront and assigned to the io_kiocb async_data field, but the request isn't marked with REQ_F_ASYNC_DATA at that point. Those two should always go together, as the flag tells io_uring whether the field is valid or not. Additionally, on failure cleanup, the futex handler frees the data but does not clear ->async_data. Clear the data and the flag in the error path as well. Thanks to Trend Micro Zero Day Initiative and particularly ReDress for reporting this. Cc: [email protected] Fixes: 194bb58c6090 ("io_uring: add support for futex wake and wait") Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jan Kara <[email protected]> Date: Wed Jul 30 12:28:41 2025 +0200 iomap: Fix broken data integrity guarantees for O_SYNC writes commit 6b65028e2b51c023a816eabffea88980fdd5564e upstream. Commit d279c80e0bac ("iomap: inline iomap_dio_bio_opflags()") has broken the logic in iomap_dio_bio_iter() in a way that when the device does support FUA (or has no writeback cache) and the direct IO happens to freshly allocated or unwritten extents, we will *not* issue fsync after completing direct IO O_SYNC / O_DSYNC write because the IOMAP_DIO_WRITE_THROUGH flag stays mistakenly set. Fix the problem by clearing IOMAP_DIO_WRITE_THROUGH whenever we do not perform FUA write as it was originally intended. CC: John Garry <[email protected]> CC: Ritesh Harjani (IBM) <[email protected]> Fixes: d279c80e0bac ("iomap: inline iomap_dio_bio_opflags()") CC: [email protected] Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/[email protected] Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Reviewed-by: John Garry <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kees Cook <[email protected]> Date: Mon Aug 4 08:40:27 2025 -0700 iommu/amd: Avoid stack buffer overflow from kernel cmdline [ Upstream commit 8503d0fcb1086a7cfe26df67ca4bd9bd9e99bdec ] While the kernel command line is considered trusted in most environments, avoid writing 1 byte past the end of "acpiid" if the "str" argument is maximum length. Reported-by: Simcha Kosman <[email protected]> Closes: https://lore.kernel.org/all/AS8P193MB2271C4B24BCEDA31830F37AE84A52@AS8P193MB2271.EURP193.PROD.OUTLOOK.COM Fixes: b6b26d86c61c ("iommu/amd: Add a length limitation for the ivrs_acpihid command-line parameter") Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Ankit Soni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nicolin Chen <[email protected]> Date: Thu Jul 31 20:01:27 2025 -0700 iommu/arm-smmu-v3: Fix smmu_domain->nr_ats_masters decrement commit 685ca577b408ffd9c5a4057a2acc0cd3e6978b36 upstream. The arm_smmu_attach_commit() updates master->ats_enabled before calling arm_smmu_remove_master_domain() that is supposed to clean up everything in the old domain, including the old domain's nr_ats_masters. So, it is supposed to use the old ats_enabled state of the device, not an updated state. This isn't a problem if switching between two domains where: - old ats_enabled = false; new ats_enabled = false - old ats_enabled = true; new ats_enabled = true but can fail cases where: - old ats_enabled = false; new ats_enabled = true (old domain should keep the counter but incorrectly decreased it) - old ats_enabled = true; new ats_enabled = false (old domain needed to decrease the counter but incorrectly missed it) Update master->ats_enabled after arm_smmu_remove_master_domain() to fix this. Fixes: 7497f4211f4f ("iommu/arm-smmu-v3: Make changing domains be hitless for ATS") Cc: [email protected] Signed-off-by: Nicolin Chen <[email protected]> Acked-by: Will Deacon <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Pranjal Shrivastava <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: XianLiang Huang <[email protected]> Date: Wed Aug 20 15:22:48 2025 +0800 iommu/riscv: prevent NULL deref in iova_to_phys commit 99d4d1a070870aa08163af8ce0522992b7f35d8c upstream. The riscv_iommu_pte_fetch() function returns either NULL for unmapped/never-mapped iova, or a valid leaf pte pointer that requires no further validation. riscv_iommu_iova_to_phys() failed to handle NULL returns. Prevent null pointer dereference in riscv_iommu_iova_to_phys(), and remove the pte validation. Fixes: 488ffbf18171 ("iommu/riscv: Paging domain support") Cc: Tomasz Jeznach <[email protected]> Signed-off-by: XianLiang Huang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Robin Murphy <[email protected]> Date: Sat Aug 23 09:43:46 2025 -0400 iommu/virtio: Make instance lookup robust [ Upstream commit 72b6f7cd89cea8251979b65528d302f9c0ed37bf ] Much like arm-smmu in commit 7d835134d4e1 ("iommu/arm-smmu: Make instance lookup robust"), virtio-iommu appears to have the same issue where iommu_device_register() makes the IOMMU instance visible to other API callers (including itself) straight away, but internally the instance isn't ready to recognise itself for viommu_probe_device() to work correctly until after viommu_probe() has returned. This matters a lot more now that bus_iommu_probe() has the DT/VIOT knowledge to probe client devices the way that was always intended. Tweak the lookup and initialisation in much the same way as for arm-smmu, to ensure that what we register is functional and ready to go. Cc: [email protected] Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path") Signed-off-by: Robin Murphy <[email protected]> Tested-by: Eric Auger <[email protected]> Link: https://lore.kernel.org/r/308911aaa1f5be32a3a709996c7bd6cf71d30f33.1755190036.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Sat Aug 23 09:43:45 2025 -0400 iommu: Remove ops.pgsize_bitmap from drivers that don't use it [ Upstream commit 8901812485de1356e3757958af40fe0d3a48e986 ] These drivers all set the domain->pgsize_bitmap in their domain_alloc_paging() functions, so the ops value is never used. Delete it. Reviewed-by: Sven Peter <[email protected]> # for Apple DART Reviewed-by: Lu Baolu <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Reviewed-by: Tomasz Jeznach <[email protected]> # for RISC-V Signed-off-by: Jason Gunthorpe <[email protected]> Tested-by: Nicolin Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Stable-dep-of: 72b6f7cd89ce ("iommu/virtio: Make instance lookup robust") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nitin Gote <[email protected]> Date: Fri Jul 18 16:20:51 2025 +0530 iosys-map: Fix undefined behavior in iosys_map_clear() [ Upstream commit 5634c8cb298a7146b4e38873473e280b50e27a2c ] The current iosys_map_clear() implementation reads the potentially uninitialized 'is_iomem' boolean field to decide which union member to clear. This causes undefined behavior when called on uninitialized structures, as 'is_iomem' may contain garbage values like 0xFF. UBSAN detects this as: UBSAN: invalid-load in include/linux/iosys-map.h:267 load of value 255 is not a valid value for type '_Bool' Fix by unconditionally clearing the entire structure with memset(), eliminating the need to read uninitialized data and ensuring all fields are set to known good values. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14639 Fixes: 01fd30da0474 ("dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr") Signed-off-by: Nitin Gote <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dominique Martinet <[email protected]> Date: Wed Aug 13 15:04:55 2025 +0900 iov_iter: iterate_folioq: fix handling of offset >= folio size commit 808471ddb0fa785559c3e7aee59be20a13b46ef5 upstream. It's apparently possible to get an iov advanced all the way up to the end of the current page we're looking at, e.g. (gdb) p *iter $24 = {iter_type = 4 '\004', nofault = false, data_source = false, iov_offset = 4096, {__ubuf_iovec = { iov_base = 0xffff88800f5bc000, iov_len = 655}, {{__iov = 0xffff88800f5bc000, kvec = 0xffff88800f5bc000, bvec = 0xffff88800f5bc000, folioq = 0xffff88800f5bc000, xarray = 0xffff88800f5bc000, ubuf = 0xffff88800f5bc000}, count = 655}}, {nr_segs = 2, folioq_slot = 2 '\002', xarray_start = 2}} Where iov_offset is 4k with 4k-sized folios This should have been fine because we're only in the 2nd slot and there's another one after this, but iterate_folioq should not try to map a folio that skips the whole size, and more importantly part here does not end up zero (because 'PAGE_SIZE - skip % PAGE_SIZE' ends up PAGE_SIZE and not zero..), so skip forward to the "advance to next folio" code Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Dominique Martinet <[email protected]> Fixes: db0aa2e9566f ("mm: Define struct folio_queue and ITER_FOLIOQ to handle a sequence of folios") Reported-by: Maximilian Bosch <[email protected]> Reported-by: Ryan Lahfa <[email protected]> Reported-by: Christian Theune <[email protected]> Reported-by: Arnout Engelen <[email protected]> Link: https://lkml.kernel.org/r/[email protected]/ Acked-by: David Howells <[email protected]> Cc: Al Viro <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: <[email protected]> [6.12+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Mon Aug 18 13:27:24 2025 -0700 ipv6: sr: Fix MAC comparison to be constant-time commit a458b2902115b26a25d67393b12ddd57d1216aaa upstream. To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this. Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support") Cc: [email protected] Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Andrea Mayer <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Minhong He <[email protected]> Date: Fri Aug 15 14:38:45 2025 +0800 ipv6: sr: validate HMAC algorithm ID in seg6_hmac_info_add [ Upstream commit 84967deee9d9870b15bc4c3acb50f1d401807902 ] The seg6_genl_sethmac() directly uses the algorithm ID provided by the userspace without verifying whether it is an HMAC algorithm supported by the system. If an unsupported HMAC algorithm ID is configured, packets using SRv6 HMAC will be dropped during encapsulation or decapsulation. Fixes: 4f4853dc1c9c ("ipv6: sr: implement API to control SR HMAC structure") Signed-off-by: Minhong He <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jedrzej Jagielski <[email protected]> Date: Sun Aug 24 20:30:14 2025 -0700 ixgbe: prevent from unwanted interface name changes [ upstream commit e67a0bc3ed4fd8ee1697cb6d937e2b294ec13b5e ] Users of the ixgbe driver report that after adding devlink support by the commit a0285236ab93 ("ixgbe: add initial devlink support") their configs got broken due to unwanted changes of interface names. It's caused by automatic phys_port_name generation during devlink port initialization flow. To prevent from that set no_phys_port_name flag for ixgbe devlink ports. Reported-by: David Howells <[email protected]> Closes: https://lore.kernel.org/netdev/[email protected]/ Reported-by: David Kaplan <[email protected]> Closes: https://lore.kernel.org/netdev/LV3PR12MB92658474624CCF60220157199470A@LV3PR12MB9265.namprd12.prod.outlook.com/ Fixes: a0285236ab93 ("ixgbe: add initial devlink support") Signed-off-by: Jedrzej Jagielski <[email protected]> Tested-by: Rinitha S <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> Cc: [email protected] # 6.16 Tested-By: Calvin Owens <[email protected]> Signed-off-by: Calvin Owens <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jason Xing <[email protected]> Date: Tue Aug 19 15:19:57 2025 -0700 ixgbe: xsk: resolve the negative overflow of budget in ixgbe_xmit_zc [ Upstream commit 4d4d9ef9dfee877d494e5418f68a1016ef08cad6 ] Resolve the budget negative overflow which leads to returning true in ixgbe_xmit_zc even when the budget of descs are thoroughly consumed. Before this patch, when the budget is decreased to zero and finishes sending the last allowed desc in ixgbe_xmit_zc, it will always turn back and enter into the while() statement to see if it should keep processing packets, but in the meantime it unexpectedly decreases the value again to 'unsigned int (0--)', namely, UINT_MAX. Finally, the ixgbe_xmit_zc returns true, showing 'we complete cleaning the budget'. That also means 'clean_complete = true' in ixgbe_poll. The true theory behind this is if that budget number of descs are consumed, it implies that we might have more descs to be done. So we should return false in ixgbe_xmit_zc to tell napi poll to find another chance to start polling to handle the rest of descs. On the contrary, returning true here means job done and we know we finish all the possible descs this time and we don't intend to start a new napi poll. It is apparently against our expectations. Please also see how ixgbe_clean_tx_irq() handles the problem: it uses do..while() statement to make sure the budget can be decreased to zero at most and the negative overflow never happens. The patch adds 'likely' because we rarely would not hit the loop condition since the standard budget is 256. Fixes: 8221c5eba8c1 ("ixgbe: add AF_XDP zero-copy Tx support") Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Larysa Zaremba <[email protected]> Reviewed-by: Paul Menzel <[email protected]> Reviewed-by: Aleksandr Loktionov <[email protected]> Tested-by: Priya Singh <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baokun Li <[email protected]> Date: Tue Aug 12 14:37:52 2025 +0800 jbd2: prevent softlockup in jbd2_log_do_checkpoint() commit 9d98cf4632258720f18265a058e62fde120c0151 upstream. Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list() periodically release j_list_lock after processing a batch of buffers to avoid long hold times on the j_list_lock. However, since both functions contend for j_list_lock, the combined time spent waiting and processing can be significant. jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when need_resched() is true to avoid softlockups during prolonged operations. But jbd2_log_do_checkpoint() only exits its loop when need_resched() is true, relying on potentially sleeping functions like __flush_batch() or wait_on_buffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup. watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wb_workfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : native_queued_spin_lock_slowpath+0x358/0x418 lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] Call trace: native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2] add_transaction_credits+0x3bc/0x418 [jbd2] start_this_handle+0xf8/0x560 [jbd2] jbd2__journal_start+0x118/0x228 [jbd2] __ext4_journal_start_sb+0x110/0x188 [ext4] ext4_do_writepages+0x3dc/0x740 [ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback+0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20 So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid softlockup. Cc: [email protected] Signed-off-by: Baokun Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jann Horn <[email protected]> Date: Mon Jul 28 22:11:54 2025 +0200 kasan/test: fix protection against compiler elision commit 475356fe2814f2f0b188da8bf0f1fcc579d81272 upstream. The kunit test is using assignments to "static volatile void *kasan_ptr_result" to prevent elision of memory loads, but that's not working: In this variable definition, the "volatile" applies to the "void", not to the pointer. To make "volatile" apply to the pointer as intended, it must follow after the "*". This makes the kasan_memchr test pass again on my system. The kasan_strings test is still failing because all the definitions of load_unaligned_zeropad() are lacking explicit instrumentation hooks and ASAN does not instrument asm() memory operands. Link: https://lkml.kernel.org/r/[email protected] Fixes: 5f1c8108e7ad ("mm:kasan: fix sparse warnings: Should it be static?") Signed-off-by: Jann Horn <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Dmitriy Vyukov <[email protected]> Cc: Jann Horn <[email protected]> Cc: Nihar Chaithanya <[email protected]> Cc: Vincenzo Frascino <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Mon Jul 28 15:47:37 2025 +0200 kbuild: userprogs: use correct linker when mixing clang and GNU ld commit 936599ca514973d44a766b7376c6bbdc96b6a8cc upstream. The userprogs infrastructure does not expect clang being used with GNU ld and in that case uses /usr/bin/ld for linking, not the configured $(LD). This fallback is problematic as it will break when cross-compiling. Mixing clang and GNU ld is used for example when building for SPARC64, as ld.lld is not sufficient; see Documentation/kbuild/llvm.rst. Relax the check around --ld-path so it gets used for all linkers. Fixes: dfc1b168a8c4 ("kbuild: userprogs: use correct lld when linking through clang") Cc: [email protected] Signed-off-by: Thomas Weißschuh <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sebastian Andrzej Siewior <[email protected]> Date: Mon Aug 11 10:27:45 2025 +0200 kcov, usb: Don't disable interrupts in kcov_remote_start_usb_softirq() commit 9528d32873b38281ae105f2f5799e79ae9d086c2 upstream. kcov_remote_start_usb_softirq() the begin of urb's completion callback. HCDs marked HCD_BH will invoke this function from the softirq and in_serving_softirq() will detect this properly. Root-HUB (RH) requests will not be delayed to softirq but complete immediately in IRQ context. This will confuse kcov because in_serving_softirq() will report true if the softirq is served after the hardirq and if the softirq got interrupted by the hardirq in which currently runs. This was addressed by simply disabling interrupts in kcov_remote_start_usb_softirq() which avoided the interruption by the RH while a regular completion callback was invoked. This not only changes the behaviour while kconv is enabled but also breaks PREEMPT_RT because now sleeping locks can no longer be acquired. Revert the previous fix. Address the issue by invoking kcov_remote_start_usb() only if the context is just "serving softirqs" which is identified by checking in_serving_softirq() and in_hardirq() must be false. Fixes: f85d39dd7ed89 ("kcov, usb: disable interrupts in kcov_remote_start_usb_softirq") Cc: stable <[email protected]> Reported-by: Yunseong Kim <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Tested-by: Yunseong Kim <[email protected]> Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pasha Tatashin <[email protected]> Date: Fri Aug 8 20:18:02 2025 +0000 kho: init new_physxa->phys_bits to fix lockdep commit 63b17b653df30e90f95338083cb44c35d64bcae4 upstream. Patch series "Several KHO Hotfixes". Three unrelated fixes for Kexec Handover. This patch (of 3): Lockdep shows the following warning: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. [<ffffffff810133a6>] dump_stack_lvl+0x66/0xa0 [<ffffffff8136012c>] assign_lock_key+0x10c/0x120 [<ffffffff81358bb4>] register_lock_class+0xf4/0x2f0 [<ffffffff813597ff>] __lock_acquire+0x7f/0x2c40 [<ffffffff81360cb0>] ? __pfx_hlock_conflict+0x10/0x10 [<ffffffff811707be>] ? native_flush_tlb_global+0x8e/0xa0 [<ffffffff8117096e>] ? __flush_tlb_all+0x4e/0xa0 [<ffffffff81172fc2>] ? __kernel_map_pages+0x112/0x140 [<ffffffff813ec327>] ? xa_load_or_alloc+0x67/0xe0 [<ffffffff81359556>] lock_acquire+0xe6/0x280 [<ffffffff813ec327>] ? xa_load_or_alloc+0x67/0xe0 [<ffffffff8100b9e0>] _raw_spin_lock+0x30/0x40 [<ffffffff813ec327>] ? xa_load_or_alloc+0x67/0xe0 [<ffffffff813ec327>] xa_load_or_alloc+0x67/0xe0 [<ffffffff813eb4c0>] kho_preserve_folio+0x90/0x100 [<ffffffff813ebb7f>] __kho_finalize+0xcf/0x400 [<ffffffff813ebef4>] kho_finalize+0x34/0x70 This is becase xa has its own lock, that is not initialized in xa_load_or_alloc. Modifiy __kho_preserve_order(), to properly call xa_init(&new_physxa->phys_bits); Link: https://lkml.kernel.org/r/[email protected] Fixes: fc33e4b44b27 ("kexec: enable KHO support for memory preservation") Signed-off-by: Pasha Tatashin <[email protected]> Acked-by: Mike Rapoport (Microsoft) <[email protected]> Cc: Alexander Graf <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Baoquan He <[email protected]> Cc: Changyuan Lyu <[email protected]> Cc: Coiby Xu <[email protected]> Cc: Dave Vasilevsky <[email protected]> Cc: Eric Biggers <[email protected]> Cc: Kees Cook <[email protected]> Cc: Pratyush Yadav <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pasha Tatashin <[email protected]> Date: Fri Aug 8 20:18:03 2025 +0000 kho: mm: don't allow deferred struct page with KHO commit 8b66ed2c3f42cc462e05704af6b94e6a7bad2f5e upstream. KHO uses struct pages for the preserved memory early in boot, however, with deferred struct page initialization, only a small portion of memory has properly initialized struct pages. This problem was detected where vmemmap is poisoned, and illegal flag combinations are detected. Don't allow them to be enabled together, and later we will have to teach KHO to work properly with deferred struct page init kernel feature. Link: https://lkml.kernel.org/r/[email protected] Fixes: 4e1d010e3bda ("kexec: add config option for KHO") Signed-off-by: Pasha Tatashin <[email protected]> Acked-by: Mike Rapoport (Microsoft) <[email protected]> Acked-by: Pratyush Yadav <[email protected]> Cc: Alexander Graf <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Baoquan He <[email protected]> Cc: Changyuan Lyu <[email protected]> Cc: Coiby Xu <[email protected]> Cc: Dave Vasilevsky <[email protected]> Cc: Eric Biggers <[email protected]> Cc: Kees Cook <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pasha Tatashin <[email protected]> Date: Fri Aug 8 20:18:04 2025 +0000 kho: warn if KHO is disabled due to an error commit 44958f2025ed3f29fc3e93bb1f6c16121d7847ad upstream. During boot scratch area is allocated based on command line parameters or auto calculated. However, scratch area may fail to allocate, and in that case KHO is disabled. Currently, no warning is printed that KHO is disabled, which makes it confusing for the end user to figure out why KHO is not available. Add the missing warning message. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Pasha Tatashin <[email protected]> Acked-by: Mike Rapoport (Microsoft) <[email protected]> Acked-by: Pratyush Yadav <[email protected]> Cc: Alexander Graf <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Baoquan He <[email protected]> Cc: Changyuan Lyu <[email protected]> Cc: Coiby Xu <[email protected]> Cc: Dave Vasilevsky <[email protected]> Cc: Eric Biggers <[email protected]> Cc: Kees Cook <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Sun Aug 17 09:48:40 2025 +0900 ksmbd: extend the connection limiting mechanism to support IPv6 commit c0d41112f1a5828c194b59cca953114bc3776ef2 upstream. Update the connection tracking logic to handle both IPv4 and IPv6 address families. Cc: [email protected] Fixes: e6bb91939740 ("ksmbd: limit repeated connections from clients with the same IP") Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ziyan Xu <[email protected]> Date: Sat Aug 16 10:20:05 2025 +0900 ksmbd: fix refcount leak causing resource not released commit 89bb430f621124af39bb31763c4a8b504c9651e2 upstream. When ksmbd_conn_releasing(opinfo->conn) returns true,the refcount was not decremented properly, causing a refcount leak that prevents the count from reaching zero and the memory from being released. Cc: [email protected] Signed-off-by: Ziyan Xu <[email protected]> Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Sun Jul 6 16:10:57 2025 -0700 lib/crypto: arm/poly1305: Fix register corruption in no-SIMD contexts commit 52c3e242f4d0043186b70d65460ba1767f27494a upstream. Restore the SIMD usability check that was removed by commit 773426f4771b ("crypto: arm/poly1305 - Add block-only interface"). This safety check is cheap and is well worth eliminating a footgun. While the Poly1305 functions should not be called when SIMD registers are unusable, if they are anyway, they should just do the right thing instead of corrupting random tasks' registers and/or computing incorrect MACs. Fixing this is also needed for poly1305_kunit to pass. Just use may_use_simd() instead of the original crypto_simd_usable(), since poly1305_kunit won't rely on crypto_simd_disabled_for_test. Fixes: 773426f4771b ("crypto: arm/poly1305 - Add block-only interface") Cc: [email protected] Reviewed-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Sun Jul 6 16:10:58 2025 -0700 lib/crypto: arm64/poly1305: Fix register corruption in no-SIMD contexts commit eec76ea5a7213c48529a46eed1b343e5cee3aaab upstream. Restore the SIMD usability check that was removed by commit a59e5468a921 ("crypto: arm64/poly1305 - Add block-only interface"). This safety check is cheap and is well worth eliminating a footgun. While the Poly1305 functions should not be called when SIMD registers are unusable, if they are anyway, they should just do the right thing instead of corrupting random tasks' registers and/or computing incorrect MACs. Fixing this is also needed for poly1305_kunit to pass. Just use may_use_simd() instead of the original crypto_simd_usable(), since poly1305_kunit won't rely on crypto_simd_disabled_for_test. Fixes: a59e5468a921 ("crypto: arm64/poly1305 - Add block-only interface") Cc: [email protected] Reviewed-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Thu Jun 19 15:55:35 2025 -0700 lib/crypto: mips/chacha: Fix clang build and remove unneeded byteswap commit 22375adaa0d9fbba9646c8e2b099c6e87c97bfae upstream. The MIPS32r2 ChaCha code has never been buildable with the clang assembler. First, clang doesn't support the 'rotl' pseudo-instruction: error: unknown instruction, did you mean: rol, rotr? Second, clang requires that both operands of the 'wsbh' instruction be explicitly given: error: too few operands for instruction To fix this, align the code with the real instruction set by (1) using the real instruction 'rotr' instead of the nonstandard pseudo- instruction 'rotl', and (2) explicitly giving both operands to 'wsbh'. To make removing the use of 'rotl' a bit easier, also remove the unnecessary special-casing for big endian CPUs at .Lchacha_mips_xor_bytes. The tail handling is actually endian-independent since it processes one byte at a time. On big endian CPUs the old code byte-swapped SAVED_X, then iterated through it in reverse order. But the byteswap and reverse iteration canceled out. Tested with chacha20poly1305-selftest in QEMU using "-M malta" with both little endian and big endian mips32r2 kernels. Fixes: 49aa7c00eddf ("crypto: mips/chacha - import 32r2 ChaCha code from Zinc") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christian Brauner <[email protected]> Date: Wed Jun 18 22:53:36 2025 +0200 libfs: massage path_from_stashed() to allow custom stashing behavior [ Upstream commit bda3f1608d993419fa247dc11263fc931ceca58a ] * Add a callback to struct stashed_operations so it's possible to implement custom behavior for pidfs and allow for it to return errors. * Teach stashed_dentry_get() to handle error pointers. Link: https://lore.kernel.org/[email protected] Reviewed-by: Alexander Mikhalitsyn <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Stable-dep-of: 0b2d71a7c826 ("pidfs: Fix memory leak in pidfd_info()") Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Thu Aug 28 16:34:51 2025 +0200 Linux 6.16.4 Link: https://lore.kernel.org/r/[email protected] Tested-by: Takeshi Ogasawara <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Tested-by: Pascal Ernster <[email protected]> Tested-by: Ronald Warsow <[email protected]> Tested-by: Dileep Malepu <[email protected]> Tested-by: Justin M. Forbes <[email protected]> Tested-by: Jon Hunter <[email protected]> Tested-by: Brett A C Sheffield <[email protected]> Tested-By: Achill Gilgenast <[email protected]>= Tested-by: Salvatore Bonaccorso <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Peter Schneider <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Mark Brown <[email protected]> Tested-by: Christian Heusel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bibo Mao <[email protected]> Date: Wed Aug 20 22:51:15 2025 +0800 LoongArch: KVM: Add address alignment check in pch_pic register access commit 538c06e3964a8e94b645686cc58ccc4a06fa6330 upstream. With pch_pic device, its register is based on MMIO address space, different access size 1/2/4/8 is supported. And base address should be naturally aligned with its access size, here add alignment check in its register access emulation function. Cc: [email protected] Signed-off-by: Bibo Mao <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bibo Mao <[email protected]> Date: Wed Aug 20 22:51:15 2025 +0800 LoongArch: KVM: Fix stack protector issue in send_ipi_data() commit 5c68549c81bcca70fc464e305ffeefd9af968287 upstream. Function kvm_io_bus_read() is called in function send_ipi_data(), buffer size of parameter *val should be at least 8 bytes. Since some emulation functions like loongarch_ipi_readl() and kvm_eiointc_read() will write the buffer *val with 8 bytes signed extension regardless parameter len. Otherwise there will be buffer overflow issue when CONFIG_STACKPROTECTOR is enabled. The bug report is shown as follows: Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: send_ipi_data+0x194/0x1a0 [kvm] CPU: 11 UID: 107 PID: 2692 Comm: CPU 0/KVM Not tainted 6.17.0-rc1+ #102 PREEMPT(full) Stack : 9000000005901568 0000000000000000 9000000003af371c 900000013c68c000 900000013c68f850 900000013c68f858 0000000000000000 900000013c68f998 900000013c68f990 900000013c68f990 900000013c68f6c0 fffffffffffdb058 fffffffffffdb0e0 900000013c68f858 911e1d4d39cf0ec2 9000000105657a00 0000000000000001 fffffffffffffffe 0000000000000578 282049464555206e 6f73676e6f6f4c20 0000000000000001 00000000086b4000 0000000000000000 0000000000000000 0000000000000000 9000000005709968 90000000058f9000 900000013c68fa68 900000013c68fab4 90000000029279f0 900000010153f940 900000010001f360 0000000000000000 9000000003af3734 000000004390000c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003af3734>] show_stack+0x5c/0x180 [<9000000003aed168>] dump_stack_lvl+0x6c/0x9c [<9000000003ad0ab0>] vpanic+0x108/0x2c4 [<9000000003ad0ca8>] panic+0x3c/0x40 [<9000000004eb0a1c>] __stack_chk_fail+0x14/0x18 [<ffff8000023473f8>] send_ipi_data+0x190/0x1a0 [kvm] [<ffff8000023313e4>] __kvm_io_bus_write+0xa4/0xe8 [kvm] [<ffff80000233147c>] kvm_io_bus_write+0x54/0x90 [kvm] [<ffff80000233f9f8>] kvm_emu_iocsr+0x180/0x310 [kvm] [<ffff80000233fe08>] kvm_handle_gspr+0x280/0x478 [kvm] [<ffff8000023443e8>] kvm_handle_exit+0xc0/0x130 [kvm] Cc: [email protected] Fixes: daee2f9cae551 ("LoongArch: KVM: Add IPI read and write function") Signed-off-by: Bibo Mao <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bibo Mao <[email protected]> Date: Wed Aug 20 22:51:14 2025 +0800 LoongArch: KVM: Make function kvm_own_lbt() robust commit 4be8cefc132606b4a6e851f37f8e8c40c406c910 upstream. Add the flag KVM_LARCH_LBT checking in function kvm_own_lbt(), so that it can be called safely rather than duplicated enabling again. Cc: [email protected] Signed-off-by: Bibo Mao <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Song Gao <[email protected]> Date: Wed Aug 20 22:51:15 2025 +0800 LoongArch: KVM: Use kvm_get_vcpu_by_id() instead of kvm_get_vcpu() [ Upstream commit 0dfd9ea7bf80fabe11f5b775d762a5cd168cdf41 ] Since using kvm_get_vcpu() may fail to retrieve the vCPU context, kvm_get_vcpu_by_id() should be used instead. Fixes: 8e3054261bc3 ("LoongArch: KVM: Add IPI user mode read and write function") Fixes: 3956a52bc05b ("LoongArch: KVM: Add EIOINTC read and write functions") Reviewed-by: Yanteng Si <[email protected]> Signed-off-by: Song Gao <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bibo Mao <[email protected]> Date: Mon Jul 21 09:26:32 2025 +0800 LoongArch: KVM: Use standard bitops API with eiointc [ Upstream commit d23bd878f6ea9cff93104159356e012a8b2bbfaf ] Standard bitops APIs such test_bit() is used here, rather than manually calculating the offset and mask. Also use non-atomic API __set_bit() and __clear_bit() rather than set_bit() and clear_bit(), since the global spinlock is held already. Signed-off-by: Bibo Mao <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Stable-dep-of: 0dfd9ea7bf80 ("LoongArch: KVM: Use kvm_get_vcpu_by_id() instead of kvm_get_vcpu()") Signed-off-by: Sasha Levin <[email protected]>
Author: Kanglong Wang <[email protected]> Date: Wed Aug 20 22:23:44 2025 +0800 LoongArch: Optimize module load time by optimizing PLT/GOT counting [ Upstream commit 63dbd8fb2af3a89466538599a9acb2d11ef65c06 ] When enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD and CONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock, the relevant logs are as follows: rcu: INFO: rcu_sched self-detected stall on CPU ... Call Trace: [<900000000024f9e4>] show_stack+0x5c/0x180 [<90000000002482f4>] dump_stack_lvl+0x94/0xbc [<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280 [<900000000037ac80>] rcu_sched_clock_irq+0x720/0xf88 [<9000000000396c34>] update_process_times+0xb4/0x150 [<90000000003b2474>] tick_nohz_handler+0xf4/0x250 [<9000000000397e28>] __hrtimer_run_queues+0x1d0/0x428 [<9000000000399b2c>] hrtimer_interrupt+0x214/0x538 [<9000000000253634>] constant_timer_interrupt+0x64/0x80 [<9000000000349938>] __handle_irq_event_percpu+0x78/0x1a0 [<9000000000349a78>] handle_irq_event_percpu+0x18/0x88 [<9000000000354c00>] handle_percpu_irq+0x90/0xf0 [<9000000000348c74>] handle_irq_desc+0x94/0xb8 [<9000000001012b28>] handle_cpu_irq+0x68/0xa0 [<9000000001def8c0>] handle_loongarch_irq+0x30/0x48 [<9000000001def958>] do_vint+0x80/0xd0 [<9000000000268a0c>] kasan_mem_to_shadow.part.0+0x2c/0x2a0 [<90000000006344f4>] __asan_load8+0x4c/0x120 [<900000000025c0d0>] module_frob_arch_sections+0x5c8/0x6b8 [<90000000003895f0>] load_module+0x9e0/0x2958 [<900000000038b770>] __do_sys_init_module+0x208/0x2d0 [<9000000001df0c34>] do_syscall+0x94/0x190 [<900000000024d6fc>] handle_syscall+0xbc/0x158 After analysis, this is because the slow speed of loading the amdgpu module leads to the long time occupation of the cpu and then the soft deadlock. When loading a module, module_frob_arch_sections() tries to figure out the number of PLTs/GOTs that will be needed to handle all the RELAs. It will call the count_max_entries() to find in an out-of-order date which counting algorithm has O(n^2) complexity. To make it faster, we sort the relocation list by info and addend. That way, to check for a duplicate relocation, it just needs to compare with the previous entry. This reduces the complexity of the algorithm to O(n log n), as done in commit d4e0340919fb ("arm64/module: Optimize module load time by optimizing PLT counting"). This gives sinificant reduction in module load time for modules with large number of relocations. After applying this patch, the soft deadlock problem has been solved, and the kernel starts normally without "Call Trace". Using the default configuration to test some modules, the results are as follows: Module Size ip_tables 36K fat 143K radeon 2.5MB amdgpu 16MB Without this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 54 1221/84 amdgpu 1411 4525/1098 With this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 22 1221/84 amdgpu 45 4525/1098 Fixes: fcdfe9d22bed ("LoongArch: Add ELF and module support") Signed-off-by: Kanglong Wang <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tiezhu Yang <[email protected]> Date: Wed Aug 20 22:23:15 2025 +0800 LoongArch: Pass annotate-tablejump option if LTO is enabled [ Upstream commit 5dfea6644d201bfeffaa7e0d79d62309856613b7 ] When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist many objtool warnings "sibling call from callable instruction with modified stack frame". For this special case, the related object file shows that there is no generated relocation section '.rela.discard.tablejump_annotate' for the table jump instruction jirl, thus objtool can not know that what is the actual destination address. It needs to do something on the LLVM side to make sure that there is the relocation section '.rela.discard.tablejump_annotate' if LTO is enabled, but in order to maintain compatibility for the current LLVM compiler, this can be done in the kernel Makefile for now. Ensure it is aware of linker with LTO, '--loongarch-annotate-tablejump' needs to be passed via '-mllvm' to ld.lld. Note that it should also pass the compiler option -mannotate-tablejump rather than only pass '-mllvm --loongarch-annotate-tablejump' to ld.lld if LTO is enabled, otherwise there are no jump info for some table jump instructions. Fixes: e20ab7d454ee ("LoongArch: Enable jump table for objtool") Closes: https://lore.kernel.org/loongarch/20250731175655.GA1455142@ax162/ Reported-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Co-developed-by: WANG Rui <[email protected]> Signed-off-by: WANG Rui <[email protected]> Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Finn Thain <[email protected]> Date: Fri Mar 28 09:39:55 2025 +1100 m68k: Fix lost column on framebuffer debug console commit 210a1ce8ed4391b64a888b3fb4b5611a13f5ccc7 upstream. Move the cursor position rightward after rendering the character, not before. This avoids complications that arise when the recursive console_putc call has to wrap the line and/or scroll the display. This also fixes the linewrap bug that crops off the rightmost column. When the cursor is at the bottom of the display, a linefeed will not move the cursor position further downward. Instead, the display scrolls upward. Avoid the repeated add/subtract sequence by way of a single subtraction at the initialization of console_struct_num_rows. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Finn Thain <[email protected]> Tested-by: Stan Johnson <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/9d4e8c68a456d5f2bc254ac6f87a472d066ebd5e.1743115195.git.fthain@linux-m68k.org Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Simon Richter <[email protected]> Date: Sat Aug 2 11:40:36 2025 +0900 Mark xe driver as BROKEN if kernel page size is not 4kB commit 022906afdf90327bce33d52fb4fb41b6c7d618fb upstream. This driver, for the time being, assumes that the kernel page size is 4kB, so it fails on loong64 and aarch64 with 16kB pages, and ppc64el with 64kB pages. Signed-off-by: Simon Richter <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: [email protected] # v6.8+ Signed-off-by: Thomas Hellström <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 0521a868222ffe636bf202b6e9d29292c1e19c62) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zheng Qixing <[email protected]> Date: Sat Aug 16 08:25:33 2025 +0800 md: add helper rdev_needs_recovery() [ Upstream commit cb0780ad4333040a98e10f014b593ef738a3f31e ] Add a helper for checking if an rdev needs recovery. Signed-off-by: Zheng Qixing <[email protected]> Link: https://lore.kernel.org/linux-raid/[email protected] Signed-off-by: Yu Kuai <[email protected]> Stable-dep-of: b7ee30f0efd1 ("md: fix sync_action incorrect display during resync") Signed-off-by: Sasha Levin <[email protected]>
Author: Zheng Qixing <[email protected]> Date: Sat Aug 16 08:25:34 2025 +0800 md: fix sync_action incorrect display during resync [ Upstream commit b7ee30f0efd12f42735ae233071015389407966c ] During raid resync, if a disk becomes faulty, the operation is briefly interrupted. The MD_RECOVERY_RECOVER flag triggered by the disk failure causes sync_action to incorrectly show "recover" instead of "resync". The same issue affects reshape operations. Reproduction steps: mdadm -Cv /dev/md1 -l1 -n4 -e1.2 /dev/sd{a..d} // -> resync happened mdadm -f /dev/md1 /dev/sda // -> resync interrupted cat sync_action -> recover Add progress checks in md_sync_action() for resync/recover/reshape to ensure the interface correctly reports the actual operation type. Fixes: 4b10a3bc67c1 ("md: ensure resync is prioritized over recovery") Signed-off-by: Zheng Qixing <[email protected]> Link: https://lore.kernel.org/linux-raid/[email protected] Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Li Nan <[email protected]> Date: Tue Jul 22 11:33:40 2025 +0800 md: rename recovery_cp to resync_offset [ Upstream commit 907a99c314a5a695e35acff78ac61f4ec950a6d3 ] 'recovery_cp' was used to represent the progress of sync, but its name contains recovery, which can cause confusion. Replaces 'recovery_cp' with 'resync_offset' for clarity. Signed-off-by: Li Nan <[email protected]> Link: https://lore.kernel.org/linux-raid/[email protected] Signed-off-by: Yu Kuai <[email protected]> Stable-dep-of: b7ee30f0efd1 ("md: fix sync_action incorrect display during resync") Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed May 28 23:22:14 2025 +0300 media: gspca: Add bounds checking to firmware parser commit aef89c0b2417da79cb2062a95476288f9f203ab0 upstream. This sd_init() function reads the firmware. The firmware data holds a series of records and the function reads each record and sends the data to the device. The request_ihex_firmware() function calls ihex_validate_fw() which ensures that the total length of all the records won't read out of bounds of the fw->data[]. However, a potential issue is if there is a single very large record (larger than PAGE_SIZE) and that would result in memory corruption. Generally we trust the firmware, but it's always better to double check. Fixes: 49b61ec9b5af ("[media] gspca: Add new vicam subdriver") Cc: [email protected] Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bingbu Cao <[email protected]> Date: Mon Jun 30 17:04:20 2025 +0800 media: hi556: correct the test pattern configuration commit 020f602b068c9ce18d5056d02c8302199377d98d upstream. Hynix hi556 support 8 test pattern modes: hi556_test_pattern_menu[] = { { "Disabled", "Solid Colour", "100% Colour Bars", "Fade To Grey Colour Bars", "PN9", "Gradient Horizontal", "Gradient Vertical", "Check Board", "Slant Pattern", } The test pattern is set by a 8-bit register according to the specification. +--------+-------------------------------+ | BIT[0] | Solid color | +--------+-------------------------------+ | BIT[1] | Color bar | +--------+-------------------------------+ | BIT[2] | Fade to grey color bar | +--------+-------------------------------+ | BIT[3] | PN9 | +--------+-------------------------------+ | BIT[4] | Gradient horizontal | +--------+-------------------------------+ | BIT[5] | Gradient vertical | +--------+-------------------------------+ | BIT[6] | Check board | +--------+-------------------------------+ | BIT[7] | Slant pattern | +--------+-------------------------------+ Based on function above, current test pattern programming is wrong. This patch fixes it by 'BIT(pattern - 1)'. If pattern is 0, driver will disable the test pattern generation and set the pattern to 0. Fixes: e62138403a84 ("media: hi556: Add support for Hi-556 sensor") Cc: [email protected] Signed-off-by: Bingbu Cao <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Thu Feb 27 15:44:51 2025 +0800 media: imx: fix a potential memory leak in imx_media_csc_scaler_device_init() commit fc5f8aec77704373ee804b5dba0e0e5029c0f180 upstream. Add video_device_release() in label 'err_m2m' to release the memory allocated by video_device_alloc() and prevent potential memory leaks. Remove the reduntant code in label 'err_m2m'. Fixes: a8ef0488cc59 ("media: imx: add csc/scaler mem2mem device") Cc: [email protected] Signed-off-by: Haoxiang Li <[email protected]> Reviewed-by: Dan Carpenter <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sakari Ailus <[email protected]> Date: Tue Jun 3 00:08:51 2025 +0300 media: ipu6: isys: Use correct pads for xlate_streams() commit ff49672a28f3a856717f09d61380e524e243121f upstream. The pad argument to v4l2_subdev_state_xlate_streams() is incorrect, static pad number is used for the source pad even though the pad number is dependent on the stream. Fix it. Fixes: 3a5c59ad926b ("media: ipu6: Rework CSI-2 sub-device streaming control") Cc: [email protected] Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:08:50 2025 +0530 media: iris: Avoid updating frame size to firmware during reconfig commit caf2055487694b6cb52f2ecb161c6c5de660dd72 upstream. During reconfig, the firmware sends the resolution aligned to 8 bytes. If the driver sends the same resolution back to the firmware the resolution will be aligned to 16 bytes not 8. The alignment mismatch would then subsequently cause the firmware to send another redundant sequence change event. Fix this by not setting the resolution property during reconfig. Cc: [email protected] Fixes: 3a19d7b9e08b ("media: iris: implement set properties to firmware during streamon") Reviewed-by: Bryan O'Donoghue <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:08:51 2025 +0530 media: iris: Drop port check for session property response commit f3516f856d1f11d9dff7d72491d474a2bae1cf8e upstream. Currently, port check enforces that session property response must arrive only on the BITSTREAM port. However, firmware can send some responses on other port as well. Remove the strict port validation to correctly handle session property responses from the firmware. Cc: [email protected] Fixes: 3a19d7b9e08b ("media: iris: implement set properties to firmware during streamon") Acked-by: Vikash Garodia <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:08:59 2025 +0530 media: iris: Fix buffer preparation failure during resolution change commit 91c6d55b477e1b66578c268214e915dff9f5ea57 upstream. When the resolution changes, the driver internally updates the width and height, but the client continue to queue buffers with the older resolution until the last flag is received. This results in a mismatch when the buffers are prepared, causing failure due to outdated size. Introduce a check to prevent size validation during buffer preparation if a resolution reconfiguration is in progress, to handle this. Cc: [email protected] Fixes: 17f2a485ca67 ("media: iris: implement vb2 ops for buf_queue and firmware response") Reviewed-by: Vikash Garodia <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:08:55 2025 +0530 media: iris: Fix missing function pointer initialization commit c314a28cdabe45f050fe7bd403ddeaf4b9c960d1 upstream. The function pointers responsible for setting firmware properties were never initialized in the instance capability structure, causing it to remain NULL. As a result, the firmware properties were not being set correctly. Fix this by properly assigning the function pointers from the core capability to the instance capability, ensuring that the properties are correctly applied to the firmware. Cc: [email protected] Fixes: 3a19d7b9e08b ("media: iris: implement set properties to firmware during streamon") Acked-by: Vikash Garodia <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:08:56 2025 +0530 media: iris: Fix NULL pointer dereference commit 0f837559ccdd275c5a059e6ac4d5034b03409f1d upstream. A warning reported by smatch indicated a possible null pointer dereference where one of the arguments to API "iris_hfi_gen2_handle_system_error" could sometimes be null. To fix this, add a check to validate that the argument passed is not null before accessing its members. Cc: [email protected] Fixes: fb583a214337 ("media: iris: introduce host firmware interface with necessary hooks") Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/linux-media/[email protected]/ Acked-by: Vikash Garodia <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:08:57 2025 +0530 media: iris: Fix typo in depth variable commit 58edc8a68de7af45a4c815636595daa530f02c13 upstream. Correct a typo from "dpeth" to "depth". Cc: [email protected] Fixes: 3a19d7b9e08b ("media: iris: implement set properties to firmware during streamon") Acked-by: Vikash Garodia <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:08:52 2025 +0530 media: iris: Prevent HFI queue writes when core is in deinit state commit 2781662dee7bbb9675e5440f5dff4e3991dc5624 upstream. The current check only considers the core error state before allowing writes to the HFI queues. However, the core can also transition to the deinit state due to a system error triggered by the response thread. In such cases, writing to the HFI queues should not be allowed. Fix this by adding a check for the core deinit state, ensuring that writes are rejected when core is not in a valid state. Cc: [email protected] Fixes: fb583a214337 ("media: iris: introduce host firmware interface with necessary hooks") Acked-by: Vikash Garodia <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:08:54 2025 +0530 media: iris: Remove deprecated property setting to firmware commit a693b4a3e7a95c010bedef4c8b3122bd8b0961b7 upstream. HFI_PROPERTY_CONFIG_VDEC_POST_LOOP_DEBLOCKER is deprecated and no longer supported on current firmware, remove setting the same to firmware. Cc: [email protected] Fixes: 79865252acb6 ("media: iris: enable video driver probe of SM8250 SoC") Acked-by: Vikash Garodia <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:08:53 2025 +0530 media: iris: Remove error check for non-zero v4l2 controls commit 03e29ab0e94831fcca2f62c96121fd14263b399b upstream. Remove the check for non-zero number of v4l2 controls as some SOCs might not expose any capability which requires v4l2 control. Cc: [email protected] Fixes: 33be1dde17e3 ("media: iris: implement iris v4l2_ctrl_ops") Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:09:02 2025 +0530 media: iris: Remove unnecessary re-initialization of flush completion commit b7a898184e74a8261c34f1265139ac1799ee4e1c upstream. Currently, The flush completion signal is being re-initialized even though no response is expected during a sequence change. Simplify the code by removing re-initialization of flush completion signal as it is redundant. Cc: [email protected] Fixes: 84e17adae3e3 ("media: iris: add support for dynamic resolution change") Acked-by: Vikash Garodia <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:09:00 2025 +0530 media: iris: Send V4L2_BUF_FLAG_ERROR for capture buffers with 0 filled length commit 7adc11e6abf619d0bb0c05918d5da5b9d4bcb81e upstream. Firmware sends capture buffers with 0 filled length which are not to be displayed and should be dropped by client. To achieve the same, add V4L2_BUF_FLAG_ERROR to such buffers by making sure: - These 0 length buffers are not returned as result of flush. - Its not a buffer with LAST flag enabled which will also have 0 filled length. Cc: [email protected] Fixes: d09100763bed ("media: iris: add support for drain sequence") Acked-by: Vikash Garodia <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:08:47 2025 +0530 media: iris: Skip destroying internal buffer if not dequeued commit 7c452ffda30c0460c568273993a3d3c611486467 upstream. Firmware might hold the DPB buffers for reference in case of sequence change, so skip destroying buffers for which QUEUED flag is not removed. Cc: [email protected] Fixes: 73702f45db81 ("media: iris: allocate, initialize and queue internal buffers") Reviewed-by: Vikash Garodia <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:09:01 2025 +0530 media: iris: Skip flush on first sequence change commit 1e27e9ffce59ac41cde71673d74eb368a533cdb2 upstream. Add a condition to skip the flush operation during the first sequence change event. At this point, the capture queue is not streaming, making the flush unnecessary. Cc: [email protected] Fixes: 84e17adae3e3 ("media: iris: add support for dynamic resolution change") Acked-by: Vikash Garodia <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:08:58 2025 +0530 media: iris: Track flush responses to prevent premature completion commit 9bf58db157139abcd60e425e5718c8e6a917f9dc upstream. Currently, two types of flush commands are queued to the firmware, the first flush queued as part of sequence change, does not wait for a response, while the second flush queued as part of stop, expects a completion response before proceeding further. Due to timing issue, the flush response corresponding to the first command could arrive after the second flush is issued. This casuses the driver to incorrectly assume that the second flush has completed, leading to the premature signaling of flush_completion. To address this, introduce a counter to track the number of pending flush responses and signal flush completion only when all expected responses are received. Cc: [email protected] Fixes: 11712ce70f8e ("media: iris: implement vb2 streaming ops") Reviewed-by: Vikash Garodia <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:08:49 2025 +0530 media: iris: Update CAPTURE format info based on OUTPUT format commit 8aadfd445373b74de4a5cd36736843ae01856636 upstream. Update the width, height and buffer size of CAPTURE based on the resolution set to OUTPUT via VIDIOC_S_FMT. This is required to set the updated capture resolution to firmware when S_FMT is called only for OUTPUT. Cc: [email protected] Fixes: b530b95de22c ("media: iris: implement s_fmt, g_fmt and try_fmt ioctls") Reviewed-by: Bryan O'Donoghue <[email protected]> Acked-by: Vikash Garodia <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dikshita Agarwal <[email protected]> Date: Fri May 9 14:08:48 2025 +0530 media: iris: Verify internal buffer release on close commit d2abb1ff5a3c13321d407ee19865d0d8d834c7c6 upstream. Validate all internal buffers queued to firmware are released back to driver on close. This helps ensure buffer lifecycle correctness and aids in debugging any resporce leaks. Cc: [email protected] Fixes: 73702f45db81 ("media: iris: allocate, initialize and queue internal buffers") Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK Signed-off-by: Dikshita Agarwal <[email protected]> Tested-by: Vikash Garodia <[email protected]> # on sa8775p-ride Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hans de Goede <[email protected]> Date: Sat Jun 21 16:00:52 2025 +0200 media: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() calls commit 0c92c49fc688cfadacc47ae99b06a31237702e9e upstream. Both the ACE and CSI driver are missing a mei_cldev_disable() call in their remove() function. This causes the mei_cl client to stay part of the mei_device->file_list list even though its memory is freed by mei_cl_bus_dev_release() calling kfree(cldev->cl). This leads to a use-after-free when mei_vsc_remove() runs mei_stop() which first removes all mei bus devices calling mei_ace_remove() and mei_csi_remove() followed by mei_cl_bus_dev_release() and then calls mei_cl_all_disconnect() which walks over mei_device->file_list dereferecing the just freed cldev->cl. And mei_vsc_remove() it self is run at shutdown because of the platform_device_unregister(tp->pdev) in vsc_tp_shutdown() When building a kernel with KASAN this leads to the following KASAN report: [ 106.634504] ================================================================== [ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei [ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1 [ 106.634729] [ 106.634767] Tainted: [E]=UNSIGNED_MODULE [ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025 [ 106.634773] Call Trace: [ 106.634777] <TASK> ... [ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) [ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei [ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei [ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei ... [ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei [ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc [ 106.635066] platform_remove (drivers/base/platform.c:1424) Add the missing mei_cldev_disable() calls so that the mei_cl gets removed from mei_device->file_list before it is freed to fix this. Fixes: 78876f71b3e9 ("media: pci: intel: ivsc: Add ACE submodule") Fixes: 29006e196a56 ("media: pci: intel: ivsc: Add CSI submodule") Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mathis Foerst <[email protected]> Date: Thu May 22 16:35:10 2025 +0200 media: mt9m114: Fix deadlock in get_frame_interval/set_frame_interval commit 298d1471cf83d5a2a05970e41822a2403f451086 upstream. Getting / Setting the frame interval using the V4L2 subdev pad ops get_frame_interval/set_frame_interval causes a deadlock, as the subdev state is locked in the [1] but also in the driver itself. In [2] it's described that the caller is responsible to acquire and release the lock in this case. Therefore, acquiring the lock in the driver is wrong. Remove the lock acquisitions/releases from mt9m114_ifp_get_frame_interval() and mt9m114_ifp_set_frame_interval(). [1] drivers/media/v4l2-core/v4l2-subdev.c - line 1129 [2] Documentation/driver-api/media/v4l2-subdev.rst Fixes: 24d756e914fc ("media: i2c: Add driver for onsemi MT9M114 camera sensor") Cc: [email protected] Signed-off-by: Mathis Foerst <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhang Shurong <[email protected]> Date: Sun Jul 6 00:31:09 2025 +0800 media: ov2659: Fix memory leaks in ov2659_probe() commit 76142b137b968d47b35cdd8d1dc924677d319c8b upstream. ov2659_probe() doesn't properly free control handler resources in failure paths, causing memory leaks. Add v4l2_ctrl_handler_free() to prevent these memory leaks and reorder the ctrl_handler assignment for better code flow. Fixes: c4c0283ab3cd ("[media] media: i2c: add support for omnivision's ov2659 sensor") Cc: [email protected] Signed-off-by: Zhang Shurong <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jacopo Mondi <[email protected]> Date: Mon Aug 26 15:30:54 2024 +0200 media: pisp_be: Fix pm_runtime underrun in probe commit e9bb2eacc7222ff8210903eb3b7d56709cc53228 upstream. During the probe() routine, the PiSP BE driver needs to power up the interface in order to identify and initialize the hardware. The driver resumes the interface by calling the pispbe_runtime_resume() function directly, without going through the pm_runtime helpers, but later suspends it by calling pm_runtime_put_autosuspend(). This causes a PM usage count imbalance at probe time, notified by the runtime_pm framework with the below message in the system log: pispbe 1000880000.pisp_be: Runtime PM usage count underflow! Fix this by resuming the interface using the pm runtime helpers instead of calling the resume function directly and use the pm_runtime framework in the probe() error path. While at it, remove manual suspend of the interface in the remove() function. The driver cannot be unloaded if in use, so simply disable runtime pm. To simplify the implementation, make the driver depend on PM as the RPI5 platform where the ISP is integrated in uses the PM framework by default. Fixes: 12187bd5d4f8 ("media: raspberrypi: Add support for PiSP BE") Cc: [email protected] Tested-by: Naushir Patuck <[email protected]> Reviewed-by: Naushir Patuck <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Jacopo Mondi <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Vladimir Zapolskiy <[email protected]> Date: Tue May 13 17:23:45 2025 +0300 media: qcom: camss: cleanup media device allocated resource on error path commit 69080ec3d0daba8a894025476c98ab16b5a505a4 upstream. A call to media_device_init() requires media_device_cleanup() counterpart to complete cleanup and release any allocated resources. This has been done in the driver .remove() right from the beginning, but error paths on .probe() shall also be fixed. Fixes: a1d7c116fcf7 ("media: camms: Add core files") Cc: [email protected] Signed-off-by: Vladimir Zapolskiy <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bryan O'Donoghue <[email protected]> Date: Thu Jun 12 09:07:15 2025 +0100 media: qcom: camss: csiphy-3ph: Fix inadvertent dropping of SDM660/SDM670 phy init commit 868423c834a29981fe3a77d32caf645c6b91a4c5 upstream. The moving of init sequence hook from gen2() to subdev_init() doesn't account for gen1 devices such as SDM660 and SDM670. The switch should find the right offset for gen2 PHYs only, not reject gen1. Remove the default error case to restore gen1 CSIPHY support. Cc: [email protected] Fixes: fbce0ca24c3a ("media: qcom: camss: csiphy-3ph: Move CSIPHY variables to data field inside csiphy struct") Signed-off-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Vladimir Zapolskiy <[email protected]> Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bryan O'Donoghue <[email protected]> Date: Thu Jun 26 02:24:33 2025 +0100 media: qcom: camss: Remove extraneous -supply postfix on supply names commit c26e8dcd9d4e86d788c5bf7a5dd0ea70a95ab067 upstream. The -supply postfix is wrong but wasn't noticed on the CRD devices or indeed the Dell devices, however on Lenovo devices the error comes up. Fixes: 1830cf0f56c3 ("media: qcom: camss: Add x1e80100 specific support") Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> [bod: reworded commit log per Konrad's feedback] Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gui-Dong Han <[email protected]> Date: Fri Jun 6 03:04:59 2025 +0000 media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt() commit 7af160aea26c7dc9e6734d19306128cce156ec40 upstream. In the interrupt handler rain_interrupt(), the buffer full check on rain->buf_len is performed before acquiring rain->buf_lock. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as rain->buf_len is concurrently accessed and modified in the work handler rain_irq_work_handler() under the same lock. Multiple interrupt invocations can race, with each reading buf_len before it becomes full and then proceeding. This can lead to both interrupts attempting to write to the buffer, incrementing buf_len beyond its capacity (DATA_SIZE) and causing a buffer overflow. Fix this bug by moving the spin_lock() to before the buffer full check. This ensures that the check and the subsequent buffer modification are performed atomically, preventing the race condition. An corresponding spin_unlock() is added to the overflow path to correctly release the lock. This possible bug was found by an experimental static analysis tool developed by our team. Fixes: 0f314f6c2e77 ("[media] rainshadow-cec: new RainShadow Tech HDMI CEC driver") Cc: [email protected] Signed-off-by: Gui-Dong Han <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ludwig Disterhof <[email protected]> Date: Mon Apr 28 20:16:50 2025 +0200 media: usbtv: Lock resolution while streaming commit 7e40e0bb778907b2441bff68d73c3eb6b6cd319f upstream. When an program is streaming (ffplay) and another program (qv4l2) changes the TV standard from NTSC to PAL, the kernel crashes due to trying to copy to unmapped memory. Changing from NTSC to PAL increases the resolution in the usbtv struct, but the video plane buffer isn't adjusted, so it overflows. Fixes: 0e0fe3958fdd13d ("[media] usbtv: Add support for PAL video source") Cc: [email protected] Signed-off-by: Ludwig Disterhof <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> [hverkuil: call vb2_is_busy instead of vb2_is_streaming] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sakari Ailus <[email protected]> Date: Thu May 8 18:55:38 2025 +0300 media: v4l2-ctrls: Don't reset handler's error in v4l2_ctrl_handler_free() commit 5a0400aca5fa7c6b8ba456c311a460e733571c88 upstream. It's a common pattern in drivers to free the control handler's resources and then return the handler's error code on drivers' error handling paths. Alas, the v4l2_ctrl_handler_free() function also zeroes the error field, effectively indicating successful return to the caller. There's no apparent need to touch the error field while releasing the control handler's resources and cleaning up stale pointers. Not touching the handler's error field is a more certain way to address this problem than changing all the users, in which case the pattern would be likely to re-emerge in new drivers. Do just that, don't touch the control handler's error field in v4l2_ctrl_handler_free(). Fixes: 0996517cf8ea ("V4L/DVB: v4l2: Add new control handling framework") Cc: [email protected] Signed-off-by: Sakari Ailus <[email protected]> Reviewed-by: Hans Verkuil <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Vedang Nagar <[email protected]> Date: Mon May 19 12:42:21 2025 +0530 media: venus: Add a check for packet size after reading from shared memory commit 49befc830daa743e051a65468c05c2ff9e8580e6 upstream. Add a check to ensure that the packet size does not exceed the number of available words after reading the packet header from shared memory. This ensures that the size provided by the firmware is safe to process and prevent potential out-of-bounds memory access. Fixes: d96d3f30c0f2 ("[media] media: venus: hfi: add Venus HFI files") Cc: [email protected] Signed-off-by: Vedang Nagar <[email protected]> Co-developed-by: Dikshita Agarwal <[email protected]> Signed-off-by: Dikshita Agarwal <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Sat May 31 14:22:00 2025 +0200 media: venus: Fix MSM8998 frequency table commit ee3b94f22638e0f7a1893d95d87b08698b680052 upstream. Fill in the correct data for the production SKU. Fixes: 193b3dac29a4 ("media: venus: add msm8998 support") Cc: [email protected] Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Vikash Garodia <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jorge Ramirez-Ortiz <[email protected]> Date: Thu Jun 19 09:48:30 2025 +0200 media: venus: hfi: explicitly release IRQ during teardown commit 640803003cd903cea73dc6a86bf6963e238e2b3f upstream. Ensure the IRQ is disabled - and all pending handlers completed - before dismantling the interrupt routing and clearing related pointers. This prevents any possibility of the interrupt triggering after the handler context has been invalidated. Fixes: d96d3f30c0f2 ("[media] media: venus: hfi: add Venus HFI files") Cc: [email protected] Signed-off-by: Jorge Ramirez-Ortiz <[email protected]> Reviewed-by: Dikshita Agarwal <[email protected]> Tested-by: Dikshita Agarwal <[email protected]> # RB5 Reviewed-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jorge Ramirez-Ortiz <[email protected]> Date: Fri Jun 6 17:25:22 2025 +0200 media: venus: protect against spurious interrupts during probe commit 3200144a2fa4209dc084a19941b9b203b43580f0 upstream. Make sure the interrupt handler is initialized before the interrupt is registered. If the IRQ is registered before hfi_create(), it's possible that an interrupt fires before the handler setup is complete, leading to a NULL dereference. This error condition has been observed during system boot on Rb3Gen2. Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions") Cc: [email protected] Signed-off-by: Jorge Ramirez-Ortiz <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Vikash Garodia <[email protected]> Reviewed-by: Dikshita Agarwal <[email protected]> Tested-by: Dikshita Agarwal <[email protected]> # RB5 Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ricardo Ribalda <[email protected]> Date: Mon Jun 16 15:29:14 2025 +0000 media: venus: vdec: Clamp param smaller than 1fps and bigger than 240. commit 377dc500d253f0b26732b2cb062e89668aef890a upstream. The driver uses "whole" fps in all its calculations (e.g. in load_per_instance()). Those calculation expect an fps bigger than 1, and not big enough to overflow. Clamp the value if the user provides a param that will result in an invalid fps. Reported-by: Hans Verkuil <[email protected]> Closes: https://lore.kernel.org/linux-media/[email protected]/T/#m91cd962ac942834654f94c92206e2f85ff7d97f0 Fixes: 7472c1c69138 ("[media] media: venus: vdec: add video decoder files") Cc: [email protected] Tested-by: Bryan O'Donoghue <[email protected]> # qrb5615-rb5 Reviewed-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Ricardo Ribalda <[email protected]> [bod: Change "parm" to "param"] Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ricardo Ribalda <[email protected]> Date: Mon Jun 16 15:29:15 2025 +0000 media: venus: venc: Clamp param smaller than 1fps and bigger than 240 commit 417c01b92ec278a1118a05c6ad8a796eaa0c9c52 upstream. The driver uses "whole" fps in all its calculations (e.g. in load_per_instance()). Those calculation expect an fps bigger than 1, and not big enough to overflow. Clamp the param if the user provides a value that will result in an invalid fps. Reported-by: Hans Verkuil <[email protected]> Closes: https://lore.kernel.org/linux-media/[email protected]/T/#m91cd962ac942834654f94c92206e2f85ff7d97f0 Fixes: aaaa93eda64b ("[media] media: venus: venc: add video encoder files") Cc: [email protected] Signed-off-by: Ricardo Ribalda <[email protected]> [bod: Change "parm" to "param"] Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nicolas Dufresne <[email protected]> Date: Mon Feb 17 16:46:54 2025 -0500 media: verisilicon: Fix AV1 decoder clock frequency commit 01350185fe02ae3ea2c12d578e06af0d5186f33e upstream. The desired clock frequency was correctly set to 400MHz in the device tree but was lowered by the driver to 300MHz breaking 4K 60Hz content playback. Fix the issue by removing the driver call to clk_set_rate(), which reduce the amount of board specific code. Fixes: 003afda97c65 ("media: verisilicon: Enable AV1 decoder on rk3588") Cc: [email protected] Reviewed-by: Benjamin Gaignard <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hans Verkuil <[email protected]> Date: Sun Jul 6 12:55:40 2025 +0200 media: vivid: fix wrong pixel_array control size commit 3e43442d4994c9e1e202c98129a87e330f7faaed upstream. The pixel_array control size was calculated incorrectly: the dimensions were swapped (dims[0] should be the height), and the values should be the width or height divided by PIXEL_ARRAY_DIV and rounded up. So don't use roundup, but use DIV_ROUND_UP instead. This bug is harmless in the sense that nothing will break, except that it consumes way too much memory for this control. Fixes: 6bc7643d1b9c ("media: vivid: add pixel_array test control") Cc: <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jiayi Li <[email protected]> Date: Mon Aug 4 09:36:04 2025 +0800 memstick: Fix deadlock by moving removing flag earlier commit 99d7ab8db9d8230b243f5ed20ba0229e54cc0dfa upstream. The existing memstick core patch: commit 62c59a8786e6 ("memstick: Skip allocating card when removing host") sets host->removing in memstick_remove_host(),but still exists a critical time window where memstick_check can run after host->eject is set but before removing is set. In the rtsx_usb_ms driver, the problematic sequence is: rtsx_usb_ms_drv_remove: memstick_check: host->eject = true cancel_work_sync(handle_req) if(!host->removing) ... memstick_alloc_card() memstick_set_rw_addr() memstick_new_req() rtsx_usb_ms_request() if(!host->eject) skip schedule_work wait_for_completion() memstick_remove_host: [blocks indefinitely] host->removing = true flush_workqueue() [block] 1. rtsx_usb_ms_drv_remove sets host->eject = true 2. cancel_work_sync(&host->handle_req) runs 3. memstick_check work may be executed here <-- danger window 4. memstick_remove_host sets removing = 1 During this window (step 3), memstick_check calls memstick_alloc_card, which may indefinitely waiting for mrq_complete completion that will never occur because rtsx_usb_ms_request sees eject=true and skips scheduling work, memstick_set_rw_addr waits forever for completion. This causes a deadlock when memstick_remove_host tries to flush_workqueue, waiting for memstick_check to complete, while memstick_check is blocked waiting for mrq_complete completion. Fix this by setting removing=true at the start of rtsx_usb_ms_drv_remove, before any work cancellation. This ensures memstick_check will see the removing flag immediately and exit early, avoiding the deadlock. Fixes: 62c59a8786e6 ("memstick: Skip allocating card when removing host") Signed-off-by: Jiayi Li <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Torokhov <[email protected]> Date: Mon Jun 30 16:01:06 2025 -0700 mfd: mt6397: Do not use generic name for keypad sub-devices commit 92ab1e41569416c639643cd75eea2379190a65f2 upstream. Do not use "mtk-pmic-keys" when creating sub-device for the keypad to make sure the keypad driver will only bind to the sub-device if it has support for the variant/has matching compatible. Cc: [email protected] Fixes: 6e31bb8d3a63 ("mfd: mt6397: Add initial support for MT6328") Fixes: de58cee8c6b8 ("mfd: mt6397-core: Add MT6357 PMIC support") Fixes: 4a901e305011 ("mfd: mt6397-core: Add resources for PMIC keys for MT6359") Reported-by: Louis-Alexis Eyraud <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> Tested-by: Louis-Alexis Eyraud <[email protected]> # on Link: https://lore.kernel.org/r/r4k3pgd3ew3ypne7ernxuzwgniiyvzosbce4cfajbcu7equblt@yato35tjb3lw Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Parthiban Veerasooran <[email protected]> Date: Mon Aug 18 11:35:13 2025 +0530 microchip: lan865x: fix missing netif_start_queue() call on device open [ Upstream commit 1683fd1b2fa79864d3c7a951d9cea0a9ba1a1923 ] This fixes an issue where the transmit queue is started implicitly only the very first time the device is registered. When the device is taken down and brought back up again (using `ip` or `ifconfig`), the transmit queue is not restarted, causing packet transmission to hang. Adding an explicit call to netif_start_queue() in lan865x_net_open() ensures the transmit queue is properly started every time the device is reopened. Fixes: 5cd2340cb6a3 ("microchip: lan865x: add driver support for Microchip's LAN865X MAC-PHY") Signed-off-by: Parthiban Veerasooran <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Parthiban Veerasooran <[email protected]> Date: Mon Aug 18 11:35:14 2025 +0530 microchip: lan865x: fix missing Timer Increment config for Rev.B0/B1 [ Upstream commit 2cd58fec912acec273cb155911ab8f06ddbb131a ] Fix missing configuration for LAN865x silicon revisions B0 and B1 as per Microchip Application Note AN1760 (Rev F, June 2024). The Timer Increment register was not being set, which is required for accurate timestamping. As per the application note, configure the MAC to set timestamping at the end of the Start of Frame Delimiter (SFD), and set the Timer Increment register to 40 ns (corresponding to a 25 MHz internal clock). Link: https://www.microchip.com/en-us/application-notes/an1760 Fixes: 5cd2340cb6a3 ("microchip: lan865x: add driver support for Microchip's LAN865X MAC-PHY") Signed-off-by: Parthiban Veerasooran <[email protected]> Reviewed-by: Vadim Fedorenko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ido Schimmel <[email protected]> Date: Thu Aug 14 15:06:40 2025 +0200 mlxsw: spectrum: Forward packets with an IPv4 link-local source IP [ Upstream commit f604d3aaf64ff0d90cc875295474d3abf4155629 ] By default, the device does not forward IPv4 packets with a link-local source IP (i.e., 169.254.0.0/16). This behavior does not align with the kernel which does forward them. Fix by instructing the device to forward such packets instead of dropping them. Fixes: ca360db4b825 ("mlxsw: spectrum: Disable DIP_LINK_LOCAL check in hardware pipeline") Reported-by: Zoey Mertes <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Petr Machata <[email protected]> Signed-off-by: Petr Machata <[email protected]> Link: https://patch.msgid.link/6721e6b2c96feb80269e72ce8d0b426e2f32d99c.1755174341.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sang-Heon Jeon <[email protected]> Date: Sun Aug 10 21:42:01 2025 +0900 mm/damon/core: fix commit_ops_filters by using correct nth function commit 63f5dec16760f2cd7d3f9034d18fc1fa0d83652f upstream. damos_commit_ops_filters() incorrectly uses damos_nth_filter() which iterates core_filters. As a result, performing a commit unintentionally corrupts ops_filters. Add damos_nth_ops_filter() which iterates ops_filters. Use this function to fix issues caused by wrong iteration. Link: https://lkml.kernel.org/r/[email protected] Fixes: 3607cc590f18 ("mm/damon/core: support committing ops_filters") # 6.15.x Signed-off-by: Sang-Heon Jeon <[email protected]> Reviewed-by: SeongJae Park <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sang-Heon Jeon <[email protected]> Date: Sat Aug 16 10:51:16 2025 +0900 mm/damon/core: fix damos_commit_filter not changing allow commit b3dee902b6c26b7d8031a4df19753e27dcfcba01 upstream. Current damos_commit_filter() does not persist the `allow' value of the filter. As a result, changing the `allow' value of a filter and committing doesn't change the `allow' value. Add the missing `allow' value update, so committing the filter persistently changes the `allow' value well. Link: https://lkml.kernel.org/r/[email protected] Fixes: fe6d7fdd6249 ("mm/damon/core: add damos_filter->allow field") Signed-off-by: Sang-Heon Jeon <[email protected]> Reviewed-by: SeongJae Park <[email protected]> Cc: <[email protected]> [6.14.x] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: SeongJae Park <[email protected]> Date: Sun Jul 20 11:58:22 2025 -0700 mm/damon/ops-common: ignore migration request to invalid nodes commit 7e6c3130690a01076efdf45aa02ba5d5c16849a0 upstream. damon_migrate_pages() tries migration even if the target node is invalid. If users mistakenly make such invalid requests via DAMOS_MIGRATE_{HOT,COLD} action, the below kernel BUG can happen. [ 7831.883495] BUG: unable to handle page fault for address: 0000000000001f48 [ 7831.884160] #PF: supervisor read access in kernel mode [ 7831.884681] #PF: error_code(0x0000) - not-present page [ 7831.885203] PGD 0 P4D 0 [ 7831.885468] Oops: Oops: 0000 [#1] SMP PTI [ 7831.885852] CPU: 31 UID: 0 PID: 94202 Comm: kdamond.0 Not tainted 6.16.0-rc5-mm-new-damon+ #93 PREEMPT(voluntary) [ 7831.886913] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.el9 04/01/2014 [ 7831.887777] RIP: 0010:__alloc_frozen_pages_noprof (include/linux/mmzone.h:1724 include/linux/mmzone.h:1750 mm/page_alloc.c:4936 mm/page_alloc.c:5137) [...] [ 7831.895953] Call Trace: [ 7831.896195] <TASK> [ 7831.896397] __folio_alloc_noprof (mm/page_alloc.c:5183 mm/page_alloc.c:5192) [ 7831.896787] migrate_pages_batch (mm/migrate.c:1189 mm/migrate.c:1851) [ 7831.897228] ? __pfx_alloc_migration_target (mm/migrate.c:2137) [ 7831.897735] migrate_pages (mm/migrate.c:2078) [ 7831.898141] ? __pfx_alloc_migration_target (mm/migrate.c:2137) [ 7831.898664] damon_migrate_folio_list (mm/damon/ops-common.c:321 mm/damon/ops-common.c:354) [ 7831.899140] damon_migrate_pages (mm/damon/ops-common.c:405) [...] Add a target node validity check in damon_migrate_pages(). The validity check is stolen from that of do_pages_move(), which is being used for the move_pages() system call. Link: https://lkml.kernel.org/r/[email protected] Fixes: b51820ebea65 ("mm/damon/paddr: introduce DAMOS_MIGRATE_COLD action for demotion") [6.11.x] Signed-off-by: SeongJae Park <[email protected]> Reviewed-by: Joshua Hahn <[email protected]> Cc: Honggyu Kim <[email protected]> Cc: Hyeongtak Ji <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Herton R. Krzesinski <[email protected]> Date: Thu Jul 31 18:40:51 2025 -0300 mm/debug_vm_pgtable: clear page table entries at destroy_args() commit dde30854bddfb5d69f30022b53c5955a41088b33 upstream. The mm/debug_vm_pagetable test allocates manually page table entries for the tests it runs, using also its manually allocated mm_struct. That in itself is ok, but when it exits, at destroy_args() it fails to clear those entries with the *_clear functions. The problem is that leaves stale entries. If another process allocates an mm_struct with a pgd at the same address, it may end up running into the stale entry. This is happening in practice on a debug kernel with CONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extra debugging I added (it prints a warning trace if pgtables_bytes goes negative, in addition to the warning at check_mm() function): [ 2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000 [ 2.539366] kmem_cache info [ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508 [ 2.539447] debug_vm_pgtable: [init_args ]: args->mm is 0x000000002267cc9e (...) [ 2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0 [ 2.552816] Modules linked in: [ 2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY [ 2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries [ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90 [ 2.552885] REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debug_vm2.el10.ppc64le+debug) [ 2.552899] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002822 XER: 0000000a [ 2.552954] CFAR: c0000000008f03f0 IRQMASK: 0 [ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001 [ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff [ 2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000 [ 2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb [ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0 [ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000 [ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001 [ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760 [ 2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0 [ 2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0 [ 2.553199] Call Trace: [ 2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable) [ 2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0 [ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570 [ 2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650 [ 2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290 [ 2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0 [ 2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870 [ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150 [ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50 [ 2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0 [ 2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec (...) [ 2.558892] ---[ end trace 0000000000000000 ]--- [ 2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1 [ 2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144 Here the modprobe process ended up with an allocated mm_struct from the mm_struct slab that was used before by the debug_vm_pgtable test. That is not a problem, since the mm_struct is initialized again etc., however, if it ends up using the same pgd table, it bumps into the old stale entry when clearing/freeing the page table entries, so it tries to free an entry already gone (that one which was allocated by the debug_vm_pgtable test), which also explains the negative pgtables_bytes since it's accounting for not allocated entries in the current process. As far as I looked pgd_{alloc,free} etc. does not clear entries, and clearing of the entries is explicitly done in the free_pgtables-> free_pgd_range->free_p4d_range->free_pud_range->free_pmd_range-> free_pte_range path. However, the debug_vm_pgtable test does not call free_pgtables, since it allocates mm_struct and entries manually for its test and eg. not goes through page faults. So it also should clear manually the entries before exit at destroy_args(). This problem was noticed on a reboot X number of times test being done on a powerpc host, with a debug kernel with CONFIG_DEBUG_VM_PGTABLE enabled. Depends on the system, but on a 100 times reboot loop the problem could manifest once or twice, if a process ends up getting the right mm->pgd entry with the stale entries used by mm/debug_vm_pagetable. After using this patch, I couldn't reproduce/experience the problems anymore. I was able to reproduce the problem as well on latest upstream kernel (6.16). I also modified destroy_args() to use mmput() instead of mmdrop(), there is no reason to hold mm_users reference and not release the mm_struct entirely, and in the output above with my debugging prints I already had patched it to use mmput, it did not fix the problem, but helped in the debugging as well. Link: https://lkml.kernel.org/r/[email protected] Fixes: 3c9b84f044a9 ("mm/debug_vm_pgtable: introduce struct pgtable_debug_args") Signed-off-by: Herton R. Krzesinski <[email protected]> Cc: Anshuman Khandual <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Gavin Shan <[email protected]> Cc: Gerald Schaefer <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jinjiang Tu <[email protected]> Date: Fri Aug 15 15:32:09 2025 +0800 mm/memory-failure: fix infinite UCE for VM_PFNMAP pfn commit 2e6053fea379806269c4f7f5e36b523c9c0fb35c upstream. When memory_failure() is called for a already hwpoisoned pfn, kill_accessing_process() will be called to kill current task. However, if the vma of the accessing vaddr is VM_PFNMAP, walk_page_range() will skip the vma in walk_page_test() and return 0. Before commit aaf99ac2ceb7 ("mm/hwpoison: do not send SIGBUS to processes with recovered clean pages"), kill_accessing_process() will return EFAULT. For x86, the current task will be killed in kill_me_maybe(). However, after this commit, kill_accessing_process() simplies return 0, that means UCE is handled properly, but it doesn't actually. In such case, the user task will trigger UCE infinitely. To fix it, add .test_walk callback for hwpoison_walk_ops to scan all vmas. Link: https://lkml.kernel.org/r/[email protected] Fixes: aaf99ac2ceb7 ("mm/hwpoison: do not send SIGBUS to processes with recovered clean pages") Signed-off-by: Jinjiang Tu <[email protected]> Acked-by: David Hildenbrand <[email protected]> Acked-by: Miaohe Lin <[email protected]> Reviewed-by: Jane Chu <[email protected]> Cc: Kefeng Wang <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: Oscar Salvador <[email protected]> Cc: Shuai Xue <[email protected]> Cc: Zi Yan <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Hildenbrand <[email protected]> Date: Mon Aug 18 19:53:58 2025 +0200 mm/mremap: fix WARN with uffd that has remap events disabled commit 772e5b4a5e8360743645b9a466842d16092c4f94 upstream. Registering userfaultd on a VMA that spans at least one PMD and then mremap()'ing that VMA can trigger a WARN when recovering from a failed page table move due to a page table allocation error. The code ends up doing the right thing (recurse, avoiding moving actual page tables), but triggering that WARN is unpleasant: WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_normal_pmd mm/mremap.c:357 [inline] WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_pgt_entry mm/mremap.c:595 [inline] WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_page_tables+0x3832/0x44a0 mm/mremap.c:852 Modules linked in: CPU: 2 UID: 0 PID: 6133 Comm: syz.0.19 Not tainted 6.17.0-rc1-syzkaller-00004-g53e760d89498 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:move_normal_pmd mm/mremap.c:357 [inline] RIP: 0010:move_pgt_entry mm/mremap.c:595 [inline] RIP: 0010:move_page_tables+0x3832/0x44a0 mm/mremap.c:852 Code: ... RSP: 0018:ffffc900037a76d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000032930007 RCX: ffffffff820c6645 RDX: ffff88802e56a440 RSI: ffffffff820c7201 RDI: 0000000000000007 RBP: ffff888037728fc0 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000032930007 R11: 0000000000000000 R12: 0000000000000000 R13: ffffc900037a79a8 R14: 0000000000000001 R15: dffffc0000000000 FS: 000055556316a500(0000) GS:ffff8880d68bc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b30863fff CR3: 0000000050171000 CR4: 0000000000352ef0 Call Trace: <TASK> copy_vma_and_data+0x468/0x790 mm/mremap.c:1215 move_vma+0x548/0x1780 mm/mremap.c:1282 mremap_to+0x1b7/0x450 mm/mremap.c:1406 do_mremap+0xfad/0x1f80 mm/mremap.c:1921 __do_sys_mremap+0x119/0x170 mm/mremap.c:1977 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f00d0b8ebe9 Code: ... RSP: 002b:00007ffe5ea5ee98 EFLAGS: 00000246 ORIG_RAX: 0000000000000019 RAX: ffffffffffffffda RBX: 00007f00d0db5fa0 RCX: 00007f00d0b8ebe9 RDX: 0000000000400000 RSI: 0000000000c00000 RDI: 0000200000000000 RBP: 00007ffe5ea5eef0 R08: 0000200000c00000 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000002 R13: 00007f00d0db5fa0 R14: 00007f00d0db5fa0 R15: 0000000000000005 </TASK> The underlying issue is that we recurse during the original page table move, but not during the recovery move. Fix it by checking for both VMAs and performing the check before the pmd_none() sanity check. Add a new helper where we perform+document that check for the PMD and PUD level. Thanks to Harry for bisecting. Link: https://lkml.kernel.org/r/[email protected] Fixes: 0cef0bb836e3 ("mm: clear uffd-wp PTE/PMD state on mremap()") Signed-off-by: David Hildenbrand <[email protected]> Reported-by: [email protected] Closes: https://lkml.kernel.org/r/[email protected] Tested-by: Harry Yoo <[email protected]> Cc: "Liam R. Howlett" <[email protected]> Cc: Lorenzo Stoakes <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Jann Horn <[email protected]> Cc: Pedro Falcato <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sai Krishna Potthuri <[email protected]> Date: Wed Jul 30 11:35:43 2025 +0530 mmc: sdhci-of-arasan: Ensure CD logic stabilization before power-up commit e251709aaddb3ee1e8ac1ed5e361a608a1cc92de upstream. During SD suspend/resume without a full card rescan (when using non-removable SD cards for rootfs), the SD card initialization may fail after resume. This occurs because, after a host controller reset, the card detect logic may take time to stabilize due to debounce logic. Without waiting for stabilization, the host may attempt powering up the card prematurely, leading to command timeouts during resume flow. Add sdhci_arasan_set_power_and_bus_voltage() to wait for the card detect stable bit before power up the card. Since the stabilization time is not fixed, a maximum timeout of one second is used to ensure sufficient wait time for the card detect signal to stabilize. Signed-off-by: Sai Krishna Potthuri <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Victor Shih <[email protected]> Date: Thu Jul 31 14:57:50 2025 +0800 mmc: sdhci-pci-gli: Add a new function to simplify the code commit dec8b38be4b35cae5f7fa086daf2631e2cfa09c1 upstream. In preparation to fix replay timer timeout, add sdhci_gli_mask_replay_timer_timeout() function to simplify some of the code, allowing it to be re-used. Signed-off-by: Victor Shih <[email protected]> Fixes: 1ae1d2d6e555 ("mmc: sdhci-pci-gli: Add Genesys Logic GL9763E support") Cc: [email protected] Acked-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Victor Shih <[email protected]> Date: Thu Jul 31 14:57:52 2025 +0800 mmc: sdhci-pci-gli: GL9763e: Mask the replay timer timeout of AER commit 340be332e420ed37d15d4169a1b4174e912ad6cb upstream. Due to a flaw in the hardware design, the GL9763e replay timer frequently times out when ASPM is enabled. As a result, the warning messages will often appear in the system log when the system accesses the GL9763e PCI config. Therefore, the replay timer timeout must be masked. Signed-off-by: Victor Shih <[email protected]> Fixes: 1ae1d2d6e555 ("mmc: sdhci-pci-gli: Add Genesys Logic GL9763E support") Cc: [email protected] Acked-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Victor Shih <[email protected]> Date: Thu Jul 31 14:57:51 2025 +0800 mmc: sdhci-pci-gli: GL9763e: Rename the gli_set_gl9763e() for consistency commit 293ed0f5f34e1e9df888456af4b0a021f57b5f54 upstream. In preparation to fix replay timer timeout, rename the gli_set_gl9763e() to gl9763e_hw_setting() for consistency. Signed-off-by: Victor Shih <[email protected]> Fixes: 1ae1d2d6e555 ("mmc: sdhci-pci-gli: Add Genesys Logic GL9763E support") Cc: [email protected] Acked-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Judith Mendez <[email protected]> Date: Wed Aug 20 14:30:47 2025 -0500 mmc: sdhci_am654: Disable HS400 for AM62P SR1.0 and SR1.1 commit d2d7a96b29ea6ab093973a1a37d26126db70c79f upstream. This adds SDHCI_AM654_QUIRK_DISABLE_HS400 quirk which shall be used to disable HS400 support. AM62P SR1.0 and SR1.1 do not support HS400 due to errata i2458 [0] so disable HS400 for these SoC revisions. [0] https://www.ti.com/lit/er/sprz574a/sprz574a.pdf Fixes: 37f28165518f ("arm64: dts: ti: k3-am62p: Add ITAP/OTAP values for MMC") Cc: [email protected] Signed-off-by: Judith Mendez <[email protected]> Reviewed-by: Andrew Davis <[email protected]> Acked-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Mon Aug 4 12:29:55 2025 +0400 most: core: Drop device reference after usage in get_channel() commit b47b493d6387ae437098112936f32be27f73516c upstream. In get_channel(), the reference obtained by bus_find_device_by_name() was dropped via put_device() before accessing the device's driver data Move put_device() after usage to avoid potential issues. Fixes: 2485055394be ("staging: most: core: drop device reference") Cc: stable <[email protected]> Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Geliang Tang <[email protected]> Date: Fri Aug 15 19:28:23 2025 +0200 mptcp: disable add_addr retransmission when timeout is 0 commit f5ce0714623cffd00bf2a83e890d09c609b7f50a upstream. When add_addr_timeout was set to 0, this caused the ADD_ADDR to be retransmitted immediately, which looks like a buggy behaviour. Instead, interpret 0 as "no retransmissions needed". The documentation is updated to explicitly state that setting the timeout to 0 disables retransmission. Fixes: 93f323b9cccc ("mptcp: add a new sysctl add_addr_timeout") Cc: [email protected] Suggested-by: Matthieu Baerts <[email protected]> Signed-off-by: Geliang Tang <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20250815-net-mptcp-misc-fixes-6-17-rc2-v1-5-521fe9957892@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christoph Paasch <[email protected]> Date: Fri Aug 15 19:28:19 2025 +0200 mptcp: drop skb if MPTCP skb extension allocation fails commit ccab044697980c6c01ab51f43f48f13b8a3e5c33 upstream. When skb_ext_add(skb, SKB_EXT_MPTCP) fails in mptcp_incoming_options(), we used to return true, letting the segment proceed through the TCP receive path without a DSS mapping. Such segments can leave inconsistent mapping state and trigger a mid-stream fallback to TCP, which in testing collapsed (by artificially forcing failures in skb_ext_add) throughput to zero. Return false instead so the TCP input path drops the skb (see tcp_data_queue() and step-7 processing). This is the safer choice under memory pressure: it preserves MPTCP correctness and provides backpressure to the sender. Control packets remain unaffected: ACK updates and DATA_FIN handling happen before attempting the extension allocation, and tcp_reset() continues to ignore the return value. With this change, MPTCP continues to work at high throughput if we artificially inject failures into skb_ext_add. Fixes: 6787b7e350d3 ("mptcp: avoid processing packet if a subflow reset") Cc: [email protected] Signed-off-by: Christoph Paasch <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20250815-net-mptcp-misc-fixes-6-17-rc2-v1-1-521fe9957892@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Fri Aug 15 19:28:20 2025 +0200 mptcp: pm: kernel: flush: do not reset ADD_ADDR limit commit 68fc0f4b0d25692940cdc85c68e366cae63e1757 upstream. A flush of the MPTCP endpoints should not affect the MPTCP limits. In other words, 'ip mptcp endpoint flush' should not change 'ip mptcp limits'. But it was the case: the MPTCP_PM_ATTR_RCV_ADD_ADDRS (add_addr_accepted) limit was reset by accident. Removing the reset of this counter during a flush fixes this issue. Fixes: 01cacb00b35c ("mptcp: add netlink-based PM") Cc: [email protected] Reported-by: Thomas Dreibholz <[email protected]> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/579 Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20250815-net-mptcp-misc-fixes-6-17-rc2-v1-2-521fe9957892@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Geliang Tang <[email protected]> Date: Fri Aug 15 19:28:22 2025 +0200 mptcp: remove duplicate sk_reset_timer call commit 5d13349472ac8abcbcb94407969aa0fdc2e1f1be upstream. sk_reset_timer() was called twice in mptcp_pm_alloc_anno_list. Simplify the code by using a 'goto' statement to eliminate the duplication. Note that this is not a fix, but it will help backporting the following patch. The same "Fixes" tag has been added for this reason. Fixes: 93f323b9cccc ("mptcp: add a new sysctl add_addr_timeout") Cc: [email protected] Signed-off-by: Geliang Tang <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20250815-net-mptcp-misc-fixes-6-17-rc2-v1-4-521fe9957892@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Mon Jul 7 09:39:37 2025 +0200 mtd: rawnand: fsmc: Add missing check after DMA map commit 6c4dab38431fee3d39a841d66ba6f2890b31b005 upstream. The DMA map functions can fail and should be tested for errors. Fixes: 4774fb0a48aa ("mtd: nand/fsmc: Add DMA support") Cc: [email protected] Signed-off-by: Thomas Fourier <[email protected]> Rule: add Link: https://lore.kernel.org/stable/20250702065806.20983-2-fourier.thomas%40gmail.com Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Wed Jul 2 10:01:06 2025 +0200 mtd: rawnand: renesas: Add missing check after DMA map commit 79e441ee47949376e3bc20f085cf017b70523d0f upstream. The DMA map functions can fail and should be tested for errors. Fixes: d8701fe890ec ("mtd: rawnand: renesas: Add new NAND controller driver") Cc: [email protected] Signed-off-by: Thomas Fourier <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michael Walle <[email protected]> Date: Tue Jul 1 16:04:26 2025 +0200 mtd: spi-nor: Fix spi_nor_try_unlock_all() commit 2e3a7476ec3989e77270b9481e76e137824b17c0 upstream. Commit ff67592cbdfc ("mtd: spi-nor: Introduce spi_nor_set_mtd_info()") moved all initialization of the mtd fields at the end of spi_nor_scan(). Normally, the mtd info is only needed for the mtd ops on the device, with one exception: spi_nor_try_unlock_all(), which will also make use of the mtd->size parameter. With that commit, the size will always be zero because it is not initialized. Fix that by not using the size of the mtd_info struct, but use the size from struct spi_nor_flash_parameter. Fixes: ff67592cbdfc ("mtd: spi-nor: Introduce spi_nor_set_mtd_info()") Cc: [email protected] Reported-by: Jean-Marc Ranger <[email protected]> Closes: https://lore.kernel.org/all/DM6PR06MB561177323DC5207E34AF2A06C547A@DM6PR06MB5611.namprd06.prod.outlook.com/ Tested-by: Jean-Marc Ranger <[email protected]> Signed-off-by: Michael Walle <[email protected]> Reviewed-by: Pratyush Yadav <[email protected]> Signed-off-by: Pratyush Yadav <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gabor Juhos <[email protected]> Date: Tue Jul 8 15:11:00 2025 +0200 mtd: spinand: propagate spinand_wait() errors from spinand_write_page() commit 091d9e35b85b0f8f7e1c73535299f91364a5c73a upstream. Since commit 3d1f08b032dc ("mtd: spinand: Use the external ECC engine logic") the spinand_write_page() function ignores the errors returned by spinand_wait(). Change the code to propagate those up to the stack as it was done before the offending change. Cc: [email protected] Fixes: 3d1f08b032dc ("mtd: spinand: Use the external ECC engine logic") Signed-off-by: Gabor Juhos <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jakub Acs <[email protected]> Date: Tue Aug 19 08:28:42 2025 +0000 net, hsr: reject HSR frame if skb can't hold tag commit 7af76e9d18a9fd6f8611b3313c86c190f9b6a5a7 upstream. Receiving HSR frame with insufficient space to hold HSR tag in the skb can result in a crash (kernel BUG): [ 45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1 [ 45.392559] ------------[ cut here ]------------ [ 45.392912] kernel BUG at net/core/skbuff.c:211! [ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef) [ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 45.395273] RIP: 0010:skb_panic+0x15b/0x1d0 <snip registers, remove unreliable trace> [ 45.402911] Call Trace: [ 45.403105] <IRQ> [ 45.404470] skb_push+0xcd/0xf0 [ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0 [ 45.406513] br_forward_finish+0x128/0x260 [ 45.408483] __br_forward+0x42d/0x590 [ 45.409464] maybe_deliver+0x2eb/0x420 [ 45.409763] br_flood+0x174/0x4a0 [ 45.410030] br_handle_frame_finish+0xc7c/0x1bc0 [ 45.411618] br_handle_frame+0xac3/0x1230 [ 45.413674] __netif_receive_skb_core.constprop.0+0x808/0x3df0 [ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0 [ 45.424478] __netif_receive_skb+0x22/0x170 [ 45.424806] process_backlog+0x242/0x6d0 [ 45.425116] __napi_poll+0xbb/0x630 [ 45.425394] net_rx_action+0x4d1/0xcc0 [ 45.427613] handle_softirqs+0x1a4/0x580 [ 45.427926] do_softirq+0x74/0x90 [ 45.428196] </IRQ> This issue was found by syzkaller. The panic happens in br_dev_queue_push_xmit() once it receives a corrupted skb with ETH header already pushed in linear data. When it attempts the skb_push() call, there's not enough headroom and skb_push() panics. The corrupted skb is put on the queue by HSR layer, which makes a sequence of unintended transformations when it receives a specific corrupted HSR frame (with incomplete TAG). Fix it by dropping and consuming frames that are not long enough to contain both ethernet and hsr headers. Alternative fix would be to check for enough headroom before skb_push() in br_dev_queue_push_xmit(). In the reproducer, this is injected via AF_PACKET, but I don't easily see why it couldn't be sent over the wire from adjacent network. Further Details: In the reproducer, the following network interface chain is set up: ┌────────────────┐ ┌────────────────┐ │ veth0_to_hsr ├───┤ hsr_slave0 ┼───┐ └────────────────┘ └────────────────┘ │ │ ┌──────┐ ├─┤ hsr0 ├───┐ │ └──────┘ │ ┌────────────────┐ ┌────────────────┐ │ │┌────────┐ │ veth1_to_hsr ┼───┤ hsr_slave1 ├───┘ └┤ │ └────────────────┘ └────────────────┘ ┌┼ bridge │ ││ │ │└────────┘ │ ┌───────┐ │ │ ... ├──────┘ └───────┘ To trigger the events leading up to crash, reproducer sends a corrupted HSR frame with incomplete TAG, via AF_PACKET socket on 'veth0_to_hsr'. The first HSR-layer function to process this frame is hsr_handle_frame(). It and then checks if the protocol is ETH_P_PRP or ETH_P_HSR. If it is, it calls skb_set_network_header(skb, ETH_HLEN + HSR_HLEN), without checking that the skb is long enough. For the crashing frame it is not, and hence the skb->network_header and skb->mac_len fields are set incorrectly, pointing after the end of the linear buffer. I will call this a BUG#1 and it is what is addressed by this patch. In the crashing scenario before the fix, the skb continues to go down the hsr path as follows. hsr_handle_frame() then calls this sequence hsr_forward_skb() fill_frame_info() hsr->proto_ops->fill_frame_info() hsr_fill_frame_info() hsr_fill_frame_info() contains a check that intends to check whether the skb actually contains the HSR header. But the check relies on the skb->mac_len field which was erroneously setup due to BUG#1, so the check passes and the execution continues back in the hsr_forward_skb(): hsr_forward_skb() hsr_forward_do() hsr->proto_ops->get_untagged_frame() hsr_get_untagged_frame() create_stripped_skb_hsr() In create_stripped_skb_hsr(), a copy of the skb is created and is further corrupted by operation that attempts to strip the HSR tag in a call to __pskb_copy(). The skb enters create_stripped_skb_hsr() with ethernet header pushed in linear buffer. The skb_pull(skb_in, HSR_HLEN) thus pulls 6 bytes of ethernet header into the headroom, creating skb_in with a headroom of size 8. The subsequent __pskb_copy() then creates an skb with headroom of just 2 and skb->len of just 12, this is how it looks after the copy: gdb) p skb->len $10 = 12 (gdb) p skb->data $11 = (unsigned char *) 0xffff888041e45382 "\252\252\252\252\252!\210\373", (gdb) p skb->head $12 = (unsigned char *) 0xffff888041e45380 "" It seems create_stripped_skb_hsr() assumes that ETH header is pulled in the headroom when it's entered, because it just pulls HSR header on top. But that is not the case in our code-path and we end up with the corrupted skb instead. I will call this BUG#2 *I got confused here because it seems that under no conditions can create_stripped_skb_hsr() work well, the assumption it makes is not true during the processing of hsr frames - since the skb_push() in hsr_handle_frame to skb_pull in hsr_deliver_master(). I wonder whether I missed something here.* Next, the execution arrives in hsr_deliver_master(). It calls skb_pull(ETH_HLEN), which just returns NULL - the SKB does not have enough space for the pull (as it only has 12 bytes in total at this point). *The skb_pull() here further suggests that ethernet header is meant to be pushed through the whole hsr processing and create_stripped_skb_hsr() should pull it before doing the HSR header pull.* hsr_deliver_master() then puts the corrupted skb on the queue, it is then picked up from there by bridge frame handling layer and finally lands in br_dev_queue_push_xmit where it panics. Cc: [email protected] Fixes: 48b491a5cc74 ("net: hsr: fix mac_len checks") Reported-by: [email protected] Signed-off-by: Jakub Acs <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Oren Sidi <[email protected]> Date: Thu Jul 17 09:48:14 2025 +0300 net/mlx5: Add IFC bits and enums for buf_ownership [ Upstream commit 6f09ee0b583cad4f2b6a82842c26235bee3d5c2e ] Extend structure layouts and defines buf_ownership. buf_ownership indicates whether the buffer is managed by SW or FW. Signed-off-by: Oren Sidi <[email protected]> Reviewed-by: Alex Lazar <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Stable-dep-of: 451d2849ea66 ("net/mlx5e: Query FW for buffer ownership") Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Jurgens <[email protected]> Date: Wed Aug 20 16:32:02 2025 +0300 net/mlx5: Base ECVF devlink port attrs from 0 [ Upstream commit bc17455bc843b2f4b206e0bb8139013eb3d3c08b ] Adjust the vport number by the base ECVF vport number so the port attributes start at 0. Previously the port attributes would start 1 after the maximum number of host VFs. Fixes: dc13180824b7 ("net/mlx5: Enable devlink port for embedded cpu VF vports") Signed-off-by: Daniel Jurgens <[email protected]> Reviewed-by: Parav Pandit <[email protected]> Reviewed-by: Saeed Mahameed <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Signed-off-by: Mark Bloch <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vlad Dogaru <[email protected]> Date: Sun Aug 17 23:23:23 2025 +0300 net/mlx5: CT: Use the correct counter offset [ Upstream commit d2d6f950cb43be6845a41cac5956cb2a10e657e5 ] Specifying the counter action is not enough, as it is used by multiple counters that were allocated in a bulk. By omitting the offset, rules will be associated with a different counter from the same bulk. Subsequently, the CT subsystem checks the correct counter, assumes that no traffic has triggered the rule, and ages out the rule. The end result is intermittent offloading of long lived connections, as rules are aged out then promptly re-added. Fix this by specifying the correct offset along with the counter rule. Fixes: 34eea5b12a10 ("net/mlx5e: CT: Add initial support for Hardware Steering") Signed-off-by: Vlad Dogaru <[email protected]> Reviewed-by: Yevgeny Kliteynik <[email protected]> Signed-off-by: Mark Bloch <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yevgeny Kliteynik <[email protected]> Date: Sun Aug 17 23:23:17 2025 +0300 net/mlx5: HWS, fix bad parameter in CQ creation [ Upstream commit 2462c1b9217246a889ec318b3894d84e4dd709c6 ] 'cqe_sz' valid value should be 0 for 64-byte CQE. Fixes: 2ca62599aa0b ("net/mlx5: HWS, added send engine and context handling") Signed-off-by: Yevgeny Kliteynik <[email protected]> Reviewed-by: Vlad Dogaru <[email protected]> Signed-off-by: Mark Bloch <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yevgeny Kliteynik <[email protected]> Date: Sun Aug 17 23:23:19 2025 +0300 net/mlx5: HWS, fix complex rules rehash error flow [ Upstream commit 4a842b1bf18a32ee0c25dd6dd98728b786a76fe4 ] Moving rules from matcher to matcher should not fail. However, if it does fail due to various reasons, the error flow should allow the kernel to continue functioning (albeit with broken steering rules) instead of going into series of soft lock-ups or some other problematic behaviour. Similar to the simple rules, complex rules rehash logic suffers from the same problems. This patch fixes the error flow for moving complex rules: - If new rule creation fails before it was even enqeued, do not poll for completion - If TIMEOUT happened while moving the rule, no point trying to poll for completions for other rules. Something is broken, completion won't come, just abort the rehash sequence. - If some other completion with error received, don't give up. Continue handling rest of the rules to minimize the damage. - Make sure that the first error code that was received will be actually returned to the caller instead of replacing it with the generic error code. All the aforementioned issues stem from the same bad error flow, so no point fixing them one by one and leaving partially broken code - fixing them in one patch. Fixes: 17e0accac577 ("net/mlx5: HWS, support complex matchers") Signed-off-by: Yevgeny Kliteynik <[email protected]> Reviewed-by: Vlad Dogaru <[email protected]> Signed-off-by: Mark Bloch <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Vesker <[email protected]> Date: Sun Aug 17 23:23:22 2025 +0300 net/mlx5: HWS, Fix table creation UID [ Upstream commit 8a51507320ebddaab32610199774f69cd7d53e78 ] During table creation, caller passes a UID using ft_attr. The UID value was ignored, which leads to problems when the caller sets the UID to a non-zero value, such as SHARED_RESOURCE_UID (0xffff) - the internal FT objects will be created with UID=0. Fixes: 0869701cba3d ("net/mlx5: HWS, added FW commands handling") Signed-off-by: Alex Vesker <[email protected]> Reviewed-by: Yevgeny Kliteynik <[email protected]> Signed-off-by: Mark Bloch <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Armen Ratner <[email protected]> Date: Wed Aug 20 16:32:09 2025 +0300 net/mlx5e: Preserve shared buffer capacity during headroom updates [ Upstream commit 8b0587a885fdb34fd6090a3f8625cb7ac1444826 ] When port buffer headroom changes, port_update_shared_buffer() recalculates the shared buffer size and splits it in a 3:1 ratio (lossy:lossless) - Currently, the calculation is: lossless = shared / 4; lossy = (shared / 4) * 3; Meaning, the calculation dropped the remainder of shared % 4 due to integer division, unintentionally reducing the total shared buffer by up to three cells on each update. Over time, this could shrink the buffer below usable size. Fix it by changing the calculation to: lossless = shared / 4; lossy = shared - lossless; This retains all buffer cells while still approximating the intended 3:1 split, preventing capacity loss over time. While at it, perform headroom calculations in units of cells rather than in bytes for more accurate calculations avoiding extra divisions. Fixes: a440030d8946 ("net/mlx5e: Update shared buffer along with device buffer changes") Signed-off-by: Armen Ratner <[email protected]> Signed-off-by: Maher Sanalla <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Alexei Lazar <[email protected]> Signed-off-by: Mark Bloch <[email protected]> Reviewed-by: Przemek Kitszel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexei Lazar <[email protected]> Date: Wed Aug 20 16:32:08 2025 +0300 net/mlx5e: Query FW for buffer ownership [ Upstream commit 451d2849ea66659040b59ae3cb7e50cc97404733 ] The SW currently saves local buffer ownership when setting the buffer. This means that the SW assumes it has ownership of the buffer after the command is set. If setting the buffer fails and we remain in FW ownership, the local buffer ownership state incorrectly remains as SW-owned. This leads to incorrect behavior in subsequent PFC commands, causing failures. Instead of saving local buffer ownership in SW, query the FW for buffer ownership when setting the buffer. This ensures that the buffer ownership state is accurately reflected, avoiding the issues caused by incorrect ownership states. Fixes: ecdf2dadee8e ("net/mlx5e: Receive buffer support for DCBX") Signed-off-by: Alexei Lazar <[email protected]> Reviewed-by: Shahar Shitrit <[email protected]> Reviewed-by: Dragos Tatulea <[email protected]> Signed-off-by: Mark Bloch <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: William Liu <[email protected]> Date: Tue Aug 12 23:57:57 2025 +0000 net/sched: Fix backlog accounting in qdisc_dequeue_internal [ Upstream commit 52bf272636bda69587952b35ae97690b8dc89941 ] This issue applies for the following qdiscs: hhf, fq, fq_codel, and fq_pie, and occurs in their change handlers when adjusting to the new limit. The problem is the following in the values passed to the subsequent qdisc_tree_reduce_backlog call given a tbf parent: When the tbf parent runs out of tokens, skbs of these qdiscs will be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued, which accounts for both qlen and backlog. However, in the case of qdisc_dequeue_internal, ONLY qlen is accounted for when pulling from gso_skb. This means that these qdiscs are missing a qdisc_qstats_backlog_dec when dropping packets to satisfy the new limit in their change handlers. One can observe this issue with the following (with tc patched to support a limit of 0): export TARGET=fq tc qdisc del dev lo root tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000 echo ''; echo 'add child'; tc -s -d qdisc show dev lo ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2>&1 >/dev/null echo ''; echo 'after ping'; tc -s -d qdisc show dev lo tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0 echo ''; echo 'after limit drop'; tc -s -d qdisc show dev lo tc qdisc replace dev lo handle 2: parent 1:1 sfq echo ''; echo 'post graft'; tc -s -d qdisc show dev lo The second to last show command shows 0 packets but a positive number (74) of backlog bytes. The problem becomes clearer in the last show command, where qdisc_purge_queue triggers qdisc_tree_reduce_backlog with the positive backlog and causes an underflow in the tbf parent's backlog (4096 Mb instead of 0). To fix this issue, the codepath for all clients of qdisc_dequeue_internal has been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel. qdisc_dequeue_internal handles the backlog adjustments for all cases that do not directly use the dequeue handler. The old fq_codel_change limit adjustment loop accumulated the arguments to the subsequent qdisc_tree_reduce_backlog call through the cstats field. However, this is confusing and error prone as fq_codel_dequeue could also potentially mutate this field (which qdisc_dequeue_internal calls in the non gso_skb case), so we have unified the code here with other qdiscs. Fixes: 2d3cbfd6d54a ("net_sched: Flush gso_skb list too during ->change()") Fixes: 4b549a2ef4be ("fq_codel: Fair Queue Codel AQM") Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc") Signed-off-by: William Liu <[email protected]> Reviewed-by: Savino Dicanosa <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: William Liu <[email protected]> Date: Tue Aug 19 03:36:28 2025 +0000 net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit [ Upstream commit 15de71d06a400f7fdc15bf377a2552b0ec437cf5 ] The following setup can trigger a WARNING in htb_activate due to the condition: !cl->leaf.q->q.qlen tc qdisc del dev lo root tc qdisc add dev lo root handle 1: htb default 1 tc class add dev lo parent 1: classid 1:1 \ htb rate 64bit tc qdisc add dev lo parent 1:1 handle f: \ cake memlimit 1b ping -I lo -f -c1 -s64 -W0.001 127.0.0.1 This is because the low memlimit leads to a low buffer_limit, which causes packet dropping. However, cake_enqueue still returns NET_XMIT_SUCCESS, causing htb_enqueue to call htb_activate with an empty child qdisc. We should return NET_XMIT_CN when packets are dropped from the same tin and flow. I do not believe return value of NET_XMIT_CN is necessary for packet drops in the case of ack filtering, as that is meant to optimize performance, not to signal congestion. Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by: William Liu <[email protected]> Reviewed-by: Savino Dicanosa <[email protected]> Acked-by: Toke Høiland-Jørgensen <[email protected]> Reviewed-by: Jamal Hadi Salim <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: William Liu <[email protected]> Date: Tue Aug 19 03:36:59 2025 +0000 net/sched: Remove unnecessary WARNING condition for empty child qdisc in htb_activate [ Upstream commit 2c2192e5f9c7c2892fe2363244d1387f62710d83 ] The WARN_ON trigger based on !cl->leaf.q->q.qlen is unnecessary in htb_activate. htb_dequeue_tree already accounts for that scenario. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: William Liu <[email protected]> Reviewed-by: Savino Dicanosa <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: D. Wythe <[email protected]> Date: Mon Aug 18 13:46:18 2025 +0800 net/smc: fix UAF on smcsk after smc_listen_out() [ Upstream commit d9cef55ed49117bd63695446fb84b4b91815c0b4 ] BPF CI testing report a UAF issue: [ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0 [ 16.447134] #PF: supervisor read access in kernel mod e [ 16.447516] #PF: error_code(0x0000) - not-present pag e [ 16.447878] PGD 0 P4D 0 [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2 [ 16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL E [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4 [ 16.450201] Workqueue: smc_hs_wq smc_listen_wor k [ 16.450531] RIP: 0010:smc_listen_work+0xc02/0x159 0 [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6 [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0 [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0 [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5 [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0 [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0 [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0 [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3 [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0 [ 16.456459] PKRU: 5555555 4 [ 16.456654] Call Trace : [ 16.456832] <TASK > [ 16.456989] ? __die+0x23/0x7 0 [ 16.457215] ? page_fault_oops+0x180/0x4c 0 [ 16.457508] ? __lock_acquire+0x3e6/0x249 0 [ 16.457801] ? exc_page_fault+0x68/0x20 0 [ 16.458080] ? asm_exc_page_fault+0x26/0x3 0 [ 16.458389] ? smc_listen_work+0xc02/0x159 0 [ 16.458689] ? smc_listen_work+0xc02/0x159 0 [ 16.458987] ? lock_is_held_type+0x8f/0x10 0 [ 16.459284] process_one_work+0x1ea/0x6d 0 [ 16.459570] worker_thread+0x1c3/0x38 0 [ 16.459839] ? __pfx_worker_thread+0x10/0x1 0 [ 16.460144] kthread+0xe0/0x11 0 [ 16.460372] ? __pfx_kthread+0x10/0x1 0 [ 16.460640] ret_from_fork+0x31/0x5 0 [ 16.460896] ? __pfx_kthread+0x10/0x1 0 [ 16.461166] ret_from_fork_asm+0x1a/0x3 0 [ 16.461453] </TASK > [ 16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE) ] [ 16.462134] CR2: 000000000000003 0 [ 16.462380] ---[ end trace 0000000000000000 ]--- [ 16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590 The direct cause of this issue is that after smc_listen_out_connected(), newclcsock->sk may be NULL since it will releases the smcsk. Therefore, if the application closes the socket immediately after accept, newclcsock->sk can be NULL. A possible execution order could be as follows: smc_listen_work | userspace ----------------------------------------------------------------- lock_sock(sk) | smc_listen_out_connected() | | \- smc_listen_out | | | \- release_sock | | |- sk->sk_data_ready() | | fd = accept(); | close(fd); | \- socket->sk = NULL; /* newclcsock->sk is NULL now */ SMC_STAT_SERV_SUCC_INC(sock_net(newclcsock->sk)) Since smc_listen_out_connected() will not fail, simply swapping the order of the code can easily fix this issue. Fixes: 3b2dec2603d5 ("net/smc: restructure client and server code in af_smc") Signed-off-by: D. Wythe <[email protected]> Reviewed-by: Guangguan Wang <[email protected]> Reviewed-by: Alexandra Winter <[email protected]> Reviewed-by: Dust Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lorenzo Bianconi <[email protected]> Date: Mon Aug 18 11:58:25 2025 +0200 net: airoha: ppe: Do not invalid PPE entries in case of SW hash collision [ Upstream commit 9f6b606b6b37e61427412708411e8e04b1a858e8 ] SW hash computed by airoha_ppe_foe_get_entry_hash routine (used for foe_flow hlist) can theoretically produce collisions between two different HW PPE entries. In airoha_ppe_foe_insert_entry() if the collision occurs we will mark the second PPE entry in the list as stale (setting the hw hash to 0xffff). Stale entries are no more updated in airoha_ppe_foe_flow_entry_update routine and so they are removed by Netfilter. Fix the problem not marking the second entry as stale in airoha_ppe_foe_insert_entry routine if we have already inserted the brand new entry in the PPE table and let Netfilter remove real stale entries according to their timestamp. Please note this is just a theoretical issue spotted reviewing the code and not faced running the system. Fixes: cd53f622611f9 ("net: airoha: Add L2 hw acceleration support") Signed-off-by: Lorenzo Bianconi <[email protected]> Link: https://patch.msgid.link/20250818-airoha-en7581-hash-collision-fix-v1-1-d190c4b53d1c@kernel.org Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wang Liang <[email protected]> Date: Wed Aug 13 10:10:54 2025 +0800 net: bridge: fix soft lockup in br_multicast_query_expired() [ Upstream commit d1547bf460baec718b3398365f8de33d25c5f36f ] When set multicast_query_interval to a large value, the local variable 'time' in br_multicast_send_query() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call mod_timer() again, which creates a loop and may trigger the following soft lockup issue. watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66] CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: <IRQ> __netdev_alloc_skb+0x2e/0x3a0 br_ip6_multicast_alloc_query+0x212/0x1b70 __br_multicast_send_query+0x376/0xac0 br_multicast_send_query+0x299/0x510 br_multicast_query_expired.constprop.0+0x16d/0x1b0 call_timer_fn+0x3b/0x2a0 __run_timers+0x619/0x950 run_timer_softirq+0x11c/0x220 handle_softirqs+0x18e/0x560 __irq_exit_rcu+0x158/0x1a0 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ> This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicast_querier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicast_query_interval ip link set dev br0 up The multicast_startup_query_interval can also cause this issue. Similar to the commit 99b40610956a ("net: bridge: mcast: add and enforce query interval minimum"), add check for the query interval maximum to fix this issue. Link: https://lore.kernel.org/netdev/[email protected]/ Link: https://lore.kernel.org/netdev/[email protected]/ Fixes: d902eee43f19 ("bridge: Add multicast count/interval sysfs entries") Suggested-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: Wang Liang <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tristram Ha <[email protected]> Date: Mon Aug 18 18:04:57 2025 -0700 net: dsa: microchip: Fix KSZ9477 HSR port setup issue [ Upstream commit e318cd6714592fb762fcab59c5684a442243a12f ] ksz9477_hsr_join() is called once to setup the HSR port membership, but the port can be enabled later, or disabled and enabled back and the port membership is not set correctly inside ksz_update_port_member(). The added code always use the correct HSR port membership for HSR port that is enabled. Fixes: 2d61298fdd7b ("net: dsa: microchip: Enable HSR offloading for KSZ9477") Reported-by: Frieder Schrempf <[email protected]> Signed-off-by: Tristram Ha <[email protected]> Reviewed-by: Łukasz Majewski <[email protected]> Tested-by: Frieder Schrempf <[email protected]> Reviewed-by: Frieder Schrempf <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qingfang Deng <[email protected]> Date: Thu Aug 14 09:25:57 2025 +0800 net: ethernet: mtk_ppe: add RCU lock around dev_fill_forward_path [ Upstream commit 62c30c544359aa18b8fb2734166467a07d435c2d ] Ensure ndo_fill_forward_path() is called with RCU lock held. Fixes: 2830e314778d ("net: ethernet: mtk-ppe: fix traffic offload with bridged wlan") Signed-off-by: Qingfang Deng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Ramaseuski <[email protected]> Date: Thu Aug 14 12:51:19 2025 +0200 net: gso: Forbid IPv6 TSO with extensions on devices with only IPV6_CSUM [ Upstream commit 864e3396976ef41de6cc7bc366276bf4e084fff2 ] When performing Generic Segmentation Offload (GSO) on an IPv6 packet that contains extension headers, the kernel incorrectly requests checksum offload if the egress device only advertises NETIF_F_IPV6_CSUM feature, which has a strict contract: it supports checksum offload only for plain TCP or UDP over IPv6 and explicitly does not support packets with extension headers. The current GSO logic violates this contract by failing to disable the feature for packets with extension headers, such as those used in GREoIPv6 tunnels. This violation results in the device being asked to perform an operation it cannot support, leading to a `skb_warn_bad_offload` warning and a collapse of network throughput. While device TSO/USO is correctly bypassed in favor of software GSO for these packets, the GSO stack must be explicitly told not to request checksum offload. Mask NETIF_F_IPV6_CSUM, NETIF_F_TSO6 and NETIF_F_GSO_UDP_L4 in gso_features_check if the IPv6 header contains extension headers to compute checksum in software. The exception is a BIG TCP extension, which, as stated in commit 68e068cabd2c6c53 ("net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets"): "The feature is only enabled on devices that support BIG TCP TSO. The header is only present for PF_PACKET taps like tcpdump, and not transmitted by physical devices." kernel log output (truncated): WARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skb_warn_bad_offload+0x81/0x140 ... Call Trace: <TASK> skb_checksum_help+0x12a/0x1f0 validate_xmit_skb+0x1a3/0x2d0 validate_xmit_skb_list+0x4f/0x80 sch_direct_xmit+0x1a2/0x380 __dev_xmit_skb+0x242/0x670 __dev_queue_xmit+0x3fc/0x7f0 ip6_finish_output2+0x25e/0x5d0 ip6_finish_output+0x1fc/0x3f0 ip6_tnl_xmit+0x608/0xc00 [ip6_tunnel] ip6gre_tunnel_xmit+0x1c0/0x390 [ip6_gre] dev_hard_start_xmit+0x63/0x1c0 __dev_queue_xmit+0x6d0/0x7f0 ip6_finish_output2+0x214/0x5d0 ip6_finish_output+0x1fc/0x3f0 ip6_xmit+0x2ca/0x6f0 ip6_finish_output+0x1fc/0x3f0 ip6_xmit+0x2ca/0x6f0 inet6_csk_xmit+0xeb/0x150 __tcp_transmit_skb+0x555/0xa80 tcp_write_xmit+0x32a/0xe90 tcp_sendmsg_locked+0x437/0x1110 tcp_sendmsg+0x2f/0x50 ... skb linear: 00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0e skb linear: 00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00 skb linear: 00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00 skb linear: 00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00 skb linear: 00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00 skb linear: 00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00 skb linear: 00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9 skb linear: 00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01 skb linear: 00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a Fixes: 04c20a9356f283da ("net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension") Reported-by: Tianhao Zhao <[email protected]> Suggested-by: Michal Schmidt <[email protected]> Suggested-by: Willem de Bruijn <[email protected]> Signed-off-by: Jakub Ramaseuski <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yao Zi <[email protected]> Date: Fri Aug 15 10:48:03 2025 +0000 net: stmmac: thead: Enable TX clock before MAC initialization [ Upstream commit 6d6714bf0c4e8eb2274081b4b023dfa01581c123 ] The clk_tx_i clock must be supplied to the MAC for successful initialization. On TH1520 SoC, the clock is provided by an internal divider configured through GMAC_PLLCLK_DIV register when using RGMII interface. However, currently we don't setup the divider before initialization of the MAC, resulting in DMA reset failures if the bootloader/firmware doesn't enable the divider, [ 7.839601] thead-dwmac ffe7060000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 7.938338] thead-dwmac ffe7060000.ethernet eth0: PHY [stmmac-0:02] driver [RTL8211F Gigabit Ethernet] (irq=POLL) [ 8.160746] thead-dwmac ffe7060000.ethernet eth0: Failed to reset the dma [ 8.170118] thead-dwmac ffe7060000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed [ 8.179384] thead-dwmac ffe7060000.ethernet eth0: __stmmac_open: Hw setup failed Let's simply write GMAC_PLLCLK_DIV_EN to GMAC_PLLCLK_DIV to enable the divider before MAC initialization. Note that for reconfiguring the divisor, the divider must be disabled first and re-enabled later to make sure the new divisor take effect. The exact clock rate doesn't affect MAC's initialization according to my test. It's set to the speed required by RGMII when the linkspeed is 1Gbps and could be reclocked later after link is up if necessary. Fixes: 33a1a01e3afa ("net: stmmac: Add glue layer for T-HEAD TH1520 SoC") Signed-off-by: Yao Zi <[email protected]> Reviewed-by: Drew Fustini <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: MD Danish Anwar <[email protected]> Date: Thu Aug 14 16:21:06 2025 +0530 net: ti: icssg-prueth: Fix HSR and switch offload Enablement during firwmare reload. [ Upstream commit 01792bc3e5bdafa171dd83c7073f00e7de93a653 ] To enable HSR / Switch offload, certain configurations are needed. Currently they are done inside icssg_change_mode(). This function only gets called if we move from one mode to another without bringing the links up / down. Once in HSR / Switch mode, if we bring the links down and bring it back up again. The callback sequence is, - emac_ndo_stop() Firmwares are stopped - emac_ndo_open() Firmwares are loaded In this path icssg_change_mode() doesn't get called and as a result the configurations needed for HSR / Switch is not done. To fix this, put all these configurations in a separate function icssg_enable_fw_offload() and call this from both icssg_change_mode() and emac_ndo_open() Fixes: 56375086d093 ("net: ti: icssg-prueth: Enable HSR Tx duplication, Tx Tag and Rx Tag offload") Signed-off-by: MD Danish Anwar <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yuichiro Tsuji <[email protected]> Date: Mon Aug 18 17:45:07 2025 +0900 net: usb: asix_devices: Fix PHY address mask in MDIO bus initialization [ Upstream commit 24ef2f53c07f273bad99173e27ee88d44d135b1c ] Syzbot reported shift-out-of-bounds exception on MDIO bus initialization. The PHY address should be masked to 5 bits (0-31). Without this mask, invalid PHY addresses could be used, potentially causing issues with MDIO bus operations. Fix this by masking the PHY address with 0x1f (31 decimal) to ensure it stays within the valid range. Fixes: 4faff70959d5 ("net: usb: asix_devices: add phy_mask for ax88772 mdio bus") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=20537064367a0f98d597 Tested-by: [email protected] Signed-off-by: Yuichiro Tsuji <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Suraj Gupta <[email protected]> Date: Wed Aug 13 19:25:59 2025 +0530 net: xilinx: axienet: Fix RX skb ring management in DMAengine mode [ Upstream commit fd980bf6e9cdae885105685259421164f843ca55 ] Submit multiple descriptors in axienet_rx_cb() to fill Rx skb ring. This ensures the ring "catches up" on previously missed allocations. Increment Rx skb ring head pointer after BD is successfully allocated. Previously, head pointer was incremented before verifying if descriptor is successfully allocated and has valid entries, which could lead to ring state inconsistency if descriptor setup failed. These changes improve reliability by maintaining adequate descriptor availability and ensuring proper ring buffer state management. Fixes: 6a91b846af85 ("net: axienet: Introduce dmaengine support") Signed-off-by: Suraj Gupta <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Westphal <[email protected]> Date: Wed Aug 20 14:37:07 2025 +0200 netfilter: nf_reject: don't leak dst refcount for loopback packets [ Upstream commit 91a79b792204313153e1bdbbe5acbfc28903b3a5 ] recent patches to add a WARN() when replacing skb dst entry found an old bug: WARNING: include/linux/skbuff.h:1165 skb_dst_check_unset include/linux/skbuff.h:1164 [inline] WARNING: include/linux/skbuff.h:1165 skb_dst_set include/linux/skbuff.h:1210 [inline] WARNING: include/linux/skbuff.h:1165 nf_reject_fill_skb_dst+0x2a4/0x330 net/ipv4/netfilter/nf_reject_ipv4.c:234 [..] Call Trace: nf_send_unreach+0x17b/0x6e0 net/ipv4/netfilter/nf_reject_ipv4.c:325 nft_reject_inet_eval+0x4bc/0x690 net/netfilter/nft_reject_inet.c:27 expr_call_ops_eval net/netfilter/nf_tables_core.c:237 [inline] .. This is because blamed commit forgot about loopback packets. Such packets already have a dst_entry attached, even at PRE_ROUTING stage. Instead of checking hook just check if the skb already has a route attached to it. Fixes: f53b9b0bdc59 ("netfilter: introduce support for reject at prerouting stage") Signed-off-by: Florian Westphal <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Howells <[email protected]> Date: Thu Aug 14 22:45:50 2025 +0100 netfs: Fix unbuffered write error handling commit a3de58b12ce074ec05b8741fa28d62ccb1070468 upstream. If all the subrequests in an unbuffered write stream fail, the subrequest collector doesn't update the stream->transferred value and it retains its initial LONG_MAX value. Unfortunately, if all active streams fail, then we take the smallest value of { LONG_MAX, LONG_MAX, ... } as the value to set in wreq->transferred - which is then returned from ->write_iter(). LONG_MAX was chosen as the initial value so that all the streams can be quickly assessed by taking the smallest value of all stream->transferred - but this only works if we've set any of them. Fix this by adding a flag to indicate whether the value in stream->transferred is valid and checking that when we integrate the values. stream->transferred can then be initialised to zero. This was found by running the generic/750 xfstest against cifs with cache=none. It splices data to the target file. Once (if) it has used up all the available scratch space, the writes start failing with ENOSPC. This causes ->write_iter() to fail. However, it was returning wreq->transferred, i.e. LONG_MAX, rather than an error (because it thought the amount transferred was non-zero) and iter_file_splice_write() would then try to clean up that amount of pipe bufferage - leading to an oops when it overran. The kernel log showed: CIFS: VFS: Send error in write = -28 followed by: BUG: kernel NULL pointer dereference, address: 0000000000000008 with: RIP: 0010:iter_file_splice_write+0x3a4/0x520 do_splice+0x197/0x4e0 or: RIP: 0010:pipe_buf_release (include/linux/pipe_fs_i.h:282) iter_file_splice_write (fs/splice.c:755) Also put a warning check into splice to announce if ->write_iter() returned that it had written more than it was asked to. Fixes: 288ace2f57c9 ("netfs: New writeback implementation") Reported-by: Xiaoli Feng <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220445 Signed-off-by: David Howells <[email protected]> Link: https://lore.kernel.org/[email protected] cc: Paulo Alcantara <[email protected]> cc: Steve French <[email protected]> cc: Shyam Prasad N <[email protected]> cc: [email protected] cc: [email protected] cc: [email protected] cc: [email protected] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Sat Aug 16 07:25:20 2025 -0700 NFS: Fix a race when updating an existing write commit 76d2e3890fb169168c73f2e4f8375c7cc24a765e upstream. After nfs_lock_and_join_requests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfs_inode_remove_request() from succeeding until we actually lock the page group. The reason is that whoever called nfs_inode_remove_request() doesn't necessarily have a lock on the page group head. So in order to avoid races, let's take the page group lock earlier in nfs_lock_and_join_requests(), and hold it across the removal of the request in nfs_inode_remove_request(). Reported-by: Jeff Layton <[email protected]> Tested-by: Joe Quanaim <[email protected]> Tested-by: Andrew Steffen <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Fixes: bd37d6fce184 ("NFSv4: Convert nfs_lock_and_join_requests() to use nfs_page_find_head_request()") Cc: [email protected] Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tiezhu Yang <[email protected]> Date: Wed Aug 20 22:23:15 2025 +0800 objtool/LoongArch: Get table size correctly if LTO is enabled [ Upstream commit a47bc954cf0eb51f2828e1607d169d487df7f11f ] When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist many objtool warnings "sibling call from callable instruction with modified stack frame". For this special case, the related object file shows that there is no generated relocation section '.rela.discard.tablejump_annotate' for the table jump instruction jirl, thus objtool can not know that what is the actual destination address. It needs to do something on the LLVM side to make sure that there is the relocation section '.rela.discard.tablejump_annotate' if LTO is enabled, but in order to maintain compatibility for the current LLVM compiler, this can be done in the kernel Makefile for now. Ensure it is aware of linker with LTO, '--loongarch-annotate-tablejump' needs to be passed via '-mllvm' to ld.lld. Before doing the above changes, it should handle the special case of the relocation section '.rela.discard.tablejump_annotate' to get the correct table size first, otherwise there are many objtool warnings and errors if LTO is enabled. There are many different rodata for each function if LTO is enabled, it is necessary to enhance get_rodata_table_size_by_table_annotate(). Fixes: b95f852d3af2 ("objtool/LoongArch: Add support for switch table") Closes: https://lore.kernel.org/loongarch/20250731175655.GA1455142@ax162/ Reported-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hariprasad Kelam <[email protected]> Date: Wed Aug 20 12:09:18 2025 +0530 Octeontx2-af: Skip overlap check for SPI field [ Upstream commit 8c5d95988c34f0aeba1f34cd5e4ba69494c90c5f ] Octeontx2/CN10K silicon supports generating a 256-bit key per packet. The specific fields to be extracted from a packet for key generation are configurable via a Key Extraction (MKEX) Profile. The AF driver scans the configured extraction profile to ensure that fields from upper layers do not overwrite fields from lower layers in the key. Example Packet Field Layout: LA: DMAC + SMAC LB: VLAN LC: IPv4/IPv6 LD: TCP/UDP Valid MKEX Profile Configuration: LA -> DMAC -> key_offset[0-5] LC -> SIP -> key_offset[20-23] LD -> SPORT -> key_offset[30-31] Invalid MKEX profile configuration: LA -> DMAC -> key_offset[0-5] LC -> SIP -> key_offset[20-23] LD -> SPORT -> key_offset[2-3] // Overlaps with DMAC field In another scenario, if the MKEX profile is configured to extract the SPI field from both AH and ESP headers at the same key offset, the driver rejecting this configuration. In a regular traffic, ipsec packet will be having either AH(LD) or ESP (LE). This patch relaxes the check for the same. Fixes: 12aa0a3b93f3 ("octeontx2-af: Harden rule validation.") Signed-off-by: Hariprasad Kelam <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aleksa Sarai <[email protected]> Date: Fri Aug 8 03:55:05 2025 +1000 open_tree_attr: do not allow id-mapping changes without OPEN_TREE_CLONE commit 9308366f062129d52e0ee3f7a019f7dd41db33df upstream. As described in commit 7a54947e727b ('Merge patch series "fs: allow changing idmappings"'), open_tree_attr(2) was necessary in order to allow for a detached mount to be created and have its idmappings changed without the risk of any racing threads operating on it. For this reason, mount_setattr(2) still does not allow for id-mappings to be changed. However, there was a bug in commit 2462651ffa76 ("fs: allow changing idmappings") which allowed users to bypass this restriction by calling open_tree_attr(2) *without* OPEN_TREE_CLONE. can_idmap_mount() prevented this bug from allowing an attached mountpoint's id-mapping from being modified (thanks to an is_anon_ns() check), but this still allows for detached (but visible) mounts to have their be id-mapping changed. This risks the same UAF and locking issues as described in the merge commit, and was likely unintentional. Fixes: 2462651ffa76 ("fs: allow changing idmappings") Cc: [email protected] # v6.15+ Signed-off-by: Aleksa Sarai <[email protected]> Link: https://lore.kernel.org/20250808-open_tree_attr-bugfix-idmap-v1-1-0ec7bc05646c@cyphar.com Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: NeilBrown <[email protected]> Date: Mon Aug 4 22:11:28 2025 +1000 ovl: use I_MUTEX_PARENT when locking parent in ovl_create_temp() commit 5f1c8965e748c150d580a2ea8fbee1bd80d07a24 upstream. ovl_create_temp() treats "workdir" as a parent in which it creates an object so it should use I_MUTEX_PARENT. Prior to the commit identified below the lock was taken by the caller which sometimes used I_MUTEX_PARENT and sometimes used I_MUTEX_NORMAL. The use of I_MUTEX_NORMAL was incorrect but unfortunately copied into ovl_create_temp(). Note to backporters: This patch only applies after the last Fixes given below (post v6.16). To fix the bug in v6.7 and later the inode_lock() call in ovl_copy_up_workdir() needs to nest using I_MUTEX_PARENT. Link: https://lore.kernel.org/all/[email protected]/ Cc: [email protected] Reported-by: [email protected] Tested-by: [email protected] Fixes: c63e56a4a652 ("ovl: do not open/llseek lower file with upper sb_writers held") Fixes: d2c995581c7c ("ovl: Call ovl_create_temp() without lock held.") Signed-off-by: NeilBrown <[email protected]> Signed-off-by: Amir Goldstein <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: John David Anglin <[email protected]> Date: Mon Jul 21 15:39:26 2025 -0400 parisc: Check region is readable by user in raw_copy_from_user() commit 91428ca9320edbab1211851d82429d33b9cd73ef upstream. Because of the way the _PAGE_READ is handled in the parisc PTE, an access interruption is not generated when the kernel reads from a region where the _PAGE_READ is zero. The current code was written assuming read access faults would also occur in the kernel. This change adds user access checks to raw_copy_from_user(). The prober_user() define checks whether user code has read access to a virtual address. Note that page faults are not handled in the exception support for the probe instruction. For this reason, we precede the probe by a ldb access check. Signed-off-by: John David Anglin <[email protected]> Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] # v5.12+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: John David Anglin <[email protected]> Date: Mon Jul 21 16:06:21 2025 -0400 parisc: Define and use set_pte_at() commit 802e55488bc2cc1ab6423b720255a785ccac42ce upstream. When a PTE is changed, we need to flush the PTE. set_pte_at() was lost in the folio update. PA-RISC version is the same as the generic version. Signed-off-by: John David Anglin <[email protected]> Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] # v5.12+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: John David Anglin <[email protected]> Date: Mon Jul 21 16:18:41 2025 -0400 parisc: Drop WARN_ON_ONCE() from flush_cache_vmap commit 4eab1c27ce1f0e89ab67b01bf1e4e4c75215708a upstream. I have observed warning to occassionally trigger. Signed-off-by: John David Anglin <[email protected]> Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] # v5.12+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Randy Dunlap <[email protected]> Date: Wed Jun 25 00:30:54 2025 -0700 parisc: Makefile: explain that 64BIT requires both 32-bit and 64-bit compilers commit 305ab0a748c52eeaeb01d8cff6408842d19e5cb5 upstream. For building a 64-bit kernel, both 32-bit and 64-bit VDSO binaries are built, so both 32-bit and 64-bit compilers (and tools) should be in the PATH environment variable. Signed-off-by: Randy Dunlap <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: Helge Deller <[email protected]> Cc: [email protected] Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] # v5.3+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: John David Anglin <[email protected]> Date: Mon Jul 21 15:56:04 2025 -0400 parisc: Rename pte_needs_flush() to pte_needs_cache_flush() in cache.c commit 52ce9406a9625c4498c4eaa51e7a7ed9dcb9db16 upstream. The local name used in cache.c conflicts the declaration in include/asm-generic/tlb.h. Signed-off-by: John David Anglin <[email protected]> Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] # v5.12+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: John David Anglin <[email protected]> Date: Fri Jul 25 13:51:32 2025 -0400 parisc: Revise __get_user() to probe user read access commit 89f686a0fb6e473a876a9a60a13aec67a62b9a7e upstream. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel executes at privilege level 0, so __get_user() never triggers a read access interruption (code 26). Thus, it is currently possible for user code to access a read protected address via a system call. Fix this by probing read access rights at privilege level 3 (PRIV_USER) and setting __gu_err to -EFAULT (-14) if access isn't allowed. Note the cmpiclr instruction does a 32-bit compare because COND macro doesn't work inside asm. Signed-off-by: John David Anglin <[email protected]> Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] # v5.12+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: John David Anglin <[email protected]> Date: Fri Jul 25 12:12:14 2025 -0400 parisc: Revise gateway LWS calls to probe user read access commit f6334f4ae9a4e962ba74b026e1d965dfdf8cbef8 upstream. We use load and stbys,e instructions to trigger memory reference interruptions without writing to memory. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel and gateway page execute at privilege level 0, so this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS compare and swap operation at an address that is read protected at privilege level 3 (PRIV_USER). Fix this by probing read access rights at privilege level 3 and branching to lws_fault if access isn't allowed. Signed-off-by: John David Anglin <[email protected]> Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] # v5.12+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: John David Anglin <[email protected]> Date: Mon Jul 21 16:13:13 2025 -0400 parisc: Try to fixup kernel exception in bad_area_nosemaphore path of do_page_fault() commit f92a5e36b0c45cd12ac0d1bc44680c0dfae34543 upstream. Signed-off-by: John David Anglin <[email protected]> Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] # v5.12+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: John David Anglin <[email protected]> Date: Mon Jul 21 15:13:42 2025 -0400 parisc: Update comments in make_insert_tlb commit cb22f247f371bd206a88cf0e0c05d80b8b62fb26 upstream. The following testcase exposed a problem with our read access checks in get_user() and raw_copy_from_user(): #include <stdint.h> #include <stddef.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <sys/mman.h> #include <sys/types.h> int main(int argc, char **argv) { unsigned long page_size = sysconf(_SC_PAGESIZE); char *p = malloc(3 * page_size); char *p_aligned; /* initialize memory region. If not initialized, write syscall below will correctly return EFAULT. */ if (1) memset(p, 'X', 3 * page_size); p_aligned = (char *) ((((uintptr_t) p) + (2*page_size - 1)) & ~(page_size - 1)); /* Drop PROT_READ protection. Kernel and userspace should fault when accessing that memory region */ mprotect(p_aligned, page_size, PROT_NONE); /* the following write() should return EFAULT, since PROT_READ was dropped by previous mprotect() */ int ret = write(2, p_aligned, 1); if (!ret || errno != EFAULT) printf("\n FAILURE: write() did not returned expected EFAULT value\n"); return 0; } Because of the way _PAGE_READ is handled, kernel code never generates a read access fault when it access a page as the kernel privilege level is always less than PL1 in the PTE. This patch reworks the comments in the make_insert_tlb macro to try to make this clearer. Signed-off-by: John David Anglin <[email protected]> Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] # v5.12+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lukas Wunner <[email protected]> Date: Sun Jul 13 16:31:02 2025 +0200 PCI/portdrv: Use is_pciehp instead of is_hotplug_bridge commit 1d60796a62f327cd9e0a6a0865ded7656d2c67f9 upstream. The PCIe port driver erroneously creates a subdevice for hotplug on ACPI slots which are handled by the ACPI hotplug driver. Avoid by checking the is_pciehp flag instead of is_hotplug_bridge when deciding whether to create a subdevice. The latter encompasses ACPI slots whereas the former doesn't. The superfluous subdevice has no real negative impact, it occupies memory and interrupt resources but otherwise just sits there waiting for interrupts from the slot that are never signaled. Fixes: f8415222837b ("PCI: Use cached copy of PCI_EXP_SLTCAP_HPC bit") Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Cc: [email protected] # v4.7+ Link: https://patch.msgid.link/40d5a5fe8d40595d505949c620a067fa110ee85e.1752390102.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Niklas Cassel <[email protected]> Date: Wed Jun 25 12:23:51 2025 +0200 PCI: dwc: Ensure that dw_pcie_wait_for_link() waits 100 ms after link up commit 80dc18a0cba8dea42614f021b20a04354b213d86 upstream. As per PCIe r6.0, sec 6.6.1, a Downstream Port that supports Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link training completes before sending a Configuration Request. Add this delay in dw_pcie_wait_for_link(), after the link is reported as up. The delay will only be performed in the success case where the link came up. DWC glue drivers that have a link up IRQ (drivers that set use_linkup_irq = true) do not call dw_pcie_wait_for_link(), instead they perform this delay in their threaded link up IRQ handler. Signed-off-by: Niklas Cassel <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Wilfred Mallawa <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Damien Le Moal <[email protected]> Date: Tue Jun 24 20:45:43 2025 +0900 PCI: endpoint: Fix configfs group list head handling commit d79123d79a8154b4318529b7b2ff7e15806f480b upstream. Doing a list_del() on the epf_group field of struct pci_epf_driver in pci_epf_remove_cfs() is not correct as this field is a list head, not a list entry. This list_del() call triggers a KASAN warning when an endpoint function driver which has a configfs attribute group is torn down: ================================================================== BUG: KASAN: slab-use-after-free in pci_epf_remove_cfs+0x17c/0x198 Write of size 8 at addr ffff00010f4a0d80 by task rmmod/319 CPU: 3 UID: 0 PID: 319 Comm: rmmod Not tainted 6.16.0-rc2 #1 NONE Hardware name: Radxa ROCK 5B (DT) Call trace: show_stack+0x2c/0x84 (C) dump_stack_lvl+0x70/0x98 print_report+0x17c/0x538 kasan_report+0xb8/0x190 __asan_report_store8_noabort+0x20/0x2c pci_epf_remove_cfs+0x17c/0x198 pci_epf_unregister_driver+0x18/0x30 nvmet_pci_epf_cleanup_module+0x24/0x30 [nvmet_pci_epf] __arm64_sys_delete_module+0x264/0x424 invoke_syscall+0x70/0x260 el0_svc_common.constprop.0+0xac/0x230 do_el0_svc+0x40/0x58 el0_svc+0x48/0xdc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ... Remove this incorrect list_del() call from pci_epf_remove_cfs(). Fixes: ef1433f717a2 ("PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry") Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Niklas Cassel <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Damien Le Moal <[email protected]> Date: Tue Jun 24 20:45:44 2025 +0900 PCI: endpoint: Fix configfs group removal on driver teardown commit 910bdb8197f9322790c738bb32feaa11dba26909 upstream. An endpoint driver configfs attributes group is added to the epf_group list of struct pci_epf_driver by pci_epf_add_cfs() but an added group is not removed from this list when the attribute group is unregistered with pci_ep_cfs_remove_epf_group(). Add the missing list_del() call in pci_ep_cfs_remove_epf_group() to correctly remove the attribute group from the driver list. With this change, once the loop over all attribute groups in pci_epf_remove_cfs() completes, the driver epf_group list should be empty. Add a WARN_ON() to make sure of that. Fixes: ef1433f717a2 ("PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry") Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Niklas Cassel <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jiwei Sun <[email protected]> Date: Thu Jan 23 13:51:54 2025 +0800 PCI: Fix link speed calculation on retrain failure commit 9989e0ca7462c62f93dbc62f684448aa2efb9226 upstream. When pcie_failed_link_retrain() fails to retrain, it tries to revert to the previous link speed. However it calculates that speed from the Link Control 2 register without masking out non-speed bits first. PCIE_LNKCTL2_TLS2SPEED() converts such incorrect values to PCI_SPEED_UNKNOWN (0xff), which in turn causes a WARN splat in pcie_set_target_speed(): pci 0000:00:01.1: [1022:14ed] type 01 class 0x060400 PCIe Root Port pci 0000:00:01.1: broken device, retraining non-functional downstream link at 2.5GT/s pci 0000:00:01.1: retraining failed WARNING: CPU: 1 PID: 1 at drivers/pci/pcie/bwctrl.c:168 pcie_set_target_speed RDX: 0000000000000001 RSI: 00000000000000ff RDI: ffff9acd82efa000 pcie_failed_link_retrain pci_device_add pci_scan_single_device Mask out the non-speed bits in PCIE_LNKCTL2_TLS2SPEED() and PCIE_LNKCAP_SLS2SPEED() so they don't incorrectly return PCI_SPEED_UNKNOWN. Fixes: de9a6c8d5dbf ("PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed") Reported-by: Andrew <[email protected]> Closes: https://lore.kernel.org/r/7iNzXbCGpf8yUMJZBQjLdbjPcXrEJqBxy5-bHfppz0ek-h4_-G93b1KUrm106r2VNF2FV_sSq0nENv4RsRIUGnlYZMlQr2ZD2NyB5sdj5aU=@protonmail.com/ Suggested-by: Maciej W. Rozycki <[email protected]> Suggested-by: Ilpo Järvinen <[email protected]> Signed-off-by: Jiwei Sun <[email protected]> [bhelgaas: commit log, add details from https://lore.kernel.org/r/1c92ef6bcb314ee6977839b46b393282e4f52e74.1750684771.git.lukas@wunner.de] Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Cc: [email protected] # v6.13+ Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Richard Zhu <[email protected]> Date: Tue Jul 8 17:10:03 2025 +0800 PCI: imx6: Add IMX8MM_EP and IMX8MP_EP fixed 256-byte BAR 4 in epc_features commit 399444a87acdea5d21c218bc8e9b621fea1cd218 upstream. For IMX8MM_EP and IMX8MP_EP, add fixed 256-byte BAR 4 and reserved BAR 5 in imx8m_pcie_epc_features. Fixes: 75c2f26da03f ("PCI: imx6: Add i.MX PCIe EP mode support") Signed-off-by: Richard Zhu <[email protected]> [bhelgaas: add details in subject] Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Frank Li <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Richard Zhu <[email protected]> Date: Tue Jul 8 17:10:02 2025 +0800 PCI: imx6: Add IMX8MQ_EP third 64-bit BAR in epc_features commit c523fa63ac1d452abeeb4e699560ec3365037f32 upstream. IMX8MQ_EP has three 64-bit BAR0/2/4 capable and programmable BARs. For IMX8MQ_EP, use imx8q_pcie_epc_features (64-bit BARs 0, 2, 4) instead of imx8m_pcie_epc_features (64-bit BARs 0, 2). Fixes: 75c2f26da03f ("PCI: imx6: Add i.MX PCIe EP mode support") Signed-off-by: Richard Zhu <[email protected]> [bhelgaas: add details in subject] Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Frank Li <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Richard Zhu <[email protected]> Date: Wed Jul 9 11:37:22 2025 +0800 PCI: imx6: Delay link start until configfs 'start' written commit 2e6ea70690ddd1ffa422423fd0d4523e4dfe4b62 upstream. According to Documentation/PCI/endpoint/pci-endpoint-cfs.rst, the Endpoint controller (EPC) should only start the link when userspace writes '1' to the '/sys/kernel/config/pci_ep/controllers/<EPC>/start' attribute, which ultimately results in calling imx_pcie_start_link() via pci_epc_start_store(). To align with the documented behavior, do not start the link automatically when adding the EP controller. Fixes: 75c2f26da03f ("PCI: imx6: Add i.MX PCIe EP mode support") Signed-off-by: Richard Zhu <[email protected]> [mani: reworded commit subject and description] Signed-off-by: Manivannan Sadhasivam <[email protected]> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Frank Li <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Richard Zhu <[email protected]> Date: Wed Jul 9 11:37:21 2025 +0800 PCI: imx6: Remove apps_reset toggling from imx_pcie_{assert/deassert}_core_reset commit d31eb217425591e100b475fad6360cd3da2073c6 upstream. apps_reset corresponds to LTSSM_EN in i.MX7, i.MX8MQ, i.MX8MM and i.MX8MP platforms. Since assertion/de-assertion of apps_reset is done in imx_pcie_ltssm_enable() and imx_pcie_ltssm_disable(), remove it from imx_pcie_assert_core_reset() and imx_pcie_deassert_core_reset(). This also fixes a failure in enumerating the PI7C9X2G608GP (hotplug) chip reliably on i.MX8MM, as reported by Tim. It should be noted that only i.MX7D, i.MX8MQ, i.MX8MM, and i.MX8MP platforms have the apps_reset logic, so this change doesn't have any effect on other platforms. Fixes: ef61c7d8d032 ("PCI: imx6: Deassert apps_reset in imx_pcie_deassert_core_reset()") Reported-by: Tim Harvey <[email protected]> Closes: https://lore.kernel.org/all/CAJ+vNU3ohR2YKTwC4xoYrc1z-neDoH2TTZcMHDy+poj9=jSy+w@mail.gmail.com/ Signed-off-by: Richard Zhu <[email protected]> [mani: reworded commit subject and description] Signed-off-by: Manivannan Sadhasivam <[email protected]> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <[email protected]> Tested-by: Tim Harvey <[email protected]> # imx8mp-venice-gw74xx (i.MX8MP + hotplug capable switch) Reviewed-by: Frank Li <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Geraldo Nascimento <[email protected]> Date: Fri Aug 22 15:10:31 2025 -0400 PCI: rockchip: Set Target Link Speed to 5.0 GT/s before retraining [ Upstream commit 114b06ee108cabc82b995fbac6672230a9776936 ] Rockchip controllers can support up to 5.0 GT/s link speed. But the driver doesn't set the Target Link Speed currently. This may cause failure in retraining the link to 5.0 GT/s if supported by the endpoint. So set the Target Link Speed to 5.0 GT/s in the Link Control and Status Register 2. Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support") Signed-off-by: Geraldo Nascimento <[email protected]> [mani: fixed whitespace warning, commit message rewording, added fixes tag] Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Tested-by: Robin Murphy <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/0afa6bc47b7f50e2e81b0b47d51c66feb0fb565f.1751322015.git.geraldogabriel@gmail.com Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Geraldo Nascimento <[email protected]> Date: Fri Aug 22 15:10:30 2025 -0400 PCI: rockchip: Use standard PCIe definitions [ Upstream commit cbbfe9f683f0f9b6a1da2eaa53b995a4b5961086 ] Current code uses custom-defined register offsets and bitfields for the standard PCIe registers. This creates duplication as the PCI header already defines them. So, switch to using the standard PCIe definitions and drop the custom ones. Suggested-by: Bjorn Helgaas <[email protected]> Signed-off-by: Geraldo Nascimento <[email protected]> [mani: commit message rewording] Signed-off-by: Manivannan Sadhasivam <[email protected]> [bhelgaas: include bitfield.h] Signed-off-by: Bjorn Helgaas <[email protected]> Link: https://patch.msgid.link/e81700ef4b49f584bc8834bfb07b6d8995fc1f42.1751322015.git.geraldogabriel@gmail.com Stable-dep-of: 114b06ee108c ("PCI: rockchip: Set Target Link Speed to 5.0 GT/s before retraining") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Horatiu Vultur <[email protected]> Date: Mon Aug 18 10:10:29 2025 +0200 phy: mscc: Fix timestamping for vsc8584 [ Upstream commit bc1a59cff9f797bfbf8f3104507584d89e9ecf2e ] There was a problem when we received frames and the frames were timestamped. The driver is configured to store the nanosecond part of the timestmap in the ptp reserved bits and it would take the second part by reading the LTC. The problem is that when reading the LTC we are in atomic context and to read the second part will go over mdio bus which might sleep, so we get an error. The fix consists in actually put all the frames in a queue and start the aux work and in that work to read the LTC and then calculate the full received time. Fixes: 7d272e63e0979d ("net: phy: mscc: timestamping and PHC support") Signed-off-by: Horatiu Vultur <[email protected]> Reviewed-by: Vadim Fedorenko <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kathiravan Thirumoorthy <[email protected]> Date: Mon Jun 30 13:48:13 2025 +0530 phy: qcom: phy-qcom-m31: Update IPQ5332 M31 USB phy initialization sequence commit 4a3556b81b99f0c8c0358f7cc6801a62b4538fe2 upstream. The current configuration used for the IPQ5332 M31 USB PHY fails the Near End High Speed Signal Quality compliance test. To resolve this, update the initialization sequence as specified in the Hardware Design Document. Fixes: 08e49af50701 ("phy: qcom: Introduce M31 USB PHY driver") Cc: [email protected] Signed-off-by: Kathiravan Thirumoorthy <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/20250630-ipq5332_hsphy_complaince-v2-1-63621439ebdb@oss.qualcomm.com Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tzung-Bi Shih <[email protected]> Date: Tue Jul 22 12:05:13 2025 +0000 platform/chrome: cros_ec: Unregister notifier in cros_ec_unregister() commit e2374953461947eee49f69b3e3204ff080ef31b1 upstream. The blocking notifier is registered in cros_ec_register(); however, it isn't unregistered in cros_ec_unregister(). Fix it. Fixes: 42cd0ab476e2 ("platform/chrome: cros_ec: Query EC protocol version if EC transitions between RO/RW") Cc: [email protected] Reviewed-by: Benson Leung <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tzung-Bi Shih <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Suma Hegde <[email protected]> Date: Thu Aug 7 10:06:37 2025 +0000 platform/x86/amd/hsmp: Ensure sock->metric_tbl_addr is non-NULL [ Upstream commit 2c78fb287e1f430b929f2e49786518350d15605c ] If metric table address is not allocated, accessing metrics_bin will result in a NULL pointer dereference, so add a check. Fixes: 5150542b8ec5 ("platform/x86/amd/hsmp: add support for metrics tbl") Signed-off-by: Suma Hegde <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Srinivas Pandruvada <[email protected]> Date: Sun Jul 27 14:05:13 2025 -0700 platform/x86/intel-uncore-freq: Check write blocked for ELC commit dff6f36878799a5ffabd15336ce993dc737374dc upstream. Add the missing write_blocked check for updating sysfs related to uncore efficiency latency control (ELC). If write operation is blocked return error. Fixes: bb516dc79c4a ("platform/x86/intel-uncore-freq: Add support for efficiency latency control") Signed-off-by: Srinivas Pandruvada <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Wed Jul 9 12:41:45 2025 +0200 PM: runtime: Take active children into account in pm_runtime_get_if_in_use() commit 51888393cc64dd0462d0b96c13ab94873abbc030 upstream. For all practical purposes, there is no difference between the situation in which a given device is not ignoring children and its active child count is nonzero and the situation in which its runtime PM usage counter is nonzero. However, pm_runtime_get_if_in_use() will only increment the device's usage counter and return 1 in the latter case. For consistency, make it do so in the former case either by adjusting pm_runtime_get_conditional() and update the related kerneldoc comments accordingly. Fixes: c111566bea7c ("PM: runtime: Add pm_runtime_get_if_active()") Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Ulf Hansson <[email protected]> Reviewed-by: Sakari Ailus <[email protected]> Cc: 5.10+ <[email protected]> # 5.10+: c0ef3df8dbae: PM: runtime: Simplify pm_runtime_get_if_active() usage Cc: 5.10+ <[email protected]> # 5.10+ Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qingfang Deng <[email protected]> Date: Thu Aug 14 09:25:58 2025 +0800 ppp: fix race conditions in ppp_fill_forward_path [ Upstream commit 0417adf367a0af11adf7ace849af4638cfb573f7 ] ppp_fill_forward_path() has two race conditions: 1. The ppp->channels list can change between list_empty() and list_first_entry(), as ppp_lock() is not held. If the only channel is deleted in ppp_disconnect_channel(), list_first_entry() may access an empty head or a freed entry, and trigger a panic. 2. pch->chan can be NULL. When ppp_unregister_channel() is called, pch->chan is set to NULL before pch is removed from ppp->channels. Fix these by using a lockless RCU approach: - Use list_first_or_null_rcu() to safely test and access the first list entry. - Convert list modifications on ppp->channels to their RCU variants and add synchronize_net() after removal. - Check for a NULL pch->chan before dereferencing it. Fixes: f6efc675c9dd ("net: ppp: resolve forwarding path for bridge pppoe devices") Signed-off-by: Qingfang Deng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jialin Wang <[email protected]> Date: Fri Aug 8 00:54:55 2025 +0800 proc: proc_maps_open allow proc_mem_open to return NULL commit c0e1b774f68bdbea1618e356e30672c7f1e32509 upstream. The commit 65c66047259f ("proc: fix the issue of proc_mem_open returning NULL") caused proc_maps_open() to return -ESRCH when proc_mem_open() returns NULL. This breaks legitimate /proc/<pid>/maps access for kernel threads since kernel threads have NULL mm_struct. The regression causes perf to fail and exit when profiling a kernel thread: # perf record -v -g -p $(pgrep kswapd0) ... couldn't open /proc/65/task/65/maps This patch partially reverts the commit to fix it. Link: https://lkml.kernel.org/r/[email protected] Fixes: 65c66047259f ("proc: fix the issue of proc_mem_open returning NULL") Signed-off-by: Jialin Wang <[email protected]> Cc: Penglei Jiang <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Laurentiu Mihalcea <[email protected]> Date: Mon Jul 28 15:41:44 2025 -0400 pwm: imx-tpm: Reset counter if CMOD is 0 commit 65c6f742ab14ab1a2679fba72b82dcc0289d96f1 upstream. As per the i.MX93 TRM, section 67.3.2.1 "MOD register update", the value of the TPM counter does NOT get updated when writing MOD.MOD unless SC.CMOD != 0. Therefore, with the current code, assuming the following sequence: 1) pwm_disable() 2) pwm_apply_might_sleep() /* period is changed here */ 3) pwm_enable() and assuming only one channel is active, if CNT.COUNT is higher than the MOD.MOD value written during the pwm_apply_might_sleep() call then, when re-enabling the PWM during pwm_enable(), the counter will end up resetting after UINT32_MAX - CNT.COUNT + MOD.MOD cycles instead of MOD.MOD cycles as normally expected. Fix this problem by forcing a reset of the TPM counter before MOD.MOD is written. Fixes: 738a1cfec2ed ("pwm: Add i.MX TPM PWM driver support") Cc: [email protected] Signed-off-by: Laurentiu Mihalcea <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Mon Jul 28 18:00:18 2025 +0200 pwm: mediatek: Fix duty and period setting commit f21d136caf8171f94159d975ea4620c164431bd9 upstream. The period generated by the hardware is (PWMDWIDTH + 1) << CLKDIV) / freq according to my tests with a signal analyser and also the documentation. The current algorithm doesn't consider the `+ 1` part and so configures slightly too high periods. The same issue exists for the duty cycle setting. So subtract 1 from both the register values for period and duty cycle. If period is 0, bail out, if duty_cycle is 0, just disable the PWM which results in a constant low output. Fixes: caf065f8fd58 ("pwm: Add MediaTek PWM support") Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/6d1fa87a76f8020bfe3171529b8e19baffceab10.1753717973.git.u.kleine-koenig@baylibre.com Cc: [email protected] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Mon Jul 28 18:00:17 2025 +0200 pwm: mediatek: Handle hardware enable and clock enable separately commit 704d918341c378c5f9505dfdf32d315e256d3846 upstream. Stop handling the clocks in pwm_mediatek_enable() and pwm_mediatek_disable(). This is a preparing change for the next commit that requires that clocks and the enable bit are handled separately. Also move these two functions a bit further up in the source file to make them usable in pwm_mediatek_config(), which is needed in the next commit, too. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/55c94fe2917ece152ee1e998f4675642a7716f13.1753717973.git.u.kleine-koenig@baylibre.com Cc: [email protected] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kalesh AP <[email protected]> Date: Tue Aug 5 15:39:59 2025 +0530 RDMA/bnxt_re: Fix a possible memory leak in the driver [ Upstream commit ba60a1e8cbbd396c69ff9c8bc3242f5ab133e38a ] The GID context reuse logic requires the context memory to be not freed if and when DEL_GID firmware command fails. But, if there's no subsequent ADD_GID to reuse it, the context memory must be freed when the driver is unloaded. Otherwise it leads to a memory leak. Below is the kmemleak trace reported: unreferenced object 0xffff88817a4f34d0 (size 8): comm "insmod", pid 1072504, jiffies 4402561550 hex dump (first 8 bytes): 01 00 00 00 00 00 00 00 ........ backtrace (crc ccaa009e): __kmalloc_cache_noprof+0x33e/0x400 0xffffffffc2db9d48 add_modify_gid+0x5e0/0xb60 [ib_core] __ib_cache_gid_add+0x213/0x350 [ib_core] update_gid+0xf2/0x180 [ib_core] enum_netdev_ipv4_ips+0x3f3/0x690 [ib_core] enum_all_gids_of_dev_cb+0x125/0x1b0 [ib_core] ib_enum_roce_netdev+0x14b/0x250 [ib_core] ib_cache_setup_one+0x2e5/0x540 [ib_core] ib_register_device+0x82c/0xf10 [ib_core] 0xffffffffc2df5ad9 0xffffffffc2da8b07 0xffffffffc2db174d auxiliary_bus_probe+0xa5/0x120 really_probe+0x1e4/0x850 __driver_probe_device+0x18f/0x3d0 Fixes: 4a62c5e9e2e1 ("RDMA/bnxt_re: Do not free the ctx_tbl entry if delete GID fails") Signed-off-by: Kalesh AP <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Sriharsha Basavapatna <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kashyap Desai <[email protected]> Date: Tue Aug 5 15:39:57 2025 +0530 RDMA/bnxt_re: Fix to do SRQ armena by default [ Upstream commit 6296f9a5293ada28558f2867ac54c487e1e2b9f2 ] Whenever SRQ is created, make sure SRQ arm enable is always set. Driver is always ready to receive SRQ ASYNC event. Additional note - There is no need to do srq arm enable conditionally. See bnxt_qplib_armen_db in bnxt_qplib_create_cq(). Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters") Signed-off-by: Kashyap Desai <[email protected]> Signed-off-by: Saravanan Vajravel <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Kalesh AP <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Anantha Prabhu <[email protected]> Date: Tue Aug 5 15:40:00 2025 +0530 RDMA/bnxt_re: Fix to initialize the PBL array [ Upstream commit 806b9f494f62791ee6d68f515a8056c615a0e7b2 ] memset the PBL page pointer and page map arrays before populating the SGL addresses of the HWQ. Fixes: 0c4dcd602817 ("RDMA/bnxt_re: Refactor hardware queue memory allocation") Signed-off-by: Anantha Prabhu <[email protected]> Reviewed-by: Saravanan Vajravel <[email protected]> Reviewed-by: Selvin Xavier <[email protected]> Signed-off-by: Kalesh AP <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kashyap Desai <[email protected]> Date: Tue Aug 5 15:39:58 2025 +0530 RDMA/bnxt_re: Fix to remove workload check in SRQ limit path [ Upstream commit 666bce0bd7e771127cb0cda125cc9d32d9f9f15d ] There should not be any checks of current workload to set srq_limit value to SRQ hw context. Remove all such workload checks and make a direct call to set srq_limit via doorbell SRQ_ARM. Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters") Signed-off-by: Kashyap Desai <[email protected]> Signed-off-by: Saravanan Vajravel <[email protected]> Signed-off-by: Kalesh AP <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Akhilesh Patil <[email protected]> Date: Sun Aug 10 23:21:58 2025 +0530 RDMA/core: Free pfn_list with appropriate kvfree call [ Upstream commit 111aea0464c20f3eb25a48d5ff6c036e6b416123 ] Ensure that pfn_list allocated by kvcalloc() is freed using corresponding kvfree() function. Match memory allocation and free routines kvcalloc -> kvfree. Fixes: 259e9bd07c57 ("RDMA/core: Avoid hmm_dma_map_alloc() for virtual DMA devices") Signed-off-by: Akhilesh Patil <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Boshi Yu <[email protected]> Date: Fri Jul 25 13:53:55 2025 +0800 RDMA/erdma: Fix ignored return value of init_kernel_qp [ Upstream commit d5c74713f0117d07f91eb48b10bc2ad44e23c9b9 ] The init_kernel_qp interface may fail. Check its return value and free related resources properly when it does. Fixes: 155055771704 ("RDMA/erdma: Add verbs implementation") Reviewed-by: Cheng Xu <[email protected]> Signed-off-by: Boshi Yu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Boshi Yu <[email protected]> Date: Fri Jul 25 13:53:56 2025 +0800 RDMA/erdma: Fix unset QPN of GSI QP [ Upstream commit d4ac86b47563c7895dae28658abd1879d266b2b4 ] The QPN of the GSI QP was not set, which may cause issues. Set the QPN to 1 when creating the GSI QP. Fixes: 999a0a2e9b87 ("RDMA/erdma: Support UD QPs and UD WRs") Reviewed-by: Cheng Xu <[email protected]> Signed-off-by: Boshi Yu <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Zhu Yanjun <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Junxian Huang <[email protected]> Date: Tue Aug 12 20:26:02 2025 +0800 RDMA/hns: Fix dip entries leak on devices newer than hip09 [ Upstream commit fa2e2d31ee3b7212079323b4b09201ef68af3a97 ] DIP algorithm is also supported on devices newer than hip09, so free dip entries too. Fixes: f91696f2f053 ("RDMA/hns: Support congestion control type selection according to the FW") Signed-off-by: Junxian Huang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: wenglianfa <[email protected]> Date: Sat Jul 26 15:53:45 2025 +0800 RDMA/hns: Fix querying wrong SCC context for DIP algorithm [ Upstream commit 085a1b42e52750769a3fa29d4da6c05ab56f18f8 ] When using DIP algorithm, all QPs establishing connections with the same destination IP share the same SCC, which is indexed by dip_idx, but dip_idx isn't necessarily equal to qpn. Therefore, dip_idx should be used to query SCC context instead of qpn. Fixes: 124a9fbe43aa ("RDMA/hns: Append SCC context to the raw dump of QPC") Signed-off-by: wenglianfa <[email protected]> Signed-off-by: Junxian Huang <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Zhu Yanjun <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhu Yanjun <[email protected]> Date: Fri Jul 25 18:31:04 2025 -0700 RDMA/rxe: Flush delayed SKBs while releasing RXE resources commit 3c3e9a9f2972b364e8c2cfbfdeb23c6d6be4f87f upstream. When skb packets are sent out, these skb packets still depends on the rxe resources, for example, QP, sk, when these packets are destroyed. If these rxe resources are released when the skb packets are destroyed, the call traces will appear. To avoid skb packets hang too long time in some network devices, a timestamp is added when these skb packets are created. If these skb packets hang too long time in network devices, these network devices can free these skb packets to release rxe resources. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=8425ccfb599521edb153 Tested-by: [email protected] Fixes: 1a633bdc8fd9 ("RDMA/rxe: Let destroy qp succeed with stuck packet") Signed-off-by: Zhu Yanjun <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chi Zhiling <[email protected]> Date: Thu Jun 5 13:49:35 2025 +0800 readahead: fix return value of page_cache_next_miss() when no hole is found commit bbcaee20e03ecaeeecba32a703816a0d4502b6c4 upstream. max_scan in page_cache_next_miss always decreases to zero when no hole is found, causing the return value to be index + 0. Fix this by preserving the max_scan value throughout the loop. Jan said "From what I know and have seen in the past, wrong responses from page_cache_next_miss() can lead to readahead window reduction and thus reduced read speeds." Link: https://lkml.kernel.org/r/[email protected] Fixes: 901a269ff3d5 ("filemap: fix page_cache_next_miss() when no hole found") Signed-off-by: Chi Zhiling <[email protected]> Reviewed-by: Jan Kara <[email protected]> Cc: Josef Bacik <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Peng Fan <[email protected]> Date: Fri Aug 15 12:52:09 2025 +0800 regulator: pca9450: Use devm_register_sys_off_handler [ Upstream commit 447be50598c05499f7ccc2b1f6ddb3da30f8099a ] With module test, there is error dump: ------------[ cut here ]------------ notifier callback pca9450_i2c_restart_handler already registered WARNING: kernel/notifier.c:23 at notifier_chain_register+0x5c/0x88, CPU#0: kworker/u16:3/50 Call trace: notifier_chain_register+0x5c/0x88 (P) atomic_notifier_chain_register+0x30/0x58 register_restart_handler+0x1c/0x28 pca9450_i2c_probe+0x418/0x538 i2c_device_probe+0x220/0x3d0 really_probe+0x114/0x410 __driver_probe_device+0xa0/0x150 driver_probe_device+0x40/0x114 __device_attach_driver+0xd4/0x12c So use devm_register_sys_off_handler to let kernel handle the resource free to avoid kernel dump. Fixes: 6157e62b07d9 ("regulator: pca9450: Add restart handler") Signed-off-by: Peng Fan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Tue Aug 19 12:40:41 2025 +0300 regulator: tps65219: regulator: tps65219: Fix error codes in probe() [ Upstream commit 11cd7a5c21db020b8001aedcae27bd3fa9e1e901 ] There is a copy and paste error and we accidentally use "PTR_ERR(rdev)" instead of "error". The "rdev" pointer is valid at this point. Also there is no need to print the error code in the error message because dev_err_probe() already prints that. So clean up the error message a bit. Fixes: 38c9f98db20a ("regulator: tps65219: Add support for TPS65215 Regulator IRQs") Signed-off-by: Dan Carpenter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Helge Deller <[email protected]> Date: Sat Aug 2 21:34:37 2025 +0200 Revert "vgacon: Add check for vc_origin address range in vgacon_scroll()" commit e4fc307d8e24f122402907ebf585248cad52841d upstream. This reverts commit 864f9963ec6b4b76d104d595ba28110b87158003. The patch is wrong as it checks vc_origin against vc_screenbuf, while in text mode it should compare against vga_vram_base. As such it broke VGA text scrolling, which can be reproduced like this: (1) boot a kernel that is configured to use text mode VGA-console (2) type commands: ls -l /usr/bin | less -S (3) scroll up/down with cursor-down/up keys Reported-by: Jari Ruusu <[email protected]> Cc: [email protected] Cc: Yi Yang <[email protected]> Cc: GONG Ruiqi <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Justin Lai <[email protected]> Date: Wed Aug 13 15:16:31 2025 +0800 rtase: Fix Rx descriptor CRC error bit definition [ Upstream commit 065c31f2c6915b38f45b1c817b31f41f62eaa774 ] The CRC error bit is located at bit 17 in the Rx descriptor, but the driver was incorrectly using bit 16. Fix it. Fixes: a36e9f5cfe9e ("rtase: Add support for a pci table in this module") Signed-off-by: Justin Lai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miguel Ojeda <[email protected]> Date: Sat Aug 16 22:42:15 2025 +0200 rust: alloc: fix `rusttest` by providing `Cmalloc::aligned_layout` too [ Upstream commit 0f580d5d3d9d9cd0953695cd32e43aac3a946338 ] Commit fde578c86281 ("rust: alloc: replace aligned_size() with Kmalloc::aligned_layout()") provides a public `aligned_layout` function in `Kamlloc`, but not in `Cmalloc`, and thus uses of it will trigger an error in `rusttest`. Such a user appeared in the following commit 22ab0641b939 ("rust: drm: ensure kmalloc() compatible Layout"): error[E0599]: no function or associated item named `aligned_layout` found for struct `alloc::allocator_test::Cmalloc` in the current scope --> rust/kernel/drm/device.rs:100:31 | 100 | let layout = Kmalloc::aligned_layout(Layout::new::<Self>()); | ^^^^^^^^^^^^^^ function or associated item not found in `Cmalloc` | ::: rust/kernel/alloc/allocator_test.rs:19:1 | 19 | pub struct Cmalloc; | ------------------ function or associated item `aligned_layout` not found for this struct Thus add an equivalent one for `Cmalloc`. Fixes: fde578c86281 ("rust: alloc: replace aligned_size() with Kmalloc::aligned_layout()") Signed-off-by: Miguel Ojeda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Danilo Krummrich <[email protected]> Date: Thu Jul 31 17:48:06 2025 +0200 rust: alloc: replace aligned_size() with Kmalloc::aligned_layout() [ Upstream commit fde578c86281f27b182680c7642836a0dbbd0be7 ] aligned_size() dates back to when Rust did support kmalloc() only, but is now used in ReallocFunc::call() and hence for all allocators. However, the additional padding applied by aligned_size() is only required by the kmalloc() allocator backend. Hence, replace aligned_size() with Kmalloc::aligned_layout() and use it for the affected allocators, i.e. kmalloc() and kvmalloc(), only. While at it, make Kmalloc::aligned_layout() public, such that Rust abstractions, which have to call subsystem specific kmalloc() based allocation primitives directly, can make use of it. Fixes: 8a799831fc63 ("rust: alloc: implement `ReallocFunc`") Reviewed-by: Alice Ryhl <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Remove `const` from Kmalloc::aligned_layout(). - Danilo ] Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Danilo Krummrich <[email protected]> Date: Thu Jul 31 17:48:09 2025 +0200 rust: drm: don't pass the address of drm::Device to drm_dev_put() [ Upstream commit 360077278ba62e81310080f075a1a3028e778ef9 ] In drm_dev_put() call in AlwaysRefCounted::dec_ref() we rely on struct drm_device to be the first field in drm::Device, whereas everywhere else we correctly obtain the address of the actual struct drm_device. Analogous to the from_drm_device() helper, provide the into_drm_device() helper in order to address this. Fixes: 1e4b8896c0f3 ("rust: drm: add device abstraction") Reviewed-by: Alice Ryhl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Danilo Krummrich <[email protected]> Date: Thu Jul 31 17:48:07 2025 +0200 rust: drm: ensure kmalloc() compatible Layout [ Upstream commit 22ab0641b939967f630d108e33a3582841ad6846 ] drm::Device is allocated through __drm_dev_alloc() (which uses kmalloc()) and the driver private data, <T as drm::Driver>::Data, is initialized in-place. Due to the order of fields in drm::Device pub struct Device<T: drm::Driver> { dev: Opaque<bindings::drm_device>, data: T::Data, } even with an arbitrary large alignment requirement of T::Data it can't happen that the size of Device is smaller than its alignment requirement. However, let's not rely on this subtle circumstance and create a proper kmalloc() compatible Layout. Fixes: 1e4b8896c0f3 ("rust: drm: add device abstraction") Reviewed-by: Alice Ryhl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Danilo Krummrich <[email protected]> Date: Thu Jul 31 17:48:08 2025 +0200 rust: drm: remove pin annotations from drm::Device [ Upstream commit 0c04a81c1d0214d5b2025f805ccec1ac37c96b08 ] The #[pin_data] and #[pin] annotations are not necessary for drm::Device, since we don't use any pin-init macros, but only __pinned_init() on the impl PinInit<T::Data, Error> argument of drm::Device::new(). Fixes: 1e4b8896c0f3 ("rust: drm: add device abstraction") Reviewed-by: Benno Lossin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miguel Ojeda <[email protected]> Date: Mon Aug 4 19:13:11 2025 +0200 rust: faux: fix C header link commit a5ba9ad417254c49ecf06ac5ab36ec4b12ee133f upstream. Starting with Rust 1.91.0 (expected 2025-10-30), `rustdoc` has improved some false negatives around intra-doc links [1], and it found a broken intra-doc link we currently have: error: unresolved link to `include/linux/device/faux.h` --> rust/kernel/faux.rs:7:17 | 7 | //! C header: [`include/linux/device/faux.h`] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ no item named `include/linux/device/faux.h` in scope | = help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]` = note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(rustdoc::broken_intra_doc_links)]` Our `srctree/` C header links are not intra-doc links, thus they need the link destination. Thus fix it. Cc: stable <[email protected]> Link: https://github.com/rust-lang/rust/pull/132748 [1] Fixes: 78418f300d39 ("rust/kernel: Add faux device bindings") Signed-off-by: Miguel Ojeda <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Peter Oberparleiter <[email protected]> Date: Thu Aug 21 14:35:40 2025 +0200 s390/hypfs: Avoid unnecessary ioctl registration in debugfs [ Upstream commit fec7bdfe7f8694a0c39e6c3ec026ff61ca1058b9 ] Currently, hypfs registers ioctl callbacks for all debugfs files, despite only one file requiring them. This leads to unintended exposure of unused interfaces to user space and can trigger side effects such as restricted access when kernel lockdown is enabled. Restrict ioctl registration to only those files that implement ioctl functionality to avoid interface clutter and unnecessary access restrictions. Tested-by: Mete Durlu <[email protected]> Reviewed-by: Vasily Gorbik <[email protected]> Fixes: 5496197f9b08 ("debugfs: Restrict debugfs when the kernel is locked down") Signed-off-by: Peter Oberparleiter <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Oberparleiter <[email protected]> Date: Thu Aug 21 15:12:37 2025 +0200 s390/hypfs: Enable limited access during lockdown [ Upstream commit 3868f910440c47cd5d158776be4ba4e2186beda7 ] When kernel lockdown is active, debugfs_locked_down() blocks access to hypfs files that register ioctl callbacks, even if the ioctl interface is not required for a function. This unnecessarily breaks userspace tools that only rely on read operations. Resolve this by registering a minimal set of file operations during lockdown, avoiding ioctl registration and preserving access for affected tooling. Note that this change restores hypfs functionality when lockdown is active from early boot (e.g. via lockdown=integrity kernel parameter), but does not apply to scenarios where lockdown is enabled dynamically while Linux is running. Tested-by: Mete Durlu <[email protected]> Reviewed-by: Vasily Gorbik <[email protected]> Fixes: 5496197f9b08 ("debugfs: Restrict debugfs when the kernel is locked down") Signed-off-by: Peter Oberparleiter <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Heiko Carstens <[email protected]> Date: Thu Aug 7 17:04:27 2025 +0200 s390/mm: Do not map lowcore with identity mapping [ Upstream commit 93f616ff870a1fb7e84d472cad0af651b18f9f87 ] Since the identity mapping is pinned to address zero the lowcore is always also mapped to address zero, this happens regardless of the relocate_lowcore command line option. If the option is specified the lowcore is mapped twice, instead of only once. This means that NULL pointer accesses will succeed instead of causing an exception (low address protection still applies, but covers only parts). To fix this never map the first two pages of physical memory with the identity mapping. Fixes: 32db401965f1 ("s390/mm: Pin identity mapping base to zero") Reviewed-by: Alexander Gordeev <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Oberparleiter <[email protected]> Date: Mon Aug 18 12:21:52 2025 +0200 s390/sclp: Fix SCCB present check commit 430fa71027b6ac9bb0ce5532b8d0676777d4219a upstream. Tracing code called by the SCLP interrupt handler contains early exits if the SCCB address associated with an interrupt is NULL. This check is performed after physical to virtual address translation. If the kernel identity mapping does not start at address zero, the resulting virtual address is never zero, so that the NULL checks won't work. Subsequently this may result in incorrect accesses to the first page of the identity mapping. Fix this by introducing a function that handles the NULL case before address translation. Fixes: ada1da31ce34 ("s390/sclp: sort out physical vs virtual pointers usage") Cc: [email protected] Reviewed-by: Alexander Gordeev <[email protected]> Signed-off-by: Peter Oberparleiter <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andrea Righi <[email protected]> Date: Tue Aug 5 10:59:11 2025 +0200 sched/ext: Fix invalid task state transitions on class switch commit ddf7233fcab6c247379d0928d46cc316ee122229 upstream. When enabling a sched_ext scheduler, we may trigger invalid task state transitions, resulting in warnings like the following (which can be easily reproduced by running the hotplug selftest in a loop): sched_ext: Invalid task state transition 0 -> 3 for fish[770] WARNING: CPU: 18 PID: 787 at kernel/sched/ext.c:3862 scx_set_task_state+0x7c/0xc0 ... RIP: 0010:scx_set_task_state+0x7c/0xc0 ... Call Trace: <TASK> scx_enable_task+0x11f/0x2e0 switching_to_scx+0x24/0x110 scx_enable.isra.0+0xd14/0x13d0 bpf_struct_ops_link_create+0x136/0x1a0 __sys_bpf+0x1edd/0x2c30 __x64_sys_bpf+0x21/0x30 do_syscall_64+0xbb/0x370 entry_SYSCALL_64_after_hwframe+0x77/0x7f This happens because we skip initialization for tasks that are already dead (with their usage counter set to zero), but we don't exclude them during the scheduling class transition phase. Fix this by also skipping dead tasks during class swiching, preventing invalid task state transitions. Fixes: a8532fac7b5d2 ("sched_ext: TASK_DEAD tasks must be switched into SCX on ops_enable") Cc: [email protected] # v6.12+ Signed-off-by: Andrea Righi <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Macpaul Lin <[email protected]> Date: Tue Jul 22 16:57:18 2025 +0800 scsi: dt-bindings: mediatek,ufs: Add ufs-disable-mcq flag for UFS host commit 794ff7a0a6e76af93c5ec09a49b86fe73373ca59 upstream. Add the 'mediatek,ufs-disable-mcq' property to the UFS device-tree bindings. This flag corresponds to the UFS_MTK_CAP_DISABLE_MCQ host capability recently introduced in the UFS host driver, allowing it to disable the Multiple Circular Queue (MCQ) feature when present. The binding schema has also been updated to resolve DTBS check errors. Cc: [email protected] Fixes: 46bd3e31d74b ("scsi: ufs: mediatek: Add UFS_MTK_CAP_DISABLE_MCQ") Signed-off-by: Macpaul Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Rob Herring (Arm) <[email protected]> Reviewed-by: Peter Wang <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ranjan Kumar <[email protected]> Date: Fri Aug 22 10:39:31 2025 -0400 scsi: mpi3mr: Drop unnecessary volatile from __iomem pointers [ Upstream commit 6853885b21cb1d7157cc14c9d30cc17141565bae ] The volatile qualifier is redundant for __iomem pointers. Cleaned up usage in mpi3mr_writeq() and sysif_regs pointer as per Upstream compliance. Signed-off-by: Ranjan Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: c91e140c82eb ("scsi: mpi3mr: Serialize admin queue BAR writes on 32-bit systems") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ranjan Kumar <[email protected]> Date: Sat Jun 28 01:15:36 2025 +0530 scsi: mpi3mr: Fix race between config read submit and interrupt completion commit e6327c4acf925bb6d6d387d76fc3bd94471e10d8 upstream. The "is_waiting" flag was updated after calling complete(), which could lead to a race where the waiting thread wakes up before the flag is cleared. This may cause a missed wakeup or stale state check. Reorder the operations to update "is_waiting" before signaling completion to ensure consistent state. Fixes: 824a156633df ("scsi: mpi3mr: Base driver code") Cc: [email protected] Co-developed-by: Chandrakanth Patil <[email protected]> Signed-off-by: Chandrakanth Patil <[email protected]> Signed-off-by: Ranjan Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ranjan Kumar <[email protected]> Date: Fri Aug 22 10:39:32 2025 -0400 scsi: mpi3mr: Serialize admin queue BAR writes on 32-bit systems [ Upstream commit c91e140c82eb58724c435f623702e51cc7896646 ] On 32-bit systems, 64-bit BAR writes to admin queue registers are performed as two 32-bit writes. Without locking, this can cause partial writes when accessed concurrently. Updated per-queue spinlocks is used to serialize these writes and prevent race conditions. Fixes: 824a156633df ("scsi: mpi3mr: Base driver code") Cc: [email protected] Signed-off-by: Ranjan Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed Aug 13 08:49:08 2025 +0300 scsi: qla4xxx: Prevent a potential error pointer dereference [ Upstream commit 9dcf111dd3e7ed5fce82bb108e3a3fc001c07225 ] The qla4xxx_get_ep_fwdb() function is supposed to return NULL on error, but qla4xxx_ep_connect() returns error pointers. Propagating the error pointers will lead to an Oops in the caller, so change the error pointers to NULL. Fixes: 13483730a13b ("[SCSI] qla4xxx: fix flash/ddb support") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Chris Leech <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bart Van Assche <[email protected]> Date: Fri Aug 15 08:58:23 2025 -0700 scsi: ufs: core: Fix IRQ lock inversion for the SCSI host lock [ Upstream commit eabcac808ca3ee9878223d4b49b750979029016b ] Commit 3c7ac40d7322 ("scsi: ufs: core: Delegate the interrupt service routine to a threaded IRQ handler") introduced an IRQ lock inversion issue. Fix this lock inversion by changing the spin_lock_irq() calls into spin_lock_irqsave() calls in code that can be called either from interrupt context or from thread context. This patch fixes the following lockdep complaint: WARNING: possible irq lock inversion dependency detected 6.12.30-android16-5-maybe-dirty-4k #1 Tainted: G W OE -------------------------------------------------------- kworker/u28:0/12 just changed the state of lock: ffffff881e29dd60 (&hba->clk_gating.lock){-...}-{2:2}, at: ufshcd_release_scsi_cmd+0x60/0x110 but this lock took another, HARDIRQ-unsafe lock in the past: (shost->host_lock){+.+.}-{2:2} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(shost->host_lock); local_irq_disable(); lock(&hba->clk_gating.lock); lock(shost->host_lock); <Interrupt> lock(&hba->clk_gating.lock); *** DEADLOCK *** 4 locks held by kworker/u28:0/12: #0: ffffff8800ac6158 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x1bc/0x65c #1: ffffffc085c93d70 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x1e4/0x65c #2: ffffff881e29c0e0 (&shost->scan_mutex){+.+.}-{3:3}, at: __scsi_add_device+0x74/0x120 #3: ffffff881960ea00 (&hwq->cq_lock){-...}-{2:2}, at: ufshcd_mcq_poll_cqe_lock+0x28/0x104 the shortest dependencies between 2nd lock and 1st lock: -> (shost->host_lock){+.+.}-{2:2} { HARDIRQ-ON-W at: lock_acquire+0x134/0x2b4 _raw_spin_lock+0x48/0x64 ufshcd_sl_intr+0x4c/0xa08 ufshcd_threaded_intr+0x70/0x12c irq_thread_fn+0x48/0xa8 irq_thread+0x130/0x1ec kthread+0x110/0x134 ret_from_fork+0x10/0x20 SOFTIRQ-ON-W at: lock_acquire+0x134/0x2b4 _raw_spin_lock+0x48/0x64 ufshcd_sl_intr+0x4c/0xa08 ufshcd_threaded_intr+0x70/0x12c irq_thread_fn+0x48/0xa8 irq_thread+0x130/0x1ec kthread+0x110/0x134 ret_from_fork+0x10/0x20 INITIAL USE at: lock_acquire+0x134/0x2b4 _raw_spin_lock+0x48/0x64 ufshcd_sl_intr+0x4c/0xa08 ufshcd_threaded_intr+0x70/0x12c irq_thread_fn+0x48/0xa8 irq_thread+0x130/0x1ec kthread+0x110/0x134 ret_from_fork+0x10/0x20 } ... key at: [<ffffffc085ba1a98>] scsi_host_alloc.__key+0x0/0x10 ... acquired at: _raw_spin_lock_irqsave+0x5c/0x80 __ufshcd_release+0x78/0x118 ufshcd_send_uic_cmd+0xe4/0x118 ufshcd_dme_set_attr+0x88/0x1c8 ufs_google_phy_initialization+0x68/0x418 [ufs] ufs_google_link_startup_notify+0x78/0x27c [ufs] ufshcd_link_startup+0x84/0x720 ufshcd_init+0xf3c/0x1330 ufshcd_pltfrm_init+0x728/0x7d8 ufs_google_probe+0x30/0x84 [ufs] platform_probe+0xa0/0xe0 really_probe+0x114/0x454 __driver_probe_device+0xa4/0x160 driver_probe_device+0x44/0x23c __driver_attach_async_helper+0x60/0xd4 async_run_entry_fn+0x4c/0x17c process_one_work+0x26c/0x65c worker_thread+0x33c/0x498 kthread+0x110/0x134 ret_from_fork+0x10/0x20 -> (&hba->clk_gating.lock){-...}-{2:2} { IN-HARDIRQ-W at: lock_acquire+0x134/0x2b4 _raw_spin_lock_irqsave+0x5c/0x80 ufshcd_release_scsi_cmd+0x60/0x110 ufshcd_compl_one_cqe+0x2c0/0x3f4 ufshcd_mcq_poll_cqe_lock+0xb0/0x104 ufs_google_mcq_intr+0x80/0xa0 [ufs] __handle_irq_event_percpu+0x104/0x32c handle_irq_event+0x40/0x9c handle_fasteoi_irq+0x170/0x2e8 generic_handle_domain_irq+0x58/0x80 gic_handle_irq+0x48/0x104 call_on_irq_stack+0x3c/0x50 do_interrupt_handler+0x7c/0xd8 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c _raw_spin_unlock_irqrestore+0x3c/0x6c debug_object_assert_init+0x16c/0x21c __mod_timer+0x4c/0x48c schedule_timeout+0xd4/0x16c io_schedule_timeout+0x48/0x70 do_wait_for_common+0x100/0x194 wait_for_completion_io_timeout+0x48/0x6c blk_execute_rq+0x124/0x17c scsi_execute_cmd+0x18c/0x3f8 scsi_probe_and_add_lun+0x204/0xd74 __scsi_add_device+0xbc/0x120 ufshcd_async_scan+0x80/0x3c0 async_run_entry_fn+0x4c/0x17c process_one_work+0x26c/0x65c worker_thread+0x33c/0x498 kthread+0x110/0x134 ret_from_fork+0x10/0x20 INITIAL USE at: lock_acquire+0x134/0x2b4 _raw_spin_lock_irqsave+0x5c/0x80 ufshcd_hold+0x34/0x14c ufshcd_send_uic_cmd+0x28/0x118 ufshcd_dme_set_attr+0x88/0x1c8 ufs_google_phy_initialization+0x68/0x418 [ufs] ufs_google_link_startup_notify+0x78/0x27c [ufs] ufshcd_link_startup+0x84/0x720 ufshcd_init+0xf3c/0x1330 ufshcd_pltfrm_init+0x728/0x7d8 ufs_google_probe+0x30/0x84 [ufs] platform_probe+0xa0/0xe0 really_probe+0x114/0x454 __driver_probe_device+0xa4/0x160 driver_probe_device+0x44/0x23c __driver_attach_async_helper+0x60/0xd4 async_run_entry_fn+0x4c/0x17c process_one_work+0x26c/0x65c worker_thread+0x33c/0x498 kthread+0x110/0x134 ret_from_fork+0x10/0x20 } ... key at: [<ffffffc085ba6fe8>] ufshcd_init.__key+0x0/0x10 ... acquired at: mark_lock+0x1c4/0x224 __lock_acquire+0x438/0x2e1c lock_acquire+0x134/0x2b4 _raw_spin_lock_irqsave+0x5c/0x80 ufshcd_release_scsi_cmd+0x60/0x110 ufshcd_compl_one_cqe+0x2c0/0x3f4 ufshcd_mcq_poll_cqe_lock+0xb0/0x104 ufs_google_mcq_intr+0x80/0xa0 [ufs] __handle_irq_event_percpu+0x104/0x32c handle_irq_event+0x40/0x9c handle_fasteoi_irq+0x170/0x2e8 generic_handle_domain_irq+0x58/0x80 gic_handle_irq+0x48/0x104 call_on_irq_stack+0x3c/0x50 do_interrupt_handler+0x7c/0xd8 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c _raw_spin_unlock_irqrestore+0x3c/0x6c debug_object_assert_init+0x16c/0x21c __mod_timer+0x4c/0x48c schedule_timeout+0xd4/0x16c io_schedule_timeout+0x48/0x70 do_wait_for_common+0x100/0x194 wait_for_completion_io_timeout+0x48/0x6c blk_execute_rq+0x124/0x17c scsi_execute_cmd+0x18c/0x3f8 scsi_probe_and_add_lun+0x204/0xd74 __scsi_add_device+0xbc/0x120 ufshcd_async_scan+0x80/0x3c0 async_run_entry_fn+0x4c/0x17c process_one_work+0x26c/0x65c worker_thread+0x33c/0x498 kthread+0x110/0x134 ret_from_fork+0x10/0x20 stack backtrace: CPU: 6 UID: 0 PID: 12 Comm: kworker/u28:0 Tainted: G W OE 6.12.30-android16-5-maybe-dirty-4k #1 ccd4020fe444bdf629efc3b86df6be920b8df7d0 Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Spacecraft board based on MALIBU (DT) Workqueue: async async_run_entry_fn Call trace: dump_backtrace+0xfc/0x17c show_stack+0x18/0x28 dump_stack_lvl+0x40/0xa0 dump_stack+0x18/0x24 print_irq_inversion_bug+0x2fc/0x304 mark_lock_irq+0x388/0x4fc mark_lock+0x1c4/0x224 __lock_acquire+0x438/0x2e1c lock_acquire+0x134/0x2b4 _raw_spin_lock_irqsave+0x5c/0x80 ufshcd_release_scsi_cmd+0x60/0x110 ufshcd_compl_one_cqe+0x2c0/0x3f4 ufshcd_mcq_poll_cqe_lock+0xb0/0x104 ufs_google_mcq_intr+0x80/0xa0 [ufs dd6f385554e109da094ab91d5f7be18625a2222a] __handle_irq_event_percpu+0x104/0x32c handle_irq_event+0x40/0x9c handle_fasteoi_irq+0x170/0x2e8 generic_handle_domain_irq+0x58/0x80 gic_handle_irq+0x48/0x104 call_on_irq_stack+0x3c/0x50 do_interrupt_handler+0x7c/0xd8 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c _raw_spin_unlock_irqrestore+0x3c/0x6c debug_object_assert_init+0x16c/0x21c __mod_timer+0x4c/0x48c schedule_timeout+0xd4/0x16c io_schedule_timeout+0x48/0x70 do_wait_for_common+0x100/0x194 wait_for_completion_io_timeout+0x48/0x6c blk_execute_rq+0x124/0x17c scsi_execute_cmd+0x18c/0x3f8 scsi_probe_and_add_lun+0x204/0xd74 __scsi_add_device+0xbc/0x120 ufshcd_async_scan+0x80/0x3c0 async_run_entry_fn+0x4c/0x17c process_one_work+0x26c/0x65c worker_thread+0x33c/0x498 kthread+0x110/0x134 ret_from_fork+0x10/0x20 Cc: Neil Armstrong <[email protected]> Cc: André Draszik <[email protected]> Reviewed-by: Peter Wang <[email protected]> Fixes: 3c7ac40d7322 ("scsi: ufs: core: Delegate the interrupt service routine to a threaded IRQ handler") Signed-off-by: Bart Van Assche <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bart Van Assche <[email protected]> Date: Fri Aug 15 08:58:24 2025 -0700 scsi: ufs: core: Remove WARN_ON_ONCE() call from ufshcd_uic_cmd_compl() [ Upstream commit e5203d89d59bfcbe1f348aa0d2dc4449a8ba644c ] The UIC completion interrupt may be disabled while an UIC command is being processed. When the UIC completion interrupt is reenabled, an UIC interrupt is triggered and the WARN_ON_ONCE(!cmd) statement is hit. Hence this patch that removes this kernel warning. Fixes: fcd8b0450a9a ("scsi: ufs: core: Make ufshcd_uic_cmd_compl() easier to analyze") Reviewed-by: Peter Wang <[email protected]> Signed-off-by: Bart Van Assche <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: André Draszik <[email protected]> Date: Mon Jul 7 18:05:27 2025 +0100 scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPE commit 01aad16c2257ab8ff33b152b972c9f2e1af47912 upstream. On Google gs101, the number of UTP transfer request slots (nutrs) is 32, and in this case the driver ends up programming the UTRL_NEXUS_TYPE incorrectly as 0. This is because the left hand side of the shift is 1, which is of type int, i.e. 31 bits wide. Shifting by more than that width results in undefined behaviour. Fix this by switching to the BIT() macro, which applies correct type casting as required. This ensures the correct value is written to UTRL_NEXUS_TYPE (0xffffffff on gs101), and it also fixes a UBSAN shift warning: UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21 shift exponent 32 is too large for 32-bit type 'int' For consistency, apply the same change to the nutmrs / UTMRL_NEXUS_TYPE write. Fixes: 55f4b1f73631 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos SoCs") Cc: [email protected] Signed-off-by: André Draszik <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Peter Griffin <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Adrian Hunter <[email protected]> Date: Wed Jul 23 19:58:50 2025 +0300 scsi: ufs: ufs-pci: Fix default runtime and system PM levels commit 6de7435e6b81fe52c0ab4c7e181f6b5decd18eb1 upstream. Intel MTL-like host controllers support auto-hibernate. Using auto-hibernate with manual (driver initiated) hibernate produces more complex operation. For example, the host controller will have to exit auto-hibernate simply to allow the driver to enter hibernate state manually. That is not recommended. The default rpm_lvl and spm_lvl is 3, which includes manual hibernate. Change the default values to 2, which does not. Note, to be simpler to backport to stable kernels, utilize the UFS PCI driver's ->late_init() call back. Recent commits have made it possible to set up a controller-specific default in the regular ->init() call back, but not all stable kernels have those changes. Fixes: 4049f7acef3e ("scsi: ufs: ufs-pci: Add support for Intel MTL") Cc: [email protected] Signed-off-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Archana Patni <[email protected]> Date: Wed Jul 23 19:58:49 2025 +0300 scsi: ufs: ufs-pci: Fix hibernate state transition for Intel MTL-like host controllers commit 4428ddea832cfdb63e476eb2e5c8feb5d36057fe upstream. UFSHCD core disables the UIC completion interrupt when issuing UIC hibernation commands, and re-enables it afterwards if it was enabled to start with, refer ufshcd_uic_pwr_ctrl(). For Intel MTL-like host controllers, accessing the register to re-enable the interrupt disrupts the state transition. Use hibern8_notify variant operation to disable the interrupt during the entire hibernation, thereby preventing the disruption. Fixes: 4049f7acef3e ("scsi: ufs: ufs-pci: Add support for Intel MTL") Cc: [email protected] Signed-off-by: Archana Patni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nitin Rawat <[email protected]> Date: Mon Aug 11 13:03:30 2025 +0530 scsi: ufs: ufs-qcom: Fix ESI null pointer dereference [ Upstream commit 6300d5c5438724c0876828da2f6e2c1a661871fc ] ESI/MSI is a performance optimization feature that provides dedicated interrupts per MCQ hardware queue. This is optional feature and UFS MCQ should work with and without ESI feature. Commit e46a28cea29a ("scsi: ufs: qcom: Remove the MSI descriptor abuse") brings a regression in ESI (Enhanced System Interrupt) configuration that causes a null pointer dereference when Platform MSI allocation fails. The issue occurs in when platform_device_msi_init_and_alloc_irqs() in ufs_qcom_config_esi() fails (returns -EINVAL) but the current code uses __free() macro for automatic cleanup free MSI resources that were never successfully allocated. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: mutex_lock+0xc/0x54 (P) platform_device_msi_free_irqs_all+0x1c/0x40 ufs_qcom_config_esi+0x1d0/0x220 [ufs_qcom] ufshcd_config_mcq+0x28/0x104 ufshcd_init+0xa3c/0xf40 ufshcd_pltfrm_init+0x504/0x7d4 ufs_qcom_probe+0x20/0x58 [ufs_qcom] Fix by restructuring the ESI configuration to try MSI allocation first, before any other resource allocation and instead use explicit cleanup instead of __free() macro to avoid cleanup of unallocated resources. Tested on SM8750 platform with MCQ enabled, both with and without Platform ESI support. Fixes: e46a28cea29a ("scsi: ufs: qcom: Remove the MSI descriptor abuse") Cc: Manivannan Sadhasivam <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: James Bottomley <[email protected]> Signed-off-by: Nitin Rawat <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bao D. Nguyen <[email protected]> Date: Mon Jul 14 13:23:34 2025 +0530 scsi: ufs: ufs-qcom: Update esi_vec_mask for HW major version >= 6 [ Upstream commit 7a9d5195a7f5871a4ad4e55fc567a2b3bee49a59 ] The MCQ feature and ESI are supported by all Qualcomm UFS controller versions 6 and above. Therefore, update the ESI vector mask in the UFS_MEM_CFG3 register for platforms with major version number of 6 or higher. Reviewed-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Bao D. Nguyen <[email protected]> Signed-off-by: Nitin Rawat <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: 6300d5c54387 ("scsi: ufs: ufs-qcom: Fix ESI null pointer dereference") Signed-off-by: Sasha Levin <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Fri Aug 15 19:28:25 2025 +0200 selftests: mptcp: connect: fix C23 extension warning commit 2eefbed30d46d5e68593baf6b52923e00e7678af upstream. GCC was complaining about the new label: mptcp_connect.c:187:2: warning: label followed by a declaration is a C23 extension [-Wc23-extensions] 187 | int err = getaddrinfo(node, service, hints, res); | ^ Simply declare 'err' before the label to avoid this warning. Fixes: a862771d1aa4 ("selftests: mptcp: use IPPROTO_MPTCP for getaddrinfo") Cc: [email protected] Reviewed-by: Geliang Tang <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20250815-net-mptcp-misc-fixes-6-17-rc2-v1-7-521fe9957892@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Fri Aug 15 19:28:21 2025 +0200 selftests: mptcp: pm: check flush doesn't reset limits commit 452690be7de2f91cc0de68cb9e95252875b33503 upstream. This modification is linked to the parent commit where the received ADD_ADDR limit was accidentally reset when the endpoints were flushed. To validate that, the test is now flushing endpoints after having set new limits, and before checking them. The 'Fixes' tag here below is the same as the one from the previous commit: this patch here is not fixing anything wrong in the selftests, but it validates the previous fix for an issue introduced by this commit ID. Fixes: 01cacb00b35c ("mptcp: add netlink-based PM") Cc: [email protected] Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20250815-net-mptcp-misc-fixes-6-17-rc2-v1-3-521fe9957892@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Fri Aug 15 19:28:26 2025 +0200 selftests: mptcp: sockopt: fix C23 extension warning commit 3259889fd3c0cc165b7e9ee375c789875dd32326 upstream. GCC was complaining about the new label: mptcp_inq.c:79:2: warning: label followed by a declaration is a C23 extension [-Wc23-extensions] 79 | int err = getaddrinfo(node, service, hints, res); | ^ mptcp_sockopt.c:166:2: warning: label followed by a declaration is a C23 extension [-Wc23-extensions] 166 | int err = getaddrinfo(node, service, hints, res); | ^ Simply declare 'err' before the label to avoid this warning. Fixes: dd367e81b79a ("selftests: mptcp: sockopt: use IPPROTO_MPTCP for getaddrinfo") Cc: [email protected] Reviewed-by: Geliang Tang <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20250815-net-mptcp-misc-fixes-6-17-rc2-v1-8-521fe9957892@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yunhui Cui <[email protected]> Date: Wed Jul 23 10:33:22 2025 +0800 serial: 8250: fix panic due to PSLVERR commit 7f8fdd4dbffc05982b96caf586f77a014b2a9353 upstream. When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70 Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") Link: https://lore.kernel.org/all/[email protected]/T/ Signed-off-by: Yunhui Cui <[email protected]> Reviewed-by: John Ogness <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ adapted to inline code structure without separate serial8250_initialize helper function ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Adrian Huang (Lenovo) <[email protected]> Date: Mon Aug 18 21:43:10 2025 +0800 signal: Fix memory leak for PIDFD_SELF* sentinels [ Upstream commit a2c1f82618b0b65f1ef615aa9cfdac8122537d69 ] Commit f08d0c3a7111 ("pidfd: add PIDFD_SELF* sentinels to refer to own thread/process") introduced a leak by acquiring a pid reference through get_task_pid(), which increments pid->count but never drops it with put_pid(). As a result, kmemleak reports unreferenced pid objects after running tools/testing/selftests/pidfd/pidfd_test, for example: unreferenced object 0xff1100206757a940 (size 160): comm "pidfd_test", pid 16965, jiffies 4294853028 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 fd 57 50 04 .............WP. 5e 44 00 00 00 00 00 00 18 de 34 17 01 00 11 ff ^D........4..... backtrace (crc cd8844d4): kmem_cache_alloc_noprof+0x2f4/0x3f0 alloc_pid+0x54/0x3d0 copy_process+0xd58/0x1740 kernel_clone+0x99/0x3b0 __do_sys_clone3+0xbe/0x100 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix this by calling put_pid() after do_pidfd_send_signal() returns. Fixes: f08d0c3a7111 ("pidfd: add PIDFD_SELF* sentinels to refer to own thread/process") Signed-off-by: Adrian Huang (Lenovo) <[email protected]> Link: https://lore.kernel.org/[email protected] Tested-by: Lorenzo Stoakes <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Metzmacher <[email protected]> Date: Tue Aug 12 18:45:46 2025 +0200 smb: server: split ksmbd_rdma_stop_listening() out of ksmbd_rdma_destroy() [ Upstream commit bac7b996d42e458a94578f4227795a0d4deef6fa ] We can't call destroy_workqueue(smb_direct_wq); before stop_sessions()! Otherwise already existing connections try to use smb_direct_wq as a NULL pointer. Cc: Namjae Jeon <[email protected]> Cc: Steve French <[email protected]> Cc: Tom Talpey <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Signed-off-by: Stefan Metzmacher <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jon Hunter <[email protected]> Date: Thu Jul 31 13:18:32 2025 +0100 soc/tegra: pmc: Ensure power-domains are in a known state commit b6bcbce3359619d05bf387d4f5cc3af63668dbaa upstream. After commit 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds on until late_initcall_sync") was applied, the Tegra210 Jetson TX1 board failed to boot. Looking into this issue, before this commit was applied, if any of the Tegra power-domains were in 'on' state when the kernel booted, they were being turned off by the genpd core before any driver had chance to request them. This was purely by luck and a consequence of the power-domains being turned off earlier during boot. After this commit was applied, any power-domains in the 'on' state are kept on for longer during boot and therefore, may never transitioned to the off state before they are requested/used. The hang on the Tegra210 Jetson TX1 is caused because devices in some power-domains are accessed without the power-domain being turned off and on, indicating that the power-domain is not in a completely on state. >From reviewing the Tegra PMC driver code, if a power-domain is in the 'on' state there is no guarantee that all the necessary clocks associated with the power-domain are on and even if they are they would not have been requested via the clock framework and so could be turned off later. Some power-domains also have a 'clamping' register that needs to be configured as well. In short, if a power-domain is already 'on' it is difficult to know if it has been configured correctly. Given that the power-domains happened to be switched off during boot previously, to ensure that they are in a good known state on boot, fix this by switching off any power-domains that are on initially when registering the power-domains with the genpd framework. Note that commit 05cfb988a4d0 ("soc/tegra: pmc: Initialise resets associated with a power partition") updated the tegra_powergate_of_get_resets() function to pass the 'off' to ensure that the resets for the power-domain are in the correct state on boot. However, now that we may power off a domain on boot, if it is on, it is better to move this logic into the tegra_powergate_add() function so that there is a single place where we are handling the initial state of the power-domain. Fixes: a38045121bf4 ("soc/tegra: pmc: Add generic PM domain support") Signed-off-by: Jon Hunter <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bjorn Andersson <[email protected]> Date: Tue Jun 10 21:58:28 2025 -0500 soc: qcom: mdt_loader: Ensure we don't read past the ELF header commit 9f9967fed9d066ed3dae9372b45ffa4f6fccfeef upstream. When the MDT loader is used in remoteproc, the ELF header is sanitized beforehand, but that's not necessary the case for other clients. Validate the size of the firmware buffer to ensure that we don't read past the end as we iterate over the header. e_phentsize and e_shentsize are validated as well, to ensure that the assumptions about step size in the traversal are valid. Fixes: 2aad40d911ee ("remoteproc: Move qcom_mdt_loader into drivers/soc/qcom") Cc: [email protected] Reported-by: Doug Anderson <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/20250610-mdt-loader-validation-and-fixes-v2-1-f7073e9ab899@oss.qualcomm.com Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed Jun 25 10:22:41 2025 -0500 soc: qcom: mdt_loader: Fix error return values in mdt_header_valid() commit 9f35ab0e53ccbea57bb9cbad8065e0406d516195 upstream. This function is supposed to return true for valid headers and false for invalid. In a couple places it returns -EINVAL instead which means the invalid headers are counted as true. Change it to return false. Fixes: 9f9967fed9d0 ("soc: qcom: mdt_loader: Ensure we don't read past the ELF header") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Stefan Wahren <[email protected]> Date: Thu Aug 7 12:07:42 2025 +0200 spi: spi-fsl-lpspi: Clamp too high speed_hz [ Upstream commit af357a6a3b7d685e7aa621c6fb1d4ed6c349ec9e ] Currently the driver is not able to handle the case that a SPI device specifies a higher spi-max-frequency than half of per-clk: per-clk should be at least two times of transfer speed Fix this by clamping to the max possible value and use the minimum SCK period of 2 cycles. Fixes: 77736a98b859 ("spi: lpspi: add the error info of transfer speed setting") Signed-off-by: Stefan Wahren <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gabor Juhos <[email protected]> Date: Tue Aug 5 18:05:42 2025 +0200 spi: spi-qpic-snand: fix calculating of ECC OOB regions' properties [ Upstream commit 13d0fe84a214658254a7412b2b46ec1507dc51f0 ] The OOB layout used by the driver has two distinct regions which contains hardware specific ECC data, yet the qcom_spi_ooblayout_ecc() function sets the same offset and length values for both regions which is clearly wrong. Change the code to calculate the correct values for both regions. For reference, the following table shows the computed offset and length values for various OOB size/ECC strength configurations: +-----------------+-----------------+ |before the change| after the change| +-------+----------+--------+--------+--------+--------+--------+ | OOB | ECC | region | region | region | region | region | | size | strength | index | offset | length | offset | length | +-------+----------+--------+--------+--------+--------+--------+ | 128 | 8 | 0 | 113 | 15 | 0 | 49 | | | | 1 | 113 | 15 | 65 | 63 | +-------+----------+--------+--------+--------+--------+--------+ | 128 | 4 | 0 | 117 | 11 | 0 | 37 | | | | 1 | 117 | 11 | 53 | 75 | +-------+----------+--------+--------+--------+--------+--------+ | 64 | 4 | 0 | 53 | 11 | 0 | 37 | | | | 1 | 53 | 11 | 53 | 11 | +-------+----------+--------+--------+--------+--------+--------+ Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface") Signed-off-by: Gabor Juhos <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gabor Juhos <[email protected]> Date: Fri Aug 1 09:58:35 2025 +0200 spi: spi-qpic-snand: use correct CW_PER_PAGE value for OOB write [ Upstream commit 6bc829220b33da8522572cc50fdf5067c51d3bf3 ] The qcom_spi_program_oob() function uses only the last codeword to write the OOB data into the flash, but it sets the CW_PER_PAGE field in the CFG0 register as it would use all codewords. It seems that this confuses the hardware somehow, and any access to the flash fails with a timeout error after the function is called. The problem can be easily reproduced with the following commands: # dd if=/dev/zero bs=2176 count=1 > /tmp/test.bin 1+0 records in 1+0 records out # flash_erase /dev/mtd4 0 0 Erasing 128 Kibyte @ 0 -- 100 % complete # nandwrite -O /dev/mtd4 /tmp/test.bin Writing data to block 0 at offset 0x0 # nanddump -o /dev/mtd4 >/dev/null ECC failed: 0 ECC corrected: 0 Number of bad blocks: 0 Number of bbt blocks: 0 Block size 131072, page size 2048, OOB size 128 Dumping data starting at 0x00000000 and ending at 0x00020000... [ 33.197605] qcom_snand 79b0000.spi: failure to read oob libmtd: error!: MEMREADOOB64 ioctl failed for mtd4, offset 0 (eraseblock 0) error 110 (Operation timed out) [ 35.277582] qcom_snand 79b0000.spi: failure in submitting cmd descriptor libmtd: error!: cannot read 2048 bytes from mtd4 (eraseblock 0, offset 2048) error 110 (Operation timed out) nanddump: error!: mtd_read Change the code to use the correct CW_PER_PAGE value to avoid this. Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface") Signed-off-by: Gabor Juhos <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Phillip Lougher <[email protected]> Date: Mon Aug 11 23:37:40 2025 +0100 squashfs: fix memory leak in squashfs_fill_super commit b64700d41bdc4e9f82f1346c15a3678ebb91a89c upstream. If sb_min_blocksize returns 0, squashfs_fill_super exits without freeing allocated memory (sb->s_fs_info). Fix this by moving the call to sb_min_blocksize to before memory is allocated. Link: https://lkml.kernel.org/r/[email protected] Fixes: 734aa85390ea ("Squashfs: check return result of sb_min_blocksize") Signed-off-by: Phillip Lougher <[email protected]> Reported-by: Scott GUO <[email protected]> Closes: https://lore.kernel.org/all/[email protected] Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Tue Aug 19 19:19:51 2025 -0700 tls: fix handling of zero-length records on the rx_list commit 62708b9452f8eb77513115b17c4f8d1a22ebf843 upstream. Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rx_list. Next recvmsg() will pick it up from there. Queuing the skb to rx_list after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length). Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rx_list, and it's zero length. Reported-by: Muhammad Alifa Ramdhan <[email protected]> Reported-by: Billy Jheng Bing-Jhong <[email protected]> Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser") Reviewed-by: Sabrina Dubroca <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Masami Hiramatsu (Google) <[email protected]> Date: Sat Aug 16 23:10:51 2025 +0900 tracing: fprobe-event: Sanitize wildcard for fprobe event name commit ec879e1a0be8007aa232ffedcf6a6445dfc1a3d7 upstream. Fprobe event accepts wildcards for the target functions, but unless user specifies its event name, it makes an event with the wildcards. /sys/kernel/tracing # echo 'f mutex*' >> dynamic_events /sys/kernel/tracing # cat dynamic_events f:fprobes/mutex*__entry mutex* /sys/kernel/tracing # ls events/fprobes/ enable filter mutex*__entry To fix this, replace the wildcard ('*') with an underscore. Link: https://lore.kernel.org/all/175535345114.282990.12294108192847938710.stgit@devnote2/ Fixes: 334e5519c375 ("tracing/probes: Add fprobe events for tracing function entry and exit.") Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pu Lehui <[email protected]> Date: Sat Aug 23 21:01:36 2025 -0400 tracing: Limit access to parser->buffer when trace_get_user failed [ Upstream commit 6a909ea83f226803ea0e718f6e88613df9234d58 ] When the length of the string written to set_ftrace_filter exceeds FTRACE_BUFF_MAX, the following KASAN alarm will be triggered: BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165 CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0 The reason is that trace_get_user will fail when processing a string longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when trace_get_user failed. Cc: [email protected] Link: https://lore.kernel.org/[email protected] Fixes: 8c9af478c06b ("ftrace: Handle commands when closing set_ftrace_filter file") Signed-off-by: Pu Lehui <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Steven Rostedt <[email protected]> Date: Sat Aug 23 21:01:35 2025 -0400 tracing: Remove unneeded goto out logic [ Upstream commit c89504a703fb779052213add0e8ed642f4a4f1c8 ] Several places in the trace.c file there's a goto out where the out is simply a return. There's no reason to jump to the out label if it's not doing any more logic but simply returning from the function. Replace the goto outs with a return and remove the out labels. Cc: Masami Hiramatsu <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Andrew Morton <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Steven Rostedt (Google) <[email protected]> Stable-dep-of: 6a909ea83f22 ("tracing: Limit access to parser->buffer when trace_get_user failed") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Tue Jul 22 12:11:18 2025 -0700 usb: atm: cxacru: Merge cxacru_upload_firmware() into cxacru_heavy_init() commit 8d1b02e5d7e3a6d2acffb1f4c094678fda9e3456 upstream. After a recent change in clang to expose uninitialized warnings from const variables [1], there is a warning in cxacru_heavy_init(): drivers/usb/atm/cxacru.c:1104:6: error: variable 'bp' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] 1104 | if (instance->modem_type->boot_rom_patch) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/usb/atm/cxacru.c:1113:39: note: uninitialized use occurs here 1113 | cxacru_upload_firmware(instance, fw, bp); | ^~ drivers/usb/atm/cxacru.c:1104:2: note: remove the 'if' if its condition is always true 1104 | if (instance->modem_type->boot_rom_patch) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/usb/atm/cxacru.c:1095:32: note: initialize the variable 'bp' to silence this warning 1095 | const struct firmware *fw, *bp; | ^ | = NULL While the warning is technically correct that bp is conditionally passed uninitialized to cxacru_upload_firmware(), it is ultimately a false positive warning on the uninitialized use of bp because the same condition that initializes bp, instance->modem_type->boot_rom_patch, is the same one that gates the use of bp within cxacru_upload_firmware(). As this warning occurs in clang's frontend before inlining occurs, it cannot know that these conditions are indentical to avoid the warning. Manually inline cxacru_upload_firmware() into cxacru_heavy_init(), as that is its only callsite, so that clang can see that bp is initialized and used under the same condition, clearing up the warning without any functional changes to the code (LLVM was already doing this inlining later). Cc: [email protected] Fixes: 1b0e61465234 ("[PATCH] USB ATM: driver for the Conexant AccessRunner chipset cxacru") Closes: https://github.com/ClangBuiltLinux/linux/issues/2102 Link: https://github.com/llvm/llvm-project/commit/2464313eef01c5b1edf0eccf57a32cdee01472c7 [1] Signed-off-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/20250722-usb-cxacru-fix-clang-21-uninit-warning-v2-1-6708a18decd2@kernel.org Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xu Yang <[email protected]> Date: Wed Aug 6 16:39:55 2025 +0800 usb: core: hcd: fix accessing unmapped memory in SINGLE_STEP_SET_FEATURE test commit 8fe06185e11ae753414aa6117f0e798aa77567ff upstream. The USB core will unmap urb->transfer_dma after SETUP stage completes. Then the USB controller will access unmapped memory when it received device descriptor. If iommu is equipped, the entire test can't be completed due to the memory accessing is blocked. Fix it by calling map_urb_for_dma() again for IN stage. To reduce redundant map for urb->transfer_buffer, this will also set URB_NO_TRANSFER_DMA_MAP flag before first map_urb_for_dma() to skip dma map for urb->transfer_buffer and clear URB_NO_TRANSFER_DMA_MAP flag before second map_urb_for_dma(). Fixes: 216e0e563d81 ("usb: core: hcd: use map_urb_for_dma for single step set feature urb") Cc: stable <[email protected]> Reviewed-by: Jun Li <[email protected]> Signed-off-by: Xu Yang <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kuen-Han Tsai <[email protected]> Date: Thu Aug 7 17:06:55 2025 +0800 usb: dwc3: Ignore late xferNotReady event to prevent halt timeout commit 58577118cc7cec9eb7c1836bf88f865ff2c5e3a3 upstream. During a device-initiated disconnect, the End Transfer command resets the event filter, allowing a new xferNotReady event to be generated before the controller is fully halted. Processing this late event incorrectly triggers a Start Transfer, which prevents the controller from halting and results in a DSTS.DEVCTLHLT bit polling timeout. Ignore the late xferNotReady event if the controller is already in a disconnected state. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable <[email protected]> Signed-off-by: Kuen-Han Tsai <[email protected]> Acked-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Thu Jul 24 11:19:06 2025 +0200 usb: dwc3: imx8mp: fix device leak at unbind commit 086a0e516f7b3844e6328a5c69e2708b66b0ce18 upstream. Make sure to drop the reference to the dwc3 device taken by of_find_device_by_node() on probe errors and on driver unbind. Fixes: 6dd2565989b4 ("usb: dwc3: add imx8mp dwc3 glue layer driver") Cc: [email protected] # 5.12 Cc: Li Jun <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Thu Jul 24 11:19:07 2025 +0200 usb: dwc3: meson-g12a: fix device leaks at unbind commit 93b400f4951404d040197943a25d6fef9f8ccabb upstream. Make sure to drop the references taken to the child devices by of_find_device_by_node() during probe on driver unbind. Fixes: c99993376f72 ("usb: dwc3: Add Amlogic G12A DWC3 glue") Cc: [email protected] # 5.2 Cc: Neil Armstrong <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Martin Blumenstingl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Heikki Krogerus <[email protected]> Date: Tue Aug 12 16:11:00 2025 +0300 usb: dwc3: pci: add support for the Intel Wildcat Lake commit 86f390ba59cd8d5755bafe2b163c3e6b89d6bbd9 upstream. This patch adds the necessary PCI ID for Intel Wildcat Lake devices. Signed-off-by: Heikki Krogerus <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Selvarasu Ganesan <[email protected]> Date: Fri Aug 8 18:23:05 2025 +0530 usb: dwc3: Remove WARN_ON for device endpoint command timeouts commit 45eae113dccaf8e502090ecf5b3d9e9b805add6f upstream. This commit addresses a rarely observed endpoint command timeout which causes kernel panic due to warn when 'panic_on_warn' is enabled and unnecessary call trace prints when 'panic_on_warn' is disabled. It is seen during fast software-controlled connect/disconnect testcases. The following is one such endpoint command timeout that we observed: 1. Connect ======= ->dwc3_thread_interrupt ->dwc3_ep0_interrupt ->configfs_composite_setup ->composite_setup ->usb_ep_queue ->dwc3_gadget_ep0_queue ->__dwc3_gadget_ep0_queue ->__dwc3_ep0_do_control_data ->dwc3_send_gadget_ep_cmd 2. Disconnect ========== ->dwc3_thread_interrupt ->dwc3_gadget_disconnect_interrupt ->dwc3_ep0_reset_state ->dwc3_ep0_end_control_data ->dwc3_send_gadget_ep_cmd In the issue scenario, in Exynos platforms, we observed that control transfers for the previous connect have not yet been completed and end transfer command sent as a part of the disconnect sequence and processing of USB_ENDPOINT_HALT feature request from the host timeout. This maybe an expected scenario since the controller is processing EP commands sent as a part of the previous connect. It maybe better to remove WARN_ON in all places where device endpoint commands are sent to avoid unnecessary kernel panic due to warn. Cc: stable <[email protected]> Co-developed-by: Akash M <[email protected]> Signed-off-by: Akash M <[email protected]> Signed-off-by: Selvarasu Ganesan <[email protected]> Acked-by: Thinh Nguyen <[email protected]> Reviewed-by: Sebastian Andrzej Siewior <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Thu Jul 24 11:19:08 2025 +0200 usb: gadget: udc: renesas_usb3: fix device leak at unbind commit 868837b0a94c6b1b1fdbc04d3ba218ca83432393 upstream. Make sure to drop the reference to the companion device taken during probe when the driver is unbound. Fixes: 39facfa01c9f ("usb: gadget: udc: renesas_usb3: Add register of usb role switch") Cc: [email protected] # 4.19 Cc: Yoshihiro Shimoda <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Thu Jul 24 11:19:09 2025 +0200 usb: musb: omap2430: fix device leak at unbind commit 1473e9e7679bd4f5a62d1abccae894fb86de280f upstream. Make sure to drop the reference to the control device taken by of_find_device_by_node() during probe when the driver is unbound. Fixes: 8934d3e4d0e7 ("usb: musb: omap2430: Don't use omap_get_control_dev()") Cc: [email protected] # 3.13 Cc: Roger Quadros <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miao Li <[email protected]> Date: Fri Aug 1 16:27:28 2025 +0800 usb: quirks: Add DELAY_INIT quick for another SanDisk 3.2Gen1 Flash Drive commit e664036cf36480414936cd91f4cfa2179a3d8367 upstream. Another SanDisk 3.2Gen1 Flash Drive also need DELAY_INIT quick, or it will randomly work incorrectly on Huawei hisi platforms when doing reboot test. Signed-off-by: Miao Li <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marek Vasut <[email protected]> Date: Sun Aug 3 00:55:20 2025 +0200 usb: renesas-xhci: Fix External ROM access timeouts commit f9420f4757752f056144896024d5ea89e5a611f1 upstream. Increase the External ROM access timeouts to prevent failures during programming of External SPI EEPROM chips. The current timeouts are too short for some SPI EEPROMs used with uPD720201 controllers. The current timeout for Chip Erase in renesas_rom_erase() is 100 ms , the current timeout for Sector Erase issued by the controller before Page Program in renesas_fw_download_image() is also 100 ms. Neither timeout is sufficient for e.g. the Macronix MX25L5121E or MX25V5126F. MX25L5121E reference manual [1] page 35 section "ERASE AND PROGRAMMING PERFORMANCE" and page 23 section "Table 8. AC CHARACTERISTICS (Temperature = 0°C to 70°C for Commercial grade, VCC = 2.7V ~ 3.6V)" row "tCE" indicate that the maximum time required for Chip Erase opcode to complete is 2 s, and for Sector Erase it is 300 ms . MX25V5126F reference manual [2] page 47 section "13. ERASE AND PROGRAMMING PERFORMANCE (2.3V - 3.6V)" and page 42 section "Table 8. AC CHARACTERISTICS (Temperature = -40°C to 85°C for Industrial grade, VCC = 2.3V - 3.6V)" row "tCE" indicate that the maximum time required for Chip Erase opcode to complete is 3.2 s, and for Sector Erase it is 400 ms . Update the timeouts such, that Chip Erase timeout is set to 5 seconds, and Sector Erase timeout is set to 500 ms. Such lengthy timeouts ought to be sufficient for majority of SPI EEPROM chips. [1] https://www.macronix.com/Lists/Datasheet/Attachments/8634/MX25L5121E,%203V,%20512Kb,%20v1.3.pdf [2] https://www.macronix.com/Lists/Datasheet/Attachments/8750/MX25V5126F,%202.5V,%20512Kb,%20v1.1.pdf Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") Cc: stable <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mael GUERIN <[email protected]> Date: Wed Aug 6 18:44:03 2025 +0200 USB: storage: Add unusual-devs entry for Novatek NTK96550-based camera commit 6ca8af3c8fb584f3424a827f554ff74f898c27cd upstream. Add the US_FL_BULK_IGNORE_TAG quirk for Novatek NTK96550-based camera to fix USB resets after sending SCSI vendor commands due to CBW and CSW tags difference, leading to undesired slowness while communicating with the device. Please find below the copy of /sys/kernel/debug/usb/devices with my device plugged in (listed as TechSys USB mass storage here, the underlying chipset being the Novatek NTK96550-based camera): T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0603 ProdID=8611 Rev= 0.01 S: Manufacturer=TechSys S: Product=USB Mass Storage S: SerialNumber=966110000000100 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Mael GUERIN <[email protected]> Cc: stable <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zenm Chen <[email protected]> Date: Thu Aug 14 00:24:15 2025 +0800 USB: storage: Ignore driver CD mode for Realtek multi-mode Wi-Fi dongles commit a3dc32c635bae0ae569f489e00de0e8f015bfc25 upstream. Many Realtek USB Wi-Fi dongles released in recent years have two modes: one is driver CD mode which has Windows driver onboard, another one is Wi-Fi mode. Add the US_FL_IGNORE_DEVICE quirk for these multi-mode devices. Otherwise, usb_modeswitch may fail to switch them to Wi-Fi mode. Currently there are only two USB IDs known to be used by these multi-mode Wi-Fi dongles: 0bda:1a2b and 0bda:a192. Information about Mercury MW310UH in /sys/kernel/debug/usb/devices. T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 12 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=a192 Rev= 2.00 S: Manufacturer=Realtek S: Product=DISK C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none) E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Information about D-Link AX9U rev. A1 in /sys/kernel/debug/usb/devices. T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 55 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=1a2b Rev= 0.00 S: Manufacturer=Realtek S: Product=DISK C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable <[email protected]> Signed-off-by: Zenm Chen <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Wed Aug 13 16:52:49 2025 +0200 usb: storage: realtek_cr: Use correct byte order for bcs->Residue commit 98da66a70ad2396e5a508c4245367797ebc052ce upstream. Since 'bcs->Residue' has the data type '__le32', convert it to the correct byte order of the CPU using this driver when assigning it to the local variable 'residue'. Cc: stable <[email protected]> Fixes: 50a6cb932d5c ("USB: usb_storage: add ums-realtek driver") Suggested-by: Alan Stern <[email protected]> Acked-by: Alan Stern <[email protected]> Signed-off-by: Thorsten Blum <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Amit Sunil Dhamne <[email protected]> Date: Fri Aug 15 11:31:51 2025 -0700 usb: typec: maxim_contaminant: disable low power mode when reading comparator values commit cabb6c5f4d9e7f49bdf8c0a13c74bd93ee35f45a upstream. Low power mode is enabled when reading CC resistance as part of `max_contaminant_read_resistance_kohm()` and left in that state. However, it's supposed to work with 1uA current source. To read CC comparator values current source is changed to 80uA. This causes a storm of CC interrupts as it (falsely) detects a potential contaminant. To prevent this, disable low power mode current sourcing before reading comparator values. Fixes: 02b332a06397 ("usb: typec: maxim_contaminant: Implement check_contaminant callback") Cc: stable <[email protected]> Signed-off-by: Amit Sunil Dhamne <[email protected]> Reviewed-by: Badhri Jagan Sridharan <[email protected]> Link: https://lore.kernel.org/stable/20250814-fix-upstream-contaminant-v1-1-801ce8089031%40google.com Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Amit Sunil Dhamne <[email protected]> Date: Fri Aug 15 11:31:52 2025 -0700 usb: typec: maxim_contaminant: re-enable cc toggle if cc is open and port is clean commit a381c6d6f646226924809d0ad01a9465786da463 upstream. Presently in `max_contaminant_is_contaminant()` if there's no contaminant detected previously, CC is open & stopped toggling and no contaminant is currently present, TCPC.RC would be programmed to do DRP toggling. However, it didn't actively look for a connection. This would lead to Type-C not detect *any* new connections. Hence, in the above situation, re-enable toggling & program TCPC to look for a new connection. Also, return early if TCPC was looking for connection as this indicates TCPC has neither detected a potential connection nor a change in contaminant state. In addition, once dry detection is complete (port is dry), restart toggling. Fixes: 02b332a06397e ("usb: typec: maxim_contaminant: Implement check_contaminant callback") Cc: stable <[email protected]> Signed-off-by: Amit Sunil Dhamne <[email protected]> Reviewed-by: Badhri Jagan Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Niklas Neronin <[email protected]> Date: Tue Aug 19 15:58:44 2025 +0300 usb: xhci: fix host not responding after suspend and resume commit ff9a09b3e09c7b794b56f2f5858f5ce42ba46cb3 upstream. Partially revert commit e1db856bd288 ("usb: xhci: remove '0' write to write-1-to-clear register") because the patch cleared the Interrupt Pending bit during interrupt enabling and disabling. The Interrupt Pending bit should only be cleared when the driver has handled the interrupt. Ideally, all interrupts should be handled before disabling the interrupt; consequently, no interrupt should be pending when enabling the interrupt. For this reason, keep the debug message informing if an interrupt is still pending when an interrupt is disabled. Because the Interrupt Pending bit is write-1-to-clear, writing '0' to it ensures that the state does not change. Link: https://lore.kernel.org/linux-usb/20250818231103.672ec7ed@foxbook Fixes: e1db856bd288 ("usb: xhci: remove '0' write to write-1-to-clear register") Closes: https://bbs.archlinux.org/viewtopic.php?id=307641 cc: [email protected] # 6.16+ Signed-off-by: Niklas Neronin <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Weitao Wang <[email protected]> Date: Tue Aug 19 15:58:43 2025 +0300 usb: xhci: Fix slot_id resource race conflict commit 2eb03376151bb8585caa23ed2673583107bb5193 upstream. xHC controller may immediately reuse a slot_id after it's disabled, giving it to a new enumerating device before the xhci driver freed all resources related to the disabled device. In such a scenario, device-A with slot_id equal to 1 is disconnecting while device-B is enumerating, device-B will fail to enumerate in the follow sequence. 1.[device-A] send disable slot command 2.[device-B] send enable slot command 3.[device-A] disable slot command completed and wakeup waiting thread 4.[device-B] enable slot command completed with slot_id equal to 1 and wakeup waiting thread 5.[device-B] driver checks that slot_id is still in use (by device-A) in xhci_alloc_virt_device, and fail to enumerate due to this conflict 6.[device-A] xhci->devs[slot_id] set to NULL in xhci_free_virt_device To fix driver's slot_id resources conflict, clear xhci->devs[slot_id] and xhci->dcbba->dev_context_ptrs[slot_id] pointers in the interrupt context when disable slot command completes successfully. Simultaneously, adjust function xhci_free_virt_device to accurately handle device release. [minor smatch warning and commit message fix -Mathias] Cc: [email protected] Fixes: 7faac1953ed1 ("xhci: avoid race between disable slot command and host runtime suspend") Signed-off-by: Weitao Wang <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Al Viro <[email protected]> Date: Thu Aug 14 01:44:31 2025 -0400 use uniform permission checks for all mount propagation changes [ Upstream commit cffd0441872e7f6b1fce5e78fb1c99187a291330 ] do_change_type() and do_set_group() are operating on different aspects of the same thing - propagation graph. The latter asks for mounts involved to be mounted in namespace(s) the caller has CAP_SYS_ADMIN for. The former is a mess - originally it didn't even check that mount *is* mounted. That got fixed, but the resulting check turns out to be too strict for userland - in effect, we check that mount is in our namespace, having already checked that we have CAP_SYS_ADMIN there. What we really need (in both cases) is * only touch mounts that are mounted. That's a must-have constraint - data corruption happens if it get violated. * don't allow to mess with a namespace unless you already have enough permissions to do so (i.e. CAP_SYS_ADMIN in its userns). That's an equivalent of what do_set_group() does; let's extract that into a helper (may_change_propagation()) and use it in both do_set_group() and do_change_type(). Fixes: 12f147ddd6de "do_change_type(): refuse to operate on unmounted/not ours mounts" Acked-by: Andrei Vagin <[email protected]> Reviewed-by: Pavel Tikhomirov <[email protected]> Tested-by: Pavel Tikhomirov <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Al Viro <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Will Deacon <[email protected]> Date: Thu Jul 17 10:01:08 2025 +0100 vhost/vsock: Avoid allocating arbitrarily-sized SKBs commit 10a886aaed293c4db3417951f396827216299e3d upstream. vhost_vsock_alloc_skb() returns NULL for packets advertising a length larger than VIRTIO_VSOCK_MAX_PKT_BUF_SIZE in the packet header. However, this is only checked once the SKB has been allocated and, if the length in the packet header is zero, the SKB may not be freed immediately. Hoist the size check before the SKB allocation so that an iovec larger than VIRTIO_VSOCK_MAX_PKT_BUF_SIZE + the header size is rejected outright. The subsequent check on the length field in the header can then simply check that the allocated SKB is indeed large enough to hold the packet. Cc: <[email protected]> Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") Reviewed-by: Stefano Garzarella <[email protected]> Signed-off-by: Will Deacon <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Will Deacon <[email protected]> Date: Thu Jul 17 10:01:09 2025 +0100 vsock/virtio: Validate length in packet header before skb_put() commit 0dab92484474587b82e8e0455839eaf5ac7bf894 upstream. When receiving a vsock packet in the guest, only the virtqueue buffer size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately, virtio_vsock_skb_rx_put() uses the length from the packet header as the length argument to skb_put(), potentially resulting in SKB overflow if the host has gone wonky. Validate the length as advertised by the packet header before calling virtio_vsock_skb_rx_put(). Cc: <[email protected]> Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") Signed-off-by: Will Deacon <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Stefano Garzarella <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Myrrh Periwinkle <[email protected]> Date: Wed Jul 2 21:17:58 2025 +0700 vt: defkeymap: Map keycodes above 127 to K_HOLE commit b43cb4ff85da5cf29c4cd351ef1d7dd8210780f7 upstream. The maximum number of keycodes got bumped to 256 a very long time ago, but the default keymaps were never adjusted to match. This is causing the kernel to interpret keycodes above 127 as U+0000 if the shipped generated keymap is used. Fix this by mapping all keycodes above 127 to K_HOLE so the kernel ignores them. The contents of this patche were generated by rerunning `loadkeys --mktable --unicode` and only including the changes to map keycodes above 127 to K_HOLE. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Myrrh Periwinkle <[email protected]> Cc: stable <[email protected]> Reviewed-by: Jiri Slaby <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Myrrh Periwinkle <[email protected]> Date: Wed Jul 2 21:17:57 2025 +0700 vt: keyboard: Don't process Unicode characters in K_OFF mode commit b1cc2092ea7a52e2c435aee6d2b1bcb773202663 upstream. We don't process Unicode characters if the virtual terminal is in raw mode, so there's no reason why we shouldn't do the same for K_OFF (especially since people would expect K_OFF to actually turn off all VT key processing). Fixes: 9fc3de9c8356 ("vt: Add virtual console keyboard mode OFF") Signed-off-by: Myrrh Periwinkle <[email protected]> Cc: stable <[email protected]> Reviewed-by: Jiri Slaby <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Wed Jun 4 16:34:53 2025 +0200 wifi: ath11k: fix dest ring-buffer corruption commit 8c1ba5091fa9a2d1478da63173b16a701bdf86bb upstream. Add the missing memory barrier to make sure that destination ring descriptors are read after the head pointers to avoid using stale data on weakly ordered architectures like aarch64. The barrier is added to the ath11k_hal_srng_access_begin() helper for symmetry with follow-on fixes for source ring buffer corruption which will add barriers to ath11k_hal_srng_access_end(). Tested-on: WCN6855 hw2.1 WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Cc: [email protected] # 5.6 Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Wed Jun 4 16:34:57 2025 +0200 wifi: ath11k: fix dest ring-buffer corruption when ring is full commit aa6956150f820e6a6deba44be325ddfcb5b10f88 upstream. Add the missing memory barriers to make sure that destination ring descriptors are read before updating the tail pointer (and passing ownership to the device) to avoid memory corruption on weakly ordered architectures like aarch64 when the ring is full. Tested-on: WCN6855 hw2.1 WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Cc: [email protected] # 5.6 Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Wed Jun 4 16:34:56 2025 +0200 wifi: ath11k: fix source ring-buffer corruption commit 6efa0df54022c6c9fd4d294b87622c7fcdc418c8 upstream. Add the missing memory barrier to make sure that LMAC source ring descriptors are written before updating the head pointer to avoid passing stale data to the firmware on weakly ordered architectures like aarch64. Note that non-LMAC rings use MMIO write accessors which have the required write memory barrier. Tested-on: WCN6855 hw2.1 WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Cc: [email protected] # 5.6 Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Tue Jun 17 10:43:59 2025 +0200 wifi: ath12k: fix dest ring-buffer corruption commit 8157ce533a60521f21d466eb4de45d9735b19484 upstream. Add the missing memory barrier to make sure that destination ring descriptors are read after the head pointers to avoid using stale data on weakly ordered architectures like aarch64. The barrier is added to the ath12k_hal_srng_access_begin() helper for symmetry with follow-on fixes for source ring buffer corruption which will add barriers to ath12k_hal_srng_access_end(). Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Cc: [email protected] # 6.3 Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Tue Jun 17 10:44:02 2025 +0200 wifi: ath12k: fix dest ring-buffer corruption when ring is full commit ed32169be1ccb9b1a295275ba7746dc6bf103e80 upstream. Add the missing memory barriers to make sure that destination ring descriptors are read before updating the tail pointer (and passing ownership to the device) to avoid memory corruption on weakly ordered architectures like aarch64 when the ring is full. Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Cc: [email protected] # 6.3 Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Tue Jun 17 10:44:01 2025 +0200 wifi: ath12k: fix source ring-buffer corruption commit e834da4cbd6fe1d24f89368bf0c80adcad212726 upstream. Add the missing memory barrier to make sure that LMAC source ring descriptors are written before updating the head pointer to avoid passing stale data to the firmware on weakly ordered architectures like aarch64. Note that non-LMAC rings use MMIO write accessors which have the required write memory barrier. Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Cc: [email protected] # 6.3 Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Tue Jul 15 19:45:23 2025 -0700 wifi: brcmsmac: Remove const from tbl_ptr parameter in wlc_lcnphy_common_read_table() commit 81284e86bf8849f8e98e8ead3ff5811926b2107f upstream. A new warning in clang [1] complains that diq_start in wlc_lcnphy_tx_iqlo_cal() is passed uninitialized as a const pointer to wlc_lcnphy_common_read_table(): drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:2728:13: error: variable 'diq_start' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 2728 | &diq_start, 1, 16, 69); | ^~~~~~~~~ The table pointer passed to wlc_lcnphy_common_read_table() should not be considered constant, as wlc_phy_read_table() is ultimately going to update it. Remove the const qualifier from the tbl_ptr to clear up the warning. Cc: [email protected] Closes: https://github.com/ClangBuiltLinux/linux/issues/2108 Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers") Link: https://github.com/llvm/llvm-project/commit/00dacf8c22f065cb52efb14cd091d441f19b319e [1] Signed-off-by: Nathan Chancellor <[email protected]> Acked-by: Arend van Spriel <[email protected]>> Link: https://patch.msgid.link/20250715-brcmsmac-fix-uninit-const-pointer-v1-1-16e6a51a8ef4@kernel.org Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yazen Ghannam <[email protected]> Date: Mon Jul 21 18:11:54 2025 +0000 x86/CPU/AMD: Ignore invalid reset reason value commit e9576e078220c50ace9e9087355423de23e25fa5 upstream. The reset reason value may be "all bits set", e.g. 0xFFFFFFFF. This is a commonly used error response from hardware. This may occur due to a real hardware issue or when running in a VM. The user will see all reset reasons reported in this case. Check for an error response value and return early to avoid decoding invalid data. Also, adjust the data variable type to match the hardware register size. Fixes: ab8131028710 ("x86/CPU/AMD: Print the reason for the last reset") Reported-by: Libing He <[email protected]> Signed-off-by: Yazen Ghannam <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Mario Limonciello <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tianxiang Peng <[email protected]> Date: Mon Jun 23 17:31:53 2025 +0800 x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper commit d8df126349dad855cdfedd6bbf315bad2e901c2f upstream. Since 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot") resctrl_cpu_detect() has been moved from common CPU initialization code to the vendor-specific BSP init helper, while Hygon didn't put that call in their code. This triggers a division by zero fault during early booting stage on our machines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() tries to calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale. Add the missing resctrl_cpu_detect() in the Hygon BSP init helper. [ bp: Massage commit message. ] Fixes: 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot") Signed-off-by: Tianxiang Peng <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Hui Li <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Mon Aug 18 21:19:55 2025 -0400 xfs: decouple xfs_trans_alloc_empty from xfs_trans_alloc [ Upstream commit 83a80e95e797a2a6d14bf7983e5e6eecf8f5facb ] xfs_trans_alloc_empty only shares the very basic transaction structure allocation and initialization with xfs_trans_alloc. Split out a new __xfs_trans_alloc helper for that and otherwise decouple xfs_trans_alloc_empty from xfs_trans_alloc. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Stable-dep-of: d2845519b072 ("xfs: fully decouple XFS_IBULK* flags from XFS_IWALK* flags") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Thu Jul 31 07:19:41 2025 -0700 xfs: fix frozen file system assert in xfs_trans_alloc commit 647b3d59c768d7638dd17c78c8044178364383ca upstream. Commit 83a80e95e797 ("xfs: decouple xfs_trans_alloc_empty from xfs_trans_alloc") move the place of the assert for a frozen file system after the sb_start_intwrite call that ensures it doesn't run on frozen file systems, and thus allows to incorrect trigger it. Fix that by moving it back to where it belongs. Fixes: 83a80e95e797 ("xfs: decouple xfs_trans_alloc_empty from xfs_trans_alloc") Reported-by: Dave Chinner <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Mon Aug 18 21:19:58 2025 -0400 xfs: fully decouple XFS_IBULK* flags from XFS_IWALK* flags [ Upstream commit d2845519b0723c5d5a0266cbf410495f9b8fd65c ] Fix up xfs_inumbers to now pass in the XFS_IBULK* flags into the flags argument to xfs_inobt_walk, which expects the XFS_IWALK* flags. Currently passing the wrong flags works for non-debug builds because the only XFS_IWALK* flag has the same encoding as the corresponding XFS_IBULK* flag, but in debug builds it can trigger an assert that no incorrect flag is passed. Instead just extra the relevant flag. Fixes: 5b35d922c52798 ("xfs: Decouple XFS_IBULK flags from XFS_IWALK flags") Cc: <[email protected]> # v5.19 Reported-by: cen zhang <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Mon Aug 18 21:19:57 2025 -0400 xfs: improve the comments in xfs_select_zone_nowait [ Upstream commit 60e02f956d77af31b85ed4e73abf85d5f12d0a98 ] The top of the function comment is outdated, and the parts still correct duplicate information in comment inside the function. Remove the top of the function comment and instead improve a comment inside the function. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Stable-dep-of: d2845519b072 ("xfs: fully decouple XFS_IBULK* flags from XFS_IWALK* flags") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alan Huang <[email protected]> Date: Mon Aug 18 21:19:59 2025 -0400 xfs: Remove unused label in xfs_dax_notify_dev_failure [ Upstream commit 8c10b04f9fc1760cb79068073686d8866e59d40f ] Fixes: e967dc40d501 ("xfs: return the allocated transaction from xfs_trans_alloc_empty") Signed-off-by: Alan Huang <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Mon Aug 18 21:19:56 2025 -0400 xfs: return the allocated transaction from xfs_trans_alloc_empty [ Upstream commit d8e1ea43e5a314bc01ec059ce93396639dcf9112 ] xfs_trans_alloc_empty can't return errors, so return the allocated transaction directly instead of an output double pointer argument. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Stable-dep-of: d2845519b072 ("xfs: fully decouple XFS_IBULK* flags from XFS_IWALK* flags") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marek Szyprowski <[email protected]> Date: Mon Jun 16 14:09:32 2025 +0200 zynq_fpga: use sgtable-based scatterlist wrappers commit 37e00703228ab44d0aacc32a97809a4f6f58df1b upstream. Use common wrappers operating directly on the struct sg_table objects to fix incorrect use of statterlists related calls. dma_unmap_sg() function has to be called with the number of elements originally passed to the dma_map_sg() function, not the one returned in sgtable's nents. CC: [email protected] Fixes: 425902f5c8e3 ("fpga zynq: Use the scatterlist interface") Signed-off-by: Marek Szyprowski <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Xu Yilun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Xu Yilun <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>