commit e60eb441596d1c70e4a264d2bac726c6cd2da067 Author: Greg Kroah-Hartman Date: Fri Jun 27 11:13:43 2025 +0100 Linux 6.15.4 Link: https://lore.kernel.org/r/20250623130700.210182694@linuxfoundation.org Tested-by: Ronald Warsow Tested-By: Achill Gilgenast Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Luna Jernberg Tested-by: Salvatore Bonaccorso Tested-by: Mark Brown Tested-by: Takeshi Ogasawara Link: https://lore.kernel.org/r/20250624121449.136416081@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: Luna Jernberg Tested-by: Christian Heusel Tested-by: Jon Hunter Tested-by: Takeshi Ogasawara Tested-by: Justin M. Forbes Tested-by: Mark Brown Tested-by: Miguel Ojeda Link: https://lore.kernel.org/r/20250626105243.160967269@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Mark Brown Tested-by: Florian Fainelli Tested-by: Miguel Ojeda Tested-by: Linux Kernel Functional Testing Tested-by: Peter Schneider Tested-by: Jon Hunter Tested-by: Luna Jernberg Tested-by: Takeshi Ogasawara Signed-off-by: Greg Kroah-Hartman commit d93065ae57544f0eeed1017daf6b36db9708e609 Author: Dillon Varone Date: Fri Mar 28 12:56:39 2025 -0400 Revert "drm/amd/display: Fix VUpdate offset calculations for dcn401" commit 0fc9635a801f6ba3a03ad2de6d46f4f3e2fdfed6 upstream. This reverts commit fe45e2af4a22e569b35b7f45eb9f040f6fbef94f. Reason for revert: it causes stuttering in some usecases. Reviewed-by: Aric Cyr Signed-off-by: Dillon Varone Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b9c04994f96b1ecd6f1cae096e088d07265be74f Author: Gao Xiang Date: Fri Jun 20 23:31:08 2025 +0800 erofs: remove a superfluous check for encoded extents [ Upstream commit 417b8af2e30d7f131682a893ad79c506fd39c624 ] It is possible when an inode is split into segments for multi-threaded compression, and the tail extent of a segment could also be small. Fixes: 1d191b4ca51d ("erofs: implement encoded extent metadata") Signed-off-by: Gao Xiang Link: https://lore.kernel.org/r/20250620153108.1368029-1-hsiangkao@linux.alibaba.com Signed-off-by: Sasha Levin commit 9957279ce953e4dbaa8560a8b54e5dd6cc283983 Author: Gao Xiang Date: Thu Jun 19 11:28:39 2025 +0800 erofs: refuse crafted out-of-file-range encoded extents [ Upstream commit 7869738b6908eec7755818aaf6f3aa068b2f0e1b ] Crafted encoded extents could record out-of-range `lstart`, which should not happen in normal cases. It caused an iomap_iter_done() complaint [1] reported by syzbot. [1] https://lore.kernel.org/r/684cb499.a00a0220.c6bd7.0010.GAE@google.com Fixes: 1d191b4ca51d ("erofs: implement encoded extent metadata") Reported-and-tested-by: syzbot+d8f000c609f05f52d9b5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d8f000c609f05f52d9b5 Signed-off-by: Gao Xiang Link: https://lore.kernel.org/r/20250619032839.2642193-1-hsiangkao@linux.alibaba.com Signed-off-by: Sasha Levin commit fde255cc76ed3ec4b58e409cf545342e25366a6c Author: Pali Rohár Date: Sun Jun 8 16:10:33 2025 +0200 cifs: Remove duplicate fattr->cf_dtype assignment from wsl_to_fattr() function [ Upstream commit 840738eae94864993a735ab677b9795bb8f3b961 ] Commit 8bd25b61c5a5 ("smb: client: set correct d_type for reparse DFS/DFSR and mount point") deduplicated assignment of fattr->cf_dtype member from all places to end of the function cifs_reparse_point_to_fattr(). The only one missing place which was not deduplicated is wsl_to_fattr(). Fix it. Fixes: 8bd25b61c5a5 ("smb: client: set correct d_type for reparse DFS/DFSR and mount point") Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 088f8ae33c0de26fc13ff74e28f67396bb0e8324 Author: Lukas Wunner Date: Wed Jun 18 16:38:25 2025 +0200 PCI: pciehp: Ignore belated Presence Detect Changed caused by DPC [ Upstream commit bbf10cd686835d5a4b8566dc73a3b00b4cd7932a ] Commit c3be50f7547c ("PCI: pciehp: Ignore Presence Detect Changed caused by DPC") sought to ignore Presence Detect Changed events occurring as a side effect of Downstream Port Containment. The commit awaits recovery from DPC and then clears events which occurred in the meantime. However if the first event seen after DPC is Data Link Layer State Changed, only that event is cleared and not Presence Detect Changed. The object of the commit is thus defeated. That's because pciehp_ist() computes the events to clear based on the local "events" variable instead of "ctrl->pending_events". The former contains the events that had occurred when pciehp_ist() was entered, whereas the latter also contains events that have accumulated while awaiting DPC recovery. In practice, the order of PDC and DLLSC events is arbitrary and the delay in-between can be several milliseconds. So change the logic to always clear PDC events, even if they come after an initial DLLSC event. Fixes: c3be50f7547c ("PCI: pciehp: Ignore Presence Detect Changed caused by DPC") Reported-by: Lương Việt Hoàng Reported-by: Joel Mathew Thomas Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219765#c165 Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Tested-by: Lương Việt Hoàng Tested-by: Joel Mathew Thomas Link: https://patch.msgid.link/d9c4286a16253af7e93eaf12e076e3ef3546367a.1750257164.git.lukas@wunner.de Signed-off-by: Sasha Levin commit eb46bc2c033bf5e26d44bf4d21190308a138c03a Author: David Thompson Date: Fri Jun 13 16:34:43 2025 +0000 gpio: mlxbf3: only get IRQ for device instance 0 [ Upstream commit 10af0273a35ab4513ca1546644b8c853044da134 ] The gpio-mlxbf3 driver interfaces with two GPIO controllers, device instance 0 and 1. There is a single IRQ resource shared between the two controllers, and it is found in the ACPI table for device instance 0. The driver should not attempt to get an IRQ resource when probing device instance 1, otherwise the following error is logged: mlxbf3_gpio MLNXBF33:01: error -ENXIO: IRQ index 0 not found Signed-off-by: David Thompson Reviewed-by: Shravan Kumar Ramani Fixes: cd33f216d241 ("gpio: mlxbf3: Add gpio driver support") Link: https://lore.kernel.org/r/20250613163443.1065217-1-davthompson@nvidia.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit caa9654112d94eb47f57ae5c35b6fe8d85f5cb38 Author: Miquel Raynal Date: Wed Jun 18 10:48:00 2025 +0200 mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants [ Upstream commit dba90f5a79c13936de4273a19e67908a0c296afe ] Dual and quad capable chips natively support dual and quad I/O variants at up to 104MHz (1-2-2 and 1-4-4 operations). Reaching the maximum speed of 166MHz is theoretically possible (while still unsupported in the field) by adding a few more dummy cycles. Let's be accurate and clearly state this limit. Setting a maximum frequency implies adding the frequency parameter to the macro, which is done using a variadic argument to avoid impacting all the other drivers which already make use of this macro. Fixes: 1ea808b4d15b ("mtd: spinand: winbond: Update the *JW chip definitions") Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 8995cf53e66285f62412cc031ff9fb3a34061975 Author: Miquel Raynal Date: Thu Apr 3 11:19:21 2025 +0200 mtd: spinand: Use more specific naming for the (quad IO) read from cache ops [ Upstream commit 9c6911072c6e8b128ccdb7dd00efa13c47513074 ] SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really mean by describing the expected bus topology in the (quad IO) read from cache macro names. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants") Signed-off-by: Sasha Levin commit 91c9856dcf85f17daee2933a20b63e566e811fbd Author: Miquel Raynal Date: Thu Apr 3 11:19:20 2025 +0200 mtd: spinand: Use more specific naming for the (quad output) read from cache ops [ Upstream commit 1deae734cc1c7e976d588e7d8f46af2bb9ef5656 ] SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really mean by describing the expected bus topology in the (quad output) read from cache macro names. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants") Signed-off-by: Sasha Levin commit 61cad5f1f3a925718c6d2821adf732d55a3ec124 Author: Miquel Raynal Date: Thu Apr 3 11:19:19 2025 +0200 mtd: spinand: Use more specific naming for the (dual IO) read from cache ops [ Upstream commit d9de177996d74c0cc44220003953ba2d2bece0ac ] SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really mean by describing the expected bus topology in the (dual IO) read from cache macro names. While at modifying them, better reordering the macros to group them all by bus topology which now feels more intuitive. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants") Signed-off-by: Sasha Levin commit 2667e28cf5c59847bf81628d13ad5f41301e3a55 Author: Miquel Raynal Date: Thu Apr 3 11:19:18 2025 +0200 mtd: spinand: Use more specific naming for the (dual output) read from cache ops [ Upstream commit 684f7105e8534f6500de389c089ba204cb1c8058 ] SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really mean by describing the expected bus topology in the (dual output) read from cache macro names. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants") Signed-off-by: Sasha Levin commit 8a39fa1753796a1955bf73bfff7dd09131b6a379 Author: Miquel Raynal Date: Thu Apr 3 11:19:17 2025 +0200 mtd: spinand: Use more specific naming for the (single) read from cache ops [ Upstream commit ea2087d4e66d0b927918cc9048576aca6a0446ad ] SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really mean by describing the expected bus topology in the (single) read from cache macro names. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants") Signed-off-by: Sasha Levin commit 1d6fcac42153018707fb715aeb0c7fd11ab4bf50 Author: Rik van Riel Date: Fri Jun 6 13:10:34 2025 -0400 x86/mm: Fix early boot use of INVPLGB [ Upstream commit cb6075bc62dc6a9cd7ab3572758685fdf78e3e20 ] The INVLPGB instruction has limits on how many pages it can invalidate at once. That limit is enumerated in CPUID, read by the kernel, and stored in 'invpgb_count_max'. Ranged invalidation, like invlpgb_kernel_range_flush() break up their invalidations so that they do not exceed the limit. However, early boot code currently attempts to do ranged invalidation before populating 'invlpgb_count_max'. There is a for loop which is basically: for (...; addr < end; addr += invlpgb_count_max*PAGE_SIZE) If invlpgb_kernel_range_flush is called before the kernel has read the value of invlpgb_count_max from the hardware, the normally bounded loop can become an infinite loop if invlpgb_count_max is initialized to zero. Fix that issue by initializing invlpgb_count_max to 1. This way INVPLGB at early boot time will be a little bit slower than normal (with initialized invplgb_count_max), and not an instant hang at bootup time. Fixes: b7aa05cbdc52 ("x86/mm: Add INVLPGB support code") Signed-off-by: Rik van Riel Signed-off-by: Dave Hansen Link: https://lore.kernel.org/all/20250606171112.4013261-3-riel%40surriel.com Signed-off-by: Sasha Levin commit 0f34182e1ecd73251b773fec9e2f457d1de38cd9 Author: Ian Rogers Date: Fri Jun 13 17:41:04 2025 -0700 perf test: Directory file descriptor leak [ Upstream commit 19f4422d485b2d0a935117a1a16015328f99be25 ] Add missed close when iterating over the script directories. Fixes: f3295f5b067d3c26 ("perf tests: Use scandirat for shell script finding") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Ingo Molnar Cc: Jiapeng Chong Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Tiezhu Yang Link: https://lore.kernel.org/r/20250614004108.1650988-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ffa4f37c84056f5ec8c98e23c4d1ab23ab1d28d7 Author: Ian Rogers Date: Fri Jun 13 17:41:05 2025 -0700 perf evsel: Missed close() when probing hybrid core PMUs [ Upstream commit ebec62bc7ec435b475722a5467d67c720a1ad79f ] Add missing close() to avoid leaking perf events. In past perfs this mattered little as the function was just used by 'perf list'. As the function is now used to detect hybrid PMUs leaking the perf event is somewhat more painful. Fixes: b41f1cec91c37eee ("perf list: Skip unsupported events") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Ingo Molnar Cc: Jiapeng Chong Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Michael Petlan Cc: Namhyung Kim Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Tiezhu Yang Link: https://lore.kernel.org/r/20250614004108.1650988-2-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 17dcb5db7540df828235b11d8d9370cf6dbaf7ef Author: Sascha Hauer Date: Mon Jun 16 15:45:03 2025 +0200 gpio: pca953x: fix wrong error probe return value [ Upstream commit 0a1db19f66c0960eb00e1f2ccd40708b6747f5b1 ] The second argument to dev_err_probe() is the error value. Pass the return value of devm_request_threaded_irq() there instead of the irq number. Signed-off-by: Sascha Hauer Fixes: c47f7ff0fe61 ("gpio: pca953x: Utilise dev_err_probe() where it makes sense") Link: https://lore.kernel.org/r/20250616134503.1201138-1-s.hauer@pengutronix.de Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 76944f40a52a2c2631c038c49d94ea49ca3df9da Author: Anup Patel Date: Thu Jun 5 11:44:47 2025 +0530 RISC-V: KVM: Don't treat SBI HFENCE calls as NOPs [ Upstream commit 2e7be162996640bbe3b6da694cc064c511b8a5d9 ] The SBI specification clearly states that SBI HFENCE calls should return SBI_ERR_NOT_SUPPORTED when one of the target hart doesn’t support hypervisor extension (aka nested virtualization in-case of KVM RISC-V). Fixes: c7fa3c48de86 ("RISC-V: KVM: Treat SBI HFENCE calls as NOPs") Reviewed-by: Atish Patra Signed-off-by: Anup Patel Link: https://lore.kernel.org/r/20250605061458.196003-3-apatel@ventanamicro.com Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit ad03ff6b2870a5dd3f54b5eab7d52e498689f4b5 Author: Anup Patel Date: Thu Jun 5 11:44:46 2025 +0530 RISC-V: KVM: Fix the size parameter check in SBI SFENCE calls [ Upstream commit 6aba0cb5bba6141158d5449f2cf53187b7f755f9 ] As-per the SBI specification, an SBI remote fence operation applies to the entire address space if either: 1) start_addr and size are both 0 2) size is equal to 2^XLEN-1 >From the above, only #1 is checked by SBI SFENCE calls so fix the size parameter check in SBI SFENCE calls to cover #2 as well. Fixes: 13acfec2dbcc ("RISC-V: KVM: Add remote HFENCE functions based on VCPU requests") Reviewed-by: Atish Patra Signed-off-by: Anup Patel Link: https://lore.kernel.org/r/20250605061458.196003-2-apatel@ventanamicro.com Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit a9e845f21d743c2a7a52194a81c89dee193fbf68 Author: Vitaliy Shevtsov Date: Thu Jun 12 21:35:18 2025 +0500 scsi: elx: efct: Fix memory leak in efct_hw_parse_filter() [ Upstream commit 2a8a5a5dd06eef580f9818567773fd75057cb875 ] strsep() modifies the address of the pointer passed to it so that it no longer points to the original address. This means kfree() gets the wrong pointer. Fix this by passing unmodified pointer returned from kstrdup() to kfree(). Found by Linux Verification Center (linuxtesting.org) with Svace. Fixes: 4df84e846624 ("scsi: elx: efct: Driver initialization routines") Signed-off-by: Vitaliy Shevtsov Link: https://lore.kernel.org/r/20250612163616.24298-1-v.shevtsov@mt-integration.ru Reviewed-by: Daniel Wagner Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 422e565b7889ebfd9c8705a3fc786642afe61fca Author: Tengda Wu Date: Wed Jun 4 00:55:33 2025 +0000 arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() [ Upstream commit 39dfc971e42d886e7df01371cd1bef505076d84c ] KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth(). Call Trace: [ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550 [ 97.285732] [ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11 [ 97.287032] Hardware name: linux,dummy-virt (DT) [ 97.287815] Call trace: [ 97.288279] dump_backtrace+0xa0/0x128 [ 97.288946] show_stack+0x20/0x38 [ 97.289551] dump_stack_lvl+0x78/0xc8 [ 97.290203] print_address_description.constprop.0+0x84/0x3c8 [ 97.291159] print_report+0xb0/0x280 [ 97.291792] kasan_report+0x84/0xd0 [ 97.292421] __asan_load8+0x9c/0xc0 [ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.293835] process_fetch_insn+0x770/0xa30 [ 97.294562] kprobe_trace_func+0x254/0x3b0 [ 97.295271] kprobe_dispatcher+0x98/0xe0 [ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210 [ 97.296774] call_break_hook+0xc4/0x100 [ 97.297451] brk_handler+0x24/0x78 [ 97.298073] do_debug_exception+0xac/0x178 [ 97.298785] el1_dbg+0x70/0x90 [ 97.299344] el1h_64_sync_handler+0xcc/0xe8 [ 97.300066] el1h_64_sync+0x78/0x80 [ 97.300699] kernel_clone+0x0/0x500 [ 97.301331] __arm64_sys_clone+0x70/0x90 [ 97.302084] invoke_syscall+0x68/0x198 [ 97.302746] el0_svc_common.constprop.0+0x11c/0x150 [ 97.303569] do_el0_svc+0x38/0x50 [ 97.304164] el0_svc+0x44/0x1d8 [ 97.304749] el0t_64_sync_handler+0x100/0x130 [ 97.305500] el0t_64_sync+0x188/0x190 [ 97.306151] [ 97.306475] The buggy address belongs to stack of task 1.sh/2550 [ 97.307461] and is located at offset 0 in frame: [ 97.308257] __se_sys_clone+0x0/0x138 [ 97.308910] [ 97.309241] This frame has 1 object: [ 97.309873] [48, 184) 'args' [ 97.309876] [ 97.310749] The buggy address belongs to the virtual mapping at [ 97.310749] [ffff800089270000, ffff800089279000) created by: [ 97.310749] dup_task_struct+0xc0/0x2e8 [ 97.313347] [ 97.313674] The buggy address belongs to the physical page: [ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a [ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff) [ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000 [ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 97.319445] page dumped because: kasan: bad access detected [ 97.320371] [ 97.320694] Memory state around the buggy address: [ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.323846] >ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00 [ 97.325023] ^ [ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 [ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 This issue seems to be related to the behavior of some gcc compilers and was also fixed on the s390 architecture before: commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()") As described in that commit, regs_get_kernel_stack_nth() has confirmed that `addr` is on the stack, so reading the value at `*addr` should be allowed. Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case. Fixes: 0a8ea52c3eb1 ("arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature") Signed-off-by: Tengda Wu Link: https://lore.kernel.org/r/20250604005533.1278992-1-wutengda@huaweicloud.com [will: Use '*addr' as the argument to READ_ONCE_NOCHECK()] Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit e6654d9a4d535bf622bc9500e52be515ea0b5038 Author: Luo Gengkun Date: Wed Jun 4 03:39:24 2025 +0000 perf/core: Fix WARN in perf_cgroup_switch() [ Upstream commit 3172fb986666dfb71bf483b6d3539e1e587fa197 ] There may be concurrency between perf_cgroup_switch and perf_cgroup_event_disable. Consider the following scenario: after a new perf cgroup event is created on CPU0, the new event may not trigger a reprogramming, causing ctx->is_active to be 0. In this case, when CPU1 disables this perf event, it executes __perf_remove_from_context-> list _del_event->perf_cgroup_event_disable on CPU1, which causes a race with perf_cgroup_switch running on CPU0. The following describes the details of this concurrency scenario: CPU0 CPU1 perf_cgroup_switch: ... # cpuctx->cgrp is not NULL here if (READ_ONCE(cpuctx->cgrp) == NULL) return; perf_remove_from_context: ... raw_spin_lock_irq(&ctx->lock); ... # ctx->is_active == 0 because reprogramm is not # tigger, so CPU1 can do __perf_remove_from_context # for CPU0 __perf_remove_from_context: perf_cgroup_event_disable: ... if (--ctx->nr_cgroups) ... # this warning will happened because CPU1 changed # ctx.nr_cgroups to 0. WARN_ON_ONCE(cpuctx->ctx.nr_cgroups == 0); [peterz: use guard instead of goto unlock] Fixes: db4a835601b7 ("perf/core: Set cgroup in CPU contexts for new cgroup events") Signed-off-by: Luo Gengkun Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20250604033924.3914647-3-luogengkun@huaweicloud.com Signed-off-by: Sasha Levin commit 062ce14cd978d47a882cf6c9a308dd51ddad9871 Author: Peter Zijlstra Date: Thu Jun 5 12:37:11 2025 +0200 perf: Fix cgroup state vs ERROR [ Upstream commit 61988e36dc5457cdff7ae7927e8d9ad1419ee998 ] While chasing down a missing perf_cgroup_event_disable() elsewhere, Leo Yan found that both perf_put_aux_event() and perf_remove_sibling_event() were also missing one. Specifically, the rule is that events that switch to OFF,ERROR need to call perf_cgroup_event_disable(). Unify the disable paths to ensure this. Fixes: ab43762ef010 ("perf: Allow normal events to output AUX data") Fixes: 9f0c4fa111dc ("perf/core: Add a new PERF_EV_CAP_SIBLING event capability") Reported-by: Leo Yan Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20250605123343.GD35970@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit 7311970d07c4606362081250da95f2c7901fc0db Author: Peter Zijlstra Date: Thu Jun 5 12:31:45 2025 +0200 perf: Fix sample vs do_exit() [ Upstream commit 4f6fc782128355931527cefe3eb45338abd8ab39 ] Baisheng Gao reported an ARM64 crash, which Mark decoded as being a synchronous external abort -- most likely due to trying to access MMIO in bad ways. The crash further shows perf trying to do a user stack sample while in exit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the address space it is trying to access. It turns out that we stop perf after we tear down the userspace mm; a receipie for disaster, since perf likes to access userspace for various reasons. Flip this order by moving up where we stop perf in do_exit(). Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER to abort when the current task does not have an mm (exit_mm() makes sure to set current->mm = NULL; before commencing with the actual teardown). Such that CPU wide events don't trip on this same problem. Fixes: c5ebcedb566e ("perf: Add ability to attach user stack dump to sample") Reported-by: Baisheng Gao Suggested-by: Mark Rutland Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20250605110815.GQ39944@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit fa2f7883d496f735635cfe6c7a42de0dea8a8130 Author: Bagas Sanjaya Date: Wed Jun 11 09:08:06 2025 +0700 Documentation: nouveau: Update GSP message queue kernel-doc reference commit 553ab30a181043f01b99a493ba13f9c011eb75ae upstream. GSP message queue docs has been moved following RPC handling split in commit 8a8b1ec5261f20 ("drm/nouveau/gsp: split rpc handling out on its own"), before GSP-RM implementation is versioned in commit c472d828348caf ("drm/nouveau/gsp: move subdev/engine impls to subdev/gsp/rm/r535/"). However, the kernel-doc reference in nouveau docs is left behind, which triggers htmldocs warnings: ERROR: Cannot find file ./drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c WARNING: No kernel-doc for file ./drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c Update the reference. Fixes: c472d828348c ("drm/nouveau/gsp: move subdev/engine impls to subdev/gsp/rm/r535/") Fixes: 8a8b1ec5261f ("drm/nouveau/gsp: split rpc handling out on its own") Signed-off-by: Bagas Sanjaya Acked-by: Randy Dunlap Tested-by: Randy Dunlap Link: https://lore.kernel.org/r/20250611020805.22418-2-bagasdotme@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 45ccfac4c5430f4de79d95c595e418634133ab5f Author: Steven Rostedt Date: Tue Jun 10 09:33:48 2025 -0400 tracing: Do not free "head" on error path of filter_free_subsystem_filters() commit 8a157d8a00e815cab4432653cb50c9cedbbb4931 upstream. The variable "head" is allocated and initialized as a list before allocating the first "item" for the list. If the allocation of "item" fails, it frees "head" and then jumps to the label "free_now" which will process head and free it. This will cause a UAF of "head", and it doesn't need to free it before jumping to the "free_now" label as that code will free it. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://lore.kernel.org/20250610093348.33c5643a@gandalf.local.home Fixes: a9d0aab5eb33 ("tracing: Fix regression of filter waiting a long time on RCU synchronization") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202506070424.lCiNreTI-lkp@intel.com/ Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit b73bf4d6304596cd5425018402a6c34227e7b731 Author: Benjamin Marzinski Date: Fri May 30 10:50:32 2025 -0400 dm-table: check BLK_FEAT_ATOMIC_WRITES inside limits_lock commit 85f6d5b729eaace1549f1dcc284d9865f2c3ec02 upstream. dm_set_device_limits() should check q->limits.features for BLK_FEAT_ATOMIC_WRITES while holding q->limits_lock, like it does for the rest of the queue limits. Fixes: b7c18b17a173 ("dm-table: Set BLK_FEAT_ATOMIC_WRITES for target queue limits") Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 504a5cbc017f2616edf73f43c8faddc44d055003 Author: Lukas Bulwahn Date: Mon Jun 16 12:04:32 2025 +0200 x86/its: Fix an ifdef typo in its_alloc() commit 3c902383f2da91cba3821b73aa6edd49f4db6023 upstream. Commit a82b26451de1 ("x86/its: explicitly manage permissions for ITS pages") reworks its_alloc() and introduces a typo in an ifdef conditional, referring to CONFIG_MODULE instead of CONFIG_MODULES. Fix this typo in its_alloc(). Fixes: a82b26451de1 ("x86/its: explicitly manage permissions for ITS pages") Signed-off-by: Lukas Bulwahn Signed-off-by: Dave Hansen Link: https://lore.kernel.org/all/20250616100432.22941-1-lukas.bulwahn%40redhat.com Signed-off-by: Greg Kroah-Hartman commit 40e69c93d6dadc5355bfe90f3940c402d171289c Author: Qiuxu Zhuo Date: Thu Jun 19 00:23:06 2025 +0800 EDAC/igen6: Fix NULL pointer dereference commit 88efa0de3285be66969b71ec137d9dab1ee19e52 upstream. A kernel panic was reported with the following kernel log: EDAC igen6: Expected 2 mcs, but only 1 detected. BUG: unable to handle page fault for address: 000000000000d570 ... Hardware name: Notebook V54x_6x_TU/V54x_6x_TU, BIOS Dasharo (coreboot+UEFI) v0.9.0 07/17/2024 RIP: e030:ecclog_handler+0x7e/0xf0 [igen6_edac] ... igen6_probe+0x2a0/0x343 [igen6_edac] ... igen6_init+0xc5/0xff0 [igen6_edac] ... This issue occurred because one memory controller was disabled by the BIOS but the igen6_edac driver still checked all the memory controllers, including this absent one, to identify the source of the error. Accessing the null MMIO for the absent memory controller resulted in the oops above. Fix this issue by reverting the configuration structure to non-const and updating the field 'res_cfg->num_imc' to reflect the number of detected memory controllers. Fixes: 20e190b1c1fd ("EDAC/igen6: Skip absent memory controllers") Reported-by: Marek Marczykowski-Górecki Closes: https://lore.kernel.org/all/aFFN7RlXkaK_loQb@mail-itl/ Suggested-by: Borislav Petkov Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov (AMD) Tested-by: Marek Marczykowski-Górecki Link: https://lore.kernel.org/r/20250618162307.1523736-1-qiuxu.zhuo@intel.com Signed-off-by: Greg Kroah-Hartman commit e0ba9b2f188166550296005e64b15e80db82ad8a Author: Stefan Metzmacher Date: Wed Jun 18 18:51:40 2025 +0200 smb: client: fix max_sge overflow in smb_extract_folioq_to_rdma() commit a379a8a2a0032e12e7ef397197c9c2ad011588d6 upstream. This fixes the following problem: [ 749.901015] [ T8673] run fstests cifs/001 at 2025-06-17 09:40:30 [ 750.346409] [ T9870] ================================================================== [ 750.346814] [ T9870] BUG: KASAN: slab-out-of-bounds in smb_set_sge+0x2cc/0x3b0 [cifs] [ 750.347330] [ T9870] Write of size 8 at addr ffff888011082890 by task xfs_io/9870 [ 750.347705] [ T9870] [ 750.348077] [ T9870] CPU: 0 UID: 0 PID: 9870 Comm: xfs_io Kdump: loaded Not tainted 6.16.0-rc2-metze.02+ #1 PREEMPT(voluntary) [ 750.348082] [ T9870] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 750.348085] [ T9870] Call Trace: [ 750.348086] [ T9870] [ 750.348088] [ T9870] dump_stack_lvl+0x76/0xa0 [ 750.348106] [ T9870] print_report+0xd1/0x640 [ 750.348116] [ T9870] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 750.348120] [ T9870] ? kasan_complete_mode_report_info+0x26/0x210 [ 750.348124] [ T9870] kasan_report+0xe7/0x130 [ 750.348128] [ T9870] ? smb_set_sge+0x2cc/0x3b0 [cifs] [ 750.348262] [ T9870] ? smb_set_sge+0x2cc/0x3b0 [cifs] [ 750.348377] [ T9870] __asan_report_store8_noabort+0x17/0x30 [ 750.348381] [ T9870] smb_set_sge+0x2cc/0x3b0 [cifs] [ 750.348496] [ T9870] smbd_post_send_iter+0x1990/0x3070 [cifs] [ 750.348625] [ T9870] ? __pfx_smbd_post_send_iter+0x10/0x10 [cifs] [ 750.348741] [ T9870] ? update_stack_state+0x2a0/0x670 [ 750.348749] [ T9870] ? cifs_flush+0x153/0x320 [cifs] [ 750.348870] [ T9870] ? cifs_flush+0x153/0x320 [cifs] [ 750.348990] [ T9870] ? update_stack_state+0x2a0/0x670 [ 750.348995] [ T9870] smbd_send+0x58c/0x9c0 [cifs] [ 750.349117] [ T9870] ? __pfx_smbd_send+0x10/0x10 [cifs] [ 750.349231] [ T9870] ? unwind_get_return_address+0x65/0xb0 [ 750.349235] [ T9870] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 750.349242] [ T9870] ? arch_stack_walk+0xa7/0x100 [ 750.349250] [ T9870] ? stack_trace_save+0x92/0xd0 [ 750.349254] [ T9870] __smb_send_rqst+0x931/0xec0 [cifs] [ 750.349374] [ T9870] ? kernel_text_address+0x173/0x190 [ 750.349379] [ T9870] ? kasan_save_stack+0x39/0x70 [ 750.349382] [ T9870] ? kasan_save_track+0x18/0x70 [ 750.349385] [ T9870] ? __kasan_slab_alloc+0x9d/0xa0 [ 750.349389] [ T9870] ? __pfx___smb_send_rqst+0x10/0x10 [cifs] [ 750.349508] [ T9870] ? smb2_mid_entry_alloc+0xb4/0x7e0 [cifs] [ 750.349626] [ T9870] ? cifs_call_async+0x277/0xb00 [cifs] [ 750.349746] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs] [ 750.349867] [ T9870] ? netfs_do_issue_write+0xc2/0x340 [netfs] [ 750.349900] [ T9870] ? netfs_advance_write+0x45b/0x1270 [netfs] [ 750.349929] [ T9870] ? netfs_write_folio+0xd6c/0x1be0 [netfs] [ 750.349958] [ T9870] ? netfs_writepages+0x2e9/0xa80 [netfs] [ 750.349987] [ T9870] ? do_writepages+0x21f/0x590 [ 750.349993] [ T9870] ? filemap_fdatawrite_wbc+0xe1/0x140 [ 750.349997] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 750.350002] [ T9870] smb_send_rqst+0x22e/0x2f0 [cifs] [ 750.350131] [ T9870] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] [ 750.350255] [ T9870] ? local_clock_noinstr+0xe/0xd0 [ 750.350261] [ T9870] ? kasan_save_alloc_info+0x37/0x60 [ 750.350268] [ T9870] ? __kasan_check_write+0x14/0x30 [ 750.350271] [ T9870] ? _raw_spin_lock+0x81/0xf0 [ 750.350275] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10 [ 750.350278] [ T9870] ? smb2_setup_async_request+0x293/0x580 [cifs] [ 750.350398] [ T9870] cifs_call_async+0x477/0xb00 [cifs] [ 750.350518] [ T9870] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs] [ 750.350636] [ T9870] ? __pfx_cifs_call_async+0x10/0x10 [cifs] [ 750.350756] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10 [ 750.350760] [ T9870] ? __kasan_check_write+0x14/0x30 [ 750.350763] [ T9870] ? __smb2_plain_req_init+0x933/0x1090 [cifs] [ 750.350891] [ T9870] smb2_async_writev+0x15ff/0x2460 [cifs] [ 750.351008] [ T9870] ? sched_clock_noinstr+0x9/0x10 [ 750.351012] [ T9870] ? local_clock_noinstr+0xe/0xd0 [ 750.351018] [ T9870] ? __pfx_smb2_async_writev+0x10/0x10 [cifs] [ 750.351144] [ T9870] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 750.351150] [ T9870] ? _raw_spin_unlock+0xe/0x40 [ 750.351154] [ T9870] ? cifs_pick_channel+0x242/0x370 [cifs] [ 750.351275] [ T9870] cifs_issue_write+0x256/0x610 [cifs] [ 750.351554] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs] [ 750.351677] [ T9870] netfs_do_issue_write+0xc2/0x340 [netfs] [ 750.351710] [ T9870] netfs_advance_write+0x45b/0x1270 [netfs] [ 750.351740] [ T9870] ? rolling_buffer_append+0x12d/0x440 [netfs] [ 750.351769] [ T9870] netfs_write_folio+0xd6c/0x1be0 [netfs] [ 750.351798] [ T9870] ? __kasan_check_write+0x14/0x30 [ 750.351804] [ T9870] netfs_writepages+0x2e9/0xa80 [netfs] [ 750.351835] [ T9870] ? __pfx_netfs_writepages+0x10/0x10 [netfs] [ 750.351864] [ T9870] ? exit_files+0xab/0xe0 [ 750.351867] [ T9870] ? do_exit+0x148f/0x2980 [ 750.351871] [ T9870] ? do_group_exit+0xb5/0x250 [ 750.351874] [ T9870] ? arch_do_signal_or_restart+0x92/0x630 [ 750.351879] [ T9870] ? exit_to_user_mode_loop+0x98/0x170 [ 750.351882] [ T9870] ? do_syscall_64+0x2cf/0xd80 [ 750.351886] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 750.351890] [ T9870] do_writepages+0x21f/0x590 [ 750.351894] [ T9870] ? __pfx_do_writepages+0x10/0x10 [ 750.351897] [ T9870] filemap_fdatawrite_wbc+0xe1/0x140 [ 750.351901] [ T9870] __filemap_fdatawrite_range+0xba/0x100 [ 750.351904] [ T9870] ? __pfx___filemap_fdatawrite_range+0x10/0x10 [ 750.351912] [ T9870] ? __kasan_check_write+0x14/0x30 [ 750.351916] [ T9870] filemap_write_and_wait_range+0x7d/0xf0 [ 750.351920] [ T9870] cifs_flush+0x153/0x320 [cifs] [ 750.352042] [ T9870] filp_flush+0x107/0x1a0 [ 750.352046] [ T9870] filp_close+0x14/0x30 [ 750.352049] [ T9870] put_files_struct.part.0+0x126/0x2a0 [ 750.352053] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10 [ 750.352058] [ T9870] exit_files+0xab/0xe0 [ 750.352061] [ T9870] do_exit+0x148f/0x2980 [ 750.352065] [ T9870] ? __pfx_do_exit+0x10/0x10 [ 750.352069] [ T9870] ? __kasan_check_write+0x14/0x30 [ 750.352072] [ T9870] ? _raw_spin_lock_irq+0x8a/0xf0 [ 750.352076] [ T9870] do_group_exit+0xb5/0x250 [ 750.352080] [ T9870] get_signal+0x22d3/0x22e0 [ 750.352086] [ T9870] ? __pfx_get_signal+0x10/0x10 [ 750.352089] [ T9870] ? fpregs_assert_state_consistent+0x68/0x100 [ 750.352101] [ T9870] ? folio_add_lru+0xda/0x120 [ 750.352105] [ T9870] arch_do_signal_or_restart+0x92/0x630 [ 750.352109] [ T9870] ? __pfx_arch_do_signal_or_restart+0x10/0x10 [ 750.352115] [ T9870] exit_to_user_mode_loop+0x98/0x170 [ 750.352118] [ T9870] do_syscall_64+0x2cf/0xd80 [ 750.352123] [ T9870] ? __kasan_check_read+0x11/0x20 [ 750.352126] [ T9870] ? count_memcg_events+0x1b4/0x420 [ 750.352132] [ T9870] ? handle_mm_fault+0x148/0x690 [ 750.352136] [ T9870] ? _raw_spin_lock_irq+0x8a/0xf0 [ 750.352140] [ T9870] ? __kasan_check_read+0x11/0x20 [ 750.352143] [ T9870] ? fpregs_assert_state_consistent+0x68/0x100 [ 750.352146] [ T9870] ? irqentry_exit_to_user_mode+0x2e/0x250 [ 750.352151] [ T9870] ? irqentry_exit+0x43/0x50 [ 750.352154] [ T9870] ? exc_page_fault+0x75/0xe0 [ 750.352160] [ T9870] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 750.352163] [ T9870] RIP: 0033:0x7858c94ab6e2 [ 750.352167] [ T9870] Code: Unable to access opcode bytes at 0x7858c94ab6b8. [ 750.352175] [ T9870] RSP: 002b:00007858c9248ce8 EFLAGS: 00000246 ORIG_RAX: 0000000000000022 [ 750.352179] [ T9870] RAX: fffffffffffffdfe RBX: 00007858c92496c0 RCX: 00007858c94ab6e2 [ 750.352182] [ T9870] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 750.352184] [ T9870] RBP: 00007858c9248d10 R08: 0000000000000000 R09: 0000000000000000 [ 750.352185] [ T9870] R10: 0000000000000000 R11: 0000000000000246 R12: fffffffffffffde0 [ 750.352187] [ T9870] R13: 0000000000000020 R14: 0000000000000002 R15: 00007ffc072d2230 [ 750.352191] [ T9870] [ 750.352195] [ T9870] [ 750.395206] [ T9870] Allocated by task 9870 on cpu 0 at 750.346406s: [ 750.395523] [ T9870] kasan_save_stack+0x39/0x70 [ 750.395532] [ T9870] kasan_save_track+0x18/0x70 [ 750.395536] [ T9870] kasan_save_alloc_info+0x37/0x60 [ 750.395539] [ T9870] __kasan_slab_alloc+0x9d/0xa0 [ 750.395543] [ T9870] kmem_cache_alloc_noprof+0x13c/0x3f0 [ 750.395548] [ T9870] mempool_alloc_slab+0x15/0x20 [ 750.395553] [ T9870] mempool_alloc_noprof+0x135/0x340 [ 750.395557] [ T9870] smbd_post_send_iter+0x63e/0x3070 [cifs] [ 750.395694] [ T9870] smbd_send+0x58c/0x9c0 [cifs] [ 750.395819] [ T9870] __smb_send_rqst+0x931/0xec0 [cifs] [ 750.395950] [ T9870] smb_send_rqst+0x22e/0x2f0 [cifs] [ 750.396081] [ T9870] cifs_call_async+0x477/0xb00 [cifs] [ 750.396232] [ T9870] smb2_async_writev+0x15ff/0x2460 [cifs] [ 750.396359] [ T9870] cifs_issue_write+0x256/0x610 [cifs] [ 750.396492] [ T9870] netfs_do_issue_write+0xc2/0x340 [netfs] [ 750.396544] [ T9870] netfs_advance_write+0x45b/0x1270 [netfs] [ 750.396576] [ T9870] netfs_write_folio+0xd6c/0x1be0 [netfs] [ 750.396608] [ T9870] netfs_writepages+0x2e9/0xa80 [netfs] [ 750.396639] [ T9870] do_writepages+0x21f/0x590 [ 750.396643] [ T9870] filemap_fdatawrite_wbc+0xe1/0x140 [ 750.396647] [ T9870] __filemap_fdatawrite_range+0xba/0x100 [ 750.396651] [ T9870] filemap_write_and_wait_range+0x7d/0xf0 [ 750.396656] [ T9870] cifs_flush+0x153/0x320 [cifs] [ 750.396787] [ T9870] filp_flush+0x107/0x1a0 [ 750.396791] [ T9870] filp_close+0x14/0x30 [ 750.396795] [ T9870] put_files_struct.part.0+0x126/0x2a0 [ 750.396800] [ T9870] exit_files+0xab/0xe0 [ 750.396803] [ T9870] do_exit+0x148f/0x2980 [ 750.396808] [ T9870] do_group_exit+0xb5/0x250 [ 750.396813] [ T9870] get_signal+0x22d3/0x22e0 [ 750.396817] [ T9870] arch_do_signal_or_restart+0x92/0x630 [ 750.396822] [ T9870] exit_to_user_mode_loop+0x98/0x170 [ 750.396827] [ T9870] do_syscall_64+0x2cf/0xd80 [ 750.396832] [ T9870] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 750.396836] [ T9870] [ 750.397150] [ T9870] The buggy address belongs to the object at ffff888011082800 which belongs to the cache smbd_request_0000000008f3bd7b of size 144 [ 750.397798] [ T9870] The buggy address is located 0 bytes to the right of allocated 144-byte region [ffff888011082800, ffff888011082890) [ 750.398469] [ T9870] [ 750.398800] [ T9870] The buggy address belongs to the physical page: [ 750.399141] [ T9870] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11082 [ 750.399148] [ T9870] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) [ 750.399155] [ T9870] page_type: f5(slab) [ 750.399161] [ T9870] raw: 000fffffc0000000 ffff888022d65640 dead000000000122 0000000000000000 [ 750.399165] [ T9870] raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 [ 750.399169] [ T9870] page dumped because: kasan: bad access detected [ 750.399172] [ T9870] [ 750.399505] [ T9870] Memory state around the buggy address: [ 750.399863] [ T9870] ffff888011082780: fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 750.400247] [ T9870] ffff888011082800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 750.400618] [ T9870] >ffff888011082880: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 750.400982] [ T9870] ^ [ 750.401370] [ T9870] ffff888011082900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 750.401774] [ T9870] ffff888011082980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 750.402171] [ T9870] ================================================================== [ 750.402696] [ T9870] Disabling lock debugging due to kernel taint [ 750.403202] [ T9870] BUG: unable to handle page fault for address: ffff8880110a2000 [ 750.403797] [ T9870] #PF: supervisor write access in kernel mode [ 750.404204] [ T9870] #PF: error_code(0x0003) - permissions violation [ 750.404581] [ T9870] PGD 5ce01067 P4D 5ce01067 PUD 5ce02067 PMD 78aa063 PTE 80000000110a2021 [ 750.404969] [ T9870] Oops: Oops: 0003 [#1] SMP KASAN PTI [ 750.405394] [ T9870] CPU: 0 UID: 0 PID: 9870 Comm: xfs_io Kdump: loaded Tainted: G B 6.16.0-rc2-metze.02+ #1 PREEMPT(voluntary) [ 750.406510] [ T9870] Tainted: [B]=BAD_PAGE [ 750.406967] [ T9870] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 750.407440] [ T9870] RIP: 0010:smb_set_sge+0x15c/0x3b0 [cifs] [ 750.408065] [ T9870] Code: 48 83 f8 ff 0f 84 b0 00 00 00 48 ba 00 00 00 00 00 fc ff df 4c 89 e1 48 c1 e9 03 80 3c 11 00 0f 85 69 01 00 00 49 8d 7c 24 08 <49> 89 04 24 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 0f [ 750.409283] [ T9870] RSP: 0018:ffffc90005e2e758 EFLAGS: 00010246 [ 750.409803] [ T9870] RAX: ffff888036c53400 RBX: ffffc90005e2e878 RCX: 1ffff11002214400 [ 750.410323] [ T9870] RDX: dffffc0000000000 RSI: dffffc0000000000 RDI: ffff8880110a2008 [ 750.411217] [ T9870] RBP: ffffc90005e2e798 R08: 0000000000000001 R09: 0000000000000400 [ 750.411770] [ T9870] R10: ffff888011082800 R11: 0000000000000000 R12: ffff8880110a2000 [ 750.412325] [ T9870] R13: 0000000000000000 R14: ffffc90005e2e888 R15: ffff88801a4b6000 [ 750.412901] [ T9870] FS: 0000000000000000(0000) GS:ffff88812bc68000(0000) knlGS:0000000000000000 [ 750.413477] [ T9870] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 750.414077] [ T9870] CR2: ffff8880110a2000 CR3: 000000005b0a6005 CR4: 00000000000726f0 [ 750.414654] [ T9870] Call Trace: [ 750.415211] [ T9870] [ 750.415748] [ T9870] smbd_post_send_iter+0x1990/0x3070 [cifs] [ 750.416449] [ T9870] ? __pfx_smbd_post_send_iter+0x10/0x10 [cifs] [ 750.417128] [ T9870] ? update_stack_state+0x2a0/0x670 [ 750.417685] [ T9870] ? cifs_flush+0x153/0x320 [cifs] [ 750.418380] [ T9870] ? cifs_flush+0x153/0x320 [cifs] [ 750.419055] [ T9870] ? update_stack_state+0x2a0/0x670 [ 750.419624] [ T9870] smbd_send+0x58c/0x9c0 [cifs] [ 750.420297] [ T9870] ? __pfx_smbd_send+0x10/0x10 [cifs] [ 750.420936] [ T9870] ? unwind_get_return_address+0x65/0xb0 [ 750.421456] [ T9870] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 750.421954] [ T9870] ? arch_stack_walk+0xa7/0x100 [ 750.422460] [ T9870] ? stack_trace_save+0x92/0xd0 [ 750.422948] [ T9870] __smb_send_rqst+0x931/0xec0 [cifs] [ 750.423579] [ T9870] ? kernel_text_address+0x173/0x190 [ 750.424056] [ T9870] ? kasan_save_stack+0x39/0x70 [ 750.424813] [ T9870] ? kasan_save_track+0x18/0x70 [ 750.425323] [ T9870] ? __kasan_slab_alloc+0x9d/0xa0 [ 750.425831] [ T9870] ? __pfx___smb_send_rqst+0x10/0x10 [cifs] [ 750.426548] [ T9870] ? smb2_mid_entry_alloc+0xb4/0x7e0 [cifs] [ 750.427231] [ T9870] ? cifs_call_async+0x277/0xb00 [cifs] [ 750.427882] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs] [ 750.428909] [ T9870] ? netfs_do_issue_write+0xc2/0x340 [netfs] [ 750.429425] [ T9870] ? netfs_advance_write+0x45b/0x1270 [netfs] [ 750.429882] [ T9870] ? netfs_write_folio+0xd6c/0x1be0 [netfs] [ 750.430345] [ T9870] ? netfs_writepages+0x2e9/0xa80 [netfs] [ 750.430809] [ T9870] ? do_writepages+0x21f/0x590 [ 750.431239] [ T9870] ? filemap_fdatawrite_wbc+0xe1/0x140 [ 750.431652] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 750.432041] [ T9870] smb_send_rqst+0x22e/0x2f0 [cifs] [ 750.432586] [ T9870] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] [ 750.433108] [ T9870] ? local_clock_noinstr+0xe/0xd0 [ 750.433482] [ T9870] ? kasan_save_alloc_info+0x37/0x60 [ 750.433855] [ T9870] ? __kasan_check_write+0x14/0x30 [ 750.434214] [ T9870] ? _raw_spin_lock+0x81/0xf0 [ 750.434561] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10 [ 750.434903] [ T9870] ? smb2_setup_async_request+0x293/0x580 [cifs] [ 750.435394] [ T9870] cifs_call_async+0x477/0xb00 [cifs] [ 750.435892] [ T9870] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs] [ 750.436388] [ T9870] ? __pfx_cifs_call_async+0x10/0x10 [cifs] [ 750.436881] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10 [ 750.437237] [ T9870] ? __kasan_check_write+0x14/0x30 [ 750.437579] [ T9870] ? __smb2_plain_req_init+0x933/0x1090 [cifs] [ 750.438062] [ T9870] smb2_async_writev+0x15ff/0x2460 [cifs] [ 750.438557] [ T9870] ? sched_clock_noinstr+0x9/0x10 [ 750.438906] [ T9870] ? local_clock_noinstr+0xe/0xd0 [ 750.439293] [ T9870] ? __pfx_smb2_async_writev+0x10/0x10 [cifs] [ 750.439786] [ T9870] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 750.440143] [ T9870] ? _raw_spin_unlock+0xe/0x40 [ 750.440495] [ T9870] ? cifs_pick_channel+0x242/0x370 [cifs] [ 750.440989] [ T9870] cifs_issue_write+0x256/0x610 [cifs] [ 750.441492] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs] [ 750.441987] [ T9870] netfs_do_issue_write+0xc2/0x340 [netfs] [ 750.442387] [ T9870] netfs_advance_write+0x45b/0x1270 [netfs] [ 750.442969] [ T9870] ? rolling_buffer_append+0x12d/0x440 [netfs] [ 750.443376] [ T9870] netfs_write_folio+0xd6c/0x1be0 [netfs] [ 750.443768] [ T9870] ? __kasan_check_write+0x14/0x30 [ 750.444145] [ T9870] netfs_writepages+0x2e9/0xa80 [netfs] [ 750.444541] [ T9870] ? __pfx_netfs_writepages+0x10/0x10 [netfs] [ 750.444936] [ T9870] ? exit_files+0xab/0xe0 [ 750.445312] [ T9870] ? do_exit+0x148f/0x2980 [ 750.445672] [ T9870] ? do_group_exit+0xb5/0x250 [ 750.446028] [ T9870] ? arch_do_signal_or_restart+0x92/0x630 [ 750.446402] [ T9870] ? exit_to_user_mode_loop+0x98/0x170 [ 750.446762] [ T9870] ? do_syscall_64+0x2cf/0xd80 [ 750.447132] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 750.447499] [ T9870] do_writepages+0x21f/0x590 [ 750.447859] [ T9870] ? __pfx_do_writepages+0x10/0x10 [ 750.448236] [ T9870] filemap_fdatawrite_wbc+0xe1/0x140 [ 750.448595] [ T9870] __filemap_fdatawrite_range+0xba/0x100 [ 750.448953] [ T9870] ? __pfx___filemap_fdatawrite_range+0x10/0x10 [ 750.449336] [ T9870] ? __kasan_check_write+0x14/0x30 [ 750.449697] [ T9870] filemap_write_and_wait_range+0x7d/0xf0 [ 750.450062] [ T9870] cifs_flush+0x153/0x320 [cifs] [ 750.450592] [ T9870] filp_flush+0x107/0x1a0 [ 750.450952] [ T9870] filp_close+0x14/0x30 [ 750.451322] [ T9870] put_files_struct.part.0+0x126/0x2a0 [ 750.451678] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10 [ 750.452033] [ T9870] exit_files+0xab/0xe0 [ 750.452401] [ T9870] do_exit+0x148f/0x2980 [ 750.452751] [ T9870] ? __pfx_do_exit+0x10/0x10 [ 750.453109] [ T9870] ? __kasan_check_write+0x14/0x30 [ 750.453459] [ T9870] ? _raw_spin_lock_irq+0x8a/0xf0 [ 750.453787] [ T9870] do_group_exit+0xb5/0x250 [ 750.454082] [ T9870] get_signal+0x22d3/0x22e0 [ 750.454406] [ T9870] ? __pfx_get_signal+0x10/0x10 [ 750.454709] [ T9870] ? fpregs_assert_state_consistent+0x68/0x100 [ 750.455031] [ T9870] ? folio_add_lru+0xda/0x120 [ 750.455347] [ T9870] arch_do_signal_or_restart+0x92/0x630 [ 750.455656] [ T9870] ? __pfx_arch_do_signal_or_restart+0x10/0x10 [ 750.455967] [ T9870] exit_to_user_mode_loop+0x98/0x170 [ 750.456282] [ T9870] do_syscall_64+0x2cf/0xd80 [ 750.456591] [ T9870] ? __kasan_check_read+0x11/0x20 [ 750.456897] [ T9870] ? count_memcg_events+0x1b4/0x420 [ 750.457280] [ T9870] ? handle_mm_fault+0x148/0x690 [ 750.457616] [ T9870] ? _raw_spin_lock_irq+0x8a/0xf0 [ 750.457925] [ T9870] ? __kasan_check_read+0x11/0x20 [ 750.458297] [ T9870] ? fpregs_assert_state_consistent+0x68/0x100 [ 750.458672] [ T9870] ? irqentry_exit_to_user_mode+0x2e/0x250 [ 750.459191] [ T9870] ? irqentry_exit+0x43/0x50 [ 750.459600] [ T9870] ? exc_page_fault+0x75/0xe0 [ 750.460130] [ T9870] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 750.460570] [ T9870] RIP: 0033:0x7858c94ab6e2 [ 750.461206] [ T9870] Code: Unable to access opcode bytes at 0x7858c94ab6b8. [ 750.461780] [ T9870] RSP: 002b:00007858c9248ce8 EFLAGS: 00000246 ORIG_RAX: 0000000000000022 [ 750.462327] [ T9870] RAX: fffffffffffffdfe RBX: 00007858c92496c0 RCX: 00007858c94ab6e2 [ 750.462653] [ T9870] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 750.462969] [ T9870] RBP: 00007858c9248d10 R08: 0000000000000000 R09: 0000000000000000 [ 750.463290] [ T9870] R10: 0000000000000000 R11: 0000000000000246 R12: fffffffffffffde0 [ 750.463640] [ T9870] R13: 0000000000000020 R14: 0000000000000002 R15: 00007ffc072d2230 [ 750.463965] [ T9870] [ 750.464285] [ T9870] Modules linked in: siw ib_uverbs ccm cmac nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm iw_cm ib_cm ib_core cifs_md4 netfs softdog vboxsf vboxguest cpuid intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_class intel_pmc_ssram_telemetry intel_vsec polyval_clmulni ghash_clmulni_intel sha1_ssse3 aesni_intel rapl i2c_piix4 i2c_smbus joydev input_leds mac_hid sunrpc binfmt_misc kvm_intel kvm irqbypass sch_fq_codel efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock vmw_vmci dmi_sysfs ip_tables x_tables autofs4 hid_generic vboxvideo usbhid drm_vram_helper psmouse vga16fb vgastate drm_ttm_helper serio_raw hid ahci libahci ttm pata_acpi video wmi [last unloaded: vboxguest] [ 750.467127] [ T9870] CR2: ffff8880110a2000 cc: Tom Talpey cc: linux-cifs@vger.kernel.org Reviewed-by: David Howells Reviewed-by: Tom Talpey Fixes: c45ebd636c32 ("cifs: Provide the capability to extract from ITER_FOLIOQ to RDMA SGEs") Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 0d3b6f16fe8e4aa3913a2877551be8684560eb65 Author: zhangjian Date: Thu Jun 19 09:18:29 2025 +0800 smb: client: fix first command failure during re-negotiation commit 34331d7beed7576acfc98e991c39738b96162499 upstream. after fabc4ed200f9, server_unresponsive add a condition to check whether client need to reconnect depending on server->lstrp. When client failed to reconnect for some time and abort connection, server->lstrp is updated for the last time. In the following scene, server->lstrp is too old. This cause next command failure in re-negotiation rather than waiting for re-negotiation done. 1. mount -t cifs -o username=Everyone,echo_internal=10 //$server_ip/export /mnt 2. ssh $server_ip "echo b > /proc/sysrq-trigger &" 3. ls /mnt 4. sleep 21s 5. ssh $server_ip "service firewalld stop" 6. ls # return EHOSTDOWN If the interval between 5 and 6 is too small, 6 may trigger sending negotiation request. Before backgrounding cifsd thread try to receive negotiation response from server in cifs_readv_from_socket, server_unresponsive may trigger cifs_reconnect which cause 6 to be failed: ls thread ---------------- smb2_negotiate server->tcpStatus = CifsInNegotiate compound_send_recv wait_for_compound_request cifsd thread ---------------- cifs_readv_from_socket server_unresponsive server->tcpStatus == CifsInNegotiate && jiffies > server->lstrp + 20s cifs_reconnect cifs_abort_connection: mid_state = MID_RETRY_NEEDED ls thread ---------------- cifs_sync_mid_result return EAGAIN smb2_negotiate return EHOSTDOWN Though server->lstrp means last server response time, it is updated in cifs_abort_connection and cifs_get_tcp_session. We can also update server->lstrp before switching into CifsInNegotiate state to avoid failure in 6. Fixes: 7ccc1465465d ("smb: client: fix hang in wait_for_response() for negproto") Acked-by: Paulo Alcantara (Red Hat) Acked-by: Meetakshi Setiya Signed-off-by: zhangjian Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 0faea00611589cd79c5f90e8766224a274328a85 Author: Alex Elder Date: Mon Jun 16 07:51:36 2025 -0500 i2c: k1: check for transfer error commit a6c23dac756b9541b33aa3bcd30f464df2879209 upstream. If spacemit_i2c_xfer_msg() times out waiting for a message transfer to complete, or if the hardware reports an error, it returns a negative error code (-ETIMEDOUT, -EAGAIN, -ENXIO. or -EIO). The sole caller of spacemit_i2c_xfer_msg() is spacemit_i2c_xfer(), which is the i2c_algorithm->xfer callback function. It currently does not save the value returned by spacemit_i2c_xfer_msg(). The result is that transfer errors go unreported, and a caller has no indication anything is wrong. When this code was out for review, the return value *was* checked in early versions. But for some reason, that assignment got dropped between versions 5 and 6 of the series, perhaps related to reworking the code to merge spacemit_i2c_xfer_core() into spacemit_i2c_xfer(). Simply assigning the value returned to "ret" fixes the problem. Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC") Signed-off-by: Alex Elder Cc: # v6.15+ Reviewed-by: Troy Mitchell Link: https://lore.kernel.org/r/20250616125137.1555453-1-elder@riscstar.com Signed-off-by: Andi Shyti Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 4479db143390bdcadc1561292aab579cdfa9f6c6 Author: Paul Aurich Date: Wed Nov 20 08:01:54 2024 -0800 smb: Log an error when close_all_cached_dirs fails commit a2182743a8b4969481f64aec4908ff162e8a206c upstream. Under low-memory conditions, close_all_cached_dirs() can't move the dentries to a separate list to dput() them once the locks are dropped. This will result in a "Dentry still in use" error, so add an error message that makes it clear this is what happened: [ 495.281119] CIFS: VFS: \\otters.example.com\share Out of memory while dropping dentries [ 495.281595] ------------[ cut here ]------------ [ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs] [ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0 Also, bail out of looping through all tcons as soon as a single allocation fails, since we're already in trouble, and kmalloc() attempts for subseqeuent tcons are likely to fail just like the first one did. Signed-off-by: Paul Aurich Acked-by: Bharath SM Suggested-by: Ruben Devos Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a85cc69acdcb05f8cd226b8ea0778b8e2e887e6f Author: Kan Liang Date: Thu Jun 12 07:38:18 2025 -0700 perf/x86/intel: Fix crash in icl_update_topdown_event() commit b0823d5fbacb1c551d793cbfe7af24e0d1fa45ed upstream. The perf_fuzzer found a hard-lockup crash on a RaptorLake machine: Oops: general protection fault, maybe for address 0xffff89aeceab400: 0000 CPU: 23 UID: 0 PID: 0 Comm: swapper/23 Tainted: [W]=WARN Hardware name: Dell Inc. Precision 9660/0VJ762 RIP: 0010:native_read_pmc+0x7/0x40 Code: cc e8 8d a9 01 00 48 89 03 5b cd cc cc cc cc 0f 1f ... RSP: 000:fffb03100273de8 EFLAGS: 00010046 .... Call Trace: icl_update_topdown_event+0x165/0x190 ? ktime_get+0x38/0xd0 intel_pmu_read_event+0xf9/0x210 __perf_event_read+0xf9/0x210 CPUs 16-23 are E-core CPUs that don't support the perf metrics feature. The icl_update_topdown_event() should not be invoked on these CPUs. It's a regression of commit: f9bdf1f95339 ("perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read") The bug introduced by that commit is that the is_topdown_event() function is mistakenly used to replace the is_topdown_count() call to check if the topdown functions for the perf metrics feature should be invoked. Fix it. Fixes: f9bdf1f95339 ("perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read") Closes: https://lore.kernel.org/lkml/352f0709-f026-cd45-e60c-60dfd97f73f3@maine.edu/ Reported-by: Vince Weaver Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Tested-by: Vince Weaver Cc: stable@vger.kernel.org # v6.15+ Link: https://lore.kernel.org/r/20250612143818.2889040-1-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 7141a578089e140164532f860d3672e6b5e67e2b Author: Akhil R Date: Tue Jun 3 21:00:20 2025 +0530 dt-bindings: i2c: nvidia,tegra20-i2c: Specify the required properties commit 903cc7096db22f889d48e2cee8840709ce04fdac upstream. Specify the properties which are essential and which are not for the Tegra I2C driver to function correctly. This was not added correctly when the TXT binding was converted to yaml. All the existing DT nodes have these properties already and hence this does not break the ABI. dmas and dma-names which were specified as a must in the TXT binding is now made optional since the driver can work in PIO mode if dmas are missing. Fixes: f10a9b722f80 ("dt-bindings: i2c: tegra: Convert to json-schema”) Signed-off-by: Akhil R Cc: # v5.17+ Reviewed-by: Krzysztof Kozlowski Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20250603153022.39434-1-akhilrajeev@nvidia.com Signed-off-by: Greg Kroah-Hartman commit 47087d99fe52406f42a193f46ff7bc75afbfb218 Author: Avadhut Naik Date: Fri Jun 13 00:51:35 2025 +0000 EDAC/amd64: Correct number of UMCs for family 19h models 70h-7fh commit b2e673ae53ef4b943f68585207a5f21cfc9a0714 upstream. AMD's Family 19h-based Models 70h-7fh support 4 unified memory controllers (UMC) per processor die. The amd64_edac driver, however, assumes only 2 UMCs are supported since max_mcs variable for the models has not been explicitly set to 4. The same results in incomplete or incorrect memory information being logged to dmesg by the module during initialization in some instances. Fixes: 6c79e42169fe ("EDAC/amd64: Add support for ECC on family 19h model 60h-7Fh") Closes: https://lore.kernel.org/all/27dc093f-ce27-4c71-9e81-786150a040b6@reox.at/ Reported-by: reox Signed-off-by: Avadhut Naik Signed-off-by: Borislav Petkov (AMD) Cc: stable@kernel.org Link: https://lore.kernel.org/20250613005233.2330627-1-avadhut.naik@amd.com Signed-off-by: Greg Kroah-Hartman commit 094074d4fb693f1fc66e4024189eaeb9d93cc6b2 Author: Dave Hansen Date: Tue Jun 10 15:24:20 2025 -0700 x86/mm: Disable INVLPGB when PTI is enabled commit 94a17f2dc90bc7eae36c0f478515d4bd1c23e877 upstream. PTI uses separate ASIDs (aka. PCIDs) for kernel and user address spaces. When the kernel needs to flush the user address space, it just sets a bit in a bitmap and then flushes the entire PCID on the next switch to userspace. This bitmap is a single 'unsigned long' which is plenty for all 6 dynamic ASIDs. But, unfortunately, the INVLPGB support brings along a bunch more user ASIDs, as many as ~2k more. The bitmap can't address that many. Fortunately, the bitmap is only needed for PTI and all the CPUs with INVLPGB are AMD CPUs that aren't vulnerable to Meltdown and don't need PTI. The only way someone can run into an issue in practice is by booting with pti=on on a newer AMD CPU. Disable INVLPGB if PTI is enabled. Avoid overrunning the small bitmap. Note: this will be fixed up properly by making the bitmap bigger. For now, just avoid the mostly theoretical bug. Fixes: 4afeb0ed1753 ("x86/mm: Enable broadcast TLB invalidation for multi-threaded processes") Signed-off-by: Dave Hansen Acked-by: Rik van Riel Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250610222420.E8CBF472%40davehans-spike.ostc.intel.com Signed-off-by: Greg Kroah-Hartman commit 0e880ca204b32d1c8605107fdcddc70ae8a67e0d Author: Mark Rutland Date: Tue Jun 17 14:37:12 2025 +0100 KVM: arm64: VHE: Synchronize restore of host debug registers commit cade3d57e456e69f67aa9894bf89dc8678796bb7 upstream. When KVM runs in non-protected VHE mode, there's no context synchronization event between __debug_switch_to_host() restoring the host debug registers and __kvm_vcpu_run() unmasking debug exceptions. Due to this, it's theoretically possible for the host to take an unexpected debug exception due to the stale guest configuration. This cannot happen in NVHE/HVHE mode as debug exceptions are masked in the hyp code, and the exception return to the host will provide the necessary context synchronization before debug exceptions can be taken. For now, avoid the problem by adding an ISB after VHE hyp code restores the host debug registers. Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Fuad Tabba Cc: Marc Zyngier Cc: Mark Brown Cc: Oliver Upton Cc: Will Deacon Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250617133718.4014181-2-mark.rutland@arm.com Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit fe13cc888661d33dcaf3b968021a00c8a59906e5 Author: Jakub Kicinski Date: Wed Jun 18 10:17:46 2025 -0700 tools: ynl: fix mixing ops and notifications on one socket [ Upstream commit 9738280aae592b579a25b5b1b6584c894827d3c7 ] The multi message support loosened the connection between the request and response handling, as we can now submit multiple requests before we start processing responses. Passing the attr set to NlMsgs decoding no longer makes sense (if it ever did), attr set may differ message by messsage. Isolate the part of decoding responsible for attr-set specific interpretation and call it once we identified the correct op. Without this fix performing SET operation on an ethtool socket, while being subscribed to notifications causes: # File "tools/net/ynl/pyynl/lib/ynl.py", line 1096, in _op # Exception| return self._ops(ops)[0] # Exception| ~~~~~~~~~^^^^^ # File "tools/net/ynl/pyynl/lib/ynl.py", line 1040, in _ops # Exception| nms = NlMsgs(reply, attr_space=op.attr_set) # Exception| ^^^^^^^^^^^ The value of op we use on line 1040 is stale, it comes form the previous loop. If a notification comes before a response we will update op to None and the next iteration thru the loop will break with the trace above. Fixes: 6fda63c45fe8 ("tools/net/ynl: fix cli.py --subscribe feature") Fixes: ba8be00f68f5 ("tools/net/ynl: Add multi message support to ynl") Reviewed-by: Donald Hunter Link: https://patch.msgid.link/20250618171746.1201403-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7dadea9ff0a85248d03cd5ca1bf6635a2c06a032 Author: Donald Hunter Date: Fri May 23 11:30:31 2025 +0100 tools: ynl: parse extack for sub-messages [ Upstream commit 09d7ff0694ea133c50ad905fd6e548c13f8af458 ] Extend the Python YNL extack decoding to handle sub-messages in the same way that YNL C does. This involves retaining the input values so that they are available during extack decoding. ./tools/net/ynl/pyynl/cli.py --family rt-link --do newlink --create \ --json '{ "linkinfo": {"kind": "netkit", "data": {"policy": 10} } }' Netlink error: Invalid argument nl_len = 92 (76) nl_flags = 0x300 nl_type = 2 error: -22 extack: {'msg': 'Provided default xmit policy not supported', 'bad-attr': '.linkinfo.data(netkit).policy'} Signed-off-by: Donald Hunter Link: https://patch.msgid.link/20250523103031.80236-1-donald.hunter@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 9738280aae59 ("tools: ynl: fix mixing ops and notifications on one socket") Signed-off-by: Sasha Levin commit 9b9aeb3ada44d8abea1e31e4446113f460848ae4 Author: Eric Dumazet Date: Wed Jun 18 14:08:44 2025 +0000 net: atm: fix /proc/net/atm/lec handling [ Upstream commit d03b79f459c7935cff830d98373474f440bd03ae ] /proc/net/atm/lec must ensure safety against dev_lec[] changes. It appears it had dev_put() calls without prior dev_hold(), leading to imbalance and UAF. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Acked-by: Francois Romieu # Minor atm contributor Link: https://patch.msgid.link/20250618140844.1686882-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 64b378db28a967f7b271b055380c2360279aa424 Author: Eric Dumazet Date: Wed Jun 18 14:08:43 2025 +0000 net: atm: add lec_mutex [ Upstream commit d13a3824bfd2b4774b671a75cf766a16637a0e67 ] syzbot found its way in net/atm/lec.c, and found an error path in lecd_attach() could leave a dangling pointer in dev_lec[]. Add a mutex to protect dev_lecp[] uses from lecd_attach(), lec_vcc_attach() and lec_mcast_attach(). Following patch will use this mutex for /proc/net/atm/lec. BUG: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline] BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008 Read of size 8 at addr ffff88807c7b8e68 by task syz.1.17/6142 CPU: 1 UID: 0 PID: 6142 Comm: syz.1.17 Not tainted 6.16.0-rc1-syzkaller-00239-g08215f5486ec #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xcd/0x680 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 lecd_attach net/atm/lec.c:751 [inline] lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 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+0x18e/0x210 fs/ioctl.c:893 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 Allocated by task 6132: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4328 [inline] __kvmalloc_node_noprof+0x27b/0x620 mm/slub.c:5015 alloc_netdev_mqs+0xd2/0x1570 net/core/dev.c:11711 lecd_attach net/atm/lec.c:737 [inline] lane_ioctl+0x17db/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 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+0x18e/0x210 fs/ioctl.c:893 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 Freed by task 6132: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x51/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x2b4/0x4d0 mm/slub.c:4842 free_netdev+0x6c5/0x910 net/core/dev.c:11892 lecd_attach net/atm/lec.c:744 [inline] lane_ioctl+0x1ce8/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 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+0x18e/0x210 fs/ioctl.c:893 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+8b64dec3affaed7b3af5@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6852c6f6.050a0220.216029.0018.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20250618140844.1686882-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9be6eb783497af623e2a02aaeec4a9e8e1519578 Author: David Thompson Date: Wed Jun 18 13:59:02 2025 +0000 mlxbf_gige: return EPROBE_DEFER if PHY IRQ is not available [ Upstream commit e7ea5f5b1858ddb96b152584d5fe06e6fc623e89 ] The message "Error getting PHY irq. Use polling instead" is emitted when the mlxbf_gige driver is loaded by the kernel before the associated gpio-mlxbf driver, and thus the call to get the PHY IRQ fails since it is not yet available. The driver probe() must return -EPROBE_DEFER if acpi_dev_gpio_irq_get_by() returns the same. Fixes: 6c2a6ddca763 ("net: mellanox: mlxbf_gige: Replace non-standard interrupt handling") Signed-off-by: David Thompson Reviewed-by: Asmaa Mnebhi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250618135902.346-1-davthompson@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d092c7fd8e220b23d6c47e03d7d0cc79e731f379 Author: Kuniyuki Iwashima Date: Tue Jun 17 15:40:42 2025 -0700 calipso: Fix null-ptr-deref in calipso_req_{set,del}attr(). [ Upstream commit 10876da918fa1aec0227fb4c67647513447f53a9 ] syzkaller reported a null-ptr-deref in sock_omalloc() while allocating a CALIPSO option. [0] The NULL is of struct sock, which was fetched by sk_to_full_sk() in calipso_req_setattr(). Since commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"), reqsk->rsk_listener could be NULL when SYN Cookie is returned to its client, as hinted by the leading SYN Cookie log. Here are 3 options to fix the bug: 1) Return 0 in calipso_req_setattr() 2) Return an error in calipso_req_setattr() 3) Alaways set rsk_listener 1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie for CALIPSO. 3) is also no go as there have been many efforts to reduce atomic ops and make TCP robust against DDoS. See also commit 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under synflood"). As of the blamed commit, SYN Cookie already did not need refcounting, and no one has stumbled on the bug for 9 years, so no CALIPSO user will care about SYN Cookie. Let's return an error in calipso_req_setattr() and calipso_req_delattr() in the SYN Cookie case. This can be reproduced by [1] on Fedora and now connect() of nc times out. [0]: TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline] RIP: 0010:sock_net include/net/sock.h:655 [inline] RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806 Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b RSP: 0018:ffff88811af89038 EFLAGS: 00010216 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400 RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030 RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e R10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000 R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050 FS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0 PKRU: 80000000 Call Trace: ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288 calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204 calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597 netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249 selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342 selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551 security_inet_conn_request+0x50/0xa0 security/security.c:4945 tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825 tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275 tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328 tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781 tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667 tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904 ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436 ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491 dst_input include/net/dst.h:469 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ipv6_rcv+0xf9/0x490 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x12e/0x1f0 net/core/dev.c:5896 __netif_receive_skb+0x1d/0x170 net/core/dev.c:6009 process_backlog+0x41e/0x13b0 net/core/dev.c:6357 __napi_poll+0xbd/0x710 net/core/dev.c:7191 napi_poll net/core/dev.c:7260 [inline] net_rx_action+0x9de/0xde0 net/core/dev.c:7382 handle_softirqs+0x19a/0x770 kernel/softirq.c:561 do_softirq.part.0+0x36/0x70 kernel/softirq.c:462 do_softirq arch/x86/include/asm/preempt.h:26 [inline] __local_bh_enable_ip+0xf1/0x110 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0xc2a/0x3c40 net/core/dev.c:4679 dev_queue_xmit include/linux/netdevice.h:3313 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip6_finish_output2+0xd69/0x1f80 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x5dc/0xd60 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x24b/0x8d0 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:459 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip6_xmit+0xbbc/0x20d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x39a/0x720 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x1a7b/0x3b40 net/ipv4/tcp_output.c:1471 tcp_transmit_skb net/ipv4/tcp_output.c:1489 [inline] tcp_send_syn_data net/ipv4/tcp_output.c:4059 [inline] tcp_connect+0x1c0c/0x4510 net/ipv4/tcp_output.c:4148 tcp_v6_connect+0x156c/0x2080 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x3a7/0xed0 net/ipv4/af_inet.c:677 tcp_sendmsg_fastopen+0x3e2/0x710 net/ipv4/tcp.c:1039 tcp_sendmsg_locked+0x1e82/0x3570 net/ipv4/tcp.c:1091 tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1358 inet6_sendmsg+0xb9/0x150 net/ipv6/af_inet6.c:659 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0xf4/0x2a0 net/socket.c:733 __sys_sendto+0x29a/0x390 net/socket.c:2187 __do_sys_sendto net/socket.c:2194 [inline] __se_sys_sendto net/socket.c:2190 [inline] __x64_sys_sendto+0xe1/0x1c0 net/socket.c:2190 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xc3/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f06553c47ed Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f0653a06fc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f0655605fa0 RCX: 00007f06553c47ed RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000000000b RBP: 00007f065545db38 R08: 0000200000000140 R09: 000000000000001c R10: f7384d4ea84b01bd R11: 0000000000000246 R12: 0000000000000000 R13: 00007f0655605fac R14: 00007f0655606038 R15: 00007f06539e7000 Modules linked in: [1]: dnf install -y selinux-policy-targeted policycoreutils netlabel_tools procps-ng nmap-ncat mount -t selinuxfs none /sys/fs/selinux load_policy netlabelctl calipso add pass doi:1 netlabelctl map del default netlabelctl map add default address:::1 protocol:calipso,1 sysctl net.ipv4.tcp_syncookies=2 nc -l ::1 80 & nc ::1 80 Fixes: e1adea927080 ("calipso: Allow request sockets to be relabelled by the lsm.") Reported-by: syzkaller Reported-by: John Cheung Closes: https://lore.kernel.org/netdev/CAP=Rh=MvfhrGADy+-WJiftV2_WzMH4VEhEFmeT28qY+4yxNu4w@mail.gmail.com/ Signed-off-by: Kuniyuki Iwashima Acked-by: Paul Moore Link: https://patch.msgid.link/20250617224125.17299-1-kuni1840@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e8f9b2d717904f78a0f22ffdf3b8f4424b5973c0 Author: Vinay Belgaumkar Date: Thu Jun 12 00:09:01 2025 -0700 drm/xe/bmg: Update Wa_16023588340 [ Upstream commit 16c1241b08751a67cd7a0221ea9f82b0b02806f4 ] This allows for additional L2 caching modes. Fixes: 01570b446939 ("drm/xe/bmg: implement Wa_16023588340") Cc: Matthew Auld Reviewed-by: Matthew Auld Signed-off-by: Vinay Belgaumkar Link: https://lore.kernel.org/r/20250612-wa-14022085890-v4-2-94ba5dcc1e30@intel.com Signed-off-by: Lucas De Marchi (cherry picked from commit 6ab42fa03d4c88a0ddf5e56e62794853b198e7bf) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit e2b2b7cf6368580114851cb3932f2ad9fbf23386 Author: Ronnie Sahlberg Date: Thu Jun 19 12:10:31 2025 +1000 ublk: santizize the arguments from userspace when adding a device [ Upstream commit 8c8472855884355caf3d8e0c50adf825f83454b2 ] Sanity check the values for queue depth and number of queues we get from userspace when adding a device. Signed-off-by: Ronnie Sahlberg Reviewed-by: Ming Lei Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Fixes: 62fe99cef94a ("ublk: add read()/write() support for ublk char device") Link: https://lore.kernel.org/r/20250619021031.181340-1-ronniesahlberg@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4da0d23516857230b8e9b3022e25422ee2e2ba80 Author: Alexey Kodanev Date: Mon Jun 16 11:37:43 2025 +0000 net: lan743x: fix potential out-of-bounds write in lan743x_ptp_io_event_clock_get() [ Upstream commit e353b0854d3a1a31cb061df8d022fbfea53a0f24 ] Before calling lan743x_ptp_io_event_clock_get(), the 'channel' value is checked against the maximum value of PCI11X1X_PTP_IO_MAX_CHANNELS(8). This seems correct and aligns with the PTP interrupt status register (PTP_INT_STS) specifications. However, lan743x_ptp_io_event_clock_get() writes to ptp->extts[] with only LAN743X_PTP_N_EXTTS(4) elements, using channel as an index: lan743x_ptp_io_event_clock_get(..., u8 channel,...) { ... /* Update Local timestamp */ extts = &ptp->extts[channel]; extts->ts.tv_sec = sec; ... } To avoid an out-of-bounds write and utilize all the supported GPIO inputs, set LAN743X_PTP_N_EXTTS to 8. Detected using the static analysis tool - Svace. Fixes: 60942c397af6 ("net: lan743x: Add support for PTP-IO Event Input External Timestamp (extts)") Signed-off-by: Alexey Kodanev Reviewed-by: Jacob Keller Acked-by: Rengarajan S Link: https://patch.msgid.link/20250616113743.36284-1-aleksei.kodanev@bell-sw.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0a211e23852019ef55c70094524e87a944accbb5 Author: Jakub Kicinski Date: Mon Jun 16 12:55:10 2025 -0700 eth: fbnic: avoid double free when failing to DMA-map FW msg [ Upstream commit 5bd1bafd4474ee26f504b41aba11f3e2a1175b88 ] The semantics are that caller of fbnic_mbx_map_msg() retains the ownership of the message on error. All existing callers dutifully free the page. Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism") Reviewed-by: Alexander Duyck Signed-off-by: Jakub Kicinski Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250616195510.225819-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6f5ab7e5be6a6e1e73604ff3f49b828f86121625 Author: David Wei Date: Tue Jun 17 14:21:02 2025 -0700 tcp: fix passive TFO socket having invalid NAPI ID [ Upstream commit dbe0ca8da1f62b6252e7be6337209f4d86d4a914 ] There is a bug with passive TFO sockets returning an invalid NAPI ID 0 from SO_INCOMING_NAPI_ID. Normally this is not an issue, but zero copy receive relies on a correct NAPI ID to process sockets on the right queue. Fix by adding a sk_mark_napi_id_set(). Fixes: e5907459ce7e ("tcp: Record Rx hash and NAPI ID in tcp_child_process") Signed-off-by: David Wei Reviewed-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20250617212102.175711-5-dw@davidwei.uk Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0f4a72fb266e48dbe928e1d936eab149e4ac3e1b Author: Haixia Qu Date: Tue Jun 17 05:56:24 2025 +0000 tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer [ Upstream commit f82727adcf2992822e12198792af450a76ebd5ef ] The reproduction steps: 1. create a tun interface 2. enable l2 bearer 3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun tipc: Started in network mode tipc: Node identity 8af312d38a21, cluster identity 4711 tipc: Enabled bearer , priority 1 Oops: general protection fault KASAN: null-ptr-deref in range CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT Hardware name: QEMU Ubuntu 24.04 PC RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0 the ub was in fact a struct dev. when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL or other media when other thread changes it. fix this by checking media_id. Fixes: 832629ca5c313 ("tipc: add UDP remoteip dump to netlink API") Signed-off-by: Haixia Qu Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20250617055624.2680-1-hxqu@hillstonenet.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 482c3fc50bcfef1365cce9a259ed7820b9165f87 Author: Hariprasad Kelam Date: Tue Jun 17 12:04:02 2025 +0530 Octeontx2-pf: Fix Backpresure configuration [ Upstream commit 9ac8d0c640a161486eaf71d1999ee990fad62947 ] NIX block can receive packets from multiple links such as MAC (RPM), LBK and CPT. ----------------- RPM --| NIX | ----------------- | | LBK Each link supports multiple channels for example RPM link supports 16 channels. In case of link oversubsribe, NIX will assert backpressure on receive channels. The previous patch considered a single channel per link, resulting in backpressure not being enabled on the remaining channels Fixes: a7ef63dbd588 ("octeontx2-af: Disable backpressure between CPT and NIX") Signed-off-by: Hariprasad Kelam Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250617063403.3582210-1-hkelam@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2be6caa9fa8408f5fe0f4491617dd45a203a68cf Author: Jesse.Zhang Date: Thu May 29 11:27:37 2025 +0800 drm/amdkfd: move SDMA queue reset capability check to node_show [ Upstream commit a55737dab6ba63eb4241e9c6547629058af31e12 ] Relocate the per-SDMA queue reset capability check from kfd_topology_set_capabilities() to node_show() to ensure we read the latest value of sdma.supported_reset after all IP blocks are initialized. Fixes: ceb7114c961b ("drm/amdkfd: flag per-sdma queue reset supported to user space") Reviewed-by: Jonathan Kim Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit e17df7b086cf908cedd919f448da9e00028419bb) Signed-off-by: Sasha Levin commit b2e92c42ef5931723a6c9defa236736363467f7e Author: Penglei Jiang Date: Tue Jun 17 09:56:44 2025 -0700 io_uring: fix potential page leak in io_sqe_buffer_register() [ Upstream commit e1c75831f682eef0f68b35723437146ed86070b1 ] If allocation of the 'imu' fails, then the existing pages aren't unpinned in the error path. This is mostly a theoretical issue, requiring fault injection to hit. Move unpin_user_pages() to unified error handling to fix the page leak issue. Fixes: d8c2237d0aa9 ("io_uring: add io_pin_pages() helper") Signed-off-by: Penglei Jiang Link: https://lore.kernel.org/r/20250617165644.79165-1-superman.xpt@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8041641ef8b0154888985867c36de31981c5f782 Author: Neal Cardwell Date: Fri Jun 13 15:30:56 2025 -0400 tcp: fix tcp_packet_delayed() for tcp_is_non_sack_preventing_reopen() behavior [ Upstream commit d0fa59897e049e84432600e86df82aab3dce7aa5 ] After the following commit from 2024: commit e37ab7373696 ("tcp: fix to allow timestamp undo if no retransmits were sent") ...there was buggy behavior where TCP connections without SACK support could easily see erroneous undo events at the end of fast recovery or RTO recovery episodes. The erroneous undo events could cause those connections to suffer repeated loss recovery episodes and high retransmit rates. The problem was an interaction between the non-SACK behavior on these connections and the undo logic. The problem is that, for non-SACK connections at the end of a loss recovery episode, if snd_una == high_seq, then tcp_is_non_sack_preventing_reopen() holds steady in CA_Recovery or CA_Loss, but clears tp->retrans_stamp to 0. Then upon the next ACK the "tcp: fix to allow timestamp undo if no retransmits were sent" logic saw the tp->retrans_stamp at 0 and erroneously concluded that no data was retransmitted, and erroneously performed an undo of the cwnd reduction, restoring cwnd immediately to the value it had before loss recovery. This caused an immediate burst of traffic and build-up of queues and likely another immediate loss recovery episode. This commit fixes tcp_packet_delayed() to ignore zero retrans_stamp values for non-SACK connections when snd_una is at or above high_seq, because tcp_is_non_sack_preventing_reopen() clears retrans_stamp in this case, so it's not a valid signal that we can undo. Note that the commit named in the Fixes footer restored long-present behavior from roughly 2005-2019, so apparently this bug was present for a while during that era, and this was simply not caught. Fixes: e37ab7373696 ("tcp: fix to allow timestamp undo if no retransmits were sent") Reported-by: Eric Wheeler Closes: https://lore.kernel.org/netdev/64ea9333-e7f9-0df-b0f2-8d566143acab@ewheeler.net/ Signed-off-by: Neal Cardwell Co-developed-by: Yuchung Cheng Signed-off-by: Yuchung Cheng Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c9260c837de1d2b454960a4a2e44a81272fbcd22 Author: Kuniyuki Iwashima Date: Mon Jun 16 11:21:14 2025 -0700 atm: atmtcp: Free invalid length skb in atmtcp_c_send(). [ Upstream commit 2f370ae1fb6317985f3497b1bb80d457508ca2f7 ] syzbot reported the splat below. [0] vcc_sendmsg() copies data passed from userspace to skb and passes it to vcc->dev->ops->send(). atmtcp_c_send() accesses skb->data as struct atmtcp_hdr after checking if skb->len is 0, but it's not enough. Also, when skb->len == 0, skb and sk (vcc) were leaked because dev_kfree_skb() is not called and sk_wmem_alloc adjustment is missing to revert atm_account_tx() in vcc_sendmsg(), which is expected to be done in atm_pop_raw(). Let's properly free skb with an invalid length in atmtcp_c_send(). [0]: BUG: KMSAN: uninit-value in atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 vcc_sendmsg+0xd7c/0xff0 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] kmem_cache_alloc_node_noprof+0x818/0xf00 mm/slub.c:4249 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:670 alloc_skb include/linux/skbuff.h:1336 [inline] vcc_sendmsg+0xb40/0xff0 net/atm/common.c:628 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 5798 Comm: syz-executor192 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(undef) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+1d3c235276f62963e93a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1d3c235276f62963e93a Tested-by: syzbot+1d3c235276f62963e93a@syzkaller.appspotmail.com Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250616182147.963333-2-kuni1840@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f19cbd84e645e39bc3228e1191bb151ef0ffac8c Author: Kuniyuki Iwashima Date: Mon Jun 16 13:15:12 2025 -0700 mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu(). [ Upstream commit 6dbb0d97c5096072c78a6abffe393584e57ae945 ] As syzbot reported [0], mpls_route_input_rcu() can be called from mpls_getroute(), where is under RTNL. net->mpls.platform_label is only updated under RTNL. Let's use rcu_dereference_rtnl() in mpls_route_input_rcu() to silence the splat. [0]: WARNING: suspicious RCU usage 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted ---------------------------- net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by syz.2.4451/17730: #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline] #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961 stack backtrace: CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865 mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84 mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381 rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964 netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmmsg+0x200/0x420 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0a2818e969 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969 RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268 Fixes: 0189197f4416 ("mpls: Basic routing support") Reported-by: syzbot+8a583bdd1a5cc0b0e068@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/68507981.a70a0220.395abc.01ef.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250616201532.1036568-1-kuni1840@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 11ef72b3312752c2ff92f3c1e64912be3228ed36 Author: Dmitry Antipov Date: Mon Jun 16 21:12:05 2025 +0300 wifi: carl9170: do not ping device which has failed to load firmware [ Upstream commit 15d25307692312cec4b57052da73387f91a2e870 ] Syzkaller reports [1, 2] crashes caused by an attempts to ping the device which has failed to load firmware. Since such a device doesn't pass 'ieee80211_register_hw()', an internal workqueue managed by 'ieee80211_queue_work()' is not yet created and an attempt to queue work on it causes null-ptr-deref. [1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff [2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217 Fixes: e4a668c59080 ("carl9170: fix spurious restart due to high latency") Signed-off-by: Dmitry Antipov Acked-by: Christian Lamparter Link: https://patch.msgid.link/20250616181205.38883-1-dmantipov@yandex.ru Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 652b6a5e28006e1dbedb6a8884eb37444a232c0a Author: Vladimir Oltean Date: Fri Jun 13 20:47:49 2025 +0300 ptp: allow reading of currently dialed frequency to succeed on free-running clocks [ Upstream commit aa112cbc5f0ac6f3b44d829005bf34005d9fe9bb ] There is a bug in ptp_clock_adjtime() which makes it refuse the operation even if we just want to read the current clock dialed frequency, not modify anything (tx->modes == 0). That should be possible even if the clock is free-running. For context, the kernel UAPI is the same for getting and setting the frequency of a POSIX clock. For example, ptp4l errors out at clock_create() -> clockadj_get_freq() -> clock_adjtime() time, when it should logically only have failed on actual adjustments to the clock, aka if the clock was configured as slave. But in master mode it should work. This was discovered when examining the issue described in the previous commit, where ptp_clock_freerun() returned true despite n_vclocks being zero. Fixes: 73f37068d540 ("ptp: support ptp physical/virtual clocks conversion") Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20250613174749.406826-3-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 64f52f0d08cb14814c460ab761bc214bdfbc043b Author: Vladimir Oltean Date: Fri Jun 13 20:47:48 2025 +0300 ptp: fix breakage after ptp_vclock_in_use() rework [ Upstream commit 5ab73b010cad294851e558f1d4714a85c6f206c7 ] What is broken -------------- ptp4l, and any other application which calls clock_adjtime() on a physical clock, is greeted with error -EBUSY after commit 87f7ce260a3c ("ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()"). Explanation for the breakage ---------------------------- The blamed commit was based on the false assumption that ptp_vclock_in_use() callers already test for n_vclocks prior to calling this function. This is notably incorrect for the code path below, in which there is, in fact, no n_vclocks test: ptp_clock_adjtime() -> ptp_clock_freerun() -> ptp_vclock_in_use() The result is that any clock adjustment on any physical clock is now impossible. This is _despite_ there not being any vclock over this physical clock. $ ptp4l -i eno0 -2 -P -m ptp4l[58.425]: selected /dev/ptp0 as PTP clock [ 58.429749] ptp: physical clock is free running ptp4l[58.431]: Failed to open /dev/ptp0: Device or resource busy failed to create a clock $ cat /sys/class/ptp/ptp0/n_vclocks 0 The patch makes the ptp_vclock_in_use() function say "if it's not a virtual clock, then this physical clock does have virtual clocks on top". Then ptp_clock_freerun() uses this information to say "this physical clock has virtual clocks on top, so it must stay free-running". Then ptp_clock_adjtime() uses this information to say "well, if this physical clock has to be free-running, I can't do it, return -EBUSY". Simply put, ptp_vclock_in_use() cannot be simplified so as to remove the test whether vclocks are in use. What did the blamed commit intend to fix ---------------------------------------- The blamed commit presents a lockdep warning stating "possible recursive locking detected", with the n_vclocks_store() and ptp_clock_unregister() functions involved. The recursive locking seems this: n_vclocks_store() -> mutex_lock_interruptible(&ptp->n_vclocks_mux) // 1 -> device_for_each_child_reverse(..., unregister_vclock) -> unregister_vclock() -> ptp_vclock_unregister() -> ptp_clock_unregister() -> ptp_vclock_in_use() -> mutex_lock_interruptible(&ptp->n_vclocks_mux) // 2 The issue can be triggered by creating and then deleting vclocks: $ echo 2 > /sys/class/ptp/ptp0/n_vclocks $ echo 0 > /sys/class/ptp/ptp0/n_vclocks But note that in the original stack trace, the address of the first lock is different from the address of the second lock. This is because at step 1 marked above, &ptp->n_vclocks_mux is the lock of the parent (physical) PTP clock, and at step 2, the lock is of the child (virtual) PTP clock. They are different locks of different devices. In this situation there is no real deadlock, the lockdep warning is caused by the fact that the mutexes have the same lock class on both the parent and the child. Functionally it is fine. Proposed alternative solution ----------------------------- We must reintroduce the body of ptp_vclock_in_use() mostly as it was structured prior to the blamed commit, but avoid the lockdep warning. Based on the fact that vclocks cannot be nested on top of one another (ptp_is_attribute_visible() hides n_vclocks for virtual clocks), we already know that ptp->n_vclocks is zero for a virtual clock. And ptp->is_virtual_clock is a runtime invariant, established at ptp_clock_register() time and never changed. There is no need to serialize on any mutex in order to read ptp->is_virtual_clock, and we take advantage of that by moving it outside the lock. Thus, virtual clocks do not need to acquire &ptp->n_vclocks_mux at all, and step 2 in the code walkthrough above can simply go away. We can simply return false to the question "ptp_vclock_in_use(a virtual clock)". Other notes ----------- Releasing &ptp->n_vclocks_mux before ptp_vclock_in_use() returns execution seems racy, because the returned value can become stale as soon as the function returns and before the return value is used (i.e. n_vclocks_store() can run any time). The locking requirement should somehow be transferred to the caller, to ensure a longer life time for the returned value, but this seems out of scope for this severe bug fix. Because we are also fixing up the logic from the original commit, there is another Fixes: tag for that. Fixes: 87f7ce260a3c ("ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()") Fixes: 73f37068d540 ("ptp: support ptp physical/virtual clocks conversion") Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20250613174749.406826-2-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d44882e0c50574057f3cb0c7ef7b6e7568b85988 Author: Pavan Chebbi Date: Fri Jun 13 16:18:41 2025 -0700 bnxt_en: Update MRU and RSS table of RSS contexts on queue reset [ Upstream commit 5dacc94c6fe61cde6f700e95cf35af9944b022c4 ] The commit under the Fixes tag below which updates the VNICs' RSS and MRU during .ndo_queue_start(), needs to be extended to cover any non-default RSS contexts which have their own VNICs. Without this step, packets that are destined to a non-default RSS context may be dropped after .ndo_queue_start(). We further optimize this scheme by updating the VNIC only if the RX ring being restarted is in the RSS table of the VNIC. Updating the VNIC (in particular setting the MRU to 0) will momentarily stop all traffic to all rings in the RSS table. Any VNIC that has the RX ring excluded from the RSS table can skip this step and avoid the traffic disruption. Note that this scheme is just an improvement. A VNIC with multiple rings in the RSS table will still see traffic disruptions to all rings in the RSS table when one of the rings is being restarted. We are working on a FW scheme that will improve upon this further. Fixes: 5ac066b7b062 ("bnxt_en: Fix queue start to update vnic RSS table") Reported-by: David Wei Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Link: https://patch.msgid.link/20250613231841.377988-4-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6b69658f49c7d80e0fd2d2177f77201cd272aee1 Author: Pavan Chebbi Date: Fri Jun 13 16:18:40 2025 -0700 bnxt_en: Add a helper function to configure MRU and RSS [ Upstream commit e11baaea94e2923739a98abeee85eb0667c04fd3 ] Add a new helper function that will configure MRU and RSS table of a VNIC. This will be useful when we configure both on a VNIC when resetting an RX ring. This function will be used again in the next bug fix patch where we have to reconfigure VNICs for RSS contexts. Suggested-by: Michael Chan Reviewed-by: Simon Horman Reviewed-by: David Wei Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Link: https://patch.msgid.link/20250613231841.377988-3-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5dacc94c6fe6 ("bnxt_en: Update MRU and RSS table of RSS contexts on queue reset") Signed-off-by: Sasha Levin commit cca4ffd4a5b768752b91f6f75d77928e47886913 Author: Kalesh AP Date: Fri Jun 13 16:18:39 2025 -0700 bnxt_en: Fix double invocation of bnxt_ulp_stop()/bnxt_ulp_start() [ Upstream commit 1e9ac33fa271be0d2480fd732f9642d81542500b ] Before the commit under the Fixes tag below, bnxt_ulp_stop() and bnxt_ulp_start() were always invoked in pairs. After that commit, the new bnxt_ulp_restart() can be invoked after bnxt_ulp_stop() has been called. This may result in the RoCE driver's aux driver .suspend() method being invoked twice. The 2nd bnxt_re_suspend() call will crash when it dereferences a NULL pointer: (NULL ib_device): Handle device suspend call BUG: kernel NULL pointer dereference, address: 0000000000000b78 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 20 UID: 0 PID: 181 Comm: kworker/u96:5 Tainted: G S 6.15.0-rc1 #4 PREEMPT(voluntary) Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017 Workqueue: bnxt_pf_wq bnxt_sp_task [bnxt_en] RIP: 0010:bnxt_re_suspend+0x45/0x1f0 [bnxt_re] Code: 8b 05 a7 3c 5b f5 48 89 44 24 18 31 c0 49 8b 5c 24 08 4d 8b 2c 24 e8 ea 06 0a f4 48 c7 c6 04 60 52 c0 48 89 df e8 1b ce f9 ff <48> 8b 83 78 0b 00 00 48 8b 80 38 03 00 00 a8 40 0f 85 b5 00 00 00 RSP: 0018:ffffa2e84084fd88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffffffb4b6b934 RDI: 00000000ffffffff RBP: ffffa1760954c9c0 R08: 0000000000000000 R09: c0000000ffffdfff R10: 0000000000000001 R11: ffffa2e84084fb50 R12: ffffa176031ef070 R13: ffffa17609775000 R14: ffffa17603adc180 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa17daa397000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000b78 CR3: 00000004aaa30003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bnxt_ulp_stop+0x69/0x90 [bnxt_en] bnxt_sp_task+0x678/0x920 [bnxt_en] ? __schedule+0x514/0xf50 process_scheduled_works+0x9d/0x400 worker_thread+0x11c/0x260 ? __pfx_worker_thread+0x10/0x10 kthread+0xfe/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2b/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Check the BNXT_EN_FLAG_ULP_STOPPED flag and do not proceed if the flag is already set. This will preserve the original symmetrical bnxt_ulp_stop() and bnxt_ulp_start(). Also, inside bnxt_ulp_start(), clear the BNXT_EN_FLAG_ULP_STOPPED flag after taking the mutex to avoid any race condition. And for symmetry, only proceed in bnxt_ulp_start() if the BNXT_EN_FLAG_ULP_STOPPED is set. Fixes: 3c163f35bd50 ("bnxt_en: Optimize recovery path ULP locking in the driver") Signed-off-by: Kalesh AP Co-developed-by: Michael Chan Signed-off-by: Michael Chan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250613231841.377988-2-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 32955a417032cccda9946e4b42816fdde0f79437 Author: Mina Almasry Date: Sun Jun 15 20:07:33 2025 +0000 net: netmem: fix skb_ensure_writable with unreadable skbs [ Upstream commit 6f793a1d053775f8324b8dba1e7ed224f8b0166f ] skb_ensure_writable should succeed when it's trying to write to the header of the unreadable skbs, so it doesn't need an unconditional skb_frags_readable check. The preceding pskb_may_pull() call will succeed if write_len is within the head and fail if we're trying to write to the unreadable payload, so we don't need an additional check. Removing this check restores DSCP functionality with unreadable skbs as it's called from dscp_tg. Cc: willemb@google.com Cc: asml.silence@gmail.com Fixes: 65249feb6b3d ("net: add support for skbs with unreadable frags") Signed-off-by: Mina Almasry Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20250615200733.520113-1-almasrymina@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ed42b8d7c0ba82a2fbae54bb38a6fcaa594d7e25 Author: Meghana Malladi Date: Mon Jun 16 12:03:19 2025 +0530 net: ti: icssg-prueth: Fix packet handling for XDP_TX [ Upstream commit 60524f1d2bdf222db6dc3f680e0272441f697fe4 ] While transmitting XDP frames for XDP_TX, page_pool is used to get the DMA buffers (already mapped to the pages) and need to be freed/reycled once the transmission is complete. This need not be explicitly done by the driver as this is handled more gracefully by the xdp driver while returning the xdp frame. __xdp_return() frees the XDP memory based on its memory type, under which page_pool memory is also handled. This change fixes the transmit queue timeout while running XDP_TX. logs: [ 309.069682] icssg-prueth icssg1-eth eth2: NETDEV WATCHDOG: CPU: 0: transmit queue 0 timed out 45860 ms [ 313.933780] icssg-prueth icssg1-eth eth2: NETDEV WATCHDOG: CPU: 0: transmit queue 0 timed out 50724 ms [ 319.053656] icssg-prueth icssg1-eth eth2: NETDEV WATCHDOG: CPU: 0: transmit queue 0 timed out 55844 ms ... Fixes: 62aa3246f462 ("net: ti: icssg-prueth: Add XDP support") Signed-off-by: Meghana Malladi Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250616063319.3347541-1-m-malladi@ti.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3f3aae77280aad9f5acc6709c596148966f765c7 Author: Namjae Jeon Date: Tue Jun 10 18:52:56 2025 +0900 ksmbd: add free_transport ops in ksmbd connection [ Upstream commit a89f5fae998bdc4d0505306f93844c9ae059d50c ] free_transport function for tcp connection can be called from smbdirect. It will cause kernel oops. This patch add free_transport ops in ksmbd connection, and add each free_transports for tcp and smbdirect. Fixes: 21a4e47578d4 ("ksmbd: fix use-after-free in __smb2_lease_break_noti()") Reviewed-by: Stefan Metzmacher Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit e20f4ebbdc64f1fb193c06f9197e360de94c09da Author: Chuyi Zhou Date: Tue Jun 17 12:42:16 2025 +0800 workqueue: Initialize wq_isolated_cpumask in workqueue_init_early() [ Upstream commit 261dce3d64021e7ec828a17b4975ce9182e54ceb ] Now when isolcpus is enabled via the cmdline, wq_isolated_cpumask does not include these isolated CPUs, even wq_unbound_cpumask has already excluded them. It is only when we successfully configure an isolate cpuset partition that wq_isolated_cpumask gets overwritten by workqueue_unbound_exclude_cpumask(), including both the cmdline-specified isolated CPUs and the isolated CPUs within the cpuset partitions. Fix this issue by initializing wq_isolated_cpumask properly in workqueue_init_early(). Fixes: fe28f631fa94 ("workqueue: Add workqueue_unbound_exclude_cpumask() to exclude CPUs from wq_unbound_cpumask") Signed-off-by: Chuyi Zhou Reviewed-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit b8aaf2bb5c67f1705bc200ec8c787d94e0e66306 Author: Vitaly Lifshits Date: Sun May 25 11:38:43 2025 +0300 e1000e: set fixed clock frequency indication for Nahum 11 and Nahum 13 [ Upstream commit 688a0d61b2d7427189c4eb036ce485d8fc957cbb ] On some systems with Nahum 11 and Nahum 13 the value of the XTAL clock in the software STRAP is incorrect. This causes the PTP timer to run at the wrong rate and can lead to synchronization issues. The STRAP value is configured by the system firmware, and a firmware update is not always possible. Since the XTAL clock on these systems always runs at 38.4MHz, the driver may ignore the STRAP and just set the correct value. Fixes: cc23f4f0b6b9 ("e1000e: Add support for Meteor Lake") Signed-off-by: Vitaly Lifshits Tested-by: Mor Bar-Gabay Reviewed-by: Gil Fine Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e97a7a051b55f55f276c1568491d0ed7f890ee94 Author: Grzegorz Nitka Date: Fri May 16 15:09:07 2025 +0200 ice: fix eswitch code memory leak in reset scenario [ Upstream commit 48c8b214974dc55283bd5f12e3a483b27c403bbc ] Add simple eswitch mode checker in attaching VF procedure and allocate required port representor memory structures only in switchdev mode. The reset flows triggers VF (if present) detach/attach procedure. It might involve VF port representor(s) re-creation if the device is configured is switchdev mode (not legacy one). The memory was blindly allocated in current implementation, regardless of the mode and not freed if in legacy mode. Kmemeleak trace: unreferenced object (percpu) 0x7e3bce5b888458 (size 40): comm "bash", pid 1784, jiffies 4295743894 hex dump (first 32 bytes on cpu 45): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): pcpu_alloc_noprof+0x4c4/0x7c0 ice_repr_create+0x66/0x130 [ice] ice_repr_create_vf+0x22/0x70 [ice] ice_eswitch_attach_vf+0x1b/0xa0 [ice] ice_reset_all_vfs+0x1dd/0x2f0 [ice] ice_pci_err_resume+0x3b/0xb0 [ice] pci_reset_function+0x8f/0x120 reset_store+0x56/0xa0 kernfs_fop_write_iter+0x120/0x1b0 vfs_write+0x31c/0x430 ksys_write+0x61/0xd0 do_syscall_64+0x5b/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Testing hints (ethX is PF netdev): - create at least one VF echo 1 > /sys/class/net/ethX/device/sriov_numvfs - trigger the reset echo 1 > /sys/class/net/ethX/device/reset Fixes: 415db8399d06 ("ice: make representor code generic") Signed-off-by: Grzegorz Nitka Reviewed-by: Przemek Kitszel Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 52993635c7a22099e8702c733aae8c52bb9d6969 Author: Krishna Kumar Date: Tue May 20 22:36:56 2025 +0530 net: ice: Perform accurate aRFS flow match [ Upstream commit 5d3bc9e5e725aa36cca9b794e340057feb6880b4 ] This patch fixes an issue seen in a large-scale deployment under heavy incoming pkts where the aRFS flow wrongly matches a flow and reprograms the NIC with wrong settings. That mis-steering causes RX-path latency spikes and noisy neighbor effects when many connections collide on the same hash (some of our production servers have 20-30K connections). set_rps_cpu() calls ndo_rx_flow_steer() with flow_id that is calculated by hashing the skb sized by the per rx-queue table size. This results in multiple connections (even across different rx-queues) getting the same hash value. The driver steer function modifies the wrong flow to use this rx-queue, e.g.: Flow#1 is first added: Flow#1: , Hash 'h', q#10 Later when a new flow needs to be added: Flow#2: , Hash 'h', q#20 The driver finds the hash 'h' from Flow#1 and updates it to use q#20. This results in both flows getting un-optimized - packets for Flow#1 goes to q#20, and then reprogrammed back to q#10 later and so on; and Flow #2 programming is never done as Flow#1 is matched first for all misses. Many flows may wrongly share the same hash and reprogram rules of the original flow each with their own q#. Tested on two 144-core servers with 16K netperf sessions for 180s. Netperf clients are pinned to cores 0-71 sequentially (so that wrong packets on q#s 72-143 can be measured). IRQs are set 1:1 for queues -> CPUs, enable XPS, enable aRFS (global value is 144 * rps_flow_cnt). Test notes about results from ice_rx_flow_steer(): --------------------------------------------------- 1. "Skip:" counter increments here: if (fltr_info->q_index == rxq_idx || arfs_entry->fltr_state != ICE_ARFS_ACTIVE) goto out; 2. "Add:" counter increments here: ret = arfs_entry->fltr_info.fltr_id; INIT_HLIST_NODE(&arfs_entry->list_entry); 3. "Update:" counter increments here: /* update the queue to forward to on an already existing flow */ Runtime comparison: original code vs with the patch for different rps_flow_cnt values. +-------------------------------+--------------+--------------+ | rps_flow_cnt | 512 | 2048 | +-------------------------------+--------------+--------------+ | Ratio of Pkts on Good:Bad q's | 214 vs 822K | 1.1M vs 980K | | Avoid wrong aRFS programming | 0 vs 310K | 0 vs 30K | | CPU User | 216 vs 183 | 216 vs 206 | | CPU System | 1441 vs 1171 | 1447 vs 1320 | | CPU Softirq | 1245 vs 920 | 1238 vs 961 | | CPU Total | 29 vs 22.7 | 29 vs 24.9 | | aRFS Update | 533K vs 59 | 521K vs 32 | | aRFS Skip | 82M vs 77M | 7.2M vs 4.5M | +-------------------------------+--------------+--------------+ A separate TCP_STREAM and TCP_RR with 1,4,8,16,64,128,256,512 connections showed no performance degradation. Some points on the patch/aRFS behavior: 1. Enabling full tuple matching ensures flows are always correctly matched, even with smaller hash sizes. 2. 5-6% drop in CPU utilization as the packets arrive at the correct CPUs and fewer calls to driver for programming on misses. 3. Larger hash tables reduces mis-steering due to more unique flow hashes, but still has clashes. However, with larger per-device rps_flow_cnt, old flows take more time to expire and new aRFS flows cannot be added if h/w limits are reached (rps_may_expire_flow() succeeds when 10*rps_flow_cnt pkts have been processed by this cpu that are not part of the flow). Fixes: 28bf26724fdb0 ("ice: Implement aRFS") Signed-off-by: Krishna Kumar Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit fb77a7760d268a9f561d8da5281256e325e7c544 Author: Jens Axboe Date: Tue Jun 17 06:43:18 2025 -0600 io_uring/sqpoll: don't put task_struct on tctx setup failure [ Upstream commit f2320f1dd6f6f82cb2c7aff23a12bab537bdea89 ] A recent commit moved the error handling of sqpoll thread and tctx failures into the thread itself, as part of fixing an issue. However, it missed that tctx allocation may also fail, and that io_sq_offload_create() does its own error handling for the task_struct in that case. Remove the manual task putting in io_sq_offload_create(), as io_sq_thread() will notice that the tctx did not get setup and hence it should put itself and exit. Reported-by: syzbot+763e12bbf004fb1062e4@syzkaller.appspotmail.com Fixes: ac0b8b327a56 ("io_uring: fix use-after-free of sq->thread in __io_uring_show_fdinfo()") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 00be74e1470af292c37a438b8e69dee47dcbf481 Author: Justin Sanders Date: Tue Jun 10 17:05:59 2025 +0000 aoe: clean device rq_list in aoedev_downdev() [ Upstream commit 7f90d45e57cb2ef1f0adcaf925ddffdfc5e680ca ] An aoe device's rq_list contains accepted block requests that are waiting to be transmitted to the aoe target. This queue was added as part of the conversion to blk_mq. However, the queue was not cleaned out when an aoe device is downed which caused blk_mq_freeze_queue() to sleep indefinitely waiting for those requests to complete, causing a hang. This fix cleans out the queue before calling blk_mq_freeze_queue(). Link: https://bugzilla.kernel.org/show_bug.cgi?id=212665 Fixes: 3582dd291788 ("aoe: convert aoeblk to blk-mq") Signed-off-by: Justin Sanders Link: https://lore.kernel.org/r/20250610170600.869-1-jsanders.devel@gmail.com Tested-By: Valentin Kleibel Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a570687e5b8e05d02f511195e8a82b4e15ec3d1c Author: Simon Horman Date: Fri Jun 13 17:46:20 2025 +0100 pldmfw: Select CRC32 when PLDMFW is selected [ Upstream commit 1224b218a4b9203656ecc932152f4c81a97b4fcc ] pldmfw calls crc32 code and depends on it being enabled, else there is a link error as follows. So PLDMFW should select CRC32. lib/pldmfw/pldmfw.o: In function `pldmfw_flash_image': pldmfw.c:(.text+0x70f): undefined reference to `crc32_le_base' This problem was introduced by commit b8265621f488 ("Add pldmfw library for PLDM firmware update"). It manifests as of commit d69ea414c9b4 ("ice: implement device flash update via devlink"). And is more likely to occur as of commit 9ad19171b6d6 ("lib/crc: remove unnecessary prompt for CONFIG_CRC32 and drop 'default y'"). Found by chance while exercising builds based on tinyconfig. Fixes: b8265621f488 ("Add pldmfw library for PLDM firmware update") Signed-off-by: Simon Horman Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250613-pldmfw-crc32-v1-1-f3fad109eee6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8d2efa67d22a23fd9e00f8e7f6854cb61d1d957d Author: Nuno Sá Date: Wed Jun 11 17:26:12 2025 +0100 hwmon: (ltc4282) avoid repeated register write [ Upstream commit c25892b7a1744355e16281cd24a9b59ec15ec974 ] The fault enabled bits were being mistankenly enabled twice in case the FW property is present. Remove one of the writes. Fixes: cbc29538dbf7 ("hwmon: Add driver for LTC4282") Signed-off-by: Nuno Sá Link: https://lore.kernel.org/r/20250611-fix-ltc4282-repetead-write-v1-1-fe46edd08cf1@analog.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 7d16e8749875fcaa08c9e050c07e38a5d9d727f2 Author: Arnd Bergmann Date: Tue Jun 10 11:25:49 2025 +0200 hwmon: (occ) fix unaligned accesses [ Upstream commit 2c021b45c154958566aad0cae9f74ab26a2d5732 ] Passing a pointer to an unaligned integer as a function argument is undefined behavior: drivers/hwmon/occ/common.c:492:27: warning: taking address of packed member 'accumulator' of class or structure 'power_sensor_2' may result in an unaligned pointer value [-Waddress-of-packed-member] 492 | val = occ_get_powr_avg(&power->accumulator, | ^~~~~~~~~~~~~~~~~~ drivers/hwmon/occ/common.c:493:13: warning: taking address of packed member 'update_tag' of class or structure 'power_sensor_2' may result in an unaligned pointer value [-Waddress-of-packed-member] 493 | &power->update_tag); | ^~~~~~~~~~~~~~~~~ Move the get_unaligned() calls out of the function and pass these through argument registers instead. Fixes: c10e753d43eb ("hwmon (occ): Add sensor types and versions") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20250610092553.2641094-1-arnd@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 78178b363654e6bf77753f23e14a9451f69a058c Author: Arnd Bergmann Date: Tue Jun 10 11:23:06 2025 +0200 hwmon: (occ) Rework attribute registration for stack usage [ Upstream commit 744c2fe950e936c4d62430de899d6253424200ed ] clang produces an output with excessive stack usage when building the occ_setup_sensor_attrs() function, apparently the result of having a lot of struct literals and building with the -fno-strict-overflow option that leads clang to skip some optimization in case the 'attr' pointer overruns: drivers/hwmon/occ/common.c:775:12: error: stack frame size (1392) exceeds limit (1280) in 'occ_setup_sensor_attrs' [-Werror,-Wframe-larger-than] Replace the custom macros for initializing the attributes with a simpler function call that does not run into this corner case. Link: https://godbolt.org/z/Wf1Yx76a5 Fixes: 54076cb3b5ff ("hwmon (occ): Add sensor attributes and register hwmon device") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20250610092315.2640039-1-arnd@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit f80cbba9b19364c20127823007c5edc28db0a1ff Author: Tzung-Bi Shih Date: Thu Jun 12 08:30:23 2025 +0000 drm/i915/pmu: Fix build error with GCOV and AutoFDO enabled [ Upstream commit a7137b1825b535eb7258b25beeb0d5425e0037d2 ] i915_pmu.c may fail to build with GCOV and AutoFDO enabled. ../drivers/gpu/drm/i915/i915_pmu.c:116:3: error: call to '__compiletime_assert_487' declared with 'error' attribute: BUILD_BUG_ON failed: bit > BITS_PER_TYPE(typeof_member(struct i915_pmu, enable)) - 1 116 | BUILD_BUG_ON(bit > | ^ Here is a way to reproduce the issue: $ git checkout v6.15 $ mkdir build $ ./scripts/kconfig/merge_config.sh -O build -n -m <(cat < Signed-off-by: Tzung-Bi Shih Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20250612083023.562585-1-tzungbi@kernel.org (cherry picked from commit 686d773186bf72b739bab7e12eb8665d914676ee) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit 1acd2d2e8ff014b026e982b6fc97bb27cd59bea6 Author: Jacob Keller Date: Tue Jun 10 14:54:51 2025 -0700 drm/nouveau/bl: increase buffer size to avoid truncate warning [ Upstream commit 61b2b3737499f1fb361a54a16828db24a8345e85 ] The nouveau_get_backlight_name() function generates a unique name for the backlight interface, appending an id from 1 to 99 for all backlight devices after the first. GCC 15 (and likely other compilers) produce the following -Wformat-truncation warning: nouveau_backlight.c: In function ‘nouveau_backlight_init’: nouveau_backlight.c:56:69: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 3 [-Werror=format-truncation=] 56 | snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb); | ^~ In function ‘nouveau_get_backlight_name’, inlined from ‘nouveau_backlight_init’ at nouveau_backlight.c:351:7: nouveau_backlight.c:56:56: note: directive argument in the range [1, 2147483647] 56 | snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb); | ^~~~~~~~~~~~~~~~ nouveau_backlight.c:56:17: note: ‘snprintf’ output between 14 and 23 bytes into a destination of size 15 56 | snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The warning started appearing after commit ab244be47a8f ("drm/nouveau: Fix a potential theorical leak in nouveau_get_backlight_name()") This fix for the ida usage removed the explicit value check for ids larger than 99. The compiler is unable to intuit that the ida_alloc_max() limits the returned value range between 0 and 99. Because the compiler can no longer infer that the number ranges from 0 to 99, it thinks that it could use as many as 11 digits (10 + the potential - sign for negative numbers). The warning has gone unfixed for some time, with at least one kernel test robot report. The code breaks W=1 builds, which is especially frustrating with the introduction of CONFIG_WERROR. The string is stored temporarily on the stack and then copied into the device name. Its not a big deal to use 11 more bytes of stack rounding out to an even 24 bytes. Increase BL_NAME_SIZE to 24 to avoid the truncation warning. This fixes the W=1 builds that include this driver. Compile tested only. Fixes: ab244be47a8f ("drm/nouveau: Fix a potential theorical leak in nouveau_get_backlight_name()") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202312050324.0kv4PnfZ-lkp@intel.com/ Suggested-by: Timur Tabi Signed-off-by: Jacob Keller Link: https://lore.kernel.org/r/20250610-jk-nouveua-drm-bl-snprintf-fix-v2-1-7fdd4b84b48e@intel.com Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit cd4677407c0ee250fc21e36439c8a442ddd62cc1 Author: Zhi Wang Date: Tue May 27 16:37:12 2025 +0000 drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() [ Upstream commit 9802f0a63b641f4cddb2139c814c2e95cb825099 ] The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM") Signed-off-by: Zhi Wang Link: https://lore.kernel.org/r/20250527163712.3444-1-zhiw@nvidia.com [ Rebase onto Blackwell changes. - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit b19f798f30fffb86f3655475ceac6d150475f0c6 Author: Ben Skeggs Date: Thu Nov 14 13:02:36 2024 +1000 drm/nouveau/gsp: split rpc handling out on its own [ Upstream commit 8a8b1ec5261f20d86c76c8fb235ee2441744bc10 ] Later patches in the series add HALs around various RM APIs in order to support a newer version of GSP-RM firmware. In order to do this, begin by splitting the code up into "modules" that roughly represent RM's API boundaries so they can be more easily managed. Aside from moving the RPC function pointers, no code change is indended. Signed-off-by: Ben Skeggs Reviewed-by: Dave Airlie Reviewed-by: Timur Tabi Tested-by: Timur Tabi Signed-off-by: Dave Airlie Stable-dep-of: 9802f0a63b64 ("drm/nouveau: fix a use-after-free in r535_gsp_rpc_push()") Signed-off-by: Sasha Levin commit a859a72b5edadbeb65285192fbe3f06c3d8c2a29 Author: Brett Creeley Date: Mon Jun 9 14:28:27 2025 -0700 ionic: Prevent driver/fw getting out of sync on devcmd(s) [ Upstream commit 5466491c9e3309ed5c7adbb8fad6e93fcc9a8fe9 ] Some stress/negative firmware testing around devcmd(s) returning EAGAIN found that the done bit could get out of sync in the firmware when it wasn't cleared in a retry case. While here, change the type of the local done variable to a bool to match the return type from ionic_dev_cmd_done(). Fixes: ec8ee714736e ("ionic: stretch heartbeat detection") Signed-off-by: Brett Creeley Signed-off-by: Shannon Nelson Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250609212827.53842-1-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 61b10dbfdb6362a6f1c8ab435058cd71cc82d2a9 Author: John Keeping Date: Wed Jun 11 12:13:06 2025 +0100 drm/ssd130x: fix ssd132x_clear_screen() columns [ Upstream commit e479da4054875c4cc53a7fb956ebff03d2dac939 ] The number of columns relates to the width, not the height. Use the correct variable. Signed-off-by: John Keeping Reviewed-by: Javier Martinez Canillas Fixes: fdd591e00a9c ("drm/ssd130x: Add support for the SSD132x OLED controller family") Link: https://lore.kernel.org/r/20250611111307.1814876-1-jkeeping@inmusicbrands.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Sasha Levin commit 35fe72f3c425bbf1d580bd9066e2456b1dbae4a8 Author: Connor Abbott Date: Tue May 20 18:28:06 2025 -0400 drm/msm/a7xx: Call CP_RESET_CONTEXT_STATE [ Upstream commit 2b520c6104f34e3a548525173c38ebca4402cac3 ] Calling this packet is necessary when we switch contexts because there are various pieces of state used by userspace to synchronize between BR and BV that are persistent across submits and we need to make sure that they are in a "safe" state when switching contexts. Otherwise a userspace submission in one context could cause another context to function incorrectly and hang, effectively a denial of service (although without leaking data). This was missed during initial a7xx bringup. Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support") Signed-off-by: Connor Abbott Patchwork: https://patchwork.freedesktop.org/patch/654924/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 412448fb3afbe6c9ff64d60ab7daabd594696ae5 Author: Connor Abbott Date: Tue May 20 18:28:05 2025 -0400 drm/msm: Fix CP_RESET_CONTEXT_STATE bitfield names [ Upstream commit b1c9e797ad37d188675505b66a3a4bbeea5d9560 ] Based on kgsl. Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support") Signed-off-by: Connor Abbott Patchwork: https://patchwork.freedesktop.org/patch/654922/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit bfba720123baf19d79df6cee45918010e87528c2 Author: Krzysztof Kozlowski Date: Tue May 20 13:13:26 2025 +0200 drm/msm/dsi/dsi_phy_10nm: Fix missing initial VCO rate [ Upstream commit 8a48e35becb214743214f5504e726c3ec131cd6d ] Driver unconditionally saves current state on first init in dsi_pll_10nm_init(), but does not save the VCO rate, only some of the divider registers. The state is then restored during probe/enable via msm_dsi_phy_enable() -> msm_dsi_phy_pll_restore_state() -> dsi_10nm_pll_restore_state(). Restoring calls dsi_pll_10nm_vco_set_rate() with pll_10nm->vco_current_rate=0, which basically overwrites existing rate of VCO and messes with clock hierarchy, by setting frequency to 0 to clock tree. This makes anyway little sense - VCO rate was not saved, so should not be restored. If PLL was not configured configure it to minimum rate to avoid glitches and configuring entire in clock hierarchy to 0 Hz. Suggested-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/sz4kbwy5nwsebgf64ia7uq4ee7wbsa5uy3xmlqwcstsbntzcov@ew3dcyjdzmi2/ Signed-off-by: Krzysztof Kozlowski Fixes: a4ccc37693a2 ("drm/msm/dsi_pll_10nm: restore VCO rate during Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/654796/ Link: https://lore.kernel.org/r/20250520111325.92352-2-krzysztof.kozlowski@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit fae49c6b805f27965d605d21e465f6a5d983f762 Author: James A. MacInnes Date: Wed Feb 12 15:03:47 2025 -0800 drm/msm/disp: Correct porch timing for SDM845 [ Upstream commit 146e87f3e11de0dfa091ff87e34b4bc6eec761a4 ] Type-C DisplayPort inoperable due to incorrect porch settings. - Re-used wide_bus_en as flag to prevent porch shifting Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: James A. MacInnes Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/636945/ Link: https://lore.kernel.org/r/20250212-sdm845_dp-v2-2-4954e51458f4@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 856ea32c4b8a93d97a14f307eb9597fb96da6b12 Author: James A. MacInnes Date: Wed Feb 12 15:03:46 2025 -0800 drm/msm/dp: Disable wide bus support for SDM845 [ Upstream commit 83c4c67076c209787515e06fffd41dd0bdab09b9 ] When widebus was enabled for DisplayPort in commit c7c412202623 ("drm/msm/dp: enable widebus on all relevant chipsets") it was clarified that it is only supported on DPU 5.0.0 onwards which includes SC7180 on DPU revision 6.2. However, this patch missed that the description structure for SC7180 is also reused for SDM845 (because of identical io_start address) which is only DPU 4.0.0, leading to a wrongly enbled widebus feature and corruption on that platform. Create a separate msm_dp_desc_sdm845 structure for this SoC compatible, with the wide_bus_supported flag turned off. Fixes: c7c412202623 ("drm/msm/dp: enable widebus on all relevant chipsets") Signed-off-by: James A. MacInnes [DB: reworded commit text following Marijn's suggestion] Reviewed-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/636944/ Link: https://lore.kernel.org/r/20250212-sdm845_dp-v2-1-4954e51458f4@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 9131bd8b6b3ef0c4e5cc5441e1707fade5f42af2 Author: Bharath SM Date: Mon Mar 17 15:57:27 2025 +0530 smb: fix secondary channel creation issue with kerberos by populating hostname when adding channels commit 306cb65bb0cb243389fcbd0a66907d5bdea07d1e upstream. When mounting a share with kerberos authentication with multichannel support, share mounts correctly, but fails to create secondary channels. This occurs because the hostname is not populated when adding the channels. The hostname is necessary for the userspace cifs.upcall program to retrieve the required credentials and pass it back to kernel, without hostname secondary channels fails establish. Cc: stable@vger.kernel.org Reviewed-by: Shyam Prasad N Signed-off-by: Bharath SM Reported-by: xfuren Link: https://bugzilla.samba.org/show_bug.cgi?id=15824 Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 4f4701489d0f768a232b10d281491184f34bacf0 Author: Maíra Canal Date: Mon Jun 2 12:14:02 2025 -0300 drm/v3d: Avoid NULL pointer dereference in `v3d_job_update_stats()` commit e1bc3a13bd775791cca0bb144d977b00f3598042 upstream. The following kernel Oops was recently reported by Mesa CI: [ 800.139824] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000588 [ 800.148619] Mem abort info: [ 800.151402] ESR = 0x0000000096000005 [ 800.155141] EC = 0x25: DABT (current EL), IL = 32 bits [ 800.160444] SET = 0, FnV = 0 [ 800.163488] EA = 0, S1PTW = 0 [ 800.166619] FSC = 0x05: level 1 translation fault [ 800.171487] Data abort info: [ 800.174357] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 800.179832] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 800.184873] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 800.190176] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001014c2000 [ 800.196607] [0000000000000588] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 800.205305] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 800.211564] Modules linked in: vc4 snd_soc_hdmi_codec drm_display_helper v3d cec gpu_sched drm_dma_helper drm_shmem_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm i2c_brcmstb snd_timer snd backlight [ 800.234448] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1 [ 800.244182] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 800.250005] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 800.256959] pc : v3d_job_update_stats+0x60/0x130 [v3d] [ 800.262112] lr : v3d_job_update_stats+0x48/0x130 [v3d] [ 800.267251] sp : ffffffc080003e60 [ 800.270555] x29: ffffffc080003e60 x28: ffffffd842784980 x27: 0224012000000000 [ 800.277687] x26: ffffffd84277f630 x25: ffffff81012fd800 x24: 0000000000000020 [ 800.284818] x23: ffffff8040238b08 x22: 0000000000000570 x21: 0000000000000158 [ 800.291948] x20: 0000000000000000 x19: ffffff8040238000 x18: 0000000000000000 [ 800.299078] x17: ffffffa8c1bd2000 x16: ffffffc080000000 x15: 0000000000000000 [ 800.306208] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 800.313338] x11: 0000000000000040 x10: 0000000000001a40 x9 : ffffffd83b39757c [ 800.320468] x8 : ffffffd842786420 x7 : 7fffffffffffffff x6 : 0000000000ef32b0 [ 800.327598] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : ffffffd842784980 [ 800.334728] x2 : 0000000000000004 x1 : 0000000000010002 x0 : 000000ba4c0ca382 [ 800.341859] Call trace: [ 800.344294] v3d_job_update_stats+0x60/0x130 [v3d] [ 800.349086] v3d_irq+0x124/0x2e0 [v3d] [ 800.352835] __handle_irq_event_percpu+0x58/0x218 [ 800.357539] handle_irq_event+0x54/0xb8 [ 800.361369] handle_fasteoi_irq+0xac/0x240 [ 800.365458] handle_irq_desc+0x48/0x68 [ 800.369200] generic_handle_domain_irq+0x24/0x38 [ 800.373810] gic_handle_irq+0x48/0xd8 [ 800.377464] call_on_irq_stack+0x24/0x58 [ 800.381379] do_interrupt_handler+0x88/0x98 [ 800.385554] el1_interrupt+0x34/0x68 [ 800.389123] el1h_64_irq_handler+0x18/0x28 [ 800.393211] el1h_64_irq+0x64/0x68 [ 800.396603] default_idle_call+0x3c/0x168 [ 800.400606] do_idle+0x1fc/0x230 [ 800.403827] cpu_startup_entry+0x40/0x50 [ 800.407742] rest_init+0xe4/0xf0 [ 800.410962] start_kernel+0x5e8/0x790 [ 800.414616] __primary_switched+0x80/0x90 [ 800.418622] Code: 8b170277 8b160296 11000421 b9000861 (b9401ac1) [ 800.424707] ---[ end trace 0000000000000000 ]--- [ 800.457313] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- This issue happens when the file descriptor is closed before the jobs submitted by it are completed. When the job completes, we update the global GPU stats and the per-fd GPU stats, which are exposed through fdinfo. If the file descriptor was closed, then the struct `v3d_file_priv` and its stats were already freed and we can't update the per-fd stats. Therefore, if the file descriptor was already closed, don't update the per-fd GPU stats, only update the global ones. Cc: stable@vger.kernel.org # v6.12+ Reviewed-by: Jose Maria Casanova Crespo Link: https://lore.kernel.org/r/20250602151451.10161-1-mcanal@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 9b82cecce14e36d66f083913089e8a6a76bfb771 Author: Maarten Lankhorst Date: Wed May 21 11:01:02 2025 +0200 drm/xe/svm: Fix regression disallowing 64K SVM migration commit d6fb4f01736a1d18cc981eb04fa2907a7121fc27 upstream. When changing the condition from >= SZ_64K, it was changed to <= SZ_64K. This disallows migration of 64K, which is the exact minimum allowed. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5057 Fixes: 794f5493f518 ("drm/xe: Strict migration policy for atomic SVM faults") Cc: stable@vger.kernel.org Cc: Matthew Brost Cc: Himal Prasad Ghimiray Reviewed-by: Himal Prasad Ghimiray Signed-off-by: Maarten Lankhorst Link: https://lore.kernel.org/r/20250521090102.2965100-1-dev@lankhorst.se (cherry picked from commit 531bef26d189b28bf0d694878c0e064b30990b6c) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit 3d19c20eafe9c69ca70072c37fde71373937d15e Author: Jens Axboe Date: Fri Jun 20 07:41:21 2025 -0600 io_uring/net: always use current transfer count for buffer put commit 51a4598ad5d9eb6be4ec9ba65bbfdf0ac302eb2e upstream. A previous fix corrected the retry condition for when to continue a current bundle, but it missed that the current (not the total) transfer count also applies to the buffer put. If not, then for incrementally consumed buffer rings repeated completions on the same request may end up over consuming. Reported-by: Roy Tang (ErgoniaTrading) Cc: stable@vger.kernel.org Fixes: 3a08988123c8 ("io_uring/net: only retry recv bundle for a full transfer") Link: https://github.com/axboe/liburing/issues/1423 Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c90459cd58bb421d275337093d8e901e0ba748dd Author: Jeff Layton Date: Thu Jun 19 06:01:55 2025 -0400 sunrpc: handle SVC_GARBAGE during svc auth processing as auth error commit 94d10a4dba0bc482f2b01e39f06d5513d0f75742 upstream. tianshuo han reported a remotely-triggerable crash if the client sends a kernel RPC server a specially crafted packet. If decoding the RPC reply fails in such a way that SVC_GARBAGE is returned without setting the rq_accept_statp pointer, then that pointer can be dereferenced and a value stored there. If it's the first time the thread has processed an RPC, then that pointer will be set to NULL and the kernel will crash. In other cases, it could create a memory scribble. The server sunrpc code treats a SVC_GARBAGE return from svc_authenticate or pg_authenticate as if it should send a GARBAGE_ARGS reply. RFC 5531 says that if authentication fails that the RPC should be rejected instead with a status of AUTH_ERR. Handle a SVC_GARBAGE return as an AUTH_ERROR, with a reason of AUTH_BADCRED instead of returning GARBAGE_ARGS in that case. This sidesteps the whole problem of touching the rpc_accept_statp pointer in this situation and avoids the crash. Cc: stable@kernel.org Fixes: 29cd2927fb91 ("SUNRPC: Fix encoding of accepted but unsuccessful RPC replies") Reported-by: tianshuo han Reviewed-by: Chuck Lever Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit eeb37e47f2017c515ae944420622b6467b4d26bd Author: Jeff Layton Date: Tue May 27 20:12:47 2025 -0400 nfsd: use threads array as-is in netlink interface commit 8ea688a3372e8369dc04395b39b4e71a6d91d4d5 upstream. The old nfsdfs interface for starting a server with multiple pools handles the special case of a single entry array passed down from userland by distributing the threads over every NUMA node. The netlink control interface however constructs an array of length nfsd_nrpools() and fills any unprovided slots with 0's. This behavior defeats the special casing that the old interface relies on. Change nfsd_nl_threads_set_doit() to pass down the array from userland as-is. Fixes: 7f5c330b2620 ("nfsd: allow passing in array of thread counts via netlink") Cc: stable@vger.kernel.org Reported-by: Mike Snitzer Closes: https://lore.kernel.org/linux-nfs/aDC-ftnzhJAlwqwh@kernel.org/ Signed-off-by: Jeff Layton Reviewed-by: Simon Horman Tested-by: Mike Snitzer Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 65d1465ce2c34c44919fbede2d1119d4bc31c11b Author: Gao Xiang Date: Tue Jun 17 13:40:56 2025 +0800 erofs: remove unused trace event erofs_destroy_inode commit 30b58444807c93bffeaba7d776110f2a909d2f9a upstream. The trace event `erofs_destroy_inode` was added but remains unused. This unused event contributes approximately 5KB to the kernel module size. Reported-by: Steven Rostedt Closes: https://lore.kernel.org/r/20250612224906.15000244@batman.local.home Fixes: 13f06f48f7bf ("staging: erofs: support tracepoint") Cc: stable@vger.kernel.org Reviewed-by: Hongbo Li Signed-off-by: Gao Xiang Link: https://lore.kernel.org/r/20250617054056.3232365-1-hsiangkao@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman commit a3c83f8927eb9fb9071e604b0c64dbbfee95ba22 Author: SeongJae Park Date: Mon Jun 2 10:49:26 2025 -0700 mm/madvise: handle madvise_lock() failure during race unwinding commit 9c49e5d09f076001e05537734d7df002162eb2b5 upstream. When unwinding race on -ERESTARTNOINTR handling of process_madvise(), madvise_lock() failure is ignored. Check the failure and abort remaining works in the case. Link: https://lkml.kernel.org/r/20250602174926.1074-1-sj@kernel.org Fixes: 4000e3d0a367 ("mm/madvise: remove redundant mmap_lock operations from process_madvise()") Signed-off-by: SeongJae Park Reported-by: Barry Song <21cnbao@gmail.com> Closes: https://lore.kernel.org/CAGsJ_4xJXXO0G+4BizhohSZ4yDteziPw43_uF8nPXPWxUVChzw@mail.gmail.com Reviewed-by: Jann Horn Reviewed-by: Lorenzo Stoakes Acked-by: David Hildenbrand Reviewed-by: Shakeel Butt Reviewed-by: Barry Song Cc: Liam Howlett Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit a02f364857d53617cef4040e33eb96c575b57ecb Author: Aditya Garg Date: Thu Apr 10 23:50:01 2025 +0530 drm/appletbdrm: Make appletbdrm depend on X86 commit de5fbbe1531f645c8b56098be8d1faf31e46f7f0 upstream. The appletbdrm driver is exclusively for Touch Bars on x86 Intel Macs. The M1 Macs have a separate driver. So, lets avoid compiling it for other architectures. Signed-off-by: Aditya Garg Reviewed-by: Alyssa Rosenzweig Link: https://lore.kernel.org/r/PN3PR01MB95970778982F28E4A3751392B8B72@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM Signed-off-by: Alyssa Rosenzweig Signed-off-by: Greg Kroah-Hartman commit 94abc7acfc4167fd2e32f982d9146a4fa24a861c Author: Richard Fitzgerald Date: Mon Jun 9 11:21:25 2025 +0100 ALSA: hda/realtek: Add quirk for Asus GU605C commit 7b23887a0c70d15459f02c51651a111e9e5cab86 upstream. The GU605C has similar audio hardware to the GU605M so apply the same quirk. Note that in the linked bugzilla there are two separate problems with the GU605C. This patch fixes one of the problems, so I haven't added a Closes: tag. Signed-off-by: Richard Fitzgerald Reported-by: Nick Karaolidis Link: https://bugzilla.kernel.org/show_bug.cgi?id=220152 Cc: Link: https://patch.msgid.link/20250609102125.63196-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b32a473859ca976288c25cdee24631728c52878c Author: Chris Chiu Date: Tue Jun 10 11:56:07 2025 +0800 ALSA: hda/realtek: Fix built-in mic on ASUS VivoBook X513EA commit c6451a7325874c119def1d4094f6815c0c8fdc23 upstream. The built-in mic of ASUS VivoBook X513EA is broken recently by the fix of the pin sort. The fixup ALC256_FIXUP_ASUS_MIC_NO_PRESENCE is working for addressing the regression, too. Fixes: 3b4309546b48 ("ALSA: hda: Fix headset detection failure due to unstable sort") Signed-off-by: Chris Chiu Cc: Link: https://patch.msgid.link/20250610035607.690771-1-chris.chiu@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 66ae0e8db11175a4a9f740c2a69643f3ad593c07 Author: Jonathan Lane Date: Wed Jun 11 12:31:25 2025 -0700 ALSA: hda/realtek: enable headset mic on Latitude 5420 Rugged commit efa6bdf1bc75e26cafaa5f1d775e8bb7c5b0c431 upstream. Like many Dell laptops, the 3.5mm port by default can not detect a combined headphones+mic headset or even a pure microphone. This change enables the port's functionality. Signed-off-by: Jonathan Lane Cc: Link: https://patch.msgid.link/20250611193124.26141-2-jon@borg.moe Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cba873a06e94f2f8b16080789e813e10a9a39b71 Author: Edip Hazuri Date: Mon Jun 9 10:59:44 2025 +0300 ALSA: hda/realtek - Add mute LED support for HP Victus 16-s1xxx and HP Victus 15-fa1xxx commit a0914bf56e26d2cf457690602883f9cd2ec2c646 upstream. The mute led on those laptops is using ALC245 but requires a quirk to work This patch enables the existing quirk for the devices. Tested on my Victus 16-s1011nt Laptop and my friend's Victus 15-fa1xxx. The LED behaviour works as intended. Cc: Signed-off-by: Edip Hazuri Link: https://patch.msgid.link/20250609075943.13934-2-edip@medip.dev Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 80dea2edc2dd720abbbbc5abad39df096c74a075 Author: Takashi Iwai Date: Sun Jun 8 11:14:14 2025 +0200 ALSA: hda/intel: Add Thinkpad E15 to PM deny list commit c987a390f1b3b8bdac11031d7004e3410fe259bd upstream. Lenovo Thinkpad E15 with Conexant CX8070 codec seems causing ugly noises after runtime-PM suspend. Disable the codec runtime PM as a workaround. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220210 Cc: Link: https://patch.msgid.link/20250608091415.21170-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1e7cadaf2cca03ec362bae91994ab7efe6edb4e5 Author: wangdicheng Date: Fri Jun 13 14:36:36 2025 +0800 ALSA: usb-audio: Rename ALSA kcontrol PCM and PCM1 for the KTMicro sound card commit 93adf20ff4d6e865e0b974110d3cf2f07c057177 upstream. PCM1 not in Pulseaudio's control list; standardize control to "Speaker" and "Headphone". Signed-off-by: wangdicheng Cc: Link: https://patch.msgid.link/20250613063636.239683-1-wangdich9700@163.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1d03bbcb2b9851672a51778f6225e466e8292104 Author: Dev Jain Date: Tue May 27 13:56:33 2025 +0530 arm64: Restrict pagetable teardown to avoid false warning commit 650768c512faba8070bf4cfbb28c95eb5cd203f3 upstream. Commit 9c006972c3fe ("arm64: mmu: drop pXd_present() checks from pXd_free_pYd_table()") removes the pxd_present() checks because the caller checks pxd_present(). But, in case of vmap_try_huge_pud(), the caller only checks pud_present(); pud_free_pmd_page() recurses on each pmd through pmd_free_pte_page(), wherein the pmd may be none. Thus it is possible to hit a warning in the latter, since pmd_none => !pmd_table(). Thus, add a pmd_present() check in pud_free_pmd_page(). This problem was found by code inspection. Fixes: 9c006972c3fe ("arm64: mmu: drop pXd_present() checks from pXd_free_pYd_table()") Cc: stable@vger.kernel.org Reported-by: Ryan Roberts Acked-by: David Hildenbrand Signed-off-by: Dev Jain Reviewed-by: Catalin Marinas Reviewed-by: Anshuman Khandual Reviewed-by: Ryan Roberts Link: https://lore.kernel.org/r/20250527082633.61073-1-dev.jain@arm.com Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 3ced4f611f9cca99e338c97b5b78a4043278d9d1 Author: Binbin Zhou Date: Tue Jun 10 19:59:26 2025 +0800 gpio: loongson-64bit: Correct Loongson-7A2000 ACPI GPIO access mode commit 72f37957007d25f4290e3ba40d40aaec1dd0b0cf upstream. According to the description of the Loongson-7A2000 ACPI GPIO register in the manual, its access mode should be BIT_CTRL_MODE, otherwise there maybe some unpredictable behavior. Cc: stable@vger.kernel.org Fixes: 44fe79020b91 ("gpio: loongson-64bit: Add more gpio chip support") Signed-off-by: Binbin Zhou Reviewed-by: Huacai Chen Link: https://lore.kernel.org/r/20250610115926.347845-1-zhoubinbin@loongson.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 8c327a0660a449c8b7ea07a07406ee894e5223e8 Author: Zhi Wang Date: Thu Feb 27 01:35:54 2025 +0000 drm/nouveau/nvkm: introduce new GSP reply policy NVKM_GSP_RPC_REPLY_POLL commit a738fa9105ac2897701ba4067c33e85faa27d1e2 upstream. Some GSP RPC commands need a new reply policy: "caller don't care about the message content but want to make sure a reply is received". To support this case, a new reply policy is introduced. NV_VGPU_MSG_FUNCTION_ALLOC_MEMORY is a large GSP RPC command. The actual required policy is NVKM_GSP_RPC_REPLY_POLL. This can be observed from the dump of the GSP message queue. After the large GSP RPC command is issued, GSP will write only an empty RPC header in the queue as the reply. Without this change, the policy "receiving the entire message" is used for NV_VGPU_MSG_FUNCTION_ALLOC_MEMORY. This causes the timeout of receiving the returned GSP message in the suspend/resume path. Introduce the new reply policy NVKM_GSP_RPC_REPLY_POLL, which waits for the returned GSP message but discards it for the caller. Use the new policy NVKM_GSP_RPC_REPLY_POLL on the GSP RPC command NV_VGPU_MSG_FUNCTION_ALLOC_MEMORY. Fixes: 50f290053d79 ("drm/nouveau: support handling the return of large GSP message") Cc: Danilo Krummrich Cc: Alexandre Courbot Tested-by: Ben Skeggs Signed-off-by: Zhi Wang Signed-off-by: Danilo Krummrich Link: https://patchwork.freedesktop.org/patch/msgid/20250227013554.8269-3-zhiw@nvidia.com Signed-off-by: Greg Kroah-Hartman commit 14ac986af685efa2668499dd1064af7abb2803d2 Author: Zhi Wang Date: Thu Feb 27 01:35:53 2025 +0000 drm/nouveau/nvkm: factor out current GSP RPC command policies commit 4570355f8eaa476164cfb7ca959fdbf0cebbc9eb upstream. There can be multiple cases of handling the GSP RPC messages, which are the reply of GSP RPC commands according to the requirement of the callers and the nature of the GSP RPC commands. The current supported reply policies are "callers don't care" and "receive the entire message" according to the requirement of the callers. To introduce a new policy, factor out the current RPC command reply polices. Also, centralize the handling of the reply in a single function. Factor out NVKM_GSP_RPC_REPLY_NOWAIT as "callers don't care" and NVKM_GSP_RPC_REPLY_RECV as "receive the entire message". Introduce a kernel doc to document the policies. Factor out r535_gsp_rpc_handle_reply(). No functional change is intended for small GSP RPC commands. For large GSP commands, the caller decides the policy of how to handle the returned GSP RPC message. Cc: Ben Skeggs Cc: Alexandre Courbot Signed-off-by: Zhi Wang Signed-off-by: Danilo Krummrich Link: https://patchwork.freedesktop.org/patch/msgid/20250227013554.8269-2-zhiw@nvidia.com Signed-off-by: Greg Kroah-Hartman commit 7d6bc28cfe5c8e3a279b4b4bdeed6698b2702685 Author: Kuniyuki Iwashima Date: Mon Jun 16 11:21:15 2025 -0700 atm: Revert atm_account_tx() if copy_from_iter_full() fails. commit 7851263998d4269125fd6cb3fdbfc7c6db853859 upstream. In vcc_sendmsg(), we account skb->truesize to sk->sk_wmem_alloc by atm_account_tx(). It is expected to be reverted by atm_pop_raw() later called by vcc->dev->ops->send(vcc, skb). However, vcc_sendmsg() misses the same revert when copy_from_iter_full() fails, and then we will leak a socket. Let's factorise the revert part as atm_return_tx() and call it in the failure path. Note that the corresponding sk_wmem_alloc operation can be found in alloc_tx() as of the blamed commit. $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Simon Horman Closes: https://lore.kernel.org/netdev/20250614161959.GR414686@horms.kernel.org/ Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250616182147.963333-3-kuni1840@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f27730de39c341f845cda78e853d9e2710d8807d Author: Tejun Heo Date: Mon Jun 16 10:13:25 2025 -1000 sched_ext, sched/core: Don't call scx_group_set_weight() prematurely from sched_create_group() commit 33796b91871ad4010c8188372dd1faf97cf0f1c0 upstream. During task_group creation, sched_create_group() calls scx_group_set_weight() with CGROUP_WEIGHT_DFL to initialize the sched_ext portion. This is premature and ends up calling ops.cgroup_set_weight() with an incorrect @cgrp before ops.cgroup_init() is called. sched_create_group() should just initialize SCX related fields in the new task_group. Fix it by factoring out scx_tg_init() from sched_init() and making sched_create_group() call that function instead of scx_group_set_weight(). v2: Retain CONFIG_EXT_GROUP_SCHED ifdef in sched_init() as removing it leads to build failures on !CONFIG_GROUP_SCHED configs. Signed-off-by: Tejun Heo Fixes: 819513666966 ("sched_ext: Add cgroup support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Greg Kroah-Hartman commit 5ab37c146c665064d972ddfa93893e048eef46d9 Author: Srinivas Pandruvada Date: Fri Jun 6 13:53:00 2025 -0700 platform/x86/intel-uncore-freq: Fail module load when plat_info is NULL commit 685f88c72a0c4d12d3bd2ff50286938f14486f85 upstream. Address a Smatch static checker warning regarding an unchecked dereference in the function call: set_cdie_id(i, cluster_info, plat_info) when plat_info is NULL. Instead of addressing this one case, in general if plat_info is NULL then it can cause other issues. For example in a two package system it will give warning for duplicate sysfs entry as package ID will be always zero for both packages when creating string for attribute group name. plat_info is derived from TPMI ID TPMI_BUS_INFO, which is integral to the core TPMI design. Therefore, it should not be NULL on a production platform. Consequently, the module should fail to load if plat_info is NULL. Reported-by: Dan Carpenter Closes: https://lore.kernel.org/platform-driver-x86/aEKvGCLd1qmX04Tc@stanley.mountain/T/#u Fixes: 8a54e2253e4c ("platform/x86/intel-uncore-freq: Uncore frequency control via TPMI") Signed-off-by: Srinivas Pandruvada Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250606205300.2384494-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 85d98254ea187b24280e3102a5e03363ff09e717 Author: Stephen Smalley Date: Fri Jun 13 15:37:05 2025 -0400 selinux: fix selinux_xfrm_alloc_user() to set correct ctx_len commit 86c8db86af43f52f682e53a0f2f0828683be1e52 upstream. We should count the terminating NUL byte as part of the ctx_len. Otherwise, UBSAN logs a warning: UBSAN: array-index-out-of-bounds in security/selinux/xfrm.c:99:14 index 60 is out of range for type 'char [*]' The allocation itself is correct so there is no actual out of bounds indexing, just a warning. Cc: stable@vger.kernel.org Suggested-by: Christian Göttsche Link: https://lore.kernel.org/selinux/CAEjxPJ6tA5+LxsGfOJokzdPeRomBHjKLBVR6zbrg+_w3ZZbM3A@mail.gmail.com/ Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 38325dc13c7d74858d65bd0694582e0d4580f326 Author: Kurt Borja Date: Wed Jun 11 18:30:40 2025 -0300 Revert "platform/x86: alienware-wmi-wmax: Add G-Mode support to Alienware m16 R1" commit e2468dc700743683e1d1793bbd855e2536fd3de2 upstream. This reverts commit 5ff79cabb23a2f14d2ed29e9596aec908905a0e6. Although the Alienware m16 R1 AMD model supports G-Mode, it actually has a lower power ceiling than plain "performance" profile, which results in lower performance. Reported-by: Cihan Ozakca Cc: stable@vger.kernel.org # 6.15.x Signed-off-by: Kurt Borja Link: https://lore.kernel.org/r/20250611-m16-rev-v1-1-72d13bad03c9@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 7f34fa4589f58c15fd82707bc9ac04da35b3c277 Author: Rong Zhang Date: Mon May 26 04:18:07 2025 +0800 platform/x86: ideapad-laptop: use usleep_range() for EC polling commit 5808c34216954cd832bd4b8bc52dfa287049122b upstream. It was reported that ideapad-laptop sometimes causes some recent (since 2024) Lenovo ThinkBook models shut down when: - suspending/resuming - closing/opening the lid - (dis)connecting a charger - reading/writing some sysfs properties, e.g., fan_mode, touchpad - pressing down some Fn keys, e.g., Brightness Up/Down (Fn+F5/F6) - (seldom) loading the kmod The issue has existed since the launch day of such models, and there have been some out-of-tree workarounds (see Link:) for the issue. One disables some functionalities, while another one simply shortens IDEAPAD_EC_TIMEOUT. The disabled functionalities have read_ec_data() in their call chains, which calls schedule() between each poll. It turns out that these models suffer from the indeterminacy of schedule() because of their low tolerance for being polled too frequently. Sometimes schedule() returns too soon due to the lack of ready tasks, causing the margin between two polls to be too short. In this case, the command is somehow aborted, and too many subsequent polls (they poll for "nothing!") may eventually break the state machine in the EC, resulting in a hard shutdown. This explains why shortening IDEAPAD_EC_TIMEOUT works around the issue - it reduces the total number of polls sent to the EC. Even when it doesn't lead to a shutdown, frequent polls may also disturb the ongoing operation and notably delay (+ 10-20ms) the availability of EC response. This phenomenon is unlikely to be exclusive to the models mentioned above, so dropping the schedule() manner should also slightly improve the responsiveness of various models. Fix these issues by migrating to usleep_range(150, 300). The interval is chosen to add some margin to the minimal 50us and considering EC responses are usually available after 150-2500us based on my test. It should be enough to fix these issues on all models subject to the EC bug without introducing latency on other models. Tested on ThinkBook 14 G7+ ASP and solved both issues. No regression was introduced in the test on a model without the EC bug (ThinkBook X IMH, thanks Eric). Link: https://github.com/ty2/ideapad-laptop-tb2024g6plus/commit/6c5db18c9e8109873c2c90a7d2d7f552148f7ad4 Link: https://github.com/ferstar/ideapad-laptop-tb/commit/42d1e68e5009529d31bd23f978f636f79c023e80 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218771 Fixes: 6a09f21dd1e2 ("ideapad: add ACPI helpers") Cc: stable@vger.kernel.org Tested-by: Felix Yan Tested-by: Eric Long Tested-by: Jianfei Zhang Tested-by: Mingcong Bai Tested-by: Minh Le Tested-by: Sicheng Zhu Signed-off-by: Rong Zhang Link: https://lore.kernel.org/r/20250525201833.37939-1-i@rong.moe Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 300dedd9fe182d4c7424550d81cee595994486d1 Author: Steven Rostedt Date: Wed Jun 18 07:38:01 2025 -0400 fgraph: Do not enable function_graph tracer when setting funcgraph-args commit 327e28664307d49ce3fa71ba30dcc0007c270974 upstream. When setting the funcgraph-args option when function graph tracer is net enabled, it incorrectly enables it. Worse, it unregisters itself when it was never registered. Then when it gets enabled again, it will register itself a second time causing a WARNing. ~# echo 1 > /sys/kernel/tracing/options/funcgraph-args ~# head -20 /sys/kernel/tracing/trace # tracer: nop # # entries-in-buffer/entries-written: 813/26317372 #P:8 # # _-----=> irqs-off/BH-disabled # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / _-=> migrate-disable # |||| / delay # TASK-PID CPU# ||||| TIMESTAMP FUNCTION # | | | ||||| | | -0 [007] d..4. 358.966010: 7) 1.692 us | fetch_next_timer_interrupt(basej=4294981640, basem=357956000000, base_local=0xffff88823c3ae040, base_global=0xffff88823c3af300, tevt=0xffff888100e47cb8); -0 [007] d..4. 358.966012: 7) | tmigr_cpu_deactivate(nextexp=357988000000) { -0 [007] d..4. 358.966013: 7) | _raw_spin_lock(lock=0xffff88823c3b2320) { -0 [007] d..4. 358.966014: 7) 0.981 us | preempt_count_add(val=1); -0 [007] d..5. 358.966017: 7) 1.058 us | do_raw_spin_lock(lock=0xffff88823c3b2320); -0 [007] d..4. 358.966019: 7) 5.824 us | } -0 [007] d..5. 358.966021: 7) | tmigr_inactive_up(group=0xffff888100cb9000, child=0x0, data=0xffff888100e47bc0) { -0 [007] d..5. 358.966022: 7) | tmigr_update_events(group=0xffff888100cb9000, child=0x0, data=0xffff888100e47bc0) { Notice the "tracer: nop" at the top there. The current tracer is the "nop" tracer, but the content is obviously the function graph tracer. Enabling function graph tracing will cause it to register again and trigger a warning in the accounting: ~# echo function_graph > /sys/kernel/tracing/current_tracer -bash: echo: write error: Device or resource busy With the dmesg of: ------------[ cut here ]------------ WARNING: CPU: 7 PID: 1095 at kernel/trace/ftrace.c:3509 ftrace_startup_subops+0xc1e/0x1000 Modules linked in: kvm_intel kvm irqbypass CPU: 7 UID: 0 PID: 1095 Comm: bash Not tainted 6.16.0-rc2-test-00006-gea03de4105d3 #24 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:ftrace_startup_subops+0xc1e/0x1000 Code: 48 b8 22 01 00 00 00 00 ad de 49 89 84 24 88 01 00 00 8b 44 24 08 89 04 24 e9 c3 f7 ff ff c7 04 24 ed ff ff ff e9 b7 f7 ff ff <0f> 0b c7 04 24 f0 ff ff ff e9 a9 f7 ff ff c7 04 24 f4 ff ff ff e9 RSP: 0018:ffff888133cff948 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 1ffff1102679ff31 RCX: 0000000000000000 RDX: 1ffffffff0b27a60 RSI: ffffffff8593d2f0 RDI: ffffffff85941140 RBP: 00000000000c2041 R08: ffffffffffffffff R09: ffffed1020240221 R10: ffff88810120110f R11: ffffed1020240214 R12: ffffffff8593d2f0 R13: ffffffff8593d300 R14: ffffffff85941140 R15: ffffffff85631100 FS: 00007f7ec6f28740(0000) GS:ffff8882b5251000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7ec6f181c0 CR3: 000000012f1d0005 CR4: 0000000000172ef0 Call Trace: ? __pfx_ftrace_startup_subops+0x10/0x10 ? find_held_lock+0x2b/0x80 ? ftrace_stub_direct_tramp+0x10/0x10 ? ftrace_stub_direct_tramp+0x10/0x10 ? trace_preempt_on+0xd0/0x110 ? __pfx_trace_graph_entry_args+0x10/0x10 register_ftrace_graph+0x4d2/0x1020 ? tracing_reset_online_cpus+0x14b/0x1e0 ? __pfx_register_ftrace_graph+0x10/0x10 ? ring_buffer_record_enable+0x16/0x20 ? tracing_reset_online_cpus+0x153/0x1e0 ? __pfx_tracing_reset_online_cpus+0x10/0x10 ? __pfx_trace_graph_return+0x10/0x10 graph_trace_init+0xfd/0x160 tracing_set_tracer+0x500/0xa80 ? __pfx_tracing_set_tracer+0x10/0x10 ? lock_release+0x181/0x2d0 ? _copy_from_user+0x26/0xa0 tracing_set_trace_write+0x132/0x1e0 ? __pfx_tracing_set_trace_write+0x10/0x10 ? ftrace_graph_func+0xcc/0x140 ? ftrace_stub_direct_tramp+0x10/0x10 ? ftrace_stub_direct_tramp+0x10/0x10 ? ftrace_stub_direct_tramp+0x10/0x10 vfs_write+0x1d0/0xe90 ? __pfx_vfs_write+0x10/0x10 Have the setting of the funcgraph-args check if function_graph tracer is the current tracer of the instance, and if not, do nothing, as there's nothing to do (the option is checked when function_graph tracing starts). Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Cc: Mark Rutland Link: https://lore.kernel.org/20250618073801.057ea636@gandalf.local.home Fixes: c7a60a733c373 ("ftrace: Have funcgraph-args take affect during tracing") Closes: https://lore.kernel.org/all/4ab1a7bdd0174ab09c7b0d68cdbff9a4@huawei.com/ Reported-by: Changbin Du Tested-by: Changbin Du Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 076f1adefb9837977af7ed233883842ddc446644 Author: Namjae Jeon Date: Fri Jun 13 10:12:43 2025 +0900 ksmbd: fix null pointer dereference in destroy_previous_session commit 7ac5b66acafcc9292fb935d7e03790f2b8b2dc0e upstream. If client set ->PreviousSessionId on kerberos session setup stage, NULL pointer dereference error will happen. Since sess->user is not set yet, It can pass the user argument as NULL to destroy_previous_session. sess->user will be set in ksmbd_krb5_authenticate(). So this patch move calling destroy_previous_session() after ksmbd_krb5_authenticate(). Cc: stable@vger.kernel.org Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-27391 Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b90c862ab7782a00c4584a7cadfe0e6c2febf805 Author: Xin Li (Intel) Date: Mon Jun 9 01:40:54 2025 -0700 selftests/x86: Add a test to detect infinite SIGTRAP handler loop commit f287822688eeb44ae1cf6ac45701d965efc33218 upstream. When FRED is enabled, if the Trap Flag (TF) is set without an external debugger attached, it can lead to an infinite loop in the SIGTRAP handler. To avoid this, the software event flag in the augmented SS must be cleared, ensuring that no single-step trap remains pending when ERETU completes. This test checks for that specific scenario—verifying whether the kernel correctly prevents an infinite SIGTRAP loop in this edge case when FRED is enabled. The test should _always_ pass with IDT event delivery, thus no need to disable the test even when FRED is not enabled. Signed-off-by: Xin Li (Intel) Signed-off-by: Dave Hansen Tested-by: Sohil Mehta Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250609084054.2083189-3-xin%40zytor.com Signed-off-by: Greg Kroah-Hartman commit bf66175d816ef065ca77356a93ad0729663806f7 Author: Kai Huang Date: Sat Jun 7 01:07:37 2025 +1200 x86/virt/tdx: Avoid indirect calls to TDX assembly functions commit 0b3bc018e86afdc0cbfef61328c63d5c08f8b370 upstream. Two 'static inline' TDX helper functions (sc_retry() and sc_retry_prerr()) take function pointer arguments which refer to assembly functions. Normally, the compiler inlines the TDX helper, realizes that the function pointer targets are completely static -- thus can be resolved at compile time -- and generates direct call instructions. But, other times (like when CONFIG_CC_OPTIMIZE_FOR_SIZE=y), the compiler declines to inline the helpers and will instead generate indirect call instructions. Indirect calls to assembly functions require special annotation (for various Control Flow Integrity mechanisms). But TDX assembly functions lack the special annotations and can only be called directly. Annotate both the helpers as '__always_inline' to prod the compiler into maintaining the direct calls. There is no guarantee here, but Peter has volunteered to report the compiler bug if this assumption ever breaks[1]. Fixes: 1e66a7e27539 ("x86/virt/tdx: Handle SEAMCALL no entropy error in common code") Fixes: df01f5ae07dd ("x86/virt/tdx: Add SEAMCALL error printing for module initialization") Signed-off-by: Kai Huang Signed-off-by: Dave Hansen Cc: stable@vger.kernel.org Link: https://lore.kernel.org/lkml/20250605145914.GW39944@noisy.programming.kicks-ass.net/ [1] Link: https://lore.kernel.org/all/20250606130737.30713-1-kai.huang%40intel.com Signed-off-by: Greg Kroah-Hartman commit 3ac44677d462874d91b0efb11309f0d2fd52626e Author: Mike Rapoport (Microsoft) Date: Tue Jun 3 14:14:45 2025 +0300 Revert "mm/execmem: Unify early execmem_cache behaviour" commit 7cd9a11dd0c3d1dd225795ed1b5b53132888e7b5 upstream. The commit d6d1e3e6580c ("mm/execmem: Unify early execmem_cache behaviour") changed early behaviour of execemem ROX cache to allow its usage in early x86 code that allocates text pages when CONFIG_MITGATION_ITS is enabled. The permission management of the pages allocated from execmem for ITS mitigation is now completely contained in arch/x86/kernel/alternatives.c and therefore there is no need to special case early allocations in execmem. This reverts commit d6d1e3e6580ca35071ad474381f053cbf1fb6414. Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20250603111446.2609381-6-rppt@kernel.org Signed-off-by: Greg Kroah-Hartman commit 343e124308a48e66aef53d278d239870beda9af7 Author: Peter Zijlstra (Intel) Date: Tue Jun 3 14:14:44 2025 +0300 x86/its: explicitly manage permissions for ITS pages commit a82b26451de126a5ae130361081986bc459afe9b upstream. execmem_alloc() sets permissions differently depending on the kernel configuration, CPU support for PSE and whether a page is allocated before or after mark_rodata_ro(). Add tracking for pages allocated for ITS when patching the core kernel and make sure the permissions for ITS pages are explicitly managed for both kernel and module allocations. Fixes: 872df34d7c51 ("x86/its: Use dynamic thunks for indirect branches") Signed-off-by: Peter Zijlstra (Intel) Co-developed-by: Mike Rapoport (Microsoft) Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Nikolay Borisov Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20250603111446.2609381-5-rppt@kernel.org Signed-off-by: Greg Kroah-Hartman commit 861ec3e8fbac6e70ada6596d05e90490f137ab31 Author: Mike Rapoport (Microsoft) Date: Tue Jun 3 14:14:43 2025 +0300 x86/its: move its_pages array to struct mod_arch_specific commit 0b0cae7119a0ec9449d7261b5e672a5fed765068 upstream. The of pages with ITS thunks allocated for modules are tracked by an array in 'struct module'. Since this is very architecture specific data structure, move it to 'struct mod_arch_specific'. No functional changes. Fixes: 872df34d7c51 ("x86/its: Use dynamic thunks for indirect branches") Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20250603111446.2609381-4-rppt@kernel.org Signed-off-by: Greg Kroah-Hartman commit 62c18d4e2494fd34c5c67bb2bc50e8053b14c0cc Author: Mike Rapoport (Microsoft) Date: Tue Jun 3 14:14:42 2025 +0300 x86/Kconfig: only enable ROX cache in execmem when STRICT_MODULE_RWX is set commit 47410d839fcda6890cb82828f874f97710982f24 upstream. Currently ROX cache in execmem is enabled regardless of STRICT_MODULE_RWX setting. This breaks an assumption that module memory is writable when STRICT_MODULE_RWX is disabled, for instance for kernel debuggin. Only enable ROX cache in execmem when STRICT_MODULE_RWX is set to restore the original behaviour of module text permissions. Fixes: 64f6a4e10c05 ("x86: re-enable EXECMEM_ROX support") Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20250603111446.2609381-3-rppt@kernel.org Signed-off-by: Greg Kroah-Hartman commit 4d080d7a834542a3af4cd4df318d2b894b6ad0dc Author: Juergen Gross Date: Tue Jun 3 14:14:41 2025 +0300 x86/mm/pat: don't collapse pages without PSE set commit 1dbf30fdb5e57fb2c39f17f35f2b544d5de34397 upstream. Collapsing pages to a leaf PMD or PUD should be done only if X86_FEATURE_PSE is available, which is not the case when running e.g. as a Xen PV guest. Fixes: 41d88484c71c ("x86/mm/pat: restore large ROX pages after fragmentation") Signed-off-by: Juergen Gross Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250528123557.12847-3-jgross@suse.com Signed-off-by: Greg Kroah-Hartman commit b07a09cf2a1c82f444c45ca603f9e03a9fccf758 Author: Lorenzo Stoakes Date: Fri Jun 6 13:50:32 2025 +0100 mm/vma: reset VMA iterator on commit_merge() OOM failure commit 0cf4b1687a187ba9247c71721d8b064634eda1f7 upstream. While an OOM failure in commit_merge() isn't really feasible due to the allocation which might fail (a maple tree pre-allocation) being 'too small to fail', we do need to handle this case correctly regardless. In vma_merge_existing_range(), we can theoretically encounter failures which result in an OOM error in two ways - firstly dup_anon_vma() might fail with an OOM error, and secondly commit_merge() failing, ultimately, to pre-allocate a maple tree node. The abort logic for dup_anon_vma() resets the VMA iterator to the initial range, ensuring that any logic looping on this iterator will correctly proceed to the next VMA. However the commit_merge() abort logic does not do the same thing. This resulted in a syzbot report occurring because mlockall() iterates through VMAs, is tolerant of errors, but ended up with an incorrect previous VMA being specified due to incorrect iterator state. While making this change, it became apparent we are duplicating logic - the logic introduced in commit 41e6ddcaa0f1 ("mm/vma: add give_up_on_oom option on modify/merge, use in uffd release") duplicates the vmg->give_up_on_oom check in both abort branches. Additionally, we observe that we can perform the anon_dup check safely on dup_anon_vma() failure, as this will not be modified should this call fail. Finally, we need to reset the iterator in both cases, so now we can simply use the exact same code to abort for both. We remove the VM_WARN_ON(err != -ENOMEM) as it would be silly for this to be otherwise and it allows us to implement the abort check more neatly. Link: https://lkml.kernel.org/r/20250606125032.164249-1-lorenzo.stoakes@oracle.com Fixes: 47b16d0462a4 ("mm: abort vma_modify() on merge out of memory failure") Signed-off-by: Lorenzo Stoakes Reported-by: syzbot+d16409ea9ecc16ed261a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-mm/6842cc67.a00a0220.29ac89.003b.GAE@google.com/ Reviewed-by: Pedro Falcato Reviewed-by: Vlastimil Babka Reviewed-by: Liam R. Howlett Cc: Jann Horn Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 03f8140d1a05596dad5cbc367ebc73cf13d12801 Author: Marek Szyprowski Date: Wed May 7 18:09:12 2025 +0200 udmabuf: use sgtable-based scatterlist wrappers commit afe382843717d44b24ef5014d57dcbaab75a4052 upstream. Use common wrappers operating directly on the struct sg_table objects to fix incorrect use of scatterlists sync calls. dma_sync_sg_for_*() functions have to be called with the number of elements originally passed to dma_map_sg_*() function, not the one returned in sgtable's nents. Fixes: 1ffe09590121 ("udmabuf: fix dma-buf cpu access") CC: stable@vger.kernel.org Signed-off-by: Marek Szyprowski Acked-by: Vivek Kasireddy Reviewed-by: Christian König Signed-off-by: Christian König Link: https://lore.kernel.org/r/20250507160913.2084079-3-m.szyprowski@samsung.com Signed-off-by: Greg Kroah-Hartman commit 79d77e8689e606899313658a4f302f210d582e0f Author: Ryan Roberts Date: Fri Jun 6 10:28:07 2025 +0100 mm: close theoretical race where stale TLB entries could linger commit 383c4613c67c26e90e8eebb72e3083457d02033f upstream. Commit 3ea277194daa ("mm, mprotect: flush TLB if potentially racing with a parallel reclaim leaving stale TLB entries") described a theoretical race as such: """ Nadav Amit identified a theoretical race between page reclaim and mprotect due to TLB flushes being batched outside of the PTL being held. He described the race as follows: CPU0 CPU1 ---- ---- user accesses memory using RW PTE [PTE now cached in TLB] try_to_unmap_one() ==> ptep_get_and_clear() ==> set_tlb_ubc_flush_pending() mprotect(addr, PROT_READ) ==> change_pte_range() ==> [ PTE non-present - no flush ] user writes using cached RW PTE ... try_to_unmap_flush() The same type of race exists for reads when protecting for PROT_NONE and also exists for operations that can leave an old TLB entry behind such as munmap, mremap and madvise. """ The solution was to introduce flush_tlb_batched_pending() and call it under the PTL from mprotect/madvise/munmap/mremap to complete any pending tlb flushes. However, while madvise_free_pte_range() and madvise_cold_or_pageout_pte_range() were both retro-fitted to call flush_tlb_batched_pending() immediately after initially acquiring the PTL, they both temporarily release the PTL to split a large folio if they stumble upon one. In this case, where re-acquiring the PTL flush_tlb_batched_pending() must be called again, but it previously was not. Let's fix that. There are 2 Fixes: tags here: the first is the commit that fixed madvise_free_pte_range(). The second is the commit that added madvise_cold_or_pageout_pte_range(), which looks like it copy/pasted the faulty pattern from madvise_free_pte_range(). This is a theoretical bug discovered during code review. Link: https://lkml.kernel.org/r/20250606092809.4194056-1-ryan.roberts@arm.com Fixes: 3ea277194daa ("mm, mprotect: flush TLB if potentially racing with a parallel reclaim leaving stale TLB entries") Fixes: 9c276cc65a58 ("mm: introduce MADV_COLD") Signed-off-by: Ryan Roberts Reviewed-by: Jann Horn Acked-by: David Hildenbrand Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Mel Gorman Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e9994e7b9f7bbb882d13c8191731649249150d21 Author: Jakub Kicinski Date: Mon Jun 9 17:12:44 2025 -0700 net: clear the dst when changing skb protocol commit ba9db6f907ac02215e30128770f85fbd7db2fcf9 upstream. A not-so-careful NAT46 BPF program can crash the kernel if it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10) The output interface has a 4->6 program attached at ingress. We try to loop the multicast skb back to the sending socket. Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr and changes skb->protocol to v6. We enter ip6_rcv_core which tries to use skb_dst(). But the dst is still an IPv4 one left after IPv4 mcast output. Clear the dst in all BPF helpers which change the protocol. Try to preserve metadata dsts, those may carry non-routing metadata. Cc: stable@vger.kernel.org Reviewed-by: Maciej Żenczykowski Acked-by: Daniel Borkmann Fixes: d219df60a70e ("bpf: Add ipip6 and ip6ip decap support for bpf_skb_adjust_room()") Fixes: 1b00e0dfe7d0 ("bpf: update skb->protocol in bpf_skb_net_grow") Fixes: 6578171a7ff0 ("bpf: add bpf_skb_change_proto helper") Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20250610001245.1981782-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 590b2d7d0beadba2aa576708a05a05f0aae39295 Author: Eric Dumazet Date: Wed Jun 11 08:35:01 2025 +0000 net_sched: sch_sfq: reject invalid perturb period commit 7ca52541c05c832d32b112274f81a985101f9ba8 upstream. Gerrard Tai reported that SFQ perturb_period has no range check yet, and this can be used to trigger a race condition fixed in a separate patch. We want to make sure ctl->perturb_period * HZ will not overflow and is positive. Tested: tc qd add dev lo root sfq perturb -10 # negative value : error Error: sch_sfq: invalid perturb period. tc qd add dev lo root sfq perturb 1000000000 # too big : error Error: sch_sfq: invalid perturb period. tc qd add dev lo root sfq perturb 2000000 # acceptable value tc -s -d qd sh dev lo qdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Gerrard Tai Signed-off-by: Eric Dumazet Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250611083501.1810459-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2df1baccc3f7409cc1e6f95b297c483c841ff21d Author: Jens Axboe Date: Fri Jun 13 13:37:41 2025 -0600 nvme: always punt polled uring_cmd end_io work to task_work commit 9ce6c9875f3e995be5fd720b65835291f8a609b1 upstream. Currently NVMe uring_cmd completions will complete locally, if they are polled. This is done because those completions are always invoked from task context. And while that is true, there's no guarantee that it's invoked under the right ring context, or even task. If someone does NVMe passthrough via multiple threads and with a limited number of poll queues, then ringA may find completions from ringB. For that case, completing the request may not be sound. Always just punt the passthrough completions via task_work, which will redirect the completion, if needed. Cc: stable@vger.kernel.org Fixes: 585079b6e425 ("nvme: wire up async polling for io passthrough commands") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9282a49960b0656ebfa7fc4e99dedc7935163a45 Author: Peter Oberparleiter Date: Tue Jun 3 20:21:56 2025 +0200 scsi: s390: zfcp: Ensure synchronous unit_add commit 9697ca0d53e3db357be26d2414276143c4a2cd49 upstream. Improve the usability of the unit_add sysfs attribute by ensuring that the associated FCP LUN scan processing is completed synchronously. This enables configuration tooling to consistently determine the end of the scan process to allow for serialization of follow-on actions. While the scan process associated with unit_add typically completes synchronously, it is deferred to an asynchronous background process if unit_add is used before initial remote port scanning has completed. This occurs when unit_add is used immediately after setting the associated FCP device online. To ensure synchronous unit_add processing, wait for remote port scanning to complete before initiating the FCP LUN scan. Cc: stable@vger.kernel.org Reviewed-by: M Nikhil Reviewed-by: Nihar Panda Signed-off-by: Peter Oberparleiter Signed-off-by: Nihar Panda Link: https://lore.kernel.org/r/20250603182252.2287285-2-niharp@linux.ibm.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit a8d20b079dc6754a55414bca0ef29a9c6d83aa82 Author: Dexuan Cui Date: Fri Jun 6 13:57:39 2025 -0700 scsi: storvsc: Increase the timeouts to storvsc_timeout commit b2f966568faaad326de97481096d0f3dc0971c43 upstream. Currently storvsc_timeout is only used in storvsc_sdev_configure(), and 5s and 10s are used elsewhere. It turns out that rarely the 5s is not enough on Azure, so let's use storvsc_timeout everywhere. In case a timeout happens and storvsc_channel_init() returns an error, close the VMBus channel so that any host-to-guest messages in the channel's ringbuffer, which might come late, can be safely ignored. Add a "const" to storvsc_timeout. Cc: stable@kernel.org Signed-off-by: Dexuan Cui Link: https://lore.kernel.org/r/1749243459-10419-1-git-send-email-decui@microsoft.com Reviewed-by: Long Li Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 000da85bc9270c18cb83a5609f27acdc2a1bb36a Author: Bharath SM Date: Wed Jun 11 16:59:02 2025 +0530 smb: improve directory cache reuse for readdir operations commit 72dd7961a4bb4fa1fc456169a61dd12e68e50645 upstream. Currently, cached directory contents were not reused across subsequent 'ls' operations because the cache validity check relied on comparing the ctx pointer, which changes with each readdir invocation. As a result, the cached dir entries was not marked as valid and the cache was not utilized for subsequent 'ls' operations. This change uses the file pointer, which remains consistent across all readdir calls for a given directory instance, to associate and validate the cache. As a result, cached directory contents can now be correctly reused, improving performance for repeated directory listings. Performance gains with local windows SMB server: Without the patch and default actimeo=1: 1000 directory enumeration operations on dir with 10k files took 135.0s With this patch and actimeo=0: 1000 directory enumeration operations on dir with 10k files took just 5.1s Signed-off-by: Bharath SM Reviewed-by: Shyam Prasad N Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 174b5ad50e29e62d1a55aa705c3c27f1837375ff Author: Steven Rostedt Date: Fri Jun 6 20:20:20 2025 -0400 tracing: Fix regression of filter waiting a long time on RCU synchronization commit a9d0aab5eb33a44792a66b7af13ff50d7b3e7022 upstream. When faultable trace events were added, a trace event may no longer use normal RCU to synchronize but instead used synchronize_rcu_tasks_trace(). This synchronization takes a much longer time to synchronize. The filter logic would free the filters by calling tracepoint_synchronize_unregister() after it unhooked the filter strings and before freeing them. With this function now calling synchronize_rcu_tasks_trace() this increased the time to free a filter tremendously. On a PREEMPT_RT system, it was even more noticeable. # time trace-cmd record -p function sleep 1 [..] real 2m29.052s user 0m0.244s sys 0m20.136s As trace-cmd would clear out all the filters before recording, it could take up to 2 minutes to do a recording of "sleep 1". To find out where the issues was: ~# trace-cmd sqlhist -e -n sched_stack select start.prev_state as state, end.next_comm as comm, TIMESTAMP_DELTA_USECS as delta, start.STACKTRACE as stack from sched_switch as start join sched_switch as end on start.prev_pid = end.next_pid Which will produce the following commands (and -e will also execute them): echo 's:sched_stack s64 state; char comm[16]; u64 delta; unsigned long stack[];' >> /sys/kernel/tracing/dynamic_events echo 'hist:keys=prev_pid:__arg_18057_2=prev_state,__arg_18057_4=common_timestamp.usecs,__arg_18057_7=common_stacktrace' >> /sys/kernel/tracing/events/sched/sched_switch/trigger echo 'hist:keys=next_pid:__state_18057_1=$__arg_18057_2,__comm_18057_3=next_comm,__delta_18057_5=common_timestamp.usecs-$__arg_18057_4,__stack_18057_6=$__arg_18057_7:onmatch(sched.sched_switch).trace(sched_stack,$__state_18057_1,$__comm_18057_3,$__delta_18057_5,$__stack_18057_6)' >> /sys/kernel/tracing/events/sched/sched_switch/trigger The above creates a synthetic event that creates a stack trace when a task schedules out and records it with the time it scheduled back in. Basically the time a task is off the CPU. It also records the state of the task when it left the CPU (running, blocked, sleeping, etc). It also saves the comm of the task as "comm" (needed for the next command). ~# echo 'hist:keys=state,stack.stacktrace:vals=delta:sort=state,delta if comm == "trace-cmd" && state & 3' > /sys/kernel/tracing/events/synthetic/sched_stack/trigger The above creates a histogram with buckets per state, per stack, and the value of the total time it was off the CPU for that stack trace. It filters on tasks with "comm == trace-cmd" and only the sleeping and blocked states (1 - sleeping, 2 - blocked). ~# trace-cmd record -p function sleep 1 ~# cat /sys/kernel/tracing/events/synthetic/sched_stack/hist | tail -18 { state: 2, stack.stacktrace __schedule+0x1545/0x3700 schedule+0xe2/0x390 schedule_timeout+0x175/0x200 wait_for_completion_state+0x294/0x440 __wait_rcu_gp+0x247/0x4f0 synchronize_rcu_tasks_generic+0x151/0x230 apply_subsystem_event_filter+0xa2b/0x1300 subsystem_filter_write+0x67/0xc0 vfs_write+0x1e2/0xeb0 ksys_write+0xff/0x1d0 do_syscall_64+0x7b/0x420 entry_SYSCALL_64_after_hwframe+0x76/0x7e } hitcount: 237 delta: 99756288 <<--------------- Delta is 99 seconds! Totals: Hits: 525 Entries: 21 Dropped: 0 This shows that this particular trace waited for 99 seconds on synchronize_rcu_tasks() in apply_subsystem_event_filter(). In fact, there's a lot of places in the filter code that spends a lot of time waiting for synchronize_rcu_tasks_trace() in order to free the filters. Add helper functions that will use call_rcu*() variants to asynchronously free the filters. This brings the timings back to normal: # time trace-cmd record -p function sleep 1 [..] real 0m14.681s user 0m0.335s sys 0m28.616s And the histogram also shows this: ~# cat /sys/kernel/tracing/events/synthetic/sched_stack/hist | tail -21 { state: 2, stack.stacktrace __schedule+0x1545/0x3700 schedule+0xe2/0x390 schedule_timeout+0x175/0x200 wait_for_completion_state+0x294/0x440 __wait_rcu_gp+0x247/0x4f0 synchronize_rcu_normal+0x3db/0x5c0 tracing_reset_online_cpus+0x8f/0x1e0 tracing_open+0x335/0x440 do_dentry_open+0x4c6/0x17a0 vfs_open+0x82/0x360 path_openat+0x1a36/0x2990 do_filp_open+0x1c5/0x420 do_sys_openat2+0xed/0x180 __x64_sys_openat+0x108/0x1d0 do_syscall_64+0x7b/0x420 } hitcount: 2 delta: 77044 Totals: Hits: 55 Entries: 28 Dropped: 0 Where the total waiting time of synchronize_rcu_tasks_trace() is 77 milliseconds. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: "Paul E. McKenney" Cc: Jan Kiszka Cc: Andreas Ziegler Cc: Felix MOESSBAUER Link: https://lore.kernel.org/20250606201936.1e3d09a9@batman.local.home Reported-by: "Flot, Julien" Tested-by: Julien Flot Fixes: a363d27cdbc2 ("tracing: Allow system call tracepoints to handle page faults") Closes: https://lore.kernel.org/all/240017f656631c7dd4017aa93d91f41f653788ea.camel@siemens.com/ Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 4f81ee0af2b8c4089e308f7cb6b5ea5a4efe5b94 Author: Shyam Prasad N Date: Mon Jun 2 22:37:17 2025 +0530 cifs: do not disable interface polling on failure commit 42ca547b13a20e7cbb04fbdf8d5f089ac4bb35b7 upstream. When a server has multichannel enabled, we keep polling the server for interfaces periodically. However, when this query fails, we disable the polling. This can be problematic as it takes away the chance for the server to start advertizing again. This change reschedules the delayed work, even if the current call failed. That way, multichannel sessions can recover. Signed-off-by: Shyam Prasad N Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a9022c2180bdc31942c890935c3ac09fc4887427 Author: Shyam Prasad N Date: Mon Jun 2 22:37:15 2025 +0530 cifs: serialize other channels when query server interfaces is pending commit b5e3e6e28cf3853566ba5d816f79aba5be579158 upstream. Today, during smb2_reconnect, session_mutex is released as soon as the tcon is reconnected and is in a good state. However, in case multichannel is enabled, there is also a query of server interfaces that follows. We've seen that this query can race with reconnects of other channels, causing them to step on each other with reconnects. This change extends the hold of session_mutex till after the query of server interfaces is complete. In order to avoid recursive smb2_reconnect checks during query ioctl, this change also introduces a session flag for sessions where such a query is in progress. Signed-off-by: Shyam Prasad N Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 75f021b020e6c20e717bcd9e442795e9fa3099d8 Author: Shyam Prasad N Date: Mon Jun 2 22:37:12 2025 +0530 cifs: deal with the channel loading lag while picking channels commit 66d590b828b1fd9fa337047ae58fe1c4c6f43609 upstream. Our current approach to select a channel for sending requests is this: 1. iterate all channels to find the min and max queue depth 2. if min and max are not the same, pick the channel with min depth 3. if min and max are same, round robin, as all channels are equally loaded The problem with this approach is that there's a lag between selecting a channel and sending the request (that increases the queue depth on the channel). While these numbers will eventually catch up, there could be a skew in the channel usage, depending on the application's I/O parallelism and the server's speed of handling requests. With sufficient parallelism, this lag can artificially increase the queue depth, thereby impacting the performance negatively. This change will change the step 1 above to start the iteration from the last selected channel. This is to reduce the skew in channel usage even in the presence of this lag. Fixes: ea90708d3cf3 ("cifs: use the least loaded channel for sending requests") Cc: Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 042fa922c84b5080401bcd8897d4ac4919d15075 Author: Fedor Pchelkin Date: Tue Mar 25 19:32:13 2025 +0300 jffs2: check jffs2_prealloc_raw_node_refs() result in few other places commit 2b6d96503255a3ed676cd70f8368870c6d6a25c6 upstream. Fuzzing hit another invalid pointer dereference due to the lack of checking whether jffs2_prealloc_raw_node_refs() completed successfully. Subsequent logic implies that the node refs have been allocated. Handle that. The code is ready for propagating the error upwards. KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 5835 Comm: syz-executor145 Not tainted 5.10.234-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_link_node_ref+0xac/0x690 fs/jffs2/nodelist.c:600 Call Trace: jffs2_mark_erased_block fs/jffs2/erase.c:460 [inline] jffs2_erase_pending_blocks+0x688/0x1860 fs/jffs2/erase.c:118 jffs2_garbage_collect_pass+0x638/0x1a00 fs/jffs2/gc.c:253 jffs2_reserve_space+0x3f4/0xad0 fs/jffs2/nodemgmt.c:167 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362 jffs2_write_end+0x712/0x1110 fs/jffs2/file.c:302 generic_perform_write+0x2c2/0x500 mm/filemap.c:3347 __generic_file_write_iter+0x252/0x610 mm/filemap.c:3465 generic_file_write_iter+0xdb/0x230 mm/filemap.c:3497 call_write_iter include/linux/fs.h:2039 [inline] do_iter_readv_writev+0x46d/0x750 fs/read_write.c:740 do_iter_write+0x18c/0x710 fs/read_write.c:866 vfs_writev+0x1db/0x6a0 fs/read_write.c:939 do_pwritev fs/read_write.c:1036 [inline] __do_sys_pwritev fs/read_write.c:1083 [inline] __se_sys_pwritev fs/read_write.c:1078 [inline] __x64_sys_pwritev+0x235/0x310 fs/read_write.c:1078 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 2f785402f39b ("[JFFS2] Reduce visibility of raw_node_ref to upper layers of JFFS2 code.") Fixes: f560928baa60 ("[JFFS2] Allocate node_ref for wasted space when skipping to page boundary") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 346cfb9d19ea7feb6fb57917b21c4797fb444dab Author: Artem Sadovnikov Date: Fri Mar 7 16:34:09 2025 +0000 jffs2: check that raw node were preallocated before writing summary commit ec9e6f22bce433b260ea226de127ec68042849b0 upstream. Syzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault injection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn't check return value of jffs2_prealloc_raw_node_refs and simply lets any error propagate into jffs2_sum_write_data, which eventually calls jffs2_link_node_ref in order to link the summary to an expectedly allocated node. kernel BUG at fs/jffs2/nodelist.c:592! invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592 Call Trace: jffs2_sum_write_data fs/jffs2/summary.c:841 [inline] jffs2_sum_write_sumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874 jffs2_do_reserve_space+0xa18/0xd60 fs/jffs2/nodemgmt.c:388 jffs2_reserve_space+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362 jffs2_write_end+0x726/0x15d0 fs/jffs2/file.c:301 generic_perform_write+0x314/0x5d0 mm/filemap.c:3856 __generic_file_write_iter+0x2ae/0x4d0 mm/filemap.c:3973 generic_file_write_iter+0xe3/0x350 mm/filemap.c:4005 call_write_iter include/linux/fs.h:2265 [inline] do_iter_readv_writev+0x20f/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10c/0x170 fs/splice.c:950 splice_direct_to_actor+0x337/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Fix this issue by checking return value of jffs2_prealloc_raw_node_refs before calling jffs2_sum_write_data. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Cc: stable@vger.kernel.org Fixes: 2f785402f39b ("[JFFS2] Reduce visibility of raw_node_ref to upper layers of JFFS2 code.") Signed-off-by: Artem Sadovnikov Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 0000a2303ba78b6424ff15b5085b5f5098750a2e Author: Jaroslav Kysela Date: Fri May 23 17:58:14 2025 +0200 firmware: cs_dsp: Fix OOB memory read access in KUnit test (wmfw info) commit d979b783d61f7f1f95664031b71a33afc74627b2 upstream. KASAN reported out of bounds access - cs_dsp_mock_wmfw_add_info(), because the source string length was rounded up to the allocation size. Cc: Simon Trimmer Cc: Charles Keepax Cc: Richard Fitzgerald Cc: patches@opensource.cirrus.com Cc: stable@vger.kernel.org Signed-off-by: Jaroslav Kysela Reviewed-by: Richard Fitzgerald Link: https://patch.msgid.link/20250523155814.1256762-1-perex@perex.cz Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e3dafc64b90546eb769f33333afabd9e3e915757 Author: Jaroslav Kysela Date: Fri May 23 17:41:51 2025 +0200 firmware: cs_dsp: Fix OOB memory read access in KUnit test (ctl cache) commit f4ba2ea57da51d616b689c4b8826c517ff5a8523 upstream. KASAN reported out of bounds access - cs_dsp_ctl_cache_init_multiple_offsets(). The code uses mock_coeff_template.length_bytes (4 bytes) for register value allocations. But later, this length is set to 8 bytes which causes test code failures. As fix, just remove the lenght override, keeping the original value 4 for all operations. Cc: Simon Trimmer Cc: Charles Keepax Cc: Richard Fitzgerald Cc: patches@opensource.cirrus.com Cc: stable@vger.kernel.org Signed-off-by: Jaroslav Kysela Reviewed-by: Richard Fitzgerald Link: https://patch.msgid.link/20250523154151.1252585-1-perex@perex.cz Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b5c7397b7fd125203c60b59860c168ee92291272 Author: Tianyang Zhang Date: Fri May 30 21:45:57 2025 +0800 LoongArch: Fix panic caused by NULL-PMD in huge_pte_offset() commit ee084fa96123ede8b0563a1b5a9b23adc43cd50d upstream. ERROR INFO: CPU 25 Unable to handle kernel paging request at virtual address 0x0 ... Call Trace: [<900000000023c30c>] huge_pte_offset+0x3c/0x58 [<900000000057fd4c>] hugetlb_follow_page_mask+0x74/0x438 [<900000000051fee8>] __get_user_pages+0xe0/0x4c8 [<9000000000522414>] faultin_page_range+0x84/0x380 [<9000000000564e8c>] madvise_vma_behavior+0x534/0xa48 [<900000000056689c>] do_madvise+0x1bc/0x3e8 [<9000000000566df4>] sys_madvise+0x24/0x38 [<90000000015b9e88>] do_syscall+0x78/0x98 [<9000000000221f18>] handle_syscall+0xb8/0x158 In some cases, pmd may be NULL and rely on NULL as the return value for processing, so it is necessary to determine this situation here. Cc: stable@vger.kernel.org Fixes: bd51834d1cf6 ("LoongArch: Return NULL from huge_pte_offset() for invalid PMD") Signed-off-by: Tianyang Zhang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit ef534ebbdcb19f737504e9b35a5237c42995a715 Author: Huacai Chen Date: Fri May 30 21:45:48 2025 +0800 LoongArch: Avoid using $r0/$r1 as "mask" for csrxchg commit 52c22661c79a7b6af7fad9f77200738fc6c51878 upstream. When building kernel with LLVM there are occasionally such errors: In file included from ./include/linux/spinlock.h:59: In file included from ./include/linux/irqflags.h:17: arch/loongarch/include/asm/irqflags.h:38:3: error: must not be $r0 or $r1 38 | "csrxchg %[val], %[mask], %[reg]\n\t" | ^ :1:16: note: instantiated into assembly here 1 | csrxchg $a1, $ra, 0 | ^ To prevent the compiler from allocating $r0 or $r1 for the "mask" of the csrxchg instruction, the 'q' constraint must be used but Clang < 21 does not support it. So force to use $t0 in the inline asm, in order to avoid using $r0/$r1 while keeping the backward compatibility. Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/pull/141037 Reviewed-by: Yanteng Si Suggested-by: WANG Rui Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit c67aad48ad17bc99bddb2a6f45a2f249772982de Author: Thomas Weißschuh Date: Thu Jun 5 20:34:18 2025 +0800 LoongArch: vDSO: Correctly use asm parameters in syscall wrappers commit e242bbbb6d7ac7556aa1e358294dc7e3c82cc902 upstream. The syscall wrappers use the "a0" register for two different register variables, both the first argument and the return value. Here the "ret" variable is used as both input and output while the argument register is only used as input. Clang treats the conflicting input parameters as an undefined behaviour and optimizes away the argument assignment. The code seems to work by chance for the most part today but that may change in the future. Specifically clock_gettime_fallback() fails with clockids from 16 to 23, as implemented by the upcoming auxiliary clocks. Switch the "ret" register variable to a pure output, similar to the other architectures' vDSO code. This works in both clang and GCC. Link: https://lore.kernel.org/lkml/20250602102825-42aa84f0-23f1-4d10-89fc-e8bbaffd291a@linutronix.de/ Link: https://lore.kernel.org/lkml/20250519082042.742926976@linutronix.de/ Fixes: c6b99bed6b8f ("LoongArch: Add VDSO and VSYSCALL support") Fixes: 18efd0b10e0f ("LoongArch: vDSO: Wire up getrandom() vDSO implementation") Cc: stable@vger.kernel.org Reviewed-by: Nathan Chancellor Reviewed-by: Yanteng Si Reviewed-by: WANG Xuerui Reviewed-by: Xi Ruoyao Signed-off-by: Thomas Weißschuh Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 23fee9bfc5ddf1301f48fcbf7086a230000e1a67 Author: Yao Zi Date: Thu Jun 5 20:34:46 2025 +0800 platform/loongarch: laptop: Add backlight power control support commit 53c762b47f726e4079a1f06f684bce2fc0d56fba upstream. loongson_laptop_turn_{on,off}_backlight() are designed for controlling the power of the backlight, but they aren't really used in the driver previously. Unify these two functions since they only differ in arguments passed to ACPI method, and wire up loongson_laptop_backlight_update() to update the power state of the backlight as well. Tested on the TongFang L860-T2 Loongson-3A5000 laptop. Cc: stable@vger.kernel.org Fixes: 6246ed09111f ("LoongArch: Add ACPI-based generic laptop driver") Signed-off-by: Yao Zi Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit bfac571ccbf91964a51598bd1d1f4c83a00734dc Author: Yao Zi Date: Thu Jun 5 20:34:46 2025 +0800 platform/loongarch: laptop: Unregister generic_sub_drivers on exit commit f78fb2576f22b0ba5297412a9aa7691920666c41 upstream. Without correct unregisteration, ACPI notify handlers and the platform drivers installed by generic_subdriver_init() will become dangling references after removing the loongson_laptop module, triggering various kernel faults when a hotkey is sent or at kernel shutdown. Cc: stable@vger.kernel.org Fixes: 6246ed09111f ("LoongArch: Add ACPI-based generic laptop driver") Signed-off-by: Yao Zi Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 84046c21c3f8b9a16642975120f013ed410963ea Author: Yao Zi Date: Thu Jun 5 20:34:46 2025 +0800 platform/loongarch: laptop: Get brightness setting from EC on probe commit 1205088fd0393bd9eae96b62bf1e4b9eb1b73edf upstream. Previously during driver probe, 1 is unconditionally taken as current brightness value and set to props.brightness, which will be considered as the brightness before suspend and restored to EC on resume. Since a brightness value of 1 almost never matches EC's state on coldboot (my laptop's EC defaults to 80), this causes surprising changes of screen brightness on the first time of resume after coldboot. Let's get brightness from EC and take it as the current brightness on probe of the laptop driver to avoid the surprising behavior. Tested on TongFang L860-T2 Loongson-3A5000 laptop. Cc: stable@vger.kernel.org Fixes: 6246ed09111f ("LoongArch: Add ACPI-based generic laptop driver") Signed-off-by: Yao Zi Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 6d5c6711a55c35ce09b90705546050408d9d4b61 Author: Andrew Morton Date: Sat Jun 7 17:43:18 2025 -0700 drivers/rapidio/rio_cm.c: prevent possible heap overwrite commit 50695153d7ddde3b1696dbf0085be0033bf3ddb3 upstream. In riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send() cm_chan_msg_send() checks that userspace didn't send too much data but riocm_ch_send() failed to check that userspace sent sufficient data. The result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr which were outside the bounds of the space which cm_chan_msg_send() allocated. Address this by teaching riocm_ch_send() to check that the entire rio_ch_chan_hdr was copied in from userspace. Reported-by: maher azz Cc: Matt Porter Cc: Alexandre Bounine Cc: Linus Torvalds Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3b1fedf02d7ec33cf42bc5dbd948c4c77d337075 Author: Penglei Jiang Date: Sun Jun 15 09:39:06 2025 -0700 io_uring: fix task leak issue in io_wq_create() commit 89465d923bda180299e69ee2800aab84ad0ba689 upstream. Add missing put_task_struct() in the error path Cc: stable@vger.kernel.org Fixes: 0f8baa3c9802 ("io-wq: fully initialize wqe before calling cpuhp_state_add_instance_nocalls()") Signed-off-by: Penglei Jiang Link: https://lore.kernel.org/r/20250615163906.2367-1-superman.xpt@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0e23ac818f3afb16660b0ba384875d56a7013879 Author: Jens Axboe Date: Sun Jun 15 08:09:14 2025 -0600 io_uring/rsrc: validate buffer count with offset for cloning commit 1d27f11bf02b38c431e49a17dee5c10a2b4c2e28 upstream. syzbot reports that it can trigger a WARN_ON() for kmalloc() attempt that's too big: WARNING: CPU: 0 PID: 6488 at mm/slub.c:5024 __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 Modules linked in: CPU: 0 UID: 0 PID: 6488 Comm: syz-executor312 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 lr : __do_kmalloc_node mm/slub.c:-1 [inline] lr : __kvmalloc_node_noprof+0x3b4/0x640 mm/slub.c:5012 sp : ffff80009cfd7a90 x29: ffff80009cfd7ac0 x28: ffff0000dd52a120 x27: 0000000000412dc0 x26: 0000000000000178 x25: ffff7000139faf70 x24: 0000000000000000 x23: ffff800082f4cea8 x22: 00000000ffffffff x21: 000000010cd004a8 x20: ffff0000d75816c0 x19: ffff0000dd52a000 x18: 00000000ffffffff x17: ffff800092f39000 x16: ffff80008adbe9e4 x15: 0000000000000005 x14: 1ffff000139faf1c x13: 0000000000000000 x12: 0000000000000000 x11: ffff7000139faf21 x10: 0000000000000003 x9 : ffff80008f27b938 x8 : 0000000000000002 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 00000000ffffffff x4 : 0000000000400dc0 x3 : 0000000200000000 x2 : 000000010cd004a8 x1 : ffff80008b3ebc40 x0 : 0000000000000001 Call trace: __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 (P) kvmalloc_array_node_noprof include/linux/slab.h:1065 [inline] io_rsrc_data_alloc io_uring/rsrc.c:206 [inline] io_clone_buffers io_uring/rsrc.c:1178 [inline] io_register_clone_buffers+0x484/0xa14 io_uring/rsrc.c:1287 __io_uring_register io_uring/register.c:815 [inline] __do_sys_io_uring_register io_uring/register.c:926 [inline] __se_sys_io_uring_register io_uring/register.c:903 [inline] __arm64_sys_io_uring_register+0x42c/0xea8 io_uring/register.c:903 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 which is due to offset + buffer_count being too large. The registration code checks only the total count of buffers, but given that the indexing is an array, it should also check offset + count. That can't exceed IORING_MAX_REG_BUFFERS either, as there's no way to reach buffers beyond that limit. There's no issue with registrering a table this large, outside of the fact that it's pointless to register buffers that cannot be reached, and that it can trigger this kmalloc() warning for attempting an allocation that is too large. Cc: stable@vger.kernel.org Fixes: b16e920a1909 ("io_uring/rsrc: allow cloning at an offset") Reported-by: syzbot+cb4bf3cb653be0d25de8@syzkaller.appspotmail.com Link: https://lore.kernel.org/io-uring/684e77bd.a00a0220.279073.0029.GAE@google.com/ Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 907e59afbe7b79e0ea2746926182ceee15ce32fa Author: Jens Axboe Date: Fri Jun 13 11:01:49 2025 -0600 io_uring/kbuf: don't truncate end buffer for multiple buffer peeks commit 26ec15e4b0c1d7b25214d9c0be1d50492e2f006c upstream. If peeking a bunch of buffers, normally io_ring_buffers_peek() will truncate the end buffer. This isn't optimal as presumably more data will be arriving later, and hence it's better to stop with the last full buffer rather than truncate the end buffer. Cc: stable@vger.kernel.org Fixes: 35c8711c8fc4 ("io_uring/kbuf: add helpers for getting/peeking multiple buffers") Reported-by: Christian Mazakas Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 361527bd6fff3e4c19221cfe85136985129d007a Author: Luis Henriques Date: Fri Jun 13 11:11:11 2025 +0100 fs: drop assert in file_seek_cur_needs_f_lock [ Upstream commit dd2d6b7f6f519d078a866a36a625b0297d81c5bc ] The assert in function file_seek_cur_needs_f_lock() can be triggered very easily because there are many users of vfs_llseek() (such as overlayfs) that do their custom locking around llseek instead of relying on fdget_pos(). Just drop the overzealous assertion. Fixes: da06e3c51794 ("fs: don't needlessly acquire f_lock") Suggested-by: Jan Kara Suggested-by: Mateusz Guzik Signed-off-by: Luis Henriques Link: https://lore.kernel.org/20250613101111.17716-1-luis@igalia.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit f10ab6f8ecfb875bb1ea283ad00a233cfecc7190 Author: Narayana Murty N Date: Thu May 8 02:29:28 2025 -0400 powerpc/eeh: Fix missing PE bridge reconfiguration during VFIO EEH recovery [ Upstream commit 33bc69cf6655cf60829a803a45275f11a74899e5 ] VFIO EEH recovery for PCI passthrough devices fails on PowerNV and pseries platforms due to missing host-side PE bridge reconfiguration. In the current implementation, eeh_pe_configure() only performs RTAS or OPAL-based bridge reconfiguration for native host devices, but skips it entirely for PEs managed through VFIO in guest passthrough scenarios. This leads to incomplete EEH recovery when a PCI error affects a passthrough device assigned to a QEMU/KVM guest. Although VFIO triggers the EEH recovery flow through VFIO_EEH_PE_ENABLE ioctl, the platform-specific bridge reconfiguration step is silently bypassed. As a result, the PE's config space is not fully restored, causing subsequent config space access failures or EEH freeze-on-access errors inside the guest. This patch fixes the issue by ensuring that eeh_pe_configure() always invokes the platform's configure_bridge() callback (e.g., pseries_eeh_phb_configure_bridge) even for VFIO-managed PEs. This ensures that RTAS or OPAL calls to reconfigure the PE bridge are correctly issued on the host side, restoring the PE's configuration space after an EEH event. This fix is essential for reliable EEH recovery in QEMU/KVM guests using VFIO PCI passthrough on PowerNV and pseries systems. Tested with: - QEMU/KVM guest using VFIO passthrough (IBM Power9,(lpar)Power11 host) - Injected EEH errors with pseries EEH errinjct tool on host, recovery verified on qemu guest. - Verified successful config space access and CAP_EXP DevCtl restoration after recovery Fixes: 212d16cdca2d ("powerpc/eeh: EEH support for VFIO PCI device") Signed-off-by: Narayana Murty N Reviewed-by: Vaibhav Jain Reviewed-by: Ganesh Goudar Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250508062928.146043-1-nnmlinux@linux.ibm.com Signed-off-by: Sasha Levin commit 97fcd5bcb0b9f32a9291dab1bc435109f04f8673 Author: Christophe Leroy Date: Mon May 12 20:14:55 2025 +0200 powerpc/vdso: Fix build of VDSO32 with pcrel [ Upstream commit b93755f408325170edb2156c6a894ed1cae5f4f6 ] Building vdso32 on power10 with pcrel leads to following errors: VDSO32A arch/powerpc/kernel/vdso/gettimeofday-32.o arch/powerpc/kernel/vdso/gettimeofday.S: Assembler messages: arch/powerpc/kernel/vdso/gettimeofday.S:40: Error: syntax error; found `@', expected `,' arch/powerpc/kernel/vdso/gettimeofday.S:71: Info: macro invoked from here arch/powerpc/kernel/vdso/gettimeofday.S:40: Error: junk at end of line: `@notoc' arch/powerpc/kernel/vdso/gettimeofday.S:71: Info: macro invoked from here ... make[2]: *** [arch/powerpc/kernel/vdso/Makefile:85: arch/powerpc/kernel/vdso/gettimeofday-32.o] Error 1 make[1]: *** [arch/powerpc/Makefile:388: vdso_prepare] Error 2 Once the above is fixed, the following happens: VDSO32C arch/powerpc/kernel/vdso/vgettimeofday-32.o cc1: error: '-mpcrel' requires '-mcmodel=medium' make[2]: *** [arch/powerpc/kernel/vdso/Makefile:89: arch/powerpc/kernel/vdso/vgettimeofday-32.o] Error 1 make[1]: *** [arch/powerpc/Makefile:388: vdso_prepare] Error 2 make: *** [Makefile:251: __sub-make] Error 2 Make sure pcrel version of CFUNC() macro is used only for powerpc64 builds and remove -mpcrel for powerpc32 builds. Fixes: 7e3a68be42e1 ("powerpc/64: vmlinux support building with PCREL addresing") Signed-off-by: Christophe Leroy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/1fa3453f07d42a50a70114da9905bf7b73304fca.1747073669.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 73ebbbbf28da933a36642a9e8cabcf1c04603250 Author: Amir Goldstein Date: Thu Jun 12 09:22:45 2025 +0200 ovl: fix debug print in case of mkdir error [ Upstream commit 527c88d8390d6c0358dea4d71696795c05328925 ] We want to print the name in case of mkdir failure and now we will get a cryptic (efault) as name. Fixes: c54b386969a5 ("VFS: Change vfs_mkdir() to return the dentry.") Signed-off-by: Amir Goldstein Link: https://lore.kernel.org/20250612072245.2825938-1-amir73il@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 6beac757731581dcfd96922a5a2f0f113579b65b Author: Stuart Hayes Date: Mon Jun 9 13:46:58 2025 -0500 platform/x86: dell_rbu: Stop overwriting data buffer [ Upstream commit f4b0fa38d5fefe9aed6ed831f3bd3538c168ee19 ] The dell_rbu driver will use memset() to clear the data held by each packet when it is no longer needed (when the driver is unloaded, the packet size is changed, etc). The amount of memory that is cleared (before this patch) is the normal packet size. However, the last packet in the list may be smaller. Fix this to only clear the memory actually used by each packet, to prevent it from writing past the end of data buffer. Because the packet data buffers are allocated with __get_free_pages() (in page-sized increments), this bug could only result in a buffer being overwritten when a packet size larger than one page is used. The only user of the dell_rbu module should be the Dell BIOS update program, which uses a packet size of 4096, so no issues should be seen without the patch, it just blocks the possiblity. Fixes: 6c54c28e69f2 ("[PATCH] dell_rbu: new Dell BIOS update driver") Signed-off-by: Stuart Hayes Link: https://lore.kernel.org/r/20250609184659.7210-5-stuart.w.hayes@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 32d05e6cc3a7bf6c8f16f7b7ef8fe80eca0c233e Author: Stuart Hayes Date: Mon Jun 9 13:46:56 2025 -0500 platform/x86: dell_rbu: Fix list usage [ Upstream commit 61ce04601e0d8265ec6d2ffa6df5a7e1bce64854 ] Pass the correct list head to list_for_each_entry*() when looping through the packet list. Without this patch, reading the packet data via sysfs will show the data incorrectly (because it starts at the wrong packet), and clearing the packet list will result in a NULL pointer dereference. Fixes: d19f359fbdc6 ("platform/x86: dell_rbu: don't open code list_for_each_entry*()") Signed-off-by: Stuart Hayes Link: https://lore.kernel.org/r/20250609184659.7210-3-stuart.w.hayes@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 2403ceef7e9d599d653f6843af997a47bf4cf17a Author: Mario Limonciello Date: Wed May 21 19:34:56 2025 -0500 platform/x86/amd: pmf: Prevent amd_pmf_tee_deinit() from running twice [ Upstream commit 93103d56650d7a38ed37ba4041578310f82776ae ] If any of the tee init fails, pass up the errors and clear the tee_ctx pointer. This will prevent cleaning up multiple times. Fixes: ac052d8c08f9d ("platform/x86/amd/pmf: Add PMF TEE interface") Suggested-by: Dan Carpenter Link: https://lore.kernel.org/r/20250512211154.2510397-3-superm1@kernel.org Signed-off-by: Mario Limonciello Link: https://lore.kernel.org/r/20250522003457.1516679-3-superm1@kernel.org Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 0d10b532f861253c283863522d59d099fcb0796d Author: Mario Limonciello Date: Wed May 21 19:34:55 2025 -0500 platform/x86/amd: pmf: Use device managed allocations [ Upstream commit d9db3a941270d92bbd1a6a6b54a10324484f2f2d ] If setting up smart PC fails for any reason then this can lead to a double free when unloading amd-pmf. This is because dev->buf was freed but never set to NULL and is again freed in amd_pmf_remove(). To avoid subtle allocation bugs in failures leading to a double free change all allocations into device managed allocations. Fixes: 5b1122fc4995f ("platform/x86/amd/pmf: fix cleanup in amd_pmf_init_smart_pc()") Link: https://lore.kernel.org/r/20250512211154.2510397-2-superm1@kernel.org Signed-off-by: Mario Limonciello Link: https://lore.kernel.org/r/20250522003457.1516679-2-superm1@kernel.org Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 35d08458faf3e2348dc863cda01f4ac419f213b3 Author: Mario Limonciello Date: Tue Jun 3 08:24:08 2025 -0500 platform/x86/amd: pmc: Clear metrics table at start of cycle [ Upstream commit 4dbd11796f3a8eb95647507befc41995458a4023 ] The area of memory that contains the metrics table may contain garbage when the cycle starts. This normally doesn't matter because the cycle itself will populate it with valid data, however commit 9f5595d5f03fd ("platform/x86/amd: pmc: Require at least 2.5 seconds between HW sleep cycles") started to use it during the check() phase. Depending upon what garbage is in the table it's possible that the system will wait 2.5 seconds for even the first cycle, which will be visible to a user. To prevent this from happening explicitly clear the table when logging is started. Fixes: 9f5595d5f03fd ("platform/x86/amd: pmc: Require at least 2.5 seconds between HW sleep cycles") Signed-off-by: Mario Limonciello Link: https://lore.kernel.org/r/20250603132412.3555302-1-superm1@kernel.org Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 2faba6d932ca9c27e4e49ee650bb8f151a2e0948 Author: Stephen Smalley Date: Thu Jun 5 12:51:16 2025 -0400 fs/xattr.c: fix simple_xattr_list() [ Upstream commit 800d0b9b6a8b1b354637b4194cc167ad1ce2bdd3 ] commit 8b0ba61df5a1 ("fs/xattr.c: fix simple_xattr_list to always include security.* xattrs") failed to reset err after the call to security_inode_listsecurity(), which returns the length of the returned xattr name. This results in simple_xattr_list() incorrectly returning this length even if a POSIX acl is also set on the inode. Reported-by: Collin Funk Closes: https://lore.kernel.org/selinux/8734ceal7q.fsf@gmail.com/ Reported-by: Paul Eggert Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2369561 Fixes: 8b0ba61df5a1 ("fs/xattr.c: fix simple_xattr_list to always include security.* xattrs") Signed-off-by: Stephen Smalley Link: https://lore.kernel.org/20250605165116.2063-1-stephen.smalley.work@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 40272dad0d0cfe1b8a7ee115c61f9d43b326c5e7 Author: Alexander Sverdlin Date: Tue Apr 1 11:06:34 2025 +0200 Revert "bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first" [ Upstream commit 36305857b1ead8f6ca033a913162ebc09bee0b43 ] This reverts commit 4700a00755fb5a4bb5109128297d6fd2d1272ee6. It breaks target-module@2b300050 ("ti,sysc-omap2") probe on AM62x in a case when minimally-configured system tries to network-boot: [ 6.888776] probe of 2b300050.target-module returned 517 after 258 usecs [ 17.129637] probe of 2b300050.target-module returned 517 after 708 usecs [ 17.137397] platform 2b300050.target-module: deferred probe pending: (reason unknown) [ 26.878471] Waiting up to 100 more seconds for network. There are minimal configurations possible when the deferred device is not being probed any more (because everything else has been successfully probed) and deferral lists are not processed any more. Stable mmc enumeration can be achieved by filling /aliases node properly (4700a00755fb commit's rationale). After revert: [ 9.006816] IP-Config: Complete: [ 9.010058] device=lan0, ... Tested-by: Andreas Kemnade # GTA04, Panda, BT200 Reviewed-by: Tony Lindgren Signed-off-by: Alexander Sverdlin Link: https://lore.kernel.org/r/20250401090643.2776793-1-alexander.sverdlin@siemens.com Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit 8ae695e28e9a0944498abed38c42ae3c8ec0c55f Author: Jann Horn Date: Mon Apr 28 15:06:43 2025 +0200 tee: Prevent size calculation wraparound on 32-bit kernels [ Upstream commit 39bb67edcc582b3b386a9ec983da67fa8a10ec03 ] The current code around TEE_IOCTL_PARAM_SIZE() is a bit wrong on 32-bit kernels: Multiplying a user-provided 32-bit value with the size of a structure can wrap around on such platforms. Fix it by using saturating arithmetic for the size calculation. This has no security consequences because, in all users of TEE_IOCTL_PARAM_SIZE(), the subsequent kcalloc() implicitly checks for wrapping. Signed-off-by: Jann Horn Signed-off-by: Jens Wiklander Tested-by: Rouven Czerwinski Signed-off-by: Sasha Levin commit 980023246f20bbbffb5ef6c96cbff6ca2074e4b6 Author: Sukrut Bellary Date: Tue Mar 18 16:00:39 2025 -0700 ARM: OMAP2+: Fix l4ls clk domain handling in STANDBY [ Upstream commit 47fe74098f3dadba2f9cc1e507d813a4aa93f5f3 ] Don't put the l4ls clk domain to sleep in case of standby. Since CM3 PM FW[1](ti-v4.1.y) doesn't wake-up/enable the l4ls clk domain upon wake-up, CM3 PM FW fails to wake-up the MPU. [1] https://git.ti.com/cgit/processor-firmware/ti-amx3-cm3-pm-firmware/ Signed-off-by: Sukrut Bellary Tested-by: Judith Mendez Link: https://lore.kernel.org/r/20250318230042.3138542-2-sbellary@baylibre.com Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit aeaae04ad9dd0e27ee153e0b7d60dfddc6dd17b3 Author: Laurentiu Tudor Date: Tue Apr 8 13:58:14 2025 +0300 bus: fsl-mc: increase MC_CMD_COMPLETION_TIMEOUT_MS value [ Upstream commit 23d060136841c58c2f9ee8c08ad945d1879ead4b ] In case the MC firmware runs in debug mode with extensive prints pushed to the console, the current timeout of 500ms is not enough. Increase the timeout value so that we don't have any chance of wrongly assuming that the firmware is not responding when it's just taking more time. Signed-off-by: Laurentiu Tudor Signed-off-by: Ioana Ciornei Link: https://lore.kernel.org/r/20250408105814.2837951-7-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy Signed-off-by: Sasha Levin commit 13aea1b846f2d95d28a415ba8939cb8e5117da79 Author: Jarkko Nikula Date: Wed Apr 9 17:03:58 2025 +0300 i3c: mipi-i3c-hci: Fix handling status of i3c_hci_irq_handler() [ Upstream commit 279c24021b838e76ca8441e9446e0ab45271153a ] Return IRQ_HANDLED from the i3c_hci_irq_handler() only if some INTR_STATUS bit was set or if DMA/PIO handler handled it. Currently it returns IRQ_HANDLED in case INTR_STATUS is zero and IO handler returns false. Which could be the case if interrupt comes from other device or is spurious. Reviewed-by: Frank Li Signed-off-by: Jarkko Nikula Link: https://lore.kernel.org/r/20250409140401.299251-2-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 041d3566b6fcc6e04371203f9313dfc6d243f7ea Author: Krzysztof Kozlowski Date: Sun Apr 6 22:35:30 2025 +0200 watchdog: stm32: Fix wakeup source leaks on device unbind [ Upstream commit b6f8a417e17f1929bb8e7e6ba9f4677f1f3ce364 ] Device can be unbound or probe can fail, so driver must also release memory for the wakeup source. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20250406203531.61322-1-krzysztof.kozlowski@linaro.org Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 23bbdca5a8e60c295607699811ee11717d6d6cfc Author: Marcus Folkesson Date: Wed Mar 26 09:29:51 2025 +0100 watchdog: da9052_wdt: respect TWDMIN [ Upstream commit 325f510fcd9cda5a44bcb662b74ba4e3dabaca10 ] We have to wait at least the minimium time for the watchdog window (TWDMIN) before writings to the wdt register after the watchdog is activated. Otherwise the chip will assert TWD_ERROR and power down to reset mode. Signed-off-by: Marcus Folkesson Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20250326-da9052-fixes-v3-4-a38a560fef0e@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 91a0421861592ea31de70a00aff11a2d9fbdaf35 Author: Kees Cook Date: Mon Apr 21 13:41:57 2025 -0700 wifi: iwlwifi: mld: Work around Clang loop unrolling bug [ Upstream commit 368556dd234dc4a506a35a0c99c0eee2ab475c77 ] The nested loop in iwl_mld_send_proto_offload() confuses Clang into thinking there could be a final loop iteration past the end of the "nsc" array (which is only 4 entries). The FORTIFY checking in memcmp() (via ipv6_addr_cmp()) notices this (due to the available bytes in the out-of-bounds position of &nsc[4] being 0), and errors out, failing the build. For some reason (likely due to architectural loop unrolling configurations), this is only exposed on ARM builds currently. Due to Clang's lack of inline tracking[1], the warning is not very helpful: include/linux/fortify-string.h:719:4: error: call to '__read_overflow' declared with 'error' attribute: detected read beyond size of object (1st parameter) 719 | __read_overflow(); | ^ 1 error generated. But this was tracked down to iwl_mld_send_proto_offload()'s ipv6_addr_cmp() call. An upstream Clang bug has been filed[2] to track this. For now fix the build by explicitly bounding the inner loop by "n_nsc", which is what "c" is already limited to. Reported-by: Nathan Chancellor Closes: https://github.com/ClangBuiltLinux/linux/issues/2076 Link: https://github.com/llvm/llvm-project/pull/73552 [1] Link: https://github.com/llvm/llvm-project/issues/136603 [2] Link: https://lore.kernel.org/r/20250421204153.work.935-kees@kernel.org Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 54b28f7c567dd659e5f9562f518e4d7f3f6a367b Author: Kees Cook Date: Fri May 9 13:06:47 2025 -0700 fbcon: Make sure modelist not set on unregistered console [ Upstream commit cedc1b63394a866bf8663a3e40f4546f1d28c8d8 ] It looks like attempting to write to the "store_modes" sysfs node will run afoul of unregistered consoles: UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28 index -1 is out of range for type 'fb_info *[32]' ... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439 static struct fb_info *fbcon_registered_fb[FB_MAX]; ... static signed char con2fb_map[MAX_NR_CONSOLES]; ... static struct fb_info *fbcon_info_from_console(int console) ... return fbcon_registered_fb[con2fb_map[console]]; If con2fb_map contains a -1 things go wrong here. Instead, return NULL, as callers of fbcon_info_from_console() are trying to compare against existing "info" pointers, so error handling should kick in correctly. Reported-by: syzbot+a7d4444e7b6e743572f7@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/679d0a8f.050a0220.163cdc.000c.GAE@google.com/ Signed-off-by: Kees Cook Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit dcb5f5612aece6bfa91ffd6ba46003eb48eaef57 Author: Vlad Dogaru Date: Tue Apr 22 12:25:39 2025 +0300 net/mlx5: HWS, Harden IP version definer checks [ Upstream commit 6991a975e416154576b0f5f06256aec13e23b0a7 ] Replicate some sanity checks that firmware does, since hardware steering does not go through firmware. When creating a definer, disallow matching on IP addresses without also matching on IP version. The latter can be satisfied by matching either on the version field in the IP header, or on the ethertype field. Also refuse to match IPv4 IHL alongside IPv6. Signed-off-by: Vlad Dogaru Reviewed-by: Yevgeny Kliteynik Signed-off-by: Mark Bloch Link: https://patch.msgid.link/20250422092540.182091-3-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 29ed5d006b328c2c2dc14759a373bccc659bc951 Author: Suraj P Kizhakkethil Date: Tue Mar 4 15:23:14 2025 +0530 wifi: ath12k: Pass correct values of center freq1 and center freq2 for 160 MHz [ Upstream commit b1b01e46a3db5ad44d1e4691ba37c1e0832cd5cf ] Currently, for 160 MHz bandwidth, center frequency1 and center frequency2 are not passed correctly to the firmware. Set center frequency1 as the center frequency of the primary 80 MHz channel segment and center frequency2 as the center frequency of the 160 MHz channel and pass the values to the firmware. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Suraj P Kizhakkethil Reviewed-by: Aditya Kumar Singh Link: https://patch.msgid.link/20250304095315.3050325-2-quic_surapk@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 37c04b995d3d0afde104ed14e09e63b5a5059b10 Author: Balamurugan S Date: Fri Mar 21 16:22:39 2025 +0530 wifi: ath12k: fix incorrect CE addresses [ Upstream commit 60031d9c3589c7983fd1deb4a4c0bebf0929890e ] In the current ath12k implementation, the CE addresses CE_HOST_IE_ADDRESS and CE_HOST_IE_2_ADDRESS are incorrect. These values were inherited from ath11k, but ath12k does not currently use them. However, the Ath12k AHB support relies on these addresses. Therefore, correct the CE addresses for ath12k. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.3.1-00130-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00210-QCAHKSWPL_SILICONZ-1 Signed-off-by: Balamurugan S Reviewed-by: Vasanthakumar Thiagarajan Signed-off-by: Raj Kumar Bhagat Link: https://patch.msgid.link/20250321-ath12k-ahb-v12-2-bb389ed76ae5@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit e451a7bf08052ac07cf646d66f237424868528a4 Author: Hari Chandrakanthan Date: Mon Mar 24 11:55:09 2025 +0530 wifi: ath12k: fix link valid field initialization in the monitor Rx [ Upstream commit 2826139f9295821fe2b049318a1cc057ec003131 ] Currently, the link_valid field is not initialized in the monitor Rx path. This can result in random values for the link_valid and link_id leads to undefined behaviour in mac80211. Therefore, initialize the link_valid field in the monitor Rx path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Hari Chandrakanthan Tested-by: Nicolas Escande Reviewed-by: Vasanthakumar Thiagarajan Signed-off-by: Karthikeyan Periyasamy Link: https://patch.msgid.link/20250324062518.2752822-2-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit d6f83743dcabb1312aa2efcb30463ad03edfc4fd Author: Baochen Qiang Date: Fri Mar 28 13:32:24 2025 +0800 wifi: ath11k: determine PM policy based on machine model [ Upstream commit ce8669a27016354dfa8bf3c954255cb9f3583bae ] To handle the Lenovo unexpected wakeup issue [1], previously we revert commit 166a490f59ac ("wifi: ath11k: support hibernation"). So currently WLAN target is put into WoWLAN mode during suspend. This is a temporary solution as it does not work on machines where WLAN power is cut off. The thought here is that we do WoWLAN suspend on Lenovo machines while do non-WoWLAN suspend (which is done in the reverted commit) on other machines. This requires us to identify Lenovo machines from others. For that purpose, read board vendor and product name from DMI interface, match it against all known affected machines. If there is a match, choose WoWLAN suspend mode, else choose non-WoWLAN mode. Save the mode in ab for later reference. [1] https://bugzilla.kernel.org/show_bug.cgi?id=219196 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-by: Muhammad Usama Anjum Tested-by: Takashi Iwai Signed-off-by: Baochen Qiang Link: https://patch.msgid.link/20250328-ath11k-bring-hibernation-back-v3-1-23405ae23431@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 232f962ae5fca98912a719e64b4964a5aec7c99b Author: Sidhanta Sahu Date: Wed Mar 26 14:35:38 2025 -0700 wifi: ath12k: Fix memory leak due to multiple rx_stats allocation [ Upstream commit c426497fa2055c8005196922e7d29c41d7e0948a ] rx_stats for each arsta is allocated when adding a station. arsta->rx_stats will be freed when a station is removed. Redundant allocations are occurring when the same station is added multiple times. This causes ath12k_mac_station_add() to be called multiple times, and rx_stats is allocated each time. As a result there is memory leaks. Prevent multiple allocations of rx_stats when ath12k_mac_station_add() is called repeatedly by checking if rx_stats is already allocated before allocating again. Allocate arsta->rx_stats if arsta->rx_stats is NULL respectively. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Sidhanta Sahu Signed-off-by: Muna Sinada Reviewed-by: Mahendran P Link: https://patch.msgid.link/20250326213538.2214194-1-muna.sinada@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 7f60eea320e384c5e7125d0346e32850efabda86 Author: Sriram R Date: Wed Apr 2 20:55:27 2025 +0530 wifi: ath12k: Fix the enabling of REO queue lookup table feature [ Upstream commit 0bbcd42b15fa730f393a01bc818802d9f0b04197 ] Instead of storing the REO queue address inside peer entries, REO hardware module prefers them to be stored in SRAM which could be directly accessed by REO using peer_ID/TID based lookup table mechanism. Fix the enabling of the REO queue lookup table(LUT) feature by configuring the LUT address information in the REO hardware register and setting the host service flags. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sriram R Signed-off-by: Nithyanantham Paramasivam Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250402152529.1649402-2-quic_nithp@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 851d492d2c3cdfa1afe8a595eb8b4a4fdcf966e5 Author: Pradeep Kumar Chitrapu Date: Thu Mar 20 16:54:26 2025 +0530 wifi: ath12k: Fix incorrect rates sent to firmware [ Upstream commit cb1790249361ba9396b06b1af2500147e6e42e5e ] Before firmware assert, if there is a station interface in the device which is not associated with an AP, the basic rates are set to zero. Following this, during firmware recovery, when basic rates are zero, ath12k driver is sending invalid rate codes, which are negative values, to firmware. This results in firmware assert. Fix this by checking if rate codes are valid, before sending them to the firmware. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Pradeep Kumar Chitrapu Signed-off-by: Roopni Devanathan Reviewed-by: Vasanthakumar Thiagarajan Reviewed-by: Ping-Ke Shih Link: https://patch.msgid.link/20250320112426.1956961-1-quic_rdevanat@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 250696ccd28af9b45fddf081841b765552e362e5 Author: Bitterblue Smith Date: Wed Apr 2 18:31:12 2025 +0300 wifi: rtw88: Set AMPDU factor to hardware for RTL8814A [ Upstream commit 0d2a88690e583168effb03c64fd217a323b2c444 ] Tell the chip the maximum AMPDU size supported by the AP. This greatly improves the TX speed of RTL8814AU in the 2.4 GHz band. Before: ~90 Mbps. After: ~300 Mbps. Signed-off-by: Bitterblue Smith Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/4edc2a63-81b3-431c-9a37-5a7d899a6cc2@gmail.com Signed-off-by: Sasha Levin commit d00c9d821471d575b78435e5e1aa95db99c33010 Author: Wentao Liang Date: Tue Apr 8 11:26:02 2025 +0800 octeontx2-pf: Add error log forcn10k_map_unmap_rq_policer() [ Upstream commit 9c056ec6dd1654b1420dafbbe2a69718850e6ff2 ] The cn10k_free_matchall_ipolicer() calls the cn10k_map_unmap_rq_policer() for each queue in a for loop without checking for any errors. Check the return value of the cn10k_map_unmap_rq_policer() function during each loop, and report a warning if the function fails. Signed-off-by: Wentao Liang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250408032602.2909-1-vulab@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ebe12e232f1d58ebb4b53b6d9149962b707bed91 Author: Linus Walleij Date: Tue Apr 8 11:26:58 2025 +0200 net: ethernet: cortina: Use TOE/TSO on all TCP [ Upstream commit 6a07e3af4973402fa199a80036c10060b922c92c ] It is desireable to push the hardware accelerator to also process non-segmented TCP frames: we pass the skb->len to the "TOE/TSO" offloader and it will handle them. Without this quirk the driver becomes unstable and lock up and and crash. I do not know exactly why, but it is probably due to the TOE (TCP offload engine) feature that is coupled with the segmentation feature - it is not possible to turn one part off and not the other, either both TOE and TSO are active, or neither of them. Not having the TOE part active seems detrimental, as if that hardware feature is not really supposed to be turned off. The datasheet says: "Based on packet parsing and TCP connection/NAT table lookup results, the NetEngine puts the packets belonging to the same TCP connection to the same queue for the software to process. The NetEngine puts incoming packets to the buffer or series of buffers for a jumbo packet. With this hardware acceleration, IP/TCP header parsing, checksum validation and connection lookup are offloaded from the software processing." After numerous tests with the hardware locking up after something between minutes and hours depending on load using iperf3 I have concluded this is necessary to stabilize the hardware. Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20250408-gemini-ethernet-tso-always-v1-1-e669f932359c@linaro.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9107d8de59cbfb849c218f07ff419e6ce4d4da1c Author: Jiayuan Chen Date: Mon Apr 7 22:21:20 2025 +0800 bpf, sockmap: Fix data lost during EAGAIN retries [ Upstream commit 7683167196bd727ad5f3c3fc6a9ca70f54520a81 ] We call skb_bpf_redirect_clear() to clean _sk_redir before handling skb in backlog, but when sk_psock_handle_skb() return EAGAIN due to sk_rcvbuf limit, the redirect info in _sk_redir is not recovered. Fix skb redir loss during EAGAIN retries by restoring _sk_redir information using skb_bpf_set_redir(). Before this patch: ''' ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress Setting up benchmark 'sockmap'... create socket fd c1:13 p1:14 c2:15 p2:16 Benchmark 'sockmap' started. Send Speed 1343.172 MB/s, BPF Speed 1343.238 MB/s, Rcv Speed 65.271 MB/s Send Speed 1352.022 MB/s, BPF Speed 1352.088 MB/s, Rcv Speed 0 MB/s Send Speed 1354.105 MB/s, BPF Speed 1354.105 MB/s, Rcv Speed 0 MB/s Send Speed 1355.018 MB/s, BPF Speed 1354.887 MB/s, Rcv Speed 0 MB/s ''' Due to the high send rate, the RX processing path may frequently hit the sk_rcvbuf limit. Once triggered, incorrect _sk_redir will cause the flow to mistakenly enter the "!ingress" path, leading to send failures. (The Rcv speed depends on tcp_rmem). After this patch: ''' ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress Setting up benchmark 'sockmap'... create socket fd c1:13 p1:14 c2:15 p2:16 Benchmark 'sockmap' started. Send Speed 1347.236 MB/s, BPF Speed 1347.367 MB/s, Rcv Speed 65.402 MB/s Send Speed 1353.320 MB/s, BPF Speed 1353.320 MB/s, Rcv Speed 65.536 MB/s Send Speed 1353.186 MB/s, BPF Speed 1353.121 MB/s, Rcv Speed 65.536 MB/s ''' Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20250407142234.47591-2-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 92611dd1362f32ae5b5c3bb4551ffdd74b441082 Author: Chao Yu Date: Thu Mar 27 13:56:06 2025 +0800 f2fs: fix to set atomic write status more clear [ Upstream commit db03c20c0850dc8d2bcabfa54b9438f7d666c863 ] 1. After we start atomic write in a database file, before committing all data, we'd better not set inode w/ vfs dirty status to avoid redundant updates, instead, we only set inode w/ atomic dirty status. 2. After we commit all data, before committing metadata, we need to clear atomic dirty status, and set vfs dirty status to allow vfs flush dirty inode. Cc: Daeho Jeong Reported-by: Zhiguo Niu Signed-off-by: Chao Yu Reviewed-by: Daeho Jeong Reviewed-by: Zhiguo Niu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 584f81e234f80af99b12323fc2d05895b1734dac Author: Krzysztof Hałasa Date: Tue Apr 8 13:59:41 2025 +0200 usbnet: asix AX88772: leave the carrier control to phylink [ Upstream commit 4145f00227ee80f21ab274e9cd9c09758e9bcf3d ] ASIX AX88772B based USB 10/100 Ethernet adapter doesn't come up ("carrier off"), despite the built-in 100BASE-FX PHY positive link indication. The internal PHY is configured (using EEPROM) in fixed 100 Mbps full duplex mode. The primary problem appears to be using carrier_netif_{on,off}() while, at the same time, delegating carrier management to phylink. Use only the latter and remove "manual control" in the asix driver. I don't have any other AX88772 board here, but the problem doesn't seem specific to a particular board or settings - it's probably timing-dependent. Remove unused asix_adjust_link() as well. Signed-off-by: Krzysztof Hałasa Tested-by: Oleksij Rempel Link: https://patch.msgid.link/m3plhmdfte.fsf_-_@t19.piap.pl Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 67cee259763de3b962cddefec695500e9294a88e Author: Mateusz Pacuszka Date: Fri Feb 14 09:50:35 2025 +0100 ice: fix check for existing switch rule [ Upstream commit a808691df39b52cd9db861b118e88e18b63e2299 ] In case the rule already exists and another VSI wants to subscribe to it new VSI list is being created and both VSIs are moved to it. Currently, the check for already existing VSI with the same rule is done based on fdw_id.hw_vsi_id, which applies only to LOOKUP_RX flag. Change it to vsi_handle. This is software VSI ID, but it can be applied here, because vsi_map itself is also based on it. Additionally change return status in case the VSI already exists in the VSI map to "Already exists". Such case should be handled by the caller. Signed-off-by: Mateusz Pacuszka Reviewed-by: Przemek Kitszel Reviewed-by: Michal Swiatkowski Signed-off-by: Larysa Zaremba Reviewed-by: Simon Horman Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 1c7f1b0ca7f71738381e4a90a1fbbeb9abef8200 Author: Chen Linxuan Date: Fri Apr 11 18:54:53 2025 +0800 RDMA/hns: initialize db in update_srq_db() [ Upstream commit ffe1cee21f8b533ae27c3a31bfa56b8c1b27fa6e ] On x86_64 with gcc version 13.3.0, I compile drivers/infiniband/hw/hns/hns_roce_hw_v2.c with: make defconfig ./scripts/kconfig/merge_config.sh .config <( echo CONFIG_COMPILE_TEST=y echo CONFIG_HNS3=m echo CONFIG_INFINIBAND=m echo CONFIG_INFINIBAND_HNS_HIP08=m ) make KCFLAGS="-fno-inline-small-functions -fno-inline-functions-called-once" \ drivers/infiniband/hw/hns/hns_roce_hw_v2.o Then I get a compile error: CALL scripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers CC [M] drivers/infiniband/hw/hns/hns_roce_hw_v2.o In file included from drivers/infiniband/hw/hns/hns_roce_hw_v2.c:47: drivers/infiniband/hw/hns/hns_roce_hw_v2.c: In function 'update_srq_db': drivers/infiniband/hw/hns/hns_roce_common.h:74:17: error: 'db' is used uninitialized [-Werror=uninitialized] 74 | *((__le32 *)_ptr + (field_h) / 32) &= \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/infiniband/hw/hns/hns_roce_common.h:90:17: note: in expansion of macro '_hr_reg_clear' 90 | _hr_reg_clear(ptr, field_type, field_h, field_l); \ | ^~~~~~~~~~~~~ drivers/infiniband/hw/hns/hns_roce_common.h:95:39: note: in expansion of macro '_hr_reg_write' 95 | #define hr_reg_write(ptr, field, val) _hr_reg_write(ptr, field, val) | ^~~~~~~~~~~~~ drivers/infiniband/hw/hns/hns_roce_hw_v2.c:948:9: note: in expansion of macro 'hr_reg_write' 948 | hr_reg_write(&db, DB_TAG, srq->srqn); | ^~~~~~~~~~~~ drivers/infiniband/hw/hns/hns_roce_hw_v2.c:946:31: note: 'db' declared here 946 | struct hns_roce_v2_db db; | ^~ cc1: all warnings being treated as errors Signed-off-by: Chen Linxuan Co-developed-by: Winston Wen Signed-off-by: Winston Wen Link: https://patch.msgid.link/FF922C77946229B6+20250411105459.90782-5-chenlinxuan@uniontech.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 7a01df3f9ec1887a77a8c82f71b908387a10ab17 Author: Rand Deeb Date: Thu Mar 6 13:12:00 2025 +0300 ixgbe: Fix unreachable retry logic in combined and byte I2C write functions [ Upstream commit cdcb3804eeda24d588348bbab6766cf14fddbeaa ] The current implementation of `ixgbe_write_i2c_combined_generic_int` and `ixgbe_write_i2c_byte_generic_int` sets `max_retry` to `1`, which makes the condition `retry < max_retry` always evaluate to `false`. This renders the retry mechanism ineffective, as the debug message and retry logic are never executed. This patch increases `max_retry` to `3` in both functions, aligning them with the retry logic in `ixgbe_read_i2c_combined_generic_int`. This ensures that the retry mechanism functions as intended, improving robustness in case of I2C write failures. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Rand Deeb Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 2a1f4f2e36442a9bdf771acf6ee86f3cf876e5ca Author: Kyungwook Boo Date: Tue Mar 11 14:16:02 2025 +0900 i40e: fix MMIO write access to an invalid page in i40e_clear_hw [ Upstream commit 015bac5daca978448f2671478c553ce1f300c21e ] When the device sends a specific input, an integer underflow can occur, leading to MMIO write access to an invalid page. Prevent the integer underflow by changing the type of related variables. Signed-off-by: Kyungwook Boo Link: https://lore.kernel.org/lkml/ffc91764-1142-4ba2-91b6-8c773f6f7095@gmail.com/T/ Reviewed-by: Przemek Kitszel Reviewed-by: Simon Horman Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 89731d75a21370ca2eeda6b0490174807c2af072 Author: Zijun Hu Date: Thu Apr 10 09:01:27 2025 +0800 sock: Correct error checking condition for (assign|release)_proto_idx() [ Upstream commit faeefc173be40512341b102cf1568aa0b6571acd ] (assign|release)_proto_idx() wrongly check find_first_zero_bit() failure by condition '(prot->inuse_idx == PROTO_INUSE_NR - 1)' obviously. Fix by correcting the condition to '(prot->inuse_idx == PROTO_INUSE_NR)' Signed-off-by: Zijun Hu Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250410-fix_net-v2-1-d69e7c5739a4@quicinc.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 003baa7a1a152576d744bd655820449bbdb0248e Author: Daniel Wagner Date: Wed Apr 9 13:34:22 2025 +0200 scsi: lpfc: Use memcpy() for BIOS version [ Upstream commit ae82eaf4aeea060bb736c3e20c0568b67c701d7d ] The strlcat() with FORTIFY support is triggering a panic because it thinks the target buffer will overflow although the correct target buffer size is passed in. Anyway, instead of memset() with 0 followed by a strlcat(), just use memcpy() and ensure that the resulting buffer is NULL terminated. BIOSVersion is only used for the lpfc_printf_log() which expects a properly terminated string. Signed-off-by: Daniel Wagner Link: https://lore.kernel.org/r/20250409-fix-lpfc-bios-str-v1-1-05dac9e51e13@kernel.org Reviewed-by: Justin Tee Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 272c9d887f24a6e04669b4e31c4c71ba8236bf68 Author: Aditya Kumar Singh Date: Tue Apr 8 11:36:31 2025 +0530 wifi: ath12k: fix failed to set mhi state error during reboot with hardware grouping [ Upstream commit dce7aec6b1f74b0a46b901ab8de1f7bd0515f733 ] With hardware grouping, during reboot, whenever a device is removed, it powers down itself and all its partner devices in the same group. Now this is done by all devices and hence there is multiple power down for devices and hence the following error messages can be seen: ath12k_pci 0002:01:00.0: failed to set mhi state POWER_OFF(3) in current mhi state (0x0) ath12k_pci 0002:01:00.0: failed to set mhi state: POWER_OFF(3) ath12k_pci 0002:01:00.0: failed to set mhi state DEINIT(1) in current mhi state (0x0) ath12k_pci 0002:01:00.0: failed to set mhi state: DEINIT(1) ath12k_pci 0003:01:00.0: failed to set mhi state POWER_OFF(3) in current mhi state (0x0) ath12k_pci 0003:01:00.0: failed to set mhi state: POWER_OFF(3) ath12k_pci 0003:01:00.0: failed to set mhi state DEINIT(1) in current mhi state (0x0) ath12k_pci 0003:01:00.0: failed to set mhi state: DEINIT(1) ath12k_pci 0004:01:00.0: failed to set mhi state POWER_OFF(3) in current mhi state (0x0) ath12k_pci 0004:01:00.0: failed to set mhi state: POWER_OFF(3) To prevent this, check if the ATH12K_PCI_FLAG_INIT_DONE flag is already set before powering down. If it is set, it indicates that another partner device has already performed the power down, and this device can skip this step. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Aditya Kumar Singh Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-3-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5449fe50035a24aae938caa31423f9016cce1f33 Author: Mike Looijmans Date: Fri Mar 14 16:17:45 2025 +0100 pinctrl: mcp23s08: Reset all pins to input at probe [ Upstream commit 3ede3f8b4b4b399b0ca41e44959f80d5cf84fc98 ] At startup, the driver just assumes that all registers have their default values. But after a soft reset, the chip will just be in the state it was, and some pins may have been configured as outputs. Any modification of the output register will cause these pins to be driven low, which leads to unexpected/unwanted effects. To prevent this from happening, set the chip's IO configuration register to a known safe mode (all inputs) before toggling any other bits. Signed-off-by: Mike Looijmans Link: https://lore.kernel.org/20250314151803.28903-1-mike.looijmans@topic.nl Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 8a1fbbe96cbca2284ee7bf4d8e42c6dcca3012ec Author: Jonas 'Sortie' Termansen Date: Fri Apr 11 16:50:21 2025 +0200 isofs: fix Y2038 and Y2156 issues in Rock Ridge TF entry [ Upstream commit 5ea45f54c8d6ca2a95b7bd450ee9eb253310bfd3 ] This change implements the Rock Ridge TF entry LONG_FORM bit, which uses the ISO 9660 17-byte date format (up to year 9999, with 10ms precision) instead of the 7-byte date format (up to year 2155, with 1s precision). Previously the LONG_FORM bit was ignored; and isofs would entirely misinterpret the date as the wrong format, resulting in garbage timestamps on the filesystem. The Y2038 issue in iso_date() is fixed by returning a struct timespec64 instead of an int. parse_rock_ridge_inode_internal() is fixed so it does proper bounds checks of the TF entry timestamps. Signed-off-by: Jonas 'Sortie' Termansen Signed-off-by: Jan Kara Link: https://patch.msgid.link/20250411145022.2292255-1-sortie@maxsi.org Signed-off-by: Sasha Levin commit 356feee23b5b37049c82024fd8dda5e9ba575b31 Author: Baochen Qiang Date: Wed Apr 9 10:26:38 2025 +0800 wifi: ath12k: make assoc link associate first [ Upstream commit ead6d41116b81098061c878d9bfc0b1a6c629090 ] In MLO scenario WCN7850 firmware requests the assoc link to associate before any other links. However currently in ath12k_mac_op_vif_cfg_changed() we are doing association in an ascending order of link id. If the assoc link does not get assigned the smallest id, a non-assoc link gets associated first and firmware crashes. Change to do association for the assoc link first. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-5-3801132ca2c3@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 7af18e42bdefe1dba5bcb32555a4d524fd504939 Author: Zijun Hu Date: Mon Apr 14 19:36:52 2025 +0800 software node: Correct a OOB check in software_node_get_reference_args() [ Upstream commit 31e4e12e0e9609850cefd4b2e1adf782f56337d6 ] software_node_get_reference_args() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property. Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'. Reviewed-by: Sakari Ailus Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20250414-fix_swnode-v2-1-9c9e6ae11eab@quicinc.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5bb1f3b1d636773481b6ff11f16def56d7374efe Author: Michael Walle Date: Mon Apr 14 10:43:36 2025 +0200 net: ethernet: ti: am65-cpsw: handle -EPROBE_DEFER [ Upstream commit 09737cb80b8686ffca4ed1805fee745d5c85604d ] of_get_mac_address() might fetch the MAC address from NVMEM and that driver might not have been loaded. In that case, -EPROBE_DEFER is returned. Right now, this will trigger an immediate fallback to am65_cpsw_am654_get_efuse_macid() possibly resulting in a random MAC address although the MAC address is stored in the referenced NVMEM. Fix it by handling the -EPROBE_DEFER return code correctly. This also means that the creation of the MDIO device has to be moved to a later stage as -EPROBE_DEFER must not be returned after child devices are created. Signed-off-by: Michael Walle Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250414084336.4017237-3-mwalle@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a28082d372c488c5c393d8a0026853db650c3000 Author: Sarika Sharma Date: Fri Apr 11 11:45:22 2025 +0530 wifi: ath12k: using msdu end descriptor to check for rx multicast packets [ Upstream commit cb7433cc5cd4d07175dbc41f5a19966e9fae48be ] Currently, the RX multicast broadcast packet check is performed using bit 15 from the info6 field of the MPDU start descriptor. This check can also be done using bit 9 from the info5 field of the MSDU end descriptor. However, in some scenarios multicast bit is not set when fetched from MPDU start descriptor. Therefore, checking the RX multicast broadcast packet from the MSDU end descriptor is more reliable as it is per MSDU. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sarika Sharma Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250411061523.859387-2-quic_sarishar@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 4b2b61da0ffc8cf623c03ca500139eaba224411f Author: Sarika Sharma Date: Fri Apr 11 11:45:23 2025 +0530 wifi: ath12k: correctly handle mcast packets for clients [ Upstream commit 4541b0c8c3c1b85564971d497224e57cf8076a02 ] Currently, RX is_mcbc bit is set for packets sent from client as destination address (DA) is multicast/broadcast address, but packets are actually unicast as receiver address (RA) is not multicast address. Hence, packets are not handled properly due to this is_mcbc bit. Therefore, reset the is_mcbc bit if interface type is AP. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sarika Sharma Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250411061523.859387-3-quic_sarishar@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 20d382d0f6683da51098c8ff1960209e7c7762d0 Author: Ido Schimmel Date: Tue Apr 15 15:11:29 2025 +0300 vxlan: Add RCU read-side critical sections in the Tx path [ Upstream commit 804b09be09f8af4eda5346a72361459ba21fcf1b ] The Tx path does not run from an RCU read-side critical section which makes the current lockless accesses to FDB entries invalid. As far as I am aware, this has not been a problem in practice, but traces will be generated once we transition the FDB lookup to rhashtable_lookup(). Add rcu_read_{lock,unlock}() around the handling of FDB entries in the Tx path. Remove the RCU read-side critical section from vxlan_xmit_nh() as now the function is always called from an RCU read-side critical section. Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20250415121143.345227-2-idosch@nvidia.com Reviewed-by: Nikolay Aleksandrov Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 90e97538e6ab6359f8ea8f4ffe741dda4f536d42 Author: Kalesh AP Date: Thu Apr 17 10:24:47 2025 -0700 bnxt_en: Remove unused field "ref_count" in struct bnxt_ulp [ Upstream commit 5bccacb4cc32cb835fe2fe100a210332c494e81d ] The "ref_count" field in struct bnxt_ulp is unused after commit a43c26fa2e6c ("RDMA/bnxt_re: Remove the sriov config callback"). So we can just remove it now. Reviewed-by: Somnath Kotur Signed-off-by: Kalesh AP Signed-off-by: Michael Chan Link: https://patch.msgid.link/20250417172448.1206107-4-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2574a501982ef2239d61dc3d811a1836905ae16d Author: Ido Schimmel Date: Tue Apr 15 15:11:41 2025 +0300 vxlan: Do not treat dst cache initialization errors as fatal [ Upstream commit 20c76dadc783759fd3819d289c72be590660cc8b ] FDB entries are allocated in an atomic context as they can be added from the data path when learning is enabled. After converting the FDB hash table to rhashtable, the insertion rate will be much higher (*) which will entail a much higher rate of per-CPU allocations via dst_cache_init(). When adding a large number of entries (e.g., 256k) in a batch, a small percentage (< 0.02%) of these per-CPU allocations will fail [1]. This does not happen with the current code since the insertion rate is low enough to give the per-CPU allocator a chance to asynchronously create new chunks of per-CPU memory. Given that: a. Only a small percentage of these per-CPU allocations fail. b. The scenario where this happens might not be the most realistic one. c. The driver can work correctly without dst caches. The dst_cache_*() APIs first check that the dst cache was properly initialized. d. The dst caches are not always used (e.g., 'tos inherit'). It seems reasonable to not treat these allocation failures as fatal. Therefore, do not bail when dst_cache_init() fails and suppress warnings by specifying '__GFP_NOWARN'. [1] percpu: allocation failed, size=40 align=8 atomic=1, atomic alloc failed, no space left (*) 97% reduction in average latency of vxlan_fdb_update() when adding 256k entries in a batch. Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20250415121143.345227-14-idosch@nvidia.com Reviewed-by: Nikolay Aleksandrov Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c996e25df0b3282c724bb5aca434518bc08cd963 Author: Yong Wang Date: Thu Apr 17 15:43:12 2025 +0200 net: bridge: mcast: re-implement br_multicast_{enable, disable}_port functions [ Upstream commit 4b30ae9adb047dd0a7982975ec3933c529537026 ] When a bridge port STP state is changed from BLOCKING/DISABLED to FORWARDING, the port's igmp query timer will NOT re-arm itself if the bridge has been configured as per-VLAN multicast snooping. Solve this by choosing the correct multicast context(s) to enable/disable port multicast based on whether per-VLAN multicast snooping is enabled or not, i.e. using per-{port, VLAN} context in case of per-VLAN multicast snooping by re-implementing br_multicast_enable_port() and br_multicast_disable_port() functions. Before the patch, the IGMP query does not happen in the last step of the following test sequence, i.e. no growth for tx counter: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 mcast_querier 1 mcast_stats_enabled 1 # bridge vlan global set vid 1 dev br1 mcast_snooping 1 mcast_querier 1 mcast_query_interval 100 mcast_startup_query_count 0 # ip link add name swp1 up master br1 type dummy # bridge link set dev swp1 state 0 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # sleep 1 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # bridge link set dev swp1 state 3 # sleep 2 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 After the patch, the IGMP query happens in the last step of the test: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 mcast_querier 1 mcast_stats_enabled 1 # bridge vlan global set vid 1 dev br1 mcast_snooping 1 mcast_querier 1 mcast_query_interval 100 mcast_startup_query_count 0 # ip link add name swp1 up master br1 type dummy # bridge link set dev swp1 state 0 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # sleep 1 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # bridge link set dev swp1 state 3 # sleep 2 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 3 Signed-off-by: Yong Wang Reviewed-by: Andy Roulin Reviewed-by: Ido Schimmel Signed-off-by: Petr Machata Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7d5b9db370c411ccb60a13920cee930898091682 Author: Yong Wang Date: Thu Apr 17 15:43:13 2025 +0200 net: bridge: mcast: update multicast contex when vlan state is changed [ Upstream commit 6c131043eaf1be2a6cc2d228f92ceb626fbcc0f3 ] When the vlan STP state is changed, which could be manipulated by "bridge vlan" commands, similar to port STP state, this also impacts multicast behaviors such as igmp query. In the scenario of per-VLAN snooping, there's a need to update the corresponding multicast context to re-arm the port query timer when vlan state becomes "forwarding" etc. Update br_vlan_set_state() function to enable vlan multicast context in such scenario. Before the patch, the IGMP query does not happen in the last step of the following test sequence, i.e. no growth for tx counter: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 mcast_querier 1 mcast_stats_enabled 1 # bridge vlan global set vid 1 dev br1 mcast_snooping 1 mcast_querier 1 mcast_query_interval 100 mcast_startup_query_count 0 # ip link add name swp1 up master br1 type dummy # sleep 1 # bridge vlan set vid 1 dev swp1 state 4 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # sleep 1 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # bridge vlan set vid 1 dev swp1 state 3 # sleep 2 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 After the patch, the IGMP query happens in the last step of the test: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 mcast_querier 1 mcast_stats_enabled 1 # bridge vlan global set vid 1 dev br1 mcast_snooping 1 mcast_querier 1 mcast_query_interval 100 mcast_startup_query_count 0 # ip link add name swp1 up master br1 type dummy # sleep 1 # bridge vlan set vid 1 dev swp1 state 4 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # sleep 1 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # bridge vlan set vid 1 dev swp1 state 3 # sleep 2 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 3 Signed-off-by: Yong Wang Reviewed-by: Andy Roulin Reviewed-by: Ido Schimmel Signed-off-by: Petr Machata Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 210dfda8003499b88162a7386861b1cdce8ffb9b Author: Víctor Gonzalo Date: Wed Mar 13 20:02:27 2024 +0200 wifi: iwlwifi: Add missing MODULE_FIRMWARE for Qu-c0-jf-b0 [ Upstream commit 2b801487ac3be7bec561ae62d1a6c4d6f5283f8c ] The module metadata for the firmware file iwlwifi-Qu-c0-jf-b0-* is missing. Signed-off-by: Víctor Gonzalo Link: https://patch.msgid.link/20240313180227.2224780-1-victor.gonzalo@anddroptable.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 91e93d66ac850868a6f95d86cce056c862b5704a Author: Toke Høiland-Jørgensen Date: Thu Apr 3 20:39:28 2025 +0200 Revert "mac80211: Dynamically set CoDel parameters per station" [ Upstream commit 4876376988081d636a4c4e5f03a5556386b49087 ] This reverts commit 484a54c2e597dbc4ace79c1687022282905afba0. The CoDel parameter change essentially disables CoDel on slow stations, with some questionable assumptions, as Dave pointed out in [0]. Quoting from there: But here are my pithy comments as to why this part of mac80211 is so wrong... static void sta_update_codel_params(struct sta_info *sta, u32 thr) { - if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) { 1) sta->local->num_sta is the number of associated, rather than active, stations. "Active" stations in the last 50ms or so, might have been a better thing to use, but as most people have far more than that associated, we end up with really lousy codel parameters, all the time. Mistake numero uno! 2) The STA_SLOW_THRESHOLD was completely arbitrary in 2016. - sta->cparams.target = MS2TIME(50); This, by itself, was probably not too bad. 30ms might have been better, at the time, when we were battling powersave etc, but 20ms was enough, really, to cover most scenarios, even where we had low rate 2Ghz multicast to cope with. Even then, codel has a hard time finding any sane drop rate at all, with a target this high. - sta->cparams.interval = MS2TIME(300); But this was horrible, a total mistake, that is leading to codel being completely ineffective in almost any scenario on clients or APS. 100ms, even 80ms, here, would be vastly better than this insanity. I'm seeing 5+seconds of delay accumulated in a bunch of otherwise happily fq-ing APs.... 100ms of observed jitter during a flow is enough. Certainly (in 2016) there were interactions with powersave that I did not understand, and still don't, but if you are transmitting in the first place, powersave shouldn't be a problemmmm..... - sta->cparams.ecn = false; At the time we were pretty nervous about ecn, I'm kind of sanguine about it now, and reliably indicating ecn seems better than turning it off for any reason. [...] In production, on p2p wireless, I've had 8ms and 80ms for target and interval for years now, and it works great. I think Dave's arguments above are basically sound on the face of it, and various experimentation with tighter CoDel parameters in the OpenWrt community have show promising results[1]. So I don't think there's any reason to keep this parameter fiddling; hence this revert. [0] https://lore.kernel.org/linux-wireless/CAA93jw6NJ2cmLmMauz0xAgC2MGbBq6n0ZiZzAdkK0u4b+O2yXg@mail.gmail.com/ [1] https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further-in-wifi/133605/130 Suggested-By: Dave Taht In-memory-of: Dave Taht Signed-off-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20250403183930.197716-1-toke@toke.dk Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 5d25f687d03a1dbce4a47d819d3aa0101bb22140 Author: Muna Sinada Date: Tue Mar 25 14:31:25 2025 -0700 wifi: mac80211: VLAN traffic in multicast path [ Upstream commit 1a4a6a22552ca9d723f28a1fe35eab1b9b3d8b33 ] Currently for MLO, sending out multicast frames on each link is handled by mac80211 only when IEEE80211_HW_MLO_MCAST_MULTI_LINK_TX flag is not set. Dynamic VLAN multicast traffic utilizes software encryption. Due to this, mac80211 should handle transmitting multicast frames on all links for multicast VLAN traffic. Signed-off-by: Muna Sinada Link: https://patch.msgid.link/20250325213125.1509362-4-muna.sinada@oss.qualcomm.com [remove unnecessary parentheses] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 76fdcafbcc565e3681a4108d462137d998d9c057 Author: Shung-Hsi Yu Date: Fri Apr 18 15:49:43 2025 +0800 bpf: Use proper type to calculate bpf_raw_tp_null_args.mask index [ Upstream commit 53ebef53a657d7957d35dc2b953db64f1bb28065 ] The calculation of the index used to access the mask field in 'struct bpf_raw_tp_null_args' is done with 'int' type, which could overflow when the tracepoint being attached has more than 8 arguments. While none of the tracepoints mentioned in raw_tp_null_args[] currently have more than 8 arguments, there do exist tracepoints that had more than 8 arguments (e.g. iocost_iocg_forgive_debt), so use the correct type for calculation and avoid Smatch static checker warning. Reported-by: Dan Carpenter Signed-off-by: Shung-Hsi Yu Signed-off-by: Andrii Nakryiko Acked-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/bpf/20250418074946.35569-1-shung-hsi.yu@suse.com Closes: https://lore.kernel.org/r/843a3b94-d53d-42db-93d4-be10a4090146@stanley.mountain/ Signed-off-by: Sasha Levin commit 1fe55ddbb351c0370e018fbb86677e11e27e3067 Author: Vlad Dogaru Date: Tue Apr 22 12:25:38 2025 +0300 net/mlx5: HWS, Fix IP version decision [ Upstream commit 5f2f8d8b6800e4fc760c2eccec9b2bd2cacf80cf ] Unify the check for IP version when creating a definer. A given matcher is deemed to match on IPv6 if any of the higher order (>31) bits of source or destination address mask are set. A single packet cannot mix IP versions between source and destination addresses, so it makes no sense that they would be decided on independently. Signed-off-by: Vlad Dogaru Reviewed-by: Yevgeny Kliteynik Signed-off-by: Mark Bloch Link: https://patch.msgid.link/20250422092540.182091-2-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3ff13ab3d1ff8e0a49ddadd957a734b7cb288e60 Author: Joe Damato Date: Thu Apr 24 00:27:31 2025 +0000 netdevsim: Mark NAPI ID on skb in nsim_rcv [ Upstream commit f71c549b26a33fd62f1e9c7deeba738bfc73fbfc ] Previously, nsim_rcv was not marking the NAPI ID on the skb, leading to applications seeing a napi ID of 0 when using SO_INCOMING_NAPI_ID. To add to the userland confusion, netlink appears to correctly report the NAPI IDs for netdevsim queues but the resulting file descriptor from a call to accept() was reporting a NAPI ID of 0. Signed-off-by: Joe Damato Link: https://patch.msgid.link/20250424002746.16891-2-jdamato@fastly.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8458721440ce715a88b1ee2d7221f0f4434d1fd1 Author: Edward Adam Davis Date: Wed Apr 23 22:15:53 2025 +0800 wifi: mac80211_hwsim: Prevent tsf from setting if beacon is disabled [ Upstream commit c575f5374be7a5c4be4acb9fe6be3a4669d94674 ] Setting tsf is meaningless if beacon is disabled, so check that beacon is enabled before setting tsf. Reported-by: syzbot+064815c6cd721082a52a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=064815c6cd721082a52a Tested-by: syzbot+064815c6cd721082a52a@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Link: https://patch.msgid.link/tencent_3609AC2EFAAED68CA5A7E3C6D212D1C67806@qq.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 73b979440d8a317b8798553945cb6082700cfcec Author: Kuan-Chung Chen Date: Wed Apr 16 16:12:39 2025 +0800 wifi: rtw89: 8922a: fix TX fail with wrong VCO setting [ Upstream commit 20aac091a15dc7229ef1a268253fe36bb6b2be39 ] An incorrect Voltage Controlled Oscillator (VCO) setting may cause Synthesizer (SYN) unlock, which may lead to a failure in the TX authentication request. Signed-off-by: Kuan-Chung Chen Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250416081241.36138-3-pkshih@realtek.com Signed-off-by: Sasha Levin commit 3447aa5bbbb643405458d53e51cf1a39a7cb3412 Author: Miri Korenblit Date: Thu Apr 24 15:38:30 2025 +0300 wifi: iwlwifi: pcie: make sure to lock rxq->read [ Upstream commit 1cc2c48c4af81bed5ddbe9f2c9d6e20fa163acf9 ] rxq->read is accessed without the rxq->lock in a few places, Make sure to have the lock there. Signed-off-by: Miri Korenblit Reviewed-by: Emmanuel Grumbach Tested-by: Emmanuel Grumbach Link: https://patch.msgid.link/20250424153620.73725f207aaa.I1a3e4b6c5fd370e029fdacfcdc9ee335788afa98@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 72d696bfacb2172b696d745d7fc010df32ec497b Author: Sean Christopherson Date: Fri Mar 14 20:10:48 2025 -0700 iommu/amd: Ensure GA log notifier callbacks finish running before module unload [ Upstream commit 94c721ea03c7078163f41dbaa101ac721ddac329 ] Synchronize RCU when unregistering KVM's GA log notifier to ensure all in-flight interrupt handlers complete before KVM-the module is unloaded. Signed-off-by: Sean Christopherson Link: https://lore.kernel.org/r/20250315031048.2374109-1-seanjc@google.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit f88b4b842d2b8f92f1e175adfaa73d9401ddc7dc Author: David Strahan Date: Wed Apr 23 13:32:26 2025 -0500 scsi: smartpqi: Add new PCI IDs [ Upstream commit 01b8bdddcfab035cf70fd9981cb20593564cd15d ] Add in support for more PCI devices. All PCI ID entries in Hex. Add PCI IDs for Ramaxel controllers: VID / DID / SVID / SDID ---- ---- ---- ---- Ramaxel SmartHBA RX8238-16i 9005 028f 1018 8238 Ramaxel SSSRAID card 9005 028f 1f3f 0610 Add PCI ID for Alibaba controller: VID / DID / SVID / SDID ---- ---- ---- ---- HBA AS1340 9005 028f 1ded 3301 Add PCI IDs for Inspur controller: VID / DID / SVID / SDID ---- ---- ---- ---- RT0800M6E2i 9005 028f 1bd4 00a3 Add PCI IDs for Delta controllers: VID / DID / SVID / SDID ---- ---- ---- ---- ThinkSystem 4450-8i SAS/SATA/NVMe PCIe Gen4 9005 028f 1d49 0222 24Gb HBA ThinkSystem 4450-16i SAS/SATA/NVMe PCIe Gen4 9005 028f 1d49 0223 24Gb HBA ThinkSystem 4450-8e SAS/SATA PCIe Gen4 9005 028f 1d49 0224 24Gb HBA ThinkSystem RAID 4450-16e PCIe Gen4 24Gb 9005 028f 1d49 0225 Adapter HBA ThinkSystem RAID 5450-16i PCIe Gen4 24Gb Adapter 9005 028f 1d49 0521 ThinkSystem RAID 9450-8i 4GB Flash PCIe Gen4 9005 028f 1d49 0624 24Gb Adapter ThinkSystem RAID 9450-16i 4GB Flash PCIe Gen4 9005 028f 1d49 0625 24Gb Adapter ThinkSystem RAID 9450-16i 4GB Flash PCIe Gen4 9005 028f 1d49 0626 24Gb Adapter ThinkSystem RAID 9450-32i 8GB Flash PCIe Gen4 9005 028f 1d49 0627 24Gb Adapter ThinkSystem RAID 9450-16e 4GB Flash PCIe Gen4 9005 028f 1d49 0628 24Gb Adapter Add PCI ID for Cloudnine Controller: VID / DID / SVID / SDID ---- ---- ---- ---- SmartHBA P6600-24i 9005 028f 1f51 100b Add PCI IDs for Hurraydata Controllers: VID / DID / SVID / SDID ---- ---- ---- ---- HRDT TrustHBA H4100-8i 9005 028f 207d 4044 HRDT TrustHBA H4100-8e 9005 028f 207d 4054 HRDT TrustHBA H4100-16i 9005 028f 207d 4084 HRDT TrustHBA H4100-16e 9005 028f 207d 4094 HRDT TrustRAID D3152s-8i 9005 028f 207d 4140 HRDT TrustRAID D3154s-8i 9005 028f 207d 4240 Reviewed-by: Scott Benesh Reviewed-by: Scott Teel Reviewed-by: Mike McGowen Signed-off-by: David Strahan Signed-off-by: Don Brace Link: https://lore.kernel.org/r/20250423183229.538572-3-don.brace@microchip.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 13d1166c54596405e08ea0b19952cffe3f10af2f Author: Justin Tee Date: Fri Apr 25 12:47:59 2025 -0700 scsi: lpfc: Fix lpfc_check_sli_ndlp() handling for GEN_REQUEST64 commands [ Upstream commit 05ae6c9c7315d844fbc15afe393f5ba5e5771126 ] In lpfc_check_sli_ndlp(), the get_job_els_rsp64_did remote_id assignment does not apply for GEN_REQUEST64 commands as it only has meaning for a ELS_REQUEST64 command. So, if (iocb->ndlp == ndlp) is false, we could erroneously return the wrong value. Fix by replacing the fallthrough statement with a break statement before the remote_id check. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20250425194806.3585-2-justintee8345@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7c5f364a4aeef7515f5c209eb65048cf05e7c38f Author: Alan Maguire Date: Tue Apr 29 17:10:42 2025 +0100 libbpf: Add identical pointer detection to btf_dedup_is_equiv() [ Upstream commit 8e64c387c942229c551d0f23de4d9993d3a2acb6 ] Recently as a side-effect of commit ac053946f5c4 ("compiler.h: introduce TYPEOF_UNQUAL() macro") issues were observed in deduplication between modules and kernel BTF such that a large number of kernel types were not deduplicated so were found in module BTF (task_struct, bpf_prog etc). The root cause appeared to be a failure to dedup struct types, specifically those with members that were pointers with __percpu annotations. The issue in dedup is at the point that we are deduplicating structures, we have not yet deduplicated reference types like pointers. If multiple copies of a pointer point at the same (deduplicated) integer as in this case, we do not see them as identical. Special handling already exists to deal with structures and arrays, so add pointer handling here too. Reported-by: Alexei Starovoitov Signed-off-by: Alan Maguire Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250429161042.2069678-1-alan.maguire@oracle.com Signed-off-by: Sasha Levin commit d2768016f091f8a5264076b433fd7c3fabb6eb97 Author: Pablo Neira Ayuso Date: Tue Apr 22 21:52:44 2025 +0200 netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX [ Upstream commit b85e3367a5716ed3662a4fe266525190d2af76df ] Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset. Similar to: b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX") Reviewed-by: Stefano Brivio Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 46b0e95e03972124ac2aa2aaef2216092b3db32a Author: Steven Rostedt Date: Tue May 6 10:23:00 2025 -0400 tracing: Only return an adjusted address if it matches the kernel address [ Upstream commit 00d872dd541cdf22230510201a1baf58f0147db9 ] The trace_adjust_address() will take a given address and examine the persistent ring buffer to see if the address matches a module that is listed there. If it does not, it will just adjust the value to the core kernel delta. But if the address was for something that was not part of the core kernel text or data it should not be adjusted. Check the result of the adjustment and only return the adjustment if it lands in the current kernel text or data. If not, return the original address. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://lore.kernel.org/20250506102300.0ba2f9e0@gandalf.local.home Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit ca860f507a61c7c3d4dde47b830a5c0d555cf83c Author: Chao Yu Date: Tue Apr 22 19:56:38 2025 +0800 f2fs: fix to bail out in get_new_segment() [ Upstream commit bb5eb8a5b222fa5092f60d5555867a05ebc3bdf2 ] ------------[ cut here ]------------ WARNING: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc pc : new_curseg+0x5e8/0x6dc Call trace: new_curseg+0x5e8/0x6dc f2fs_allocate_data_block+0xa54/0xe28 do_write_page+0x6c/0x194 f2fs_do_write_node_page+0x38/0x78 __write_node_page+0x248/0x6d4 f2fs_sync_node_pages+0x524/0x72c f2fs_write_checkpoint+0x4bc/0x9b0 __checkpoint_and_complete_reqs+0x80/0x244 issue_checkpoint_thread+0x8c/0xec kthread+0x114/0x1bc ret_from_fork+0x10/0x20 get_new_segment() detects inconsistent status in between free_segmap and free_secmap, let's record such error into super block, and bail out get_new_segment() instead of continue using the segment. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit f8efb4a2b3fea7ab192db57ab879a4f58af8889c Author: Miri Korenblit Date: Wed Apr 30 15:23:16 2025 +0300 wifi: iwlwifi: mld: check for NULL before referencing a pointer [ Upstream commit f9151f16e140b9c43f076579146679408af6f442 ] Errors can happen, and it is better not to risk with a NULL pointer dereference. Make sure that the links-to-remove pointers are not NULL before dereferencing it. Signed-off-by: Miri Korenblit Reviewed-by: Johannes Berg Link: https://patch.msgid.link/20250430151952.408652d45cda.I1bb72836dab17895a2e39910e4493d667db0fa80@changeid Signed-off-by: Sasha Levin commit a85832dae1d63880d360714c6a15616fac4337a3 Author: Johannes Berg Date: Sun May 4 13:26:30 2025 +0300 wifi: iwlwifi: dvm: pair transport op-mode enter/leave [ Upstream commit 6b340a694cee9e7a24b2be827c738b5b6cb13c84 ] If there's a failure and the op-mode didn't actually fully initialize, it should leave the transport again. Fix that. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250504132447.714c3517548b.I49557e7ba8c03be2b558cc9fb5efa2a9fbab890e@changeid Signed-off-by: Sasha Levin commit d093eb4fc59bfad9a2fffbe754492f9499061f1e Author: Johannes Berg Date: Mon May 5 21:56:47 2025 +0300 wifi: iwlwifi: mvm: fix beacon CCK flag [ Upstream commit 8d7f08922a8cb621aa5d00bdce6a7afe57af1665 ] The beacon CCK flag should be set for any CCK rate, not just for 1 Mbps. Fix that. Signed-off-by: Johannes Berg Reviewed-by: Ilan Peer Link: https://patch.msgid.link/20250505215513.fe18b7d92d7d.I7bb40a92cea102677b695beb1e2a62a5ea72678b@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit c7c077f2e6aafea8bfac4cd8b6911df63f460362 Author: Tiezhu Yang Date: Tue Apr 22 15:49:17 2025 +0800 rtla: Define __NR_sched_setattr for LoongArch [ Upstream commit 6a38c51a2557d4d50748818a858d507c250f3bee ] When executing "make -C tools/tracing/rtla" on LoongArch, there exists the following error: src/utils.c:237:24: error: '__NR_sched_setattr' undeclared Just define __NR_sched_setattr for LoongArch if not exist. Link: https://lore.kernel.org/20250422074917.25771-1-yangtiezhu@loongson.cn Reported-by: Haiyong Sun Signed-off-by: Tiezhu Yang Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit fd1a0d3023bd95c43a889d75a686c395df65072a Author: Corey Minyard Date: Thu Apr 10 14:44:26 2025 -0500 ipmi:ssif: Fix a shutdown race [ Upstream commit 6bd0eb6d759b9a22c5509ea04e19c2e8407ba418 ] It was possible for the SSIF thread to stop and quit before the kthread_stop() call because ssif->stopping was set before the stop. So only exit the SSIF thread is kthread_should_stop() returns true. There is no need to wake the thread, as the wait will be interrupted by kthread_stop(). Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 02d5431198f10e7c6e31f4138c14cfe400ec55a7 Author: Luke D. Jones Date: Sun Mar 23 15:34:20 2025 +1300 hid-asus: check ROG Ally MCU version and warn [ Upstream commit 00e005c952f74f50a3f86af96f56877be4685e14 ] ASUS have fixed suspend issues arising from a flag not being cleared in the MCU FW in both the ROG Ally 1 and the ROG Ally X. Implement a check and a warning to encourage users to update the FW to a minimum supported version. Signed-off-by: Luke D. Jones Reviewed-by: Mario Limonciello Link: https://lore.kernel.org/r/20250323023421.78012-2-luke@ljones.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 6af13ae6ee0e061d335ba6c8d7447596c7a5e93e Author: Heiko Stuebner Date: Sat May 3 22:25:31 2025 +0200 clk: rockchip: rk3036: mark ddrphy as critical [ Upstream commit 596a977b34a722c00245801a5774aa79cec4e81d ] The ddrphy is supplied by the dpll, but due to the limited number of PLLs on the rk3036, the dpll also is used for other periperhals, like the GPU. So it happened, when the Lima driver turned off the gpu clock, this in turn also disabled the dpll and thus the ram. Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20250503202532.992033-4-heiko@sntech.de Signed-off-by: Sasha Levin commit 1ae449ac8d5309010f4337d560bf8b086cdcad40 Author: Martin KaFai Lau Date: Wed May 7 13:32:32 2025 -0700 bpftool: Fix cgroup command to only show cgroup bpf programs [ Upstream commit b69d4413aa1961930fbf9ffad8376d577378daf9 ] The netkit program is not a cgroup bpf program and should not be shown in the output of the "bpftool cgroup show" command. However, if the netkit device happens to have ifindex 3, the "bpftool cgroup show" command will output the netkit bpf program as well: > ip -d link show dev nk1 3: nk1@if2: ... link/ether ... netkit mode ... > bpftool net show tc: nk1(3) netkit/peer tw_ns_nk2phy prog_id 469447 > bpftool cgroup show /sys/fs/cgroup/... ID AttachType AttachFlags Name ... ... ... 469447 netkit_peer tw_ns_nk2phy The reason is that the target_fd (which is the cgroup_fd here) and the target_ifindex are in a union in the uapi/linux/bpf.h. The bpftool iterates all values in "enum bpf_attach_type" which includes non cgroup attach types like netkit. The cgroup_fd is usually 3 here, so the bug is triggered when the netkit ifindex just happens to be 3 as well. The bpftool's cgroup.c already has a list of cgroup-only attach type defined in "cgroup_attach_types[]". This patch fixes it by iterating over "cgroup_attach_types[]" instead of "__MAX_BPF_ATTACH_TYPE". Cc: Quentin Monnet Reported-by: Takshak Chahande Signed-off-by: Martin KaFai Lau Acked-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/r/20250507203232.1420762-1-martin.lau@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit d76329704c68dafd19fa097e055c47ea420da697 Author: Benjamin Berg Date: Wed Apr 30 21:10:42 2025 +0200 wifi: mac80211: do not offer a mesh path if forwarding is disabled [ Upstream commit cf1b684a06170d253b47d6a5287821de976435bd ] When processing a PREQ the code would always check whether we have a mesh path locally and reply accordingly. However, when forwarding is disabled then we should not reply with this information as we will not forward data packets down that path. Move the check for dot11MeshForwarding up in the function and skip the mesh path lookup in that case. In the else block, set forward to false so that the rest of the function becomes a no-op and the dot11MeshForwarding check does not need to be duplicated. This explains an effect observed in the Freifunk community where mesh forwarding is disabled. In that case a mesh with three STAs and only bad links in between them, individual STAs would occionally have indirect mpath entries. This should not have happened. Signed-off-by: Benjamin Berg Reviewed-by: Rouven Czerwinski Link: https://patch.msgid.link/20250430191042.3287004-1-benjamin@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 4a97e183d0658078527c6f67d433fc5792ef0759 Author: Salah Triki Date: Sun Apr 27 10:57:45 2025 +0100 wireless: purelifi: plfxlc: fix memory leak in plfxlc_usb_wreq_asyn() [ Upstream commit 63a9a727d373fa5b8ce509eef50dbc45e0f745b9 ] Add usb_free_urb() in the error path to prevent memory leak. Signed-off-by: Salah Triki Link: https://patch.msgid.link/aA3_maPlEJzO7wrL@pc [fix subject] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 7b3fba91390c9d66f0fc3f48ef2d9ccea866d2f3 Author: Benjamin Berg Date: Tue May 6 22:40:58 2025 +0300 wifi: iwlwifi: mld: call thermal exit without wiphy lock held [ Upstream commit 83128399f3b4926ab73ce8e5081ce6595e9230e9 ] The driver must not hold the wiphy mutex when unregistering the thermal devices. Do not hold the lock for the call to iwl_mld_thermal_exit and only do a lock/unlock to cancel the ct_kill_exit_wk work. The problem is that iwl_mld_tzone_get_temp needs to take the wiphy lock while the thermal code is holding its own locks already. When unregistering the device, the reverse would happen as the driver was calling thermal_cooling_device_unregister with the wiphy mutex already held. It is not likely to trigger this deadlock as it can only happen if the thermal code is polling the temperature while the driver is being unloaded. However, lockdep reported it so fix it. Signed-off-by: Benjamin Berg Reviewed-by: Johannes Berg Link: https://patch.msgid.link/20250506194102.3407967-12-miriam.rachel.korenblit@intel.com Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 4cd1ae66090c79e3fe052de48e16ea69c854cead Author: Yuuki NAGAO Date: Sat May 3 09:32:27 2025 +0900 wifi: rtw88: rtw8822bu VID/PID for BUFFALO WI-U2-866DM [ Upstream commit b7f0cc647e52296a3d4dd727b6479dcd6d7e364e ] Add VID/PID 0411/03d1 for recently released BUFFALO WI-U2-866DM USB WiFi adapter. Signed-off-by: Yuuki NAGAO Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250503003227.6673-1-wf.yn386@gmail.com Signed-off-by: Sasha Levin commit c93f8fef1b378f3b8fb22b84a28846bfbd455e7f Author: Stefan Wahren Date: Fri May 9 14:04:34 2025 +0200 net: vertexcom: mse102x: Return code for mse102x_rx_pkt_spi [ Upstream commit 4ecf56f4b66011b583644bf9a62188d05dfcd78c ] The MSE102x doesn't provide any interrupt register, so the only way to handle the level interrupt is to fetch the whole packet from the MSE102x internal buffer via SPI. So in cases the interrupt handler fails to do this, it should return IRQ_NONE. This allows the core to disable the interrupt in case the issue persists and prevent an interrupt storm. Signed-off-by: Stefan Wahren Link: https://patch.msgid.link/20250509120435.43646-6-wahrenst@gmx.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 30afaa8cd3e4969bf725245d9ebbe4790c799bea Author: Jason Xing Date: Sat May 10 17:34:42 2025 +0800 net: mlx4: add SOF_TIMESTAMPING_TX_SOFTWARE flag when getting ts info [ Upstream commit b86bcfee30576b752302c55693fff97242b35dfd ] As mlx4 has implemented skb_tx_timestamp() in mlx4_en_xmit(), the SOFTWARE flag is surely needed when users are trying to get timestamp information. Signed-off-by: Jason Xing Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20250510093442.79711-1-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 46dd6e98dd954153a41d4920d7c6230c0dd3af55 Author: Yevgeny Kliteynik Date: Sun May 11 22:38:07 2025 +0300 net/mlx5: HWS, fix counting of rules in the matcher [ Upstream commit 4c56b5cbc323a10ebb6595500fb78fd8a4762efd ] Currently the counter that counts number of rules in a matcher is increased only when rule insertion is completed. In a multi-threaded usecase this can lead to a scenario that many rules can be in process of insertion in the same matcher, while none of them has completed the insertion and the rule counter is not updated. This results in a rule insertion failure for many of them at first attempt, which leads to all of them requiring rehash and requiring locking of all the queue locks. This patch fixes the case by increasing the rule counter in the beginning of insertion process and decreasing in case of any failure. Signed-off-by: Vlad Dogaru Signed-off-by: Yevgeny Kliteynik Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/1746992290-568936-8-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b5b48b90caf88ab40430513fb39c4a6af4726319 Author: Gabor Juhos Date: Wed May 14 21:18:35 2025 +0200 pinctrl: armada-37xx: propagate error from armada_37xx_gpio_get() [ Upstream commit 57273ff8bb16f3842c2597b5bbcd49e7fa12edf7 ] The regmap_read() function can fail, so propagate its error up to the stack instead of silently ignoring that. Signed-off-by: Imre Kaloz Reviewed-by: Andrew Lunn Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/20250514-pinctrl-a37xx-fixes-v2-4-07e9ac1ab737@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 44b9497f9271b5f4ee5c9d5b33376e3a363db384 Author: Mykyta Yatsenko Date: Wed May 14 12:32:20 2025 +0100 libbpf: Check bpf_map_skeleton link for NULL [ Upstream commit d0445d7dd3fd9b15af7564c38d7aa3cbc29778ee ] Avoid dereferencing bpf_map_skeleton's link field if it's NULL. If BPF map skeleton is created with the size, that indicates containing link field, but the field was not actually initialized with valid bpf_link pointer, libbpf crashes. This may happen when using libbpf-rs skeleton. Skeleton loading may still progress, but user needs to attach struct_ops map separately. Signed-off-by: Mykyta Yatsenko Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250514113220.219095-1-mykyta.yatsenko5@gmail.com Signed-off-by: Sasha Levin commit fcf7a2d62a27e50525116c6031346f3ffa7e251e Author: Gabor Juhos Date: Wed May 14 21:18:36 2025 +0200 pinctrl: armada-37xx: propagate error from armada_37xx_pmx_gpio_set_direction() [ Upstream commit bfa0ff804ffa8b1246ade8be08de98c9eb19d16f ] The armada_37xx_gpio_direction_{in,out}put() functions can fail, so propagate their error values back to the stack instead of silently ignoring those. Signed-off-by: Imre Kaloz Reviewed-by: Andrew Lunn Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/20250514-pinctrl-a37xx-fixes-v2-5-07e9ac1ab737@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 4380157eb754b87313be67503b3cbc42d071d141 Author: Jason Xing Date: Sat May 10 21:48:12 2025 +0800 net: stmmac: generate software timestamp just before the doorbell [ Upstream commit 33d4cc81fcd930fdbcca7ac9e8959225cbec0a5e ] Make sure the call of skb_tx_timestamp is as close as possbile to the doorbell. The patch also adjusts the order of setting SKBTX_IN_PROGRESS and generate software timestamp so that without SOF_TIMESTAMPING_OPT_TX_SWHW being set the software and hardware timestamps will not appear in the error queue of socket nearly at the same time (Please see __skb_tstamp_tx()). Signed-off-by: Jason Xing Link: https://patch.msgid.link/20250510134812.48199-4-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bf81bdce31805c685e947d6d419d0c6044a46048 Author: Ilya Leoshkevich Date: Mon May 12 22:57:30 2025 +0200 bpf: Pass the same orig_call value to trampoline functions [ Upstream commit 94bde253d3ae5d8a01cb958663b12daef1d06574 ] There is currently some confusion in the s390x JIT regarding whether orig_call can be NULL and what that means. Originally the NULL value was used to distinguish the struct_ops case, but this was superseded by BPF_TRAMP_F_INDIRECT (see commit 0c970ed2f87c ("s390/bpf: Fix indirect trampoline generation"). The remaining reason to have this check is that NULL can actually be passed to the arch_bpf_trampoline_size() call - but not to the respective arch_prepare_bpf_trampoline()! call - by bpf_struct_ops_prepare_trampoline(). Remove this asymmetry by passing stub_func to both functions, so that JITs may rely on orig_call never being NULL. Signed-off-by: Ilya Leoshkevich Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/r/20250512221911.61314-2-iii@linux.ibm.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit f7967d0374de9377b05a980c8d47e22fea609554 Author: Gabor Juhos Date: Wed May 14 21:18:37 2025 +0200 pinctrl: armada-37xx: propagate error from armada_37xx_gpio_get_direction() [ Upstream commit 6481c0a83367b0672951ccc876fbae7ee37b594b ] The regmap_read() function can fail, so propagate its error up to the stack instead of silently ignoring that. Signed-off-by: Imre Kaloz Reviewed-by: Andrew Lunn Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/20250514-pinctrl-a37xx-fixes-v2-6-07e9ac1ab737@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 3ffec7536a6350d401c7b6aafec6de3ca518d375 Author: Gabor Juhos Date: Wed May 14 21:18:38 2025 +0200 pinctrl: armada-37xx: propagate error from armada_37xx_pmx_set_by_name() [ Upstream commit 4229c28323db141eda69cb99427be75d3edba071 ] The regmap_update_bits() function can fail, so propagate its error up to the stack instead of silently ignoring that. Signed-off-by: Imre Kaloz Reviewed-by: Andrew Lunn Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/20250514-pinctrl-a37xx-fixes-v2-7-07e9ac1ab737@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit b6df8aab53cd59e2dc24dbcf3b9173f083dfeac4 Author: Jason Xing Date: Sat May 10 21:48:10 2025 +0800 net: atlantic: generate software timestamp just before the doorbell [ Upstream commit 285ad7477559b6b5ceed10ba7ecfed9d17c0e7c6 ] Make sure the call of skb_tx_timestamp is as close as possible to the doorbell. Signed-off-by: Jason Xing Link: https://patch.msgid.link/20250510134812.48199-2-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3dc0631ab94523ec155ccd14aab464d0df902083 Author: Dimitri Fedrau Date: Mon May 12 14:03:42 2025 +0200 net: phy: marvell-88q2xxx: Enable temperature measurement in probe again [ Upstream commit 10465365f3b094ba9a9795f212d13dee594bcfe7 ] Enabling of the temperature sensor was moved from mv88q2xxx_hwmon_probe to mv88q222x_config_init with the consequence that the sensor is only usable when the PHY is configured. Enable the sensor in mv88q2xxx_hwmon_probe as well to fix this. Signed-off-by: Dimitri Fedrau Link: https://patch.msgid.link/20250512-marvell-88q2xxx-hwmon-enable-at-probe-v4-1-9256a5c8f603@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ac9e7987008317b20e49180615fa1f961025ddcb Author: Leon Romanovsky Date: Tue May 13 13:56:22 2025 +0300 xfrm: validate assignment of maximal possible SEQ number [ Upstream commit e86212b6b13a20c5ad404c5597933f57fd0f1519 ] Users can set any seq/seq_hi/oseq/oseq_hi values. The XFRM core code doesn't prevent from them to set even 0xFFFFFFFF, however this value will cause for traffic drop. Is is happening because SEQ numbers here mean that packet with such number was processed and next number should be sent on the wire. In this case, the next number will be 0, and it means overflow which causes to (expected) packet drops. While it can be considered as misconfiguration and handled by XFRM datapath in the same manner as any other SEQ number, let's add validation to easy for packet offloads implementations which need to configure HW with next SEQ to send and not with current SEQ like it is done in core code. Signed-off-by: Leon Romanovsky Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 5d294539fa99293a6599c911d646a01698712c6b Author: Sebastian Andrzej Siewior Date: Mon May 12 11:27:22 2025 +0200 net: page_pool: Don't recycle into cache on PREEMPT_RT [ Upstream commit 32471b2f481dea8624f27669d36ffd131d24b732 ] With preemptible softirq and no per-CPU locking in local_bh_disable() on PREEMPT_RT the consumer can be preempted while a skb is returned. Avoid the race by disabling the recycle into the cache on PREEMPT_RT. Cc: Jesper Dangaard Brouer Cc: Ilias Apalodimas Signed-off-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20250512092736.229935-2-bigeasy@linutronix.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b799d6eab183be0300594e81c09c4e85ad914930 Author: Sebastian Andrzej Siewior Date: Mon May 12 11:27:24 2025 +0200 ipv4/route: Use this_cpu_inc() for stats on PREEMPT_RT [ Upstream commit 1c0829788a6e6e165846b9bedd0b908ef16260b6 ] The statistics are incremented with raw_cpu_inc() assuming it always happens with bottom half disabled. Without per-CPU locking in local_bh_disable() on PREEMPT_RT this is no longer true. Use this_cpu_inc() on PREEMPT_RT for the increment to not worry about preemption. Cc: David Ahern Signed-off-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20250512092736.229935-4-bigeasy@linutronix.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 31dcbac94bfeabb86bf85b0c36803fdd6536437b Author: Andrew Zaborowski Date: Fri May 9 01:04:29 2025 +0200 x86/sgx: Prevent attempts to reclaim poisoned pages [ Upstream commit ed16618c380c32c68c06186d0ccbb0d5e0586e59 ] TL;DR: SGX page reclaim touches the page to copy its contents to secondary storage. SGX instructions do not gracefully handle machine checks. Despite this, the existing SGX code will try to reclaim pages that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages. The longer story: Pages used by an enclave only get epc_page->poison set in arch_memory_failure() but they currently stay on sgx_active_page_list until sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched. epc_page->poison is not checked in the reclaimer logic meaning that, if other conditions are met, an attempt will be made to reclaim an EPC page that was poisoned. This is bad because 1. we don't want that page to end up added to another enclave and 2. it is likely to cause one core to shut down and the kernel to panic. Specifically, reclaiming uses microcode operations including "EWB" which accesses the EPC page contents to encrypt and write them out to non-SGX memory. Those operations cannot handle MCEs in their accesses other than by putting the executing core into a special shutdown state (affecting both threads with HT.) The kernel will subsequently panic on the remaining cores seeing the core didn't enter MCE handler(s) in time. Call sgx_unmark_page_reclaimable() to remove the affected EPC page from sgx_active_page_list on memory error to stop it being considered for reclaiming. Testing epc_page->poison in sgx_reclaim_pages() would also work but I assume it's better to add code in the less likely paths. The affected EPC page is not added to &node->sgx_poison_page_list until later in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd. Membership on other lists doesn't change to avoid changing any of the lists' semantics except for sgx_active_page_list. There's a "TBD" comment in arch_memory_failure() about pre-emptive actions, the goal here is not to address everything that it may imply. This also doesn't completely close the time window when a memory error notification will be fatal (for a not previously poisoned EPC page) -- the MCE can happen after sgx_reclaim_pages() has selected its candidates or even *inside* a microcode operation (actually easy to trigger due to the amount of time spent in them.) The spinlock in sgx_unmark_page_reclaimable() is safe because memory_failure() runs in process context and no spinlocks are held, explicitly noted in a mm/memory-failure.c comment. Signed-off-by: Andrew Zaborowski Signed-off-by: Ingo Molnar Acked-by: Dave Hansen Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Tony Luck Cc: balrogg@gmail.com Cc: linux-sgx@vger.kernel.org Link: https://lore.kernel.org/r/20250508230429.456271-1-andrew.zaborowski@intel.com Signed-off-by: Sasha Levin commit e6854134eae2a8ffd9cfb9be7e08415ae053afe5 Author: Eric Dumazet Date: Tue May 13 19:39:12 2025 +0000 tcp: add receive queue awareness in tcp_rcv_space_adjust() [ Upstream commit ea33537d82921e71f852ea2ed985acc562125efe ] If the application can not drain fast enough a TCP socket queue, tcp_rcv_space_adjust() can overestimate tp->rcvq_space.space. Then sk->sk_rcvbuf can grow and hit tcp_rmem[2] for no good reason. Fix this by taking into acount the number of available bytes. Keeping sk->sk_rcvbuf at the right size allows better cache efficiency. Signed-off-by: Eric Dumazet Reviewed-by: Wei Wang Link: https://patch.msgid.link/20250513193919.1089692-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 454a7a89b9b7a09eb846adaa126e84a7e00cd329 Author: Eric Dumazet Date: Tue May 13 19:39:14 2025 +0000 tcp: fix initial tp->rcvq_space.space value for passive TS enabled flows [ Upstream commit cd171461b90a2d2cf230943df60d580174633718 ] tcp_rcv_state_process() must tweak tp->advmss for TS enabled flows before the call to tcp_init_transfer() / tcp_init_buffer_space(). Otherwise tp->rcvq_space.space is off by 120 bytes (TCP_INIT_CWND * TCPOLEN_TSTAMP_ALIGNED). Signed-off-by: Eric Dumazet Reviewed-by: Wei Wang Link: https://patch.msgid.link/20250513193919.1089692-7-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e5e94cf6b734a24c08fa9f31f26696b2376e69a8 Author: Eric Dumazet Date: Tue May 13 19:39:13 2025 +0000 tcp: remove zero TCP TS samples for autotuning [ Upstream commit d59fc95be9d0fd05ed3ccc11b4a2f832bdf2ee03 ] For TCP flows using ms RFC 7323 timestamp granularity tcp_rcv_rtt_update() can be fed with 1 ms samples, breaking TCP autotuning for data center flows with sub ms RTT. Instead, rely on the window based samples, fed by tcp_rcv_rtt_measure() tcp_rcvbuf_grow() for a 10 second TCP_STREAM sesssion now looks saner. We can see rcvbuf is kept at a reasonable value. 222.234976: tcp:tcp_rcvbuf_grow: time=348 rtt_us=330 copied=110592 inq=0 space=40960 ooo=0 scaling_ratio=230 rcvbuf=131072 ... 222.235276: tcp:tcp_rcvbuf_grow: time=300 rtt_us=288 copied=126976 inq=0 space=110592 ooo=0 scaling_ratio=230 rcvbuf=246187 ... 222.235569: tcp:tcp_rcvbuf_grow: time=294 rtt_us=288 copied=184320 inq=0 space=126976 ooo=0 scaling_ratio=230 rcvbuf=282659 ... 222.235833: tcp:tcp_rcvbuf_grow: time=264 rtt_us=244 copied=373760 inq=0 space=184320 ooo=0 scaling_ratio=230 rcvbuf=410312 ... 222.236142: tcp:tcp_rcvbuf_grow: time=308 rtt_us=219 copied=424960 inq=20480 space=373760 ooo=0 scaling_ratio=230 rcvbuf=832022 ... 222.236378: tcp:tcp_rcvbuf_grow: time=236 rtt_us=219 copied=692224 inq=49152 space=404480 ooo=0 scaling_ratio=230 rcvbuf=900407 ... 222.236602: tcp:tcp_rcvbuf_grow: time=225 rtt_us=219 copied=730112 inq=49152 space=643072 ooo=0 scaling_ratio=230 rcvbuf=1431534 ... 222.237050: tcp:tcp_rcvbuf_grow: time=229 rtt_us=219 copied=1160192 inq=49152 space=680960 ooo=0 scaling_ratio=230 rcvbuf=1515876 ... 222.237618: tcp:tcp_rcvbuf_grow: time=305 rtt_us=218 copied=2228224 inq=49152 space=1111040 ooo=0 scaling_ratio=230 rcvbuf=2473271 ... 222.238591: tcp:tcp_rcvbuf_grow: time=224 rtt_us=218 copied=3063808 inq=360448 space=2179072 ooo=0 scaling_ratio=230 rcvbuf=4850803 ... 222.240647: tcp:tcp_rcvbuf_grow: time=260 rtt_us=218 copied=2752512 inq=0 space=2703360 ooo=0 scaling_ratio=230 rcvbuf=6017914 ... 222.243535: tcp:tcp_rcvbuf_grow: time=224 rtt_us=218 copied=2834432 inq=49152 space=2752512 ooo=0 scaling_ratio=230 rcvbuf=6127331 ... 222.245108: tcp:tcp_rcvbuf_grow: time=240 rtt_us=218 copied=2883584 inq=49152 space=2785280 ooo=0 scaling_ratio=230 rcvbuf=6200275 ... 222.245333: tcp:tcp_rcvbuf_grow: time=224 rtt_us=218 copied=2859008 inq=0 space=2834432 ooo=0 scaling_ratio=230 rcvbuf=6309692 ... 222.301021: tcp:tcp_rcvbuf_grow: time=222 rtt_us=218 copied=2883584 inq=0 space=2859008 ooo=0 scaling_ratio=230 rcvbuf=6364400 ... 222.989242: tcp:tcp_rcvbuf_grow: time=225 rtt_us=218 copied=2899968 inq=0 space=2883584 ooo=0 scaling_ratio=230 rcvbuf=6419108 ... 224.139553: tcp:tcp_rcvbuf_grow: time=224 rtt_us=218 copied=3014656 inq=65536 space=2899968 ooo=0 scaling_ratio=230 rcvbuf=6455580 ... 224.584608: tcp:tcp_rcvbuf_grow: time=232 rtt_us=218 copied=3014656 inq=49152 space=2949120 ooo=0 scaling_ratio=230 rcvbuf=6564997 ... 230.145560: tcp:tcp_rcvbuf_grow: time=223 rtt_us=218 copied=2981888 inq=0 space=2965504 ooo=0 scaling_ratio=230 rcvbuf=6601469 ... Signed-off-by: Eric Dumazet Reviewed-by: Wei Wang Link: https://patch.msgid.link/20250513193919.1089692-6-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 05f763e85e30fad6350662a8f9e0c72296351063 Author: Eric Dumazet Date: Tue May 13 19:39:15 2025 +0000 tcp: always seek for minimal rtt in tcp_rcv_rtt_update() [ Upstream commit b879dcb1aeeca278eacaac0b1e2425b1c7599f9f ] tcp_rcv_rtt_update() goal is to maintain an estimation of the RTT in tp->rcv_rtt_est.rtt_us, used by tcp_rcv_space_adjust() When TCP TS are enabled, tcp_rcv_rtt_update() is using EWMA to smooth the samples. Change this to immediately latch the incoming value if it is lower than tp->rcv_rtt_est.rtt_us, so that tcp_rcv_space_adjust() does not overshoot tp->rcvq_space.space and sk->sk_rcvbuf. Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20250513193919.1089692-8-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 81906b6404c8450e8e58e8bc4f33c2fe2a2c9d49 Author: Dian-Syuan Yang Date: Wed May 7 11:12:03 2025 +0800 wifi: rtw89: leave idle mode when setting WEP encryption for AP mode [ Upstream commit d105652b33245162867ac769bea336976e67efb8 ] Due to mac80211 triggering the hardware to enter idle mode, it fails to install WEP key causing connected station can't ping successfully. Currently, it forces the hardware to leave idle mode before driver adding WEP keys. Signed-off-by: Dian-Syuan Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250507031203.8256-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit 474adbff06891df7ceb4d9033bd2e45ec49ba09e Author: Mario Limonciello Date: Mon May 12 12:30:32 2025 -0500 iommu/amd: Allow matching ACPI HID devices without matching UIDs [ Upstream commit 51c33f333bbf7bdb6aa2a327e3a3e4bbb2591511 ] A BIOS upgrade has changed the IVRS DTE UID for a device that no longer matches the UID in the SSDT. In this case there is only one ACPI device on the system with that _HID but the _UID mismatch. IVRS: ``` Subtable Type : F0 [Device Entry: ACPI HID Named Device] Device ID : 0060 Data Setting (decoded below) : 40 INITPass : 0 EIntPass : 0 NMIPass : 0 Reserved : 0 System MGMT : 0 LINT0 Pass : 1 LINT1 Pass : 0 ACPI HID : "MSFT0201" ACPI CID : 0000000000000000 UID Format : 02 UID Length : 09 UID : "\_SB.MHSP" ``` SSDT: ``` Device (MHSP) { Name (_ADR, Zero) // _ADR: Address Name (_HID, "MSFT0201") // _HID: Hardware ID Name (_UID, One) // _UID: Unique ID ``` To handle this case; while enumerating ACPI devices in get_acpihid_device_id() count the number of matching ACPI devices with a matching _HID. If there is exactly one _HID match then accept it even if the UID doesn't match. Other operating systems allow this, but the current IVRS spec leaves some ambiguity whether to allow or disallow it. This should be clarified in future revisions of the spec. Output 'Firmware Bug' for this case to encourage it to be solved in the BIOS. Signed-off-by: Mario Limonciello Reviewed-by: Vasant Hegde Link: https://lore.kernel.org/r/20250512173129.1274275-1-superm1@kernel.org Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit d6d154ce3378a48957cd7a6141b610867f6e7310 Author: Muhammad Usama Anjum Date: Mon Apr 28 13:02:41 2025 +0500 wifi: ath11k: Fix QMI memory reuse logic [ Upstream commit cd2e7bae92bd7e65063ab8d04721d2b711ba4cbe ] Firmware requests 2 segments at first. The first segment is of 6799360 whose allocation fails due to dma remapping not available. The success is returned to firmware. Then firmware asks for 22 smaller segments instead of 2 big ones. Those get allocated successfully. At suspend/ hibernation time, these segments aren't freed as they will be reused by firmware after resuming. After resuming, the firmware asks for the 2 segments again with the first segment of 6799360 size. Since chunk->vaddr is not NULL, the type and size are compared with the previous type and size to know if it can be reused or not. Unfortunately, it is detected that it cannot be reused and this first smaller segment is freed. Then we continue to allocate 6799360 size memory which fails and ath11k_qmi_free_target_mem_chunk() is called which frees the second smaller segment as well. Later success is returned to firmware which asks for 22 smaller segments again. But as we had freed 2 segments already, we'll allocate the first 2 new smaller segments again and reuse the remaining 20. Hence 20 small segments are being reused instead of 22. Add skip logic when vaddr is set, but size/type don't match. Use the same skip and success logic as used when dma_alloc_coherent() fails. By skipping, the possibility of resume failure due to kernel failing to allocate memory for QMI can be avoided. kernel: ath11k_pci 0000:03:00.0: failed to allocate dma memory for qmi (524288 B type 1) ath11k_pci 0000:03:00.0: failed to allocate qmi target memory: -22 Tested-on: WCN6855 WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.6 Signed-off-by: Muhammad Usama Anjum Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20250428080242.466901-1-usama.anjum@collabora.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit f547b05092e34c5d66b50dcb000bca49e03b896f Author: Baochen Qiang Date: Fri Apr 18 10:55:34 2025 +0800 wifi: ath12k: fix a possible dead lock caused by ab->base_lock [ Upstream commit ef115c265a21e3c11deee7f73bd1061775a7bf20 ] spin_lock/spin_unlock are used in ath12k_reg_chan_list_event to acquire/release ab->base_lock. For now this is safe because that function is only called in soft IRQ context. But ath12k_reg_chan_list_event() will be called from process context in an upcoming patch, and this can result in a deadlock if ab->base_lock is acquired in process context and then soft IRQ occurs on the same CPU and tries to acquire that lock. Fix it by using spin_lock_bh and spin_unlock_bh instead. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250418-ath12k-6g-lp-vlp-v1-1-c869c86cad60@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 71c0becc58b6d8dc96f1572e72c312b979bdeb65 Author: Kang Yang Date: Mon Apr 21 10:34:39 2025 +0800 wifi: ath12k: fix macro definition HAL_RX_MSDU_PKT_LENGTH_GET [ Upstream commit a69bbf89d751ba2d6da21d773c4e29c91c5e53c4 ] Currently, HAL_RX_MSDU_PKT_LENGTH_GET uses u32_get_bits to obtain the MSDU length from the MSDU description. This is not right. Because all halphy descriptions are little endian. So use le32_get_bits for HAL_RX_MSDU_PKT_LENGTH_GET. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Kang Yang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250421023444.1778-9-kang.yang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 996423e3c7aa7264501d7ac91c820b0babcff233 Author: Frank Wunderlich Date: Sat May 10 19:49:32 2025 +0200 net: phy: mediatek: do not require syscon compatible for pio property [ Upstream commit 15d7b3dfafa98270eade6c77d2336790dde0a40d ] Current implementation requires syscon compatible for pio property which is used for driving the switch leds on mt7988. Replace syscon_regmap_lookup_by_phandle with of_parse_phandle and device_node_to_regmap to get the regmap already assigned by pinctrl driver. Signed-off-by: Frank Wunderlich Link: https://patch.msgid.link/20250510174933.154589-1-linux@fw-web.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 44870537fc60b3bbc2509d55c78b057725091fa9 Author: Moon Yeounsu Date: Thu May 15 16:53:31 2025 +0900 net: dlink: add synchronization for stats update [ Upstream commit 12889ce926e9a9baf6b83d809ba316af539b89e2 ] This patch synchronizes code that accesses from both user-space and IRQ contexts. The `get_stats()` function can be called from both context. `dev->stats.tx_errors` and `dev->stats.collisions` are also updated in the `tx_errors()` function. Therefore, these fields must also be protected by synchronized. There is no code that accessses `dev->stats.tx_errors` between the previous and updated lines, so the updating point can be moved. Signed-off-by: Moon Yeounsu Link: https://patch.msgid.link/20250515075333.48290-1-yyyynoom@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 359283bd52bca969b71225d982cb2cdfd00102f7 Author: Taniya Das Date: Mon Apr 14 14:30:40 2025 +0530 clk: qcom: gcc: Set FORCE_MEM_CORE_ON for gcc_ufs_axi_clk for 8650/8750 [ Upstream commit da94a81ea6c6f1cd2f389c5631e33c145ac7b35b ] Update the force mem core bit for UFS AXI clock to force the core on signal to remain active during halt state of the clk. If force mem core bit of the clock is not set, the memories of the subsystem will not retain the logic across power states. This is required for the MCQ feature of the UFS driver. Signed-off-by: Taniya Das Reviewed-by: Imran Shaik Link: https://lore.kernel.org/r/20250414-gcc_ufs_mem_core-v1-1-67b5529b9b5d@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0b7b6f613800506ae35fbcb74f0763490fb9be82 Author: Taniya Das Date: Mon Apr 14 14:30:41 2025 +0530 clk: qcom: gcc-x1e80100: Set FORCE MEM CORE for UFS clocks [ Upstream commit 201bf08ba9e26eeb0a96ba3fd5c026f531b31aed ] Update the force mem core bit for UFS ICE clock and UFS PHY AXI clock to force the core on signal to remain active during halt state of the clk. If force mem core bit of the clock is not set, the memories of the subsystem will not retain the logic across power states. This is required for the MCQ feature of UFS. Signed-off-by: Taniya Das Reviewed-by: Imran Shaik Link: https://lore.kernel.org/r/20250414-gcc_ufs_mem_core-v1-2-67b5529b9b5d@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ad309369a2aaa2cf6a9e420f64f0ecc888d48774 Author: Tali Perry Date: Fri Mar 28 19:32:50 2025 +0000 i2c: npcm: Add clock toggle recovery [ Upstream commit 38010591a0fc3203f1cee45b01ab358b72dd9ab2 ] During init of the bus, the module checks that the bus is idle. If one of the lines are stuck try to recover them first before failing. Sometimes SDA and SCL are low if improper reset occurs (e.g., reboot). Signed-off-by: Tali Perry Signed-off-by: Mohammed Elbadry Reviewed-by: Mukesh Kumar Savaliya Link: https://lore.kernel.org/r/20250328193252.1570811-1-mohammed.0.elbadry@gmail.com Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin commit 06bae199fff87a71668207425feb7204952e3a83 Author: Hector Martin Date: Sun Apr 27 11:30:43 2025 +0000 i2c: pasemi: Enable the unjam machine [ Upstream commit 88fe3078b54c9efaea7d1adfcf295e37dfb0274f ] The I2C bus can get stuck under some conditions (desync between controller and device). The pasemi controllers include an unjam feature that is enabled on reset, but was being disabled by the driver. Keep it enabled by explicitly setting the UJM bit in the CTL register. This should help recover the bus from certain conditions, which would otherwise remain stuck forever. Signed-off-by: Hector Martin Reviewed-by: Neal Gompa Reviewed-by: Alyssa Rosenzweig Signed-off-by: Sven Peter Link: https://lore.kernel.org/r/20250427-pasemi-fixes-v3-1-af28568296c0@svenpeter.dev Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin commit 3f03f77ce688d02da284174e1884b6065d6159bd Author: Akhil R Date: Thu Apr 24 11:03:20 2025 +0530 i2c: tegra: check msg length in SMBUS block read [ Upstream commit a6e04f05ce0b070ab39d5775580e65c7d943da0b ] For SMBUS block read, do not continue to read if the message length passed from the device is '0' or greater than the maximum allowed bytes. Signed-off-by: Akhil R Acked-by: Thierry Reding Link: https://lore.kernel.org/r/20250424053320.19211-1-akhilrajeev@nvidia.com Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin commit 02bd24dfdc8fa96dce58311ea259e24aefddd753 Author: Mike Tipton Date: Wed May 14 20:53:12 2025 -0700 cpufreq: scmi: Skip SCMI devices that aren't used by the CPUs [ Upstream commit 6c9bb86922728c7a4cceb99f131e00dd87514f20 ] Currently, all SCMI devices with performance domains attempt to register a cpufreq driver, even if their performance domains aren't used to control the CPUs. The cpufreq framework only supports registering a single driver, so only the first device will succeed. And if that device isn't used for the CPUs, then cpufreq will scale the wrong domains. To avoid this, return early from scmi_cpufreq_probe() if the probing SCMI device isn't referenced by the CPU device phandles. This keeps the existing assumption that all CPUs are controlled by a single SCMI device. Signed-off-by: Mike Tipton Reviewed-by: Peng Fan Reviewed-by: Cristian Marussi Reviewed-by: Sudeep Holla Tested-by: Cristian Marussi Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 401bc9f3a634857d3fb4d58c4dbdef04b3f29a90 Author: Alan Maguire Date: Mon May 19 17:59:34 2025 +0100 libbpf/btf: Fix string handling to support multi-split BTF [ Upstream commit 4e29128a9acec2a622734844bedee013e2901bdf ] libbpf handling of split BTF has been written largely with the assumption that multiple splits are possible, i.e. split BTF on top of split BTF on top of base BTF. One area where this does not quite work is string handling in split BTF; the start string offset should be the base BTF string section length + the base BTF string offset. This worked in the past because for a single split BTF with base the start string offset was always 0. Signed-off-by: Alan Maguire Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250519165935.261614-2-alan.maguire@oracle.com Signed-off-by: Sasha Levin commit 16fc7e7f3b8d7c8e257d6a3fcfeefca660ab1937 Author: Petr Malat Date: Fri May 16 10:17:28 2025 +0200 sctp: Do not wake readers in __sctp_write_space() [ Upstream commit af295892a7abbf05a3c2ba7abc4d81bb448623d6 ] Function __sctp_write_space() doesn't set poll key, which leads to ep_poll_callback() waking up all waiters, not only these waiting for the socket being writable. Set the key properly using wake_up_interruptible_poll(), which is preferred over the sync variant, as writers are not woken up before at least half of the queue is available. Also, TCP does the same. Signed-off-by: Petr Malat Acked-by: Xin Long Link: https://patch.msgid.link/20250516081727.1361451-1-oss@malat.biz Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9e0218b5cb00cc09608b600499feea1c12215237 Author: Aditya Kumar Singh Date: Fri May 16 16:02:07 2025 +0530 wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO [ Upstream commit 78a7a126dc5b8e3c5a3d4da9f513e0236d2dc1a3 ] When an AP interface is already beaconing, a subsequent scan is not allowed unless the user space explicitly sets the flag NL80211_SCAN_FLAG_AP in the scan request. If this flag is not set, the scan request will be returned with the error code -EOPNOTSUPP. However, this restriction currently applies only to non-ML interfaces. For ML interfaces, scans are allowed without this flag being explicitly set by the user space which is wrong. This is because the beaconing check currently uses only the deflink, which does not get set during MLO. Hence to fix this, during MLO, use the existing helper ieee80211_num_beaconing_links() to know if any of the link is beaconing. Signed-off-by: Aditya Kumar Singh Link: https://patch.msgid.link/20250516-bug_fix_mlo_scan-v2-1-12e59d9110ac@oss.qualcomm.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 66ed42793926009180b4978e9f5e16a1051355fc Author: Leon Yen Date: Fri May 9 16:21:17 2025 +0800 wifi: mt76: mt7925: introduce thermal protection [ Upstream commit 1d81e893b422a6f0ae70f8648867c2e73edfb413 ] Add thermal protection to prevent the chip from possible overheating due to prolonged high traffic and adverse operating conditions. Signed-off-by: Leon Yen Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250509082117.453819-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit abd282c194dcc1048499e2545bfae8f65f93298d Author: Samuel Williams Date: Sat May 10 19:53:09 2025 -0500 wifi: mt76: mt7921: add 160 MHz AP for mt7922 device [ Upstream commit 7011faebe543f8f094fdb3281d0ec9e1eab81309 ] This allows mt7922 in hostapd mode to transmit up to 1.4 Gbps. Signed-off-by: Samuel Williams Link: https://patch.msgid.link/20250511005316.1118961-1-sam8641@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0450224913f763064b65cfc0e9b0db130df77bdf Author: Henk Vergonet Date: Fri Apr 18 16:39:14 2025 +0200 wifi: mt76: mt76x2: Add support for LiteOn WN4516R,WN4519R [ Upstream commit 3c0e4f606d8693795a2c965d6f4987b1bfc31097 ] Adds support for: - LiteOn WN4516R - LiteOn WN4519R Both use: - A nonstandard USB connector - Mediatek chipset MT7600U - ASIC revision: 76320044 Disabled VHT support on ASIC revision 76320044: This fixes the 5G connectibity issue on LiteOn WN4519R module see https://github.com/openwrt/mt76/issues/971 And may also fix the 5G issues on the XBox One Wireless Adapter see https://github.com/openwrt/mt76/issues/200 I have looked at the FCC info related to the MT7632U chip as mentioned in here: https://github.com/openwrt/mt76/issues/459 These confirm the chipset does not support 'ac' mode and hence VHT should be turned of. Signed-off-by: Henk Vergonet Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20250418143914.31384-1-henk.vergonet@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 6bb003c5833e3459024a88acd675454c6afb0728 Author: sunliming Date: Sat Apr 19 11:15:28 2025 +0800 wifi: mt76: mt7996: fix uninitialized symbol warning [ Upstream commit 187de25110c8ac8d52e24f8c596ebdcbcd55bbbf ] Fix below smatch warnings: drivers/net/wireless/mediatek/mt76/mt7996/main.c:952 mt7996_mac_sta_add_links() error: uninitialized symbol 'err'. drivers/net/wireless/mediatek/mt76/mt7996/main.c:1133 mt7996_set_rts_threshold() error: uninitialized symbol 'ret'. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202504101051.1ya4Z4va-lkp@intel.com/ Signed-off-by: sunliming Link: https://patch.msgid.link/20250419031528.2073892-1-sunliming@linux.dev Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d754009016a31769fdae603d2c7b7bce13849dd6 Author: Krzysztof Kozlowski Date: Sun Apr 6 22:10:17 2025 +0200 Bluetooth: btmtksdio: Fix wakeup source leaks on device unbind [ Upstream commit ee3e4209e66d44180a41d5ca7271361a2a28fccf ] Device can be unbound or probe can fail, so driver must also release memory for the wakeup source. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit b79cfd53c283e57f2fa84b0049ec9a08e0d38593 Author: Krzysztof Kozlowski Date: Sun Apr 6 22:10:16 2025 +0200 Bluetooth: btmrvl_sdio: Fix wakeup source leaks on device unbind [ Upstream commit ba6535e8b494931471df9666addf0f1e5e6efa27 ] Device can be unbound or probe can fail, so driver must also release memory for the wakeup source. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 97610502cf513cd61aac1069e2bac1fe4b88888d Author: WangYuli Date: Tue Apr 15 10:33:50 2025 +0800 Bluetooth: btusb: Add RTL8851BE device 0x0bda:0xb850 [ Upstream commit c4dbb1bdada90168dd5fa2f7e4553cb0e1dad3c8 ] The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below: T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=b850 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Co-developed-by: Hao Li Signed-off-by: Hao Li Signed-off-by: WangYuli Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d29af67bc4d3e39312ebb6ed0d671414c97e02a1 Author: Jiande Lu Date: Tue Apr 29 18:16:05 2025 +0800 Bluetooth: btusb: Add new VID/PID 13d3/3630 for MT7925 [ Upstream commit 5bd5c716f7ec3e25d8d3b8a7566e192a26f9c7ce ] Add VID 13d3 & PID 3630 for MediaTek MT7925 USB Bluetooth chip. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=07 Lev=01 Prnt=01 Port=10 Cnt=02 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3630 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Signed-off-by: Jiande Lu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 5b695251bdf36e7648ed9efbcc034ea1aef0ab00 Author: Alok Tiwari Date: Mon May 19 07:17:19 2025 -0700 emulex/benet: correct command version selection in be_cmd_get_stats() [ Upstream commit edb888d29748cee674006a52e544925dacc7728e ] Logic here always sets hdr->version to 2 if it is not a BE3 or Lancer chip, even if it is BE2. Use 'else if' to prevent multiple assignments, setting version 0 for BE2, version 1 for BE3 and Lancer, and version 2 for others. Fixes potential incorrect version setting when BE2_chip and BE3_chip/lancer_chip checks could both be true. Signed-off-by: Alok Tiwari Link: https://patch.msgid.link/20250519141731.691136-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5fd5b8132b5de08c99eea003f7715ff2e361b007 Author: Benjamin Lin Date: Thu May 15 11:29:47 2025 +0800 wifi: mt76: mt7996: drop fragments with multicast or broadcast RA [ Upstream commit 80fda1cd7b0a1edd0849dc71403a070d0922118d ] IEEE 802.11 fragmentation can only be applied to unicast frames. Therefore, drop fragments with multicast or broadcast RA. This patch addresses vulnerabilities such as CVE-2020-26145. Signed-off-by: Benjamin Lin Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20250515032952.1653494-4-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d5b9137464d4cf809c1ab8609307efef2873fb2b Author: Tan En De Date: Sat Apr 12 10:33:03 2025 +0800 i2c: designware: Invoke runtime suspend on quick slave re-registration [ Upstream commit 2fe2b969d911a09abcd6a47401a3c66c38a310e6 ] Replaced pm_runtime_put() with pm_runtime_put_sync_suspend() to ensure the runtime suspend is invoked immediately when unregistering a slave. This prevents a race condition where suspend was skipped when unregistering and registering slave in quick succession. For example, consider the rapid sequence of `delete_device -> new_device -> delete_device -> new_device`. In this sequence, it is observed that the dw_i2c_plat_runtime_suspend() might not be invoked after `delete_device` operation. This is because after `delete_device` operation, when the pm_runtime_put() is about to trigger suspend, the following `new_device` operation might race and cancel the suspend. If that happens, during the `new_device` operation, dw_i2c_plat_runtime_resume() is skipped (since there was no suspend), which means `i_dev->init()`, i.e. i2c_dw_init_slave(), is skipped. Since i2c_dw_init_slave() is skipped, i2c_dw_configure_fifo_slave() is skipped too, which leaves `DW_IC_INTR_MASK` unconfigured. If we inspect the interrupt mask register using devmem, it will show as zero. Example shell script to reproduce the issue: ``` #!/bin/sh SLAVE_LADDR=0x1010 SLAVE_BUS=13 NEW_DEVICE=/sys/bus/i2c/devices/i2c-$SLAVE_BUS/new_device DELETE_DEVICE=/sys/bus/i2c/devices/i2c-$SLAVE_BUS/delete_device # Create initial device echo slave-24c02 $SLAVE_LADDR > $NEW_DEVICE sleep 2 # Rapid sequence of # delete_device -> new_device -> delete_device -> new_device echo $SLAVE_LADDR > $DELETE_DEVICE echo slave-24c02 $SLAVE_LADDR > $NEW_DEVICE echo $SLAVE_LADDR > $DELETE_DEVICE echo slave-24c02 $SLAVE_LADDR > $NEW_DEVICE # Using devmem to inspect IC_INTR_MASK will show as zero ``` Signed-off-by: Tan En De Acked-by: Jarkko Nikula Link: https://lore.kernel.org/r/20250412023303.378600-1-ende.tan@starfivetech.com Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin commit 02a46b15956a9341ac1c94ed5c096a754bbd5757 Author: Liwei Sun Date: Tue May 13 14:13:54 2025 +0800 Bluetooth: btusb: Add new VID/PID 13d3/3584 for MT7922 [ Upstream commit 71d9d3522aec301e4a1c4eae4b5e0656fc4a7262 ] A new variant of MT7922 wireless device has been identified. The device introduces itself as MEDIATEK MT7922, so treat it as MediaTek device. With this patch, btusb driver works as expected: [ 3.151162] Bluetooth: Core ver 2.22 [ 3.151185] Bluetooth: HCI device and connection manager initialized [ 3.151189] Bluetooth: HCI socket layer initialized [ 3.151191] Bluetooth: L2CAP socket layer initialized [ 3.151194] Bluetooth: SCO socket layer initialized [ 3.295718] Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20241106163512 [ 4.676634] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 4.676637] Bluetooth: BNEP filters: protocol multicast [ 4.676640] Bluetooth: BNEP socket layer initialized [ 5.560453] Bluetooth: hci0: Device setup in 2320660 usecs [ 5.560457] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported. [ 5.619197] Bluetooth: hci0: AOSP extensions version v1.00 [ 5.619204] Bluetooth: hci0: AOSP quality report is supported [ 5.619301] Bluetooth: MGMT ver 1.23 [ 6.741247] Bluetooth: RFCOMM TTY layer initialized [ 6.741258] Bluetooth: RFCOMM socket layer initialized [ 6.741261] Bluetooth: RFCOMM ver 1.11 lspci output: 04:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter USB information: T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3584 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I: If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I:* If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us Signed-off-by: Liwei Sun Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit b522d4d334f206284b1a44b0b0b2f99fd443b39b Author: Hou Tao Date: Mon May 26 14:25:34 2025 +0800 bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem() [ Upstream commit d4965578267e2e81f67c86e2608481e77e9c8569 ] bpf_map_lookup_percpu_elem() helper is also available for sleepable bpf program. When BPF JIT is disabled or under 32-bit host, bpf_map_lookup_percpu_elem() will not be inlined. Using it in a sleepable bpf program will trigger the warning in bpf_map_lookup_percpu_elem(), because the bpf program only holds rcu_read_lock_trace lock. Therefore, add the missed check. Reported-by: syzbot+dce5aae19ae4d6399986@syzkaller.appspotmail.com Closes: https://lore.kernel.org/bpf/000000000000176a130617420310@google.com/ Signed-off-by: Hou Tao Link: https://lore.kernel.org/r/20250526062534.1105938-1-houtao@huaweicloud.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 51f8108feff48e9e3943298609e42c0e7acd0039 Author: Chao Yu Date: Tue May 13 13:57:20 2025 +0800 f2fs: use vmalloc instead of kvmalloc in .init_{,de}compress_ctx [ Upstream commit 70dd07c888451503c3e93b6821e10d1ea1ec9930 ] .init_{,de}compress_ctx uses kvmalloc() to alloc memory, it will try to allocate physically continuous page first, it may cause more memory allocation pressure, let's use vmalloc instead to mitigate it. [Test] cd /data/local/tmp touch file f2fs_io setflags compression file f2fs_io getflags file for i in $(seq 1 10); do sync; echo 3 > /proc/sys/vm/drop_caches;\ time f2fs_io write 512 0 4096 zero osync file; truncate -s 0 file;\ done [Result] Before After Delta 21.243 21.694 -2.12% For compression, we recommend to use ioctl to compress file data in background for workaround. For decompression, only zstd will be affected. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit eb894bb2bdcc501367d43fae53529376345ac118 Author: Zilin Guan Date: Fri May 23 11:47:17 2025 +0000 tipc: use kfree_sensitive() for aead cleanup [ Upstream commit c8ef20fe7274c5766a317f9193b70bed717b6b3d ] The tipc_aead_free() function currently uses kfree() to release the aead structure. However, this structure contains sensitive information, such as key's SALT value, which should be securely erased from memory to prevent potential leakage. To enhance security, replace kfree() with kfree_sensitive() when freeing the aead structure. This change ensures that sensitive data is explicitly cleared before memory deallocation, aligning with the approach used in tipc_aead_init() and adhering to best practices for handling confidential information. Signed-off-by: Zilin Guan Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20250523114717.4021518-1-zilin@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9c41d2a2aa3817946eb613522200cab55513ddaa Author: Rengarajan S Date: Fri May 23 23:03:26 2025 +0530 net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devices [ Upstream commit 3b9935586a9b54d2da27901b830d3cf46ad66a1e ] Maximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kb and 64 Kb respectively. Adjust max size definitions and return correct EEPROM length based on device. Also prevent out-of-bound read/write. Signed-off-by: Rengarajan S Link: https://patch.msgid.link/20250523173326.18509-1-rengarajan.s@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 495015f99f6ca67e26c536232c2cef1c09a138b2 Author: Sergio Perez Gonzalez Date: Sun May 25 21:20:31 2025 -0600 net: macb: Check return value of dma_set_mask_and_coherent() [ Upstream commit 3920a758800762917177a6b5ab39707d8e376fe6 ] Issue flagged by coverity. Add a safety check for the return value of dma_set_mask_and_coherent, go to a safe exit if it returns error. Link: https://scan7.scan.coverity.com/#/project-view/53936/11354?selectedIssue=1643754 Signed-off-by: Sergio Perez Gonzalez Reviewed-by: Claudiu Beznea Link: https://patch.msgid.link/20250526032034.84900-1-sperezglz@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0b38fbb7a16a54ef71d349c38b0a196a2009a324 Author: Antonin Godard Date: Tue Mar 11 17:40:06 2025 +0100 drm/panel: simple: Add POWERTIP PH128800T004-ZZA01 panel entry [ Upstream commit 6374a1005f20c1c2f7bbcc1bc735c2be4910a685 ] Add support for the POWERTIP PH128800T004-ZZA01 10.1" (1280x800) LCD-TFT panel. Its panel description is very much like the POWERTIP PH128800T006-ZHC01 configured below this one, only its timings are different. Signed-off-by: Antonin Godard Reviewed-by: Dmitry Baryshkov Link: https://patchwork.freedesktop.org/patch/msgid/20250311-add-powertip-ph128800t004-v1-2-7f95e6984cea@bootlin.com Signed-off-by: Louis Chauvet Signed-off-by: Sasha Levin commit 249f16cdfc385ee6a764139a69be7b965bd944fd Author: Nas Chung Date: Thu Jul 25 15:10:33 2024 +0900 media: qcom: venus: Fix uninitialized variable warning [ Upstream commit 8e172e38a623ce284baf2514f963b29e4d47c62e ] Avoid uninitialized variable when both V4L2_TYPE_IS_OUTPUT() and V4L2_TYPE_IS_CAPTURE() return false. Signed-off-by: Nas Chung Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b3ca8b429e3acc605b35bb011edac111015da189 Author: Lucas De Marchi Date: Fri Mar 7 10:13:21 2025 -0800 drm/xe/uc: Remove static from loop variable [ Upstream commit 75584c8213d341ddd5b7c72abf822e62f4b3ab27 ] The `entries` variable is used to loop through the array - it's supposed to be const, but not static. Reviewed-by: John Harrison Link: https://patchwork.freedesktop.org/patch/msgid/20250307-xe-per-gt-fw-v1-1-459574d76400@intel.com Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin commit 58d9290ff21f3cc26f92c8288174ea333e397da0 Author: Victor Skvortsov Date: Thu Mar 27 11:38:42 2025 -0400 drm/amdgpu: Add indirect L1_TLB_CNTL reg programming for VFs [ Upstream commit 0c6e39ce6da20104900b11bad64464a12fb47320 ] VFs on some IP versions are unable to access this register directly. This register must be programmed before PSP ring is setup, so use PSP VF mailbox directly. PSP will broadcast the register value to all VF assigned instances. Signed-off-by: Victor Skvortsov Reviewed-by: Zhigang Luo Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit bb5728d12a64fc5c59f89ac7b762f00e827ddeea Author: Andy Yan Date: Tue Mar 18 14:20:17 2025 +0800 drm/rockchip: vop2: Make overlay layer select register configuration take effect by vsync [ Upstream commit c5996e4ab109c8bb5541453b20647eaaf9350f41 ] Because the layer/window enable/disable is take effect by vsync, if the overlay configuration of these layers does not follow vsync and takes effect immediately instead, when multiple layers are dynamically enable/disable, inconsistent display contents may be seen on the screen. Signed-off-by: Andy Yan Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20250318062024.4555-1-andyshrk@163.com Signed-off-by: Sasha Levin commit 373fa551187e35b17f14a424ef0442e41d751060 Author: Niklas Söderlund Date: Wed Apr 2 20:33:02 2025 +0200 media: rcar-vin: Fix stride setting for RAW8 formats [ Upstream commit e7376745ad5c8548e31d9ea58adfb5a847e017a4 ] Earlier versions of the datasheet where unclear about the stride setting for RAW8 capture formats. Later datasheets clarifies that the stride only process in this mode for non-image data. For image data the full stride shall be used. Compare section "RAW: 8 Bits and Embedded 8-Bit Non-Image Data, User Defined 8-bit Data" vs "RAW: 8 Bits". Remove the special case from pixel formats that carry image data and treat it as any other image format. Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20250402183302.140055-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 14ff37e2954eb33e1f6fb4d48af2cb82b1e0e96f Author: Simon Schuster Date: Thu Mar 27 14:54:22 2025 +0100 nios2: force update_mmu_cache on spurious tlb-permission--related pagefaults [ Upstream commit 2d8a3179ea035f9341b6a73e5ba4029fc67e983d ] NIOS2 uses a software-managed TLB for virtual address translation. To flush a cache line, the original mapping is replaced by one to physical address 0x0 with no permissions (rwx mapped to 0) set. This can lead to TLB-permission--related traps when such a nominally flushed entry is encountered as a mapping for an otherwise valid virtual address within a process (e.g. due to an MMU-PID-namespace rollover that previously flushed the complete TLB including entries of existing, running processes). The default ptep_set_access_flags implementation from mm/pgtable-generic.c only forces a TLB-update when the page-table entry has changed within the page table: /* * [...] We return whether the PTE actually changed, which in turn * instructs the caller to do things like update__mmu_cache. [...] */ int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long address, pte_t *ptep, pte_t entry, int dirty) { int changed = !pte_same(*ptep, entry); if (changed) { set_pte_at(vma->vm_mm, address, ptep, entry); flush_tlb_fix_spurious_fault(vma, address); } return changed; } However, no cross-referencing with the TLB-state occurs, so the flushing-induced pseudo entries that are responsible for the pagefault in the first place are never pre-empted from TLB on this code path. This commit fixes this behaviour by always requesting a TLB-update in this part of the pagefault handling, fixing spurious page-faults on the way. The handling is a straightforward port of the logic from the MIPS architecture via an arch-specific ptep_set_access_flags function ported from arch/mips/include/asm/pgtable.h. Signed-off-by: Simon Schuster Signed-off-by: Andreas Oetken Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin commit 4b7d6e44a3987c00fd0bc8be72ef944cb6a196fe Author: Shravan Chippa Date: Wed Mar 5 10:44:41 2025 +0530 media: i2c: imx334: update mode_3840x2160_regs array [ Upstream commit 35132d039c566b0e9d8e53f76f512b22607c2405 ] The 3840x2160 mode operates with the imx334 reset values. If we switch to other modes and then return to the 3840x2160 mode, it should function correctly. so updated the mode_3840x2160_regs array with the imx334 reset values. Signed-off-by: Shravan Chippa Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 14acbb5af101b7bb58c0952949bba4c5fdf0ee7e Author: Wentao Liang Date: Tue Apr 22 10:13:45 2025 +0800 media: platform: exynos4-is: Add hardware sync wait to fimc_is_hw_change_mode() [ Upstream commit bd9f6ce7d512fa21249415c16af801a4ed5d97b6 ] In fimc_is_hw_change_mode(), the function changes camera modes without waiting for hardware completion, risking corrupted data or system hangs if subsequent operations proceed before the hardware is ready. Add fimc_is_hw_wait_intmsr0_intmsd0() after mode configuration, ensuring hardware state synchronization and stable interrupt handling. Signed-off-by: Wentao Liang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 83f3b6f987b359d25b4ba06344e52b672b05467f Author: Hans Verkuil Date: Tue Apr 1 11:54:17 2025 +0200 media: tc358743: ignore video while HPD is low [ Upstream commit 6829c5b5d26b1be31880d74ec24cb32d2d75f1ae ] If the HPD is low (happens if there is no EDID or the EDID is being updated), then return -ENOLINK in tc358743_get_detected_timings() instead of detecting video. This avoids userspace thinking that it can start streaming when the HPD is low. Signed-off-by: Hans Verkuil Tested-by: Maxime Ripard Link: https://lore.kernel.org/linux-media/20240628-stoic-bettong-of-fortitude-e25611@houat/ Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 75b6e47bf214eb0899887f12dadde94c3c94a540 Author: Amber Lin Date: Tue Apr 22 15:54:19 2025 -0400 drm/amdkfd: Set SDMA_RLCx_IB_CNTL/SWITCH_INSIDE_IB [ Upstream commit ab9fcc6362e0699fc1150aa1d8503c40fce2c1e1 ] When submitting MQD to CP, set SDMA_RLCx_IB_CNTL/SWITCH_INSIDE_IB bit so it'll allow SDMA preemption if there is a massive command buffer of long-running SDMA commands. Signed-off-by: Amber Lin Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 85b032ef73598fb6e71f13f9e72276318ba9c6f0 Author: Dmitry Baryshkov Date: Fri Mar 7 08:24:53 2025 +0200 drm/msm/dpu: don't select single flush for active CTL blocks [ Upstream commit e93eee524bb78f3ee4b78654d0083382f98b3d23 ] In case of ACTIVE CTLs, a single CTL is being used for flushing all INTF blocks. Don't skip programming the CTL on those targets. Tested-by: Neil Armstrong # on SM8550-QRD Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/641585/ Link: https://lore.kernel.org/r/20250307-dpu-active-ctl-v3-5-5d20655f10ca@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 9b4b05a262cb8f9bbad0a38d1b65e42cff9838bd Author: Laurent Pinchart Date: Wed Apr 30 02:28:59 2025 +0300 media: renesas: vsp1: Fix media bus code setup on RWPF source pad [ Upstream commit b6e57605eff6224df4debf188eb7a02dedb7686f ] The RWPF source pad media bus code can only be different from the sink pad code when enabling color space conversion, which can only convert between RGB and YUV. If the sink pad code is HSV, no conversion is possible. Fix the pad set format handler to reflect this hardware limitation. Signed-off-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Link: https://lore.kernel.org/r/20250429232904.26413-5-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 22defb034df416ea0cf1b40b9932d6636bdb68e2 Author: Mario Limonciello Date: Tue Apr 22 15:58:41 2025 -0500 drm/amd/display: Restructure DMI quirks [ Upstream commit de6485e3df24170d71706d6f2c55a496443c3803 ] [Why] DMI quirks are relatively big code that makes amdgpu_dm 200 lines larger. [How] Move DMI quirks into a dedicated source file and make all quirks variables for `struct amdgpu_display_manager`. Reviewed-by: Alex Hung Signed-off-by: Mario Limonciello Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3d4bd0ea0c63faf3ec258e89f6122ff33a868135 Author: TungYu Lu Date: Fri Apr 11 10:41:48 2025 +0800 drm/amd/display: Correct prefetch calculation [ Upstream commit 33bc89949b4366dff2dca30bc61ba1c0cbcd2ab2 ] [Why] The minimum value of the dst_y_prefetch_equ was not correct in prefetch calculation whice causes OPTC underflow. [How] Add the min operation of dst_y_prefetch_equ in prefetch calculation for legacy DML. Reviewed-by: Nicholas Kazlauskas Signed-off-by: TungYu Lu Signed-off-by: Zaeem Mohamed Tested-by: Mark Broadworth Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit bdf223b36cbb13051dbb6d68e1f10c8530efed54 Author: Lijo Lazar Date: Thu Apr 17 10:15:46 2025 +0530 drm/amd/pm: Reset SMU v13.0.x custom settings [ Upstream commit 923406e74ec66364b829b7f8b6b67d46200567a6 ] On SMU v13.0.2 and SMU v13.0.6 variants user may choose custom min/max clocks in manual perf mode. Those custom min/max values need to be reset once user switches to auto or restores default settings. Otherwise, they may get used inadvertently during the next operation. Signed-off-by: Lijo Lazar Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9806ae34d7d661c372247cd36f83bfa0523d60ed Author: Dylan Wolff Date: Wed Mar 12 16:02:00 2025 +0800 jfs: Fix null-ptr-deref in jfs_ioc_trim [ Upstream commit a4685408ff6c3e2af366ad9a7274f45ff3f394ee ] [ Syzkaller Report ] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000087: 0000 [#1 KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f] CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted 6.13.0-rc6-gfbfd64d25c7a-dirty #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Sched_ext: serialise (enabled+all), task: runnable_at=-30ms RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body+0x61/0xb0 ? die_addr+0xb1/0xe0 ? exc_general_protection+0x333/0x510 ? asm_exc_general_protection+0x26/0x30 ? jfs_ioc_trim+0x34b/0x8f0 jfs_ioctl+0x3c8/0x4f0 ? __pfx_jfs_ioctl+0x10/0x10 ? __pfx_jfs_ioctl+0x10/0x10 __se_sys_ioctl+0x269/0x350 ? __pfx___se_sys_ioctl+0x10/0x10 ? do_syscall_64+0xfb/0x210 do_syscall_64+0xee/0x210 ? syscall_exit_to_user_mode+0x1e0/0x330 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe51f4903ad Code: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d RSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903ad RDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640 R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Kernel panic - not syncing: Fatal exception [ Analysis ] We believe that we have found a concurrency bug in the `fs/jfs` module that results in a null pointer dereference. There is a closely related issue which has been fixed: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234 ... but, unfortunately, the accepted patch appears to still be susceptible to a null pointer dereference under some interleavings. To trigger the bug, we think that `JFS_SBI(ipbmap->i_sb)->bmap` is set to NULL in `dbFreeBits` and then dereferenced in `jfs_ioc_trim`. This bug manifests quite rarely under normal circumstances, but is triggereable from a syz-program. Reported-and-tested-by: Dylan J. Wolff Reported-and-tested-by: Jiacheng Xu Signed-off-by: Dylan J. Wolff Signed-off-by: Jiacheng Xu Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit f693a01b361ee04c85307b40161d216202046767 Author: Dillon Varone Date: Wed Mar 19 13:53:25 2025 -0400 drm/amd/display: Fix VUpdate offset calculations for dcn401 [ Upstream commit fe45e2af4a22e569b35b7f45eb9f040f6fbef94f ] [WHY&HOW] DCN401 uses a different structure to store the VStartup offset used to calculate the VUpdate position, so adjust the calculations to use this value. Reviewed-by: Aric Cyr Signed-off-by: Dillon Varone Signed-off-by: Fangzhi Zuo Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 27a15fcb68bb5aa826859bde4f6ae8a083ccf547 Author: Alex Deucher Date: Wed Mar 19 11:57:49 2025 -0400 drm/amdgpu/gfx9: fix CSIB handling [ Upstream commit a4a4c0ae6742ec7d6bf1548d2c6828de440814a0 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 173d6f41d08957e14b4148ff61bb1a6c8e600c32 Author: Samson Tam Date: Thu May 1 15:59:47 2025 -0400 drm/amd/display: disable EASF narrow filter sharpening [ Upstream commit c8d7e0be8183f4375a5cf5c3efd0c678129ea4de ] [Why & How] Default should be 1 to disable EASF narrow filter sharpening. Reviewed-by: Alvin Lee Signed-off-by: Samson Tam Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0160b9d6c48d2d72f84f7ca592d30cf88db9b4df Author: Alex Deucher Date: Wed Mar 19 11:57:34 2025 -0400 drm/amdgpu/gfx8: fix CSIB handling [ Upstream commit c8b8d7a4f1c5cdfbd61d75302fb3e3cdefb1a7ab ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 00f38b361ec2156667a66c175351fa75e39c24e0 Author: Zhang Yi Date: Wed Apr 23 16:52:53 2025 +0800 ext4: prevent stale extent cache entries caused by concurrent get es_cache [ Upstream commit f22a0ef2231a7d8374bb021eb86404d0e9de5a02 ] The EXT4_IOC_GET_ES_CACHE and EXT4_IOC_PRECACHE_EXTENTS currently invokes ext4_ext_precache() to preload the extent cache without holding the inode's i_rwsem. This can result in stale extent cache entries when competing with operations such as ext4_collapse_range() which calls ext4_ext_remove_space() or ext4_ext_shift_extents(). The problem arises when ext4_ext_remove_space() temporarily releases i_data_sem due to insufficient journal credits. During this interval, a concurrent EXT4_IOC_GET_ES_CACHE or EXT4_IOC_PRECACHE_EXTENTS may cache extent entries that are about to be deleted. As a result, these cached entries become stale and inconsistent with the actual extents. Loading the extents cache without holding the inode's i_rwsem or the mapping's invalidate_lock is not permitted besides during the writeback. Fix this by holding the i_rwsem during EXT4_IOC_GET_ES_CACHE and EXT4_IOC_PRECACHE_EXTENTS. Signed-off-by: Zhang Yi Link: https://patch.msgid.link/20250423085257.122685-6-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit b772fdeb760dec59352e4dd4abbd0b9813ff02ce Author: Long Li Date: Sat Mar 1 14:48:36 2025 +0800 sunrpc: fix race in cache cleanup causing stale nextcheck time [ Upstream commit 2298abcbe11e9b553d03c0f1d084da786f7eff88 ] When cache cleanup runs concurrently with cache entry removal, a race condition can occur that leads to incorrect nextcheck times. This can delay cache cleanup for the cache_detail by up to 1800 seconds: 1. cache_clean() sets nextcheck to current time plus 1800 seconds 2. While scanning a non-empty bucket, concurrent cache entry removal can empty that bucket 3. cache_clean() finds no cache entries in the now-empty bucket to update the nextcheck time 4. This maybe delays the next scan of the cache_detail by up to 1800 seconds even when it should be scanned earlier based on remaining entries Fix this by moving the hash_lock acquisition earlier in cache_clean(). This ensures bucket emptiness checks and nextcheck updates happen atomically, preventing the race between cleanup and entry removal. Signed-off-by: Long Li Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 1c16a901a43a7fdddedcb3907e5d27fe95eee991 Author: Lijo Lazar Date: Wed Apr 16 12:23:44 2025 +0530 drm/amdgpu: Disallow partition query during reset [ Upstream commit 75f138db48c5c493f0ac198c2579d52fc6a4c4a0 ] Reject queries to get current partition modes during reset. Also, don't accept sysfs interface requests to switch compute partition mode while in reset. Signed-off-by: Lijo Lazar Reviewed-by: Hawking Zhang Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8aa3b10fb320ea05cf3eae9db8ee7d292cd3cde6 Author: Arvind Yadav Date: Tue Aug 27 15:29:49 2024 +0530 drm/amdgpu: fix MES GFX mask [ Upstream commit 9d3afcb7b9f950b9b7c58ceeeb9e71f3476e69ed ] Current MES GFX mask prevents FW to enable oversubscription. This patch does the following: - Fixes the mask values and adds a description for the same - Removes the central mask setup and makes it IP specific, as it would be different when the number of pipes and queues are different. v2: squash in fix from Shashank Cc: Christian König Cc: Alex Deucher Acked-by: Christian König Signed-off-by: Shashank Sharma Signed-off-by: Arvind Yadav Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6879de7134d1810b053360ec4dcf8d43bb92c249 Author: Nicolas Dufresne Date: Thu May 1 15:55:48 2025 -0400 media: rkvdec: Initialize the m2m context before the controls [ Upstream commit d43d7db3c8a1868dcbc6cb8de90a3cdf309d6cbb ] Setting up the control handler calls into .s_ctrl ops. While validating the controls the ops may need to access some of the context state, which could lead to a crash if not properly initialized. Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 3e9352af5b920ae937a0c3a278094cba22673696 Author: Hans Verkuil Date: Tue Apr 1 14:17:55 2025 +0000 media: cec: extron-da-hd-4k-plus: Fix Wformat-truncation [ Upstream commit 5edc9b560f60c40e658af0b8e98ae2dfadc438d8 ] Fix gcc8 warning: drivers/media/cec/usb/extron-da-hd-4k-plus/extron-da-hd-4k-plus.c:1014:44: warning: 'DCEC' directive output may be truncated writing 4 bytes into a region of size between 0 and 53 [-Wformat-truncation=] Resizing the 'buf' and 'cmd' arrays fixed the warning. Signed-off-by: Ricardo Ribalda Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 28989522f5448e5662e8ac05faf9b2ab5a62c461 Author: Dillon Varone Date: Wed Mar 19 13:54:44 2025 -0400 drm/amd/display: Fix Vertical Interrupt definitions for dcn32, dcn401 [ Upstream commit e8cc149ed906a371a5962ff8065393bae28165c9 ] [WHY&HOW] - VUPDATE_NO_LOCK should be used in place of VUPDATE always - Add VERTICAL_INTERRUPT1 and VERTICAL_INTERRUPT2 definitions Reviewed-by: Aric Cyr Signed-off-by: Dillon Varone Signed-off-by: Fangzhi Zuo Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8060a23490e3e2aae764c376cbb139ebe54f0953 Author: Kevin Gao Date: Wed Mar 26 14:14:05 2025 -0400 drm/amd/display: Correct SSC enable detection for DCN351 [ Upstream commit d01a7306e1bec9c02268793f58144e3e42695bf0 ] [Why] Due to very small clock register delta between DCN35 and DCN351, clock spread is being checked on the wrong register for DCN351, causing the display driver to believe that DPREFCLK downspread to be disabled when in some stacks it is enabled. This causes the clock values for audio to be incorrect. [How] Both DCN351 and DCN35 use the same clk_mgr, so we modify the DCN35 function that checks for SSC enable to read CLK6 instead of CLK5 when using DCN351. This allows us to read for DPREFCLK downspread correctly so the clock can properly compensate when setting values. Reviewed-by: Charlene Liu Signed-off-by: Kevin Gao Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c289128375cec1f39b81c41b8a0602eb29a7a7cf Author: Ovidiu Bunea Date: Thu Apr 10 11:00:08 2025 -0400 drm/amd/display: Update IPS sequential_ono requirement checks [ Upstream commit b4db797117ceba88ba405a080811369418104304 ] [why & how] ASICs that require special RCG/PG programming are determined based on hw_internal_rev. Update these checks to properly include all such ASICs. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Ovidiu Bunea Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 70a1a541ce7e2b981259e5f089b93e78e0313a69 Author: Daniele Ceraolo Spurio Date: Wed Apr 23 10:39:08 2025 -0700 drm/xe/vf: Fix guc_info debugfs for VFs [ Upstream commit dba7d17d50b4488c697e991d18a0e55669d9fa59 ] The guc_info debugfs attempts to read a bunch of registers that the VFs doesn't have access to, so fix it by skipping the reads. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4775 Signed-off-by: Daniele Ceraolo Spurio Cc: Michal Wajdeczko Cc: Lukasz Laguna Reviewed-by: Lukasz Laguna Link: https://lore.kernel.org/r/20250423173908.1571412-1-daniele.ceraolospurio@intel.com Signed-off-by: Sasha Levin commit bc46ded74dbb028171cb3911dd42484208d7f5e6 Author: Tomi Valkeinen Date: Wed Mar 26 13:34:02 2025 +0200 media: ti: cal: Fix wrong goto on error path [ Upstream commit a5b18fd769b7dc2e77a9e6a390844cbf50626ae8 ] If pm_runtime_resume_and_get() fails, we should unprepare the context, but currently we skip that as we goto to a later line. Reviewed-by: Kieran Bingham Signed-off-by: Tomi Valkeinen Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit c8399564a58fb6ea2ff21a6fd278417943cb51a5 Author: Aditya Dutt Date: Tue Apr 1 20:59:16 2025 +0530 jfs: fix array-index-out-of-bounds read in add_missing_indices [ Upstream commit 5dff41a86377563f7a2b968aae00d25b4ceb37c9 ] stbl is s8 but it must contain offsets into slot which can go from 0 to 127. Added a bound check for that error and return -EIO if the check fails. Also make jfs_readdir return with error if add_missing_indices returns with an error. Reported-by: syzbot+b974bd41515f770c608b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com./bug?extid=b974bd41515f770c608b Signed-off-by: Aditya Dutt Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 4251c65a004c13271421f6f7803b0c5fbb1ef191 Author: Zhang Yi Date: Wed Apr 23 16:52:49 2025 +0800 ext4: ext4: unify EXT4_EX_NOCACHE|NOFAIL flags in ext4_ext_remove_space() [ Upstream commit 53ce42accd2002cc490fc86000ac532530507a74 ] When removing space, we should use EXT4_EX_NOCACHE because we don't need to cache extents, and we should also use EXT4_EX_NOFAIL to prevent metadata inconsistencies that may arise from memory allocation failures. While ext4_ext_remove_space() already uses these two flags in most places, they are missing in ext4_ext_search_right() and read_extent_tree_block() calls. Unify the flags to ensure consistent behavior throughout the extent removal process. Signed-off-by: Zhang Yi Link: https://patch.msgid.link/20250423085257.122685-2-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 65d1cb1eb12b011504a24801ffe72c8adf8d835a Author: Harish Chegondi Date: Thu May 1 12:14:45 2025 -0700 drm/xe: Use copy_from_user() instead of __copy_from_user() [ Upstream commit aef87a5fdb5117eafb498ac4fc25e9f26f630f45 ] copy_from_user() has more checks and is more safer than __copy_from_user() Suggested-by: Kees Cook Signed-off-by: Harish Chegondi Reviewed-by: Matthew Brost Reviewed-by: Ashutosh Dixit Signed-off-by: Ashutosh Dixit Link: https://lore.kernel.org/r/acabf20aa8621c7bc8de09b1bffb8d14b5376484.1746126614.git.harish.chegondi@intel.com Signed-off-by: Sasha Levin commit 2d8c5b608b5232f36e1f5412737c0b4667d7c42b Author: Alex Deucher Date: Wed Mar 19 11:57:19 2025 -0400 drm/amdgpu/gfx7: fix CSIB handling [ Upstream commit be7652c23d833d1ab2c67b16e173b1a4e69d1ae6 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3e6c77f9d41a1c45ac333c3aa855e20250258dd3 Author: Qasim Ijaz Date: Thu Mar 13 16:14:24 2025 +0000 drm/ttm/tests: fix incorrect assert in ttm_bo_unreserve_bulk() [ Upstream commit 878516a9e62cd220379e511d43dcf58df3a6ca9f ] In the ttm_bo_unreserve_bulk() test function, resv is allocated using kunit_kzalloc(), but the subsequent assertion mistakenly verifies the ttm_dev pointer instead of the resv pointer. Fix the assertion to properly verify the resv pointer. Signed-off-by: Qasim Ijaz Link: https://patchwork.freedesktop.org/patch/msgid/20250313161424.10688-1-qasdev00@gmail.com Reviewed-by: Christian König Signed-off-by: Christian König Signed-off-by: Sasha Levin commit 4e3f9a8312ccd290ad2b3f672f8c71ed6aebb6f8 Author: Charlene Liu Date: Wed Mar 12 17:30:25 2025 -0400 drm/amd/display: fix zero value for APU watermark_c [ Upstream commit d5a7fdc88a2d64242d959942cbd0e1499ebb9806 ] [why] the guard of is_apu not in sync, caused no watermark_c output. Reviewed-by: Ovidiu Bunea Signed-off-by: Charlene Liu Signed-off-by: Aurabindo Pillai Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 724b01051a3ac6336e444adc83b71459d03a2c2c Author: Nas Chung Date: Thu Jul 25 15:10:32 2024 +0900 media: uapi: v4l: Change V4L2_TYPE_IS_CAPTURE condition [ Upstream commit ad2698efce37e910dcf3c3914263e6cb3e86f8cd ] Explicitly compare a buffer type only with valid buffer types, to avoid matching a buffer type outside of the valid buffer type set. Signed-off-by: Nas Chung Reviewed-by: Michael Tretter Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9d977d8f876d07a7a632c8260d5665b739c74f3e Author: Sakari Ailus Date: Wed Feb 26 14:27:58 2025 +0200 media: ccs-pll: Better validate VT PLL branch [ Upstream commit cd9cb0313a42ae029cd5af9293b0add984ed252e ] Check that the VT PLL dividers are actually found, don't trust they always are even though they should be. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit db66cee5feec7c4682bc87b45d28b0249f067049 Author: Vicki Pfau Date: Thu Mar 13 14:16:44 2025 -0700 drm: panel-orientation-quirks: Add ZOTAC Gaming Zone [ Upstream commit 96c85e428ebaeacd2c640eba075479ab92072ccd ] Add a panel orientation quirk for the ZOTAC Gaming Zone handheld gaming device. Signed-off-by: Vicki Pfau Reviewed-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20250313211643.860786-2-vi@endrift.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit b5ececd273cff5ad1b2fb2f9bd0951cd387d0c29 Author: Alex Deucher Date: Wed Mar 19 11:58:03 2025 -0400 drm/amdgpu/gfx10: fix CSIB handling [ Upstream commit 683308af030cd9b8d3f1de5cbc1ee51788878feb ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1c4842ccf664beae21aa60ec511a60855bc4f7ca Author: Tarang Raval Date: Sat Mar 29 11:13:28 2025 +0530 media: i2c: imx334: Fix runtime PM handling in remove function [ Upstream commit b493cd3c03641f9bbaa9787e43ca92163cb50051 ] pm_runtime_suspended() only checks the current runtime PM status and does not modify it, making it ineffective in this context. This could result in improper power management if the device remains active when removed. This patch fixes the issue by introducing a check with pm_runtime_status_suspended() to determine if the device is already suspended. If it is not, it calls imx334_power_off() to power down the device and then uses pm_runtime_set_suspended() to correctly update the runtime PM status to suspended. Signed-off-by: Tarang Raval Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 60b9aacd4d7c0410d40be7d54c3648aaaf61bf78 Author: Fangzhi Zuo Date: Thu Mar 20 13:58:24 2025 -0400 drm/amd/display: Do Not Consider DSC if Valid Config Not Found [ Upstream commit 146a4429b5674b7520a96aea34233949731c6086 ] [why] In the mode validation, mst dsc is considered for bw calculation after common dsc config is determined. Currently it considered common dsc config is found if max and min target bpp are non zero which is not accurate. Invalid max and min target bpp values would not get max_kbps and min_kbps calculated, leading to falsefully pass a mode that does not have valid dsc parameters available. [how] Use the return value of decide_dsc_bandwidth_range() to determine whether valid dsc common config is found or not. Prune out modes that do not have valid common dsc config determined. Reviewed-by: Wayne Lin Signed-off-by: Fangzhi Zuo Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 324a9d865ddbab9d38b6ef12c7d7532fee1badae Author: Akhil P Oommen Date: Sat Apr 19 20:21:31 2025 +0530 drm/msm/a6xx: Increase HFI response timeout [ Upstream commit 5f02f5e78ec9688e29b6857813185b1181796abe ] When ACD feature is enabled, it triggers some internal calibrations which result in a pretty long delay during the first HFI perf vote. So, increase the HFI response timeout to match the downstream driver. Signed-off-by: Akhil P Oommen Tested-by: Maya Matuszczyk Tested-by: Anthony Ruhier Patchwork: https://patchwork.freedesktop.org/patch/649344/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit a253c02451a623a71391cba31fda7676a575b600 Author: Alexander Aring Date: Tue Apr 29 16:29:11 2025 -0400 dlm: use SHUT_RDWR for SCTP shutdown [ Upstream commit 55612ddb62fc12437a7ff2f27b51a8981bc187a4 ] Currently SCTP shutdown() call gets stuck because there is no incoming EOF indicator on its socket. On the peer side the EOF indicator as recvmsg() returns 0 will be triggered as mechanism to flush the socket queue on the receive side. In SCTP recvmsg() function sctp_recvmsg() we can see that only if sk_shutdown has the bit RCV_SHUTDOWN set SCTP will recvmsg() will return EOF. The RCV_SHUTDOWN bit will only be set when shutdown with SHUT_RD is called. We use now SHUT_RDWR to also get a EOF indicator from recvmsg() call on the shutdown() initiator. SCTP does not support half closed sockets and the semantic of SHUT_WR is different here, it seems that calling SHUT_WR on sctp sockets keeps the socket open to have the possibility to do some specific SCTP operations on it that we don't do here. There exists still a difference in the limitations of TCP vs SCTP in case if we are required to have a half closed socket functionality. This was tried to archieve with DLM protocol changes in the past and hopefully we really don't require half closed socket functionality. Signed-off-by: Alexander Aring Tested-by: Heming zhao Reviewed-by: Heming zhao Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit b52f52bc5ba9feb026c0be600f8ac584fd12d187 Author: Lijo Lazar Date: Wed Mar 26 13:28:38 2025 +0530 drm/amdgpu: Add basic validation for RAS header [ Upstream commit 5df0d6addb7e9b6f71f7162d1253762a5be9138e ] If RAS header read from EEPROM is corrupted, it could result in trying to allocate huge memory for reading the records. Add some validation to header fields. Signed-off-by: Lijo Lazar Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 534494ed09a1586d20074d95d6b1dbff044edd36 Author: Paul Hsieh Date: Tue Mar 11 17:16:57 2025 +0800 drm/amd/display: Skip to enable dsc if it has been off [ Upstream commit 8b8a602c985e99074fa1d5233cd224b7bcfb9df2 ] [Why] It makes DSC enable when we commit the stream which need keep power off.And then it will skip to disable DSC if pipe reset at this situation as power has been off. It may cause the DSC unexpected enable on the pipe with the next new stream which doesn't support DSC. [HOW] Check the DSC used on current pipe status when update stream. Skip to enable if it has been off. The operation enable DSC should happen when set power on. Reviewed-by: Wenjing Liu Signed-off-by: Paul Hsieh Signed-off-by: Aurabindo Pillai Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 19a23df2cfac81ce1ea8d9eca91e3d77c15c0e39 Author: Nicolas Dufresne Date: Thu Apr 3 15:07:41 2025 -0400 media: verisilicon: Enable wide 4K in AV1 decoder [ Upstream commit 311e40e877bd980bc665e6c8d3b15d96f0ec2aa8 ] Tested on RK3588, this decoder is capable of handling WUHD, so bump the maximum width and height accordingly. Reviewed-by: Benjamin Gaignard Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e6a1fe50c1e63fb0dcedba58180c1ac5aae756b7 Author: Srinivasan Shanmugam Date: Fri Apr 18 00:57:19 2025 +0530 drm/amd/display: Add NULL pointer checks in dm_force_atomic_commit() [ Upstream commit 3f397cd203f247879c2f1a061e90d4c8d23655de ] This commit updates the dm_force_atomic_commit function to replace the usage of PTR_ERR_OR_ZERO with IS_ERR for checking error states after retrieving the Connector (drm_atomic_get_connector_state), CRTC (drm_atomic_get_crtc_state), and Plane (drm_atomic_get_plane_state) states. The function utilized PTR_ERR_OR_ZERO for error checking. However, this approach is inappropriate in this context because the respective functions do not return NULL; they return pointers that encode errors. This change ensures that error pointers are properly checked using IS_ERR before attempting to dereference. Cc: Harry Wentland Cc: Nicholas Kazlauskas Cc: Tom Chung Cc: Roman Li Cc: Alex Hung Cc: Aurabindo Pillai Signed-off-by: Srinivasan Shanmugam Reviewed-by: Aurabindo Pillai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8f2ae5107981235d65041b430614aa0d49111419 Author: Nas Chung Date: Thu Jul 25 15:10:34 2024 +0900 media: uapi: v4l: Fix V4L2_TYPE_IS_OUTPUT condition [ Upstream commit f81f69a0e3da141bdd73a16b8676f4e542533d87 ] V4L2_TYPE_IS_OUTPUT() returns true for V4L2_BUF_TYPE_VIDEO_OVERLAY which definitely belongs to CAPTURE. Signed-off-by: Nas Chung Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 7b7ebd35613a602c30714c09d35171b404cc1680 Author: Dmitry Baryshkov Date: Mon May 5 03:14:52 2025 +0300 drm/msm/hdmi: add runtime PM calls to DDC transfer function [ Upstream commit 531b4e2c206e5f7dead04d9da84dfa693ac57481 ] We must be sure that the HDMI controller is powered on, while performing the DDC transfer. Add corresponding runtime PM calls to msm_hdmi_i2c_xfer(). Reviewed-by: Jessica Zhang Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/651727/ Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-8-48541f76318c@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit b67373d1e146a47c69b036d550fa938732ad8c2b Author: Ben Skeggs Date: Wed Feb 5 03:12:51 2025 +1000 drm/nouveau/gsp: fix rm shutdown wait condition [ Upstream commit 7904bcdcf6b56602a049ed2b47282db63671fa99 ] Though the initial upstreamed GSP-RM version in nouveau was 535.113.01, the code was developed against earlier versions. 535.42.02 modified the mailbox value used by GSP-RM to signal shutdown has completed, which was missed at the time. I'm not aware of any issues caused by this, but noticed the bug while working on GB20x support. Signed-off-by: Ben Skeggs Reviewed-by: Dave Airlie Reviewed-by: Timur Tabi Tested-by: Timur Tabi Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit 8044f981b2cf8c32fe1bd5d1fc991552cdf7ffe0 Author: Mario Limonciello Date: Tue Jan 21 16:03:52 2025 -0600 drm/amd/display: Avoid divide by zero by initializing dummy pitch to 1 [ Upstream commit 7e40f64896e8e3dca471e287672db5ace12ea0be ] [Why] If the dummy values in `populate_dummy_dml_surface_cfg()` aren't updated then they can lead to a divide by zero in downstream callers like CalculateVMAndRowBytes() [How] Initialize dummy value to a value to avoid divide by zero. Reviewed-by: Alex Hung Signed-off-by: Mario Limonciello Signed-off-by: Zaeem Mohamed Tested-by: Mark Broadworth Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit aaf7b8ee685ae0d65d1ed28eac220917e88fe4c0 Author: Tarang Raval Date: Sat Mar 29 11:13:29 2025 +0530 media: i2c: imx334: Enable runtime PM before sub-device registration [ Upstream commit 01dfdf6a80c57151af0589af0db7adbbdd1361c7 ] Runtime PM is fully initialized before calling v4l2_async_register_subdev_sensor(). Moving the runtime PM initialization earlier prevents potential access to an uninitialized or powered-down device. Signed-off-by: Tarang Raval Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit d600b0c8c1b477ada310e0892789235b2e3a3b0a Author: Christoph Rudorff Date: Tue Mar 25 13:44:36 2025 +0100 drm/nouveau: fix hibernate on disabled GPU [ Upstream commit 4c4d9b7b6c6e676eca22585139aba5f03de74b90 ] Hibernate bricks the machine if a discrete GPU was disabled via echo IGD > /sys/kernel/debug/vgaswitcheroo/switch The freeze and thaw handler lacks checking the GPU power state, as suspend and resume do. This patch add the checks and fix this issue. Signed-off-by: Christoph Rudorff Signed-off-by: Lyude Paul Link: https://lore.kernel.org/r/20250325-nouveau-fix-hibernate-v2-1-2bd5c13fb953@rudorff.com Signed-off-by: Sasha Levin commit eef8c0f23673106628a3e9fd6e2626af9ac26e38 Author: Michael Chang Date: Tue Apr 8 13:48:39 2025 +0800 media: nuvoton: npcm-video: Fix stuck due to no video signal error [ Upstream commit 497f1fb94759fa0c638f15c12b1ab3e586bccfcb ] Fix the issue when start_frame and detect_resolution functions are executed at the same time, which may cause driver stops capturing due to status of no video signal error. Signed-off-by: Michael Chang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 36766c85989dac2dc089167edf10c5f938fa0450 Author: Alex Deucher Date: Wed Mar 19 11:58:19 2025 -0400 drm/amdgpu/gfx11: fix CSIB handling [ Upstream commit a9a8bccaa3ba64d509cf7df387cf0b5e1cd06499 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0ad9b5c83e25ca6abae38d47c0b9740ea15aa39f Author: Apurv Mishra Date: Mon Mar 17 14:00:38 2025 -0400 drm/amdkfd: Drop workaround for GC v9.4.3 revID 0 [ Upstream commit daafa303d19f5522e4c24fbf5c1c981a16df2c2f ] Remove workaround code for the early engineering samples GC v9.4.3 SOCs with revID 0 Reviewed-by: Amber Lin Signed-off-by: Apurv Mishra Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c53dc6f8e6ae8e95fc3376408e4c2ae464d57d13 Author: Yuezhang Mo Date: Thu Apr 10 17:26:14 2025 -0600 exfat: do not clear volume dirty flag during sync [ Upstream commit 46a557694b464881b3c2c4a0ba389a6436419a37 ] xfstests generic/482 tests the file system consistency after each FUA operation. It fails when run on exfat. exFAT clears the volume dirty flag with a FUA operation during sync. Since s_lock is not held when data is being written to a file, sync can be executed at the same time. When data is being written to a file, the FAT chain is updated first, and then the file size is updated. If sync is executed between updating them, the length of the FAT chain may be inconsistent with the file size. To avoid the situation where the file system is inconsistent but the volume dirty flag is cleared, this commit moves the clearing of the volume dirty flag from exfat_fs_sync() to exfat_put_super(), so that the volume dirty flag is not cleared until unmounting. After the move, there is no additional action during sync, so exfat_fs_sync() can be deleted. Reviewed-by: Sungjong Seo Signed-off-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 8ade2fb722b554ce5d209972e9301de753000dfb Author: Ayushi Makhija Date: Mon May 5 15:12:45 2025 +0530 drm/bridge: anx7625: change the gpiod_set_value API [ Upstream commit 50935044e58e563cdcfd556d62f27bc8744dd64e ] Use gpiod_set_value_cansleep() instead of gpiod_set_value() to fix the below call trace in the boot log: [ 5.690534] Call trace: [ 5.690536] gpiod_set_value+0x40/0xa4 [ 5.690540] anx7625_runtime_pm_resume+0xa0/0x324 [anx7625] [ 5.690545] __rpm_callback+0x48/0x1d8 [ 5.690549] rpm_callback+0x6c/0x78 Certain GPIO controllers require access via message-based buses such as I2C or SPI, which may cause the GPIOs to enter a sleep state. Therefore, use the gpiod_set_value_cansleep(). Signed-off-by: Ayushi Makhija Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250505094245.2660750-7-quic_amakhija@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 8d33b60f877c1b02491a2819e85a081b1c9a6026 Author: Boris Brezillon Date: Fri Apr 4 10:09:33 2025 +0200 drm/panthor: Don't update MMU_INT_MASK in panthor_mmu_irq_handler() [ Upstream commit 6c4a3fa26799785c1873aacabcfd9b2d27e8dc97 ] Interrupts are automatically unmasked in panthor_mmu_irq_threaded_handler() when the handler returns. Unmasking prematurely might generate spurious interrupts if the IRQ line is shared. Changes in v2: - New patch Changes in v3: - Add R-bs Reviewed-by: Liviu Dudau Reviewed-by: Steven Price Link: https://lore.kernel.org/r/20250404080933.2912674-6-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 62d2437f8161f30935cc1dd90a966a651ee079a0 Author: Ayushi Makhija Date: Mon May 5 15:12:42 2025 +0530 drm/bridge: anx7625: enable HPD interrupts [ Upstream commit ca8a78cdceb48ad3b753f836068611265840ef22 ] When the device enters the suspend state, it prevents HPD interrupts from occurring. To address this, implement .hpd_enable() and .hpd_disable() callbacks functions of the drm_bridge. Signed-off-by: Ayushi Makhija Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250505094245.2660750-4-quic_amakhija@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit d3cef0e7a5c1aa6217c51faa9ce8ecac35d6e1fd Author: Namjae Jeon Date: Tue Apr 1 13:50:39 2025 +0900 exfat: fix double free in delayed_free [ Upstream commit 1f3d9724e16d62c7d42c67d6613b8512f2887c22 ] The double free could happen in the following path. exfat_create_upcase_table() exfat_create_upcase_table() : return error exfat_free_upcase_table() : free ->vol_utbl exfat_load_default_upcase_table : return error exfat_kill_sb() delayed_free() exfat_free_upcase_table() <--------- double free This patch set ->vol_util as NULL after freeing it. Reported-by: Jianzhou Zhao Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit fe50bf7759e5eb4cc7141ac2c9c0c21585f2bb9e Author: Anusha Srivatsa Date: Wed Mar 26 23:29:19 2025 -0400 drm/panel/sharp-ls043t1le01: Use _multi variants [ Upstream commit 20e8219205145e1af3b98b6a0a3cc59568116a05 ] Move away from using deprecated API and use _multi variants if available. Use mipi_dsi_msleep() and mipi_dsi_usleep_range() instead of msleep() and usleep_range() respectively. Used Coccinelle to find the _multi variant APIs,replacing mpi_dsi_msleep() where necessary and for returning dsi_ctx.accum_err in these functions. mipi_dsi_dcs_write() does not have a corresponding _multi() variant. Replacing it with mipi_dsi_dcs_write_seq_multi() instead. This change is manual. The Coccinelle script is the same as the one in commit c8ba07caaecc ("drm/panel/synaptics-r63353: Use _multi variants") v2: Use mipi_dsi_write_buffer_multi() in place of mipi_dsi_dcs_write(). (Dmitry) v3: add commit details where the same coccinelle script is used and remove the actual script from commit log. Use mipi_dsi_dcs_write_seq_multi() for mipi_dsi_dcs_write() (Doug) Cc: Maxime Ripard Cc: Dmitry Baryshkov Cc: Tejas Vipin Cc: Doug Anderson Signed-off-by: Anusha Srivatsa Reviewed-by: Neil Armstrong Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20250326-b4-panel-ls043t1le01-v3-1-96c554c0ea2b@redhat.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit e363595fa10d27dcbf427c4db383b911ed1f3498 Author: Jiayuan Chen Date: Thu Apr 24 00:17:42 2025 +0800 workqueue: Fix race condition in wq->stats incrementation [ Upstream commit 70e1683ca3a6474360af1d3a020a9a98c8492cc0 ] Fixed a race condition in incrementing wq->stats[PWQ_STAT_COMPLETED] by moving the operation under pool->lock. Reported-by: syzbot+01affb1491750534256d@syzkaller.appspotmail.com Signed-off-by: Jiayuan Chen Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 8285c8ac23c01ec4496c641e2ff026f382f86c6f Author: Damon Ding Date: Mon Mar 10 18:41:02 2025 +0800 drm/bridge: analogix_dp: Add irq flag IRQF_NO_AUTOEN instead of calling disable_irq() [ Upstream commit efab13e7d13a641a22c7508cde6e1a5285161944 ] The IRQF_NO_AUTOEN can be used for the drivers that don't want interrupts to be enabled automatically via devm_request_threaded_irq(). Using this flag can provide be more robust compared to the way of calling disable_irq() after devm_request_threaded_irq() without the IRQF_NO_AUTOEN flag. Suggested-by: Douglas Anderson Reviewed-by: Douglas Anderson Signed-off-by: Damon Ding Link: https://lore.kernel.org/r/20250310104114.2608063-2-damon.ding@rock-chips.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit dcdd8a5ce3e56d9625f233ac7b87d9b18edcf02f Author: Jeevaka Prabu Badrappan Date: Tue Apr 22 17:18:52 2025 +0000 drm/xe: Fix CFI violation when accessing sysfs files [ Upstream commit 4ea512714c42c69828b4a2647d206bf404043ad5 ] When an attribute group is created with sysfs_create_group() or sysfs_create_files() the ->sysfs_ops() callback is set to kobj_sysfs_ops, which sets the ->show() callback to kobj_attr_show(). kobj_attr_show() uses container_of() to get the ->show() callback from the attribute it was passed, meaning the ->show() callback needs to be the same type as the ->show() callback in 'struct kobj_attribute'. However, cur_freq_show() has the type of the ->show() callback in 'struct device_attribute', which causes a CFI violation when opening the 'id' sysfs node under gtidle/freq/throttle. This happens to work because the layout of 'struct kobj_attribute' and 'struct device_attribute' are the same, so the container_of() cast happens to allow the ->show() callback to still work. Changed the type of cur_freq_show() and few more functions to match the ->show() callback in 'struct kobj_attributes' to resolve the CFI violation. CFI failure seen while accessing sysfs files under /sys/class/drm/card0/device/tile0/gt*/gtidle/* /sys/class/drm/card0/device/tile0/gt*/freq0/* /sys/class/drm/card0/device/tile0/gt*/freq0/throttle/* [ 2599.618075] RIP: 0010:__cfi_cur_freq_show+0xd/0x10 [xe] [ 2599.624452] Code: 44 c1 44 89 fa e8 03 95 39 f2 48 98 5b 41 5e 41 5f 5d c3 c9 [ 2599.646638] RSP: 0018:ffffbe438ead7d10 EFLAGS: 00010286 [ 2599.652823] RAX: ffff9f7d8b3845d8 RBX: ffff9f7dee8c95d8 RCX: 0000000000000000 [ 2599.661246] RDX: ffff9f7e6f439000 RSI: ffffffffc13ada30 RDI: ffff9f7d975d4b00 [ 2599.669669] RBP: ffffbe438ead7d18 R08: 0000000000001000 R09: ffff9f7e6f439000 [ 2599.678092] R10: 00000000e07304a6 R11: ffffffffc1241ca0 R12: ffffffffb4836ea0 [ 2599.688435] R13: ffff9f7e45fb1180 R14: ffff9f7d975d4b00 R15: ffff9f7e6f439000 [ 2599.696860] FS: 000076b02b66cfc0(0000) GS:ffff9f80ef400000(0000) knlGS:00000 [ 2599.706412] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2599.713196] CR2: 00005f80d94641a9 CR3: 00000001e44ec006 CR4: 0000000100f72ef0 [ 2599.721618] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2599.730041] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 [ 2599.738464] PKRU: 55555554 [ 2599.741655] Call Trace: [ 2599.744541] [ 2599.747017] ? __die_body+0x69/0xb0 [ 2599.751151] ? die+0xa9/0xd0 [ 2599.754548] ? do_trap+0x89/0x160 [ 2599.758476] ? __cfi_cur_freq_show+0xd/0x10 [xe b37985c94829727668bd7c5b33c1] [ 2599.768315] ? handle_invalid_op+0x69/0x90 [ 2599.773167] ? __cfi_cur_freq_show+0xd/0x10 [xe b37985c94829727668bd7c5b33c1] [ 2599.783010] ? exc_invalid_op+0x36/0x60 [ 2599.787552] ? fred_hwexc+0x123/0x1a0 [ 2599.791873] ? fred_entry_from_kernel+0x7b/0xd0 [ 2599.797219] ? asm_fred_entrypoint_kernel+0x45/0x70 [ 2599.802976] ? act_freq_show+0x70/0x70 [xe b37985c94829727668bd7c5b33c1d9998] [ 2599.812301] ? __cfi_cur_freq_show+0xd/0x10 [xe b37985c94829727668bd7c5b33c1] [ 2599.822137] ? __kmalloc_node_noprof+0x1f3/0x420 [ 2599.827594] ? __kvmalloc_node_noprof+0xcb/0x180 [ 2599.833045] ? kobj_attr_show+0x22/0x40 [ 2599.837571] sysfs_kf_seq_show+0xa8/0x110 [ 2599.842302] kernfs_seq_show+0x38/0x50 Signed-off-by: Jeevaka Prabu Badrappan Reviewed-by: Rodrigo Vivi Link: https://lore.kernel.org/r/20250422171852.85558-1-jeevaka.badrappan@intel.com Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 4d2e6491fef4e6a1fc09f89d1ff692278dca7605 Author: Yihan Zhu Date: Mon Mar 31 15:59:51 2025 -0400 drm/amd/display: DCN32 null data check [ Upstream commit c9646e5a7e01c3ede286ec5edd4fcb2e1e80261d ] [WHY & HOW] Avoid null curve data structure used in the cm block for the potential issue. Reviewed-by: Charlene Liu Signed-off-by: Yihan Zhu Signed-off-by: Zaeem Mohamed Tested-by: Mark Broadworth Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f5dfaffa48958d6fd8a329b874a1b2e337dac773 Author: Jesse.Zhang Date: Mon Apr 28 10:35:19 2025 +0800 drm/amdgpu: Fix API status offset for MES queue reset [ Upstream commit ad7c088e31f026d71fe87fd09473fafb7d6ed006 ] The mes_v11_0_reset_hw_queue and mes_v12_0_reset_hw_queue functions were using the wrong union type (MESAPI__REMOVE_QUEUE) when getting the offset for api_status. Since these functions handle queue reset operations, they should use MESAPI__RESET union instead. This fixes the polling of API status during hardware queue reset operations in the MES for both v11 and v12 versions. Signed-off-by: Jesse Zhang Reviewed-By: Shaoyun.liu Reviewed-by: Prike Liang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 48e8730027695f9c829bc575da3de2a2fbcd6bba Author: Long Li Date: Sat Mar 1 14:48:35 2025 +0800 sunrpc: update nextcheck time when adding new cache entries [ Upstream commit 5ca00634c8bbb2979c73465588f486b9632f5ed5 ] The cache_detail structure uses a "nextcheck" field to control hash table scanning intervals. When a table scan begins, nextcheck is set to current time plus 1800 seconds. During scanning, if cache_detail is not empty and a cache entry's expiry time is earlier than the current nextcheck, the nextcheck is updated to that expiry time. This mechanism ensures that: 1) Empty cache_details are scanned every 1800 seconds to avoid unnecessary scans 2) Non-empty cache_details are scanned based on the earliest expiry time found However, when adding a new cache entry to an empty cache_detail, the nextcheck time was not being updated, remaining at 1800 seconds. This could delay cache cleanup for up to 1800 seconds, potentially blocking threads(such as nfsd) that are waiting for cache cleanup. Fix this by updating the nextcheck time whenever a new cache entry is added. Signed-off-by: Long Li Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 4799fc81d42e0651a444ced59036a06418609785 Author: Dave Airlie Date: Tue Mar 4 01:56:03 2025 +1000 drm/dp: add option to disable zero sized address only transactions. [ Upstream commit f0ddbb1eed1898286d2bd99fd6ab64ca9700d267 ] Some older NVIDIA and some newer NVIDIA hardware/firmware seems to have issues with address only transactions (firmware rejects them). Add an option to the core drm dp to avoid address only transactions, This just puts the MOT flag removal on the last message of the transfer and avoids the start of transfer transaction. This with the flag set in nouveau, allows eDP probing on GB203 device. Signed-off-by: Dave Airlie Reviewed-by: Ben Skeggs Reviewed-by: Timur Tabi Tested-by: Timur Tabi Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit 1d1fae3105ec6a683f0e69cc320aea0b190f2433 Author: Andy Yan Date: Tue Apr 22 15:04:43 2025 +0800 drm/rockchip: inno-hdmi: Fix video timing HSYNC/VSYNC polarity setting for rk3036 [ Upstream commit ad10b82c2bcac7f87ac6eaecfca33378b43425ee ] The HSYNC/VSYNC polarity of rk3036 HDMI are controlled by GRF. Without the polarity configuration in GRF, it can be observed from the HDMI protocol analyzer that the H/V front/back timing output by RK3036 HDMI are currently not in line with the specifications. Signed-off-by: Andy Yan Tested-by: Heiko Stuebner #rk3036-kylin Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20250422070455.432666-5-andyshrk@163.com Signed-off-by: Sasha Levin commit 3cbbe38aa32e9a4597f0dd16d2a1c613cc9db4be Author: Ming Qian Date: Mon Apr 21 16:12:56 2025 +0800 media: imx-jpeg: Check decoding is ongoing for motion-jpeg [ Upstream commit fd5b6cd730676940df63b0970bb1ba30bca1aac3 ] As the first frame in "repeat-mode" is the pattern, the pattern done interrupt is ignored by the driver. With small resolution bitstreams, the interrupts might fire too quickly and hardware combine two irqs to once because irq handle have latency. Thus the driver might miss the frame decode done interrupt from the first actual frame. In order to avoid the driver wait for the frame done interrupt that has been combined to the pattern done interrupt and been ignored, driver will check the curr_desc and slot_status registers to figure out if the decoding of actual frame is finished or not. Firstly we check the curr_desc register, - if it is still pointing to the pattern descriptor, the second actual frame is not started, we can wait for its frame-done interrupt. - if the curr_desc has pointed to the frame descriptor, then we check the ongoing bit of slot_status register. - if the ongoing bit is set to 1, the decoding of the actual frame is not finished, we can wait for its frame-done interrupt. - if the ongoing bit is set to 0, the decoding of the actual frame is finished, we can't wait for the second interrupt, but mark it as done. But there is still a small problem, that the curr_desc and slot_status registers are not synchronous. curr_desc is updated when the next_descpt_ptr is loaded, but the ongoing bit of slot_status is set after the 32 bytes descriptor is loaded, there will be a short time interval in between, which may cause fake false. Consider read register is quite slow compared with IP read 32byte from memory, read twice slot_status can avoid this situation. Signed-off-by: Ming Qian Reviewed-by: Frank Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit df489405e10159fada63e51fdb779d93a29547c1 Author: Alex Deucher Date: Wed Mar 19 11:56:02 2025 -0400 drm/amdgpu/gfx6: fix CSIB handling [ Upstream commit 8307ebc15c1ea98a8a0b7837af1faa6c01514577 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a1438cfccb26680fb521ac3db917022997ce2929 Author: Dmitry Baryshkov Date: Fri Apr 11 18:09:40 2025 +0300 drm/bridge: select DRM_KMS_HELPER for AUX_BRIDGE [ Upstream commit b12fa5e76e1463fc5a196f2717040e4564e184b6 ] The aux bridge uses devm_drm_of_get_bridge() from the panel bridge (and correctly selects DRM_PANEL_BRIDGE). However panel bridge is not a separate module, it is compiled into the drm_kms_helper.o. Select DRM_KMS_HELPER too to express this dependency. Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20250411-aux-select-kms-v1-1-c4276f905a56@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit ab215bcd0251ca4f7782366fa2b1a1b9fc97dd1e Author: Charlene Liu Date: Tue Apr 15 21:29:17 2025 -0400 drm/amd/display: disable DPP RCG before DPP CLK enable [ Upstream commit 1bcd679209420305a86833bc357d50021909edaf ] [why] DPP CLK enable needs to disable DPPCLK RCG first. The DPPCLK_en in dccg should always be enabled when the corresponding pipe is enabled. Reviewed-by: Hansen Dsouza Signed-off-by: Charlene Liu Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2a51edd0ac8a137fbafa17f6feef85f4d7cd42c8 Author: Peter Marheine Date: Thu May 8 12:41:45 2025 +1000 ACPI: battery: negate current when discharging [ Upstream commit 234f71555019d308c6bc6f98c78c5551cb8cd56a ] The ACPI specification requires that battery rate is always positive, but the kernel ABI for POWER_SUPPLY_PROP_CURRENT_NOW (Documentation/ABI/testing/sysfs-class-power) specifies that it should be negative when a battery is discharging. When reporting CURRENT_NOW, massage the value to match the documented ABI. This only changes the sign of `current_now` and not `power_now` because documentation doesn't describe any particular meaning for `power_now` so leaving `power_now` unchanged is less likely to confuse userspace unnecessarily, whereas becoming consistent with the documented ABI is worth potentially confusing clients that read `current_now`. Signed-off-by: Peter Marheine Link: https://patch.msgid.link/20250508024146.1436129-1-pmarheine@chromium.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 919e82f6fbbd764dbb09e3cc5e8da0363d0b4c7f Author: Svyatoslav Ryhel Date: Wed Apr 30 09:02:39 2025 +0300 power: supply: max17040: adjust thermal channel scaling [ Upstream commit d055f51731744243b244aafb1720f793a5b61f7b ] IIO thermal channel is in millidegree while power supply framework expects decidegree values. Adjust scaling to get correct readings. Signed-off-by: Svyatoslav Ryhel Link: https://lore.kernel.org/r/20250430060239.12085-2-clamor95@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 0bd887636e7642664905bae2a7fdd5092e69310e Author: Charan Teja Kalla Date: Thu May 15 12:11:25 2025 +0530 PM: runtime: fix denying of auto suspend in pm_suspend_timer_fn() [ Upstream commit 40d3b40dce375d6f1c1dbf08d79eed3aed6c691d ] pm_runtime_put_autosuspend() schedules a hrtimer to expire at "dev->power.timer_expires". If the hrtimer's callback, pm_suspend_timer_fn(), observes that the current time equals "dev->power.timer_expires", it unexpectedly bails out instead of proceeding with runtime suspend. pm_suspend_timer_fn(): if (expires > 0 && expires < ktime_get_mono_fast_ns()) { dev->power.timer_expires = 0; rpm_suspend(..) } Additionally, as ->timer_expires is not cleared, all the future auto suspend requests will not schedule hrtimer to perform auto suspend. rpm_suspend(): if ((rpmflags & RPM_AUTO) &&...) { if (!(dev->power.timer_expires && ...) { <-- this will fail. hrtimer_start_range_ns(&dev->power.suspend_timer,...); } } Fix this by as well checking if current time reaches the set expiration. Co-developed-by: Patrick Daly Signed-off-by: Patrick Daly Signed-off-by: Charan Teja Kalla Link: https://patch.msgid.link/20250515064125.1211561-1-quic_charante@quicinc.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f2891af7141a399ee9d5415e05a3616adec20719 Author: Peng Fan Date: Thu Mar 27 08:49:44 2025 +0800 gpiolib: of: Add polarity quirk for s5m8767 [ Upstream commit 4e310626eb4df52a31a142c1360fead0fcbd3793 ] This is prepare patch for switching s5m8767 regulator driver to use GPIO descriptor. DTS for exynos5250 spring incorrectly specifies "active low" polarity for the DVS and DS line. But per datasheet, they are actually active high. So add polarity quirk for it. Signed-off-by: Peng Fan Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20250327004945.563765-1-peng.fan@oss.nxp.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit feaebd0e0a31a590d8a7ec3962e5f5de32eb7ba7 Author: Linus Torvalds Date: Tue May 27 14:35:51 2025 -0700 Make 'cc-option' work correctly for the -Wno-xyzzy pattern [ Upstream commit 550ccb178de2f379f5e1a1833dd6f4bdafef4b68 ] This is the follow-up to commit a79be02bba5c ("Fix mis-uses of 'cc-option' for warning disablement") where I mentioned that the best fix would be to just make 'cc-option' a bit smarter, and work for all compiler options, including the '-Wno-xyzzy' pattern that it used to accept unknown options for. It turns out that fixing cc-option is pretty straightforward: just rewrite any '-Wno-xyzzy' option pattern to use '-Wxyzzy' instead for testing. That makes the whole artificial distinction between 'cc-option' and 'cc-disable-warning' go away, and we can happily forget about the odd build rule that you have to treat compiler options that disable warnings specially. The 'cc-disable-warning' helper remains as a backwards compatibility syntax for now, but is implemented in terms of the new and improved cc-option. Acked-by: Masahiro Yamada Cc: Greg Kroah-Hartman Cc: Arnd Bergmann Cc: Stephen Rothwell Cc: Thomas Weißschuh Cc: Nathan Chancellor Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 3bca3137b2f7d2e246ba65f0a2ad28b51a0b5684 Author: Yuanjun Gong Date: Tue May 13 20:37:44 2025 +0800 ASoC: tegra210_ahub: Add check to of_device_get_match_data() [ Upstream commit 04cb269c204398763a620d426cbee43064854000 ] In tegra_ahub_probe(), check the result of function of_device_get_match_data(), return an error code in case it fails. Signed-off-by: Yuanjun Gong Link: https://patch.msgid.link/20250513123744.3041724-1-ruc_gongyuanjun@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 288e81a72e157f0a7e31c1f0e47ffd5ce7288f90 Author: Frank Li Date: Mon Apr 14 14:30:55 2025 -0400 platform-msi: Add msi_remove_device_irq_domain() in platform_device_msi_free_irqs_all() [ Upstream commit 9a958e1fd40d6fae8c66385687a00ebd9575a7d2 ] platform_device_msi_init_and_alloc_irqs() performs two tasks: allocating the MSI domain for a platform device, and allocate a number of MSIs in that domain. platform_device_msi_free_irqs_all() only frees the MSIs, and leaves the MSI domain alive. Given that platform_device_msi_init_and_alloc_irqs() is the sole tool a platform device has to allocate platform MSIs, it makes sense for platform_device_msi_free_irqs_all() to teardown the MSI domain at the same time as the MSIs. This avoids warnings and unexpected behaviours when a driver repeatedly allocates and frees MSIs. Signed-off-by: Frank Li Signed-off-by: Thomas Gleixner Acked-by: Marc Zyngier Link: https://lore.kernel.org/all/20250414-ep-msi-v18-1-f69b49917464@nxp.com Signed-off-by: Sasha Levin commit 93e1ffd22c585405c56bf31996ba373c4d702773 Author: gldrk Date: Fri Apr 25 21:21:52 2025 +0200 ACPICA: utilities: Fix overflow check in vsnprintf() [ Upstream commit 12b660251007e00a3e4d47ec62dbe3a7ace7023e ] ACPICA commit d9d59b7918514ae55063b93f3ec041b1a569bf49 The old version breaks sprintf on 64-bit systems for buffers outside [0..UINT32_MAX]. Link: https://github.com/acpica/acpica/commit/d9d59b79 Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/4994935.GXAFRqVoOG@rjwysocki.net Signed-off-by: gldrk [ rjw: Added the tag from gldrk ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit bd0b9422a423f13e8f3e3b417ecbd02315bfefeb Author: Ulf Hansson Date: Wed Apr 2 14:06:13 2025 +0200 pmdomain: core: Reset genpd->states to avoid freeing invalid data [ Upstream commit 99012014c902cd9ad85fd288d8a107f33a69855e ] If genpd_alloc_data() allocates data for the default power-states for the genpd, let's make sure to also reset the pointer in the error path. This makes sure a genpd provider driver doesn't end up trying to free the data again, but using an invalid pointer. Signed-off-by: Ulf Hansson Reviewed-by: Dhruva Gole Link: https://lore.kernel.org/r/20250402120613.1116711-1-ulf.hansson@linaro.org Signed-off-by: Sasha Levin commit b2d5993bb1f9f5e9f1627e99697d26eb3167365c Author: Kuninori Morimoto Date: Mon Apr 14 00:45:59 2025 +0000 ASoC: simple-card-utils: fixup dlc->xxx handling for error case [ Upstream commit 2b4ce994afca0690ab79b7860045e6883e8706db ] Current graph_util_parse_dai() has 2 issue for dlc->xxx handling. 1) dlc->xxx might be filled if snd_soc_get_dai_via_args() (A) works. In such case it will fill dlc->xxx first (B), and detect error after that (C). We need to fill dlc->xxx in success case only. (A) dai = snd_soc_get_dai_via_args(&args); if (dai) { ret = -ENOMEM; ^ dlc->of_node = ... (B) dlc->dai_name = ... v dlc->dai_args = ... (C) if (!dlc->dai_args) goto end; ... } 2) graph_util_parse_dai() itself has 2 patterns (X)(Y) to fill dlc->xxx. Both case, we need to call of_node_put(node) (Z) in error case, but we are calling it only in (Y) case. int graph_util_parse_dai(...) { ... dai = snd_soc_get_dai_via_args(&args); if (dai) { ... ^ dlc->of_node = ... (X) dlc->dai_name = ... v dlc->dai_args = ... ... } ... (Y) ret = snd_soc_get_dlc(&args, dlc); if (ret < 0) { (Z) of_node_put(node); ... } ... } This patch fixup both case. Make it easy to understand, update lavel "end" to "err", too. Signed-off-by: Kuninori Morimoto Link: https://patch.msgid.link/87fribr2ns.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b6c32e67ea54588d3718b3eb62c216dd009ad529 Author: Jerry Lv Date: Tue Apr 15 11:40:47 2025 +0800 power: supply: bq27xxx: Retrieve again when busy [ Upstream commit f16d9fb6cf03fdbdefa41a8b32ba1e57afb7ae3d ] Multiple applications may access the battery gauge at the same time, so the gauge may be busy and EBUSY will be returned. The driver will set a flag to record the EBUSY state, and this flag will be kept until the next periodic update. When this flag is set, bq27xxx_battery_get_property() will just return ENODEV until the flag is updated. Even if the gauge was busy during the last accessing attempt, returning ENODEV is not ideal, and can cause confusion in the applications layer. Instead, retry accessing the I2C to update the flag is as expected, for the gauge typically recovers from busy state within a few milliseconds. If still failed to access the gauge, the real error code would be returned instead of ENODEV (as suggested by Pali Rohár). Reviewed-by: Pali Rohár Signed-off-by: Jerry Lv Link: https://lore.kernel.org/r/20250415-foo-fix-v2-1-5b45a395e4cc@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit eeb464f4d3ae9b042ff5ea912ea31ca828e8fc38 Author: Stefan Binding Date: Thu May 15 17:28:33 2025 +0100 ALSA: hda: cs35l41: Fix swapped l/r audio channels for Acer Helios laptops [ Upstream commit e43a93c41982e82c1b703dd7fa9c1d965260fbb3 ] Fixes audio channel assignment from ACPI using configuration table. Signed-off-by: Stefan Binding Link: https://patch.msgid.link/20250515162848.405055-3-sbinding@opensource.cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8016f89f995e525eea78493e85e5391dcb45eb2e Author: Tamir Duberstein Date: Fri Apr 25 21:21:05 2025 +0200 ACPICA: Apply pack(1) to union aml_resource [ Upstream commit eedf3e3c2f2af55dca42b0ea81dffb808211d269 ] ACPICA commit 1c28da2242783579d59767617121035dafba18c3 This was originally done in NetBSD: https://github.com/NetBSD/src/commit/b69d1ac3f7702f67edfe412e4392f77d09804910 and is the correct alternative to the smattering of `memcpy`s I previously contributed to this repository. This also sidesteps the newly strict checks added in UBSAN: https://github.com/llvm/llvm-project/commit/792674400f6f04a074a3827349ed0e2ac10067f6 Before this change we see the following UBSAN stack trace in Fuchsia: #0 0x000021afcfdeca5e in acpi_rs_get_address_common(struct acpi_resource*, union aml_resource*) ../../third_party/acpica/source/components/resources/rsaddr.c:329 +0x6aca5e #1.2 0x000021982bc4af3c in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 +0x41f3c #1.1 0x000021982bc4af3c in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 +0x41f3c #1 0x000021982bc4af3c in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:395 +0x41f3c #2 0x000021982bc4bb6f in handletype_mismatch_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:137 +0x42b6f #3 0x000021982bc4b723 in __ubsan_handle_type_mismatch_v1 compiler-rt/lib/ubsan/ubsan_handlers.cpp:142 +0x42723 #4 0x000021afcfdeca5e in acpi_rs_get_address_common(struct acpi_resource*, union aml_resource*) ../../third_party/acpica/source/components/resources/rsaddr.c:329 +0x6aca5e #5 0x000021afcfdf2089 in acpi_rs_convert_aml_to_resource(struct acpi_resource*, union aml_resource*, struct acpi_rsconvert_info*) ../../third_party/acpica/source/components/resources/rsmisc.c:355 +0x6b2089 #6 0x000021afcfded169 in acpi_rs_convert_aml_to_resources(u8*, u32, u32, u8, void**) ../../third_party/acpica/source/components/resources/rslist.c:137 +0x6ad169 #7 0x000021afcfe2d24a in acpi_ut_walk_aml_resources(struct acpi_walk_state*, u8*, acpi_size, acpi_walk_aml_callback, void**) ../../third_party/acpica/source/components/utilities/utresrc.c:237 +0x6ed24a #8 0x000021afcfde66b7 in acpi_rs_create_resource_list(union acpi_operand_object*, struct acpi_buffer*) ../../third_party/acpica/source/components/resources/rscreate.c:199 +0x6a66b7 #9 0x000021afcfdf6979 in acpi_rs_get_method_data(acpi_handle, const char*, struct acpi_buffer*) ../../third_party/acpica/source/components/resources/rsutils.c:770 +0x6b6979 #10 0x000021afcfdf708f in acpi_walk_resources(acpi_handle, char*, acpi_walk_resource_callback, void*) ../../third_party/acpica/source/components/resources/rsxface.c:731 +0x6b708f #11 0x000021afcfa95dcf in acpi::acpi_impl::walk_resources(acpi::acpi_impl*, acpi_handle, const char*, acpi::Acpi::resources_callable) ../../src/devices/board/lib/acpi/acpi-impl.cc:41 +0x355dcf #12 0x000021afcfaa8278 in acpi::device_builder::gather_resources(acpi::device_builder*, acpi::Acpi*, fidl::any_arena&, acpi::Manager*, acpi::device_builder::gather_resources_callback) ../../src/devices/board/lib/acpi/device-builder.cc:84 +0x368278 #13 0x000021afcfbddb87 in acpi::Manager::configure_discovered_devices(acpi::Manager*) ../../src/devices/board/lib/acpi/manager.cc:75 +0x49db87 #14 0x000021afcf99091d in publish_acpi_devices(acpi::Manager*, zx_device_t*, zx_device_t*) ../../src/devices/board/drivers/x86/acpi-nswalk.cc:95 +0x25091d #15 0x000021afcf9c1d4e in x86::X86::do_init(x86::X86*) ../../src/devices/board/drivers/x86/x86.cc:60 +0x281d4e #16 0x000021afcf9e33ad in λ(x86::X86::ddk_init::(anon class)*) ../../src/devices/board/drivers/x86/x86.cc:77 +0x2a33ad #17 0x000021afcf9e313e in fit::internal::target<(lambda at../../src/devices/board/drivers/x86/x86.cc:76:19), false, false, std::__2::allocator, void>::invoke(void*) ../../sdk/lib/fit/include/lib/fit/internal/function.h:183 +0x2a313e #18 0x000021afcfbab4c7 in fit::internal::function_base<16UL, false, void(), std::__2::allocator>::invoke(const fit::internal::function_base<16UL, false, void (), std::__2::allocator >*) ../../sdk/lib/fit/include/lib/fit/internal/function.h:522 +0x46b4c7 #19 0x000021afcfbab342 in fit::function_impl<16UL, false, void(), std::__2::allocator>::operator()(const fit::function_impl<16UL, false, void (), std::__2::allocator >*) ../../sdk/lib/fit/include/lib/fit/function.h:315 +0x46b342 #20 0x000021afcfcd98c3 in async::internal::retained_task::Handler(async_dispatcher_t*, async_task_t*, zx_status_t) ../../sdk/lib/async/task.cc:24 +0x5998c3 #21 0x00002290f9924616 in λ(const driver_runtime::Dispatcher::post_task::(anon class)*, std::__2::unique_ptr >, zx_status_t) ../../src/devices/bin/driver_runtime/dispatcher.cc:789 +0x10a616 #22 0x00002290f9924323 in fit::internal::target<(lambda at../../src/devices/bin/driver_runtime/dispatcher.cc:788:7), true, false, std::__2::allocator, void, std::__2::unique_ptr>, int>::invoke(void*, std::__2::unique_ptr >, int) ../../sdk/lib/fit/include/lib/fit/internal/function.h:128 +0x10a323 #23 0x00002290f9904b76 in fit::internal::function_base<24UL, true, void(std::__2::unique_ptr>, int), std::__2::allocator>::invoke(const fit::internal::function_base<24UL, true, void (std::__2::unique_ptr >, int), std::__2::allocator >*, std::__2::unique_ptr >, int) ../../sdk/lib/fit/include/lib/fit/internal/function.h:522 +0xeab76 #24 0x00002290f9904831 in fit::callback_impl<24UL, true, void(std::__2::unique_ptr>, int), std::__2::allocator>::operator()(fit::callback_impl<24UL, true, void (std::__2::unique_ptr >, int), std::__2::allocator >*, std::__2::unique_ptr >, int) ../../sdk/lib/fit/include/lib/fit/function.h:471 +0xea831 #25 0x00002290f98d5adc in driver_runtime::callback_request::Call(driver_runtime::callback_request*, std::__2::unique_ptr >, zx_status_t) ../../src/devices/bin/driver_runtime/callback_request.h:74 +0xbbadc #26 0x00002290f98e1e58 in driver_runtime::Dispatcher::dispatch_callback(driver_runtime::Dispatcher*, std::__2::unique_ptr >) ../../src/devices/bin/driver_runtime/dispatcher.cc:1248 +0xc7e58 #27 0x00002290f98e4159 in driver_runtime::Dispatcher::dispatch_callbacks(driver_runtime::Dispatcher*, std::__2::unique_ptr >, fbl::ref_ptr) ../../src/devices/bin/driver_runtime/dispatcher.cc:1308 +0xca159 #28 0x00002290f9918414 in λ(const driver_runtime::Dispatcher::create_with_adder::(anon class)*, std::__2::unique_ptr >, fbl::ref_ptr) ../../src/devices/bin/driver_runtime/dispatcher.cc:353 +0xfe414 #29 0x00002290f991812d in fit::internal::target<(lambda at../../src/devices/bin/driver_runtime/dispatcher.cc:351:7), true, false, std::__2::allocator, void, std::__2::unique_ptr>, fbl::ref_ptr>::invoke(void*, std::__2::unique_ptr >, fbl::ref_ptr) ../../sdk/lib/fit/include/lib/fit/internal/function.h:128 +0xfe12d #30 0x00002290f9906fc7 in fit::internal::function_base<8UL, true, void(std::__2::unique_ptr>, fbl::ref_ptr), std::__2::allocator>::invoke(const fit::internal::function_base<8UL, true, void (std::__2::unique_ptr >, fbl::ref_ptr), std::__2::allocator >*, std::__2::unique_ptr >, fbl::ref_ptr) ../../sdk/lib/fit/include/lib/fit/internal/function.h:522 +0xecfc7 #31 0x00002290f9906c66 in fit::function_impl<8UL, true, void(std::__2::unique_ptr>, fbl::ref_ptr), std::__2::allocator>::operator()(const fit::function_impl<8UL, true, void (std::__2::unique_ptr >, fbl::ref_ptr), std::__2::allocator >*, std::__2::unique_ptr >, fbl::ref_ptr) ../../sdk/lib/fit/include/lib/fit/function.h:315 +0xecc66 #32 0x00002290f98e73d9 in driver_runtime::Dispatcher::event_waiter::invoke_callback(driver_runtime::Dispatcher::event_waiter*, std::__2::unique_ptr >, fbl::ref_ptr) ../../src/devices/bin/driver_runtime/dispatcher.h:543 +0xcd3d9 #33 0x00002290f98e700d in driver_runtime::Dispatcher::event_waiter::handle_event(std::__2::unique_ptr >, async_dispatcher_t*, async::wait_base*, zx_status_t, zx_packet_signal_t const*) ../../src/devices/bin/driver_runtime/dispatcher.cc:1442 +0xcd00d #34 0x00002290f9918983 in async_loop_owned_event_handler::handle_event(async_loop_owned_event_handler*, async_dispatcher_t*, async::wait_base*, zx_status_t, zx_packet_signal_t const*) ../../src/devices/bin/driver_runtime/async_loop_owned_event_handler.h:59 +0xfe983 #35 0x00002290f9918b9e in async::wait_method, &async_loop_owned_event_handler::handle_event>::call_handler(async_dispatcher_t*, async_wait_t*, zx_status_t, zx_packet_signal_t const*) ../../sdk/lib/async/include/lib/async/cpp/wait.h:201 +0xfeb9e #36 0x00002290f99bf509 in async_loop_dispatch_wait(async_loop_t*, async_wait_t*, zx_status_t, zx_packet_signal_t const*) ../../sdk/lib/async-loop/loop.c:394 +0x1a5509 #37 0x00002290f99b9958 in async_loop_run_once(async_loop_t*, zx_time_t) ../../sdk/lib/async-loop/loop.c:343 +0x19f958 #38 0x00002290f99b9247 in async_loop_run(async_loop_t*, zx_time_t, _Bool) ../../sdk/lib/async-loop/loop.c:301 +0x19f247 #39 0x00002290f99ba962 in async_loop_run_thread(void*) ../../sdk/lib/async-loop/loop.c:860 +0x1a0962 #40 0x000041afd176ef30 in start_c11(void*) ../../zircon/third_party/ulib/musl/pthread/pthread_create.c:63 +0x84f30 #41 0x000041afd18a448d in thread_trampoline(uintptr_t, uintptr_t) ../../zircon/system/ulib/runtime/thread.cc:100 +0x1ba48d Link: https://github.com/acpica/acpica/commit/1c28da22 Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/4664267.LvFx2qVVIh@rjwysocki.net Signed-off-by: Tamir Duberstein [ rjw: Pick up the tag from Tamir ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 3e0c59180ec83bdec43b3d3482cff23d86d380d0 Author: Seunghun Han Date: Wed Mar 26 21:06:21 2025 +0100 ACPICA: fix acpi parse and parseext cache leaks [ Upstream commit bed18f0bdcd6737a938264a59d67923688696fc4 ] ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5 I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [ 0.352414] ACPI: Added _OSI(Module Device) [ 0.353182] ACPI: Added _OSI(Processor Device) [ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.353182] ACPI: Added _OSI(Processor Aggregator Device) [ 0.356028] ACPI: Unable to start the ACPI Interpreter [ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #10 [ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.361873] Call Trace: [ 0.362243] ? dump_stack+0x5c/0x81 [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27 [ 0.363296] ? acpi_os_delete_cache+0xa/0x10 [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.364000] ? acpi_terminate+0xa/0x14 [ 0.364000] ? acpi_init+0x2af/0x34f [ 0.364000] ? __class_create+0x4c/0x80 [ 0.364000] ? video_setup+0x7f/0x7f [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.364000] ? do_one_initcall+0x4e/0x1a0 [ 0.364000] ? kernel_init_freeable+0x189/0x20a [ 0.364000] ? rest_init+0xc0/0xc0 [ 0.364000] ? kernel_init+0xa/0x100 [ 0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [ 0.360101] ACPI: Added _OSI(Module Device) [ 0.360101] ACPI: Added _OSI(Processor Device) [ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.361043] ACPI: Added _OSI(Processor Aggregator Device) [ 0.364016] ACPI: Unable to start the ACPI Interpreter [ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.372000] Call Trace: [ 0.372000] ? dump_stack+0x5c/0x81 [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? acpi_os_delete_cache+0xa/0x10 [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b [ 0.372000] ? acpi_terminate+0xa/0x14 [ 0.372000] ? acpi_init+0x2af/0x34f [ 0.372000] ? __class_create+0x4c/0x80 [ 0.372000] ? video_setup+0x7f/0x7f [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? do_one_initcall+0x4e/0x1a0 [ 0.372000] ? kernel_init_freeable+0x189/0x20a [ 0.372000] ? rest_init+0xc0/0xc0 [ 0.372000] ? kernel_init+0xa/0x100 [ 0.372000] ? ret_from_fork+0x25/0x30 [ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.392000] Call Trace: [ 0.392000] ? dump_stack+0x5c/0x81 [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? acpi_os_delete_cache+0xa/0x10 [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.392000] ? acpi_terminate+0xa/0x14 [ 0.392000] ? acpi_init+0x2af/0x34f [ 0.392000] ? __class_create+0x4c/0x80 [ 0.392000] ? video_setup+0x7f/0x7f [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? do_one_initcall+0x4e/0x1a0 [ 0.392000] ? kernel_init_freeable+0x189/0x20a [ 0.392000] ? rest_init+0xc0/0xc0 [ 0.392000] ? kernel_init+0xa/0x100 [ 0.392000] ? ret_from_fork+0x25/0x30 When early abort is occurred due to invalid ACPI information, Linux kernel terminates ACPI by calling acpi_terminate() function. The function calls acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_ cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache). But the deletion codes in acpi_ut_delete_caches() function only delete slab caches using kmem_cache_destroy() function, therefore the cache objects should be flushed before acpi_ut_delete_caches() function. "Acpi-Parse" cache and "Acpi-ParseExt" cache are used in an AML parse function, acpi_ps_parse_loop(). The function should complete all ops using acpi_ps_complete_final_op() when an error occurs due to invalid AML codes. However, the current implementation of acpi_ps_complete_final_op() does not complete all ops when it meets some errors and this cause cache leak. This cache leak has a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. To fix ACPI cache leak for enhancing security, I made a patch to complete all ops unconditionally for acpi_ps_complete_final_op() function. I hope that this patch improves the security of Linux kernel. Thank you. Link: https://github.com/acpica/acpica/commit/8829e70e Signed-off-by: Seunghun Han Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2363774.ElGaqSPkdT@rjwysocki.net Signed-off-by: Sasha Levin commit 58a5d355f19f72f43a9127f03f41612442c73277 Author: Mario Limonciello Date: Mon Apr 7 13:36:55 2025 -0500 ACPI: Add missing prototype for non CONFIG_SUSPEND/CONFIG_X86 case [ Upstream commit e1bdbbc98279164d910d2de82a745f090a8b249f ] acpi_register_lps0_dev() and acpi_unregister_lps0_dev() may be used in drivers that don't require CONFIG_SUSPEND or compile on !X86. Add prototypes for those cases. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202502191627.fRgoBwcZ-lkp@intel.com/ Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20250407183656.1503446-1-superm1@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 1bf99d122b40772b7710135d7b3ca8f7a0751f73 Author: Stefan Binding Date: Thu May 15 17:28:32 2025 +0100 ALSA: hda/realtek: Add support for Acer Helios Laptops using CS35L41 HDA [ Upstream commit d64cbb5ed9227566c068ac9300a85912234d10aa ] Laptops use 2 CS35L41 Amps with HDA, using External boost with I2C. Similar to previous Acer laptops, these laptops also need the ALC255_FIXUP_PREDATOR_SUBWOOFER quirk to function properly. Signed-off-by: Stefan Binding Link: https://patch.msgid.link/20250515162848.405055-2-sbinding@opensource.cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4e1189b0ebdc8cb0638a889f706fc2dd5eb4ee77 Author: Armin Wolf Date: Sun May 18 20:51:11 2025 +0200 ACPI: bus: Bail out if acpi_kobj registration fails [ Upstream commit 94a370fc8def6038dbc02199db9584b0b3690f1a ] The ACPI sysfs code will fail to initialize if acpi_kobj is NULL, together with some ACPI drivers. Follow the other firmware subsystems and bail out if the kobject cannot be registered. Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20250518185111.3560-2-W_Armin@gmx.de Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 9af061625c457104f170ea0553346918ce5890b0 Author: I Hsin Cheng Date: Tue May 6 02:54:23 2025 +0800 ASoC: intel/sdw_utils: Assign initial value in asoc_sdw_rt_amp_spk_rtd_init() [ Upstream commit 5fb3878216aece471af030b33a9fbef3babd8617 ] Initialize "ret" with "-EINVAL" to handle cases where "strstr()" for "codec_dai->component->name_prefix" doesn't find "-1" nor "-2". In that case "name_prefix" is invalid because for current implementation it's expected to have either "-1" or "-2" in it. (Maybe "-3", "-4" and so on in the future.) Link: https://scan5.scan.coverity.com/#/project-view/36179/10063?selectedIssue=1627120 Signed-off-by: I Hsin Cheng Link: https://patch.msgid.link/20250505185423.680608-1-richard120310@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 428bb457fc5ea96104d3a6b50699b3e219705f1c Author: Hector Martin Date: Sun Apr 6 09:15:05 2025 +1000 ASoC: tas2770: Power cycle amp on ISENSE/VSENSE change [ Upstream commit f529c91be8a34ac12e7599bf87c65b6f4a2c9f5c ] The ISENSE/VSENSE blocks are only powered up when the amplifier transitions from shutdown to active. This means that if those controls are flipped on while the amplifier is already playing back audio, they will have no effect. Fix this by forcing a power cycle around transitions in those controls. Reviewed-by: Neal Gompa Signed-off-by: Hector Martin Signed-off-by: James Calligeros Link: https://patch.msgid.link/20250406-apple-codec-changes-v5-1-50a00ec850a3@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit decaed3a7c4159916fb3c58f2c944bbcbfbdde06 Author: Qiuxu Zhuo Date: Tue Apr 8 21:24:53 2025 +0800 EDAC/igen6: Skip absent memory controllers [ Upstream commit 20e190b1c1fd88b21cc5106c12cfe6def5ab849d ] Some BIOS versions may fuse off certain memory controllers and set the registers of these absent memory controllers to ~0. The current igen6_edac mistakenly enumerates these absent memory controllers and registers them with the EDAC core. Skip the absent memory controllers to avoid mistakenly enumerating them. Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://lore.kernel.org/r/20250408132455.489046-2-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit d2aebba9a2417bb4850ff2eba47e4d51108c87d5 Author: Ahmed Salem Date: Fri Apr 25 21:30:27 2025 +0200 ACPICA: Avoid sequence overread in call to strncmp() [ Upstream commit 64b9dfd0776e9c38d733094859a09f13282ce6f8 ] ACPICA commit 8b83a8d88dfec59ea147fad35fc6deea8859c58c ap_get_table_length() checks if tables are valid by calling ap_is_valid_header(). The latter then calls ACPI_VALIDATE_RSDP_SIG(Table->Signature). ap_is_valid_header() accepts struct acpi_table_header as an argument, so the signature size is always fixed to 4 bytes. The problem is when the string comparison is between ACPI-defined table signature and ACPI_SIG_RSDP. Common ACPI table header specifies the Signature field to be 4 bytes long[1], with the exception of the RSDP structure whose signature is 8 bytes long "RSD PTR " (including the trailing blank character)[2]. Calling strncmp(sig, rsdp_sig, 8) would then result in a sequence overread[3] as sig would be smaller (4 bytes) than the specified bound (8 bytes). As a workaround, pass the bound conditionally based on the size of the signature being passed. Link: https://uefi.org/specs/ACPI/6.5_A/05_ACPI_Software_Programming_Model.html#system-description-table-header [1] Link: https://uefi.org/specs/ACPI/6.5_A/05_ACPI_Software_Programming_Model.html#root-system-description-pointer-rsdp-structure [2] Link: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overread [3] Link: https://github.com/acpica/acpica/commit/8b83a8d8 Signed-off-by: Ahmed Salem Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2248233.Mh6RI2rZIc@rjwysocki.net Signed-off-by: Sasha Levin commit a580c65a86f75698379bbed547ceb86d6b175882 Author: Erick Shepherd Date: Mon Mar 31 17:13:37 2025 -0500 mmc: Add quirk to disable DDR50 tuning [ Upstream commit 9510b38dc0ba358c93cbf5ee7c28820afb85937b ] Adds the MMC_QUIRK_NO_UHS_DDR50_TUNING quirk and updates mmc_execute_tuning() to return 0 if that quirk is set. This fixes an issue on certain Swissbit SD cards that do not support DDR50 tuning where tuning requests caused I/O errors to be thrown. Signed-off-by: Erick Shepherd Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20250331221337.1414534-1-erick.shepherd@ni.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 5e47ff0a813494612bdd46073886efaa90e20c59 Author: Krzysztof Kozlowski Date: Sun Apr 6 22:27:29 2025 +0200 power: supply: collie: Fix wakeup source leaks on device unbind [ Upstream commit c73d19f89cb03c43abbbfa3b9caa1b8fc719764c ] Device can be unbound, so driver must also release memory for the wakeup source. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250406202730.55096-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 19ef4d3f74a49d5d35904abb7c86498f10e43e66 Author: Krzysztof Kozlowski Date: Sun Apr 6 22:27:30 2025 +0200 power: supply: gpio-charger: Fix wakeup source leaks on device unbind [ Upstream commit 51212ce95354c5b51e8c3054bf80eeeed80003b6 ] Device can be unbound, so driver must also release memory for the wakeup source. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250406202730.55096-2-krzysztof.kozlowski@linaro.org Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit b66fc1b38dff2c281870636ffd8b528e9c63d198 Author: Guilherme G. Piccoli Date: Sun Mar 23 14:36:24 2025 -0300 clocksource: Fix the CPUs' choice in the watchdog per CPU verification [ Upstream commit 08d7becc1a6b8c936e25d827becabfe3bff72a36 ] Right now, if the clocksource watchdog detects a clocksource skew, it might perform a per CPU check, for example in the TSC case on x86. In other words: supposing TSC is detected as unstable by the clocksource watchdog running at CPU1, as part of marking TSC unstable the kernel will also run a check of TSC readings on some CPUs to be sure it is synced between them all. But that check happens only on some CPUs, not all of them; this choice is based on the parameter "verify_n_cpus" and in some random cpumask calculation. So, the watchdog runs such per CPU checks on up to "verify_n_cpus" random CPUs among all online CPUs, with the risk of repeating CPUs (that aren't double checked) in the cpumask random calculation. But if "verify_n_cpus" > num_online_cpus(), it should skip the random calculation and just go ahead and check the clocksource sync between all online CPUs, without the risk of skipping some CPUs due to duplicity in the random cpumask calculation. Tests in a 4 CPU laptop with TSC skew detected led to some cases of the per CPU verification skipping some CPU even with verify_n_cpus=8, due to the duplicity on random cpumask generation. Skipping the randomization when the number of online CPUs is smaller than verify_n_cpus, solves that. Suggested-by: Thadeu Lima de Souza Cascardo Signed-off-by: Guilherme G. Piccoli Signed-off-by: Thomas Gleixner Reviewed-by: Paul E. McKenney Link: https://lore.kernel.org/all/20250323173857.372390-1-gpiccoli@igalia.com Signed-off-by: Sasha Levin commit e944fc786c15f3d7177b3facbad8fd7dfb194fa4 Author: Talhah Peerbhai Date: Fri May 16 01:27:41 2025 +0300 ASoC: amd: yc: Add quirk for Lenovo Yoga Pro 7 14ASP9 [ Upstream commit a28206060dc5848a1a2a15b7f6ac6223d869084d ] Similar to many other Lenovo models with AMD chips, the Lenovo Yoga Pro 7 14ASP9 (product name 83HN) requires a specific quirk to ensure internal mic detection. This patch adds a quirk fixing this. Signed-off-by: Talhah Peerbhai Link: https://patch.msgid.link/20250515222741.144616-1-talhah.peerbhai@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e0783910ca4368b01466bc8dcdcc13c3e0b7db53 Author: Seunghun Han Date: Wed Mar 26 21:05:24 2025 +0100 ACPICA: fix acpi operand cache leak in dswstate.c [ Upstream commit 156fd20a41e776bbf334bd5e45c4f78dfc90ce1c ] ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net Signed-off-by: Sasha Levin commit ef10ae2d7eb525abc85a6586bd2c904c3bc3a7eb Author: David Lechner Date: Fri May 2 10:04:30 2025 -0500 iio: adc: ad7606: fix raw read for 18-bit chips commit 3f5fd1717ae9497215f22aa748fc2c09df88b0e3 upstream. Fix 18-bit raw read for 18-bit chips by applying a mask to the value we receive from the SPI controller. SPI controllers either return 1, 2 or 4 bytes per word depending on the bits_per_word. For 16-bit chips, there was no problem since they raw data fit exactly in the 2 bytes received from the SPI controller. But now that we have 18-bit chips and we are using bits_per_word = 18, we cannot assume that the extra bits in the 32-bit word are always zero. In fact, with the AXI SPI Engine controller, these bits are not always zero which caused the raw values to read 10s of 1000s of volts instead of the correct value. Therefore, we need to mask the value we receive from the SPI controller to ensure that only the 18 bits of real data are used. Fixes: f3838e934dff ("iio: adc: ad7606: add support for AD7606C-{16,18} parts") Signed-off-by: David Lechner Link: https://patch.msgid.link/20250502-iio-adc-ad7606-fix-raw-read-for-18-bit-chips-v1-1-06caa92d8f11@baylibre.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 936cbd9725c595b680094966d4d2b8fc7b1df020 Author: David Lechner Date: Tue Apr 22 15:12:27 2025 -0500 iio: adc: ad7173: fix compiling without gpiolib commit c553aa1b03719400a30d9387477190d4743fc1de upstream. Fix compiling the ad7173 driver when CONFIG_GPIOLIB is not set by selecting GPIOLIB to be always enabled and remove the #if. Commit 031bdc8aee01 ("iio: adc: ad7173: add calibration support") placed unrelated code in the middle of the #if IS_ENABLED(CONFIG_GPIOLIB) block which caused the reported compile error. However, later commit 7530ed2aaa3f ("iio: adc: ad7173: add openwire detection support for single conversions") makes use of the gpio regmap even when we aren't providing gpio controller support. So it makes more sense to always enable GPIOLIB rather than trying to make it optional. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202504220824.HVrTVov1-lkp@intel.com/ Fixes: 031bdc8aee01 ("iio: adc: ad7173: add calibration support") Signed-off-by: David Lechner Link: https://patch.msgid.link/20250422-iio-adc-ad7173-fix-compile-without-gpiolib-v1-1-295f2c990754@baylibre.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5814e4335261ac817518b08324fe2d8d86a3776a Author: David Lechner Date: Mon Apr 28 20:55:34 2025 -0500 iio: adc: ad7606_spi: fix reg write value mask commit 89944d88f8795c6c89b9514cb365998145511cd4 upstream. Fix incorrect value mask for register write. Register values are 8-bit, not 9. If this function was called with a value > 0xFF and an even addr, it would cause writing to the next register. Fixes: f2a22e1e172f ("iio: adc: ad7606: Add support for software mode for ad7616") Signed-off-by: David Lechner Reviewed-by: Angelo Dureghello Link: https://patch.msgid.link/20250428-iio-adc-ad7606_spi-fix-write-value-mask-v1-1-a2d5e85a809f@baylibre.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2940d1e9ce8bbdcb73bd7cb6a3c34f0ac7d8417b Author: Arthur-Prince Date: Wed Apr 30 16:07:37 2025 -0300 iio: adc: ti-ads1298: Kconfig: add kfifo dependency to fix module build commit 3c5dfea39a245b2dad869db24e2830aa299b1cf2 upstream. Add dependency to Kconfig’s ti-ads1298 because compiling it as a module failed with an undefined kfifo symbol. Fixes: 00ef7708fa60 ("iio: adc: ti-ads1298: Add driver") Signed-off-by: Arthur-Prince Co-developed-by: Mariana Valério Signed-off-by: Mariana Valério Link: https://patch.msgid.link/20250430191131.120831-1-r2.arthur.prince@gmail.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e86a32504ea487e5ba255b37fcdd03317c38d17a Author: David Lechner Date: Mon May 5 13:28:40 2025 -0500 iio: adc: ad7944: mask high bits on direct read commit 7cdfbc0113d087348b8e65dd79276d0f57b89a10 upstream. Apply a mask to the raw value received over the SPI bus for unsigned direct reads. As we found recently, SPI controllers may not set unused bits to 0 when reading with bits_per_word != {8,16,32}. The ad7944 uses bits_per_word of 14 and 18, so we need to mask the value to be sure we returning the correct value to userspace during a direct read. Fixes: d1efcf8871db ("iio: adc: ad7944: add driver for AD7944/AD7985/AD7986") Signed-off-by: David Lechner Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20250505-iio-adc-ad7944-max-high-bits-on-direct-read-v1-1-b173facceefe@baylibre.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 552c3f61f237c16d40668459fb98b9811727fc4e Author: Sean Nyekjaer Date: Fri May 2 11:37:26 2025 +0200 iio: imu: inv_icm42600: Fix temperature calculation commit e2f820014239df9360064079ae93f838ff3b7f8c upstream. >From the documentation: "offset to be added to [Y]_raw prior toscaling by [Y]_scale" Offset should be applied before multiplying scale, so divide offset by scale to make this correct. Fixes: bc3eb0207fb5 ("iio: imu: inv_icm42600: add temperature sensor support") Signed-off-by: Sean Nyekjaer Acked-by: Jean-Baptiste Maneyrol Link: https://patch.msgid.link/20250502-imu-v1-1-129b8391a4e3@geanix.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a6bfeb97941a9187833b526bc6cc4ff5706d0ce9 Author: Jann Horn Date: Tue May 27 23:23:54 2025 +0200 mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race commit 1013af4f585fccc4d3e5c5824d174de2257f7d6d upstream. huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse. Link: https://lkml.kernel.org/r/20250528-hugetlb-fixes-splitrace-v2-2-1329349bad1a@google.com Link: https://lkml.kernel.org/r/20250527-hugetlb-fixes-splitrace-v1-2-f4136f5ec58a@google.com Fixes: 39dde65c9940 ("[PATCH] shared page table for hugetlb page") Signed-off-by: Jann Horn Reviewed-by: Lorenzo Stoakes Cc: Liam Howlett Cc: Muchun Song Cc: Oscar Salvador Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8a21d5584826f4880f45bbf8f72375f4e6c0ff2a Author: Jann Horn Date: Tue May 27 23:23:53 2025 +0200 mm/hugetlb: unshare page tables during VMA split, not before commit 081056dc00a27bccb55ccc3c6f230a3d5fd3f7e0 upstream. Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked. An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts: 1. from hugetlb_split(), holding: - mmap lock (exclusively) - VMA lock - file rmap lock (exclusively) 2. hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back. [jannh@google.com: v2] Link: https://lkml.kernel.org/r/20250528-hugetlb-fixes-splitrace-v2-1-1329349bad1a@google.com Link: https://lkml.kernel.org/r/20250528-hugetlb-fixes-splitrace-v2-0-1329349bad1a@google.com Link: https://lkml.kernel.org/r/20250527-hugetlb-fixes-splitrace-v1-1-f4136f5ec58a@google.com Fixes: 39dde65c9940 ("[PATCH] shared page table for hugetlb page") Signed-off-by: Jann Horn Cc: Liam Howlett Reviewed-by: Lorenzo Stoakes Reviewed-by: Oscar Salvador Cc: Lorenzo Stoakes Cc: Vlastimil Babka Cc: [b30c14cd6102: hugetlb: unshare some PMDs when splitting VMAs] Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 58b83b9a9a929611a2a2e7d88f45cb0d786b7ee0 Author: Pu Lehui Date: Thu May 29 15:56:47 2025 +0000 mm: fix uprobe pte be overwritten when expanding vma commit 2b12d06c37fd3a394376f42f026a7478d826ed63 upstream. Patch series "Fix uprobe pte be overwritten when expanding vma". This patch (of 4): We encountered a BUG alert triggered by Syzkaller as follows: BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1 And we can reproduce it with the following steps: 1. register uprobe on file at zero offset 2. mmap the file at zero offset: addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0); 3. mremap part of vma1 to new vma2: addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE); 4. mremap back to orig addr1: mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1); In step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2 with range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1 to vma2, then unmap the vma1 range [addr1, addr1 + 4096]. In step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the addr range [addr1, addr1 + 4096]. Since the addr range [addr1 + 4096, addr1 + 8192] still maps the file, it will take vma_merge_new_range to expand the range, and then do uprobe_mmap in vma_complete. Since the merged vma pgoff is also zero offset, it will install uprobe anon page to the merged vma. However, the upcomming move_page_tables step, which use set_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite the newly uprobe pte in the merged vma, and lead that pte to be orphan. Since the uprobe pte will be remapped to the merged vma, we can remove the unnecessary uprobe_mmap upon merged vma. This problem was first found in linux-6.6.y and also exists in the community syzkaller: https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/ Link: https://lkml.kernel.org/r/20250529155650.4017699-1-pulehui@huaweicloud.com Link: https://lkml.kernel.org/r/20250529155650.4017699-2-pulehui@huaweicloud.com Fixes: 2b1444983508 ("uprobes, mm, x86: Add the ability to install and remove uprobes breakpoints") Signed-off-by: Pu Lehui Suggested-by: Lorenzo Stoakes Reviewed-by: Lorenzo Stoakes Acked-by: David Hildenbrand Cc: Jann Horn Cc: Liam Howlett Cc: "Masami Hiramatsu (Google)" Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit bf048fa4794f370ea556f81b07f16f5ee2fbc39e Author: Thomas Zimmermann Date: Tue May 20 09:14:00 2025 +0200 dummycon: Trigger redraw when switching consoles with deferred takeover commit 03bcbbb3995ba5df43af9aba45334e35f2dfe27b upstream. Signal vt subsystem to redraw console when switching to dummycon with deferred takeover enabled. Makes the console switch to fbcon and displays the available output. With deferred takeover enabled, dummycon acts as the placeholder until the first output to the console happens. At that point, fbcon takes over. If the output happens while dummycon is not active, it cannot inform fbcon. This is the case if the vt subsystem runs in graphics mode. A typical graphical boot starts plymouth, a display manager and a compositor; all while leaving out dummycon. Switching to a text-mode console leaves the console with dummycon even if a getty terminal has been started. Returning true from dummycon's con_switch helper signals the vt subsystem to redraw the screen. If there's output available dummycon's con_putc{s} helpers trigger deferred takeover of fbcon, which sets a display mode and displays the output. If no output is available, dummycon remains active. v2: - make the comment slightly more verbose (Javier) Signed-off-by: Thomas Zimmermann Reported-by: Andrei Borzenkov Closes: https://bugzilla.suse.com/show_bug.cgi?id=1242191 Tested-by: Andrei Borzenkov Acked-by: Javier Martinez Canillas Fixes: 83d83bebf401 ("console/fbcon: Add support for deferred console takeover") Cc: Hans de Goede Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: # v4.19+ Link: https://lore.kernel.org/r/20250520071418.8462-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit f65271ac66f3cb54e5dfc94441a5a9d1ef002bf2 Author: Jens Axboe Date: Wed May 28 13:45:44 2025 -0600 io_uring/net: only consider msg_inq if larger than 1 commit 2c7f023219966777be0687e15b57689894304cd3 upstream. Currently retry and general validity of msg_inq is gated on it being larger than zero, but it's entirely possible for this to be slightly inaccurate. In particular, if FIN is received, it'll return 1. Just use larger than 1 as the check. This covers both the FIN case, and at the same time, it doesn't make much sense to retry a recv immediately if there's even just a single 1 byte of valid data in the socket. Leave the SOCK_NONEMPTY flagging when larger than 0 still, as an app may use that for the final receive. Cc: stable@vger.kernel.org Reported-by: Christian Mazakas Fixes: 7c71a0af81ba ("io_uring/net: improve recv bundles") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 61c124a86550e55613ae4d08b8b1c0b8d4f5abf2 Author: Jacek Lawrynowicz Date: Wed May 28 19:12:20 2025 +0200 accel/ivpu: Fix warning in ivpu_gem_bo_free() commit 91274fd4ed9ba110b02c53d71d2778b7d13b49ac upstream. Don't WARN if imported buffers are in use in ivpu_gem_bo_free() as they can be indeed used in the original context/driver. Fixes: 647371a6609d ("accel/ivpu: Add GEM buffer object management") Cc: stable@vger.kernel.org # v6.3 Reviewed-by: Jeff Hugo Reviewed-by: Lizhi Hou Signed-off-by: Jacek Lawrynowicz Link: https://lore.kernel.org/r/20250528171220.513225-1-jacek.lawrynowicz@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 4aee46b509a013f4db5ff4fca4d0359a61a6ddeb Author: Jacek Lawrynowicz Date: Wed May 28 17:43:25 2025 +0200 accel/ivpu: Use dma_resv_lock() instead of a custom mutex commit 98d3f772ca7d6822bdfc8c960f5f909574db97c9 upstream. This fixes a potential race conditions in: - ivpu_bo_unbind_locked() where we modified the shmem->sgt without holding the dma_resv_lock(). - ivpu_bo_print_info() where we read the shmem->pages without holding the dma_resv_lock(). Using dma_resv_lock() also protects against future syncronisation issues that may arise when accessing drm_gem_shmem_object or drm_gem_object members. Fixes: 42328003ecb6 ("accel/ivpu: Refactor BO creation functions") Cc: stable@vger.kernel.org # v6.9+ Reviewed-by: Lizhi Hou Signed-off-by: Jacek Lawrynowicz Link: https://lore.kernel.org/r/20250528154325.500684-1-jacek.lawrynowicz@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 635ceaeff3beba22c07872960a3c18a7b86c7de0 Author: Karol Wachowski Date: Wed May 28 17:42:53 2025 +0200 accel/ivpu: Trigger device recovery on engine reset/resume failure commit a47e36dc5d90dc664cac87304c17d50f1595d634 upstream. Trigger full device recovery when the driver fails to restore device state via engine reset and resume operations. This is necessary because, even if submissions from a faulty context are blocked, the NPU may still process previously submitted faulty jobs if the engine reset fails to abort them. Such jobs can continue to generate faults and occupy device resources. When engine reset is ineffective, the only way to recover is to perform a full device recovery. Fixes: dad945c27a42 ("accel/ivpu: Add handling of VPU_JSM_STATUS_MVNCI_CONTEXT_VIOLATION_HW") Cc: stable@vger.kernel.org # v6.15+ Signed-off-by: Karol Wachowski Reviewed-by: Lizhi Hou Signed-off-by: Jacek Lawrynowicz Link: https://lore.kernel.org/r/20250528154253.500556-1-jacek.lawrynowicz@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 585b3baa9029176308a3d214f3027c64d17a451c Author: Jacek Lawrynowicz Date: Tue May 6 11:20:30 2025 +0200 accel/ivpu: Use firmware names from upstream repo commit 1c2c0e29f24360b3130c005a3c261cb8c7b363c6 upstream. Use FW names from linux-firmware repo instead of deprecated ones. The vpu_37xx.bin style names were never released and were only used for internal testing, so it is safe to remove them. Fixes: c140244f0cfb ("accel/ivpu: Add initial Panther Lake support") Cc: stable@vger.kernel.org # v6.13+ Reviewed-by: Lizhi Hou Reviewed-by: Jeff Hugo Signed-off-by: Jacek Lawrynowicz Link: https://lore.kernel.org/r/20250506092030.280276-1-jacek.lawrynowicz@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 8778149bc1e637c211a2237f739d308740ca8c82 Author: Jacek Lawrynowicz Date: Tue May 6 11:13:03 2025 +0200 accel/ivpu: Improve buffer object logging commit a01e93ee44f7ed76f872d0ede82f8d31bf0a048a upstream. - Fix missing alloc log when drm_gem_handle_create() fails in drm_vma_node_allow() and open callback is not called - Add ivpu_bo->ctx_id that enables to log the actual context id instead of using 0 as default - Add couple WARNs and errors so we can catch more memory corruption issues Fixes: 37dee2a2f433 ("accel/ivpu: Improve buffer object debug logs") Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Jeff Hugo Reviewed-by: Lizhi Hou Signed-off-by: Jacek Lawrynowicz Link: https://lore.kernel.org/r/20250506091303.262034-1-jacek.lawrynowicz@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 1c79b24848c3cfed13ee460ff3a7889126e00a34 Author: Sean Nyekjaer Date: Mon May 5 21:20:07 2025 +0200 iio: accel: fxls8962af: Fix temperature calculation commit 16038474e3a0263572f36326ef85057aaf341814 upstream. According to spec temperature should be returned in milli degrees Celsius. Add in_temp_scale to calculate from Celsius to milli Celsius. Fixes: a3e0b51884ee ("iio: accel: add support for FXLS8962AF/FXLS8964AF accelerometers") Cc: stable@vger.kernel.org Reviewed-by: Marcelo Schmitt Signed-off-by: Sean Nyekjaer Link: https://patch.msgid.link/20250505-fxls-v4-1-a38652e21738@geanix.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 443b7fadbf9275c2d8999b991fe73d1f1bff1c70 Author: Sean Nyekjaer Date: Mon May 5 21:20:08 2025 +0200 iio: accel: fxls8962af: Fix temperature scan element sign commit 9c78317b42e7c32523c91099859bc4721e9f75dd upstream. Mark the temperature element signed, data read from the TEMP_OUT register is in two's complement format. This will avoid the temperature being mishandled and miss displayed. Fixes: a3e0b51884ee ("iio: accel: add support for FXLS8962AF/FXLS8964AF accelerometers") Suggested-by: Marcelo Schmitt Cc: stable@vger.kernel.org Reviewed-by: Marcelo Schmitt Signed-off-by: Sean Nyekjaer Link: https://patch.msgid.link/20250505-fxls-v4-2-a38652e21738@geanix.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 288f9bfc91c69ced4dcf4c5a2582a12c54e1d522 Author: Saurabh Sengar Date: Thu May 29 03:18:30 2025 -0700 hv_netvsc: fix potential deadlock in netvsc_vf_setxdp() commit 3ec523304976648b45a3eef045e97d17122ff1b2 upstream. The MANA driver's probe registers netdevice via the following call chain: mana_probe() register_netdev() register_netdevice() register_netdevice() calls notifier callback for netvsc driver, holding the netdev mutex via netdev_lock_ops(). Further this netvsc notifier callback end up attempting to acquire the same lock again in dev_xdp_propagate() leading to deadlock. netvsc_netdev_event() netvsc_vf_setxdp() dev_xdp_propagate() This deadlock was not observed so far because net_shaper_ops was never set, and thus the lock was effectively a no-op in this case. Fix this by using netif_xdp_propagate() instead of dev_xdp_propagate() to avoid recursive locking in this path. And, since no deadlock is observed on the other path which is via netvsc_probe, add the lock exclusivly for that path. Also, clean up the unregistration path by removing the unnecessary call to netvsc_vf_setxdp(), since unregister_netdevice_many_notify() already performs this cleanup via dev_xdp_uninstall(). Fixes: 97246d6d21c2 ("net: hold netdev instance lock during ndo_bpf") Cc: stable@vger.kernel.org Signed-off-by: Saurabh Sengar Tested-by: Erni Sri Satya Vennela Reviewed-by: Haiyang Zhang Reviewed-by: Subbaraya Sundeep Link: https://patch.msgid.link/1748513910-23963-1-git-send-email-ssengar@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e32d0d7d4a92962591f4158bd1c707db183194bc Author: Diederik de Haas Date: Thu Apr 17 16:21:18 2025 +0200 PCI: dw-rockchip: Fix PHY function call sequence in rockchip_pcie_phy_deinit() commit 286ed198b899739862456f451eda884558526a9d upstream. The documentation for the phy_power_off() function explicitly says that it must be called before phy_exit(). Hence, follow the same rule in rockchip_pcie_phy_deinit(). Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver") Signed-off-by: Diederik de Haas [mani: commit message change] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Reviewed-by: Dragan Simic Acked-by: Shawn Lin Cc: stable@vger.kernel.org # v5.15+ Link: https://patch.msgid.link/20250417142138.1377451-1-didi.debian@cknow.org Signed-off-by: Greg Kroah-Hartman commit 8f9dff4a3dfa9518a7890d1c58845826f10ea2d6 Author: Janne Grunau Date: Tue Apr 1 10:17:01 2025 +0100 PCI: apple: Set only available ports up commit 751bec089c4eed486578994abd2c5395f08d0302 upstream. Iterating over disabled ports results in of_irq_parse_raw() parsing the wrong "interrupt-map" entries, as it takes the status of the node into account. This became apparent after disabling unused PCIe ports in the Apple Silicon device trees instead of deleting them. Switching from for_each_child_of_node_scoped() to for_each_available_child_of_node_scoped() solves this issue. Fixes: 1e33888fbe44 ("PCI: apple: Add initial hardware bring-up") Fixes: a0189fdfb73d ("arm64: dts: apple: t8103: Disable unused PCIe ports") Signed-off-by: Janne Grunau Signed-off-by: Alyssa Rosenzweig Signed-off-by: Marc Zyngier Signed-off-by: Manivannan Sadhasivam Tested-by: Janne Grunau Reviewed-by: Rob Herring (Arm) Reviewed-by: Manivannan Sadhasivam Acked-by: Alyssa Rosenzweig Cc: stable@vger.kernel.org Link: https://lore.kernel.org/asahi/20230214-apple_dts_pcie_disable_unused-v1-0-5ea0d3ddcde3@jannau.net/ Link: https://lore.kernel.org/asahi/1ea2107a-bb86-8c22-0bbc-82c453ab08ce@linaro.org/ Link: https://patch.msgid.link/20250401091713.2765724-2-maz@kernel.org Signed-off-by: Greg Kroah-Hartman commit 5ceb96c7b59902cc47cbcf0a7882f8ed6299ffd6 Author: Shawn Lin Date: Thu Apr 17 08:35:09 2025 +0800 PCI: dw-rockchip: Remove PCIE_L0S_ENTRY check from rockchip_pcie_link_up() commit 7d9b5d6115532cf90a789ed6afd3f4c70ebbd827 upstream. rockchip_pcie_link_up() currently has two issues: 1. Value 0x11 of PCIE_L0S_ENTRY corresponds to L0 state, not L0S. So the naming is wrong from the very beginning. 2. Checking for value 0x11 treats other states like L0S and L1 as link down, which is wrong. Hence, remove the PCIE_L0S_ENTRY check and also its definition. This allows adding ASPM support in the successive commits. Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver") Signed-off-by: Shawn Lin [mani: commit message rewording] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Reviewed-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/1744850111-236269-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Greg Kroah-Hartman commit 73d55ab7cd5e57e217c5a920a3a5f5549a665cd5 Author: Ilpo Järvinen Date: Mon May 5 14:54:12 2025 +0300 PCI: Fix lock symmetry in pci_slot_unlock() commit f3efb9569b4a21354ef2caf7ab0608a3e14cc6e4 upstream. The commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") made the lock function to call depend on dev->subordinate but left pci_slot_unlock() unmodified creating locking asymmetry compared with pci_slot_lock(). Because of the asymmetric lock handling, the same bridge device is unlocked twice. First pci_bus_unlock() unlocks bus->self and then pci_slot_unlock() will unconditionally unlock the same bridge device. Move pci_dev_unlock() inside an else branch to match the logic in pci_slot_lock(). Fixes: a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Reviewed-by: Dave Jiang Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250505115412.37628-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 1eef426628cbc9e7730168a0149fa48b19b8a3b1 Author: Huacai Chen Date: Thu Apr 3 12:07:56 2025 +0800 PCI: Add ACS quirk for Loongson PCIe commit 1f3303aa92e15fa273779acac2d0023609de30f1 upstream. Loongson PCIe Root Ports don't advertise an ACS capability, but they do not allow peer-to-peer transactions between Root Ports. Add an ACS quirk so each Root Port can be in a separate IOMMU group. Signed-off-by: Xianglai Li Signed-off-by: Huacai Chen Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250403040756.720409-1-chenhuacai@loongson.cn Signed-off-by: Greg Kroah-Hartman commit ec40a58b64864ec1b1b65d3c0e5c0764e6850bcb Author: Niklas Cassel Date: Wed May 14 09:43:14 2025 +0200 PCI: dwc: ep: Correct PBA offset in .set_msix() callback commit 810276362bad172d063d1f6be1cc2cb425b90103 upstream. While dw_pcie_ep_set_msix() writes the Table Size field correctly (N-1), the calculation of the PBA offset is wrong because it calculates space for (N-1) entries instead of N. This results in the following QEMU error when using PCI passthrough on a device which relies on the PCI endpoint subsystem: failed to add PCI capability 0x11[0x50]@0xb0: table & pba overlap, or they don't fit in BARs, or don't align Fix the calculation of PBA offset in the MSI-X capability. [bhelgaas: more specific subject and commit log] Fixes: 83153d9f36e2 ("PCI: endpoint: Fix ->set_msix() to take BIR and offset as arguments") Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Wilfred Mallawa Reviewed-by: Damien Le Moal Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250514074313.283156-9-cassel@kernel.org Signed-off-by: Greg Kroah-Hartman commit 7d638a65e9d76bf1ef48da2647540fc2868ff3d8 Author: Niklas Cassel Date: Wed May 14 09:43:15 2025 +0200 PCI: cadence-ep: Correct PBA offset in .set_msix() callback commit c8bcb01352a86bc5592403904109c22b66bd916e upstream. While cdns_pcie_ep_set_msix() writes the Table Size field correctly (N-1), the calculation of the PBA offset is wrong because it calculates space for (N-1) entries instead of N. This results in the following QEMU error when using PCI passthrough on a device which relies on the PCI endpoint subsystem: failed to add PCI capability 0x11[0x50]@0xb0: table & pba overlap, or they don't fit in BARs, or don't align Fix the calculation of PBA offset in the MSI-X capability. [bhelgaas: more specific subject and commit log] Fixes: 3ef5d16f50f8 ("PCI: cadence: Add MSI-X support to Endpoint driver") Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Wilfred Mallawa Reviewed-by: Damien Le Moal Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250514074313.283156-10-cassel@kernel.org Signed-off-by: Greg Kroah-Hartman commit b4b375d796c73a58cb79996685397f312e97da0d Author: Long Li Date: Mon May 5 17:56:35 2025 -0700 uio_hv_generic: Align ring size to system page commit 0315fef2aff9f251ddef8a4b53db9187429c3553 upstream. Following the ring header, the ring data should align to system page boundary. Adjust the size if necessary. Cc: stable@vger.kernel.org Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus") Signed-off-by: Long Li Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/1746492997-4599-4-git-send-email-longli@linuxonhyperv.com Signed-off-by: Wei Liu Message-ID: <1746492997-4599-4-git-send-email-longli@linuxonhyperv.com> Signed-off-by: Greg Kroah-Hartman commit 2415e9b634910f50acfa8ae66af6c79f63938517 Author: Long Li Date: Mon May 5 17:56:34 2025 -0700 uio_hv_generic: Use correct size for interrupt and monitor pages commit c951ab8fd3589cf6991ed4111d2130816f2e3ac2 upstream. Interrupt and monitor pages should be in Hyper-V page size (4k bytes). This can be different from the system page size. This size is read and used by the user-mode program to determine the mapped data region. An example of such user-mode program is the VMBus driver in DPDK. Cc: stable@vger.kernel.org Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus") Signed-off-by: Long Li Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/1746492997-4599-3-git-send-email-longli@linuxonhyperv.com Signed-off-by: Wei Liu Message-ID: <1746492997-4599-3-git-send-email-longli@linuxonhyperv.com> Signed-off-by: Greg Kroah-Hartman commit 734226f482b827383b6c648cadba1efc87dbb97a Author: Long Li Date: Mon May 5 17:56:33 2025 -0700 Drivers: hv: Allocate interrupt and monitor pages aligned to system page boundary commit 09eea7ad0b8e973dcf5ed49902838e5d68177f8e upstream. There are use cases that interrupt and monitor pages are mapped to user-mode through UIO, so they need to be system page aligned. Some Hyper-V allocation APIs introduced earlier broke those requirements. Fix this by using page allocation functions directly for interrupt and monitor pages. Cc: stable@vger.kernel.org Fixes: ca48739e59df ("Drivers: hv: vmbus: Move Hyper-V page allocator to arch neutral code") Signed-off-by: Long Li Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/1746492997-4599-2-git-send-email-longli@linuxonhyperv.com Signed-off-by: Wei Liu Message-ID: <1746492997-4599-2-git-send-email-longli@linuxonhyperv.com> Signed-off-by: Greg Kroah-Hartman commit cce8e71ca1f7ad9045707f0d22490c1e9ed1df6c Author: Ruben Devos Date: Sun Jun 1 19:18:55 2025 +0200 smb: client: add NULL check in automount_fullpath commit f1e7a277a1736e12cc4bd6d93b8a5c439b8ca20c upstream. page is checked for null in __build_path_from_dentry_optional_prefix when tcon->origin_fullpath is not set. However, the check is missing when it is set. Add a check to prevent a potential NULL pointer dereference. Signed-off-by: Ruben Devos Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a45a4a3869e3415b531eab8c3d3e54eb23763cac Author: Shyam Prasad N Date: Mon Jun 2 22:37:16 2025 +0530 cifs: dns resolution is needed only for primary channel commit b4f60a053a2534c3e510ba0c1f8727566adf8317 upstream. When calling cifs_reconnect, before the connection to the server is reestablished, the code today does a DNS resolution and updates server->dstaddr. However, this is not necessary for secondary channels. Secondary channels use the interface list returned by the server to decide which address to connect to. And that happens after tcon is reconnected and server interfaces are requested. Signed-off-by: Shyam Prasad N Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 669e2a5789b667f8212ad5c8b994c32857746ad3 Author: Shyam Prasad N Date: Mon Jun 2 22:37:14 2025 +0530 cifs: update dstaddr whenever channel iface is updated commit c1846893991f3b4ec8a0cc12219ada153f0814d6 upstream. When the server interface info changes (more common in clustered servers like Azure Files), the per-channel iface gets updated. However, this did not update the corresponding dstaddr. As a result these channels will still connect (or try connecting) to older addresses. Fixes: b54034a73baf ("cifs: during reconnect, update interface if necessary") Cc: Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 1a0d81ade8a7f05fb0b77d9f60f365fd0894fb2c Author: Shyam Prasad N Date: Mon Jun 2 22:37:13 2025 +0530 cifs: reset connections for all channels when reconnect requested commit 1f396b9bfe39aaf55ea74a7005806164b236653d upstream. cifs_reconnect can be called with a flag to mark the session as needing reconnect too. When this is done, we expect the connections of all channels to be reconnected too, which is not happening today. Without doing this, we have seen bad things happen when primary and secondary channels are connected to different servers (in case of cloud services like Azure Files SMB). This change would force all connections to reconnect as well, not just the sessions and tcons. Cc: Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b2675f8e63d7f0b64b9806f8dfad8f080548cd0a Author: Beleswar Padhi Date: Tue May 13 11:14:38 2025 +0530 remoteproc: k3-m4: Don't assert reset in detach routine commit 23532524594c211871054a15c425812a4ac35102 upstream. The rproc_detach() function invokes __rproc_detach() before rproc_unprepare_device(). The __rproc_detach() function sets the rproc->state to "RPROC_DETACHED". However, the TI K3 M4 driver erroneously looks for "RPROC_ATTACHED" state in its .unprepare ops to identify IPC-only mode; which leads to resetting the rproc in detach routine. Therefore, correct the IPC-only mode detection logic to look for "RPROC_DETACHED" in k3_m4_rproc_unprepare() function. Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem") Signed-off-by: Beleswar Padhi Reviewed-by: Hari Nagalla Reviewed-by: Martyn Welch Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250513054510.3439842-5-b-padhi@ti.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 6fe9486d709e4a60990843832501ef6556440ca7 Author: Xiaolei Wang Date: Wed Apr 30 17:20:43 2025 +0800 remoteproc: core: Release rproc->clean_table after rproc_attach() fails commit bcd241230fdbc6005230f80a4f8646ff5a84f15b upstream. When rproc->state = RPROC_DETACHED is attached to remote processor through rproc_attach(), if rproc_handle_resources() returns failure, then the clean table should be released, otherwise the following memory leak will occur. unreferenced object 0xffff000086a99800 (size 1024): comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s) hex dump (first 32 bytes): 00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............ 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............ backtrace: [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230 [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260 [<0000000037818dae>] kmemdup+0x34/0x60 [<00000000610f7f57>] rproc_boot+0x35c/0x56c [<0000000065f8871a>] rproc_add+0x124/0x17c [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4 [<000000003bcaa37d>] platform_probe+0x68/0xd8 [<00000000771577f9>] really_probe+0x110/0x27c [<00000000531fea59>] __driver_probe_device+0x78/0x12c [<0000000080036a04>] driver_probe_device+0x3c/0x118 [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8 [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4 [<000000001a53b53e>] __device_attach+0xfc/0x18c [<00000000d1a2a32c>] device_initial_probe+0x14/0x20 [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4 unreferenced object 0xffff0000864c9690 (size 16): Fixes: 9dc9507f1880 ("remoteproc: Properly deal with the resource table when detaching") Signed-off-by: Xiaolei Wang Reviewed-by: Peng Fan Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250430092043.1819308-3-xiaolei.wang@windriver.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 5434d9f2fd68722b514c14b417b53a8af02c4d24 Author: Xiaolei Wang Date: Wed Apr 30 17:20:42 2025 +0800 remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach() commit 7692c9fbedd9087dc9050903f58095915458d9b1 upstream. When rproc->state = RPROC_DETACHED and rproc_attach() is used to attach to the remote processor, if rproc_handle_resources() returns a failure, the resources allocated by imx_rproc_prepare() should be released, otherwise the following memory leak will occur. Since almost the same thing is done in imx_rproc_prepare() and rproc_resource_cleanup(), Function rproc_resource_cleanup() is able to deal with empty lists so it is better to fix the "goto" statements in rproc_attach(). replace the "unprepare_device" goto statement with "clean_up_resources" and get rid of the "unprepare_device" label. unreferenced object 0xffff0000861c5d00 (size 128): comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............ backtrace: [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0 [<00000000521c0345>] kmalloc_trace+0x40/0x158 [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8 [<000000002815755e>] imx_rproc_prepare+0xe0/0x180 [<0000000003f61b4e>] rproc_boot+0x2ec/0x528 [<00000000e7e994ac>] rproc_add+0x124/0x17c [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4 [<00000000efc298a1>] platform_probe+0x68/0xd8 [<00000000110be6fe>] really_probe+0x110/0x27c [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118 [<00000000a7874938>] __device_attach_driver+0xb8/0xf8 [<0000000065319e69>] bus_for_each_drv+0x84/0xe4 [<00000000db3eb243>] __device_attach+0xfc/0x18c [<0000000072e4e1a4>] device_initial_probe+0x14/0x20 Fixes: 10a3d4079eae ("remoteproc: imx_rproc: move memory parsing to rproc_ops") Suggested-by: Mathieu Poirier Signed-off-by: Xiaolei Wang Reviewed-by: Peng Fan Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250430092043.1819308-2-xiaolei.wang@windriver.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit e412883920f8fc40160f945a3bdba75594afaccf Author: Wentao Liang Date: Mon May 26 10:56:27 2025 +0800 regulator: max14577: Add error check for max14577_read_reg() commit 65271f868cb1dca709ff69e45939bbef8d6d0b70 upstream. The function max14577_reg_get_current_limit() calls the function max14577_read_reg(), but does not check its return value. A proper implementation can be found in max14577_get_online(). Add a error check for the max14577_read_reg() and return error code if the function fails. Fixes: b0902bbeb768 ("regulator: max14577: Add regulator driver for Maxim 14577") Cc: stable@vger.kernel.org # v3.14 Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20250526025627.407-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 48b761b322971238e4806914d5629c2ab6052591 Author: André Almeida Date: Tue Apr 29 15:38:50 2025 -0300 ovl: Fix nested backing file paths commit 924577e4f6ca473de1528953a0e13505fae61d7b upstream. When the lowerdir of an overlayfs is a merged directory of another overlayfs, ovl_open_realfile() will fail to open the real file and point to a lower dentry copy, without the proper parent path. After this, d_path() will then display the path incorrectly as if the file is placed in the root directory. This bug can be triggered with the following setup: mkdir -p ovl-A/lower ovl-A/upper ovl-A/merge ovl-A/work mkdir -p ovl-B/upper ovl-B/merge ovl-B/work cp /bin/cat ovl-A/lower/ mount -t overlay overlay -o \ lowerdir=ovl-A/lower,upperdir=ovl-A/upper,workdir=ovl-A/work \ ovl-A/merge mount -t overlay overlay -o \ lowerdir=ovl-A/merge,upperdir=ovl-B/upper,workdir=ovl-B/work \ ovl-B/merge ovl-A/merge/cat /proc/self/maps | grep --color cat ovl-B/merge/cat /proc/self/maps | grep --color cat The first cat will correctly show `/ovl-A/merge/cat`, while the second one shows just `/cat`. To fix that, uses file_user_path() inside of backing_file_open() to get the correct file path for the dentry. Co-developed-by: John Schoenick Signed-off-by: John Schoenick Signed-off-by: André Almeida Fixes: def3ae83da02 ("fs: store real path instead of fake path in backing file f_path") Cc: # v6.7 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 8035243298c6df48dc9fc102c1469a5865828ac7 Author: Khem Raj Date: Sat Mar 29 08:39:03 2025 -0700 mips: Add -std= flag specified in KBUILD_CFLAGS to vdso CFLAGS commit 0f4ae7c6ecb89bfda026d210dcf8216fb67d2333 upstream. GCC 15 changed the default C standard dialect from gnu17 to gnu23, which should not have impacted the kernel because it explicitly requests the gnu11 standard in the main Makefile. However, mips/vdso code uses its own CFLAGS without a '-std=' value, which break with this dialect change because of the kernel's own definitions of bool, false, and true conflicting with the C23 reserved keywords. include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant 11 | false = 0, | ^~~~~ include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards include/linux/types.h:35:33: error: 'bool' cannot be defined via 'typedef' 35 | typedef _Bool bool; | ^~~~ include/linux/types.h:35:33: note: 'bool' is a keyword with '-std=c23' onwards Add -std as specified in KBUILD_CFLAGS to the decompressor and purgatory CFLAGS to eliminate these errors and make the C standard version of these areas match the rest of the kernel. Signed-off-by: Khem Raj Cc: stable@vger.kernel.org Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit ea02ebb794c1057b45baf350e8410312da452abc Author: Gabriel Shahrouzi Date: Sat Apr 19 21:30:09 2025 -0400 staging: iio: ad5933: Correct settling cycles encoding per datasheet commit 60638e2a2d4bc03798f00d5ab65ce9b83cb8b03b upstream. The AD5933 datasheet (Table 13) lists the maximum cycles to be 0x7FC (2044). Clamp the user input to the maximum effective value of 0x7FC cycles. Fixes: f94aa354d676 ("iio: impedance-analyzer: New driver for AD5933/4 Impedance Converter, Network Analyzer") Cc: stable@vger.kernel.org Signed-off-by: Gabriel Shahrouzi Reviewed-by: Marcelo Schmitt Link: https://patch.msgid.link/20250420013009.847851-1-gshahrouzi@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a41b428b22c59980f1d9a17ba3acc48c6b8f0ee5 Author: David Lechner Date: Thu May 29 11:53:20 2025 -0500 pwm: axi-pwmgen: fix missing separate external clock commit a8841dc3dfbf127a19c3612204bd336ee559b9a1 upstream. Add proper support for external clock to the AXI PWM generator driver. In most cases, the HDL for this IP block is compiled with the default ASYNC_CLK_EN=1. With this option, there is a separate external clock that drives the PWM output separate from the peripheral clock. So the driver should be enabling the "axi" clock to power the peripheral and the "ext" clock to drive the PWM output. When ASYNC_CLK_EN=0, the "axi" clock is also used to drive the PWM output and there is no "ext" clock. Previously, if there was a separate external clock, users had to specify only the external clock and (incorrectly) omit the AXI clock in order to get the correct operating frequency for the PWM output. The devicetree bindings are updated to fix this shortcoming and this patch changes the driver to match the new bindings. To preserve compatibility with any existing dtbs that specify only one clock, we don't require the clock name on the first clock. Fixes: 41814fe5c782 ("pwm: Add driver for AXI PWM generator") Cc: stable@vger.kernel.org Acked-by: Nuno Sá Reviewed-by: Trevor Gamblin Signed-off-by: David Lechner Link: https://lore.kernel.org/r/20250529-pwm-axi-pwmgen-add-external-clock-v3-3-5d8809a7da91@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit db1da838b6012e4570c6f81e28ffe1d0ff595948 Author: Shin'ichiro Kawasaki Date: Mon Jun 2 13:35:22 2025 +0900 nvme-tcp: remove tag set when second admin queue config fails commit e7143706702a209c814ed2c3fc6486c2a7decf6c upstream. Commit 104d0e2f6222 ("nvme-fabrics: reset admin connection for secure concatenation") modified nvme_tcp_setup_ctrl() to call nvme_tcp_configure_admin_queue() twice. The first call prepares for DH-CHAP negotitation, and the second call is required for secure concatenation. However, this change triggered BUG KASAN slab-use-after- free in blk_mq_queue_tag_busy_iter(). This BUG can be recreated by repeating the blktests test case nvme/063 a few times [1]. When the BUG happens, nvme_tcp_create_ctrl() fails in the call chain below: nvme_tcp_create_ctrl() nvme_tcp_alloc_ctrl() new=true ... Alloc nvme_tcp_ctrl and admin_tag_set nvme_tcp_setup_ctrl() new=true nvme_tcp_configure_admin_queue() new=true ... Succeed nvme_alloc_admin_tag_set() ... Alloc the tag set for admin_tag_set nvme_stop_keep_alive() nvme_tcp_teardown_admin_queue() remove=false nvme_tcp_configure_admin_queue() new=false nvme_tcp_alloc_admin_queue() ... Fail, but do not call nvme_remove_admin_tag_set() nvme_uninit_ctrl() nvme_put_ctrl() ... Free up the nvme_tcp_ctrl and admin_tag_set The first call of nvme_tcp_configure_admin_queue() succeeds with new=true argument. The second call fails with new=false argument. This second call does not call nvme_remove_admin_tag_set() on failure, due to the new=false argument. Then the admin tag set is not removed. However, nvme_tcp_create_ctrl() assumes that nvme_tcp_setup_ctrl() would call nvme_remove_admin_tag_set(). Then it frees up struct nvme_tcp_ctrl which has admin_tag_set field. Later on, the timeout handler accesses the admin_tag_set field and causes the BUG KASAN slab-use-after-free. To not leave the admin tag set, call nvme_remove_admin_tag_set() when the second nvme_tcp_configure_admin_queue() call fails. Do not return from nvme_tcp_setup_ctrl() on failure. Instead, jump to "destroy_admin" go-to label to call nvme_tcp_teardown_admin_queue() which calls nvme_remove_admin_tag_set(). Fixes: 104d0e2f6222 ("nvme-fabrics: reset admin connection for secure concatenation") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-nvme/6mhxskdlbo6fk6hotsffvwriauurqky33dfb3s44mqtr5dsxmf@gywwmnyh3twm/ [1] Signed-off-by: Shin'ichiro Kawasaki Reviewed-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni Reviewed-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit aeda386d86d79269a08f470dbdc53d13a91e51fa Author: Thomas Zimmermann Date: Wed May 28 10:02:08 2025 +0200 video: screen_info: Relocate framebuffers behind PCI bridges commit 2f29b5c231011b94007d2c8a6d793992f2275db1 upstream. Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes invalid access to I/O memory. Resources behind a PCI host bridge can be relocated by a certain offset in the kernel's CPU address range used for I/O. The framebuffer memory range stored in screen_info refers to the CPU addresses as seen during boot (where the offset is 0). During boot up, firmware may assign a different memory offset to the PCI host bridge and thereby relocating the framebuffer address of the PCI graphics device as seen by the kernel. The information in screen_info must be updated as well. The helper pcibios_bus_to_resource() performs the relocation of the screen_info's framebuffer resource (given in PCI bus addresses). The result matches the I/O-memory resource of the PCI graphics device (given in CPU addresses). As before, we store away the information necessary to later update the information in screen_info itself. Commit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated EFI framebuffers") added the code for updating screen_info. It is based on similar functionality that pre-existed in efifb. Efifb uses a pointer to the PCI resource, while the newer code does a memcpy of the region. Hence efifb sees any updates to the PCI resource and avoids the issue. v3: - Only use struct pci_bus_region for PCI bus addresses (Bjorn) - Clarify address semantics in commit messages and comments (Bjorn) v2: - Fixed tags (Takashi, Ivan) - Updated information on efifb Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Reported-by: "Ivan T. Ivanov" Closes: https://bugzilla.suse.com/show_bug.cgi?id=1240696 Tested-by: "Ivan T. Ivanov" Fixes: 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated EFI framebuffers") Cc: dri-devel@lists.freedesktop.org Cc: # v6.9+ Link: https://lore.kernel.org/r/20250528080234.7380-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit fbd54bf4a1a6ce1a6f368e6438ae40c3df57b653 Author: Thomas Zimmermann Date: Tue Jun 3 17:48:20 2025 +0200 sysfb: Fix screen_info type check for VGA commit f670b50ef5e4a69bf4d2ec5ac6a9228d93b13a7a upstream. Use the helper screen_info_video_type() to get the framebuffer type from struct screen_info. Handle supported values in sorted switch statement. Reading orig_video_isVGA is unreliable. On most systems it is a VIDEO_TYPE_ constant. On some systems with VGA it is simply set to 1 to signal the presence of a VGA output. See vga_probe() for an example. Retrieving the screen_info type with the helper screen_info_video_type() detects these cases and returns the appropriate VIDEO_TYPE_ constant. For VGA, sysfb creates a device named "vga-framebuffer". The sysfb code has been taken from vga16fb, where it likely didn't work correctly either. With this bugfix applied, vga16fb loads for compatible vga-framebuffer devices. Fixes: 0db5b61e0dc0 ("fbdev/vga16fb: Create EGA/VGA devices in sysfb code") Cc: Thomas Zimmermann Cc: Javier Martinez Canillas Cc: Alex Deucher Cc: Tzung-Bi Shih Cc: Helge Deller Cc: "Uwe Kleine-König" Cc: Zsolt Kajtar Cc: # v6.1+ Signed-off-by: Thomas Zimmermann Reviewed-by: Tzung-Bi Shih Reviewed-by: Javier Martinez Canillas Link: https://lore.kernel.org/r/20250603154838.401882-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 7ee6470a8099d589c8bc6dcf51c6bd8b6421da2c Author: Lorenzo Stoakes Date: Mon May 19 15:56:57 2025 +0100 KVM: s390: rename PROT_NONE to PROT_TYPE_DUMMY commit 15ac613f124e51a6623975efad9657b1f3ee47e7 upstream. The enum type prot_type declared in arch/s390/kvm/gaccess.c declares an unfortunate identifier within it - PROT_NONE. This clashes with the protection bit define from the uapi for mmap() declared in include/uapi/asm-generic/mman-common.h, which is indeed what those casually reading this code would assume this to refer to. This means that any changes which subsequently alter headers in any way which results in the uapi header being imported here will cause build errors. Resolve the issue by renaming PROT_NONE to PROT_TYPE_DUMMY. Link: https://lkml.kernel.org/r/20250519145657.178365-1-lorenzo.stoakes@oracle.com Fixes: b3cefd6bf16e ("KVM: s390: Pass initialized arg even if unused") Signed-off-by: Lorenzo Stoakes Suggested-by: Ignacio Moreno Gonzalez Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202505140943.IgHDa9s7-lkp@intel.com/ Acked-by: Christian Borntraeger Acked-by: Ignacio Moreno Gonzalez Acked-by: Yang Shi Reviewed-by: David Hildenbrand Acked-by: Liam R. Howlett Reviewed-by: Oscar Salvador Reviewed-by: Claudio Imbrenda Cc: Cc: Alexander Gordeev Cc: Heiko Carstens Cc: James Houghton Cc: Janosch Frank Cc: Matthew Wilcox (Oracle) Cc: Paolo Bonzini Cc: Sven Schnelle Cc: Vasily Gorbik Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cdaa6d1cb2ff1219c6c822b27655dd170ffb0f72 Author: Qasim Ijaz Date: Mon May 26 19:36:07 2025 +0100 net: ch9200: fix uninitialised access during mii_nway_restart commit 9ad0452c0277b816a435433cca601304cfac7c21 upstream. In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read(): if (err == size) { memcpy(data, buf, size); } If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read(): return (buff[0] | buff[1] << 8); The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff". To fix this we should check the return value of control_read() and return early on error. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=3361c2d6f78a3e0892f9 Tested-by: syzbot Fixes: 4a476bd6d1d9 ("usbnet: New driver for QinHeng CH9200 devices") Cc: stable@vger.kernel.org Signed-off-by: Qasim Ijaz Link: https://patch.msgid.link/20250526183607.66527-1-qasdev00@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6fc1ad3d24c5779e87b199a82a9241742cdfe109 Author: Xu Yang Date: Wed Apr 30 17:45:01 2025 +0800 phy: fsl-imx8mq-usb: fix phy_tx_vboost_level_from_property() commit b15ee09ddb987a122e74fb0fdf1bd6e864959fd3 upstream. The description of TX_VBOOST_LVL is wrong in register PHY_CTRL3 bit[31:29]. The updated description as below: 011: Corresponds to a launch amplitude of 0.844 V. 100: Corresponds to a launch amplitude of 1.008 V. 101: Corresponds to a launch amplitude of 1.156 V. This will fix the parsing function phy_tx_vboost_level_from_property() to return correct value. Fixes: 63c85ad0cd81 ("phy: fsl-imx8mp-usb: add support for phy tuning") Cc: stable@vger.kernel.org Reviewed-by: Jun Li Signed-off-by: Xu Yang Link: https://lore.kernel.org/r/20250430094502.2723983-3-xu.yang_2@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit b655b93329797b32c38d768e5f3f32bfa589c2e9 Author: John Garry Date: Sun May 4 11:26:45 2025 +0200 dm-table: Set BLK_FEAT_ATOMIC_WRITES for target queue limits commit b7c18b17a173087ce97e809cefd55e581121f19e upstream. Feature flag BLK_FEAT_ATOMIC_WRITES is not being properly set for the target queue limits, and this means that atomic writes are not being enabled for any dm personalities. When calling dm_set_device_limits() -> blk_stack_limits() -> ... -> blk_stack_atomic_writes_limits(), the bottom device limits (which corresponds to intermediate target queue limits) does not have BLK_FEAT_ATOMIC_WRITES set, and so atomic writes can never be enabled. Typically such a flag would be inherited from the stacked device in dm_set_device_limits() -> blk_stack_limits() via BLK_FEAT_INHERIT_MASK, but BLK_FEAT_ATOMIC_WRITES is not inherited as it's preferred to manually enable on a per-personality basis. Set BLK_FEAT_ATOMIC_WRITES manually for the intermediate target queue limits from the stacked device to get atomic writes working. Fixes: 3194e36488e2 ("dm-table: atomic writes support") Cc: stable@vger.kernel.org # v6.14 Signed-off-by: John Garry Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 079934c4f01f895507ea1f2573c6171569dab489 Author: Mikulas Patocka Date: Tue Apr 22 21:17:36 2025 +0200 dm: lock limits when reading them commit abb4cf2f4c1c1b637cad04d726f2e13fd3051e03 upstream. Lock queue limits when reading them, so that we don't read halfway modified values. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f78a786ad9a5443a29eef4dae60cde85b7375129 Author: Ye Bin Date: Thu May 29 19:19:54 2025 +0800 ftrace: Fix UAF when lookup kallsym after ftrace disabled commit f914b52c379c12288b7623bb814d0508dbe7481d upstream. The following issue happens with a buggy module: BUG: unable to handle page fault for address: ffffffffc05d0218 PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN PTI Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS RIP: 0010:sized_strscpy+0x81/0x2f0 RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000 RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68 R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038 R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff FS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ftrace_mod_get_kallsym+0x1ac/0x590 update_iter_mod+0x239/0x5b0 s_next+0x5b/0xa0 seq_read_iter+0x8c9/0x1070 seq_read+0x249/0x3b0 proc_reg_read+0x1b0/0x280 vfs_read+0x17f/0x920 ksys_read+0xf3/0x1c0 do_syscall_64+0x5f/0x2e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The above issue may happen as follows: (1) Add kprobe tracepoint; (2) insmod test.ko; (3) Module triggers ftrace disabled; (4) rmmod test.ko; (5) cat /proc/kallsyms; --> Will trigger UAF as test.ko already removed; ftrace_mod_get_kallsym() ... strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); ... The problem is when a module triggers an issue with ftrace and sets ftrace_disable. The ftrace_disable is set when an anomaly is discovered and to prevent any more damage, ftrace stops all text modification. The issue that happened was that the ftrace_disable stops more than just the text modification. When a module is loaded, its init functions can also be traced. Because kallsyms deletes the init functions after a module has loaded, ftrace saves them when the module is loaded and function tracing is enabled. This allows the output of the function trace to show the init function names instead of just their raw memory addresses. When a module is removed, ftrace_release_mod() is called, and if ftrace_disable is set, it just returns without doing anything more. The problem here is that it leaves the mod_list still around and if kallsyms is called, it will call into this code and access the module memory that has already been freed as it will return: strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); Where the "mod" no longer exists and triggers a UAF bug. Link: https://lore.kernel.org/all/20250523135452.626d8dcd@gandalf.local.home/ Cc: stable@vger.kernel.org Fixes: aba4b5c22cba ("ftrace: Save module init functions kallsyms symbols for tracing") Link: https://lore.kernel.org/20250529111955.2349189-2-yebin@huaweicloud.com Signed-off-by: Ye Bin Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 2560e867c8b792ca46f9cb47a5dfb6f3a68da6ff Author: Md Sadre Alam Date: Thu Apr 10 15:30:19 2025 +0530 mtd: rawnand: qcom: Fix read len for onfi param page commit e6031b11544b44966ba020c867fe438bccd3bdfa upstream. The minimum size to fetch the data from device to QPIC buffer is 512-bytes. If size is less than 512-bytes the data will not be protected by ECC as per QPIC standard. So while reading onfi parameter page from NAND device set nandc->buf_count = 512. Cc: stable@vger.kernel.org Fixes: 89550beb098e ("mtd: rawnand: qcom: Implement exec_op()") Reviewed-by: Manivannan Sadhasivam Tested-by: Lakshmi Sowjanya D Signed-off-by: Md Sadre Alam Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit ba2673579b9902de87b2202fc1dae4b92497101c Author: Md Sadre Alam Date: Thu Apr 10 15:30:18 2025 +0530 mtd: rawnand: qcom: Fix last codeword read in qcom_param_page_type_exec() commit 47bddabbf69da50999ec68be92b58356c687e1d6 upstream. For QPIC V2 onwards there is a separate register to read last code word "QPIC_NAND_READ_LOCATION_LAST_CW_n". qcom_param_page_type_exec() is used to read only one code word If it configures the number of code words to 1 in QPIC_NAND_DEV0_CFG0 register then QPIC controller thinks its reading the last code word, since we are having separate register to read the last code word, we have to configure "QPIC_NAND_READ_LOCATION_LAST_CW_n" register to fetch data from QPIC buffer to system memory. Without this change page read was failing with timeout error / # hexdump -C /dev/mtd1 [ 129.206113] qcom-nandc 1cc8000.nand-controller: failure to read page/oob hexdump: /dev/mtd1: Connection timed out This issue only seen on SDX targets since SDX target used QPICv2. But same working on IPQ targets since IPQ used QPICv1. Cc: stable@vger.kernel.org Fixes: 89550beb098e ("mtd: rawnand: qcom: Implement exec_op()") Reviewed-by: Manivannan Sadhasivam Tested-by: Lakshmi Sowjanya D Signed-off-by: Md Sadre Alam Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit c990e0c453c7c4e80b0d6fb8f0e8e02b63bfac22 Author: Md Sadre Alam Date: Thu Apr 10 15:30:17 2025 +0530 mtd: rawnand: qcom: Pass 18 bit offset from NANDc base to BAM base commit ee000969f28bf579d3772bf7c0ae8aff86586e20 upstream. The BAM command descriptor provides only 18 bits to specify the BAM register offset. Additionally, in the BAM command descriptor, the BAM register offset is supposed to be specified as "(NANDc base - BAM base) + reg_off". Since, the BAM controller expecting the value in the form of "NANDc base - BAM base", so that added a new field 'bam_offset' in the NAND properties structure and use it while preparing the command descriptor. Previously, the driver was specifying the NANDc base address in the BAM command descriptor. Cc: stable@vger.kernel.org Fixes: 8d6b6d7e135e ("mtd: nand: qcom: support for command descriptor formation") Tested-by: Lakshmi Sowjanya D Signed-off-by: Md Sadre Alam Acked-by: Mark Brown Tested-by: Gabor Juhos # on IPQ9574 Reviewed-by: Manivannan Sadhasivam Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 08a55a025c5f64c8a44d5dab3f7704098a38a771 Author: Mikulas Patocka Date: Tue Jun 3 18:55:50 2025 +0200 dm-verity: fix a memory leak if some arguments are specified multiple times commit 66be40a14e496689e1f0add50118408e22c96169 upstream. If some of the arguments "check_at_most_once", "ignore_zero_blocks", "use_fec_from_device", "root_hash_sig_key_desc" were specified more than once on the target line, a memory leak would happen. This commit fixes the memory leak. It also fixes error handling in verity_verify_sig_parse_opt_args. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0a52ab52a91d4fa4d6ef7334b47c05d962fd2ab8 Author: Mikulas Patocka Date: Tue Jun 3 18:53:17 2025 +0200 dm-mirror: fix a tiny race condition commit 829451beaed6165eb11d7a9fb4e28eb17f489980 upstream. There's a tiny race condition in dm-mirror. The functions queue_bio and write_callback grab a spinlock, add a bio to the list, drop the spinlock and wake up the mirrord thread that processes bios in the list. It may be possible that the mirrord thread processes the bio just after spin_unlock_irqrestore is called, before wakeup_mirrord. This spurious wake-up is normally harmless, however if the device mapper device is unloaded just after the bio was processed, it may be possible that wakeup_mirrord(ms) uses invalid "ms" pointer. Fix this bug by moving wakeup_mirrord inside the spinlock. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d5d1be99ce8f0cb08224eae63de65b3745ef6dec Author: Chao Gao Date: Mon Mar 24 22:08:48 2025 +0800 KVM: VMX: Flush shadow VMCS on emergency reboot commit a0ee1d5faff135e28810f29e0f06328c66f89852 upstream. Ensure the shadow VMCS cache is evicted during an emergency reboot to prevent potential memory corruption if the cache is evicted after reboot. This issue was identified through code inspection, as __loaded_vmcs_clear() flushes both the normal VMCS and the shadow VMCS. Avoid checking the "launched" state during an emergency reboot, unlike the behavior in __loaded_vmcs_clear(). This is important because reboot NMIs can interfere with operations like copy_shadow_to_vmcs12(), where shadow VMCSes are loaded directly using VMPTRLD. In such cases, if NMIs occur right after the VMCS load, the shadow VMCSes will be active but the "launched" state may not be set. Fixes: 16f5b9034b69 ("KVM: nVMX: Copy processor-specific shadow-vmcs to VMCS12") Cc: stable@vger.kernel.org Signed-off-by: Chao Gao Reviewed-by: Kai Huang Link: https://lore.kernel.org/r/20250324140849.2099723-1-chao.gao@intel.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 146129fbd339797ef843bcdc022f52af70646009 Author: Yosry Ahmed Date: Tue Apr 29 08:32:15 2025 -0700 KVM: SVM: Clear current_vmcb during vCPU free for all *possible* CPUs commit 1bee4838eb3a2c689f23c7170ea66ae87ea7d93a upstream. When freeing a vCPU and thus its VMCB, clear current_vmcb for all possible CPUs, not just online CPUs, as it's theoretically possible a CPU could go offline and come back online in conjunction with KVM reusing the page for a new VMCB. Link: https://lore.kernel.org/all/20250320013759.3965869-1-yosry.ahmed@linux.dev Fixes: fd65d3142f73 ("kvm: svm: Ensure an IBPB on all affected CPUs when freeing a vmcb") Cc: stable@vger.kernel.org Cc: Jim Mattson Signed-off-by: Yosry Ahmed [sean: split to separate patch, write changelog] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit e2da605f84e0b6a372d29989fd61dfa9732bde36 Author: Wentao Liang Date: Mon May 19 23:42:24 2025 +0800 mtd: nand: sunxi: Add randomizer configuration before randomizer enable commit 4a5a99bc79cdc4be63933653682b0261a67a0c9f upstream. In sunxi_nfc_hw_ecc_read_chunk(), the sunxi_nfc_randomizer_enable() is called without the config of randomizer. A proper implementation can be found in sunxi_nfc_hw_ecc_read_chunks_dma(). Add sunxi_nfc_randomizer_config() before the start of randomization. Fixes: 4be4e03efc7f ("mtd: nand: sunxi: add randomizer support") Cc: stable@vger.kernel.org # v4.6 Signed-off-by: Wentao Liang Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit c3b4cfeb37f9da12bfdb3992985b4902a6182411 Author: Wentao Liang Date: Mon May 26 11:43:44 2025 +0800 mtd: rawnand: sunxi: Add randomizer configuration in sunxi_nfc_hw_ecc_write_chunk commit 44ed1f5ff73e9e115b6f5411744d5a22ea1c855b upstream. The function sunxi_nfc_hw_ecc_write_chunk() calls the sunxi_nfc_hw_ecc_write_chunk(), but does not call the configuration function sunxi_nfc_randomizer_config(). Consequently, the randomization might not conduct correctly, which will affect the lifespan of NAND flash. A proper implementation can be found in sunxi_nfc_hw_ecc_write_page_dma(). Add the sunxi_nfc_randomizer_config() to config randomizer. Fixes: 4be4e03efc7f ("mtd: nand: sunxi: add randomizer support") Cc: stable@vger.kernel.org # v4.6 Signed-off-by: Wentao Liang Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 92ab6e9ff6254208a79c076956e8987c6d49a918 Author: Lu Baolu Date: Thu Apr 24 11:41:23 2025 +0800 iommu: Allow attaching static domains in iommu_attach_device_pasid() commit 6f7340120a0aa8b2eb29c826a4434e8b5c4e11d3 upstream. The idxd driver attaches the default domain to a PASID of the device to perform kernel DMA using that PASID. The domain is attached to the device's PASID through iommu_attach_device_pasid(), which checks if the domain->owner matches the iommu_ops retrieved from the device. If they do not match, it returns a failure. if (ops != domain->owner || pasid == IOMMU_NO_PASID) return -EINVAL; The static identity domain implemented by the intel iommu driver doesn't specify the domain owner. Therefore, kernel DMA with PASID doesn't work for the idxd driver if the device translation mode is set to passthrough. Generally the owner field of static domains are not set because they are already part of iommu ops. Add a helper domain_iommu_ops_compatible() that checks if a domain is compatible with the device's iommu ops. This helper explicitly allows the static blocked and identity domains associated with the device's iommu_ops to be considered compatible. Fixes: 2031c469f816 ("iommu/vt-d: Add support for static identity domain") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220031 Cc: stable@vger.kernel.org Suggested-by: Jason Gunthorpe Link: https://lore.kernel.org/linux-iommu/20250422191554.GC1213339@ziepe.ca/ Signed-off-by: Lu Baolu Reviewed-by: Dave Jiang Reviewed-by: Robin Murphy Reviewed-by: Jason Gunthorpe Reviewed-by: Vasant Hegde Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20250424034123.2311362-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit bb9296b7ad2089a6b6404cb1c9d34d4d7e6a6e82 Author: Sibi Sankar Date: Tue Apr 29 15:11:06 2025 +0100 firmware: arm_scmi: Ensure that the message-id supports fastchannel commit 94a263f981a3fa3d93f65c31e0fed0756736be43 upstream. Currently the perf and powercap protocol relies on the protocol domain attributes, which just ensures that one fastchannel per domain, before instantiating fastchannels for all possible message-ids. Fix this by ensuring that each message-id supports fastchannel before initialization. Logs: | scmi: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:0] - ret:-95. Using regular messaging | scmi: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:1] - ret:-95. Using regular messaging | scmi: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:2] - ret:-95. Using regular messaging CC: stable@vger.kernel.org Reported-by: Johan Hovold Closes: https://lore.kernel.org/lkml/ZoQjAWse2YxwyRJv@hovoldconsulting.com/ Fixes: 6f9ea4dabd2d ("firmware: arm_scmi: Generalize the fast channel support") Reviewed-by: Johan Hovold Tested-by: Johan Hovold Signed-off-by: Sibi Sankar [Cristian: Modified the condition checked to establish support or not] Signed-off-by: Cristian Marussi Message-Id: <20250429141108.406045-2-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman commit 029a3d3e80503e065271c355ab19c36d88d07039 Author: Kendall Willis Date: Mon Apr 28 15:53:36 2025 -0500 firmware: ti_sci: Convert CPU latency constraint from us to ms commit 9b808f7f395ae375a26e32046b680cf898dacc21 upstream. Fix CPU resume latency constraint units sent to device manager through the TI SCI API. The device manager expects CPU resume latency to be in msecs which is passed in with the TI SCI API [1]. CPU latency constraints are set in userspace using the PM QoS framework which uses usecs as the unit. Since PM QoS uses usecs for units and the device manager expects msecs as the unit, TI SCI needs to convert from usecs to msecs before passing to device manager. [1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html#tisci-msg-lpm-set-latency-constraint Cc: stable@vger.kernel.org Fixes: a7a15754c7f7 ("firmware: ti_sci: add CPU latency constraint management") Signed-off-by: Kendall Willis Link: https://lore.kernel.org/r/20250428205336.2947118-1-k-willis@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Greg Kroah-Hartman commit cefbafcbdef011d6ef9414902311afdfba3c33eb Author: Dan Williams Date: Wed Apr 30 13:33:31 2025 -0700 configfs-tsm-report: Fix NULL dereference of tsm_ops commit fba4ceaa242d2bdf4c04b77bda41d32d02d3925d upstream. Unlike sysfs, the lifetime of configfs objects is controlled by userspace. There is no mechanism for the kernel to find and delete all created config-items. Instead, the configfs-tsm-report mechanism has an expectation that tsm_unregister() can happen at any time and cause established config-item access to start failing. That expectation is not fully satisfied. While tsm_report_read(), tsm_report_{is,is_bin}_visible(), and tsm_report_make_item() safely fail if tsm_ops have been unregistered, tsm_report_privlevel_store() tsm_report_provider_show() fail to check for ops registration. Add the missing checks for tsm_ops having been removed. Now, in supporting the ability for tsm_unregister() to always succeed, it leaves the problem of what to do with lingering config-items. The expectation is that the admin that arranges for the ->remove() (unbind) of the ${tsm_arch}-guest driver is also responsible for deletion of all open config-items. Until that deletion happens, ->probe() (reload / bind) of the ${tsm_arch}-guest driver fails. This allows for emergency shutdown / revocation of attestation interfaces, and requires coordinated restart. Fixes: 70e6f7e2b985 ("configfs-tsm: Introduce a shared ABI for attestation reports") Cc: stable@vger.kernel.org Cc: Suzuki K Poulose Cc: Steven Price Cc: Sami Mujawar Cc: Borislav Petkov (AMD) Cc: Tom Lendacky Reviewed-by: Kuppuswamy Sathyanarayanan Reported-by: Cedric Xing Reviewed-by: Kai Huang Link: https://patch.msgid.link/20250430203331.1177062-1-dan.j.williams@intel.com Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 21ca2f3ecd66a4c6ec37381fbd60313df8e4a2ec Author: Johan Hovold Date: Mon Mar 24 14:24:48 2025 +0100 soc: qcom: pmic_glink_altmode: fix spurious DP hotplug events commit 5090ac9191a19c61beeade60d3d839e509fab640 upstream. The PMIC GLINK driver is currently generating DisplayPort hotplug notifications whenever something is connected to (or disconnected from) a port regardless of the type of notification sent by the firmware. These notifications are forwarded to user space by the DRM subsystem as connector "change" uevents: KERNEL[1556.223776] change /devices/platform/soc@0/ae00000.display-subsystem/ae01000.display-controller/drm/card0 (drm) ACTION=change DEVPATH=/devices/platform/soc@0/ae00000.display-subsystem/ae01000.display-controller/drm/card0 SUBSYSTEM=drm HOTPLUG=1 CONNECTOR=36 DEVNAME=/dev/dri/card0 DEVTYPE=drm_minor SEQNUM=4176 MAJOR=226 MINOR=0 On the Lenovo ThinkPad X13s and T14s, the PMIC GLINK firmware sends two identical notifications with orientation information when connecting a charger, each generating a bogus DRM hotplug event. On the X13s, two such notification are also sent every 90 seconds while a charger remains connected, which again are forwarded to user space: port = 1, svid = ff00, mode = 255, hpd_state = 0 payload = 01 00 00 00 00 00 00 ff 00 00 00 00 00 00 00 00 Note that the firmware only sends on of these when connecting an ethernet adapter. Fix the spurious hotplug events by only forwarding hotplug notifications for the Type-C DisplayPort service id. This also reduces the number of uevents from four to two when an actual DisplayPort altmode device is connected: port = 0, svid = ff01, mode = 2, hpd_state = 0 payload = 00 01 02 00 f2 0c 01 ff 03 00 00 00 00 00 00 00 port = 0, svid = ff01, mode = 2, hpd_state = 1 payload = 00 01 02 00 f2 0c 01 ff 43 00 00 00 00 00 00 00 Fixes: 080b4e24852b ("soc: qcom: pmic_glink: Introduce altmode support") Cc: stable@vger.kernel.org # 6.3 Cc: Bjorn Andersson Reported-by: Clayton Craft Signed-off-by: Johan Hovold Acked-by: Konrad Dybcio Tested-by: Clayton Craft Link: https://lore.kernel.org/r/20250324132448.6134-1-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 2b065fd4d5663e14f30609b3b0561f9656699c9d Author: Jinliang Zheng Date: Tue Apr 15 17:02:32 2025 +0800 mm: fix ratelimit_pages update error in dirty_ratio_handler() commit f83f362d40ccceb647f7d80eb92206733d76a36b upstream. In dirty_ratio_handler(), vm_dirty_bytes must be set to zero before calling writeback_set_ratelimit(), as global_dirty_limits() always prioritizes the value of vm_dirty_bytes. It's domain_dirty_limits() that's relevant here, not node_dirty_ok: dirty_ratio_handler writeback_set_ratelimit global_dirty_limits(&dirty_thresh) <- ratelimit_pages based on dirty_thresh domain_dirty_limits if (bytes) <- bytes = vm_dirty_bytes <--------+ thresh = f1(bytes) <- prioritizes vm_dirty_bytes | else | thresh = f2(ratio) | ratelimit_pages = f3(dirty_thresh) | vm_dirty_bytes = 0 <- it's late! ---------------------+ This causes ratelimit_pages to still use the value calculated based on vm_dirty_bytes, which is wrong now. The impact visible to userspace is difficult to capture directly because there is no procfs/sysfs interface exported to user space. However, it will have a real impact on the balance of dirty pages. For example: 1. On default, we have vm_dirty_ratio=40, vm_dirty_bytes=0 2. echo 8192 > dirty_bytes, then vm_dirty_bytes=8192, vm_dirty_ratio=0, and ratelimit_pages is calculated based on vm_dirty_bytes now. 3. echo 20 > dirty_ratio, then since vm_dirty_bytes is not reset to zero when writeback_set_ratelimit() -> global_dirty_limits() -> domain_dirty_limits() is called, reallimit_pages is still calculated based on vm_dirty_bytes instead of vm_dirty_ratio. This does not conform to the actual intent of the user. Link: https://lkml.kernel.org/r/20250415090232.7544-1-alexjlzheng@tencent.com Fixes: 9d823e8f6b1b ("writeback: per task dirty rate limit") Signed-off-by: Jinliang Zheng Reviewed-by: MengEn Sun Cc: Andrea Righi Cc: Fenggaung Wu Cc: Jinliang Zheng Cc: Matthew Wilcox (Oracle) Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit fd960b5ddf4faf00da43babdd3acda68842e1f6a Author: Shin'ichiro Kawasaki Date: Sat May 10 19:10:36 2025 +0900 RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction commit 6883b680e703c6b2efddb4e7a8d891ce1803d06b upstream. The commit 59c68ac31e15 ("iw_cm: free cm_id resources on the last deref") simplified cm_id resource management by freeing cm_id once all references to the cm_id were removed. The references are removed either upon completion of iw_cm event handlers or when the application destroys the cm_id. This commit introduced the use-after-free condition where cm_id_private object could still be in use by event handler works during the destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs") addressed this use-after- free by flushing all pending works at the cm_id destruction. However, still another use-after-free possibility remained. It happens with the work objects allocated for each cm_id_priv within alloc_work_entries() during cm_id creation, and subsequently freed in dealloc_work_entries() once all references to the cm_id are removed. If the cm_id's last reference is decremented in the event handler work, the work object for the work itself gets removed, and causes the use- after-free BUG below: BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091 CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iw_cm_wq) Call Trace: dump_stack_lvl+0x6a/0x90 print_report+0x174/0x554 ? __virt_addr_valid+0x208/0x430 ? __pwq_activate_work+0x1ff/0x250 kasan_report+0xae/0x170 ? __pwq_activate_work+0x1ff/0x250 __pwq_activate_work+0x1ff/0x250 pwq_dec_nr_in_flight+0x8c5/0xfb0 process_one_work+0xc11/0x1460 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x16c/0x240 worker_thread+0x5ef/0xfd0 ? __pfx_worker_thread+0x10/0x10 kthread+0x3b0/0x770 ? __pfx_kthread+0x10/0x10 ? rcu_is_watching+0x11/0xb0 ? _raw_spin_unlock_irq+0x24/0x50 ? rcu_is_watching+0x11/0xb0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 147416: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 alloc_work_entries+0xa9/0x260 [iw_cm] iw_cm_connect+0x23/0x4a0 [iw_cm] rdma_connect_locked+0xbfd/0x1920 [rdma_cm] nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma] cma_cm_event_handler+0xae/0x320 [rdma_cm] cma_work_handler+0x106/0x1b0 [rdma_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 147091: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kfree+0x13a/0x4b0 dealloc_work_entries+0x125/0x1f0 [iw_cm] iwcm_deref_id+0x6f/0xa0 [iw_cm] cm_work_handler+0x136/0x1ba0 [iw_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x2c/0x50 kasan_record_aux_stack+0xa3/0xb0 __queue_work+0x2ff/0x1390 queue_work_on+0x67/0xc0 cm_event_handler+0x46a/0x820 [iw_cm] siw_cm_upcall+0x330/0x650 [siw] siw_cm_work_handler+0x6b9/0x2b20 [siw] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 This BUG is reproducible by repeating the blktests test case nvme/061 for the rdma transport and the siw driver. To avoid the use-after-free of cm_id_private work objects, ensure that the last reference to the cm_id is decremented not in the event handler works, but in the cm_id destruction context. For that purpose, move iwcm_deref_id() call from destroy_cm_id() to the callers of destroy_cm_id(). In iw_destroy_cm_id(), call iwcm_deref_id() after flushing the pending works. During the fix work, I noticed that iw_destroy_cm_id() is called from cm_work_handler() and process_event() context. However, the comment of iw_destroy_cm_id() notes that the function "cannot be called by the event thread". Drop the false comment. Closes: https://lore.kernel.org/linux-rdma/r5676e754sv35aq7cdsqrlnvyhiq5zktteaurl7vmfih35efko@z6lay7uypy3c/ Fixes: 59c68ac31e15 ("iw_cm: free cm_id resources on the last deref") Cc: stable@vger.kernel.org Signed-off-by: Shin'ichiro Kawasaki Link: https://patch.msgid.link/20250510101036.1756439-1-shinichiro.kawasaki@wdc.com Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 26b167fa359bce943f9cdb03e9b18494bb671cc9 Author: Luo Gengkun Date: Mon Apr 21 03:50:21 2025 +0000 watchdog: fix watchdog may detect false positive of softlockup commit 7123dbbef88cfd9f09e8a7899b0911834600cfa3 upstream. When updating `watchdog_thresh`, there is a race condition between writing the new `watchdog_thresh` value and stopping the old watchdog timer. If the old timer triggers during this window, it may falsely detect a softlockup due to the old interval and the new `watchdog_thresh` value being used. The problem can be described as follow: # We asuume previous watchdog_thresh is 60, so the watchdog timer is # coming every 24s. echo 10 > /proc/sys/kernel/watchdog_thresh (User space) | +------>+ update watchdog_thresh (We are in kernel now) | | # using old interval and new `watchdog_thresh` +------>+ watchdog hrtimer (irq context: detect softlockup) | | +-------+ | | + softlockup_stop_all To fix this problem, introduce a shadow variable for `watchdog_thresh`. The update to the actual `watchdog_thresh` is delayed until after the old timer is stopped, preventing false positives. The following testcase may help to understand this problem. --------------------------------------------- echo RT_RUNTIME_SHARE > /sys/kernel/debug/sched/features echo -1 > /proc/sys/kernel/sched_rt_runtime_us echo 0 > /sys/kernel/debug/sched/fair_server/cpu3/runtime echo 60 > /proc/sys/kernel/watchdog_thresh taskset -c 3 chrt -r 99 /bin/bash -c "while true;do true; done" & echo 10 > /proc/sys/kernel/watchdog_thresh & --------------------------------------------- The test case above first removes the throttling restrictions for real-time tasks. It then sets watchdog_thresh to 60 and executes a real-time task ,a simple while(1) loop, on cpu3. Consequently, the final command gets blocked because the presence of this real-time thread prevents kworker:3 from being selected by the scheduler. This eventually triggers a softlockup detection on cpu3 due to watchdog_timer_fn operating with inconsistent variable - using both the old interval and the updated watchdog_thresh simultaneously. [nysal@linux.ibm.com: fix the SOFTLOCKUP_DETECTOR=n case] Link: https://lkml.kernel.org/r/20250502111120.282690-1-nysal@linux.ibm.com Link: https://lkml.kernel.org/r/20250421035021.3507649-1-luogengkun@huaweicloud.com Signed-off-by: Luo Gengkun Signed-off-by: Nysal Jan K.A. Cc: Doug Anderson Cc: Joel Granados Cc: Song Liu Cc: Thomas Gleinxer Cc: "Nysal Jan K.A." Cc: Venkat Rao Bagalkote Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b0b6bf90ce2699a574b3683e22c44d0dcdd7a057 Author: Jeongjun Park Date: Thu Apr 24 23:33:22 2025 +0900 ipc: fix to protect IPCS lookups using RCU commit d66adabe91803ef34a8b90613c81267b5ded1472 upstream. syzbot reported that it discovered a use-after-free vulnerability, [0] [0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/ idr_for_each() is protected by rwsem, but this is not enough. If it is not protected by RCU read-critical region, when idr_for_each() calls radix_tree_node_free() through call_rcu() to free the radix_tree_node structure, the node will be freed immediately, and when reading the next node in radix_tree_for_each_slot(), the already freed memory may be read. Therefore, we need to add code to make sure that idr_for_each() is protected within the RCU read-critical region when we call it in shm_destroy_orphaned(). Link: https://lkml.kernel.org/r/20250424143322.18830-1-aha310510@gmail.com Fixes: b34a6b1da371 ("ipc: introduce shm_rmid_forced sysctl") Signed-off-by: Jeongjun Park Reported-by: syzbot+a2b84e569d06ca3a949c@syzkaller.appspotmail.com Cc: Jeongjun Park Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Vasiliy Kulikov Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 43210a87a12f34dcd80345cf83b3a1d3a04e8d17 Author: Da Xue Date: Mon May 12 10:26:16 2025 -0400 clk: meson-g12a: add missing fclk_div2 to spicc commit daf004f87c3520c414992893e2eadd5db5f86a5a upstream. SPICC is missing fclk_div2, which means fclk_div5 and fclk_div7 indexes are wrong on this clock. This causes the spicc module to output sclk at 2.5x the expected rate when clock index 3 is picked. Adding the missing fclk_div2 resolves this. [jbrunet: amended commit description] Fixes: a18c8e0b7697 ("clk: meson: g12a: add support for the SPICC SCLK Source clocks") Cc: stable@vger.kernel.org # 6.1 Signed-off-by: Da Xue Reviewed-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20250512142617.2175291-1-da@libre.computer Signed-off-by: Jerome Brunet Signed-off-by: Greg Kroah-Hartman commit ce4da1e3476f45fd0e3f16057fa1ffdbe6b2c4ab Author: Arnd Bergmann Date: Tue May 20 11:00:46 2025 +0200 parisc: fix building with gcc-15 commit 7cbb015e2d3d6f180256cde0c908eab21268e7b9 upstream. The decompressor is built with the default C dialect, which is now gnu23 on gcc-15, and this clashes with the kernel's bool type definition: In file included from include/uapi/linux/posix_types.h:5, from arch/parisc/boot/compressed/misc.c:7: include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant 11 | false = 0, Add the -std=gnu11 argument here, as we do for all other architectures. Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 499b77fa1416a85fee106e60b240e912bca10cb8 Author: GONG Ruiqi Date: Sun Apr 27 10:53:03 2025 +0800 vgacon: Add check for vc_origin address range in vgacon_scroll() commit 864f9963ec6b4b76d104d595ba28110b87158003 upstream. Our in-house Syzkaller reported the following BUG (twice), which we believed was the same issue with [1]: ================================================================== BUG: KASAN: slab-out-of-bounds in vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740 Read of size 2 at addr ffff88800f5bef60 by task syz.7.2620/12393 ... Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106 print_address_description.constprop.0+0x6b/0x3d0 mm/kasan/report.c:364 print_report+0xba/0x280 mm/kasan/report.c:475 kasan_report+0xa9/0xe0 mm/kasan/report.c:588 vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740 vcs_write_buf_noattr drivers/tty/vt/vc_screen.c:493 [inline] vcs_write+0x586/0x840 drivers/tty/vt/vc_screen.c:690 vfs_write+0x219/0x960 fs/read_write.c:584 ksys_write+0x12e/0x260 fs/read_write.c:639 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ... Allocated by task 5614: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:374 [inline] __kasan_kmalloc+0x8f/0xa0 mm/kasan/common.c:383 kasan_kmalloc include/linux/kasan.h:201 [inline] __do_kmalloc_node mm/slab_common.c:1007 [inline] __kmalloc+0x62/0x140 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] kzalloc include/linux/slab.h:721 [inline] vc_do_resize+0x235/0xf40 drivers/tty/vt/vt.c:1193 vgacon_adjust_height+0x2d4/0x350 drivers/video/console/vgacon.c:1007 vgacon_font_set+0x1f7/0x240 drivers/video/console/vgacon.c:1031 con_font_set drivers/tty/vt/vt.c:4628 [inline] con_font_op+0x4da/0xa20 drivers/tty/vt/vt.c:4675 vt_k_ioctl+0xa10/0xb30 drivers/tty/vt/vt_ioctl.c:474 vt_ioctl+0x14c/0x1870 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0x655/0x1510 drivers/tty/tty_io.c:2779 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Last potentially related work creation: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492 __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713 netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802 __sock_release+0xb5/0x270 net/socket.c:663 sock_close+0x1e/0x30 net/socket.c:1425 __fput+0x408/0xab0 fs/file_table.c:384 __fput_sync+0x4c/0x60 fs/file_table.c:465 __do_sys_close fs/open.c:1580 [inline] __se_sys_close+0x68/0xd0 fs/open.c:1565 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Second to last potentially related work creation: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492 __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713 netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802 __sock_release+0xb5/0x270 net/socket.c:663 sock_close+0x1e/0x30 net/socket.c:1425 __fput+0x408/0xab0 fs/file_table.c:384 task_work_run+0x154/0x240 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:45 [inline] do_exit+0x8e5/0x1320 kernel/exit.c:874 do_group_exit+0xcd/0x280 kernel/exit.c:1023 get_signal+0x1675/0x1850 kernel/signal.c:2905 arch_do_signal_or_restart+0x80/0x3b0 arch/x86/kernel/signal.c:310 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x1b3/0x1e0 kernel/entry/common.c:218 do_syscall_64+0x66/0x110 arch/x86/entry/common.c:87 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The buggy address belongs to the object at ffff88800f5be000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 2656 bytes to the right of allocated 1280-byte region [ffff88800f5be000, ffff88800f5be500) ... Memory state around the buggy address: ffff88800f5bee00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800f5bee80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800f5bef00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88800f5bef80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800f5bf000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== By analyzing the vmcore, we found that vc->vc_origin was somehow placed one line prior to vc->vc_screenbuf when vc was in KD_TEXT mode, and further writings to /dev/vcs caused out-of-bounds reads (and writes right after) in vcs_write_buf_noattr(). Our further experiments show that in most cases, vc->vc_origin equals to vga_vram_base when the console is in KD_TEXT mode, and it's around vc->vc_screenbuf for the KD_GRAPHICS mode. But via triggerring a TIOCL_SETVESABLANK ioctl beforehand, we can make vc->vc_origin be around vc->vc_screenbuf while the console is in KD_TEXT mode, and then by writing the special 'ESC M' control sequence to the tty certain times (depends on the value of `vc->state.y - vc->vc_top`), we can eventually move vc->vc_origin prior to vc->vc_screenbuf. Here's the PoC, tested on QEMU: ``` int main() { const int RI_NUM = 10; // should be greater than `vc->state.y - vc->vc_top` int tty_fd, vcs_fd; const char *tty_path = "/dev/tty0"; const char *vcs_path = "/dev/vcs"; const char escape_seq[] = "\x1bM"; // ESC + M const char trigger_seq[] = "Let's trigger an OOB write."; struct vt_sizes vt_size = { 70, 2 }; int blank = TIOCL_BLANKSCREEN; tty_fd = open(tty_path, O_RDWR); char vesa_mode[] = { TIOCL_SETVESABLANK, 1 }; ioctl(tty_fd, TIOCLINUX, vesa_mode); ioctl(tty_fd, TIOCLINUX, &blank); ioctl(tty_fd, VT_RESIZE, &vt_size); for (int i = 0; i < RI_NUM; ++i) write(tty_fd, escape_seq, sizeof(escape_seq) - 1); vcs_fd = open(vcs_path, O_RDWR); write(vcs_fd, trigger_seq, sizeof(trigger_seq)); close(vcs_fd); close(tty_fd); return 0; } ``` To solve this problem, add an address range validation check in vgacon_scroll(), ensuring vc->vc_origin never precedes vc_screenbuf. Reported-by: syzbot+9c09fda97a1a65ea859b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9c09fda97a1a65ea859b [1] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Co-developed-by: Yi Yang Signed-off-by: Yi Yang Signed-off-by: GONG Ruiqi Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 390ea185434084ce364882d31411b878dd0e244d Author: Helge Deller Date: Sat May 31 15:26:27 2025 +0200 parisc/unaligned: Fix hex output to show 8 hex chars commit 213205889d5ffc19cb8df06aa6778b2d4724c887 upstream. Change back printk format to 0x%08lx instead of %#08lx, since the latter does not seem to reliably format the value to 8 hex chars. Signed-off-by: Helge Deller Cc: stable@vger.kernel.org # v5.18+ Fixes: e5e9e7f222e5b ("parisc/unaligned: Enhance user-space visible output") Signed-off-by: Greg Kroah-Hartman commit 8a3a2887794b2c8e78b3e5d6e3de724527c9f41b Author: Murad Masimov Date: Mon Apr 28 18:34:07 2025 +0300 fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var commit 05f6e183879d9785a3cdf2f08a498bc31b7a20aa upstream. If fb_add_videomode() in fb_set_var() fails to allocate memory for fb_videomode, later it may lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ The reason is that fb_info->var is being modified in fb_set_var(), and then fb_videomode_to_var() is called. If it fails to add the mode to fb_info->modelist, fb_set_var() returns error, but does not restore the old value of fb_info->var. Restore fb_info->var on failure the same way it is done earlier in the function. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Murad Masimov Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 0740747ed7655af3519d9c855a0de1eddf57c759 Author: Niravkumar L Rabara Date: Tue May 27 07:57:07 2025 -0700 EDAC/altera: Use correct write width with the INTTEST register commit e5ef4cd2a47f27c0c9d8ff6c0f63a18937c071a3 upstream. On the SoCFPGA platform, the INTTEST register supports only 16-bit writes. A 32-bit write triggers an SError to the CPU so do 16-bit accesses only. [ bp: AI-massage the commit message. ] Fixes: c7b4be8db8bc ("EDAC, altera: Add Arria10 OCRAM ECC support") Signed-off-by: Niravkumar L Rabara Signed-off-by: Matthew Gerlach Signed-off-by: Borislav Petkov (AMD) Acked-by: Dinh Nguyen Cc: stable@kernel.org Link: https://lore.kernel.org/20250527145707.25458-1-matthew.gerlach@altera.com Signed-off-by: Greg Kroah-Hartman commit d803c4c2a4ac8ce2be6d899d5c7ab0bf7ec355e9 Author: Murad Masimov Date: Mon Apr 28 18:34:06 2025 +0300 fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var commit 17186f1f90d34fa701e4f14e6818305151637b9e upstream. If fb_add_videomode() in do_register_framebuffer() fails to allocate memory for fb_videomode, it will later lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ Even though fbcon_init() checks beforehand if fb_match_mode() in var_to_display() fails, it can not prevent the panic because fbcon_init() does not return error code. Considering this and the comment in the code about fb_match_mode() returning NULL - "This should not happen" - it is better to prevent registering the fb_info if its mode was not set successfully. Also move fb_add_videomode() closer to the beginning of do_register_framebuffer() to avoid having to do the cleanup on fail. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Murad Masimov Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit d43c81b691813e16a2d08208ce8947aebdab83cd Author: Lu Baolu Date: Tue May 20 15:58:49 2025 +0800 iommu/vt-d: Restore context entry setup order for aliased devices commit 320302baed05c6456164652541f23d2a96522c06 upstream. Commit 2031c469f816 ("iommu/vt-d: Add support for static identity domain") changed the context entry setup during domain attachment from a set-and-check policy to a clear-and-reset approach. This inadvertently introduced a regression affecting PCI aliased devices behind PCIe-to-PCI bridges. Specifically, keyboard and touchpad stopped working on several Apple Macbooks with below messages: kernel: platform pxa2xx-spi.3: Adding to iommu group 20 kernel: input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:1e.3/pxa2xx-spi.3/spi_master/spi2/spi-APP000D:00/input/input0 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00 Fix this by restoring the previous context setup order. Fixes: 2031c469f816 ("iommu/vt-d: Add support for static identity domain") Closes: https://lore.kernel.org/all/4dada48a-c5dd-4c30-9c85-5b03b0aa01f0@bfh.ch/ Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian Reviewed-by: Yi Liu Link: https://lore.kernel.org/r/20250514060523.2862195-1-baolu.lu@linux.intel.com Link: https://lore.kernel.org/r/20250520075849.755012-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit eb4e6c3a811b03b456f83f6ca2de9ef3324cf667 Author: Heiner Kallweit Date: Tue Jun 17 20:20:17 2025 +0200 net: ftgmac100: select FIXED_PHY commit ae409629e022fbebbc6d31a1bfeccdbbeee20fd6 upstream. Depending on e.g. DT configuration this driver uses a fixed link. So we shouldn't rely on the user to enable FIXED_PHY, select it in Kconfig instead. We may end up with a non-functional driver otherwise. Fixes: 38561ded50d0 ("net: ftgmac100: support fixed link") Cc: stable@vger.kernel.org Signed-off-by: Heiner Kallweit Link: https://patch.msgid.link/476bb33b-5584-40f0-826a-7294980f2895@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b1547d28ba468bc3b88764efd13e4319bab63be8 Author: Hyunwoo Kim Date: Fri Jun 13 20:54:57 2025 -0400 net/sched: fix use-after-free in taprio_dev_notifier commit b160766e26d4e2e2d6fe2294e0b02f92baefcec5 upstream. Since taprio’s taprio_dev_notifier() isn’t protected by an RCU read-side critical section, a race with advance_sched() can lead to a use-after-free. Adding rcu_read_lock() inside taprio_dev_notifier() prevents this. Fixes: fed87cc6718a ("net/sched: taprio: automatically calculate queueMaxSDU based on TC gate durations") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim Reviewed-by: Simon Horman Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/aEzIYYxt0is9upYG@v4bel-B760M-AORUS-ELITE-AX Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e9799db771b2d574d5bf0dfb3177485e5f40d4d6 Author: Krzysztof Kozlowski Date: Wed Jun 18 09:36:50 2025 +0200 NFC: nci: uart: Set tty->disc_data only in success path commit fc27ab48904ceb7e4792f0c400f1ef175edf16fe upstream. Setting tty->disc_data before opening the NCI device means we need to clean it up on error paths. This also opens some short window if device starts sending data, even before NCIUARTSETDRIVER IOCTL succeeded (broken hardware?). Close the window by exposing tty->disc_data only on the success path, when opening of the NCI device and try_module_get() succeeds. The code differs in error path in one aspect: tty->disc_data won't be ever assigned thus NULL-ified. This however should not be relevant difference, because of "tty->disc_data=NULL" in nci_uart_tty_open(). Cc: Linus Torvalds Fixes: 9961127d4bce ("NFC: nci: add generic uart support") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20250618073649.25049-2-krzysztof.kozlowski@linaro.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4d646f627d3b7ed1cacca66e598af8bcd632d465 Author: Gui-Dong Han Date: Fri Jun 6 07:16:40 2025 +0000 hwmon: (ftsteutates) Fix TOCTOU race in fts_read() commit 14c9ede9ca4cd078ad76a6ab9617b81074eb58bf upstream. In the fts_read() function, when handling hwmon_pwm_auto_channels_temp, the code accesses the shared variable data->fan_source[channel] twice without holding any locks. It is first checked against FTS_FAN_SOURCE_INVALID, and if the check passes, it is read again when used as an argument to the BIT() macro. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition. Another thread executing fts_update_device() can modify the value of data->fan_source[channel] between the check and its use. If the value is changed to FTS_FAN_SOURCE_INVALID (0xff) during this window, the BIT() macro will be called with a large shift value (BIT(255)). A bit shift by a value greater than or equal to the type width is undefined behavior and can lead to a crash or incorrect values being returned to userspace. Fix this by reading data->fan_source[channel] into a local variable once, eliminating the race condition. Additionally, add a bounds check to ensure the value is less than BITS_PER_LONG before passing it to the BIT() macro, making the code more robust against undefined behavior. This possible bug was found by an experimental static analysis tool developed by our team. Fixes: 1c5759d8ce05 ("hwmon: (ftsteutates) Replace fanX_source with pwmX_auto_channels_temp") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han Link: https://lore.kernel.org/r/20250606071640.501262-1-hanguidong02@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit d0e68a63f03883fd6ae75de560a7791c50318026 Author: Chao Yu Date: Thu May 8 07:14:27 2025 +0200 f2fs: fix to return correct error number in f2fs_sync_node_pages() commit 43ba56a043b14426ca9ecac875ab357e32cb595e upstream. If __write_node_folio() failed, it will return AOP_WRITEPAGE_ACTIVATE, the incorrect return value may be passed to userspace in below path, fix it. - sync_filesystem - sync_fs - f2fs_issue_checkpoint - block_operations - f2fs_sync_node_pages - __write_node_folio : return AOP_WRITEPAGE_ACTIVATE Cc: stable@vger.kernel.org Reported-by: Christoph Hellwig Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 3e5ac62a56a24f4d88ce8ffd7bc452428b235868 Author: Chao Yu Date: Mon Apr 14 18:55:20 2025 +0800 f2fs: fix to do sanity check on sit_bitmap_size commit 5db0d252c64e91ba1929c70112352e85dc5751e7 upstream. w/ below testcase, resize will generate a corrupted image which contains inconsistent metadata, so when mounting such image, it will trigger kernel panic: touch img truncate -s $((512*1024*1024*1024)) img mkfs.f2fs -f img $((256*1024*1024)) resize.f2fs -s -i img -t $((1024*1024*1024)) mount img /mnt/f2fs ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.h:863! Oops: invalid opcode: 0000 [#1] SMP PTI CPU: 11 UID: 0 PID: 3922 Comm: mount Not tainted 6.15.0-rc1+ #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:f2fs_ra_meta_pages+0x47c/0x490 Call Trace: f2fs_build_segment_manager+0x11c3/0x2600 f2fs_fill_super+0xe97/0x2840 mount_bdev+0xf4/0x140 legacy_get_tree+0x2b/0x50 vfs_get_tree+0x29/0xd0 path_mount+0x487/0xaf0 __x64_sys_mount+0x116/0x150 do_syscall_64+0x82/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdbfde1bcfe The reaseon is: sit_i->bitmap_size is 192, so size of sit bitmap is 192*8=1536, at maximum there are 1536 sit blocks, however MAIN_SEGS is 261893, so that sit_blk_cnt is 4762, build_sit_entries() -> current_sit_addr() tries to access out-of-boundary in sit_bitmap at offset from [1536, 4762), once sit_bitmap and sit_bitmap_mirror is not the same, it will trigger f2fs_bug_on(). Let's add sanity check in f2fs_sanity_check_ckpt() to avoid panic. Cc: stable@vger.kernel.org Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit d14cbed4baccd712447fb3f9c011f008b56b2097 Author: Jaegeuk Kim Date: Sat Apr 12 21:09:46 2025 +0000 f2fs: prevent kernel warning due to negative i_nlink from corrupted image commit 42cb74a92adaf88061039601ddf7c874f58b554e upstream. WARNING: CPU: 1 PID: 9426 at fs/inode.c:417 drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417 Modules linked in: CPU: 1 UID: 0 PID: 9426 Comm: syz-executor568 Not tainted 6.14.0-12627-g94d471a4f428 #2 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417 Code: 48 8b 5d 28 be 08 00 00 00 48 8d bb 70 07 00 00 e8 f9 67 e6 ff f0 48 ff 83 70 07 00 00 5b 5d e9 9a 12 82 ff e8 95 12 82 ff 90 <0f> 0b 90 c7 45 48 ff ff ff ff 5b 5d e9 83 12 82 ff e8 fe 5f e6 ff RSP: 0018:ffffc900026b7c28 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8239710f RDX: ffff888041345a00 RSI: ffffffff8239717b RDI: 0000000000000005 RBP: ffff888054509ad0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: ffffffff9ab36f08 R12: ffff88804bb40000 R13: ffff8880545091e0 R14: 0000000000008000 R15: ffff8880545091e0 FS: 000055555d0c5880(0000) GS:ffff8880eb3e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f915c55b178 CR3: 0000000050d20000 CR4: 0000000000352ef0 Call Trace: f2fs_i_links_write home/cc/linux/fs/f2fs/f2fs.h:3194 [inline] f2fs_drop_nlink+0xd1/0x3c0 home/cc/linux/fs/f2fs/dir.c:845 f2fs_delete_entry+0x542/0x1450 home/cc/linux/fs/f2fs/dir.c:909 f2fs_unlink+0x45c/0x890 home/cc/linux/fs/f2fs/namei.c:581 vfs_unlink+0x2fb/0x9b0 home/cc/linux/fs/namei.c:4544 do_unlinkat+0x4c5/0x6a0 home/cc/linux/fs/namei.c:4608 __do_sys_unlink home/cc/linux/fs/namei.c:4654 [inline] __se_sys_unlink home/cc/linux/fs/namei.c:4652 [inline] __x64_sys_unlink+0xc5/0x110 home/cc/linux/fs/namei.c:4652 do_syscall_x64 home/cc/linux/arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x250 home/cc/linux/arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb3d092324b Code: 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 57 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdc232d938 EFLAGS: 00000206 ORIG_RAX: 0000000000000057 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb3d092324b RDX: 00007ffdc232d960 RSI: 00007ffdc232d960 RDI: 00007ffdc232d9f0 RBP: 00007ffdc232d9f0 R08: 0000000000000001 R09: 00007ffdc232d7c0 R10: 00000000fffffffd R11: 0000000000000206 R12: 00007ffdc232eaf0 R13: 000055555d0cebb0 R14: 00007ffdc232d958 R15: 0000000000000001 Cc: stable@vger.kernel.org Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 5a06d97d5340c00510f24e80e8de821bd3bd9285 Author: Chao Yu Date: Mon Mar 24 13:33:39 2025 +0800 f2fs: fix to do sanity check on ino and xnid commit 061cf3a84bde038708eb0f1d065b31b7c2456533 upstream. syzbot reported a f2fs bug as below: INFO: task syz-executor140:5308 blocked for more than 143 seconds. Not tainted 6.14.0-rc7-syzkaller-00069-g81e4f8d68c66 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor140 state:D stack:24016 pid:5308 tgid:5308 ppid:5306 task_flags:0x400140 flags:0x00000006 Call Trace: context_switch kernel/sched/core.c:5378 [inline] __schedule+0x190e/0x4c90 kernel/sched/core.c:6765 __schedule_loop kernel/sched/core.c:6842 [inline] schedule+0x14b/0x320 kernel/sched/core.c:6857 io_schedule+0x8d/0x110 kernel/sched/core.c:7690 folio_wait_bit_common+0x839/0xee0 mm/filemap.c:1317 __folio_lock mm/filemap.c:1664 [inline] folio_lock include/linux/pagemap.h:1163 [inline] __filemap_get_folio+0x147/0xb40 mm/filemap.c:1917 pagecache_get_page+0x2c/0x130 mm/folio-compat.c:87 find_get_page_flags include/linux/pagemap.h:842 [inline] f2fs_grab_cache_page+0x2b/0x320 fs/f2fs/f2fs.h:2776 __get_node_page+0x131/0x11b0 fs/f2fs/node.c:1463 read_xattr_block+0xfb/0x190 fs/f2fs/xattr.c:306 lookup_all_xattrs fs/f2fs/xattr.c:355 [inline] f2fs_getxattr+0x676/0xf70 fs/f2fs/xattr.c:533 __f2fs_get_acl+0x52/0x870 fs/f2fs/acl.c:179 f2fs_acl_create fs/f2fs/acl.c:375 [inline] f2fs_init_acl+0xd7/0x9b0 fs/f2fs/acl.c:418 f2fs_init_inode_metadata+0xa0f/0x1050 fs/f2fs/dir.c:539 f2fs_add_inline_entry+0x448/0x860 fs/f2fs/inline.c:666 f2fs_add_dentry+0xba/0x1e0 fs/f2fs/dir.c:765 f2fs_do_add_link+0x28c/0x3a0 fs/f2fs/dir.c:808 f2fs_add_link fs/f2fs/f2fs.h:3616 [inline] f2fs_mknod+0x2e8/0x5b0 fs/f2fs/namei.c:766 vfs_mknod+0x36d/0x3b0 fs/namei.c:4191 unix_bind_bsd net/unix/af_unix.c:1286 [inline] unix_bind+0x563/0xe30 net/unix/af_unix.c:1379 __sys_bind_socket net/socket.c:1817 [inline] __sys_bind+0x1e4/0x290 net/socket.c:1848 __do_sys_bind net/socket.c:1853 [inline] __se_sys_bind net/socket.c:1851 [inline] __x64_sys_bind+0x7a/0x90 net/socket.c:1851 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Let's dump and check metadata of corrupted inode, it shows its xattr_nid is the same to its i_ino. dump.f2fs -i 3 chaseyu.img.raw i_xattr_nid [0x 3 : 3] So that, during mknod in the corrupted directory, it tries to get and lock inode page twice, result in deadlock. - f2fs_mknod - f2fs_add_inline_entry - f2fs_get_inode_page --- lock dir's inode page - f2fs_init_acl - f2fs_acl_create(dir,..) - __f2fs_get_acl - f2fs_getxattr - lookup_all_xattrs - __get_node_page --- try to lock dir's inode page In order to fix this, let's add sanity check on ino and xnid. Cc: stable@vger.kernel.org Reported-by: syzbot+cc448dcdc7ae0b4e4ffa@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/67e06150.050a0220.21942d.0005.GAE@google.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 7c73ec5cf086f45745e722bea8b208542d661d5e Author: Gatien Chevallier Date: Fri May 30 16:09:23 2025 -0700 Input: gpio-keys - fix possible concurrent access in gpio_keys_irq_timer() commit 8f38219fa139623c29db2cb0f17d0a197a86e344 upstream. gpio_keys_irq_isr() and gpio_keys_irq_timer() access the same resources. There could be a concurrent access if a GPIO interrupt occurs in parallel of a HR timer interrupt. Guard back those resources with a spinlock. Fixes: 019002f20cb5 ("Input: gpio-keys - use hrtimer for release timer") Signed-off-by: Gatien Chevallier Link: https://lore.kernel.org/r/20250528-gpio_keys_preempt_rt-v2-2-3fc55a9c3619@foss.st.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 74661516daee1eadebede8dc607b6830530096ec Author: Dan Carpenter Date: Fri May 30 16:13:32 2025 -0700 Input: ims-pcu - check record size in ims_pcu_flash_firmware() commit a95ef0199e80f3384eb992889322957d26c00102 upstream. The "len" variable comes from the firmware and we generally do trust firmware, but it's always better to double check. If the "len" is too large it could result in memory corruption when we do "memcpy(fragment->data, rec->data, len);" Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/131fd1ae92c828ee9f4fa2de03d8c210ae1f3524.1748463049.git.dan.carpenter@linaro.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit ec8f5da79b425deef5aebacdd4fe645620cd4f0b Author: Fabrice Gasnier Date: Fri May 30 15:36:43 2025 -0700 Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT commit f4a8f561d08e39f7833d4a278ebfb12a41eef15f upstream. When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in hard irq context, but the input_event() takes a spin_lock, which isn't allowed there as it is converted to a rt_spin_lock(). [ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0 ... [ 4054.290195] __might_resched+0x13c/0x1f4 [ 4054.290209] rt_spin_lock+0x54/0x11c [ 4054.290219] input_event+0x48/0x80 [ 4054.290230] gpio_keys_irq_timer+0x4c/0x78 [ 4054.290243] __hrtimer_run_queues+0x1a4/0x438 [ 4054.290257] hrtimer_interrupt+0xe4/0x240 [ 4054.290269] arch_timer_handler_phys+0x2c/0x44 [ 4054.290283] handle_percpu_devid_irq+0x8c/0x14c [ 4054.290297] handle_irq_desc+0x40/0x58 [ 4054.290307] generic_handle_domain_irq+0x1c/0x28 [ 4054.290316] gic_handle_irq+0x44/0xcc Considering the gpio_keys_irq_isr() can run in any context, e.g. it can be threaded, it seems there's no point in requesting the timer isr to run in hard irq context. Relax the hrtimer not to use the hard context. Fixes: 019002f20cb5 ("Input: gpio-keys - use hrtimer for release timer") Suggested-by: Sebastian Andrzej Siewior Signed-off-by: Fabrice Gasnier Signed-off-by: Gatien Chevallier Link: https://lore.kernel.org/r/20250528-gpio_keys_preempt_rt-v2-1-3fc55a9c3619@foss.st.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d7af6eee8cd60f55aa8c5fe2b91f11ec0c9a0f27 Author: Brian Foster Date: Fri May 16 13:38:00 2025 -0400 ext4: only dirty folios when data journaling regular files commit e26268ff1dcae5662c1b96c35f18cfa6ab73d9de upstream. fstest generic/388 occasionally reproduces a crash that looks as follows: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: ext4_block_zero_page_range+0x30c/0x380 [ext4] ext4_truncate+0x436/0x440 [ext4] ext4_process_orphan+0x5d/0x110 [ext4] ext4_orphan_cleanup+0x124/0x4f0 [ext4] ext4_fill_super+0x262d/0x3110 [ext4] get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x26/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4ed/0x6b0 do_syscall_64+0x82/0x170 ... This occurs when processing a symlink inode from the orphan list. The partial block zeroing code in the truncate path calls ext4_dirty_journalled_data() -> folio_mark_dirty(). The latter calls mapping->a_ops->dirty_folio(), but symlink inodes are not assigned an a_ops vector in ext4, hence the crash. To avoid this problem, update the ext4_dirty_journalled_data() helper to only mark the folio dirty on regular files (for which a_ops is assigned). This also matches the journaling logic in the ext4_symlink() creation path, where ext4_handle_dirty_metadata() is called directly. Fixes: d84c9ebdac1e ("ext4: Mark pages with journalled data dirty") Signed-off-by: Brian Foster Link: https://patch.msgid.link/20250516173800.175577-1-bfoster@redhat.com Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit c8b699133297119132db500d12a8e62a88fdd031 Author: Zhang Yi Date: Tue May 6 09:20:09 2025 +0800 ext4: ensure i_size is smaller than maxbytes commit 1a77a028a392fab66dd637cdfac3f888450d00af upstream. The inode i_size cannot be larger than maxbytes, check it while loading inode from the disk. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Link: https://patch.msgid.link/20250506012009.3896990-4-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8e49c6aea8a7375dc91a49a2471749b5c95f6c39 Author: Zhang Yi Date: Tue May 6 09:20:08 2025 +0800 ext4: factor out ext4_get_maxbytes() commit dbe27f06fa38b9bfc598f8864ae1c5d5831d9992 upstream. There are several locations that get the correct maxbytes value based on the inode's block type. It would be beneficial to extract a common helper function to make the code more clear. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Link: https://patch.msgid.link/20250506012009.3896990-3-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit aa6dd3d34de9f3d8771db69cc46201bc5aa190ee Author: Zhang Yi Date: Tue May 6 09:20:07 2025 +0800 ext4: fix incorrect punch max_end commit 29ec9bed2395061350249ae356fb300dd82a78e7 upstream. For the extents based inodes, the maxbytes should be sb->s_maxbytes instead of sbi->s_bitmap_maxbytes. Additionally, for the calculation of max_end, the -sb->s_blocksize operation is necessary only for indirect-block based inodes. Correct the maxbytes and max_end value to correct the behavior of punch hole. Fixes: 2da376228a24 ("ext4: limit length to bitmap_maxbytes - blocksize in punch_hole") Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Link: https://patch.msgid.link/20250506012009.3896990-2-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 28b62cb58fd014338f5004170f2e3a35bf0af238 Author: Zhang Yi Date: Tue May 6 09:20:06 2025 +0800 ext4: fix out of bounds punch offset commit b5e58bcd79625423487fa3ecba8e8411b5396327 upstream. Punching a hole with a start offset that exceeds max_end is not permitted and will result in a negative length in the truncate_inode_partial_folio() function while truncating the page cache, potentially leading to undesirable consequences. A simple reproducer: truncate -s 9895604649994 /mnt/foo xfs_io -c "pwrite 8796093022208 4096" /mnt/foo xfs_io -c "fpunch 8796093022213 25769803777" /mnt/foo kernel BUG at include/linux/highmem.h:275! Oops: invalid opcode: 0000 [#1] SMP PTI CPU: 3 UID: 0 PID: 710 Comm: xfs_io Not tainted 6.15.0-rc3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:zero_user_segments.constprop.0+0xd7/0x110 RSP: 0018:ffffc90001cf3b38 EFLAGS: 00010287 RAX: 0000000000000005 RBX: ffffea0001485e40 RCX: 0000000000001000 RDX: 000000000040b000 RSI: 0000000000000005 RDI: 000000000040b000 RBP: 000000000040affb R08: ffff888000000000 R09: ffffea0000000000 R10: 0000000000000003 R11: 00000000fffc7fc5 R12: 0000000000000005 R13: 000000000040affb R14: ffffea0001485e40 R15: ffff888031cd3000 FS: 00007f4f63d0b780(0000) GS:ffff8880d337d000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000001ae0b038 CR3: 00000000536aa000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: truncate_inode_partial_folio+0x3dd/0x620 truncate_inode_pages_range+0x226/0x720 ? bdev_getblk+0x52/0x3e0 ? ext4_get_group_desc+0x78/0x150 ? crc32c_arch+0xfd/0x180 ? __ext4_get_inode_loc+0x18c/0x840 ? ext4_inode_csum+0x117/0x160 ? jbd2_journal_dirty_metadata+0x61/0x390 ? __ext4_handle_dirty_metadata+0xa0/0x2b0 ? kmem_cache_free+0x90/0x5a0 ? jbd2_journal_stop+0x1d5/0x550 ? __ext4_journal_stop+0x49/0x100 truncate_pagecache_range+0x50/0x80 ext4_truncate_page_cache_block_range+0x57/0x3a0 ext4_punch_hole+0x1fe/0x670 ext4_fallocate+0x792/0x17d0 ? __count_memcg_events+0x175/0x2a0 vfs_fallocate+0x121/0x560 ksys_fallocate+0x51/0xc0 __x64_sys_fallocate+0x24/0x40 x64_sys_call+0x18d2/0x4170 do_syscall_64+0xa7/0x220 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix this by filtering out cases where the punching start offset exceeds max_end. Fixes: 982bf37da09d ("ext4: refactor ext4_punch_hole()") Reported-by: Liebes Wang Closes: https://lore.kernel.org/linux-ext4/ac3a58f6-e686-488b-a9ee-fc041024e43d@huawei.com/ Tested-by: Liebes Wang Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Link: https://patch.msgid.link/20250506012009.3896990-1-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 4b05f54412f4e4648070008b19fa67627dbe5342 Author: Jan Kara Date: Tue Apr 29 19:55:36 2025 +0200 ext4: fix calculation of credits for extent tree modification commit 32a93f5bc9b9812fc710f43a4d8a6830f91e4988 upstream. Luis and David are reporting that after running generic/750 test for 90+ hours on 2k ext4 filesystem, they are able to trigger a warning in jbd2_journal_dirty_metadata() complaining that there are not enough credits in the running transaction started in ext4_do_writepages(). Indeed the code in ext4_do_writepages() is racy and the extent tree can change between the time we compute credits necessary for extent tree computation and the time we actually modify the extent tree. Thus it may happen that the number of credits actually needed is higher. Modify ext4_ext_index_trans_blocks() to count with the worst case of maximum tree depth. This can reduce the possible number of writers that can operate in the system in parallel (because the credit estimates now won't fit in one transaction) but for reasonably sized journals this shouldn't really be an issue. So just go with a safe and simple fix. Link: https://lore.kernel.org/all/20250415013641.f2ppw6wov4kn4wq2@offworld Reported-by: Davidlohr Bueso Reported-by: Luis Chamberlain Tested-by: kdevops@lists.linux.dev Signed-off-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20250429175535.23125-2-jack@suse.cz Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit e80ee0263d88d77f2fd1927f915003a7066cbb50 Author: Thadeu Lima de Souza Cascardo Date: Tue Apr 15 11:53:04 2025 -0300 ext4: inline: fix len overflow in ext4_prepare_inline_data commit 227cb4ca5a6502164f850d22aec3104d7888b270 upstream. When running the following code on an ext4 filesystem with inline_data feature enabled, it will lead to the bug below. fd = open("file1", O_RDWR | O_CREAT | O_TRUNC, 0666); ftruncate(fd, 30); pwrite(fd, "a", 1, (1UL << 40) + 5UL); That happens because write_begin will succeed as when ext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + len will be truncated, leading to ext4_prepare_inline_data parameter to be 6 instead of 0x10000000006. Then, later when write_end is called, we hit: BUG_ON(pos + len > EXT4_I(inode)->i_inline_size); at ext4_write_inline_data. Fix it by using a loff_t type for the len parameter in ext4_prepare_inline_data instead of an unsigned int. [ 44.545164] ------------[ cut here ]------------ [ 44.545530] kernel BUG at fs/ext4/inline.c:240! [ 44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full) 112853fcebfdb93254270a7959841d2c6aa2c8bb [ 44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100 [ 44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49 [ 44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216 [ 44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006 [ 44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738 [ 44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [ 44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000 [ 44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738 [ 44.546523] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000 [ 44.546523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0 [ 44.546523] PKRU: 55555554 [ 44.546523] Call Trace: [ 44.546523] [ 44.546523] ext4_write_inline_data_end+0x126/0x2d0 [ 44.546523] generic_perform_write+0x17e/0x270 [ 44.546523] ext4_buffered_write_iter+0xc8/0x170 [ 44.546523] vfs_write+0x2be/0x3e0 [ 44.546523] __x64_sys_pwrite64+0x6d/0xc0 [ 44.546523] do_syscall_64+0x6a/0xf0 [ 44.546523] ? __wake_up+0x89/0xb0 [ 44.546523] ? xas_find+0x72/0x1c0 [ 44.546523] ? next_uptodate_folio+0x317/0x330 [ 44.546523] ? set_pte_range+0x1a6/0x270 [ 44.546523] ? filemap_map_pages+0x6ee/0x840 [ 44.546523] ? ext4_setattr+0x2fa/0x750 [ 44.546523] ? do_pte_missing+0x128/0xf70 [ 44.546523] ? security_inode_post_setattr+0x3e/0xd0 [ 44.546523] ? ___pte_offset_map+0x19/0x100 [ 44.546523] ? handle_mm_fault+0x721/0xa10 [ 44.546523] ? do_user_addr_fault+0x197/0x730 [ 44.546523] ? do_syscall_64+0x76/0xf0 [ 44.546523] ? arch_exit_to_user_mode_prepare+0x1e/0x60 [ 44.546523] ? irqentry_exit_to_user_mode+0x79/0x90 [ 44.546523] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 44.546523] RIP: 0033:0x7f42999c6687 [ 44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff [ 44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012 [ 44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687 [ 44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003 [ 44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000 [ 44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000000000000000 [ 44.546523] R13: 00007ffeae4a7ac8 R14: 00007f4299b86000 R15: 000055ea61493dd8 [ 44.546523] [ 44.546523] Modules linked in: [ 44.568501] ---[ end trace 0000000000000000 ]--- [ 44.568889] RIP: 0010:ext4_write_inline_data+0xfe/0x100 [ 44.569328] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49 [ 44.570931] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216 [ 44.571356] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006 [ 44.571959] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738 [ 44.572571] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [ 44.573148] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000 [ 44.573748] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738 [ 44.574335] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000 [ 44.575027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 44.575520] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0 [ 44.576112] PKRU: 55555554 [ 44.576338] Kernel panic - not syncing: Fatal exception [ 44.576517] Kernel Offset: 0x1a600000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Reported-by: syzbot+fe2a25dae02a207717a0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=fe2a25dae02a207717a0 Fixes: f19d5870cbf7 ("ext4: add normal write support for inline data") Signed-off-by: Thadeu Lima de Souza Cascardo Cc: stable@vger.kernel.org Reviewed-by: Jan Kara Reviewed-by: Andreas Dilger Link: https://patch.msgid.link/20250415-ext4-prepare-inline-overflow-v1-1-f4c13d900967@igalia.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 16f687ef746fa3cc964d5ab66a4268b70174d56f Author: Wan Junjie Date: Tue Apr 8 13:58:11 2025 +0300 bus: fsl-mc: fix GET/SET_TAILDROP command ids commit c78230ad34f82c6c0e0e986865073aeeef1f5d30 upstream. Command ids for taildrop get/set can not pass the check when they are using from the restool user space utility. Correct them according to the user manual. Fixes: d67cc29e6d1f ("bus: fsl-mc: list more commands as accepted through the ioctl") Signed-off-by: Wan Junjie Signed-off-by: Ioana Ciornei Cc: stable@vger.kernel.org Reviewed-by: Ioana Ciornei Link: https://lore.kernel.org/r/20250408105814.2837951-4-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy Signed-off-by: Greg Kroah-Hartman commit 52422187dd58d6d90ef8b79528ccef40033238b9 Author: Ioana Ciornei Date: Tue Apr 8 13:58:10 2025 +0300 bus: fsl-mc: do not add a device-link for the UAPI used DPMCP device commit dd7d8e012b23de158ca0188239c7a1f2a83b4484 upstream. The fsl-mc bus associated to the root DPRC in a DPAA2 system exports a device file for userspace access to the MC firmware. In case the DPRC's local MC portal (DPMCP) is currently in use, a new DPMCP device is allocated through the fsl_mc_portal_allocate() function. In this case, the call to fsl_mc_portal_allocate() will fail with -EINVAL when trying to add a device link between the root DPRC (consumer) and the newly allocated DPMCP device (supplier). This is because the DPMCP is a dependent of the DPRC device (the bus). Fix this by not adding a device link in case the DPMCP is allocated for the root DPRC's usage. Fixes: afb77422819f ("bus: fsl-mc: automatically add a device_link on fsl_mc_[portal,object]_allocate") Signed-off-by: Ioana Ciornei Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250408105814.2837951-3-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy Signed-off-by: Greg Kroah-Hartman commit 42c10598f3fc7afbbeb1251531b734099b20dd1c Author: Mikko Korhonen Date: Tue Jun 17 09:18:41 2025 +0300 ata: ahci: Disallow LPM for Asus B550-F motherboard commit a7b3b77fd111d49f8e25624e4ea1046322a57baf upstream. Asus ROG STRIX B550-F GAMING (WI-FI) motherboard has problems on some SATA ports with at least one hard drive model (WDC WD20EFAX-68FB5N0) when LPM is enabled. Disabling LPM solves the issue. Cc: stable@vger.kernel.org Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type") Signed-off-by: Mikko Korhonen Link: https://lore.kernel.org/r/20250617062055.784827-1-mjkorhon@gmail.com [cassel: more detailed comment, make single line comments consistent] Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit ddc20982b0cf67a11c9105fbbc5adaff274449a2 Author: Niklas Cassel Date: Thu Jun 12 16:17:51 2025 +0200 ata: ahci: Disallow LPM for ASUSPRO-D840SA motherboard commit b5acc3628898baa63658bc4125f9525f9b3dd4f3 upstream. A user has bisected a regression which causes graphical corruptions on his screen to commit 7627a0edef54 ("ata: ahci: Drop low power policy board type"). Simply reverting commit 7627a0edef54 ("ata: ahci: Drop low power policy board type") makes the graphical corruptions on his screen to go away. (Note: there are no visible messages in dmesg that indicates a problem with AHCI.) The user also reports that the problem occurs regardless if there is an HDD or an SSD connected via AHCI, so the problem is not device related. The devices also work fine on other motherboards, so it seems specific to the ASUSPRO-D840SA motherboard. While enabling low power modes for AHCI is not supposed to affect completely unrelated hardware, like a graphics card, it does however allow the system to enter deeper PC-states, which could expose ACPI issues that were previously not visible (because the system never entered these lower power states before). There are previous examples where enabling LPM exposed serious BIOS/ACPI bugs, see e.g. commit 240630e61870 ("ahci: Disable LPM on Lenovo 50 series laptops with a too old BIOS"). Since there hasn't been any BIOS update in years for the ASUSPRO-D840SA motherboard, disable LPM for this board, in order to avoid entering lower PC-states, which triggers graphical corruptions. Cc: stable@vger.kernel.org Reported-by: Andy Yang Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220111 Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type") Reviewed-by: Damien Le Moal Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20250612141750.2108342-2-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit bb7212ee4ff086628a2c1c22336d082a87cb893d Author: Tasos Sahanidis Date: Mon May 19 11:49:45 2025 +0300 ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330 commit d29fc02caad7f94b62d56ee1b01c954f9c961ba7 upstream. The controller has a hardware bug that can hard hang the system when doing ATAPI DMAs without any trace of what happened. Depending on the device attached, it can also prevent the system from booting. In this case, the system hangs when reading the ATIP from optical media with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4, running at UDMA/33. The issue can be reproduced by running the same command with a cygwin build of cdrecord on WinXP, although it requires more attempts to cause it. The hang in that case is also resolved by forcing PIO. It doesn't appear that VIA has produced any drivers for that OS, thus no known workaround exists. HDDs attached to the controller do not suffer from any DMA issues. Cc: stable@vger.kernel.org Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/916677 Signed-off-by: Tasos Sahanidis Link: https://lore.kernel.org/r/20250519085508.1398701-1-tasos@tasossah.com Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit f87b84a60924f4e692c2d237a39c5a085ffcaf8f Author: Krzysztof Kozlowski Date: Wed May 7 11:21:22 2025 +0200 bus: firewall: Fix missing static inline annotations for stubs commit 66db876162155c1cec87359cd78c62aaafde9257 upstream. Stubs in the header file for !CONFIG_STM32_FIREWALL case should be both static and inline, because they do not come with earlier declaration and should be inlined in every unit including the header. Cc: Patrice Chotard Cc: stable@vger.kernel.org Fixes: 5c9668cfc6d7 ("firewall: introduce stm32_firewall framework") Link: https://lore.kernel.org/r/20250507092121.95121-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit e47657a40b83cc2570fbf241d653ff0baed3122c Author: Chen Ridong Date: Wed Jun 18 07:32:17 2025 +0000 cgroup,freezer: fix incomplete freezing when attaching tasks commit 37fb58a7273726e59f9429c89ade5116083a213d upstream. An issue was found: # cd /sys/fs/cgroup/freezer/ # mkdir test # echo FROZEN > test/freezer.state # cat test/freezer.state FROZEN # sleep 1000 & [1] 863 # echo 863 > test/cgroup.procs # cat test/freezer.state FREEZING When tasks are migrated to a frozen cgroup, the freezer fails to immediately freeze the tasks, causing the cgroup to remain in the "FREEZING". The freeze_task() function is called before clearing the CGROUP_FROZEN flag. This causes the freezing() check to incorrectly return false, preventing __freeze_task() from being invoked for the migrated task. To fix this issue, clear the CGROUP_FROZEN state before calling freeze_task(). Fixes: f5d39b020809 ("freezer,sched: Rewrite core freezer logic") Cc: stable@vger.kernel.org # v6.1+ Reported-by: Zhong Jiawei Signed-off-by: Chen Ridong Acked-by: Michal Koutný Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit e4559bdc15034071b0dcc7d009610dda2325a508 Author: Dennis Marttinen Date: Thu May 29 17:45:12 2025 +0000 ceph: set superblock s_magic for IMA fsmagic matching commit 72386d5245b249f5a0a8fabb881df7ad947b8ea4 upstream. The CephFS kernel driver forgets to set the filesystem magic signature in its superblock. As a result, IMA policy rules based on fsmagic matching do not apply as intended. This causes a major performance regression in Talos Linux [1] when mounting CephFS volumes, such as when deploying Rook Ceph [2]. Talos Linux ships a hardened kernel with the following IMA policy (irrelevant lines omitted): [...] dont_measure fsmagic=0xc36400 # CEPH_SUPER_MAGIC [...] measure func=FILE_CHECK mask=^MAY_READ euid=0 measure func=FILE_CHECK mask=^MAY_READ uid=0 [...] Currently, IMA compares 0xc36400 == 0x0 for CephFS files, resulting in all files opened with O_RDONLY or O_RDWR getting measured with SHA512 on every open(2): 10 69990c87e8af323d47e2d6ae4... ima-ng sha512: /data/cephfs/test-file Since O_WRONLY is rare, this results in an order of magnitude lower performance than expected for practically all file operations. Properly setting CEPH_SUPER_MAGIC in the CephFS superblock resolves the regression. Tests performed on a 3x replicated Ceph v19.3.0 cluster across three i5-7200U nodes each equipped with one Micron 7400 MAX M.2 disk (BlueStore) and Gigabit ethernet, on Talos Linux v1.10.2: FS-Mark 3.3 Test: 500 Files, Empty Files/s > Higher Is Better 6.12.27-talos . 16.6 |==== +twelho patch . 208.4 |==================================================== FS-Mark 3.3 Test: 500 Files, 1KB Size Files/s > Higher Is Better 6.12.27-talos . 15.6 |======= +twelho patch . 118.6 |==================================================== FS-Mark 3.3 Test: 500 Files, 32 Sub Dirs, 1MB Size Files/s > Higher Is Better 6.12.27-talos . 12.7 |=============== +twelho patch . 44.7 |===================================================== IO500 [3] 2fcd6d6 results (benchmarks within variance omitted): | IO500 benchmark | 6.12.27-talos | +twelho patch | Speedup | |-------------------|----------------|----------------|-----------| | mdtest-easy-write | 0.018524 kIOPS | 1.135027 kIOPS | 6027.33 % | | mdtest-hard-write | 0.018498 kIOPS | 0.973312 kIOPS | 5161.71 % | | ior-easy-read | 0.064727 GiB/s | 0.155324 GiB/s | 139.97 % | | mdtest-hard-read | 0.018246 kIOPS | 0.780800 kIOPS | 4179.29 % | This applies outside of synthetic benchmarks as well, for example, the time to rsync a 55 MiB directory with ~12k of mostly small files drops from an unusable 10m5s to a reasonable 26s (23x the throughput). [1]: https://www.talos.dev/ [2]: https://www.talos.dev/v1.10/kubernetes-guides/configuration/ceph-with-rook/ [3]: https://github.com/IO500/io500 Cc: stable@vger.kernel.org Signed-off-by: Dennis Marttinen Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 26725a76264b97d1ff104031b78da57f47741625 Author: Viacheslav Dubeyko Date: Thu Jan 16 16:30:08 2025 -0800 ceph: avoid kernel BUG for encrypted inode with unaligned file size commit 060909278cc0a91373a20726bd3d8ce085f480a9 upstream. The generic/397 test hits a BUG_ON for the case of encrypted inode with unaligned file size (for example, 33K or 1K): [ 877.737811] run fstests generic/397 at 2025-01-03 12:34:40 [ 877.875761] libceph: mon0 (2)127.0.0.1:40674 session established [ 877.876130] libceph: client4614 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 [ 877.991965] libceph: mon0 (2)127.0.0.1:40674 session established [ 877.992334] libceph: client4617 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 [ 878.017234] libceph: mon0 (2)127.0.0.1:40674 session established [ 878.017594] libceph: client4620 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 [ 878.031394] xfs_io (pid 18988) is setting deprecated v1 encryption policy; recommend upgrading to v2. [ 878.054528] libceph: mon0 (2)127.0.0.1:40674 session established [ 878.054892] libceph: client4623 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 [ 878.070287] libceph: mon0 (2)127.0.0.1:40674 session established [ 878.070704] libceph: client4626 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 [ 878.264586] libceph: mon0 (2)127.0.0.1:40674 session established [ 878.265258] libceph: client4629 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 [ 878.374578] -----------[ cut here ]------------ [ 878.374586] kernel BUG at net/ceph/messenger.c:1070! [ 878.375150] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 878.378145] CPU: 2 UID: 0 PID: 4759 Comm: kworker/2:9 Not tainted 6.13.0-rc5+ #1 [ 878.378969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 878.380167] Workqueue: ceph-msgr ceph_con_workfn [ 878.381639] RIP: 0010:ceph_msg_data_cursor_init+0x42/0x50 [ 878.382152] Code: 89 17 48 8b 46 70 55 48 89 47 08 c7 47 18 00 00 00 00 48 89 e5 e8 de cc ff ff 5d 31 c0 31 d2 31 f6 31 ff c3 cc cc cc cc 0f 0b <0f> 0b 0f 0b 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 [ 878.383928] RSP: 0018:ffffb4ffc7cbbd28 EFLAGS: 00010287 [ 878.384447] RAX: ffffffff82bb9ac0 RBX: ffff981390c2f1f8 RCX: 0000000000000000 [ 878.385129] RDX: 0000000000009000 RSI: ffff981288232b58 RDI: ffff981390c2f378 [ 878.385839] RBP: ffffb4ffc7cbbe18 R08: 0000000000000000 R09: 0000000000000000 [ 878.386539] R10: 0000000000000000 R11: 0000000000000000 R12: ffff981390c2f030 [ 878.387203] R13: ffff981288232b58 R14: 0000000000000029 R15: 0000000000000001 [ 878.387877] FS: 0000000000000000(0000) GS:ffff9814b7900000(0000) knlGS:0000000000000000 [ 878.388663] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 878.389212] CR2: 00005e106a0554e0 CR3: 0000000112bf0001 CR4: 0000000000772ef0 [ 878.389921] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 878.390620] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 878.391307] PKRU: 55555554 [ 878.391567] Call Trace: [ 878.391807] [ 878.392021] ? show_regs+0x71/0x90 [ 878.392391] ? die+0x38/0xa0 [ 878.392667] ? do_trap+0xdb/0x100 [ 878.392981] ? do_error_trap+0x75/0xb0 [ 878.393372] ? ceph_msg_data_cursor_init+0x42/0x50 [ 878.393842] ? exc_invalid_op+0x53/0x80 [ 878.394232] ? ceph_msg_data_cursor_init+0x42/0x50 [ 878.394694] ? asm_exc_invalid_op+0x1b/0x20 [ 878.395099] ? ceph_msg_data_cursor_init+0x42/0x50 [ 878.395583] ? ceph_con_v2_try_read+0xd16/0x2220 [ 878.396027] ? _raw_spin_unlock+0xe/0x40 [ 878.396428] ? raw_spin_rq_unlock+0x10/0x40 [ 878.396842] ? finish_task_switch.isra.0+0x97/0x310 [ 878.397338] ? __schedule+0x44b/0x16b0 [ 878.397738] ceph_con_workfn+0x326/0x750 [ 878.398121] process_one_work+0x188/0x3d0 [ 878.398522] ? __pfx_worker_thread+0x10/0x10 [ 878.398929] worker_thread+0x2b5/0x3c0 [ 878.399310] ? __pfx_worker_thread+0x10/0x10 [ 878.399727] kthread+0xe1/0x120 [ 878.400031] ? __pfx_kthread+0x10/0x10 [ 878.400431] ret_from_fork+0x43/0x70 [ 878.400771] ? __pfx_kthread+0x10/0x10 [ 878.401127] ret_from_fork_asm+0x1a/0x30 [ 878.401543] [ 878.401760] Modules linked in: hctr2 nhpoly1305_avx2 nhpoly1305_sse2 nhpoly1305 chacha_generic chacha_x86_64 libchacha adiantum libpoly1305 essiv authenc mptcp_diag xsk_diag tcp_diag udp_diag raw_diag inet_diag unix_diag af_packet_diag netlink_diag intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha256_ssse3 sha1_ssse3 aesni_intel joydev crypto_simd cryptd rapl input_leds psmouse sch_fq_codel serio_raw bochs i2c_piix4 floppy qemu_fw_cfg i2c_smbus mac_hid pata_acpi msr parport_pc ppdev lp parport efi_pstore ip_tables x_tables [ 878.407319] ---[ end trace 0000000000000000 ]--- [ 878.407775] RIP: 0010:ceph_msg_data_cursor_init+0x42/0x50 [ 878.408317] Code: 89 17 48 8b 46 70 55 48 89 47 08 c7 47 18 00 00 00 00 48 89 e5 e8 de cc ff ff 5d 31 c0 31 d2 31 f6 31 ff c3 cc cc cc cc 0f 0b <0f> 0b 0f 0b 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 [ 878.410087] RSP: 0018:ffffb4ffc7cbbd28 EFLAGS: 00010287 [ 878.410609] RAX: ffffffff82bb9ac0 RBX: ffff981390c2f1f8 RCX: 0000000000000000 [ 878.411318] RDX: 0000000000009000 RSI: ffff981288232b58 RDI: ffff981390c2f378 [ 878.412014] RBP: ffffb4ffc7cbbe18 R08: 0000000000000000 R09: 0000000000000000 [ 878.412735] R10: 0000000000000000 R11: 0000000000000000 R12: ffff981390c2f030 [ 878.413438] R13: ffff981288232b58 R14: 0000000000000029 R15: 0000000000000001 [ 878.414121] FS: 0000000000000000(0000) GS:ffff9814b7900000(0000) knlGS:0000000000000000 [ 878.414935] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 878.415516] CR2: 00005e106a0554e0 CR3: 0000000112bf0001 CR4: 0000000000772ef0 [ 878.416211] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 878.416907] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 878.417630] PKRU: 55555554 (gdb) l *ceph_msg_data_cursor_init+0x42 0xffffffff823b45a2 is in ceph_msg_data_cursor_init (net/ceph/messenger.c:1070). 1065 1066 void ceph_msg_data_cursor_init(struct ceph_msg_data_cursor *cursor, 1067 struct ceph_msg *msg, size_t length) 1068 { 1069 BUG_ON(!length); 1070 BUG_ON(length > msg->data_length); 1071 BUG_ON(!msg->num_data_items); 1072 1073 cursor->total_resid = length; 1074 cursor->data = msg->data; The issue takes place because of this: [ 202.628853] libceph: net/ceph/messenger_v2.c:2034 prepare_sparse_read_data(): msg->data_length 33792, msg->sparse_read_total 36864 1070 BUG_ON(length > msg->data_length); The generic/397 test (xfstests) executes such steps: (1) create encrypted files and directories; (2) access the created files and folders with encryption key; (3) access the created files and folders without encryption key. The issue takes place in this portion of code: if (IS_ENCRYPTED(inode)) { struct page **pages; size_t page_off; err = iov_iter_get_pages_alloc2(&subreq->io_iter, &pages, len, &page_off); if (err < 0) { doutc(cl, "%llx.%llx failed to allocate pages, %d\n", ceph_vinop(inode), err); goto out; } /* should always give us a page-aligned read */ WARN_ON_ONCE(page_off); len = err; err = 0; osd_req_op_extent_osd_data_pages(req, 0, pages, len, 0, false, false); The reason of the issue is that subreq->io_iter.count keeps unaligned value of length: [ 347.751182] lib/iov_iter.c:1185 __iov_iter_get_pages_alloc(): maxsize 36864, maxpages 4294967295, start 18446659367320516064 [ 347.752808] lib/iov_iter.c:1196 __iov_iter_get_pages_alloc(): maxsize 33792, maxpages 4294967295, start 18446659367320516064 [ 347.754394] lib/iov_iter.c:1015 iter_folioq_get_pages(): maxsize 33792, maxpages 4294967295, extracted 0, _start_offset 18446659367320516064 This patch simply assigns the aligned value to subreq->io_iter.count before calling iov_iter_get_pages_alloc2(). [ idryomov: tag the comment with FIXME to make it clear that it's only a workaround for netfslib not coexisting with fscrypt nicely (this is also noted in another pre-existing comment) ] Cc: David Howells Cc: stable@vger.kernel.org Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Signed-off-by: Viacheslav Dubeyko Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit b2aa738211d162f308dfaf89da62e4355158141b Author: Brett Werling Date: Thu Jun 12 14:18:25 2025 -0500 can: tcan4x5x: fix power regulator retrieval during probe commit db22720545207f734aaa9d9f71637bfc8b0155e0 upstream. Fixes the power regulator retrieval in tcan4x5x_can_probe() by ensuring the regulator pointer is not set to NULL in the successful return from devm_regulator_get_optional(). Fixes: 3814ca3a10be ("can: tcan4x5x: tcan4x5x_can_probe(): turn on the power before parsing the config") Signed-off-by: Brett Werling Link: https://patch.msgid.link/20250612191825.3646364-1-brett.werling@garmin.com Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit a6550c9aa11e2f57f9cdaa6249cdd44d446be874 Author: Fedor Pchelkin Date: Wed May 28 22:27:12 2025 +0300 can: kvaser_pciefd: refine error prone echo_skb_max handling logic commit 54ec8b08216f3be2cc98b33633d3c8ea79749895 upstream. echo_skb_max should define the supported upper limit of echo_skb[] allocated inside the netdevice's priv. The corresponding size value provided by this driver to alloc_candev() is KVASER_PCIEFD_CAN_TX_MAX_COUNT which is 17. But later echo_skb_max is rounded up to the nearest power of two (for the max case, that would be 32) and the tx/ack indices calculated further during tx/rx may exceed the upper array boundary. Kasan reported this for the ack case inside kvaser_pciefd_handle_ack_packet(), though the xmit function has actually caught the same thing earlier. BUG: KASAN: slab-out-of-bounds in kvaser_pciefd_handle_ack_packet+0x2d7/0x92a drivers/net/can/kvaser_pciefd.c:1528 Read of size 8 at addr ffff888105e4f078 by task swapper/4/0 CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 6.15.0 #12 PREEMPT(voluntary) Call Trace: dump_stack_lvl lib/dump_stack.c:122 print_report mm/kasan/report.c:521 kasan_report mm/kasan/report.c:634 kvaser_pciefd_handle_ack_packet drivers/net/can/kvaser_pciefd.c:1528 kvaser_pciefd_read_packet drivers/net/can/kvaser_pciefd.c:1605 kvaser_pciefd_read_buffer drivers/net/can/kvaser_pciefd.c:1656 kvaser_pciefd_receive_irq drivers/net/can/kvaser_pciefd.c:1684 kvaser_pciefd_irq_handler drivers/net/can/kvaser_pciefd.c:1733 __handle_irq_event_percpu kernel/irq/handle.c:158 handle_irq_event kernel/irq/handle.c:210 handle_edge_irq kernel/irq/chip.c:833 __common_interrupt arch/x86/kernel/irq.c:296 common_interrupt arch/x86/kernel/irq.c:286 Tx max count definitely matters for kvaser_pciefd_tx_avail(), but for seq numbers' generation that's not the case - we're free to calculate them as would be more convenient, not taking tx max count into account. The only downside is that the size of echo_skb[] should correspond to the max seq number (not tx max count), so in some situations a bit more memory would be consumed than could be. Thus make the size of the underlying echo_skb[] sufficient for the rounded max tx value. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 8256e0ca6010 ("can: kvaser_pciefd: Fix echo_skb race") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Link: https://patch.msgid.link/20250528192713.63894-1-pchelkin@ispras.ru Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit ea95150ee80b3ebd2cbe2489c5ebb7d91e234a7b Author: Jeff Hugo Date: Fri Mar 28 10:35:26 2025 -0600 bus: mhi: host: Fix conflict between power_up and SYSERR commit 4d92e7c5ccadc79764674ffc2c88d329aabbb7e0 upstream. When mhi_async_power_up() enables IRQs, it is possible that we could receive a SYSERR notification from the device if the firmware has crashed for some reason. Then the SYSERR notification queues a work item that cannot execute until the pm_mutex is released by mhi_async_power_up(). So the SYSERR work item will be pending. If mhi_async_power_up() detects the SYSERR, it will handle it. If the device is in PBL, then the PBL state transition event will be queued, resulting in a work item after the pending SYSERR work item. Once mhi_async_power_up() releases the pm_mutex, the SYSERR work item can run. It will blindly attempt to reset the MHI state machine, which is the recovery action for SYSERR. PBL/SBL are not interrupt driven and will ignore the MHI Reset unless SYSERR is actively advertised. This will cause the SYSERR work item to timeout waiting for reset to be cleared, and will leave the host state in SYSERR processing. The PBL transition work item will then run, and immediately fail because SYSERR processing is not a valid state for PBL transition. This leaves the device uninitialized. This issue has a fairly unique signature in the kernel log: mhi mhi3: Requested to power ON Qualcomm Cloud AI 100 0000:36:00.0: Fatal error received from device. Attempting to recover mhi mhi3: Power on setup success mhi mhi3: Device failed to exit MHI Reset state mhi mhi3: Device MHI is not in valid state We cannot remove the SYSERR handling from mhi_async_power_up() because the device may be in the SYSERR state, but we missed the notification as the irq was fired before irqs were enabled. We also can't queue the SYSERR work item from mhi_async_power_up() if SYSERR is detected because that may result in a duplicate work item, and cause the same issue since the duplicate item will blindly issue MHI reset even if SYSERR is no longer active. Instead, add a check in the SYSERR work item to make sure that MHI reset is only issued if the device is in SYSERR state for PBL or SBL EEs. Fixes: a6e2e3522f29 ("bus: mhi: core: Add support for PM state transitions") Signed-off-by: Jeffrey Hugo Signed-off-by: Jeff Hugo Signed-off-by: Manivannan Sadhasivam Reviewed-by: Troy Hanson Reviewed-by: Manivannan Sadhasivam cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250328163526.3365497-1-jeff.hugo@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 0007ef098dab48f1ba58364c40b4809f1e21b130 Author: Sumit Kumar Date: Wed Apr 9 16:17:43 2025 +0530 bus: mhi: ep: Update read pointer only after buffer is written commit 6f18d174b73d0ceeaa341f46c0986436b3aefc9a upstream. Inside mhi_ep_ring_add_element, the read pointer (rd_offset) is updated before the buffer is written, potentially causing race conditions where the host sees an updated read pointer before the buffer is actually written. Updating rd_offset prematurely can lead to the host accessing an uninitialized or incomplete element, resulting in data corruption. Invoke the buffer write before updating rd_offset to ensure the element is fully written before signaling its availability. Fixes: bbdcba57a1a2 ("bus: mhi: ep: Add support for ring management") cc: stable@vger.kernel.org Co-developed-by: Youssef Samir Signed-off-by: Youssef Samir Signed-off-by: Sumit Kumar Reviewed-by: Jeff Hugo Reviewed-by: Krishna Chaitanya Chundru Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20250409-rp_fix-v1-1-8cf1fa22ed28@quicinc.com Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman commit 6ba6e64dcef5193334d96c5ab14d120906d3db99 Author: Damien Le Moal Date: Wed Jun 11 09:59:15 2025 +0900 block: Clear BIO_EMULATES_ZONE_APPEND flag on BIO completion commit f705d33c2f0353039d03e5d6f18f70467d86080e upstream. When blk_zone_write_plug_bio_endio() is called for a regular write BIO used to emulate a zone append operation, that is, a BIO flagged with BIO_EMULATES_ZONE_APPEND, the BIO operation code is restored to the original REQ_OP_ZONE_APPEND but the BIO_EMULATES_ZONE_APPEND flag is not cleared. Clear it to fully return the BIO to its orginal definition. Fixes: 9b1ce7f0c6f8 ("block: Implement zone append emulation") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Johannes Thumshirn Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20250611005915.89843-1-dlemoal@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c464a74ef512a4ff057a2d4b2141bc9ba7acdd0e Author: Jens Axboe Date: Wed Jun 11 08:48:46 2025 -0600 block: use plug request list tail for one-shot backmerge attempt commit 961296e89dc3800e6a3abc3f5d5bb4192cf31e98 upstream. Previously, the block layer stored the requests in the plug list in LIFO order. For this reason, blk_attempt_plug_merge() would check just the head entry for a back merge attempt, and abort after that unless requests for multiple queues existed in the plug list. If more than one request is present in the plug list, this makes the one-shot back merging less useful than before, as it'll always fail to find a quick merge candidate. Use the tail entry for the one-shot merge attempt, which is the last added request in the list. If that fails, abort immediately unless there are multiple queues available. If multiple queues are available, then scan the list. Ideally the latter scan would be a backwards scan of the list, but as it currently stands, the plug list is singly linked and hence this isn't easily feasible. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-block/20250611121626.7252-1-abuehaze@amazon.com/ Reported-by: Hazem Mohamed Abuelfotoh Fixes: e70c301faece ("block: don't reorder requests in blk_add_rq_to_plug") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit aa01b45271da960b382f7c8af9795269952d060a Author: Krzysztof Kozlowski Date: Mon May 26 11:47:02 2025 +0200 ASoC: codecs: wcd937x: Drop unused buck_supply commit dc59189d32fc3dbddcf418fd4b418fb61f24ade6 upstream. Last user of wcd937x_priv->buck_supply was removed in commit 216d04139a6d ("ASoC: codecs: wcd937x: Remove separate handling for vdd-buck supply"). Fixes: 216d04139a6d ("ASoC: codecs: wcd937x: Remove separate handling for vdd-buck supply") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20250526-b4-b4-asoc-wcd9395-vdd-px-fixes-v1-2-0b8a2993b7d3@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ce30258c05d39b62a05c99016d7148b3bf60fbdc Author: Krzysztof Kozlowski Date: Mon May 26 11:47:03 2025 +0200 ASoC: codecs: wcd9375: Fix double free of regulator supplies commit 63fe298652d4eda07d738bfcbbc59d1343a675ef upstream. Driver gets regulator supplies in probe path with devm_regulator_bulk_get(), so should not call regulator_bulk_free() in error and remove paths to avoid double free. Fixes: 216d04139a6d ("ASoC: codecs: wcd937x: Remove separate handling for vdd-buck supply") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20250526-b4-b4-asoc-wcd9395-vdd-px-fixes-v1-3-0b8a2993b7d3@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 7624b1cadb41aff79b653088ad4a5069bb517281 Author: Andreas Kemnade Date: Mon Mar 31 16:44:39 2025 +0200 ARM: omap: pmic-cpcap: do not mess around without CPCAP or OMAP4 commit 7397daf1029d5bfd3415ec8622f5179603d5702d upstream. The late init call just writes to omap4 registers as soon as CONFIG_MFD_CPCAP is enabled without checking whether the cpcap driver is actually there or the SoC is indeed an OMAP4. Rather do these things only with the right device combination. Fixes booting the BT200 with said configuration enabled and non-factory X-Loader and probably also some surprising behavior on other devices. Fixes: c145649bf262 ("ARM: OMAP2+: Configure voltage controller for cpcap to low-speed") CC: stable@vger.kernel.org Signed-off-by: Andreas Kemnade Reivewed-by: Tony Lindgren Link: https://lore.kernel.org/r/20250331144439.769697-1-andreas@kemnade.info Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit 1642ab77aa01d7decbed043becb0e1f15f27e981 Author: Ross Stutterheim Date: Wed Apr 16 14:50:06 2025 +0100 ARM: 9447/1: arm/memremap: fix arch_memremap_can_ram_remap() commit 96e0b355883006554a0bee3697da475971d6bba8 upstream. arm/memremap: fix arch_memremap_can_ram_remap() commit 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map") added the definition of arch_memremap_can_ram_remap() for arm[64] specific filtering of what pages can be used from the linear mapping. memblock_is_map_memory() was called with the pfn of the address given to arch_memremap_can_ram_remap(); however, memblock_is_map_memory() expects to be given an address for arm, not a pfn. This results in calls to memremap() returning a newly mapped area when it should return an address in the existing linear mapping. Fix this by removing the address to pfn translation and pass the address directly. Fixes: 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map") Signed-off-by: Ross Stutterheim Cc: Mike Rapoport Cc: stable@vger.kernel.org Reviewed-by: Catalin Marinas Reviewed-by: Linus Walleij Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit e12461b1dd3b0413ea8bde21e8c32deb4fd5dffb Author: Ryan Roberts Date: Fri May 30 16:23:47 2025 +0100 arm64/mm: Close theoretical race where stale TLB entry remains valid commit 4b634918384c0f84c33aeb4dd9fd4c38e7be5ccb upstream. Commit 3ea277194daa ("mm, mprotect: flush TLB if potentially racing with a parallel reclaim leaving stale TLB entries") describes a race that, prior to the commit, could occur between reclaim and operations such as mprotect() when using reclaim's tlbbatch mechanism. See that commit for details but the summary is: """ Nadav Amit identified a theoritical race between page reclaim and mprotect due to TLB flushes being batched outside of the PTL being held. He described the race as follows: CPU0 CPU1 ---- ---- user accesses memory using RW PTE [PTE now cached in TLB] try_to_unmap_one() ==> ptep_get_and_clear() ==> set_tlb_ubc_flush_pending() mprotect(addr, PROT_READ) ==> change_pte_range() ==> [ PTE non-present - no flush ] user writes using cached RW PTE ... try_to_unmap_flush() """ The solution was to insert flush_tlb_batched_pending() in mprotect() and friends to explcitly drain any pending reclaim TLB flushes. In the modern version of this solution, arch_flush_tlb_batched_pending() is called to do that synchronisation. arm64's tlbbatch implementation simply issues TLBIs at queue-time (arch_tlbbatch_add_pending()), eliding the trailing dsb(ish). The trailing dsb(ish) is finally issued in arch_tlbbatch_flush() at the end of the batch to wait for all the issued TLBIs to complete. Now, the Arm ARM states: """ The completion of the TLB maintenance instruction is guaranteed only by the execution of a DSB by the observer that performed the TLB maintenance instruction. The execution of a DSB by a different observer does not have this effect, even if the DSB is known to be executed after the TLB maintenance instruction is observed by that different observer. """ arch_tlbbatch_add_pending() and arch_tlbbatch_flush() conform to this requirement because they are called from the same task (either kswapd or caller of madvise(MADV_PAGEOUT)), so either they are on the same CPU or if the task was migrated, __switch_to() contains an extra dsb(ish). HOWEVER, arm64's arch_flush_tlb_batched_pending() is also implemented as a dsb(ish). But this may be running on a CPU remote from the one that issued the outstanding TLBIs. So there is no architectural gurantee of synchonization. Therefore we are still vulnerable to the theoretical race described in Commit 3ea277194daa ("mm, mprotect: flush TLB if potentially racing with a parallel reclaim leaving stale TLB entries"). Fix this by flushing the entire mm in arch_flush_tlb_batched_pending(). This aligns with what the other arches that implement the tlbbatch feature do. Cc: Fixes: 43b3dfdd0455 ("arm64: support batched/deferred tlb shootdown during page reclamation/migration") Signed-off-by: Ryan Roberts Link: https://lore.kernel.org/r/20250530152445.2430295-1-ryan.roberts@arm.com Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit bd96f6681185391447b401612b89ae8cd421daf3 Author: Ricardo Ribalda Date: Thu Mar 13 12:20:39 2025 +0000 media: uvcvideo: Fix deferred probing error commit 387e8939307192d5a852a2afeeb83427fa477151 upstream. uvc_gpio_parse() can return -EPROBE_DEFER when the GPIOs it depends on have not yet been probed. This return code should be propagated to the caller of uvc_probe() to ensure that probing is retried when the required GPIOs become available. Currently, this error code is incorrectly converted to -ENODEV, causing some internal cameras to be ignored. This commit fixes this issue by propagating the -EPROBE_DEFER error. Cc: stable@vger.kernel.org Fixes: 2886477ff987 ("media: uvcvideo: Implement UVC_EXT_GPIO_UNIT") Reviewed-by: Douglas Anderson Signed-off-by: Ricardo Ribalda Message-ID: <20250313-uvc-eprobedefer-v3-1-a1d312708eef@chromium.org> Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 193933cc72ef88ebc14309797f284d4ddb903f12 Author: Ricardo Ribalda Date: Mon Feb 24 10:34:54 2025 +0000 media: uvcvideo: Send control events for partial succeeds commit 5c791467aea6277430da5f089b9b6c2a9d8a4af7 upstream. Today, when we are applying a change to entities A, B. If A succeeds and B fails the events for A are not sent. This change changes the code so the events for A are send right after they happen. Cc: stable@kernel.org Fixes: b4012002f3a3 ("[media] uvcvideo: Add support for control events") Signed-off-by: Ricardo Ribalda Message-ID: <20250224-uvc-data-backup-v2-2-de993ed9823b@chromium.org> Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit c1ca12d5910c795ae9bff1e19b4349413d790901 Author: Ricardo Ribalda Date: Mon Feb 24 10:34:53 2025 +0000 media: uvcvideo: Return the number of processed controls commit ba4fafb02ad6a4eb2e00f861893b5db42ba54369 upstream. If we let know our callers that we have not done anything, they will be able to optimize their decisions. Cc: stable@kernel.org Fixes: b4012002f3a3 ("[media] uvcvideo: Add support for control events") Reviewed-by: Laurent Pinchart Signed-off-by: Ricardo Ribalda Message-ID: <20250224-uvc-data-backup-v2-1-de993ed9823b@chromium.org> Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6d0efe7d35c75394f32ff9d0650a007642d23857 Author: Ming Qian Date: Mon Apr 21 16:12:54 2025 +0800 media: imx-jpeg: Cleanup after an allocation error commit 7500bb9cf164edbb2c8117d57620227b1a4a8369 upstream. When allocation failures are not cleaned up by the driver, further allocation errors will be false-positives, which will cause buffers to remain uninitialized and cause NULL pointer dereferences. Ensure proper cleanup of failed allocations to prevent these issues. Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Reviewed-by: Frank Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit b558492a946432d5339fb2c17e4fe13be796d4d0 Author: Ming Qian Date: Mon Apr 21 16:12:53 2025 +0800 media: imx-jpeg: Reset slot data pointers when freed commit faa8051b128f4b34277ea8a026d02d83826f8122 upstream. Ensure that the slot data pointers are reset to NULL and handles are set to 0 after freeing the coherent memory. This makes he function mxc_jpeg_alloc_slot_data() and mxc_jpeg_free_slot_data() safe to be called multiple times. Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Reviewed-by: Nicolas Dufresne Reviewed-by: Frank Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit c7aad2d9c8e8c5521f41db66c9ac3a61539717ad Author: Ming Qian Date: Mon Apr 21 16:12:52 2025 +0800 media: imx-jpeg: Move mxc_jpeg_free_slot_data() ahead commit 46e9c092f850bd7b4d06de92d3d21877f49a3fcb upstream. Move function mxc_jpeg_free_slot_data() above mxc_jpeg_alloc_slot_data() allowing to call that function during allocation failures. No functional changes are made. Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Reviewed-by: Nicolas Dufresne Reviewed-by: Frank Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit bc2417888e5c33dcf72aebcfc8de82680f911053 Author: Ming Qian Date: Mon Apr 21 15:06:12 2025 +0800 media: imx-jpeg: Drop the first error frames commit d52b9b7e2f10d22a49468128540533e8d76910cd upstream. When an output buffer contains error frame header, v4l2_jpeg_parse_header() will return error, then driver will mark this buffer and a capture buffer done with error flag in device_run(). But if the error occurs in the first frames, before setup the capture queue, there is no chance to schedule device_run(), and there may be no capture to mark error. So we need to drop this buffer with error flag, and make the decoding can continue. Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit c56398885716d97ee9bcadb2bc9663a8c1757a34 Author: Denis Arefev Date: Tue Apr 15 11:27:21 2025 +0300 media: vivid: Change the siize of the composing commit f83ac8d30c43fd902af7c84c480f216157b60ef0 upstream. syzkaller found a bug: BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline] BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705 Write of size 1440 at addr ffffc9000d0ffda0 by task vivid-000-vid-c/5304 CPU: 0 UID: 0 PID: 5304 Comm: vivid-000-vid-c Not tainted 6.14.0-rc2-syzkaller-00039-g09fbf3d50205 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline] tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705 vivid_fillbuff drivers/media/test-drivers/vivid/vivid-kthread-cap.c:470 [inline] vivid_thread_vid_cap_tick+0xf8e/0x60d0 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:629 vivid_thread_vid_cap+0x8aa/0xf30 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:767 kthread+0x7a9/0x920 kernel/kthread.c:464 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The composition size cannot be larger than the size of fmt_cap_rect. So execute v4l2_rect_map_inside() even if has_compose_cap == 0. Fixes: 94a7ad928346 ("media: vivid: fix compose size exceed boundary") Cc: stable@vger.kernel.org Reported-by: syzbot+365005005522b70a36f2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?id=8ed8e8cc30cbe0d86c9a25bd1d6a5775129b8ea3 Signed-off-by: Denis Arefev Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f8c2483be6e8bb6c2148315b4a924c65bb442b5e Author: Edward Adam Davis Date: Tue Mar 11 15:20:14 2025 +0800 media: vidtv: Terminating the subsequent process of initialization failure commit 1d5f88f053480326873115092bc116b7d14916ba upstream. syzbot reported a slab-use-after-free Read in vidtv_mux_init. [1] After PSI initialization fails, the si member is accessed again, resulting in this uaf. After si initialization fails, the subsequent process needs to be exited. [1] BUG: KASAN: slab-use-after-free in vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78 [inline] BUG: KASAN: slab-use-after-free in vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524 Read of size 8 at addr ffff88802fa42acc by task syz.2.37/6059 CPU: 0 UID: 0 PID: 6059 Comm: syz.2.37 Not tainted 6.14.0-rc5-syzkaller #0 Hardware name: Google Compute Engine, BIOS Google 02/12/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xd9/0x110 mm/kasan/report.c:634 vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78 vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973 dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline] dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537 dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3ff/0xb70 fs/file_table.c:464 task_work_run+0x14e/0x250 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xad8/0x2d70 kernel/exit.c:938 do_group_exit+0xd3/0x2a0 kernel/exit.c:1087 __do_sys_exit_group kernel/exit.c:1098 [inline] __se_sys_exit_group kernel/exit.c:1096 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1096 x64_sys_call+0x151f/0x1720 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f871d58d169 Code: Unable to access opcode bytes at 0x7f871d58d13f. RSP: 002b:00007fff4b19a788 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f871d58d169 RDX: 0000000000000064 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00007fff4b19a7ec R08: 0000000b4b19a87f R09: 00000000000927c0 R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000003 R13: 00000000000927c0 R14: 000000000001d553 R15: 00007fff4b19a840 Allocated by task 6059: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] vidtv_psi_pat_table_init drivers/media/test-drivers/vidtv/vidtv_psi.c:970 vidtv_channel_si_init drivers/media/test-drivers/vidtv/vidtv_channel.c:423 vidtv_mux_init drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973 dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline] dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537 dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3ff/0xb70 fs/file_table.c:464 task_work_run+0x14e/0x250 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xad8/0x2d70 kernel/exit.c:938 do_group_exit+0xd3/0x2a0 kernel/exit.c:1087 __do_sys_exit_group kernel/exit.c:1098 [inline] __se_sys_exit_group kernel/exit.c:1096 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1096 x64_sys_call arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6059: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x51/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4609 [inline] kfree+0x2c4/0x4d0 mm/slub.c:4757 vidtv_channel_si_init drivers/media/test-drivers/vidtv/vidtv_channel.c:499 vidtv_mux_init drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973 dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline] dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537 dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3ff/0xb70 fs/file_table.c:464 task_work_run+0x14e/0x250 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xad8/0x2d70 kernel/exit.c:938 do_group_exit+0xd3/0x2a0 kernel/exit.c:1087 __do_sys_exit_group kernel/exit.c:1098 [inline] __se_sys_exit_group kernel/exit.c:1096 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1096 x64_sys_call arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 3be8037960bc ("media: vidtv: add error checks") Cc: stable@vger.kernel.org Reported-by: syzbot+0d33ab192bd50b6c91e6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0d33ab192bd50b6c91e6 Signed-off-by: Edward Adam Davis Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 856853d1703dbdcc9e0255c8cd88f9b9c6974993 Author: Marek Szyprowski Date: Wed May 7 18:09:11 2025 +0200 media: videobuf2: use sgtable-based scatterlist wrappers commit a704a3c503ae1cfd9de8a2e2d16a0c9430e98162 upstream. Use common wrappers operating directly on the struct sg_table objects to fix incorrect use of scatterlists sync calls. dma_sync_sg_for_*() functions have to be called with the number of elements originally passed to dma_map_sg_*() function, not the one returned in sgt->nents. Fixes: d4db5eb57cab ("media: videobuf2: add begin/end cpu_access callbacks to dma-sg") CC: stable@vger.kernel.org Signed-off-by: Marek Szyprowski Reviewed-by: Sergey Senozhatsky Acked-by: Tomasz Figa Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 1a319f074e7bb9e691df2f0721d1bb3de01a1d62 Author: Loic Poulain Date: Thu Mar 27 13:53:04 2025 +0100 media: venus: Fix probe error handling commit 523cea3a19f0b3b020a4745344c136a636e6ffd7 upstream. Video device registering has been moved earlier in the probe function, but the new order has not been propagated to error handling. This means we can end with unreleased resources on error (e.g dangling video device on missing firmware probe aborting). Fixes: 08b1cf474b7f7 ("media: venus: core, venc, vdec: Fix probe dependency error") Cc: stable@vger.kernel.org Signed-off-by: Loic Poulain Reviewed-by: Dikshita Agarwal Reviewed-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4451412739ed33a49b34624299394ee575116d0c Author: Ma Ke Date: Wed Mar 19 16:02:48 2025 +0800 media: v4l2-dev: fix error handling in __video_register_device() commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a upstream. Once device_register() failed, we should call put_device() to decrement reference count for cleanup. Or it could cause memory leak. And move callback function v4l2_device_release() and v4l2_device_get() before put_device(). As comment of device_register() says, 'NOTE: _Never_ directly free @dev after calling this function, even if it returned an error! Always use put_device() to give up the reference initialized in this function instead.' Found by code review. Cc: stable@vger.kernel.org Fixes: dc93a70cc7f9 ("V4L/DVB (9973): v4l2-dev: use the release callback from device instead of cdev") Signed-off-by: Ma Ke Reviewed-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit bc601a9f4bc6cc91ef8eee76dbd2f5536b4922c5 Author: Tomi Valkeinen Date: Thu Apr 24 10:05:36 2025 +0300 media: rcar-vin: Fix RAW10 commit 94bf847ae5a61e0ab0b971ed186a443688eb793f upstream. Fix the following to get RAW10 formats working: In rvin_formats, the bpp is set to 4 for RAW10. As VIN unpacks RAW10 to 16-bit containers, the bpp should be 2. Don't set VNDMR_YC_THR to the VNDMR register. The YC_THR is "YC Data Through Mode", used for YUV formats and should not be set for RAW10. Fixes: 1b7e7240eaf3 ("media: rcar-vin: Add support for RAW10") Cc: stable@vger.kernel.org Signed-off-by: Tomi Valkeinen Reviewed-by: Niklas Söderlund Tested-by: Niklas Söderlund Link: https://lore.kernel.org/r/20250424-rcar-fix-raw-v2-4-f6afca378124@ideasonboard.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit cf4442cae81af69958193b6ba3dd415561cfb067 Author: Johan Hovold Date: Mon Apr 7 12:48:28 2025 +0200 media: qcom: camss: vfe: suppress VFE version log spam commit b6fafb3941fa0f065def304d44d6c3c6d6ac0f64 upstream. A recent commit refactored the printing of the VFE hardware version, but (without it being mentioned) also changed the log level from debug to info. This results in several hundred lines of repeated log spam during boot and use, for example, on the Lenovo ThinkPad X13s: qcom-camss ac5a000.camss: VFE:1 HW Version = 1.2.2 qcom-camss ac5a000.camss: VFE:0 HW Version = 1.2.2 qcom-camss ac5a000.camss: VFE:2 HW Version = 1.2.2 qcom-camss ac5a000.camss: VFE:2 HW Version = 1.2.2 qcom-camss ac5a000.camss: VFE:3 HW Version = 1.2.2 qcom-camss ac5a000.camss: VFE:5 HW Version = 1.3.0 qcom-camss ac5a000.camss: VFE:6 HW Version = 1.3.0 qcom-camss ac5a000.camss: VFE:4 HW Version = 1.3.0 qcom-camss ac5a000.camss: VFE:5 HW Version = 1.3.0 qcom-camss ac5a000.camss: VFE:6 HW Version = 1.3.0 qcom-camss ac5a000.camss: VFE:7 HW Version = 1.3.0 qcom-camss ac5a000.camss: VFE:7 HW Version = 1.3.0 qcom-camss ac5a000.camss: VFE:7 HW Version = 1.3.0 ... Suppress the version logging by demoting to debug level again. Fixes: 10693fed125d ("media: qcom: camss: vfe: Move common code into vfe core") Cc: stable@vger.kernel.org Cc: Depeng Shao Reviewed-by: Bryan O'Donoghue Signed-off-by: Johan Hovold Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9d61abf1a5f5753ce8be8b855947549582782579 Author: Johan Hovold Date: Mon Apr 7 10:51:25 2025 +0200 media: qcom: camss: csid: suppress CSID log spam commit aef1d545989bc9e7f555af6b9f1be4963772192b upstream. A recent commit refactored the printing of the CSID hardware version, but (without it being mentioned) also changed the log level from debug to info. This results in repeated log spam during use, for example, on the Lenovo ThinkPad X13s: qcom-camss ac5a000.camss: CSID:0 HW Version = 1.0.0 qcom-camss ac5a000.camss: CSID:0 HW Version = 1.0.0 qcom-camss ac5a000.camss: CSID:0 HW Version = 1.0.0 qcom-camss ac5a000.camss: CSID:0 HW Version = 1.0.0 qcom-camss ac5a000.camss: CSID:0 HW Version = 1.0.0 Suppress the version logging by demoting to debug level again. Fixes: f759b8fd3086 ("media: qcom: camss: csid: Move common code into csid core") Cc: stable@vger.kernel.org Cc: Depeng Shao Signed-off-by: Johan Hovold Reviewed-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit cd5320dd7021aeb47b30082107b408d00a06c34d Author: Hans de Goede Date: Tue Mar 11 12:48:44 2025 +0100 media: ov08x40: Extend sleep after reset to 5 ms commit 77aed862c34f192f9d4b80d5288263b22b50ca98 upstream. Some users are reporting that ov08x40_identify_module() fails to identify the chip reading 0x00 as value for OV08X40_REG_CHIP_ID. Intel's out of tree IPU6 drivers include some ov08x40 changes including adding support for the reset GPIO for older kernels and Intel's patch for this uses 5 ms. Extend the sleep to 5 ms following Intel's example, this fixes the ov08x40_identify_module() problem. Link: https://github.com/intel/ipu6-drivers/blob/c09e2198d801e1eb701984d2948373123ba92a56/patch/v6.12/0008-media-ov08x40-Add-support-for-2-4-lanes-support-at-1.patch#L4607 Fixes: df1ae2251a50 ("media: ov08x40: Add OF probe support") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Reviewed-by: Bryan O'Donoghue Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit aa955e37774f96afaa1ac249f9eac18b7a3c673b Author: Marek Szyprowski Date: Wed May 7 18:09:13 2025 +0200 media: omap3isp: use sgtable-based scatterlist wrappers commit 3de572fe2189a4a0bd80295e1f478401e739498e upstream. Use common wrappers operating directly on the struct sg_table objects to fix incorrect use of scatterlists sync calls. dma_sync_sg_for_*() functions have to be called with the number of elements originally passed to dma_map_sg_*() function, not the one returned in sgtable's nents. Fixes: d33186d0be18 ("[media] omap3isp: ccdc: Use the DMA API for LSC") Fixes: 0e24e90f2ca7 ("[media] omap3isp: stat: Use the DMA API") CC: stable@vger.kernel.org Signed-off-by: Marek Szyprowski Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit fdcab88da72555dc387260a7207446364c7f6d5a Author: Fei Shao Date: Fri Mar 14 15:56:17 2025 +0800 media: mediatek: vcodec: Correct vsi_core framebuffer size commit f19035b86382f635a0d13d177b601babaf263a12 upstream. The framebuffer size for decoder instances was being incorrectly set - inst->vsi_core->fb.y.size was assigned twice consecutively. Assign the second picinfo framebuffer size to the C framebuffer instead, which appears to be the intended target based on the surrounding code. Fixes: 2674486aac7d ("media: mediatek: vcodec: support stateless hevc decoder") Cc: stable@vger.kernel.org Signed-off-by: Fei Shao Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 0a64fb2f3ad1059c41ece95409980c2b26e0906d Author: Dan Carpenter Date: Mon Feb 17 11:08:00 2025 +0300 media: iris: fix error code in iris_load_fw_to_memory() commit e68c3c50a736490d9c07888fe525718d16ff9e9c upstream. Return -ENOMEM if memremap() fails. Don't return success. Fixes: d19b163356b8 ("media: iris: implement video firmware load/unload") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter Reviewed-by: Dikshita Agarwal Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit c46fb1783d96d48892747b2bc601198767381778 Author: Hao Yao Date: Tue Mar 11 16:41:55 2025 +0800 media: ipu6: Remove workaround for Meteor Lake ES2 commit d471fb06b21ae54bf76464731ae1dcb26ef1ca68 upstream. There was a hardware bug which need IPU6 driver to disable the ATS. This workaround is not needed anymore as the bug was fixed in hardware level. Additionally, Arrow Lake has the same IPU6 PCI ID and x86 stepping but does not have the bug. Removing the Meteor Lake workaround is also required for the driver to function on Arrow Lake. Signed-off-by: Hao Yao Reviewed-by: Stanislaw Gruszka Fixes: 25fedc021985 ("media: intel/ipu6: add Intel IPU6 PCI device driver") Cc: stable@vger.kernel.org [Sakari Ailus: Added tags and explanation of what is fixed.] Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit a74d6dcfa050c7369e7220d0f14847abd36aedc1 Author: Stanislaw Gruszka Date: Thu Apr 10 11:47:06 2025 +0200 media: intel/ipu6: Fix dma mask for non-secure mode commit 0209916ebe2475079ce6d8dc4114afbc0ccad1c2 upstream. We use dma_get_mask() of auxdev device for calculate iova pfn limit. This is always 32 bit mask as we do not initialize the mask (and we can not do so, since dev->dev_mask is NULL anyways for auxdev). Since we need 31 bit mask for non-secure mode use mmu_info->aperture_end which is properly initialized to correct mask for both modes. Fixes: daabc5c64703 ("media: ipu6: not override the dma_ops of device in driver") Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit fac3b9a91fa099d9bad29648127c0328d6c478c3 Author: Haoxiang Li Date: Wed Feb 26 20:49:22 2025 +0800 media: imagination: fix a potential memory leak in e5010_probe() commit 609ba05b9484856b08869f827a6edee51d51b5f3 upstream. Add video_device_release() to release the memory allocated by video_device_alloc() if something goes wrong. Fixes: a1e294045885 ("media: imagination: Add E5010 JPEG Encoder driver") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 35a26625ee636a89130b5217c192996f928b1108 Author: Kieran Bingham Date: Wed Apr 30 08:36:49 2025 +0100 media: i2c: imx335: Fix frame size enumeration commit b240df2913d396638033b86af0f0ff76aa1aafc8 upstream. In commit cfa49ff0558a ("media: i2c: imx335: Support 2592x1940 10-bit mode") the IMX335 driver was extended to support multiple output bitdepth modes. This incorrectly extended the frame size enumeration to check against the supported mbus_codes array instead of the supported mode/frame array. This has the unwanted side effect of reporting the currently supported frame size 2592x1944 three times. Fix the check accordingly to report a frame size for each supported size, which is presently only a single entry. Fixes: cfa49ff0558a ("media: i2c: imx335: Support 2592x1940 10-bit mode") Cc: stable@vger.kernel.org Signed-off-by: Kieran Bingham Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6adfe6ad77c8bb4d2941029f9686cb0c746761f7 Author: Wentao Liang Date: Tue Apr 22 11:07:39 2025 +0800 media: gspca: Add error handling for stv06xx_read_sensor() commit 398a1b33f1479af35ca915c5efc9b00d6204f8fa upstream. In hdcs_init(), the return value of stv06xx_read_sensor() needs to be checked. A proper implementation can be found in vv6410_dump(). Add a check in loop condition and propergate error code to fix this issue. Fixes: 4c98834addfe ("V4L/DVB (10048): gspca - stv06xx: New subdriver.") Cc: stable@vger.kernel.org # v2.6+ Signed-off-by: Wentao Liang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 5372682a1a876343b1da0dcefc2f3c91c9c72c31 Author: Dmitry Nikiforov Date: Wed Apr 16 23:51:19 2025 +0300 media: davinci: vpif: Fix memory leak in probe error path commit 024bf40edf1155e7a587f0ec46294049777d9b02 upstream. If an error occurs during the initialization of `pdev_display`, the allocated platform device `pdev_capture` is not released properly, leading to a memory leak. Adjust error path handling to fix the leak. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 43acb728bbc4 ("media: davinci: vpif: fix use-after-free on driver unbind") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Nikiforov Reviewed-by: Johan Hovold Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 8b35b50b7e98d8e9a0a27257c8424448afae10de Author: Edward Adam Davis Date: Sat Apr 5 19:56:41 2025 +0800 media: cxusb: no longer judge rbuf when the write fails commit 73fb3b92da84637e3817580fa205d48065924e15 upstream. syzbot reported a uninit-value in cxusb_i2c_xfer. [1] Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw() succeeds and rlen is greater than 0, the read operation of usb_bulk_msg() will be executed to read rlen bytes of data from the dvb device into the rbuf. In this case, although rlen is 1, the write operation failed which resulted in the dvb read operation not being executed, and ultimately variable i was not initialized. [1] BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reported-by: syzbot+526bd95c0ec629993bf3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=526bd95c0ec629993bf3 Tested-by: syzbot+526bd95c0ec629993bf3@syzkaller.appspotmail.com Fixes: 22c6d93a7310 ("[PATCH] dvb: usb: support Medion hybrid USB2.0 DVB-T/analogue box") Cc: stable@vger.kernel.org Signed-off-by: Edward Adam Davis Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 2d88e349ce04e308541377b74ac5548439d6d9a9 Author: Sakari Ailus Date: Thu Feb 20 10:54:44 2025 +0200 media: ccs-pll: Check for too high VT PLL multiplier in dual PLL case commit 6868b955acd6e5d7405a2b730c2ffb692ad50d2c upstream. The check for VT PLL upper limit in dual PLL case was missing. Add it now. Fixes: 6c7469e46b60 ("media: ccs-pll: Add trivial dual PLL support") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 914e8f7848d8820d3e63d92c5a03c37f72291a14 Author: Sakari Ailus Date: Wed Feb 19 15:06:11 2025 +0200 media: ccs-pll: Correct the upper limit of maximum op_pre_pll_clk_div commit f639494db450770fa30d6845d9c84b9cb009758f upstream. The PLL calculator does a search of the PLL configuration space for all valid OP pre-PLL clock dividers. The maximum did not take into account the CCS PLL flag CCS_PLL_FLAG_EXT_IP_PLL_DIVIDER in which case also odd PLL dividers (other than 1) are valid. Do that now. Fixes: 4e1e8d240dff ("media: ccs-pll: Add support for extended input PLL clock divider") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 092c29ee937dd37e7cb6d8638274cf5dc5ae5442 Author: Sakari Ailus Date: Tue Feb 18 23:43:58 2025 +0200 media: ccs-pll: Start OP pre-PLL multiplier search from correct value commit 660e613d05e449766784c549faf5927ffaf281f1 upstream. The ccs_pll_calculate() function does a search over possible PLL configurations to find the "best" one. If the sensor does not support odd pre-PLL divisors and the minimum value (with constraints) isn't 1, other odd values could be errorneously searched (and selected) for the pre-PLL divisor. Fix this. Fixes: 415ddd993978 ("media: ccs-pll: Split limits and PLL configuration into front and back parts") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 450784bd24d6549a80c697dae7442cdfd0d3b480 Author: Hans de Goede Date: Mon Mar 24 14:01:09 2025 +0100 media: ov2740: Move pm-runtime cleanup on probe-errors to proper place commit 81cf4f46a03a07b0b86f9d677c34ba782df7d65e upstream. When v4l2_subdev_init_finalize() fails no changes have been made to the runtime-pm device state yet, so the probe_error_media_entity_cleanup rollback path should not touch the runtime-pm device state. Instead this should be done from the probe_error_v4l2_subdev_cleanup rollback path. Note the pm_runtime_xxx() calls are put above the v4l2_subdev_cleanup() call to have the reverse call order of probe(). Signed-off-by: Hans de Goede Reviewed-by: Bingbu Cao Fixes: 289c25923ecd ("media: ov2740: Use sub-device active state") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit bc4aea40eef4a3c00f8e2c84dbe991c3a7559717 Author: Sakari Ailus Date: Tue Feb 18 23:47:13 2025 +0200 media: ccs-pll: Start VT pre-PLL multiplier search from correct value commit 06d2d478b09e6764fb6161d1621fc10d9f0f2860 upstream. The ccs_pll_calculate_vt_tree() function does a search over possible VT PLL configurations to find the "best" one. If the sensor does not support odd pre-PLL divisors and the minimum value (with constraints) isn't 1, other odd values could be errorneously searched (and selected) for the pre-PLL divisor. Fix this. Fixes: 415ddd993978 ("media: ccs-pll: Split limits and PLL configuration into front and back parts") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 77065bd8a7c8c06eaae05e8c101ed27ce1d1c915 Author: Tomi Valkeinen Date: Mon Mar 3 21:32:05 2025 +0530 media: i2c: ds90ub913: Fix returned fmt from .set_fmt() commit ef205273132bdc9bcfa1540eef8105475a453300 upstream. When setting the sink pad's stream format, set_fmt accidentally changes the returned format's code to 'outcode', while the purpose is to only use the 'outcode' for the propagated source stream format. Fixes: c158d0d4ff15 ("media: i2c: add DS90UB913 driver") Cc: stable@vger.kernel.org Signed-off-by: Tomi Valkeinen Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 091e72c314180f833f526a33f08ccddb59ddef2f Author: Laurentiu Palcu Date: Wed Oct 23 11:56:43 2024 +0300 media: nxp: imx8-isi: better handle the m2m usage_count commit 910efa649076be9c2e1326059830327cf4228cf6 upstream. Currently, if streamon/streamoff calls are imbalanced we can either end up with a negative ISI m2m usage_count (if streamoff() is called more times than streamon()) in which case we'll not be able to restart the ISI pipe next time, or the usage_count never gets to 0 and the pipe is never switched off. To avoid that, add a 'streaming' flag to mxc_isi_m2m_ctx_queue_data and use it in the streamon/streamoff to avoid incrementing/decrementing the usage_count uselessly, if called multiple times from the same context. Fixes: cf21f328fcafac ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Suggested-by: Laurent Pinchart Signed-off-by: Laurentiu Palcu Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20241023085643.978729-1-laurentiu.palcu@oss.nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 59401821332806a36ece0a3f4547917530431dc9 Author: Umang Jain Date: Tue Apr 22 13:20:52 2025 +0100 media: imx335: Use correct register width for HNUM commit b122c9cfcb39c8ef520d50eddfbe15f3e6551a50 upstream. CCI_REG_HNUM should be using CCI_REG16_LE() instead of CCI_REG8() as HNUM spans from 0x302e[0:7] to 0x302f[0:3]. Signed-off-by: Umang Jain Signed-off-by: Kieran Bingham Fixes: 8f0926dba799 ("media: imx335: Use V4L2 CCI for accessing sensor registers") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit ea1fadaef4a187337178ccf167a2b175967b118b Author: Dongcheng Yan Date: Fri Apr 25 18:43:31 2025 +0800 media: i2c: change lt6911uxe irq_gpio name to "hpd" commit 20244cbafbd6c8486347bb82d972f6e2d2d5a201 upstream. Lt6911uxe is used in IPU6 / x86 platform, worked with an out-of-tree int3472 patch and upstream intel/ipu6 before. It is only used on ACPI platforms till now and there are no devicetree bindings for this driver. The upstream int3472 driver uses "hpd" instead of "readystat" now. this patch updates the irq_gpio name to "hpd" accordingly, so that mere users can now use the upstream version directly without relying on out-of-tree int3472 pin support. The new name "hpd" (Hotplug Detect) aligns with common naming conventions used in other drivers(like adv7604) and documentation. Fixes: e49563c3be09d4 ("media: i2c: add lt6911uxe hdmi bridge driver") Cc: stable@vger.kernel.org Signed-off-by: Dongcheng Yan Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit ba58c3e51ff92ce533c2400bf9e26d785432a197 Author: Johan Hovold Date: Fri Apr 25 14:52:37 2025 +0200 media: ov5675: suppress probe deferral errors commit 8268da3c474a43a79a6540fb06c5d3b730a0d5a5 upstream. Probe deferral should not be logged as an error: ov5675 24-0010: failed to get HW configuration: -517 Drop the (mostly) redundant dev_err() from sensor probe() to suppress it. Note that errors during clock and regulator lookup are already correctly logged using dev_err_probe(). Fixes: 49d9ad719e89 ("media: ov5675: add device-tree support and support runtime PM") Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 2e003dbd5d8b90ebb7a88f8951b8e69aa66539a5 Author: Johan Hovold Date: Fri Apr 25 14:52:38 2025 +0200 media: ov8856: suppress probe deferral errors commit e3d86847fba58cf71f66e81b6a2515e07039ae17 upstream. Probe deferral should not be logged as an error: ov8856 24-0010: failed to get HW configuration: -517 Use dev_err_probe() for the clock lookup and drop the (mostly) redundant dev_err() from sensor probe() to suppress it. Note that errors during regulator lookup is already correctly logged using dev_err_probe(). Fixes: 0c2c7a1e0d69 ("media: ov8856: Add devicetree support") Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit b62a1e59d8716bbd2e73660743fe06acc97ed7d1 Author: Vasiliy Kovalev Date: Mon Mar 10 11:56:02 2025 +0300 jfs: validate AG parameters in dbMount() to prevent crashes commit 37bfb464ddca87f203071b5bd562cd91ddc0b40a upstream. Validate db_agheight, db_agwidth, and db_agstart in dbMount to catch corrupted metadata early and avoid undefined behavior in dbAllocAG. Limits are derived from L2LPERCTL, LPERCTL/MAXAG, and CTLTREESIZE: - agheight: 0 to L2LPERCTL/2 (0 to 5) ensures shift (L2LPERCTL - 2*agheight) >= 0. - agwidth: 1 to min(LPERCTL/MAXAG, 2^(L2LPERCTL - 2*agheight)) ensures agperlev >= 1. - Ranges: 1-8 (agheight 0-3), 1-4 (agheight 4), 1 (agheight 5). - LPERCTL/MAXAG = 1024/128 = 8 limits leaves per AG; 2^(10 - 2*agheight) prevents division to 0. - agstart: 0 to CTLTREESIZE-1 - agwidth*(MAXAG-1) keeps ti within stree (size 1365). - Ranges: 0-1237 (agwidth 1), 0-348 (agwidth 8). UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:1400:9 shift exponent -335544310 is negative CPU: 0 UID: 0 PID: 5822 Comm: syz-executor130 Not tainted 6.14.0-rc5-syzkaller #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 dbAllocAG+0x1087/0x10b0 fs/jfs/jfs_dmap.c:1400 dbDiscardAG+0x352/0xa20 fs/jfs/jfs_dmap.c:1613 jfs_ioc_trim+0x45a/0x6b0 fs/jfs/jfs_discard.c:105 jfs_ioctl+0x2cd/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Cc: stable@vger.kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+fe8264911355151c487f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=fe8264911355151c487f Signed-off-by: Vasiliy Kovalev Signed-off-by: Dave Kleikamp Signed-off-by: Greg Kroah-Hartman commit d2c36e1b323b1796a365a561aff739031c579f1d Author: Mingcong Bai Date: Tue Apr 22 14:17:54 2025 +0800 wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723 commit 77a6407c6ab240527166fb19ee96e95f5be4d3cd upstream. RTL8723BE found on some ASUSTek laptops, such as F441U and X555UQ with subsystem ID 11ad:1723 are known to output large amounts of PCIe AER errors during and after boot up, causing heavy lags and at times lock-ups: pcieport 0000:00:1c.5: AER: Correctable error message received from 0000:00:1c.5 pcieport 0000:00:1c.5: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID) pcieport 0000:00:1c.5: device [8086:9d15] error status/mask=00000001/00002000 pcieport 0000:00:1c.5: [ 0] RxErr Disable ASPM on this combo as a quirk. This patch is a revision of a previous patch (linked below) which attempted to disable ASPM for RTL8723BE on all Intel Skylake and Kaby Lake PCIe bridges. I take a more conservative approach as all known reports point to ASUSTek laptops of these two generations with this particular wireless card. Please note, however, before the rtl8723be finishes probing, the AER errors remained. After the module finishes probing, all AER errors would indeed be eliminated, along with heavy lags, poor network throughput, and/or occasional lock-ups. Cc: Fixes: a619d1abe20c ("rtlwifi: rtl8723be: Add new driver") Reported-by: Liangliang Zou Link: https://bugzilla.kernel.org/show_bug.cgi?id=218127 Link: https://lore.kernel.org/lkml/05390e0b-27fd-4190-971e-e70a498c8221@lwfinger.net/T/ Tested-by: Liangliang Zou Signed-off-by: Mingcong Bai Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250422061755.356535-1-jeffbai@aosc.io Signed-off-by: Greg Kroah-Hartman commit b52e3fcaa0f8c1d91338b5ac7308875608f2f343 Author: Bitterblue Smith Date: Sat May 10 15:21:25 2025 +0300 wifi: rtw88: usb: Reduce control message timeout to 500 ms commit 490340faddea461319652ce36dbc7c1b4482c35e upstream. RTL8811AU stops responding during the firmware download on some systems: [ 809.256440] rtw_8821au 5-2.1:1.0: Firmware version 42.4.0, H2C version 0 [ 812.759142] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: renamed from wlan0 [ 837.315388] rtw_8821au 1-4:1.0: write register 0x1ef4 failed with -110 [ 867.524259] rtw_8821au 1-4:1.0: write register 0x1ef8 failed with -110 [ 868.930976] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: entered promiscuous mode [ 897.730952] rtw_8821au 1-4:1.0: write register 0x1efc failed with -110 Each write takes 30 seconds to fail because that's the timeout currently used for control messages in rtw_usb_write(). In this scenario the firmware download takes at least 2000 seconds. Because this is done from the USB probe function, the long delay makes other things in the system hang. Reduce the timeout to 500 ms. This is the value used by the official USB wifi drivers from Realtek. Of course this only makes things hang for ~30 seconds instead of ~30 minutes. It doesn't fix the firmware download. Tested with RTL8822CU, RTL8812BU, RTL8811CU, RTL8814AU, RTL8811AU, RTL8812AU, RTL8821AU, RTL8723DU. Cc: stable@vger.kernel.org Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support") Link: https://github.com/lwfinger/rtw88/issues/344 Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/1e35dd26-3f10-40b1-b2b4-f72184a26611@gmail.com Signed-off-by: Greg Kroah-Hartman commit d310955106c358c8e1ea682defd8e21af44a6cba Author: Chuck Lever Date: Sun Apr 27 12:39:59 2025 -0400 svcrdma: Unregister the device if svc_rdma_accept() fails commit 8ac6fcae5dc0e801f1c82a83f5ae2c0a4db19932 upstream. To handle device removal, svc_rdma_accept() requests removal notification for the underlying device when accepting a connection. However svc_rdma_free() is not invoked if svc_rdma_accept() fails. There needs to be a matching "unregister" in that case; otherwise the device cannot be removed. Fixes: c4de97f7c454 ("svcrdma: Handle device removal outside of the CM event handler") Cc: stable@vger.kernel.org Reviewed-by: Zhu Yanjun Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit a377996d714afb8d4d5f4906336f78510039da29 Author: Jeongjun Park Date: Wed May 14 22:08:55 2025 +0900 jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata() commit af98b0157adf6504fade79b3e6cb260c4ff68e37 upstream. Since handle->h_transaction may be a NULL pointer, so we should change it to call is_handle_aborted(handle) first before dereferencing it. And the following data-race was reported in my fuzzer: ================================================================== BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1: jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0: jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... value changed: 0x00000000 -> 0x00000001 ================================================================== This issue is caused by missing data-race annotation for jh->b_modified. Therefore, the missing annotation needs to be added. Reported-by: syzbot+de24c3fe3c4091051710@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=de24c3fe3c4091051710 Fixes: 6e06ae88edae ("jbd2: speedup jbd2_journal_dirty_metadata()") Signed-off-by: Jeongjun Park Reviewed-by: Jan Kara Link: https://patch.msgid.link/20250514130855.99010-1-aha310510@gmail.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit c5e7b56db07b12ad0520e6c1771ffd476e1d2b1f Author: Johan Hovold Date: Fri Mar 21 10:52:19 2025 +0100 wifi: ath12k: fix ring-buffer corruption commit 6b67d2cf14ea997061f61e9c8afd4e1c0f22acb9 upstream. Users of the Lenovo ThinkPad X13s have reported that Wi-Fi sometimes breaks and the log fills up with errors like: ath11k_pci 0006:01:00.0: HTC Rx: insufficient length, got 1484, expected 1492 ath11k_pci 0006:01:00.0: HTC Rx: insufficient length, got 1460, expected 1484 which based on a quick look at the ath11k driver seemed to indicate some kind of ring-buffer corruption. Miaoqing Pan tracked it down to the host seeing the updated destination ring head pointer before the updated descriptor, and the error handling for that in turn leaves the ring buffer in an inconsistent state. While this has not yet been observed with ath12k, the ring-buffer implementation is very similar to the ath11k one and it suffers from the same bugs. Add the missing memory barrier to make sure that the descriptor is read after the head pointer to address the root cause of the corruption while fixing up the error handling in case there are ever any (ordering) bugs on the device side. Note that the READ_ONCE() are only needed to avoid compiler mischief in case the ring-buffer helpers are ever inlined. 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: stable@vger.kernel.org # 6.3 Link: https://bugzilla.kernel.org/show_bug.cgi?id=218623 Link: https://lore.kernel.org/20250310010217.3845141-3-quic_miaoqing@quicinc.com Cc: Miaoqing Pan Signed-off-by: Johan Hovold Reviewed-by: Miaoqing Pan Link: https://patch.msgid.link/20250321095219.19369-1-johan+linaro@kernel.org Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit 1e93b61d3eaa14bfebcc2716ac09d43f3845d420 Author: Max Kellermann Date: Wed Apr 23 15:22:50 2025 +0200 fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio() commit 4c10fa44bc5f700e2ea21de2fbae520ba21f19d9 upstream. Sometimes, when a file was read while it was being truncated by another NFS client, the kernel could deadlock because folio_unlock() was called twice, and the second call would XOR back the `PG_locked` flag. Most of the time (depending on the timing of the truncation), nobody notices the problem because folio_unlock() gets called three times, which flips `PG_locked` back off: 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio, nfs_return_empty_folio 2. vfs_read, nfs_read_folio, ... netfs_read_collection, netfs_unlock_abandoned_read_pages 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio, nfs_return_empty_folio The problem is that nfs_read_add_folio() is not supposed to unlock the folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is missing in nfs_return_empty_folio(). Rarely this leads to a warning in netfs_read_collection(): ------------[ cut here ]------------ R=0000031c: folio 10 is not locked WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00 [...] Workqueue: events_unbound netfs_read_collection_worker RIP: 0010:netfs_read_collection+0x7c0/0xf00 [...] Call Trace: netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0 worker_thread+0x295/0x3a0 Most of the time, however, processes just get stuck forever in folio_wait_bit_common(), waiting for `PG_locked` to disappear, which never happens because nobody is really holding the folio lock. Fixes: 000dbe0bec05 ("NFS: Convert buffered read paths to use netfs when fscache is enabled") Cc: stable@vger.kernel.org Signed-off-by: Max Kellermann Reviewed-by: Dave Wysochanski Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 81e8a81dc003457f3c172ec264695085ff10c488 Author: Scott Mayhew Date: Wed Apr 30 07:12:29 2025 -0400 NFSv4: Don't check for OPEN feature support in v4.1 commit 4d4832ed13ff505fe0371544b4773e79be2bb964 upstream. fattr4_open_arguments is a v4.2 recommended attribute, so we shouldn't be sending it to v4.1 servers. Fixes: cb78f9b7d0c0 ("nfs: fix the fetch of FATTR4_OPEN_ARGUMENTS") Signed-off-by: Scott Mayhew Reviewed-by: Jeff Layton Reviewed-by: Benjamin Coddington Cc: stable@vger.kernel.org # 6.11+ Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 547f26da51445734070e5a9c3522b92d579584b7 Author: Mike Snitzer Date: Tue May 13 12:08:31 2025 -0400 NFS: always probe for LOCALIO support asynchronously commit 1ff4716f420b5a6e6ef095b23bb5db76f46be7fc upstream. It was reported that NFS client mounts of AWS Elastic File System (EFS) volumes is slow, this is because the AWS firewall disallows LOCALIO (because it doesn't consider the use of NFS_LOCALIO_PROGRAM valid), see: https://bugzilla.redhat.com/show_bug.cgi?id=2335129 Switch to performing the LOCALIO probe asynchronously to address the potential for the NFS LOCALIO protocol being disallowed and/or slowed by the remote server's response. While at it, fix nfs_local_probe_async() to always take/put a reference on the nfs_client that is using the LOCALIO protocol. Also, unexport the nfs_local_probe() symbol and make it private to fs/nfs/localio.c This change has the side-effect of initially issuing reads, writes and commits over the wire via SUNRPC until the LOCALIO probe completes. Suggested-by: Jeff Layton # to always probe async Fixes: 76d4cb6345da ("nfs: probe for LOCALIO when v4 client reconnects to server") Cc: stable@vger.kernel.org # 6.14+ Signed-off-by: Mike Snitzer Reviewed-by: Jeff Layton Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit fda21fcba8869c826756cb6838605dc47c426de7 Author: Chuck Lever Date: Wed May 21 16:34:13 2025 -0400 SUNRPC: Prevent hang on NFS mount with xprtsec=[m]tls commit 0bd2f6b8996d4f1ca4573652454987826730a04a upstream. Engineers at Hammerspace noticed that sometimes mounting with "xprtsec=tls" hangs for a minute or so, and then times out, even when the NFS server is reachable and responsive. kTLS shuts off data_ready callbacks if strp->msg_ready is set to mitigate data_ready callbacks when a full TLS record is not yet ready to be read from the socket. Normally msg_ready is clear when the first TLS record arrives on a socket. However, I observed that sometimes tls_setsockopt() sets strp->msg_ready, and that prevents forward progress because tls_data_ready() becomes a no-op. Moreover, Jakub says: "If there's a full record queued at the time when [tlshd] passes the socket back to the kernel, it's up to the reader to read the already queued data out." So SunRPC cannot expect a data_ready call when ingress data is already waiting. Add an explicit poll after SunRPC's upper transport is set up to pick up any data that arrived after the TLS handshake but before transport set-up is complete. Reported-by: Steve Sears Suggested-by: Jakub Kacinski Fixes: 75eb6af7acdf ("SUNRPC: Add a TCP-with-TLS RPC transport class") Tested-by: Mike Snitzer Reviewed-by: Mike Snitzer Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 83ac1ba8ca102ab5c0ed4351f8ac6e74ac4d5d64 Author: Li Lingfeng Date: Mon Apr 14 22:38:52 2025 +0800 nfsd: Initialize ssc before laundromat_work to prevent NULL dereference commit b31da62889e6d610114d81dc7a6edbcaa503fcf8 upstream. In nfs4_state_start_net(), laundromat_work may access nfsd_ssc through nfs4_laundromat -> nfsd4_ssc_expire_umount. If nfsd_ssc isn't initialized, this can cause NULL pointer dereference. Normally the delayed start of laundromat_work allows sufficient time for nfsd_ssc initialization to complete. However, when the kernel waits too long for userspace responses (e.g. in nfs4_state_start_net -> nfsd4_end_grace -> nfsd4_record_grace_done -> nfsd4_cld_grace_done -> cld_pipe_upcall -> __cld_pipe_upcall -> wait_for_completion path), the delayed work may start before nfsd_ssc initialization finishes. Fix this by moving nfsd_ssc initialization before starting laundromat_work. Fixes: f4e44b393389 ("NFSD: delay unmount source's export after inter-server copy completed.") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Signed-off-by: Li Lingfeng Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 2c54bd5a380ebf646fb9efbc4ae782ff3a83a5af Author: NeilBrown Date: Fri Mar 28 11:05:59 2025 +1100 nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request commit 1244f0b2c3cecd3f349a877006e67c9492b41807 upstream. If the request being processed is not a v4 compound request, then examining the cstate can have undefined results. This patch adds a check that the rpc procedure being executed (rq_procinfo) is the NFSPROC4_COMPOUND procedure. Reported-by: Olga Kornievskaia Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Signed-off-by: NeilBrown Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 02b5e10b5b02d497cee08a67becc23229fd6eedf Author: Olga Kornievskaia Date: Fri Mar 21 20:13:04 2025 -0400 nfsd: fix access checking for NLM under XPRTSEC policies commit 0813c5f01249dbc32ccbc68d27a24fde5bf2901c upstream. When an export policy with xprtsec policy is set with "tls" and/or "mtls", but an NFS client is doing a v3 xprtsec=tls mount, then NLM locking calls fail with an error because there is currently no support for NLM with TLS. Until such support is added, allow NLM calls under TLS-secured policy. Fixes: 4cc9b9f2bf4d ("nfsd: refine and rename NFSD_MAY_LOCK") Cc: stable@vger.kernel.org Signed-off-by: Olga Kornievskaia Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 5ca40f4a211e7f31608a65ccd8532f8073940eac Author: Chuck Lever Date: Wed May 7 10:45:15 2025 -0400 NFSD: Implement FATTR4_CLONE_BLKSIZE attribute commit d6ca7d2643eebe09cf46840bdc7d68b6e07aba77 upstream. RFC 7862 states that if an NFS server implements a CLONE operation, it MUST also implement FATTR4_CLONE_BLKSIZE. NFSD implements CLONE, but does not implement FATTR4_CLONE_BLKSIZE. Note that in Section 12.2, RFC 7862 claims that FATTR4_CLONE_BLKSIZE is RECOMMENDED, not REQUIRED. Likely this is because a minor version is not permitted to add a REQUIRED attribute. Confusing. We assume this attribute reports a block size as a count of bytes, as RFC 7862 does not specify a unit. Reported-by: Roland Mainz Suggested-by: Christoph Hellwig Reviewed-by: Roland Mainz Cc: stable@vger.kernel.org # v6.7+ Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 327011a2bb4f7de9c72b891a96ce8d902828bddf Author: Maninder Singh Date: Thu Mar 6 14:50:07 2025 +0530 NFSD: fix race between nfsd registration and exports_proc commit f7fb730cac9aafda8b9813b55d04e28a9664d17c upstream. As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd. Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd for 5.4 kernel ARM64: CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0 CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 PC is at : exports_net_open+0x50/0x68 [nfsd] Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248 Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu(). and same is happening on latest 6.14 kernel as well: [ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]--- It reproduced simply with below script: while [ 1 ] do /exportfs -r done & while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done & So exporting interfaces to user space shall be done at last and cleanup at first place. With change there is no Kernel OOPs. Co-developed-by: Shubham Rana Signed-off-by: Shubham Rana Signed-off-by: Maninder Singh Reviewed-by: Jeff Layton Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 773dd355e03604389adf0041cc65e020d2488043 Author: Maninder Singh Date: Thu Mar 6 14:50:06 2025 +0530 NFSD: unregister filesystem in case genl_register_family() fails commit ff12eb379554eea7932ad6caea55e3091701cce4 upstream. With rpc_status netlink support, unregister of register_filesystem() was missed in case of genl_register_family() fails. Correcting it by making new label. Fixes: bd9d6a3efa97 ("NFSD: add rpc_status netlink support") Cc: stable@vger.kernel.org Signed-off-by: Maninder Singh Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 51fb8c7937d1873fc308275ae74592fb0b503fc5 Author: Johan Hovold Date: Fri Mar 21 10:49:16 2025 +0100 wifi: ath11k: fix ring-buffer corruption commit 6d037a372f817e9fcb56482f37917545596bd776 upstream. Users of the Lenovo ThinkPad X13s have reported that Wi-Fi sometimes breaks and the log fills up with errors like: ath11k_pci 0006:01:00.0: HTC Rx: insufficient length, got 1484, expected 1492 ath11k_pci 0006:01:00.0: HTC Rx: insufficient length, got 1460, expected 1484 which based on a quick look at the driver seemed to indicate some kind of ring-buffer corruption. Miaoqing Pan tracked it down to the host seeing the updated destination ring head pointer before the updated descriptor, and the error handling for that in turn leaves the ring buffer in an inconsistent state. Add the missing memory barrier to make sure that the descriptor is read after the head pointer to address the root cause of the corruption while fixing up the error handling in case there are ever any (ordering) bugs on the device side. Note that the READ_ONCE() are only needed to avoid compiler mischief in case the ring-buffer helpers are ever inlined. 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") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218623 Link: https://lore.kernel.org/20250310010217.3845141-3-quic_miaoqing@quicinc.com Cc: Miaoqing Pan Cc: stable@vger.kernel.org # 5.6 Signed-off-by: Johan Hovold Reviewed-by: Miaoqing Pan Tested-by: Steev Klimaszewski Tested-by: Jens Glathe Tested-by: Clayton Craft Link: https://patch.msgid.link/20250321094916.19098-1-johan+linaro@kernel.org Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit 814abab3b4f7723280b151d61e0b23ace2a2167f Author: Bitterblue Smith Date: Sat May 10 15:22:24 2025 +0300 wifi: rtw88: usb: Upload the firmware in bigger chunks commit 80fe0bc1659c0ccc79d082e426fa376be5df9c04 upstream. RTL8811AU stops responding during the firmware download on some systems: [ 809.256440] rtw_8821au 5-2.1:1.0: Firmware version 42.4.0, H2C version 0 [ 812.759142] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: renamed from wlan0 [ 837.315388] rtw_8821au 1-4:1.0: write register 0x1ef4 failed with -110 [ 867.524259] rtw_8821au 1-4:1.0: write register 0x1ef8 failed with -110 [ 868.930976] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: entered promiscuous mode [ 897.730952] rtw_8821au 1-4:1.0: write register 0x1efc failed with -110 Maybe it takes too long when writing the firmware 4 bytes at a time. Write 196 bytes at a time for RTL8821AU, RTL8811AU, and RTL8812AU, and 254 bytes at a time for RTL8723DU. These are the sizes used in their official drivers. Tested with all these chips. Cc: stable@vger.kernel.org Link: https://github.com/lwfinger/rtw88/issues/344 Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/43f1daad-3ec0-4a3b-a50c-9cd9eb2c2f52@gmail.com Signed-off-by: Greg Kroah-Hartman commit 8cd1067d3819d73c837d7583881e44f2aad1d337 Author: Johan Hovold Date: Fri Mar 21 15:53:02 2025 +0100 wifi: ath11k: fix rx completion meta data corruption commit ab52e3e44fe9b666281752e2481d11e25b0e3fdd upstream. Add the missing memory barrier to make sure that the REO dest ring descriptor is read after the head pointer to avoid using stale data on weakly ordered architectures like aarch64. This may fix the ring-buffer corruption worked around by commit f9fff67d2d7c ("wifi: ath11k: Fix SKB corruption in REO destination ring") by silently discarding data, and may possibly also address user reported errors like: ath11k_pci 0006:01:00.0: msdu_done bit in attention is not set 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: stable@vger.kernel.org # 5.6 Link: https://bugzilla.kernel.org/show_bug.cgi?id=218005 Signed-off-by: Johan Hovold Tested-by: Clayton Craft Link: https://patch.msgid.link/20250321145302.4775-1-johan+linaro@kernel.org Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit 8046ccc6ac2361c0e3908cfda8b1bfa22f6c8ca6 Author: Christian Brauner Date: Mon Apr 21 10:27:40 2025 +0200 fs: add S_ANON_INODE commit 19bbfe7b5fcc04d8711e8e1352acc77c1a5c3955 upstream. This makes it easy to detect proper anonymous inodes and to ensure that we can detect them in codepaths such as readahead(). Readahead on anonymous inodes didn't work because they didn't have a proper mode. Now that they have we need to retain EINVAL being returned otherwise LTP will fail. We also need to ensure that ioctls aren't simply fired like they are for regular files so things like inotify inodes continue to correctly call their own ioctl handlers as in [1]. Reported-by: Xilin Wu Link: https://lore.kernel.org/3A9139D5CD543962+89831381-31b9-4392-87ec-a84a5b3507d8@radxa.com [1] Link: https://lore.kernel.org/7a1a7076-ff6b-4cb0-94e7-7218a0a44028@sirena.org.uk Signed-off-by: Christian Brauner Cc: "Barry K. Nathan" Signed-off-by: Greg Kroah-Hartman commit ce7419b6cf23d81dc9d68f69137d3fdf6f3f0360 Author: Christian Brauner Date: Mon Apr 7 11:54:19 2025 +0200 anon_inode: raise SB_I_NODEV and SB_I_NOEXEC commit 1ed95281c0c77dbb1540f9855cd3c5f19900f7a5 upstream. It isn't possible to execute anonymous inodes because they cannot be opened in any way after they have been created. This includes execution: execveat(fd_anon_inode, "", NULL, NULL, AT_EMPTY_PATH) Anonymous inodes have inode->f_op set to no_open_fops which sets no_open() which returns ENXIO. That means any call to do_dentry_open() which is the endpoint of the do_open_execat() will fail. There's no chance to execute an anonymous inode. Unless a given subsystem overrides it ofc. However, we should still harden this and raise SB_I_NODEV and SB_I_NOEXEC on the superblock itself so that no one gets any creative ideas. Link: https://lore.kernel.org/20250407-work-anon_inode-v1-5-53a44c20d44e@kernel.org Reviewed-by: Jeff Layton Cc: stable@vger.kernel.org # all LTS kernels Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 641635059fa988d8f6339e5d0d13f884ef83cbaf Author: Christian Brauner Date: Mon Apr 7 11:54:17 2025 +0200 anon_inode: explicitly block ->setattr() commit 22bdf3d6581af6d06ed8a46c6835648421cca0ea upstream. It is currently possible to change the mode and owner of the single anonymous inode in the kernel: int main(int argc, char *argv[]) { int ret, sfd; sigset_t mask; struct signalfd_siginfo fdsi; sigemptyset(&mask); sigaddset(&mask, SIGINT); sigaddset(&mask, SIGQUIT); ret = sigprocmask(SIG_BLOCK, &mask, NULL); if (ret < 0) _exit(1); sfd = signalfd(-1, &mask, 0); if (sfd < 0) _exit(2); ret = fchown(sfd, 5555, 5555); if (ret < 0) _exit(3); ret = fchmod(sfd, 0777); if (ret < 0) _exit(3); _exit(4); } This is a bug. It's not really a meaningful one because anonymous inodes don't really figure into path lookup and they cannot be reopened via /proc//fd/ and can't be used for lookup itself. So they can only ever serve as direct references. But it is still completely bogus to allow the mode and ownership or any of the properties of the anonymous inode to be changed. Block this! Link: https://lore.kernel.org/20250407-work-anon_inode-v1-3-53a44c20d44e@kernel.org Reviewed-by: Jeff Layton Cc: stable@vger.kernel.org # all LTS kernels Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 864c2bb3262ab888f84f46ff77cb3b799359c416 Author: Christian Brauner Date: Mon Apr 7 11:54:15 2025 +0200 anon_inode: use a proper mode internally commit cfd86ef7e8e7b9e015707e46479a6b1de141eed0 upstream. This allows the VFS to not trip over anonymous inodes and we can add asserts based on the mode into the vfs. When we report it to userspace we can simply hide the mode to avoid regressions. I've audited all direct callers of alloc_anon_inode() and only secretmen overrides i_mode and i_op inode operations but it already uses a regular file. Link: https://lore.kernel.org/20250407-work-anon_inode-v1-1-53a44c20d44e@kernel.org Fixes: af153bb63a336 ("vfs: catch invalid modes in may_open()") Reviewed-by: Jeff Layton Cc: stable@vger.kernel.org # all LTS kernels Reported-by: syzbot+5d8e79d323a13aa0b248@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67ed3fb3.050a0220.14623d.0009.GAE@google.com Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 94fca902818e60240a7c74d7b297448bd5d6d609 Author: Michael Lo Date: Fri May 9 16:35:12 2025 +0800 wifi: mt76: mt7925: fix host interrupt register initialization commit ca872e0ad97159375da8f3d05cac1f48239e01d7 upstream. ensure proper interrupt handling and aligns with the hardware spec by updating the register offset for MT_WFDMA0_HOST_INT_ENA. Cc: stable@vger.kernel.org Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Michael Lo Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250509083512.455095-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 714afb4c38edd19a057d519c1f9c5d164b43de94 Author: Christian Lamparter Date: Fri May 16 20:41:06 2025 +0200 wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback() commit da1b9a55ff116cb040528ef664c70a4eec03ae99 upstream. Robert Morris reported: |If a malicious USB device pretends to be an Intersil p54 wifi |interface and generates an eeprom_readback message with a large |eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the |message beyond the end of priv->eeprom. | |static void p54_rx_eeprom_readback(struct p54_common *priv, | struct sk_buff *skb) |{ | struct p54_hdr *hdr = (struct p54_hdr *) skb->data; | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data; | | if (priv->fw_var >= 0x509) { | memcpy(priv->eeprom, eeprom->v2.data, | le16_to_cpu(eeprom->v2.len)); | } else { | memcpy(priv->eeprom, eeprom->v1.data, | le16_to_cpu(eeprom->v1.len)); | } | [...] The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom(). The device is supposed to provide the same length back to the driver. But yes, it's possible (like shown in the report) to alter the value to something that causes a crash/panic due to overrun. This patch addresses the issue by adding the size to the common device context, so p54_rx_eeprom_readback no longer relies on possibly tampered values... That said, it also checks if the "firmware" altered the value and no longer copies them. The one, small saving grace is: Before the driver tries to read the eeprom, it needs to upload >a< firmware. the vendor firmware has a proprietary license and as a reason, it is not present on most distributions by default. Cc: Reported-by: Robert Morris Closes: https://lore.kernel.org/linux-wireless/28782.1747258414@localhost/ Fixes: 7cb770729ba8 ("p54: move eeprom code into common library") Signed-off-by: Christian Lamparter Link: https://patch.msgid.link/20250516184107.47794-1-chunkeey@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit f593ee04b221bd0fdbe1ef8497e4c16ff60bba8f Author: Wentao Liang Date: Sun May 25 00:34:25 2025 +0800 net/mlx5: Add error handling in mlx5_query_nic_vport_node_guid() commit c6bb8a21cdad8c975a3a646b9e5c8df01ad29783 upstream. The function mlx5_query_nic_vport_node_guid() calls the function mlx5_query_nic_vport_context() but does not check its return value. A proper implementation can be found in mlx5_nic_vport_query_local_lb(). Add error handling for mlx5_query_nic_vport_context(). If it fails, free the out buffer via kvfree() and return error code. Fixes: 9efa75254593 ("net/mlx5_core: Introduce access functions to query vport RoCE fields") Cc: stable@vger.kernel.org # v4.5 Signed-off-by: Wentao Liang Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20250524163425.1695-1-vulab@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 56db32abca3f1fbb5e68f8f6ad65db0c1efe1c01 Author: Wentao Liang Date: Wed May 21 21:36:20 2025 +0800 net/mlx5_core: Add error handling inmlx5_query_nic_vport_qkey_viol_cntr() commit f0b50730bdd8f2734e548de541e845c0d40dceb6 upstream. The function mlx5_query_nic_vport_qkey_viol_cntr() calls the function mlx5_query_nic_vport_context() but does not check its return value. This could lead to undefined behavior if the query fails. A proper implementation can be found in mlx5_nic_vport_query_local_lb(). Add error handling for mlx5_query_nic_vport_context(). If it fails, free the out buffer via kvfree() and return error code. Fixes: 9efa75254593 ("net/mlx5_core: Introduce access functions to query vport RoCE fields") Cc: stable@vger.kernel.org # v4.5 Signed-off-by: Wentao Liang Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20250521133620.912-1-vulab@iscas.ac.cn Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 10f5b0f7288e43c2af9d85fee1b37e85a50d8aa2 Author: João Paulo Gonçalves Date: Sun Apr 20 15:28:02 2025 -0300 regulator: max20086: Change enable gpio to optional commit e8ac7336dd62f0443a675ed80b17f0f0e6846e20 upstream. The enable pin can be configured as always enabled by the hardware. Make the enable gpio request optional so the driver doesn't fail to probe when `enable-gpios` property is not present in the device tree. Cc: stable@vger.kernel.org Fixes: bfff546aae50 ("regulator: Add MAX20086-MAX20089 driver") Signed-off-by: João Paulo Gonçalves Link: https://patch.msgid.link/20250420-fix-max20086-v1-2-8cc9ee0d5a08@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c7b008c87aa59958403ded6a627b5f1054d42666 Author: João Paulo Gonçalves Date: Sun Apr 20 15:28:01 2025 -0300 regulator: max20086: Fix MAX200086 chip id commit 71406b6d1155d883c80c1b4405939a52f723aa05 upstream. >From MAX20086-MAX20089 datasheet, the id for a MAX20086 is 0x30 and not 0x40. With the current code, the driver will fail on probe when the driver tries to identify the chip id from a MAX20086 device over I2C. Cc: stable@vger.kernel.org Fixes: bfff546aae50 ("regulator: Add MAX20086-MAX20089 driver") Signed-off-by: João Paulo Gonçalves Link: https://patch.msgid.link/20250420-fix-max20086-v1-1-8cc9ee0d5a08@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 9c3e9d11424b5c4d2e349478f23465c153c6f98c Author: Niklas Schnelle Date: Thu May 22 14:13:15 2025 +0200 s390/pci: Serialize device addition and removal commit 774a1fa880bc949d88b5ddec9494a13be733dfa8 upstream. Prior changes ensured that when zpci_release_device() is called and it removed the zdev from the zpci_list this instance can not be found via the zpci_list anymore even while allowing re-add of reserved devices. This only accounts for the overall lifetime and zpci_list addition and removal, it does not yet prevent concurrent add of a new instance for the same underlying device. Such concurrent add would subsequently cause issues such as attempted re-use of the same IOMMU sysfs directory and is generally undesired. Introduce a new zpci_add_remove_lock mutex to serialize adding a new device with removal. Together this ensures that if a struct zpci_dev is not found in the zpci_list it was either already removed and torn down, or its removal and tear down is in progress with the zpci_add_remove_lock held. Cc: stable@vger.kernel.org Fixes: a46044a92add ("s390/pci: fix zpci_zdev_put() on reserve") Reviewed-by: Gerd Bayer Tested-by: Gerd Bayer Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit ea8faa3d225585a196d9603b05c361c98eb9aa5a Author: Niklas Schnelle Date: Thu May 22 14:13:14 2025 +0200 s390/pci: Allow re-add of a reserved but not yet removed device commit 4b1815a52d7eb03b3e0e6742c6728bc16a4b2d1d upstream. The architecture assumes that PCI functions can be removed synchronously as PCI events are processed. This however clashes with the reference counting of struct pci_dev which allows device drivers to hold on to a struct pci_dev reference even as the underlying device is removed. To bridge this gap commit 2a671f77ee49 ("s390/pci: fix use after free of zpci_dev") keeps the struct zpci_dev in ZPCI_FN_STATE_RESERVED state until common code releases the struct pci_dev. Only when all references are dropped, the struct zpci_dev can be removed and freed. Later commit a46044a92add ("s390/pci: fix zpci_zdev_put() on reserve") moved the deletion of the struct zpci_dev from the zpci_list in zpci_release_device() to the point where the device is reserved. This was done to prevent handling events for a device that is already being removed, e.g. when the platform generates both PCI event codes 0x304 and 0x308. In retrospect, deletion from the zpci_list in the release function without holding the zpci_list_lock was also racy. A side effect of this handling is that if the underlying device re-appears while the struct zpci_dev is in the ZPCI_FN_STATE_RESERVED state, the new and old instances of the struct zpci_dev and/or struct pci_dev may clash. For example when trying to create the IOMMU sysfs files for the new instance. In this case, re-adding the new instance is aborted. The old instance is removed, and the device will remain absent until the platform issues another event. Fix this by allowing the struct zpci_dev to be brought back up right until it is finally removed. To this end also keep the struct zpci_dev in the zpci_list until it is finally released when all references have been dropped. Deletion from the zpci_list from within the release function is made safe by using kref_put_lock() with the zpci_list_lock. This ensures that the releasing code holds the last reference. Cc: stable@vger.kernel.org Fixes: a46044a92add ("s390/pci: fix zpci_zdev_put() on reserve") Reviewed-by: Gerd Bayer Tested-by: Gerd Bayer Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 926cba4ff01e70a905181700fd43fb928341fcb4 Author: Niklas Schnelle Date: Thu May 22 14:13:13 2025 +0200 s390/pci: Prevent self deletion in disable_slot() commit 47c397844869ad0e6738afb5879c7492f4691122 upstream. As disable_slot() takes a struct zpci_dev from the Configured to the Standby state. In Standby there is still a hotplug slot so this is not usually a case of sysfs self deletion. This is important because self deletion gets very hairy in terms of locking (see for example recover_store() in arch/s390/pci/pci_sysfs.c). Because the pci_dev_put() is not within the critical section of the zdev->state_lock however, disable_slot() can turn into a case of self deletion if zPCI device event handling slips between the mutex_unlock() and the pci_dev_put(). If the latter is the last put and zpci_release_device() is called this then tries to remove the hotplug slot via zpci_exit_slot() which will try to remove the hotplug slot directory the disable_slot() is part of i.e. self deletion. Prevent this by widening the zdev->state_lock critical section to include the pci_dev_put() which is then guaranteed to happen with the struct zpci_dev still in Standby state ensuring it will not lead to a zpci_release_device() call as at least the zPCI event handling code still holds a reference. Cc: stable@vger.kernel.org Fixes: a46044a92add ("s390/pci: fix zpci_zdev_put() on reserve") Reviewed-by: Gerd Bayer Tested-by: Gerd Bayer Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit f5f9e339f4d8d42a5a0e8f9a764653713d6c80b0 Author: Niklas Schnelle Date: Thu May 22 14:13:12 2025 +0200 s390/pci: Remove redundant bus removal and disable from zpci_release_device() commit d76f9633296785343d45f85199f4138cb724b6d2 upstream. Remove zpci_bus_remove_device() and zpci_disable_device() calls from zpci_release_device(). These calls were done when the device transitioned into the ZPCI_FN_STATE_STANDBY state which is guaranteed to happen before it enters the ZPCI_FN_STATE_RESERVED state. When zpci_release_device() is called the device is known to be in the ZPCI_FN_STATE_RESERVED state which is also checked by a WARN_ON(). Cc: stable@vger.kernel.org Fixes: a46044a92add ("s390/pci: fix zpci_zdev_put() on reserve") Reviewed-by: Gerd Bayer Reviewed-by: Julian Ruess Tested-by: Gerd Bayer Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 797655b76d16ca490026ad243e190e6bffca4e7d Author: Heiko Carstens Date: Mon May 19 18:07:11 2025 +0200 s390/pci: Fix __pcilg_mio_inuser() inline assembly commit c4abe6234246c75cdc43326415d9cff88b7cf06c upstream. Use "a" constraint for the shift operand of the __pcilg_mio_inuser() inline assembly. The used "d" constraint allows the compiler to use any general purpose register for the shift operand, including register zero. If register zero is used this my result in incorrect code generation: 8f6: a7 0a ff f8 ahi %r0,-8 8fa: eb 32 00 00 00 0c srlg %r3,%r2,0 <---- If register zero is selected to contain the shift value, the srlg instruction ignores the contents of the register and always shifts zero bits. Therefore use the "a" constraint which does not permit to select register zero. Fixes: f058599e22d5 ("s390/pci: Fix s390_mmio_read/write with MIO") Cc: stable@vger.kernel.org Reported-by: Niklas Schnelle Reviewed-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 7833deb95e05bec146414b3a2feb24f025ca27c0 Author: Hari Bathini Date: Tue Apr 22 13:56:09 2025 +0530 powerpc/bpf: fix JIT code size calculation of bpf trampoline commit 59ba025948be2a92e8bc9ae1cbdaf197660bd508 upstream. arch_bpf_trampoline_size() provides JIT size of the BPF trampoline before the buffer for JIT'ing it is allocated. The total number of instructions emitted for BPF trampoline JIT code depends on where the final image is located. So, the size arrived at with the dummy pass in arch_bpf_trampoline_size() can vary from the actual size needed in arch_prepare_bpf_trampoline(). When the instructions accounted in arch_bpf_trampoline_size() is less than the number of instructions emitted during the actual JIT compile of the trampoline, the below warning is produced: WARNING: CPU: 8 PID: 204190 at arch/powerpc/net/bpf_jit_comp.c:981 __arch_prepare_bpf_trampoline.isra.0+0xd2c/0xdcc which is: /* Make sure the trampoline generation logic doesn't overflow */ if (image && WARN_ON_ONCE(&image[ctx->idx] > (u32 *)rw_image_end - BPF_INSN_SAFETY)) { So, during the dummy pass, instead of providing some arbitrary image location, account for maximum possible instructions if and when there is a dependency with image location for JIT'ing. Fixes: d243b62b7bd3 ("powerpc64/bpf: Add support for bpf trampolines") Reported-by: Venkat Rao Bagalkote Closes: https://lore.kernel.org/all/6168bfc8-659f-4b5a-a6fb-90a916dde3b3@linux.ibm.com/ Cc: stable@vger.kernel.org # v6.13+ Acked-by: Naveen N Rao (AMD) Tested-by: Venkat Rao Bagalkote Signed-off-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250422082609.949301-1-hbathini@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit a9212bf5ca640232254b31330e86272fe4073bc9 Author: Hari Bathini Date: Thu Apr 17 00:42:27 2025 +0530 powerpc64/ftrace: fix clobbered r15 during livepatching commit cb5b691f8273432297611863ac142e17119279e0 upstream. While r15 is clobbered always with PPC_FTRACE_OUT_OF_LINE, it is not restored in livepatch sequence leading to not so obvious fails like below: BUG: Unable to handle kernel data access on write at 0xc0000000000f9078 Faulting instruction address: 0xc0000000018ff958 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP: c0000000018ff958 LR: c0000000018ff930 CTR: c0000000009c0790 REGS: c00000005f2e7790 TRAP: 0300 Tainted: G K (6.14.0+) MSR: 8000000000009033 CR: 2822880b XER: 20040000 CFAR: c0000000008addc0 DAR: c0000000000f9078 DSISR: 0a000000 IRQMASK: 1 GPR00: c0000000018f2584 c00000005f2e7a30 c00000000280a900 c000000017ffa488 GPR04: 0000000000000008 0000000000000000 c0000000018f24fc 000000000000000d GPR08: fffffffffffe0000 000000000000000d 0000000000000000 0000000000008000 GPR12: c0000000009c0790 c000000017ffa480 c00000005f2e7c78 c0000000000f9070 GPR16: c00000005f2e7c90 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 c00000005f3efa80 c00000005f2e7c60 c00000005f2e7c88 GPR24: c00000005f2e7c60 0000000000000001 c0000000000f9078 0000000000000000 GPR28: 00007fff97960000 c000000017ffa480 0000000000000000 c0000000000f9078 ... Call Trace: check_heap_object+0x34/0x390 (unreliable) __mutex_unlock_slowpath.isra.0+0xe4/0x230 seq_read_iter+0x430/0xa90 proc_reg_read_iter+0xa4/0x200 vfs_read+0x41c/0x510 ksys_read+0xa4/0x190 system_call_exception+0x1d0/0x440 system_call_vectored_common+0x15c/0x2ec Fix it by restoring r15 always. Fixes: eec37961a56a ("powerpc64/ftrace: Move ftrace sequence out of line") Reported-by: Viktor Malik Closes: https://lore.kernel.org/lkml/1aec4a9a-a30b-43fd-b303-7a351caeccb7@redhat.com Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Hari Bathini Tested-by: Viktor Malik Acked-by: Naveen N Rao (AMD) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250416191227.201146-1-hbathini@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 17983a2b559c379b9368e927901ee32bd34d6ba2 Author: Gautam Menghani Date: Wed Mar 5 14:32:36 2025 +0530 powerpc/pseries/msi: Avoid reading PCI device registers in reduced power states commit 9cc0eafd28c7faef300822992bb08d79cab2a36c upstream. When a system is being suspended to RAM, the PCI devices are also suspended and the PPC code ends up calling pseries_msi_compose_msg() and this triggers the BUG_ON() in __pci_read_msi_msg() because the device at this point is in reduced power state. In reduced power state, the memory mapped registers of the PCI device are not accessible. To replicate the bug: 1. Make sure deep sleep is selected # cat /sys/power/mem_sleep s2idle [deep] 2. Make sure console is not suspended (so that dmesg logs are visible) echo N > /sys/module/printk/parameters/console_suspend 3. Suspend the system echo mem > /sys/power/state To fix this behaviour, read the cached msi message of the device when the device is not in PCI_D0 power state instead of touching the hardware. Fixes: a5f3d2c17b07 ("powerpc/pseries/pci: Add MSI domains") Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Gautam Menghani Tested-by: Venkat Rao Bagalkote Reviewed-by: Vaibhav Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250305090237.294633-1-gautam@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 15af4b96ebcc8e5e3bf02ce54344b81457b95ed2 Author: Pavel Begunkov Date: Tue May 13 18:26:46 2025 +0100 io_uring/kbuf: account ring io_buffer_list memory commit 475a8d30371604a6363da8e304a608a5959afc40 upstream. Follow the non-ringed pbuf struct io_buffer_list allocations and account it against the memcg. There is low chance of that being an actual problem as ring provided buffer should either pin user memory or allocate it, which is already accounted. Cc: stable@vger.kernel.org # 6.1 Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/3985218b50d341273cafff7234e1a7e6d0db9808.1747150490.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a5fcf5275ad33ec0682ffad3a3a5fd2aeec48dba Author: Pavel Begunkov Date: Fri May 9 12:12:47 2025 +0100 io_uring: account drain memory to cgroup commit f979c20547e72568e3c793bc92c7522bc3166246 upstream. Account drain allocations against memcg. It's not a big problem as each such allocation is paired with a request, which is accounted, but it's nicer to follow the limits more closely. Cc: stable@vger.kernel.org # 6.1 Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/f8dfdbd755c41fd9c75d12b858af07dfba5bbb68.1746788718.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ee18257d3946c003107a720c72c455854b2fe5f7 Author: Vijendar Mukunda Date: Tue May 6 17:37:23 2025 +0530 ASoC: amd: sof_amd_sdw: Fix unlikely uninitialized variable use in create_sdw_dailinks() commit 6b83ba4bc3ecb915476d688c9f00f3be57b49a0c upstream. Initialize current_be_id to 0 in SOF based AMD generic SoundWire machine driver to handle the unlikely case when there are no devices connected to a DAI. In this case create_sdw_dailink() would return without touching the passed pointer to current_be_id. Found by gcc -fanalyzer Cc: stable@vger.kernel.org Fixes: 6d8348ddc56ed ("ASoC: amd: acp: refactor SoundWire machine driver code") Signed-off-by: Vijendar Mukunda Link: https://patch.msgid.link/20250506120823.3621604-2-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1ab37aa110e181edd56ca298cd67957366d6c801 Author: Vijendar Mukunda Date: Tue May 6 17:37:22 2025 +0530 ASoC: amd: amd_sdw: Fix unlikely uninitialized variable use in create_sdw_dailinks() commit 4d87ae7508cb7ff58fd0bcecc6e9491f42f987f8 upstream. Initialize current_be_id to 0 in AMD legacy stack(NO DSP enabled) SoundWire generic machine driver code to handle the unlikely case when there are no devices connected to a DAI. In this case create_sdw_dailink() would return without touching the passed pointer to current_be_id. Found by gcc -fanalyzer Cc: stable@vger.kernel.org Fixes: 2981d9b0789c4 ("ASoC: amd: acp: add soundwire machine driver for legacy stack") Signed-off-by: Vijendar Mukunda Link: https://patch.msgid.link/20250506120823.3621604-1-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c69a126f45dacb31c83ac8f7116c0dd143e6ee64 Author: Martin Blumenstingl Date: Sat Apr 19 23:34:48 2025 +0200 ASoC: meson: meson-card-utils: use of_property_present() for DT parsing commit 171eb6f71e9e3ba6a7410a1d93f3ac213f39dae2 upstream. Commit c141ecc3cecd ("of: Warn when of_property_read_bool() is used on non-boolean properties") added a warning when trying to parse a property with a value (boolean properties are defined as: absent = false, present without any value = true). This causes a warning from meson-card-utils. meson-card-utils needs to know about the existence of the "audio-routing" and/or "audio-widgets" properties in order to properly parse them. Switch to of_property_present() in order to silence the following warning messages during boot: OF: /sound: Read of boolean property 'audio-routing' with a value. OF: /sound: Read of boolean property 'audio-widgets' with a value. Fixes: 7864a79f37b5 ("ASoC: meson: add axg sound card support") Tested-by: Christian Hewitt Cc: stable@vger.kernel.org Signed-off-by: Martin Blumenstingl Link: https://patch.msgid.link/20250419213448.59647-1-martin.blumenstingl@googlemail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8f4cc454a0bb45b800bc7817c09c8f72e31901f3 Author: Jaroslav Kysela Date: Fri May 23 12:21:02 2025 +0200 firmware: cs_dsp: Fix OOB memory read access in KUnit test commit fe6446215bfad11cf3b446f38b28dc7708973c25 upstream. KASAN reported out of bounds access - cs_dsp_mock_bin_add_name_or_info(), because the source string length was rounded up to the allocation size. Cc: Simon Trimmer Cc: Charles Keepax Cc: Richard Fitzgerald Cc: patches@opensource.cirrus.com Cc: stable@vger.kernel.org Signed-off-by: Jaroslav Kysela Link: https://patch.msgid.link/20250523102102.1177151-1-perex@perex.cz Reviewed-by: Richard Fitzgerald Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b89bf3fccb6131e8e581ad1243156f2ac56c3948 Author: Wentao Liang Date: Mon May 19 15:57:39 2025 +0800 ASoC: qcom: sdm845: Add error handling in sdm845_slim_snd_hw_params() commit 688abe2860fd9c644705b9e11cb9649eb891b879 upstream. The function sdm845_slim_snd_hw_params() calls the functuion snd_soc_dai_set_channel_map() but does not check its return value. A proper implementation can be found in msm_snd_hw_params(). Add error handling for snd_soc_dai_set_channel_map(). If the function fails and it is not a unsupported error, return the error code immediately. Fixes: 5caf64c633a3 ("ASoC: qcom: sdm845: add support to DB845c and Lenovo Yoga") Cc: stable@vger.kernel.org # v5.6 Signed-off-by: Wentao Liang Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20250519075739.1458-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e7ae9012bee8377107aa27be9d0223b960c50e2a Author: Giovanni Cabiddu Date: Wed Mar 26 15:59:49 2025 +0000 crypto: qat - add shutdown handler to qat_dh895xcc commit 2c4e8b228733bfbcaf49408fdf94d220f6eb78fc upstream. During a warm reset via kexec, the system bypasses the driver removal sequence, meaning that the remove() callback is not invoked. If a QAT device is not shutdown properly, the device driver will fail to load in a newly rebooted kernel. This might result in output like the following after the kexec reboot: QAT: AE0 is inactive!! QAT: failed to get device out of reset dh895xcc 0000:3f:00.0: qat_hal_clr_reset error dh895xcc 0000:3f:00.0: Failed to init the AEs dh895xcc 0000:3f:00.0: Failed to initialise Acceleration Engine dh895xcc 0000:3f:00.0: Resetting device qat_dev0 dh895xcc 0000:3f:00.0: probe with driver dh895xcc failed with error -14 Implement the shutdown() handler that hooks into the reboot notifier list. This brings down the QAT device and ensures it is shut down properly. Cc: Fixes: 7afa232e76ce ("crypto: qat - Intel(R) QAT DH895xcc accelerator") Reviewed-by: Ahsan Atta Reviewed-by: Andy Shevchenko Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 366b56c9d3f5bef6181cd66263f45bf0917beca5 Author: Giovanni Cabiddu Date: Wed Mar 26 15:59:51 2025 +0000 crypto: qat - add shutdown handler to qat_c62x commit a9a6e9279b2998e2610c70b0dfc80a234f97c76c upstream. During a warm reset via kexec, the system bypasses the driver removal sequence, meaning that the remove() callback is not invoked. If a QAT device is not shutdown properly, the device driver will fail to load in a newly rebooted kernel. This might result in output like the following after the kexec reboot: QAT: AE0 is inactive!! QAT: failed to get device out of reset c6xx 0000:3f:00.0: qat_hal_clr_reset error c6xx 0000:3f:00.0: Failed to init the AEs c6xx 0000:3f:00.0: Failed to initialise Acceleration Engine c6xx 0000:3f:00.0: Resetting device qat_dev0 c6xx 0000:3f:00.0: probe with driver c6xx failed with error -14 Implement the shutdown() handler that hooks into the reboot notifier list. This brings down the QAT device and ensures it is shut down properly. Cc: Fixes: a6dabee6c8ba ("crypto: qat - add support for c62x accel type") Reviewed-by: Ahsan Atta Reviewed-by: Andy Shevchenko Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 62c679b2e12378b6ceec5a3cd2a97ad775b1ef2d Author: Giovanni Cabiddu Date: Wed Mar 26 15:59:46 2025 +0000 crypto: qat - add shutdown handler to qat_4xxx commit 845bc952024dbf482c7434daeac66f764642d52d upstream. During a warm reset via kexec, the system bypasses the driver removal sequence, meaning that the remove() callback is not invoked. If a QAT device is not shutdown properly, the device driver will fail to load in a newly rebooted kernel. This might result in output like the following after the kexec reboot: 4xxx 0000:01:00.0: Failed to power up the device 4xxx 0000:01:00.0: Failed to initialize device 4xxx 0000:01:00.0: Resetting device qat_dev0 4xxx 0000:01:00.0: probe with driver 4xxx failed with error -14 Implement the shutdown() handler that hooks into the reboot notifier list. This brings down the QAT device and ensures it is shut down properly. Cc: Fixes: 8c8268166e83 ("crypto: qat - add qat_4xxx driver") Link: https://lore.kernel.org/all/Z-DGQrhRj9niR9iZ@gondor.apana.org.au/ Reported-by: Randy Wright Closes: https://issues.redhat.com/browse/RHEL-84366 Reviewed-by: Ahsan Atta Reviewed-by: Andy Shevchenko Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit b507b769811369a860852a97f657d6183fe11629 Author: Giovanni Cabiddu Date: Wed Mar 26 15:59:47 2025 +0000 crypto: qat - add shutdown handler to qat_420xx commit 097143f23a1164bfd1b6f70279d229be44da2e30 upstream. During a warm reset via kexec, the system bypasses the driver removal sequence, meaning that the remove() callback is not invoked. If a QAT device is not shutdown properly, the device driver will fail to load in a newly rebooted kernel. This might result in output like the following after the kexec reboot: 420xx 0000:01:00.0: Failed to power up the device 420xx 0000:01:00.0: Failed to initialize device 420xx 0000:01:00.0: Resetting device qat_dev0 420xx 0000:01:00.0: probe with driver 420xx failed with error -14 Implement the shutdown() handler that hooks into the reboot notifier list. This brings down the QAT device and ensures it is shut down properly. Cc: Fixes: fcf60f4bcf54 ("crypto: qat - add support for 420xx devices") Reviewed-by: Ahsan Atta Reviewed-by: Andy Shevchenko Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 9a0371cd9a0e631b80492a04741fc414d394946c Author: Giovanni Cabiddu Date: Wed Mar 26 15:59:53 2025 +0000 crypto: qat - add shutdown handler to qat_c3xxx commit 71e0cc1eab584d6f95526a5e8c69ec666ca33e1b upstream. During a warm reset via kexec, the system bypasses the driver removal sequence, meaning that the remove() callback is not invoked. If a QAT device is not shutdown properly, the device driver will fail to load in a newly rebooted kernel. This might result in output like the following after the kexec reboot: QAT: AE0 is inactive!! QAT: failed to get device out of reset c3xxx 0000:3f:00.0: qat_hal_clr_reset error c3xxx 0000:3f:00.0: Failed to init the AEs c3xxx 0000:3f:00.0: Failed to initialise Acceleration Engine c3xxx 0000:3f:00.0: Resetting device qat_dev0 c3xxx 0000:3f:00.0: probe with driver c3xxx failed with error -14 Implement the shutdown() handler that hooks into the reboot notifier list. This brings down the QAT device and ensures it is shut down properly. Cc: Fixes: 890c55f4dc0e ("crypto: qat - add support for c3xxx accel type") Reviewed-by: Ahsan Atta Reviewed-by: Andy Shevchenko Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ac1d1d0f16e6411b40ff5c5c00175b81f2b0c7b0 Author: Peter Zijlstra Date: Tue Jan 28 15:39:49 2025 +0100 sched/fair: Adhere to place_entity() constraints commit c70fc32f44431bb30f9025ce753ba8be25acbba3 upstream. Mike reports that commit 6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing scheduling lag") relies on commit 4423af84b297 ("sched/fair: optimize the PLACE_LAG when se->vlag is zero") to not trip a WARN in place_entity(). What happens is that the lag of the very last entity is 0 per definition -- the average of one element matches the value of that element. Therefore place_entity() will match the condition skipping the lag adjustment: if (sched_feat(PLACE_LAG) && cfs_rq->nr_queued && se->vlag) { Without the 'se->vlag' condition -- it will attempt to adjust the zero lag even though we're inserting into an empty tree. Notably, we should have failed the 'cfs_rq->nr_queued' condition, but don't because they didn't get updated. Additionally, move update_load_add() after placement() as is consistent with other place_entity() users -- this change is non-functional, place_entity() does not use cfs_rq->load. Fixes: 6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing scheduling lag") Signed-off-by: Peter Zijlstra (Intel) Reported-by: Mike Galbraith Signed-off-by: "Peter Zijlstra (Intel)" Signed-off-by: Mike Galbraith Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/c216eb4ef0e0e0029c600aefc69d56681cee5581.camel@gmx.de Signed-off-by: Greg Kroah-Hartman commit 07ecabfbca64f4f0b6071cf96e49d162fa9d138d Author: Harshit Agarwal Date: Tue Feb 25 18:05:53 2025 +0000 sched/rt: Fix race in push_rt_task commit 690e47d1403e90b7f2366f03b52ed3304194c793 upstream. Overview ======== When a CPU chooses to call push_rt_task and picks a task to push to another CPU's runqueue then it will call find_lock_lowest_rq method which would take a double lock on both CPUs' runqueues. If one of the locks aren't readily available, it may lead to dropping the current runqueue lock and reacquiring both the locks at once. During this window it is possible that the task is already migrated and is running on some other CPU. These cases are already handled. However, if the task is migrated and has already been executed and another CPU is now trying to wake it up (ttwu) such that it is queued again on the runqeue (on_rq is 1) and also if the task was run by the same CPU, then the current checks will pass even though the task was migrated out and is no longer in the pushable tasks list. Crashes ======= This bug resulted in quite a few flavors of crashes triggering kernel panics with various crash signatures such as assert failures, page faults, null pointer dereferences, and queue corruption errors all coming from scheduler itself. Some of the crashes: -> kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx >= MAX_RT_PRIO) Call Trace: ? __die_body+0x1a/0x60 ? die+0x2a/0x50 ? do_trap+0x85/0x100 ? pick_next_task_rt+0x6e/0x1d0 ? do_error_trap+0x64/0xa0 ? pick_next_task_rt+0x6e/0x1d0 ? exc_invalid_op+0x4c/0x60 ? pick_next_task_rt+0x6e/0x1d0 ? asm_exc_invalid_op+0x12/0x20 ? pick_next_task_rt+0x6e/0x1d0 __schedule+0x5cb/0x790 ? update_ts_time_stats+0x55/0x70 schedule_idle+0x1e/0x40 do_idle+0x15e/0x200 cpu_startup_entry+0x19/0x20 start_secondary+0x117/0x160 secondary_startup_64_no_verify+0xb0/0xbb -> BUG: kernel NULL pointer dereference, address: 00000000000000c0 Call Trace: ? __die_body+0x1a/0x60 ? no_context+0x183/0x350 ? __warn+0x8a/0xe0 ? exc_page_fault+0x3d6/0x520 ? asm_exc_page_fault+0x1e/0x30 ? pick_next_task_rt+0xb5/0x1d0 ? pick_next_task_rt+0x8c/0x1d0 __schedule+0x583/0x7e0 ? update_ts_time_stats+0x55/0x70 schedule_idle+0x1e/0x40 do_idle+0x15e/0x200 cpu_startup_entry+0x19/0x20 start_secondary+0x117/0x160 secondary_startup_64_no_verify+0xb0/0xbb -> BUG: unable to handle page fault for address: ffff9464daea5900 kernel BUG at kernel/sched/rt.c:1861! BUG_ON(rq->cpu != task_cpu(p)) -> kernel BUG at kernel/sched/rt.c:1055! BUG_ON(!rq->nr_running) Call Trace: ? __die_body+0x1a/0x60 ? die+0x2a/0x50 ? do_trap+0x85/0x100 ? dequeue_top_rt_rq+0xa2/0xb0 ? do_error_trap+0x64/0xa0 ? dequeue_top_rt_rq+0xa2/0xb0 ? exc_invalid_op+0x4c/0x60 ? dequeue_top_rt_rq+0xa2/0xb0 ? asm_exc_invalid_op+0x12/0x20 ? dequeue_top_rt_rq+0xa2/0xb0 dequeue_rt_entity+0x1f/0x70 dequeue_task_rt+0x2d/0x70 __schedule+0x1a8/0x7e0 ? blk_finish_plug+0x25/0x40 schedule+0x3c/0xb0 futex_wait_queue_me+0xb6/0x120 futex_wait+0xd9/0x240 do_futex+0x344/0xa90 ? get_mm_exe_file+0x30/0x60 ? audit_exe_compare+0x58/0x70 ? audit_filter_rules.constprop.26+0x65e/0x1220 __x64_sys_futex+0x148/0x1f0 do_syscall_64+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x62/0xc7 -> BUG: unable to handle page fault for address: ffff8cf3608bc2c0 Call Trace: ? __die_body+0x1a/0x60 ? no_context+0x183/0x350 ? spurious_kernel_fault+0x171/0x1c0 ? exc_page_fault+0x3b6/0x520 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? asm_exc_page_fault+0x1e/0x30 ? _cond_resched+0x15/0x30 ? futex_wait_queue_me+0xc8/0x120 ? futex_wait+0xd9/0x240 ? try_to_wake_up+0x1b8/0x490 ? futex_wake+0x78/0x160 ? do_futex+0xcd/0xa90 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? plist_del+0x6a/0xd0 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? dequeue_pushable_task+0x20/0x70 ? __schedule+0x382/0x7e0 ? asm_sysvec_reschedule_ipi+0xa/0x20 ? schedule+0x3c/0xb0 ? exit_to_user_mode_prepare+0x9e/0x150 ? irqentry_exit_to_user_mode+0x5/0x30 ? asm_sysvec_reschedule_ipi+0x12/0x20 Above are some of the common examples of the crashes that were observed due to this issue. Details ======= Let's look at the following scenario to understand this race. 1) CPU A enters push_rt_task a) CPU A has chosen next_task = task p. b) CPU A calls find_lock_lowest_rq(Task p, CPU Z’s rq). c) CPU A identifies CPU X as a destination CPU (X < Z). d) CPU A enters double_lock_balance(CPU Z’s rq, CPU X’s rq). e) Since X is lower than Z, CPU A unlocks CPU Z’s rq. Someone else has locked CPU X’s rq, and thus, CPU A must wait. 2) At CPU Z a) Previous task has completed execution and thus, CPU Z enters schedule, locks its own rq after CPU A releases it. b) CPU Z dequeues previous task and begins executing task p. c) CPU Z unlocks its rq. d) Task p yields the CPU (ex. by doing IO or waiting to acquire a lock) which triggers the schedule function on CPU Z. e) CPU Z enters schedule again, locks its own rq, and dequeues task p. f) As part of dequeue, it sets p.on_rq = 0 and unlocks its rq. 3) At CPU B a) CPU B enters try_to_wake_up with input task p. b) Since CPU Z dequeued task p, p.on_rq = 0, and CPU B updates B.state = WAKING. c) CPU B via select_task_rq determines CPU Y as the target CPU. 4) The race a) CPU A acquires CPU X’s lock and relocks CPU Z. b) CPU A reads task p.cpu = Z and incorrectly concludes task p is still on CPU Z. c) CPU A failed to notice task p had been dequeued from CPU Z while CPU A was waiting for locks in double_lock_balance. If CPU A knew that task p had been dequeued, it would return NULL forcing push_rt_task to give up the task p's migration. d) CPU B updates task p.cpu = Y and calls ttwu_queue. e) CPU B locks Ys rq. CPU B enqueues task p onto Y and sets task p.on_rq = 1. f) CPU B unlocks CPU Y, triggering memory synchronization. g) CPU A reads task p.on_rq = 1, cementing its assumption that task p has not migrated. h) CPU A decides to migrate p to CPU X. This leads to A dequeuing p from Y's queue and various crashes down the line. Solution ======== The solution here is fairly simple. After obtaining the lock (at 4a), the check is enhanced to make sure that the task is still at the head of the pushable tasks list. If not, then it is anyway not suitable for being pushed out. Testing ======= The fix is tested on a cluster of 3 nodes, where the panics due to this are hit every couple of days. A fix similar to this was deployed on such cluster and was stable for more than 30 days. Co-developed-by: Jon Kohler Signed-off-by: Jon Kohler Co-developed-by: Gauri Patwardhan Signed-off-by: Gauri Patwardhan Co-developed-by: Rahul Chunduru Signed-off-by: Rahul Chunduru Signed-off-by: Harshit Agarwal Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: "Steven Rostedt (Google)" Reviewed-by: Phil Auld Tested-by: Will Ton Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250225180553.167995-1-harshit@nutanix.com Signed-off-by: Greg Kroah-Hartman commit 507c1a81ab4c14bb2a45339793a1114919913f46 Author: Alexander Aring Date: Mon Mar 31 19:03:24 2025 -0400 gfs2: move msleep to sleepable context commit ac5ee087d31ed93b6e45d2968a66828c6f621d8c upstream. This patch moves the msleep_interruptible() out of the non-sleepable context by moving the ls->ls_recover_spin spinlock around so msleep_interruptible() will be called in a sleepable context. Cc: stable@vger.kernel.org Fixes: 4a7727725dc7 ("GFS2: Fix recovery issues for spectators") Suggested-by: Andreas Gruenbacher Signed-off-by: Alexander Aring Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit 0a8a9c8cf624f40b6f9fdd79a34c9c904bed0721 Author: Herbert Xu Date: Thu May 8 13:22:16 2025 +0800 crypto: marvell/cesa - Do not chain submitted requests commit 0413bcf0fc460a68a2a7a8354aee833293d7d693 upstream. This driver tries to chain requests together before submitting them to hardware in order to reduce completion interrupts. However, it even extends chains that have already been submitted to hardware. This is dangerous because there is no way of knowing whether the hardware has already read the DMA memory in question or not. Fix this by splitting the chain list into two. One for submitted requests and one for requests that have not yet been submitted. Only extend the latter. Reported-by: Klaus Kudielka Fixes: 85030c5168f1 ("crypto: marvell - Add support for chaining crypto requests in TDMA mode") Cc: Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ebf1196ff28ad72292ffc87990d6271c92463963 Author: Zijun Hu Date: Wed May 7 19:50:26 2025 +0800 configfs: Do not override creating attribute file failure in populate_attrs() commit f830edbae247b89228c3e09294151b21e0dc849c upstream. populate_attrs() may override failure for creating attribute files by success for creating subsequent bin attribute files, and have wrong return value. Fix by creating bin attribute files under successfully creating attribute files. Fixes: 03607ace807b ("configfs: implement binary attributes") Cc: stable@vger.kernel.org Reviewed-by: Joel Becker Reviewed-by: Breno Leitao Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20250507-fix_configfs-v3-2-fe2d96de8dc4@quicinc.com Signed-off-by: Andreas Hindborg Signed-off-by: Greg Kroah-Hartman commit b6bbbb8ef48dde09c0dbd77121fa0f09b0237fec Author: Suren Baghdasaryan Date: Wed May 21 09:06:02 2025 -0700 alloc_tag: handle module codetag load errors as module load failures commit 044d2aee6c575231ed4a24fb3d119bad0937488b upstream. Failures inside codetag_load_module() are currently ignored. As a result an error there would not cause a module load failure and freeing of the associated resources. Correct this behavior by propagating the error code to the caller and handling possible errors. With this change, error to allocate percpu counters, which happens at this stage, will not be ignored and will cause a module load failure and freeing of resources. With this change we also do not need to disable memory allocation profiling when this error happens, instead we fail to load the module. Link: https://lkml.kernel.org/r/20250521160602.1940771-1-surenb@google.com Fixes: 10075262888b ("alloc_tag: allocate percpu counters for module tags dynamically") Signed-off-by: Suren Baghdasaryan Reported-by: Casey Chen Closes: https://lore.kernel.org/all/20250520231620.15259-1-cachen@purestorage.com/ Cc: Daniel Gomez Cc: David Wang <00107082@163.com> Cc: Kent Overstreet Cc: Luis Chamberalin Cc: Petr Pavlu Cc: Sami Tolvanen Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman