commit e0c3d4707e1f57ea8bedfcb643439c64ce7270ef Author: Alexandre Frade Date: Sun Apr 20 16:05:00 2025 +0000 Linux 6.12.24-rt-xanmod1 Signed-off-by: Alexandre Frade commit b3477e106d1f5f9e5f2313aa1a3bc110aa8f9cee Merge: 4c5fbba8c7e2 b1bbf406c3d0 Author: Alexandre Frade Date: Sun Apr 20 16:03:51 2025 +0000 Merge branch '6.12' into 6.12-rt commit b1bbf406c3d0cf2abc5d61c3f26ca19278987716 Author: Alexandre Frade Date: Sun Apr 20 15:55:31 2025 +0000 Linux 6.12.24-xanmod1 Signed-off-by: Alexandre Frade commit e18f5ec6fd1ad09c5d3124f70fae46226e6eeee0 Merge: 1b37c2e3ec99 b6efa8ce222e Author: Alexandre Frade Date: Sun Apr 20 15:50:25 2025 +0000 Merge tag 'v6.12.24' into 6.12 This is the 6.12.24 stable release commit b6efa8ce222e58cfe2bbaa4e3329818c2b4bd74e Author: Greg Kroah-Hartman Date: Sun Apr 20 10:16:02 2025 +0200 Linux 6.12.24 Link: https://lore.kernel.org/r/20250417175107.546547190@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Salvatore Bonaccorso Tested-by: Peter Schneider Tested-by: Markus Reichelt Tested-by: Shuah Khan Tested-by: Harshit Mogalapalli Link: https://lore.kernel.org/r/20250418110359.237869758@linuxfoundation.org Tested-by: Mark Brown Tested-by: Jon Hunter Tested-by: SeongJae Park Tested-by: Ron Economos Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit ae5a6a0b425e8f76a9f0677e50796e494e89b088 Author: Kaixin Wang Date: Wed Sep 18 20:07:50 2024 +0800 HSI: ssi_protocol: Fix use after free vulnerability in ssi_protocol Driver Due to Race Condition commit e3f88665a78045fe35c7669d2926b8d97b892c11 upstream. In the ssi_protocol_probe() function, &ssi->work is bound with ssip_xmit_work(), In ssip_pn_setup(), the ssip_pn_xmit() function within the ssip_pn_ops structure is capable of starting the work. If we remove the module which will call ssi_protocol_remove() to make a cleanup, it will free ssi through kfree(ssi), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ssip_xmit_work ssi_protocol_remove | kfree(ssi); | | struct hsi_client *cl = ssi->cl; | // use ssi Fix it by ensuring that the work is canceled before proceeding with the cleanup in ssi_protocol_remove(). Signed-off-by: Kaixin Wang Acked-by: Andy Shevchenko Link: https://lore.kernel.org/r/20240918120749.1730-1-kxwang23@m.fudan.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit bdbecb2bf531fadbbc9347a79009f7a58ea7eb03 Author: Thomas Richter Date: Wed Apr 9 10:03:53 2025 +0200 s390/cpumf: Fix double free on error in cpumf_pmu_event_init() commit aa1ac98268cd1f380c713f07e39b1fa1d5c7650c upstream. In PMU event initialization functions - cpumsf_pmu_event_init() - cpumf_pmu_event_init() - cfdiag_event_init() the partially created event had to be removed when an error was detected. The event::event_init() member function had to release all resources it allocated in case of error. event::destroy() had to be called on freeing an event after it was successfully created and event::event_init() returned success. With commit c70ca298036c ("perf/core: Simplify the perf_event_alloc() error path") this is not necessary anymore. The performance subsystem common code now always calls event::destroy() to clean up the allocated resources created during event initialization. Remove the event::destroy() invocation in PMU event initialization or that function is called twice for each event that runs into an error condition in event creation. This is the kernel log entry which shows up without the fix: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 43388 at lib/refcount.c:87 refcount_dec_not_one+0x74/0x90 CPU: 0 UID: 0 PID: 43388 Comm: perf Not tainted 6.15.0-20250407.rc1.git0.300.fc41.s390x+git #1 NONE Hardware name: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704c00180000000 00000209cb2c1b88 (refcount_dec_not_one+0x78/0x90) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 0000020900000027 0000020900000023 0000000000000026 0000018900000000 00000004a2200a00 0000000000000000 0000000000000057 ffffffffffffffea 00000002b386c600 00000002b3f5b3e0 00000209cc51f140 00000209cc7fc550 0000000001449d38 ffffffffffffffff 00000209cb2c1b84 00000189d67dfb80 Krnl Code: 00000209cb2c1b78: c02000506727 larl %r2,00000209cbcce9c6 00000209cb2c1b7e: c0e5ffbd4431 brasl %r14,00000209caa6a3e0 #00000209cb2c1b84: af000000 mc 0,0 >00000209cb2c1b88: a7480001 lhi %r4,1 00000209cb2c1b8c: ebeff0a00004 lmg %r14,%r15,160(%r15) 00000209cb2c1b92: ec243fbf0055 risbg %r2,%r4,63,191,0 00000209cb2c1b98: 07fe bcr 15,%r14 00000209cb2c1b9a: 47000700 bc 0,1792 Call Trace: [<00000209cb2c1b88>] refcount_dec_not_one+0x78/0x90 [<00000209cb2c1dc4>] refcount_dec_and_mutex_lock+0x24/0x90 [<00000209caa3c29e>] hw_perf_event_destroy+0x2e/0x80 [<00000209cacaf8b4>] __free_event+0x74/0x270 [<00000209cacb47c4>] perf_event_alloc.part.0+0x4a4/0x730 [<00000209cacbf3e8>] __do_sys_perf_event_open+0x248/0xc20 [<00000209cacc14a4>] __s390x_sys_perf_event_open+0x44/0x50 [<00000209cb8114de>] __do_syscall+0x12e/0x260 [<00000209cb81ce34>] system_call+0x74/0x98 Last Breaking-Event-Address: [<00000209caa6a4d2>] __warn_printk+0xf2/0x100 ---[ end trace 0000000000000000 ]--- Fixes: c70ca298036c ("perf/core: Simplify the perf_event_alloc() error path") Signed-off-by: Thomas Richter Reviewed-by: Sumanth Korikkar Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 281782d2c6730241e300d630bb9f200d831ede71 Author: Arseniy Krasnov Date: Wed Feb 12 18:59:46 2025 +0300 Bluetooth: hci_uart: Fix another race during initialization commit 5df5dafc171b90d0b8d51547a82657cd5a1986c7 upstream. Do not set 'HCI_UART_PROTO_READY' before call 'hci_uart_register_dev()'. Possible race is when someone calls 'hci_tty_uart_close()' after this bit is set, but 'hci_uart_register_dev()' wasn't done. This leads to access to uninitialized fields. To fix it let's set this bit after device was registered (as before patch c411c62cc133) and to fix previous problem let's add one more bit in addition to 'HCI_UART_PROTO_READY' which allows to perform power up without original bit set (pls see commit c411c62cc133). Crash backtrace from syzbot report: RIP: 0010:skb_queue_empty_lockless include/linux/skbuff.h:1887 [inline] RIP: 0010:skb_queue_purge_reason+0x6d/0x140 net/core/skbuff.c:3936 Call Trace: skb_queue_purge include/linux/skbuff.h:3364 [inline] mrvl_close+0x2f/0x90 drivers/bluetooth/hci_mrvl.c:100 hci_uart_tty_close+0xb6/0x120 drivers/bluetooth/hci_ldisc.c:557 tty_ldisc_close drivers/tty/tty_ldisc.c:455 [inline] tty_ldisc_kill+0x66/0xc0 drivers/tty/tty_ldisc.c:613 tty_ldisc_release+0xc9/0x120 drivers/tty/tty_ldisc.c:781 tty_release_struct+0x10/0x80 drivers/tty/tty_io.c:1690 tty_release+0x4ef/0x640 drivers/tty/tty_io.c:1861 __fput+0x86/0x2a0 fs/file_table.c:450 task_work_run+0x82/0xb0 kernel/task_work.c:239 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop kernel/entry/common.c:114 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0xa3/0x1b0 kernel/entry/common.c:218 do_syscall_64+0x9a/0x190 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f Signed-off-by: Arseniy Krasnov Reported-by: syzbot+683f8cb11b94b1824c77@syzkaller.appspotmail.com Tested-by: syzbot+683f8cb11b94b1824c77@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-bluetooth/d159c57f-8490-4c26-79da-6ad3612c4a14@salutedevices.com/ Fixes: 366ceff495f9 ("Bluetooth: hci_uart: fix race during initialization") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit f87626a55c215c4d2f2934aba928bd05f52764c5 Author: Arnd Bergmann Date: Fri Oct 18 15:14:42 2024 +0000 media: mediatek: vcodec: mark vdec_vp9_slice_map_counts_eob_coef noinline commit 8b55f8818900c99dd4f55a59a103f5b29e41eb2c upstream. With KASAN enabled, clang fails to optimize the inline version of vdec_vp9_slice_map_counts_eob_coef() properly, leading to kilobytes of temporary values spilled to the stack: drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c:1526:12: error: stack frame size (2160) exceeds limit (2048) in 'vdec_vp9_slice_update_prob' [-Werror,-Wframe-larger-than] This seems to affect all versions of clang including the latest (clang-20), but the degree of stack overhead is different per release. Marking the function as noinline_for_stack is harmless here and avoids the problem completely. Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Signed-off-by: Sebastian Fricke Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 9c03f6194e88cc5b737e353e546bf52d4f7d51da Author: Nathan Chancellor Date: Mon Apr 7 16:22:12 2025 -0700 kbuild: Add '-fno-builtin-wcslen' commit 84ffc79bfbf70c779e60218563f2f3ad45288671 upstream. A recent optimization change in LLVM [1] aims to transform certain loop idioms into calls to strlen() or wcslen(). This change transforms the first while loop in UniStrcat() into a call to wcslen(), breaking the build when UniStrcat() gets inlined into alloc_path_with_tree_prefix(): ld.lld: error: undefined symbol: wcslen >>> referenced by nls_ucs2_utils.h:54 (fs/smb/client/../../nls/nls_ucs2_utils.h:54) >>> vmlinux.o:(alloc_path_with_tree_prefix) >>> referenced by nls_ucs2_utils.h:54 (fs/smb/client/../../nls/nls_ucs2_utils.h:54) >>> vmlinux.o:(alloc_path_with_tree_prefix) Disable this optimization with '-fno-builtin-wcslen', which prevents the compiler from assuming that wcslen() is available in the kernel's C library. [ More to the point - it's not that we couldn't implement wcslen(), it's that this isn't an optimization at all in the context of the kernel. Replacing a simple inlined loop with a function call to the same loop is just stupid and pointless if you don't have long strings and fancy libraries with vectorization support etc. For the regular 'strlen()' cases, we want the compiler to do this in order to handle the trivial case of constant strings. And we do have optimized versions of 'strlen()' on some architectures. But for wcslen? Just no. - Linus ] Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/commit/9694844d7e36fd5e01011ab56b64f27b867aa72d [1] Signed-off-by: Nathan Chancellor Signed-off-by: Linus Torvalds [nathan: Resolve small conflict in older trees] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 5f494f4823413f16f4f79999f83df9c8b6ee57be Author: Eder Zulian Date: Tue Oct 22 19:23:28 2024 +0200 libbpf: Prevent compiler warnings/errors commit 7f4ec77f3fee41dd6a41f03a40703889e6e8f7b2 upstream. Initialize 'new_off' and 'pad_bits' to 0 and 'pad_type' to NULL in btf_dump_emit_bit_padding to prevent compiler warnings/errors which are observed when compiling with 'EXTRA_CFLAGS=-g -Og' options, but do not happen when compiling with current default options. For example, when compiling libbpf with $ make "EXTRA_CFLAGS=-g -Og" -C tools/lib/bpf/ clean all Clang version 17.0.6 and GCC 13.3.1 fail to compile btf_dump.c due to following errors: btf_dump.c: In function ‘btf_dump_emit_bit_padding’: btf_dump.c:903:42: error: ‘new_off’ may be used uninitialized [-Werror=maybe-uninitialized] 903 | if (new_off > cur_off && new_off <= next_off) { | ~~~~~~~~^~~~~~~~~~~ btf_dump.c:870:13: note: ‘new_off’ was declared here 870 | int new_off, pad_bits, bits, i; | ^~~~~~~ btf_dump.c:917:25: error: ‘pad_type’ may be used uninitialized [-Werror=maybe-uninitialized] 917 | btf_dump_printf(d, "\n%s%s: %d;", pfx(lvl), pad_type, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 918 | in_bitfield ? new_off - cur_off : 0); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ btf_dump.c:871:21: note: ‘pad_type’ was declared here 871 | const char *pad_type; | ^~~~~~~~ btf_dump.c:930:20: error: ‘pad_bits’ may be used uninitialized [-Werror=maybe-uninitialized] 930 | if (bits == pad_bits) { | ^ btf_dump.c:870:22: note: ‘pad_bits’ was declared here 870 | int new_off, pad_bits, bits, i; | ^~~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Eder Zulian Signed-off-by: Andrii Nakryiko Acked-by: Jiri Olsa Link: https://lore.kernel.org/bpf/20241022172329.3871958-3-ezulian@redhat.com Signed-off-by: He Zhe Signed-off-by: Xiangyu Chen Signed-off-by: Greg Kroah-Hartman commit bd6eae1f30bfe5093a85d8a9ad8efb92fde92a21 Author: Myrrh Periwinkle Date: Sun Apr 6 11:45:22 2025 +0700 x86/e820: Fix handling of subpage regions when calculating nosave ranges in e820__register_nosave_regions() commit f2f29da9f0d4367f6ff35e0d9d021257bb53e273 upstream. While debugging kexec/hibernation hangs and crashes, it turned out that the current implementation of e820__register_nosave_regions() suffers from multiple serious issues: - The end of last region is tracked by PFN, causing it to find holes that aren't there if two consecutive subpage regions are present - The nosave PFN ranges derived from holes are rounded out (instead of rounded in) which makes it inconsistent with how explicitly reserved regions are handled Fix this by: - Treating reserved regions as if they were holes, to ensure consistent handling (rounding out nosave PFN ranges is more correct as the kernel does not use partial pages) - Tracking the end of the last RAM region by address instead of pages to detect holes more precisely These bugs appear to have been introduced about ~18 years ago with the very first version of e820_mark_nosave_regions(), and its flawed assumptions were carried forward uninterrupted through various waves of rewrites and renames. [ mingo: Added Git archeology details, for kicks and giggles. ] Fixes: e8eff5ac294e ("[PATCH] Make swsusp avoid memory holes and reserved memory regions on x86_64") Reported-by: Roberto Ricci Tested-by: Roberto Ricci Signed-off-by: Myrrh Periwinkle Signed-off-by: Ingo Molnar Cc: Rafael J. Wysocki Cc: Ard Biesheuvel Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: David Woodhouse Cc: Len Brown Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250406-fix-e820-nosave-v3-1-f3787bc1ee1d@qtmlabs.xyz Closes: https://lore.kernel.org/all/Z4WFjBVHpndct7br@desktop0a/ Signed-off-by: Myrrh Periwinkle Signed-off-by: Greg Kroah-Hartman commit 6a59b70fe71ec66c0dd19e2c279c71846a3fb2f0 Author: Jeff Layton Date: Thu Feb 6 13:12:13 2025 -0500 nfsd: don't ignore the return code of svc_proc_register() commit 930b64ca0c511521f0abdd1d57ce52b2a6e3476b upstream. Currently, nfsd_proc_stat_init() ignores the return value of svc_proc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later. Fix nfsd_proc_stat_init() to return the same type of pointer as svc_proc_register(), and fix up nfsd_net_init() to check that and fail the nfsd_net construction if it occurs. svc_proc_register() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsd_net construction codepath, so if this happens, return -ENOMEM. Reported-by: syzbot+e34ad04f27991521104c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-nfs/67a47501.050a0220.19061f.05f9.GAE@google.com/ Cc: stable@vger.kernel.org # v6.9 Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit b2b18a9f68f992f0082969ec755d7ca8af76bcb0 Author: Chuck Lever Date: Mon Feb 10 11:43:31 2025 -0500 NFSD: Fix CB_GETATTR status fix commit 4990d098433db18c854e75fb0f90d941eb7d479e upstream. Jeff says: Now that I look, 1b3e26a5ccbf is wrong. The patch on the ml was correct, but the one that got committed is different. It should be: status = decode_cb_op_status(xdr, OP_CB_GETATTR, &cb->cb_status); if (unlikely(status || cb->cb_status)) If "status" is non-zero, decoding failed (usu. BADXDR), but we also want to bail out and not decode the rest of the call if the decoded cb_status is non-zero. That's not happening here, cb_seq_status has already been checked and is non-zero, so this ends up trying to decode the rest of the CB_GETATTR reply when it doesn't exist. Reported-by: Jeff Layton Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219737 Fixes: 1b3e26a5ccbf ("NFSD: fix decoding in nfs4_xdr_dec_cb_getattr") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 560c03189615c4b89509ab696fdc04b4edad6ed9 Author: Olga Kornievskaia Date: Thu Dec 19 15:12:04 2024 -0500 NFSD: fix decoding in nfs4_xdr_dec_cb_getattr commit 1b3e26a5ccbfc2f85bda1930cc278e313165e353 upstream. If a client were to send an error to a CB_GETATTR call, the code erronously continues to try decode past the error code. It ends up returning BAD_XDR error to the rpc layer and then in turn trigger a WARN_ONCE in nfsd4_cb_done() function. Fixes: 6487a13b5c6b ("NFSD: add support for CB_GETATTR callback") Signed-off-by: Olga Kornievskaia Reviewed-by: Jeff Layton Reviewed-by: Benjamin Coddington Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 7005fdceff205c7c92b4d1b616bb778e12db14a5 Author: Nathan Chancellor Date: Mon Feb 10 21:28:25 2025 -0500 ACPI: platform-profile: Fix CFI violation when accessing sysfs files commit dd4f730b557ce701a2cd4f604bf1e57667bd8b6e upstream. When an attribute group is created with sysfs_create_group(), the ->sysfs_ops() callback is set to kobj_sysfs_ops, which sets the ->show() and ->store() callbacks to kobj_attr_show() and kobj_attr_store() respectively. These functions use container_of() to get the respective callback from the passed attribute, meaning that these callbacks need to be of the same type as the callbacks in 'struct kobj_attribute'. However, ->show() and ->store() in the platform_profile driver are defined for struct device_attribute with the help of DEVICE_ATTR_RO() and DEVICE_ATTR_RW(), which results in a CFI violation when accessing platform_profile or platform_profile_choices under /sys/firmware/acpi because the types do not match: CFI failure at kobj_attr_show+0x19/0x30 (target: platform_profile_choices_show+0x0/0x140; expected type: 0x7a69590c) There is no functional issue from the type mismatch because the layout of 'struct kobj_attribute' and 'struct device_attribute' are the same, so the container_of() cast does not break anything aside from CFI. Change the type of platform_profile_choices_show() and platform_profile_{show,store}() to match the callbacks in 'struct kobj_attribute' and update the attribute variables to match, which resolves the CFI violation. Cc: All applicable Fixes: a2ff95e018f1 ("ACPI: platform: Add platform profile support") Reported-by: John Rowley Closes: https://github.com/ClangBuiltLinux/linux/issues/2047 Tested-by: John Rowley Reviewed-by: Sami Tolvanen Signed-off-by: Nathan Chancellor Acked-by: Greg Kroah-Hartman Reviewed-by: Mark Pearson Tested-by: Mark Pearson Link: https://patch.msgid.link/20250210-acpi-platform_profile-fix-cfi-violation-v3-1-ed9e9901c33a@kernel.org [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki [nathan: Fix conflicts in older stable branches] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 20867f094883ac409bed8d080993f4810db70a90 Author: Kirill A. Shutemov Date: Fri Feb 28 01:44:14 2025 +0000 x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT commit 22cc5ca5de52bbfc36a7d4a55323f91fb4492264 upstream. CONFIG_PARAVIRT_XXL is mainly defined/used by XEN PV guests. For other VM guest types, features supported under CONFIG_PARAVIRT are self sufficient. CONFIG_PARAVIRT mainly provides support for TLB flush operations and time related operations. For TDX guest as well, paravirt calls under CONFIG_PARVIRT meets most of its requirement except the need of HLT and SAFE_HLT paravirt calls, which is currently defined under CONFIG_PARAVIRT_XXL. Since enabling CONFIG_PARAVIRT_XXL is too bloated for TDX guest like platforms, move HLT and SAFE_HLT paravirt calls under CONFIG_PARAVIRT. Moving HLT and SAFE_HLT paravirt calls are not fatal and should not break any functionality for current users of CONFIG_PARAVIRT. Fixes: bfe6ed0c6727 ("x86/tdx: Add HLT support for TDX guests") Co-developed-by: Kuppuswamy Sathyanarayanan Signed-off-by: Kuppuswamy Sathyanarayanan Signed-off-by: Kirill A. Shutemov Signed-off-by: Vishal Annapurve Signed-off-by: Ingo Molnar Reviewed-by: Andi Kleen Reviewed-by: Tony Luck Reviewed-by: Juergen Gross Tested-by: Ryan Afranji Cc: Andy Lutomirski Cc: Brian Gerst Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Josh Poimboeuf Cc: stable@kernel.org Link: https://lore.kernel.org/r/20250228014416.3925664-2-vannapurve@google.com Signed-off-by: Greg Kroah-Hartman commit 5d9484cd372db106e8303464a67641ce66ad7ec1 Author: Yi Liu Date: Wed Mar 5 19:48:42 2025 -0800 iommufd: Fail replace if device has not been attached commit 55c85fa7579dc2e3f5399ef5bad67a44257c1a48 upstream. The current implementation of iommufd_device_do_replace() implicitly assumes that the input device has already been attached. However, there is no explicit check to verify this assumption. If another device within the same group has been attached, the replace operation might succeed, but the input device itself may not have been attached yet. As a result, the input device might not be tracked in the igroup->device_list, and its reserved IOVA might not be added. Despite this, the caller might incorrectly assume that the device has been successfully replaced, which could lead to unexpected behavior or errors. To address this issue, add a check to ensure that the input device has been attached before proceeding with the replace operation. This check will help maintain the integrity of the device tracking system and prevent potential issues arising from incorrect assumptions about the device's attachment status. Fixes: e88d4ec154a8 ("iommufd: Add iommufd_device_replace()") Link: https://patch.msgid.link/r/20250306034842.5950-1-yi.l.liu@intel.com Cc: stable@vger.kernel.org Reviewed-by: Kevin Tian Signed-off-by: Yi Liu Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 6d11543bf37abdf60b8e6022a62fccfb82a5fe2e Author: Nicolin Chen Date: Mon Feb 3 21:00:54 2025 -0800 iommufd: Make attach_handle generic than fault specific commit fb21b1568adaa76af7a8c853f37c60fba8b28661 upstream. "attach_handle" was added exclusively for the iommufd_fault_iopf_handler() used by IOPF/PRI use cases. Now, both the MSI and PASID series require to reuse the attach_handle for non-fault cases. Add a set of new attach/detach/replace helpers that does the attach_handle allocation/releasing/replacement in the common path and also handles those fault specific routines such as iopf enabling/disabling and auto response. This covers both non-fault and fault cases in a clean way, replacing those inline helpers in the header. The following patch will clean up those old helpers in the fault.c file. Link: https://patch.msgid.link/r/32687df01c02291d89986a9fca897bbbe2b10987.1738645017.git.nicolinc@nvidia.com Signed-off-by: Nicolin Chen Reviewed-by: Yi Liu Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 9ca4fe357464bbdad0db67985275f2694df8dab5 Author: Douglas Anderson Date: Tue Jan 7 12:06:02 2025 -0800 arm64: errata: Add newer ARM cores to the spectre_bhb_loop_affected() lists commit a5951389e58d2e816eed3dbec5877de9327fd881 upstream. When comparing to the ARM list [1], it appears that several ARM cores were missing from the lists in spectre_bhb_loop_affected(). Add them. NOTE: for some of these cores it may not matter since other ways of clearing the BHB may be used (like the CLRBHB instruction or ECBHB), but it still seems good to have all the info from ARM's whitepaper included. [1] https://developer.arm.com/Arm%20Security%20Center/Spectre-BHB Fixes: 558c303c9734 ("arm64: Mitigate spectre style branch history side channels") Cc: stable@vger.kernel.org Signed-off-by: Douglas Anderson Reviewed-by: James Morse Link: https://lore.kernel.org/r/20250107120555.v4.5.I4a9a527e03f663040721c5401c41de587d015c82@changeid Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit d25a240c5a937f7a60a4a2f8e548e78a8de54ea0 Author: Nícolas F. R. A. Prado Date: Mon Jan 13 10:27:13 2025 -0300 thermal/drivers/mediatek/lvts: Disable Stage 3 thermal threshold commit c612cbcdf603aefb3358b2e3964dcd5aa3f827a0 upstream. The Stage 3 thermal threshold is currently configured during the controller initialization to 105 Celsius. From the kernel perspective, this configuration is harmful because: * The stage 3 interrupt that gets triggered when the threshold is crossed is not handled in any way by the IRQ handler, it just gets cleared. Besides, the temperature used for stage 3 comes from the sensors, and the critical thermal trip points described in the Devicetree will already cause a shutdown when crossed (at a lower temperature, of 100 Celsius, for all SoCs currently using this driver). * The only effect of crossing the stage 3 threshold that has been observed is that it causes the machine to no longer be able to enter suspend. Even if that was a result of a momentary glitch in the temperature reading of a sensor (as has been observed on the MT8192-based Chromebooks). For those reasons, disable the Stage 3 thermal threshold configuration. Cc: stable@vger.kernel.org Reported-by: Hsin-Te Yuan Closes: https://lore.kernel.org/all/20241108-lvts-v1-1-eee339c6ca20@chromium.org/ Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver") Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nícolas F. R. A. Prado Link: https://lore.kernel.org/r/20250113-mt8192-lvts-filtered-suspend-fix-v2-2-07a25200c7c6@collabora.com Signed-off-by: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman commit 0131251d932f7cf9f1e1f47d5e6d1e682b9114bf Author: Nícolas F. R. A. Prado Date: Mon Jan 13 10:27:12 2025 -0300 thermal/drivers/mediatek/lvts: Disable monitor mode during suspend commit 65594b3745024857f812145a58db3601d733676c upstream. When configured in filtered mode, the LVTS thermal controller will monitor the temperature from the sensors and trigger an interrupt once a thermal threshold is crossed. Currently this is true even during suspend and resume. The problem with that is that when enabling the internal clock of the LVTS controller in lvts_ctrl_set_enable() during resume, the temperature reading can glitch and appear much higher than the real one, resulting in a spurious interrupt getting generated. Disable the temperature monitoring and give some time for the signals to stabilize during suspend in order to prevent such spurious interrupts. Cc: stable@vger.kernel.org Reported-by: Hsin-Te Yuan Closes: https://lore.kernel.org/all/20241108-lvts-v1-1-eee339c6ca20@chromium.org/ Fixes: 8137bb90600d ("thermal/drivers/mediatek/lvts_thermal: Add suspend and resume") Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nícolas F. R. A. Prado Link: https://lore.kernel.org/r/20250113-mt8192-lvts-filtered-suspend-fix-v2-1-07a25200c7c6@collabora.com Signed-off-by: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman commit 9580b603654dd0ea769a55dffdbab1587d3b47a5 Author: Cong Liu Date: Fri Mar 28 15:27:17 2025 +0100 selftests: mptcp: fix incorrect fd checks in main_loop commit 7335d4ac812917c16e04958775826d12d481c92d upstream. Fix a bug where the code was checking the wrong file descriptors when opening the input files. The code was checking 'fd' instead of 'fd_in', which could lead to incorrect error handling. Fixes: 05be5e273c84 ("selftests: mptcp: add disconnect tests") Cc: stable@vger.kernel.org Fixes: ca7ae8916043 ("selftests: mptcp: mptfo Initiator/Listener") Co-developed-by: Geliang Tang Signed-off-by: Geliang Tang Signed-off-by: Cong Liu Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250328-net-mptcp-misc-fixes-6-15-v1-2-34161a482a7f@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2f1b4d6725b01a2fecddad7bd531f775a41fa4a2 Author: Geliang Tang Date: Fri Mar 28 15:27:18 2025 +0100 selftests: mptcp: close fd_in before returning in main_loop commit c183165f87a486d5879f782c05a23c179c3794ab upstream. The file descriptor 'fd_in' is opened when cfg_input is configured, but not closed in main_loop(), this patch fixes it. Fixes: 05be5e273c84 ("selftests: mptcp: add disconnect tests") Cc: stable@vger.kernel.org Co-developed-by: Cong Liu Signed-off-by: Cong Liu Signed-off-by: Geliang Tang Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250328-net-mptcp-misc-fixes-6-15-v1-3-34161a482a7f@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0f91e4f69fe6cb6730bd82fa607b27fa69f038fd Author: Jake Hillion Date: Tue Mar 25 22:41:52 2025 +0000 sched_ext: create_dsq: Return -EEXIST on duplicate request commit a8897ed8523d4c9d782e282b18005a3779c92714 upstream. create_dsq and therefore the scx_bpf_create_dsq kfunc currently silently ignore duplicate entries. As a sched_ext scheduler is creating each DSQ for a different purpose this is surprising behaviour. Replace rhashtable_insert_fast which ignores duplicates with rhashtable_lookup_insert_fast that reports duplicates (though doesn't return their value). The rest of the code is structured correctly and this now returns -EEXIST. Tested by adding an extra scx_bpf_create_dsq to scx_simple. Previously this was ignored, now init fails with a -17 code. Also ran scx_lavd which continued to work well. Signed-off-by: Jake Hillion Acked-by: Andrea Righi Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 7a30bbd36cb4bd15fe9967e45418bf52520effe6 Author: Sumanth Korikkar Date: Tue Mar 25 19:02:45 2025 +0100 s390: Fix linker error when -no-pie option is unavailable commit 991a20173a1fbafd9fc0df0c7e17bb62d44a4deb upstream. The kernel build may fail if the linker does not support -no-pie option, as it always included in LDFLAGS_vmlinux. Error log: s390-linux-ld: unable to disambiguate: -no-pie (did you mean --no-pie ?) Although the GNU linker defaults to -no-pie, the ability to explicitly specify this option was introduced in binutils 2.36. Hence, fix it by adding -no-pie to LDFLAGS_vmlinux only when it is available. Cc: stable@vger.kernel.org Fixes: 00cda11d3b2e ("s390: Compile kernel with -fPIC and link with -no-pie") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202503220342.T3fElO9L-lkp@intel.com/ Suggested-by: Jens Remus Reviewed-by: Jens Remus Signed-off-by: Sumanth Korikkar Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit f268ee2fbb53bc7d8c30f36d91bc2a213c43662b Author: David Hildenbrand Date: Wed Apr 2 22:36:21 2025 +0200 s390/virtio_ccw: Don't allocate/assign airqs for non-existing queues commit 2ccd42b959aaf490333dbd3b9b102eaf295c036a upstream. If we finds a vq without a name in our input array in virtio_ccw_find_vqs(), we treat it as "non-existing" and set the vq pointer to NULL; we will not call virtio_ccw_setup_vq() to allocate/setup a vq. Consequently, we create only a queue if it actually exists (name != NULL) and assign an incremental queue index to each such existing queue. However, in virtio_ccw_register_adapter_ind()->get_airq_indicator() we will not ignore these "non-existing queues", but instead assign an airq indicator to them. Besides never releasing them in virtio_ccw_drop_indicators() (because there is no virtqueue), the bigger issue seems to be that there will be a disagreement between the device and the Linux guest about the airq indicator to be used for notifying a queue, because the indicator bit for adapter I/O interrupt is derived from the queue index. The virtio spec states under "Setting Up Two-Stage Queue Indicators": ... indicator contains the guest address of an area wherein the indicators for the devices are contained, starting at bit_nr, one bit per virtqueue of the device. And further in "Notification via Adapter I/O Interrupts": For notifying the driver of virtqueue buffers, the device sets the bit in the guest-provided indicator area at the corresponding offset. For example, QEMU uses in virtio_ccw_notify() the queue index (passed as "vector") to select the relevant indicator bit. If a queue does not exist, it does not have a corresponding indicator bit assigned, because it effectively doesn't have a queue index. Using a virtio-balloon-ccw device under QEMU with free-page-hinting disabled ("free-page-hint=off") but free-page-reporting enabled ("free-page-reporting=on") will result in free page reporting not working as expected: in the virtio_balloon driver, we'll be stuck forever in virtballoon_free_page_report()->wait_event(), because the waitqueue will not be woken up as the notification from the device is lost: it would use the wrong indicator bit. Free page reporting stops working and we get splats (when configured to detect hung wqs) like: INFO: task kworker/1:3:463 blocked for more than 61 seconds. Not tainted 6.14.0 #4 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/1:3 [...] Workqueue: events page_reporting_process Call Trace: [<000002f404e6dfb2>] __schedule+0x402/0x1640 [<000002f404e6f22e>] schedule+0x3e/0xe0 [<000002f3846a88fa>] virtballoon_free_page_report+0xaa/0x110 [virtio_balloon] [<000002f40435c8a4>] page_reporting_process+0x2e4/0x740 [<000002f403fd3ee2>] process_one_work+0x1c2/0x400 [<000002f403fd4b96>] worker_thread+0x296/0x420 [<000002f403fe10b4>] kthread+0x124/0x290 [<000002f403f4e0dc>] __ret_from_fork+0x3c/0x60 [<000002f404e77272>] ret_from_fork+0xa/0x38 There was recently a discussion [1] whether the "holes" should be treated differently again, effectively assigning also non-existing queues a queue index: that should also fix the issue, but requires other workarounds to not break existing setups. Let's fix it without affecting existing setups for now by properly ignoring the non-existing queues, so the indicator bits will match the queue indexes. [1] https://lore.kernel.org/all/cover.1720611677.git.mst@redhat.com/ Fixes: a229989d975e ("virtio: don't allocate vqs when names[i] = NULL") Reported-by: Chandra Merla Cc: stable@vger.kernel.org Signed-off-by: David Hildenbrand Tested-by: Thomas Huth Reviewed-by: Thomas Huth Reviewed-by: Cornelia Huck Acked-by: Michael S. Tsirkin Acked-by: Christian Borntraeger Link: https://lore.kernel.org/r/20250402203621.940090-1-david@redhat.com Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 05a0f9c407815487ae9627a1b680d21322bfb54d Author: Niklas Schnelle Date: Thu Mar 20 17:26:12 2025 +0100 s390/pci: Fix zpci_bus_is_isolated_vf() for non-VFs commit 8691abd3afaadd816a298503ec1a759df1305d2e upstream. For non-VFs, zpci_bus_is_isolated_vf() should return false because they aren't VFs. While zpci_iov_find_parent_pf() specifically checks if a function is a VF, it then simply returns that there is no parent. The simplistic check for a parent then leads to these functions being confused with isolated VFs and isolating them on their own domain even if sibling PFs should share the domain. Fix this by explicitly checking if a function is not a VF. Note also that at this point the case where RIDs are ignored is already handled and in this case all PCI functions get isolated by being detected in zpci_bus_is_multifunction_root(). Cc: stable@vger.kernel.org Fixes: 2844ddbd540f ("s390/pci: Fix handling of isolated VFs") Signed-off-by: Niklas Schnelle Reviewed-by: Halil Pasic Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 92ca7270fe5eae90015a54a818df46f7f7886a41 Author: Steven Rostedt Date: Wed Apr 2 10:49:07 2025 -0400 ring-buffer: Use flush_kernel_vmap_range() over flush_dcache_folio() commit e4d4b8670c44cdd22212cab3c576e2d317efa67c upstream. Some architectures do not have data cache coherency between user and kernel space. For these architectures, the cache needs to be flushed on both the kernel and user addresses so that user space can see the updates the kernel has made. Instead of using flush_dcache_folio() and playing with virt_to_folio() within the call to that function, use flush_kernel_vmap_range() which takes the virtual address and does the work for those architectures that need it. This also fixes a bug where the flush of the reader page only flushed one page. If the sub-buffer order is 1 or more, where the sub-buffer size would be greater than a page, it would miss the rest of the sub-buffer content, as the "reader page" is not just a page, but the size of a sub-buffer. Link: https://lore.kernel.org/all/CAG48ez3w0my4Rwttbc5tEbNsme6tc0mrSN95thjXUFaJ3aQ6SA@mail.gmail.com/ Cc: stable@vger.kernel.org Cc: Linus Torvalds Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Vincent Donnefort Cc: Vlastimil Babka Cc: Mike Rapoport Link: https://lore.kernel.org/20250402144953.920792197@goodmis.org Fixes: 117c39200d9d7 ("ring-buffer: Introducing ring-buffer mapping functions"); Suggested-by: Jann Horn Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit de08212061ea6991c1ef6ae294b675c74875c9c7 Author: Peter Griffin Date: Fri Mar 7 10:29:05 2025 +0000 pinctrl: samsung: add support for eint_fltcon_offset commit 701d0e910955627734917c3587258aa7e73068bb upstream. On gs101 SoC the fltcon0 (filter configuration 0) offset isn't at a fixed offset like previous SoCs as the fltcon1 register only exists when there are more than 4 pins in the bank. Add a eint_fltcon_offset and new GS101_PIN_BANK_EINT* macros that take an additional fltcon_offs variable. This can then be used in suspend/resume callbacks to save and restore the fltcon0 and fltcon1 registers. Fixes: 4a8be01a1a7a ("pinctrl: samsung: Add gs101 SoC pinctrl configuration") Cc: stable@vger.kernel.org Reviewed-by: André Draszik Signed-off-by: Peter Griffin Link: https://lore.kernel.org/r/20250307-pinctrl-fltcon-suspend-v4-1-2d775e486036@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit c1368383cd37aa1dddc209c2c8734019d486e50c Author: Stephan Gerhold Date: Wed Mar 12 14:19:27 2025 +0100 pinctrl: qcom: Clear latched interrupt status when changing IRQ type commit e225128c3f8be879e7d4eb71a25949e188b420ae upstream. When submitting the TLMM test driver, Bjorn reported that some of the test cases are failing for GPIOs that not are backed by PDC (i.e. "non-wakeup" GPIOs that are handled directly in pinctrl-msm). Basically, lingering latched interrupt state is still being delivered at IRQ request time, e.g.: ok 1 tlmm_test_silent_rising tlmm_test_silent_falling: ASSERTION FAILED at drivers/pinctrl/qcom/tlmm-test.c:178 Expected atomic_read(&priv->intr_count) == 0, but atomic_read(&priv->intr_count) == 1 (0x1) not ok 2 tlmm_test_silent_falling tlmm_test_silent_low: ASSERTION FAILED at drivers/pinctrl/qcom/tlmm-test.c:178 Expected atomic_read(&priv->intr_count) == 0, but atomic_read(&priv->intr_count) == 1 (0x1) not ok 3 tlmm_test_silent_low ok 4 tlmm_test_silent_high Whether to report interrupts that came in while the IRQ was unclaimed doesn't seem to be well-defined in the Linux IRQ API. However, looking closer at these specific cases, we're actually reporting events that do not match the interrupt type requested by the driver: 1. After "ok 1 tlmm_test_silent_rising", the GPIO is in low state and configured for IRQF_TRIGGER_RISING. 2. (a) In preparation for "tlmm_test_silent_falling", the GPIO is switched to high state. The rising interrupt gets latched. (b) The GPIO is re-configured for IRQF_TRIGGER_FALLING, but the latched interrupt isn't cleared. (c) The IRQ handler is called for the latched interrupt, but there wasn't any falling edge. 3. (a) For "tlmm_test_silent_low", the GPIO remains in high state. (b) The GPIO is re-configured for IRQF_TRIGGER_LOW. This seems to result in a phantom interrupt that gets latched. (c) The IRQ handler is called for the latched interrupt, but the GPIO isn't in low state. 4. (a) For "tlmm_test_silent_high", the GPIO is switched to low state. (b) This doesn't result in a latched interrupt, because RAW_STATUS_EN was cleared when masking the level-triggered interrupt. Fix this by clearing the interrupt state whenever making any changes to the interrupt configuration. This includes previously disabled interrupts, but also any changes to interrupt polarity or detection type. With this change, all 16 test cases are now passing for the non-wakeup GPIOs in the TLMM. Cc: stable@vger.kernel.org Fixes: cf9d052aa600 ("pinctrl: qcom: Don't clear pending interrupts when enabling") Reported-by: Bjorn Andersson Closes: https://lore.kernel.org/r/20250227-tlmm-test-v1-1-d18877b4a5db@oss.qualcomm.com/ Signed-off-by: Stephan Gerhold Tested-by: Bjorn Andersson Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/20250312-pinctrl-msm-type-latch-v1-1-ce87c561d3d7@linaro.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit beb9a5cb7aa57e712ff5b7827e6bf3e2ed42aa99 Author: Stefan Eichenberger Date: Wed Mar 5 15:43:16 2025 +0100 phy: freescale: imx8m-pcie: assert phy reset and perst in power off commit aecb63e88c5e5fb9afb782a1577264c76f179af9 upstream. Ensure the PHY reset and perst is asserted during power-off to guarantee it is in a reset state upon repeated power-on calls. This resolves an issue where the PHY may not properly initialize during subsequent power-on cycles. Power-on will deassert the reset at the appropriate time after tuning the PHY parameters. During suspend/resume cycles, we observed that the PHY PLL failed to lock during resume when the CPU temperature increased from 65C to 75C. The observed errors were: phy phy-32f00000.pcie-phy.3: phy poweron failed --> -110 imx6q-pcie 33800000.pcie: waiting for PHY ready timeout! imx6q-pcie 33800000.pcie: PM: dpm_run_callback(): genpd_resume_noirq+0x0/0x80 returns -110 imx6q-pcie 33800000.pcie: PM: failed to resume noirq: error -110 This resulted in a complete CPU freeze, which is resolved by ensuring the PHY is in reset during power-on, thus preventing PHY PLL failures. Cc: stable@vger.kernel.org Fixes: 1aa97b002258 ("phy: freescale: pcie: Initialize the imx8 pcie standalone phy driver") Signed-off-by: Stefan Eichenberger Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250305144355.20364-3-eichest@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 869202291aa47523d73a2ad9ef9ecfdeba0be5e5 Author: Philipp Stanner Date: Wed Mar 12 09:06:34 2025 +0100 PCI: Fix wrong length of devres array commit f09d3937d400433080d17982bd1a540da53a156d upstream. The array for the iomapping cookie addresses has a length of PCI_STD_NUM_BARS. This constant, however, only describes standard BARs; while PCI can allow for additional, special BARs. The total number of PCI resources is described by constant PCI_NUM_RESOURCES, which is also used in, e.g., pci_select_bars(). Thus, the devres array has so far been too small. Change the length of the devres array to PCI_NUM_RESOURCES. Link: https://lore.kernel.org/r/20250312080634.13731-3-phasta@kernel.org Fixes: bbaff68bf4a4 ("PCI: Add managed partial-BAR request and map infrastructure") Signed-off-by: Philipp Stanner Signed-off-by: Bjorn Helgaas Signed-off-by: Krzysztof Wilczyński Cc: stable@vger.kernel.org # v6.11+ Signed-off-by: Greg Kroah-Hartman commit 9707d0c932f41006a2701afc926b232b50e356b4 Author: Ma Ke Date: Tue Feb 25 10:14:40 2025 +0800 PCI: Fix reference leak in pci_register_host_bridge() commit 804443c1f27883926de94c849d91f5b7d7d696e9 upstream. If device_register() fails, call put_device() to give up the reference to avoid a memory leak, per the comment at device_register(). Found by code review. Link: https://lore.kernel.org/r/20250225021440.3130264-1-make24@iscas.ac.cn Fixes: 37d6a0a6f470 ("PCI: Add pci_register_host_bridge() interface") Signed-off-by: Ma Ke [bhelgaas: squash Dan Carpenter's double free fix from https://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d69ad6e1a5799b5865a50184544b9eecd526a4c0 Author: Ma Ke Date: Sun Feb 2 14:23:57 2025 +0800 PCI: Fix reference leak in pci_alloc_child_bus() commit 1f2768b6a3ee77a295106e3a5d68458064923ede upstream. If device_register(&child->dev) fails, call put_device() to explicitly release child->dev, per the comment at device_register(). Found by code review. Link: https://lore.kernel.org/r/20250202062357.872971-1-make24@iscas.ac.cn Fixes: 4f535093cf8f ("PCI: Put pci_dev in device tree as early as possible") Signed-off-by: Ma Ke Signed-off-by: Bjorn Helgaas Reviewed-by: Ilpo Järvinen Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e4a1d7defbc2d806540720a5adebe24ec3488683 Author: Lukas Wunner Date: Tue Mar 11 07:27:32 2025 +0100 PCI: pciehp: Avoid unnecessary device replacement check commit e3260237aaadc9799107ccb940c6688195c4518d upstream. Hot-removal of nested PCI hotplug ports suffers from a long-standing race condition which can lead to a deadlock: A parent hotplug port acquires pci_lock_rescan_remove(), then waits for pciehp to unbind from a child hotplug port. Meanwhile that child hotplug port tries to acquire pci_lock_rescan_remove() as well in order to remove its own children. The deadlock only occurs if the parent acquires pci_lock_rescan_remove() first, not if the child happens to acquire it first. Several workarounds to avoid the issue have been proposed and discarded over the years, e.g.: https://lore.kernel.org/r/4c882e25194ba8282b78fe963fec8faae7cf23eb.1529173804.git.lukas@wunner.de/ A proper fix is being worked on, but needs more time as it is nontrivial and necessarily intrusive. Recent commit 9d573d19547b ("PCI: pciehp: Detect device replacement during system sleep") provokes more frequent occurrence of the deadlock when removing more than one Thunderbolt device during system sleep. The commit sought to detect device replacement, but also triggered on device removal. Differentiating reliably between replacement and removal is impossible because pci_get_dsn() returns 0 both if the device was removed, as well as if it was replaced with one lacking a Device Serial Number. Avoid the more frequent occurrence of the deadlock by checking whether the hotplug port itself was hot-removed. If so, there's no sense in checking whether its child device was replaced. This works because the ->resume_noirq() callback is invoked in top-down order for the entire hierarchy: A parent hotplug port detecting device replacement (or removal) marks all children as removed using pci_dev_set_disconnected() and a child hotplug port can then reliably detect being removed. Link: https://lore.kernel.org/r/02f166e24c87d6cde4085865cce9adfdfd969688.1741674172.git.lukas@wunner.de Fixes: 9d573d19547b ("PCI: pciehp: Detect device replacement during system sleep") Reported-by: Kenneth Crudup Closes: https://lore.kernel.org/r/83d9302a-f743-43e4-9de2-2dd66d91ab5b@panix.com/ Reported-by: Chia-Lin Kao (AceLan) Closes: https://lore.kernel.org/r/20240926125909.2362244-1-acelan.kao@canonical.com/ Tested-by: Kenneth Crudup Tested-by: Mika Westerberg Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Reviewed-by: Mika Westerberg Reviewed-by: Kuppuswamy Sathyanarayanan Cc: stable@vger.kernel.org # v6.11+ Signed-off-by: Greg Kroah-Hartman commit ce9643a541b66770f590c59ed54b27da5a8e2ce4 Author: Siddharth Vadapalli Date: Wed Mar 5 18:50:18 2025 +0530 PCI: j721e: Fix the value of .linkdown_irq_regfield for J784S4 commit d66b5b336245b91681c2042e7eedf63ef7c2f6db upstream. Commit e49ad667815d ("PCI: j721e: Add TI J784S4 PCIe configuration") assigned the value of .linkdown_irq_regfield for the J784S4 SoC as the "LINK_DOWN" macro corresponding to BIT(1), and as a result, the Link Down interrupts on J784S4 SoC are missed. According to the Technical Reference Manual and Register Documentation for the J784S4 SoC[1], BIT(1) corresponds to "ENABLE_SYS_EN_PCIE_DPA_1", which is not the correct field for the link-state interrupt. Instead, it is BIT(10) of the "PCIE_INTD_ENABLE_REG_SYS_2" register that corresponds to the link-state field named as "ENABLE_SYS_EN_PCIE_LINK_STATE". Thus, set .linkdown_irq_regfield to the macro "J7200_LINK_DOWN", which expands to BIT(10) and was first defined for the J7200 SoC. Other SoCs already reuse this macro since it accurately represents the "link-state" field in their respective "PCIE_INTD_ENABLE_REG_SYS_2" register. 1: https://www.ti.com/lit/zip/spruj52 Fixes: e49ad667815d ("PCI: j721e: Add TI J784S4 PCIe configuration") Cc: stable@vger.kernel.org Signed-off-by: Siddharth Vadapalli [kwilczynski: commit log, add a missing .linkdown_irq_regfield member set to the J7200_LINK_DOWN macro to struct j7200_pcie_ep_data] Signed-off-by: Krzysztof Wilczyński Link: https://lore.kernel.org/r/20250305132018.2260771-1-s-vadapalli@ti.com Signed-off-by: Greg Kroah-Hartman commit 71bf0769a6c63b6f2e2774a5b7eef8af854a89f1 Author: Stanimir Varbanov Date: Thu Jan 23 00:29:55 2025 +0200 PCI: brcmstb: Fix missing of_node_put() in brcm_pcie_probe() commit 2df181e1aea4628a8fd257f866026625d0519627 upstream. A call to of_parse_phandle() is incrementing the refcount, and as such, the of_node_put() must be called when the reference is no longer needed. Thus, refactor the existing code and add a missing of_node_put() call following the check to ensure that "msi_np" matches "pcie->np" and after MSI initialization, but only if the MSI support is enabled system-wide. Cc: stable@vger.kernel.org # v5.10+ Fixes: 40ca1bf580ef ("PCI: brcmstb: Add MSI support") Signed-off-by: Stanimir Varbanov Reviewed-by: Florian Fainelli Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250122222955.1752778-1-svarbanov@suse.de [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Greg Kroah-Hartman commit 712d84459a53fc78f36ef44967f4cde4623b38f6 Author: Zijun Hu Date: Sun Feb 9 20:59:00 2025 +0800 of/irq: Fix device node refcount leakages in of_irq_init() commit 708124d9e6e7ac5ebf927830760679136b23fdf0 upstream. of_irq_init() will leak interrupt controller device node refcounts in two places as explained below: 1) Leak refcounts of both @desc->dev and @desc->interrupt_parent when suffers @desc->irq_init_cb() failure. 2) Leak refcount of @desc->interrupt_parent when cleans up list @intc_desc_list in the end. Refcounts of both @desc->dev and @desc->interrupt_parent were got in the first loop, but of_irq_init() does not put them before kfree(@desc) in places mentioned above, so causes refcount leakages. Fix by putting refcounts involved before kfree(@desc). Fixes: 8363ccb917c6 ("of/irq: add missing of_node_put") Fixes: c71a54b08201 ("of/irq: introduce of_irq_init") Cc: stable@vger.kernel.org Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20250209-of_irq_fix-v2-7-93e3a2659aa7@quicinc.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit d0f25a99770f761deea9c26f818c4c171fe71afc Author: Zijun Hu Date: Sun Feb 9 20:58:59 2025 +0800 of/irq: Fix device node refcount leakage in API irq_of_parse_and_map() commit 962a2805e47b933876ba0e4c488d9e89ced2dd29 upstream. In irq_of_parse_and_map(), refcount of device node @oirq.np was got by successful of_irq_parse_one() invocation, but it does not put the refcount before return, so causes @oirq.np refcount leakage. Fix by putting @oirq.np refcount before return. Fixes: e3873444990d ("of/irq: Move irq_of_parse_and_map() to common code") Cc: stable@vger.kernel.org Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20250209-of_irq_fix-v2-6-93e3a2659aa7@quicinc.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit 29cb94963ca9dce389e02047199db2f7cfaaa23e Author: Zijun Hu Date: Sun Feb 9 20:58:58 2025 +0800 of/irq: Fix device node refcount leakages in of_irq_count() commit bbf71f44aaf241d853759a71de7e7ebcdb89be3d upstream. of_irq_count() invokes of_irq_parse_one() to count IRQs, and successful invocation of the later will get device node @irq.np refcount, but the former does not put the refcount before next iteration invocation, hence causes device node refcount leakages. Fix by putting @irq.np refcount before the next iteration invocation. Fixes: 3da5278727a8 ("of/irq: Rework of_irq_count()") Cc: stable@vger.kernel.org Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20250209-of_irq_fix-v2-5-93e3a2659aa7@quicinc.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit 3540164c7594da629cf60d66bddd948952085c67 Author: Zijun Hu Date: Sun Feb 9 20:58:57 2025 +0800 of/irq: Fix device node refcount leakage in API of_irq_parse_raw() commit ff93e7213d6cc8d9a7b0bc64f70ed26094e168f3 upstream. if the node @out_irq->np got by of_irq_parse_raw() is a combo node which consists of both controller and nexus, namely, of_irq_parse_raw() returns due to condition (@ipar == @newpar), then the node's refcount was increased twice, hence causes refcount leakage. Fix by putting @out_irq->np refcount before returning due to the condition. Also add comments about refcount of node @out_irq->np got by the API. Fixes: 041284181226 ("of/irq: Allow matching of an interrupt-map local to an interrupt controller") Cc: stable@vger.kernel.org Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20250209-of_irq_fix-v2-4-93e3a2659aa7@quicinc.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit dc83eccc93ed0e401f20f752add3e2753432859e Author: Zijun Hu Date: Sun Feb 9 20:58:55 2025 +0800 of/irq: Fix device node refcount leakage in API of_irq_parse_one() commit 0cb58d6c7b558a69957fabe159bfb184196e1e8d upstream. of_irq_parse_one(@int_gen_dev, i, ...) will leak refcount of @i_th_phandle int_gen_dev { ... interrupts-extended = ..., <&i_th_phandle ...>, ...; ... }; Refcount of @i_th_phandle is increased by of_parse_phandle_with_args() but is not decreased by API of_irq_parse_one() before return, so causes refcount leakage. Rework the refcounting to use __free() cleanup and simplify the code to have a single call to of_irq_parse_raw(). Also add comments about refcount of node @out_irq->np got by the API. Fixes: 79d9701559a9 ("of/irq: create interrupts-extended property") Cc: stable@vger.kernel.org Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20250209-of_irq_fix-v2-2-93e3a2659aa7@quicinc.com [robh: Use __free() to do puts] Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit 60faeef98b99e3d94e068ad8f037741cad58dca0 Author: Fedor Pchelkin Date: Wed Jan 15 21:28:17 2025 +0300 ntb: use 64-bit arithmetic for the MSI doorbell mask commit fd5625fc86922f36bedee5846fefd647b7e72751 upstream. msi_db_mask is of type 'u64', still the standard 'int' arithmetic is performed to compute its value. While most of the ntb_hw drivers actually don't utilize the higher 32 bits of the doorbell mask now, this may be the case for Switchtec - see switchtec_ntb_init_db(). Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool. Fixes: 2b0569b3b7e6 ("NTB: Add MSI interrupt support to ntb_transport") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Reviewed-by: Dave Jiang Signed-off-by: Jon Mason Signed-off-by: Greg Kroah-Hartman commit 34baf1cfd679bd6312f696c4277eda5085f21878 Author: Haiyang Zhang Date: Tue Mar 25 09:32:37 2025 -0700 net: mana: Switch to page pool for jumbo frames commit fa37a8849634db2dd3545116873da8cf4b1e67c6 upstream. Frag allocators, such as netdev_alloc_frag(), were not designed to work for fragsz > PAGE_SIZE. So, switch to page pool for jumbo frames instead of using page frag allocators. This driver is using page pool for smaller MTUs already. Cc: stable@vger.kernel.org Fixes: 80f6215b450e ("net: mana: Add support for jumbo frame") Signed-off-by: Haiyang Zhang Reviewed-by: Long Li Reviewed-by: Shradha Gupta Link: https://patch.msgid.link/1742920357-27263-1-git-send-email-haiyangz@microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a2acc67d61550f931303ffa8f6dbe9ae003bbed7 Author: Kunihiko Hayashi Date: Tue Feb 25 20:02:49 2025 +0900 misc: pci_endpoint_test: Fix displaying 'irq_type' after 'request_irq' error commit 919d14603dab6a9cf03ebbeb2cfa556df48737c8 upstream. There are two variables that indicate the interrupt type to be used in the next test execution, global "irq_type" and "test->irq_type". The former is referenced from pci_endpoint_test_get_irq() to preserve the current type for ioctl(PCITEST_GET_IRQTYPE). In the pci_endpoint_test_request_irq(), since this global variable is referenced when an error occurs, the unintended error message is displayed. For example, after running "pcitest -i 2", the following message shows "MSI 3" even if the current IRQ type becomes "MSI-X": pci-endpoint-test 0000:01:00.0: Failed to request IRQ 30 for MSI 3 SET IRQ TYPE TO MSI-X: NOT OKAY Fix this issue by using "test->irq_type" instead of global "irq_type". Cc: stable@vger.kernel.org Fixes: b2ba9225e031 ("misc: pci_endpoint_test: Avoid using module parameter to determine irqtype") Reviewed-by: Manivannan Sadhasivam Signed-off-by: Kunihiko Hayashi Link: https://lore.kernel.org/r/20250225110252.28866-4-hayashi.kunihiko@socionext.com [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Greg Kroah-Hartman commit e98f77f74c66dc897eac029277a08f4ed92c7cad Author: Mickaël Salaün Date: Tue Mar 18 17:14:42 2025 +0100 selftests/landlock: Add a new test for setuid() commit c5efa393d82cf68812e0ae4d93e339873eabe9fe upstream. The new signal_scoping_thread_setuid tests check that the libc's setuid() function works as expected even when a thread is sandboxed with scoped signal restrictions. Before the signal scoping fix, this test would have failed with the setuid() call: [pid 65] getpid() = 65 [pid 65] tgkill(65, 66, SIGRT_1) = -1 EPERM (Operation not permitted) [pid 65] futex(0x40a66cdc, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 65] setuid(1001) = 0 After the fix, tgkill(2) is successfully leveraged to synchronize credentials update across threads: [pid 65] getpid() = 65 [pid 65] tgkill(65, 66, SIGRT_1) = 0 [pid 66] <... read resumed>0x40a65eb7, 1) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) [pid 66] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=65, si_uid=1000} --- [pid 66] getpid() = 65 [pid 66] setuid(1001) = 0 [pid 66] futex(0x40a66cdc, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 66] rt_sigreturn({mask=[]}) = 0 [pid 66] read(3, [pid 65] setuid(1001) = 0 Test coverage for security/landlock is 92.9% of 1137 lines according to gcc/gcov-14. Fixes: c8994965013e ("selftests/landlock: Test signal scoping for threads") Cc: Günther Noack Cc: Tahera Fahimi Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250318161443.279194-8-mic@digikod.net [mic: Update test coverage] Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 76ab50fa6e351b3529c66698df125d50f5837bc2 Author: Mickaël Salaün Date: Tue Mar 18 17:14:41 2025 +0100 selftests/landlock: Split signal_scoping_threads tests commit bbe72274035a83159c8fff7d553b4a0b3c473690 upstream. Split signal_scoping_threads tests into signal_scoping_thread_before and signal_scoping_thread_after. Use local variables for thread synchronization. Fix exported function. Replace some asserts with expects. Fixes: c8994965013e ("selftests/landlock: Test signal scoping for threads") Cc: Günther Noack Cc: Tahera Fahimi Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250318161443.279194-7-mic@digikod.net Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit b017f2846a3e47b118b4fe822e3cddd127818682 Author: Mickaël Salaün Date: Tue Mar 18 17:14:39 2025 +0100 landlock: Prepare to add second errata commit 6d9ac5e4d70eba3e336f9809ba91ab2c49de6d87 upstream. Potentially include errata for Landlock ABI v5 (Linux 6.10) and v6 (Linux 6.12). That will be useful for the following signal scoping erratum. As explained in errata.h, this commit should be backportable without conflict down to ABI v5. It must then not include the errata/abi-6.h file. Fixes: 54a6e6bbf3be ("landlock: Add signal scoping") Cc: Günther Noack Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250318161443.279194-5-mic@digikod.net Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 332facfa80751b80006c2f95b13c6d208ab0aee1 Author: Mickaël Salaün Date: Tue Mar 18 17:14:40 2025 +0100 landlock: Always allow signals between threads of the same process commit 18eb75f3af40be1f0fc2025d4ff821711222a2fd upstream. Because Linux credentials are managed per thread, user space relies on some hack to synchronize credential update across threads from the same process. This is required by the Native POSIX Threads Library and implemented by set*id(2) wrappers and libcap(3) to use tgkill(2) to synchronize threads. See nptl(7) and libpsx(3). Furthermore, some runtimes like Go do not enable developers to have control over threads [1]. To avoid potential issues, and because threads are not security boundaries, let's relax the Landlock (optional) signal scoping to always allow signals sent between threads of the same process. This exception is similar to the __ptrace_may_access() one. hook_file_set_fowner() now checks if the target task is part of the same process as the caller. If this is the case, then the related signal triggered by the socket will always be allowed. Scoping of abstract UNIX sockets is not changed because kernel objects (e.g. sockets) should be tied to their creator's domain at creation time. Note that creating one Landlock domain per thread puts each of these threads (and their future children) in their own scope, which is probably not what users expect, especially in Go where we do not control threads. However, being able to drop permissions on all threads should not be restricted by signal scoping. We are working on a way to make it possible to atomically restrict all threads of a process with the same domain [2]. Add erratum for signal scoping. Closes: https://github.com/landlock-lsm/go-landlock/issues/36 Fixes: 54a6e6bbf3be ("landlock: Add signal scoping") Fixes: c8994965013e ("selftests/landlock: Test signal scoping for threads") Depends-on: 26f204380a3c ("fs: Fix file_set_fowner LSM hook inconsistencies") Link: https://pkg.go.dev/kernel.org/pub/linux/libs/security/libcap/psx [1] Link: https://github.com/landlock-lsm/linux/issues/2 [2] Cc: Günther Noack Cc: Paul Moore Cc: Serge Hallyn Cc: Tahera Fahimi Cc: stable@vger.kernel.org Acked-by: Christian Brauner Link: https://lore.kernel.org/r/20250318161443.279194-6-mic@digikod.net [mic: Add extra pointer check and RCU guard, and ease backport] Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 7dd7f87e0711ed495ec3988ef42066ac9b73aa59 Author: Mickaël Salaün Date: Tue Mar 18 17:14:38 2025 +0100 landlock: Add erratum for TCP fix commit 48fce74fe209ba9e9b416d7100ccee546edc9fc6 upstream. Add erratum for the TCP socket identification fixed with commit 854277e2cc8c ("landlock: Fix non-TCP sockets restriction"). Fixes: 854277e2cc8c ("landlock: Fix non-TCP sockets restriction") Cc: Günther Noack Cc: Mikhail Ivanov Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250318161443.279194-4-mic@digikod.net Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit ea980ea4d18acaaf0b795690c9b6f9d9df6c342d Author: Mickaël Salaün Date: Tue Mar 18 17:14:37 2025 +0100 landlock: Add the errata interface commit 15383a0d63dbcd63dc7e8d9ec1bf3a0f7ebf64ac upstream. Some fixes may require user space to check if they are applied on the running kernel before using a specific feature. For instance, this applies when a restriction was previously too restrictive and is now getting relaxed (e.g. for compatibility reasons). However, non-visible changes for legitimate use (e.g. security fixes) do not require an erratum. Because fixes are backported down to a specific Landlock ABI, we need a way to avoid cherry-pick conflicts. The solution is to only update a file related to the lower ABI impacted by this issue. All the ABI files are then used to create a bitmask of fixes. The new errata interface is similar to the one used to get the supported Landlock ABI version, but it returns a bitmask instead because the order of fixes may not match the order of versions, and not all fixes may apply to all versions. The actual errata will come with dedicated commits. The description is not actually used in the code but serves as documentation. Create the landlock_abi_version symbol and use its value to check errata consistency. Update test_base's create_ruleset_checks_ordering tests and add errata tests. This commit is backportable down to the first version of Landlock. Fixes: 3532b0b4352c ("landlock: Enable user space to infer supported features") Cc: Günther Noack Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250318161443.279194-3-mic@digikod.net Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 9b0d24fa64cae26ef49dd7a2c4a3531ea03b85f9 Author: Mickaël Salaün Date: Tue Mar 18 17:14:36 2025 +0100 landlock: Move code to ease future backports commit 624f177d8f62032b4f3343c289120269645cec37 upstream. To ease backports in setup.c, let's group changes from __lsm_ro_after_init to __ro_after_init with commit f22f9aaf6c3d ("selinux: remove the runtime disable functionality"), and the landlock_lsmid addition with commit f3b8788cde61 ("LSM: Identify modules by more than name"). That will help to backport the following errata. Cc: Günther Noack Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250318161443.279194-2-mic@digikod.net Fixes: f3b8788cde61 ("LSM: Identify modules by more than name") Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 7bc5c360375d28ba5ef6298b0d53e735c81d66a1 Author: Sean Christopherson Date: Tue Apr 1 08:05:04 2025 -0700 KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses commit ef01cac401f18647d62720cf773d7bb0541827da upstream. Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where "accepting" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->check_nested_events(), and emuating the nested VM-Exit can access guest memory. The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triple_fault_event_test selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario. ============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted ----------------------------- include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm] stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20250401150504.829812-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit bbf821c35dab3211d6e4229656b4a53e04ca0c4e Author: Sean Christopherson Date: Fri Mar 14 19:41:02 2025 -0700 KVM: x86: Explicitly zero-initialize on-stack CPUID unions commit bc52ae0a708cb6fa3926d11c88e3c55e1171b4a1 upstream. Explicitly zero/empty-initialize the unions used for PMU related CPUID entries, instead of manually zeroing all fields (hopefully), or in the case of 0x80000022, relying on the compiler to clobber the uninitialized bitfields. Signed-off-by: Sean Christopherson Reviewed-by: Jim Mattson Message-ID: <20250315024102.2361628-1-seanjc@google.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 99b99032a89e67debd6742d773d8ad271b042df7 Author: Amit Machhiwal Date: Thu Feb 20 12:30:02 2025 +0530 KVM: PPC: Enable CAP_SPAPR_TCE_VFIO on pSeries KVM guests commit b4392813bbc3b05fc01a33c64d8b8c6c62c32cfa upstream. Currently on book3s-hv, the capability KVM_CAP_SPAPR_TCE_VFIO is only available for KVM Guests running on PowerNV and not for the KVM guests running on pSeries hypervisors. This prevents a pSeries L2 guest from leveraging the in-kernel acceleration for H_PUT_TCE_INDIRECT and H_STUFF_TCE hcalls that results in slow startup times for large memory guests. Support for VFIO on pSeries was restored in commit f431a8cde7f1 ("powerpc/iommu: Reimplement the iommu_table_group_ops for pSeries"), making it possible to re-enable this capability on pSeries hosts. This change enables KVM_CAP_SPAPR_TCE_VFIO for nested PAPR guests on pSeries, while maintaining the existing behavior on PowerNV. Booting an L2 guest with 128GB of memory shows an average 11% improvement in startup time. Fixes: f431a8cde7f1 ("powerpc/iommu: Reimplement the iommu_table_group_ops for pSeries") Cc: stable@vger.kernel.org Reviewed-by: Vaibhav Jain Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Amit Machhiwal Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250220070002.1478849-1-amachhiw@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit fae0a8796c4f5d31500959753e87953238eccd95 Author: Sean Christopherson Date: Fri Mar 14 19:46:23 2025 -0700 KVM: Allow building irqbypass.ko as as module when kvm.ko is a module commit 459a35111b0a890172a78d51c01b204e13a34a18 upstream. Convert HAVE_KVM_IRQ_BYPASS into a tristate so that selecting IRQ_BYPASS_MANAGER follows KVM={m,y}, i.e. doesn't force irqbypass.ko to be built-in. Note, PPC allows building KVM as a module, but selects HAVE_KVM_IRQ_BYPASS from a boolean Kconfig, i.e. KVM PPC unnecessarily forces irqbpass.ko to be built-in. But that flaw is a longstanding PPC specific issue. Fixes: 61df71ee992d ("kvm: move "select IRQ_BYPASS_MANAGER" to common code") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20250315024623.2363994-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 3bc2208c749cd8ac2315482cf5cdc722a168c742 Author: Joshua Washington Date: Wed Apr 2 00:10:37 2025 +0000 gve: handle overflow when reporting TX consumed descriptors commit 15970e1b23f5c25db88c613fddf9131de086f28e upstream. When the tx tail is less than the head (in cases of wraparound), the TX consumed descriptor statistic in DQ will be reported as UINT32_MAX - head + tail, which is incorrect. Mask the difference of head and tail according to the ring size when reporting the statistic. Cc: stable@vger.kernel.org Fixes: 2c9198356d56 ("gve: Add consumed counts to ethtool stats") Signed-off-by: Joshua Washington Signed-off-by: Harshitha Ramamurthy Reviewed-by: Michal Swiatkowski Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250402001037.2717315-1-hramamurthy@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 62024ad4c51edc4ed1a8aa78ec13557513297e62 Author: Krzysztof Kozlowski Date: Sun Apr 6 22:22:45 2025 +0200 gpio: zynq: Fix wakeup source leaks on device unbind commit c5672e310ad971d408752fce7596ed27adc6008f upstream. Device can be unbound, so driver must also release memory for the wakeup source. Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250406202245.53854-2-krzysztof.kozlowski@linaro.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 2d66517135de9ad778e28ddfb2f90a4f56476395 Author: Guixin Liu Date: Thu Mar 27 11:23:49 2025 +0800 gpio: tegra186: fix resource handling in ACPI probe path commit 8323f3a69de6f6e96bf22f32dd8e2920766050c2 upstream. When the Tegra186 GPIO controller is probed through ACPI matching, the driver emits two error messages during probing: "tegra186-gpio NVDA0508:00: invalid resource (null)" "tegra186-gpio NVDA0508:00: invalid resource (null)" Fix this by getting resource first and then do the ioremap. Fixes: 2606e7c9f5fc ("gpio: tegra186: Add ACPI support") Cc: stable@vger.kernel.org Signed-off-by: Guixin Liu Link: https://lore.kernel.org/r/20250327032349.78809-1-kanie@linux.alibaba.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit e66fb9b4e9add293fc29420519a116bdb6922999 Author: Andy Chiu Date: Wed Apr 9 00:02:57 2025 +0800 ftrace: Properly merge notrace hashes commit 04a80a34c22f4db245f553d8696d1318d1c00ece upstream. The global notrace hash should be jointly decided by the intersection of each subops's notrace hash, but not the filter hash. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20250408160258.48563-1-andybnac@gmail.com Fixes: 5fccc7552ccb ("ftrace: Add subops logic to allow one ops to manage many") Signed-off-by: Andy Chiu [ fixed removing of freeing of filter_hash ] Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 1fce9574b9d515bcb8a75379a8053e18602424e3 Author: zhoumin Date: Tue Apr 1 01:00:34 2025 +0800 ftrace: Add cond_resched() to ftrace_graph_set_hash() commit 42ea22e754ba4f2b86f8760ca27f6f71da2d982c upstream. When the kernel contains a large number of functions that can be traced, the loop in ftrace_graph_set_hash() may take a lot of time to execute. This may trigger the softlockup watchdog. Add cond_resched() within the loop to allow the kernel to remain responsive even when processing a large number of functions. This matches the cond_resched() that is used in other locations of the code that iterates over all functions that can be traced. Cc: stable@vger.kernel.org Fixes: b9b0c831bed26 ("ftrace: Convert graph filter to use hash tables") Link: https://lore.kernel.org/tencent_3E06CE338692017B5809534B9C5C03DA7705@qq.com Signed-off-by: zhoumin Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 3e467f1c74f4d6361dae4302ffca1a098f9a1e12 Author: Krzysztof Kozlowski Date: Wed Feb 26 12:29:14 2025 +0100 dt-bindings: coresight: qcom,coresight-tpdm: Fix too many 'reg' commit 1e4e454223f770748775f211455513c79cb3121e upstream. Binding listed variable number of IO addresses without defining them, however example DTS code, all in-tree DTS and Linux kernel driver mention only one address space, so drop the second to make binding precise and correctly describe the hardware. Fixes: 6c781a35133d ("dt-bindings: arm: Add CoreSight TPDM hardware") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250226112914.94361-2-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman commit 58c453801bb912c3ab0a479b0bdc154f83160a4e Author: Krzysztof Kozlowski Date: Wed Feb 26 12:29:13 2025 +0100 dt-bindings: coresight: qcom,coresight-tpda: Fix too many 'reg' commit d72deaf05ac18e421d7e52a6be8966fd6ee185f4 upstream. Binding listed variable number of IO addresses without defining them, however example DTS code, all in-tree DTS and Linux kernel driver mention only one address space, so drop the second to make binding precise and correctly describe the hardware. Fixes: a8fbe1442c2b ("dt-bindings: arm: Adds CoreSight TPDA hardware definitions") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250226112914.94361-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman commit 74f01c2ca8029d71f817673a72c70b70c98e2a66 Author: Mikulas Patocka Date: Fri Mar 28 16:17:45 2025 +0100 dm-verity: fix prefetch-vs-suspend race commit 2de510fccbca3d1906b55f4be5f1de83fa2424ef upstream. There's a possible race condition in dm-verity - the prefetch work item may race with suspend and it is possible that prefetch continues to run while the device is suspended. Fix this by calling flush_workqueue and dm_bufio_client_reset in the postsuspend hook. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit dd91458a8443d1bbca6ff3ac4eae2af9a88ef12e Author: Jo Van Bulck Date: Fri Mar 28 16:04:47 2025 +0100 dm-integrity: fix non-constant-time tag verification commit 8bde1033f9cfc1c08628255cc434c6cf39c9d9ba upstream. When using dm-integrity in standalone mode with a keyed hmac algorithm, integrity tags are calculated and verified internally. Using plain memcmp to compare the stored and computed tags may leak the position of the first byte mismatch through side-channel analysis, allowing to brute-force expected tags in linear time (e.g., by counting single-stepping interrupts in confidential virtual machine environments). Co-developed-by: Luca Wilke Signed-off-by: Luca Wilke Signed-off-by: Jo Van Bulck Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ba42f98f092b0a9d275a3d65635457262d8333d1 Author: Mikulas Patocka Date: Mon Feb 10 16:14:22 2025 +0100 dm-integrity: set ti->error on memory allocation failure commit 00204ae3d6712ee053353920e3ce2b00c35ef75b upstream. The dm-integrity target didn't set the error string when memory allocation failed. This patch fixes it. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a1a4fdc33d9cf4953b9daa22e3b6abb4ed1bd85e Author: Mikulas Patocka Date: Fri Mar 28 16:19:07 2025 +0100 dm-ebs: fix prefetch-vs-suspend race commit 9c565428788fb9b49066f94ab7b10efc686a0a4c upstream. There's a possible race condition in dm-ebs - dm bufio prefetch may be in progress while the device is suspended. Fix this by calling dm_bufio_client_reset in the postsuspend hook. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 08deafddfcb0380787c7239e57d9b68dd2d29afa Author: Alexander Aring Date: Fri Feb 28 17:48:51 2025 -0500 dlm: fix error if active rsb is not hashed commit a3672304abf2a847ac0c54c84842c64c5bfba279 upstream. If an active rsb is not hashed anymore and this could occur because we releases and acquired locks we need to signal the followed code that the lookup failed. Since the lookup was successful, but it isn't part of the rsb hash anymore we need to signal it by setting error to -EBADR as dlm_search_rsb_tree() does it. Cc: stable@vger.kernel.org Fixes: 5be323b0c64d ("dlm: move dlm_search_rsb_tree() out of lock") Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit b77f8a17ef6f5b578ab6c83ca02d0d07505b93d5 Author: Alexander Aring Date: Fri Feb 28 17:48:50 2025 -0500 dlm: fix error if inactive rsb is not hashed commit 94e6e889a786dd16542fc8f2a45405fa13e3bbb5 upstream. If an inactive rsb is not hashed anymore and this could occur because we releases and acquired locks we need to signal the followed code that the lookup failed. Since the lookup was successful, but it isn't part of the rsb hash anymore we need to signal it by setting error to -EBADR as dlm_search_rsb_tree() does it. Cc: stable@vger.kernel.org Fixes: 01fdeca1cc2d ("dlm: use rcu to avoid an extra rsb struct lookup") Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit eaa7014aecb5e46ff94c3c8395b57f78bcf22baf Author: Dionna Glaze Date: Sat Mar 8 12:10:28 2025 +1100 crypto: ccp - Fix uAPI definitions of PSP errors commit b949f55644a6d1645c0a71f78afabf12aec7c33b upstream. Additions to the error enum after explicit 0x27 setting for SEV_RET_INVALID_KEY leads to incorrect value assignments. Use explicit values to match the manufacturer specifications more clearly. Fixes: 3a45dc2b419e ("crypto: ccp: Define the SEV-SNP commands") CC: stable@vger.kernel.org Signed-off-by: Dionna Glaze Reviewed-by: Tom Lendacky Signed-off-by: Alexey Kardashevskiy Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 5116b340cf8858e645338edbd2bae641b6ac2c88 Author: Tom Lendacky Date: Fri Jan 17 17:05:47 2025 -0600 crypto: ccp - Fix check for the primary ASP device commit 07bb097b92b987db518e72525b515d77904e966e upstream. Currently, the ASP primary device check does not have support for PCI domains, and, as a result, when the system is configured with PCI domains (PCI segments) the wrong device can be selected as primary. This results in commands submitted to the device timing out and failing. The device check also relies on specific device and function assignments that may not hold in the future. Fix the primary ASP device check to include support for PCI domains and to perform proper checking of the Bus/Device/Function positions. Fixes: 2a6170dfe755 ("crypto: ccp: Add Platform Security Processor (PSP) device support") Cc: stable@vger.kernel.org Signed-off-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 1f9648e2460ba2c4e2ed71c83f210b4c96ecd045 Author: Taniya Das Date: Fri Feb 14 09:56:59 2025 +0530 clk: qcom: gdsc: Set retain_ff before moving to HW CTRL commit 25708f73ff171bb4171950c9f4be5aa8504b8459 upstream. Enable the retain_ff_enable bit of GDSCR only if the GDSC is already ON. Once the GDSCR moves to HW control, SW no longer can determine the state of the GDSCR and setting the retain_ff bit could destroy all the register contents we intended to save. Therefore, move the retain_ff configuration before switching the GDSC to HW trigger mode. Cc: stable@vger.kernel.org Fixes: 173722995cdb ("clk: qcom: gdsc: Add support to enable retention of GSDCR") Signed-off-by: Taniya Das Reviewed-by: Imran Shaik Tested-by: Imran Shaik # on QCS8300 Link: https://lore.kernel.org/r/20250214-gdsc_fixes-v1-1-73e56d68a80f@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 4d6fb2a43f0d7a0e04a85cfc69907836c2dd018d Author: Bryan O'Donoghue Date: Fri Jan 17 13:54:08 2025 +0000 clk: qcom: gdsc: Capture pm_genpd_add_subdomain result code commit 65a733464553ea192797b889d1533a1a37216f32 upstream. Adding a new clause to this if/else I noticed the existing usage of pm_genpd_add_subdomain() wasn't capturing and returning the result code. pm_genpd_add_subdomain() returns an int and can fail. Capture that result code and throw it up the call stack if something goes wrong. Fixes: 1b771839de05 ("clk: qcom: gdsc: enable optional power domain support") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20250117-b4-linux-next-24-11-18-clock-multiple-power-domains-v10-2-13f2bb656dad@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 12ef07c4bfe4bc424216eb8ef4c93c3239972458 Author: Bryan O'Donoghue Date: Fri Jan 17 13:54:07 2025 +0000 clk: qcom: gdsc: Release pm subdomains in reverse add order commit 0e6dfde439df0bb977cddd3cf7fff150a084a9bf upstream. gdsc_unregister() should release subdomains in the reverse order to the order in which those subdomains were added. I've made this patch a standalone patch because it facilitates a subsequent fix to stable. Fixes: 1b771839de05 ("clk: qcom: gdsc: enable optional power domain support") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20250117-b4-linux-next-24-11-18-clock-multiple-power-domains-v10-1-13f2bb656dad@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 809e83a5758edbffd3579fee320f59bd221a71db Author: Ajit Pandey Date: Tue Jan 28 17:08:35 2025 +0530 clk: qcom: clk-branch: Fix invert halt status bit check for votable clocks commit 5eac348182d2b5ed1066459abedb7bc6b5466f81 upstream. BRANCH_HALT_ENABLE and BRANCH_HALT_ENABLE_VOTED flags are used to check halt status of branch clocks, which have an inverted logic for the halt bit in CBCR register. However, the current logic in the _check_halt() method only compares the BRANCH_HALT_ENABLE flags, ignoring the votable branch clocks. Update the logic to correctly handle the invert logic for votable clocks using the BRANCH_HALT_ENABLE_VOTED flags. Fixes: 9092d1083a62 ("clk: qcom: branch: Extend the invert logic for branch2 clocks") Cc: stable@vger.kernel.org Signed-off-by: Ajit Pandey Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250128-push_fix-v1-1-fafec6747881@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 56c29847bc4ca651ebeac0671f1a8519a47506e8 Author: Lad Prabhakar Date: Mon Jan 27 17:31:59 2025 +0000 clk: renesas: r9a07g043: Fix HP clock source for RZ/Five commit 7f22a298d926664b51fcfe2f8ea5feb7f8b79952 upstream. According to the Rev.1.20 hardware manual for the RZ/Five SoC, the clock source for HP is derived from PLL6 divided by 2. Correct the implementation by configuring HP as a fixed clock source instead of a MUX. The `CPG_PL6_ETH_SSEL' register, which is available on the RZ/G2UL SoC, is not present on the RZ/Five SoC, necessitating this change. Fixes: 95d48d270305ad2c ("clk: renesas: r9a07g043: Add support for RZ/Five SoC") Cc: stable@vger.kernel.org Reported-by: Hien Huynh Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250127173159.34572-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit 4ed194d9bbf7260b409071937ca8a6a4b473e7c9 Author: Pali Rohár Date: Sat Apr 5 19:51:07 2025 +0200 cifs: Ensure that all non-client-specific reparse points are processed by the server commit 6f8a394aa952257575910d57cf0a63627fa949a2 upstream. Fix regression in mounts to e.g. onedrive shares. Generally, reparse points are processed by the SMB server during the SMB OPEN request, but there are few reparse points which do not have OPEN-like meaning for the SMB server and has to be processed by the SMB client. Those are symlinks and special files (fifo, socket, block, char). For Linux SMB client, it is required to process also name surrogate reparse points as they represent another entity on the SMB server system. Linux client will mark them as separate mount points. Examples of name surrogate reparse points are NTFS junction points (e.g. created by the "mklink" tool on Windows servers). So after processing the name surrogate reparse points, clear the -EOPNOTSUPP error code returned from the parse_reparse_point() to let SMB server to process reparse points. And remove printing misleading error message "unhandled reparse tag:" as reparse points are handled by SMB server and hence unhandled fact is normal operation. Fixes: cad3fc0a4c8c ("cifs: Throw -EOPNOTSUPP error on unsupported reparse point type from parse_reparse_point()") Fixes: b587fd128660 ("cifs: Treat unhandled directory name surrogate reparse points as mount directory nodes") Cc: stable@vger.kernel.org Reported-by: Junwen Sun Tested-by: Junwen Sun Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 2a240405978d7a741269d1bf68aee22f3d54e2ba Author: Roman Smirnov Date: Mon Mar 31 11:22:49 2025 +0300 cifs: fix integer overflow in match_server() commit 2510859475d7f46ed7940db0853f3342bf1b65ee upstream. The echo_interval is not limited in any way during mounting, which makes it possible to write a large number to it. This can cause an overflow when multiplying ctx->echo_interval by HZ in match_server(). Add constraints for echo_interval to smb3_fs_context_parse_param(). Found by Linux Verification Center (linuxtesting.org) with Svace. Fixes: adfeb3e00e8e1 ("cifs: Make echo interval tunable") Cc: stable@vger.kernel.org Signed-off-by: Roman Smirnov Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit e0717385f5c51e290c2cd2ad4699a778316b5132 Author: Alexandra Diupina Date: Wed Mar 19 17:28:58 2025 +0300 cifs: avoid NULL pointer dereference in dbg call commit b4885bd5935bb26f0a414ad55679a372e53f9b9b upstream. cifs_server_dbg() implies server to be non-NULL so move call under condition to avoid NULL pointer dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: e79b0332ae06 ("cifs: ignore cached share root handle closing errors") Cc: stable@vger.kernel.org Signed-off-by: Alexandra Diupina Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 2eb6e5e0944c7cbdff862bb80d87f3de41d70c5a Author: Aman Date: Thu Mar 6 17:46:43 2025 +0000 CIFS: Propagate min offload along with other parameters from primary to secondary channels. commit 1821e90be08e7d4a54cd167dd818d80d06e064e9 upstream. In a multichannel setup, it was observed that a few fields were not being copied over to the secondary channels, which impacted performance in cases where these options were relevant but not properly synchronized. To address this, this patch introduces copying the following parameters from the primary channel to the secondary channels: - min_offload - compression.requested - dfs_conn - ignore_signature - leaf_fullpath - noblockcnt - retrans - sign By copying these parameters, we ensure consistency across channels and prevent performance degradation due to missing or outdated settings. Cc: stable@vger.kernel.org Signed-off-by: Aman Reviewed-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 63d71ae01092249269a7248ea777246032a4a066 Author: Trevor Woerner Date: Fri Feb 7 12:50:47 2025 -0500 thermal/drivers/rockchip: Add missing rk3328 mapping entry commit ee022e5cae052e0c67ca7c5fec0f2e7bc897c70e upstream. The mapping table for the rk3328 is missing the entry for -25C which is found in the TRM section 9.5.2 "Temperature-to-code mapping". NOTE: the kernel uses the tsadc_q_sel=1'b1 mode which is defined as: 4096-. Whereas the table in the TRM gives the code "3774" for -25C, the kernel uses 4096-3774=322. [Dragan Simic] : "After going through the RK3308 and RK3328 TRMs, as well as through the downstream kernel code, it seems we may have some troubles at our hands. Let me explain, please. To sum it up, part 1 of the RK3308 TRM v1.1 says on page 538 that the equation for the output when tsadc_q_sel equals 1 is (4096 - tsadc_q), while part 1 of the RK3328 TRM v1.2 says that the output equation is (1024 - tsadc_q) in that case. The downstream kernel code, however, treats the RK3308 and RK3328 tables and their values as being the same. It even mentions 1024 as the "offset" value in a comment block for the rk_tsadcv3_control() function, just like the upstream code does, which is obviously wrong "offset" value when correlated with the table on page 544 of part 1 of the RK3308 TRM v1.1. With all this in mind, it's obvious that more work is needed to make it clear where's the actual mistake (it could be that the TRM is wrong), which I'll volunteer for as part of the SoC binning project. In the meantime, this patch looks fine as-is to me, by offering what's a clear improvement to the current state of the upstream code" Link: https://opensource.rock-chips.com/images/9/97/Rockchip_RK3328TRM_V1.1-Part1-20170321.pdf Cc: stable@vger.kernel.org Fixes: eda519d5f73e ("thermal: rockchip: Support the RK3328 SOC in thermal driver") Signed-off-by: Trevor Woerner Reviewed-by: Dragan Simic Link: https://lore.kernel.org/r/20250207175048.35959-1-twoerner@gmail.com Signed-off-by: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman commit 474b3194c8ffc1831904a405c4d60441a31c0245 Author: Steven Rostedt Date: Mon Apr 7 15:41:39 2025 -0400 tracing: Do not add length to print format in synthetic events commit e1a453a57bc76be678bd746f84e3d73f378a9511 upstream. The following causes a vsnprintf fault: # echo 's:wake_lat char[] wakee; u64 delta;' >> /sys/kernel/tracing/dynamic_events # echo 'hist:keys=pid:ts=common_timestamp.usecs if !(common_flags & 0x18)' > /sys/kernel/tracing/events/sched/sched_waking/trigger # echo 'hist:keys=next_pid:delta=common_timestamp.usecs-$ts:onmatch(sched.sched_waking).trace(wake_lat,next_comm,$delta)' > /sys/kernel/tracing/events/sched/sched_switch/trigger Because the synthetic event's "wakee" field is created as a dynamic string (even though the string copied is not). The print format to print the dynamic string changed from "%*s" to "%s" because another location (__set_synth_event_print_fmt()) exported this to user space, and user space did not need that. But it is still used in print_synth_event(), and the output looks like: -0 [001] d..5. 193.428167: wake_lat: wakee=(efault)sshd-sessiondelta=155 sshd-session-879 [001] d..5. 193.811080: wake_lat: wakee=(efault)kworker/u34:5delta=58 -0 [002] d..5. 193.811198: wake_lat: wakee=(efault)bashdelta=91 bash-880 [002] d..5. 193.811371: wake_lat: wakee=(efault)kworker/u35:2delta=21 -0 [001] d..5. 193.811516: wake_lat: wakee=(efault)sshd-sessiondelta=129 sshd-session-879 [001] d..5. 193.967576: wake_lat: wakee=(efault)kworker/u34:5delta=50 The length isn't needed as the string is always nul terminated. Just print the string and not add the length (which was hard coded to the max string length anyway). Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Cc: Tom Zanussi Cc: Douglas Raillard Acked-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/20250407154139.69955768@gandalf.local.home Fixes: 4d38328eb442d ("tracing: Fix synth event printk format for str fields"); Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 868df4eb784c3ccc7e4340a9ea993cbbedca167e Author: Masami Hiramatsu (Google) Date: Mon Mar 31 23:05:07 2025 +0900 tracing: fprobe events: Fix possible UAF on modules commit dd941507a9486252d6fcf11814387666792020f3 upstream. Commit ac91052f0ae5 ("tracing: tprobe-events: Fix leakage of module refcount") moved try_module_get() from __find_tracepoint_module_cb() to find_tracepoint() caller, but that introduced a possible UAF because the module can be unloaded before try_module_get(). In this case, the module object should be freed too. Thus, try_module_get() does not only fail but may access to the freed object. To avoid that, try_module_get() in __find_tracepoint_module_cb() again. Link: https://lore.kernel.org/all/174342990779.781946.9138388479067729366.stgit@devnote2/ Fixes: ac91052f0ae5 ("tracing: tprobe-events: Fix leakage of module refcount") Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit a7fda1fd6d6c6e39054bc3d40d1c12f8fecba69c Author: Roger Pau Monne Date: Mon Apr 7 10:28:37 2025 +0200 x86/xen: fix balloon target initialization for PVH dom0 commit 87af633689ce16ddb166c80f32b120e50b1295de upstream. PVH dom0 re-uses logic from PV dom0, in which RAM ranges not assigned to dom0 are re-used as scratch memory to map foreign and grant pages. Such logic relies on reporting those unpopulated ranges as RAM to Linux, and mark them as reserved. This way Linux creates the underlying page structures required for metadata management. Such approach works fine on PV because the initial balloon target is calculated using specific Xen data, that doesn't take into account the memory type changes described above. However on HVM and PVH the initial balloon target is calculated using get_num_physpages(), and that function does take into account the unpopulated RAM regions used as scratch space for remote domain mappings. This leads to PVH dom0 having an incorrect initial balloon target, which causes malfunction (excessive memory freeing) of the balloon driver if the dom0 memory target is later adjusted from the toolstack. Fix this by using xen_released_pages to account for any pages that are part of the memory map, but are already unpopulated when the balloon driver is initialized. This accounts for any regions used for scratch remote mappings. Note on x86 xen_released_pages definition is moved to enlighten.c so it's uniformly available for all Xen-enabled builds. Take the opportunity to unify PV with PVH/HVM guests regarding the usage of get_num_physpages(), as that avoids having to add different logic for PV vs PVH in both balloon_add_regions() and arch_xen_unpopulated_init(). Much like a6aa4eb994ee, the code in this changeset should have been part of 38620fc4e893. Fixes: a6aa4eb994ee ('xen/x86: add extra pages to unpopulated-alloc if available') Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross Message-ID: <20250407082838.65495-1-roger.pau@citrix.com> Signed-off-by: Greg Kroah-Hartman commit 9e7c37fadb3be1fc33073fcf10aa96d166caa697 Author: Ricardo Cañuelo Navarro Date: Fri Apr 4 16:53:21 2025 +0200 sctp: detect and prevent references to a freed transport in sendmsg commit f1a69a940de58b16e8249dff26f74c8cc59b32be upstream. sctp_sendmsg() re-uses associations and transports when possible by doing a lookup based on the socket endpoint and the message destination address, and then sctp_sendmsg_to_asoc() sets the selected transport in all the message chunks to be sent. There's a possible race condition if another thread triggers the removal of that selected transport, for instance, by explicitly unbinding an address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have been set up and before the message is sent. This can happen if the send buffer is full, during the period when the sender thread temporarily releases the socket lock in sctp_wait_for_sndbuf(). This causes the access to the transport data in sctp_outq_select_transport(), when the association outqueue is flushed, to result in a use-after-free read. This change avoids this scenario by having sctp_transport_free() signal the freeing of the transport, tagging it as "dead". In order to do this, the patch restores the "dead" bit in struct sctp_transport, which was removed in commit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport"). Then, in the scenario where the sender thread has released the socket lock in sctp_wait_for_sndbuf(), the bit is checked again after re-acquiring the socket lock to detect the deletion. This is done while holding a reference to the transport to prevent it from being freed in the process. If the transport was deleted while the socket lock was relinquished, sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the send. The bug was found by a private syzbot instance (see the error report [1] and the C reproducer that triggers it [2]). Link: https://people.igalia.com/rcn/kernel_logs/20250402__KASAN_slab-use-after-free_Read_in_sctp_outq_select_transport.txt [1] Link: https://people.igalia.com/rcn/kernel_logs/20250402__KASAN_slab-use-after-free_Read_in_sctp_outq_select_transport__repro.c [2] Cc: stable@vger.kernel.org Fixes: df132eff4638 ("sctp: clear the transport of some out_chunk_list chunks in sctp_assoc_rm_peer") Suggested-by: Xin Long Signed-off-by: Ricardo Cañuelo Navarro Acked-by: Xin Long Link: https://patch.msgid.link/20250404-kasan_slab-use-after-free_read_in_sctp_outq_select_transport__20250404-v1-1-5ce4a0b78ef2@igalia.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 65b259e3e06dc3c59a3d15a717d06c9d6b66e4a7 Author: Jinjiang Tu Date: Tue Mar 18 16:39:38 2025 +0800 mm/hwpoison: introduce folio_contain_hwpoisoned_page() helper commit 5f5ee52d4f58605330b09851273d6e56aaadd29e upstream. Patch series "mm/vmscan: don't try to reclaim hwpoison folio". Fix a bug during memory reclaim if folio is hwpoisoned. This patch (of 2): Introduce helper folio_contain_hwpoisoned_page() to check if the entire folio is hwpoisoned or it contains hwpoisoned pages. Link: https://lkml.kernel.org/r/20250318083939.987651-1-tujinjiang@huawei.com Link: https://lkml.kernel.org/r/20250318083939.987651-2-tujinjiang@huawei.com Signed-off-by: Jinjiang Tu Acked-by: Miaohe Lin Cc: David Hildenbrand Cc: Kefeng Wang Cc: Nanyong Sun Cc: Naoya Horiguchi Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 1fd89407d7cb5d26a4029caaa6543c1c502e2e18 Author: Marc Herbert Date: Wed Mar 19 06:00:30 2025 +0000 mm/hugetlb: move hugetlb_sysctl_init() to the __init section commit 1ca77ff1837249701053a7fcbdedabc41f4ae67c upstream. hugetlb_sysctl_init() is only invoked once by an __init function and is merely a wrapper around another __init function so there is not reason to keep it. Fixes the following warning when toning down some GCC inline options: WARNING: modpost: vmlinux: section mismatch in reference: hugetlb_sysctl_init+0x1b (section: .text) -> __register_sysctl_init (section: .init.text) Link: https://lkml.kernel.org/r/20250319060041.2737320-1-marc.herbert@linux.intel.com Signed-off-by: Marc Herbert Reviewed-by: Anshuman Khandual Reviewed-by: Muchun Song Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 73d17d48df6cd78f1ee5d15932dd09a1a79b85fa Author: Shuai Xue Date: Wed Mar 12 19:28:51 2025 +0800 mm/hwpoison: do not send SIGBUS to processes with recovered clean pages commit aaf99ac2ceb7c974f758a635723eeaf48596388e upstream. When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed. - Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1] Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR. Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to #CMCI. Just to add to the confusion, Linux does take an action (in uc_decode_notifier()) to try to offline the page despite the UC*NA* signature name. - Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1] Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a "real" read and a speculative read. So it will do CMCI/UCNA if an error is found in any read. Thus: 1) Core is clever and thinks address A is needed soon, issues a speculative read. 2) Core finds it is going to use address A soon after sending the read request 3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A. Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison). - Why user process is killed for instr case Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not recovered"") tries to fix noise message "Memory error not recovered" and skips duplicate SIGBUSs due to the race. But it also introduced a bug that kill_accessing_process() return -EHWPOISON for instr case, as result, kill_me_maybe() send a SIGBUS to user process. If the CMCI wins that race, the page is marked poisoned when uc_decode_notifier() calls memory_failure(). For dirty pages, memory_failure() invokes try_to_unmap() with the TTU_HWPOISON flag, converting the PTE to a hwpoison entry. As a result, kill_accessing_process(): - call walk_page_range() and return 1 regardless of whether try_to_unmap() succeeds or fails, - call kill_proc() to make sure a SIGBUS is sent - return -EHWPOISON to indicate that SIGBUS is already sent to the process and kill_me_maybe() doesn't have to send it again. However, for clean pages, the TTU_HWPOISON flag is cleared, leaving the PTE unchanged and not converted to a hwpoison entry. Conversely, for clean pages where PTE entries are not marked as hwpoison, kill_accessing_process() returns -EFAULT, causing kill_me_maybe() to send a SIGBUS. Console log looks like this: Memory failure: 0x827ca68: corrupted page was clean: dropped without side effects Memory failure: 0x827ca68: recovery action for clean LRU page: Recovered Memory failure: 0x827ca68: already hardware poisoned mce: Memory error not recovered To fix it, return 0 for "corrupted page was clean", preventing an unnecessary SIGBUS to user process. [1] https://lore.kernel.org/lkml/20250217063335.22257-1-xueshuai@linux.alibaba.com/T/#mba94f1305b3009dd340ce4114d3221fe810d1871 Link: https://lkml.kernel.org/r/20250312112852.82415-3-xueshuai@linux.alibaba.com Fixes: 046545a661af ("mm/hwpoison: fix error page recovered but reported "not recovered"") Signed-off-by: Shuai Xue Tested-by: Tony Luck Acked-by: Miaohe Lin Cc: Baolin Wang Cc: Borislav Betkov Cc: Catalin Marinas Cc: Dave Hansen Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jane Chu Cc: Jarkko Sakkinen Cc: Jonathan Cameron Cc: Josh Poimboeuf Cc: Naoya Horiguchi Cc: Peter Zijlstra Cc: Ruidong Tian Cc: Thomas Gleinxer Cc: Yazen Ghannam Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 14936034de92ad3dd57d03379edda12514aa0ab2 Author: Peter Xu Date: Wed Mar 12 10:51:31 2025 -0400 mm/userfaultfd: fix release hang over concurrent GUP commit fe4cdc2c4e248f48de23bc778870fd71e772a274 upstream. This patch should fix a possible userfaultfd release() hang during concurrent GUP. This problem was initially reported by Dimitris Siakavaras in July 2023 [1] in a firecracker use case. Firecracker has a separate process handling page faults remotely, and when the process releases the userfaultfd it can race with a concurrent GUP from KVM trying to fault in a guest page during the secondary MMU page fault process. A similar problem was reported recently again by Jinjiang Tu in March 2025 [2], even though the race happened this time with a mlockall() operation, which does GUP in a similar fashion. In 2017, commit 656710a60e36 ("userfaultfd: non-cooperative: closing the uffd without triggering SIGBUS") was trying to fix this issue. AFAIU, that fixes well the fault paths but may not work yet for GUP. In GUP, the issue is NOPAGE will be almost treated the same as "page fault resolved" in faultin_page(), then the GUP will follow page again, seeing page missing, and it'll keep going into a live lock situation as reported. This change makes core mm return RETRY instead of NOPAGE for both the GUP and fault paths, proactively releasing the mmap read lock. This should guarantee the other release thread make progress on taking the write lock and avoid the live lock even for GUP. When at it, rearrange the comments to make sure it's uptodate. [1] https://lore.kernel.org/r/79375b71-db2e-3e66-346b-254c90d915e2@cslab.ece.ntua.gr [2] https://lore.kernel.org/r/20250307072133.3522652-1-tujinjiang@huawei.com Link: https://lkml.kernel.org/r/20250312145131.1143062-1-peterx@redhat.com Signed-off-by: Peter Xu Cc: Andrea Arcangeli Cc: Mike Rapoport (IBM) Cc: Axel Rasmussen Cc: Jinjiang Tu Cc: Dimitris Siakavaras Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cc98577f911738871ceb08c334d3062a7defd168 Author: Mathieu Desnoyers Date: Wed Mar 12 10:10:13 2025 -0400 mm: add missing release barrier on PGDAT_RECLAIM_LOCKED unlock commit c0ebbb3841e07c4493e6fe351698806b09a87a37 upstream. The PGDAT_RECLAIM_LOCKED bit is used to provide mutual exclusion of node reclaim for struct pglist_data using a single bit. It is "locked" with a test_and_set_bit (similarly to a try lock) which provides full ordering with respect to loads and stores done within __node_reclaim(). It is "unlocked" with clear_bit(), which does not provide any ordering with respect to loads and stores done before clearing the bit. The lack of clear_bit() memory ordering with respect to stores within __node_reclaim() can cause a subsequent CPU to fail to observe stores from a prior node reclaim. This is not an issue in practice on TSO (e.g. x86), but it is an issue on weakly-ordered architectures (e.g. arm64). Fix this by using clear_bit_unlock rather than clear_bit to clear PGDAT_RECLAIM_LOCKED with a release memory ordering semantic. This provides stronger memory ordering (release rather than relaxed). Link: https://lkml.kernel.org/r/20250312141014.129725-1-mathieu.desnoyers@efficios.com Fixes: d773ed6b856a ("mm: test and set zone reclaim lock before starting reclaim") Signed-off-by: Mathieu Desnoyers Cc: Lorenzo Stoakes Cc: Matthew Wilcox Cc: Alan Stern Cc: Andrea Parri Cc: Will Deacon Cc: Peter Zijlstra Cc: Boqun Feng Cc: Nicholas Piggin Cc: David Howells Cc: Jade Alglave Cc: Luc Maranget Cc: "Paul E. McKenney" Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2532df0a9b747c982d5b12201e368027aaa72744 Author: Lorenzo Stoakes Date: Mon Mar 10 20:50:34 2025 +0000 mm/mremap: correctly handle partial mremap() of VMA starting at 0 commit 937582ee8e8d227c30ec147629a0179131feaa80 upstream. Patch series "refactor mremap and fix bug", v3. The existing mremap() logic has grown organically over a very long period of time, resulting in code that is in many parts, very difficult to follow and full of subtleties and sources of confusion. In addition, it is difficult to thread state through the operation correctly, as function arguments have expanded, some parameters are expected to be temporarily altered during the operation, others are intended to remain static and some can be overridden. This series completely refactors the mremap implementation, sensibly separating functions, adding comments to explain the more subtle aspects of the implementation and making use of small structs to thread state through everything. The reason for doing so is to lay the groundwork for planned future changes to the mremap logic, changes which require the ability to easily pass around state. Additionally, it would be unhelpful to add yet more logic to code that is already difficult to follow without first refactoring it like this. The first patch in this series additionally fixes a bug when a VMA with start address zero is partially remapped. Tested on real hardware under heavy workload and all self tests are passing. This patch (of 3): Consider the case of a partial mremap() (that results in a VMA split) of an accountable VMA (i.e. which has the VM_ACCOUNT flag set) whose start address is zero, with the MREMAP_MAYMOVE flag specified and a scenario where a move does in fact occur: addr end | | v v |-------------| | vma | |-------------| 0 This move is affected by unmapping the range [addr, end). In order to prevent an incorrect decrement of accounted memory which has already been determined, the mremap() code in move_vma() clears VM_ACCOUNT from the VMA prior to doing so, before reestablishing it in each of the VMAs post-split: addr end | | v v |---| |---| | A | | B | |---| |---| Commit 6b73cff239e5 ("mm: change munmap splitting order and move_vma()") changed this logic such as to determine whether there is a need to do so by establishing account_start and account_end and, in the instance where such an operation is required, assigning them to vma->vm_start and vma->vm_end. Later the code checks if the operation is required for 'A' referenced above thusly: if (account_start) { ... } However, if the VMA described above has vma->vm_start == 0, which is now assigned to account_start, this branch will not be executed. As a result, the VMA 'A' above will remain stripped of its VM_ACCOUNT flag, incorrectly. The fix is to simply convert these variables to booleans and set them as required. Link: https://lkml.kernel.org/r/cover.1741639347.git.lorenzo.stoakes@oracle.com Link: https://lkml.kernel.org/r/dc55cb6db25d97c3d9e460de4986a323fa959676.1741639347.git.lorenzo.stoakes@oracle.com Fixes: 6b73cff239e5 ("mm: change munmap splitting order and move_vma()") Signed-off-by: Lorenzo Stoakes Reviewed-by: Harry Yoo Reviewed-by: Liam R. Howlett Reviewed-by: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6dd8d9440fd31aca292c6e1dc2ec567c61d93bdb Author: Ryan Roberts Date: Mon Mar 3 14:15:35 2025 +0000 mm: fix lazy mmu docs and usage commit 691ee97e1a9de0cdb3efb893c1f180e3f4a35e32 upstream. Patch series "Fix lazy mmu mode", v2. I'm planning to implement lazy mmu mode for arm64 to optimize vmalloc. As part of that, I will extend lazy mmu mode to cover kernel mappings in vmalloc table walkers. While lazy mmu mode is already used for kernel mappings in a few places, this will extend it's use significantly. Having reviewed the existing lazy mmu implementations in powerpc, sparc and x86, it looks like there are a bunch of bugs, some of which may be more likely to trigger once I extend the use of lazy mmu. So this series attempts to clarify the requirements and fix all the bugs in advance of that series. See patch #1 commit log for all the details. This patch (of 5): The docs, implementations and use of arch_[enter|leave]_lazy_mmu_mode() is a bit of a mess (to put it politely). There are a number of issues related to nesting of lazy mmu regions and confusion over whether the task, when in a lazy mmu region, is preemptible or not. Fix all the issues relating to the core-mm. Follow up commits will fix the arch-specific implementations. 3 arches implement lazy mmu; powerpc, sparc and x86. When arch_[enter|leave]_lazy_mmu_mode() was first introduced by commit 6606c3e0da53 ("[PATCH] paravirt: lazy mmu mode hooks.patch"), it was expected that lazy mmu regions would never nest and that the appropriate page table lock(s) would be held while in the region, thus ensuring the region is non-preemptible. Additionally lazy mmu regions were only used during manipulation of user mappings. Commit 38e0edb15bd0 ("mm/apply_to_range: call pte function with lazy updates") started invoking the lazy mmu mode in apply_to_pte_range(), which is used for both user and kernel mappings. For kernel mappings the region is no longer protected by any lock so there is no longer any guarantee about non-preemptibility. Additionally, for RT configs, the holding the PTL only implies no CPU migration, it doesn't prevent preemption. Commit bcc6cc832573 ("mm: add default definition of set_ptes()") added arch_[enter|leave]_lazy_mmu_mode() to the default implementation of set_ptes(), used by x86. So after this commit, lazy mmu regions can be nested. Additionally commit 1a10a44dfc1d ("sparc64: implement the new page table range API") and commit 9fee28baa601 ("powerpc: implement the new page table range API") did the same for the sparc and powerpc set_ptes() overrides. powerpc couldn't deal with preemption so avoids it in commit b9ef323ea168 ("powerpc/64s: Disable preemption in hash lazy mmu mode"), which explicitly disables preemption for the whole region in its implementation. x86 can support preemption (or at least it could until it tried to add support nesting; more on this below). Sparc looks to be totally broken in the face of preemption, as far as I can tell. powerpc can't deal with nesting, so avoids it in commit 47b8def9358c ("powerpc/mm: Avoid calling arch_enter/leave_lazy_mmu() in set_ptes"), which removes the lazy mmu calls from its implementation of set_ptes(). x86 attempted to support nesting in commit 49147beb0ccb ("x86/xen: allow nesting of same lazy mode") but as far as I can tell, this breaks its support for preemption. In short, it's all a mess; the semantics for arch_[enter|leave]_lazy_mmu_mode() are not clearly defined and as a result the implementations all have different expectations, sticking plasters and bugs. arm64 is aiming to start using these hooks, so let's clean everything up before adding an arm64 implementation. Update the documentation to state that lazy mmu regions can never be nested, must not be called in interrupt context and preemption may or may not be enabled for the duration of the region. And fix the generic implementation of set_ptes() to avoid nesting. arch-specific fixes to conform to the new spec will proceed this one. These issues were spotted by code review and I have no evidence of issues being reported in the wild. Link: https://lkml.kernel.org/r/20250303141542.3371656-1-ryan.roberts@arm.com Link: https://lkml.kernel.org/r/20250303141542.3371656-2-ryan.roberts@arm.com Fixes: bcc6cc832573 ("mm: add default definition of set_ptes()") Signed-off-by: Ryan Roberts Acked-by: David Hildenbrand Acked-by: Juergen Gross Cc: Andreas Larsson Cc: Borislav Betkov Cc: Boris Ostrovsky Cc: Catalin Marinas Cc: Dave Hansen Cc: David S. Miller Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Juegren Gross Cc: Matthew Wilcow (Oracle) Cc: Thomas Gleinxer Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 83b6b5061ebd9d688922682dcca9c1b3f30fa58a Author: Jane Chu Date: Mon Feb 24 14:14:45 2025 -0700 mm: make page_mapped_in_vma() hugetlb walk aware commit 442b1eca223b4860cc85ef970ae602d125aec5a4 upstream. When a process consumes a UE in a page, the memory failure handler attempts to collect information for a potential SIGBUS. If the page is an anonymous page, page_mapped_in_vma(page, vma) is invoked in order to 1. retrieve the vaddr from the process' address space, 2. verify that the vaddr is indeed mapped to the poisoned page, where 'page' is the precise small page with UE. It's been observed that when injecting poison to a non-head subpage of an anonymous hugetlb page, no SIGBUS shows up, while injecting to the head page produces a SIGBUS. The cause is that, though hugetlb_walk() returns a valid pmd entry (on x86), but check_pte() detects mismatch between the head page per the pmd and the input subpage. Thus the vaddr is considered not mapped to the subpage and the process is not collected for SIGBUS purpose. This is the calling stack: collect_procs_anon page_mapped_in_vma page_vma_mapped_walk hugetlb_walk huge_pte_lock check_pte check_pte() header says that it "check if [pvmw->pfn, @pvmw->pfn + @pvmw->nr_pages) is mapped at the @pvmw->pte" but practically works only if pvmw->pfn is the head page pfn at pvmw->pte. Hindsight acknowledging that some pvmw->pte could point to a hugepage of some sort such that it makes sense to make check_pte() work for hugepage. Link: https://lkml.kernel.org/r/20250224211445.2663312-1-jane.chu@oracle.com Signed-off-by: Jane Chu Cc: Hugh Dickins Cc: Kirill A. Shuemov Cc: linmiaohe Cc: Matthew Wilcow (Oracle) Cc: Peter Xu Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 53dc6b00c02d677fc9394d194ef5d5f18043148a Author: David Hildenbrand Date: Mon Feb 10 20:37:44 2025 +0100 mm/rmap: reject hugetlb folios in folio_make_device_exclusive() commit bc3fe6805cf09a25a086573a17d40e525208c5d8 upstream. Even though FOLL_SPLIT_PMD on hugetlb now always fails with -EOPNOTSUPP, let's add a safety net in case FOLL_SPLIT_PMD usage would ever be reworked. In particular, before commit 9cb28da54643 ("mm/gup: handle hugetlb in the generic follow_page_mask code"), GUP(FOLL_SPLIT_PMD) would just have returned a page. In particular, hugetlb folios that are not PMD-sized would never have been prone to FOLL_SPLIT_PMD. hugetlb folios can be anonymous, and page_make_device_exclusive_one() is not really prepared for handling them at all. So let's spell that out. Link: https://lkml.kernel.org/r/20250210193801.781278-3-david@redhat.com Fixes: b756a3b5e7ea ("mm: device exclusive memory access") Signed-off-by: David Hildenbrand Reviewed-by: Alistair Popple Tested-by: Alistair Popple Cc: Alex Shi Cc: Danilo Krummrich Cc: Dave Airlie Cc: Jann Horn Cc: Jason Gunthorpe Cc: Jerome Glisse Cc: John Hubbard Cc: Jonathan Corbet Cc: Karol Herbst Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Lyude Cc: "Masami Hiramatsu (Google)" Cc: Oleg Nesterov Cc: Pasha Tatashin Cc: Peter Xu Cc: Peter Zijlstra (Intel) Cc: SeongJae Park Cc: Simona Vetter Cc: Vlastimil Babka Cc: Yanteng Si Cc: Barry Song Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ab0af0126023fa9e419d8b03a12ae42b66433ba6 Author: Usama Arif Date: Fri Feb 7 13:20:32 2025 -0800 mm/damon/ops: have damon_get_folio return folio even for tail pages commit 3a06696305e757f652dd0dcf4dfa2272eda39434 upstream. Patch series "mm/damon/paddr: fix large folios access and schemes handling". DAMON operations set for physical address space, namely 'paddr', treats tail pages as unaccessed always. It can also apply DAMOS action to a large folio multiple times within single DAMOS' regions walking. As a result, the monitoring output has poor quality and DAMOS works in unexpected ways when large folios are being used. Fix those. The patches were parts of Usama's hugepage_size DAMOS filter patch series[1]. The first fix has collected from there with a slight commit message change for the subject prefix. The second fix is re-written by SJ and posted as an RFC before this series. The second one also got a slight commit message change for the subject prefix. [1] https://lore.kernel.org/20250203225604.44742-1-usamaarif642@gmail.com [2] https://lore.kernel.org/20250206231103.38298-1-sj@kernel.org This patch (of 2): This effectively adds support for large folios in damon for paddr, as damon_pa_mkold/young won't get a null folio from this function and won't ignore it, hence access will be checked and reported. This also means that larger folios will be considered for different DAMOS actions like pageout, prioritization and migration. As these DAMOS actions will consider larger folios, iterate through the region at folio_size and not PAGE_SIZE intervals. This should not have an affect on vaddr, as damon_young_pmd_entry considers pmd entries. Link: https://lkml.kernel.org/r/20250207212033.45269-1-sj@kernel.org Link: https://lkml.kernel.org/r/20250207212033.45269-2-sj@kernel.org Fixes: a28397beb55b ("mm/damon: implement primitives for physical address space monitoring") Signed-off-by: Usama Arif Signed-off-by: SeongJae Park Reviewed-by: SeongJae Park Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5f7f6abd92b6c8dc8f19625ef93c3a18549ede04 Author: Kuniyuki Iwashima Date: Mon Apr 7 09:33:11 2025 -0700 net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod. commit 0bb2f7a1ad1f11d861f58e5ee5051c8974ff9569 upstream. When I ran the repro [0] and waited a few seconds, I observed two LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1] Reproduction Steps: 1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables rule At step 3), the CIFS module calls sock_release() for the underlying TCP socket, and it returns quickly. However, the socket remains in FIN_WAIT_1 because incoming FIN packets are dropped. At this point, the module's refcnt is 0 while the socket is still alive, so the following rmmod command succeeds. # ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445 # lsmod | grep cifs cifs 1159168 0 This highlights a discrepancy between the lifetime of the CIFS module and the underlying TCP socket. Even after CIFS calls sock_release() and it returns, the TCP socket does not die immediately in order to close the connection gracefully. While this is generally fine, it causes an issue with LOCKDEP because CIFS assigns a different lock class to the TCP socket's sk->sk_lock using sock_lock_init_class_and_name(). Once an incoming packet is processed for the socket or a timer fires, sk->sk_lock is acquired. Then, LOCKDEP checks the lock context in check_wait_context(), where hlock_class() is called to retrieve the lock class. However, since the module has already been unloaded, hlock_class() logs a warning and returns NULL, triggering the null-ptr-deref. If LOCKDEP is enabled, we must ensure that a module calling sock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloaded while such a socket is still alive to prevent this issue. Let's hold the module reference in sock_lock_init_class_and_name() and release it when the socket is freed in sk_prot_free(). Note that sock_lock_init() clears sk->sk_owner for svc_create_socket() that calls sock_lock_init_class_and_name() for a listening socket, which clones a socket by sk_clone_lock() without GFP_ZERO. [0]: CIFS_SERVER="10.0.0.137" CIFS_PATH="//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST" DEV="enp0s3" CRED="/root/WindowsCredential.txt" MNT=$(mktemp -d /tmp/XXXXXX) mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1 iptables -A INPUT -s ${CIFS_SERVER} -j DROP for i in $(seq 10); do umount ${MNT} rmmod cifs sleep 1 done rm -r ${MNT} iptables -D INPUT -s ${CIFS_SERVER} -j DROP [1]: DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) ... Call Trace: __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) _raw_spin_lock_nested (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350) ... BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__lock_acquire (kernel/locking/lockdep.c:4852 kernel/locking/lockdep.c:5178) Code: 15 41 09 c7 41 8b 44 24 20 25 ff 1f 00 00 41 09 c7 8b 84 24 a0 00 00 00 45 89 7c 24 20 41 89 44 24 24 e8 e1 bc ff ff 4c 89 e7 <44> 0f b6 b8 c4 00 00 00 e8 d1 bc ff ff 0f b6 80 c5 00 00 00 88 44 RSP: 0018:ffa0000000468a10 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ff1100010091cc38 RCX: 0000000000000027 RDX: ff1100081f09ca48 RSI: 0000000000000001 RDI: ff1100010091cc88 RBP: ff1100010091c200 R08: ff1100083fe6e228 R09: 00000000ffffbfff R10: ff1100081eca0000 R11: ff1100083fe10dc0 R12: ff1100010091cc88 R13: 0000000000000001 R14: 0000000000000000 R15: 00000000000424b1 FS: 0000000000000000(0000) GS:ff1100081f080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c4 CR3: 0000000002c4a003 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) _raw_spin_lock_nested (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1)) ip_local_deliver_finish (./include/linux/rcupdate.h:878 net/ipv4/ip_input.c:234) ip_sublist_rcv_finish (net/ipv4/ip_input.c:576) ip_list_rcv_finish (net/ipv4/ip_input.c:628) ip_list_rcv (net/ipv4/ip_input.c:670) __netif_receive_skb_list_core (net/core/dev.c:5939 net/core/dev.c:5986) netif_receive_skb_list_internal (net/core/dev.c:6040 net/core/dev.c:6129) napi_complete_done (./include/linux/list.h:37 ./include/net/gro.h:519 ./include/net/gro.h:514 net/core/dev.c:6496) e1000_clean (drivers/net/ethernet/intel/e1000/e1000_main.c:3815) __napi_poll.constprop.0 (net/core/dev.c:7191) net_rx_action (net/core/dev.c:7262 net/core/dev.c:7382) handle_softirqs (kernel/softirq.c:561) __irq_exit_rcu (kernel/softirq.c:596 kernel/softirq.c:435 kernel/softirq.c:662) irq_exit_rcu (kernel/softirq.c:680) common_interrupt (arch/x86/kernel/irq.c:280 (discriminator 14)) asm_common_interrupt (./arch/x86/include/asm/idtentry.h:693) RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:744) Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d c3 2b 15 00 fb f4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 RSP: 0018:ffa00000000ffee8 EFLAGS: 00000202 RAX: 000000000000640b RBX: ff1100010091c200 RCX: 0000000000061aa4 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff812f30c5 RBP: 000000000000000a R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000002 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 ? do_idle (kernel/sched/idle.c:186 kernel/sched/idle.c:325) default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118) do_idle (kernel/sched/idle.c:186 kernel/sched/idle.c:325) cpu_startup_entry (kernel/sched/idle.c:422 (discriminator 1)) start_secondary (arch/x86/kernel/smpboot.c:315) common_startup_64 (arch/x86/kernel/head_64.S:421) Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs] CR2: 00000000000000c4 Fixes: ed07536ed673 ("[PATCH] lockdep: annotate nfs/nfsd in-kernel sockets") Signed-off-by: Kuniyuki Iwashima Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250407163313.22682-1-kuniyu@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fba396b79942be5432ca27ec003fa0f151235ca6 Author: Ryan Roberts Date: Mon Mar 3 14:15:38 2025 +0000 sparc/mm: avoid calling arch_enter/leave_lazy_mmu() in set_ptes commit eb61ad14c459b54f71f76331ca35d12fa3eb8f98 upstream. With commit 1a10a44dfc1d ("sparc64: implement the new page table range API") set_ptes was added to the sparc architecture. The implementation included calling arch_enter/leave_lazy_mmu() calls. The patch removes the usage of arch_enter/leave_lazy_mmu() since this implies nesting of lazy mmu regions which is not supported. Without this fix, lazy mmu mode is effectively disabled because we exit the mode after the first set_ptes: remap_pte_range() -> arch_enter_lazy_mmu() -> set_ptes() -> arch_enter_lazy_mmu() -> arch_leave_lazy_mmu() -> arch_leave_lazy_mmu() Powerpc suffered the same problem and fixed it in a corresponding way with commit 47b8def9358c ("powerpc/mm: Avoid calling arch_enter/leave_lazy_mmu() in set_ptes"). Link: https://lkml.kernel.org/r/20250303141542.3371656-5-ryan.roberts@arm.com Fixes: 1a10a44dfc1d ("sparc64: implement the new page table range API") Signed-off-by: Ryan Roberts Acked-by: David Hildenbrand Acked-by: Andreas Larsson Acked-by: Juergen Gross Cc: Borislav Betkov Cc: Boris Ostrovsky Cc: Catalin Marinas Cc: Dave Hansen Cc: David S. Miller Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Juegren Gross Cc: Matthew Wilcow (Oracle) Cc: Thomas Gleinxer Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 690446dc72d5de012d8d0301bc1454c4ec740923 Author: Ryan Roberts Date: Mon Mar 3 14:15:37 2025 +0000 sparc/mm: disable preemption in lazy mmu mode commit a1d416bf9faf4f4871cb5a943614a07f80a7d70f upstream. Since commit 38e0edb15bd0 ("mm/apply_to_range: call pte function with lazy updates") it's been possible for arch_[enter|leave]_lazy_mmu_mode() to be called without holding a page table lock (for the kernel mappings case), and therefore it is possible that preemption may occur while in the lazy mmu mode. The Sparc lazy mmu implementation is not robust to preemption since it stores the lazy mode state in a per-cpu structure and does not attempt to manage that state on task switch. Powerpc had the same issue and fixed it by explicitly disabling preemption in arch_enter_lazy_mmu_mode() and re-enabling in arch_leave_lazy_mmu_mode(). See commit b9ef323ea168 ("powerpc/64s: Disable preemption in hash lazy mmu mode"). Given Sparc's lazy mmu mode is based on powerpc's, let's fix it in the same way here. Link: https://lkml.kernel.org/r/20250303141542.3371656-4-ryan.roberts@arm.com Fixes: 38e0edb15bd0 ("mm/apply_to_range: call pte function with lazy updates") Signed-off-by: Ryan Roberts Acked-by: David Hildenbrand Acked-by: Andreas Larsson Acked-by: Juergen Gross Cc: Borislav Betkov Cc: Boris Ostrovsky Cc: Catalin Marinas Cc: Dave Hansen Cc: David S. Miller Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Juegren Gross Cc: Matthew Wilcow (Oracle) Cc: Thomas Gleinxer Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cb6b9bd66181f43c6723f20c91878b1de864933a Author: Sean Christopherson Date: Thu Apr 10 15:32:46 2025 +0800 iommu/vt-d: Wire up irq_ack() to irq_move_irq() for posted MSIs commit 548183ea388c12b6d76d6982f3d72df3887af0da upstream. Set the posted MSI irq_chip's irq_ack() hook to irq_move_irq() instead of a dummy/empty callback so that posted MSIs process pending changes to the IRQ's SMP affinity. Failure to honor a pending set-affinity results in userspace being unable to change the effective affinity of the IRQ, as IRQD_SETAFFINITY_PENDING is never cleared and so irq_set_affinity_locked() always defers moving the IRQ. The issue is most easily reproducible by setting /proc/irq/xx/smp_affinity multiple times in quick succession, as only the first update is likely to be handled in process context. Fixes: ed1e48ea4370 ("iommu/vt-d: Enable posted mode for device MSIs") Cc: Robert Lippert Cc: Thomas Gleixner Reported-by: Wentao Yang Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Reviewed-by: Thomas Gleixner Link: https://lore.kernel.org/r/20250321194249.1217961-1-seanjc@google.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 6722a0cb818691e63c613fa801d6ccfba3f7d38c Author: Lu Baolu Date: Wed Mar 19 10:21:01 2025 +0800 iommu/vt-d: Fix possible circular locking dependency commit 93ae6e68b6d6b62d92b3a89d1c253d4a1721a1d3 upstream. We have recently seen report of lockdep circular lock dependency warnings on platforms like Skylake and Kabylake: ====================================================== WARNING: possible circular locking dependency detected 6.14.0-rc6-CI_DRM_16276-gca2c04fe76e8+ #1 Not tainted ------------------------------------------------------ swapper/0/1 is trying to acquire lock: ffffffff8360ee48 (iommu_probe_device_lock){+.+.}-{3:3}, at: iommu_probe_device+0x1d/0x70 but task is already holding lock: ffff888102c7efa8 (&device->physical_node_lock){+.+.}-{3:3}, at: intel_iommu_init+0xe75/0x11f0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #6 (&device->physical_node_lock){+.+.}-{3:3}: __mutex_lock+0xb4/0xe40 mutex_lock_nested+0x1b/0x30 intel_iommu_init+0xe75/0x11f0 pci_iommu_init+0x13/0x70 do_one_initcall+0x62/0x3f0 kernel_init_freeable+0x3da/0x6a0 kernel_init+0x1b/0x200 ret_from_fork+0x44/0x70 ret_from_fork_asm+0x1a/0x30 -> #5 (dmar_global_lock){++++}-{3:3}: down_read+0x43/0x1d0 enable_drhd_fault_handling+0x21/0x110 cpuhp_invoke_callback+0x4c6/0x870 cpuhp_issue_call+0xbf/0x1f0 __cpuhp_setup_state_cpuslocked+0x111/0x320 __cpuhp_setup_state+0xb0/0x220 irq_remap_enable_fault_handling+0x3f/0xa0 apic_intr_mode_init+0x5c/0x110 x86_late_time_init+0x24/0x40 start_kernel+0x895/0xbd0 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0xbf/0x110 common_startup_64+0x13e/0x141 -> #4 (cpuhp_state_mutex){+.+.}-{3:3}: __mutex_lock+0xb4/0xe40 mutex_lock_nested+0x1b/0x30 __cpuhp_setup_state_cpuslocked+0x67/0x320 __cpuhp_setup_state+0xb0/0x220 page_alloc_init_cpuhp+0x2d/0x60 mm_core_init+0x18/0x2c0 start_kernel+0x576/0xbd0 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0xbf/0x110 common_startup_64+0x13e/0x141 -> #3 (cpu_hotplug_lock){++++}-{0:0}: __cpuhp_state_add_instance+0x4f/0x220 iova_domain_init_rcaches+0x214/0x280 iommu_setup_dma_ops+0x1a4/0x710 iommu_device_register+0x17d/0x260 intel_iommu_init+0xda4/0x11f0 pci_iommu_init+0x13/0x70 do_one_initcall+0x62/0x3f0 kernel_init_freeable+0x3da/0x6a0 kernel_init+0x1b/0x200 ret_from_fork+0x44/0x70 ret_from_fork_asm+0x1a/0x30 -> #2 (&domain->iova_cookie->mutex){+.+.}-{3:3}: __mutex_lock+0xb4/0xe40 mutex_lock_nested+0x1b/0x30 iommu_setup_dma_ops+0x16b/0x710 iommu_device_register+0x17d/0x260 intel_iommu_init+0xda4/0x11f0 pci_iommu_init+0x13/0x70 do_one_initcall+0x62/0x3f0 kernel_init_freeable+0x3da/0x6a0 kernel_init+0x1b/0x200 ret_from_fork+0x44/0x70 ret_from_fork_asm+0x1a/0x30 -> #1 (&group->mutex){+.+.}-{3:3}: __mutex_lock+0xb4/0xe40 mutex_lock_nested+0x1b/0x30 __iommu_probe_device+0x24c/0x4e0 probe_iommu_group+0x2b/0x50 bus_for_each_dev+0x7d/0xe0 iommu_device_register+0xe1/0x260 intel_iommu_init+0xda4/0x11f0 pci_iommu_init+0x13/0x70 do_one_initcall+0x62/0x3f0 kernel_init_freeable+0x3da/0x6a0 kernel_init+0x1b/0x200 ret_from_fork+0x44/0x70 ret_from_fork_asm+0x1a/0x30 -> #0 (iommu_probe_device_lock){+.+.}-{3:3}: __lock_acquire+0x1637/0x2810 lock_acquire+0xc9/0x300 __mutex_lock+0xb4/0xe40 mutex_lock_nested+0x1b/0x30 iommu_probe_device+0x1d/0x70 intel_iommu_init+0xe90/0x11f0 pci_iommu_init+0x13/0x70 do_one_initcall+0x62/0x3f0 kernel_init_freeable+0x3da/0x6a0 kernel_init+0x1b/0x200 ret_from_fork+0x44/0x70 ret_from_fork_asm+0x1a/0x30 other info that might help us debug this: Chain exists of: iommu_probe_device_lock --> dmar_global_lock --> &device->physical_node_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&device->physical_node_lock); lock(dmar_global_lock); lock(&device->physical_node_lock); lock(iommu_probe_device_lock); *** DEADLOCK *** This driver uses a global lock to protect the list of enumerated DMA remapping units. It is necessary due to the driver's support for dynamic addition and removal of remapping units at runtime. Two distinct code paths require iteration over this remapping unit list: - Device registration and probing: the driver iterates the list to register each remapping unit with the upper layer IOMMU framework and subsequently probe the devices managed by that unit. - Global configuration: Upper layer components may also iterate the list to apply configuration changes. The lock acquisition order between these two code paths was reversed. This caused lockdep warnings, indicating a risk of deadlock. Fix this warning by releasing the global lock before invoking upper layer interfaces for device registration. Fixes: b150654f74bf ("iommu/vt-d: Fix suspicious RCU usage") Closes: https://lore.kernel.org/linux-iommu/SJ1PR11MB612953431F94F18C954C4A9CB9D32@SJ1PR11MB6129.namprd11.prod.outlook.com/ Tested-by: Chaitanya Kumar Borah Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20250317035714.1041549-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit e953e11123aa703241418ee69a82e5538e58eaff Author: Sean Christopherson Date: Wed Mar 19 10:21:00 2025 +0800 iommu/vt-d: Don't clobber posted vCPU IRTE when host IRQ affinity changes commit 688124cc541f60d26a7547f45637b23dada4e527 upstream. Don't overwrite an IRTE that is posting IRQs to a vCPU with a posted MSI entry if the host IRQ affinity happens to change. If/when the IRTE is reverted back to "host mode", it will be reconfigured as a posted MSI or remapped entry as appropriate. Drop the "mode" field, which doesn't differentiate between posted MSIs and posted vCPUs, in favor of a dedicated posted_vcpu flag. Note! The two posted_{msi,vcpu} flags are intentionally not mutually exclusive; an IRTE can transition between posted MSI and posted vCPU. Fixes: ed1e48ea4370 ("iommu/vt-d: Enable posted mode for device MSIs") Cc: stable@vger.kernel.org Cc: Thomas Gleixner Cc: Jacob Pan Signed-off-by: Sean Christopherson Link: https://lore.kernel.org/r/20250315025135.2365846-3-seanjc@google.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit c95a438d2c37748541b696053cd5c72042c838ad Author: Sean Christopherson Date: Wed Mar 19 10:20:59 2025 +0800 iommu/vt-d: Put IRTE back into posted MSI mode if vCPU posting is disabled commit 2454823e97a63d85a6b215905f71e5a06324eab7 upstream. Add a helper to take care of reconfiguring an IRTE to deliver IRQs to the host, i.e. not to a vCPU, and use the helper when an IRTE's vCPU affinity is nullified, i.e. when KVM puts an IRTE back into "host" mode. Because posted MSIs use an ephemeral IRTE, using modify_irte() puts the IRTE into full remapped mode, i.e. unintentionally disables posted MSIs on the IRQ. Fixes: ed1e48ea4370 ("iommu/vt-d: Enable posted mode for device MSIs") Cc: stable@vger.kernel.org Cc: Thomas Gleixner Cc: Jacob Pan Signed-off-by: Sean Christopherson Link: https://lore.kernel.org/r/20250315025135.2365846-2-seanjc@google.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit e5dd974d6e00704553308ef1a88659f8dcfb39d4 Author: Nicolin Chen Date: Mon Apr 7 13:19:08 2025 -0700 iommu/tegra241-cmdqv: Fix warnings due to dmam_free_coherent() commit 767e22001dfce64cc03b7def1562338591ab6031 upstream. Two WARNINGs are observed when SMMU driver rolls back upon failure: arm-smmu-v3.9.auto: Failed to register iommu arm-smmu-v3.9.auto: probe with driver arm-smmu-v3 failed with error -22 ------------[ cut here ]------------ WARNING: CPU: 5 PID: 1 at kernel/dma/mapping.c:74 dmam_free_coherent+0xc0/0xd8 Call trace: dmam_free_coherent+0xc0/0xd8 (P) tegra241_vintf_free_lvcmdq+0x74/0x188 tegra241_cmdqv_remove_vintf+0x60/0x148 tegra241_cmdqv_remove+0x48/0xc8 arm_smmu_impl_remove+0x28/0x60 devm_action_release+0x1c/0x40 ------------[ cut here ]------------ 128 pages are still in use! WARNING: CPU: 16 PID: 1 at mm/page_alloc.c:6902 free_contig_range+0x18c/0x1c8 Call trace: free_contig_range+0x18c/0x1c8 (P) cma_release+0x154/0x2f0 dma_free_contiguous+0x38/0xa0 dma_direct_free+0x10c/0x248 dma_free_attrs+0x100/0x290 dmam_free_coherent+0x78/0xd8 tegra241_vintf_free_lvcmdq+0x74/0x160 tegra241_cmdqv_remove+0x98/0x198 arm_smmu_impl_remove+0x28/0x60 devm_action_release+0x1c/0x40 This is because the LVCMDQ queue memory are managed by devres, while that dmam_free_coherent() is called in the context of devm_action_release(). Jason pointed out that "arm_smmu_impl_probe() has mis-ordered the devres callbacks if ops->device_remove() is going to be manually freeing things that probe allocated": https://lore.kernel.org/linux-iommu/20250407174408.GB1722458@nvidia.com/ In fact, tegra241_cmdqv_init_structures() only allocates memory resources which means any failure that it generates would be similar to -ENOMEM, so there is no point in having that "falling back to standard SMMU" routine, as the standard SMMU would likely fail to allocate memory too. Remove the unwind part in tegra241_cmdqv_init_structures(), and return a proper error code to ask SMMU driver to call tegra241_cmdqv_remove() via impl_ops->device_remove(). Then, drop tegra241_vintf_free_lvcmdq() since devres will take care of that. Fixes: 483e0bd8883a ("iommu/tegra241-cmdqv: Do not allocate vcmdq until dma_set_mask_and_coherent") Cc: stable@vger.kernel.org Suggested-by: Jason Gunthorpe Signed-off-by: Nicolin Chen Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20250407201908.172225-1-nicolinc@nvidia.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit b8b41eac70546c19e5812330634457110378899d Author: Nicolin Chen Date: Thu Feb 27 12:07:29 2025 -0800 iommufd: Fix uninitialized rc in iommufd_access_rw() commit a05df03a88bc1088be8e9d958f208d6484691e43 upstream. Reported by smatch: drivers/iommu/iommufd/device.c:1392 iommufd_access_rw() error: uninitialized symbol 'rc'. Fixes: 8d40205f6093 ("iommufd: Add kAPI toward external drivers for kernel access") Link: https://patch.msgid.link/r/20250227200729.85030-1-nicolinc@nvidia.com Cc: stable@vger.kernel.org Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202502271339.a2nWr9UA-lkp@intel.com/ [nicolinc: can't find an original report but only in "old smatch warnings"] Signed-off-by: Nicolin Chen Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 327e6b8b2816e0599c62ef684841ba3f04f148f9 Author: Johannes Thumshirn Date: Mon Mar 17 12:24:59 2025 +0100 btrfs: zoned: fix zone finishing with missing devices commit 35fec1089ebb5617f85884d3fa6a699ce6337a75 upstream. If do_zone_finish() is called with a filesystem that has missing devices (e.g. a RAID file system mounted in degraded mode) it is accessing the btrfs_device::zone_info pointer, which will not be set if the device in question is missing. Check if the device is present (by checking if it has a valid block device pointer associated) and if not, skip zone finishing for it. Fixes: 4dcbb8ab31c1 ("btrfs: zoned: make zone finishing multi stripe capable") CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Naohiro Aota Reviewed-by: Anand Jain Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 380ba38801eb32d76e283469dad8c2a68e0a2ee2 Author: Johannes Thumshirn Date: Mon Mar 17 12:24:58 2025 +0100 btrfs: zoned: fix zone activation with missing devices commit 2bbc4a45e5eb6b868357c1045bf6f38f6ba576e0 upstream. If btrfs_zone_activate() is called with a filesystem that has missing devices (e.g. a RAID file system mounted in degraded mode) it is accessing the btrfs_device::zone_info pointer, which will not be set if the device in question is missing. Check if the device is present (by checking if it has a valid block device pointer associated) and if not, skip zone activation for it. Fixes: f9a912a3c45f ("btrfs: zoned: make zone activation multi stripe capable") CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Naohiro Aota Reviewed-by: Anand Jain Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit b9af27d020e4fbc20529cfde494b2bb77ec39a4c Author: Filipe Manana Date: Tue Mar 11 15:50:50 2025 +0000 btrfs: tests: fix chunk map leak after failure to add it to the tree commit 009ca358486ded9b4822eddb924009b6848d7271 upstream. If we fail to add the chunk map to the fs mapping tree we exit test_rmap_block() without freeing the chunk map. Fix this by adding a call to btrfs_free_chunk_map() before exiting the test function if the call to btrfs_add_chunk_map() failed. Fixes: 7dc66abb5a47 ("btrfs: use a dedicated data structure for chunk maps") CC: stable@vger.kernel.org # 6.12+ Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 601db4e8bfe86ef32c498d62f57c2a9fc4d82b4c Author: Filipe Manana Date: Wed Mar 5 16:52:26 2025 +0000 btrfs: fix non-empty delayed iputs list on unmount due to compressed write workers commit 4c782247b89376a83fa132f7d45d6977edae0629 upstream. At close_ctree() after we have ran delayed iputs either through explicitly calling btrfs_run_delayed_iputs() or later during the call to btrfs_commit_super() or btrfs_error_commit_super(), we assert that the delayed iputs list is empty. When we have compressed writes this assertion may fail because delayed iputs may have been added to the list after we last ran delayed iputs. This happens like this: 1) We have a compressed write bio executing; 2) We enter close_ctree() and flush the fs_info->endio_write_workers queue which is the queue used for running ordered extent completion; 3) The compressed write bio finishes and enters btrfs_finish_compressed_write_work(), where it calls btrfs_finish_ordered_extent() which in turn calls btrfs_queue_ordered_fn(), which queues a work item in the fs_info->endio_write_workers queue that we have flushed before; 4) At close_ctree() we proceed, run all existing delayed iputs and call btrfs_commit_super() (which also runs delayed iputs), but before we run the following assertion below: ASSERT(list_empty(&fs_info->delayed_iputs)) A delayed iput is added by the step below... 5) The ordered extent completion job queued in step 3 runs and results in creating a delayed iput when dropping the last reference of the ordered extent (a call to btrfs_put_ordered_extent() made from btrfs_finish_one_ordered()); 6) At this point the delayed iputs list is not empty, so the assertion at close_ctree() fails. Fix this by flushing the fs_info->compressed_write_workers queue at close_ctree() before flushing the fs_info->endio_write_workers queue, respecting the queue dependency as the later is responsible for the execution of ordered extent completion. CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 61a5c565fd2442d3128f3bab5f022658adc3a4e6 Author: Herve Codina Date: Wed Jan 22 10:19:14 2025 +0100 backlight: led_bl: Hold led_access lock when calling led_sysfs_disable() commit 276822a00db3c1061382b41e72cafc09d6a0ec30 upstream. Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ... Indeed, led_sysfs_enable() has to be called with the led_access lock held. Hold the lock when calling led_sysfs_disable(). Fixes: ae232e45acf9 ("backlight: add led-backlight driver") Cc: stable@vger.kernel.org Signed-off-by: Herve Codina Link: https://lore.kernel.org/r/20250122091914.309533-1-herve.codina@bootlin.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit a3b36c9da305c206833b5b116f7da51e3a5bba9c Author: Peter Griffin Date: Mon Jan 6 14:57:46 2025 +0000 arm64: dts: exynos: gs101: disable pinctrl_gsacore node commit 168e24966f10ff635b0ec9728aa71833bf850ee5 upstream. gsacore registers are not accessible from normal world. Disable this node, so that the suspend/resume callbacks in the pinctrl driver don't cause a Serror attempting to access the registers. Fixes: ea89fdf24fd9 ("arm64: dts: exynos: google: Add initial Google gs101 SoC support") Signed-off-by: Peter Griffin To: Rob Herring To: Krzysztof Kozlowski To: Conor Dooley To: Alim Akhtar Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: tudor.ambarus@linaro.org Cc: andre.draszik@linaro.org Cc: kernel-team@android.com Cc: willmcvicker@google.com Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250106-contrib-pg-pinctrl_gsacore_disable-v1-1-d3fc88a48aed@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit ac45d49df9dc606d362fabc523696cd5ebd569a5 Author: Chen-Yu Tsai Date: Wed Jan 8 16:34:22 2025 +0800 arm64: dts: mediatek: mt8173: Fix disp-pwm compatible string commit 46ad36002088eff8fc5cae200aa42ae9f9310ddd upstream. The MT8173 disp-pwm device should have only one compatible string, based on the following DT validation error: arch/arm64/boot/dts/mediatek/mt8173-elm.dtb: pwm@1401e000: compatible: 'oneOf' conditional failed, one must be fixed: ['mediatek,mt8173-disp-pwm', 'mediatek,mt6595-disp-pwm'] is too long 'mediatek,mt8173-disp-pwm' is not one of ['mediatek,mt6795-disp-pwm', 'mediatek,mt8167-disp-pwm'] 'mediatek,mt8173-disp-pwm' is not one of ['mediatek,mt8186-disp-pwm', 'mediatek,mt8188-disp-pwm', 'mediatek,mt8192-disp-pwm', 'mediatek,mt8195-disp-pwm', 'mediatek,mt8365-disp-pwm'] 'mediatek,mt8173-disp-pwm' was expected 'mediatek,mt8183-disp-pwm' was expected from schema $id: http://devicetree.org/schemas/pwm/mediatek,pwm-disp.yaml# arch/arm64/boot/dts/mediatek/mt8173-elm.dtb: pwm@1401f000: compatible: 'oneOf' conditional failed, one must be fixed: ['mediatek,mt8173-disp-pwm', 'mediatek,mt6595-disp-pwm'] is too long 'mediatek,mt8173-disp-pwm' is not one of ['mediatek,mt6795-disp-pwm', 'mediatek,mt8167-disp-pwm'] 'mediatek,mt8173-disp-pwm' is not one of ['mediatek,mt8186-disp-pwm', 'mediatek,mt8188-disp-pwm', 'mediatek,mt8192-disp-pwm', 'mediatek,mt8195-disp-pwm', 'mediatek,mt8365-disp-pwm'] 'mediatek,mt8173-disp-pwm' was expected 'mediatek,mt8183-disp-pwm' was expected from schema $id: http://devicetree.org/schemas/pwm/mediatek,pwm-disp.yaml# Drop the extra "mediatek,mt6595-disp-pwm" compatible string. Fixes: 61aee9342514 ("arm64: dts: mt8173: add MT8173 display PWM driver support node") Cc: YH Huang Cc: stable@vger.kernel.org # v4.5+ Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20250108083424.2732375-2-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Greg Kroah-Hartman commit 1dd288783dcb113982352f8a7dd38fe75791b9ed Author: Zhenhua Huang Date: Fri Mar 21 15:00:19 2025 +0800 arm64: mm: Correct the update of max_pfn commit 89f43e1ce6f60d4f44399059595ac47f7a90a393 upstream. Hotplugged memory can be smaller than the original memory. For example, on my target: root@genericarmv8:~# cat /sys/kernel/debug/memblock/memory 0: 0x0000000064005000..0x0000000064023fff 0 NOMAP 1: 0x0000000064400000..0x00000000647fffff 0 NOMAP 2: 0x0000000068000000..0x000000006fffffff 0 DRV_MNG 3: 0x0000000088800000..0x0000000094ffefff 0 NONE 4: 0x0000000094fff000..0x0000000094ffffff 0 NOMAP max_pfn will affect read_page_owner. Therefore, it should first compare and then select the larger value for max_pfn. Fixes: 8fac67ca236b ("arm64: mm: update max_pfn after memory hotplug") Cc: # 6.1.x Signed-off-by: Zhenhua Huang Acked-by: David Hildenbrand Reviewed-by: Anshuman Khandual Link: https://lore.kernel.org/r/20250321070019.1271859-1-quic_zhenhuah@quicinc.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 21c5124304242170f93842c186ffa6fda682121b Author: Ninad Malwade Date: Thu Feb 6 22:40:34 2025 +0000 arm64: tegra: Remove the Orin NX/Nano suspend key commit bb8a3ad25f098b6ea9b1d0f522427b4ad53a7bba upstream. As per the Orin Nano Dev Kit schematic, GPIO_G.02 is not available on this device family. It should not be used at all on Orin NX/Nano. Having this unused pin mapped as the suspend key can lead to unpredictable behavior for low power modes. Orin NX/Nano uses GPIO_EE.04 as both a "power" button and a "suspend" button. However, we cannot have two gpio-keys mapped to the same GPIO. Therefore remove the "suspend" key. Cc: stable@vger.kernel.org Fixes: e63472eda5ea ("arm64: tegra: Support Jetson Orin NX reference platform") Signed-off-by: Ninad Malwade Signed-off-by: Ivy Huang Link: https://lore.kernel.org/r/20250206224034.3691397-1-yijuh@nvidia.com Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit eec737e17e5567e08148550a7f1d94d495b9fb17 Author: Keir Fraser Date: Wed Mar 26 11:04:47 2025 +0000 arm64: mops: Do not dereference src reg for a set operation commit a13bfa4fe0d6949cea14718df2d1fe84c38cd113 upstream. The source register is not used for SET* and reading it can result in a UBSAN out-of-bounds array access error, specifically when the MOPS exception is taken from a SET* sequence with XZR (reg 31) as the source. Architecturally this is the only case where a src/dst/size field in the ESR can be reported as 31. Prior to 2de451a329cf662b the code in do_el0_mops() was benign as the use of pt_regs_read_reg() prevented the out-of-bounds access. Fixes: 2de451a329cf ("KVM: arm64: Add handler for MOPS exceptions") Cc: # 6.12.x Cc: Kristina Martsenko Cc: Will Deacon Cc: stable@vger.kernel.org Reviewed-by: Marc Zyngier Signed-off-by: Keir Fraser Reviewed-by: Kristina Martšenko Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20250326110448.3792396-1-keirf@google.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 52f251dbfb387339879120f5de4c8194a5c4fd82 Author: Wentao Liang Date: Wed Apr 2 15:56:23 2025 +0800 mtd: rawnand: Add status chack in r852_ready() commit b79fe1829975556854665258cf4d2476784a89db upstream. In r852_ready(), the dev get from r852_get_dev() need to be checked. An unstable device should not be ready. A proper implementation can be found in r852_read_byte(). Add a status check and return 0 when it is unstable. Fixes: 50a487e7719c ("mtd: rawnand: Pass a nand_chip object to chip->dev_ready()") Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Wentao Liang Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 5479a6af3c96f73bec2d2819532b6d6814f52dd6 Author: Wentao Liang Date: Wed Apr 2 11:16:43 2025 +0800 mtd: inftlcore: Add error check for inftl_read_oob() commit d027951dc85cb2e15924c980dc22a6754d100c7c upstream. In INFTL_findwriteunit(), the return value of inftl_read_oob() need to be checked. A proper implementation can be found in INFTL_deleteblock(). The status will be set as SECTOR_IGNORE to break from the while-loop correctly if the inftl_read_oob() fails. Fixes: 8593fbc68b0d ("[MTD] Rework the out of band handling completely") Cc: stable@vger.kernel.org # v2.6+ Signed-off-by: Wentao Liang Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 6554491b4a770ec0ddd4a13b4420d51685849c3f Author: Matthieu Baerts (NGI0) Date: Mon Apr 7 20:26:32 2025 +0200 mptcp: only inc MPJoinAckHMacFailure for HMAC failures commit 21c02e8272bc95ba0dd44943665c669029b42760 upstream. Recently, during a debugging session using local MPTCP connections, I noticed MPJoinAckHMacFailure was not zero on the server side. The counter was in fact incremented when the PM rejected new subflows, because the 'subflow' limit was reached. The fix is easy, simply dissociating the two cases: only the HMAC validation check should increase MPTCP_MIB_JOINACKMAC counter. Fixes: 4cf8b7e48a09 ("subflow: introduce and use mptcp_can_accept_new_subflow()") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250407-net-mptcp-hmac-failure-mib-v1-1-3c9ecd0a3a50@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit dc81e41a307df523072186b241fa8244fecd7803 Author: Gang Yan Date: Fri Mar 28 15:27:16 2025 +0100 mptcp: fix NULL pointer in can_accept_new_subflow commit 443041deb5ef6a1289a99ed95015ec7442f141dc upstream. When testing valkey benchmark tool with MPTCP, the kernel panics in 'mptcp_can_accept_new_subflow' because subflow_req->msk is NULL. Call trace: mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P) subflow_syn_recv_sock (./net/mptcp/subflow.c:854) tcp_check_req (./net/ipv4/tcp_minisocks.c:863) tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268) ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207) ip_local_deliver_finish (./net/ipv4/ip_input.c:234) ip_local_deliver (./net/ipv4/ip_input.c:254) ip_rcv_finish (./net/ipv4/ip_input.c:449) ... According to the debug log, the same req received two SYN-ACK in a very short time, very likely because the client retransmits the syn ack due to multiple reasons. Even if the packets are transmitted with a relevant time interval, they can be processed by the server on different CPUs concurrently). The 'subflow_req->msk' ownership is transferred to the subflow the first, and there will be a risk of a null pointer dereference here. This patch fixes this issue by moving the 'subflow_req->msk' under the `own_req == true` conditional. Note that the !msk check in subflow_hmac_valid() can be dropped, because the same check already exists under the own_req mpj branch where the code has been moved to. Fixes: 9466a1ccebbe ("mptcp: enable JOIN requests even if cookies are in use") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250328-net-mptcp-misc-fixes-6-15-v1-1-34161a482a7f@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c7f611e711c870ac18a4e8e592751630c8e26940 Author: T Pratham Date: Wed Mar 19 16:44:38 2025 +0530 lib: scatterlist: fix sg_split_phys to preserve original scatterlist offsets commit 8b46fdaea819a679da176b879e7b0674a1161a5e upstream. The split_sg_phys function was incorrectly setting the offsets of all scatterlist entries (except the first) to 0. Only the first scatterlist entry's offset and length needs to be modified to account for the skip. Setting the rest entries' offsets to 0 could lead to incorrect data access. I am using this function in a crypto driver that I'm currently developing (not yet sent to mailing list). During testing, it was observed that the output scatterlists (except the first one) contained incorrect garbage data. I narrowed this issue down to the call of sg_split(). Upon debugging inside this function, I found that this resetting of offset is the cause of the problem, causing the subsequent scatterlists to point to incorrect memory locations in a page. By removing this code, I am obtaining expected data in all the split output scatterlists. Thus, this was indeed causing observable runtime effects! This patch removes the offending code, ensuring that the page offsets in the input scatterlist are preserved in the output scatterlist. Link: https://lkml.kernel.org/r/20250319111437.1969903-1-t-pratham@ti.com Fixes: f8bcbe62acd0 ("lib: scatterlist: add sg splitting function") Signed-off-by: T Pratham Cc: Robert Jarzmik Cc: Jens Axboe Cc: Kamlesh Gurudasani Cc: Praneeth Bajjuri Cc: Vignesh Raghavendra Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 95f0958240e6e63b6da2836629e74b16ca08d544 Author: Boqun Feng Date: Wed Mar 26 11:08:30 2025 -0700 locking/lockdep: Decrease nr_unused_locks if lock unused in zap_class() commit 495f53d5cca0f939eaed9dca90b67e7e6fb0e30c upstream. Currently, when a lock class is allocated, nr_unused_locks will be increased by 1, until it gets used: nr_unused_locks will be decreased by 1 in mark_lock(). However, one scenario is missed: a lock class may be zapped without even being used once. This could result into a situation that nr_unused_locks != 0 but no unused lock class is active in the system, and when `cat /proc/lockdep_stats`, a WARN_ON() will be triggered in a CONFIG_DEBUG_LOCKDEP=y kernel: [...] DEBUG_LOCKS_WARN_ON(debug_atomic_read(nr_unused_locks) != nr_unused) [...] WARNING: CPU: 41 PID: 1121 at kernel/locking/lockdep_proc.c:283 lockdep_stats_show+0xba9/0xbd0 And as a result, lockdep will be disabled after this. Therefore, nr_unused_locks needs to be accounted correctly at zap_class() time. Signed-off-by: Boqun Feng Signed-off-by: Ingo Molnar Reviewed-by: Waiman Long Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250326180831.510348-1-boqun.feng@gmail.com Signed-off-by: Greg Kroah-Hartman commit 008b90d36d913604ad206e706a9ac4b3630e6c88 Author: Kartik Rajput Date: Thu Jan 23 18:16:32 2025 +0530 mailbox: tegra-hsp: Define dimensioning masks in SoC data commit bf0c9fb462038815f5f502653fb6dba06e6af415 upstream. Tegra264 has updated HSP_INT_DIMENSIONING register as follows: * nSI is now BIT17:BIT21. * nDB is now BIT12:BIT16. Currently, we are using a static macro HSP_nINT_MASK to get the values from HSP_INT_DIMENSIONING register. This results in wrong values for nSI for HSP instances that supports 16 shared interrupts. Define dimensioning masks in soc data and use them to parse nSI, nDB, nAS, nSS & nSM values. Fixes: 602dbbacc3ef ("mailbox: tegra: add support for Tegra264") Cc: stable@vger.kernel.org Signed-off-by: Kartik Rajput Acked-by: Thierry Reding Acked-by: Jon Hunter Signed-off-by: Jassi Brar Signed-off-by: Greg Kroah-Hartman commit 7b47df6498f223c8956bfe0d994a0e42a520dfcd Author: Chenyuan Yang Date: Mon Feb 24 17:37:36 2025 -0600 mfd: ene-kb3930: Fix a potential NULL pointer dereference commit 4cdf1d2a816a93fa02f7b6b5492dc7f55af2a199 upstream. The off_gpios could be NULL. Add missing check in the kb3930_probe(). This is similar to the issue fixed in commit b1ba8bcb2d1f ("backlight: hx8357: Fix potential NULL pointer dereference"). This was detected by our static analysis tool. Cc: stable@vger.kernel.org Fixes: ede6b2d1dfc0 ("mfd: ene-kb3930: Add driver for ENE KB3930 Embedded Controller") Suggested-by: Lee Jones Signed-off-by: Chenyuan Yang Link: https://lore.kernel.org/r/20250224233736.1919739-1-chenyuan0y@gmail.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 4b037851edd7eedecee9ab31a871ffde0169fc20 Author: Abel Vesa Date: Wed Mar 5 15:09:06 2025 +0200 leds: rgb: leds-qcom-lpg: Fix calculation of best period Hi-Res PWMs commit 2528eec7da0ec58fcae6d12cfa79a622c933d86b upstream. When determining the actual best period by looping through all possible PWM configs, the resolution currently used is based on bit shift value which is off-by-one above the possible maximum PWM value allowed. So subtract one from the resolution before determining the best period so that the maximum duty cycle requested by the PWM user won't result in a value above the maximum allowed by the selected resolution. Cc: stable@vger.kernel.org # 6.4 Fixes: b00d2ed37617 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM") Signed-off-by: Abel Vesa Reviewed-by: Sebastian Reichel Link: https://lore.kernel.org/r/20250305-leds-qcom-lpg-fix-max-pwm-on-hi-res-v4-3-bfe124a53a9f@linaro.org Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 5ae9e361e28476a37f1099100d8b214607220bb6 Author: Abel Vesa Date: Wed Mar 5 15:09:05 2025 +0200 leds: rgb: leds-qcom-lpg: Fix pwm resolution max for Hi-Res PWMs commit b7881eacc07fdf50be3f33c662997541bb59366d upstream. Ideally, the requested duty cycle should never translate to a PWM value higher than the selected resolution (PWM size), but currently the best matched period is never reported back to the PWM consumer, so the consumer will still be using the requested period which is higher than the best matched one. This will result in PWM consumer requesting duty cycle values higher than the allowed PWM value. For example, a consumer might request a period of 5ms while the best (closest) period the PWM hardware will do is 4.26ms. For this best matched resolution, if the selected resolution is 8-bit wide, when the consumer asks for a duty cycle of 5ms, the PWM value will be 300, which is outside of what the resolution allows. This will happen with all possible resolutions when selected. Since for these Hi-Res PWMs, the current implementation is capping the PWM value at a 15-bit resolution, even when lower resolutions are selected, the value will be wrapped around by the HW internal logic to the selected resolution. Fix the issue by capping the PWM value to the maximum value allowed by the selected resolution. Cc: stable@vger.kernel.org # 6.4 Fixes: b00d2ed37617 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM") Signed-off-by: Abel Vesa Reviewed-by: Bjorn Andersson Reviewed-by: Sebastian Reichel Link: https://lore.kernel.org/r/20250305-leds-qcom-lpg-fix-max-pwm-on-hi-res-v4-2-bfe124a53a9f@linaro.org Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit e94314b727683f2b2d969a85e88d730caa7fe180 Author: Kris Van Hees Date: Fri Mar 7 11:53:28 2025 -0500 kbuild: exclude .rodata.(cst|str)* when building ranges commit 87bb368d0637c466a8a77433837056f981d01991 upstream. The .rodata.(cst|str)* sections are often resized during the final linking and since these sections do not cover actual symbols there is no need to include them in the modules.builtin.ranges data. When these sections were included in processing and resizing occurred, modules were reported with ranges that extended beyond their true end, causing subsequent symbols (in address order) to be associated with the wrong module. Fixes: 5f5e7344322f ("kbuild: generate offset range data for builtin modules") Cc: stable@vger.kernel.org Signed-off-by: Kris Van Hees Reviewed-by: Jack Vogel Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit 9eaec071f111cd2124ce9a5b93536d3f6837d457 Author: Jan Kara Date: Thu Feb 6 10:46:58 2025 +0100 jbd2: remove wrong sb->s_sequence check commit e6eff39dd0fe4190c6146069cc16d160e71d1148 upstream. Journal emptiness is not determined by sb->s_sequence == 0 but rather by sb->s_start == 0 (which is set a few lines above). Furthermore 0 is a valid transaction ID so the check can spuriously trigger. Remove the invalid WARN_ON. CC: stable@vger.kernel.org Signed-off-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20250206094657.20865-3-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit e6bba328578feb58c614c11868c259b40484c5fa Author: Manjunatha Venkatesh Date: Wed Mar 26 18:00:46 2025 +0530 i3c: Add NULL pointer check in i3c_master_queue_ibi() commit bd496a44f041da9ef3afe14d1d6193d460424e91 upstream. The I3C master driver may receive an IBI from a target device that has not been probed yet. In such cases, the master calls `i3c_master_queue_ibi()` to queue an IBI work task, leading to "Unable to handle kernel read from unreadable memory" and resulting in a kernel panic. Typical IBI handling flow: 1. The I3C master scans target devices and probes their respective drivers. 2. The target device driver calls `i3c_device_request_ibi()` to enable IBI and assigns `dev->ibi = ibi`. 3. The I3C master receives an IBI from the target device and calls `i3c_master_queue_ibi()` to queue the target device driver’s IBI handler task. However, since target device events are asynchronous to the I3C probe sequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`, leading to a kernel panic. Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessing an uninitialized `dev->ibi`, ensuring stability. Fixes: 3a379bbcea0af ("i3c: Add core I3C infrastructure") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/lkml/Z9gjGYudiYyl3bSe@lizhi-Precision-Tower-5810/ Signed-off-by: Manjunatha Venkatesh Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250326123047.2797946-1-manjunatha.venkatesh@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 34aaf448e204b83bf59dbfb5f15d191d7ae51eee Author: Stanley Chu Date: Tue Mar 18 13:36:05 2025 +0800 i3c: master: svc: Use readsb helper for reading MDB commit c06acf7143bddaa3c0f7bedd8b99e48f6acb85c3 upstream. The target can send the MDB byte followed by additional data bytes. The readl on MRDATAB reads one actual byte, but the readsl advances the destination pointer by 4 bytes. This causes the subsequent payload to be copied to wrong position in the destination buffer. Cc: stable@kernel.org Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver") Signed-off-by: Stanley Chu Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250318053606.3087121-3-yschu@nuvoton.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 0327683c5571dc24f07c1c45c17a9a08fa38b592 Author: Mimi Zohar Date: Mon Jan 27 10:45:48 2025 -0500 ima: limit the number of ToMToU integrity violations commit a414016218ca97140171aa3bb926b02e1f68c2cc upstream. Each time a file in policy, that is already opened for read, is opened for write, a Time-of-Measure-Time-of-Use (ToMToU) integrity violation audit message is emitted and a violation record is added to the IMA measurement list. This occurs even if a ToMToU violation has already been recorded. Limit the number of ToMToU integrity violations per file open for read. Note: The IMA_MAY_EMIT_TOMTOU atomic flag must be set from the reader side based on policy. This may result in a per file open for read ToMToU violation. Since IMA_MUST_MEASURE is only used for violations, rename the atomic IMA_MUST_MEASURE flag to IMA_MAY_EMIT_TOMTOU. Cc: stable@vger.kernel.org # applies cleanly up to linux-6.6 Tested-by: Stefan Berger Reviewed-by: Petr Vorel Tested-by: Petr Vorel Reviewed-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 48085ab823f00cb7a63ce1cdf2185214d89590a2 Author: Mimi Zohar Date: Mon Jan 27 10:24:13 2025 -0500 ima: limit the number of open-writers integrity violations commit 5b3cd801155f0b34b0b95942a5b057c9b8cad33e upstream. Each time a file in policy, that is already opened for write, is opened for read, an open-writers integrity violation audit message is emitted and a violation record is added to the IMA measurement list. This occurs even if an open-writers violation has already been recorded. Limit the number of open-writers integrity violations for an existing file open for write to one. After the existing file open for write closes (__fput), subsequent open-writers integrity violations may be emitted. Cc: stable@vger.kernel.org # applies cleanly up to linux-6.6 Tested-by: Stefan Berger Reviewed-by: Petr Vorel Tested-by: Petr Vorel Reviewed-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 9a264e4a595df65eeeaf35d3ba4af8c73a9ffb36 Author: Steve French Date: Sun Apr 6 14:09:19 2025 -0500 smb311 client: fix missing tcon check when mounting with linux/posix extensions commit b365b9d404b7376c60c91cd079218bfef11b7822 upstream. When mounting the same share twice, once with the "linux" mount parameter (or equivalently "posix") and then once without (or e.g. with "nolinux"), we were incorrectly reusing the same tree connection for both mounts. This meant that the first mount of the share on the client, would cause subsequent mounts of that same share on the same client to ignore that mount parm ("linux" vs. "nolinux") and incorrectly reuse the same tcon. Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 44a2572a0fdcf3e7565763690d579b998a8f0562 Author: Chenyuan Yang Date: Wed Feb 12 15:35:18 2025 -0600 soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe() commit c8222ef6cf29dd7cad21643228f96535cc02b327 upstream. soc_dev_attr->revision could be NULL, thus, a pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 ("ice: Fix some null pointer dereference issues in ice_ptp.c"). This issue is found by our static analysis tool. Signed-off-by: Chenyuan Yang Link: https://lore.kernel.org/r/20250212213518.69432-1-chenyuan0y@gmail.com Fixes: 3253b7b7cd44 ("soc: samsung: Add exynos chipid driver support") Cc: Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit fbda9cac1bb3651ec4f994dba71ce7b186a81a0d Author: Olga Kornievskaia Date: Thu Feb 6 13:15:34 2025 -0500 svcrdma: do not unregister device for listeners commit 750037aa0a9f28d84df3dcf319a28423d69092fd upstream. On an rdma-capable machine, a start/stop/start and then on a stop of a knfsd server would lead kref underflow warning because svc_rdma_free would indiscriminately unregister the rdma device but a listening transport never calls the rdma_rn_register() thus leading to kref going down to 0 on the 1st stop of the server and on the 2nd stop it leads to a problem. Suggested-by: Chuck Lever Fixes: c4de97f7c454 ("svcrdma: Handle device removal outside of the CM event handler") Signed-off-by: Olga Kornievskaia Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit f3cb81cb96d587f9f235a11789d1ec0992643078 Author: Thadeu Lima de Souza Cascardo Date: Fri Feb 7 15:07:46 2025 -0300 tpm: do not start chip while suspended commit 17d253af4c2c8a2acf84bb55a0c2045f150b7dfd upstream. Checking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can lead to a spurious tpm_chip_start() call: [35985.503771] i2c i2c-1: Transfer while suspended [35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810 [35985.503802] Modules linked in: [35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f [35985.503814] Tainted: [W]=WARN [35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023 [35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810 [35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5 [35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246 [35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000 [35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001 [35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820 [35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120 [35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000 [35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0 [35985.503855] Call Trace: [35985.503859] [35985.503863] ? __warn+0xd4/0x260 [35985.503868] ? __i2c_transfer+0xbe/0x810 [35985.503874] ? report_bug+0xf3/0x210 [35985.503882] ? handle_bug+0x63/0xb0 [35985.503887] ? exc_invalid_op+0x16/0x50 [35985.503892] ? asm_exc_invalid_op+0x16/0x20 [35985.503904] ? __i2c_transfer+0xbe/0x810 [35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0 [35985.503920] tpm_cr50_i2c_read+0x8e/0x120 [35985.503928] tpm_cr50_request_locality+0x75/0x170 [35985.503935] tpm_chip_start+0x116/0x160 [35985.503942] tpm_try_get_ops+0x57/0x90 [35985.503948] tpm_find_get_ops+0x26/0xd0 [35985.503955] tpm_get_random+0x2d/0x80 Don't move forward with tpm_chip_start() inside tpm_try_get_ops(), unless TPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in such a failure case. Fixes: 9265fed6db60 ("tpm: Lock TPM chip in tpm_pm_suspend() first") Signed-off-by: Thadeu Lima de Souza Cascardo Cc: stable@vger.kernel.org Cc: Jerry Snitselaar Cc: Mike Seo Cc: Jarkko Sakkinen Reviewed-by: Jerry Snitselaar Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 76cc21a9a40f2ed8bc74bb040a8e188070872d59 Author: Jan Kara Date: Wed Mar 12 16:18:39 2025 +0100 udf: Fix inode_getblk() return value commit 6afdc60ec30b0a9390d11b7cebed79c857ce82aa upstream. Smatch noticed that inode_getblk() can return 1 on successful mapping of a block instead of expected 0 after commit b405c1e58b73 ("udf: refactor udf_next_aext() to handle error"). This could confuse some of the callers and lead to strange failures (although the one reported by Smatch in udf_mkdir() is impossible to trigger in practice). Fix the return value of inode_getblk(). Link: https://lore.kernel.org/all/cb514af7-bbe0-435b-934f-dd1d7a16d2cd@stanley.mountain Reported-by: Dan Carpenter Reviewed-by: Carlos Maiolino Fixes: b405c1e58b73 ("udf: refactor udf_next_aext() to handle error") CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 8fd217a99dbbe64ef533c08ad13b0f1df35f4cf5 Author: Si-Wei Liu Date: Thu Feb 20 21:37:33 2025 +0200 vdpa/mlx5: Fix oversized null mkey longer than 32bit commit a6097e0a54a5c24f8d577ffecbc35289ae281c2e upstream. create_user_mr() has correct code to count the number of null keys used to fill in a hole for the memory map. However, fill_indir() does not follow the same to cap the range up to the 1GB limit correspondingly. Fill in more null keys for the gaps in between, so that null keys are correctly populated. Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code") Cc: stable@vger.kernel.org Reported-by: Cong Meng Signed-off-by: Si-Wei Liu Signed-off-by: Dragos Tatulea Acked-by: Eugenio Pérez Message-Id: <20250220193732.521462-2-dtatulea@nvidia.com> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Greg Kroah-Hartman commit a1dde7457d5722a8f54fbceb98aafdeb0e31e5e1 Author: Yeongjin Gil Date: Fri Mar 14 21:06:51 2025 +0900 f2fs: fix to avoid atomicity corruption of atomic file commit f098aeba04c9328571567dca45159358a250240c upstream. In the case of the following call stack for an atomic file, FI_DIRTY_INODE is set, but FI_ATOMIC_DIRTIED is not subsequently set. f2fs_file_write_iter f2fs_map_blocks f2fs_reserve_new_blocks inc_valid_block_count __mark_inode_dirty(dquot) f2fs_dirty_inode If FI_ATOMIC_DIRTIED is not set, atomic file can encounter corruption due to a mismatch between old file size and new data. To resolve this issue, I changed to set FI_ATOMIC_DIRTIED when FI_DIRTY_INODE is set. This ensures that FI_DIRTY_INODE, which was previously cleared by the Writeback thread during the commit atomic, is set and i_size is updated. Cc: Fixes: fccaa81de87e ("f2fs: prevent atomic file from being dirtied before commit") Reviewed-by: Sungjong Seo Reviewed-by: Sunmin Jeong Signed-off-by: Yeongjin Gil Reviewed-by: Daeho Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 16d9067f00e3a7d1df7c3aa9c20d214923d27e10 Author: Artem Sadovnikov Date: Fri Apr 4 08:28:05 2025 +0000 ext4: fix off-by-one error in do_split commit 94824ac9a8aaf2fb3c54b4bdde842db80ffa555d upstream. Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split. BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847 CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 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 The following loop is located right above 'if' statement. for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; } 'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Cc: stable@vger.kernel.org Fixes: 5872331b3d91 ("ext4: fix potential negative array index in do_split()") Signed-off-by: Artem Sadovnikov Reviewed-by: Jan Kara Link: https://patch.msgid.link/20250404082804.2567-3-a.sadovnikov@ispras.ru Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit a77955f7704b2a00385e232cbcc1cb06b5c7a425 Author: Jeff Hugo Date: Thu Mar 6 10:29:13 2025 -0700 bus: mhi: host: Fix race between unprepare and queue_buf commit 0686a818d77a431fc3ba2fab4b46bbb04e8c9380 upstream. A client driver may use mhi_unprepare_from_transfer() to quiesce incoming data during the client driver's tear down. The client driver might also be processing data at the same time, resulting in a call to mhi_queue_buf() which will invoke mhi_gen_tre(). If mhi_gen_tre() runs after mhi_unprepare_from_transfer() has torn down the channel, a panic will occur due to an invalid dereference leading to a page fault. This occurs because mhi_gen_tre() does not verify the channel state after locking it. Fix this by having mhi_gen_tre() confirm the channel state is valid, or return error to avoid accessing deinitialized data. Cc: stable@vger.kernel.org # 6.8 Fixes: b89b6a863dd5 ("bus: mhi: host: Add spinlock to protect WP access when queueing TREs") Signed-off-by: Jeffrey Hugo Signed-off-by: Jeff Hugo Reviewed-by: Krishna Chaitanya Chundru Reviewed-by: Youssef Samir Reviewed-by: Manivannan Sadhasivam Reviewed-by: Troy Hanson Link: https://lore.kernel.org/r/20250306172913.856982-1-jeff.hugo@oss.qualcomm.com [mani: added stable tag] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman commit 7d12a7d43c7bab9097ba466581d8db702e7908dc Author: Jacek Lawrynowicz Date: Tue Mar 25 12:43:05 2025 +0100 accel/ivpu: Fix deadlock in ivpu_ms_cleanup() commit 9a6f56762d23a1f3af15e67901493c927caaf882 upstream. Fix deadlock in ivpu_ms_cleanup() by preventing runtime resume after file_priv->ms_lock is acquired. During a failure in runtime resume, a cold boot is executed, which calls ivpu_ms_cleanup_all(). This function calls ivpu_ms_cleanup() that acquires file_priv->ms_lock and causes the deadlock. Fixes: cdfad4db7756 ("accel/ivpu: Add NPU profiling support") Cc: stable@vger.kernel.org # v6.11+ Signed-off-by: Maciej Falkowski Reviewed-by: Lizhi Hou Signed-off-by: Jacek Lawrynowicz Link: https://lore.kernel.org/r/20250325114306.3740022-2-maciej.falkowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 5c200b7ebdf932d0f61c68815b8867792c01663c Author: Jacek Lawrynowicz Date: Tue Mar 25 12:42:19 2025 +0100 accel/ivpu: Fix warning in ivpu_ipc_send_receive_internal() commit 6b4568b675b14cf890c0c21779773c3e08e80ce5 upstream. Warn if device is suspended only when runtime PM is enabled. Runtime PM is disabled during reset/recovery and it is not an error to use ivpu_ipc_send_receive_internal() in such cases. Fixes: 5eaa49741119 ("accel/ivpu: Prevent recovery invocation during probe and resume") Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Maciej Falkowski Reviewed-by: Lizhi Hou Signed-off-by: Jacek Lawrynowicz Link: https://lore.kernel.org/r/20250325114219.3739951-1-maciej.falkowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 7022946773d7bd5e834ab4398b5797ce261c5a2b Author: Sharan Kumar M Date: Sat Mar 29 21:11:06 2025 +0530 ALSA: hda/realtek: Enable Mute LED on HP OMEN 16 Laptop xd000xx commit e5182305a5199246dbcb4053299dcb1c8867b6ff upstream. This patch adds the HP OMEN 16 Laptop xd000xx to enable mute led. it uses ALC245_FIXUP_HP_MUTE_LED_COEFBIT with a slight modification setting mute_led_coef.off to 0(it was set to 4 i guess in that function) which i referred to your previous patch disscusion https://bugzilla.kernel.org/show_bug.cgi?id=214735 . i am not sure whether i can modify the current working function so i added another version calling ALC245_FIXUP_HP_MUTE_LED_V1_COEFBIT. and both works for me. Tested on 6.13.4-arch1-1 to 6.14.0-arch1-1 Signed-off-by: Sharan Kumar M Cc: Link: https://patch.msgid.link/20250329154105.7618-2-sharweshraajan@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d2a2076d9cb7492a8435b5c7f589c796b144361b Author: Alexey Klimov Date: Thu Mar 27 15:46:50 2025 +0000 ASoC: qdsp6: q6asm-dai: fix q6asm_dai_compr_set_params error path commit 7eccc86e90f04a0d758d16c08627a620ac59604d upstream. In case of attempts to compress playback something, for instance, when audio routing is not set up correctly, the audio DSP is left in inconsistent state because we are not doing the correct things in the error path of q6asm_dai_compr_set_params(). So, when routing is not set up and compress playback is attempted the following errors are present (simplified log): q6routing routing: Routing not setup for MultiMedia-1 Session q6asm-dai dais: Stream reg failed ret:-22 q6asm-dai dais: ASoC error (-22): at snd_soc_component_compr_set_params() on 17300000.remoteproc:glink-edge:apr:service@7:dais After setting the correct routing the compress playback will always fail: q6asm-dai dais: cmd = 0x10db3 returned error = 0x9 q6asm-dai dais: DSP returned error[9] q6asm-dai dais: q6asm_open_write failed q6asm-dai dais: ASoC error (-22): at snd_soc_component_compr_set_params() on 17300000.remoteproc:glink-edge:apr:service@7:dais 0x9 here means "Operation is already processed". The CMD_OPEN here was sent the second time hence DSP responds that it was already done. Turns out the CMD_CLOSE should be sent after the q6asm_open_write() succeeded but something failed after that, for instance, routing setup. Fix this by slightly reworking the error path in q6asm_dai_compr_set_params(). Tested on QRB5165 RB5 and SDM845 RB3 boards. Cc: stable@vger.kernel.org Fixes: 5b39363e54cc ("ASoC: q6asm-dai: prepare set params to accept profile change") Cc: Srinivas Kandagatla Cc: Vinod Koul Cc: Pierre-Louis Bossart Signed-off-by: Alexey Klimov Reviewed-by: Srinivas Kandagatla Link: https://patch.msgid.link/20250327154650.337404-1-alexey.klimov@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 17f1e421311360cb8fd363c1236a142b8a99f72c Author: Srinivas Kandagatla Date: Fri Mar 14 17:48:00 2025 +0000 ASoC: qdsp6: q6apm-dai: fix capture pipeline overruns. commit 5d01ed9b9939b4c726be74db291a982bc984c584 upstream. Period sizes less than 6k for capture path triggers overruns in the dsp capture pipeline. Change the period size and number of periods to value which DSP is happy with. Fixes: 9b4fe0f1cd79 ("ASoC: qdsp6: audioreach: add q6apm-dai support") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Tested-by: Krzysztof Kozlowski Tested-by: Johan Hovold Link: https://patch.msgid.link/20250314174800.10142-6-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit aa7e9eabe68ce69f213e8d234a53cdd76676664f Author: Srinivas Kandagatla Date: Fri Mar 14 17:47:59 2025 +0000 ASoC: qdsp6: q6apm-dai: set 10 ms period and buffer alignment. commit 3107019501842c27334554ba9d6583b1f200f61f upstream. DSP expects the periods to be aligned to fragment sizes, currently setting up to hw constriants on periods bytes is not going to work correctly as we can endup with periods sizes aligned to 32 bytes however not aligned to fragment size. Update the constriants to use fragment size, and also set at step of 10ms for period size to accommodate DSP requirements of 10ms latency. Fixes: 9b4fe0f1cd79 ("ASoC: qdsp6: audioreach: add q6apm-dai support") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Tested-by: Johan Hovold Link: https://patch.msgid.link/20250314174800.10142-5-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a28217b064f8619282a6d05e2bfc465c2f78b6e9 Author: Srinivas Kandagatla Date: Fri Mar 14 17:47:58 2025 +0000 ASoC: q6apm-dai: make use of q6apm_get_hw_pointer commit a93dad6f4e6a04a5943f6ee5686585f24abf7063 upstream. With the existing code, the buffer position is only reset in pointer callback, which leaves the possiblity of it going over the size of buffer size and reporting incorrect position to userspace. Without this patch, its possible to see errors like: snd-x1e80100 sound: invalid position: pcmC0D0p:0, pos = 12288, buffer size = 12288, period size = 1536 snd-x1e80100 sound: invalid position: pcmC0D0p:0, pos = 12288, buffer size = 12288, period size = 1536 Fixes: 9b4fe0f1cd791 ("ASoC: qdsp6: audioreach: add q6apm-dai support") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Tested-by: Krzysztof Kozlowski Tested-by: Johan Hovold Link: https://patch.msgid.link/20250314174800.10142-4-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f5891f204d1381ba40cef9bf8f13f579e17250a2 Author: Srinivas Kandagatla Date: Fri Mar 14 17:47:56 2025 +0000 ASoC: q6apm-dai: schedule all available frames to avoid dsp under-runs commit 3d4a4411aa8bbc3653ff22a1ff0432eb93d22ae0 upstream. With the existing code, we are only setting up one period at a time, in a ping-pong buffer style. This triggers lot of underruns in the dsp leading to jitter noise during audio playback. Fix this by scheduling all available periods, this will ensure that the dsp has enough buffer feed and ultimatley fixing the underruns and audio distortion. Fixes: 9b4fe0f1cd79 ("ASoC: qdsp6: audioreach: add q6apm-dai support") Cc: stable@vger.kernel.org Reported-by: Krzysztof Kozlowski Signed-off-by: Srinivas Kandagatla Tested-by: Krzysztof Kozlowski Tested-by: Johan Hovold Link: https://patch.msgid.link/20250314174800.10142-2-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d383051f8293f564a5f82052e25048c18aced33e Author: Srinivas Kandagatla Date: Fri Mar 14 17:47:57 2025 +0000 ASoC: q6apm: add q6apm_get_hw_pointer helper commit 0badb5432fd525a00db5630c459b635e9d47f445 upstream. Implement an helper function in q6apm to be able to read the current hardware pointer for both read and write buffers. This should help q6apm-dai to get the hardware pointer consistently without it doing manual calculation, which could go wrong in some race conditions. Fixes: 9b4fe0f1cd79 ("ASoC: qdsp6: audioreach: add q6apm-dai support") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Tested-by: Krzysztof Kozlowski Tested-by: Johan Hovold Link: https://patch.msgid.link/20250314174800.10142-3-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit acadb2e2b3c5b9977a843a3a94fece9bdcf6aea1 Author: Haoxiang Li Date: Wed Feb 26 16:50:50 2025 +0800 ASoC: codecs: wcd937x: fix a potential memory leak in wcd937x_soc_codec_probe() commit 3e330acf4efd63876d673c046cd073a1d4ed57a8 upstream. When snd_soc_dapm_new_controls() or snd_soc_dapm_add_routes() fails, wcd937x_soc_codec_probe() returns without releasing 'wcd937x->clsh_info', which is allocated by wcd_clsh_ctrl_alloc. Add wcd_clsh_ctrl_free() to prevent potential memory leak. Fixes: 313e978df7fc ("ASoC: codecs: wcd937x: add audio routing and Kconfig") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20250226085050.3584898-1-haoxiang_li2024@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3e0356857ed5986d62203a567cd5e51513643176 Author: Jens Axboe Date: Mon Apr 7 07:51:23 2025 -0600 io_uring/kbuf: reject zero sized provided buffers commit cf960726eb65e8d0bfecbcce6cf95f47b1ffa6cc upstream. This isn't fixing a real issue, but there's also zero point in going through group and buffer setup, when the buffers are going to be rejected once attempted to get used. Cc: stable@vger.kernel.org Reported-by: syzbot+58928048fd1416f1457c@syzkaller.appspotmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b7c6d081c19a5e11bbd77bb97a62cff2b6b21cb5 Author: Pavel Begunkov Date: Thu Mar 27 09:57:27 2025 +0000 io_uring/net: fix io_req_post_cqe abuse by send bundle commit 6889ae1b4df1579bcdffef023e2ea9a982565dff upstream. [ 114.987980][ T5313] WARNING: CPU: 6 PID: 5313 at io_uring/io_uring.c:872 io_req_post_cqe+0x12e/0x4f0 [ 114.991597][ T5313] RIP: 0010:io_req_post_cqe+0x12e/0x4f0 [ 115.001880][ T5313] Call Trace: [ 115.002222][ T5313] [ 115.007813][ T5313] io_send+0x4fe/0x10f0 [ 115.009317][ T5313] io_issue_sqe+0x1a6/0x1740 [ 115.012094][ T5313] io_wq_submit_work+0x38b/0xed0 [ 115.013223][ T5313] io_worker_handle_work+0x62a/0x1600 [ 115.013876][ T5313] io_wq_worker+0x34f/0xdf0 As the comment states, io_req_post_cqe() should only be used by multishot requests, i.e. REQ_F_APOLL_MULTISHOT, which bundled sends are not. Add a flag signifying whether a request wants to post multiple CQEs. Eventually REQ_F_APOLL_MULTISHOT should imply the new flag, but that's left out for simplicity. Cc: stable@vger.kernel.org Fixes: a05d1f625c7aa ("io_uring/net: support bundles for send") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/8b611dbb54d1cd47a88681f5d38c84d0c02bc563.1743067183.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0828d6e9add67ce4f893c5fbb31ec6c23f34426c Author: Pavel Begunkov Date: Sun Feb 23 17:22:29 2025 +0000 io_uring/net: fix accept multishot handling commit f6a89bf5278d6e15016a736db67043560d1b50d5 upstream. REQ_F_APOLL_MULTISHOT doesn't guarantee it's executed from the multishot context, so a multishot accept may get executed inline, fail io_req_post_cqe(), and ask the core code to kill the request with -ECANCELED by returning IOU_STOP_MULTISHOT even when a socket has been accepted and installed. Cc: stable@vger.kernel.org Fixes: 390ed29b5e425 ("io_uring: add IORING_ACCEPT_MULTISHOT for accept") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/51c6deb01feaa78b08565ca8f24843c017f5bc80.1740331076.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 00026f80c430077f7298262d14d783b33ec23342 Author: Ming Yen Hsieh Date: Tue Mar 4 16:08:48 2025 -0800 wifi: mt76: mt7925: fix the wrong simultaneous cap for MLO commit 7dcea6fe33ee3d7cbb65baee0dd7adc76d1c9ddc upstream. The mt7925 chip is only support a single radio, so the maximum number of simultaneous should be 0. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Cc: stable@vger.kernel.org Co-developed-by: Sean Wang Signed-off-by: Sean Wang Tested-by: Caleb Jorden Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250305000851.493671-3-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 374f2bf7b3ffa9d176dd096c8a04cb33033542b6 Author: Ming Yen Hsieh Date: Tue Mar 4 16:08:47 2025 -0800 wifi: mt76: mt7925: fix the wrong link_idx when a p2p_device is present commit 4bada9b0a29c185d45cc9512509edd6069fbfa79 upstream. When the p2p device and MLO station are running concurrently, the p2p device will occupy the wrong link_idx when the MLO secondary link is added. Fixes: 9e4c3a007f01 ("wifi: mt76: connac: Extend mt76_connac_mcu_uni_add_dev for MLO") Cc: stable@vger.kernel.org Co-developed-by: Sean Wang Signed-off-by: Sean Wang Tested-by: Caleb Jorden Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250305000851.493671-2-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 0dd6c62c1370918eb5c38b00cb0ca1b64a9c9302 Author: Ming Yen Hsieh Date: Thu Jan 16 14:21:31 2025 +0800 wifi: mt76: mt7925: fix country count limitation for CLC commit 6458d760a0c0afd2fda11e83ed3e1125a252432f upstream. Due to the increase in the number of power tables for 6Ghz on CLC, the variable nr_country is no longer sufficient to represent the total quantity. Therefore, we have switched to calculating the length of clc buf to obtain the correct power table. Cc: stable@vger.kernel.org Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250116062131.3860198-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 1706a07b38ae061ca42acfa004d0d49d1f1fe786 Author: Ming Yen Hsieh Date: Thu Jan 16 13:59:25 2025 +0800 wifi: mt76: mt7925: ensure wow pattern command align fw format commit 8ae45b1f699bbc27ea8647093f794f671e77410b upstream. Align the format of "struct mt7925_wow_pattern_tlv" with firmware to ensure proper functionality. Cc: stable@vger.kernel.org Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250116055925.3856856-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit eb434adf79ddb0a6296fe82b04ae6f483dc28466 Author: Gavrilov Ilia Date: Wed Feb 12 08:21:25 2025 +0000 wifi: mac80211: fix integer overflow in hwmp_route_info_get() commit d00c0c4105e5ab8a6a13ed23d701cceb285761fa upstream. Since the new_metric and last_hop_metric variables can reach the MAX_METRIC(0xffffffff) value, an integer overflow may occur when multiplying them by 10/9. It can lead to incorrect behavior. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a8d418d9ac25 ("mac80211: mesh: only switch path when new metric is at least 10% better") Cc: stable@vger.kernel.org Signed-off-by: Ilia Gavrilov Link: https://patch.msgid.link/20250212082124.4078236-1-Ilia.Gavrilov@infotecs.ru Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit ef44c9e81172fd3495ae0852047510b6dfdb4e40 Author: Haoxiang Li Date: Wed Feb 19 11:36:45 2025 +0800 wifi: mt76: Add check for devm_kstrdup() commit 4bc1da524b502999da28d287de4286c986a1af57 upstream. Add check for the return value of devm_kstrdup() in mt76_get_of_data_from_mtd() to catch potential exception. Fixes: e7a6a044f9b9 ("mt76: testmode: move mtd part to mt76_dev") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20250219033645.2594753-1-haoxiang_li2024@163.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 9d6b789a8ff95d4fc4df389f4c57693b11c3f5c8 Author: Alexandre Torgue Date: Thu Mar 6 11:25:01 2025 +0100 clocksource/drivers/stm32-lptimer: Use wakeup capable instead of init wakeup commit 96bf4b89a6ab22426ad83ef76e66c72a5a8daca0 upstream. "wakeup-source" property describes a device which has wakeup capability but should not force this device as a wakeup source. Fixes: 48b41c5e2de6 ("clocksource: Add Low Power STM32 timers driver") Cc: stable@vger.kernel.org Signed-off-by: Alexandre Torgue Signed-off-by: Fabrice Gasnier Rule: add Link: https://lore.kernel.org/stable/20250306083407.2374894-1-fabrice.gasnier%40foss.st.com Link: https://lore.kernel.org/r/20250306102501.2980153-1-fabrice.gasnier@foss.st.com Signed-off-by: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman commit 9d99358349e4600601dc2dae5f6fe349e744564c Author: Jiasheng Jiang Date: Wed Feb 5 02:31:40 2025 +0000 mtd: Replace kcalloc() with devm_kcalloc() commit 1b61a59876f0eafc19b23007c522ee407f55dbec upstream. Replace kcalloc() with devm_kcalloc() to prevent memory leaks in case of errors. Fixes: 78c08247b9d3 ("mtd: Support kmsg dumper based on pstore/blk") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Jiasheng Jiang Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 2b27df6852444b76724f5d425826a38581d63407 Author: Marek Behún Date: Mon Mar 17 18:32:49 2025 +0100 net: dsa: mv88e6xxx: fix internal PHYs for 6320 family commit 52fdc41c3278c981066a461d03d5477ebfcf270c upstream. Fix internal PHYs definition for the 6320 family, which has only 2 internal PHYs (on ports 3 and 4). Fixes: bc3931557d1d ("net: dsa: mv88e6xxx: Add number of internal PHYs") Signed-off-by: Marek Behún Cc: # 6.6.x Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250317173250.28780-7-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 020404265b871a74730bdebdeafa6c8ebecf2188 Author: Marek Behún Date: Mon Mar 17 18:32:50 2025 +0100 net: dsa: mv88e6xxx: workaround RGMII transmit delay erratum for 6320 family commit 1ebc8e1ef906db9c08e9abe9776d85ddec837725 upstream. Implement the workaround for erratum 3.3 RGMII timing may be out of spec when transmit delay is enabled for the 6320 family, which says: When transmit delay is enabled via Port register 1 bit 14 = 1, duty cycle may be out of spec. Under very rare conditions this may cause the attached device receive CRC errors. Signed-off-by: Marek Behún Cc: # 5.4.x Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250317173250.28780-8-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 39fc12742292ed1ba38ac0f08ac324b1ad6ca297 Author: Jiasheng Jiang Date: Wed Feb 5 02:31:41 2025 +0000 mtd: Add check for devm_kcalloc() commit 2aee30bb10d7bad0a60255059c9ce1b84cf0130e upstream. Add a check for devm_kcalloc() to ensure successful allocation. Fixes: 78c08247b9d3 ("mtd: Support kmsg dumper based on pstore/blk") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Jiasheng Jiang Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 91e1405088a9e31b61acbd6774d98f23fbd2d95a Author: Matthieu Baerts (NGI0) Date: Fri Mar 14 21:11:33 2025 +0100 mptcp: sockopt: fix getting freebind & transparent commit e2f4ac7bab2205d3c4dd9464e6ffd82502177c51 upstream. When adding a socket option support in MPTCP, both the get and set parts are supposed to be implemented. IP(V6)_FREEBIND and IP(V6)_TRANSPARENT support for the setsockopt part has been added a while ago, but it looks like the get part got forgotten. It should have been present as a way to verify a setting has been set as expected, and not to act differently from TCP or any other socket types. Everything was in place to expose it, just the last step was missing. Only new code is added to cover these specific getsockopt(), that seems safe. Fixes: c9406a23c116 ("mptcp: sockopt: add SOL_IP freebind & transparent options") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250314-net-mptcp-fix-data-stream-corr-sockopt-v1-3-122dbb249db3@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 1b4ecd033e3066fa82b4ed33b66deffef2e9c7cb Author: Matthieu Baerts (NGI0) Date: Fri Mar 14 21:11:32 2025 +0100 mptcp: sockopt: fix getting IPV6_V6ONLY commit 8c39633759885b6ff85f6d96cf445560e74df5e8 upstream. When adding a socket option support in MPTCP, both the get and set parts are supposed to be implemented. IPV6_V6ONLY support for the setsockopt part has been added a while ago, but it looks like the get part got forgotten. It should have been present as a way to verify a setting has been set as expected, and not to act differently from TCP or any other socket types. Not supporting this getsockopt(IPV6_V6ONLY) blocks some apps which want to check the default value, before doing extra actions. On Linux, the default value is 0, but this can be changed with the net.ipv6.bindv6only sysctl knob. On Windows, it is set to 1 by default. So supporting the get part, like for all other socket options, is important. Everything was in place to expose it, just the last step was missing. Only new code is added to cover this specific getsockopt(), that seems safe. Fixes: c9b95a135987 ("mptcp: support IPV6_V6ONLY setsockopt") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/550 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250314-net-mptcp-fix-data-stream-corr-sockopt-v1-2-122dbb249db3@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit c59dc7c425cc17dd7b0ebde27fbff4ff7092598d Author: Jackson.lee Date: Tue Dec 17 13:51:25 2024 +0900 media: chips-media: wave5: Fix timeout while testing 10bit hevc fluster commit 035371c9e5098018b8512efc6a8812912469480c upstream. The Wave5 521C variant does not support 10 bit decoding. When 10 bit decoding support was added for the 515 variant, a section of the code was removed which returned an error. This removal causes a timeout for the 521 variant, which was discovered during HEVC 10-bit decoding tests. Fixes: 143e7ab4d9a0 ("media: chips-media: wave5: support decoding HEVC Main10 profile") Cc: stable@vger.kernel.org Signed-off-by: Jackson.lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit d595713de7f867d9fc6ad7bef9e9776f9977067b Author: Jackson.lee Date: Tue Dec 17 13:51:24 2024 +0900 media: chips-media: wave5: Fix a hang after seeking commit a2c75e964e51b096e9fe6adfa3eaed53594a668b upstream. While seeking, the driver calls the flush command. Before the flush command is sent to the VPU, the driver should handle the display buffer flags and should get all decoded information from the VPU if the VCORE is running. Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson.lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 76cab9f540cce46e8cf9a3189a20a40870e5d36c Author: Jackson.lee Date: Tue Dec 17 13:51:23 2024 +0900 media: chips-media: wave5: Avoid race condition in the interrupt handler commit ac35f768986610480a1c01323d9cf9f5eaf3ee9b upstream. In case of multiple active instances, new interrupts can occur as soon as the current interrupt is cleared. If the driver reads the instance_info after clearing the interrupt, then there is no guarantee, that the instance_info is still valid for the current interrupt. Read the instance_info register for each interrupt before clearing the interrupt. Fixes: ed7276ed2fd0 ("media: chips-media: wave5: Add hrtimer based polling support") Cc: stable@vger.kernel.org Signed-off-by: Jackson.lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 7fafaf00cc5fd1fd7b828a1dc73bda79683b629b Author: Jackson.lee Date: Tue Dec 17 13:51:22 2024 +0900 media: chips-media: wave5: Fix gray color on screen commit 6bae4d5053da634eecb611118e7cd91a677a4bbf upstream. When a decoder instance is created, the W5_CMD_ERR_CONCEAL register should be initialized to 0. Otherwise, gray color is occasionally displayed on the screen while decoding. Fixes: 45d1a2b93277 ("media: chips-media: wave5: Add vpuapi layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson.lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6f77a6d2ea31dd8a0a59ba4f7eb0cd1b2ca4599a Author: Sakari Ailus Date: Fri Jan 10 14:36:01 2025 +0200 media: i2c: imx214: Rectify probe error handling related to runtime PM commit ccc888d1698b6f42d52ddf5cecfe50fe925c95e5 upstream. There were multiple issues in the driver's probe function related to error handling: - Device's PM runtime status wasn't reverted to suspended on some errors in probe. - Runtime PM was left enabled for the device on some probe errors. - Device was left powered on if a probe failure happened or when it was removed when it was powered on. - An extra pm_runtime_set_suspended() was issued in driver's remove function when the device was suspended. Fix these bugs. Fixes: 436190596241 ("media: imx214: Add imx214 camera sensor driver") Cc: stable@vger.kernel.org # for >= v6.12 Signed-off-by: Sakari Ailus Acked-by: André Apitzsch Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 8dd2d1561c6a42213ad2e118cef805ec81c544b1 Author: Sakari Ailus Date: Fri Jan 10 14:53:20 2025 +0200 media: i2c: imx219: Rectify runtime PM handling in probe and remove commit 42eceae9793566d0df53d509be3e416465c347f5 upstream. Set the device's runtime PM status and enable runtime PM before registering the async sub-device. This is needed to avoid the case where the device is runtime PM resumed while runtime PM has not been enabled yet. Also set the device's runtime PM status to suspended in remove only if it wasn't so already. Fixes: 1283b3b8f82b ("media: i2c: Add driver for Sony IMX219 sensor") Cc: stable@vger.kernel.org # for >= v6.6 Reviewed-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 99f929914713bff32737e703f67b39dedbb6bcc3 Author: Sakari Ailus Date: Fri Jan 10 14:55:59 2025 +0200 media: i2c: imx319: Rectify runtime PM handling probe and remove commit 5f5ffd3bc62b2e6c478061918b10473d8b90ac2d upstream. Idle the device only after the async sub-device has been successfully registered. In error handling, set the device's runtime PM status to suspended only if it has been set to active previously in probe. Also set the device's runtime PM status to suspended in remove only if it wasn't so already. Fixes: 8a89dc62f28c ("media: add imx319 camera sensor driver") Cc: stable@vger.kernel.org # for >= v6.12 Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit bb3fd8b7906a12dc2b61389abb742bf6542d97fb Author: Vikash Garodia Date: Thu Feb 20 22:50:09 2025 +0530 media: venus: hfi_parser: refactor hfi packet parsing logic commit 9edaaa8e3e15aab1ca413ab50556de1975bcb329 upstream. words_count denotes the number of words in total payload, while data points to payload of various property within it. When words_count reaches last word, data can access memory beyond the total payload. This can lead to OOB access. With this patch, the utility api for handling individual properties now returns the size of data consumed. Accordingly remaining bytes are calculated before parsing the payload, thereby eliminates the OOB access possibilities. Cc: stable@vger.kernel.org Fixes: 1a73374a04e5 ("media: venus: hfi_parser: add common capability parser") Signed-off-by: Vikash Garodia Reviewed-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 53e376178ceacca3ef1795038b22fc9ef45ff1d3 Author: Vikash Garodia Date: Thu Feb 20 22:50:08 2025 +0530 media: venus: hfi_parser: add check to avoid out of bound access commit 172bf5a9ef70a399bb227809db78442dc01d9e48 upstream. There is a possibility that init_codecs is invoked multiple times during manipulated payload from video firmware. In such case, if codecs_count can get incremented to value more than MAX_CODEC_NUM, there can be OOB access. Reset the count so that it always starts from beginning. Cc: stable@vger.kernel.org Fixes: 1a73374a04e5 ("media: venus: hfi_parser: add common capability parser") Reviewed-by: Bryan O'Donoghue Signed-off-by: Vikash Garodia Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 3da0d7318730a45fdba5623974f518c62188fea2 Author: Ricardo Ribalda Date: Mon Feb 24 07:03:55 2025 +0000 media: nuvoton: Fix reference handling of ece_pdev commit 453d5cadab1bde8e6fdd5bd05f4200338cb21e72 upstream. When we obtain a reference to of a platform_device, we need to release it via put_device. Found by cocci: ./platform/nuvoton/npcm-video.c:1677:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. ./platform/nuvoton/npcm-video.c:1684:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. ./platform/nuvoton/npcm-video.c:1690:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. ./platform/nuvoton/npcm-video.c:1694:1-7: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. Instead of manually calling put_device, use the __free macros. Cc: stable@vger.kernel.org Fixes: 46c15a4ff1f4 ("media: nuvoton: Add driver for NPCM video capture and encoding engine") Signed-off-by: Ricardo Ribalda Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4b1bdaadbf19f6c0d1a8d7e43418eb97c224a017 Author: Ricardo Ribalda Date: Mon Feb 24 07:03:54 2025 +0000 media: nuvoton: Fix reference handling of ece_node commit 8ba4ef40ad6ca62368292a69855324213181abfb upstream. Make sure all the code paths call of_node_put(). Instead of manually calling of_node_put, use the __free macros/helpers. Cc: stable@vger.kernel.org Fixes: 46c15a4ff1f4 ("media: nuvoton: Add driver for NPCM video capture and encoding engine") Signed-off-by: Ricardo Ribalda Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit e22fa60bcd85bb392422bf9f3210694893dc1347 Author: Sakari Ailus Date: Fri Jan 17 16:04:02 2025 +0200 media: i2c: ov7251: Introduce 1 ms delay between regulators and en GPIO commit 3d391292cdd53984ec1b9a1f6182a62a62751e03 upstream. Lift the xshutdown (enable) GPIO 1 ms after enabling the regulators, as required by the sensor's power-up sequence. Fixes: d30bb512da3d ("media: Add a driver for the ov7251 camera sensor") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Dave Stevenson Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit b155aecd7f0fdc36c8e06af424e280a5a4875c69 Author: Sakari Ailus Date: Fri Jan 17 15:38:13 2025 +0200 media: i2c: ov7251: Set enable GPIO low in probe commit a1963698d59cec83df640ded343af08b76c8e9c5 upstream. Set the enable GPIO low when acquiring it. Fixes: d30bb512da3d ("media: Add a driver for the ov7251 camera sensor") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Dave Stevenson Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit ad466aacb17f960e02854e45641462a9f6612f9a Author: Sakari Ailus Date: Fri Jan 10 15:54:22 2025 +0200 media: i2c: ccs: Set the device's runtime PM status correctly in probe commit 80704d14f1bd3628f578510e0a88b66824990ef6 upstream. Set the device's runtime PM status to suspended in probe error paths where it was previously set to active. Fixes: 9447082ae666 ("[media] smiapp: Implement power-on and power-off sequences without runtime PM") Cc: stable@vger.kernel.org # for >= v5.15 Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 983b5434a66b84a6c06c6d5dfe2dbe11e8feb5d2 Author: Sakari Ailus Date: Fri Jan 10 14:50:27 2025 +0200 media: i2c: ccs: Set the device's runtime PM status correctly in remove commit e04604583095faf455b3490b004254a225fd60d4 upstream. Set the device's runtime PM status to suspended in device removal only if it wasn't suspended already. Fixes: 9447082ae666 ("[media] smiapp: Implement power-on and power-off sequences without runtime PM") Cc: stable@vger.kernel.org # for >= v5.15 Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 3ff4feef7af388299a23a0a49a48679b633b0a0e Author: Sakari Ailus Date: Fri Jan 10 10:11:51 2025 +0200 Revert "media: imx214: Fix the error handling in imx214_probe()" commit abd88757252c2a2cea7909f3922de1f0e9e04002 upstream. This reverts commit 9bc92332cc3f06fda3c6e2423995ca2da0a7ec9a. Revert this "fix" as it's not really helpful but makes backporting a proper fix harder. Fixes: 9bc92332cc3f ("media: imx214: Fix the error handling in imx214_probe()") Cc: stable@vger.kernel.org # for >= v6.12 Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit baea1762cdf20cfd9d66014e79d773a1eeef67a1 Author: Karina Yankevich Date: Wed Aug 21 14:31:34 2024 +0300 media: v4l2-dv-timings: prevent possible overflow in v4l2_detect_gtf() commit 3edd1fc48d2c045e8259561797c89fe78f01717e upstream. In v4l2_detect_gtf(), it seems safer to cast the 32-bit image_width variable to the 64-bit type u64 before multiplying to avoid a possible overflow. The resulting object code even seems to look better, at least on x86_64. Found by Linux Verification Center (linuxtesting.org) with Svace. [Sergey: rewrote the patch subject/descripition] Fixes: c9bc9f50753d ("[media] v4l2-dv-timings: fix overflow in gtf timings calculation") Cc: stable@vger.kernel.org Signed-off-by: Karina Yankevich Signed-off-by: Sergey Shtylyov Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit b933486f6b8049dc1e05d263db848ec44b79f958 Author: Dave Stevenson Date: Thu Jan 23 15:37:49 2025 +0000 media: imx219: Adjust PLL settings based on the number of MIPI lanes commit 591a07588c03437dbcc3addfff07675de95a461e upstream. Commit ceddfd4493b3 ("media: i2c: imx219: Support four-lane operation") added support for device tree to allow configuration of the sensor to use 4 lanes with a link frequency of 363MHz, and amended the advertised pixel rate to 280.8MPix/s. However it didn't change any of the PLL settings, so actually it would have been running overclocked in the MIPI block, and with the frame rate and exposure calculations being wrong as the pixel rate was unchanged. The pixel rate and link frequency advertised were taken from the "Clock Setting Example" section of the datasheet. However those are based on an external clock of 12MHz, and are unachievable with a clock of 24MHz - it seems PREPLLCLK_VT_DIV and PREPLLCK_OP_DIV can ONLY be set via the automatic configuration documented in "9-1-2 EXCK_FREQ setting depend on INCK frequency", not by writing the registers. The closest we can get with a 24MHz clock is 281.6MPix/s and 364MHz. Dropping all support for the 363MHz link frequency would cause problems for existing users, so allow it, but log a warning that the requested value is being changed to the supported one. Fixes: ceddfd4493b3 ("media: i2c: imx219: Support four-lane operation") Cc: stable@vger.kernel.org Co-developed-by: Peyton Howe Signed-off-by: Peyton Howe Signed-off-by: Dave Stevenson Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit dd0d323b472f7251d09f5d4b5ce731ffad20e01b Author: Jiasheng Jiang Date: Fri Nov 22 20:46:03 2024 +0000 media: platform: stm32: Add check for clk_enable() commit f883f34b6a46b1a09d44d7f94c3cd72fe0e8f93b upstream. Add check for the return value of clk_enable() to gurantee the success. Fixes: 002e8f0d5927 ("media: stm32-dma2d: STM32 DMA2D driver") Cc: stable@vger.kernel.org Signed-off-by: Jiasheng Jiang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 3f1f712f80db845441eca5ae0d63b75f8736d975 Author: Nicolas Dufresne Date: Tue Dec 10 16:02:53 2024 -0500 media: visl: Fix ERANGE error when setting enum controls commit d98e9213a768a3cc3a99f5e1abe09ad3baff2104 upstream. The visl driver supports both frame and slice mode, with and without a start-code. But, the range and default for these enum controls was not set, which currently limits the decoder to enums with a value of 0. Fix this by setting the decoder mode and start code controls for both the H.264 and HEVC codecs. Fixes: 0c078e310b6d ("media: visl: add virtual stateless decoder driver") Cc: stable@vger.kernel.org Signed-off-by: Nicolas Dufresne Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f67c3f84520b4069761119e25cdf283bc026563c Author: Hans de Goede Date: Thu Dec 19 20:27:30 2024 +0100 media: hi556: Fix memory leak (on error) in hi556_check_hwcfg() commit ed554da65abd0c561e40d35272d1a61d030fe977 upstream. Commit 7d968b5badfc ("media: hi556: Return -EPROBE_DEFER if no endpoint is found") moved the v4l2_fwnode_endpoint_alloc_parse() call in hi556_check_hwcfg() up, but it did not make the error-exit paths between the old and new call-site use "goto check_hwcfg_error;" to free the bus_cfg on errors. Add the missing "goto check_hwcfg_error;" statements to fix a memleak on early error-exits from hi556_check_hwcfg(). Fixes: 7d968b5badfc ("media: hi556: Return -EPROBE_DEFER if no endpoint is found") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit df6ef66cc3ff93287d38b4bec043c8a0596a2701 Author: Murad Masimov Date: Mon Jan 13 13:51:31 2025 +0300 media: streamzap: prevent processing IR data on URB failure commit 549f6d348167fb2f7800ed7c8d4bce9630c74498 upstream. If streamzap_callback() receives an urb with any non-critical error status, i.e. any error code other than -ECONNRESET, -ENOENT or -ESHUTDOWN, it will try to process IR data, ignoring a possible transfer failure. Make streamzap_callback() process IR data only when urb->status is 0. Move processing logic to a separate function to make code cleaner and more similar to the URB completion handlers in other RC drivers. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 19770693c354 ("V4L/DVB: staging/lirc: add lirc_streamzap driver") Cc: stable@vger.kernel.org Signed-off-by: Murad Masimov Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit afada73000bef7c79a22f0d7e93fac414eeff19e Author: Jacek Lawrynowicz Date: Tue Mar 25 12:43:06 2025 +0100 accel/ivpu: Fix PM related deadlocks in MS IOCTLs commit d893da85e06edf54737bb80648bb58ba8fd56d9f upstream. Prevent runtime resume/suspend while MS IOCTLs are in progress. Failed suspend will call ivpu_ms_cleanup() that would try to acquire file_priv->ms_lock, which is already held by the IOCTLs. Fixes: cdfad4db7756 ("accel/ivpu: Add NPU profiling support") Cc: stable@vger.kernel.org # v6.11+ Signed-off-by: Maciej Falkowski Reviewed-by: Lizhi Hou Signed-off-by: Jacek Lawrynowicz Link: https://lore.kernel.org/r/20250325114306.3740022-3-maciej.falkowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 4c8056fbb17d652227b66f53162601b043a06ece Author: Jonathan McDowell Date: Wed Mar 12 07:31:57 2025 +0200 tpm, tpm_tis: Fix timeout handling when waiting for TPM status commit 7146dffa875cd00e7a7f918e1fce79c7593ac1fa upstream. The change to only use interrupts to handle supported status changes introduced an issue when it is necessary to poll for the status. Rather than checking for the status after sleeping the code now sleeps after the check. This means a correct, but slower, status change on the part of the TPM can be missed, resulting in a spurious timeout error, especially on a more loaded system. Switch back to sleeping *then* checking. An up front check of the status has been done at the start of the function, so this does not cause an additional delay when the status is already what we're looking for. Cc: stable@vger.kernel.org # v6.4+ Fixes: e87fcf0dc2b4 ("tpm, tpm_tis: Only handle supported interrupts") Signed-off-by: Jonathan McDowell Reviewed-by: Michal Suchánek Reviewed-by: Lino Sanfilippo Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 7266066b9469f04ed1d4c0fdddaea1425835eb55 Author: Kamal Dasu Date: Thu Feb 27 12:46:08 2025 -0500 mtd: rawnand: brcmnand: fix PM resume warning commit ddc210cf8b8a8be68051ad958bf3e2cef6b681c2 upstream. Fixed warning on PM resume as shown below caused due to uninitialized struct nand_operation that checks chip select field : WARN_ON(op->cs >= nanddev_ntargets(&chip->base) [ 14.588522] ------------[ cut here ]------------ [ 14.588529] WARNING: CPU: 0 PID: 1392 at drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8 [ 14.588553] Modules linked in: bdc udc_core [ 14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: G W 6.14.0-rc4-g5394eea10651 #16 [ 14.588590] Tainted: [W]=WARN [ 14.588593] Hardware name: Broadcom STB (Flattened Device Tree) [ 14.588598] Call trace: [ 14.588604] dump_backtrace from show_stack+0x18/0x1c [ 14.588622] r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c [ 14.588625] show_stack from dump_stack_lvl+0x70/0x7c [ 14.588639] dump_stack_lvl from dump_stack+0x18/0x1c [ 14.588653] r5:c08d40b0 r4:c1003cb0 [ 14.588656] dump_stack from __warn+0x84/0xe4 [ 14.588668] __warn from warn_slowpath_fmt+0x18c/0x194 [ 14.588678] r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000 [ 14.588681] warn_slowpath_fmt from nand_reset_op+0x1e0/0x1f8 [ 14.588695] r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048 [ 14.588697] nand_reset_op from brcmnand_resume+0x13c/0x150 [ 14.588714] r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040 [ 14.588717] brcmnand_resume from platform_pm_resume+0x34/0x54 [ 14.588735] r5:00000010 r4:c0840a50 [ 14.588738] platform_pm_resume from dpm_run_callback+0x5c/0x14c [ 14.588757] dpm_run_callback from device_resume+0xc0/0x324 [ 14.588776] r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r4:c24f8010 [ 14.588779] device_resume from dpm_resume+0x130/0x160 [ 14.588799] r9:c22539e4 r8:00000010 r7:c22bebb0 r6:c24f8010 r5:c22539dc r4:c22539b0 [ 14.588802] dpm_resume from dpm_resume_end+0x14/0x20 [ 14.588822] r10:c2204e40 r9:00000000 r8:c228a3fc r7:00000000 r6:00000003 r5:c228a414 [ 14.588826] r4:00000010 [ 14.588828] dpm_resume_end from suspend_devices_and_enter+0x274/0x6f8 [ 14.588848] r5:c228a414 r4:00000000 [ 14.588851] suspend_devices_and_enter from pm_suspend+0x228/0x2bc [ 14.588868] r10:c3502910 r9:c3501f40 r8:00000004 r7:c228a438 r6:c0f95e18 r5:00000000 [ 14.588871] r4:00000003 [ 14.588874] pm_suspend from state_store+0x74/0xd0 [ 14.588889] r7:c228a438 r6:c0f934c8 r5:00000003 r4:00000003 [ 14.588892] state_store from kobj_attr_store+0x1c/0x28 [ 14.588913] r9:00000000 r8:00000000 r7:f09f9f08 r6:00000004 r5:c3502900 r4:c0283250 [ 14.588916] kobj_attr_store from sysfs_kf_write+0x40/0x4c [ 14.588936] r5:c3502900 r4:c0d92a48 [ 14.588939] sysfs_kf_write from kernfs_fop_write_iter+0x104/0x1f0 [ 14.588956] r5:c3502900 r4:c3501f40 [ 14.588960] kernfs_fop_write_iter from vfs_write+0x250/0x420 [ 14.588980] r10:c0e14b48 r9:00000000 r8:c25f5780 r7:00443398 r6:f09f9f68 r5:c34f7f00 [ 14.588983] r4:c042a88c [ 14.588987] vfs_write from ksys_write+0x74/0xe4 [ 14.589005] r10:00000004 r9:c25f5780 r8:c02002fA0 r7:00000000 r6:00000000 r5:c34f7f00 [ 14.589008] r4:c34f7f00 [ 14.589011] ksys_write from sys_write+0x10/0x14 [ 14.589029] r7:00000004 r6:004421c0 r5:00443398 r4:00000004 [ 14.589032] sys_write from ret_fast_syscall+0x0/0x5c [ 14.589044] Exception stack(0xf09f9fa8 to 0xf09f9ff0) [ 14.589050] 9fa0: 00000004 00443398 00000004 00443398 00000004 00000001 [ 14.589056] 9fc0: 00000004 00443398 004421c0 00000004 b6ecbd58 00000008 bebfbc38 0043eb78 [ 14.589062] 9fe0: 00440eb0 bebfbaf8 b6de18a0 b6e579e8 [ 14.589065] ---[ end trace 0000000000000000 ]--- The fix uses the higher level nand_reset(chip, chipnr); where chipnr = 0, when doing PM resume operation in compliance with the controller support for single die nand chip. Switching from nand_reset_op() to nand_reset() implies more than just setting the cs field op->cs, it also reconfigures the data interface (ie. the timings). Tested and confirmed the NAND chip is in sync timing wise with host after the fix. Fixes: 97d90da8a886 ("mtd: nand: provide several helpers to do common NAND operations") Cc: stable@vger.kernel.org Signed-off-by: Kamal Dasu Reviewed-by: Florian Fainelli Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 33607e92402324245e0d5b8028055f49ba81beaa Author: Miquel Raynal Date: Wed Mar 5 21:09:32 2025 +0100 spi: cadence-qspi: Fix probe on AM62A LP SK commit b8665a1b49f5498edb7b21d730030c06b7348a3c upstream. In 2020, there's been an unnoticed change which rightfully attempted to report probe deferrals upon DMA absence by checking the return value of dma_request_chan_by_mask(). By doing so, it also reported errors which were simply ignored otherwise, likely on purpose. This change actually turned a void return into an error code. Hence, not only the -EPROBE_DEFER error codes but all error codes got reported to the callers, now failing to probe in the absence of Rx DMA channel, despite the fact that DMA seems to not be supported natively by many implementations. Looking at the history, this change probably led to: ad2775dc3fc5 ("spi: cadence-quadspi: Disable the DAC for Intel LGM SoC") f724c296f2f2 ("spi: cadence-quadspi: fix Direct Access Mode disable for SoCFPGA") In my case, the AM62A LP SK core octo-SPI node from TI does not advertise any DMA channel, hinting that there is likely no support for it, but yet when the support for the am654 compatible was added, DMA seemed to be used, so just discarding its use with the CQSPI_DISABLE_DAC_MODE quirk for this compatible does not seem the correct approach. Let's get change the return condition back to: - return a probe deferral error if we get one - ignore the return value otherwise The "error" log level was however likely too high for something that is expected to fail, so let's lower it arbitrarily to the info level. Fixes: 935da5e5100f ("mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://patch.msgid.link/20250305200933.2512925-2-miquel.raynal@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c322789613407647a05ff5c451a7bf545fb34e73 Author: Will Deacon Date: Fri Mar 14 13:34:09 2025 +0000 KVM: arm64: Tear down vGIC on failed vCPU creation commit 250f25367b58d8c65a1b060a2dda037eea09a672 upstream. If kvm_arch_vcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU. Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error. Cc: Cc: Marc Zyngier Cc: Oliver Upton Cc: Quentin Perret Signed-off-by: Will Deacon Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/r/20250314133409.9123-1-will@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 20c105f5876953b12f773972b442ffda8795c71d Author: Douglas Anderson Date: Tue Jan 7 12:06:00 2025 -0800 arm64: errata: Add KRYO 2XX/3XX/4XX silver cores to Spectre BHB safe list commit 0c9fc6e652cd5aed48c5f700c32b7642bea7f453 upstream. Qualcomm has confirmed that, much like Cortex A53 and A55, KRYO 2XX/3XX/4XX silver cores are unaffected by Spectre BHB. Add them to the safe list. Fixes: 558c303c9734 ("arm64: Mitigate spectre style branch history side channels") Cc: stable@vger.kernel.org Cc: Scott Bauer Signed-off-by: Douglas Anderson Acked-by: Trilok Soni Link: https://lore.kernel.org/r/20250107120555.v4.3.Iab8dbfb5c9b1e143e7a29f410bce5f9525a0ba32@changeid Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 3b0f2526c87e00adfd3bcc9e3dd9b4fa77b62465 Author: Douglas Anderson Date: Tue Jan 7 12:05:59 2025 -0800 arm64: errata: Assume that unknown CPUs _are_ vulnerable to Spectre BHB commit e403e8538359d8580cbee1976ff71813e947101e upstream. The code for detecting CPUs that are vulnerable to Spectre BHB was based on a hardcoded list of CPU IDs that were known to be affected. Unfortunately, the list mostly only contained the IDs of standard ARM cores. The IDs for many cores that are minor variants of the standard ARM cores (like many Qualcomm Kyro CPUs) weren't listed. This led the code to assume that those variants were not affected. Flip the code on its head and instead assume that a core is vulnerable if it doesn't have CSV2_3 but is unrecognized as being safe. This involves creating a "Spectre BHB safe" list. As of right now, the only CPU IDs added to the "Spectre BHB safe" list are ARM Cortex A35, A53, A55, A510, and A520. This list was created by looking for cores that weren't listed in ARM's list [1] as per review feedback on v2 of this patch [2]. Additionally Brahma A53 is added as per mailing list feedback [3]. NOTE: this patch will not actually _mitigate_ anyone, it will simply cause them to report themselves as vulnerable. If any cores in the system are reported as vulnerable but not mitigated then the whole system will be reported as vulnerable though the system will attempt to mitigate with the information it has about the known cores. [1] https://developer.arm.com/Arm%20Security%20Center/Spectre-BHB [2] https://lore.kernel.org/r/20241219175128.GA25477@willie-the-truck [3] https://lore.kernel.org/r/18dbd7d1-a46c-4112-a425-320c99f67a8d@broadcom.com Fixes: 558c303c9734 ("arm64: Mitigate spectre style branch history side channels") Cc: stable@vger.kernel.org Reviewed-by: Julius Werner Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20250107120555.v4.2.I2040fa004dafe196243f67ebcc647cbedbb516e6@changeid Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 4af285843525c8db4215ec28e4e639bfd4ed2029 Author: Douglas Anderson Date: Tue Jan 7 12:05:58 2025 -0800 arm64: errata: Add QCOM_KRYO_4XX_GOLD to the spectre_bhb_k24_list commit ed1ce841245d8febe3badf51c57e81c3619d0a1d upstream. Qualcomm Kryo 400-series Gold cores have a derivative of an ARM Cortex A76 in them. Since A76 needs Spectre mitigation via looping then the Kyro 400-series Gold cores also need Spectre mitigation via looping. Qualcomm has confirmed that the proper "k" value for Kryo 400-series Gold cores is 24. Fixes: 558c303c9734 ("arm64: Mitigate spectre style branch history side channels") Cc: stable@vger.kernel.org Cc: Scott Bauer Signed-off-by: Douglas Anderson Acked-by: Trilok Soni Link: https://lore.kernel.org/r/20250107120555.v4.1.Ie4ef54abe02e7eb0eee50f830575719bf23bda48@changeid Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 2ff58c5b260f7d663a73d4c12b599600d47e20a5 Author: Douglas Anderson Date: Tue Jan 7 12:06:01 2025 -0800 arm64: cputype: Add MIDR_CORTEX_A76AE commit a9b5bd81b294d30a747edd125e9f6aef2def7c79 upstream. >From the TRM, MIDR_CORTEX_A76AE has a partnum of 0xDOE and an implementor of 0x41 (ARM). Add the values. Cc: stable@vger.kernel.org # dependency of the next fix in the series Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20250107120555.v4.4.I151f3b7ee323bcc3082179b8c60c3cd03308aa94@changeid Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 7e619d4d2715af933a554801ad5b4e9a739120dc Author: Jan Beulich Date: Wed Mar 12 16:32:45 2025 +0100 xenfs/xensyms: respect hypervisor's "next" indication commit 5c4e79e29a9fe4ea132118ac40c2bc97cfe23077 upstream. The interface specifies the symnum field as an input and output; the hypervisor sets it to the next sequential symbol's index. xensyms_next() incrementing the position explicitly (and xensyms_next_sym() decrementing it to "rewind") is only correct as long as the sequence of symbol indexes is non-sparse. Use the hypervisor-supplied value instead to update the position in xensyms_next(), and use the saved incoming index in xensyms_next_sym(). Cc: stable@kernel.org Fixes: a11f4f0a4e18 ("xen: xensyms support") Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Message-ID: <15d5e7fa-ec5d-422f-9319-d28bed916349@suse.com> Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 88962f1978761e0f247b99bfe36804b13d960778 Author: John Keeping Date: Sat Aug 10 14:02:54 2024 +0100 media: rockchip: rga: fix rga offset lookup commit 11de3582675cc0b7136e12f3971f1da3e5a05382 upstream. The arguments to rga_lookup_draw_pos() are passed in the wrong order, rotate mode should be before mirror mode. Fixes: 558c248f930e6 ("media: rockchip: rga: split src and dst buffer setup") Cc: stable@vger.kernel.org Signed-off-by: John Keeping Reviewed-by: Michael Tretter Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit ceb23f66ef8fde1ed949e96f1a27323625ddc0ff Author: Yuan Can Date: Tue Oct 22 14:50:37 2024 +0800 media: siano: Fix error handling in smsdvb_module_init() commit 734ac57e47b3bdd140a1119e2c4e8e6f8ef8b33d upstream. The smsdvb_module_init() returns without checking the retval from smscore_register_hotplug(). If the smscore_register_hotplug() failed, the module failed to install, leaving the smsdvb_debugfs not unregistered. Fixes: 3f6b87cff66b ("[media] siano: allow showing the complete statistics via debugfs") Cc: stable@vger.kernel.org Signed-off-by: Yuan Can Acked-by: Ricardo Ribalda Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 7631d176086c1bec0dc29ab3e90d5fe58ce38195 Author: Matthew Majewski Date: Wed Feb 19 14:05:01 2025 -0500 media: vim2m: print device name after registering device commit 143d75583f2427f3a97dba62413c4f0604867ebf upstream. Move the v4l2_info() call displaying the video device name after the device is actually registered. This fixes a bug where the driver was always displaying "/dev/video0" since it was reading from the vfd before it was registered. Fixes: cf7f34777a5b ("media: vim2m: Register video device after setting up internals") Cc: stable@vger.kernel.org Signed-off-by: Matthew Majewski Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 679424f8b31446f90080befd0300ea915485b096 Author: Vikash Garodia Date: Thu Feb 20 22:50:10 2025 +0530 media: venus: hfi: add check to handle incorrect queue size commit 69baf245b23e20efda0079238b27fc63ecf13de1 upstream. qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write Add check to ensure qsize is within the allocated size while reading and writing packets into the queue. Cc: stable@vger.kernel.org Fixes: d96d3f30c0f2 ("[media] media: venus: hfi: add Venus HFI files") Reviewed-by: Bryan O'Donoghue Signed-off-by: Vikash Garodia Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 530f623f56a6680792499a8404083e17f8ec51f4 Author: Vikash Garodia Date: Thu Feb 20 22:50:11 2025 +0530 media: venus: hfi: add a check to handle OOB in sfr region commit f4b211714bcc70effa60c34d9fa613d182e3ef1e upstream. sfr->buf_size is in shared memory and can be modified by malicious user. OOB write is possible when the size is made higher than actual sfr data buffer. Cap the size to allocated size for such cases. Cc: stable@vger.kernel.org Fixes: d96d3f30c0f2 ("[media] media: venus: hfi: add Venus HFI files") Reviewed-by: Bryan O'Donoghue Signed-off-by: Vikash Garodia Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 72629a582db72a4f4c9ecbd32dbe40d220d1746d Author: Bingbu Cao Date: Fri Feb 14 18:52:38 2025 +0800 media: intel/ipu6: set the dev_parent of video device to pdev commit 6f0ab5d3671f7cbb326c8cab6fb69cb7ab9901cc upstream. The bus_info in v4l2_capability of IPU6 isys v4l2_dev is missing. The driver didn't set the dev_parent of v4l2_dev, its parent is set to its parent auxdev which is neither platform nor PCI device, thus media_set_bus_info() will not set the bus_info of v4l2_capability, then `v4l2-ctl --all` cannot show the bus_info. This patch fixes it by setting the dev_parent of video_device and v4l2 framework can detect the device type and set the bus_info instead. Fixes: 3c1dfb5a69cf ("media: intel/ipu6: input system video nodes and buffer queues") Cc: stable@vger.kernel.org Signed-off-by: Hidenori Kobayashi Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f598940803cd2800796c5433abec82ccef48f21e Author: Martin Tůma Date: Fri Feb 21 13:07:43 2025 +0100 media: mgb4: Fix switched CMT frequency range "magic values" sets commit 450acf0840232eaf6eb7a80da11cf492e57498e8 upstream. The reason why this passed unnoticed is that most infotainment systems use frequencies near enough the middle (50MHz) where both sets work. Fixes: 0ab13674a9bd ("media: pci: mgb4: Added Digiteq Automotive MGB4 driver") Cc: stable@vger.kernel.org Signed-off-by: Martin Tůma Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 66e35600f7264d1b69b1fcab906b6477a552bc1a Author: Niklas Söderlund Date: Tue Jan 21 21:44:00 2025 +0100 media: i2c: adv748x: Fix test pattern selection mask commit 9e38acacb9d809b97a0bdc5c76e725355a47158a upstream. The mask to select the test-pattern in register ADV748X_SDP_FRP is incorrect, it's the lower 3 bits which controls the pattern. The GENMASK() macro is used incorrectly and the generated mask is 0x0e instead of 0x07. The result is that not all test patterns are selectable, and that in some cases the wrong test pattern is activated. Fix this by correcting the GENMASK(). Fixes: 3e89586a64df ("media: i2c: adv748x: add adv748x driver") Cc: stable@vger.kernel.org Signed-off-by: Niklas Söderlund Reviewed-by: Kieran Bingham Signed-off-by: Hans Verkuil [hverkuil: fixed tiny typo in commit log: my -> by] Signed-off-by: Greg Kroah-Hartman commit 1c673fa8889ec04952c70ed343ab0a118200f70f Author: Martin Tůma Date: Fri Feb 21 13:07:42 2025 +0100 media: mgb4: Fix CMT registers update logic commit dd05443189f9ae175dd806594b67bf55ddb6539e upstream. The CMT "magic values" registers must be updated while the CMT reset registers are active. Fixes: 0ab13674a9bd ("media: pci: mgb4: Added Digiteq Automotive MGB4 driver") Cc: stable@vger.kernel.org Signed-off-by: Martin Tůma Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit ced0ddecc04b314e30c033c14e2fa964de40efa6 Author: Niklas Söderlund Date: Wed Feb 12 17:50:53 2025 +0100 media: uapi: rkisp1-config: Fix typo in extensible params example commit 7b0ee2de7c76e5518e2235a927fd211bc785d320 upstream. The define used for the version in the example diagram does not match what is defined in enum rksip1_ext_param_buffer_version, nor the description above it. Correct the typo to make it clear which define to use. Fixes: e9d05e9d5db1 ("media: uapi: rkisp1-config: Add extensible params format") Cc: stable@vger.kernel.org Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 8c64a2cfdbb810ca059a24742a13bd8bef5b1904 Author: Arnd Bergmann Date: Fri Oct 18 15:21:10 2024 +0000 media: mtk-vcodec: venc: avoid -Wenum-compare-conditional warning commit 07df4f23ef3ffe6fee697cd2e03623ad27108843 upstream. This is one of three clang warnings about incompatible enum types in a conditional expression: drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c:597:29: error: conditional expression between different enumeration types ('enum scp_ipi_id' and 'enum ipi_id') [-Werror,-Wenum-compare-conditional] 597 | inst->vpu_inst.id = is_ext ? SCP_IPI_VENC_H264 : IPI_VENC_H264; | ^ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ The code is correct, so just rework it to avoid the warning. Fixes: 0dc4b3286125 ("media: mtk-vcodec: venc: support SCP firmware") Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Reviewed-by: Alexandre Courbot Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9f009fa823c54ca0857c81f7525ea5a5d32de29c Author: Jiasheng Jiang Date: Tue Feb 18 18:58:09 2025 +0000 media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization commit 4936cd5817af35d23e4d283f48fa59a18ef481e4 upstream. On Mediatek devices with a system companion processor (SCP) the mtk_scp structure has to be removed explicitly to avoid a resource leak. Free the structure in case the allocation of the firmware structure fails during the firmware initialization. Fixes: 53dbe0850444 ("media: mtk-vcodec: potential null pointer deference in SCP") Cc: stable@vger.kernel.org Signed-off-by: Jiasheng Jiang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 956c5e4965d59abff6bd9dc3e0f3566286db454e Author: Alain Volmat Date: Mon Feb 10 11:04:31 2025 +0100 dt-bindings: media: st,stmipid02: correct lane-polarities maxItems commit 3a544a39e0a4c492e3026dfbed018321d2bd6caa upstream. The MIPID02 can use up to 2 data lanes which leads to having a maximum item number of 3 for the lane-polarities since this also contains the clock lane. CC: stable@vger.kernel.org Fixes: c2741cbe7f8a ("dt-bindings: media: st,stmipid02: Convert the text bindings to YAML") Signed-off-by: Alain Volmat Acked-by: Conor Dooley Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit a9a73da6e014e0469a5d03ecc4b8c7017ccc19c9 Author: Haoxiang Li Date: Mon Feb 24 18:15:27 2025 +0800 auxdisplay: hd44780: Fix an API misuse in hd44780.c commit 9b98a7d2e5f4e2beeff88f6571da0cdc5883c7fb upstream. Variable allocated by charlcd_alloc() should be released by charlcd_free(). The following patch changed kfree() to charlcd_free() to fix an API misuse. Fixes: 718e05ed92ec ("auxdisplay: Introduce hd44780_common.[ch]") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Geert Uytterhoeven Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit bdbc38bd12eb36bbbcce4f013879c1755c9a9084 Author: Tomasz Pakuła Date: Tue Feb 25 23:30:04 2025 +0100 HID: pidff: Fix set_device_control() [ Upstream commit e2fa0bdf08a70623f24ed52f2037a330999d9800 ] As the search for Device Control report is permissive, make sure the desired field was actually found, before trying to set it. Fix bitmask clearing as it was erronously using index instead of index - 1 (HID arrays index is 1-based). Add last two missing Device Control usages to the defined array. PID_PAUSE and PID_CONTINUE. Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 1565ead12f5c581550ef07c30ee33fe7022f9859 Author: Tomasz Pakuła Date: Tue Feb 25 23:30:03 2025 +0100 HID: pidff: Fix 90 degrees direction name North -> East [ Upstream commit f98ecedbeca34a8df1460c3a03cce32639c99a9d ] Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 5318556ed31fd6964818339e764f6817cc6a2041 Author: Tomasz Pakuła Date: Tue Feb 25 23:30:02 2025 +0100 HID: pidff: Compute INFINITE value instead of using hardcoded 0xffff [ Upstream commit 1a575044d516972a1d036d54c0180b9085e21dc6 ] As per USB PID standard: INFINITE - Referrers to the maximum value of a range. i.e. if in an 8 bit unsigned field the value of 255 would indicate INFINITE. Detecting 0xffff (U16_MAX) is still important as we MIGHT get this value as infinite from some native software as 0 was never actually defined in Linux' FF api as the infinite value. I'm working on it though. Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit b15301f289602eb93bc0a0b823a95a0a37b60b0e Author: Tomasz Pakuła Date: Tue Feb 25 23:30:01 2025 +0100 HID: pidff: Clamp effect playback LOOP_COUNT value [ Upstream commit 0c6673e3d17b258b8c5c7331d28bf6c49f25ed30 ] Ensures the loop count will never exceed the logical_maximum. Fixes implementation errors happening when applications use the max value of int32/DWORD as the effect iterations. This could be observed when running software both native and in wine. Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 42ec3b5bf7e6980ec219888fdb9e0090bd83cb30 Author: Tomasz Pakuła Date: Tue Feb 25 23:30:00 2025 +0100 HID: pidff: Rename two functions to align them with naming convention [ Upstream commit bbeface1051142bcb0473fdcc89102ea5b31607d ] Driver uses "set" everywhere to indicate setting report values and requesting HID_REQ_SET_REPORT Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit b782892cd264629caf810ca0d2c17fb77c6dc92a Author: Tomasz Pakuła Date: Tue Feb 11 15:35:12 2025 +0100 HID: pidff: Remove redundant call to pidff_find_special_keys [ Upstream commit 1bd55e79cbc0ea2d6a65f51e06c891806359c2f2 ] Probably left out as a mistake after Anssi created the helper macro Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 239c8ac58cfc35dc61e53770f0bd24ea8d685d72 Author: Tomasz Pakuła Date: Tue Feb 11 15:35:11 2025 +0100 HID: pidff: Support device error response from PID_BLOCK_LOAD [ Upstream commit 9d4174dc4a234408d91fd83725e1899766cd1731 ] If an error happens on the device, the driver will no longer fall into the trap of reading this status 60 times before it decides that this reply won't change to success/memory full. Greatly reduces communication overhead during device error situation. Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 2d698115f9b3e44caf03b9899a3100f2a1075000 Author: Tomasz Pakuła Date: Tue Feb 11 15:35:10 2025 +0100 HID: pidff: Comment and code style update [ Upstream commit e19675c2477491401b236ed939ad5a43ddc339af ] Update comments to fully conform to the Linux comment styling. Define Linux infinite effect duration (0) as FF_INFINITE Chanage Oleg's name order Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 35ebc643aff90e08f6696f75d49dc26e33fe3b50 Author: Tomasz Pakuła Date: Tue Feb 11 15:35:09 2025 +0100 HID: hid-universal-pidff: Add Asetek wheelbases support [ Upstream commit c385f61108d403633e8cfbdae15b35ccf7cee686 ] Adds Asetek vendor id and product ids for: - Invicta - Forte - La Prima - Tony Kanaan v2: - Misc spelling fix in driver loaded info v3: - Chanage Oleg's name order Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 211861869766a7bb7c72158aee0140ec67e182a7 Author: Tomasz Pakuła Date: Tue Feb 11 15:35:08 2025 +0100 HID: pidff: Make sure to fetch pool before checking SIMULTANEOUS_MAX [ Upstream commit 1f650dcec32d22deb1d6db12300a2b98483099a9 ] As noted by Anssi some 20 years ago, pool report is sometimes messed up. This worked fine on many devices but casued oops on VRS DirectForce PRO. Here, we're making sure pool report is refetched before trying to access any of it's fields. While loop was replaced with a for loop + exit conditions were moved aroud to decrease the possibility of creating an infinite loop scenario. Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 13d15dd6175e1e3eb70ce95e3da0b8a0a5a54d34 Author: Tomasz Pakuła Date: Sat Feb 1 12:39:06 2025 +0100 HID: pidff: Factor out pool report fetch and remove excess declaration [ Upstream commit 5d98079b2d0186e1f586301a9c00144a669416a8 ] We only want to refetch the pool report during device init. Reset function is now called when uploading effects to an empty device so extract pool fetch to separate function and call it from init before autocenter check (autocenter check triggered reset during init). Remove a superfluous pointer declaration and assigment as well. Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 6fbf2ac6d5b63312167977d14288b68dcfc3d37d Author: Tomasz Pakuła Date: Sat Feb 1 12:39:05 2025 +0100 HID: pidff: Use macros instead of hardcoded min/max values for shorts [ Upstream commit 21755162456902998f8d9897086b8c980c540df5 ] Makes it obvious these magic values ARE in fact derived from min and max values for s16 and u16 Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 87783d301e9893451ff52ed2f3d81c14365a5083 Author: Tomasz Pakuła Date: Sat Feb 1 12:39:04 2025 +0100 HID: pidff: Simplify pidff_rescale_signed [ Upstream commit 4eb9c2ee538b62dc5dcae192297c3a4044b7ade5 ] This function overrelies on ternary operators and makes it hard to parse it mentally. New version makes it very easy to understand. Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 61e4de1728aca6aa886940c725faf713cfffe187 Author: Tomasz Pakuła Date: Sat Feb 1 12:39:03 2025 +0100 HID: pidff: Move all hid-pidff definitions to a dedicated header [ Upstream commit 0d24d4b1da96df9fc5ff36966f40f980ef864d46 ] Do not clutter hid includes with stuff not needed outside of the kernel. Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 8f0b2d791e0fcaa8afe9a6a28ba300dab63fe6ed Author: Tomasz Pakuła Date: Sat Feb 1 12:39:01 2025 +0100 HID: pidff: Factor out code for setting gain [ Upstream commit f7ebf0b11b9e04bf59c438ad14f0115b12aa2f44 ] Makes it possible to easily set gain from inside hid-pidff.c Changes in v7: - Check if device gain field exists before setting device gain Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 5243ca2a5c678bf86150a8f8567b505c1d154524 Author: Tomasz Pakuła Date: Sat Feb 1 12:39:00 2025 +0100 HID: pidff: Rescale time values to match field units [ Upstream commit 8713107221a8ce4021ec5fa12bb50ecc8165cf08 ] PID devices can use different exponents for time fields, while Linux Force Feedback API only supports miliseconds. Read the exponent of a given time field and scale its value accordingly. Changes in v7: - Rescale all time fields, not only period changes in v9: - Properly assign fade_lenght, not attack_length to PID_FADE_TIME Co-developed-by: Makarenko Oleg Signed-off-by: Makarenko Oleg Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 7009a060ffef4c757c40297fc4b7345ec7c63dbd Author: Tomasz Pakuła Date: Sat Feb 1 12:38:59 2025 +0100 HID: pidff: Define values used in pidff_find_special_fields [ Upstream commit 1c12f136891cf4d2d4e6aa202d671a9d2171a716 ] Makes it clear where did these values came from Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 9cdd95f9a4f3f60388c069d262953d9f19b5a692 Author: Tomasz Pakuła Date: Sat Feb 1 12:38:58 2025 +0100 HID: pidff: Simplify pidff_upload_effect function [ Upstream commit e4bdc80ef14272ef56c38d8ca2f365fdf59cd0ba ] Merge a bit of code that reqeusts conditional effects upload. Makes it clear, that effect handling should be identical for SPRING, DAMPER, INERTIA and FRICTION. Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 433c4234ff7365368ece8ba9ae94c23210dc93a8 Author: Tomasz Pakuła Date: Sat Feb 1 12:38:57 2025 +0100 HID: pidff: Completely rework and fix pidff_reset function [ Upstream commit cb3fd788e3fa5358602a49809c4eb4911539c9d0 ] Previously, it was assumed that DEVICE_CONTROL usage is always an array but a lot of devices implements it as a bitmask variable. This led to the pidff_reset function not working and causing errors in such cases. Selectors can come in three types. One selection of a set, N selections and Any selection in form of bitmask as from USB Hid Usage Tables v1.5, subsection 3.4.2.1 Added pidff_send_device_control which handles usage flag check which decides whether DEVICE_CONTROL should be handled as "One selection of a set" or "Any selection of a set". Reset was triggered once, on device initialization. Now, it's triggered every time when uploading an effect to an empty device (no currently stored effects), tracked by pidff->effect_count variable. Co-developed-by: Makarenko Oleg Signed-off-by: Makarenko Oleg Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 2b1e13ed295a207c5523721edad67013c8eef942 Author: Tomasz Pakuła Date: Sat Feb 1 12:38:53 2025 +0100 HID: pidff: Stop all effects before enabling actuators [ Upstream commit ce52c0c939fcb568d1abe454821d5623de38b424 ] Some PID compliant devices automatically play effects after boot (i.e. autocenter spring) that prevent the rendering of other effects since it is done outside the kernel driver. This makes sure all the effects currently played are stopped after resetting the device. It brings compatibility to the Brunner CLS-P joystick and others Reported-by: Jules Noirant Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 629405d18543b6caec22c2bd359a2de6a406e1c6 Author: Tomasz Pakuła Date: Sat Feb 1 12:38:47 2025 +0100 HID: pidff: Clamp PERIODIC effect period to device's logical range [ Upstream commit f538183e997a9fb6087e94e71e372de967b9e56a ] This ensures the effect can actually be played on the connected force feedback device. Adds clamping functions used instead of rescaling, as we don't want to change the characteristics of the periodic effects. Fixes edge cases found on Moza Racing and some other hardware where the effects would not play if the period is outside the defined logical range. Changes in v6: - Use in-kernel clamp macro instead of a custom solution Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 43e5e2879deecc286f2859791e7c795969aa4335 Author: Niklas Schnelle Date: Wed Feb 26 13:07:45 2025 +0100 s390/pci: Fix s390_mmio_read/write syscall page fault handling [ Upstream commit 41a0926e82f4963046876ed9a1b5f681be8087a8 ] The s390 MMIO syscalls when using the classic PCI instructions do not cause a page fault when follow_pfnmap_start() fails due to the page not being present. Besides being a general deficiency this breaks vfio-pci's mmap() handling once VFIO_PCI_MMAP gets enabled as this lazily maps on first access. Fix this by following a failed follow_pfnmap_start() with fixup_user_page() and retrying the follow_pfnmap_start(). Also fix a VM_READ vs VM_WRITE mixup in the read syscall. Link: https://lore.kernel.org/r/20250226-vfio_pci_mmap-v7-1-c5c0f1d26efd@linux.ibm.com Signed-off-by: Niklas Schnelle Signed-off-by: Bjorn Helgaas Reviewed-by: Matthew Rosato Signed-off-by: Sasha Levin commit dd3edffae868f34e494656245786de888189d2de Author: Jann Horn Date: Fri Nov 29 21:20:53 2024 +0100 ext4: don't treat fhandle lookup of ea_inode as FS corruption [ Upstream commit 642335f3ea2b3fd6dba03e57e01fa9587843a497 ] A file handle that userspace provides to open_by_handle_at() can legitimately contain an outdated inode number that has since been reused for another purpose - that's why the file handle also contains a generation number. But if the inode number has been reused for an ea_inode, check_igot_inode() will notice, __ext4_iget() will go through ext4_error_inode(), and if the inode was newly created, it will also be marked as bad by iget_failed(). This all happens before the point where the inode generation is checked. ext4_error_inode() is supposed to only be used on filesystem corruption; it should not be used when userspace just got unlucky with a stale file handle. So when this happens, let __ext4_iget() just return an error. Fixes: b3e6bcb94590 ("ext4: add EA_INODE checking to ext4_iget()") Signed-off-by: Jann Horn Reviewed-by: Jan Kara Link: https://patch.msgid.link/20241129-ext4-ignore-ea-fhandle-v1-1-e532c0d1cee0@google.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 806908d5d978bd81b2b9529e1598c2d3a67f6228 Author: Willem de Bruijn Date: Tue Apr 8 09:27:48 2025 -0400 bpf: support SKF_NET_OFF and SKF_LL_OFF on skb frags [ Upstream commit d4bac0288a2b444e468e6df9cb4ed69479ddf14a ] Classic BPF socket filters with SKB_NET_OFF and SKB_LL_OFF fail to read when these offsets extend into frags. This has been observed with iwlwifi and reproduced with tun with IFF_NAPI_FRAGS. The below straightforward socket filter on UDP port, applied to a RAW socket, will silently miss matching packets. const int offset_proto = offsetof(struct ip6_hdr, ip6_nxt); const int offset_dport = sizeof(struct ip6_hdr) + offsetof(struct udphdr, dest); struct sock_filter filter_code[] = { BPF_STMT(BPF_LD + BPF_B + BPF_ABS, SKF_AD_OFF + SKF_AD_PKTTYPE), BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, PACKET_HOST, 0, 4), BPF_STMT(BPF_LD + BPF_B + BPF_ABS, SKF_NET_OFF + offset_proto), BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, IPPROTO_UDP, 0, 2), BPF_STMT(BPF_LD + BPF_H + BPF_ABS, SKF_NET_OFF + offset_dport), This is unexpected behavior. Socket filter programs should be consistent regardless of environment. Silent misses are particularly concerning as hard to detect. Use skb_copy_bits for offsets outside linear, same as done for non-SKF_(LL|NET) offsets. Offset is always positive after subtracting the reference threshold SKB_(LL|NET)_OFF, so is always >= skb_(mac|network)_offset. The sum of the two is an offset against skb->data, and may be negative, but it cannot point before skb->head, as skb_(mac|network)_offset would too. This appears to go back to when frag support was introduced to sk_run_filter in linux-2.4.4, before the introduction of git. The amount of code change and 8/16/32 bit duplication are unfortunate. But any attempt I made to be smarter saved very few LoC while complicating the code. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/netdev/20250122200402.3461154-1-maze@google.com/ Link: https://elixir.bootlin.com/linux/2.4.4/source/net/core/filter.c#L244 Reported-by: Matt Moeller Co-developed-by: Maciej Żenczykowski Signed-off-by: Maciej Żenczykowski Signed-off-by: Willem de Bruijn Acked-by: Stanislav Fomichev Link: https://lore.kernel.org/r/20250408132833.195491-2-willemdebruijn.kernel@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7b9bdd705911468cd4ec847de8e5fdfc95eabdbf Author: Sheng Yong Date: Tue Apr 8 20:23:50 2025 +0800 erofs: set error to bio if file-backed IO fails [ Upstream commit 1595f15391b81815e4ef91c339991913d556c1b6 ] If a file-backed IO fails before submitting the bio to the lower filesystem, an error is returned, but the bio->bi_status is not marked as an error. However, the error information should be passed to the end_io handler. Otherwise, the IO request will be treated as successful. Fixes: 283213718f5d ("erofs: support compressed inodes for fileio") Signed-off-by: Sheng Yong Reviewed-by: Gao Xiang Link: https://lore.kernel.org/r/20250408122351.2104507-1-shengyong1@xiaomi.com Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 61f590c6771b48e1b96b8b55297dcb168623a7b2 Author: Uwe Kleine-König Date: Tue Apr 1 12:29:01 2025 +0200 pwm: fsl-ftm: Handle clk_get_rate() returning 0 [ Upstream commit 928446a5302eee30ebb32075c0db5dda5a138fb7 ] Considering that the driver doesn't enable the used clocks (and also that clk_get_rate() returns 0 if CONFIG_HAVE_CLK is unset) better check the return value of clk_get_rate() for being non-zero before dividing by it. Fixes: 3479bbd1e1f8 ("pwm: fsl-ftm: More relaxed permissions for updating period") Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/b68351a51017035651bc62ad3146afcb706874f0.1743501688.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit a2786a82de0c97acccefddc3dd7e0c2f5835bb7f Author: Uwe Kleine-König Date: Tue Apr 1 12:29:00 2025 +0200 pwm: rcar: Improve register calculation [ Upstream commit e7327c193014a4d8666e9c1cda09cf2c060518e8 ] There were several issues in the function rcar_pwm_set_counter(): - The u64 values period_ns and duty_ns were cast to int on function call which might loose bits on 32 bit architectures. Fix: Make parameters to rcar_pwm_set_counter() u64 - The algorithm divided by the result of a division which looses precision. Fix: Make use of mul_u64_u64_div_u64() - The calculated values were just masked to fit the respective register fields which again might loose bits. Fix: Explicitly check for overlow Implement the respective fixes. A side effect of fixing the 2nd issue is that there is no division by 0 if clk_get_rate() returns 0. Fixes: ed6c1476bf7f ("pwm: Add support for R-Car PWM Timer") Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/ab3dac794b2216cc1cc56d65c93dd164f8bd461b.1743501688.git.u.kleine-koenig@baylibre.com [ukleinek: Added an explicit #include to please the 0day build bot] Link: https://lore.kernel.org/oe-kbuild-all/202504031354.VJtxScP5-lkp@intel.com/ Reviewed-by: Geert Uytterhoeven Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit 4cb15042b5f3ec0474e91cf379120cc597625dbb Author: Josh Poimboeuf Date: Tue Apr 1 12:28:59 2025 +0200 pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config() [ Upstream commit 7ca59947b5fcf94e7ea4029d1bd0f7c41500a161 ] With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has a divide-by-zero in the following line: do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm])); due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate() returns zero. This is presumably just a theoretical problem: COMPILE_TEST overrides the dependency on RALINK which would select COMMON_CLK. Regardless it's a good idea to check for the error explicitly to avoid divide-by-zero. Fixes the following warning: drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section Signed-off-by: Josh Poimboeuf Link: https://lore.kernel.org/r/fb56444939325cc173e752ba199abd7aeae3bf12.1742852847.git.jpoimboe@kernel.org [ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/] Fixes: caf065f8fd58 ("pwm: Add MediaTek PWM support") Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/9e78a0796acba3435553ed7db1c7965dcffa6215.1743501688.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit 2bef78f9622d473e9dd67b71e4841677aa11d122 Author: Jonathan McDowell Date: Fri Mar 7 12:25:23 2025 +0000 tpm: End any active auth session before shutdown [ Upstream commit 1dbf74e00a5f882b04b398399b6def65cd51ef21 ] Lazy flushing of TPM auth sessions can interact badly with IMA + kexec, resulting in loaded session handles being leaked across the kexec and not cleaned up. Fix by ensuring any active auth session is ended before the TPM is told about the shutdown, matching what is done when suspending. Before: root@debian-qemu-efi:~# tpm2_getcap handles-loaded-session root@debian-qemu-efi:~# tpm2_getcap handles-saved-session root@debian-qemu-efi:~# kexec --load --kexec-file-syscall … root@debian-qemu-efi:~# systemctl kexec … root@debian-qemu-efi:~# tpm2_getcap handles-loaded-session - 0x2000000 root@debian-qemu-efi:~# tpm2_getcap handles-saved-session root@debian-qemu-efi:~# (repeat kexec steps) root@debian-qemu-efi:~# tpm2_getcap handles-loaded-session - 0x2000000 - 0x2000001 root@debian-qemu-efi:~# tpm2_getcap handles-saved-session root@debian-qemu-efi:~# After: root@debian-qemu-efi:~# tpm2_getcap handles-loaded-session root@debian-qemu-efi:~# tpm2_getcap handles-saved-session root@debian-qemu-efi:~# kexec --load --kexec-file-syscall … root@debian-qemu-efi:~# systemctl kexec … root@debian-qemu-efi:~# tpm2_getcap handles-loaded-session root@debian-qemu-efi:~# tpm2_getcap handles-saved-session root@debian-qemu-efi:~# Signed-off-by: Jonathan McDowell Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 01c2ed3f7dcef2f6e1c55da902f07310203ef790 Author: Jonathan McDowell Date: Wed Mar 12 07:26:18 2025 +0200 tpm, tpm_tis: Workaround failed command reception on Infineon devices [ Upstream commit de9e33df7762abbfc2a1568291f2c3a3154c6a9d ] Some Infineon devices have a issue where the status register will get stuck with a quick REQUEST_USE / COMMAND_READY sequence. This is not simply a matter of requiring a longer timeout; the work around is to retry the command submission. Add appropriate logic to do this in the send path. This is fixed in later firmware revisions, but those are not always available, and cannot generally be easily updated from outside a firmware environment. Testing has been performed with a simple repeated loop of doing a TPM2_CC_GET_CAPABILITY for TPM_CAP_PROP_MANUFACTURER using the Go code at: https://the.earth.li/~noodles/tpm-stuff/timeout-reproducer-simple.go It can take several hours to reproduce, and several million operations. Signed-off-by: Jonathan McDowell Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit a4e3c80cecbe724176811475cfb3ec654c24c5a0 Author: Ayush Jain Date: Fri Mar 7 04:38:54 2025 +0000 ktest: Fix Test Failures Due to Missing LOG_FILE Directories [ Upstream commit 5a1bed232781d356f842576daacc260f0d0c8d2e ] Handle missing parent directories for LOG_FILE path to prevent test failures. If the parent directories don't exist, create them to ensure the tests proceed successfully. Cc: Link: https://lore.kernel.org/20250307043854.2518539-1-Ayush.jain3@amd.com Signed-off-by: Ayush Jain Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 9a6be23eb0ff0460f3de5d215ac1b5727b2bdf80 Author: Masami Hiramatsu (Google) Date: Thu Mar 27 21:19:54 2025 +0900 tracing: probe-events: Add comments about entry data storing code [ Upstream commit bb9c6020f4c3a07a90dc36826cb5fbe83f09efd5 ] Add comments about entry data storing code to __store_entry_arg() and traceprobe_get_entry_data_size(). These are a bit complicated because of building the entry data storing code and scanning it. This just add comments, no behavior change. Link: https://lore.kernel.org/all/174061715004.501424.333819546601401102.stgit@devnote2/ Reported-by: Steven Rostedt Closes: https://lore.kernel.org/all/20250226102223.586d7119@gandalf.local.home/ Reviewed-by: Steven Rostedt (Google) Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 52eafaa56f8f6d6a0cdff9282b25b4acbde34edc Author: Leonid Arapov Date: Tue Mar 18 21:19:52 2025 +0000 fbdev: omapfb: Add 'plane' value check [ Upstream commit 3e411827f31db7f938a30a3c7a7599839401ec30 ] Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB of the enum parameter plane. The value of this parameter is initialized in dss_init_overlays and in the current state of the code it cannot take this value so it's not a real problem. For the purposes of defensive coding it wouldn't be superfluous to check the parameter value, because some functions down the call stack process this value correctly and some not. For example, in dispc_ovl_setup_global_alpha it may lead to buffer overflow. Add check for this value. Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool. Signed-off-by: Leonid Arapov Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit fb4c507bf24a77e210ed68924c48a1ff7eeff94f Author: Christian König Date: Tue Jan 14 13:51:39 2025 +0100 drm/amdgpu: grab an additional reference on the gang fence v2 [ Upstream commit 0d9a95099dcb05b5f4719c830d15bf4fdcad0dc2 ] We keep the gang submission fence around in adev, make sure that it stays alive. v2: fix memory leak on retry Signed-off-by: Christian König Acked-by: Srinivasan Shanmugam Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5c3cfcf0b4bf43530788b08a8eaf7896ec567484 Author: Ryo Takakura Date: Tue Feb 18 09:08:30 2025 +0100 PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type [ Upstream commit 18056a48669a040bef491e63b25896561ee14d90 ] The access to the PCI config space via pci_ops::read and pci_ops::write is a low-level hardware access. The functions can be accessed with disabled interrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this purpose. A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be acquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in the same context as the pci_lock. Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with interrupts disabled. This was reported as: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 Call Trace: rt_spin_lock+0x4e/0x130 vmd_pci_read+0x8d/0x100 [vmd] pci_user_read_config_byte+0x6f/0xe0 pci_read_config+0xfe/0x290 sysfs_kf_bin_read+0x68/0x90 Signed-off-by: Ryo Takakura Tested-by: Luis Claudio R. Goncalves Acked-by: Luis Claudio R. Goncalves [bigeasy: reword commit message] Signed-off-by: Sebastian Andrzej Siewior Tested-off-by: Luis Claudio R. Goncalves Link: https://lore.kernel.org/r/20250218080830.ufw3IgyX@linutronix.de [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński [bhelgaas: add back report info from https://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/] Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 73d2b962503151f7a69cfe28f24185fb96c14915 Author: Philipp Stanner Date: Wed Mar 12 09:06:35 2025 +0100 PCI: Check BAR index for validity [ Upstream commit b1a7f99967fc0c052db8e65b449c7b32b1e9177f ] Many functions in PCI use accessor macros such as pci_resource_len(), which take a BAR index. That index, however, is never checked for validity, potentially resulting in undefined behavior by overflowing the array pci_dev.resource in the macro pci_resource_n(). Since many users of those macros directly assign the accessed value to an unsigned integer, the macros cannot be changed easily anymore to return -EINVAL for invalid indexes. Consequently, the problem has to be mitigated in higher layers. Add pci_bar_index_valid(). Use it where appropriate. Link: https://lore.kernel.org/r/20250312080634.13731-4-phasta@kernel.org Closes: https://lore.kernel.org/all/adb53b1f-29e1-3d14-0e61-351fd2d3ff0d@linux.intel.com/ Reported-by: Bingbu Cao Signed-off-by: Philipp Stanner [kwilczynski: correct if-statement condition the pci_bar_index_is_valid() helper function uses, tidy up code comments] Signed-off-by: Krzysztof Wilczyński [bhelgaas: fix typo] Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit e64be12f8401819662e608efa247638b61d023cd Author: Emily Deng Date: Thu Mar 6 08:40:01 2025 +0800 drm/amdgpu: Fix the race condition for draining retry fault [ Upstream commit f844732e3ad9c4b78df7436232949b8d2096d1a6 ] Issue: In the scenario where svm_range_restore_pages is called, but svm->checkpoint_ts has not been set and the retry fault has not been drained, svm_range_unmap_from_cpu is triggered and calls svm_range_free. Meanwhile, svm_range_restore_pages continues execution and reaches svm_range_from_addr. This results in a "failed to find prange..." error, causing the page recovery to fail. How to fix: Move the timestamp check code under the protection of svm->lock. v2: Make sure all right locks are released before go out. v3: Directly goto out_unlock_svms, and return -EAGAIN. v4: Refine code. Signed-off-by: Emily Deng Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8feefd106afb0592f8f574b31341dbeb034d9086 Author: Bjorn Helgaas Date: Mon Mar 3 15:02:17 2025 -0600 PCI: Enable Configuration RRS SV early [ Upstream commit 3f8c4959fc18e477801386a625e726c59f52a2c4 ] Following a reset, a Function may respond to Config Requests with Request Retry Status (RRS) Completion Status to indicate that it is temporarily unable to process the Request, but will be able to process the Request in the future (PCIe r6.0, sec 2.3.1). If the Configuration RRS Software Visibility feature is enabled and a Root Complex receives RRS for a config read of the Vendor ID, the Root Complex completes the Request to the host by returning PCI_VENDOR_ID_PCI_SIG, 0x0001 (sec 2.3.2). The Config RRS SV feature applies only to Root Ports and is not directly related to pci_scan_bridge_extend(). Move the RRS SV enable to set_pcie_port_type() where we handle other PCIe-specific configuration. Link: https://lore.kernel.org/r/20250303210217.199504-1-helgaas@kernel.org Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit dc4380f34613eaae997b3ed263bd1cb3d0fd0075 Author: Wentao Liang Date: Thu Mar 6 15:51:48 2025 +0800 drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create() [ Upstream commit 1435e895d4fc967d64e9f5bf81e992ac32f5ac76 ] Add error handling to propagate amdgpu_cgs_create_device() failures to the caller. When amdgpu_cgs_create_device() fails, release hwmgr and return -ENOMEM to prevent null pointer dereference. [v1]->[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr. Signed-off-by: Wentao Liang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7a872981c69d94a710a465155848d527608e12ea Author: Shawn Lin Date: Tue Feb 18 10:21:21 2025 +0100 PCI: Add Rockchip Vendor ID [ Upstream commit 20bbb083bbc9d3f8db390f2e35e168f1b23dae8a ] Move PCI_VENDOR_ID_ROCKCHIP from pci_endpoint_test.c to pci_ids.h and reuse it in pcie-rockchip-host.c. Link: https://lore.kernel.org/r/20250218092120.2322784-2-cassel@kernel.org Signed-off-by: Shawn Lin Signed-off-by: Niklas Cassel Signed-off-by: Bjorn Helgaas Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 6e415cb823b10d9f0c55d48b6519780c3d290123 Author: AngeloGioacchino Del Regno Date: Mon Feb 17 16:48:02 2025 +0100 drm/mediatek: mtk_dpi: Explicitly manage TVD clock in power on/off [ Upstream commit 473c33f5ce651365468503c76f33158aaa1c7dd2 ] In preparation for adding support for MT8195's HDMI reserved DPI, add calls to clk_prepare_enable() / clk_disable_unprepare() for the TVD clock: in this particular case, the aforementioned clock is not (and cannot be) parented to neither pixel or engine clocks hence it won't get enabled automatically by the clock framework. Please note that on all of the currently supported MediaTek platforms, the TVD clock is always a parent of either pixel or engine clocks, and this means that the common clock framework is already enabling this clock before the children. On such platforms, this commit will only increase the refcount of the TVD clock without any functional change. Reviewed-by: CK Hu Signed-off-by: AngeloGioacchino Del Regno Link: https://patchwork.kernel.org/project/dri-devel/patch/20250217154836.108895-10-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 39a7576d113c571f67ddb263fc166904e4f71173 Author: AngeloGioacchino Del Regno Date: Mon Feb 17 16:47:59 2025 +0100 drm/mediatek: mtk_dpi: Move the input_2p_en bit to platform data [ Upstream commit c90876a695dd83e76680b88b40067275a5982811 ] In preparation for adding support for MT8195's HDMI reserved DPI instance, move the input_2p_en bit for DP_INTF to platform data. While at it, remove the input_2pixel member from platform data as having this bit implies that the 2pixel feature must be enabled. Reviewed-by: CK Hu Signed-off-by: AngeloGioacchino Del Regno Link: https://patchwork.kernel.org/project/dri-devel/patch/20250217154836.108895-7-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 831c4017f4ab91f654aa90564c7e9cc922dbca43 Author: Tvrtko Ursulin Date: Thu Feb 27 10:13:01 2025 +0000 drm/xe/xelp: Move Wa_16011163337 from tunings to workarounds [ Upstream commit d9b5d83c5a4d720af6ddbefe2825c78f0325a3fd ] Workaround database specifies 16011163337 as a workaround so lets move it there. Signed-off-by: Tvrtko Ursulin Cc: Lucas De Marchi Cc: Matt Roper Cc: Gustavo Sousa Reviewed-by: Lucas De Marchi Link: https://patchwork.freedesktop.org/patch/msgid/20250227101304.46660-3-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin commit 1a322b330dc0b775d1d7a84e55c752d9451bfe7d Author: Philip Yang Date: Mon Feb 10 09:42:31 2025 -0500 drm/amdkfd: debugfs hang_hws skip GPU with MES [ Upstream commit fe9d0061c413f8fb8c529b18b592b04170850ded ] debugfs hang_hws is used by GPU reset test with HWS, for MES this crash the kernel with NULL pointer access because dqm->packet_mgr is not setup for MES path. Skip GPU with MES for now, MES hang_hws debugfs interface will be supported later. Signed-off-by: Philip Yang Reviewed-by: Kent Russell Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 10ce36501f1e6f54e046f7cd35683a87225e74b0 Author: Philip Yang Date: Thu Feb 20 16:02:13 2025 -0500 drm/amdkfd: Fix pqm_destroy_queue race with GPU reset [ Upstream commit 7919b4cad5545ed93778f11881ceee72e4dbed66 ] If GPU in reset, destroy_queue return -EIO, pqm_destroy_queue should delete the queue from process_queue_list and free the resource. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ffd37d7d44d7e0b6e769d4fe6590e327f8cc3951 Author: Philip Yang Date: Thu Feb 6 17:50:13 2025 -0500 drm/amdkfd: Fix mode1 reset crash issue [ Upstream commit f0b4440cdc1807bb6ec3dce0d6de81170803569b ] If HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal user space to abort the processes. After process abort exit, user queues still use the GPU to access system memory before h/w is reset while KFD cleanup worker free system memory and free VRAM. There is use-after-free race bug that KFD allocate and reuse the freed system memory, and user queue write to the same system memory to corrupt the data structure and cause driver crash. To fix this race, KFD cleanup worker terminate user queues, then flush reset_domain wq to wait for any GPU ongoing reset complete, and then free outstanding BOs. Signed-off-by: Philip Yang Reviewed-by: Lijo Lazar Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 96757c085bd94495ebe4069807f9d35d6d2c75f8 Author: David Yat Sin Date: Tue Feb 25 18:08:02 2025 -0500 drm/amdkfd: clamp queue size to minimum [ Upstream commit e90711946b53590371ecce32e8fcc381a99d6333 ] If queue size is less than minimum, clamp it to minimum to prevent underflow when writing queue mqd. Signed-off-by: David Yat Sin Reviewed-by: Jay Cornwall Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1c38108a49aafeb79e3c7be327612a81a967d9da Author: Lucas De Marchi Date: Fri Feb 21 16:10:41 2025 -0800 drivers: base: devres: Allow to release group on device release [ Upstream commit 8e1ddfada4530939a8cb64ee9251aef780474274 ] When releasing a device, if the release action causes a group to be released, a warning is emitted because it can't find the group. This happens because devres_release_all() moves the entire list to a todo list and also move the group markers. Considering r* normal resource nodes and g1 a group resource node: g1 -----------. v v r1 -> r2 -> g1[0] -> r3-> g[1] -> r4 After devres_release_all(), dev->devres_head becomes empty and the todo list it iterates on becomes: g1 v r1 -> r2 -> r3-> r4 -> g1[0] When a call to component_del() is made and takes down the aggregate device, a warning like this happen: RIP: 0010:devres_release_group+0x362/0x530 ... Call Trace: component_unbind+0x156/0x380 component_unbind_all+0x1d0/0x270 mei_component_master_unbind+0x28/0x80 [mei_hdcp] take_down_aggregate_device+0xc1/0x160 component_del+0x1c6/0x3e0 intel_hdcp_component_fini+0xf1/0x170 [xe] xe_display_fini+0x1e/0x40 [xe] Because the devres group corresponding to the hdcp component cannot be found. Just ignore this corner case: if the dev->devres_head is empty and the caller is trying to remove a group, it's likely in the process of device cleanup so just ignore it instead of warning. Acked-by: Greg Kroah-Hartman Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20250222001051.3012936-2-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin commit c9323cbc94d566dce7f2717b7b4f143250cbdac2 Author: Mike Katsnelson Date: Thu Feb 13 11:52:32 2025 -0500 drm/amd/display: stop DML2 from removing pipes based on planes [ Upstream commit 8adeff83a3b07fa6d0958ed51e1b38ba7469e448 ] [Why] Transitioning from low to high resolutions at high refresh rates caused grey corruption. During the transition state, there is a period where plane size is based on low resultion state and ODM slices are based on high resoultion state, causing the entire plane to be contained in one ODM slice. DML2 would turn off the pipe for the ODM slice with no plane, causing an underflow since the pixel rate for the higher resolution cannot be supported on one pipe. This change stops DML2 from turning off pipes that are mapped to an ODM slice with no plane. This is possible to do without negative consequences because pipes can now take the minimum viewport and draw with zero recout size, removing the need to have the pipe turned off. [How] In map_pipes_from_plane(), remove "check" that skips ODM slices that are not covered by the plane. This prevents the pipes for those ODM slices from being freed. Reviewed-by: Ovidiu Bunea Signed-off-by: Mike Katsnelson Signed-off-by: Zaeem Mohamed Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b22cb42a5ee1d708ec7ac2bc8475399efb7a8a19 Author: Luca Ceresoli Date: Fri Feb 14 13:57:44 2025 +0100 drm/bridge: panel: forbid initializing a panel with unknown connector type [ Upstream commit b296955b3a740ecc8b3b08e34fd64f1ceabb8fb4 ] Having an DRM_MODE_CONNECTOR_Unknown connector type is considered bad, and drm_panel_bridge_add_typed() and derivatives are deprecated for this. drm_panel_init() won't prevent initializing a panel with a DRM_MODE_CONNECTOR_Unknown connector type. Luckily there are no in-tree users doing it, so take this as an opportinuty to document a valid connector type must be passed. Returning an error if this rule is violated is not possible because drm_panel_init() is a void function. Add at least a warning to make any violations noticeable, especially to non-upstream drivers. Reviewed-by: Dmitry Baryshkov Signed-off-by: Luca Ceresoli Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20250214-drm-assorted-cleanups-v7-5-88ca5827d7af@bootlin.com Signed-off-by: Sasha Levin commit f04612890c56d00134c50ca99891b89472a89eea Author: Luca Ceresoli Date: Fri Feb 14 13:57:40 2025 +0100 drm/debugfs: fix printk format for bridge index [ Upstream commit 72443c730b7a7b5670a921ea928e17b9b99bd934 ] idx is an unsigned int, use %u for printk-style strings. Reviewed-by: Dmitry Baryshkov Signed-off-by: Luca Ceresoli Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20250214-drm-assorted-cleanups-v7-1-88ca5827d7af@bootlin.com Signed-off-by: Sasha Levin commit ba5a998f84cdaa0e15c6ec7958fe3226b754e0f3 Author: Andrew Wyatt Date: Thu Feb 13 22:24:53 2025 +0000 drm: panel-orientation-quirks: Add quirk for OneXPlayer Mini (Intel) [ Upstream commit b24dcc183583fc360ae0f0899e286a68f46abbd0 ] The Intel model of the OneXPlayer Mini uses a 1200x1920 portrait LCD panel. The DMI strings are the same as the OneXPlayer, which already has a DMI quirk, but the panel is different. Add a DMI match to correctly rotate this panel. Signed-off-by: Andrew Wyatt Co-developed-by: John Edwards Signed-off-by: John Edwards Tested-by: João Pedro Kurtz Reviewed-by: Thomas Zimmermann Reviewed-by: Hans de Goede Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20250213222455.93533-6-uejji@uejji.net Signed-off-by: Sasha Levin commit a64e0974266e449963a11be2646aa0aa7b999f1f Author: Andrew Wyatt Date: Thu Feb 13 22:24:52 2025 +0000 drm: panel-orientation-quirks: Add new quirk for GPD Win 2 [ Upstream commit a860eb9c6ba6cdbf32e3e01a606556e5a90a2931 ] Some GPD Win 2 units shipped with the correct DMI strings. Add a DMI match to correctly rotate the panel on these units. Signed-off-by: Andrew Wyatt Signed-off-by: John Edwards Tested-by: Paco Avelar Reviewed-by: Thomas Zimmermann Reviewed-by: Hans de Goede Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20250213222455.93533-5-uejji@uejji.net Signed-off-by: Sasha Levin commit 5dd6fdb88953e0c9a60ce882e0e6a695d383486e Author: Andrew Wyatt Date: Thu Feb 13 22:24:51 2025 +0000 drm: panel-orientation-quirks: Add quirk for AYA NEO Slide [ Upstream commit 132c89ef8872e602cfb909377815111d121fe8d7 ] The AYANEO Slide uses a 1080x1920 portrait LCD panel. This is the same panel used on the AYANEO Air Plus, but the DMI data is too different to match both with one entry. Add a DMI match to correctly rotate the panel on the AYANEO Slide. This also covers the Antec Core HS, which is a rebranded AYANEO Slide with the exact same hardware and DMI strings. Signed-off-by: Andrew Wyatt Signed-off-by: John Edwards Tested-by: John Edwards Reviewed-by: Thomas Zimmermann Reviewed-by: Hans de Goede Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20250213222455.93533-4-uejji@uejji.net Signed-off-by: Sasha Levin commit 6fe4ed94ee82ff769907c16f26e99f27a925725a Author: Andrew Wyatt Date: Thu Feb 13 22:24:50 2025 +0000 drm: panel-orientation-quirks: Add quirks for AYA NEO Flip DS and KB [ Upstream commit 529741c331da1fbf54f86c6ec3a4558b9b0b16dc ] The AYA NEO Flip DS and KB both use a 1080x1920 portrait LCD panel. The Flip DS additionally uses a 640x960 portrait LCD panel as a second display. Add DMI matches to correctly rotate these panels. Signed-off-by: Andrew Wyatt Co-developed-by: John Edwards Signed-off-by: John Edwards Tested-by: Paco Avelar Reviewed-by: Thomas Zimmermann Reviewed-by: Hans de Goede Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20250213222455.93533-3-uejji@uejji.net Signed-off-by: Sasha Levin commit df33b535f0deb965fcf8555c1dc11db4b3bbc0ef Author: Andrew Wyatt Date: Thu Feb 13 22:24:49 2025 +0000 drm: panel-orientation-quirks: Add support for AYANEO 2S [ Upstream commit eb8f1e3e8ee10cff591d4a47437dfd34d850d454 ] AYANEO 2S uses the same panel and orientation as the AYANEO 2. Update the AYANEO 2 DMI match to also match AYANEO 2S. Signed-off-by: Andrew Wyatt Signed-off-by: John Edwards Tested-by: John Edwards Reviewed-by: Thomas Zimmermann Reviewed-by: Hans de Goede Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20250213222455.93533-2-uejji@uejji.net Signed-off-by: Sasha Levin commit 357ba4ed6980afe236b961d5bcedc47c22e10f93 Author: Philip Yang Date: Tue Jan 14 09:53:13 2025 -0500 drm/amdgpu: Unlocked unmap only clear page table leaves [ Upstream commit 23b645231eeffdaf44021debac881d2f26824150 ] SVM migration unmap pages from GPU and then update mapping to GPU to recover page fault. Currently unmap clears the PDE entry for range length >= huge page and free PTB bo, update mapping to alloc new PT bo. There is race bug that the freed entry bo maybe still on the pt_free list, reused when updating mapping and then freed, leave invalid PDE entry and cause GPU page fault. By setting the update to clear only one PDE entry or clear PTB, to avoid unmap to free PTE bo. This fixes the race bug and improve the unmap and map to GPU performance. Update mapping to huge page will still free the PTB bo. With this change, the vm->pt_freed list and work is not needed. Add WARN_ON(unlocked) in amdgpu_vm_pt_free_dfs to catch if unmap to free the PTB. Signed-off-by: Philip Yang Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c15a9c84494c1e215a0d26526992e18a86420c84 Author: Zhikai Zhai Date: Thu Jan 9 16:11:48 2025 +0800 drm/amd/display: Update Cursor request mode to the beginning prefetch always [ Upstream commit 4a4077b4b63a8404efd6d37fc2926f03fb25bace ] [Why] The double buffer cursor registers is updated by the cursor vupdate event. There is a gap between vupdate and cursor data fetch if cursor fetch data reletive to cursor position. Cursor corruption will happen if we update the cursor surface in this gap. [How] Modify the cursor request mode to the beginning prefetch always and avoid wraparound calculation issues. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Zhikai Zhai Signed-off-by: Zaeem Mohamed Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2eec2fa8666dcecebae33a565a818c9de9af8b50 Author: Michal Wajdeczko Date: Fri Jan 31 19:25:02 2025 +0100 drm/xe/vf: Don't try to trigger a full GT reset if VF [ Upstream commit 459777724d306315070d24608fcd89aea85516d6 ] VFs don't have access to the GDRST(0x941c) register that driver uses to reset a GT. Attempt to trigger a reset using debugfs: $ cat /sys/kernel/debug/dri/0000:00:02.1/gt0/force_reset or due to a hang condition detected by the driver leads to: [ ] xe 0000:00:02.1: [drm] GT0: trying reset from force_reset [xe] [ ] xe 0000:00:02.1: [drm] GT0: reset queued [ ] xe 0000:00:02.1: [drm] GT0: reset started [ ] ------------[ cut here ]------------ [ ] xe 0000:00:02.1: [drm] GT0: VF is trying to write 0x1 to an inaccessible register 0x941c+0x0 [ ] WARNING: CPU: 3 PID: 3069 at drivers/gpu/drm/xe/xe_gt_sriov_vf.c:996 xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] RIP: 0010:xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] Call Trace: [ ] [ ] ? show_regs+0x6c/0x80 [ ] ? __warn+0x93/0x1c0 [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? report_bug+0x182/0x1b0 [ ] ? handle_bug+0x6e/0xb0 [ ] ? exc_invalid_op+0x18/0x80 [ ] ? asm_exc_invalid_op+0x1b/0x20 [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? xe_gt_tlb_invalidation_reset+0xef/0x110 [xe] [ ] ? __mutex_unlock_slowpath+0x41/0x2e0 [ ] xe_mmio_write32+0x64/0x150 [xe] [ ] do_gt_reset+0x2f/0xa0 [xe] [ ] gt_reset_worker+0x14e/0x1e0 [xe] [ ] process_one_work+0x21c/0x740 [ ] worker_thread+0x1db/0x3c0 Fix that by sending H2G VF_RESET(0x5507) action instead. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4078 Signed-off-by: Michal Wajdeczko Reviewed-by: Lucas De Marchi Link: https://patchwork.freedesktop.org/patch/msgid/20250131182502.852-1-michal.wajdeczko@intel.com Signed-off-by: Sasha Levin commit 4a5f14246bc484db3d06969ddd9831e6bdcf9a29 Author: Shekhar Chauhan Date: Tue Jan 28 21:50:15 2025 +0530 drm/xe/bmg: Add new PCI IDs [ Upstream commit fa8ffaae1b15236b8afb0fbbc04117ff7c900a83 ] Add 3 new PCI IDs for BMG. v2: Fix typo -> Replace '.' with ',' Signed-off-by: Shekhar Chauhan Reviewed-by: Clint Taylor Link: https://patchwork.freedesktop.org/patch/msgid/20250128162015.3288675-1-shekhar.chauhan@intel.com Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 044c1b3528413bdf02711df0e6fb37ef3c5adf6f Author: Abhinav Kumar Date: Wed Dec 11 13:18:42 2024 -0800 drm: allow encoder mode_set even when connectors change for crtc [ Upstream commit 7e182cb4f5567f53417b762ec0d679f0b6f0039d ] In certain use-cases, a CRTC could switch between two encoders and because the mode being programmed on the CRTC remains the same during this switch, the CRTC's mode_changed remains false. In such cases, the encoder's mode_set also gets skipped. Skipping mode_set on the encoder for such cases could cause an issue because even though the same CRTC mode was being used, the encoder type could have changed like the CRTC could have switched from a real time encoder to a writeback encoder OR vice-versa. Allow encoder's mode_set to happen even when connectors changed on a CRTC and not just when the mode changed. Signed-off-by: Abhinav Kumar Signed-off-by: Jessica Zhang Reviewed-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20241211-abhinavk-modeset-fix-v3-1-0de4bf3e7c32@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 09246dfb5c8758113f878456d30c02ecb42b0595 Author: Pedro Nishiyama Date: Sat Mar 1 03:22:59 2025 -0300 Bluetooth: Add quirk for broken READ_PAGE_SCAN_TYPE [ Upstream commit 127881334eaad639e0a19a399ee8c91d6c9dc982 ] Some fake controllers cannot be initialized because they return a smaller report than expected for READ_PAGE_SCAN_TYPE. Signed-off-by: Pedro Nishiyama Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 035e1bffc063399ad1e193f6e4d8f70bb2f6301f Author: Pedro Nishiyama Date: Sat Mar 1 03:22:58 2025 -0300 Bluetooth: Add quirk for broken READ_VOICE_SETTING [ Upstream commit ff26b2dd6568392f60fa67a4e58279938025c3af ] Some fake controllers cannot be initialized because they return a smaller report than expected for READ_VOICE_SETTING. Signed-off-by: Pedro Nishiyama Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit feed98579d4038900e7cfeea676b6e90d009174c Author: Dmitry Baryshkov Date: Fri Feb 7 22:41:16 2025 +0200 Bluetooth: qca: simplify WCN399x NVM loading [ Upstream commit 1cc41b5092e3aa511454ec882c525af311bee631 ] The WCN399x code has two separate cases for loading the NVM data. In preparation to adding support for WCN3950, which also requires similar quirk, split the "variant" to be specified explicitly and merge two snprintfs into a single one. Signed-off-by: Dmitry Baryshkov Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit fe6f1f349d6e0f06c2dd99ccf7a234dbf051c5c3 Author: Janaki Ramaiah Thota Date: Thu Feb 20 16:59:45 2025 +0530 Bluetooth: hci_qca: use the power sequencer for wcn6750 [ Upstream commit 852cfdc7a5a5af54358325c1e0f490cc178d9664 ] Older boards are having entry "enable-gpios" in dts, we can safely assume latest boards which are supporting PMU node enrty will support power sequencer. Signed-off-by: Janaki Ramaiah Thota Reviewed-by: Dmitry Baryshkov Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a4d49212e31620022c38ee4ba7876b0ea275789b Author: Jiande Lu Date: Thu Feb 20 10:01:28 2025 +0800 Bluetooth: btusb: Add 2 HWIDs for MT7922 [ Upstream commit a88643b7e48506777e175e80c902c727ddd90851 ] Add below HWIDs for MediaTek MT7922 USB Bluetooth chip. VID 0x0489, PID 0xe152 VID 0x0489, PID 0xe153 Patch has been tested successfully and controller is recognized device pair successfully. MT7922 module bring up message as below. Bluetooth: Core ver 2.22 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20241106163512 Bluetooth: hci0: Device setup in 2284925 usecs Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported. Bluetooth: hci0: AOSP extensions version v1.00 Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Bluetooth: BNEP filters: protocol multicast Bluetooth: BNEP socket layer initialized Bluetooth: MGMT ver 1.22 Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM ver 1.11 Signed-off-by: Jiande Lu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 6b7a32fa9bacdebd98c18b2a56994116995ee643 Author: Arseniy Krasnov Date: Thu Jan 30 21:43:26 2025 +0300 Bluetooth: hci_uart: fix race during initialization [ Upstream commit 366ceff495f902182d42b6f41525c2474caf3f9a ] 'hci_register_dev()' calls power up function, which is executed by kworker - 'hci_power_on()'. This function does access to bluetooth chip using callbacks from 'hci_ldisc.c', for example 'hci_uart_send_frame()'. Now 'hci_uart_send_frame()' checks 'HCI_UART_PROTO_READY' bit set, and if not - it fails. Problem is that 'HCI_UART_PROTO_READY' is set after 'hci_register_dev()', and there is tiny chance that 'hci_power_on()' will be executed before setting this bit. In that case HCI init logic fails. Patch moves setting of 'HCI_UART_PROTO_READY' before calling function 'hci_uart_register_dev()'. Signed-off-by: Arseniy Krasnov Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 082ae971a1db5bac8a4fa808406b4ce6c82c6f5e Author: Kiran K Date: Thu Jan 16 17:07:09 2025 +0530 Bluetooth: btintel_pcie: Add device id of Whale Peak [ Upstream commit 6b8c05e52d66e4fe4ab1df4c6e15f339ecd9aa51 ] Add device of Whale Peak. Output of sudo lspci -v -s 00:14.7: 00:14.7 Bluetooth: Intel Corporation Device e476 Subsystem: Intel Corporation Device 0011 Flags: bus master, fast devsel, latency 0, IRQ 16, IOMMU group 11 Memory at 11011c30000 (64-bit, non-prefetchable) [size=16K] Capabilities: [c8] Power Management version 3 Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [40] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [80] MSI-X: Enable+ Count=32 Masked- Capabilities: [100] Latency Tolerance Reporting Kernel driver in use: btintel_pcie Kernel modules: btintel_pcie Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 40c70ff44b70564b01f53d0cd86bfb38e7653b37 Author: Gabriele Paoloni Date: Fri Mar 21 18:08:21 2025 +0100 tracing: fix return value in __ftrace_event_enable_disable for TRACE_REG_UNREGISTER [ Upstream commit 0c588ac0ca6c22b774d9ad4a6594681fdfa57d9d ] When __ftrace_event_enable_disable invokes the class callback to unregister the event, the return value is not reported up to the caller, hence leading to event unregister failures being silently ignored. This patch assigns the ret variable to the invocation of the event unregister callback, so that its return value is stored and reported to the caller, and it raises a warning in case of error. Link: https://lore.kernel.org/20250321170821.101403-1-gpaoloni@redhat.com Signed-off-by: Gabriele Paoloni Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 299d7d27af6b5844cda06a0fdfa635705e1bc50f Author: Stanislav Fomichev Date: Thu Mar 13 03:06:57 2025 -0700 net: vlan: don't propagate flags on open [ Upstream commit 27b918007d96402aba10ed52a6af8015230f1793 ] With the device instance lock, there is now a possibility of a deadlock: [ 1.211455] ============================================ [ 1.211571] WARNING: possible recursive locking detected [ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted [ 1.211823] -------------------------------------------- [ 1.211936] ip/184 is trying to acquire lock: [ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0 [ 1.212207] [ 1.212207] but task is already holding lock: [ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.212487] [ 1.212487] other info that might help us debug this: [ 1.212626] Possible unsafe locking scenario: [ 1.212626] [ 1.212751] CPU0 [ 1.212815] ---- [ 1.212871] lock(&dev->lock); [ 1.212944] lock(&dev->lock); [ 1.213016] [ 1.213016] *** DEADLOCK *** [ 1.213016] [ 1.213143] May be due to missing lock nesting notation [ 1.213143] [ 1.213294] 3 locks held by ip/184: [ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0 [ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0 [ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.213895] [ 1.213895] stack backtrace: [ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 [ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [ 1.213994] Call Trace: [ 1.213995] [ 1.213996] dump_stack_lvl+0x8e/0xd0 [ 1.214000] print_deadlock_bug+0x28b/0x2a0 [ 1.214020] lock_acquire+0xea/0x2a0 [ 1.214027] __mutex_lock+0xbf/0xd40 [ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev->flags & IFF_ALLMULTI [ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev [ 1.214042] __dev_open+0x145/0x270 [ 1.214046] __dev_change_flags+0xb0/0x1e0 [ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev [ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev->vlan_info [ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0 [ 1.214058] notifier_call_chain+0x78/0x120 [ 1.214062] netif_open+0x6d/0x90 [ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0 [ 1.214066] bond_enslave+0x64c/0x1230 [ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0 [ 1.214077] do_setlink+0x516/0x13b0 [ 1.214094] rtnl_newlink+0xaba/0xb80 [ 1.214132] rtnetlink_rcv_msg+0x440/0x490 [ 1.214144] netlink_rcv_skb+0xeb/0x120 [ 1.214150] netlink_unicast+0x1f9/0x320 [ 1.214153] netlink_sendmsg+0x346/0x3f0 [ 1.214157] __sock_sendmsg+0x86/0xb0 [ 1.214160] ____sys_sendmsg+0x1c8/0x220 [ 1.214164] ___sys_sendmsg+0x28f/0x2d0 [ 1.214179] __x64_sys_sendmsg+0xef/0x140 [ 1.214184] do_syscall_64+0xec/0x1d0 [ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 1.214191] RIP: 0033:0x7f2d1b4a7e56 Device setup: netdevsim0 (down) ^ ^ bond netdevsim1.100@netdevsim1 allmulticast=on (down) When we enslave the lower device (netdevsim0) which has a vlan, we propagate vlan's allmuti/promisc flags during ndo_open. This causes (re)locking on of the real_dev. Propagate allmulti/promisc on flags change, not on the open. There is a slight semantics change that vlans that are down now propagate the flags, but this seems unlikely to result in the real issues. Reproducer: echo 0 1 > /sys/bus/netdevsim/new_device dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*) dev=$(echo $dev_path | rev | cut -d/ -f1 | rev) ip link set dev $dev name netdevsim0 ip link set dev netdevsim0 up ip link add link netdevsim0 name netdevsim0.100 type vlan id 100 ip link set dev netdevsim0.100 allmulticast on down ip link add name bond1 type bond mode 802.3ad ip link set dev netdevsim0 down ip link set dev netdevsim0 master bond1 ip link set dev bond1 up ip link show Reported-by: syzbot+b0c03d76056ef6cd12a6@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/Z9CfXjLMKn6VLG5d@mini-arch/T/#m15ba130f53227c883e79fb969687d69d670337a0 Signed-off-by: Stanislav Fomichev Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250313100657.2287455-1-sdf@fomichev.me Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit fe51630ba2bad632e8c692df705fd3633b0dbb8f Author: Icenowy Zheng Date: Mon Mar 17 18:22:35 2025 +0800 wifi: mt76: mt76x2u: add TP-Link TL-WDN6200 ID to device table [ Upstream commit 06cccc2ebbe6c8a20f714f3a0ff3ff489d3004bb ] The TP-Link TL-WDN6200 "Driverless" version cards use a MT7612U chipset. Add the USB ID to mt76x2u driver. Signed-off-by: Icenowy Zheng Link: https://patch.msgid.link/20250317102235.1421726-1-uwu@icenowy.me Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit bf089c4d1141b27332c092b1dcca5022c415a3b6 Author: Boris Burkov Date: Wed Mar 5 15:16:57 2025 -0800 btrfs: harden block_group::bg_list against list_del() races [ Upstream commit 7511e29cf1355b2c47d0effb39e463119913e2f6 ] As far as I can tell, these calls of list_del_init() on bg_list cannot run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(), as they are in transaction error paths and situations where the block group is readonly. However, if there is any chance at all of racing with mark_bg_unused(), or a different future user of bg_list, better to be safe than sorry. Otherwise we risk the following interleaving (bg_list refcount in parens) T1 (some random op) T2 (btrfs_mark_bg_unused) !list_empty(&bg->bg_list); (1) list_del_init(&bg->bg_list); (1) list_move_tail (1) btrfs_put_block_group (0) btrfs_delete_unused_bgs bg = list_first_entry list_del_init(&bg->bg_list); btrfs_put_block_group(bg); (-1) Ultimately, this results in a broken ref count that hits zero one deref early and the real final deref underflows the refcount, resulting in a WARNING. Reviewed-by: Qu Wenruo Reviewed-by: Filipe Manana Signed-off-by: Boris Burkov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 0519ba030c3e993007ed4e641ad10a0e13589b7a Author: Huacai Chen Date: Tue Mar 18 18:43:14 2025 +0800 ahci: Marvell 88SE9215 controllers prefer DMA for ATAPI [ Upstream commit 0507c777f5d8f9e34b137d28ee263599a7b81242 ] We use CD/DVD drives under Marvell 88SE9215 SATA controller on many Loongson-based machines. We found its PIO doesn't work well, and on the opposite its DMA seems work very well. We don't know the detail of the 88SE9215 SATA controller, but we have tested different CD/DVD drives and they all have problems under 88SE9215 (but they all work well under an Intel SATA controller). So, we consider this problem is bound to 88SE9215 SATA controller rather than bound to CD/DVD drives. As a solution, we define a new dedicated AHCI board id which is named board_ahci_yes_fbs_atapi_dma for 88SE9215, and for this id we set the AHCI_HFLAG_ATAPI_DMA_QUIRK and ATA_QUIRK_ATAPI_MOD16_DMA flags on the SATA controller in order to prefer ATAPI DMA. Reported-by: Yuli Wang Tested-by: Jie Fan Tested-by: Erpeng Xu Tested-by: Yuli Wang Signed-off-by: Huacai Chen Link: https://lore.kernel.org/r/20250318104314.2160526-1-chenhuacai@loongson.cn Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 7fe3b4deed8b93609058c37c9a11df1d2b2c0423 Author: Kai Mäkisara Date: Tue Mar 11 13:25:14 2025 +0200 scsi: st: Fix array overflow in st_setup() [ Upstream commit a018d1cf990d0c339fe0e29b762ea5dc10567d67 ] Change the array size to follow parms size instead of a fixed value. Reported-by: Chenyuan Yang Closes: https://lore.kernel.org/linux-scsi/CALGdzuoubbra4xKOJcsyThdk5Y1BrAmZs==wbqjbkAgmKS39Aw@mail.gmail.com/ Signed-off-by: Kai Mäkisara Link: https://lore.kernel.org/r/20250311112516.5548-2-Kai.Makisara@kolumbus.fi Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a8a8076210c24fe7121e3c6b7c8caf89d5ae65d5 Author: Philipp Hahn Date: Mon Mar 10 11:17:35 2025 +0100 cdc_ether|r8152: ThinkPad Hybrid USB-C/A Dock quirk [ Upstream commit a07f23ad9baf716cbf7746e452c92960536ceae6 ] Lenovo ThinkPad Hybrid USB-C with USB-A Dock (17ef:a359) is affected by the same problem as the Lenovo Powered USB-C Travel Hub (17ef:721e): Both are based on the Realtek RTL8153B chip used to use the cdc_ether driver. However, using this driver, with the system suspended the device constantly sends pause-frames as soon as the receive buffer fills up. This causes issues with other devices, where some Ethernet switches stop forwarding packets altogether. Using the Realtek driver (r8152) fixes this issue. Pause frames are no longer sent while the host system is suspended. Cc: Leon Schuermann Cc: Jakub Kicinski Cc: Oliver Neukum (maintainer:USB CDC ETHERNET DRIVER) Cc: netdev@vger.kernel.org (open list:NETWORKING DRIVERS) Link: https://git.kernel.org/netdev/net/c/cb82a54904a9 Link: https://git.kernel.org/netdev/net/c/2284bbd0cf39 Link: https://www.lenovo.com/de/de/p/accessories-and-software/docking/docking-usb-docks/40af0135eu Signed-off-by: Philipp Hahn Reviewed-by: Kory Maincent Link: https://patch.msgid.link/484336aad52d14ccf061b535bc19ef6396ef5120.1741601523.git.p.hahn@avm.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit eb59cc31b6ea076021d14b04e7faab1636b87d0e Author: Bhupesh Date: Tue Jan 28 13:57:50 2025 +0530 ext4: ignore xattrs past end [ Upstream commit c8e008b60492cf6fd31ef127aea6d02fd3d314cd ] Once inside 'ext4_xattr_inode_dec_ref_all' we should ignore xattrs entries past the 'end' entry. This fixes the following KASAN reported issue: ================================================================== BUG: KASAN: slab-use-after-free in ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 Read of size 4 at addr ffff888012c120c4 by task repro/2065 CPU: 1 UID: 0 PID: 2065 Comm: repro Not tainted 6.13.0-rc2+ #11 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x1fd/0x300 ? tcp_gro_dev_warn+0x260/0x260 ? _printk+0xc0/0x100 ? read_lock_is_recursive+0x10/0x10 ? irq_work_queue+0x72/0xf0 ? __virt_addr_valid+0x17b/0x4b0 print_address_description+0x78/0x390 print_report+0x107/0x1f0 ? __virt_addr_valid+0x17b/0x4b0 ? __virt_addr_valid+0x3ff/0x4b0 ? __phys_addr+0xb5/0x160 ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 kasan_report+0xcc/0x100 ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 ? ext4_xattr_delete_inode+0xd30/0xd30 ? __ext4_journal_ensure_credits+0x5f0/0x5f0 ? __ext4_journal_ensure_credits+0x2b/0x5f0 ? inode_update_timestamps+0x410/0x410 ext4_xattr_delete_inode+0xb64/0xd30 ? ext4_truncate+0xb70/0xdc0 ? ext4_expand_extra_isize_ea+0x1d20/0x1d20 ? __ext4_mark_inode_dirty+0x670/0x670 ? ext4_journal_check_start+0x16f/0x240 ? ext4_inode_is_fast_symlink+0x2f2/0x3a0 ext4_evict_inode+0xc8c/0xff0 ? ext4_inode_is_fast_symlink+0x3a0/0x3a0 ? do_raw_spin_unlock+0x53/0x8a0 ? ext4_inode_is_fast_symlink+0x3a0/0x3a0 evict+0x4ac/0x950 ? proc_nr_inodes+0x310/0x310 ? trace_ext4_drop_inode+0xa2/0x220 ? _raw_spin_unlock+0x1a/0x30 ? iput+0x4cb/0x7e0 do_unlinkat+0x495/0x7c0 ? try_break_deleg+0x120/0x120 ? 0xffffffff81000000 ? __check_object_size+0x15a/0x210 ? strncpy_from_user+0x13e/0x250 ? getname_flags+0x1dc/0x530 __x64_sys_unlinkat+0xc8/0xf0 do_syscall_64+0x65/0x110 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x434ffd Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 8 RSP: 002b:00007ffc50fa7b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000107 RAX: ffffffffffffffda RBX: 00007ffc50fa7e18 RCX: 0000000000434ffd RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 00007ffc50fa7be0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007ffc50fa7e08 R14: 00000000004bbf30 R15: 0000000000000001 The buggy address belongs to the object at ffff888012c12000 which belongs to the cache filp of size 360 The buggy address is located 196 bytes inside of freed 360-byte region [ffff888012c12000, ffff888012c12168) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12c12 head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x40(head|node=0|zone=0) page_type: f5(slab) raw: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004 raw: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000 head: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004 head: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000 head: 0000000000000001 ffffea00004b0481 ffffffffffffffff 0000000000000000 head: 0000000000000002 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888012c11f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888012c12000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff888012c12080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888012c12100: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888012c12180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Reported-by: syzbot+b244bda78289b00204ed@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b244bda78289b00204ed Suggested-by: Thadeu Lima de Souza Cascardo Signed-off-by: Bhupesh Link: https://patch.msgid.link/20250128082751.124948-2-bhupesh@igalia.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit aa39d45071ec18fc9592e9458556d7b46187eab8 Author: Chao Yu Date: Wed Mar 5 19:07:12 2025 +0800 Revert "f2fs: rebuild nat_bits during umount" [ Upstream commit 19426c4988aa85298c1b4caf2889d37ec5c80fea ] This reverts commit 94c821fb286b545d37549ff30a0c341e066f0d6c. It reports that there is potential corruption in node footer, the most suspious feature is nat_bits, let's revert recovery related code. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 5f815757e6debbe0b7ecd2c99e32a46de196a797 Author: Ojaswin Mujoo Date: Thu Nov 21 18:08:55 2024 +0530 ext4: protect ext4_release_dquot against freezing [ Upstream commit 530fea29ef82e169cd7fe048c2b7baaeb85a0028 ] Protect ext4_release_dquot against freezing so that we don't try to start a transaction when FS is frozen, leading to warnings. Further, avoid taking the freeze protection if a transaction is already running so that we don't need end up in a deadlock as described in 46e294efc355 ext4: fix deadlock with fs freezing and EA inodes Suggested-by: Jan Kara Signed-off-by: Ojaswin Mujoo Reviewed-by: Baokun Li Reviewed-by: Jan Kara Link: https://patch.msgid.link/20241121123855.645335-3-ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 202ba2f483cdceb14b1613adcb30797b48cab745 Author: Daniel Kral Date: Tue Mar 4 10:20:30 2025 +0100 ahci: add PCI ID for Marvell 88SE9215 SATA Controller [ Upstream commit 885251dc35767b1c992f6909532ca366c830814a ] Add support for Marvell Technology Group Ltd. 88SE9215 SATA 6 Gb/s controller, which is e.g. used in the DAWICONTROL DC-614e RAID bus controller and was not automatically recognized before. Tested with a DAWICONTROL DC-614e RAID bus controller. Signed-off-by: Daniel Kral Link: https://lore.kernel.org/r/20250304092030.37108-1-d.kral@proxmox.com Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 163e8c1083b41289aad2afd06c39b9f859dc4ec0 Author: Martin Schiller Date: Thu Feb 27 08:10:58 2025 +0100 net: sfp: add quirk for FS SFP-10GM-T copper SFP+ module [ Upstream commit 05ec5c085eb7ae044d49e04a3cff194a0b2a3251 ] Add quirk for a copper SFP that identifies itself as "FS" "SFP-10GM-T". It uses RollBall protocol to talk to the PHY and needs 4 sec wait before probing the PHY. Signed-off-by: Martin Schiller Link: https://patch.msgid.link/20250227071058.1520027-1-ms@dev.tdt.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ecc461331604b07cdbdb7360dbdf78471653264c Author: Chao Yu Date: Mon Mar 3 11:47:38 2025 +0800 f2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks() [ Upstream commit e6494977bd4a83862118a05f57a8df40256951c0 ] syzbot reports an UBSAN issue as below: ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10 index 18446744073709550692 is out of range for type '__le32[5]' (aka 'unsigned int[5]') CPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0 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_out_of_bounds+0x121/0x150 lib/ubsan.c:429 get_nid fs/f2fs/node.h:381 [inline] f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181 f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:836 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:886 f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/file.c:5093 aio_write+0x56b/0x7c0 fs/aio.c:1633 io_submit_one+0x8a7/0x18a0 fs/aio.c:2052 __do_sys_io_submit fs/aio.c:2111 [inline] __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081 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 RIP: 0033:0x7f238798cde9 index 18446744073709550692 (decimal, unsigned long long) = 0xfffffffffffffc64 (hexadecimal, unsigned long long) = -924 (decimal, long long) In f2fs_truncate_inode_blocks(), UBSAN detects that get_nid() tries to access .i_nid[-924], it means both offset[0] and level should zero. The possible case should be in f2fs_do_truncate_blocks(), we try to truncate inode size to zero, however, dn.ofs_in_node is zero and dn.node_page is not an inode page, so it fails to truncate inode page, and then pass zeroed free_from to f2fs_truncate_inode_blocks(), result in this issue. if (dn.ofs_in_node || IS_INODE(dn.node_page)) { f2fs_truncate_data_blocks_range(&dn, count); free_from += count; } I guess the reason why dn.node_page is not an inode page could be: there are multiple nat entries share the same node block address, once the node block address was reused, f2fs_get_node_page() may load a non-inode block. Let's add a sanity check for such condition to avoid out-of-bounds access issue. Reported-by: syzbot+6653f10281a1badc749e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/66fdcdf3.050a0220.40bef.0025.GAE@google.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 3abe15e756481c45f6acba3d476cb3ca4afc3b61 Author: Manish Dharanenthiran Date: Tue Feb 11 14:33:02 2025 +0530 wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi [ Upstream commit 9a0dddfb30f120db3851627935851d262e4e7acb ] In certain cases, hardware might provide packets with a length greater than the maximum native Wi-Fi header length. This can lead to accessing and modifying fields in the header within the ath12k_dp_rx_h_undecap_nwifi function for DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and potentially resulting in invalid data access and memory corruption. Add a sanity check before processing the SKB to prevent invalid data access in the undecap native Wi-Fi function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Manish Dharanenthiran Signed-off-by: Tamizh Chelvam Raja Link: https://patch.msgid.link/20250211090302.4105141-1-tamizh.raja@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 1833e165005928eeee00d450b7c906e91ea5ffaa Author: Birger Koblitz Date: Tue Feb 18 18:59:40 2025 +0100 net: sfp: add quirk for 2.5G OEM BX SFP [ Upstream commit a85035561025063125f81090e4f2bd65da368c83 ] The OEM SFP-2.5G-BX10-D/U SFP module pair is meant to operate with 2500Base-X. However, in their EEPROM they incorrectly specify: Transceiver codes : 0x00 0x12 0x00 0x00 0x12 0x00 0x01 0x05 0x00 BR, Nominal : 2500MBd Use sfp_quirk_2500basex for this module to allow 2500Base-X mode anyway. Tested on BananaPi R3. Signed-off-by: Birger Koblitz Reviewed-by: Daniel Golle Link: https://patch.msgid.link/20250218-b4-lkmsub-v1-1-1e51dcabed90@birger-koblitz.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 04c0c555049fc7aec7c72011b5fe33c8f4b7a48a Author: Niklas Cassel Date: Fri Feb 21 02:54:23 2025 +0100 ata: libata-eh: Do not use ATAPI DMA for a device limited to PIO mode [ Upstream commit 91ec84f8eaddbc93d7c62e363d68aeb7b89879c7 ] atapi_eh_request_sense() currently uses ATAPI DMA if the SATA controller has ATA_FLAG_PIO_DMA (PIO cmds via DMA) set. However, ATA_FLAG_PIO_DMA is a flag that can be set by a low-level driver on a port at initialization time, before any devices are scanned. If a controller detects a connected device that only supports PIO, we set the flag ATA_DFLAG_PIO. Modify atapi_eh_request_sense() to not use ATAPI DMA if the connected device only supports PIO. Reported-by: Philip Pemberton Closes: https://lore.kernel.org/linux-ide/c6722ee8-5e21-4169-af59-cbbae9edc02f@philpem.me.uk/ Tested-by: Philip Pemberton Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20250221015422.20687-2-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit ccd97c8a4f90810f228ee40d1055148fa146dd57 Author: Edward Adam Davis Date: Thu Feb 20 19:24:19 2025 +0800 jfs: add sanity check for agwidth in dbMount [ Upstream commit ddf2846f22e8575d6b4b6a66f2100f168b8cd73d ] The width in dmapctl of the AG is zero, it trigger a divide error when calculating the control page level in dbAllocAG. To avoid this issue, add a check for agwidth in dbAllocAG. Reported-and-tested-by: syzbot+7c808908291a569281a9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7c808908291a569281a9 Signed-off-by: Edward Adam Davis Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit aeb926e605f97857504bdf748f575e40617e2ef9 Author: Edward Adam Davis Date: Thu Feb 20 19:13:21 2025 +0800 jfs: Prevent copying of nlink with value 0 from disk inode [ Upstream commit b61e69bb1c049cf507e3c654fa3dc1568231bd07 ] syzbot report a deadlock in diFree. [1] When calling "ioctl$LOOP_SET_STATUS64", the offset value passed in is 4, which does not match the mounted loop device, causing the mapping of the mounted loop device to be invalidated. When creating the directory and creating the inode of iag in diReadSpecial(), read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the metapage data it returns is corrupted, which causes the nlink value of 0 to be assigned to the iag inode when executing copy_from_dinode(), which ultimately causes a deadlock when entering diFree(). To avoid this, first check the nlink value of dinode before setting iag inode. [1] WARNING: possible recursive locking detected 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted -------------------------------------------- syz-executor301/5309 is trying to acquire lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 but task is already holding lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(imap->im_aglock[index])); lock(&(imap->im_aglock[index])); *** DEADLOCK *** May be due to missing lock nesting notation 5 locks held by syz-executor301/5309: #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515 #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline] #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026 #2: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669 #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669 stack backtrace: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #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_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037 check_deadlock kernel/locking/lockdep.c:3089 [inline] validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfs_imap.c:552 [inline] duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022 diNewIAG fs/jfs/jfs_imap.c:2597 [inline] diAllocExt fs/jfs/jfs_imap.c:1905 [inline] diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 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 Reported-by: syzbot+355da3b3a74881008e8f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=355da3b3a74881008e8f Signed-off-by: Edward Adam Davis Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit c802a6a4009f585111f903e810b3be9c6d0da329 Author: Rand Deeb Date: Thu Feb 20 12:52:31 2025 +0300 fs/jfs: Prevent integer overflow in AG size calculation [ Upstream commit 7fcbf789629cdb9fbf4e2172ce31136cfed11e5e ] The JFS filesystem calculates allocation group (AG) size using 1 << l2agsize in dbExtendFS(). When l2agsize exceeds 31 (possible with >2TB aggregates on 32-bit systems), this 32-bit shift operation causes undefined behavior and improper AG sizing. On 32-bit architectures: - Left-shifting 1 by 32+ bits results in 0 due to integer overflow - This creates invalid AG sizes (0 or garbage values) in sbi->bmap->db_agsize - Subsequent block allocations would reference invalid AG structures - Could lead to: - Filesystem corruption during extend operations - Kernel crashes due to invalid memory accesses - Security vulnerabilities via malformed on-disk structures Fix by casting to s64 before shifting: bmp->db_agsize = (s64)1 << l2agsize; This ensures 64-bit arithmetic even on 32-bit architectures. The cast matches the data type of db_agsize (s64) and follows similar patterns in JFS block calculation code. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Rand Deeb Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 319877db0aa9624b4b2b3b902f56858c8a0f4491 Author: Rand Deeb Date: Thu Feb 20 12:43:49 2025 +0300 fs/jfs: cast inactags to s64 to prevent potential overflow [ Upstream commit 70ca3246ad201b53a9f09380b3f29d8bac320383 ] The expression "inactags << bmp->db_agl2size" in the function dbFinalizeBmap() is computed using int operands. Although the values (inactags and db_agl2size) are derived from filesystem parameters and are usually small, there is a theoretical risk that the shift could overflow a 32-bit int if extreme values occur. According to the C standard, shifting a signed 32-bit int can lead to undefined behavior if the result exceeds its range. In our case, an overflow could miscalculate free blocks, potentially leading to erroneous filesystem accounting. To ensure the arithmetic is performed in 64-bit space, we cast "inactags" to s64 before shifting. This defensive fix prevents any risk of overflow and complies with kernel coding best practices. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Rand Deeb Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 63148ce4904faa668daffdd1d3c1199ae315ef2c Author: Zhongqiu Han Date: Wed Feb 19 22:02:11 2025 +0800 jfs: Fix uninit-value access of imap allocated in the diMount() function [ Upstream commit 9629d7d66c621671d9a47afe27ca9336bfc8a9ea ] syzbot reports that hex_dump_to_buffer is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171 hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171 print_hex_dump+0x13d/0x3e0 lib/hexdump.c:276 diFree+0x5ba/0x4350 fs/jfs/jfs_imap.c:876 jfs_evict_inode+0x510/0x550 fs/jfs/inode.c:156 evict+0x723/0xd10 fs/inode.c:796 iput_final fs/inode.c:1946 [inline] iput+0x97b/0xdb0 fs/inode.c:1972 txUpdateMap+0xf3e/0x1150 fs/jfs/jfs_txnmgr.c:2367 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x627/0x11d0 fs/jfs/jfs_txnmgr.c:2733 kthread+0x6b9/0xef0 kernel/kthread.c:464 ret_from_fork+0x6d/0x90 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Uninit was created at: slab_post_alloc_hook mm/slub.c:4121 [inline] slab_alloc_node mm/slub.c:4164 [inline] __kmalloc_cache_noprof+0x8e3/0xdf0 mm/slub.c:4320 kmalloc_noprof include/linux/slab.h:901 [inline] diMount+0x61/0x7f0 fs/jfs/jfs_imap.c:105 jfs_mount+0xa8e/0x11d0 fs/jfs/jfs_mount.c:176 jfs_fill_super+0xa47/0x17c0 fs/jfs/super.c:523 get_tree_bdev_flags+0x6ec/0x910 fs/super.c:1636 get_tree_bdev+0x37/0x50 fs/super.c:1659 jfs_get_tree+0x34/0x40 fs/jfs/super.c:635 vfs_get_tree+0xb1/0x5a0 fs/super.c:1814 do_new_mount+0x71f/0x15e0 fs/namespace.c:3560 path_mount+0x742/0x1f10 fs/namespace.c:3887 do_mount fs/namespace.c:3900 [inline] __do_sys_mount fs/namespace.c:4111 [inline] __se_sys_mount+0x71f/0x800 fs/namespace.c:4088 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4088 x64_sys_call+0x39bf/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ===================================================== The reason is that imap is not properly initialized after memory allocation. It will cause the snprintf() function to write uninitialized data into linebuf within hex_dump_to_buffer(). Fix this by using kzalloc instead of kmalloc to clear its content at the beginning in diMount(). Signed-off-by: Zhongqiu Han Reported-by: syzbot+df6cdcb35904203d2b6d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/lkml/67b5d07e.050a0220.14d86d.00e6.GAE@google.com/ Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 8e7bb6636082a9c64da88aff2af82e2466de060f Author: Ciprian Marian Costea Date: Mon Jan 13 14:07:04 2025 +0200 can: flexcan: add NXP S32G2/S32G3 SoC support [ Upstream commit 8503a4b1a24d32e95f3a233062e8f1dc0b2052bd ] Add device type data for S32G2/S32G3 SoC. FlexCAN module from S32G2/S32G3 is similar with i.MX SoCs, but interrupt management is different. On S32G2/S32G3 SoC, there are separate interrupts for state change, bus errors, Mailboxes 0-7 and Mailboxes 8-127 respectively. In order to handle this FlexCAN hardware particularity, first reuse the 'FLEXCAN_QUIRK_NR_IRQ_3' quirk provided by mcf5441x's irq handling support. Secondly, use the newly introduced 'FLEXCAN_QUIRK_SECONDARY_MB_IRQ' quirk which handles the case where two separate mailbox ranges are controlled by independent hardware interrupt lines. Signed-off-by: Ciprian Marian Costea Link: https://patch.msgid.link/20250113120704.522307-4-ciprianmarian.costea@oss.nxp.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit fba5f41f1536086e0c24d444865f035ebf300825 Author: Ciprian Marian Costea Date: Mon Jan 13 14:07:03 2025 +0200 can: flexcan: Add quirk to handle separate interrupt lines for mailboxes [ Upstream commit 8c652cf030a769fbfc73cfc280ed3f1656343c35 ] Introduce 'FLEXCAN_QUIRK_SECONDARY_MB_IRQ' quirk to handle a FlexCAN hardware module integration particularity where two ranges of mailboxes are controlled by separate hardware interrupt lines. The same 'flexcan_irq' handler is used for both separate mailbox interrupt lines, with no other changes. Signed-off-by: Ciprian Marian Costea Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/20250113120704.522307-3-ciprianmarian.costea@oss.nxp.com [mkl: flexcan_open(): change order and free irq_secondary_mb first] Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 7204335d1991c23fc615ab76f31f175748a578e1 Author: Jason Xing Date: Fri Feb 14 14:42:50 2025 +0800 page_pool: avoid infinite loop to schedule delayed worker [ Upstream commit 43130d02baa137033c25297aaae95fd0edc41654 ] We noticed the kworker in page_pool_release_retry() was waken up repeatedly and infinitely in production because of the buggy driver causing the inflight less than 0 and warning us in page_pool_inflight()[1]. Since the inflight value goes negative, it means we should not expect the whole page_pool to get back to work normally. This patch mitigates the adverse effect by not rescheduling the kworker when detecting the inflight negative in page_pool_release_retry(). [1] [Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------ [Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages ... [Mon Feb 10 20:36:11 2025] Call Trace: [Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70 [Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370 [Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0 [Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140 [Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370 [Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40 [Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40 [Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]--- Note: before this patch, the above calltrace would flood the dmesg due to repeated reschedule of release_dw kworker. Signed-off-by: Jason Xing Reviewed-by: Mina Almasry Link: https://patch.msgid.link/20250214064250.85987-1-kerneljasonxing@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit de94d0ca9ea5884c3fe8288176facc205147a913 Author: Max Schulze Date: Wed Feb 12 16:09:51 2025 +0100 net: usb: asix_devices: add FiberGecko DeviceID [ Upstream commit 4079918ae720e842ed7dff65fedeb9980b374995 ] The FiberGecko is a small USB module that connects a 100 Mbit/s SFP Signed-off-by: Max Schulze Tested-by: Max Schulze Suggested-by: David Hollis Reported-by: Sven Kreiensen Link: https://patch.msgid.link/20250212150957.43900-2-max.schulze@online.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 93a562eedcd5da087e30d7e35374fe2bad38f88e Author: Chaohai Chen Date: Wed Jan 15 15:07:39 2025 +0800 scsi: target: spc: Fix RSOC parameter data header size [ Upstream commit b50532318793d28a7628c1ffc129a2226e83e495 ] The SPC document states that "The COMMAND DATA LENGTH field indicates the length in bytes of the command descriptor list". The length should be subtracted by 4 to represent the length of the description list, not 3. Signed-off-by: Chaohai Chen Link: https://lore.kernel.org/r/20250115070739.216154-1-wdhh66@163.com Reviewed-by: Dmitry Bogdanov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4ae2c7c7d36976b381352b34eab6bf501afe0f1a Author: Miri Korenblit Date: Wed Feb 5 11:39:26 2025 +0200 wifi: mac80211: ensure sdata->work is canceled before initialized. [ Upstream commit 6c93fd502023dd919b5987ccbe990735410edd49 ] This wiphy work is canceled when the iface is stopped, and shouldn't be queued for a non-running iface. If it happens to be queued for a non-running iface (due to a bug) it can cause a corruption of wiphy_work_list when ieee80211_setup_sdata is called. Make sure to cancel it in this case and warn on. Signed-off-by: Miri Korenblit Reviewed-by: Johannes Berg Link: https://patch.msgid.link/20250205110958.99204c767c10.I84ce27a239059f6009cee197b252549a11426046@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit cca16fbd17b0aa1709be2373f362931c9f847108 Author: Johannes Berg Date: Wed Feb 5 11:39:16 2025 +0200 wifi: mac80211: add strict mode disabling workarounds [ Upstream commit 3ad4fce66e4f9d82abfc366707757e29cc14a9d2 ] Add a strict mode where we disable certain workarounds and have additional checks such as, for now, that VHT capabilities from association response match those from beacon/probe response. We can extend the checks in the future. Make it an opt-in setting by the driver so it can be set there in some driver-specific way, for example. Also allow setting this one hw flag through the hwflags debugfs, by writing a new strict=0 or strict=1 value. Signed-off-by: Johannes Berg Reviewed-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250205110958.5cecb0469479.I4a69617dc60ba0d6308416ffbc3102cfd08ba068@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c6e50cb8bf57dfa90f65303e15eab02a561f6add Author: Chao Yu Date: Mon Feb 10 15:36:32 2025 +0800 f2fs: don't retry IO for corrupted data scenario [ Upstream commit 1534747d3170646ddeb9ea5f7caaac90359707cf ] F2FS-fs (dm-105): inconsistent node block, nid:430, node_footer[nid:2198964142,ino:598252782,ofs:118300154,cpver:5409237455940746069,blkaddr:2125070942] F2FS-fs (dm-105): inconsistent node block, nid:430, node_footer[nid:2198964142,ino:598252782,ofs:118300154,cpver:5409237455940746069,blkaddr:2125070942] F2FS-fs (dm-105): inconsistent node block, nid:430, node_footer[nid:2198964142,ino:598252782,ofs:118300154,cpver:5409237455940746069,blkaddr:2125070942] F2FS-fs (dm-105): inconsistent node block, nid:430, node_footer[nid:2198964142,ino:598252782,ofs:118300154,cpver:5409237455940746069,blkaddr:2125070942] F2FS-fs (dm-105): inconsistent node block, nid:430, node_footer[nid:2198964142,ino:598252782,ofs:118300154,cpver:5409237455940746069,blkaddr:2125070942] F2FS-fs (dm-105): inconsistent node block, nid:430, node_footer[nid:2198964142,ino:598252782,ofs:118300154,cpver:5409237455940746069,blkaddr:2125070942] F2FS-fs (dm-105): inconsistent node block, nid:430, node_footer[nid:2198964142,ino:598252782,ofs:118300154,cpver:5409237455940746069,blkaddr:2125070942] F2FS-fs (dm-105): inconsistent node block, nid:430, node_footer[nid:2198964142,ino:598252782,ofs:118300154,cpver:5409237455940746069,blkaddr:2125070942] F2FS-fs (dm-105): inconsistent node block, nid:430, node_footer[nid:2198964142,ino:598252782,ofs:118300154,cpver:5409237455940746069,blkaddr:2125070942] F2FS-fs (dm-105): inconsistent node block, nid:430, node_footer[nid:2198964142,ino:598252782,ofs:118300154,cpver:5409237455940746069,blkaddr:2125070942] If node block is loaded successfully, but its content is inconsistent, it doesn't need to retry IO. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit a6bf0fd322abd0e432847857e3f86a308a86762e Author: Pavel Begunkov Date: Tue Feb 4 13:56:12 2025 -0800 net: page_pool: don't cast mp param to devmem [ Upstream commit 8d522566ae9cb3f0609ddb2a6ce3f4f39988043c ] page_pool_check_memory_provider() is a generic path and shouldn't assume anything about the actual type of the memory provider argument. It's fine while devmem is the only provider, but cast away the devmem specific binding types to avoid confusion. Reviewed-by: Jakub Kicinski Reviewed-by: Mina Almasry Signed-off-by: Pavel Begunkov Signed-off-by: David Wei Link: https://patch.msgid.link/20250204215622.695511-2-dw@davidwei.uk Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 65ba18c84dbd03afe9b38c06c151239d97a09834 Author: Ranjan Kumar Date: Wed Jan 29 15:38:49 2025 +0530 scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue [ Upstream commit f195fc060c738d303a21fae146dbf85e1595fb4c ] When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable. Signed-off-by: Sumit Saxena Signed-off-by: Ranjan Kumar Link: https://lore.kernel.org/r/20250129100850.25430-4-ranjan.kumar@broadcom.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6a35449df867a04450e51194b4d9ba2f896bbe71 Author: Ranjan Kumar Date: Wed Jan 29 15:38:47 2025 +0530 scsi: mpi3mr: Avoid reply queue full condition [ Upstream commit f08b24d82749117ce779cc66689e8594341130d3 ] To avoid reply queue full condition, update the driver to check IOCFacts capabilities for qfull. Update the operational reply queue's Consumer Index after processing 100 replies. If pending I/Os on a reply queue exceeds a threshold (reply_queue_depth - 200), then return I/O back to OS to retry. Also increase default admin reply queue size to 2K. Signed-off-by: Sumit Saxena Signed-off-by: Ranjan Kumar Link: https://lore.kernel.org/r/20250129100850.25430-2-ranjan.kumar@broadcom.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b1e0b4f494c5c3aec775fb6afa91cb84b2f12afc Author: Niklas Cassel Date: Thu Jan 30 14:35:46 2025 +0100 ata: libata-core: Add 'external' to the libata.force kernel parameter [ Upstream commit deca423213cb33feda15e261e7b5b992077a6a08 ] Commit ae1f3db006b7 ("ata: ahci: do not enable LPM on external ports") changed so that LPM is not enabled on external ports (hotplug-capable or eSATA ports). This is because hotplug and LPM are mutually exclusive, see 7.3.1 Hot Plug Removal Detection and Power Management Interaction in AHCI 1.3.1. This does require that firmware has set the appropate bits (HPCP or ESP) in PxCMD (which is a per port register in the AHCI controller). If the firmware has failed to mark a port as hotplug-capable or eSATA in PxCMD, then there is currently not much a user can do. If LPM is enabled on the port, hotplug insertions and removals will not be detected on that port. In order to allow a user to fix up broken firmware, add 'external' to the libata.force kernel parameter. libata.force can be specified either on the kernel command line, or as a kernel module parameter. For more information, see Documentation/admin-guide/kernel-parameters.txt. Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20250130133544.219297-4-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 535b666118f6ddeae90a480a146c061796d37022 Author: P Praneesh Date: Mon Dec 23 11:31:24 2024 +0530 wifi: ath12k: Fix invalid entry fetch in ath12k_dp_mon_srng_process [ Upstream commit 63fdc4509bcf483e79548de6bc08bf3c8e504bb3 ] Currently, ath12k_dp_mon_srng_process uses ath12k_hal_srng_src_get_next_entry to fetch the next entry from the destination ring. This is incorrect because ath12k_hal_srng_src_get_next_entry is intended for source rings, not destination rings. This leads to invalid entry fetches, causing potential data corruption or crashes due to accessing incorrect memory locations. This happens because the source ring and destination ring have different handling mechanisms and using the wrong function results in incorrect pointer arithmetic and ring management. To fix this issue, replace the call to ath12k_hal_srng_src_get_next_entry with ath12k_hal_srng_dst_get_next_entry in ath12k_dp_mon_srng_process. This ensures that the correct function is used for fetching entries from the destination ring, preventing invalid memory accesses. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh Link: https://patch.msgid.link/20241223060132.3506372-7-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 3cb47b50926a5b9eef8c06506a14cdc0f3d95c53 Author: Miaoqing Pan Date: Thu Jan 23 16:02:26 2025 +0800 wifi: ath12k: fix memory leak in ath12k_pci_remove() [ Upstream commit 1b24394ed5c8a8d8f7b9e3aa9044c31495d46f2e ] Kmemleak reported this error: unreferenced object 0xffff1c165cec3060 (size 32): comm "insmod", pid 560, jiffies 4296964570 (age 235.596s) backtrace: [<000000005434db68>] __kmem_cache_alloc_node+0x1f4/0x2c0 [<000000001203b155>] kmalloc_trace+0x40/0x88 [<0000000028adc9c8>] _request_firmware+0xb8/0x608 [<00000000cad1aef7>] firmware_request_nowarn+0x50/0x80 [<000000005011a682>] local_pci_probe+0x48/0xd0 [<00000000077cd295>] pci_device_probe+0xb4/0x200 [<0000000087184c94>] really_probe+0x150/0x2c0 The firmware memory was allocated in ath12k_pci_probe(), but not freed in ath12k_pci_remove() in case ATH12K_FLAG_QMI_FAIL bit is set. So call ath12k_fw_unmap() to free the memory. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.2.0-02280-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Signed-off-by: Miaoqing Pan Reviewed-by: Aditya Kumar Singh Link: https://patch.msgid.link/20250123080226.1116479-1-quic_miaoqing@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit a3981850f14ecda037459863f17816961b1c470e Author: Miaoqing Pan Date: Thu Jan 23 16:49:48 2025 +0800 wifi: ath11k: fix memory leak in ath11k_xxx_remove() [ Upstream commit efb24b1f0d29537714dd3cc46fb335ac27855251 ] The firmware memory was allocated in ath11k_pci_probe() or ath11k_ahb_probe(), but not freed in ath11k_xxx_remove() in case ATH11K_FLAG_QMI_FAIL bit is set. So call ath11k_fw_destroy() to free the memory. Found while fixing the same problem in ath12k: https://lore.kernel.org/linux-wireless/20240314012746.2729101-1-quic_miaoqing@quicinc.com Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04546-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Signed-off-by: Miaoqing Pan Reviewed-by: Aditya Kumar Singh Link: https://patch.msgid.link/20250123084948.1124357-1-quic_miaoqing@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit b92c5179db4b19152c6492d1dfda457bff789272 Author: P Praneesh Date: Sun Jan 19 22:12:18 2025 +0530 wifi: ath11k: Fix DMA buffer allocation to resolve SWIOTLB issues [ Upstream commit 1bcd20981834928ccc5d981aacb806bb523d8b29 ] Currently, the driver allocates cacheable DMA buffers for rings like HAL_REO_DST and HAL_WBM2SW_RELEASE. The buffers for HAL_WBM2SW_RELEASE are large (1024 KiB), exceeding the SWIOTLB slot size of 256 KiB. This leads to "swiotlb buffer is full" error messages on systems without an IOMMU that use SWIOTLB, causing driver initialization failures. The driver calls dma_map_single() with these large buffers obtained from kzalloc(), resulting in ring initialization errors on systems without an IOMMU that use SWIOTLB. To address these issues, replace the flawed buffer allocation mechanism with the appropriate DMA API. Specifically, use dma_alloc_noncoherent() for cacheable DMA buffers, ensuring proper freeing of buffers with dma_free_noncoherent(). Error log: [ 10.194343] ath11k_pci 0000:04:00.0: swiotlb buffer is full (sz:1048583 bytes), total 32768 (slots), used 2529 (slots) [ 10.194406] ath11k_pci 0000:04:00.0: failed to set up tcl_comp ring (0) :-12 [ 10.194781] ath11k_pci 0000:04:00.0: failed to init DP: -12 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Reported-by: Tim Harvey Closes: https://lore.kernel.org/all/20241210041133.GA17116@lst.de/ Signed-off-by: P Praneesh Tested-by: Tim Harvey Link: https://patch.msgid.link/20250119164219.647059-2-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 90a5892d8531ae031fb44027b61683882a4c63b2 Author: Hans de Goede Date: Mon Mar 24 13:50:52 2025 +0100 platform/x86: x86-android-tablets: Add select POWER_SUPPLY to Kconfig [ Upstream commit 2c30357e755b087217c7643fda2b8aea6d6deda4 ] Commit c78dd25138d1 ("platform/x86: x86-android-tablets: Add Vexia EDU ATLA 10 EC battery driver"), adds power_supply class registering to the x86-android-tablets code. Add "select POWER_SUPPLY" to the Kconfig entry to avoid these errors: ERROR: modpost: "power_supply_get_drvdata" [drivers/platform/x86/x86-android-tablets/vexia_atla10_ec.ko] undefined! ERROR: modpost: "power_supply_changed" [drivers/platform/x86/x86-android-tablets/vexia_atla10_ec.ko] undefined! ERROR: modpost: "devm_power_supply_register" [drivers/platform/x86/x86-android-tablets/vexia_atla10_ec.ko] undefined! When POWER_SUPPLY support is not enabled. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202503231159.ga9eWMVO-lkp@intel.com/ Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20250324125052.374369-1-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 7f04c9e8fffed4bc691daadea7f6166ae3d9e672 Author: Syed Saba kareem Date: Fri Mar 21 17:55:03 2025 +0530 ASoC: amd: yc: update quirk data for new Lenovo model [ Upstream commit 5a4dd520ef8a94ecf81ac77b90d6a03e91c100a9 ] Update Quirk data for new Lenovo model 83J2 for YC platform. Signed-off-by: Syed Saba kareem Link: https://patch.msgid.link/20250321122507.190193-1-syed.sabakareem@amd.com Reported-by: Reiner Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219887 Tested-by: Reiner Reviewed-by: Mario Limonciello Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3a03a7f0f872a1a6f53adccf3660924264bf0650 Author: keenplify Date: Sat Mar 15 19:16:17 2025 +0800 ASoC: amd: Add DMI quirk for ACP6X mic support [ Upstream commit 309b367eafc8e162603cd29189da6db770411fea ] Some AMD laptops with ACP6X do not expose the DMIC properly on Linux. Adding a DMI quirk enables mic functionality. Similar to Bugzilla #218402, this issue affects multiple users. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219853 Signed-off-by: keenplify Link: https://patch.msgid.link/20250315111617.12194-1-keenplify@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cb1c6cb1105630edf0959aeac8d41c5f48ab686c Author: Ricard Wanderlof Date: Thu Mar 13 23:16:17 2025 +0100 ALSA: usb-audio: Fix CME quirk for UF series keyboards [ Upstream commit c2820405ba55a38932aa2177f026b70064296663 ] Fix quirk for CME master keyboards so it not only handles sysex but also song position pointer, MIDI timing clock, start and stop messages, and active sensing. All of these can be output by the CME UF series master keyboards. Tested with a CME UF6 in a desktop Linux environment as well as on the Zynthian Raspberry Pi based platform. Signed-off-by: Ricard Wanderlof Link: https://patch.msgid.link/20250313-cme-fix-v1-1-d404889e4de8@butoba.net Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit fe74885e3609ce74bc314992b7606249ed2acec9 Author: Kaustabh Chakraborty Date: Wed Feb 19 00:17:48 2025 +0530 mmc: dw_mmc: add a quirk for accessing 64-bit FIFOs in two halves [ Upstream commit 57c0902f8bec51add5a1eb908d8b876592725d81 ] In certain DW MMC implementations (such as in some Exynos7870 controllers), 64-bit read/write is not allowed from a 64-bit FIFO. Add a quirk which facilitates accessing the 64-bit FIFO registers in two 32-bit halves. Signed-off-by: Kaustabh Chakraborty Link: https://lore.kernel.org/r/20250219-exynos7870-mmc-v2-2-b4255a3e39ed@disroot.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 6d32a30fa1b5795053676de566f11568e8c1467c Author: Aakarsh Jain Date: Wed Feb 26 15:52:51 2025 +0530 media: s5p-mfc: Corrected NV12M/NV21M plane-sizes [ Upstream commit 7d0d0b2342bebc47a46499cdf21257ed1e58c4aa ] There is a possibility of getting page fault if the overall buffer size is not aligned to 256bytes. Since MFC does read operation only and it won't corrupt the data values even if it reads the extra bytes. Corrected luma and chroma plane sizes for V4L2_PIX_FMT_NV12M and V4L2_PIX_FMT_NV21M pixel format. Suggested-by: Hans Verkuil Signed-off-by: Aakarsh Jain Reviewed-by: Nicolas Dufresne Acked-by: Marek Szyprowski Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 3c057a49045ffcb0a03242192b90e2eb7610fb45 Author: Ricardo Ribalda Date: Tue Dec 10 10:48:14 2024 +0000 media: uvcvideo: Add quirk for Actions UVC05 [ Upstream commit 8c54e58f94ed3ff28643aefd2c0c2c98313ee770 ] Actions UVC05 is a HDMI to USB dongle that implements the UVC protocol. When the device suspends, its firmware seems to enter a weird mode when it does not produce more frames. Add the device to the quirk list to disable autosuspend. Bus 001 Device 007: ID 1de1:f105 Actions Microelectronics Co. Display capture-UVC05 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 [unknown] bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x1de1 Actions Microelectronics Co. idProduct 0xf105 Display capture-UVC05 bcdDevice 4.09 iManufacturer 1 Actions Micro iProduct 2 Display capture-UVC05 iSerial 3 -1005308387 bNumConfigurations 1 Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20241210-uvc-hdmi-suspend-v1-1-01f5dec023ea@chromium.org Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit d4fcd06e1231bf0cc75af312b4ee9a7a3d12409e Author: Shengjiu Wang Date: Wed Feb 26 18:05:08 2025 +0800 ASoC: fsl_audmix: register card device depends on 'dais' property [ Upstream commit 294a60e5e9830045c161181286d44ce669f88833 ] In order to make the audmix device linked by audio graph card, make 'dais' property to be optional. If 'dais' property exists, then register the imx-audmix card driver. otherwise, it should be linked by audio graph card. Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20250226100508.2352568-5-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d981c3d2980aa5564ac4b5acc529c423fc20a17f Author: Maxim Mikityanskiy Date: Sat Feb 8 23:46:02 2025 +0200 ALSA: hda: intel: Add Lenovo IdeaPad Z570 to probe denylist [ Upstream commit becc794c5e46f4dfca59f2385f78d83fc9e84700 ] Lenovo IdeaPad Z570 with NVIDIA GeForce Ge 540M doesn't have sound on the discrete GPU. The HDA controller in DGPU is disabled by BIOS, but then reenabled by quirk_nvidia_hda(). The probe fails and ends up with the "GPU sound probed, but not operational" error. Add this laptop to DMI-based denylist to prevent probe early. DMI is used, because the audio device has zero subsystem IDs, and this entry would be too much, blocking all 540M chips: PCI_DEVICE_SUB(0x10de, 0x0bea, 0x0000, 0x0000) Also, this laptop comes in a variety of modifications with different NVIDIA GPUs, so the DMI check will cover them all. Signed-off-by: Maxim Mikityanskiy Link: https://patch.msgid.link/20250208214602.39607-3-maxtram95@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 97ae1d5080f7fb6379f79ea2909ba4c96e2aef75 Author: Maxim Mikityanskiy Date: Sat Feb 8 23:46:01 2025 +0200 ALSA: hda: intel: Fix Optimus when GPU has no sound [ Upstream commit 2b360ba9a4936486380bc30d1eabceb40a714d98 ] quirk_nvidia_hda() forcefully enables HDA controller on all NVIDIA GPUs, because some buggy BIOSes leave it disabled. However, some dual-GPU laptops do not have a functional HDA controller in DGPU, and BIOS disables it on purpose. After quirk_nvidia_hda() reenables this dummy HDA controller, attempting to probe it fails at azx_first_init(), which is too late to cancel the probe, as it happens in azx_probe_continue(). The sna_hda_intel driver calls azx_free() and stops the chip, however, it stays probed, and from the runtime PM point of view, the device remains active (it was set as active by the PCI subsystem on probe). It prevents vga_switcheroo from turning off the DGPU, because pci_create_device_link() syncs power management for video and audio devices. Affected devices should be added to driver_denylist to prevent them from probing early. This patch helps identify such devices by printing a warning, and also forces the device to the suspended state to allow vga_switcheroo turn off DGPU. Signed-off-by: Maxim Mikityanskiy Link: https://patch.msgid.link/20250208214602.39607-2-maxtram95@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 25490b45d17cd3612b712b4b7dec6ce8986ebb42 Author: Vijendar Mukunda Date: Fri Feb 7 11:57:56 2025 +0530 ASoC: amd: ps: use macro for ACP6.3 pci revision id [ Upstream commit 4b36a47e2d989b98953dbfb1e97da0f0169f5086 ] Use macro for ACP6.3 PCI revision id instead of hard coded value. Signed-off-by: Vijendar Mukunda Link: https://patch.msgid.link/20250207062819.1527184-3-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f8f4d77710e1c38f4a2bd26c88c4878b5b5e817a Author: Tomasz Pakuła Date: Sat Feb 1 12:39:02 2025 +0100 HID: pidff: Fix null pointer dereference in pidff_find_fields [ Upstream commit 22a05462c3d0eee15154faf8d13c49e6295270a5 ] This function triggered a null pointer dereference if used to search for a report that isn't implemented on the device. This happened both for optional and required reports alike. The same logic was applied to pidff_find_special_field and although pidff_init_fields should return an error earlier if one of the required reports is missing, future modifications could change this logic and resurface this possible null pointer dereference again. LKML bug report: https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com Reported-by: Nolan Nicholson Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 0301b85fe6f983d41c0a85e94161e1f262716384 Author: Tomasz Pakuła Date: Sat Feb 1 12:38:56 2025 +0100 HID: pidff: Add PERIODIC_SINE_ONLY quirk [ Upstream commit abdbf8764f4962af2a910abb3a213ecf304a73d3 ] Some devices only support SINE periodic effect although they advertise support for all PERIODIC effect in their HID descriptor. Some just do nothing when trying to play such an effect (upload goes fine), some express undefined behavior like turning to one side. This quirk forces all the periodic effects to be uploaded as SINE. This is acceptable as all these effects are similar in nature and are mostly used as rumble. SINE is the most popular with others seldom used (especially SAW_UP and SAW_DOWN). Fixes periodic effects for PXN and LITE STAR wheels Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Cristóferson Bueno Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit f45f26a6b3e7260c129c7c6bb0ace63aeb7b3868 Author: Tomasz Pakuła Date: Sat Feb 1 12:38:54 2025 +0100 HID: Add hid-universal-pidff driver and supported device ids [ Upstream commit f06bf8d94fffbb544b1cb5402c92e0a075f0d420 ] Extend pidff compatibility, usable button range, manage pidff quirks and set improved fuzz/flat default for high precision devices. Possibility of fixing device descriptors in the future if such needs arises. As many of PID devices are quite similar and not dependent on custom drivers, this one can handle all of PID devices which need special care. Numerous sim racing/sim flight bases report a lot of buttons in excess of 100. Moza Racing exposes 128 of them and thus the need to extend the available range. All the included devices were tested and confirmed working with the help of the sim racing community. Changes in v6: - Support "split" devices with a separate "input device" for buttons - Fixed comment styling Co-developed-by: Makarenko Oleg Signed-off-by: Makarenko Oleg Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 116d4f67aeb5d8aeec58106d72be3ea1d0dc4835 Author: Tomasz Pakuła Date: Sat Feb 1 12:38:52 2025 +0100 HID: pidff: Add FIX_WHEEL_DIRECTION quirk [ Upstream commit 3051bf5ec773b803c474ea556b57d678a8885be3 ] Most steering wheels simply ignore DIRECTION field, but some try to be compliant with the PID standard and use it in force calculations. Games often ignore setting this field properly and/or there can be issues with dinput8 -> wine -> SDL -> Linux API translation, and this value can be incorrect. This can lead to partial/complete loss of Force Feedback or even unexpected force reversal. Sadly, this quirk can't be detected automatically without sending out effects that would move an axis. This fixes FFB on Moza Racing devices and others where effect direction is not simply ignored. Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit ed806fd80eba04789915e90c3a087381df0ce0d9 Author: Tomasz Pakuła Date: Sat Feb 1 12:38:51 2025 +0100 HID: pidff: Add hid_pidff_init_with_quirks and export as GPL symbol [ Upstream commit 36de0164bbaff1484288e84ac5df5cff00580263 ] This lays out a way to provide an initial set of quirks to enable before device initialization takes place. GPL symbol export needed for the possibility of building HID drivers which use this function as modules. Adding a wrapper function to ensure compatibility with the old behavior of hid_pidff_init. Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 6a20fae104ef93f631b52bca4946eedf403be47c Author: Tomasz Pakuła Date: Sat Feb 1 12:38:50 2025 +0100 HID: pidff: Add PERMISSIVE_CONTROL quirk [ Upstream commit a4119108d2530747e61c7cbf52e2affd089cb1f6 ] With this quirk, a PID device isn't required to have a strict logical_minimum of 1 for the the PID_DEVICE_CONTROL usage page. Some devices come with weird values in their device descriptors and this quirk enables their initialization even if the logical minimum of the DEVICE_CONTROL page is not 1. Fixes initialization of VRS Direct Force Pro Changes in v6: - Change quirk name to better reflect it's intention Co-developed-by: Makarenko Oleg Signed-off-by: Makarenko Oleg Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit fd608e2a06c25db6e516e852e72c0a0ed4573838 Author: Tomasz Pakuła Date: Sat Feb 1 12:38:49 2025 +0100 HID: pidff: Add MISSING_PBO quirk and its detection [ Upstream commit fc7c154e9bb3c2b98875cfc565406f4787e3b7a4 ] Some devices with only one axis are missing PARAMETER_BLOCK_OFFSET field for conditional effects. They can only have one axis, so we're limiting the max_axis when setting the report for those effects. Automatic detection ensures compatibility even if such device won't be explicitly defined in the kernel. Fixes initialization of VRS DirectForce PRO and possibly other devices. Changes in v6: - Fixed NULL pointer dereference. When PBO is missing, make sure not to set it anyway Co-developed-by: Makarenko Oleg Signed-off-by: Makarenko Oleg Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit fab3dbb604be87374120a1d069b670cd4915882a Author: Tomasz Pakuła Date: Sat Feb 1 12:38:48 2025 +0100 HID: pidff: Add MISSING_DELAY quirk and its detection [ Upstream commit 2d5c7ce5bf4cc27db41632f357f682d0ee4518e7 ] A lot of devices do not include this field, and it's seldom used in force feedback implementations. I tested about three dozen applications and none of them make use of the delay. This fixes initialization of a lot of PID wheels like Cammus, VRS, FFBeast This change has no effect on fully compliant devices Co-developed-by: Makarenko Oleg Signed-off-by: Makarenko Oleg Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit d21ccf544ca15c863331a8c1e0c377ca4fd18ffe Author: Tomasz Pakuła Date: Sat Feb 1 12:38:46 2025 +0100 HID: pidff: Do not send effect envelope if it's empty [ Upstream commit 8876fc1884f5b39550c8387ff3176396c988541d ] Envelope struct is always initialized, but the envelope itself is optional as described in USB PID Device class definition 1.0. 5.1.1.1 Type Specific Block Offsets ... 4) Effects that do not use Condition Blocks use 1 Parameter Block and an *optional* Envelope Block. Sending out "empty" envelope breaks force feedback on some devices with games that use SINE effect + offset to emulate constant force effect, as well as generally breaking Constant/Periodic effects. One of the affected brands is Moza Racing. This change prevents the envelope from being sent if it contains all 0 values while keeping the old behavior of only sending it, if it differs from the old one. Changes in v6: - Simplify the checks to make them clearer - Fix possible null pointer dereference while calling pidff_needs_set_envelope Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 1c0785f16472cedc1db41222e4d4993605ed5a6a Author: Tomasz Pakuła Date: Sat Feb 1 12:38:45 2025 +0100 HID: pidff: Convert infinite length from Linux API to PID standard [ Upstream commit 37e0591fe44dce39d1ebc7a82d5b6e4dba1582eb ] Software uses 0 as de-facto infinite lenght on Linux FF apis (SDL), Linux doesn't actually define anythi as of now, while USB PID defines NULL (0xffff). Most PID devices do not expect a 0-length effect and can't interpret it as infinite. This change fixes Force Feedback for most PID compliant devices. As most games depend on updating the values of already playing infinite effects, this is crucial to ensure they will actually work. Previously, users had to rely on third-party software to do this conversion and make their PID devices usable. Co-developed-by: Makarenko Oleg Signed-off-by: Makarenko Oleg Signed-off-by: Tomasz Pakuła Reviewed-by: Michał Kopeć Reviewed-by: Paul Dino Jones Tested-by: Paul Dino Jones Tested-by: Cristóferson Bueno Tested-by: Pablo Cisneros Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 5330ce1ee2bec9e51334996965cb15faed5fbd9c Author: Zhang Heng Date: Fri Jan 17 09:43:43 2025 +0800 ASoC: SOF: topology: Use krealloc_array() to replace krealloc() [ Upstream commit a05143a8f713d9ae6abc41141dac52c66fca8b06 ] Use krealloc_array() to replace krealloc() with multiplication. krealloc_array() has multiply overflow check, which will be safer. Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20250117014343.451503-1-zhangheng@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 377b041c22ac204465b40b5f0e0100734fa443e4 Author: Daniel Schaefer Date: Wed Jan 29 02:13:29 2025 +0800 platform/chrome: cros_ec_lpc: Match on Framework ACPI device [ Upstream commit d83c45aeec9b223fe6db4175e9d1c4f5699cc37a ] Load the cros_ec_lpc driver based on a Framework FRMWC004 ACPI device, which mirrors GOOG0004, but also applies npcx quirks for Framework systems. Matching on ACPI will let us avoid having to change the SMBIOS match rules again and again. Cc: Tzung-Bi Shih Cc: linux@frame.work Cc: Dustin L. Howett Signed-off-by: Daniel Schaefer Link: https://lore.kernel.org/r/20250128181329.8070-1-dhs@frame.work Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit 97f68e7287e048d4ddc7389ec7a724579e4f8cf1 Author: Ingo Molnar Date: Fri Mar 21 08:38:43 2025 +0100 zstd: Increase DYNAMIC_BMI2 GCC version cutoff from 4.8 to 11.0 to work around compiler segfault [ Upstream commit 1400c87e6cac47eb243f260352c854474d9a9073 ] Due to pending percpu improvements in -next, GCC9 and GCC10 are crashing during the build with: lib/zstd/compress/huf_compress.c:1033:1: internal compiler error: Segmentation fault 1033 | { | ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. The DYNAMIC_BMI2 feature is a known-challenging feature of the ZSTD library, with an existing GCC quirk turning it off for GCC versions below 4.8. Increase the DYNAMIC_BMI2 version cutoff to GCC 11.0 - GCC 10.5 is the last version known to crash. Reported-by: Michael Kelley Debugged-by: Ard Biesheuvel Signed-off-by: Ingo Molnar Cc: https://lore.kernel.org/r/SN6PR02MB415723FBCD79365E8D72CA5FD4D82@SN6PR02MB4157.namprd02.prod.outlook.com Cc: Linus Torvalds Signed-off-by: Sasha Levin commit 8d0f280e7aeca42ad3c581175d9628ef64f57e1e Author: Kees Cook Date: Mon Mar 10 15:22:38 2025 -0700 xen/mcelog: Add __nonstring annotations for unterminated strings [ Upstream commit 1c3dfc7c6b0f551fdca3f7c1f1e4c73be8adb17d ] When a character array without a terminating NUL character has a static initializer, GCC 15's -Wunterminated-string-initialization will only warn if the array lacks the "nonstring" attribute[1]. Mark the arrays with __nonstring to and correctly identify the char array as "not a C string" and thereby eliminate the warning. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 [1] Cc: Juergen Gross Cc: Stefano Stabellini Cc: Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org Signed-off-by: Kees Cook Acked-by: Juergen Gross Message-ID: <20250310222234.work.473-kees@kernel.org> Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit cb58e909203e3dd4de27838f29fc6928dcb246ea Author: Douglas Anderson Date: Thu Dec 19 13:11:09 2024 -0800 arm64: cputype: Add QCOM_CPU_PART_KRYO_3XX_GOLD [ Upstream commit 401c3333bb2396aa52e4121887a6f6a6e2f040bc ] Add a definition for the Qualcomm Kryo 300-series Gold cores. Reviewed-by: Dmitry Baryshkov Signed-off-by: Douglas Anderson Acked-by: Trilok Soni Link: https://lore.kernel.org/r/20241219131107.v3.1.I18e0288742871393228249a768e5d56ea65d93dc@changeid Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit ead1fc9f93e2e51164f2af55ed356fd1a0b48018 Author: Paul E. McKenney Date: Tue Feb 25 10:33:28 2025 -0800 Flush console log from kernel_power_off() [ Upstream commit 6ea9a1781c70a8be1fcdc49134fc1bf4baba8bca ] Kernels built with CONFIG_PREEMPT_RT=y can lose significant console output and shutdown time, which hides shutdown-time RCU issues from rcutorture. Therefore, make pr_flush() public and invoke it after then last print in kernel_power_off(). [ paulmck: Apply John Ogness feedback. ] [ paulmck: Appy Sebastian Andrzej Siewior feedback. ] [ paulmck: Apply kernel test robot feedback. ] Signed-off-by: Paul E. McKenney Reviewed-by: John Ogness Reviewed-by: Petr Mladek Cc: Steven Rostedt Cc: Sergey Senozhatsky Link: https://lore.kernel.org/r/5f743488-dc2a-4f19-bdda-cf50b9314832@paulmck-laptop Signed-off-by: Boqun Feng Signed-off-by: Sasha Levin commit 11ae4fec1f4b4ee06770a572c37d89cbaecbf66e Author: Lizhi Xu Date: Mon Feb 24 09:31:39 2025 +0800 PM: hibernate: Avoid deadlock in hibernate_compressor_param_set() [ Upstream commit 52323ed1444ea5c2a5f1754ea0a2d9c8c216ccdf ] syzbot reported a deadlock in lock_system_sleep() (see below). The write operation to "/sys/module/hibernate/parameters/compressor" conflicts with the registration of ieee80211 device, resulting in a deadlock when attempting to acquire system_transition_mutex under param_lock. To avoid this deadlock, change hibernate_compressor_param_set() to use mutex_trylock() for attempting to acquire system_transition_mutex and return -EBUSY when it fails. Task flags need not be saved or adjusted before calling mutex_trylock(&system_transition_mutex) because the caller is not going to end up waiting for this mutex and if it runs concurrently with system suspend in progress, it will be frozen properly when it returns to user space. syzbot report: syz-executor895/5833 is trying to acquire lock: ffffffff8e0828c8 (system_transition_mutex){+.+.}-{4:4}, at: lock_system_sleep+0x87/0xa0 kernel/power/main.c:56 but task is already holding lock: ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: kernel_param_lock kernel/params.c:607 [inline] ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: param_attr_store+0xe6/0x300 kernel/params.c:586 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (param_lock){+.+.}-{4:4}: __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730 ieee80211_rate_control_ops_get net/mac80211/rate.c:220 [inline] rate_control_alloc net/mac80211/rate.c:266 [inline] ieee80211_init_rate_ctrl_alg+0x18d/0x6b0 net/mac80211/rate.c:1015 ieee80211_register_hw+0x20cd/0x4060 net/mac80211/main.c:1531 mac80211_hwsim_new_radio+0x304e/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5558 init_mac80211_hwsim+0x432/0x8c0 drivers/net/wireless/virtual/mac80211_hwsim.c:6910 do_one_initcall+0x128/0x700 init/main.c:1257 do_initcall_level init/main.c:1319 [inline] do_initcalls init/main.c:1335 [inline] do_basic_setup init/main.c:1354 [inline] kernel_init_freeable+0x5c7/0x900 init/main.c:1568 kernel_init+0x1c/0x2b0 init/main.c:1457 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 -> #2 (rtnl_mutex){+.+.}-{4:4}: __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730 wg_pm_notification drivers/net/wireguard/device.c:80 [inline] wg_pm_notification+0x49/0x180 drivers/net/wireguard/device.c:64 notifier_call_chain+0xb7/0x410 kernel/notifier.c:85 notifier_call_chain_robust kernel/notifier.c:120 [inline] blocking_notifier_call_chain_robust kernel/notifier.c:345 [inline] blocking_notifier_call_chain_robust+0xc9/0x170 kernel/notifier.c:333 pm_notifier_call_chain_robust+0x27/0x60 kernel/power/main.c:102 snapshot_open+0x189/0x2b0 kernel/power/user.c:77 misc_open+0x35a/0x420 drivers/char/misc.c:179 chrdev_open+0x237/0x6a0 fs/char_dev.c:414 do_dentry_open+0x735/0x1c40 fs/open.c:956 vfs_open+0x82/0x3f0 fs/open.c:1086 do_open fs/namei.c:3830 [inline] path_openat+0x1e88/0x2d80 fs/namei.c:3989 do_filp_open+0x20c/0x470 fs/namei.c:4016 do_sys_openat2+0x17a/0x1e0 fs/open.c:1428 do_sys_open fs/open.c:1443 [inline] __do_sys_openat fs/open.c:1459 [inline] __se_sys_openat fs/open.c:1454 [inline] __x64_sys_openat+0x175/0x210 fs/open.c:1454 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 -> #1 ((pm_chain_head).rwsem){++++}-{4:4}: down_read+0x9a/0x330 kernel/locking/rwsem.c:1524 blocking_notifier_call_chain_robust kernel/notifier.c:344 [inline] blocking_notifier_call_chain_robust+0xa9/0x170 kernel/notifier.c:333 pm_notifier_call_chain_robust+0x27/0x60 kernel/power/main.c:102 snapshot_open+0x189/0x2b0 kernel/power/user.c:77 misc_open+0x35a/0x420 drivers/char/misc.c:179 chrdev_open+0x237/0x6a0 fs/char_dev.c:414 do_dentry_open+0x735/0x1c40 fs/open.c:956 vfs_open+0x82/0x3f0 fs/open.c:1086 do_open fs/namei.c:3830 [inline] path_openat+0x1e88/0x2d80 fs/namei.c:3989 do_filp_open+0x20c/0x470 fs/namei.c:4016 do_sys_openat2+0x17a/0x1e0 fs/open.c:1428 do_sys_open fs/open.c:1443 [inline] __do_sys_openat fs/open.c:1459 [inline] __se_sys_openat fs/open.c:1454 [inline] __x64_sys_openat+0x175/0x210 fs/open.c:1454 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 -> #0 (system_transition_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3163 [inline] check_prevs_add kernel/locking/lockdep.c:3282 [inline] validate_chain kernel/locking/lockdep.c:3906 [inline] __lock_acquire+0x249e/0x3c40 kernel/locking/lockdep.c:5228 lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5851 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730 lock_system_sleep+0x87/0xa0 kernel/power/main.c:56 hibernate_compressor_param_set+0x1c/0x210 kernel/power/hibernate.c:1452 param_attr_store+0x18f/0x300 kernel/params.c:588 module_attr_store+0x55/0x80 kernel/params.c:924 sysfs_kf_write+0x117/0x170 fs/sysfs/file.c:139 kernfs_fop_write_iter+0x33d/0x500 fs/kernfs/file.c:334 new_sync_write fs/read_write.c:586 [inline] vfs_write+0x5ae/0x1150 fs/read_write.c:679 ksys_write+0x12b/0x250 fs/read_write.c:731 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 other info that might help us debug this: Chain exists of: system_transition_mutex --> rtnl_mutex --> param_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(param_lock); lock(rtnl_mutex); lock(param_lock); lock(system_transition_mutex); *** DEADLOCK *** Reported-by: syzbot+ace60642828c074eb913@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ace60642828c074eb913 Signed-off-by: Lizhi Xu Link: https://patch.msgid.link/20250224013139.3994500-1-lizhi.xu@windriver.com [ rjw: New subject matching the code changes, changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 89a4db7a67e707533d20649fc4eaa2fcbf29472a Author: Yunhui Cui Date: Thu Feb 20 20:17:15 2025 +0800 perf/dwc_pcie: fix some unreleased resources [ Upstream commit 6eb1e8ef586ac4a3dcdc20248f9cb45e4ceb141f ] Release leaked resources, such as plat_dev and dev_info. Signed-off-by: Yunhui Cui Reviewed-by: Shuai Xue Link: https://lore.kernel.org/r/20250220121716.50324-2-cuiyunhui@bytedance.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 1b3ebfb15dc0bb14d3ac202446919acd4b4e9408 Author: Mark Rutland Date: Tue Feb 18 14:39:57 2025 -0600 perf: arm_pmu: Don't disable counter in armpmu_add() [ Upstream commit dcca27bc1eccb9abc2552aab950b18a9742fb8e7 ] Currently armpmu_add() tries to handle a newly-allocated counter having a stale associated event, but this should not be possible, and if this were to happen the current mitigation is insufficient and potentially expensive. It would be better to warn if we encounter the impossible case. Calls to pmu::add() and pmu::del() are serialized by the core perf code, and armpmu_del() clears the relevant slot in pmu_hw_events::events[] before clearing the bit in pmu_hw_events::used_mask such that the counter can be reallocated. Thus when armpmu_add() allocates a counter index from pmu_hw_events::used_mask, it should not be possible to observe a stale even in pmu_hw_events::events[] unless either pmu_hw_events::used_mask or pmu_hw_events::events[] have been corrupted. If this were to happen, we'd end up with two events with the same event->hw.idx, which would clash with each other during reprogramming, deletion, etc, and produce bogus results. Add a WARN_ON_ONCE() for this case so that we can detect if this ever occurs in practice. That possiblity aside, there's no need to call arm_pmu::disable(event) for the new event. The PMU reset code initialises the counter in a disabled state, and armpmu_del() will disable the counter before it can be reused. Remove the redundant disable. Signed-off-by: Mark Rutland Signed-off-by: Rob Herring (Arm) Reviewed-by: Anshuman Khandual Tested-by: James Clark Link: https://lore.kernel.org/r/20250218-arm-brbe-v19-v20-2-4e9922fc2e8e@kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit f48625eeeb29df394e3aba77373e80ca71961443 Author: Max Grobecker Date: Thu Feb 27 21:45:05 2025 +0100 x86/cpu: Don't clear X86_FEATURE_LAHF_LM flag in init_amd_k8() on AMD when running in a virtual machine [ Upstream commit a4248ee16f411ac1ea7dfab228a6659b111e3d65 ] When running in a virtual machine, we might see the original hardware CPU vendor string (i.e. "AuthenticAMD"), but a model and family ID set by the hypervisor. In case we run on AMD hardware and the hypervisor sets a model ID < 0x14, the LAHF cpu feature is eliminated from the the list of CPU capabilities present to circumvent a bug with some BIOSes in conjunction with AMD K8 processors. Parsing the flags list from /proc/cpuinfo seems to be happening mostly in bash scripts and prebuilt Docker containers, as it does not need to have additionals tools present – even though more reliable ways like using "kcpuid", which calls the CPUID instruction instead of parsing a list, should be preferred. Scripts, that use /proc/cpuinfo to determine if the current CPU is "compliant" with defined microarchitecture levels like x86-64-v2 will falsely claim the CPU is incapable of modern CPU instructions when "lahf_lm" is missing in that flags list. This can prevent some docker containers from starting or build scripts to create unoptimized binaries. Admittably, this is more a small inconvenience than a severe bug in the kernel and the shoddy scripts that rely on parsing /proc/cpuinfo should be fixed instead. This patch adds an additional check to see if we're running inside a virtual machine (X86_FEATURE_HYPERVISOR is present), which, to my understanding, can't be present on a real K8 processor as it was introduced only with the later/other Athlon64 models. Example output with the "lahf_lm" flag missing in the flags list (should be shown between "hypervisor" and "abm"): $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 6 model name : Common KVM processor stepping : 1 microcode : 0x1000065 cpu MHz : 2599.998 cache size : 512 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c hypervisor abm 3dnowprefetch vmmcall bmi1 avx2 bmi2 xsaveopt ... while kcpuid shows the feature to be present in the CPU: # kcpuid -d | grep lahf lahf_lm - LAHF/SAHF available in 64-bit mode [ mingo: Updated the comment a bit, incorporated Boris's review feedback. ] Signed-off-by: Max Grobecker Signed-off-by: Ingo Molnar Cc: linux-kernel@vger.kernel.org Cc: Borislav Petkov Signed-off-by: Sasha Levin commit 48e705652db9c222be67c50e303ff53a9f1469ee Author: Xin Li (Intel) Date: Tue Nov 26 10:45:28 2024 -0800 x86/ia32: Leave NULL selector values 0~3 unchanged [ Upstream commit ad546940b5991d3e141238cd80a6d1894b767184 ] The first GDT descriptor is reserved as 'NULL descriptor'. As bits 0 and 1 of a segment selector, i.e., the RPL bits, are NOT used to index GDT, selector values 0~3 all point to the NULL descriptor, thus values 0, 1, 2 and 3 are all valid NULL selector values. When a NULL selector value is to be loaded into a segment register, reload_segments() sets its RPL bits. Later IRET zeros ES, FS, GS, and DS segment registers if any of them is found to have any nonzero NULL selector value. The two operations offset each other to actually effect a nop. Besides, zeroing of RPL in NULL selector values is an information leak in pre-FRED systems as userspace can spot any interrupt/exception by loading a nonzero NULL selector, and waiting for it to become zero. But there is nothing software can do to prevent it before FRED. ERETU, the only legit instruction to return to userspace from kernel under FRED, by design does NOT zero any segment register to avoid this problem behavior. As such, leave NULL selector values 0~3 unchanged and close the leak. Do the same on 32-bit kernel as well. Signed-off-by: Xin Li (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Andrew Cooper Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Brian Gerst Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20241126184529.1607334-1-xin@zytor.com Signed-off-by: Sasha Levin commit 640bb225215810cf883f1bbd30d1d75f1b77d422 Author: Uros Bizjak Date: Thu Feb 27 15:06:58 2025 +0100 x86/percpu: Disable named address spaces for UBSAN_BOOL with KASAN for GCC < 14.2 [ Upstream commit b6762467a09ba8838c499e4f36561e82fc608ed1 ] GCC < 14.2 does not correctly propagate address space qualifiers with -fsanitize=bool,enum. Together with address sanitizer then causes that load to be sanitized. Disable named address spaces for GCC < 14.2 when both, UBSAN_BOOL and KASAN are enabled. Reported-by: Matt Fleming Signed-off-by: Uros Bizjak Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250227140715.2276353-1-ubizjak@gmail.com Closes: https://lore.kernel.org/lkml/20241213190119.3449103-1-matt@readmodwrite.com/ Signed-off-by: Sasha Levin commit 837f5cb7be9a5a67d1a983ab2f72f7488628fc17 Author: Matthew Wilcox (Oracle) Date: Tue Feb 25 19:37:32 2025 +0000 x86/mm: Clear _PAGE_DIRTY for kernel mappings when we clear _PAGE_RW [ Upstream commit c1fcf41cf37f7a3fd3bbf6f0c04aba3ea4258888 ] The bit pattern of _PAGE_DIRTY set and _PAGE_RW clear is used to mark shadow stacks. This is currently checked for in mk_pte() but not pfn_pte(). If we add the check to pfn_pte(), it catches vfree() calling set_direct_map_invalid_noflush() which calls __change_page_attr() which loads the old protection bits from the PTE, clears the specified bits and uses pfn_pte() to construct the new PTE. We should, therefore, for kernel mappings, clear the _PAGE_DIRTY bit consistently whenever we clear _PAGE_RW. I opted to do it in the callers in case we want to use __change_page_attr() to create shadow stacks inside the kernel at some point in the future. Arguably, we might also want to clear _PAGE_ACCESSED here. Note that the 3 functions involved: __set_pages_np() kernel_map_pages_in_pgd() kernel_unmap_pages_in_pgd() Only ever manipulate non-swappable kernel mappings, so maintaining the DIRTY:1|RW:0 special pattern for shadow stacks and DIRTY:0 pattern for non-shadow-stack entries can be maintained consistently and doesn't result in the unintended clearing of a live dirty bit that could corrupt (destroy) dirty bit information for user mappings. Reported-by: kernel test robot Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Ingo Molnar Acked-by: Linus Torvalds Link: https://lore.kernel.org/r/174051422675.10177.13226545170101706336.tip-bot2@tip-bot2 Closes: https://lore.kernel.org/oe-lkp/202502241646.719f4651-lkp@intel.com Signed-off-by: Sasha Levin commit f8d28fa305b78c5d1073b63f26db265ba8291ae1 Author: Zhongqiu Han Date: Wed Feb 19 20:27:15 2025 +0800 pm: cpupower: bench: Prevent NULL dereference on malloc failure [ Upstream commit 208baa3ec9043a664d9acfb8174b332e6b17fb69 ] If malloc returns NULL due to low memory, 'config' pointer can be NULL. Add a check to prevent NULL dereference. Link: https://lore.kernel.org/r/20250219122715.3892223-1-quic_zhonhan@quicinc.com Signed-off-by: Zhongqiu Han Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 67e85cfa951cb074dabd9ec5ef11b74e78cb5a06 Author: Trond Myklebust Date: Tue Mar 18 12:29:21 2025 -0400 umount: Allow superblock owners to force umount [ Upstream commit e1ff7aa34dec7e650159fd7ca8ec6af7cc428d9f ] Loosen the permission check on forced umount to allow users holding CAP_SYS_ADMIN privileges in namespaces that are privileged with respect to the userns that originally mounted the filesystem. Signed-off-by: Trond Myklebust Link: https://lore.kernel.org/r/12f212d4ef983714d065a6bb372fbb378753bf4c.1742315194.git.trond.myklebust@hammerspace.com Acked-by: "Eric W. Biederman" Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 52535688c27f5a8c8d7f972d40142c52874844d3 Author: Mateusz Guzik Date: Thu Mar 13 14:57:25 2025 +0100 fs: consistently deref the files table with rcu_dereference_raw() [ Upstream commit f381640e1bd4f2de7ccafbfe8703d33c3718aad9 ] ... except when the table is known to be only used by one thread. A file pointer can get installed at any moment despite the ->file_lock being held since the following: 8a81252b774b53e6 ("fs/file.c: don't acquire files->file_lock in fd_install()") Accesses subject to such a race can in principle suffer load tearing. While here redo the comment in dup_fd -- it only covered a race against files showing up, still assuming fd_install() takes the lock. Signed-off-by: Mateusz Guzik Link: https://lore.kernel.org/r/20250313135725.1320914-1-mjguzik@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit fa1827fa968c0674e9b6fca223fa9fb4da4493eb Author: Frederic Weisbecker Date: Tue Mar 4 14:54:46 2025 +0100 perf: Fix hang while freeing sigtrap event [ Upstream commit 56799bc035658738f362acec3e7647bb84e68933 ] Perf can hang while freeing a sigtrap event if a related deferred signal hadn't managed to be sent before the file got closed: perf_event_overflow() task_work_add(perf_pending_task) fput() task_work_add(____fput()) task_work_run() ____fput() perf_release() perf_event_release_kernel() _free_event() perf_pending_task_sync() task_work_cancel() -> FAILED rcuwait_wait_event() Once task_work_run() is running, the list of pending callbacks is removed from the task_struct and from this point on task_work_cancel() can't remove any pending and not yet started work items, hence the task_work_cancel() failure and the hang on rcuwait_wait_event(). Task work could be changed to remove one work at a time, so a work running on the current task can always cancel a pending one, however the wait / wake design is still subject to inverted dependencies when remote targets are involved, as pictured by Oleg: T1 T2 fd = perf_event_open(pid => T2->pid); fd = perf_event_open(pid => T1->pid); close(fd) close(fd) perf_event_overflow() perf_event_overflow() task_work_add(perf_pending_task) task_work_add(perf_pending_task) fput() fput() task_work_add(____fput()) task_work_add(____fput()) task_work_run() task_work_run() ____fput() ____fput() perf_release() perf_release() perf_event_release_kernel() perf_event_release_kernel() _free_event() _free_event() perf_pending_task_sync() perf_pending_task_sync() rcuwait_wait_event() rcuwait_wait_event() Therefore the only option left is to acquire the event reference count upon queueing the perf task work and release it from the task work, just like it was done before 3a5465418f5f ("perf: Fix event leak upon exec and file release") but without the leaks it fixed. Some adjustments are necessary to make it work: * A child event might dereference its parent upon freeing. Care must be taken to release the parent last. * Some places assuming the event doesn't have any reference held and therefore can be freed right away must instead put the reference and let the reference counting to its job. Reported-by: "Yi Lai" Closes: https://lore.kernel.org/all/Zx9Losv4YcJowaP%2F@ly-workstation/ Reported-by: syzbot+3c4321e10eea460eb606@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/673adf75.050a0220.87769.0024.GAE@google.com/ Fixes: 3a5465418f5f ("perf: Fix event leak upon exec and file release") Signed-off-by: Frederic Weisbecker Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20250304135446.18905-1-frederic@kernel.org Signed-off-by: Sasha Levin commit 7ef5aa081f989ecfecc1df02068a80aebbd3ec31 Author: Peter Zijlstra Date: Mon Nov 4 14:39:13 2024 +0100 perf/core: Simplify the perf_event_alloc() error path [ Upstream commit c70ca298036c58a88686ff388d3d367e9d21acf0 ] The error cleanup sequence in perf_event_alloc() is a subset of the existing _free_event() function (it must of course be). Split this out into __free_event() and simplify the error path. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Ravi Bangoria Link: https://lore.kernel.org/r/20241104135517.967889521@infradead.org Stable-dep-of: 56799bc03565 ("perf: Fix hang while freeing sigtrap event") Signed-off-by: Sasha Levin commit c61feda3735068ad22422ffc7a81752e07d73fb1 Author: Adrian Hunter Date: Tue Oct 22 18:59:08 2024 +0300 perf/core: Add aux_pause, aux_resume, aux_start_paused [ Upstream commit 18d92bb57c39504d9da11c6ef604f58eb1d5a117 ] Hardware traces, such as instruction traces, can produce a vast amount of trace data, so being able to reduce tracing to more specific circumstances can be useful. The ability to pause or resume tracing when another event happens, can do that. Add ability for an event to "pause" or "resume" AUX area tracing. Add aux_pause bit to perf_event_attr to indicate that, if the event happens, the associated AUX area tracing should be paused. Ditto aux_resume. Do not allow aux_pause and aux_resume to be set together. Add aux_start_paused bit to perf_event_attr to indicate to an AUX area event that it should start in a "paused" state. Add aux_paused to struct hw_perf_event for AUX area events to keep track of the "paused" state. aux_paused is initialized to aux_start_paused. Add PERF_EF_PAUSE and PERF_EF_RESUME modes for ->stop() and ->start() callbacks. Call as needed, during __perf_event_output(). Add aux_in_pause_resume to struct perf_buffer to prevent races with the NMI handler. Pause/resume in NMI context will miss out if it coincides with another pause/resume. To use aux_pause or aux_resume, an event must be in a group with the AUX area event as the group leader. Example (requires Intel PT and tools patches also): $ perf record --kcore -e intel_pt/aux-action=start-paused/k,syscalls:sys_enter_newuname/aux-action=resume/,syscalls:sys_exit_newuname/aux-action=pause/ uname Linux [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.043 MB perf.data ] $ perf script --call-trace uname 30805 [000] 24001.058782799: name: 0x7ffc9c1865b0 uname 30805 [000] 24001.058784424: psb offs: 0 uname 30805 [000] 24001.058784424: cbr: 39 freq: 3904 MHz (139%) uname 30805 [000] 24001.058784629: ([kernel.kallsyms]) debug_smp_processor_id uname 30805 [000] 24001.058784629: ([kernel.kallsyms]) __x64_sys_newuname uname 30805 [000] 24001.058784629: ([kernel.kallsyms]) down_read uname 30805 [000] 24001.058784629: ([kernel.kallsyms]) __cond_resched uname 30805 [000] 24001.058784629: ([kernel.kallsyms]) preempt_count_add uname 30805 [000] 24001.058784629: ([kernel.kallsyms]) in_lock_functions uname 30805 [000] 24001.058784629: ([kernel.kallsyms]) preempt_count_sub uname 30805 [000] 24001.058784629: ([kernel.kallsyms]) up_read uname 30805 [000] 24001.058784629: ([kernel.kallsyms]) preempt_count_add uname 30805 [000] 24001.058784838: ([kernel.kallsyms]) in_lock_functions uname 30805 [000] 24001.058784838: ([kernel.kallsyms]) preempt_count_sub uname 30805 [000] 24001.058784838: ([kernel.kallsyms]) _copy_to_user uname 30805 [000] 24001.058784838: ([kernel.kallsyms]) syscall_exit_to_user_mode uname 30805 [000] 24001.058784838: ([kernel.kallsyms]) syscall_exit_work uname 30805 [000] 24001.058784838: ([kernel.kallsyms]) perf_syscall_exit uname 30805 [000] 24001.058784838: ([kernel.kallsyms]) debug_smp_processor_id uname 30805 [000] 24001.058785046: ([kernel.kallsyms]) perf_trace_buf_alloc uname 30805 [000] 24001.058785046: ([kernel.kallsyms]) perf_swevent_get_recursion_context uname 30805 [000] 24001.058785046: ([kernel.kallsyms]) debug_smp_processor_id uname 30805 [000] 24001.058785046: ([kernel.kallsyms]) debug_smp_processor_id uname 30805 [000] 24001.058785046: ([kernel.kallsyms]) perf_tp_event uname 30805 [000] 24001.058785046: ([kernel.kallsyms]) perf_trace_buf_update uname 30805 [000] 24001.058785046: ([kernel.kallsyms]) tracing_gen_ctx_irq_test uname 30805 [000] 24001.058785046: ([kernel.kallsyms]) perf_swevent_event uname 30805 [000] 24001.058785046: ([kernel.kallsyms]) __perf_event_account_interrupt uname 30805 [000] 24001.058785046: ([kernel.kallsyms]) __this_cpu_preempt_check uname 30805 [000] 24001.058785046: ([kernel.kallsyms]) perf_event_output_forward uname 30805 [000] 24001.058785046: ([kernel.kallsyms]) perf_event_aux_pause uname 30805 [000] 24001.058785046: ([kernel.kallsyms]) ring_buffer_get uname 30805 [000] 24001.058785046: ([kernel.kallsyms]) __rcu_read_lock uname 30805 [000] 24001.058785046: ([kernel.kallsyms]) __rcu_read_unlock uname 30805 [000] 24001.058785254: ([kernel.kallsyms]) pt_event_stop uname 30805 [000] 24001.058785254: ([kernel.kallsyms]) debug_smp_processor_id uname 30805 [000] 24001.058785254: ([kernel.kallsyms]) debug_smp_processor_id uname 30805 [000] 24001.058785254: ([kernel.kallsyms]) native_write_msr uname 30805 [000] 24001.058785463: ([kernel.kallsyms]) native_write_msr uname 30805 [000] 24001.058785639: 0x0 Signed-off-by: Adrian Hunter Signed-off-by: Peter Zijlstra (Intel) Acked-by: James Clark Link: https://lkml.kernel.org/r/20241022155920.17511-3-adrian.hunter@intel.com Stable-dep-of: 56799bc03565 ("perf: Fix hang while freeing sigtrap event") Signed-off-by: Sasha Levin commit a0842539e8ef9386c070156103aff888e558a60c Author: Louis-Alexis Eyraud Date: Thu Apr 3 12:22:12 2025 +0200 iommu/mediatek: Fix NULL pointer deference in mtk_iommu_device_group [ Upstream commit 38e8844005e6068f336a3ad45451a562a0040ca1 ] Currently, mtk_iommu calls during probe iommu_device_register before the hw_list from driver data is initialized. Since iommu probing issue fix, it leads to NULL pointer dereference in mtk_iommu_device_group when hw_list is accessed with list_first_entry (not null safe). So, change the call order to ensure iommu_device_register is called after the driver data are initialized. Fixes: 9e3a2a643653 ("iommu/mediatek: Adapt sharing and non-sharing pgtable case") Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path") Reviewed-by: Yong Wu Tested-by: Chen-Yu Tsai # MT8183 Juniper, MT8186 Tentacruel Reviewed-by: AngeloGioacchino Del Regno Tested-by: AngeloGioacchino Del Regno Signed-off-by: Louis-Alexis Eyraud Link: https://lore.kernel.org/r/20250403-fix-mtk-iommu-error-v2-1-fe8b18f8b0a8@collabora.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 5efd53900acc658ac0570cddd2078a772ad3b269 Author: Marek Szyprowski Date: Tue Apr 1 22:27:31 2025 +0200 iommu/exynos: Fix suspend/resume with IDENTITY domain [ Upstream commit 99deffc409b69000ac4877486e69ec6516becd53 ] Commit bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path") changed the sequence of probing the SYSMMU controller devices and calls to arm_iommu_attach_device(), what results in resuming SYSMMU controller earlier, when it is still set to IDENTITY mapping. Such change revealed the bug in IDENTITY handling in the exynos-iommu driver. When SYSMMU controller is set to IDENTITY mapping, data->domain is NULL, so adjust checks in suspend & resume callbacks to handle this case correctly. Fixes: b3d14960e629 ("iommu/exynos: Implement an IDENTITY domain") Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20250401202731.2810474-1-m.szyprowski@samsung.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 7640c2abb6474808c07acc079763123aceb0532e Author: Florian Westphal Date: Mon Apr 7 19:40:18 2025 +0200 nft_set_pipapo: fix incorrect avx2 match of 5th field octet [ Upstream commit e042ed950d4e176379ba4c0722146cd96fb38aa2 ] Given a set element like: icmpv6 . dead:beef:00ff::1 The value of 'ff' is irrelevant, any address will be matched as long as the other octets are the same. This is because of too-early register clobbering: ymm7 is reloaded with new packet data (pkt[9]) but it still holds data of an earlier load that wasn't processed yet. The existing tests in nft_concat_range.sh selftests do exercise this code path, but do not trigger incorrect matching due to the network prefix limitation. Fixes: 7400b063969b ("nft_set_pipapo: Introduce AVX2-based lookup implementation") Reported-by: sontu mazumdar Closes: https://lore.kernel.org/netfilter/CANgxkqwnMH7fXra+VUfODT-8+qFLgskq3set1cAzqqJaV4iEZg@mail.gmail.com/T/#t Reviewed-by: Stefano Brivio Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit b4c836d33ca888695b2f2665f948bc1b34fbd533 Author: Arnaud Lecomte Date: Tue Apr 8 17:55:08 2025 +0200 net: ppp: Add bound checking for skb data on ppp_sync_txmung [ Upstream commit aabc6596ffb377c4c9c8f335124b92ea282c9821 ] Ensure we have enough data in linear buffer from skb before accessing initial bytes. This prevents potential out-of-bounds accesses when processing short packets. When ppp_sync_txmung receives an incoming package with an empty payload: (remote) gef➤ p *(struct pppoe_hdr *) (skb->head + skb->network_header) $18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96 } from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0, it is not safe to access data[2]. Reported-by: syzbot+29fc8991b0ecb186cf40@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=29fc8991b0ecb186cf40 Tested-by: syzbot+29fc8991b0ecb186cf40@syzkaller.appspotmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Arnaud Lecomte Link: https://patch.msgid.link/20250408-bound-checking-ppp_txmung-v2-1-94bb6e1b92d0@arnaud-lcm.com [pabeni@redhat.com: fixed subj typo] Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit cc16f7402a9120446339d969d334b654da59787b Author: Ido Schimmel Date: Tue Apr 8 11:43:16 2025 +0300 ipv6: Align behavior across nexthops during path selection [ Upstream commit 6933cd4714861eea6848f18396a119d741f25fc3 ] A nexthop is only chosen when the calculated multipath hash falls in the nexthop's hash region (i.e., the hash is smaller than the nexthop's hash threshold) and when the nexthop is assigned a non-negative score by rt6_score_route(). Commit 4d0ab3a6885e ("ipv6: Start path selection from the first nexthop") introduced an unintentional difference between the first nexthop and the rest when the score is negative. When the first nexthop matches, but has a negative score, the code will currently evaluate subsequent nexthops until one is found with a non-negative score. On the other hand, when a different nexthop matches, but has a negative score, the code will fallback to the nexthop with which the selection started ('match'). Align the behavior across all nexthops and fallback to 'match' when the first nexthop matches, but has a negative score. Fixes: 3d709f69a3e7 ("ipv6: Use hash-threshold instead of modulo-N") Fixes: 4d0ab3a6885e ("ipv6: Start path selection from the first nexthop") Reported-by: Willem de Bruijn Closes: https://lore.kernel.org/netdev/67efef607bc41_1ddca82948c@willemb.c.googlers.com.notmuch/ Signed-off-by: Ido Schimmel Reviewed-by: Willem de Bruijn Reviewed-by: David Ahern Link: https://patch.msgid.link/20250408084316.243559-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a6ed6f8ec81b8ca7100dcd9e62bdbc0dff1b2259 Author: Vladimir Oltean Date: Mon Apr 7 12:40:42 2025 +0300 net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY [ Upstream commit fc75ea20ffb452652f0d4033f38fe88d7cfdae35 ] DSA has 2 kinds of drivers: 1. Those who call dsa_switch_suspend() and dsa_switch_resume() from their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz 2. Those who don't: all others. The above methods should be optional. For type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(), and dsa_switch_resume() calls dsa_user_resume() -> phylink_start(). These seem good candidates for setting mac_managed_pm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on. Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full), I have noticed that the following warning from mdio_bus_phy_resume() is triggered: WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY && phydev->state != PHY_UP); because the PHY state machine is running. It's running as a result of a previous dsa_user_open() -> ... -> phylink_start() -> phy_start() having been initiated by the user. The previous mdio_bus_phy_suspend() was supposed to have called phy_stop_machine(), but it didn't. So this is why the PHY is in state PHY_NOLINK by the time mdio_bus_phy_resume() runs. mdio_bus_phy_suspend() did not call phy_stop_machine() because for phylink, the phydev->adjust_link function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 ("phylib: fix PAL state machine restart on resume"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently not tested too much in that scenario, allowing this bug to exist unnoticed for so long. Plus, prior to the WARN_ON(), it would have likely been invisible. This issue is not in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to any MAC driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where the issue was reported. Assuming mac_managed_pm is set correctly, a quick search indicates the following other drivers might be affected: $ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5_main.c drivers/net/ethernet/microchip/lan966x/lan966x_main.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c drivers/net/ethernet/freescale/dpaa/dpaa_eth.c drivers/net/ethernet/freescale/ucc_geth.c drivers/net/ethernet/freescale/enetc/enetc_pf_common.c drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c drivers/net/ethernet/marvell/mvneta.c drivers/net/ethernet/marvell/prestera/prestera_main.c drivers/net/ethernet/mediatek/mtk_eth_soc.c drivers/net/ethernet/altera/altera_tse_main.c drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c drivers/net/ethernet/meta/fbnic/fbnic_phylink.c drivers/net/ethernet/tehuti/tn40_phy.c drivers/net/ethernet/mscc/ocelot_net.c Make the existing conditions dependent on the PHY device having a phydev->phy_link_change() implementation equal to the default phy_link_change() provided by phylib. Otherwise, we implicitly know that the phydev has the phylink-provided phylink_phy_change() callback, and when phylink is used, the PHY state machine always needs to be stopped/ started on the suspend/resume path. The code is structured as such that if phydev->phy_link_change() is absent, it is a matter of time until the kernel will crash - no need to further complicate the test. Thus, for the situation where the PM is not managed by the MAC, we will make the MDIO bus PM ops treat identically the phylink-controlled PHYs with the phylib-controlled PHYs where an adjust_link() callback is supplied. In both cases, the MDIO bus PM ops should stop and restart the PHY state machine. [1] https://lore.kernel.org/netdev/Z-1tiW9zjcoFkhwc@shell.armlinux.org.uk/ Fixes: 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state") Reported-by: Wei Fang Tested-by: Wei Fang Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20250407094042.2155633-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6d98cd63426e35208a380ab43afeb9184bb29477 Author: Vladimir Oltean Date: Mon Apr 7 12:38:59 2025 +0300 net: phy: move phy_link_change() prior to mdio_bus_phy_may_suspend() [ Upstream commit f40a673d6b4a128fe95dd9b8c3ed02da50a6a862 ] In an upcoming change, mdio_bus_phy_may_suspend() will need to distinguish a phylib-based PHY client from a phylink PHY client. For that, it will need to compare the phydev->phy_link_change() function pointer with the eponymous phy_link_change() provided by phylib. To avoid forward function declarations, the default PHY link state change method should be moved upwards. There is no functional change associated with this patch, it is only to reduce the noise from a real bug fix. Signed-off-by: Vladimir Oltean Reviewed-by: Russell King (Oracle) Link: https://patch.msgid.link/20250407093900.2155112-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Stable-dep-of: fc75ea20ffb4 ("net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY") Signed-off-by: Sasha Levin commit aa5a1e4b882964eb79d5b5d1d1e8a1a5efbb1d15 Author: Paulo Alcantara Date: Wed Apr 9 11:14:21 2025 -0300 smb: client: fix UAF in decryption with multichannel [ Upstream commit 9502dd5c7029902f4a425bf959917a5a9e7c0e50 ] After commit f7025d861694 ("smb: client: allocate crypto only for primary server") and commit b0abcd65ec54 ("smb: client: fix UAF in async decryption"), the channels started reusing AEAD TFM from primary channel to perform synchronous decryption, but that can't done as there could be multiple cifsd threads (one per channel) simultaneously accessing it to perform decryption. This fixes the following KASAN splat when running fstest generic/249 with 'vers=3.1.1,multichannel,max_channels=4,seal' against Windows Server 2022: BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xba/0x110 Read of size 8 at addr ffff8881046c18a0 by task cifsd/986 CPU: 3 UID: 0 PID: 986 Comm: cifsd Not tainted 6.15.0-rc1 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x156/0x528 ? gf128mul_4k_lle+0xba/0x110 ? __virt_addr_valid+0x145/0x300 ? __phys_addr+0x46/0x90 ? gf128mul_4k_lle+0xba/0x110 kasan_report+0xdf/0x1a0 ? gf128mul_4k_lle+0xba/0x110 gf128mul_4k_lle+0xba/0x110 ghash_update+0x189/0x210 shash_ahash_update+0x295/0x370 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_extract_iter_to_sg+0x10/0x10 ? ___kmalloc_large_node+0x10e/0x180 ? __asan_memset+0x23/0x50 crypto_ahash_update+0x3c/0xc0 gcm_hash_assoc_remain_continue+0x93/0xc0 crypt_message+0xe09/0xec0 [cifs] ? __pfx_crypt_message+0x10/0x10 [cifs] ? _raw_spin_unlock+0x23/0x40 ? __pfx_cifs_readv_from_socket+0x10/0x10 [cifs] decrypt_raw_data+0x229/0x380 [cifs] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] ? __pfx_cifs_read_iter_from_socket+0x10/0x10 [cifs] smb3_receive_transform+0x837/0xc80 [cifs] ? __pfx_smb3_receive_transform+0x10/0x10 [cifs] ? __pfx___might_resched+0x10/0x10 ? __pfx_smb3_is_transform_hdr+0x10/0x10 [cifs] cifs_demultiplex_thread+0x692/0x1570 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? rcu_lockdep_current_cpu_online+0x62/0xb0 ? find_held_lock+0x32/0x90 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xd/0xd0 ? trace_irq_enable.constprop.0+0xa8/0xe0 ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0x1fe/0x380 ? kthread+0x10f/0x380 ? __pfx_kthread+0x10/0x10 ? local_clock_noinstr+0xd/0xd0 ? ret_from_fork+0x1b/0x60 ? local_clock+0x15/0x30 ? lock_release+0x29b/0x390 ? rcu_is_watching+0x20/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Tested-by: David Howells Reported-by: Steve French Closes: https://lore.kernel.org/r/CAH2r5mu6Yc0-RJXM3kFyBYUB09XmXBrNodOiCVR4EDrmxq5Szg@mail.gmail.com Fixes: f7025d861694 ("smb: client: allocate crypto only for primary server") Fixes: b0abcd65ec54 ("smb: client: fix UAF in async decryption") Signed-off-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit f86293adce0c201cfabb283ef9d6f21292089bb8 Author: Octavian Purdila Date: Mon Apr 7 13:24:08 2025 -0700 net_sched: sch_sfq: move the limit validation [ Upstream commit b3bf8f63e6179076b57c9de660c9f80b5abefe70 ] It is not sufficient to directly validate the limit on the data that the user passes as it can be updated based on how the other parameters are changed. Move the check at the end of the configuration update process to also catch scenarios where the limit is indirectly updated, for example with the following configurations: tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1 tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1 This fixes the following syzkaller reported crash: ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429 sfq_link net/sched/sch_sfq.c:203 [inline] sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231 sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493 sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311 netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline] dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375 Reported-by: syzbot Fixes: 10685681bafc ("net_sched: sch_sfq: don't allow 1 packet limit") Signed-off-by: Octavian Purdila Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 70449ca40609ec77f58b93ed154d54e1fdb197b6 Author: Octavian Purdila Date: Mon Apr 7 13:24:07 2025 -0700 net_sched: sch_sfq: use a temporary work area for validating configuration [ Upstream commit 8c0cea59d40cf6dd13c2950437631dd614fbade6 ] Many configuration parameters have influence on others (e.g. divisor -> flows -> limit, depth -> limit) and so it is difficult to correctly do all of the validation before applying the configuration. And if a validation error is detected late it is difficult to roll back a partially applied configuration. To avoid these issues use a temporary work area to update and validate the configuration and only then apply the configuration to the internal state. Signed-off-by: Octavian Purdila Acked-by: Cong Wang Signed-off-by: David S. Miller Stable-dep-of: b3bf8f63e617 ("net_sched: sch_sfq: move the limit validation") Signed-off-by: Sasha Levin commit ec12da4bcc44d5dd21679b3a0eb5e501e1a831a3 Author: Daniel Wagner Date: Tue Apr 8 17:29:03 2025 +0200 nvmet-fcloop: swap list_add_tail arguments [ Upstream commit 2b5f0c5bc819af2b0759a8fcddc1b39102735c0f ] The newly element to be added to the list is the first argument of list_add_tail. This fix is missing dcfad4ab4d67 ("nvmet-fcloop: swap the list_add_tail arguments"). Fixes: 437c0b824dbd ("nvme-fcloop: add target to host LS request support") Signed-off-by: Daniel Wagner Reviewed-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit c5a906806162aea62dbe5d327760ce3b7117ca17 Author: Janusz Krzysztofik Date: Wed Apr 2 19:20:57 2025 +0200 drm/i915/huc: Fix fence not released on early probe errors [ Upstream commit e3ea2eae70692a455e256787e4f54153fb739b90 ] HuC delayed loading fence, introduced with commit 27536e03271da ("drm/i915/huc: track delayed HuC load with a fence"), is registered with object tracker early on driver probe but unregistered only from driver remove, which is not called on early probe errors. Since its memory is allocated under devres, then released anyway, it may happen to be allocated again to the fence and reused on future driver probes, resulting in kernel warnings that taint the kernel: <4> [309.731371] ------------[ cut here ]------------ <3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915] <4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0 ... <4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G U 6.14.0-CI_DRM_16362-gf0fd77956987+ #1 ... <4> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0 ... <4> [309.731728] Call Trace: <4> [309.731730] ... <4> [309.731949] __debug_object_init+0x17b/0x1c0 <4> [309.731957] debug_object_init+0x34/0x50 <4> [309.732126] __i915_sw_fence_init+0x34/0x60 [i915] <4> [309.732256] intel_huc_init_early+0x4b/0x1d0 [i915] <4> [309.732468] intel_uc_init_early+0x61/0x680 [i915] <4> [309.732667] intel_gt_common_init_early+0x105/0x130 [i915] <4> [309.732804] intel_root_gt_init_early+0x63/0x80 [i915] <4> [309.732938] i915_driver_probe+0x1fa/0xeb0 [i915] <4> [309.733075] i915_pci_probe+0xe6/0x220 [i915] <4> [309.733198] local_pci_probe+0x44/0xb0 <4> [309.733203] pci_device_probe+0xf4/0x270 <4> [309.733209] really_probe+0xee/0x3c0 <4> [309.733215] __driver_probe_device+0x8c/0x180 <4> [309.733219] driver_probe_device+0x24/0xd0 <4> [309.733223] __driver_attach+0x10f/0x220 <4> [309.733230] bus_for_each_dev+0x7d/0xe0 <4> [309.733236] driver_attach+0x1e/0x30 <4> [309.733239] bus_add_driver+0x151/0x290 <4> [309.733244] driver_register+0x5e/0x130 <4> [309.733247] __pci_register_driver+0x7d/0x90 <4> [309.733251] i915_pci_register_driver+0x23/0x30 [i915] <4> [309.733413] i915_init+0x34/0x120 [i915] <4> [309.733655] do_one_initcall+0x62/0x3f0 <4> [309.733667] do_init_module+0x97/0x2a0 <4> [309.733671] load_module+0x25ff/0x2890 <4> [309.733688] init_module_from_file+0x97/0xe0 <4> [309.733701] idempotent_init_module+0x118/0x330 <4> [309.733711] __x64_sys_finit_module+0x77/0x100 <4> [309.733715] x64_sys_call+0x1f37/0x2650 <4> [309.733719] do_syscall_64+0x91/0x180 <4> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e <4> [309.733792] ... <4> [309.733806] ---[ end trace 0000000000000000 ]--- That scenario is most easily reproducible with igt@i915_module_load@reload-with-fault-injection. Fix the issue by moving the cleanup step to driver release path. Fixes: 27536e03271da ("drm/i915/huc: track delayed HuC load with a fence") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13592 Cc: Daniele Ceraolo Spurio Cc: Alan Previn Signed-off-by: Janusz Krzysztofik Reviewed-by: Daniele Ceraolo Spurio Reviewed-by: Krzysztof Karas Signed-off-by: Daniele Ceraolo Spurio Link: https://lore.kernel.org/r/20250402172057.209924-2-janusz.krzysztofik@linux.intel.com (cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 0ae84adbc9cc62d01e9846a767cc39c97a9e9694 Author: Wentao Liang Date: Tue Apr 8 15:30:01 2025 +0800 ata: sata_sx4: Add error handling in pdc20621_i2c_read() [ Upstream commit 8d46a27085039158eb5e253ab8a35a0e33b5e864 ] The function pdc20621_prog_dimm0() calls the function pdc20621_i2c_read() but does not handle the error if the read fails. This could lead to process with invalid data. A proper implementation can be found in /source/drivers/ata/sata_sx4.c, pdc20621_prog_dimm_global(). As mentioned in its commit: bb44e154e25125bef31fa956785e90fccd24610b, the variable spd0 might be used uninitialized when pdc20621_i2c_read() fails. Add error handling to pdc20621_i2c_read(). If a read operation fails, an error message is logged via dev_err(), and return a negative error code. Add error handling to pdc20621_prog_dimm0() in pdc20621_dimm_init(), and return a negative error code if pdc20621_prog_dimm0() fails. Fixes: 4447d3515616 ("libata: convert the remaining SATA drivers to new init model") Signed-off-by: Wentao Liang Reviewed-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit ad81d666e114ebf989fc9994d4c93d451dc60056 Author: Chenyuan Yang Date: Mon Apr 7 13:49:52 2025 -0500 net: libwx: handle page_pool_dev_alloc_pages error [ Upstream commit 7f1ff1b38a7c8b872382b796023419d87d78c47e ] page_pool_dev_alloc_pages could return NULL. There was a WARN_ON(!page) but it would still proceed to use the NULL pointer and then crash. This is similar to commit 001ba0902046 ("net: fec: handle page_pool_dev_alloc_pages error"). This is found by our static analysis tool KNighter. Signed-off-by: Chenyuan Yang Fixes: 3c47e8ae113a ("net: libwx: Support to receive packets in NAPI") Reviewed-by: Joe Damato Link: https://patch.msgid.link/20250407184952.2111299-1-chenyuan0y@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c81306c9d6d98cc8f5595abea09b55f577595c5f Author: Maxime Ripard Date: Tue Apr 8 09:34:13 2025 +0200 drm/tests: probe-helper: Fix drm_display_mode memory leak [ Upstream commit 8b6f2e28431b2f9f84073bff50353aeaf25559d0 ] drm_analog_tv_mode() and its variants return a drm_display_mode that needs to be destroyed later one. The drm_test_connector_helper_tv_get_modes_check() test never does however, which leads to a memory leak. Let's make sure it's freed. Reported-by: Philipp Stanner Closes: https://lore.kernel.org/dri-devel/a7655158a6367ac46194d57f4b7433ef0772a73e.camel@mailbox.org/ Fixes: 1e4a91db109f ("drm/probe-helper: Provide a TV get_modes helper") Reviewed-by: Thomas Zimmermann Link: https://lore.kernel.org/r/20250408-drm-kunit-drm-display-mode-memleak-v1-7-996305a2e75a@kernel.org Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 80f4dc6e1f5bfa53a6ea0d61e2620f2eb5ddc3db Author: Maxime Ripard Date: Tue Apr 8 09:34:11 2025 +0200 drm/tests: modes: Fix drm_display_mode memory leak [ Upstream commit d34146340f95cd9bf06d4ce71cca72127dc0b7cd ] drm_analog_tv_mode() and its variants return a drm_display_mode that needs to be destroyed later one. The drm_modes_analog_tv tests never do however, which leads to a memory leak. Let's make sure it's freed. Reported-by: Philipp Stanner Closes: https://lore.kernel.org/dri-devel/a7655158a6367ac46194d57f4b7433ef0772a73e.camel@mailbox.org/ Fixes: 4fcd238560ee ("drm/modes: Add a function to generate analog display modes") Reviewed-by: Thomas Zimmermann Link: https://lore.kernel.org/r/20250408-drm-kunit-drm-display-mode-memleak-v1-5-996305a2e75a@kernel.org Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit c7a0a32e6cf74d739a1f83d31a9988e143d333c1 Author: Maxime Ripard Date: Tue Apr 8 09:34:10 2025 +0200 drm/tests: cmdline: Fix drm_display_mode memory leak [ Upstream commit 70f29ca3117a8796cd6bde7612a3ded96d0f2dde ] drm_analog_tv_mode() and its variants return a drm_display_mode that needs to be destroyed later one. The drm_test_cmdline_tv_options() test never does however, which leads to a memory leak. Let's make sure it's freed. Reported-by: Philipp Stanner Closes: https://lore.kernel.org/dri-devel/a7655158a6367ac46194d57f4b7433ef0772a73e.camel@mailbox.org/ Fixes: e691c9992ae1 ("drm/modes: Introduce the tv_mode property as a command-line option") Reviewed-by: Thomas Zimmermann Link: https://lore.kernel.org/r/20250408-drm-kunit-drm-display-mode-memleak-v1-4-996305a2e75a@kernel.org Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit f951d643bc2618c41162189f24491f7a21c55e6f Author: Maxime Ripard Date: Tue Apr 8 09:34:07 2025 +0200 drm/tests: helpers: Create kunit helper to destroy a drm_display_mode [ Upstream commit 13c1d5f3a7fa7b55a26e73bb9e95342374a489b2 ] A number of test suites call functions that expect the returned drm_display_mode to be destroyed eventually. However, none of the tests called drm_mode_destroy, which results in a memory leak. Since drm_mode_destroy takes two pointers as argument, we can't use a kunit wrapper. Let's just create a helper every test suite can use. Reviewed-by: Thomas Zimmermann Link: https://lore.kernel.org/r/20250408-drm-kunit-drm-display-mode-memleak-v1-1-996305a2e75a@kernel.org Signed-off-by: Maxime Ripard Stable-dep-of: 70f29ca3117a ("drm/tests: cmdline: Fix drm_display_mode memory leak") Signed-off-by: Sasha Levin commit 71dd750a08344e46d54023c9477036aaf26d79f9 Author: Maxime Ripard Date: Tue Apr 8 09:34:08 2025 +0200 drm/tests: modeset: Fix drm_display_mode memory leak [ Upstream commit dacafdcc7789cfeb0f0552716db56f210238225d ] drm_mode_find_dmt() returns a drm_display_mode that needs to be destroyed later one. The drm_test_pick_cmdline_res_1920_1080_60() test never does however, which leads to a memory leak. Let's make sure it's freed. Reported-by: Philipp Stanner Closes: https://lore.kernel.org/dri-devel/a7655158a6367ac46194d57f4b7433ef0772a73e.camel@mailbox.org/ Fixes: 8fc0380f6ba7 ("drm/client: Add some tests for drm_connector_pick_cmdline_mode()") Reviewed-by: Thomas Zimmermann Link: https://lore.kernel.org/r/20250408-drm-kunit-drm-display-mode-memleak-v1-2-996305a2e75a@kernel.org Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit a065b996052656a65afc51ad82336dc55ae4c72f Author: Maxime Chevallier Date: Mon Apr 7 15:05:10 2025 +0200 net: ethtool: Don't call .cleanup_data when prepare_data fails [ Upstream commit 4f038a6a02d20859a3479293cbf172b0f14cbdd6 ] There's a consistent pattern where the .cleanup_data() callback is called when .prepare_data() fails, when it should really be called to clean after a successful .prepare_data() as per the documentation. Rewrite the error-handling paths to make sure we don't cleanup un-prepared data. Fixes: c781ff12a2f3 ("ethtool: Allow network drivers to dump arbitrary EEPROM data") Reviewed-by: Kory Maincent Reviewed-by: Simon Horman Reviewed-by: Michal Kubecek Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20250407130511.75621-1-maxime.chevallier@bootlin.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b2f3c3d57a832666a9d15e905e7717ac13977ef4 Author: Toke Høiland-Jørgensen Date: Mon Apr 7 12:55:34 2025 +0200 tc: Ensure we have enough buffer space when sending filter netlink notifications [ Upstream commit 369609fc6272c2f6ad666ba4fd913f3baf32908f ] The tfilter_notify() and tfilter_del_notify() functions assume that NLMSG_GOODSIZE is always enough to dump the filter chain. This is not always the case, which can lead to silent notify failures (because the return code of tfilter_notify() is not always checked). In particular, this can lead to NLM_F_ECHO not being honoured even though an action succeeds, which forces userspace to create workarounds[0]. Fix this by increasing the message size if dumping the filter chain into the allocated skb fails. Use the size of the incoming skb as a size hint if set, so we can start at a larger value when appropriate. To trigger this, run the following commands: # ip link add type veth # tc qdisc replace dev veth0 root handle 1: fq_codel # tc -echo filter add dev veth0 parent 1: u32 match u32 0 0 $(for i in $(seq 32); do echo action pedit munge ip dport set 22; done) Before this fix, tc just returns: Not a filter(cmd 2) After the fix, we get the correct echo: added filter dev veth0 parent 1: protocol all pref 49152 u32 chain 0 fh 800::800 order 2048 key ht 800 bkt 0 terminal flowid not_in_hw match 00000000/00000000 at 0 action order 1: pedit action pass keys 1 index 1 ref 1 bind 1 key #0 at 20: val 00000016 mask ffff0000 [repeated 32 times] [0] https://github.com/openvswitch/ovs/commit/106ef21860c935e5e0017a88bf42b94025c4e511 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Frode Nordahl Closes: https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2018500 Signed-off-by: Toke Høiland-Jørgensen Reviewed-by: Jiri Pirko Link: https://patch.msgid.link/20250407105542.16601-1-toke@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f0bb06b9f1d0bf6d02d957126cd25b52f089fb46 Author: Hariprasad Kelam Date: Mon Apr 7 12:33:41 2025 +0530 octeontx2-pf: qos: fix VF root node parent queue index [ Upstream commit b7db94734e785e380b0db0f9295e07024f4d42a0 ] The current code configures the Physical Function (PF) root node at TL1 and the Virtual Function (VF) root node at TL2. This ensure at any given point of time PF traffic gets more priority. PF root node TL1 / \ TL2 TL2 VF root node / \ TL3 TL3 / \ TL4 TL4 / \ SMQ SMQ Due to a bug in the current code, the TL2 parent queue index on the VF interface is not being configured, leading to 'SMQ Flush' errors Fixes: 5e6808b4c68d ("octeontx2-pf: Add support for HTB offload") Signed-off-by: Hariprasad Kelam Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250407070341.2765426-1-hkelam@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9fcbca0f801580cbb583e9cb274e2c7fbe766ca6 Author: Jakub Kicinski Date: Fri Apr 4 11:03:33 2025 -0700 net: tls: explicitly disallow disconnect [ Upstream commit 5071a1e606b30c0c11278d3c6620cd6a24724cf6 ] syzbot discovered that it can disconnect a TLS socket and then run into all sort of unexpected corner cases. I have a vague recollection of Eric pointing this out to us a long time ago. Supporting disconnect is really hard, for one thing if offload is enabled we'd need to wait for all packets to be _acked_. Disconnect is not commonly used, disallow it. The immediate problem syzbot run into is the warning in the strp, but that's just the easiest bug to trigger: WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237 Fixes: 3c4d7559159b ("tls: kernel TLS support") Reported-by: syzbot+b4cd76826045a1eb93c1@syzkaller.appspotmail.com Signed-off-by: Jakub Kicinski Reviewed-by: Eric Dumazet Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20250404180334.3224206-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4d55144b12e742404bb3f8fee6038bafbf45619d Author: Cong Wang Date: Thu Apr 3 14:16:31 2025 -0700 codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog() [ Upstream commit 342debc12183b51773b3345ba267e9263bdfaaef ] After making all ->qlen_notify() callbacks idempotent, now it is safe to remove the check of qlen!=0 from both fq_codel_dequeue() and codel_qdisc_dequeue(). Reported-by: Gerrard Tai Fixes: 4b549a2ef4be ("fq_codel: Fair Queue Codel AQM") Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM") Signed-off-by: Cong Wang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250403211636.166257-1-xiyou.wangcong@gmail.com Acked-by: Jamal Hadi Salim Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7c5957f7905b4aede9d7a559d271438f3ca9e852 Author: Tung Nguyen Date: Thu Apr 3 09:24:31 2025 +0000 tipc: fix memory leak in tipc_link_xmit [ Upstream commit 69ae94725f4fc9e75219d2d69022029c5b24bc9a ] In case the backlog transmit queue for system-importance messages is overloaded, tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads to memory leak and failure when a skb is allocated. This commit fixes this issue by purging the skb list before tipc_link_xmit() returns. Fixes: 365ad353c256 ("tipc: reduce risk of user starvation during link congestion") Signed-off-by: Tung Nguyen Link: https://patch.msgid.link/20250403092431.514063-1-tung.quang.nguyen@est.tech Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1b7685256db2faa07b75ecd137d172cc45b11c74 Author: Josh Poimboeuf Date: Tue Apr 8 00:02:13 2025 -0700 objtool: Fix INSN_CONTEXT_SWITCH handling in validate_unret() [ Upstream commit a8df7d0ef92eca28c610206c6748daf537ac0586 ] The !CONFIG_IA32_EMULATION version of xen_entry_SYSCALL_compat() ends with a SYSCALL instruction which is classified by objtool as INSN_CONTEXT_SWITCH. Unlike validate_branch(), validate_unret() doesn't consider INSN_CONTEXT_SWITCH in a non-function to be a dead end, so it keeps going past the end of xen_entry_SYSCALL_compat(), resulting in the following warning: vmlinux.o: warning: objtool: xen_reschedule_interrupt+0x2a: RET before UNTRAIN Fix that by adding INSN_CONTEXT_SWITCH handling to validate_unret() to match what validate_branch() is already doing. Fixes: a09a6e2399ba ("objtool: Add entry UNRET validation") Reported-by: Andrew Cooper Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/f5eda46fd09f15b1f5cde3d9ae3b92b958342add.1744095216.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit ee2b0301d6bfe16b35d57947687c664ecb815775 Author: Henry Martin Date: Fri Apr 4 14:14:38 2025 +0800 ata: pata_pxa: Fix potential NULL pointer dereference in pxa_ata_probe() [ Upstream commit ad320e408a8c95a282ab9c05cdf0c9b95e317985 ] devm_ioremap() returns NULL on error. Currently, pxa_ata_probe() does not check for this case, which can result in a NULL pointer dereference. Add NULL check after devm_ioremap() to prevent this issue. Fixes: 2dc6c6f15da9 ("[ARM] pata_pxa: DMA-capable PATA driver") Signed-off-by: Henry Martin Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 9e0bdc15579e3ab619525583e1da699f50afb0d2 Author: Tejas Upadhyay Date: Thu Mar 27 17:56:47 2025 +0530 drm/xe/hw_engine: define sysfs_ops on all directories [ Upstream commit a5c71fd5b69b9da77e5e0b268e69e256932ba49c ] Sysfs_ops needs to be defined on all directories which can have attr files with set/get method. Add sysfs_ops to even those directories which is currently empty but would have attr files with set/get method in future. Leave .default with default sysfs_ops as it will never have setter method. V2(Himal/Rodrigo): - use single sysfs_ops for all dir and attr with set/get - add default ops as ./default does not need runtime pm at all Fixes: 3f0e14651ab0 ("drm/xe: Runtime PM wake on every sysfs call") Reviewed-by: Himal Prasad Ghimiray Link: https://patchwork.freedesktop.org/patch/msgid/20250327122647.886637-1-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay (cherry picked from commit 40780b9760b561e093508d07b8b9b06c94ab201e) Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin commit 857e9432dab9daf4cd1a8278c6a8c4662e63dbc0 Author: Petr Vaněk Date: Mon Apr 7 15:24:27 2025 +0200 x86/acpi: Don't limit CPUs to 1 for Xen PV guests due to disabled ACPI [ Upstream commit 8b37357a78d7fa13d88ea822b35b40137da1c85e ] Xen disables ACPI for PV guests in DomU, which causes acpi_mps_check() to return 1 when CONFIG_X86_MPPARSE is not set. As a result, the local APIC is disabled and the guest is later limited to a single vCPU, despite being configured with more. This regression was introduced in version 6.9 in commit 7c0edad3643f ("x86/cpu/topology: Rework possible CPU management"), which added an early check that limits CPUs to 1 if apic_is_disabled. Update the acpi_mps_check() logic to return 0 early when running as a Xen PV guest in DomU, preventing APIC from being disabled in this specific case and restoring correct multi-vCPU behaviour. Fixes: 7c0edad3643f ("x86/cpu/topology: Rework possible CPU management") Signed-off-by: Petr Vaněk Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250407132445.6732-2-arkamar@atlas.cz Signed-off-by: Sasha Levin commit 9ddc7edc558acef8dd4f645af3683b226e2b590c Author: Badal Nilawar Date: Mon Mar 10 20:58:21 2025 +0530 drm/i915: Disable RPG during live selftest [ Upstream commit 9d3d9776bd3bd9c32d460dfe6c3363134de578bc ] The Forcewake timeout issue has been observed on Gen 12.0 and above. To address this, disable Render Power-Gating (RPG) during live self-tests for these generations. The temporary workaround 'drm/i915/mtl: do not enable render power-gating on MTL' disables RPG globally, which is unnecessary since the issues were only seen during self-tests. v2: take runtime pm wakeref Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/9413 Fixes: 25e7976db86b ("drm/i915/mtl: do not enable render power-gating on MTL") Cc: Rodrigo Vivi Cc: Andi Shyti Cc: Andrzej Hajda Signed-off-by: Badal Nilawar Signed-off-by: Sk Anirban Reviewed-by: Karthik Poosa Signed-off-by: Anshuman Gupta Link: https://patchwork.freedesktop.org/patch/msgid/20250310152821.2931678-1-sk.anirban@intel.com (cherry picked from commit 0a4ae87706c6d15d14648e428c3a76351f823e48) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit caa5c8a2358604f38bf0a4afaa5eacda13763067 Author: Ming Lei Date: Wed Apr 9 09:14:41 2025 +0800 ublk: fix handling recovery & reissue in ublk_abort_queue() [ Upstream commit 6ee6bd5d4fce502a5b5a2ea805e9ff16e6aa890f ] Commit 8284066946e6 ("ublk: grab request reference when the request is handled by userspace") doesn't grab request reference in case of recovery reissue. Then the request can be requeued & re-dispatch & failed when canceling uring command. If it is one zc request, the request can be freed before io_uring returns the zc buffer back, then cause kernel panic: [ 126.773061] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 126.773657] #PF: supervisor read access in kernel mode [ 126.774052] #PF: error_code(0x0000) - not-present page [ 126.774455] PGD 0 P4D 0 [ 126.774698] Oops: Oops: 0000 [#1] SMP NOPTI [ 126.775034] CPU: 13 UID: 0 PID: 1612 Comm: kworker/u64:55 Not tainted 6.14.0_blk+ #182 PREEMPT(full) [ 126.775676] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 [ 126.776275] Workqueue: iou_exit io_ring_exit_work [ 126.776651] RIP: 0010:ublk_io_release+0x14/0x130 [ublk_drv] Fixes it by always grabbing request reference for aborting the request. Reported-by: Caleb Sander Mateos Closes: https://lore.kernel.org/linux-block/CADUfDZodKfOGUeWrnAxcZiLT+puaZX8jDHoj_sfHZCOZwhzz6A@mail.gmail.com/ Fixes: 8284066946e6 ("ublk: grab request reference when the request is handled by userspace") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20250409011444.2142010-2-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cb8372e54fdb91f1123f01b566d0797cd585a3d1 Author: Uday Shankar Date: Mon Oct 7 12:24:15 2024 -0600 ublk: refactor recovery configuration flag helpers [ Upstream commit 3b939b8f715e014adcc48f7827fe9417252f0833 ] ublk currently supports the following behaviors on ublk server exit: A: outstanding I/Os get errors, subsequently issued I/Os get errors B: outstanding I/Os get errors, subsequently issued I/Os queue C: outstanding I/Os get reissued, subsequently issued I/Os queue and the following behaviors for recovery of preexisting block devices by a future incarnation of the ublk server: 1: ublk devices stopped on ublk server exit (no recovery possible) 2: ublk devices are recoverable using start/end_recovery commands The userspace interface allows selection of combinations of these behaviors using flags specified at device creation time, namely: default behavior: A + 1 UBLK_F_USER_RECOVERY: B + 2 UBLK_F_USER_RECOVERY|UBLK_F_USER_RECOVERY_REISSUE: C + 2 We can't easily change the userspace interface to allow independent selection of one of {A, B, C} and one of {1, 2}, but we can refactor the internal helpers which test for the flags. Replace the existing helpers with the following set: ublk_nosrv_should_reissue_outstanding: tests for behavior C ublk_nosrv_[dev_]should_queue_io: tests for behavior B ublk_nosrv_should_stop_dev: tests for behavior 1 Signed-off-by: Uday Shankar Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20241007182419.3263186-3-ushankar@purestorage.com Signed-off-by: Jens Axboe Stable-dep-of: 6ee6bd5d4fce ("ublk: fix handling recovery & reissue in ublk_abort_queue()") Signed-off-by: Sasha Levin commit 206d0df7b6a52daa6a9dcb326b243bbce389344c Author: Edward Liaw Date: Fri Apr 4 22:12:20 2025 +0000 selftests/futex: futex_waitv wouldblock test should fail [ Upstream commit 7d50e00fef2832e98d7e06bbfc85c1d66ee110ca ] Testcase should fail if -EWOULDBLOCK is not returned when expected value differs from actual value from the waiter. Link: https://lore.kernel.org/r/20250404221225.1596324-1-edliaw@google.com Fixes: 9d57f7c79748920636f8293d2f01192d702fe390 ("selftests: futex: Test sys_futex_waitv() wouldblock") Signed-off-by: Edward Liaw Reviewed-by: Thomas Gleixner Reviewed-by: André Almeida Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 179ef2f8109e3a8cde6cf02afa730d54bee92cd7 Author: Andy Shevchenko Date: Wed Apr 2 15:20:00 2025 +0300 gpiolib: of: Fix the choice for Ingenic NAND quirk [ Upstream commit 2b9c536430126c233552cdcd6ec9d5077454ece4 ] The Ingenic NAND quirk has been added under CONFIG_LCD_HX8357 ifdeffery which sounds quite wrong. Fix the choice for Ingenic NAND quirk by wrapping it into own ifdeffery related to the respective driver. Fixes: 3a7fd473bd5d ("mtd: rawnand: ingenic: move the GPIO quirk to gpiolib-of.c") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20250402122058.1517393-2-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit cdb6e724e7c5713d13c5ad3340e9d71c3dd8c9fb Author: Waiman Long Date: Sun Mar 30 17:52:39 2025 -0400 cgroup/cpuset: Fix race between newly created partition and dying one [ Upstream commit a22b3d54de94f82ca057cc2ebf9496fa91ebf698 ] There is a possible race between removing a cgroup diectory that is a partition root and the creation of a new partition. The partition to be removed can be dying but still online, it doesn't not currently participate in checking for exclusive CPUs conflict, but the exclusive CPUs are still there in subpartitions_cpus and isolated_cpus. These two cpumasks are global states that affect the operation of cpuset partitions. The exclusive CPUs in dying cpusets will only be removed when cpuset_css_offline() function is called after an RCU delay. As a result, it is possible that a new partition can be created with exclusive CPUs that overlap with those of a dying one. When that dying partition is finally offlined, it removes those overlapping exclusive CPUs from subpartitions_cpus and maybe isolated_cpus resulting in an incorrect CPU configuration. This bug was found when a warning was triggered in remote_partition_disable() during testing because the subpartitions_cpus mask was empty. One possible way to fix this is to iterate the dying cpusets as well and avoid using the exclusive CPUs in those dying cpusets. However, this can still cause random partition creation failures or other anomalies due to racing. A better way to fix this race is to reset the partition state at the moment when a cpuset is being killed. Introduce a new css_killed() CSS function pointer and call it, if defined, before setting CSS_DYING flag in kill_css(). Also update the css_is_dying() helper to use the CSS_DYING flag introduced by commit 33c35aa48178 ("cgroup: Prevent kill_css() from being called more than once") for proper synchronization. Add a new cpuset_css_killed() function to reset the partition state of a valid partition root if it is being killed. Fixes: ee8dde0cd2ce ("cpuset: Add new v2 cpuset.sched.partition flag") Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 1b06f00edaaa08ee23dba7972b24ede337c3a3cf Author: Waiman Long Date: Sat Nov 9 21:50:23 2024 -0500 cgroup/cpuset: Further optimize code if CONFIG_CPUSETS_V1 not set [ Upstream commit c4c9cebe2fb9cdc73e55513de7af7a4f50260e88 ] Currently the cpuset code uses group_subsys_on_dfl() to check if we are running with cgroup v2. If CONFIG_CPUSETS_V1 isn't set, there is really no need to do this check and we can optimize out some of the unneeded v1 specific code paths. Introduce a new cpuset_v2() and use it to replace the cgroup_subsys_on_dfl() check to further optimize the code. Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Stable-dep-of: a22b3d54de94 ("cgroup/cpuset: Fix race between newly created partition and dying one") Signed-off-by: Sasha Levin commit 6b145f8b22011743b563965df0e090789b413bb8 Author: Waiman Long Date: Sat Nov 9 21:50:22 2024 -0500 cgroup/cpuset: Enforce at most one rebuild_sched_domains_locked() call per operation [ Upstream commit a040c351283e3ac75422621ea205b1d8d687e108 ] Since commit ff0ce721ec21 ("cgroup/cpuset: Eliminate unncessary sched domains rebuilds in hotplug"), there is only one rebuild_sched_domains_locked() call per hotplug operation. However, writing to the various cpuset control files may still casue more than one rebuild_sched_domains_locked() call to happen in some cases. Juri had found that two rebuild_sched_domains_locked() calls in update_prstate(), one from update_cpumasks_hier() and another one from update_partition_sd_lb() could cause cpuset partition to be created with null total_bw for DL tasks. IOW, DL tasks may not be scheduled correctly in such a partition. A sample command sequence that can reproduce null total_bw is as follows. # echo Y >/sys/kernel/debug/sched/verbose # echo +cpuset >/sys/fs/cgroup/cgroup.subtree_control # mkdir /sys/fs/cgroup/test # echo 0-7 > /sys/fs/cgroup/test/cpuset.cpus # echo 6-7 > /sys/fs/cgroup/test/cpuset.cpus.exclusive # echo root >/sys/fs/cgroup/test/cpuset.cpus.partition Fix this double rebuild_sched_domains_locked() calls problem by replacing existing calls with cpuset_force_rebuild() except the rebuild_sched_domains_cpuslocked() call at the end of cpuset_handle_hotplug(). Checking of the force_sd_rebuild flag is now done at the end of cpuset_write_resmask() and update_prstate() to determine if rebuild_sched_domains_locked() should be called or not. The cpuset v1 code can still call rebuild_sched_domains_locked() directly as double rebuild_sched_domains_locked() calls is not possible. Reported-by: Juri Lelli Closes: https://lore.kernel.org/lkml/ZyuUcJDPBln1BK1Y@jlelli-thinkpadt14gen4.remote.csb/ Signed-off-by: Waiman Long Tested-by: Juri Lelli Signed-off-by: Tejun Heo Stable-dep-of: a22b3d54de94 ("cgroup/cpuset: Fix race between newly created partition and dying one") Signed-off-by: Sasha Levin commit 2dbd1b166034ab4bff100130a1a49309c6b31e48 Author: Waiman Long Date: Sat Nov 9 21:50:21 2024 -0500 cgroup/cpuset: Revert "Allow suppression of sched domain rebuild in update_cpumasks_hier()" [ Upstream commit bcd7012afd7bcd45fcd7a0e2f48e57b273702317 ] Revert commit 3ae0b773211e ("cgroup/cpuset: Allow suppression of sched domain rebuild in update_cpumasks_hier()") to allow for an alternative way to suppress unnecessary rebuild_sched_domains_locked() calls in update_cpumasks_hier() and elsewhere in a following commit. Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Stable-dep-of: a22b3d54de94 ("cgroup/cpuset: Fix race between newly created partition and dying one") Signed-off-by: Sasha Levin commit 9701dcbf5fce193def747ed03d6c788bcc49e2ca Author: Waiman Long Date: Sun Mar 30 17:52:41 2025 -0400 cgroup/cpuset: Fix error handling in remote_partition_disable() [ Upstream commit 8bf450f3aec3d1bbd725d179502c64b8992588e4 ] When remote_partition_disable() is called to disable a remote partition, it always sets the partition to an invalid partition state. It should only do so if an error code (prs_err) has been set. Correct that and add proper error code in places where remote_partition_disable() is called due to error. Fixes: 181c8e091aae ("cgroup/cpuset: Introduce remote partition") Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 40bc55e4fcbd740731e5f131f4fc9a94a2f86ac8 Author: Waiman Long Date: Sun Mar 30 17:52:40 2025 -0400 cgroup/cpuset: Fix incorrect isolated_cpus update in update_parent_effective_cpumask() [ Upstream commit 668e041662e92ab3ebcb9eb606d3ec01884546ab ] Before commit f0af1bfc27b5 ("cgroup/cpuset: Relax constraints to partition & cpus changes"), a cpuset partition cannot be enabled if not all the requested CPUs can be granted from the parent cpuset. After that commit, a cpuset partition can be created even if the requested exclusive CPUs contain CPUs not allowed its parent. The delmask containing exclusive CPUs to be removed from its parent wasn't adjusted accordingly. That is not a problem until the introduction of a new isolated_cpus mask in commit 11e5f407b64a ("cgroup/cpuset: Keep track of CPUs in isolated partitions") as the CPUs in the delmask may be added directly into isolated_cpus. As a result, isolated_cpus may incorrectly contain CPUs that are not isolated leading to incorrect data reporting. Fix this by adjusting the delmask to reflect the actual exclusive CPUs for the creation of the partition. Fixes: 11e5f407b64a ("cgroup/cpuset: Keep track of CPUs in isolated partitions") Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit b980b832318ca6686d1c077162d45153fae16875 Author: Bard Liao Date: Wed Mar 5 21:54:35 2025 +0800 ASoC: Intel: adl: add 2xrt1316 audio configuration commit 8b36447c9ae102539d82d6278971b23b20d87629 upstream. That is a speaker only configuration and 2 rt1316 are on link 0 and 2. Signed-off-by: Bard Liao Reviewed-by: Liam Girdwood Reviewed-by: Péter Ujfalusi Link: https://patch.msgid.link/20250305135443.201884-2-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1b37c2e3ec990243eb17cd05cdffe881d4e3658d Author: Alexandre Frade Date: Thu Apr 10 22:21:36 2025 +0000 Linux 6.12.23-xanmod1 Signed-off-by: Alexandre Frade commit e607650cb18dddb4687326cd22ae0ba5bb6bae59 Merge: 5d770250a6a9 83b4161a63b8 Author: Alexandre Frade Date: Thu Apr 10 22:18:42 2025 +0000 Merge tag 'v6.12.23' into 6.12 This is the 6.12.23 stable release commit 83b4161a63b87ce40d9f24f09b5b006f63d95b7c Author: Greg Kroah-Hartman Date: Thu Apr 10 14:39:41 2025 +0200 Linux 6.12.23 Link: https://lore.kernel.org/r/20250408104845.675475678@linuxfoundation.org Tested-by: Markus Reichelt Link: https://lore.kernel.org/r/20250408154121.378213016@linuxfoundation.org Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: SeongJae Park Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Salvatore Bonaccorso Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20250409115859.721906906@linuxfoundation.org Tested-by: Miguel Ojeda Tested-by: Mark Brown Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman commit e70b4b8f93d7fcf8ee063a1d1f18782c4da3d335 Author: Dan Carpenter Date: Mon Mar 10 22:48:29 2025 +0300 platform/x86/amd/pmf: fix cleanup in amd_pmf_init_smart_pc() commit 5b1122fc4995f308b21d7cfc64ef9880ac834d20 upstream. There are a few problems in this code: First, if amd_pmf_tee_init() fails then the function returns directly instead of cleaning up. We cannot simply do a "goto error;" because the amd_pmf_tee_init() cleanup calls tee_shm_free(dev->fw_shm_pool); and amd_pmf_tee_deinit() calls it as well leading to a double free. I have re-written this code to use an unwind ladder to free the allocations. Second, if amd_pmf_start_policy_engine() fails on every iteration though the loop then the code calls amd_pmf_tee_deinit() twice which is also a double free. Call amd_pmf_tee_deinit() inside the loop for each failed iteration. Also on that path the error codes are not necessarily negative kernel error codes. Set the error code to -EINVAL. There is a very subtle third bug which is that if the call to input_register_device() in amd_pmf_register_input_device() fails then we call input_unregister_device() on an input device that wasn't registered. This will lead to a reference counting underflow because of the device_del(&dev->dev) in __input_unregister_device(). It's unlikely that anyone would ever hit this bug in real life. Fixes: 376a8c2a1443 ("platform/x86/amd/pmf: Update PMF Driver for Compatibility with new PMF-TA") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/232231fc-6a71-495e-971b-be2a76f6db4c@stanley.mountain Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 625e9b91eb136280f084859d4e3994ff598a0d28 Author: Steven Rostedt Date: Sun Mar 23 15:21:51 2025 -0400 tracing: Do not use PERF enums when perf is not defined commit 8eb1518642738c6892bd629b46043513a3bf1a6a upstream. An update was made to up the module ref count when a synthetic event is registered for both trace and perf events. But if perf is not configured in, the perf enums used will cause the kernel to fail to build. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Douglas Raillard Link: https://lore.kernel.org/20250323152151.528b5ced@batman.local.home Fixes: 21581dd4e7ff ("tracing: Ensure module defining synth event cannot be unloaded while tracing") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202503232230.TeREVy8R-lkp@intel.com/ Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 59fc42318305cb38efb4f5565408150419be8451 Author: Nathan Chancellor Date: Thu Mar 20 22:33:49 2025 +0100 ARM: 9443/1: Require linker to support KEEP within OVERLAY for DCE commit e7607f7d6d81af71dcc5171278aadccc94d277cd upstream. ld.lld prior to 21.0.0 does not support using the KEEP keyword within an overlay description, which may be needed to avoid discarding necessary sections within an overlay with '--gc-sections', which can be enabled for the kernel via CONFIG_LD_DEAD_CODE_DATA_ELIMINATION. Disallow CONFIG_LD_DEAD_CODE_DATA_ELIMINATION without support for KEEP within OVERLAY and introduce a macro, OVERLAY_KEEP, that can be used to conditionally add KEEP when it is properly supported to avoid breaking old versions of ld.lld. Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/commit/381599f1fe973afad3094e55ec99b1620dba7d8c Reviewed-by: Linus Walleij Signed-off-by: Nathan Chancellor Signed-off-by: Russell King (Oracle) [nathan: Fix conflict in init/Kconfig due to lack of RUSTC symbols] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit c6f2a8146da1c30d947bbdddd5cd84566ed8ae5d Author: Chuck Lever Date: Tue Jan 14 17:09:24 2025 -0500 NFSD: Skip sending CB_RECALL_ANY when the backchannel isn't up commit 8a388c1fabeb6606e16467b23242416c0dbeffad upstream. NFSD sends CB_RECALL_ANY to clients when the server is low on memory or that client has a large number of delegations outstanding. We've seen cases where NFSD attempts to send CB_RECALL_ANY requests to disconnected clients, and gets confused. These calls never go anywhere if a backchannel transport to the target client isn't available. Before the server can send any backchannel operation, the client has to connect first and then do a BIND_CONN_TO_SESSION. This patch doesn't address the root cause of the confusion, but there's no need to queue up these optional operations if they can't go anywhere. Fixes: 44df6f439a17 ("NFSD: add delegation reaper to react to low memory condition") Reviewed-by: Jeff Layton Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit afec5b5010de3f8494e10fc904a9453003d9a0aa Author: Chuck Lever Date: Sun Jan 26 16:50:18 2025 -0500 NFSD: Never return NFS4ERR_FILE_OPEN when removing a directory commit 370345b4bd184a49ac68d6591801e5e3605b355a upstream. RFC 8881 Section 18.25.4 paragraph 5 tells us that the server should return NFS4ERR_FILE_OPEN only if the target object is an opened file. This suggests that returning this status when removing a directory will confuse NFS clients. This is a version-specific issue; nfsd_proc_remove/rmdir() and nfsd3_proc_remove/rmdir() already return nfserr_access as appropriate. Unfortunately there is no quick way for nfsd4_remove() to determine whether the target object is a file or not, so the check is done in in nfsd_unlink() for now. Reported-by: Trond Myklebust Fixes: 466e16f0920f ("nfsd: check for EBUSY from vfs_rmdir/vfs_unink.") Reviewed-by: Jeff Layton Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 101fd0aa0d7d502ea947cdc20abdc9a6e565dea0 Author: Chuck Lever Date: Sun Jan 26 16:50:17 2025 -0500 NFSD: nfsd_unlink() clobbers non-zero status returned from fh_fill_pre_attrs() commit d7d8e3169b56e7696559a2427c922c0d55debcec upstream. If fh_fill_pre_attrs() returns a non-zero status, the error flow takes it through out_unlock, which then overwrites the returned status code with err = nfserrno(host_err); Fixes: a332018a91c4 ("nfsd: handle failure to collect pre/post-op attrs more sanely") Reviewed-by: Jeff Layton Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit a84c80515ca8a0cdf6d06f1b6ca721224b08453e Author: Olga Kornievskaia Date: Fri Jan 17 11:32:58 2025 -0500 nfsd: fix management of listener transports commit d093c90892607be505e801469d6674459e69ab89 upstream. Currently, when no active threads are running, a root user using nfsdctl command can try to remove a particular listener from the list of previously added ones, then start the server by increasing the number of threads, it leads to the following problem: [ 158.835354] refcount_t: addition on 0; use-after-free. [ 158.835603] WARNING: CPU: 2 PID: 9145 at lib/refcount.c:25 refcount_warn_saturate+0x160/0x1a0 [ 158.836017] Modules linked in: rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd auth_rpcgss nfs_acl lockd grace overlay isofs uinput snd_seq_dummy snd_hrtimer nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set nf_tables qrtr sunrpc vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops uvc videobuf2_v4l2 videodev videobuf2_common snd_hda_codec_generic mc e1000e snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore sg loop dm_multipath dm_mod nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs libcrc32c crct10dif_ce ghash_ce vmwgfx sha2_ce sha256_arm64 sr_mod sha1_ce cdrom nvme drm_client_lib drm_ttm_helper ttm nvme_core drm_kms_helper nvme_auth drm fuse [ 158.840093] CPU: 2 UID: 0 PID: 9145 Comm: nfsd Kdump: loaded Tainted: G B W 6.13.0-rc6+ #7 [ 158.840624] Tainted: [B]=BAD_PAGE, [W]=WARN [ 158.840802] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 158.841220] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 158.841563] pc : refcount_warn_saturate+0x160/0x1a0 [ 158.841780] lr : refcount_warn_saturate+0x160/0x1a0 [ 158.842000] sp : ffff800089be7d80 [ 158.842147] x29: ffff800089be7d80 x28: ffff00008e68c148 x27: ffff00008e68c148 [ 158.842492] x26: ffff0002e3b5c000 x25: ffff600011cd1829 x24: ffff00008653c010 [ 158.842832] x23: ffff00008653c000 x22: 1fffe00011cd1829 x21: ffff00008653c028 [ 158.843175] x20: 0000000000000002 x19: ffff00008653c010 x18: 0000000000000000 [ 158.843505] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 158.843836] x14: 0000000000000000 x13: 0000000000000001 x12: ffff600050a26493 [ 158.844143] x11: 1fffe00050a26492 x10: ffff600050a26492 x9 : dfff800000000000 [ 158.844475] x8 : 00009fffaf5d9b6e x7 : ffff000285132493 x6 : 0000000000000001 [ 158.844823] x5 : ffff000285132490 x4 : ffff600050a26493 x3 : ffff8000805e72bc [ 158.845174] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000098588000 [ 158.845528] Call trace: [ 158.845658] refcount_warn_saturate+0x160/0x1a0 (P) [ 158.845894] svc_recv+0x58c/0x680 [sunrpc] [ 158.846183] nfsd+0x1fc/0x348 [nfsd] [ 158.846390] kthread+0x274/0x2f8 [ 158.846546] ret_from_fork+0x10/0x20 [ 158.846714] ---[ end trace 0000000000000000 ]--- nfsd_nl_listener_set_doit() would manipulate the list of transports of server's sv_permsocks and close the specified listener but the other list of transports (server's sp_xprts list) would not be changed leading to the problem above. Instead, determined if the nfsdctl is trying to remove a listener, in which case, delete all the existing listener transports and re-create all-but-the-removed ones. Fixes: 16a471177496 ("NFSD: add listener-{set,get} netlink command") Signed-off-by: Olga Kornievskaia Reviewed-by: Jeff Layton Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit cad3479b63661a399c9df1d0b759e1806e2df3c8 Author: Li Lingfeng Date: Thu Feb 13 22:42:20 2025 +0800 nfsd: put dl_stid if fail to queue dl_recall commit 230ca758453c63bd38e4d9f4a21db698f7abada8 upstream. Before calling nfsd4_run_cb to queue dl_recall to the callback_wq, we increment the reference count of dl_stid. We expect that after the corresponding work_struct is processed, the reference count of dl_stid will be decremented through the callback function nfsd4_cb_recall_release. However, if the call to nfsd4_run_cb fails, the incremented reference count of dl_stid will not be decremented correspondingly, leading to the following nfs4_stid leak: unreferenced object 0xffff88812067b578 (size 344): comm "nfsd", pid 2761, jiffies 4295044002 (age 5541.241s) hex dump (first 32 bytes): 01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff ....kkkk........ 00 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .kkkkkkk.....N.. backtrace: kmem_cache_alloc+0x4b9/0x700 nfsd4_process_open1+0x34/0x300 nfsd4_open+0x2d1/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 unreferenced object 0xffff8881499f4d28 (size 368): comm "nfsd", pid 2761, jiffies 4295044005 (age 5541.239s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff ........0M.I.... 30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00 0M.I.... ....... backtrace: kmem_cache_alloc+0x4b9/0x700 nfs4_alloc_stid+0x29/0x210 alloc_init_deleg+0x92/0x2e0 nfs4_set_delegation+0x284/0xc00 nfs4_open_delegation+0x216/0x3f0 nfsd4_process_open2+0x2b3/0xee0 nfsd4_open+0x770/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 Fix it by checking the result of nfsd4_run_cb and call nfs4_put_stid if fail to queue dl_recall. Cc: stable@vger.kernel.org Signed-off-by: Li Lingfeng Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 52e209203c35a4fbff8af23cd3613efe5df40102 Author: Jeff Layton Date: Thu Feb 13 09:08:29 2025 -0500 nfsd: allow SC_STATUS_FREEABLE when searching via nfs4_lookup_stateid() commit d1bc15b147d35b4cb7ca99a9a7d79d41ca342c13 upstream. The pynfs DELEG8 test fails when run against nfsd. It acquires a delegation and then lets the lease time out. It then tries to use the deleg stateid and expects to see NFS4ERR_DELEG_REVOKED, but it gets bad NFS4ERR_BAD_STATEID instead. When a delegation is revoked, it's initially marked with SC_STATUS_REVOKED, or SC_STATUS_ADMIN_REVOKED and later, it's marked with the SC_STATUS_FREEABLE flag, which denotes that it is waiting for s FREE_STATEID call. nfs4_lookup_stateid() accepts a statusmask that includes the status flags that a found stateid is allowed to have. Currently, that mask never includes SC_STATUS_FREEABLE, which means that revoked delegations are (almost) never found. Add SC_STATUS_FREEABLE to the always-allowed status flags, and remove it from nfsd4_delegreturn() since it's now always implied. Fixes: 8dd91e8d31fe ("nfsd: fix race between laundromat and free_stateid") Cc: stable@vger.kernel.org Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit adf0ddb914c9e5b3e50da4c97959e82de2df75c3 Author: Murad Masimov Date: Mon Jan 13 13:51:30 2025 +0300 media: streamzap: fix race between device disconnection and urb callback commit f656cfbc7a293a039d6a0c7100e1c846845148c1 upstream. Syzkaller has reported a general protection fault at function ir_raw_event_store_with_filter(). This crash is caused by a NULL pointer dereference of dev->raw pointer, even though it is checked for NULL in the same function, which means there is a race condition. It occurs due to the incorrect order of actions in the streamzap_disconnect() function: rc_unregister_device() is called before usb_kill_urb(). The dev->raw pointer is freed and set to NULL in rc_unregister_device(), and only after that usb_kill_urb() waits for in-progress requests to finish. If rc_unregister_device() is called while streamzap_callback() handler is not finished, this can lead to accessing freed resources. Thus rc_unregister_device() should be called after usb_kill_urb(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 8e9e60640067 ("V4L/DVB: staging/lirc: port lirc_streamzap to ir-core") Cc: stable@vger.kernel.org Reported-by: syzbot+34008406ee9a31b13c73@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=34008406ee9a31b13c73 Signed-off-by: Murad Masimov Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 845e9286ff99ee88cfdeb2b748f730003a512190 Author: Nikita Zhandarovich Date: Sun Mar 2 17:58:25 2025 +0300 media: vimc: skip .s_stream() for stopped entities commit 36cef585e2a31e4ddf33a004b0584a7a572246de upstream. Syzbot reported [1] a warning prompted by a check in call_s_stream() that checks whether .s_stream() operation is warranted for unstarted or stopped subdevs. Add a simple fix in vimc_streamer_pipeline_terminate() ensuring that entities skip a call to .s_stream() unless they have been previously properly started. [1] Syzbot report: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460 Modules linked in: CPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0 ... Call Trace: vimc_streamer_pipeline_terminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62 vimc_streamer_pipeline_init drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline] vimc_streamer_s_stream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203 vimc_capture_start_streaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256 vb2_start_streaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789 vb2_core_streamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348 vb2_streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline] vb2_ioctl_streamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118 __video_do_ioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122 video_usercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463 v4l2_ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 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:0x7f2b85c01b19 ... Reported-by: syzbot+5bcd7c809d365e14c4df@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5bcd7c809d365e14c4df Fixes: adc589d2a208 ("media: vimc: Add vimc-streamer for stream control") Cc: stable@vger.kernel.org Signed-off-by: Nikita Zhandarovich Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit e2d8e7bd3314485e0b3b08380c659b3d1d67ed6a Author: Oleg Nesterov Date: Mon Mar 24 17:00:03 2025 +0100 exec: fix the racy usage of fs_struct->in_exec commit af7bb0d2ca459f15cb5ca604dab5d9af103643f0 upstream. check_unsafe_exec() sets fs->in_exec under cred_guard_mutex, then execve() paths clear fs->in_exec lockless. This is fine if exec succeeds, but if it fails we have the following race: T1 sets fs->in_exec = 1, fails, drops cred_guard_mutex T2 sets fs->in_exec = 1 T1 clears fs->in_exec T2 continues with fs->in_exec == 0 Change fs/exec.c to clear fs->in_exec with cred_guard_mutex held. Reported-by: syzbot+1c486d0b62032c82a968@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67dc67f0.050a0220.25ae54.001f.GAE@google.com/ Cc: stable@vger.kernel.org Signed-off-by: Oleg Nesterov Link: https://lore.kernel.org/r/20250324160003.GA8878@redhat.com Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 747e3eec1d7d124ea90ed3d7b85369df8b4e36d2 Author: Yosry Ahmed Date: Wed Feb 26 18:56:25 2025 +0000 mm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead() commit c11bcbc0a517acf69282c8225059b2a8ac5fe628 upstream. Currently, zswap_cpu_comp_dead() calls crypto_free_acomp() while holding the per-CPU acomp_ctx mutex. crypto_free_acomp() then holds scomp_lock (through crypto_exit_scomp_ops_async()). On the other hand, crypto_alloc_acomp_node() holds the scomp_lock (through crypto_scomp_init_tfm()), and then allocates memory. If the allocation results in reclaim, we may attempt to hold the per-CPU acomp_ctx mutex. The above dependencies can cause an ABBA deadlock. For example in the following scenario: (1) Task A running on CPU #1: crypto_alloc_acomp_node() Holds scomp_lock Enters reclaim Reads per_cpu_ptr(pool->acomp_ctx, 1) (2) Task A is descheduled (3) CPU #1 goes offline zswap_cpu_comp_dead(CPU #1) Holds per_cpu_ptr(pool->acomp_ctx, 1)) Calls crypto_free_acomp() Waits for scomp_lock (4) Task A running on CPU #2: Waits for per_cpu_ptr(pool->acomp_ctx, 1) // Read on CPU #1 DEADLOCK Since there is no requirement to call crypto_free_acomp() with the per-CPU acomp_ctx mutex held in zswap_cpu_comp_dead(), move it after the mutex is unlocked. Also move the acomp_request_free() and kfree() calls for consistency and to avoid any potential sublte locking dependencies in the future. With this, only setting acomp_ctx fields to NULL occurs with the mutex held. This is similar to how zswap_cpu_comp_prepare() only initializes acomp_ctx fields with the mutex held, after performing all allocations before holding the mutex. Opportunistically, move the NULL check on acomp_ctx so that it takes place before the mutex dereference. Link: https://lkml.kernel.org/r/20250226185625.2672936-1-yosry.ahmed@linux.dev Fixes: 12dcb0ef5406 ("mm: zswap: properly synchronize freeing resources during CPU hotunplug") Signed-off-by: Herbert Xu Co-developed-by: Herbert Xu Signed-off-by: Yosry Ahmed Reported-by: syzbot+1a517ccfcbc6a7ab0f82@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67bcea51.050a0220.bbfd1.0096.GAE@google.com/ Acked-by: Herbert Xu Reviewed-by: Chengming Zhou Reviewed-by: Nhat Pham Tested-by: Nhat Pham Cc: David S. Miller Cc: Eric Biggers Cc: Johannes Weiner Cc: Chris Murphy Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2d9709690f31540adc3e97923878f539db07d0f0 Author: Roman Smirnov Date: Wed Feb 26 11:25:22 2025 +0300 jfs: add index corruption check to DT_GETPAGE() commit a8dfb2168906944ea61acfc87846b816eeab882d upstream. If the file system is corrupted, the header.stblindex variable may become greater than 127. Because of this, an array access out of bounds may occur: ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:3096:10 index 237 is out of range for type 'struct dtslot[128]' CPU: 0 UID: 0 PID: 5822 Comm: syz-executor740 Not tainted 6.13.0-rc4-syzkaller-00110-g4099a71718b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 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_out_of_bounds+0x121/0x150 lib/ubsan.c:429 dtReadFirst+0x622/0xc50 fs/jfs/jfs_dtree.c:3096 dtReadNext fs/jfs/jfs_dtree.c:3147 [inline] jfs_readdir+0x9aa/0x3c50 fs/jfs/jfs_dtree.c:2862 wrap_directory_iterator+0x91/0xd0 fs/readdir.c:65 iterate_dir+0x571/0x800 fs/readdir.c:108 __do_sys_getdents64 fs/readdir.c:403 [inline] __se_sys_getdents64+0x1e2/0x4b0 fs/readdir.c:389 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 ---[ end trace ]--- Add a stblindex check for corruption. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=9120834fc227768625ba Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Roman Smirnov Signed-off-by: Dave Kleikamp Signed-off-by: Greg Kroah-Hartman commit 0beddc2a3f9b9cf7d8887973041e36c2d0fa3652 Author: Qasim Ijaz Date: Thu Feb 13 21:05:53 2025 +0000 jfs: fix slab-out-of-bounds read in ea_get() commit fdf480da5837c23b146c4743c18de97202fcab37 upstream. During the "size_check" label in ea_get(), the code checks if the extended attribute list (xattr) size matches ea_size. If not, it logs "ea_get: invalid extended attribute" and calls print_hex_dump(). Here, EALIST_SIZE(ea_buf->xattr) returns 4110417968, which exceeds INT_MAX (2,147,483,647). Then ea_size is clamped: int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr)); Although clamp_t aims to bound ea_size between 0 and 4110417968, the upper limit is treated as an int, causing an overflow above 2^31 - 1. This leads "size" to wrap around and become negative (-184549328). The "size" is then passed to print_hex_dump() (called "len" in print_hex_dump()), it is passed as type size_t (an unsigned type), this is then stored inside a variable called "int remaining", which is then assigned to "int linelen" which is then passed to hex_dump_to_buffer(). In print_hex_dump() the for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hex_dump_to_buffer() on each iteration: for (i = 0; i < len; i += rowsize) { linelen = min(remaining, rowsize); remaining -= rowsize; hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize, linebuf, sizeof(linebuf), ascii); ... } The expected stopping condition (i < len) is effectively broken since len is corrupted and very large. This eventually leads to the "ptr+i" being passed to hex_dump_to_buffer() to get closer to the end of the actual bounds of "ptr", eventually an out of bounds access is done in hex_dump_to_buffer() in the following for loop: for (j = 0; j < len; j++) { if (linebuflen < lx + 2) goto overflow2; ch = ptr[j]; ... } To fix this we should validate "EALIST_SIZE(ea_buf->xattr)" before it is utilised. Reported-by: syzbot Tested-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=4e6e7e4279d046613bc5 Fixes: d9f9d96136cb ("jfs: xattr: check invalid xattr size more strictly") Cc: stable@vger.kernel.org Signed-off-by: Qasim Ijaz Signed-off-by: Dave Kleikamp Signed-off-by: Greg Kroah-Hartman commit b47584c556444cf7acb66b26a62cbc348eb92b78 Author: Acs, Jakub Date: Thu Mar 20 15:46:49 2025 +0000 ext4: fix OOB read when checking dotdot dir commit d5e206778e96e8667d3bde695ad372c296dc9353 upstream. Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed). ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block. If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access. Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero). Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read. This issue was found by syzkaller tool. Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: ac27a0ec112a0 ("[PATCH] ext4: initial copy of files from ext3") Signed-off-by: Jakub Acs Cc: Theodore Ts'o Cc: Andreas Dilger Cc: linux-ext4@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Mahmoud Adam Cc: stable@vger.kernel.org Cc: security@kernel.org Link: https://patch.msgid.link/b3ae36a6794c4a01944c7d70b403db5b@amazon.de Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 13d6f8ba5074a030f6b972a8af4b056ce03f816b Author: Theodore Ts'o Date: Fri Mar 14 00:38:42 2025 -0400 ext4: don't over-report free space or inodes in statvfs commit f87d3af7419307ae26e705a2b2db36140db367a2 upstream. This fixes an analogus bug that was fixed in xfs in commit 4b8d867ca6e2 ("xfs: don't over-report free space or inodes in statvfs") where statfs can report misleading / incorrect information where project quota is enabled, and the free space is less than the remaining quota. This commit will resolve a test failure in generic/762 which tests for this bug. Cc: stable@kernel.org Fixes: 689c958cbe6b ("ext4: add project quota support") Signed-off-by: Theodore Ts'o Reviewed-by: "Darrick J. Wong" Signed-off-by: Greg Kroah-Hartman commit 0cfea60966e4b1239d20bebf02258295e189e82a Author: Ming Yen Hsieh Date: Tue Feb 18 11:33:42 2025 +0800 wifi: mt76: mt7921: fix kernel panic due to null pointer dereference commit adc3fd2a2277b7cc0b61692463771bf9bd298036 upstream. Address a kernel panic caused by a null pointer dereference in the `mt792x_rx_get_wcid` function. The issue arises because the `deflink` structure is not properly initialized with the `sta` context. This patch ensures that the `deflink` structure is correctly linked to the `sta` context, preventing the null pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000400 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 UID: 0 PID: 470 Comm: mt76-usb-rx phy Not tainted 6.12.13-gentoo-dist #1 Hardware name: /AMD HUDSON-M1, BIOS 4.6.4 11/15/2011 RIP: 0010:mt792x_rx_get_wcid+0x48/0x140 [mt792x_lib] RSP: 0018:ffffa147c055fd98 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff8e9ecb652000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8e9ecb652000 RBP: 0000000000000685 R08: ffff8e9ec6570000 R09: 0000000000000000 R10: ffff8e9ecd2ca000 R11: ffff8e9f22a217c0 R12: 0000000038010119 R13: 0000000080843801 R14: ffff8e9ec6570000 R15: ffff8e9ecb652000 FS: 0000000000000000(0000) GS:ffff8e9f22a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000400 CR3: 000000000d2ea000 CR4: 00000000000006f0 Call Trace: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? mt792x_rx_get_wcid+0x48/0x140 [mt792x_lib] mt7921_queue_rx_skb+0x1c6/0xaa0 [mt7921_common] mt76u_alloc_queues+0x784/0x810 [mt76_usb] ? __pfx___mt76_worker_fn+0x10/0x10 [mt76] __mt76_worker_fn+0x4f/0x80 [mt76] kthread+0xd2/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Reported-by: Nick Morrow Closes: https://github.com/morrownr/USB-WiFi/issues/577 Cc: stable@vger.kernel.org Fixes: 90c10286b176 ("wifi: mt76: mt7925: Update mt792x_rx_get_wcid for per-link STA") Signed-off-by: Ming Yen Hsieh Tested-by: Salah Coronya Link: https://patch.msgid.link/20250218033343.1999648-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 2df8ee605eb6806cd41c2095306db05206633a08 Author: Angelos Oikonomopoulos Date: Tue Apr 1 10:51:50 2025 +0200 arm64: Don't call NULL in do_compat_alignment_fixup() commit c28f31deeacda307acfee2f18c0ad904e5123aac upstream. do_alignment_t32_to_handler() only fixes up alignment faults for specific instructions; it returns NULL otherwise (e.g. LDREX). When that's the case, signal to the caller that it needs to proceed with the regular alignment fault handling (i.e. SIGBUS). Without this patch, the kernel panics: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000006 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000 [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000 Internal error: Oops: 0000000086000006 [#1] SMP Modules linked in: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa> libcrc32c crc32c_generic raid0 multipath linear dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c> CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1 Debian 6.1.128-1 Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : do_compat_alignment_fixup+0xd8/0x3dc sp : ffff80000f973dd0 x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001 x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000 x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001 Call trace: 0x0 do_alignment_fault+0x40/0x50 do_mem_abort+0x4c/0xa0 el0_da+0x48/0xf0 el0t_32_sync_handler+0x110/0x140 el0t_32_sync+0x190/0x194 Code: bad PC value ---[ end trace 0000000000000000 ]--- Signed-off-by: Angelos Oikonomopoulos Fixes: 3fc24ef32d3b ("arm64: compat: Implement misalignment fixups for multiword loads") Cc: # 6.1.x Reviewed-by: Anshuman Khandual Link: https://lore.kernel.org/r/20250401085150.148313-1-angelos@igalia.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 2e877ff3492267def06dd50cb165dc9ab8838e7d Author: David Hildenbrand Date: Mon Feb 10 20:37:43 2025 +0100 mm/gup: reject FOLL_SPLIT_PMD with hugetlb VMAs commit 8977752c8056a6a094a279004a49722da15bace3 upstream. Patch series "mm: fixes for device-exclusive entries (hmm)", v2. Discussing the PageTail() call in make_device_exclusive_range() with Willy, I recently discovered [1] that device-exclusive handling does not properly work with THP, making the hmm-tests selftests fail if THPs are enabled on the system. Looking into more details, I found that hugetlb is not properly fenced, and I realized that something that was bugging me for longer -- how device-exclusive entries interact with mapcounts -- completely breaks migration/swapout/split/hwpoison handling of these folios while they have device-exclusive PTEs. The program below can be used to allocate 1 GiB worth of pages and making them device-exclusive on a kernel with CONFIG_TEST_HMM. Once they are device-exclusive, these folios cannot get swapped out (proc$pid/smaps_rollup will always indicate 1 GiB RSS no matter how much one forces memory reclaim), and when having a memory block onlined to ZONE_MOVABLE, trying to offline it will loop forever and complain about failed migration of a page that should be movable. # echo offline > /sys/devices/system/memory/memory136/state # echo online_movable > /sys/devices/system/memory/memory136/state # ./hmm-swap & ... wait until everything is device-exclusive # echo offline > /sys/devices/system/memory/memory136/state [ 285.193431][T14882] page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x7f20671f7 pfn:0x442b6a [ 285.196618][T14882] memcg:ffff888179298000 [ 285.198085][T14882] anon flags: 0x5fff0000002091c(referenced|uptodate| dirty|active|owner_2|swapbacked|node=1|zone=3|lastcpupid=0x7ff) [ 285.201734][T14882] raw: ... [ 285.204464][T14882] raw: ... [ 285.207196][T14882] page dumped because: migration failure [ 285.209072][T14882] page_owner tracks the page as allocated [ 285.210915][T14882] page last allocated via order 0, migratetype Movable, gfp_mask 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), id 14926, tgid 14926 (hmm-swap), ts 254506295376, free_ts 227402023774 [ 285.216765][T14882] post_alloc_hook+0x197/0x1b0 [ 285.218874][T14882] get_page_from_freelist+0x76e/0x3280 [ 285.220864][T14882] __alloc_frozen_pages_noprof+0x38e/0x2740 [ 285.223302][T14882] alloc_pages_mpol+0x1fc/0x540 [ 285.225130][T14882] folio_alloc_mpol_noprof+0x36/0x340 [ 285.227222][T14882] vma_alloc_folio_noprof+0xee/0x1a0 [ 285.229074][T14882] __handle_mm_fault+0x2b38/0x56a0 [ 285.230822][T14882] handle_mm_fault+0x368/0x9f0 ... This series fixes all issues I found so far. There is no easy way to fix without a bigger rework/cleanup. I have a bunch of cleanups on top (some previous sent, some the result of the discussion in v1) that I will send out separately once this landed and I get to it. I wish we could just use some special present PROT_NONE PTEs instead of these (non-present, non-none) fake-swap entries; but that just results in the same problem we keep having (lack of spare PTE bits), and staring at other similar fake-swap entries, that ship has sailed. With this series, make_device_exclusive() doesn't actually belong into mm/rmap.c anymore, but I'll leave moving that for another day. I only tested this series with the hmm-tests selftests due to lack of HW, so I'd appreciate some testing, especially if the interaction between two GPUs wanting a device-exclusive entry works as expected. #include #include #include #include #include #include #include #include #include #include #define HMM_DMIRROR_EXCLUSIVE _IOWR('H', 0x05, struct hmm_dmirror_cmd) struct hmm_dmirror_cmd { __u64 addr; __u64 ptr; __u64 npages; __u64 cpages; __u64 faults; }; const size_t size = 1 * 1024 * 1024 * 1024ul; const size_t chunk_size = 2 * 1024 * 1024ul; int main(void) { struct hmm_dmirror_cmd cmd; size_t cur_size; int fd, ret; char *addr, *mirror; fd = open("/dev/hmm_dmirror1", O_RDWR, 0); if (fd < 0) { perror("open failed\n"); exit(1); } addr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (addr == MAP_FAILED) { perror("mmap failed\n"); exit(1); } madvise(addr, size, MADV_NOHUGEPAGE); memset(addr, 1, size); mirror = malloc(chunk_size); for (cur_size = 0; cur_size < size; cur_size += chunk_size) { cmd.addr = (uintptr_t)addr + cur_size; cmd.ptr = (uintptr_t)mirror; cmd.npages = chunk_size / getpagesize(); ret = ioctl(fd, HMM_DMIRROR_EXCLUSIVE, &cmd); if (ret) { perror("ioctl failed\n"); exit(1); } } pause(); return 0; } [1] https://lkml.kernel.org/r/25e02685-4f1d-47fa-be5b-01ff85bb0ce2@redhat.com This patch (of 17): We only have two FOLL_SPLIT_PMD users. While uprobe refuses hugetlb early, make_device_exclusive_range() can end up getting called on hugetlb VMAs. Right now, this means that with a PMD-sized hugetlb page, we can end up calling split_huge_pmd(), because pmd_trans_huge() also succeeds with hugetlb PMDs. For example, using a modified hmm-test selftest one can trigger: [ 207.017134][T14945] ------------[ cut here ]------------ [ 207.018614][T14945] kernel BUG at mm/page_table_check.c:87! [ 207.019716][T14945] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 207.021072][T14945] CPU: 3 UID: 0 PID: ... [ 207.023036][T14945] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 207.024834][T14945] RIP: 0010:page_table_check_clear.part.0+0x488/0x510 [ 207.026128][T14945] Code: ... [ 207.029965][T14945] RSP: 0018:ffffc9000cb8f348 EFLAGS: 00010293 [ 207.031139][T14945] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: ffffffff8249a0cd [ 207.032649][T14945] RDX: ffff88811e883c80 RSI: ffffffff8249a357 RDI: ffff88811e883c80 [ 207.034183][T14945] RBP: ffff888105c0a050 R08: 0000000000000005 R09: 0000000000000000 [ 207.035688][T14945] R10: 00000000ffffffff R11: 0000000000000003 R12: 0000000000000001 [ 207.037203][T14945] R13: 0000000000000200 R14: 0000000000000001 R15: dffffc0000000000 [ 207.038711][T14945] FS: 00007f2783275740(0000) GS:ffff8881f4980000(0000) knlGS:0000000000000000 [ 207.040407][T14945] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 207.041660][T14945] CR2: 00007f2782c00000 CR3: 0000000132356000 CR4: 0000000000750ef0 [ 207.043196][T14945] PKRU: 55555554 [ 207.043880][T14945] Call Trace: [ 207.044506][T14945] [ 207.045086][T14945] ? __die+0x51/0x92 [ 207.045864][T14945] ? die+0x29/0x50 [ 207.046596][T14945] ? do_trap+0x250/0x320 [ 207.047430][T14945] ? do_error_trap+0xe7/0x220 [ 207.048346][T14945] ? page_table_check_clear.part.0+0x488/0x510 [ 207.049535][T14945] ? handle_invalid_op+0x34/0x40 [ 207.050494][T14945] ? page_table_check_clear.part.0+0x488/0x510 [ 207.051681][T14945] ? exc_invalid_op+0x2e/0x50 [ 207.052589][T14945] ? asm_exc_invalid_op+0x1a/0x20 [ 207.053596][T14945] ? page_table_check_clear.part.0+0x1fd/0x510 [ 207.054790][T14945] ? page_table_check_clear.part.0+0x487/0x510 [ 207.055993][T14945] ? page_table_check_clear.part.0+0x488/0x510 [ 207.057195][T14945] ? page_table_check_clear.part.0+0x487/0x510 [ 207.058384][T14945] __page_table_check_pmd_clear+0x34b/0x5a0 [ 207.059524][T14945] ? __pfx___page_table_check_pmd_clear+0x10/0x10 [ 207.060775][T14945] ? __pfx___mutex_unlock_slowpath+0x10/0x10 [ 207.061940][T14945] ? __pfx___lock_acquire+0x10/0x10 [ 207.062967][T14945] pmdp_huge_clear_flush+0x279/0x360 [ 207.064024][T14945] split_huge_pmd_locked+0x82b/0x3750 ... Before commit 9cb28da54643 ("mm/gup: handle hugetlb in the generic follow_page_mask code"), we would have ignored the flag; instead, let's simply refuse the combination completely in check_vma_flags(): the caller is likely not prepared to handle any hugetlb folios. We'll teach make_device_exclusive_range() separately to ignore any hugetlb folios as a future-proof safety net. Link: https://lkml.kernel.org/r/20250210193801.781278-1-david@redhat.com Link: https://lkml.kernel.org/r/20250210193801.781278-2-david@redhat.com Fixes: 9cb28da54643 ("mm/gup: handle hugetlb in the generic follow_page_mask code") Signed-off-by: David Hildenbrand Reviewed-by: John Hubbard Reviewed-by: Alistair Popple Tested-by: Alistair Popple Cc: Alex Shi Cc: Danilo Krummrich Cc: Dave Airlie Cc: Jann Horn Cc: Jason Gunthorpe Cc: Jerome Glisse Cc: Jonathan Corbet Cc: Karol Herbst Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Lyude Cc: "Masami Hiramatsu (Google)" Cc: Oleg Nesterov Cc: Pasha Tatashin Cc: Peter Xu Cc: Peter Zijlstra (Intel) Cc: SeongJae Park Cc: Vlastimil Babka Cc: Yanteng Si Cc: Simona Vetter Cc: Barry Song Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 1abca855ea9f9f45a8980c8c3c11f6ad39ef6cb0 Author: Ran Xiaokai Date: Fri Mar 21 09:52:49 2025 +0000 tracing/osnoise: Fix possible recursive locking for cpus_read_lock() commit 7e6b3fcc9c5294aeafed0dbe1a09a1bc899bd0f2 upstream. Lockdep reports this deadlock log: osnoise: could not start sampling thread ============================================ WARNING: possible recursive locking detected -------------------------------------------- CPU0 ---- lock(cpu_hotplug_lock); lock(cpu_hotplug_lock); Call Trace: print_deadlock_bug+0x282/0x3c0 __lock_acquire+0x1610/0x29a0 lock_acquire+0xcb/0x2d0 cpus_read_lock+0x49/0x120 stop_per_cpu_kthreads+0x7/0x60 start_kthread+0x103/0x120 osnoise_hotplug_workfn+0x5e/0x90 process_one_work+0x44f/0xb30 worker_thread+0x33e/0x5e0 kthread+0x206/0x3b0 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 This is the deadlock scenario: osnoise_hotplug_workfn() guard(cpus_read_lock)(); // first lock call start_kthread(cpu) if (IS_ERR(kthread)) { stop_per_cpu_kthreads(); { cpus_read_lock(); // second lock call. Cause the AA deadlock } } It is not necessary to call stop_per_cpu_kthreads() which stops osnoise kthread for every other CPUs in the system if a failure occurs during hotplug of a certain CPU. For start_per_cpu_kthreads(), if the start_kthread() call fails, this function calls stop_per_cpu_kthreads() to handle the error. Therefore, similarly, there is no need to call stop_per_cpu_kthreads() again within start_kthread(). So just remove stop_per_cpu_kthreads() from start_kthread to solve this issue. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20250321095249.2739397-1-ranxiaokai627@163.com Fixes: c8895e271f79 ("trace/osnoise: Support hotplug operations") Signed-off-by: Ran Xiaokai Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 33052e7f52c56b41bd07f5c9a25dab3177cb4c97 Author: Douglas Raillard Date: Tue Mar 25 16:52:02 2025 +0000 tracing: Fix synth event printk format for str fields commit 4d38328eb442dc06aec4350fd9594ffa6488af02 upstream. The printk format for synth event uses "%.*s" to print string fields, but then only passes the pointer part as var arg. Replace %.*s with %s as the C string is guaranteed to be null-terminated. The output in print fmt should never have been updated as __get_str() handles the string limit because it can access the length of the string in the string meta data that is saved in the ring buffer. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Fixes: 8db4d6bfbbf92 ("tracing: Change synthetic event string format to limit printed length") Link: https://lore.kernel.org/20250325165202.541088-1-douglas.raillard@arm.com Signed-off-by: Douglas Raillard Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit cffc2a6718e43ef4219bf3c5017146b9090e4a45 Author: Douglas Raillard Date: Tue Mar 18 18:09:05 2025 +0000 tracing: Ensure module defining synth event cannot be unloaded while tracing commit 21581dd4e7ff6c07d0ab577e3c32b13a74b31522 upstream. Currently, using synth_event_delete() will fail if the event is being used (tracing in progress), but that is normally done in the module exit function. At that stage, failing is problematic as returning a non-zero status means the module will become locked (impossible to unload or reload again). Instead, ensure the module exit function does not get called in the first place by increasing the module refcnt when the event is enabled. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Fixes: 35ca5207c2d11 ("tracing: Add synthetic event command generation functions") Link: https://lore.kernel.org/20250318180906.226841-1-douglas.raillard@arm.com Signed-off-by: Douglas Raillard Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit c85efe6e13743cac6ba4ccf144cb91f44c86231a Author: Tengda Wu Date: Thu Mar 20 12:21:37 2025 +0000 tracing: Fix use-after-free in print_graph_function_flags during tracer switching commit 7f81f27b1093e4895e87b74143c59c055c3b1906 upstream. Kairui reported a UAF issue in print_graph_function_flags() during ftrace stress testing [1]. This issue can be reproduced if puting a 'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(), and executing the following script: $ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracer The root cause lies in the two calls to print_graph_function_flags within print_trace_line during each s_show(): * One through 'iter->trace->print_line()'; * Another through 'event->funcs->trace()', which is hidden in print_trace_fmt() before print_trace_line returns. Tracer switching only updates the former, while the latter continues to use the print_line function of the old tracer, which in the script above is print_graph_function_flags. Moreover, when switching from the 'function_graph' tracer to the 'timerlat' tracer, s_start only calls graph_trace_close of the 'function_graph' tracer to free 'iter->private', but does not set it to NULL. This provides an opportunity for 'event->funcs->trace()' to use an invalid 'iter->private'. To fix this issue, set 'iter->private' to NULL immediately after freeing it in graph_trace_close(), ensuring that an invalid pointer is not passed to other tracers. Additionally, clean up the unnecessary 'iter->private = NULL' during each 'cat trace' when using wakeup and irqsoff tracers. [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/ Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Zheng Yejian Link: https://lore.kernel.org/20250320122137.23635-1-wutengda@huaweicloud.com Fixes: eecb91b9f98d ("tracing: Fix memleak due to race between current_tracer and trace") Closes: https://lore.kernel.org/all/CAMgjq7BW79KDSCyp+tZHjShSzHsScSiJxn5ffskp-QzVM06fxw@mail.gmail.com/ Reported-by: Kairui Song Signed-off-by: Tengda Wu Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 37c9875c178f1503af1864aadc29c42e7cb4374a Author: Sungjong Seo Date: Wed Mar 26 23:48:48 2025 +0900 exfat: fix potential wrong error return from get_block commit 59c30e31425833385e6644ad33151420e37eabe1 upstream. If there is no error, get_block() should return 0. However, when bh_read() returns 1, get_block() also returns 1 in the same manner. Let's set err to 0, if there is no error from bh_read() Fixes: 11a347fb6cef ("exfat: change to get file size from DataLength") Cc: stable@vger.kernel.org Signed-off-by: Sungjong Seo Reviewed-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 49b0a6ab8e528a0c1c50e37cef9b9c7c121365f2 Author: Sungjong Seo Date: Fri Mar 21 15:34:42 2025 +0900 exfat: fix random stack corruption after get_block commit 1bb7ff4204b6d4927e982cd256286c09ed4fd8ca upstream. When get_block is called with a buffer_head allocated on the stack, such as do_mpage_readpage, stack corruption due to buffer_head UAF may occur in the following race condition situation. mpage_read_folio <> do_mpage_readpage exfat_get_block bh_read __bh_read get_bh(bh) submit_bh wait_on_buffer ... end_buffer_read_sync __end_buffer_read_notouch unlock_buffer <> ... ... ... ... <> . . another_function <> put_bh(bh) atomic_dec(bh->b_count) * stack corruption here * This patch returns -EAGAIN if a folio does not have buffers when bh_read needs to be called. By doing this, the caller can fallback to functions like block_read_full_folio(), create a buffer_head in the folio, and then call get_block again. Let's do not call bh_read() with on-stack buffer_head. Fixes: 11a347fb6cef ("exfat: change to get file size from DataLength") Cc: stable@vger.kernel.org Tested-by: Yeongjin Gil Signed-off-by: Sungjong Seo Reviewed-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit ca8bed31edf728a662ef9d6f39f50e7a7dc2b5ad Author: Namjae Jeon Date: Wed Apr 2 09:11:23 2025 +0900 ksmbd: fix null pointer dereference in alloc_preauth_hash() commit c8b5b7c5da7d0c31c9b7190b4a7bba5281fc4780 upstream. The Client send malformed smb2 negotiate request. ksmbd return error response. Subsequently, the client can send smb2 session setup even thought conn->preauth_info is not allocated. This patch add KSMBD_SESS_NEED_SETUP status of connection to ignore session setup request if smb2 negotiate phase is not complete. Cc: stable@vger.kernel.org Tested-by: Steve French Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-26505 Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 56de7778a48560278c334077ace7b9ac4bfb2fd1 Author: Norbert Szetei Date: Sat Mar 29 16:06:01 2025 +0000 ksmbd: validate zero num_subauth before sub_auth is accessed commit bf21e29d78cd2c2371023953d9c82dfef82ebb36 upstream. Access psid->sub_auth[psid->num_subauth - 1] without checking if num_subauth is non-zero leads to an out-of-bounds read. This patch adds a validation step to ensure num_subauth != 0 before sub_auth is accessed. Cc: stable@vger.kernel.org Signed-off-by: Norbert Szetei Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6a9cd9ff0fa2bcc30b2bfb8bdb161eb20e44b9dc Author: Norbert Szetei Date: Sat Mar 29 06:58:15 2025 +0000 ksmbd: fix overflow in dacloffset bounds check commit beff0bc9d69bc8e733f9bca28e2d3df5b3e10e42 upstream. The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl(). This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer. This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL. Cc: stable@vger.kernel.org Signed-off-by: Norbert Szetei Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 9069939d762138e232a6f79e3e1462682ed6a17d Author: Namjae Jeon Date: Thu Mar 27 21:22:51 2025 +0900 ksmbd: fix session use-after-free in multichannel connection commit fa4cdb8cbca7d6cb6aa13e4d8d83d1103f6345db upstream. There is a race condition between session setup and ksmbd_sessions_deregister. The session can be freed before the connection is added to channel list of session. This patch check reference count of session before freeing it. Cc: stable@vger.kernel.org Reported-by: Sean Heelan Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit ca042cc0e4f9e0d2c8f86dd67e4b22f30a516a9b Author: Namjae Jeon Date: Sat Mar 22 09:20:19 2025 +0900 ksmbd: fix use-after-free in ksmbd_sessions_deregister() commit 15a9605f8d69dc85005b1a00c31a050b8625e1aa upstream. In multichannel mode, UAF issue can occur in session_deregister when the second channel sets up a session through the connection of the first channel. session that is freed through the global session table can be accessed again through ->sessions of connection. Cc: stable@vger.kernel.org Reported-by: Norbert Szetei Tested-by: Norbert Szetei Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 800c482c9ef5910f05e3a713943c67cc6c1d4939 Author: Norbert Szetei Date: Sat Mar 15 12:19:28 2025 +0900 ksmbd: add bounds check for create lease context commit bab703ed8472aa9d109c5f8c1863921533363dae upstream. Add missing bounds check for create lease context. Cc: stable@vger.kernel.org Reported-by: Norbert Szetei Tested-by: Norbert Szetei Signed-off-by: Norbert Szetei Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 29b946714d6aa77de54c71243bba39469ac43ef2 Author: Namjae Jeon Date: Fri Mar 14 18:21:47 2025 +0900 ksmbd: add bounds check for durable handle context commit 542027e123fc0bfd61dd59e21ae0ee4ef2101b29 upstream. Add missing bounds check for durable handle context. Cc: stable@vger.kernel.org Reported-by: Norbert Szetei Tested-by: Norbert Szetei Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 9bc3299039d2c10d4fff7650ac17e415e87a862c Author: Sean Christopherson Date: Wed Feb 26 17:25:35 2025 -0800 KVM: SVM: Don't change target vCPU state on AP Creation VMGEXIT error commit d26638bfcdfc5c8c4e085dc3f5976a0443abab3c upstream. If KVM rejects an AP Creation event, leave the target vCPU state as-is. Nothing in the GHCB suggests the hypervisor is *allowed* to muck with vCPU state on failure, let alone required to do so. Furthermore, kicking only in the !ON_INIT case leads to divergent behavior, and even the "kick" case is non-deterministic. E.g. if an ON_INIT request fails, the guest can successfully retry if the fixed AP Creation request is made prior to sending INIT. And if a !ON_INIT fails, the guest can successfully retry if the fixed AP Creation request is handled before the target vCPU processes KVM's KVM_REQ_UPDATE_PROTECTED_GUEST_STATE. Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Cc: stable@vger.kernel.org Reviewed-by: Tom Lendacky Reviewed-by: Pankaj Gupta Link: https://lore.kernel.org/r/20250227012541.3234589-5-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit a31fa24813a770dc3389e5174a7757e74b96ac0f Author: Ulf Hansson Date: Wed Mar 12 13:17:12 2025 +0100 mmc: sdhci-omap: Disable MMC_CAP_AGGRESSIVE_PM for eMMC/SD commit 49d162635151d0dd04935070d7cf67137ab863aa upstream. We have received reports about cards can become corrupt related to the aggressive PM support. Let's make a partial revert of the change that enabled the feature. Reported-by: David Owens Reported-by: Romain Naour Reported-by: Robert Nelson Tested-by: Robert Nelson Fixes: 3edf588e7fe0 ("mmc: sdhci-omap: Allow SDIO card power off and enable aggressive PM") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Acked-by: Adrian Hunter Reviewed-by: Tony Lindgren Link: https://lore.kernel.org/r/20250312121712.1168007-1-ulf.hansson@linaro.org Signed-off-by: Greg Kroah-Hartman commit 1209241a6b40c8fff985a32fcaa75e174d37ff5f Author: Karel Balej Date: Mon Mar 10 15:07:04 2025 +0100 mmc: sdhci-pxav3: set NEED_RSP_BUSY capability commit a41fcca4b342811b473bbaa4b44f1d34d87fcce6 upstream. Set the MMC_CAP_NEED_RSP_BUSY capability for the sdhci-pxav3 host to prevent conversion of R1B responses to R1. Without this, the eMMC card in the samsung,coreprimevelte smartphone using the Marvell PXA1908 SoC with this mmc host doesn't probe with the ETIMEDOUT error originating in __mmc_poll_for_busy. Note that the other issues reported for this phone and host, namely floods of "Tuning failed, falling back to fixed sampling clock" dmesg messages for the eMMC and unstable SDIO are not mitigated by this change. Link: https://lore.kernel.org/r/20200310153340.5593-1-ulf.hansson@linaro.org/ Link: https://lore.kernel.org/r/D7204PWIGQGI.1FRFQPPIEE2P9@matfyz.cz/ Link: https://lore.kernel.org/r/20250115-pxa1908-lkml-v14-0-847d24f3665a@skole.hr/ Cc: stable@vger.kernel.org Signed-off-by: Karel Balej Acked-by: Adrian Hunter Tested-by: Duje Mihanović Link: https://lore.kernel.org/r/20250310140707.23459-1-balejk@matfyz.cz Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit b548a448993ac2b8cb0ec64e9353cfdf6d2f79a9 Author: Miaoqian Lin Date: Tue Mar 18 22:02:25 2025 +0800 mmc: omap: Fix memory leak in mmc_omap_new_slot commit 3834a759afb817e23a7a2f09c2c9911b0ce5c588 upstream. Add err_free_host label to properly pair mmc_alloc_host() with mmc_free_host() in GPIO error paths. The allocated host memory was leaked when GPIO lookups failed. Fixes: e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors") Signed-off-by: Miaoqian Lin Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250318140226.19650-1-linmq006@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 0c121f2065e44ae055e2661f05b4cfe6f6d6c500 Author: Candice Li Date: Wed Mar 26 13:41:01 2025 +0800 Remove unnecessary firmware version check for gc v9_4_2 commit 5b3c08ae9ed324743f5f7286940d45caeb656e6e upstream. GC v9_4_2 uses a new versioning scheme for CP firmware, making the warning ("CP firmware version too old, please update!") irrelevant. Signed-off-by: Candice Li Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6b9ddc4f5f2e2698ac83e9d0824c0c91d7bb447c Author: Robin Murphy Date: Mon Oct 28 17:58:36 2024 +0000 media: omap3isp: Handle ARM dma_iommu_mapping commit 6bc076eec6f85f778f33a8242b438e1bd9fcdd59 upstream. It's no longer practical for the OMAP IOMMU driver to trick arm_setup_iommu_dma_ops() into ignoring its presence, so let's use the same tactic as other IOMMU API users on 32-bit ARM and explicitly kick the arch code's dma_iommu_mapping out of the way to avoid problems. Fixes: 4720287c7bf7 ("iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()") Cc: stable@vger.kernel.org Signed-off-by: Robin Murphy Tested-by: Sicelo A. Mhlongo Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9f7ae45f0c615d0c26ce6d42f712f525764699ed Author: Christian Eggers Date: Thu Mar 20 22:33:51 2025 +0100 ARM: 9444/1: add KEEP() keyword to ARM_VECTORS commit c3d944a367c0d9e4e125c7006e52f352e75776dc upstream. Without this, the vectors are removed if LD_DEAD_CODE_DATA_ELIMINATION is enabled. At startup, the CPU (silently) hangs in the undefined instruction exception as soon as the first timer interrupt arrives. On my setup, the system also boots fine without the 2nd and 3rd KEEP() statements, so I cannot tell whether these are actually required. [nathan: Use OVERLAY_KEEP() to avoid breaking old ld.lld versions] Cc: stable@vger.kernel.org Fixes: ed0f94102251 ("ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION") Signed-off-by: Christian Eggers Reviewed-by: Linus Walleij Signed-off-by: Nathan Chancellor Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit 498edda23f7e643ad2b100e47c3257ac21a83a47 Author: Paul Menzel Date: Tue Mar 18 17:09:02 2025 +0100 ACPI: resource: Skip IRQ override on ASUS Vivobook 14 X1404VAP commit 2da31ea2a085cd189857f2db0f7b78d0162db87a upstream. Like the ASUS Vivobook X1504VAP and Vivobook X1704VAP, the ASUS Vivobook 14 X1404VAP has its keyboard IRQ (1) described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh breaking the keyboard. $ sudo dmidecode […] System Information Manufacturer: ASUSTeK COMPUTER INC. Product Name: ASUS Vivobook 14 X1404VAP_X1404VA […] $ grep -A 30 PS2K dsdt.dsl | grep IRQ -A 1 IRQ (Level, ActiveLow, Exclusive, ) {1} Add the X1404VAP to the irq1_level_low_skip_override[] quirk table to fix this. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219224 Cc: All applicable Signed-off-by: Paul Menzel Reviewed-by: Hans de Goede Tested-by: Anton Shyndin Link: https://patch.msgid.link/20250318160903.77107-1-pmenzel@molgen.mpg.de Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit e71a57c5aaa389d4c3c82f920761262efdd18d38 Author: Murad Masimov Date: Thu Jan 23 19:39:45 2025 +0300 acpi: nfit: fix narrowing conversion in acpi_nfit_ctl commit 2ff0e408db36c21ed3fa5e3c1e0e687c82cf132f upstream. Syzkaller has reported a warning in to_nfit_bus_uuid(): "only secondary bus families can be translated". This warning is emited if the argument is equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() first verifies that a user-provided value call_pkg->nd_family of type u64 is not equal to 0. Then the value is converted to int, and only after that is compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalid argument to acpi_nfit_ctl(), if call_pkg->nd_family is non-zero, while the lower 32 bits are zero. Furthermore, it is best to return EINVAL immediately upon seeing the invalid user input. The WARNING is insufficient to prevent further undefined behavior based on other invalid user input. All checks of the input value should be applied to the original variable call_pkg->nd_family. [iweiny: update commit message] Fixes: 6450ddbd5d8e ("ACPI: NFIT: Define runtime firmware activation commands") Cc: stable@vger.kernel.org Reported-by: syzbot+c80d8dc0d9fa81a3cd8c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c80d8dc0d9fa81a3cd8c Signed-off-by: Murad Masimov Link: https://patch.msgid.link/20250123163945.251-1-m.masimov@mt-integration.ru Signed-off-by: Ira Weiny Signed-off-by: Greg Kroah-Hartman commit 339d6c965f207eecf273cf684677d27d9466e932 Author: Ming Yen Hsieh Date: Tue Mar 4 19:36:47 2025 +0800 wifi: mt76: mt7925: remove unused acpi function for clc commit b4ea6fdfc08375aae59c7e7059653b9877171fe4 upstream. The code for handling ACPI configuration in CLC was copied from the mt7921 driver but is not utilized in the mt7925 implementation. So removes the unused functionality to clean up the codebase. Cc: stable@vger.kernel.org Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250304113649.867387-4-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 93224deb50a8d20df3884f3672ce9f982129aa50 Author: Jann Horn Date: Fri Jan 3 19:39:38 2025 +0100 x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs commit 3ef938c3503563bfc2ac15083557f880d29c2e64 upstream. On the following path, flush_tlb_range() can be used for zapping normal PMD entries (PMD entries that point to page tables) together with the PTE entries in the pointed-to page table: collapse_pte_mapped_thp pmdp_collapse_flush flush_tlb_range The arm64 version of flush_tlb_range() has a comment describing that it can be used for page table removal, and does not use any last-level invalidation optimizations. Fix the X86 version by making it behave the same way. Currently, X86 only uses this information for the following two purposes, which I think means the issue doesn't have much impact: - In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be IPI'd to avoid issues with speculative page table walks. - In Hyper-V TLB paravirtualization, again for lazy TLB stuff. The patch "x86/mm: only invalidate final translations with INVLPGB" which is currently under review (see ) would probably be making the impact of this a lot worse. Fixes: 016c4d92cd16 ("x86/mm/tlb: Add freed_tables argument to flush_tlb_mm_range") Signed-off-by: Jann Horn Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20250103-x86-collapse-flush-fix-v1-1-3c521856cfa6@google.com Signed-off-by: Greg Kroah-Hartman commit 70a2fa13d4a9e782ee342354202fd4190e075108 Author: Guilherme G. Piccoli Date: Sat Feb 15 17:58:16 2025 -0300 x86/tsc: Always save/restore TSC sched_clock() on suspend/resume commit d90c9de9de2f1712df56de6e4f7d6982d358cabe upstream. TSC could be reset in deep ACPI sleep states, even with invariant TSC. That's the reason we have sched_clock() save/restore functions, to deal with this situation. But what happens is that such functions are guarded with a check for the stability of sched_clock - if not considered stable, the save/restore routines aren't executed. On top of that, we have a clear comment in native_sched_clock() saying that *even* with TSC unstable, we continue using TSC for sched_clock due to its speed. In other words, if we have a situation of TSC getting detected as unstable, it marks the sched_clock as unstable as well, so subsequent S3 sleep cycles could bring bogus sched_clock values due to the lack of the save/restore mechanism, causing warnings like this: [22.954918] ------------[ cut here ]------------ [22.954923] Delta way too big! 18446743750843854390 ts=18446744072977390405 before=322133536015 after=322133536015 write stamp=18446744072977390405 [22.954923] If you just came from a suspend/resume, [22.954923] please switch to the trace global clock: [22.954923] echo global > /sys/kernel/tracing/trace_clock [22.954923] or add trace_clock=global to the kernel command line [22.954937] WARNING: CPU: 2 PID: 5728 at kernel/trace/ring_buffer.c:2890 rb_add_timestamp+0x193/0x1c0 Notice that the above was reproduced even with "trace_clock=global". The fix for that is to _always_ save/restore the sched_clock on suspend cycle _if TSC is used_ as sched_clock - only if we fallback to jiffies the sched_clock_stable() check becomes relevant to save/restore the sched_clock. Debugged-by: Thadeu Lima de Souza Cascardo Signed-off-by: Guilherme G. Piccoli Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250215210314.351480-1-gpiccoli@igalia.com Signed-off-by: Greg Kroah-Hartman commit e3d54decc75c40ec76fff5b60ee6d4152e2bb22e Author: Arnd Bergmann Date: Wed Feb 26 22:37:05 2025 +0100 x86/Kconfig: Add cmpxchg8b support back to Geode CPUs commit 6ac43f2be982ea54b75206dccd33f4cf81bfdc39 upstream. An older cleanup of mine inadvertently removed geode-gx1 and geode-lx from the list of CPUs that are known to support a working cmpxchg8b. Fixes: 88a2b4edda3d ("x86/Kconfig: Rework CONFIG_X86_PAE dependency") Signed-off-by: Arnd Bergmann Signed-off-by: Ingo Molnar Cc: Linus Torvalds Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250226213714.4040853-2-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman commit e8bba7ced03ef9a8de546ba2f79945aa13a0e9e6 Author: Joe Damato Date: Fri Oct 4 10:54:07 2024 +0000 idpf: Don't hard code napi_struct size commit 49717ef01ce1b6dbe4cd12bee0fc25e086c555df upstream. The sizeof(struct napi_struct) can change. Don't hardcode the size to 400 bytes and instead use "sizeof(struct napi_struct)". Suggested-by: Alexander Lobakin Signed-off-by: Joe Damato Acked-by: Alexander Lobakin Link: https://patch.msgid.link/20241004105407.73585-1-jdamato@fastly.com Signed-off-by: Jakub Kicinski [Yifei: In Linux-6.12.y, it still hard code the size of napi_struct, adding a member will lead the entire build failed] Signed-off-by: Yifei Liu Signed-off-by: Greg Kroah-Hartman commit c35771342e47d58ab9433f3be1c3c30f2c5fa4f3 Author: Jiri Olsa Date: Wed Feb 12 23:04:33 2025 +0100 uprobes/x86: Harden uretprobe syscall trampoline check commit fa6192adc32f4fdfe5b74edd5b210e12afd6ecc0 upstream. Jann reported a possible issue when trampoline_check_ip returns address near the bottom of the address space that is allowed to call into the syscall if uretprobes are not set up: https://lore.kernel.org/bpf/202502081235.5A6F352985@keescook/T/#m9d416df341b8fbc11737dacbcd29f0054413cbbf Though the mmap minimum address restrictions will typically prevent creating mappings there, let's make sure uretprobe syscall checks for that. Fixes: ff474a78cef5 ("uprobe: Add uretprobe syscall to speed up return probe") Reported-by: Jann Horn Signed-off-by: Jiri Olsa Signed-off-by: Ingo Molnar Reviewed-by: Oleg Nesterov Reviewed-by: Kees Cook Acked-by: Andrii Nakryiko Acked-by: Masami Hiramatsu (Google) Acked-by: Alexei Starovoitov Cc: Andy Lutomirski Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250212220433.3624297-1-jolsa@kernel.org Signed-off-by: Greg Kroah-Hartman commit 3a8bec6583e5239de3bd597ab382dc6c2b0c29a1 Author: Kan Liang Date: Tue Jan 21 07:23:01 2025 -0800 perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read commit f9bdf1f953392c9edd69a7f884f78c0390127029 upstream. The WARN_ON(this_cpu_read(cpu_hw_events.enabled)) in the intel_pmu_save_and_restart_reload() is triggered, when sampling read topdown events. In a NMI handler, the cpu_hw_events.enabled is set and used to indicate the status of core PMU. The generic pmu->pmu_disable_count, updated in the perf_pmu_disable/enable pair, is not touched. However, the perf_pmu_disable/enable pair is invoked when sampling read in a NMI handler. The cpuc->enabled is mistakenly set by the perf_pmu_enable(). Avoid disabling PMU if the core PMU is already disabled. Merge the logic together. Fixes: 7b2c05a15d29 ("perf/x86/intel: Generic support for hardware TopDown metrics") Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20250121152303.3128733-2-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit e853bb7d6aec34d91dfae639254892bd5721fc7b Author: Peter Zijlstra (Intel) Date: Tue Jan 21 07:23:00 2025 -0800 perf/x86/intel: Apply static call for drain_pebs commit 314dfe10576912e1d786b13c5d4eee8c51b63caa upstream. The x86_pmu_drain_pebs static call was introduced in commit 7c9903c9bf71 ("x86/perf, static_call: Optimize x86_pmu methods"), but it's not really used to replace the old method. Apply the static call for drain_pebs. Fixes: 7c9903c9bf71 ("x86/perf, static_call: Optimize x86_pmu methods") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20250121152303.3128733-1-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 854b6764be33d0b37eb91acf7b8b89a1e45ee868 Author: Markus Elfring Date: Mon Sep 23 10:38:11 2024 +0200 ntb_perf: Delete duplicate dmaengine_unmap_put() call in perf_copy_chunk() commit 4279e72cab31dd3eb8c89591eb9d2affa90ab6aa upstream. The function call “dmaengine_unmap_put(unmap)” was used in an if branch. The same call was immediately triggered by a subsequent goto statement. Thus avoid such a call repetition. This issue was detected by using the Coccinelle software. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Cc: stable@vger.kernel.org Signed-off-by: Markus Elfring Signed-off-by: Jon Mason Signed-off-by: Greg Kroah-Hartman commit 1a85281415fbe6509a30c347d14214b63f990870 Author: Srinivas Pandruvada Date: Fri Mar 28 15:47:49 2025 -0700 platform/x86: ISST: Correct command storage data length commit 9462e74c5c983cce34019bfb27f734552bebe59f upstream. After resume/online turbo limit ratio (TRL) is restored partially if the admin explicitly changed TRL from user space. A hash table is used to store SST mail box and MSR settings when modified to restore those settings after resume or online. This uses a struct isst_cmd field "data" to store these settings. This is a 64 bit field. But isst_store_new_cmd() is only assigning as u32. This results in truncation of 32 bits. Change the argument to u64 from u32. Fixes: f607874f35cb ("platform/x86: ISST: Restore state on resume") Signed-off-by: Srinivas Pandruvada Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250328224749.2691272-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 48792ab445529e2d929035456051bb4fd9e42fbe Author: Eduard Christian Dumitrescu Date: Mon Mar 24 11:24:42 2025 -0400 platform/x86: thinkpad_acpi: disable ACPI fan access for T495* and E560 commit 2b9f84e7dc863afd63357b867cea246aeedda036 upstream. T495, T495s, and E560 laptops have the FANG+FANW ACPI methods (therefore fang_handle and fanw_handle are not NULL) but they do not actually work, which results in a "No such device or address" error. The DSDT table code for the FANG+FANW methods doesn't seem to do anything special regarding the fan being secondary. The bug was introduced in commit 57d0557dfa49 ("platform/x86: thinkpad_acpi: Add Thinkpad Edge E531 fan support"), which added a new fan control method via the FANG+FANW ACPI methods. Add a quirk for T495, T495s, and E560 to avoid the FANG+FANW methods. Fan access and control is restored after forcing the legacy non-ACPI fan control method by setting both fang_handle and fanw_handle to NULL. Reported-by: Vlastimil Holer Fixes: 57d0557dfa49 ("platform/x86: thinkpad_acpi: Add Thinkpad Edge E531 fan support") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219643 Cc: stable@vger.kernel.org Tested-by: Alireza Elikahi Reviewed-by: Kurt Borja Signed-off-by: Eduard Christian Dumitrescu Co-developed-by: Seyediman Seyedarab Signed-off-by: Seyediman Seyedarab Link: https://lore.kernel.org/r/20250324152442.106113-1-ImanDevel@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 35c1834dd630919e50414250fcc573d13bae2f78 Author: Hans de Goede Date: Tue Mar 25 22:04:50 2025 +0100 ACPI: x86: Extend Lenovo Yoga Tab 3 quirk with skip GPIO event-handlers commit 2fa87c71d2adb4b82c105f9191e6120340feff00 upstream. Depending on the secureboot signature on EFI\BOOT\BOOTX86.EFI the Lenovo Yoga Tab 3 UEFI will switch its OSID ACPI variable between 1 (Windows) and 4 (Android(GMIN)). In Windows mode a GPIO event handler gets installed for GPO1 pin 5, causing Linux' x86-android-tables code which deals with the general brokenness of this device's ACPI tables to fail to probe with: [ 17.853705] x86_android_tablets: error -16 getting GPIO INT33FF:01 5 [ 17.859623] x86_android_tablets x86_android_tablets: probe with driver which renders sound, the touchscreen, charging-management, battery-monitoring and more non functional. Add ACPI_QUIRK_SKIP_GPIO_EVENT_HANDLERS to the existing quirks for this device to fix this. Reported-by: Agoston Lorincz Closes: https://lore.kernel.org/platform-driver-x86/CAMEzqD+DNXrAvUOHviB2O2bjtcbmo3xH=kunKr4nubuMLbb_0A@mail.gmail.com/ Cc: All applicable Fixes: fe820db35275 ("ACPI: x86: Add skip i2c clients quirk for Lenovo Yoga Tab 3 Pro (YT3-X90F)") Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20250325210450.358506-1-hdegoede@redhat.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 805e3ce5e0e32b31dcecc0774c57c17a1f13cef6 Author: Vishal Annapurve Date: Fri Feb 28 01:44:15 2025 +0000 x86/tdx: Fix arch_safe_halt() execution for TDX VMs commit 9f98a4f4e7216dbe366010b4cdcab6b220f229c4 upstream. Direct HLT instruction execution causes #VEs for TDX VMs which is routed to hypervisor via TDCALL. If HLT is executed in STI-shadow, resulting #VE handler will enable interrupts before TDCALL is routed to hypervisor leading to missed wakeup events, as current TDX spec doesn't expose interruptibility state information to allow #VE handler to selectively enable interrupts. Commit bfe6ed0c6727 ("x86/tdx: Add HLT support for TDX guests") prevented the idle routines from executing HLT instruction in STI-shadow. But it missed the paravirt routine which can be reached via this path as an example: kvm_wait() => safe_halt() => raw_safe_halt() => arch_safe_halt() => irq.safe_halt() => pv_native_safe_halt() To reliably handle arch_safe_halt() for TDX VMs, introduce explicit dependency on CONFIG_PARAVIRT and override paravirt halt()/safe_halt() routines with TDX-safe versions that execute direct TDCALL and needed interrupt flag updates. Executing direct TDCALL brings in additional benefit of avoiding HLT related #VEs altogether. As tested by Ryan Afranji: "Tested with the specjbb2015 benchmark. It has heavy lock contention which leads to many halt calls. TDX VMs suffered a poor score before this patchset. Verified the major performance improvement with this patchset applied." Fixes: bfe6ed0c6727 ("x86/tdx: Add HLT support for TDX guests") Signed-off-by: Vishal Annapurve Signed-off-by: Ingo Molnar Reviewed-by: Kirill A. Shutemov Tested-by: Ryan Afranji Cc: Andy Lutomirski Cc: Brian Gerst Cc: Juergen Gross Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Josh Poimboeuf Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250228014416.3925664-3-vannapurve@google.com Signed-off-by: Greg Kroah-Hartman commit 3e3d8169c0950a0b3cd5105f6403a78350dcac80 Author: Shuai Xue Date: Wed Mar 12 19:28:50 2025 +0800 x86/mce: use is_copy_from_user() to determine copy-from-user context commit 1a15bb8303b6b104e78028b6c68f76a0d4562134 upstream. Patch series "mm/hwpoison: Fix regressions in memory failure handling", v4. ## 1. What am I trying to do: This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS. - copyin case: poison found in user page while kernel copying from user space - instr case: poison found while instruction fetching in user space ## 2. What is the expected outcome and why - For copyin case: Kernel can recover from poison found where kernel is doing get_user() or copy_from_user() if those places get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space. - For instr case: If a poison found while instruction fetching in user space, full recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from storage. ## 3. What actually happens and why - For copyin case: kernel panic since v5.17 Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS handling when posion found in get_user() or copy_from_user(). - For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE race When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed. ### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1] Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR. Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to #CMCI. Just to add to the confusion, Linux does take an action (in uc_decode_notifier()) to try to offline the page despite the UC*NA* signature name. ### Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1] Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a "real" read and a speculative read. So it will do CMCI/UCNA if an error is found in any read. Thus: 1) Core is clever and thinks address A is needed soon, issues a speculative read. 2) Core finds it is going to use address A soon after sending the read request 3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A. Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison). ## Why user process is killed for instr case Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not recovered"") tries to fix noise message "Memory error not recovered" and skips duplicate SIGBUSs due to the race. But it also introduced a bug that kill_accessing_process() return -EHWPOISON for instr case, as result, kill_me_maybe() send a SIGBUS to user process. # 4. The fix, in my opinion, should be: - For copyin case: The key point is whether the error context is in a read from user memory. We do not care about the ex-type if we know its a MOV reading from userspace. is_copy_from_user() return true when both of the following two checks are true: - the current instruction is copy - source address is user memory If copy_user is true, we set m->kflags |= MCE_IN_KERNEL_COPYIN | MCE_IN_KERNEL_RECOV; Then do_machine_check() will try fixup_exception() first. - For instr case: let kill_accessing_process() return 0 to prevent a SIGBUS. - For patch 3: The return value of memory_failure() is quite important while discussed instr case regression with Tony and Miaohe for patch 2, so add comment about the return value. This patch (of 3): Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EX_TYPE_EFAULT_REG, and commit 4c132d1d844a ("x86/futex: Remove .fixup usage") updated the extable fixup type for copy-from-user operations, changing it from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. The error context for copy-from-user operations no longer functions as an in-kernel recovery context. Consequently, the error context for copy-from-user operations no longer functions as an in-kernel recovery context, resulting in kernel panics with the message: "Machine check: Data load in unrecoverable area of kernel." To address this, it is crucial to identify if an error context involves a read operation from user memory. The function is_copy_from_user() can be utilized to determine: - the current operation is copy - when reading user memory When these conditions are met, is_copy_from_user() will return true, confirming that it is indeed a direct copy from user memory. This check is essential for correctly handling the context of errors in these operations without relying on the extable fixup types that previously allowed for in-kernel recovery. So, use is_copy_from_user() to determine if a context is copy user directly. Link: https://lkml.kernel.org/r/20250312112852.82415-1-xueshuai@linux.alibaba.com Link: https://lkml.kernel.org/r/20250312112852.82415-2-xueshuai@linux.alibaba.com Fixes: 4c132d1d844a ("x86/futex: Remove .fixup usage") Signed-off-by: Shuai Xue Suggested-by: Peter Zijlstra Acked-by: Borislav Petkov (AMD) Tested-by: Tony Luck Cc: Baolin Wang Cc: Borislav Betkov Cc: Catalin Marinas Cc: Dave Hansen Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Josh Poimboeuf Cc: Miaohe Lin Cc: Naoya Horiguchi Cc: Ruidong Tian Cc: Thomas Gleinxer Cc: Yazen Ghannam Cc: Jane Chu Cc: Jarkko Sakkinen Cc: Jonathan Cameron Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ada88219d5315fc13f2910fe278c7112d8d68889 Author: Boris Ostrovsky Date: Thu Mar 27 19:05:02 2025 -0400 x86/microcode/AMD: Fix __apply_microcode_amd()'s return value commit 31ab12df723543047c3fc19cb8f8c4498ec6267f upstream. When verify_sha256_digest() fails, __apply_microcode_amd() should propagate the failure by returning false (and not -1 which is promoted to true). Fixes: 50cef76d5cb0 ("x86/microcode/AMD: Load only SHA256-checksummed patches") Signed-off-by: Boris Ostrovsky Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250327230503.1850368-2-boris.ostrovsky@oracle.com Signed-off-by: Greg Kroah-Hartman commit d39838da59bda11b5b292f46db5a52201cef107a Author: Paolo Bonzini Date: Thu Mar 6 21:29:22 2025 +0100 KVM: x86: block KVM_CAP_SYNC_REGS if guest state is protected commit 74c1807f6c4feddb3c3cb1056c54531d4adbaea6 upstream. KVM_CAP_SYNC_REGS does not make sense for VMs with protected guest state, since the register values cannot actually be written. Return 0 when using the VM-level KVM_CHECK_EXTENSION ioctl, and accordingly return -EINVAL from KVM_RUN if the valid/dirty fields are nonzero. However, on exit from KVM_RUN userspace could have placed a nonzero value into kvm_run->kvm_valid_regs, so check guest_state_protected again and skip store_regs() in that case. Cc: stable@vger.kernel.org Fixes: 517987e3fb19 ("KVM: x86: add fields to struct kvm_arch for CoCo features") Signed-off-by: Paolo Bonzini Message-ID: <20250306202923.646075-1-pbonzini@redhat.com> Reviewed-by: Pankaj Gupta Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit a54247efbc73131def0d5cd3ac35ef89629f2c13 Author: Tianyu Lan Date: Thu Mar 13 04:52:17 2025 -0400 x86/hyperv: Fix check of return value from snp_set_vmsa() commit e792d843aa3c9d039074cdce728d5803262e57a7 upstream. snp_set_vmsa() returns 0 as success result and so fix it. Cc: stable@vger.kernel.org Fixes: 44676bb9d566 ("x86/hyperv: Add smp support for SEV-SNP guest") Signed-off-by: Tianyu Lan Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20250313085217.45483-1-ltykernel@gmail.com Signed-off-by: Wei Liu Message-ID: <20250313085217.45483-1-ltykernel@gmail.com> Signed-off-by: Greg Kroah-Hartman commit add72c418d0a3c4531f0664aa758868f598542dd Author: Hengqi Chen Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: BPF: Use move_addr() for BPF_PSEUDO_FUNC commit 52266f1015a8b5aabec7d127f83d105f702b388e upstream. Vincent reported that running XDP synproxy program on LoongArch results in the following error: JIT doesn't support bpf-to-bpf calls With dmesg: multi-func JIT bug 1391 != 1390 The root cause is that verifier will refill the imm with the correct addresses of bpf_calls for BPF_PSEUDO_FUNC instructions and then run the last pass of JIT. So we generate different JIT code for the same instruction in two passes (one for placeholder and the other for the real address). Let's use move_addr() instead. See commit 64f50f6575721ef0 ("LoongArch, bpf: Use 4 instructions for function address in JIT") for a similar fix. Cc: stable@vger.kernel.org Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper") Fixes: bb035ef0cc91 ("LoongArch: BPF: Support mixing bpf2bpf and tailcalls") Reported-by: Vincent Li Tested-by: Vincent Li Closes: https://lore.kernel.org/loongarch/CAK3+h2yfM9FTNiXvEQBkvtuoJrvzmN4c_NZsFXqEk4Cj1tsBNA@mail.gmail.com/T/#u Signed-off-by: Hengqi Chen Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 223d565d8892481684091cfbaf3466f2b0e289d3 Author: Hengqi Chen Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: BPF: Don't override subprog's return value commit 60f3caff1492e5b8616b9578c4bedb5c0a88ed14 upstream. The verifier test `calls: div by 0 in subprog` triggers a panic at the ld.bu instruction. The ld.bu insn is trying to load byte from memory address returned by the subprog. The subprog actually set the correct address at the a5 register (dedicated register for BPF return values). But at commit 73c359d1d356 ("LoongArch: BPF: Sign-extend return values") we also sign extended a5 to the a0 register (return value in LoongArch). For function call insn, we later propagate the a0 register back to a5 register. This is right for native calls but wrong for bpf2bpf calls which expect zero-extended return value in a5 register. So only move a0 to a5 for native calls (i.e. non-BPF_PSEUDO_CALL). Cc: stable@vger.kernel.org Fixes: 73c359d1d356 ("LoongArch: BPF: Sign-extend return values") Signed-off-by: Hengqi Chen Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 205a2182c51ffebaef54d643e3745e720cded08b Author: Hengqi Chen Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: BPF: Fix off-by-one error in build_prologue() commit 7e2586991e36663c9bc48c828b83eab180ad30a9 upstream. Vincent reported that running BPF progs with tailcalls on LoongArch causes kernel hard lockup. Debugging the issues shows that the JITed image missing a jirl instruction at the end of the epilogue. There are two passes in JIT compiling, the first pass set the flags and the second pass generates JIT code based on those flags. With BPF progs mixing bpf2bpf and tailcalls, build_prologue() generates N insns in the first pass and then generates N+1 insns in the second pass. This makes epilogue_offset off by one and we will jump to some unexpected insn and cause lockup. Fix this by inserting a nop insn. Cc: stable@vger.kernel.org Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support") Fixes: bb035ef0cc91 ("LoongArch: BPF: Support mixing bpf2bpf and tailcalls") Reported-by: Vincent Li Tested-by: Vincent Li Closes: https://lore.kernel.org/loongarch/CAK3+h2w6WESdBN3UCr3WKHByD7D6Q_Ve1EDAjotVrnx6Or_c8g@mail.gmail.com/ Closes: https://lore.kernel.org/bpf/CAK3+h2woEjG_N=-XzqEGaAeCmgu2eTCUc7p6bP4u8Q+DFHm-7g@mail.gmail.com/ Signed-off-by: Hengqi Chen Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 0aa5d4370b5b667bb2d9f7224da46dfdb76a396f Author: Huacai Chen Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: Increase MAX_IO_PICS up to 8 commit ec105cadff5d8c0a029a3dc1084cae46cf3f799d upstream. Begin with Loongson-3C6000, the number of PCI host can be as many as 8 for multi-chip machines, and this number should be the same for I/O interrupt controllers. To support these machines we also increase the MAX_IO_PICS up to 8. Cc: stable@vger.kernel.org Tested-by: Mingcong Bai Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 1d0def2d1658666ec1f32c9495df60e7411e3c82 Author: Huacai Chen Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: Increase ARCH_DMA_MINALIGN up to 16 commit 4103cfe9dcb88010ae4911d3ff417457d1b6a720 upstream. ARCH_DMA_MINALIGN is 1 by default, but some LoongArch-specific devices (such as APBDMA) require 16 bytes alignment. When the data buffer length is too small, the hardware may make an error writing cacheline. Thus, it is dangerous to allocate a small memory buffer for DMA. It's always safe to define ARCH_DMA_MINALIGN as L1_CACHE_BYTES but unnecessary (kmalloc() need small memory objects). Therefore, just increase it to 16. Cc: stable@vger.kernel.org Tested-by: Binbin Zhou Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit dc07c4698587bc9e1040a24d9a4e739c4f2caa75 Author: WANG Rui Date: Sun Mar 30 16:30:20 2025 +0800 rust: Fix enabling Rust and building with GCC for LoongArch commit 13c23cb4ed09466d73f1beae8956810b95add6ef upstream. This patch fixes a build issue on LoongArch when Rust is enabled and compiled with GCC by explicitly setting the bindgen target and skipping C flags that Clang doesn't support. Cc: stable@vger.kernel.org Acked-by: Miguel Ojeda Signed-off-by: WANG Rui Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit d689645cd1594ea1d13cb0c404f8ad1011353e0e Author: Ying Lu Date: Wed Apr 2 16:58:59 2025 +0800 usbnet:fix NPE during rx_complete commit 51de3600093429e3b712e5f091d767babc5dd6df upstream. Missing usbnet_going_away Check in Critical Path. The usb_submit_urb function lacks a usbnet_going_away validation, whereas __usbnet_queue_skb includes this check. This inconsistency creates a race condition where: A URB request may succeed, but the corresponding SKB data fails to be queued. Subsequent processes: (e.g., rx_complete → defer_bh → __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic). Fixes: 04e906839a05 ("usbnet: fix cyclical race on disconnect with work queue") Cc: stable@vger.kernel.org Signed-off-by: Ying Lu Link: https://patch.msgid.link/4c9ef2efaa07eb7f9a5042b74348a67e5a3a7aea.1743584159.git.luying1@xiaomi.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 86f327305ed4bb5caa95fba368cfc6f040dd7917 Author: Alexander Wetzel Date: Thu Feb 13 22:43:30 2025 +0100 wifi: mac80211: Fix sparse warning for monitor_sdata commit 861d0445e72e9e33797f2ceef882c74decb16a87 upstream. Use rcu_access_pointer() to avoid sparse warning in drv_remove_interface(). Signed-off-by: Alexander Wetzel Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202502130534.bVrZZBK0-lkp@intel.com/ Fixes: 646262c71aca ("wifi: mac80211: remove debugfs dir for virtual monitor") Link: https://patch.msgid.link/20250213214330.6113-1-Alexander@wetzel-home.de Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 96fa2608296da9ce5d519d9741ef59e17ceb0e43 Author: Sherry Sun Date: Fri Mar 7 14:54:46 2025 +0800 tty: serial: lpuart: only disable CTS instead of overwriting the whole UARTMODIR register [ Upstream commit e98ab45ec5182605d2e00114cba3bbf46b0ea27f ] No need to overwrite the whole UARTMODIR register before waiting the transmit engine complete, actually our target here is only to disable CTS flow control to avoid the dirty data in TX FIFO may block the transmit engine complete. Also delete the following duplicate CTS disable configuration. Fixes: d5a2e0834364 ("tty: serial: lpuart: disable flow control while waiting for the transmit engine to complete") Cc: stable Signed-off-by: Sherry Sun Link: https://lore.kernel.org/r/20250307065446.1122482-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b09ff334c168e99e09ff86b91a30f5270f87a733 Author: Sherry Sun Date: Mon Mar 24 10:10:51 2025 +0800 tty: serial: fsl_lpuart: Fix unused variable 'sport' build warning commit 9f8fe348ac9544f6855f82565e754bf085d81f88 upstream. Remove the unused variable 'sport' to avoid the kernel build warning. Fixes: 3cc16ae096f1 ("tty: serial: fsl_lpuart: use port struct directly to simply code") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202503210614.2qGlnbIq-lkp@intel.com/ Signed-off-by: Sherry Sun Link: https://lore.kernel.org/r/20250324021051.162676-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman commit ac08fa36d8cbcdbe39eb490fc2dd4345d50a433c Author: Sherry Sun Date: Wed Mar 12 10:39:03 2025 +0800 tty: serial: fsl_lpuart: use port struct directly to simply code commit 3cc16ae096f164ae0c6b98416c25a01db5f3a529 upstream. Most lpuart functions have the parameter struct uart_port *port, but still use the &sport->port to get the uart_port instead of use it directly, let's simply the code logic, directly use this struct instead of covert it from struct sport. Signed-off-by: Sherry Sun Link: https://lore.kernel.org/r/20250312023904.1343351-3-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman commit 82719d0e7584bf78aebf66fd94f12aa437c94031 Author: Sherry Sun Date: Wed Mar 12 10:39:02 2025 +0800 tty: serial: fsl_lpuart: Use u32 and u8 for register variables [ Upstream commit b6a8f6ab2c53e5ea3c7f2a3978db378a89bb7595 ] Use u32 and u8 rather than unsigned long or unsigned char for register variables for clarity and consistency. Signed-off-by: Sherry Sun Link: https://lore.kernel.org/r/20250312023904.1343351-2-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: e98ab45ec518 ("tty: serial: lpuart: only disable CTS instead of overwriting the whole UARTMODIR register") Signed-off-by: Sasha Levin commit 3501677651cac478826e83690ec3d19706fbf3cd Author: Abel Wu Date: Sun Feb 9 14:13:11 2025 +0800 cgroup/rstat: Fix forceidle time in cpu.stat [ Upstream commit c4af66a95aa3bc1d4f607ebd4eea524fb58946e3 ] The commit b824766504e4 ("cgroup/rstat: add force idle show helper") retrieves forceidle_time outside cgroup_rstat_lock for non-root cgroups which can be potentially inconsistent with other stats. Rather than reverting that commit, fix it in a way that retains the effort of cleaning up the ifdef-messes. Fixes: b824766504e4 ("cgroup/rstat: add force idle show helper") Signed-off-by: Abel Wu Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 39bc1484eb0663c84b2ec72c2960b2e01ef99545 Author: Joshua Hahn Date: Wed Oct 2 11:47:16 2024 -0700 cgroup/rstat: Tracking cgroup-level niced CPU time [ Upstream commit aefa398d93d5db7c555be78a605ff015357f127d ] Cgroup-level CPU statistics currently include time spent on user/system processes, but do not include niced CPU time (despite already being tracked). This patch exposes niced CPU time to the userspace, allowing users to get a better understanding of their hardware limits and can facilitate more informed workload distribution. A new field 'ntime' is added to struct cgroup_base_stat as opposed to struct task_cputime to minimize footprint. Signed-off-by: Joshua Hahn Signed-off-by: Tejun Heo Stable-dep-of: c4af66a95aa3 ("cgroup/rstat: Fix forceidle time in cpu.stat") Signed-off-by: Sasha Levin commit ef79f2dec7a9df7f935530410727bb6b0ec82496 Author: Tengda Wu Date: Fri Mar 14 06:53:35 2025 +0000 tracing: Correct the refcount if the hist/hist_debug file fails to open [ Upstream commit 0b4ffbe4888a2c71185eaf5c1a02dd3586a9bc04 ] The function event_{hist,hist_debug}_open() maintains the refcount of 'file->tr' and 'file' through tracing_open_file_tr(). However, it does not roll back these counts on subsequent failure paths, resulting in a refcount leak. A very obvious case is that if the hist/hist_debug file belongs to a specific instance, the refcount leak will prevent the deletion of that instance, as it relies on the condition 'tr->ref == 1' within __remove_instance(). Fix this by calling tracing_release_file_tr() on all failure paths in event_{hist,hist_debug}_open() to correct the refcount. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Zheng Yejian Link: https://lore.kernel.org/20250314065335.1202817-1-wutengda@huaweicloud.com Fixes: 1cc111b9cddc ("tracing: Fix uaf issue when open the hist or hist_debug file") Signed-off-by: Tengda Wu Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit eecb62a24b23b89169a6b25a00b47626b322abb8 Author: Masami Hiramatsu (Google) Date: Fri Dec 27 13:08:07 2024 +0900 tracing/hist: Support POLLPRI event for poll on histogram [ Upstream commit 66fc6f521a0b91051ce6968a216a30bc52267bf8 ] Since POLLIN will not be flushed until the hist file is read, the user needs to repeatedly read() and poll() on the hist file for monitoring the event continuously. But the read() is somewhat redundant when the user is only monitoring for event updates. Add POLLPRI poll event on the hist file so the event returns when a histogram is updated after open(), poll() or read(). Thus it is possible to wait for the next event without having to issue a read(). Cc: Shuah Khan Cc: Mathieu Desnoyers Link: https://lore.kernel.org/173527248770.464571.2536902137325258133.stgit@devnote2 Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Tom Zanussi Signed-off-by: Steven Rostedt (Google) Stable-dep-of: 0b4ffbe4888a ("tracing: Correct the refcount if the hist/hist_debug file fails to open") Signed-off-by: Sasha Levin commit fe87f8d3a5b485eb8fc605d37437c8a70bf89731 Author: Masami Hiramatsu (Google) Date: Fri Dec 27 13:07:57 2024 +0900 tracing/hist: Add poll(POLLIN) support on hist file [ Upstream commit 1bd13edbbed6e7e396f1aab92b224a4775218e68 ] Add poll syscall support on the `hist` file. The Waiter will be waken up when the histogram is updated with POLLIN. Currently, there is no way to wait for a specific event in userspace. So user needs to peek the `trace` periodicaly, or wait on `trace_pipe`. But it is not a good idea to peek at the `trace` for an event that randomly happens. And `trace_pipe` is not coming back until a page is filled with events. This allows a user to wait for a specific event on the `hist` file. User can set a histogram trigger on the event which they want to monitor and poll() on its `hist` file. Since this poll() returns POLLIN, the next poll() will return soon unless a read() happens on that hist file. NOTE: To read the hist file again, you must set the file offset to 0, but just for monitoring the event, you may not need to read the histogram. Cc: Shuah Khan Cc: Mathieu Desnoyers Link: https://lore.kernel.org/173527247756.464571.14236296701625509931.stgit@devnote2 Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Tom Zanussi Signed-off-by: Steven Rostedt (Google) Stable-dep-of: 0b4ffbe4888a ("tracing: Correct the refcount if the hist/hist_debug file fails to open") Signed-off-by: Sasha Levin commit 387dc88c2c27c33f6c0422fb79c6470b06b3c046 Author: Steven Rostedt Date: Thu Dec 19 15:12:05 2024 -0500 tracing: Switch trace_events_hist.c code over to use guard() [ Upstream commit 2b36a97aeeb71b1e4a48bfedc7f21f44aeb1e6fb ] There are a couple functions in trace_events_hist.c that have "goto out" or equivalent on error in order to release locks that were taken. This can be error prone or just simply make the code more complex. Switch every location that ends with unlocking a mutex on error over to using the guard(mutex)() infrastructure to let the compiler worry about releasing locks. This makes the code easier to read and understand. Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Peter Zijlstra Link: https://lore.kernel.org/20241219201345.694601480@goodmis.org Signed-off-by: Steven Rostedt (Google) Stable-dep-of: 0b4ffbe4888a ("tracing: Correct the refcount if the hist/hist_debug file fails to open") Signed-off-by: Sasha Levin commit 7de8290a66df7229eb78b0ae5249f4bcef0a253f Author: Len Brown Date: Sun Apr 6 11:18:39 2025 -0400 tools/power turbostat: report CoreThr per measurement interval [ Upstream commit f729775f79a9c942c6c82ed6b44bd030afe10423 ] The CoreThr column displays total thermal throttling events since boot time. Change it to report events during the measurement interval. This is more useful for showing a user the current conditions. Total events since boot time are still available to the user via /sys/devices/system/cpu/cpu*/thermal_throttle/* Document CoreThr on turbostat.8 Fixes: eae97e053fe30 ("turbostat: Support thermal throttle count print") Reported-by: Arjan van de Ven Signed-off-by: Len Brown Cc: Chen Yu Signed-off-by: Sasha Levin commit e9c92880723979c0ba59dba58161da3a4a00884e Author: Yeoreum Yun Date: Wed Mar 26 08:20:03 2025 +0000 perf/core: Fix child_total_time_enabled accounting bug at task exit [ Upstream commit a3c3c66670cee11eb13aa43905904bf29cb92d32 ] The perf events code fails to account for total_time_enabled of inactive events. Here is a failure case for accounting total_time_enabled for CPU PMU events: sudo ./perf stat -vvv -e armv8_pmuv3_0/event=0x08/ -e armv8_pmuv3_1/event=0x08/ -- stress-ng --pthread=2 -t 2s ... armv8_pmuv3_0/event=0x08/: 1138698008 2289429840 2174835740 armv8_pmuv3_1/event=0x08/: 1826791390 1950025700 847648440 ` ` ` ` ` > total_time_running with child ` > total_time_enabled with child > count with child Performance counter stats for 'stress-ng --pthread=2 -t 2s': 1,138,698,008 armv8_pmuv3_0/event=0x08/ (94.99%) 1,826,791,390 armv8_pmuv3_1/event=0x08/ (43.47%) The two events above are opened on two different CPU PMUs, for example, each event is opened for a cluster in an Arm big.LITTLE system, they will never run on the same CPU. In theory, the total enabled time should be same for both events, as two events are opened and closed together. As the result show, the two events' total enabled time including child event is different (2289429840 vs 1950025700). This is because child events are not accounted properly if a event is INACTIVE state when the task exits: perf_event_exit_event() `> perf_remove_from_context() `> __perf_remove_from_context() `> perf_child_detach() -> Accumulate child_total_time_enabled `> list_del_event() -> Update child event's time The problem is the time accumulation happens prior to child event's time updating. Thus, it misses to account the last period's time when the event exits. The perf core layer follows the rule that timekeeping is tied to state change. To address the issue, make __perf_remove_from_context() handle the task exit case by passing 'DETACH_EXIT' to it and invoke perf_event_state() for state alongside with accounting the time. Then, perf_child_detach() populates the time into the parent's time metrics. After this patch, the bug is fixed: sudo ./perf stat -vvv -e armv8_pmuv3_0/event=0x08/ -e armv8_pmuv3_1/event=0x08/ -- stress-ng --pthread=2 -t 10s ... armv8_pmuv3_0/event=0x08/: 15396770398 32157963940 21898169000 armv8_pmuv3_1/event=0x08/: 22428964974 32157963940 10259794940 Performance counter stats for 'stress-ng --pthread=2 -t 10s': 15,396,770,398 armv8_pmuv3_0/event=0x08/ (68.10%) 22,428,964,974 armv8_pmuv3_1/event=0x08/ (31.90%) [ mingo: Clarified the changelog. ] Fixes: ef54c1a476aef ("perf: Rework perf_event_exit_event()") Suggested-by: Peter Zijlstra Signed-off-by: Yeoreum Yun Signed-off-by: Ingo Molnar Tested-by: Leo Yan Link: https://lore.kernel.org/r/20250326082003.1630986-1-yeoreum.yun@arm.com Signed-off-by: Sasha Levin commit d3f0a68b2914061e20b004b488034010d83d0be1 Author: Alex Deucher Date: Thu Mar 20 12:09:11 2025 -0400 drm/amdgpu/gfx12: fix num_mec [ Upstream commit dce8bd9137b88735dd0efc4e2693213d98c15913 ] GC12 only has 1 mec. Fixes: 52cb80c12e8a ("drm/amdgpu: Add gfx v12_0 ip block support (v6)") Reviewed-by: Sunil Khatri Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2ac69453e9e5c24ebb55abe15e075d59b6ca01da Author: Alex Deucher Date: Wed Mar 26 09:35:02 2025 -0400 drm/amdgpu/gfx11: fix num_mec [ Upstream commit 4161050d47e1b083a7e1b0b875c9907e1a6f1f1f ] GC11 only has 1 mec. Fixes: 3d879e81f0f9 ("drm/amdgpu: add init support for GFX11 (v2)") Reviewed-by: Sunil Khatri Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 528287815ee52a2f5ea68df83e712513a19f9c8a Author: Alexandru Gagniuc Date: Fri Mar 14 13:10:53 2025 +0000 kbuild: deb-pkg: don't set KBUILD_BUILD_VERSION unconditionally [ Upstream commit 62604063621fb075c7966286bdddcb057d883fa8 ] In ThinPro, we use the convention +hp for the kernel package. This does not have a dash in the name or version. This is built by editing ".version" before a build, and setting EXTRAVERSION="+hp" and KDEB_PKGVERSION make variables: echo 68 > .version make -j EXTRAVERSION="+hp" bindeb-pkg KDEB_PKGVERSION=6.12.2+hp69 .deb name: linux-image-6.12.2+hp_6.12.2+hp69_amd64.deb Since commit 7d4f07d5cb71 ("kbuild: deb-pkg: squash scripts/package/deb-build-option to debian/rules"), this no longer works. The deb build logic changed, even though, the commit message implies that the logic should be unmodified. Before, KBUILD_BUILD_VERSION was not set if the KDEB_PKGVERSION did not contain a dash. After the change KBUILD_BUILD_VERSION is always set to KDEB_PKGVERSION. Since this determines UTS_VERSION, the uname output to look off: (now) uname -a: version 6.12.2+hp ... #6.12.2+hp69 (expected) uname -a: version 6.12.2+hp ... #69 Update the debian/rules logic to restore the original behavior. Fixes: 7d4f07d5cb71 ("kbuild: deb-pkg: squash scripts/package/deb-build-option to debian/rules") Signed-off-by: Alexandru Gagniuc Reviewed-by: Nicolas Schier Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 8a88bb092f4208355880b9fdcc69d491aa297595 Author: Dave Marquardt Date: Wed Apr 2 10:44:03 2025 -0500 net: ibmveth: make veth_pool_store stop hanging [ Upstream commit 053f3ff67d7feefc75797863f3d84b47ad47086f ] v2: - Created a single error handling unlock and exit in veth_pool_store - Greatly expanded commit message with previous explanatory-only text Summary: Use rtnl_mutex to synchronize veth_pool_store with itself, ibmveth_close and ibmveth_open, preventing multiple calls in a row to napi_disable. Background: Two (or more) threads could call veth_pool_store through writing to /sys/devices/vio/30000002/pool*/*. You can do this easily with a little shell script. This causes a hang. I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new kernel. I ran this test again and saw: Setting pool0/active to 0 Setting pool1/active to 1 [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting Setting pool1/active to 1 Setting pool1/active to 0 [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds. [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8 [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000 [ 243.683852][ T123] Call Trace: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable) [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0 [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0 [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210 [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50 [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0 [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60 [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270 [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0 [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0 [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650 [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150 [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ... [ 243.684087][ T123] Showing all locks held in the system: [ 243.684095][ T123] 1 lock held by khungtaskd/123: [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248 [ 243.684114][ T123] 4 locks held by stress.sh/4365: [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60 [ 243.684166][ T123] 5 locks held by stress.sh/4366: [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.684183][ T123] #1: c00000000aee2288 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684194][ T123] #2: c0000000366f4ba8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684205][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_disable+0x30/0x60 [ 243.684216][ T123] #4: c0000003ff9bbf18 (&rq->__lock){-.-.}-{2:2}, at: __schedule+0x138/0x12a0 From the ibmveth debug, two threads are calling veth_pool_store, which calls ibmveth_close and ibmveth_open. Here's the sequence: T4365 T4366 ----------------- ----------------- --------- veth_pool_store veth_pool_store ibmveth_close ibmveth_close napi_disable napi_disable ibmveth_open napi_enable <- HANG ibmveth_close calls napi_disable at the top and ibmveth_open calls napi_enable at the top. https://docs.kernel.org/networking/napi.html]] says The control APIs are not idempotent. Control API calls are safe against concurrent use of datapath APIs but an incorrect sequence of control API calls may result in crashes, deadlocks, or race conditions. For example, calling napi_disable() multiple times in a row will deadlock. In the normal open and close paths, rtnl_mutex is acquired to prevent other callers. This is missing from veth_pool_store. Use rtnl_mutex in veth_pool_store fixes these hangs. Signed-off-by: Dave Marquardt Fixes: 860f242eb534 ("[PATCH] ibmveth change buffer pools dynamically") Reviewed-by: Nick Child Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250402154403.386744-1-davemarq@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ebebeb58d48e25525fa654f2c53a24713fe141c3 Author: Henry Martin Date: Wed Apr 2 21:50:36 2025 +0800 arcnet: Add NULL check in com20020pci_probe() [ Upstream commit fda8c491db2a90ff3e6fbbae58e495b4ddddeca3 ] devm_kasprintf() returns NULL when memory allocation fails. Currently, com20020pci_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue and ensure no resources are left allocated. Fixes: 6b17a597fc2f ("arcnet: restoring support for multiple Sohard Arcnet cards") Signed-off-by: Henry Martin Link: https://patch.msgid.link/20250402135036.44697-1-bsdhenrymartin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f4fea25f5c7f2841d356c438aba34e44ad341bde Author: Ido Schimmel Date: Wed Apr 2 14:42:24 2025 +0300 ipv6: Do not consider link down nexthops in path selection [ Upstream commit 8b8e0dd357165e0258d9f9cdab5366720ed2f619 ] Nexthops whose link is down are not supposed to be considered during path selection when the "ignore_routes_with_linkdown" sysctl is set. This is done by assigning them a negative region boundary. However, when comparing the computed hash (unsigned) with the region boundary (signed), the negative region boundary is treated as unsigned, resulting in incorrect nexthop selection. Fix by treating the computed hash as signed. Note that the computed hash is always in range of [0, 2^31 - 1]. Fixes: 3d709f69a3e7 ("ipv6: Use hash-threshold instead of modulo-N") Signed-off-by: Ido Schimmel Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20250402114224.293392-3-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1eb36a2cdf639483d414d193ad31ff476a8fb2a9 Author: Ido Schimmel Date: Wed Apr 2 14:42:23 2025 +0300 ipv6: Start path selection from the first nexthop [ Upstream commit 4d0ab3a6885e3e9040310a8d8f54503366083626 ] Cited commit transitioned IPv6 path selection to use hash-threshold instead of modulo-N. With hash-threshold, each nexthop is assigned a region boundary in the multipath hash function's output space and a nexthop is chosen if the calculated hash is smaller than the nexthop's region boundary. Hash-threshold does not work correctly if path selection does not start with the first nexthop. For example, if fib6_select_path() is always passed the last nexthop in the group, then it will always be chosen because its region boundary covers the entire hash function's output space. Fix this by starting the selection process from the first nexthop and do not consider nexthops for which rt6_score_route() provided a negative score. Fixes: 3d709f69a3e7 ("ipv6: Use hash-threshold instead of modulo-N") Reported-by: Stanislav Fomichev Closes: https://lore.kernel.org/netdev/Z9RIyKZDNoka53EO@mini-arch/ Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20250402114224.293392-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2952776c69a1a551649ed770bf22e3f691f6ec65 Author: Lin Ma Date: Thu Apr 3 00:56:32 2025 +0800 net: fix geneve_opt length integer overflow [ Upstream commit b27055a08ad4b415dcf15b63034f9cb236f7fb40 ] struct geneve_opt uses 5 bit length for each single option, which means every vary size option should be smaller than 128 bytes. However, all current related Netlink policies cannot promise this length condition and the attacker can exploit a exact 128-byte size option to *fake* a zero length option and confuse the parsing logic, further achieve heap out-of-bounds read. One example crash log is like below: [ 3.905425] ================================================================== [ 3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0 [ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177 [ 3.906646] [ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1 [ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 3.907784] Call Trace: [ 3.907925] [ 3.908048] dump_stack_lvl+0x44/0x5c [ 3.908258] print_report+0x184/0x4be [ 3.909151] kasan_report+0xc5/0x100 [ 3.909539] kasan_check_range+0xf3/0x1a0 [ 3.909794] memcpy+0x1f/0x60 [ 3.909968] nla_put+0xa9/0xe0 [ 3.910147] tunnel_key_dump+0x945/0xba0 [ 3.911536] tcf_action_dump_1+0x1c1/0x340 [ 3.912436] tcf_action_dump+0x101/0x180 [ 3.912689] tcf_exts_dump+0x164/0x1e0 [ 3.912905] fw_dump+0x18b/0x2d0 [ 3.913483] tcf_fill_node+0x2ee/0x460 [ 3.914778] tfilter_notify+0xf4/0x180 [ 3.915208] tc_new_tfilter+0xd51/0x10d0 [ 3.918615] rtnetlink_rcv_msg+0x4a2/0x560 [ 3.919118] netlink_rcv_skb+0xcd/0x200 [ 3.919787] netlink_unicast+0x395/0x530 [ 3.921032] netlink_sendmsg+0x3d0/0x6d0 [ 3.921987] __sock_sendmsg+0x99/0xa0 [ 3.922220] __sys_sendto+0x1b7/0x240 [ 3.922682] __x64_sys_sendto+0x72/0x90 [ 3.922906] do_syscall_64+0x5e/0x90 [ 3.923814] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 3.924122] RIP: 0033:0x7e83eab84407 [ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 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 faf [ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407 [ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003 [ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c [ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0 [ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8 Fix these issues by enforing correct length condition in related policies. Fixes: 925d844696d9 ("netfilter: nft_tunnel: add support for geneve opts") Fixes: 4ece47787077 ("lwtunnel: add options setting and dumping for geneve") Fixes: 0ed5269f9e41 ("net/sched: add tunnel option support to act_tunnel_key") Fixes: 0a6e77784f49 ("net/sched: allow flower to match tunnel options") Signed-off-by: Lin Ma Reviewed-by: Xin Long Acked-by: Cong Wang Link: https://patch.msgid.link/20250402165632.6958-1-linma@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9dec9dacaeeda0b87c9833fa85d8a015677fa65a Author: David Oberhollenzer Date: Tue Apr 1 15:56:37 2025 +0200 net: dsa: mv88e6xxx: propperly shutdown PPU re-enable timer on destroy [ Upstream commit a58d882841a0750da3c482cd3d82432b1c7edb77 ] The mv88e6xxx has an internal PPU that polls PHY state. If we want to access the internal PHYs, we need to disable the PPU first. Because that is a slow operation, a 10ms timer is used to re-enable it, canceled with every access, so bulk operations effectively only disable it once and re-enable it some 10ms after the last access. If a PHY is accessed and then the mv88e6xxx module is removed before the 10ms are up, the PPU re-enable ends up accessing a dangling pointer. This especially affects probing during bootup. The MDIO bus and PHY registration may succeed, but registration with the DSA framework may fail later on (e.g. because the CPU port depends on another, very slow device that isn't done probing yet, returning -EPROBE_DEFER). In this case, probe() fails, but the MDIO subsystem may already have accessed the MIDO bus or PHYs, arming the timer. This is fixed as follows: - If probe fails after mv88e6xxx_phy_init(), make sure we also call mv88e6xxx_phy_destroy() before returning - In mv88e6xxx_remove(), make sure we do the teardown in the correct order, calling mv88e6xxx_phy_destroy() after unregistering the switch device. - In mv88e6xxx_phy_destroy(), destroy both the timer and the work item that the timer might schedule, synchronously waiting in case one of the callbacks already fired and destroying the timer first, before waiting for the work item. - Access to the PPU is guarded by a mutex, the worker acquires it with a mutex_trylock(), not proceeding with the expensive shutdown if that fails. We grab the mutex in mv88e6xxx_phy_destroy() to make sure the slow PPU shutdown is already done or won't even enter, when we wait for the work item. Fixes: 2e5f032095ff ("dsa: add support for the Marvell 88E6131 switch chip") Signed-off-by: David Oberhollenzer Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20250401135705.92760-1-david.oberhollenzer@sigma-star.at Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit de579015d132e742af32611900b038ffbe5a0850 Author: Fernando Fernandez Mancera Date: Wed Apr 2 14:17:51 2025 +0200 ipv6: fix omitted netlink attributes when using RTEXT_FILTER_SKIP_STATS [ Upstream commit 7ac6ea4a3e0898db76aecccd68fb2c403eb7d24e ] Using RTEXT_FILTER_SKIP_STATS is incorrectly skipping non-stats IPv6 netlink attributes on link dump. This causes issues on userspace tools, e.g iproute2 is not rendering address generation mode as it should due to missing netlink attribute. Move the filling of IFLA_INET6_STATS and IFLA_INET6_ICMP6STATS to a helper function guarded by a flag check to avoid hitting the same situation in the future. Fixes: d5566fd72ec1 ("rtnetlink: RTEXT_FILTER_SKIP_STATS support to avoid dumping inet/inet6 stats") Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250402121751.3108-1-ffmancera@riseup.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0a93a710d6df334b828ea064c6d39fda34f901dc Author: Lin Ma Date: Thu Apr 3 01:00:26 2025 +0800 netfilter: nft_tunnel: fix geneve_opt type confusion addition [ Upstream commit 1b755d8eb1ace3870789d48fbd94f386ad6e30be ] When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the parsing logic should place every geneve_opt structure one by one compactly. Hence, when deciding the next geneve_opt position, the pointer addition should be in units of char *. However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write. [ 6.989857] ================================================================== [ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] [ 6.992586] dump_stack_lvl+0x44/0x5c [ 6.992801] print_report+0x184/0x4be [ 6.993790] kasan_report+0xc5/0x100 [ 6.994252] kasan_check_range+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nft_tunnel_obj_init+0x977/0xa70 [ 6.995677] nft_obj_init+0x10c/0x1b0 [ 6.995891] nf_tables_newobj+0x585/0x950 [ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020 [ 6.998997] nfnetlink_rcv+0x1df/0x220 [ 6.999537] netlink_unicast+0x395/0x530 [ 7.000771] netlink_sendmsg+0x3d0/0x6d0 [ 7.001462] __sock_sendmsg+0x99/0xa0 [ 7.001707] ____sys_sendmsg+0x409/0x450 [ 7.002391] ___sys_sendmsg+0xfd/0x170 [ 7.003145] __sys_sendmsg+0xea/0x170 [ 7.004359] do_syscall_64+0x5e/0x90 [ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 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 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8 Fix this bug with correct pointer addition and conversion in parse and dump code. Fixes: 925d844696d9 ("netfilter: nft_tunnel: add support for geneve opts") Signed-off-by: Lin Ma Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 92a5c18513117be69bc00419dd1724c1940f8fcd Author: Antoine Tenart Date: Wed Mar 26 18:36:32 2025 +0100 net: decrease cached dst counters in dst_release [ Upstream commit 3a0a3ff6593d670af2451ec363ccb7b18aec0c0a ] Upstream fix ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts: Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30 Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too. Fixes: d71785ffc7e7 ("net: add dst_cache to ovs vxlan lwtunnel") Signed-off-by: Antoine Tenart Link: https://patch.msgid.link/20250326173634.31096-1-atenart@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9539c1721a36ef6d5b5e342b7b4927d01629cc0a Author: Guillaume Nault Date: Sat Mar 29 01:33:44 2025 +0100 tunnels: Accept PACKET_HOST in skb_tunnel_check_pmtu(). [ Upstream commit 8930424777e43257f5bf6f0f0f53defd0d30415c ] Because skb_tunnel_check_pmtu() doesn't handle PACKET_HOST packets, commit 30a92c9e3d6b ("openvswitch: Set the skbuff pkt_type for proper pmtud support.") forced skb->pkt_type to PACKET_OUTGOING for openvswitch packets that are sent using the OVS_ACTION_ATTR_OUTPUT action. This allowed such packets to invoke the iptunnel_pmtud_check_icmp() or iptunnel_pmtud_check_icmpv6() helpers and thus trigger PMTU update on the input device. However, this also broke other parts of PMTU discovery. Since these packets don't have the PACKET_HOST type anymore, they won't trigger the sending of ICMP Fragmentation Needed or Packet Too Big messages to remote hosts when oversized (see the skb_in->pkt_type condition in __icmp_send() for example). These two skb->pkt_type checks are therefore incompatible as one requires skb->pkt_type to be PACKET_HOST, while the other requires it to be anything but PACKET_HOST. It makes sense to not trigger ICMP messages for non-PACKET_HOST packets as these messages should be generated only for incoming l2-unicast packets. However there doesn't seem to be any reason for skb_tunnel_check_pmtu() to ignore PACKET_HOST packets. Allow both cases to work by allowing skb_tunnel_check_pmtu() to work on PACKET_HOST packets and not overriding skb->pkt_type in openvswitch anymore. Fixes: 30a92c9e3d6b ("openvswitch: Set the skbuff pkt_type for proper pmtud support.") Fixes: 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets") Signed-off-by: Guillaume Nault Reviewed-by: Stefano Brivio Reviewed-by: Aaron Conole Tested-by: Aaron Conole Link: https://patch.msgid.link/eac941652b86fddf8909df9b3bf0d97bc9444793.1743208264.git.gnault@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 47744d0d5f3bd413e8153d721c57886a81f84831 Author: Stefano Garzarella Date: Fri Mar 28 15:15:28 2025 +0100 vsock: avoid timeout during connect() if the socket is closing [ Upstream commit fccd2b711d9628c7ce0111d5e4938652101ee30a ] When a peer attempts to establish a connection, vsock_connect() contains a loop that waits for the state to be TCP_ESTABLISHED. However, the other peer can be fast enough to accept the connection and close it immediately, thus moving the state to TCP_CLOSING. When this happens, the peer in the vsock_connect() is properly woken up, but since the state is not TCP_ESTABLISHED, it goes back to sleep until the timeout expires, returning -ETIMEDOUT. If the socket state is TCP_CLOSING, waiting for the timeout is pointless. vsock_connect() can return immediately without errors or delay since the connection actually happened. The socket will be in a closing state, but this is not an issue, and subsequent calls will fail as expected. We discovered this issue while developing a test that accepts and immediately closes connections to stress the transport switch between two connect() calls, where the first one was interrupted by a signal (see Closes link). Reported-by: Luigi Leonardi Closes: https://lore.kernel.org/virtualization/bq6hxrolno2vmtqwcvb5bljfpb7mvwb3kohrvaed6auz5vxrfv@ijmd2f3grobn/ Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Signed-off-by: Stefano Garzarella Acked-by: Paolo Abeni Tested-by: Luigi Leonardi Reviewed-by: Luigi Leonardi Link: https://patch.msgid.link/20250328141528.420719-1-sgarzare@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a116b271bf3cb72c8155b6b7f39083c1b80dcd00 Author: Kuniyuki Iwashima Date: Tue Apr 1 11:44:43 2025 -0700 udp: Fix memory accounting leak. [ Upstream commit df207de9d9e7a4d92f8567e2c539d9c8c12fd99d ] Matt Dowling reported a weird UDP memory usage issue. Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops. We can reproduce the issue with the script below [0]: 1. /proc/net/sockstat reports 0 pages # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Run the script till the report reaches 524,288 # python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT 3. Kill the socket and confirm the number never drops # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. The number doubles # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577 The application set INT_MAX to SO_RCVBUF, which triggered an integer overflow in udp_rmem_release(). When a socket is close()d, udp_destruct_common() purges its receive queue and sums up skb->truesize in the queue. This total is calculated and stored in a local unsigned integer variable. The total size is then passed to udp_rmem_release() to adjust memory accounting. However, because the function takes a signed integer argument, the total size can wrap around, causing an overflow. Then, the released amount is calculated as follows: 1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated(). When the issue occurred, the total in udp_destruct_common() was 2147484480 (INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release(). At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't see a warning in inet_sock_destruct(). However, udp_memory_allocated ends up doubling at 4). Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for memory_allocated"), memory usage no longer doubles immediately after a socket is close()d because __sk_mem_reduce_allocated() caches the amount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP socket receives a packet, the subtraction takes effect, causing UDP memory usage to double. This issue makes further memory allocation fail once the socket's sk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet drops. To prevent this issue, let's use unsigned int for the calculation and call sk_forward_alloc_add() only once for the small delta. Note that first_packet_length() also potentially has the same problem. [0]: from socket import * SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1 s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX) c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname()) data = b'a' * 100 while True: c.send(data) Fixes: f970bd9e3a06 ("udp: implement memory accounting helpers") Reported-by: Matt Dowling Signed-off-by: Kuniyuki Iwashima Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20250401184501.67377-3-kuniyu@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 94d5ad7b41122be33ebc2a6830fe710cba1ecd75 Author: Kuniyuki Iwashima Date: Tue Apr 1 11:44:42 2025 -0700 udp: Fix multiple wraparounds of sk->sk_rmem_alloc. [ Upstream commit 5a465a0da13ee9fbd7d3cd0b2893309b0fe4b7e3 ] __udp_enqueue_schedule_skb() has the following condition: if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) goto drop; sk->sk_rcvbuf is initialised by net.core.rmem_default and later can be configured by SO_RCVBUF, which is limited by net.core.rmem_max, or SO_RCVBUFFORCE. If we set INT_MAX to sk->sk_rcvbuf, the condition is always false as sk->sk_rmem_alloc is also signed int. Then, the size of the incoming skb is added to sk->sk_rmem_alloc unconditionally. This results in integer overflow (possibly multiple times) on sk->sk_rmem_alloc and allows a single socket to have skb up to net.core.udp_mem[1]. For example, if we set a large value to udp_mem[1] and INT_MAX to sk->sk_rcvbuf and flood packets to the socket, we can see multiple overflows: # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 7956736 <-- (7956736 << 12) bytes > INT_MAX * 15 ^- PAGE_SHIFT # ss -uam State Recv-Q ... UNCONN -1757018048 ... <-- flipping the sign repeatedly skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0) Previously, we had a boundary check for INT_MAX, which was removed by commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc"). A complete fix would be to revert it and cap the right operand by INT_MAX: rmem = atomic_add_return(size, &sk->sk_rmem_alloc); if (rmem > min(size + (unsigned int)sk->sk_rcvbuf, INT_MAX)) goto uncharge_drop; but we do not want to add the expensive atomic_add_return() back just for the corner case. Casting rmem to unsigned int prevents multiple wraparounds, but we still allow a single wraparound. # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> 12 # ss -uam State Recv-Q ... UNCONN -2147482816 ... <-- INT_MAX + 831 bytes skmem:(r2147484480,rb2147483646,t0,tb212992,f3264,w0,o0,bl0,d14468947) So, let's define rmem and rcvbuf as unsigned int and check skb->truesize only when rcvbuf is large enough to lower the overflow possibility. Note that we still have a small chance to see overflow if multiple skbs to the same socket are processed on different core at the same time and each size does not exceed the limit but the total size does. Note also that we must ignore skb->truesize for a small buffer as explained in commit 363dc73acacb ("udp: be less conservative with sock rmem accounting"). Fixes: 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20250401184501.67377-2-kuniyu@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fcbfb54a0269875cf3cd6a2bff4f85a2e0a0b552 Author: Tobias Waldekranz Date: Tue Apr 1 08:58:04 2025 +0200 net: mvpp2: Prevent parser TCAM memory corruption [ Upstream commit 96844075226b49af25a69a1d084b648ec2d9b08d ] Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM information, from concurrent modifications. Both the TCAM and SRAM tables are indirectly accessed by configuring an index register that selects the row to read or write to. This means that operations must be atomic in order to, e.g., avoid spreading writes across multiple rows. Since the shadow SRAM array is used to find free rows in the hardware table, it must also be protected in order to avoid TOCTOU errors where multiple cores allocate the same row. This issue was detected in a situation where `mvpp2_set_rx_mode()` ran concurrently on two CPUs. In this particular case the MVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the classifier unit to drop all incoming unicast - indicated by the `rx_classifier_drops` counter. Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit") Signed-off-by: Tobias Waldekranz Reviewed-by: Maxime Chevallier Tested-by: Maxime Chevallier Link: https://patch.msgid.link/20250401065855.3113635-1-tobias@waldekranz.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e5178bfc55b3a78000f0f8298e7ade88783ce581 Author: Eric Dumazet Date: Mon Mar 31 09:15:32 2025 +0000 sctp: add mutual exclusion in proc_sctp_do_udp_port() [ Upstream commit 10206302af856791fbcc27a33ed3c3eb09b2793d ] We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start() or risk a crash as syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653 Call Trace: udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181 sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930 proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553 proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601 iter_file_splice_write+0x91c/0x1150 fs/splice.c:738 do_splice_from fs/splice.c:935 [inline] direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158 splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102 do_splice_direct_actor fs/splice.c:1201 [inline] do_splice_direct+0x174/0x240 fs/splice.c:1227 do_sendfile+0xafd/0xe50 fs/read_write.c:1368 __do_sys_sendfile64 fs/read_write.c:1429 [inline] __se_sys_sendfile64 fs/read_write.c:1415 [inline] __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] Fixes: 046c052b475e ("sctp: enable udp tunneling socks") Reported-by: syzbot+fae49d997eb56fa7c74d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/67ea5c01.050a0220.1547ec.012b.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Cc: Marcelo Ricardo Leitner Acked-by: Xin Long Link: https://patch.msgid.link/20250331091532.224982-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2f35b7673a3aa3d09b3eb05811669622ebaa98ca Author: Cong Wang Date: Sat Mar 29 15:25:35 2025 -0700 net_sched: skbprio: Remove overly strict queue assertions [ Upstream commit ce8fe975fd99b49c29c42e50f2441ba53112b2e8 ] In the current implementation, skbprio enqueue/dequeue contains an assertion that fails under certain conditions when SKBPRIO is used as a child qdisc under TBF with specific parameters. The failure occurs because TBF sometimes peeks at packets in the child qdisc without actually dequeuing them when tokens are unavailable. This peek operation creates a discrepancy between the parent and child qdisc queue length counters. When TBF later receives a high-priority packet, SKBPRIO's queue length may show a different value than what's reflected in its internal priority queue tracking, triggering the assertion. The fix removes this overly strict assertions in SKBPRIO, they are not necessary at all. Reported-by: syzbot+a3422a19b05ea96bee18@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a3422a19b05ea96bee18 Fixes: aea5f654e6b7 ("net/sched: add skbprio scheduler") Cc: Nishanth Devarajan Signed-off-by: Cong Wang Acked-by: Paolo Abeni Link: https://patch.msgid.link/20250329222536.696204-2-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3ba9cf69de50e8abed32b448616c313baa4c5712 Author: Debin Zhu Date: Tue Apr 1 20:40:18 2025 +0800 netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets [ Upstream commit 078aabd567de3d63d37d7673f714e309d369e6e2 ] When calling netlbl_conn_setattr(), addr->sa_family is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipso_sock_setattr() is triggered. Inside this function, the following code is executed: sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL; Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference. This patch fixes the issue by checking if inet6_sk(sk) returns a NULL pointer before accessing pinet6. Signed-off-by: Debin Zhu Signed-off-by: Bitao Ouyang <1985755126@qq.com> Acked-by: Paul Moore Fixes: ceba1832b1b2 ("calipso: Set the calipso socket label to match the secattr.") Link: https://patch.msgid.link/20250401124018.4763-1-mowenroot@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit feb1fa2a03a27fec7001e93e4223be4120d1784b Author: Florian Westphal Date: Tue Apr 1 14:36:47 2025 +0200 netfilter: nf_tables: don't unregister hook when table is dormant [ Upstream commit 688c15017d5cd5aac882400782e7213d40dc3556 ] When nf_tables_updchain encounters an error, hook registration needs to be rolled back. This should only be done if the hook has been registered, which won't happen when the table is flagged as dormant (inactive). Just move the assignment into the registration block. Reported-by: syzbot+53ed3a6440173ddbf499@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=53ed3a6440173ddbf499 Fixes: b9703ed44ffb ("netfilter: nf_tables: support for adding new devices to an existing netdev chain") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 86bd9609fd3ec64e4807117d635e187d523b3438 Author: Pablo Neira Ayuso Date: Fri Mar 21 23:24:20 2025 +0100 netfilter: nft_set_hash: GC reaps elements with conncount for dynamic sets only [ Upstream commit 9d74da1177c800eb3d51c13f9821b7b0683845a5 ] conncount has its own GC handler which determines when to reap stale elements, this is convenient for dynamic sets. However, this also reaps non-dynamic sets with static configurations coming from control plane. Always run connlimit gc handler but honor feedback to reap element if this set is dynamic. Fixes: 290180e2448c ("netfilter: nf_tables: add connlimit support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 79618e952ef4dfa1a17ee0631d5549603fab58d8 Author: Emil Tantilov Date: Mon Mar 17 22:42:02 2025 -0700 idpf: fix adapter NULL pointer dereference on reboot [ Upstream commit 4c9106f4906a85f6b13542d862e423bcdc118cc3 ] With SRIOV enabled, idpf ends up calling into idpf_remove() twice. First via idpf_shutdown() and then again when idpf_remove() calls into sriov_disable(), because the VF devices use the idpf driver, hence the same remove routine. When that happens, it is possible for the adapter to be NULL from the first call to idpf_remove(), leading to a NULL pointer dereference. echo 1 > /sys/class/net//device/sriov_numvfs reboot BUG: kernel NULL pointer dereference, address: 0000000000000020 ... RIP: 0010:idpf_remove+0x22/0x1f0 [idpf] ... ? idpf_remove+0x22/0x1f0 [idpf] ? idpf_remove+0x1e4/0x1f0 [idpf] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x19f/0x200 pci_stop_bus_device+0x6d/0x90 pci_stop_and_remove_bus_device+0x12/0x20 pci_iov_remove_virtfn+0xbe/0x120 sriov_disable+0x34/0xe0 idpf_sriov_configure+0x58/0x140 [idpf] idpf_remove+0x1b9/0x1f0 [idpf] idpf_shutdown+0x12/0x30 [idpf] pci_device_shutdown+0x35/0x60 device_shutdown+0x156/0x200 ... Replace the direct idpf_remove() call in idpf_shutdown() with idpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which perform the bulk of the cleanup, such as stopping the init task, freeing IRQs, destroying the vports and freeing the mailbox. This avoids the calls to sriov_disable() in addition to a small netdev cleanup, and destroying workqueues, which don't seem to be required on shutdown. Reported-by: Yuying Ma Fixes: e850efed5e15 ("idpf: add module register and probe functionality") Reviewed-by: Madhu Chittim Signed-off-by: Emil Tantilov Reviewed-by: Simon Horman Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit d11d0ce887f4fdb2fb2e4364cde60913c80c3fce Author: Vitaly Lifshits Date: Thu Mar 13 16:05:56 2025 +0200 e1000e: change k1 configuration on MTP and later platforms [ Upstream commit efaaf344bc2917cbfa5997633bc18a05d3aed27f ] Starting from Meteor Lake, the Kumeran interface between the integrated MAC and the I219 PHY works at a different frequency. This causes sporadic MDI errors when accessing the PHY, and in rare circumstances could lead to packet corruption. To overcome this, introduce minor changes to the Kumeran idle state (K1) parameters during device initialization. Hardware reset reverts this configuration, therefore it needs to be applied in a few places. Fixes: cc23f4f0b6b9 ("e1000e: Add support for Meteor Lake") Signed-off-by: Vitaly Lifshits Tested-by: Avigail Dahan Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 40d187b247b39b4abe38197c3cb75fbe6bc3731b Author: Florian Fainelli Date: Tue Apr 1 16:36:03 2025 -0700 spi: bcm2835: Restore native CS probing when pinctrl-bcm2835 is absent [ Upstream commit e19c1272c80a5ecce387c1b0c3b995f4edf9c525 ] The lookup table forces the use of the "pinctrl-bcm2835" GPIO chip provider and essentially assumes that there is going to be such a provider, and if not, we will fail to set-up the SPI device. While this is true on Raspberry Pi based systems (2835/36/37, 2711, 2712), this is not true on 7712/77122 Broadcom STB systems which use the SPI driver, but not the GPIO driver. There used to be an early check: chip = gpiochip_find("pinctrl-bcm2835", chip_match_name); if (!chip) return 0; which would accomplish that nicely, bring something similar back by checking for the compatible strings matched by the pinctrl-bcm2835.c driver, if there is no Device Tree node matching those compatible strings, then we won't find any GPIO provider registered by the "pinctrl-bcm2835" driver. Fixes: 21f252cd29f0 ("spi: bcm2835: reduce the abuse of the GPIO API") Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20250401233603.2938955-1-florian.fainelli@broadcom.com Acked-by: Bartosz Golaszewski Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 174954911f1ca8ec6c4f9efd211e693c5ec6cbb6 Author: Takashi Iwai Date: Wed Apr 2 09:42:07 2025 +0200 ALSA: hda/realtek: Fix built-in mic on another ASUS VivoBook model [ Upstream commit 8983dc1b66c0e1928a263b8af0bb06f6cb9229c4 ] There is another VivoBook model which built-in mic got broken recently by the fix of the pin sort. Apply the correct quirk ALC256_FIXUP_ASUS_MIC_NO_PRESENCE to this model for addressing the regression, too. Fixes: 3b4309546b48 ("ALSA: hda: Fix headset detection failure due to unstable sort") Closes: https://lore.kernel.org/Z95s5T6OXFPjRnKf@eldamar.lan Link: https://patch.msgid.link/20250402074208.7347-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 48b175aa4677498268c50cb5eaaea11650ce805d Author: Florian Fainelli Date: Tue Apr 1 15:42:38 2025 -0700 spi: bcm2835: Do not call gpiod_put() on invalid descriptor [ Upstream commit d6691010523fe1016f482a1e1defcc6289eeea48 ] If we are unable to lookup the chip-select GPIO, the error path will call bcm2835_spi_cleanup() which unconditionally calls gpiod_put() on the cs->gpio variable which we just determined was invalid. Fixes: 21f252cd29f0 ("spi: bcm2835: reduce the abuse of the GPIO API") Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20250401224238.2854256-1-florian.fainelli@broadcom.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4d8458e48ff135bddc402ad79821dc058ea163d0 Author: Henry Martin Date: Tue Apr 1 22:25:10 2025 +0800 ASoC: imx-card: Add NULL check in imx_card_probe() [ Upstream commit 93d34608fd162f725172e780b1c60cc93a920719 ] devm_kasprintf() returns NULL when memory allocation fails. Currently, imx_card_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: aa736700f42f ("ASoC: imx-card: Add imx-card machine driver") Signed-off-by: Henry Martin Reviewed-by: Frank Li Link: https://patch.msgid.link/20250401142510.29900-1-bsdhenrymartin@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a3800b64f866c06c1f631de91a7e82880b8780eb Author: Caleb Sander Mateos Date: Fri Mar 28 09:46:45 2025 -0600 nvme/ioctl: don't warn on vectorized uring_cmd with fixed buffer [ Upstream commit eada75467fca0b016b9b22212637c07216135c20 ] The vectorized io_uring NVMe passthru opcodes don't yet support fixed buffers. But since userspace can trigger this condition based on the io_uring SQE parameters, it shouldn't cause a kernel warning. Signed-off-by: Caleb Sander Mateos Reviewed-by: Jens Axboe Reviewed-by: Chaitanya Kulkarni Reviewed-by: Christoph Hellwig Fixes: 23fd22e55b76 ("nvme: wire up fixed buffer support for nvme passthrough") Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit c35ec5e046ba5c0e410eb3a99771e691ea093170 Author: Björn Töpel Date: Fri Mar 28 09:53:11 2025 +0100 riscv/purgatory: 4B align purgatory_start [ Upstream commit 3f7023171df43641a8a8a1c9a12124501e589010 ] When a crashkernel is launched on RISC-V, the entry to purgatory is done by trapping via the stvec CSR. From riscv_kexec_norelocate(): | ... | /* | * Switch to physical addressing | * This will also trigger a jump to CSR_STVEC | * which in this case is the address of the new | * kernel. | */ | csrw CSR_STVEC, a2 | csrw CSR_SATP, zero stvec requires that the address is 4B aligned, which was not the case, e.g.: | Loaded purgatory at 0xffffc000 | kexec_file: kexec_file_load: type:1, start:0xffffd232 head:0x4 flags:0x6 The address 0xffffd232 not 4B aligned. Correct by adding proper function alignment. With this change, crashkernels loaded with kexec-file will be able to properly enter the purgatory. Fixes: 736e30af583fb ("RISC-V: Add purgatory") Signed-off-by: Björn Töpel Reviewed-by: Alexandre Ghiti Link: https://lore.kernel.org/r/20250328085313.1193815-1-bjorn@kernel.org Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit 4c6b1d08e61460949021011353604a06ff515e85 Author: Yao Zi Date: Wed Mar 26 05:14:46 2025 +0000 riscv/kexec_file: Handle R_RISCV_64 in purgatory relocator [ Upstream commit 28093cfef5dd62f4cbd537f2bdf6f0bf85309c45 ] Commit 58ff537109ac ("riscv: Omit optimized string routines when using KASAN") introduced calls to EXPORT_SYMBOL() in assembly string routines, which result in R_RISCV_64 relocations against .export_symbol section. As these rountines are reused by RISC-V purgatory and our relocator doesn't recognize these relocations, this fails kexec-file-load with dmesg like [ 11.344251] kexec_image: Unknown rela relocation: 2 [ 11.345972] kexec_image: Error loading purgatory ret=-8 Let's support R_RISCV_64 relocation to fix kexec on 64-bit RISC-V. 32-bit variant isn't covered since KEXEC_FILE and KEXEC_PURGATORY isn't available. Fixes: 58ff537109ac ("riscv: Omit optimized string routines when using KASAN") Signed-off-by: Yao Zi Tested-by: Björn Töpel Reviewed-by: Björn Töpel Link: https://lore.kernel.org/r/20250326051445.55131-2-ziyao@disroot.org Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit be85b932b57864599905021e1070adf4eb292860 Author: Alexandre Ghiti Date: Mon Mar 17 08:25:51 2025 +0100 riscv: Fix hugetlb retrieval of number of ptes in case of !present pte [ Upstream commit 83d78ac677b9fdd8ea763507c6fe02d6bf415f3a ] Ryan sent a fix [1] for arm64 that applies to riscv too: in some hugetlb functions, we must not use the pte value to get the size of a mapping because the pte may not be present. So use the already present size parameter for huge_pte_clear() and the newly introduced size parameter for huge_ptep_get_and_clear(). And make sure to gather A/D bits only on present ptes. Fixes: 82a1a1f3bfb6 ("riscv: mm: support Svnapot in hugetlb page") Link: https://lore.kernel.org/all/20250217140419.1702389-1-ryan.roberts@arm.com/ [1] Link: https://lore.kernel.org/r/20250317072551.572169-1-alexghiti@rivosinc.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit e50781bf7accc75883cb8a6a9921fb4e2fa8cca4 Author: Josh Poimboeuf Date: Mon Mar 31 08:33:32 2025 -0700 spi: cadence: Fix out-of-bounds array access in cdns_mrvl_xspi_setup_clock() [ Upstream commit 7ba0847fa1c22e7801cebfe5f7b75aee4fae317e ] If requested_clk > 128, cdns_mrvl_xspi_setup_clock() iterates over the entire cdns_mrvl_xspi_clk_div_list array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, clamping the clock to the minimum 6.25 MHz. Fixes the following warning with an UBSAN kernel: vmlinux.o: warning: objtool: cdns_mrvl_xspi_setup_clock: unexpected end of section .text.cdns_mrvl_xspi_setup_clock Fixes: 26d34fdc4971 ("spi: cadence: Add clock configuration for Marvell xSPI overlay") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202503282236.UhfRsF3B-lkp@intel.com/ Link: https://lore.kernel.org/r/gs2ooxfkblnee6cc5yfcxh7nu4wvoqnuv4lrllkhccxgcac2jg@7snmwd73jkhs Signed-off-by: Josh Poimboeuf Link: https://patch.msgid.link/h6bef6wof6zpjfp3jbhrkigqsnykdfy6j4qmmvb6gsabhianhj@k57a7hwpa3bj Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d3b862658669dfeb007d4b312556e526439e8129 Author: Christophe JAILLET Date: Sat Mar 22 08:45:49 2025 +0100 ASoC: codecs: rt5665: Fix some error handling paths in rt5665_probe() [ Upstream commit 1ebd4944266e86a7ce274f197847f5a6399651e8 ] Should an error occur after a successful regulator_bulk_enable() call, regulator_bulk_disable() should be called, as already done in the remove function. Instead of adding an error handling path in the probe, switch from devm_regulator_bulk_get() to devm_regulator_bulk_get_enable() and simplify the remove function and some other places accordingly. Finally, add a missing const when defining rt5665_supply_names to please checkpatch and constify a few bytes. Fixes: 33ada14a26c8 ("ASoC: add rt5665 codec driver") Signed-off-by: Christophe JAILLET Link: https://patch.msgid.link/e3c2aa1b2fdfa646752d94f4af968630c0d58248.1742629525.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c76bb2d0aa54d8be4102e5480fa6bec353381699 Author: Sven Schnelle Date: Thu Mar 20 13:25:38 2025 +0100 s390/entry: Fix setting _CIF_MCCK_GUEST with lowcore relocation [ Upstream commit 121df45b37a1016ee6828c2ca3ba825f3e18a8c1 ] When lowcore relocation is enabled, the machine check handler doesn't use the lowcore address when setting _CIF_MCCK_GUEST. Fix this by adding the missing base register. Fixes: 0001b7bbc53a ("s390/entry: Make mchk_int_handler() ready for lowcore relocation") Reported-by: Heiko Carstens Reviewed-by: Heiko Carstens Signed-off-by: Sven Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 7e3497d7dacb5aee69dd9be842b778083cae0e75 Author: Ming Lei Date: Thu Mar 27 17:51:10 2025 +0800 ublk: make sure ubq->canceling is set when queue is frozen [ Upstream commit 8741d0737921ec1c03cf59aebf4d01400c2b461a ] Now ublk driver depends on `ubq->canceling` for deciding if the request can be dispatched via uring_cmd & io_uring_cmd_complete_in_task(). Once ubq->canceling is set, the uring_cmd can be done via ublk_cancel_cmd() and io_uring_cmd_done(). So set ubq->canceling when queue is frozen, this way makes sure that the flag can be observed from ublk_queue_rq() reliably, and avoids use-after-free on uring_cmd. Fixes: 216c8f5ef0f2 ("ublk: replace monitor with cancelable uring_cmd") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20250327095123.179113-2-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit efd101b1f0f5144ffe422b01a7cce823201a5e08 Author: Herton R. Krzesinski Date: Thu Mar 20 11:22:13 2025 -0300 x86/uaccess: Improve performance by aligning writes to 8 bytes in copy_user_generic(), on non-FSRM/ERMS CPUs [ Upstream commit b5322b6ec06a6c58650f52abcd2492000396363b ] History of the performance regression: ====================================== Since the following series of user copy updates were merged upstream ~2 years ago via: a5624566431d ("Merge branch 'x86-rep-insns': x86 user copy clarifications") .. copy_user_generic() on x86_64 stopped doing alignment of the writes to the destination to a 8 byte boundary for the non FSRM case. Previously, this was done through the ALIGN_DESTINATION macro that was used in the now removed copy_user_generic_unrolled function. Turns out this change causes some loss of performance/throughput on some use cases and specific CPU/platforms without FSRM and ERMS. Lately I got two reports of performance/throughput issues after a RHEL 9 kernel pulled the same upstream series with updates to user copy functions. Both reports consisted of running specific networking/TCP related testing using iperf3. Partial upstream fix ==================== The first report was related to a Linux Bridge testing using VMs on a specific machine with an AMD CPU (EPYC 7402), and after a brief investigation it turned out that the later change via: ca96b162bfd2 ("x86: bring back rep movsq for user access on CPUs without ERMS") ... helped/fixed the performance issue. However, after the later commit/fix was applied, then I got another regression reported in a multistream TCP test on a 100Gbit mlx5 nic, also running on an AMD based platform (AMD EPYC 7302 CPU), again that was using iperf3 to run the test. That regression was after applying the later fix/commit, but only this didn't help in telling the whole history. Testing performed to pinpoint residual regression ================================================= So I narrowed down the second regression use case, but running it without traffic through a NIC, on localhost, in trying to narrow down CPU usage and not being limited by other factor like network bandwidth. I used another system also with an AMD CPU (AMD EPYC 7742). Basically, I run iperf3 in server and client mode in the same system, for example: - Start the server binding it to CPU core/thread 19: $ taskset -c 19 iperf3 -D -s -B 127.0.0.1 -p 12000 - Start the client always binding/running on CPU core/thread 17, using perf to get statistics: $ perf stat -o stat.txt taskset -c 17 iperf3 -c 127.0.0.1 -b 0/1000 -V \ -n 50G --repeating-payload -l 16384 -p 12000 --cport 12001 2>&1 \ > stat-19.txt For the client, always running/pinned to CPU 17. But for the iperf3 in server mode, I did test runs using CPUs 19, 21, 23 or not pinned to any specific CPU. So it basically consisted with four runs of the same commands, just changing the CPU which the server is pinned, or without pinning by removing the taskset call before the server command. The CPUs were chosen based on NUMA node they were on, this is the relevant output of lscpu on the system: $ lscpu ... Model name: AMD EPYC 7742 64-Core Processor ... Caches (sum of all): L1d: 2 MiB (64 instances) L1i: 2 MiB (64 instances) L2: 32 MiB (64 instances) L3: 256 MiB (16 instances) NUMA: NUMA node(s): 4 NUMA node0 CPU(s): 0,1,8,9,16,17,24,25,32,33,40,41,48,49,56,57,64,65,72,73,80,81,88,89,96,97,104,105,112,113,120,121 NUMA node1 CPU(s): 2,3,10,11,18,19,26,27,34,35,42,43,50,51,58,59,66,67,74,75,82,83,90,91,98,99,106,107,114,115,122,123 NUMA node2 CPU(s): 4,5,12,13,20,21,28,29,36,37,44,45,52,53,60,61,68,69,76,77,84,85,92,93,100,101,108,109,116,117,124,125 NUMA node3 CPU(s): 6,7,14,15,22,23,30,31,38,39,46,47,54,55,62,63,70,71,78,79,86,87,94,95,102,103,110,111,118,119,126,127 ... So for the server run, when picking a CPU, I chose CPUs to be not on the same node. The reason is with that I was able to get/measure relevant performance differences when changing the alignment of the writes to the destination in copy_user_generic. Testing shows up to +81% performance improvement under iperf3 ============================================================= Here's a summary of the iperf3 runs: # Vanilla upstream alignment: CPU RATE SYS TIME sender-receiver Server bind 19: 13.0Gbits/sec 28.371851000 33.233499566 86.9%-70.8% Server bind 21: 12.9Gbits/sec 28.283381000 33.586486621 85.8%-69.9% Server bind 23: 11.1Gbits/sec 33.660190000 39.012243176 87.7%-64.5% Server bind none: 18.9Gbits/sec 19.215339000 22.875117865 86.0%-80.5% # With the attached patch (aligning writes in non ERMS/FSRM case): CPU RATE SYS TIME sender-receiver Server bind 19: 20.8Gbits/sec 14.897284000 20.811101382 75.7%-89.0% Server bind 21: 20.4Gbits/sec 15.205055000 21.263165909 75.4%-89.7% Server bind 23: 20.2Gbits/sec 15.433801000 21.456175000 75.5%-89.8% Server bind none: 26.1Gbits/sec 12.534022000 16.632447315 79.8%-89.6% So I consistently got better results when aligning the write. The results above were run on 6.14.0-rc6/rc7 based kernels. The sys is sys time and then the total time to run/transfer 50G of data. The last field is the CPU usage of sender/receiver iperf3 process. It's also worth to note that each pair of iperf3 runs may get slightly different results on each run, but I always got consistent higher results with the write alignment for this specific test of running the processes on CPUs in different NUMA nodes. Linus Torvalds helped/provided this version of the patch. Initially I proposed a version which aligned writes for all cases in rep_movs_alternative, however it used two extra registers and thus Linus provided an enhanced version that only aligns the write on the large_movsq case, which is sufficient since the problem happens only on those AMD CPUs like ones mentioned above without ERMS/FSRM, and also doesn't require using extra registers. Also, I validated that aligning only on large_movsq case is really enough for getting the performance back. I also tested this patch on an old Intel based non-ERMS/FRMS system (with Xeon E5-2667 - Sandy Bridge based) and didn't get any problems: no performance enhancement but also no regression either, using the same iperf3 based benchmark. Also newer Intel processors after Sandy Bridge usually have ERMS and should not be affected by this change. [ mingo: Updated the changelog. ] Fixes: ca96b162bfd2 ("x86: bring back rep movsq for user access on CPUs without ERMS") Fixes: 034ff37d3407 ("x86: rewrite '__copy_user_nocache' function") Reported-by: Ondrej Lichtner Co-developed-by: Linus Torvalds Signed-off-by: Linus Torvalds Signed-off-by: Herton R. Krzesinski Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250320142213.2623518-1-herton@redhat.com Signed-off-by: Sasha Levin commit 0751db851374023be9c75ae7e506d0aa058056fd Author: Palmer Dabbelt Date: Wed Mar 26 15:45:07 2025 -0700 RISC-V: errata: Use medany for relocatable builds [ Upstream commit bb58e1579f431d42469b6aed0f03eff383ba6db5 ] We're trying to mix non-PIC/PIE objects into the otherwise-PIE relocatable kernels, to avoid GOT/PLT references during early boot alternative resolution (which happens before the GOT/PLT are set up). riscv64-unknown-linux-gnu-ld: arch/riscv/errata/sifive/errata.o: relocation R_RISCV_HI20 against `tlb_flush_all_threshold' can not be used when making a shared object; recompile with -fPIC riscv64-unknown-linux-gnu-ld: arch/riscv/errata/thead/errata.o: relocation R_RISCV_HI20 against `riscv_cbom_block_size' can not be used when making a shared object; recompile with -fPIC Fixes: 8dc2a7e8027f ("riscv: Fix relocatable kernels with early alternatives using -fno-pie") Link: https://lore.kernel.org/r/20250326224506.27165-2-palmer@rivosinc.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 92a25feb4546a6c55838d38c6c54d9b04527ad04 Author: Takashi Iwai Date: Wed Mar 26 16:22:01 2025 +0100 ALSA: hda/realtek: Fix built-in mic breakage on ASUS VivoBook X515JA [ Upstream commit 84c3c08f5a6c2e2209428b76156bcaf349c3a62d ] ASUS VivoBook X515JA with PCI SSID 1043:14f2 also hits the same issue as other VivoBook model about the mic pin assignment, and the same workaround is required to apply ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk. Fixes: 3b4309546b48 ("ALSA: hda: Fix headset detection failure due to unstable sort") Link: https://bugzilla.kernel.org/show_bug.cgi?id=219902 Link: https://patch.msgid.link/20250326152205.26733-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 26d14768c4baea1d53182f5bcacbc45c5187d539 Author: Richard Fitzgerald Date: Sun Mar 23 17:05:29 2025 +0000 firmware: cs_dsp: Ensure cs_dsp_load[_coeff]() returns 0 on success [ Upstream commit 2593f7e0dc93a898a84220b3fb180d86f1ca8c60 ] Set ret = 0 on successful completion of the processing loop in cs_dsp_load() and cs_dsp_load_coeff() to ensure that the function returns 0 on success. All normal firmware files will have at least one data block, and processing this block will set ret == 0, from the result of either regmap_raw_write() or cs_dsp_parse_coeff(). The kunit tests create a dummy firmware file that contains only the header, without any data blocks. This gives cs_dsp a file to "load" that will not cause any side-effects. As there aren't any data blocks, the processing loop will not set ret == 0. Originally there was a line after the processing loop: ret = regmap_async_complete(regmap); which would set ret == 0 before the function returned. Commit fe08b7d5085a ("firmware: cs_dsp: Remove async regmap writes") changed the regmap write to a normal sync write, so the call to regmap_async_complete() wasn't necessary and was removed. It was overlooked that the ret here wasn't only to check the result of regmap_async_complete(), it also set the final return value of the function. Fixes: fe08b7d5085a ("firmware: cs_dsp: Remove async regmap writes") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20250323170529.197205-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3dbb73a07579a08362a865da43e46b4d0cae2bf1 Author: Nikita Shubin Date: Thu Jun 6 11:15:19 2024 +0300 ntb: intel: Fix using link status DB's [ Upstream commit 8144e9c8f30fb23bb736a5d24d5c9d46965563c4 ] Make sure we are not using DB's which were remapped for link status. Fixes: f6e51c354b60 ("ntb: intel: split out the gen3 code") Signed-off-by: Nikita Shubin Reviewed-by: Dave Jiang Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit cb153bdc1812a3375639ed6ca5f147eaefb65349 Author: Yajun Deng Date: Wed Aug 16 16:33:05 2023 +0800 ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_trans [ Upstream commit de203da734fae00e75be50220ba5391e7beecdf9 ] There is a kernel API ntb_mw_clear_trans() would pass 0 to both addr and size. This would make xlate_pos negative. [ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000 [ 23.734158] ================================================================================ [ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7 [ 23.734418] shift exponent -1 is negative Ensuring xlate_pos is a positive or zero before BIT. Fixes: 1e2fd202f859 ("ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()") Signed-off-by: Yajun Deng Reviewed-by: Logan Gunthorpe Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 4119e80ce22df78b18f291c0e9891edace607b2f Author: Juhan Jin Date: Thu Feb 6 13:28:36 2025 -0600 riscv: ftrace: Add parentheses in macro definitions of make_call_t0 and make_call_ra [ Upstream commit 5f1a58ed91a040d4625d854f9bb3dd4995919202 ] This patch adds parentheses to parameters caller and callee of macros make_call_t0 and make_call_ra. Every existing invocation of these two macros uses a single variable for each argument, so the absence of the parentheses seems okay. However, future invocations might use more complex expressions as arguments. For example, a future invocation might look like this: make_call_t0(a - b, c, call). Without parentheses in the macro definition, the macro invocation expands to: ... unsigned int offset = (unsigned long) c - (unsigned long) a - b; ... which is clearly wrong. The use of parentheses ensures arguments are correctly evaluated and potentially saves future users of make_call_t0 and make_call_ra debugging trouble. Fixes: 6724a76cff85 ("riscv: ftrace: Reduce the detour code size to half") Signed-off-by: Juhan Jin Reviewed-by: Alexandre Ghiti Link: https://lore.kernel.org/r/tencent_AE90AA59903A628E87E9F80E563DA5BA5508@qq.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit 8522051c58d68146b93e8a5ba9987e83b3d64e7b Author: Christian Schoenebeck Date: Thu Mar 13 13:59:32 2025 +0100 fs/9p: fix NULL pointer dereference on mkdir [ Upstream commit 3f61ac7c65bdb26accb52f9db66313597e759821 ] When a 9p tree was mounted with option 'posixacl', parent directory had a default ACL set for its subdirectories, e.g.: setfacl -m default:group:simpsons:rwx parentdir then creating a subdirectory crashed 9p client, as v9fs_fid_add() call in function v9fs_vfs_mkdir_dotl() sets the passed 'fid' pointer to NULL (since dafbe689736) even though the subsequent v9fs_set_create_acl() call expects a valid non-NULL 'fid' pointer: [ 37.273191] BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 37.322338] Call Trace: [ 37.323043] [ 37.323621] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 37.324448] ? page_fault_oops (arch/x86/mm/fault.c:714) [ 37.325532] ? search_module_extables (kernel/module/main.c:3733) [ 37.326742] ? p9_client_walk (net/9p/client.c:1165) 9pnet [ 37.328006] ? search_bpf_extables (kernel/bpf/core.c:804) [ 37.329142] ? exc_page_fault (./arch/x86/include/asm/paravirt.h:686 arch/x86/mm/fault.c:1488 arch/x86/mm/fault.c:1538) [ 37.330196] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:574) [ 37.331330] ? p9_client_walk (net/9p/client.c:1165) 9pnet [ 37.332562] ? v9fs_fid_xattr_get (fs/9p/xattr.c:30) 9p [ 37.333824] v9fs_fid_xattr_set (fs/9p/fid.h:23 fs/9p/xattr.c:121) 9p [ 37.335077] v9fs_set_acl (fs/9p/acl.c:276) 9p [ 37.336112] v9fs_set_create_acl (fs/9p/acl.c:307) 9p [ 37.337326] v9fs_vfs_mkdir_dotl (fs/9p/vfs_inode_dotl.c:411) 9p [ 37.338590] vfs_mkdir (fs/namei.c:4313) [ 37.339535] do_mkdirat (fs/namei.c:4336) [ 37.340465] __x64_sys_mkdir (fs/namei.c:4354) [ 37.341455] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) [ 37.342447] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Fix this by simply swapping the sequence of these two calls in v9fs_vfs_mkdir_dotl(), i.e. calling v9fs_set_create_acl() before v9fs_fid_add(). Fixes: dafbe689736f ("9p fid refcount: cleanup p9_fid_put calls") Reported-by: syzbot+5b667f9a1fee4ba3775a@syzkaller.appspotmail.com Signed-off-by: Christian Schoenebeck Message-ID: Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit d04600f43569d48262e1328eaa1592fcefa2c19c Author: Al Viro Date: Wed Mar 12 19:38:28 2025 -0400 spufs: fix a leak in spufs_create_context() [ Upstream commit 0f5cce3fc55b08ee4da3372baccf4bcd36a98396 ] Leak fixes back in 2008 missed one case - if we are trying to set affinity and spufs_mkdir() fails, we need to drop the reference to neighbor. Fixes: 58119068cb27 "[POWERPC] spufs: Fix memory leak on SPU affinity" Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 029d8c711f5e5fe8cf63e8a4a1a140a06e224e45 Author: Al Viro Date: Wed Mar 12 19:18:39 2025 -0400 spufs: fix gang directory lifetimes [ Upstream commit c134deabf4784e155d360744d4a6a835b9de4dd4 ] prior to "[POWERPC] spufs: Fix gang destroy leaks" we used to have a problem with gang lifetimes - creation of a gang returns opened gang directory, which normally gets removed when that gets closed, but if somebody has created a context belonging to that gang and kept it alive until the gang got closed, removal failed and we ended up with a leak. Unfortunately, it had been fixed the wrong way. Dentry of gang directory was no longer pinned, and rmdir on close was gone. One problem was that failure of open kept calling simple_rmdir() as cleanup, which meant an unbalanced dput(). Another bug was in the success case - gang creation incremented link count on root directory, but that was no longer undone when gang got destroyed. Fix consists of * reverting the commit in question * adding a counter to gang, protected by ->i_rwsem of gang directory inode. * having it set to 1 at creation time, dropped in both spufs_dir_close() and spufs_gang_close() and bumped in spufs_create_context(), provided that it's not 0. * using simple_recursive_removal() to take the gang directory out when counter reaches zero. Fixes: 877907d37da9 "[POWERPC] spufs: Fix gang destroy leaks" Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 35f789ccebd69f6f9a1e0a9b85435003b2450065 Author: Al Viro Date: Sat Mar 8 19:26:31 2025 -0500 spufs: fix a leak on spufs_new_file() failure [ Upstream commit d1ca8698ca1332625d83ea0d753747be66f9906d ] It's called from spufs_fill_dir(), and caller of that will do spufs_rmdir() in case of failure. That does remove everything we'd managed to create, but... the problem dentry is still negative. IOW, it needs to be explicitly dropped. Fixes: 3f51dd91c807 "[PATCH] spufs: fix spufs_fill_dir error path" Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 7a95b4887348d04985c0ce455c3dc6804da55079 Author: David Howells Date: Fri Mar 14 16:41:59 2025 +0000 netfs: Fix netfs_unbuffered_read() to return ssize_t rather than int [ Upstream commit 07c574eb53d4cc9aa7b985bc8bfcb302e5dc4694 ] Fix netfs_unbuffered_read() to return an ssize_t rather than an int as netfs_wait_for_read() returns ssize_t and this gets implicitly truncated. Signed-off-by: David Howells Link: https://lore.kernel.org/r/20250314164201.1993231-5-dhowells@redhat.com Acked-by: "Paulo Alcantara (Red Hat)" cc: Jeff Layton cc: Viacheslav Dubeyko cc: Alex Markuze cc: Ilya Dryomov cc: ceph-devel@vger.kernel.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 8a2cc9ffd13c1b6ebed12ddbd9dbd6468f71fcff Author: Tasos Sahanidis Date: Wed Mar 12 05:08:32 2025 +0200 hwmon: (nct6775-core) Fix out of bounds access for NCT679{8,9} [ Upstream commit 815f80ad20b63830949a77c816e35395d5d55144 ] pwm_num is set to 7 for these chips, but NCT6776_REG_PWM_MODE and NCT6776_PWM_MODE_MASK only contain 6 values. Fix this by adding another 0 to the end of each array. Signed-off-by: Tasos Sahanidis Link: https://lore.kernel.org/r/20250312030832.106475-1-tasos@tasossah.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit bc08c087118efb3b5140bdbb4a2e75e97391e64e Author: Roger Quadros Date: Mon Mar 10 15:15:14 2025 +0100 memory: omap-gpmc: drop no compatible check [ Upstream commit edcccc6892f65eff5fd3027a13976131dc7fd733 ] We are no longer depending on legacy device trees so drop the no compatible check for NAND and OneNAND nodes. Suggested-by: Rob Herring (Arm) Signed-off-by: Roger Quadros Reviewed-by: Rob Herring (Arm) Link: https://lore.kernel.org/r/20250114-omap-gpmc-drop-no-compatible-check-v1-1-262c8d549732@kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit d840c84cdddd73787056aa1845a06e1272614028 Author: Oliver Hartkopp Date: Mon Mar 10 15:33:53 2025 +0100 can: statistics: use atomic access in hot path [ Upstream commit 80b5f90158d1364cbd80ad82852a757fc0692bf2 ] In can_send() and can_receive() CAN messages and CAN filter matches are counted to be visible in the CAN procfs files. KCSAN detected a data race within can_send() when two CAN frames have been generated by a timer event writing to the same CAN netdevice at the same time. Use atomic operations to access the statistics in the hot path to fix the KCSAN complaint. Reported-by: syzbot+78ce4489b812515d5e4d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67cd717d.050a0220.e1a89.0006.GAE@google.com Signed-off-by: Oliver Hartkopp Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/20250310143353.3242-1-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 54c198d672ca1016bf57e9acc3b7aaa0e5fd2a0a Author: Navon John Lukose Date: Sat Mar 8 03:03:19 2025 +0530 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion x360 14-dy1xxx [ Upstream commit b11a74ac4f545626d0dc95a8ca8c41df90532bf3 ] Add a fixup to enable the mute LED on HP Pavilion x360 Convertible 14-dy1xxx with ALC295 codec. The appropriate coefficient index and bits were identified through a brute-force method, as detailed in https://bbs.archlinux.org/viewtopic.php?pid=2079504#p2079504. Signed-off-by: Navon John Lukose Link: https://patch.msgid.link/20250307213319.35507-1-navonjohnlukose@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a3612053b2e7a2f91f3a39d1c3154f8704596342 Author: Florian Westphal Date: Tue Mar 11 12:52:45 2025 +0100 selftests: netfilter: skip br_netfilter queue tests if kernel is tainted [ Upstream commit c21b02fd9cbf15aed6e32c89e0fd70070281e3d1 ] These scripts fail if the kernel is tainted which leads to wrong test failure reports in CI environments when an unrelated test triggers some splat. Check taint state at start of script and SKIP if its already dodgy. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 93c59b5548ee8f833a3cebeab9126e3dd7219f9e Author: Taehee Yoo Date: Sun Mar 9 13:42:18 2025 +0000 net: devmem: do not WARN conditionally after netdev_rx_queue_restart() [ Upstream commit a70f891e0fa0435379ad4950e156a15a4ef88b4d ] When devmem socket is closed, netdev_rx_queue_restart() is called to reset queue by the net_devmem_unbind_dmabuf(). But callback may return -ENETDOWN if the interface is down because queues are already freed when the interface is down so queue reset is not needed. So, it should not warn if the return value is -ENETDOWN. Signed-off-by: Taehee Yoo Reviewed-by: Mina Almasry Link: https://patch.msgid.link/20250309134219.91670-8-ap420073@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cf1b90486748fc7251794074aeacb779ac9befb2 Author: Mario Limonciello Date: Thu Mar 6 12:51:24 2025 -0600 drm/amd: Keep display off while going into S4 [ Upstream commit 4afacc9948e1f8fdbca401d259ae65ad93d298c0 ] When userspace invokes S4 the flow is: 1) amdgpu_pmops_prepare() 2) amdgpu_pmops_freeze() 3) Create hibernation image 4) amdgpu_pmops_thaw() 5) Write out image to disk 6) Turn off system Then on resume amdgpu_pmops_restore() is called. This flow has a problem that because amdgpu_pmops_thaw() is called it will call amdgpu_device_resume() which will resume all of the GPU. This includes turning the display hardware back on and discovering connectors again. This is an unexpected experience for the display to turn back on. Adjust the flow so that during the S4 sequence display hardware is not turned back on. Reported-by: Xaver Hugl Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2038 Cc: Muhammad Usama Anjum Tested-by: Muhammad Usama Anjum Acked-by: Alex Deucher Acked-by: Harry Wentland Link: https://lore.kernel.org/r/20250306185124.44780-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 68bfdc8dc0a1a7fdd9ab61e69907ae71a6fd3d91) Signed-off-by: Sasha Levin commit 3e6ce0d9ec796860af31fcd77fe4120dd3c73d56 Author: Keith Busch Date: Thu Mar 6 14:25:57 2025 -0800 nvme-pci: fix stuck reset on concurrent DPC and HP [ Upstream commit 3f674e7b670b7b7d9261935820e4eba3c059f835 ] The PCIe error handling has the nvme driver quiesce the device, attempt to restart it, then wait for that restart to complete. A PCIe DPC event also toggles the PCIe link. If the slot doesn't have out-of-band presence detection, this will trigger a pciehp re-enumeration. The error handling that calls nvme_error_resume is holding the device lock while this happens. This lock blocks pciehp's request to disconnect the driver from proceeding. Meanwhile the nvme's reset can't make forward progress because its device isn't there anymore with outstanding IO, and the timeout handler won't do anything to fix it because the device is undergoing error handling. End result: deadlocked. Fix this by having the timeout handler short cut the disabling for a disconnected PCIe device. The downside is that we're relying on an IO timeout to clean up this mess, which could be a minute by default. Tested-by: Nilay Shroff Reviewed-by: Nilay Shroff Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 5e194e0f77ee5c5c1e9ab2b6114fbfdd1bbce519 Author: Vladis Dronov Date: Sun Mar 9 18:22:16 2025 +0100 x86/sgx: Warn explicitly if X86_FEATURE_SGX_LC is not enabled [ Upstream commit 65be5c95d08eedda570a6c888a12384c77fe7614 ] The kernel requires X86_FEATURE_SGX_LC to be able to create SGX enclaves, not just X86_FEATURE_SGX. There is quite a number of hardware which has X86_FEATURE_SGX but not X86_FEATURE_SGX_LC. A kernel running on such hardware does not create the /dev/sgx_enclave file and does so silently. Explicitly warn if X86_FEATURE_SGX_LC is not enabled to properly notify users that the kernel disabled the SGX driver. The X86_FEATURE_SGX_LC, a.k.a. SGX Launch Control, is a CPU feature that enables LE (Launch Enclave) hash MSRs to be writable (with additional opt-in required in the 'feature control' MSR) when running enclaves, i.e. using a custom root key rather than the Intel proprietary key for enclave signing. I've hit this issue myself and have spent some time researching where my /dev/sgx_enclave file went on SGX-enabled hardware. Related links: https://github.com/intel/linux-sgx/issues/837 https://patchwork.kernel.org/project/platform-driver-x86/patch/20180827185507.17087-3-jarkko.sakkinen@linux.intel.com/ [ mingo: Made the error message a bit more verbose, and added other cases where the kernel fails to create the /dev/sgx_enclave device node. ] Signed-off-by: Vladis Dronov Signed-off-by: Ingo Molnar Acked-by: Kai Huang Cc: Jarkko Sakkinen Cc: Andy Lutomirski Cc: Sean Christopherson Cc: Linus Torvalds Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250309172215.21777-2-vdronov@redhat.com Signed-off-by: Sasha Levin commit eafd7ec55b1de96478bddf52de3cc7ac0d71a599 Author: Michael Kelley Date: Wed Feb 26 12:06:06 2025 -0800 x86/hyperv: Fix output argument to hypercall that changes page visibility [ Upstream commit 09beefefb57bbc3a06d98f319d85db4d719d7bcb ] The hypercall in hv_mark_gpa_visibility() is invoked with an input argument and an output argument. The output argument ostensibly returns the number of pages that were processed. But in fact, the hypercall does not provide any output, so the output argument is spurious. The spurious argument is harmless because Hyper-V ignores it, but in the interest of correctness and to avoid the potential for future problems, remove it. Signed-off-by: Michael Kelley Reviewed-by: Nuno Das Neves Link: https://lore.kernel.org/r/20250226200612.2062-2-mhklinux@outlook.com Signed-off-by: Wei Liu Message-ID: <20250226200612.2062-2-mhklinux@outlook.com> Signed-off-by: Sasha Levin commit ddf40162ac79acd0d3882501e3de48db6ed008da Author: Waiman Long Date: Fri Mar 7 15:26:52 2025 -0800 locking/semaphore: Use wake_q to wake up processes outside lock critical section [ Upstream commit 85b2b9c16d053364e2004883140538e73b333cdb ] A circular lock dependency splat has been seen involving down_trylock(): ====================================================== WARNING: possible circular locking dependency detected 6.12.0-41.el10.s390x+debug ------------------------------------------------------ dd/32479 is trying to acquire lock: 0015a20accd0d4f8 ((console_sem).lock){-.-.}-{2:2}, at: down_trylock+0x26/0x90 but task is already holding lock: 000000017e461698 (&zone->lock){-.-.}-{2:2}, at: rmqueue_bulk+0xac/0x8f0 the existing dependency chain (in reverse order) is: -> #4 (&zone->lock){-.-.}-{2:2}: -> #3 (hrtimer_bases.lock){-.-.}-{2:2}: -> #2 (&rq->__lock){-.-.}-{2:2}: -> #1 (&p->pi_lock){-.-.}-{2:2}: -> #0 ((console_sem).lock){-.-.}-{2:2}: The console_sem -> pi_lock dependency is due to calling try_to_wake_up() while holding the console_sem raw_spinlock. This dependency can be broken by using wake_q to do the wakeup instead of calling try_to_wake_up() under the console_sem lock. This will also make the semaphore's raw_spinlock become a terminal lock without taking any further locks underneath it. The hrtimer_bases.lock is a raw_spinlock while zone->lock is a spinlock. The hrtimer_bases.lock -> zone->lock dependency happens via the debug_objects_fill_pool() helper function in the debugobjects code. -> #4 (&zone->lock){-.-.}-{2:2}: __lock_acquire+0xe86/0x1cc0 lock_acquire.part.0+0x258/0x630 lock_acquire+0xb8/0xe0 _raw_spin_lock_irqsave+0xb4/0x120 rmqueue_bulk+0xac/0x8f0 __rmqueue_pcplist+0x580/0x830 rmqueue_pcplist+0xfc/0x470 rmqueue.isra.0+0xdec/0x11b0 get_page_from_freelist+0x2ee/0xeb0 __alloc_pages_noprof+0x2c2/0x520 alloc_pages_mpol_noprof+0x1fc/0x4d0 alloc_pages_noprof+0x8c/0xe0 allocate_slab+0x320/0x460 ___slab_alloc+0xa58/0x12b0 __slab_alloc.isra.0+0x42/0x60 kmem_cache_alloc_noprof+0x304/0x350 fill_pool+0xf6/0x450 debug_object_activate+0xfe/0x360 enqueue_hrtimer+0x34/0x190 __run_hrtimer+0x3c8/0x4c0 __hrtimer_run_queues+0x1b2/0x260 hrtimer_interrupt+0x316/0x760 do_IRQ+0x9a/0xe0 do_irq_async+0xf6/0x160 Normally a raw_spinlock to spinlock dependency is not legitimate and will be warned if CONFIG_PROVE_RAW_LOCK_NESTING is enabled, but debug_objects_fill_pool() is an exception as it explicitly allows this dependency for non-PREEMPT_RT kernel without causing PROVE_RAW_LOCK_NESTING lockdep splat. As a result, this dependency is legitimate and not a bug. Anyway, semaphore is the only locking primitive left that is still using try_to_wake_up() to do wakeup inside critical section, all the other locking primitives had been migrated to use wake_q to do wakeup outside of the critical section. It is also possible that there are other circular locking dependencies involving printk/console_sem or other existing/new semaphores lurking somewhere which may show up in the future. Let just do the migration now to wake_q to avoid headache like this. Reported-by: yzbot+ed801a886dfdbfe7136d@syzkaller.appspotmail.com Signed-off-by: Waiman Long Signed-off-by: Boqun Feng Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250307232717.1759087-3-boqun.feng@gmail.com Signed-off-by: Sasha Levin commit e401fa5b953e9b393da4eb7034ee6b7ada4a135b Author: Johannes Berg Date: Thu Mar 6 12:37:58 2025 +0200 wifi: mac80211: fix SA Query processing in MLO [ Upstream commit 9a267ce4a3fca93a34a8881046f97bcf472228c8 ] When MLO is used and SA Query processing isn't done by userspace (e.g. wpa_supplicant w/o CONFIG_OCV), then the mac80211 code kicks in but uses the wrong addresses. Fix them. Signed-off-by: Johannes Berg Reviewed-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250306123626.bab48bb49061.I9391b22f1360d20ac8c4e92604de23f27696ba8f@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9465e09b74ebab124e21790e3a4d37cc5d8dbe0c Author: Emmanuel Grumbach Date: Thu Mar 6 12:37:55 2025 +0200 wifi: mac80211: flush the station before moving it to UN-AUTHORIZED state [ Upstream commit 43e04077170799d0e6289f3e928f727e401b3d79 ] We first want to flush the station to make sure we no longer have any frames being Tx by the station before the station is moved to un-authorized state. Failing to do that will lead to races: a frame may be sent after the station's state has been changed. Since the API clearly states that the driver can't fail the sta_state() transition down the list of state, we can easily flush the station first, and only then call the driver's sta_state(). Signed-off-by: Emmanuel Grumbach Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250306123626.450bc40e8b04.I636ba96843c77f13309c15c9fd6eb0c5a52a7976@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 56e6d4a8877ff6701d83e75f194f016ef8574308 Author: Bard Liao Date: Wed Mar 5 21:41:13 2025 +0800 ASoC: rt1320: set wake_capable = 0 explicitly [ Upstream commit 927e6bec5cf3624665b0a2e9f64a1d32f3d22cdd ] "generic_new_peripheral_assigned: invalid dev_num 1, wake supported 1" is reported by our internal CI test. Rt1320's wake feature is not used in Linux and that's why it is not in the wake_capable_list[] list in intel_auxdevice.c. However, BIOS may set it as wake-capable. Overwrite wake_capable to 0 in the codec driver to align with wake_capable_list[]. Signed-off-by: Bard Liao Reviewed-by: Péter Ujfalusi Reviewed-by: Ranjani Sridharan Acked-by: Shuming Fan Link: https://patch.msgid.link/20250305134113.201326-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f8dfd7c50170cdf68183f73ecb3a3e87a9837081 Author: Alexey Klimov Date: Fri Feb 21 04:40:24 2025 +0000 ASoC: codecs: wsa884x: report temps to hwmon in millidegree of Celsius [ Upstream commit d776f016d24816f15033169dcd081f077b6c10f4 ] Temperatures are reported in units of Celsius however hwmon expects values to be in millidegree of Celsius. Userspace tools observe values close to zero and report it as "Not available" or incorrect values like 0C or 1C. Add a simple conversion to fix that. Before the change: wsa884x-virtual-0 Adapter: Virtual device temp1: +0.0°C -- wsa884x-virtual-0 Adapter: Virtual device temp1: +0.0°C Also reported as N/A before first amplifier power on. After this change and initial wsa884x power on: wsa884x-virtual-0 Adapter: Virtual device temp1: +39.0°C -- wsa884x-virtual-0 Adapter: Virtual device temp1: +37.0°C Tested on sm8550 only. Cc: Krzysztof Kozlowski Cc: Srinivas Kandagatla Signed-off-by: Alexey Klimov Link: https://patch.msgid.link/20250221044024.1207921-1-alexey.klimov@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e1fc76b2bbf36a687b1c060a421d3618326be15e Author: Naman Jain Date: Thu Jan 16 06:12:24 2025 +0000 x86/hyperv/vtl: Stop kernel from probing VTL0 low memory [ Upstream commit 59115e2e25f42924181055ed7cc1d123af7598b7 ] For Linux, running in Hyper-V VTL (Virtual Trust Level), kernel in VTL2 tries to access VTL0 low memory in probe_roms. This memory is not described in the e820 map. Initialize probe_roms call to no-ops during boot for VTL2 kernel to avoid this. The issue got identified in OpenVMM which detects invalid accesses initiated from kernel running in VTL2. Co-developed-by: Saurabh Sengar Signed-off-by: Saurabh Sengar Signed-off-by: Naman Jain Tested-by: Roman Kisel Reviewed-by: Roman Kisel Link: https://lore.kernel.org/r/20250116061224.1701-1-namjain@linux.microsoft.com Signed-off-by: Wei Liu Message-ID: <20250116061224.1701-1-namjain@linux.microsoft.com> Signed-off-by: Sasha Levin commit ecc08c460866de7677e3656440b7d8a4bcae34be Author: Shrikanth Hegde Date: Thu Mar 6 10:59:53 2025 +0530 sched/deadline: Use online cpus for validating runtime [ Upstream commit 14672f059d83f591afb2ee1fff56858efe055e5a ] The ftrace selftest reported a failure because writing -1 to sched_rt_runtime_us returns -EBUSY. This happens when the possible CPUs are different from active CPUs. Active CPUs are part of one root domain, while remaining CPUs are part of def_root_domain. Since active cpumask is being used, this results in cpus=0 when a non active CPUs is used in the loop. Fix it by looping over the online CPUs instead for validating the bandwidth calculations. Signed-off-by: Shrikanth Hegde Signed-off-by: Ingo Molnar Reviewed-by: Juri Lelli Link: https://lore.kernel.org/r/20250306052954.452005-2-sshegde@linux.ibm.com Signed-off-by: Sasha Levin commit c730833bc025de786c63458b1997660457382295 Author: Stefan Binding Date: Wed Mar 5 17:06:51 2025 +0000 ALSA: hda/realtek: Add support for ASUS Zenbook UM3406KA Laptops using CS35L41 HDA [ Upstream commit 8463d2adbe1901247937fcdfe4b525130f6db10b ] Laptop uses 2 CS35L41 Amps with HDA, using External boost with I2C Signed-off-by: Stefan Binding Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250305170714.755794-8-sbinding@opensource.cirrus.com Signed-off-by: Sasha Levin commit 01a27b2dd07fa3c2efc1e94b295edd718c258130 Author: Stefan Binding Date: Wed Mar 5 17:06:50 2025 +0000 ALSA: hda/realtek: Add support for ASUS B5405 and B5605 Laptops using CS35L41 HDA [ Upstream commit c86dd79a7c338fff9bebb9503857e07db9845eca ] Add support for ASUS B5605CCA and B5405CCA. Laptops use 2 CS35L41 Amps with HDA, using Internal boost, with SPI Signed-off-by: Stefan Binding Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250305170714.755794-7-sbinding@opensource.cirrus.com Signed-off-by: Sasha Levin commit 2e2626d1e8db09fc423c08ab8e0c3d313d39ac79 Author: Stefan Binding Date: Wed Mar 5 17:06:49 2025 +0000 ALSA: hda/realtek: Add support for ASUS B3405 and B3605 Laptops using CS35L41 HDA [ Upstream commit 7ab61d0a9a35e32497bcf2233310fec79ee3338f ] Add support for ASUS B3405CCA / P3405CCA, B3605CCA / P3605CCA, B3405CCA, B3605CCA. Laptops use 2 CS35L41 Amps with HDA, using Internal boost, with SPI Signed-off-by: Stefan Binding Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250305170714.755794-6-sbinding@opensource.cirrus.com Signed-off-by: Sasha Levin commit f57ca98c65cd2280bc7e0047d34a86231f294d82 Author: Stefan Binding Date: Wed Mar 5 17:06:48 2025 +0000 ALSA: hda/realtek: Add support for various ASUS Laptops using CS35L41 HDA [ Upstream commit 859a11917001424776e1cca02b762efcabb4044e ] Add support for ASUS B3405CVA, B5405CVA, B5605CVA, B3605CVA. Laptops use 2 CS35L41 Amps with HDA, using Internal boost, with SPI Signed-off-by: Stefan Binding Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250305170714.755794-5-sbinding@opensource.cirrus.com Signed-off-by: Sasha Levin commit ff8ebaf47dced57f5a6a15730ac2dd1d4c3f3569 Author: Stefan Binding Date: Wed Mar 5 17:06:47 2025 +0000 ALSA: hda/realtek: Add support for ASUS ROG Strix G614 Laptops using CS35L41 HDA [ Upstream commit 9120b2b4ad0dad2f6bbb6bcacd0456f806fda62d ] Add support for ASUS G614PH/PM/PP and G614FH/FM/FP. Laptops use 2 CS35L41 Amps with HDA, using Internal boost, with I2C Signed-off-by: Stefan Binding Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250305170714.755794-4-sbinding@opensource.cirrus.com Signed-off-by: Sasha Levin commit 9dcf970c5c38bcbff1446989495d0b01395ca588 Author: Stefan Binding Date: Wed Mar 5 17:06:46 2025 +0000 ALSA: hda/realtek: Add support for ASUS ROG Strix GA603 Laptops using CS35L41 HDA [ Upstream commit 16dc157346dd4404b02b42e73b88604be3652039 ] Add support for ASUS GA603KP, GA603KM and GA603KH. Laptops use 2 CS35L41 Amps with HDA, using Internal boost, with I2C Signed-off-by: Stefan Binding Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250305170714.755794-3-sbinding@opensource.cirrus.com Signed-off-by: Sasha Levin commit c7943f0677d6fc13bb2167c797813dbe440465de Author: Stefan Binding Date: Wed Mar 5 17:06:45 2025 +0000 ALSA: hda/realtek: Add support for ASUS ROG Strix G814 Laptop using CS35L41 HDA [ Upstream commit f2c11231b57b5163bf16cdfd65271d53d61dd996 ] Add support for ASUS G814PH/PM/PP and G814FH/FM/FP. Laptops use 2 CS35L41 Amps with HDA, using Internal boost, with I2C. Signed-off-by: Stefan Binding Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250305170714.755794-2-sbinding@opensource.cirrus.com Signed-off-by: Sasha Levin commit 92075758782c5edb4c67d0da9e47586a624c22f7 Author: Yuezhang Mo Date: Sat Feb 8 17:16:58 2025 +0800 exfat: add a check for invalid data size [ Upstream commit 13940cef95491472760ca261b6713692ece9b946 ] Add a check for invalid data size to avoid corrupted filesystem from being further corrupted. Signed-off-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 77a5ed6b0349f34ec9a3a7d1a668f7e0a28afcfc Author: Shyam Sundar S K Date: Wed Mar 5 10:28:42 2025 +0530 platform/x86/amd/pmf: Update PMF Driver for Compatibility with new PMF-TA [ Upstream commit 376a8c2a144397d9cf2a67d403dd64f4a7ff9104 ] The PMF driver allocates a shared memory buffer using tee_shm_alloc_kernel_buf() for communication with the PMF-TA. The latest PMF-TA version introduces new structures with OEM debug information and additional policy input conditions for evaluating the policy binary. Consequently, the shared memory size must be increased to ensure compatibility between the PMF driver and the updated PMF-TA. To do so, introduce the new PMF-TA UUID and update the PMF shared memory configuration to ensure compatibility with the latest PMF-TA version. Additionally, export the TA UUID. These updates will result in modifications to the prototypes of amd_pmf_tee_init() and amd_pmf_ta_open_session(). Link: https://lore.kernel.org/all/55ac865f-b1c7-fa81-51c4-d211c7963e7e@linux.intel.com/ Reviewed-by: Mario Limonciello Co-developed-by: Patil Rajesh Reddy Signed-off-by: Patil Rajesh Reddy Signed-off-by: Shyam Sundar S K Link: https://lore.kernel.org/r/20250305045842.4117767-2-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 5dd02199143087d5a3b2c79356c1fd4f60044baa Author: Shyam Sundar S K Date: Wed Mar 5 10:28:41 2025 +0530 platform/x86/amd/pmf: Propagate PMF-TA return codes [ Upstream commit 9ba93cb8212d62bccd8b41b8adb6656abf37280a ] In the amd_pmf_invoke_cmd_init() function within the PMF driver ensure that the actual result from the PMF-TA is returned rather than a generic EIO. This change allows for proper handling of errors originating from the PMF-TA. Reviewed-by: Mario Limonciello Co-developed-by: Patil Rajesh Reddy Signed-off-by: Patil Rajesh Reddy Signed-off-by: Shyam Sundar S K Link: https://lore.kernel.org/r/20250305045842.4117767-1-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit f7038ea68fc01a31a2baae74081c03d42ccb9f14 Author: Wentao Guan Date: Fri Feb 14 19:04:18 2025 +0800 HID: i2c-hid: improve i2c_hid_get_report error message [ Upstream commit 723aa55c08c9d1e0734e39a815fd41272eac8269 ] We have two places to print "failed to set a report to ...", use "get a report from" instead of "set a report to", it makes people who knows less about the module to know where the error happened. Before: i2c_hid_acpi i2c-FTSC1000:00: failed to set a report to device: -11 After: i2c_hid_acpi i2c-FTSC1000:00: failed to get a report from device: -11 Signed-off-by: Wentao Guan Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 95459156b3663a05529997e4f8fb9cce86f357de Author: Jakub Kicinski Date: Thu Feb 27 16:45:34 2025 -0800 net: dsa: rtl8366rb: don't prompt users for LED control [ Upstream commit c34424eb3be4c01db831428c0d7d483701ae820f ] Make NET_DSA_REALTEK_RTL8366RB_LEDS a hidden symbol. It seems very unlikely user would want to intentionally disable it. Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20250228004534.3428681-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 64eb31d872fe9b5d809cdac29acec8b9c7958c6a Author: David E. Box Date: Wed Feb 26 13:47:27 2025 -0800 platform/x86/intel/vsec: Add Diamond Rapids support [ Upstream commit f317f38e7fbb15a0d8329289fef8cf034938fb4f ] Add PCI ID for the Diamond Rapids Platforms Signed-off-by: David E. Box Link: https://lore.kernel.org/r/20250226214728.1256747-1-david.e.box@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 10ac73318c3a3cfbbbc90ef3ccf3f4660e3d2bad Author: Dmitry Panchenko Date: Thu Feb 20 17:39:31 2025 +0200 platform/x86: intel-hid: fix volume buttons on Microsoft Surface Go 4 tablet [ Upstream commit 2738d06fb4f01145b24c542fb06de538ffc56430 ] Volume buttons on Microsoft Surface Go 4 tablet didn't send any events. Add Surface Go 4 DMI match to button_array_table to fix this. Signed-off-by: Dmitry Panchenko Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20250220154016.3620917-1-dmitry@d-systems.ee Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 6edee7c63b93e9a676adc8f01af4715020850cc8 Author: Namjae Jeon Date: Wed Feb 12 09:37:57 2025 +0900 cifs: fix incorrect validation for num_aces field of smb_acl [ Upstream commit aa2a739a75ab6f24ef72fb3fdb9192c081eacf06 ] parse_dcal() validate num_aces to allocate ace array. f (num_aces > ULONG_MAX / sizeof(struct smb_ace *)) It is an incorrect validation that we can create an array of size ULONG_MAX. smb_acl has ->size field to calculate actual number of aces in response buffer size. Use this to check invalid num_aces. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit da087905e3270e2291c0afae39a28e7d183e5ec3 Author: Namjae Jeon Date: Wed Feb 12 23:26:09 2025 +0900 smb: common: change the data type of num_aces to le16 [ Upstream commit 62e7dd0a39c2d0d7ff03274c36df971f1b3d2d0d ] 2.4.5 in [MS-DTYP].pdf describe the data type of num_aces as le16. AceCount (2 bytes): An unsigned 16-bit integer that specifies the count of the number of ACE records in the ACL. Change it to le16 and add reserved field to smb_acl struct. Reported-by: Igor Leite Ladessa Tested-by: Igor Leite Ladessa Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 7364420090ac14617ab816bed8cbeaad689799a8 Author: Peter Zijlstra Date: Mon Nov 4 14:39:12 2024 +0100 perf/core: Fix perf_pmu_register() vs. perf_init_event() [ Upstream commit 003659fec9f6d8c04738cb74b5384398ae8a7e88 ] There is a fairly obvious race between perf_init_event() doing idr_find() and perf_pmu_register() doing idr_alloc() with an incompletely initialized PMU pointer. Avoid by doing idr_alloc() on a NULL pointer to register the id, and swizzling the real struct pmu pointer at the end using idr_replace(). Also making sure to not set struct pmu members after publishing the struct pmu, duh. [ introduce idr_cmpxchg() in order to better handle the idr_replace() error case -- if it were to return an unexpected pointer, it will already have replaced the value and there is no going back. ] Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20241104135517.858805880@infradead.org Signed-off-by: Sasha Levin commit fbd3a04bd86f1c4cfe67624f6312f33060a92a5d Author: Daniel Bárta Date: Thu Feb 27 17:12:55 2025 +0100 ALSA: hda: Fix speakers on ASUS EXPERTBOOK P5405CSA 1.0 [ Upstream commit f479ecc5ef15ed8d774968c1a8726a49420f11a0 ] After some digging around I have found that this laptop has Cirrus's smart aplifiers connected to SPI bus (spi1-CSC3551:00-cs35l41-hda). To get them correctly detected and working I had to modify patch_realtek.c with ASUS EXPERTBOOK P5405CSA 1.0 SystemID (0x1043, 0x1f63) and add corresponding hda_quirk (ALC245_FIXUP_CS35L41_SPI_2). Signed-off-by: Daniel Bárta Link: https://patch.msgid.link/20250227161256.18061-2-daniel.barta@trustlab.cz Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 64c707d24cccf3020e0e4019b71a034e8568acdf Author: Antheas Kapenekakis Date: Thu Feb 27 18:51:07 2025 +0100 ALSA: hda/realtek: Fix Asus Z13 2025 audio [ Upstream commit 12784ca33b62fd327631749e6a0cd2a10110a56c ] Use the basic quirk for this type of amplifier. Sound works in speakers, headphones, and microphone. Whereas none worked before. Tested-by: Kyle Gospodnetich Signed-off-by: Antheas Kapenekakis Link: https://patch.msgid.link/20250227175107.33432-3-lkml@antheas.dev Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 83d888b693108367f283a353d2dada04c452b8a7 Author: Simon Tatham Date: Thu Feb 20 08:14:44 2025 +0000 affs: don't write overlarge OFS data block size fields [ Upstream commit 011ea742a25a77bac3d995f457886a67d178c6f0 ] If a data sector on an OFS floppy contains a value > 0x1e8 (the largest amount of data that fits in the sector after its header), then an Amiga reading the file can return corrupt data, by taking the overlarge size at its word and reading past the end of the buffer it read the disk sector into! The cause: when affs_write_end_ofs() writes data to an OFS filesystem, the new size field for a data block was computed by adding the amount of data currently being written (into the block) to the existing value of the size field. This is correct if you're extending the file at the end, but if you seek backwards in the file and overwrite _existing_ data, it can lead to the size field being larger than the maximum legal value. This commit changes the calculation so that it sets the size field to the max of its previous size and the position within the block that we just wrote up to. Signed-off-by: Simon Tatham Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 4fbfb003bba425ed9fb14b1f6439b91b8590e274 Author: Simon Tatham Date: Thu Feb 20 08:14:43 2025 +0000 affs: generate OFS sequence numbers starting at 1 [ Upstream commit e4cf8ec4de4e13f156c1d61977d282d90c221085 ] If I write a file to an OFS floppy image, and try to read it back on an emulated Amiga running Workbench 1.3, the Amiga reports a disk error trying to read the file. (That is, it's unable to read it _at all_, even to copy it to the NIL: device. It isn't a matter of getting the wrong data and being unable to parse the file format.) This is because the 'sequence number' field in the OFS data block header is supposed to be based at 1, but affs writes it based at 0. All three locations changed by this patch were setting the sequence number to a variable 'bidx' which was previously obtained by dividing a file position by bsize, so bidx will naturally use 0 for the first block. Therefore all three should add 1 to that value before writing it into the sequence number field. With this change, the Amiga successfully reads the file. For data block reference: https://wiki.osdev.org/FFS_(Amiga) Signed-off-by: Simon Tatham Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit d8575bdcf8203a2672c24f5625b7a3057dfc108e Author: Matthias Proske Date: Wed Feb 12 19:59:35 2025 +0100 wifi: brcmfmac: keep power during suspend if board requires it [ Upstream commit 8c3170628a9ce24a59647bd24f897e666af919b8 ] After commit 92cadedd9d5f ("brcmfmac: Avoid keeping power to SDIO card unless WOWL is used"), the wifi adapter by default is turned off on suspend and then re-probed on resume. This conflicts with some embedded boards that require to remain powered. They will fail on resume with: brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout ieee80211 phy1: brcmf_bus_started: failed: -110 ieee80211 phy1: brcmf_attach: dongle is not responding: err=-110 brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed This commit checks for the Device Tree property 'cap-power-off-cards'. If this property is not set, it means that we do not have the capability to power off and should therefore remain powered. Signed-off-by: Matthias Proske Acked-by: Arend van Spriel Link: https://patch.msgid.link/20250212185941.146958-2-email@matthias-proske.de Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 5eb8c8fee72608472628f178b5220cba6dea83f8 Author: Icenowy Zheng Date: Thu Feb 13 01:04:44 2025 +0800 nvme-pci: skip CMB blocks incompatible with PCI P2P DMA [ Upstream commit 56cf7ef0d490b28fad8f8629fc135c5ab7c9f54e ] The PCI P2PDMA code will register the CMB block to the memory hot-plugging subsystem, which have an alignment requirement. Memory blocks that do not satisfy this alignment requirement (usually 2MB) will lead to a WARNING from memory hotplugging. Verify the CMB block's address and size against the alignment and only try to send CMB blocks compatible with it to prevent this warning. Tested on Intel DC D4502 SSD, which has a 512K CMB block that is too small for memory hotplugging (thus PCI P2PDMA). Signed-off-by: Icenowy Zheng Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 63bd235de24237ffd5fb898d870c8f61148440aa Author: Icenowy Zheng Date: Thu Feb 13 01:04:43 2025 +0800 nvme-pci: clean up CMBMSC when registering CMB fails [ Upstream commit 6a3572e10f740acd48e2713ef37e92186a3ce5e8 ] CMB decoding should get disabled when the CMB block isn't successfully registered to P2P DMA subsystem. Clean up the CMBMSC register in this error handling codepath to disable CMB decoding (and CMBLOC/CMBSZ registers). Signed-off-by: Icenowy Zheng Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit c2fa1deeb4b8df9ead2f1a6b8ffc772e3acb2a48 Author: Sagi Grimberg Date: Thu Feb 20 13:18:30 2025 +0200 nvme-tcp: fix possible UAF in nvme_tcp_poll [ Upstream commit 8c1624b63a7d24142a2bbc3a5ee7e95f004ea36e ] nvme_tcp_poll() may race with the send path error handler because it may complete the request while it is actively being polled for completion, resulting in a UAF panic [1]: We should make sure to stop polling when we see an error when trying to read from the socket. Hence make sure to propagate the error so that the block layer breaks the polling cycle. [1]: -- [35665.692310] nvme nvme2: failed to send request -13 [35665.702265] nvme nvme2: unsupported pdu type (3) [35665.702272] BUG: kernel NULL pointer dereference, address: 0000000000000000 [35665.702542] nvme nvme2: queue 1 receive failed: -22 [35665.703209] #PF: supervisor write access in kernel mode [35665.703213] #PF: error_code(0x0002) - not-present page [35665.703214] PGD 8000003801cce067 P4D 8000003801cce067 PUD 37e6f79067 PMD 0 [35665.703220] Oops: 0002 [#1] SMP PTI [35665.703658] nvme nvme2: starting error recovery [35665.705809] Hardware name: Inspur aaabbb/YZMB-00882-104, BIOS 4.1.26 09/22/2022 [35665.705812] Workqueue: kblockd blk_mq_requeue_work [35665.709172] RIP: 0010:_raw_spin_lock+0xc/0x30 [35665.715788] Call Trace: [35665.716201] [35665.716613] ? show_trace_log_lvl+0x1c1/0x2d9 [35665.717049] ? show_trace_log_lvl+0x1c1/0x2d9 [35665.717457] ? blk_mq_request_bypass_insert+0x2c/0xb0 [35665.717950] ? __die_body.cold+0x8/0xd [35665.718361] ? page_fault_oops+0xac/0x140 [35665.718749] ? blk_mq_start_request+0x30/0xf0 [35665.719144] ? nvme_tcp_queue_rq+0xc7/0x170 [nvme_tcp] [35665.719547] ? exc_page_fault+0x62/0x130 [35665.719938] ? asm_exc_page_fault+0x22/0x30 [35665.720333] ? _raw_spin_lock+0xc/0x30 [35665.720723] blk_mq_request_bypass_insert+0x2c/0xb0 [35665.721101] blk_mq_requeue_work+0xa5/0x180 [35665.721451] process_one_work+0x1e8/0x390 [35665.721809] worker_thread+0x53/0x3d0 [35665.722159] ? process_one_work+0x390/0x390 [35665.722501] kthread+0x124/0x150 [35665.722849] ? set_kthread_struct+0x50/0x50 [35665.723182] ret_from_fork+0x1f/0x30 Reported-by: Zhang Guanghui Signed-off-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 12622cb7b1d8451ca5b5020a43a8f57bd71151d1 Author: Emmanuel Grumbach Date: Sun Feb 9 14:34:50 2025 +0200 wifi: iwlwifi: mvm: use the right version of the rate API [ Upstream commit a03e2082e678ea10d0d8bdf3ed933eb05a8ddbb0 ] The firmware uses the newer version of the API in recent devices. For older devices, we translate the rate to the new format. Don't parse the rate with old parsing macros. Signed-off-by: Emmanuel Grumbach Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250209143303.13d70cdcbb4e.Ic92193bce4013b70a823cfef250ee79c16cf7c17@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit bd888d67c7ce1682287c375d2ca331da8be840e8 Author: Johannes Berg Date: Sun Feb 9 14:34:45 2025 +0200 wifi: iwlwifi: fw: allocate chained SG tables for dump [ Upstream commit 7774e3920029398ad49dc848b23840593f14d515 ] The firmware dumps can be pretty big, and since we use single pages for each SG table entry, even the table itself may end up being an order-5 allocation. Build chained tables so that we need not allocate a higher-order table here. This could be improved and cleaned up, e.g. by using the SG pool code or simply kvmalloc(), but all of that would require also updating the devcoredump first since that frees it all, so we need to be more careful. SG pool might also run against the CONFIG_ARCH_NO_SG_CHAIN limitation, which is irrelevant here. Also use _devcd_free_sgtable() for the error paths now, much simpler especially since it's in two places now. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250209143303.697c7a465ac9.Iea982df46b5c075bfb77ade36f187d99a70c63db@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit e0862a6d3dabddbfaa44990a950f131c88d467cb Author: Alexander Wetzel Date: Tue Feb 4 17:42:40 2025 +0100 wifi: mac80211: remove debugfs dir for virtual monitor [ Upstream commit 646262c71aca87bb66945933abe4e620796d6c5a ] Don't call ieee80211_debugfs_recreate_netdev() for virtual monitor interface when deleting it. The virtual monitor interface shouldn't have debugfs entries and trying to update them will *create* them on deletion. And when the virtual monitor interface is created/destroyed multiple times we'll get warnings about debugfs name conflicts. Signed-off-by: Alexander Wetzel Link: https://patch.msgid.link/20250204164240.370153-1-Alexander@wetzel-home.de Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 5d42a34137243b1d86acf02b49963c529ff6ea3e Author: Alexander Wetzel Date: Tue Feb 4 13:31:29 2025 +0100 wifi: mac80211: Cleanup sta TXQs on flush [ Upstream commit 5b999006e35ea9c11116ddff7e375b256421d0af ] Drop the sta TXQs on flush when the drivers is not supporting flush. ieee80211_set_disassoc() tries to clean up everything for the sta. But it ignored queued frames in the sta TX queues when the driver isn't supporting the flush driver ops. Signed-off-by: Alexander Wetzel Link: https://patch.msgid.link/20250204123129.9162-1-Alexander@wetzel-home.de Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit eb532ac40dc87f27d8e680c1a9c2801cbeae6e6a Author: Dan Carpenter Date: Wed Apr 2 14:02:40 2025 +0300 nfs: Add missing release on error in nfs_lock_and_join_requests() [ Upstream commit 8e5419d6542fdf2dca9a0acdef2b8255f0e4ba69 ] Call nfs_release_request() on this error path before returning. Fixes: c3f2235782c3 ("nfs: fold nfs_folio_find_and_lock_request into nfs_lock_and_join_requests") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/3aaaa3d5-1c8a-41e4-98c7-717801ddd171@stanley.mountain Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 26bf086ebd7019928aca7b0f8972d9ef09faeb09 Author: Josh Poimboeuf Date: Mon Mar 31 21:26:43 2025 -0700 objtool/loongarch: Add unwind hints in prepare_frametrace() [ Upstream commit 7c977393b8277ed319e92e4b598b26598c9d30c0 ] If 'regs' points to a local stack variable, prepare_frametrace() stores all registers to the stack. This confuses objtool as it expects them to be restored from the stack later. The stores don't affect stack tracing, so use unwind hints to hide them from objtool. Fixes the following warnings: arch/loongarch/kernel/traps.o: warning: objtool: show_stack+0xe0: stack state mismatch: reg1[22]=-1+0 reg2[22]=-2-160 arch/loongarch/kernel/traps.o: warning: objtool: show_stack+0xe0: stack state mismatch: reg1[23]=-1+0 reg2[23]=-2-152 Fixes: cb8a2ef0848c ("LoongArch: Add ORC stack unwinder support") Reported-by: kernel test robot Tested-by: Tiezhu Yang Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/270cadd8040dda74db2307f23497bb68e65db98d.1743481539.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202503280703.OARM8SrY-lkp@intel.com/ Signed-off-by: Sasha Levin commit d80168db5e0c68426c67c7568e12b4b8a4550abf Author: Josh Poimboeuf Date: Mon Mar 31 21:26:46 2025 -0700 rcu-tasks: Always inline rcu_irq_work_resched() [ Upstream commit 6309a5c43b0dc629851f25b2e5ef8beff61d08e5 ] Thanks to CONFIG_DEBUG_SECTION_MISMATCH, empty functions can be generated out of line. rcu_irq_work_resched() can be called from noinstr code, so make sure it's always inlined. Fixes: 564506495ca9 ("rcu/context-tracking: Move deferred nocb resched to context tracking") Reported-by: Randy Dunlap Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Frederic Weisbecker Cc: Paul E. McKenney Cc: Linus Torvalds Link: https://lore.kernel.org/r/e84f15f013c07e4c410d972e75620c53b62c1b3e.1743481539.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/d1eca076-fdde-484a-b33e-70e0d167c36d@infradead.org Signed-off-by: Sasha Levin commit 00911b416ad734b4adcf0c77d45cfcda8a6c9074 Author: Josh Poimboeuf Date: Mon Mar 31 21:26:45 2025 -0700 context_tracking: Always inline ct_{nmi,irq}_{enter,exit}() [ Upstream commit 9ac50f7311dc8b39e355582f14c1e82da47a8196 ] Thanks to CONFIG_DEBUG_SECTION_MISMATCH, empty functions can be generated out of line. These can be called from noinstr code, so make sure they're always inlined. Fixes the following warnings: vmlinux.o: warning: objtool: irqentry_nmi_enter+0xa2: call to ct_nmi_enter() leaves .noinstr.text section vmlinux.o: warning: objtool: irqentry_nmi_exit+0x16: call to ct_nmi_exit() leaves .noinstr.text section vmlinux.o: warning: objtool: irqentry_exit+0x78: call to ct_irq_exit() leaves .noinstr.text section Fixes: 6f0e6c1598b1 ("context_tracking: Take IRQ eqs entrypoints over RCU") Reported-by: Randy Dunlap Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Frederic Weisbecker Cc: Paul E. McKenney Cc: Linus Torvalds Link: https://lore.kernel.org/r/8509bce3f536bcd4ae7af3a2cf6930d48c5e631a.1743481539.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/d1eca076-fdde-484a-b33e-70e0d167c36d@infradead.org Signed-off-by: Sasha Levin commit 8e49f912ae1479995606026aafa4cbaeb244404f Author: Josh Poimboeuf Date: Mon Mar 31 21:26:44 2025 -0700 sched/smt: Always inline sched_smt_active() [ Upstream commit 09f37f2d7b21ff35b8b533f9ab8cfad2fe8f72f6 ] sched_smt_active() can be called from noinstr code, so it should always be inlined. The CONFIG_SCHED_SMT version already has __always_inline. Do the same for its !CONFIG_SCHED_SMT counterpart. Fixes the following warning: vmlinux.o: error: objtool: intel_idle_ibrs+0x13: call to sched_smt_active() leaves .noinstr.text section Fixes: 321a874a7ef8 ("sched/smt: Expose sched_smt_present static key") Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/1d03907b0a247cf7fb5c1d518de378864f603060.1743481539.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/r/202503311434.lyw2Tveh-lkp@intel.com/ Signed-off-by: Sasha Levin commit 22e1e4e11af594aa71428cc319a97c7aab9b4773 Author: David Laight Date: Mon Mar 31 21:26:42 2025 -0700 objtool: Fix verbose disassembly if CROSS_COMPILE isn't set [ Upstream commit e77956e4e5c11218e60a1fe8cdbccd02476f2e56 ] In verbose mode, when printing the disassembly of affected functions, if CROSS_COMPILE isn't set, the objdump command string gets prefixed with "(null)". Somehow this worked before. Maybe some versions of glibc return an empty string instead of NULL. Fix it regardless. [ jpoimboe: Rewrite commit log. ] Fixes: ca653464dd097 ("objtool: Add verbose option for disassembling affected functions") Signed-off-by: David Laight Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250215142321.14081-1-david.laight.linux@gmail.com Link: https://lore.kernel.org/r/b931a4786bc0127aa4c94e8b35ed617dcbd3d3da.1743481539.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit 10856c530de3373282efa5d3a8b5729bd116b13c Author: Geetha sowjanya Date: Thu Mar 27 15:10:54 2025 +0530 octeontx2-af: Free NIX_AF_INT_VEC_GEN irq [ Upstream commit 323d6db6dc7decb06f2545efb9496259ddacd4f4 ] Due to the incorrect initial vector number in rvu_nix_unregister_interrupts(), NIX_AF_INT_VEC_GEN is not geeting free. Fix the vector number to include NIX_AF_INT_VEC_GEN irq. Fixes: 5ed66306eab6 ("octeontx2-af: Add devlink health reporters for NIX") Signed-off-by: Geetha sowjanya Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250327094054.2312-1-gakula@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d2e60c3b8a6250aebe9934211e6e340840968169 Author: Geetha sowjanya Date: Thu Mar 27 14:44:41 2025 +0530 octeontx2-af: Fix mbox INTR handler when num VFs > 64 [ Upstream commit 0fdba88a211508984eb5df62008c29688692b134 ] When number of RVU VFs > 64, the vfs value passed to "rvu_queue_work" function is incorrect. Due to which mbox workqueue entries for VFs 0 to 63 never gets added to workqueue. Fixes: 9bdc47a6e328 ("octeontx2-af: Mbox communication support btw AF and it's VFs") Signed-off-by: Geetha sowjanya Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250327091441.1284-1-gakula@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a436e14343177c1db81b7a5be4deb100bb97340f Author: Jim Liu Date: Thu Mar 27 14:29:42 2025 +0800 net: phy: broadcom: Correct BCM5221 PHY model detection [ Upstream commit 4f1eaabb4b66a1f7473f584e14e15b2ac19dfaf3 ] Correct detect condition is applied to the entire 5221 family of PHYs. Fixes: 3abbd0699b67 ("net: phy: broadcom: add support for BCM5221 phy") Signed-off-by: Jim Liu Reviewed-by: Michal Swiatkowski Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d3561dc471ac6c83c2d02640f53e8957cba138b8 Author: Giovanni Gherdovich Date: Fri Mar 28 15:30:39 2025 +0100 ACPI: processor: idle: Return an error if both P_LVL{2,3} idle states are invalid [ Upstream commit 9e9b893404d43894d69a18dd2fc8fcf1c36abb7e ] Prior to commit 496121c02127 ("ACPI: processor: idle: Allow probing on platforms with one ACPI C-state"), the acpi_idle driver wouldn't load on systems without a valid C-State at least as deep as C2. The behavior was desirable for guests on hypervisors such as VMWare ESXi, which by default don't have the _CST ACPI method, and set the C2 and C3 latencies to 101 and 1001 microseconds respectively via the FADT, to signify they're unsupported. Since the above change though, these virtualized deployments end up loading acpi_idle, and thus entering the default C1 C-State set by acpi_processor_get_power_info_default(); this is undesirable for a system that's communicating to the OS it doesn't want C-States (missing _CST, and invalid C2/C3 in FADT). Make acpi_processor_get_power_info_fadt() return -ENODEV in that case, so that acpi_processor_get_cstate_info() exits early and doesn't set pr->flags.power = 1. Fixes: 496121c02127 ("ACPI: processor: idle: Allow probing on platforms with one ACPI C-state") Signed-off-by: Giovanni Gherdovich Reviewed-by: Zhang Rui Link: https://patch.msgid.link/20250328143040.9348-1-ggherdovich@suse.cz [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 00c22ab0614ab341a1a2b3ab0881dfa4bdc34a03 Author: Yuli Wang Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: Rework the arch_kgdb_breakpoint() implementation [ Upstream commit 29c92a41c6d2879c1f62220fe4758dce191bb38f ] The arch_kgdb_breakpoint() function defines the kgdb_breakinst symbol using inline assembly. 1. There's a potential issue where the compiler might inline arch_kgdb_breakpoint(), which would then define the kgdb_breakinst symbol multiple times, leading to a linker error. To prevent this, declare arch_kgdb_breakpoint() as noinline. Fix follow error with LLVM-19 *only* when LTO_CLANG_FULL: LD vmlinux.o ld.lld-19: error: ld-temp.o :3:1: symbol 'kgdb_breakinst' is already defined kgdb_breakinst: break 2 ^ 2. Remove "nop" in the inline assembly because it's meaningless for LoongArch here. 3. Add "STACK_FRAME_NON_STANDARD" for arch_kgdb_breakpoint() to avoid the objtool warning. Fixes: e14dd076964e ("LoongArch: Add basic KGDB & KDB support") Tested-by: Binbin Zhou Co-developed-by: Winston Wen Signed-off-by: Winston Wen Co-developed-by: Wentao Guan Signed-off-by: Wentao Guan Signed-off-by: Yuli Wang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 035a4a852ee830f415e3987bc8c6f65abe5800d4 Author: Miaoqian Lin Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: Fix device node refcount leak in fdt_cpu_clk_init() [ Upstream commit 2e3bc71e4f394ecf8f499d21923cf556b4bfa1e7 ] Add missing of_node_put() to properly handle the reference count of the device node obtained from of_get_cpu_node(). Fixes: 44a01f1f726a ("LoongArch: Parsing CPU-related information from DTS") Signed-off-by: Miaoqian Lin Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 396cdb580e2e91043a78cd4b9d4d81b980c897a7 Author: 谢致邦 (XIE Zhibang) Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: Fix help text of CMDLINE_EXTEND in Kconfig [ Upstream commit be216cbc1ddf99a51915414ce147311c0dfd50a2 ] It is the built-in command line appended to the bootloader command line, not the bootloader command line appended to the built-in command line. Fixes: fa96b57c1490 ("LoongArch: Add build infrastructure") Signed-off-by: 谢致邦 (XIE Zhibang) Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 11d479dffde5280b6a6f0e54d66eb7f2ee469078 Author: Josh Poimboeuf Date: Thu Mar 27 22:04:21 2025 -0700 objtool: Fix segfault in ignore_unreachable_insn() [ Upstream commit 69d41d6dafff0967565b971d950bd10443e4076c ] Check 'prev_insn' before dereferencing it. Fixes: bd841d6154f5 ("objtool: Fix CONFIG_UBSAN_TRAP unreachable warnings") Reported-by: Arnd Bergmann Reported-by: Ingo Molnar Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/5df4ff89c9e4b9e788b77b0531234ffa7ba03e9e.1743136205.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/d86b4cc6-0b97-4095-8793-a7384410b8ab@app.fastmail.com Closes: https://lore.kernel.org/Z-V_rruKY0-36pqA@gmail.com Signed-off-by: Sasha Levin commit 2a6f8823ff608ed1ee1880821c68071d0e89d909 Author: Feng Yang Date: Sun Feb 23 15:01:06 2025 +0800 ring-buffer: Fix bytes_dropped calculation issue [ Upstream commit c73f0b69648501978e8b3e8fa7eef7f4197d0481 ] The calculation of bytes-dropped and bytes_dropped_nested is reversed. Although it does not affect the final calculation of total_dropped, it should still be modified. Link: https://lore.kernel.org/20250223070106.6781-1-yangfeng59949@163.com Fixes: 6c43e554a2a5 ("ring-buffer: Add ring buffer startup selftest") Signed-off-by: Feng Yang Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 5923492ba353fa56d3d50ca2a63a82470d44dce0 Author: Lama Kayal Date: Sun Mar 23 14:28:26 2025 +0200 net/mlx5e: SHAMPO, Make reserved size independent of page size [ Upstream commit fab05835688526f9de123d1e98e4d1f838da4e22 ] When hw-gro is enabled, the maximum number of header entries that are needed per wqe (hd_per_wqe) is calculated based on the size of the reservations among other parameters. Miscalculation of the size of reservations leads to incorrect calculation of hd_per_wqe as 0, particularly in the case of large page size like in aarch64, this prevents the SHAMPO header from being correctly initialized in the device, ultimately causing the following cqe err that indicates a violation of PD. mlx5_core 0000:00:08.0 eth2: ERR CQE on RQ: 0x1180 mlx5_core 0000:00:08.0 eth2: Error cqe on cqn 0x510, ci 0x0, qn 0x1180, opcode 0xe, syndrome 0x4, vendor syndrome 0x32 00000000: 00 00 00 00 04 4a 00 00 00 00 00 00 20 00 93 32 00000010: 55 00 00 00 fb cc 00 00 00 00 00 00 07 18 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4a 00000030: 00 00 00 9a 93 00 32 04 00 00 00 00 00 00 da e1 Use the correct formula for calculating the size of reservations, precisely it shouldn't be dependent on page size, instead use the correct multiply of MLX5E_SHAMPO_WQ_BASE_RESRV_SIZE. Fixes: e5ca8fb08ab2 ("net/mlx5e: Add control path for SHAMPO feature") Signed-off-by: Lama Kayal Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/1742732906-166564-1-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 457db486203c90e10c3efc87fd45cc7000b1cd36 Author: Namjae Jeon Date: Tue Mar 25 00:00:24 2025 +0900 ksmbd: fix r_count dec/increment mismatch [ Upstream commit ddb7ea36ba7129c2ed107e2186591128618864e1 ] r_count is only increased when there is an oplock break wait, so r_count inc/decrement are not paired. This can cause r_count to become negative, which can lead to a problem where the ksmbd thread does not terminate. Fixes: 3aa660c05924 ("ksmbd: prevent connection release during oplock break notification") Reported-by: Norbert Szetei Tested-by: Norbert Szetei Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit e0b32b6f0f13ea6ec878afb26f4f273275d4786f Author: Namjae Jeon Date: Mon Mar 24 20:19:20 2025 +0900 ksmbd: fix multichannel connection failure [ Upstream commit c1883049aa9b2b7dffd3a68c5fc67fa92c174bd9 ] ksmbd check that the session of second channel is in the session list of first connection. If it is in session list, multichannel connection should not be allowed. Fixes: b95629435b84 ("ksmbd: fix racy issue from session lookup and expire") Reported-by: Sean Heelan Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 3e341dbd5f5a6e5a558e67da80731dc38a7f758c Author: Miaoqian Lin Date: Tue Mar 18 20:12:34 2025 +0800 ksmbd: use aead_request_free to match aead_request_alloc [ Upstream commit 6171063e9d046ffa46f51579b2ca4a43caef581a ] Use aead_request_free() instead of kfree() to properly free memory allocated by aead_request_alloc(). This ensures sensitive crypto data is zeroed before being freed. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Miaoqian Lin Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 3f17af46cfc7c1b0fd62114c2d7f38071eb80f02 Author: Lubomir Rintel Date: Tue Mar 25 10:58:41 2025 +0100 rndis_host: Flag RNDIS modems as WWAN devices [ Upstream commit 67d1a8956d2d62fe6b4c13ebabb57806098511d8 ] Set FLAG_WWAN instead of FLAG_ETHERNET for RNDIS interfaces on Mobile Broadband Modems, as opposed to regular Ethernet adapters. Otherwise NetworkManager gets confused, misjudges the device type, and wouldn't know it should connect a modem to get the device to work. What would be the result depends on ModemManager version -- older ModemManager would end up disconnecting a device after an unsuccessful probe attempt (if it connected without needing to unlock a SIM), while a newer one might spawn a separate PPP connection over a tty interface instead, resulting in a general confusion and no end of chaos. The only way to get this work reliably is to fix the device type and have good enough version ModemManager (or equivalent). Fixes: 63ba395cd7a5 ("rndis_host: support Novatel Verizon USB730L") Signed-off-by: Lubomir Rintel Link: https://patch.msgid.link/20250325095842.1567999-1-lkundrak@v3.sk Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 28b21ee8e8fb326ba961a4bbce04ec04c65e705a Author: Mark Zhang Date: Tue Mar 25 11:02:26 2025 +0200 rtnetlink: Allocate vfinfo size for VF GUIDs when supported [ Upstream commit 23f00807619d15063d676218f36c5dfeda1eb420 ] Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs") added support for getting VF port and node GUIDs in netlink ifinfo messages, but their size was not taken into consideration in the function that allocates the netlink message, causing the following warning when a netlink message is filled with many VF port and node GUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too long Kernel warning: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfx___mutex_lock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx___netlink_lookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? __pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ____sys_sendmsg+0x559/0x5a0 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 ___sys_sendmsg+0xe4/0x150 ? __pfx____sys_sendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? __pfx_handle_pte_fault+0x10/0x10 ? preempt_count_sub+0x14/0xc0 ? __down_read_trylock+0x150/0x270 ? __handle_mm_fault+0x404/0x8e0 ? __pfx___handle_mm_fault+0x10/0x10 ? lock_release+0x62/0x200 ? __rcu_read_unlock+0x65/0x90 ? rcu_is_watching+0x34/0x60 __sys_sendmsg+0xd5/0x150 ? __pfx___sys_sendmsg+0x10/0x10 ? __up_read+0x192/0x480 ? lock_release+0x62/0x200 ? __rcu_read_unlock+0x65/0x90 ? rcu_is_watching+0x34/0x60 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f63a5b13367 Code: 0e 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RSP: 002b:00007fff8c726bc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000067b687c2 RCX: 00007f63a5b13367 RDX: 0000000000000000 RSI: 00007fff8c726c30 RDI: 0000000000000004 RBP: 00007fff8c726cb8 R08: 0000000000000000 R09: 0000000000000034 R10: 00007fff8c726c7c R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000000 R14: 00007fff8c726cd0 R15: 00007fff8c726cd0 irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [] copy_process+0xd08/0x2830 softirqs last enabled at (0): [] copy_process+0xd08/0x2830 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 0000000000000000 ]--- Thus, when calculating ifinfo message size, take VF GUIDs sizes into account when supported. Fixes: 30aad41721e0 ("net/core: Add support for getting VF GUIDs") Signed-off-by: Mark Zhang Reviewed-by: Maher Sanalla Signed-off-by: Mark Bloch Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20250325090226.749730-1-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4a9595eb024b8319957c178be3cdeed613ac0795 Author: Yuezhang Mo Date: Thu Mar 6 15:02:07 2025 +0800 exfat: fix missing shutdown check [ Upstream commit 47e35366bc6fa3cf189a8305bce63992495f3efa ] xfstests generic/730 test failed because after deleting the device that still had dirty data, the file could still be read without returning an error. The reason is the missing shutdown check in ->read_iter. I also noticed that shutdown checks were missing from ->write_iter, ->splice_read, and ->mmap. This commit adds shutdown checks to all of them. Fixes: f761fcdd289d ("exfat: Implement sops->shutdown and ioctl") Signed-off-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 6a14075325006dad7fef2f980f60dea8acb097a2 Author: Yuezhang Mo Date: Mon Mar 17 10:53:10 2025 +0800 exfat: fix the infinite loop in exfat_find_last_cluster() [ Upstream commit b0522303f67255926b946aa66885a0104d1b2980 ] In exfat_find_last_cluster(), the cluster chain is traversed until the EOF cluster. If the cluster chain includes a loop due to file system corruption, the EOF cluster cannot be traversed, resulting in an infinite loop. If the number of clusters indicated by the file size is inconsistent with the cluster chain length, exfat_find_last_cluster() will return an error, so if this inconsistency is found, the traversal can be aborted without traversing to the EOF cluster. Reported-by: syzbot+f7d147e6db52b1e09dba@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f7d147e6db52b1e09dba Tested-by: syzbot+f7d147e6db52b1e09dba@syzkaller.appspotmail.com Fixes: 31023864e67a ("exfat: add fat entry operations") Signed-off-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 7d8dfc27d90d41627c0d6ada97ed0ab57b3dae25 Author: Wang Zhaolong Date: Tue Feb 18 22:30:05 2025 +0800 smb: client: Fix netns refcount imbalance causing leaks and use-after-free [ Upstream commit 4e7f1644f2ac6d01dc584f6301c3b1d5aac4eaef ] Commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") attempted to fix a netns use-after-free issue by manually adjusting reference counts via sk->sk_net_refcnt and sock_inuse_add(). However, a later commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") pointed out that the approach of manually setting sk->sk_net_refcnt in the first commit was technically incorrect, as sk->sk_net_refcnt should only be set for user sockets. It led to issues like TCP timers not being cleared properly on close. The second commit moved to a model of just holding an extra netns reference for server->ssocket using get_net(), and dropping it when the server is torn down. But there remain some gaps in the get_net()/put_net() balancing added by these commits. The incomplete reference handling in these fixes results in two issues: 1. Netns refcount leaks[1] The problem process is as follows: ``` mount.cifs cifsd cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* First get net. */ ip_connect generic_ip_connect /* Try port 445 */ get_net() ->connect() /* Failed */ put_net() generic_ip_connect /* Try port 139 */ get_net() /* Missing matching put_net() for this get_net().*/ cifs_get_smb_ses cifs_negotiate_protocol smb2_negotiate SMB2_negotiate cifs_send_recv wait_for_response cifs_demultiplex_thread cifs_read_from_socket cifs_readv_from_socket cifs_reconnect cifs_abort_connection sock_release(); server->ssocket = NULL; /* Missing put_net() here. */ generic_ip_connect get_net() ->connect() /* Failed */ put_net() sock_release(); server->ssocket = NULL; free_rsp_buf ... clean_demultiplex_info /* It's only called once here. */ put_net() ``` When cifs_reconnect() is triggered, the server->ssocket is released without a corresponding put_net() for the reference acquired in generic_ip_connect() before. it ends up calling generic_ip_connect() again to retry get_net(). After that, server->ssocket is set to NULL in the error path of generic_ip_connect(), and the net count cannot be released in the final clean_demultiplex_info() function. 2. Potential use-after-free The current refcounting scheme can lead to a potential use-after-free issue in the following scenario: ``` cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* First get net */ ip_connect generic_ip_connect get_net() bind_socket kernel_bind /* failed */ put_net() /* after out_err_crypto_release label */ put_net() /* after out_err label */ put_net() ``` In the exception handling process where binding the socket fails, the get_net() and put_net() calls are unbalanced, which may cause the server->net reference count to drop to zero and be prematurely released. To address both issues, this patch ties the netns reference counting to the server->ssocket and server lifecycles. The extra reference is now acquired when the server or socket is created, and released when the socket is destroyed or the server is torn down. [1]: https://bugzilla.kernel.org/show_bug.cgi?id=219792 Fixes: ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") Fixes: e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") Signed-off-by: Wang Zhaolong Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 81270dd79606366f32d2d4a4aee9cba08f8181bb Author: Trond Myklebust Date: Tue Mar 25 17:58:50 2025 -0400 NFS: Shut down the nfs_client only after all the superblocks [ Upstream commit 2d3e998a0bc7fe26a724f87a8ce217848040520e ] The nfs_client manages state for all the superblocks in the "cl_superblocks" list, so it must not be shut down until all of them are gone. Fixes: 7d3e26a054c8 ("NFS: Cancel all existing RPC tasks when shutdown") Reviewed-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit cd80277f652138d2619f149f86ae6d17bce721d1 Author: Josh Poimboeuf Date: Mon Mar 24 14:56:06 2025 -0700 objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds() [ Upstream commit e63d465f59011dede0a0f1d21718b59a64c3ff5c ] If dib8000_set_dds()'s call to dib8000_read32() returns zero, the result is a divide-by-zero. Prevent that from happening. Fixes the following warning with an UBSAN kernel: drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx() Fixes: 173a64cb3fcf ("[media] dib8000: enhancement") Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Mauro Carvalho Chehab Cc: Linus Torvalds Link: https://lore.kernel.org/r/bd1d504d930ae3f073b1e071bcf62cae7708773c.1742852847.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/r/202503210602.fvH5DO1i-lkp@intel.com/ Signed-off-by: Sasha Levin commit 1adc93a525fdee8e2b311e6d5fd93eb69714ca05 Author: Josh Poimboeuf Date: Mon Mar 24 14:56:05 2025 -0700 objtool, nvmet: Fix out-of-bounds stack access in nvmet_ctrl_state_show() [ Upstream commit 107a23185d990e3df6638d9a84c835f963fe30a6 ] The csts_state_names[] array only has six sparse entries, but the iteration code in nvmet_ctrl_state_show() iterates seven, resulting in a potential out-of-bounds stack read. Fix that. Fixes the following warning with an UBSAN kernel: vmlinux.o: warning: objtool: .text.nvmet_ctrl_state_show: unexpected end of section Fixes: 649fd41420a8 ("nvmet: add debugfs support") Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Christoph Hellwig Cc: Sagi Grimberg Cc: Chaitanya Kulkarni Cc: Linus Torvalds Link: https://lore.kernel.org/r/f1f60858ee7a941863dc7f5506c540cb9f97b5f6.1742852847.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202503171547.LlCTJLQL-lkp@intel.com/ Signed-off-by: Sasha Levin commit 456300be232e05ac847fc5a0bd8b04d7ded69041 Author: xueqin Luo Date: Thu Feb 6 16:14:36 2025 +0800 thermal: core: Remove duplicate struct declaration [ Upstream commit 9e6ec8cf64e2973f0ec74f09023988cabd218426 ] The struct thermal_zone_device is already declared on line 32, so the duplicate declaration has been removed. Fixes: b1ae92dcfa8e ("thermal: core: Make struct thermal_zone_device definition internal") Signed-off-by: xueqin Luo Link: https://lore.kernel.org/r/20250206081436.51785-1-luoxueqin@kylinos.cn Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit 8f178998af67e98db6d48975a8e1a264604f84d9 Author: Namhyung Kim Date: Fri Mar 7 14:09:21 2025 -0800 perf bpf-filter: Fix a parsing error with comma [ Upstream commit 35d13f841a3d8159ef20d5e32a9ed3faa27875bc ] The previous change to support cgroup filters introduced a bug that pathname can include commas. It confused the lexer to treat an item and the trailing comma as a single token. And it resulted in a parse error: $ sudo perf record -e cycles:P --filter 'period > 0, ip > 64' -- true perf_bpf_filter: Error: Unexpected item: 0, perf_bpf_filter: syntax error, unexpected BFT_ERROR, expecting BFT_NUM Usage: perf record [] [] or: perf record [] -- [] --filter event filter It should get "0" and "," separately. An easiest fix would be to remove "," from the possible pathname characters. As it's for cgroup names, probably ok to assume it won't have commas in the pathname. I found that the existing BPF filtering test didn't have any complex filter condition with commas. Let's update the group filter test which is supposed to test filter combinations like this. Link: https://lore.kernel.org/r/20250307220922.434319-1-namhyung@kernel.org Fixes: 91e88437d5156b20 ("perf bpf-filter: Support filtering on cgroups") Reported-by: Sally Shi Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 2c3dea5d17763132a0f9c27716449c24cd400174 Author: Marcus Meissner Date: Sun Mar 23 09:53:45 2025 +0100 perf tools: annotate asm_pure_loop.S [ Upstream commit 9a352a90e88a041f4b26d359493e12a7f5ae1a6a ] Annotate so it is built with non-executable stack. Fixes: 8b97519711c3 ("perf test: Add asm pureloop test tool") Signed-off-by: Marcus Meissner Reviewed-by: Leo Yan Link: https://lore.kernel.org/r/20250323085410.23751-1-meissner@suse.de Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit aba918999252668b711b51f59bc46278d95ea66b Author: Bart Van Assche Date: Wed Mar 19 14:02:22 2025 -0700 fs/procfs: fix the comment above proc_pid_wchan() [ Upstream commit 6287fbad1cd91f0c25cdc3a580499060828a8f30 ] proc_pid_wchan() used to report kernel addresses to user space but that is no longer the case today. Bring the comment above proc_pid_wchan() in sync with the implementation. Link: https://lkml.kernel.org/r/20250319210222.1518771-1-bvanassche@acm.org Fixes: b2f73922d119 ("fs/proc, core/debug: Don't expose absolute kernel addresses via wchan") Signed-off-by: Bart Van Assche Cc: Kees Cook Cc: Eric W. Biederman Cc: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 819685fcebdf79923ff84f56ea979204307a8750 Author: Ilkka Koskinen Date: Thu Mar 13 20:15:59 2025 +0000 perf vendor events arm64 AmpereOneX: Fix frontend_bound calculation [ Upstream commit 182f12f3193341c3400ae719a34c00a8a1204cff ] frontend_bound metrics was miscalculated due to different scaling in a couple of metrics it depends on. Change the scaling to match with AmpereOne. Fixes: 16438b652b46 ("perf vendor events arm64 AmpereOneX: Add core PMU events and metrics") Signed-off-by: Ilkka Koskinen Reviewed-by: James Clark Link: https://lore.kernel.org/r/20250313201559.11332-3-ilkka@os.amperecomputing.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 5b2b692804ce9da7c1690a7303b86254f1d3594a Author: Jiri Slaby (SUSE) Date: Mon Mar 17 08:00:20 2025 +0100 tty: n_tty: use uint for space returned by tty_write_room() [ Upstream commit d97aa066678bd1e2951ee93db9690835dfe57ab6 ] tty_write_room() returns an "unsigned int". So in case some insane driver (like my tty test driver) returns (legitimate) UINT_MAX from its tty_operations::write_room(), n_tty is confused on several places. For example, in process_output_block(), the result of tty_write_room() is stored into (signed) "int". So this UINT_MAX suddenly becomes -1. And that is extended to ssize_t and returned from process_output_block(). This causes a write() to such a node to receive -EPERM (which is -1). Fix that by using proper "unsigned int" and proper "== 0" test. And return 0 constant directly in that "if", so that it is immediately clear what is returned ("space" equals to 0 at that point). Similarly for process_output() and __process_echoes(). Note this does not fix any in-tree driver as of now. If you want "Fixes: something", it would be commit 03b3b1a2405c ("tty: make tty_operations::write_room return uint"). I intentionally do not mark this patch by a real tag below. Signed-off-by: Jiri Slaby (SUSE) Link: https://lore.kernel.org/r/20250317070046.24386-6-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1817c4b85011998604e5ff9a80a6e01adb7e7e81 Author: Stefan Wahren Date: Sun Mar 9 13:50:11 2025 +0100 staging: vchiq_arm: Fix possible NPR of keep-alive thread [ Upstream commit 3db89bc6d973e2bcaa852f6409c98c228f39a926 ] In case vchiq_platform_conn_state_changed() is never called or fails before driver removal, ka_thread won't be a valid pointer to a task_struct. So do the necessary checks before calling kthread_stop to avoid a crash. Fixes: 863a756aaf49 ("staging: vc04_services: vchiq_core: Stop kthreads on vchiq module unload") Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/20250309125014.37166-3-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f3fafa188d96e7cd1c155ec717f908e7361872e0 Author: Stefan Wahren Date: Sun Mar 9 13:50:10 2025 +0100 staging: vchiq_arm: Register debugfs after cdev [ Upstream commit 63f4dbb196db60a8536ba3d1b835d597a83f6cbb ] The commit 2a4d15a4ae98 ("staging: vchiq: Refactor vchiq cdev code") moved the debugfs directory creation before vchiq character device registration. In case the latter fails, the debugfs directory won't be cleaned up. Fixes: 2a4d15a4ae98 ("staging: vchiq: Refactor vchiq cdev code") Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/20250309125014.37166-2-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f14dd4025975493dce012ae503cb6f511167a8bb Author: 谢致邦 (XIE Zhibang) Date: Sat Feb 22 19:36:17 2025 +0000 staging: rtl8723bs: select CONFIG_CRYPTO_LIB_AES [ Upstream commit b2a9a6a26b7e954297e51822e396572026480bad ] This fixes the following issue: ERROR: modpost: "aes_expandkey" [drivers/staging/rtl8723bs/r8723bs.ko] undefined! ERROR: modpost: "aes_encrypt" [drivers/staging/rtl8723bs/r8723bs.ko] undefined! Fixes: 7d40753d8820 ("staging: rtl8723bs: use in-kernel aes encryption in OMAC1 routines") Fixes: 3d3a170f6d80 ("staging: rtl8723bs: use in-kernel aes encryption") Signed-off-by: 谢致邦 (XIE Zhibang) Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/tencent_0BDDF3A721708D16A2E7C3DAFF0FEC79A105@qq.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ed1d004a5af08acb32ee2b66253aca6d10e59eeb Author: James Clark Date: Wed Mar 19 10:16:10 2025 +0000 perf: intel-tpebs: Fix incorrect usage of zfree() [ Upstream commit 6d2dcd635204c023eb5328ad7d38b198a5558c9b ] zfree() requires an address otherwise it frees what's in name, rather than name itself. Pass the address of name to fix it. This was the only incorrect occurrence in Perf found using a search. Fixes: 8db5cabcf1b6 ("perf stat: Fork and launch 'perf record' when 'perf stat' needs to get retire latency value for a metric.") Signed-off-by: James Clark Link: https://lore.kernel.org/r/20250319101614.190922-1-james.clark@linaro.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 70afdf7711712395382a4946e9e5a5216d3eaf3d Author: Stephen Brennan Date: Tue Mar 18 16:00:11 2025 -0700 perf dso: fix dso__is_kallsyms() check [ Upstream commit ebf0b332732dcc64239119e554faa946562b0b93 ] Kernel modules for which we cannot find a file on-disk will have a dso->long_name that looks like "[module_name]". Prior to the commit listed in the fixes, the dso->kernel field would be zero (for user space), so dso__is_kallsyms() would return false. After the commit, kernel module DSOs are correctly labeled, but the result is that dso__is_kallsyms() erroneously returns true for those modules without a filesystem path. Later, build_id_cache__add() consults this value of is_kallsyms, and when true, it copies /proc/kallsyms into the cache. Users with many kernel modules without a filesystem path (e.g. ksplice or possibly kernel live patch modules) have reported excessive disk space usage in the build ID cache directory due to this behavior. To reproduce the issue, it's enough to build a trivial out-of-tree hello world kernel module, load it using insmod, and then use: perf record -ag -- sleep 1 In the build ID directory, there will be a directory for your module name containing a kallsyms file. Fix this up by changing dso__is_kallsyms() to consult the dso_binary_type enumeration, which is also symmetric to the above checks for dso__is_vmlinux() and dso__is_kcore(). With this change, kallsyms is not cached in the build-id cache for out-of-tree modules. Fixes: 02213cec64bbe ("perf maps: Mark module DSOs with kernel type") Signed-off-by: Stephen Brennan Link: https://lore.kernel.org/r/20250318230012.2038790-1-stephen.s.brennan@oracle.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 18ea76a747acd2d1a435f0f22224ab956a864329 Author: Arnaldo Carvalho de Melo Date: Wed Mar 12 17:31:41 2025 -0300 perf python: Check if there is space to copy all the event [ Upstream commit 89aaeaf84231157288035b366cb6300c1c6cac64 ] The pyrf_event__new() method copies the event obtained from the perf ring buffer to a structure that will then be turned into a python object for further consumption, so it copies perf_event.header.size bytes to its 'event' member: $ pahole -C pyrf_event /tmp/build/perf-tools-next/python/perf.cpython-312-x86_64-linux-gnu.so struct pyrf_event { PyObject ob_base; /* 0 16 */ struct evsel * evsel; /* 16 8 */ struct perf_sample sample; /* 24 312 */ /* XXX last struct has 7 bytes of padding, 2 holes */ /* --- cacheline 5 boundary (320 bytes) was 16 bytes ago --- */ union perf_event event; /* 336 4168 */ /* size: 4504, cachelines: 71, members: 4 */ /* member types with holes: 1, total: 2 */ /* paddings: 1, sum paddings: 7 */ /* last cacheline: 24 bytes */ }; $ It was doing so without checking if the event just obtained has more than that space, fix it. This isn't a proper, final solution, as we need to support larger events, but for the time being we at least bounds check and document it. Fixes: 877108e42b1b9ba6 ("perf tools: Initial python binding") Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250312203141.285263-7-acme@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 9816424d65a23e1c083d8c138ac54067dae47126 Author: Arnaldo Carvalho de Melo Date: Wed Mar 12 17:31:40 2025 -0300 perf python: Don't keep a raw_data pointer to consumed ring buffer space [ Upstream commit f3fed3ae34d606819d87a63d970cc3092a5be7ab ] When processing tracepoints the perf python binding was parsing the event before calling perf_mmap__consume(&md->core) in pyrf_evlist__read_on_cpu(). But part of this event parsing was to set the perf_sample->raw_data pointer to the payload of the event, which then could be overwritten by other event before tracepoint fields were asked for via event.prev_comm in a python program, for instance. This also happened with other fields, but strings were were problems were surfacing, as there is UTF-8 validation for the potentially garbled data. This ended up showing up as (with some added debugging messages): ( field 'prev_comm' ret=0x7f7c31f65110, raw_size=68 ) ( field 'prev_pid' ret=0x7f7c23b1bed0, raw_size=68 ) ( field 'prev_prio' ret=0x7f7c239c0030, raw_size=68 ) ( field 'prev_state' ret=0x7f7c239c0250, raw_size=68 ) time 14771421785867 prev_comm= prev_pid=1919907691 prev_prio=796026219 prev_state=0x303a32313175 ==> ( XXX '��' len=16, raw_size=68) ( field 'next_comm' ret=(nil), raw_size=68 ) Traceback (most recent call last): File "/home/acme/git/perf-tools-next/tools/perf/python/tracepoint.py", line 51, in main() File "/home/acme/git/perf-tools-next/tools/perf/python/tracepoint.py", line 46, in main event.next_comm, ^^^^^^^^^^^^^^^ AttributeError: 'perf.sample_event' object has no attribute 'next_comm' When event.next_comm was asked for, the PyUnicode_FromString() python API would fail and that tracepoint field wouldn't be available, stopping the tools/perf/python/tracepoint.py test tool. But, since we already do a copy of the whole event in pyrf_event__new, just use it and while at it remove what was done in in e8968e654191390a ("perf python: Fix pyrf_evlist__read_on_cpu event consuming") because we don't really need to wait for parsing the sample before declaring the event as consumed. This copy is questionable as is now, as it limits the maximum event + sample_type and tracepoint payload to sizeof(union perf_event), this all has been "working" because 'struct perf_event_mmap2', the largest entry in 'union perf_event' is: $ pahole -C perf_event ~/bin/perf | grep mmap2 struct perf_record_mmap2 mmap2; /* 0 4168 */ $ Fixes: bae57e3825a3dded ("perf python: Add support to resolve tracepoint fields") Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250312203141.285263-6-acme@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 4608d15a43fb347beed040342586187456e57c2a Author: Arnaldo Carvalho de Melo Date: Wed Mar 12 17:31:39 2025 -0300 perf python: Decrement the refcount of just created event on failure [ Upstream commit 3de5a2bf5b4847f7a59a184568f969f8fe05d57f ] To avoid a leak if we have the python object but then something happens and we need to return the operation, decrement the offset of the newly created object. Fixes: 377f698db12150a1 ("perf python: Add struct evsel into struct pyrf_event") Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250312203141.285263-5-acme@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit f0343969111f269e7a6d1498712a0f6560987e01 Author: Arnaldo Carvalho de Melo Date: Wed Mar 12 17:31:36 2025 -0300 perf python: Fixup description of sample.id event member [ Upstream commit 1376c195e8ad327bb9f2d32e0acc5ac39e7cb30a ] Some old cut'n'paste error, its "ip", so the description should be "event ip", not "event type". Fixes: 877108e42b1b9ba6 ("perf tools: Initial python binding") Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250312203141.285263-2-acme@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit e1c900e078d588a18b64ebc19f59243fd1ab2ad2 Author: Stanley Chu Date: Tue Mar 18 13:36:04 2025 +0800 i3c: master: svc: Fix missing the IBI rules [ Upstream commit 9cecad134d84d14dc72a0eea7a107691c3e5a837 ] The code does not add IBI rules for devices with controller capability. However, the secondary controller has the controller capability and works at target mode when the device is probed. Therefore, add IBI rules for such devices. Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver") Signed-off-by: Stanley Chu Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250318053606.3087121-2-yschu@nuvoton.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit a8edfc206ed109201c9d1dc7a5da3d3da20949d5 Author: Benjamin Berg Date: Fri Feb 14 10:28:22 2025 +0100 um: hostfs: avoid issues on inode number reuse by host [ Upstream commit 0bc754d1e31f40f4a343b692096d9e092ccc0370 ] Some file systems (e.g. ext4) may reuse inode numbers once the inode is not in use anymore. Usually hostfs will keep an FD open for each inode, but this is not always the case. In the case of sockets, this cannot even be done properly. As such, the following sequence of events was possible: * application creates and deletes a socket * hostfs creates/deletes the socket on the host * inode is still in the hostfs cache * hostfs creates a new file * ext4 on the outside reuses the inode number * hostfs finds the socket inode for the newly created file * application receives -ENXIO when opening the file As mentioned, this can only happen if the deleted file is a special file that is never opened on the host (i.e. no .open fop). As such, to prevent issues, it is sufficient to check that the inode has the expected type. That said, also add a check for the inode birth time, just to be on the safe side. Fixes: 74ce793bcbde ("hostfs: Fix ephemeral inodes") Signed-off-by: Benjamin Berg Reviewed-by: Mickaël Salaün Tested-by: Mickaël Salaün Link: https://patch.msgid.link/20250214092822.1241575-1-benjamin@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 5b37d2370d0c37fbf4dd7e6842cd1e0145605fbc Author: Benjamin Berg Date: Mon Feb 10 17:09:26 2025 +0100 um: remove copy_from_kernel_nofault_allowed [ Upstream commit 84a6fc378471fbeaf48f8604566a5a33a3d63c18 ] There is no need to override the default version of this function anymore as UML now has proper _nofault memory access functions. Doing this also fixes the fact that the implementation was incorrect as using mincore() will incorrectly flag pages as inaccessible if they were swapped out by the host. Fixes: f75b1b1bedfb ("um: Implement probe_kernel_read()") Signed-off-by: Benjamin Berg Link: https://patch.msgid.link/20250210160926.420133-3-benjamin@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2b0328c5f0f972ed3ec485cc2f57993b46e456d2 Author: David Gow Date: Mon Feb 10 18:53:51 2025 +0800 um: Pass the correct Rust target and options with gcc [ Upstream commit 5550187c4c21740942c32a9ae56f9f472a104cb4 ] In order to work around some issues with disabling SSE on older versions of gcc (compilation would fail upon seeing a function declaration containing a float, even if it was never called or defined), the corresponding CFLAGS and RUSTFLAGS were only set when using clang. However, this led to two problems: - Newer gcc versions also wouldn't get the correct flags, despite not having the bug. - The RUSTFLAGS for setting the rust target definition were not set, despite being unrelated. This works by chance for x86_64, as the built-in default target is close enough, but not for 32-bit x86. Move the target definition outside the conditional block, and update the condition to take into account the gcc version. Fixes: a3046a618a28 ("um: Only disable SSE on clang to work around old GCC bugs") Signed-off-by: David Gow Link: https://patch.msgid.link/20250210105353.2238769-2-davidgow@google.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0d8ba0ed03c3ff277fa0d271f0905e60991282fb Author: Cyan Yang Date: Wed Mar 12 12:38:40 2025 +0800 selftests/mm/cow: fix the incorrect error handling [ Upstream commit f841ad9ca5007167c02de143980c9dc703f90b3d ] Error handling doesn't check the correct return value. This patch will fix it. Link: https://lkml.kernel.org/r/20250312043840.71799-1-cyan.yang@sifive.com Fixes: f4b5fd6946e2 ("selftests/vm: anon_cow: THP tests") Signed-off-by: Cyan Yang Reviewed-by: Dev Jain Reviewed-by: Muhammad Usama Anjum Cc: David Hildenbrand Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit eafb4e3a82aa29112cc3cef46e4c9e7ab700d797 Author: Alistair Popple Date: Fri Feb 28 14:30:56 2025 +1100 fuse: fix dax truncate/punch_hole fault path [ Upstream commit 7851bf649d423edd7286b292739f2eefded3d35c ] Patch series "fs/dax: Fix ZONE_DEVICE page reference counts", v9. Device and FS DAX pages have always maintained their own page reference counts without following the normal rules for page reference counting. In particular pages are considered free when the refcount hits one rather than zero and refcounts are not added when mapping the page. Tracking this requires special PTE bits (PTE_DEVMAP) and a secondary mechanism for allowing GUP to hold references on the page (see get_dev_pagemap). However there doesn't seem to be any reason why FS DAX pages need their own reference counting scheme. By treating the refcounts on these pages the same way as normal pages we can remove a lot of special checks. In particular pXd_trans_huge() becomes the same as pXd_leaf(), although I haven't made that change here. It also frees up a valuable SW define PTE bit on architectures that have devmap PTE bits defined. It also almost certainly allows further clean-up of the devmap managed functions, but I have left that as a future improvment. It also enables support for compound ZONE_DEVICE pages which is one of my primary motivators for doing this work. This patch (of 20): FS DAX requires file systems to call into the DAX layout prior to unlinking inodes to ensure there is no ongoing DMA or other remote access to the direct mapped page. The fuse file system implements fuse_dax_break_layouts() to do this which includes a comment indicating that passing dmap_end == 0 leads to unmapping of the whole file. However this is not true - passing dmap_end == 0 will not unmap anything before dmap_start, and further more dax_layout_busy_page_range() will not scan any of the range to see if there maybe ongoing DMA access to the range. Fix this by passing -1 for dmap_end to fuse_dax_break_layouts() which will invalidate the entire file range to dax_layout_busy_page_range(). Link: https://lkml.kernel.org/r/cover.8068ad144a7eea4a813670301f4d2a86a8e68ec4.1740713401.git-series.apopple@nvidia.com Link: https://lkml.kernel.org/r/f09a34b6c40032022e4ddee6fadb7cc676f08867.1740713401.git-series.apopple@nvidia.com Fixes: 6ae330cad6ef ("virtiofs: serialize truncate/punch_hole and dax fault path") Signed-off-by: Alistair Popple Co-developed-by: Dan Williams Signed-off-by: Dan Williams Reviewed-by: Balbir Singh Tested-by: Alison Schofield Cc: Vivek Goyal Cc: Alexander Gordeev Cc: Asahi Lina Cc: Bjorn Helgaas Cc: Catalin Marinas Cc: Christian Borntraeger Cc: Christoph Hellwig Cc: Chunyan Zhang Cc: "Darrick J. Wong" Cc: Dave Chinner Cc: Dave Hansen Cc: Dave Jiang Cc: David Hildenbrand Cc: Gerald Schaefer Cc: Heiko Carstens Cc: Huacai Chen Cc: Ira Weiny Cc: Jan Kara Cc: Jason Gunthorpe Cc: Jason Gunthorpe Cc: John Hubbard Cc: linmiaohe Cc: Logan Gunthorpe Cc: Matthew Wilcow (Oracle) Cc: Michael "Camp Drill Sergeant" Ellerman Cc: Nicholas Piggin Cc: Peter Xu Cc: Sven Schnelle Cc: Ted Ts'o Cc: Vasily Gorbik Cc: Vishal Verma Cc: WANG Xuerui Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit ca27c16539a30d67ac50b5c2ba093ea80aa1bc69 Author: NeilBrown Date: Wed Dec 4 13:53:09 2024 +1100 NFS: fix open_owner_id_maxsz and related fields. [ Upstream commit 43502f6e8d1e767d6736ea0676cc784025cf6eeb ] A recent change increased the size of an NFSv4 open owner, but didn't increase the corresponding max_sz defines. This is not know to have caused failure, but should be fixed. This patch also fixes some relates _maxsz fields that are wrong. Note that the XXX_owner_id_maxsz values now are only the size of the id and do NOT include the len field that will always preceed the id in xdr encoding. I think this is clearer. Reported-by: David Disseldorp Fixes: d98f72272500 ("nfs: simplify and guarantee owner uniqueness.") Signed-off-by: NeilBrown Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 46117472a279c2da7729ce75abc202ca6d72aff6 Author: Trond Myklebust Date: Tue Feb 18 18:37:51 2025 -0500 NFSv4: Avoid unnecessary scans of filesystems for delayed delegations [ Upstream commit e767b59e29b8327d25edde65efc743f479f30d0a ] The amount of looping through the list of delegations is occasionally leading to soft lockups. If the state manager was asked to manage the delayed return of delegations, then only scan those filesystems containing delegations that were marked as being delayed. Fixes: be20037725d1 ("NFSv4: Fix delegation return in cases where we have to retry") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 8765bc2638ce755d6ec159d2fa3296d870da6eed Author: Trond Myklebust Date: Tue Feb 18 19:03:21 2025 -0500 NFSv4: Avoid unnecessary scans of filesystems for expired delegations [ Upstream commit f163aa81a799e2d46d7f8f0b42a0e7770eaa0d06 ] The amount of looping through the list of delegations is occasionally leading to soft lockups. If the state manager was asked to reap the expired delegations, it should scan only those filesystems that hold delegations that need to be reaped. Fixes: 7f156ef0bf45 ("NFSv4: Clean up nfs_delegation_reap_expired()") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit ac8be75a7deb073439a1bc9dd1f717223bacc496 Author: Trond Myklebust Date: Tue Feb 18 18:14:26 2025 -0500 NFSv4: Avoid unnecessary scans of filesystems for returning delegations [ Upstream commit 35a566a24e58f1b5f89737edf60b77de58719ed0 ] The amount of looping through the list of delegations is occasionally leading to soft lockups. If the state manager was asked to return delegations asynchronously, it should only scan those filesystems that hold delegations that need to be returned. Fixes: af3b61bf6131 ("NFSv4: Clean up nfs_client_return_marked_delegations()") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 4595beb5fee9b9e714c1e0e3ce7400b86c24a524 Author: Trond Myklebust Date: Tue Feb 18 16:50:30 2025 -0500 NFSv4: Don't trigger uneccessary scans for return-on-close delegations [ Upstream commit 47acca884f714f41d95dc654f802845544554784 ] The amount of looping through the list of delegations is occasionally leading to soft lockups. Avoid at least some loops by not requiring the NFSv4 state manager to scan for delegations that are marked for return-on-close. Instead, either mark them for immediate return (if possible) or else leave it up to nfs4_inode_return_delegation_on_close() to return them once the file is closed by the application. Fixes: b757144fd77c ("NFSv4: Be less aggressive about returning delegations for open files") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit d04bea49c806b32e8a6c5eb7a858adaaa0336e3e Author: Anshuman Khandual Date: Wed Feb 26 17:54:01 2025 +0530 arch/powerpc: drop GENERIC_PTDUMP from mpc885_ads_defconfig [ Upstream commit 2c5e6ac2db64ace51f66a9f3b3b3ab9553d748e8 ] GENERIC_PTDUMP gets selected on powerpc explicitly and hence can be dropped off from mpc885_ads_defconfig. Replace with CONFIG_PTDUMP_DEBUGFS instead. Link: https://lkml.kernel.org/r/20250226122404.1927473-3-anshuman.khandual@arm.com Fixes: e084728393a5 ("powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP") Signed-off-by: Anshuman Khandual Suggested-by: Christophe Leroy Reviewed-by: Christophe Leroy Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Catalin Marinas Cc: Heiko Carstens Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Marc Zyngier Cc: Mark Rutland Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Steven Price Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 49d2a2ea9d30991bae82107f9523915b91637683 Author: Vasiliy Kovalev Date: Fri Feb 14 11:49:08 2025 +0300 ocfs2: validate l_tree_depth to avoid out-of-bounds access [ Upstream commit a406aff8c05115119127c962cbbbbd202e1973ef ] The l_tree_depth field is 16-bit (__le16), but the actual maximum depth is limited to OCFS2_MAX_PATH_DEPTH. Add a check to prevent out-of-bounds access if l_tree_depth has an invalid value, which may occur when reading from a corrupted mounted disk [1]. Link: https://lkml.kernel.org/r/20250214084908.736528-1-kovalev@altlinux.org Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Vasiliy Kovalev Reported-by: syzbot+66c146268dc88f4341fd@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=66c146268dc88f4341fd [1] Reviewed-by: Joseph Qi Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Kurt Hackel Cc: Mark Fasheh Cc: Vasiliy Kovalev Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit c6338b0d56f0840b09b8a0e91ad9e44b0f788eda Author: Sourabh Jain Date: Fri Jan 31 17:08:24 2025 +0530 kexec: initialize ELF lowest address to ULONG_MAX [ Upstream commit 9986fb5164c8b21f6439cfd45ba36d8cc80c9710 ] Patch series "powerpc/crash: use generic crashkernel reservation", v3. Commit 0ab97169aa05 ("crash_core: add generic function to do reservation") added a generic function to reserve crashkernel memory. So let's use the same function on powerpc and remove the architecture-specific code that essentially does the same thing. The generic crashkernel reservation also provides a way to split the crashkernel reservation into high and low memory reservations, which can be enabled for powerpc in the future. Additionally move powerpc to use generic APIs to locate memory hole for kexec segments while loading kdump kernel. This patch (of 7): kexec_elf_load() loads an ELF executable and sets the address of the lowest PT_LOAD section to the address held by the lowest_load_addr function argument. To determine the lowest PT_LOAD address, a local variable lowest_addr (type unsigned long) is initialized to UINT_MAX. After loading each PT_LOAD, its address is compared to lowest_addr. If a loaded PT_LOAD address is lower, lowest_addr is updated. However, setting lowest_addr to UINT_MAX won't work when the kernel image is loaded above 4G, as the returned lowest PT_LOAD address would be invalid. This is resolved by initializing lowest_addr to ULONG_MAX instead. This issue was discovered while implementing crashkernel high/low reservation on the PowerPC architecture. Link: https://lkml.kernel.org/r/20250131113830.925179-1-sourabhjain@linux.ibm.com Link: https://lkml.kernel.org/r/20250131113830.925179-2-sourabhjain@linux.ibm.com Fixes: a0458284f062 ("powerpc: Add support code for kexec_file_load()") Signed-off-by: Sourabh Jain Acked-by: Hari Bathini Acked-by: Baoquan He Cc: Madhavan Srinivasan Cc: Mahesh Salgaonkar Cc: Michael Ellerman Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit c42282a07832d6bff065a4be005441a4876d1988 Author: David Hildenbrand Date: Mon Feb 10 20:37:50 2025 +0100 kernel/events/uprobes: handle device-exclusive entries correctly in __replace_page() [ Upstream commit 096cbb80ab3fd85a9035ec17a1312c2a7db8bc8c ] Ever since commit b756a3b5e7ea ("mm: device exclusive memory access") we can return with a device-exclusive entry from page_vma_mapped_walk(). __replace_page() is not prepared for that, so teach it about these PFN swap PTEs. Note that device-private entries are so far not applicable on that path, because GUP would never have returned such folios (conversion to device-private happens by page migration, not in-place conversion of the PTE). There is a race between GUP and us locking the folio to look it up using page_vma_mapped_walk(), so this is likely a fix (unless something else could prevent that race, but it doesn't look like). pte_pfn() on something that is not a present pte could give use garbage, and we'd wrongly mess up the mapcount because it was already adjusted by calling folio_remove_rmap_pte() when making the entry device-exclusive. Link: https://lkml.kernel.org/r/20250210193801.781278-9-david@redhat.com Fixes: b756a3b5e7ea ("mm: device exclusive memory access") Signed-off-by: David Hildenbrand Tested-by: Alistair Popple Cc: Alex Shi Cc: Danilo Krummrich Cc: Dave Airlie Cc: Jann Horn Cc: Jason Gunthorpe Cc: Jerome Glisse Cc: John Hubbard Cc: Jonathan Corbet Cc: Karol Herbst Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Lyude Cc: "Masami Hiramatsu (Google)" Cc: Oleg Nesterov Cc: Pasha Tatashin Cc: Peter Xu Cc: Peter Zijlstra (Intel) Cc: SeongJae Park Cc: Simona Vetter Cc: Vlastimil Babka Cc: Yanteng Si Cc: Barry Song Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 32222c0fd242d3294038b21252f3f385287ec712 Author: Arnaldo Carvalho de Melo Date: Mon Mar 10 16:45:32 2025 -0300 perf units: Fix insufficient array space [ Upstream commit cf67629f7f637fb988228abdb3aae46d0c1748fe ] No need to specify the array size, let the compiler figure that out. This addresses this compiler warning that was noticed while build testing on fedora rawhide: 31 15.81 fedora:rawhide : FAIL gcc version 15.0.1 20250225 (Red Hat 15.0.1-0) (GCC) util/units.c: In function 'unit_number__scnprintf': util/units.c:67:24: error: initializer-string for array of 'char' is too long [-Werror=unterminated-string-initialization] 67 | char unit[4] = "BKMG"; | ^~~~~~ cc1: all warnings being treated as errors Fixes: 9808143ba2e54818 ("perf tools: Add unit_number__scnprintf function") Signed-off-by: Arnaldo Carvalho de Melo Link: https://lore.kernel.org/r/20250310194534.265487-3-acme@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b18056f753bf477c58cd53991e7e59659d52cf87 Author: Ian Rogers Date: Fri Feb 28 14:22:59 2025 -0800 perf evlist: Add success path to evlist__create_syswide_maps [ Upstream commit fe0ce8a9d85a48642880c9b78944cb0d23e779c5 ] Over various refactorings evlist__create_syswide_maps has been made to only ever return with -ENOMEM. Fix this so that when perf_evlist__set_maps is successfully called, 0 is returned. Reviewed-by: Howard Chu Signed-off-by: Ian Rogers Reviewed-by: Arnaldo Carvalho de Melo Link: https://lore.kernel.org/r/20250228222308.626803-3-irogers@google.com Fixes: 8c0498b6891d7ca5 ("perf evlist: Fix create_syswide_maps() not propagating maps") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 7cd1096d3bead15446433559e4419bbffa033e03 Author: Ian Rogers Date: Fri Feb 28 14:22:58 2025 -0800 perf debug: Avoid stack overflow in recursive error message [ Upstream commit bda840191d2aae3b7cadc3ac21835dcf29487191 ] In debug_file, pr_warning_once is called on error. As that function calls debug_file the function will yield a stack overflow. Switch the location of the call so the recursion is avoided. Reviewed-by: Howard Chu Signed-off-by: Ian Rogers Reviewed-by: Arnaldo Carvalho de Melo Link: https://lore.kernel.org/r/20250228222308.626803-2-irogers@google.com Fixes: ec49230cf6dda704 ("perf debug: Expose debug file") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 7a40b52d4442178bee0cf1c36bc450ab951cef0f Author: Karan Sanghavi Date: Thu Feb 20 17:34:36 2025 +0000 iio: light: Add check for array bounds in veml6075_read_int_time_ms [ Upstream commit ee735aa33db16c1fb5ebccbaf84ad38f5583f3cc ] The array contains only 5 elements, but the index calculated by veml6075_read_int_time_index can range from 0 to 7, which could lead to out-of-bounds access. The check prevents this issue. Coverity Issue CID 1574309: (#1 of 1): Out-of-bounds read (OVERRUN) overrun-local: Overrunning array veml6075_it_ms of 5 4-byte elements at element index 7 (byte offset 31) using index int_index (which evaluates to 7) This is hardening against potentially broken hardware. Good to have but not necessary to backport. Fixes: 3b82f43238ae ("iio: light: add VEML6075 UVA and UVB light sensor driver") Signed-off-by: Karan Sanghavi Reviewed-by: Javier Carrasco Link: https://patch.msgid.link/Z7dnrEpKQdRZ2qFU@Emma Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 967570b52826741f51d5ebdbeff264e425c426ce Author: Jonathan Santos Date: Thu Mar 6 18:00:43 2025 -0300 iio: adc: ad7768-1: set MOSI idle state to prevent accidental reset [ Upstream commit 2416cec859299be04d021b4cf98eff814f345af7 ] Datasheet recommends Setting the MOSI idle state to high in order to prevent accidental reset of the device when SCLK is free running. This happens when the controller clocks out a 1 followed by 63 zeros while the CS is held low. Check if SPI controller supports SPI_MOSI_IDLE_HIGH flag and set it. Fixes: a5f8c7da3dbe ("iio: adc: Add AD7768-1 ADC basic support") Signed-off-by: Jonathan Santos Reviewed-by: Marcelo Schmitt Link: https://patch.msgid.link/c2a2b0f3d54829079763a5511359a1fa80516cfb.1741268122.git.Jonathan.Santos@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit dd6391006379d7c3ff42936dfa28bb76555b70d4 Author: Uwe Kleine-König Date: Mon Mar 3 12:47:02 2025 +0100 iio: adc: ad7173: Fix comparison of channel configs [ Upstream commit 7b6033ed5a9e1a369a9cf58018388ae4c5f17e41 ] Checking the binary representation of two structs (of the same type) for equality doesn't have the same semantic as comparing all members for equality. The former might find a difference where the latter doesn't in the presence of padding or when ambiguous types like float or bool are involved. (Floats typically have different representations for single values, like -0.0 vs +0.0, or 0.5 * 2² vs 0.25 * 2³. The type bool has at least 8 bits and the raw values 1 and 2 (probably) both evaluate to true, but memcmp finds a difference.) When searching for a channel that already has the configuration we need, the comparison by member is the one that is needed. Convert the comparison accordingly to compare the members one after another. Also add a static_assert guard to (somewhat) ensure that when struct ad7173_channel_config::config_props is expanded, the comparison is adapted, too. This issue is somewhat theoretic, but using memcmp() on a struct is a bad pattern that is worth fixing. Fixes: 76a1e6a42802 ("iio: adc: ad7173: add AD7173 driver") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/20250303114659.1672695-14-u.kleine-koenig@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 12eeec2fe012f4e15738cc609b13bcdc1e393ac3 Author: Uwe Kleine-König Date: Mon Mar 3 12:47:01 2025 +0100 iio: adc: ad7124: Fix comparison of channel configs [ Upstream commit 05a5d874f7327b75e9bc4359618017e047cc129c ] Checking the binary representation of two structs (of the same type) for equality doesn't have the same semantic as comparing all members for equality. The former might find a difference where the latter doesn't in the presence of padding or when ambiguous types like float or bool are involved. (Floats typically have different representations for single values, like -0.0 vs +0.0, or 0.5 * 2² vs 0.25 * 2³. The type bool has at least 8 bits and the raw values 1 and 2 (probably) both evaluate to true, but memcmp finds a difference.) When searching for a channel that already has the configuration we need, the comparison by member is the one that is needed. Convert the comparison accordingly to compare the members one after another. Also add a static_assert guard to (somewhat) ensure that when struct ad7124_channel_config::config_props is expanded, the comparison is adapted, too. This issue is somewhat theoretic, but using memcmp() on a struct is a bad pattern that is worth fixing. Fixes: 7b8d045e497a ("iio: adc: ad7124: allow more than 8 channels") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/20250303114659.1672695-13-u.kleine-koenig@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 0c13dc967e07b8338253626dcf0de04c40c34d3e Author: Uwe Kleine-König Date: Mon Mar 3 12:47:00 2025 +0100 iio: adc: ad4130: Fix comparison of channel setups [ Upstream commit 280acb19824663d55a3f4d09087c76fabe86fa3c ] Checking the binary representation of two structs (of the same type) for equality doesn't have the same semantic as comparing all members for equality. The former might find a difference where the latter doesn't in the presence of padding or when ambiguous types like float or bool are involved. (Floats typically have different representations for single values, like -0.0 vs +0.0, or 0.5 * 2² vs 0.25 * 2³. The type bool has at least 8 bits and the raw values 1 and 2 (probably) both evaluate to true, but memcmp finds a difference.) When searching for a channel that already has the configuration we need, the comparison by member is the one that is needed. Convert the comparison accordingly to compare the members one after another. Also add a static_assert guard to (somewhat) ensure that when struct ad4130_setup_info is expanded, the comparison is adapted, too. This issue is somewhat theoretic, but using memcmp() on a struct is a bad pattern that is worth fixing. Fixes: 62094060cf3a ("iio: adc: ad4130: add AD4130 driver") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/20250303114659.1672695-12-u.kleine-koenig@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 55e2dbe2ba787d4fc2306f6bb2f43fb32176e184 Author: Peng Fan Date: Fri Feb 28 15:17:20 2025 +0800 dmaengine: fsl-edma: free irq correctly in remove path [ Upstream commit fa70c4c3c580c239a0f9e83a14770ab026e8d820 ] Add fsl_edma->txirq/errirq check to avoid below warning because no errirq at i.MX9 platform. Otherwise there will be kernel dump: WARNING: CPU: 0 PID: 11 at kernel/irq/devres.c:144 devm_free_irq+0x74/0x80 Modules linked in: CPU: 0 UID: 0 PID: 11 Comm: kworker/u8:0 Not tainted 6.12.0-rc7#18 Hardware name: NXP i.MX93 11X11 EVK board (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : devm_free_irq+0x74/0x80 lr : devm_free_irq+0x48/0x80 Call trace: devm_free_irq+0x74/0x80 (P) devm_free_irq+0x48/0x80 (L) fsl_edma_remove+0xc4/0xc8 platform_remove+0x28/0x44 device_remove+0x4c/0x80 Fixes: 44eb827264de ("dmaengine: fsl-edma: request per-channel IRQ only when channel is allocated") Reviewed-by: Frank Li Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20250228071720.3780479-2-peng.fan@oss.nxp.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit bcd00d044346d149e616061b474215de036e29f1 Author: Peng Fan Date: Fri Feb 28 15:17:19 2025 +0800 dmaengine: fsl-edma: cleanup chan after dma_async_device_unregister [ Upstream commit c9c59da76ce9cb3f215b66eb3708cda1134a5206 ] There is kernel dump when do module test: sysfs: cannot create duplicate filename /devices/platform/soc@0/44000000.bus/44000000.dma-controller/dma/dma0chan0 __dma_async_device_channel_register+0x128/0x19c dma_async_device_register+0x150/0x454 fsl_edma_probe+0x6cc/0x8a0 platform_probe+0x68/0xc8 fsl_edma_cleanup_vchan will unlink vchan.chan.device_node, while dma_async_device_unregister needs the link to do __dma_async_device_channel_unregister. So need move fsl_edma_cleanup_vchan after dma_async_device_unregister to make sure channel could be freed. So clean up chan after dma_async_device_unregister to address this. Fixes: 6f93b93b2a1b ("dmaengine: fsl-edma: kill the tasklets upon exit") Reviewed-by: Frank Li Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20250228071720.3780479-1-peng.fan@oss.nxp.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 201a2bdda13b619c4927700ffe47d387a30ced50 Author: Dan Carpenter Date: Sun Feb 16 23:52:10 2025 +0300 fs/ntfs3: Prevent integer overflow in hdr_first_de() [ Upstream commit 6bb81b94f7a9cba6bde9a905cef52a65317a8b04 ] The "de_off" and "used" variables come from the disk so they both need to check. The problem is that on 32bit systems if they're both greater than UINT_MAX - 16 then the check does work as intended because of an integer overflow. Fixes: 60ce8dfde035 ("fs/ntfs3: Fix wrong if in hdr_first_de") Signed-off-by: Dan Carpenter Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 284c9549386e9883855fb82b730303bb2edea9de Author: Dan Carpenter Date: Sun Feb 16 23:52:00 2025 +0300 fs/ntfs3: Fix a couple integer overflows on 32bit systems [ Upstream commit 5ad414f4df2294b28836b5b7b69787659d6aa708 ] On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add(). Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Dan Carpenter Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 8109f57613a06bb7f9279e0c4fa0103174b05d2f Author: Niklas Neronin Date: Thu Mar 6 16:49:47 2025 +0200 usb: xhci: correct debug message page size calculation [ Upstream commit 55741c723318905e6d5161bf1e12749020b161e3 ] The ffs() function returns the index of the first set bit, starting from 1. If no bits are set, it returns zero. This behavior causes an off-by-one page size in the debug message, as the page size calculation [1] is zero-based, while ffs() is one-based. Fix this by subtracting one from the result of ffs(). Note that since variable 'val' is unsigned, subtracting one from zero will result in the maximum unsigned integer value. Consequently, the condition 'if (val < 16)' will still function correctly. [1], Page size: (2^(n+12)), where 'n' is the set page size bit. Fixes: 81720ec5320c ("usb: host: xhci: use ffs() in xhci_mem_init()") Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250306144954.3507700-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fc1b20f168977e716297954fe5ad2187002e54a0 Author: Thomas Richter Date: Tue Mar 4 10:23:49 2025 +0100 perf bench: Fix perf bench syscall loop count [ Upstream commit 957d194163bf983da98bf7ec7e4f86caff8cd0eb ] Command 'perf bench syscall fork -l 100000' offers option -l to run for a specified number of iterations. However this option is not always observed. The number is silently limited to 10000 iterations as can be seen: Output before: # perf bench syscall fork -l 100000 # Running 'syscall/fork' benchmark: # Executed 10,000 fork() calls Total time: 23.388 [sec] 2338.809800 usecs/op 427 ops/sec # When explicitly specified with option -l or --loops, also observe higher number of iterations: Output after: # perf bench syscall fork -l 100000 # Running 'syscall/fork' benchmark: # Executed 100,000 fork() calls Total time: 716.982 [sec] 7169.829510 usecs/op 139 ops/sec # This patch fixes the issue for basic execve fork and getpgid. Fixes: ece7f7c0507c ("perf bench syscall: Add fork syscall benchmark") Signed-off-by: Thomas Richter Acked-by: Sumanth Korikkar Tested-by: Athira Rajeev Cc: Tiezhu Yang Link: https://lore.kernel.org/r/20250304092349.2618082-1-tmricht@linux.ibm.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 8e901e95bedcd7e055e6ac270a37a765a2757746 Author: Leo Yan Date: Tue Mar 4 11:12:34 2025 +0000 perf arm-spe: Fix load-store operation checking [ Upstream commit e1d47850bbf79a541c9b3bacdd562f5e0112274d ] The ARM_SPE_OP_LD and ARM_SPE_OP_ST operations are secondary operation type, they are overlapping with other second level's operation types belonging to SVE and branch operations. As a result, a non load-store operation can be parsed for data source and memory sample. To fix the issue, this commit introduces a is_ldst_op() macro for checking LDST operation, and apply the checking when synthesize data source and memory samples. Fixes: a89dbc9b988f ("perf arm-spe: Set sample's data source field") Signed-off-by: Leo Yan Reviewed-by: James Clark Link: https://lore.kernel.org/r/20250304111240.3378214-7-leo.yan@arm.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit df3892e5e861c43d5612728ed259634675b8a71f Author: Nuno Sá Date: Tue Feb 18 10:31:25 2025 +0000 iio: backend: make sure to NULL terminate stack buffer [ Upstream commit 035b4989211dc1c8626e186d655ae8ca5141bb73 ] Make sure to NULL terminate the buffer in iio_backend_debugfs_write_reg() before passing it to sscanf(). It is a stack variable so we should not assume it will 0 initialized. Fixes: cdf01e0809a4 ("iio: backend: add debugFs interface") Signed-off-by: Nuno Sá Reviewed-by: David Lechner Link: https://patch.msgid.link/20250218-dev-iio-misc-v1-1-bf72b20a1eb8@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 91cc7dca2a69366632ce19357155d3db29ceaed8 Author: Jonathan Cameron Date: Mon Feb 17 14:01:33 2025 +0000 iio: accel: msa311: Fix failure to release runtime pm if direct mode claim fails. [ Upstream commit 60a0cf2ebab92011055ab7db6553c0fc3c546938 ] Reorder the claiming of direct mode and runtime pm calls to simplify handling a little. For correct error handling, after the reorder iio_device_release_direct_mode() must be claimed in an error occurs in pm_runtime_resume_and_get() Fixes: 1ca2cfbc0c33 ("iio: add MEMSensing MSA311 3-axis accelerometer driver") Reviewed-by: David Lechner Link: https://patch.msgid.link/20250217140135.896574-7-jic23@kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 7c640dd70e63b8f6c72a3a0e74cbf92e28be29dc Author: Jonathan Cameron Date: Mon Feb 17 14:01:28 2025 +0000 iio: accel: mma8452: Ensure error return on failure to matching oversampling ratio [ Upstream commit df330c808182a8beab5d0f84a6cbc9cff76c61fc ] If a match was not found, then the write_raw() callback would return the odr index, not an error. Return -EINVAL if this occurs. To avoid similar issues in future, introduce j, a new indexing variable rather than using ret for this purpose. Fixes: 79de2ee469aa ("iio: accel: mma8452: claim direct mode during write raw") Reviewed-by: David Lechner Link: https://patch.msgid.link/20250217140135.896574-2-jic23@kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit a17a3db6d411265d6514d60a10d899fdcf17beb8 Author: Mario Limonciello Date: Thu Feb 20 23:40:03 2025 -0600 ucsi_ccg: Don't show failed to get FW build information error [ Upstream commit c16006852732dc4fe37c14b81f9b4458df05b832 ] The error `failed to get FW build information` is added for what looks to be for misdetection of the device property firmware-name. If the property is missing (such as on non-nvidia HW) this error shows up. Move the error into the scope of the property parser for "firmware-name" to avoid showing errors on systems without the firmware-name property. Fixes: 5c9ae5a87573d ("usb: typec: ucsi: ccg: add firmware flashing support") Signed-off-by: Mario Limonciello Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250221054137.1631765-2-superm1@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d72a8585043b2d795f1f39eaea33ad768a61ccc4 Author: Luca Ceresoli Date: Fri Jan 24 14:06:08 2025 +0100 perf build: Fix in-tree build due to symbolic link [ Upstream commit 75100d848ef4b8ca39bb6dd3a21181e37dea27e2 ] Building perf in-tree is broken after commit 890a1961c812 ("perf tools: Create source symlink in perf object dir") which added a 'source' symlink in the output dir pointing to the source dir. With in-tree builds, the added 'SOURCE = ...' line is executed multiple times (I observed 2 during the build plus 2 during installation). This is a minor inefficiency, in theory not harmful because symlink creation is assumed to be idempotent. But it is not. Considering with in-tree builds: srctree=/absolute/path/to/linux OUTPUT=/absolute/path/to/linux/tools/perf here's what happens: 1. ln -sf $(srctree)/tools/perf $(OUTPUT)/source -> creates /absolute/path/to/linux/tools/perf/source link to /absolute/path/to/linux/tools/perf => OK, that's what was intended 2. ln -sf $(srctree)/tools/perf $(OUTPUT)/source # same command as 1 -> creates /absolute/path/to/linux/tools/perf/perf link to /absolute/path/to/linux/tools/perf => Not what was intended, not idempotent 3. Now the build _should_ create the 'perf' executable, but it fails The reason is the tricky 'ln' command line. At the first invocation 'ln' uses the 1st form: ln [OPTION]... [-T] TARGET LINK_NAME and creates a link to TARGET *called LINK_NAME*. At the second invocation $(OUTPUT)/source exists, so 'ln' uses the 3rd form: ln [OPTION]... TARGET... DIRECTORY and creates a link to TARGET *called TARGET* inside DIRECTORY. Fix by adding -n/--no-dereference to "treat LINK_NAME as a normal file if it is a symbolic link to a directory", as the manpage says. Closes: https://lore.kernel.org/all/20241125182506.38af9907@booty/ Fixes: 890a1961c812 ("perf tools: Create source symlink in perf object dir") Signed-off-by: Luca Ceresoli Reviewed-by: Charlie Jenkins Tested-by: Charlie Jenkins Link: https://lore.kernel.org/r/20250124-perf-fix-intree-build-v1-1-485dd7a855e4@bootlin.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit a7b29a28d1e491305f388057b0819a07fdffb824 Author: Ian Rogers Date: Tue Feb 25 11:36:00 2025 -0800 tools/x86: Fix linux/unaligned.h include path in lib/insn.c [ Upstream commit fad07a5c0f07ad0884e1cb4362fe28c083b5b811 ] tools/arch/x86/include/linux doesn't exist but building is working by virtue of a -I. Building using bazel this fails. Use angle brackets to include unaligned.h so there isn't an invalid relative include. Fixes: 5f60d5f6bbc1 ("move asm/unaligned.h to linux/unaligned.h") Signed-off-by: Ian Rogers Acked-by: Josh Poimboeuf Cc: Al Viro Link: https://lore.kernel.org/r/20250225193600.90037-1-irogers@google.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 72a1497927147b13d3e5d1ae56a88289a63eb901 Author: James Clark Date: Wed Feb 26 10:41:01 2025 +0000 perf pmu: Don't double count common sysfs and json events [ Upstream commit c9d699e10fa6c0cdabcddcf991e7ff42af6b2503 ] After pmu_add_cpu_aliases() is called, perf_pmu__num_events() returns an incorrect value that double counts common events and doesn't match the actual count of events in the alias list. This is because after 'cpu_aliases_added == true', the number of events returned is 'sysfs_aliases + cpu_json_aliases'. But when adding 'case EVENT_SRC_SYSFS' events, 'sysfs_aliases' and 'cpu_json_aliases' are both incremented together, failing to account that these ones overlap and only add a single item to the list. Fix it by adding another counter for overlapping events which doesn't influence 'cpu_json_aliases'. There doesn't seem to be a current issue because it's used in perf list before pmu_add_cpu_aliases() so the correct value is returned. Other uses in tests may also miss it for other reasons like only looking at uncore events. However it's marked as a fixes commit in case any new fix with new uses of perf_pmu__num_events() is backported. Fixes: d9c5f5f94c2d ("perf pmu: Count sys and cpuid JSON events separately") Reviewed-by: Ian Rogers Signed-off-by: James Clark Link: https://lore.kernel.org/r/20250226104111.564443-3-james.clark@linaro.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 1315b08f609ee17d8ccccd8fa2e384ba6853e373 Author: Yuanfang Zhang Date: Thu Jan 16 17:04:20 2025 +0800 coresight-etm4x: add isb() before reading the TRCSTATR [ Upstream commit 4ff6039ffb79a4a8a44b63810a8a2f2b43264856 ] As recommended by section 4.3.7 ("Synchronization when using system instructions to progrom the trace unit") of ARM IHI 0064H.b, the self-hosted trace analyzer must perform a Context synchronization event between writing to the TRCPRGCTLR and reading the TRCSTATR. Additionally, add an ISB between the each read of TRCSTATR on coresight_timeout() when using system instructions to program the trace unit. Fixes: 1ab3bb9df5e3 ("coresight: etm4x: Add necessary synchronization for sysreg access") Signed-off-by: Yuanfang Zhang Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250116-etm_sync-v4-1-39f2b05e9514@quicinc.com Signed-off-by: Sasha Levin commit 3a19eb3d9818e28f14c818a18dc913344a52ca92 Author: Mike Christie Date: Wed Jan 29 15:09:22 2025 -0600 vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint [ Upstream commit 5dd639a1646ef5fe8f4bf270fad47c5c3755b9b6 ] If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang: 1. Use-after-free when no tpgs are found: This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do: vhost_vq_set_backend(vq, vs_tpg); ... kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via: kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If a scsi request is then sent we do: vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend which sees the vs_tpg we just did a kfree on. 2. Tpg dir removal hang: This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1. The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg. Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir. 3. Tpg leak: This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names. The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs. Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first. Fixes: 25b98b64e284 ("vhost scsi: alloc cmds per vq instead of session") Fixes: 4f7f46d32c98 ("tcm_vhost: Use vq->private_data to indicate if the endpoint is setup") Reported-by: Haoran Zhang Closes: https://lore.kernel.org/virtualization/e418a5ee-45ca-4d18-9b5d-6f8b6b1add8e@oracle.com/T/#me6c0041ce376677419b9b2563494172a01487ecb Signed-off-by: Mike Christie Reviewed-by: Stefan Hajnoczi Message-Id: <20250129210922.121533-1-michael.christie@oracle.com> Signed-off-by: Michael S. Tsirkin Acked-by: Stefano Garzarella Signed-off-by: Sasha Levin commit e90a5776e105f50b71e267b666a993ffec1e2aae Author: Ilkka Koskinen Date: Thu Jan 9 21:53:48 2025 +0000 coresight: catu: Fix number of pages while using 64k pages [ Upstream commit 0e14e062f5ff98aa15264dfa87c5f5e924028561 ] Trying to record a trace on kernel with 64k pages resulted in -ENOMEM. This happens due to a bug in calculating the number of table pages, which returns zero. Fix the issue by rounding up. $ perf record --kcore -e cs_etm/@tmc_etr55,cycacc,branch_broadcast/k --per-thread taskset --cpu-list 1 dd if=/dev/zero of=/dev/null failed to mmap with 12 (Cannot allocate memory) Fixes: 8ed536b1e283 ("coresight: catu: Add support for scatter gather tables") Signed-off-by: Ilkka Koskinen Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250109215348.5483-1-ilkka@os.amperecomputing.com Signed-off-by: Sasha Levin commit 6f774f82a7fa3dca70c1fa71b8dc2ae008c4efdc Author: Wentao Liang Date: Mon Jan 20 22:05:47 2025 +0800 greybus: gb-beagleplay: Add error handling for gb_greybus_init [ Upstream commit be382372d55d65b5c7e5a523793ca5e403f8c595 ] Add error handling for the gb_greybus_init(bg) function call during the firmware reflash process to maintain consistency in error handling throughout the codebase. If initialization fails, log an error and return FW_UPLOAD_ERR_RW_ERROR. Fixes: 0cf7befa3ea2 ("greybus: gb-beagleplay: Add firmware upload API") Signed-off-by: Wentao Liang Reviewed-by: Ayush Singh Link: https://lore.kernel.org/r/20250120140547.1460-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 372a144dbb961c63c559d6a46a121c79b2ae0d8f Author: Namhyung Kim Date: Mon Feb 10 22:07:44 2025 -0800 perf report: Switch data file correctly in TUI [ Upstream commit 43c2b6139b188d8a756130147f7efd5ddf99f88d ] The 's' key is to switch to a new data file and load the data in the same window. The switch_data_file() will show a popup menu to select which data file user wants and update the 'input_name' global variable. But in the cmd_report(), it didn't update the data.path using the new 'input_name' and keep usng the old file. This is fairly an old bug and I assume people don't use this feature much. :) Link: https://lore.kernel.org/r/20250211060745.294289-1-namhyung@kernel.org Closes: https://lore.kernel.org/linux-perf-users/89e678bc-f0af-4929-a8a6-a2666f1294a4@linaro.org Fixes: f5fc14124c5cefdd ("perf tools: Add data object to handle perf data file") Reported-by: James Clark Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 0e344b67bf26f6ea7f5696550848eada80c395e1 Author: Joe Hattori Date: Thu Dec 5 12:48:44 2024 +0900 soundwire: slave: fix an OF node reference leak in soundwire slave device [ Upstream commit aac2f8363f773ae1f65aab140e06e2084ac6b787 ] When initializing a soundwire slave device, an OF node is stored to the device with refcount incremented. However, the refcount is not decremented in .release(), thus call of_node_put() in sdw_slave_release(). Fixes: a2e484585ad3 ("soundwire: core: add device tree support for slave devices") Signed-off-by: Joe Hattori Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20241205034844.2784964-1-joe@pf.is.s.u-tokyo.ac.jp Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 82d0586c3592c87f6e8128046335276eef7a9b4a Author: Qasim Ijaz Date: Tue Feb 11 19:59:00 2025 +0000 isofs: fix KMSAN uninit-value bug in do_isofs_readdir() [ Upstream commit 81a82e8f33880793029cd6f8a766fb13b737e6a7 ] In do_isofs_readdir() when assigning the variable "struct iso_directory_record *de" the b_data field of the buffer_head is accessed and an offset is added to it, the size of b_data is 2048 and the offset size is 2047, meaning "de = (struct iso_directory_record *) (bh->b_data + offset);" yields the final byte of the 2048 sized b_data block. The first byte of the directory record (de_len) is then read and found to be 31, meaning the directory record size is 31 bytes long. The directory record is defined by the structure: struct iso_directory_record { __u8 length; // 1 byte __u8 ext_attr_length; // 1 byte __u8 extent[8]; // 8 bytes __u8 size[8]; // 8 bytes __u8 date[7]; // 7 bytes __u8 flags; // 1 byte __u8 file_unit_size; // 1 byte __u8 interleave; // 1 byte __u8 volume_sequence_number[4]; // 4 bytes __u8 name_len; // 1 byte char name[]; // variable size } __attribute__((packed)); The fixed portion of this structure occupies 33 bytes. Therefore, a valid directory record must be at least 33 bytes long (even without considering the variable-length name field). Since de_len is only 31, it is insufficient to contain the complete fixed header. The code later hits the following sanity check that compares de_len against the sum of de->name_len and sizeof(struct iso_directory_record): if (de_len < de->name_len[0] + sizeof(struct iso_directory_record)) { ... } Since the fixed portion of the structure is 33 bytes (up to and including name_len member), a valid record should have de_len of at least 33 bytes; here, however, de_len is too short, and the field de->name_len (located at offset 32) is accessed even though it lies beyond the available 31 bytes. This access on the corrupted isofs data triggers a KASAN uninitialized memory warning. The fix would be to first verify that de_len is at least sizeof(struct iso_directory_record) before accessing any fields like de->name_len. Reported-by: syzbot Tested-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=812641c6c3d7586a1613 Fixes: 2deb1acc653c ("isofs: fix access to unallocated memory when reading corrupted filesystem") Signed-off-by: Qasim Ijaz Signed-off-by: Jan Kara Link: https://patch.msgid.link/20250211195900.42406-1-qasdev00@gmail.com Signed-off-by: Sasha Levin commit f9b0819e8b10186e18537da34aba07f969e0d0a4 Author: Heiko Stuebner Date: Fri Dec 6 11:34:01 2024 +0100 phy: phy-rockchip-samsung-hdptx: Don't use dt aliases to determine phy-id [ Upstream commit f08d1c08563846f9be79a4859e912c8795d690fd ] The phy needs to know its identity in the system (phy0 or phy1 on rk3588) for some actions and the driver currently contains code abusing of_alias for that. Devicetree aliases are always optional and should not be used for core device functionality, so instead keep a list of phys on a soc in the of_device_data and find the phy-id by comparing against the mapped register-base. Fixes: c4b09c562086 ("phy: phy-rockchip-samsung-hdptx: Add clock provider support") Signed-off-by: Heiko Stuebner Reviewed-by: Cristian Ciocaltea Reviewed-by: Sebastian Reichel Link: https://lore.kernel.org/r/20241206103401.1780416-3-heiko@sntech.de Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 641394fbb5a5355f1ae3dc833c71960ea1797e03 Author: Konstantin Komarov Date: Thu Jan 30 17:03:41 2025 +0300 fs/ntfs3: Update inode->i_mapping->a_ops on compression state [ Upstream commit b432163ebd15a0fb74051949cb61456d6c55ccbd ] Update inode->i_mapping->a_ops when the compression state changes to ensure correct address space operations. Clear ATTR_FLAG_SPARSED/FILE_ATTRIBUTE_SPARSE_FILE when enabling compression to prevent flag conflicts. v2: Additionally, ensure that all dirty pages are flushed and concurrent access to the page cache is blocked. Fixes: 6b39bfaeec44 ("fs/ntfs3: Add support for the compression attribute") Reported-by: Kun Hu , Jiaji Qin Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 4f750b84628080ff0d67bf1af67a4967b740acf2 Author: Chenyuan Yang Date: Sat Jan 11 12:18:03 2025 -0600 w1: fix NULL pointer dereference in probe [ Upstream commit 0dd6770a72f138dabea9eae87f3da6ffa68f0d06 ] The w1_uart_probe() function calls w1_uart_serdev_open() (which includes devm_serdev_device_open()) before setting the client ops via serdev_device_set_client_ops(). This ordering can trigger a NULL pointer dereference in the serdev controller's receive_buf handler, as it assumes serdev->ops is valid when SERPORT_ACTIVE is set. This is similar to the issue fixed in commit 5e700b384ec1 ("platform/chrome: cros_ec_uart: properly fix race condition") where devm_serdev_device_open() was called before fully initializing the device. Fix the race by ensuring client ops are set before enabling the port via w1_uart_serdev_open(). Fixes: a3c08804364e ("w1: add UART w1 bus driver") Signed-off-by: Chenyuan Yang Acked-by: Christoph Winklhofer Link: https://lore.kernel.org/r/20250111181803.2283611-1-chenyuan0y@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 4baed8d7452ba598b8309b7f0814a8364a7ee2ab Author: James Clark Date: Wed Jan 29 15:44:05 2025 +0000 perf: Always feature test reallocarray [ Upstream commit 4c4c0724d6521a8092b7c16f8f210c5869d95b17 ] This is also used in util/comm.c now, so instead of selectively doing the feature test, always do it. If it's ever used anywhere else it's less likely to cause another build failure. This doesn't remove the need to manually include libc_compat.h, and missing that will still cause an error for glibc < 2.26. There isn't a way to fix that without poisoning reallocarray like libbpf did, but that has other downsides like making memory debugging tools less useful. So for Perf keep it like this and we'll have to fix up any missed includes. Fixes the following build error: util/comm.c:152:31: error: implicit declaration of function 'reallocarray' [-Wimplicit-function-declaration] 152 | tmp = reallocarray(comm_strs->strs, | ^~~~~~~~~~~~ Fixes: 13ca628716c6 ("perf comm: Add reference count checking to 'struct comm_str'") Reported-by: Ali Utku Selen Signed-off-by: James Clark Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250129154405.777533-1-james.clark@linaro.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit de9c7127473548a412908f5c67b653335b6d3a10 Author: Ian Rogers Date: Thu Jan 9 14:21:07 2025 -0800 perf stat: Fix find_stat for mixed legacy/non-legacy events [ Upstream commit 8ce0d2da14d3fb62844dd0e95982c194326b1a5f ] Legacy events typically don't have a PMU when added leading to mismatched legacy/non-legacy cases in find_stat. Use evsel__find_pmu to make sure the evsel PMU is looked up. Update the evsel__find_pmu code to look for the PMU using the extended config type or, for legacy hardware/hw_cache events on non-hybrid systems, just use the core PMU. Before: ``` $ perf stat -e cycles,cpu/instructions/ -a sleep 1 Performance counter stats for 'system wide': 215,309,764 cycles 44,326,491 cpu/instructions/ 1.002555314 seconds time elapsed ``` After: ``` $ perf stat -e cycles,cpu/instructions/ -a sleep 1 Performance counter stats for 'system wide': 990,676,332 cycles 1,235,762,487 cpu/instructions/ # 1.25 insn per cycle 1.002667198 seconds time elapsed ``` Fixes: 3612ca8e2935 ("perf stat: Fix the hard-coded metrics calculation on the hybrid") Signed-off-by: Ian Rogers Tested-by: James Clark Tested-by: Leo Yan Tested-by: Atish Patra Link: https://lore.kernel.org/r/20250109222109.567031-3-irogers@google.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 165b155dfedbbd2f345cb02b08c29f891d894099 Author: Barnabás Czémán Date: Sat Mar 15 16:26:17 2025 +0100 clk: qcom: mmcc-sdm660: fix stuck video_subcore0 clock [ Upstream commit 000cbe3896c56bf5c625e286ff096533a6b27657 ] This clock can't be enable with VENUS_CORE0 GDSC turned off. But that GDSC is under HW control so it can be turned off at any moment. Instead of checking the dependent clock we can just vote for it to enable later when GDSC gets turned on. Fixes: 5db3ae8b33de6 ("clk: qcom: Add SDM660 Multimedia Clock Controller (MMCC) driver") Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20250315-clock-fix-v1-1-2efdc4920dda@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit bf233124d3986f30a68617e4014ecfa3a821e585 Author: Andy Shevchenko Date: Mon Feb 10 21:44:51 2025 +0200 pinctrl: intel: Fix wrong bypass assignment in intel_pinctrl_probe_pwm() [ Upstream commit 0eee258cdf172763502f142d85e967f27a573be0 ] When instantiating PWM, the bypass should be set to false. The field is used for the selected Intel SoCs that do not have PWM feature enabled in their pin control IPs. Fixes: eb78d3604d6b ("pinctrl: intel: Enumerate PWM device when community has a capability") Reported-by: Alexis GUILLEMET Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Tested-by: Alexis GUILLEMET Signed-off-by: Sasha Levin commit 5416777d568aad260866fa8ea71307cf3baca505 Author: Wenkai Lin Date: Wed Feb 5 11:56:26 2025 +0800 crypto: hisilicon/sec2 - fix for aead auth key length [ Upstream commit 1b284ffc30b02808a0de698667cbcf5ce5f9144e ] According to the HMAC RFC, the authentication key can be 0 bytes, and the hardware can handle this scenario. Therefore, remove the incorrect validation for this case. Fixes: 2f072d75d1ab ("crypto: hisilicon - Add aead support on SEC2") Signed-off-by: Wenkai Lin Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 0d6460b9d2a3ee380940bdf47680751ef91cb88e Author: Wang Liang Date: Thu Mar 13 17:24:21 2025 +0800 RDMA/core: Fix use-after-free when rename device name [ Upstream commit 1d6a9e7449e2a0c1e2934eee7880ba8bd1e464cd ] Syzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in nla_put+0xd3/0x150 lib/nlattr.c:1099 Read of size 5 at addr ffff888140ea1c60 by task syz.0.988/10025 CPU: 0 UID: 0 PID: 10025 Comm: syz.0.988 Not tainted 6.14.0-rc4-syzkaller-00859-gf77f12010f67 #0 Hardware name: 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 print_address_description mm/kasan/report.c:408 [inline] print_report+0x16e/0x5b0 mm/kasan/report.c:521 kasan_report+0x143/0x180 mm/kasan/report.c:634 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 nla_put+0xd3/0x150 lib/nlattr.c:1099 nla_put_string include/net/netlink.h:1621 [inline] fill_nldev_handle+0x16e/0x200 drivers/infiniband/core/nldev.c:265 rdma_nl_notify_event+0x561/0xef0 drivers/infiniband/core/nldev.c:2857 ib_device_notify_register+0x22/0x230 drivers/infiniband/core/device.c:1344 ib_register_device+0x1292/0x1460 drivers/infiniband/core/device.c:1460 rxe_register_device+0x233/0x350 drivers/infiniband/sw/rxe/rxe_verbs.c:1540 rxe_net_add+0x74/0xf0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0xde/0x1a0 drivers/infiniband/sw/rxe/rxe.c:212 nldev_newlink+0x5ea/0x680 drivers/infiniband/core/nldev.c:1795 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x6dd/0x9e0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:709 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:724 ____sys_sendmsg+0x53a/0x860 net/socket.c:2564 ___sys_sendmsg net/socket.c:2618 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2650 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 RIP: 0033:0x7f42d1b8d169 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 ... RSP: 002b:00007f42d2960038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f42d1da6320 RCX: 00007f42d1b8d169 RDX: 0000000000000000 RSI: 00004000000002c0 RDI: 000000000000000c RBP: 00007f42d1c0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f42d1da6320 R15: 00007ffe399344a8 Allocated by task 10025: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_node_track_caller_noprof+0x28b/0x4c0 mm/slub.c:4313 __kmemdup_nul mm/util.c:61 [inline] kstrdup+0x42/0x100 mm/util.c:81 kobject_set_name_vargs+0x61/0x120 lib/kobject.c:274 dev_set_name+0xd5/0x120 drivers/base/core.c:3468 assign_name drivers/infiniband/core/device.c:1202 [inline] ib_register_device+0x178/0x1460 drivers/infiniband/core/device.c:1384 rxe_register_device+0x233/0x350 drivers/infiniband/sw/rxe/rxe_verbs.c:1540 rxe_net_add+0x74/0xf0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0xde/0x1a0 drivers/infiniband/sw/rxe/rxe.c:212 nldev_newlink+0x5ea/0x680 drivers/infiniband/core/nldev.c:1795 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x6dd/0x9e0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:709 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:724 ____sys_sendmsg+0x53a/0x860 net/socket.c:2564 ___sys_sendmsg net/socket.c:2618 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2650 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 Freed by task 10035: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/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+0x196/0x430 mm/slub.c:4757 kobject_rename+0x38f/0x410 lib/kobject.c:524 device_rename+0x16a/0x200 drivers/base/core.c:4525 ib_device_rename+0x270/0x710 drivers/infiniband/core/device.c:402 nldev_set_doit+0x30e/0x4c0 drivers/infiniband/core/nldev.c:1146 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x6dd/0x9e0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:709 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:724 ____sys_sendmsg+0x53a/0x860 net/socket.c:2564 ___sys_sendmsg net/socket.c:2618 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2650 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 This is because if rename device happens, the old name is freed in ib_device_rename() with lock, but ib_device_notify_register() may visit the dev name locklessly by event RDMA_REGISTER_EVENT or RDMA_NETDEV_ATTACH_EVENT. Fix this by hold devices_rwsem in ib_device_notify_register(). Reported-by: syzbot+f60349ba1f9f08df349f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=25bc6f0ed2b88b9eb9b8 Fixes: 9cbed5aab5ae ("RDMA/nldev: Add support for RDMA monitoring") Signed-off-by: Wang Liang Link: https://patch.msgid.link/20250313092421.944658-1-wangliang74@huawei.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 782526a40149a5aefdaf8cf8380337ad1b32970b Author: Jann Horn Date: Tue Mar 25 03:01:23 2025 +0100 x86/dumpstack: Fix inaccurate unwinding from exception stacks due to misplaced assignment [ Upstream commit 2c118f50d7fd4d9aefc4533a26f83338b2906b7a ] Commit: 2e4be0d011f2 ("x86/show_trace_log_lvl: Ensure stack pointer is aligned, again") was intended to ensure alignment of the stack pointer; but it also moved the initialization of the "stack" variable down into the loop header. This was likely intended as a no-op cleanup, since the commit message does not mention it; however, this caused a behavioral change because the value of "regs" is different between the two places. Originally, get_stack_pointer() used the regs provided by the caller; after that commit, get_stack_pointer() instead uses the regs at the top of the stack frame the unwinder is looking at. Often, there are no such regs at all, and "regs" is NULL, causing get_stack_pointer() to fall back to the task's current stack pointer, which is not what we want here, but probably happens to mostly work. Other times, the original regs will point to another regs frame - in that case, the linear guess unwind logic in show_trace_log_lvl() will start unwinding too far up the stack, causing the first frame found by the proper unwinder to never be visited, resulting in a stack trace consisting purely of guess lines. Fix it by moving the "stack = " assignment back where it belongs. Fixes: 2e4be0d011f2 ("x86/show_trace_log_lvl: Ensure stack pointer is aligned, again") Signed-off-by: Jann Horn Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250325-2025-03-unwind-fixes-v1-2-acd774364768@google.com Signed-off-by: Sasha Levin commit c2ddf2f5760b54533dc9080f0546e4c42a29c756 Author: Remi Pommarel Date: Thu Feb 20 12:23:17 2025 +0100 leds: Fix LED_OFF brightness race [ Upstream commit 2c70953b6f535f7698ccbf22c1f5ba26cb6c2816 ] While commit fa15d8c69238 ("leds: Fix set_brightness_delayed() race") successfully forces led_set_brightness() to be called with LED_OFF at least once when switching from blinking to LED on state so that hw-blinking can be disabled, another race remains. Indeed in led_set_brightness(LED_OFF) followed by led_set_brightness(any) scenario the following CPU scheduling can happen: CPU0 CPU1 ---- ---- set_brightness_delayed() { test_and_clear_bit(BRIGHTNESS_OFF) led_set_brightness(LED_OFF) { set_bit(BRIGHTNESS_OFF) queue_work() } led_set_brightness(any) { set_bit(BRIGHTNESS) queue_work() //already queued } test_and_clear_bit(BRIGHTNESS) /* LED set with brightness any */ } /* From previous CPU1 queue_work() */ set_brightness_delayed() { test_and_clear_bit(BRIGHTNESS_OFF) /* LED turned off */ test_and_clear_bit(BRIGHTNESS) /* Clear from previous run, LED remains off */ In that case the led_set_brightness(LED_OFF)/led_set_brightness(any) sequence will be effectively executed in reverse order and LED will remain off. With the introduction of commit 32360bf6a5d4 ("leds: Introduce ordered workqueue for LEDs events instead of system_wq") the race is easier to trigger as sysfs brightness configuration does not wait for set_brightness_delayed() work to finish (flush_work() removal). Use delayed_set_value to optionnally re-configure brightness after a LED_OFF. That way a LED state could be configured more that once but final state will always be as expected. Ensure that delayed_set_value modification is seen before set_bit() using smp_mb__before_atomic(). Fixes: fa15d8c69238 ("leds: Fix set_brightness_delayed() race") Signed-off-by: Remi Pommarel Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/19c81177059dab7b656c42063958011a8e4d1a66.1740050412.git.repk@triplefau.lt Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit a1fab9e649483aaee6e9cc63a1a8697248feedc3 Author: Nikita Zhandarovich Date: Wed Jan 15 09:12:06 2025 -0800 mfd: sm501: Switch to BIT() to mitigate integer overflows [ Upstream commit 2d8cb9ffe18c2f1e5bd07a19cbce85b26c1d0cf0 ] If offset end up being high enough, right hand expression in functions like sm501_gpio_set() shifted left for that number of bits, may not fit in int type. Just in case, fix that by using BIT() both as an option safe from overflow issues and to make this step look similar to other gpio drivers. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: f61be273d369 ("sm501: add gpiolib support") Signed-off-by: Nikita Zhandarovich Link: https://lore.kernel.org/r/20250115171206.20308-1-n.zhandarovich@fintech.ru Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 7ee71ef057b101294b5725d5d87a7d20bf7ee29b Author: Fabrizio Castro Date: Wed Mar 5 16:37:52 2025 +0000 pinctrl: renesas: rzv2m: Fix missing of_node_put() call [ Upstream commit 5a550b00704d3a2cd9d766a9427b0f8166da37df ] of_parse_phandle_with_fixed_args() requires its caller to call into of_node_put() on the node pointer from the output structure, but such a call is currently missing. Call into of_node_put() to rectify that. Fixes: 92a9b8252576 ("pinctrl: renesas: Add RZ/V2M pin and gpio controller driver") Signed-off-by: Fabrizio Castro Reviewed-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250305163753.34913-4-fabrizio.castro.jz@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit cad677085274ecf9c7565b5bfc5d2e49acbf174c Author: Patrisious Haddad Date: Thu Mar 13 16:29:53 2025 +0200 RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow [ Upstream commit 5ed3b0cb3f827072e93b4c5b6e2b8106fd7cccbd ] When cur_qp isn't NULL, in order to avoid fetching the QP from the radix tree again we check if the next cqe QP is identical to the one we already have. The bug however is that we are checking if the QP is identical by checking the QP number inside the CQE against the QP number inside the mlx5_ib_qp, but that's wrong since the QP number from the CQE is from FW so it should be matched against mlx5_core_qp which is our FW QP number. Otherwise we could use the wrong QP when handling a CQE which could cause the kernel trace below. This issue is mainly noticeable over QPs 0 & 1, since for now they are the only QPs in our driver whereas the QP number inside mlx5_ib_qp doesn't match the QP number inside mlx5_core_qp. BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20 Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Patrisious Haddad Reviewed-by: Edward Srouji Link: https://patch.msgid.link/4ada09d41f1e36db62c44a9b25c209ea5f054316.1741875692.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 19e6817f84000d0b06f09fd69ebd56217842c122 Author: Jiayuan Chen Date: Fri Feb 14 17:18:21 2025 +0800 bpf: Fix array bounds error with may_goto [ Upstream commit 6ebc5030e0c5a698f1dd9a6684cddf6ccaed64a0 ] may_goto uses an additional 8 bytes on the stack, which causes the interpreters[] array to go out of bounds when calculating index by stack_size. 1. If a BPF program is rewritten, re-evaluate the stack size. For non-JIT cases, reject loading directly. 2. For non-JIT cases, calculating interpreters[idx] may still cause out-of-bounds array access, and just warn about it. 3. For jit_requested cases, the execution of bpf_func also needs to be warned. So move the definition of function __bpf_prog_ret0_warn out of the macro definition CONFIG_BPF_JIT_ALWAYS_ON. Reported-by: syzbot+d2a2c639d03ac200a4f1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/bpf/0000000000000f823606139faa5d@google.com/ Fixes: 011832b97b311 ("bpf: Introduce may_goto instruction") Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20250214091823.46042-2-mrpre@163.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit cff6b3c8085d65af4d079c4c43829a07c0a97595 Author: Neil Armstrong Date: Wed Mar 5 20:00:29 2025 +0100 clk: qcom: gcc-sm8650: Do not turn off USB GDSCs during gdsc_disable() [ Upstream commit 8b75c2973997e66fd897b7e87b5ba2f3d683e94b ] With PWRSTS_OFF_ON, USB GDSCs are turned off during gdsc_disable(). This can happen during scenarios such as system suspend and breaks the resume of USB controller from suspend. So use PWRSTS_RET_ON to indicate the GDSC driver to not turn off the GDSCs during gdsc_disable() and allow the hardware to transition the GDSCs to retention when the parent domain enters low power state during system suspend. Fixes: c58225b7e3d7 ("clk: qcom: add the SM8650 Global Clock Controller driver, part 1") Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250305-topic-sm8650-upstream-fix-usb-suspend-v1-1-649036ab0557@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4fdbccc738afd130010679c7aa2ceb5cf06b8afb Author: Herbert Xu Date: Sat Mar 15 16:50:42 2025 +0800 crypto: nx - Fix uninitialised hv_nxc on error [ Upstream commit 9b00eb923f3e60ca76cbc8b31123716f3a87ac6a ] The compiler correctly warns that hv_nxc may be used uninitialised as that will occur when NX-GZIP is unavailable. Fix it by rearranging the code and delay setting caps_feat until the final query succeeds. Fixes: b4ba22114c78 ("crypto/nx: Get NX capabilities for GZIP coprocessor type") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ac9e52aca2cb745fd3d10c827987fb4a46455bc5 Author: Artur Weber Date: Sun Mar 16 21:11:49 2025 +0100 power: supply: max77693: Fix wrong conversion of charge input threshold value [ Upstream commit 30cc7b0d0e9341d419eb7da15fb5c22406dbe499 ] The charge input threshold voltage register on the MAX77693 PMIC accepts four values: 0x0 for 4.3v, 0x1 for 4.7v, 0x2 for 4.8v and 0x3 for 4.9v. Due to an oversight, the driver calculated the values for 4.7v and above starting from 0x0, rather than from 0x1 ([(4700000 - 4700000) / 100000] gives 0). Add 1 to the calculation to ensure that 4.7v is converted to a register value of 0x1 and that the other two voltages are converted correctly as well. Fixes: 87c2d9067893 ("power: max77693: Add charger driver for Maxim 77693") Signed-off-by: Artur Weber Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250316-max77693-charger-input-threshold-fix-v1-1-2b037d0ac722@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit b6542ef0d4dde851f75d3c909a34b12d302b99f3 Author: Jann Horn Date: Tue Mar 25 03:01:22 2025 +0100 x86/entry: Fix ORC unwinder for PUSH_REGS with save_ret=1 [ Upstream commit 57e2428f8df8263275344566e02c277648a4b7f1 ] PUSH_REGS with save_ret=1 is used by interrupt entry helper functions that initially start with a UNWIND_HINT_FUNC ORC state. However, save_ret=1 means that we clobber the helper function's return address (and then later restore the return address further down on the stack); after that point, the only thing on the stack we can unwind through is the IRET frame, so use UNWIND_HINT_IRET_REGS until we have a full pt_regs frame. ( An alternate approach would be to move the pt_regs->di overwrite down such that it is the final step of pt_regs setup; but I don't want to rearrange entry code just to make unwinding a tiny bit more elegant. ) Fixes: 9e809d15d6b6 ("x86/entry: Reduce the code footprint of the 'idtentry' macro") Signed-off-by: Jann Horn Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: Brian Gerst Cc: Juergen Gross Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Kees Cook Cc: Peter Zijlstra Cc: Josh Poimboeuf Link: https://lore.kernel.org/r/20250325-2025-03-unwind-fixes-v1-1-acd774364768@google.com Signed-off-by: Sasha Levin commit cd0e4789f87063505a1765634732112f547485c4 Author: Jerome Brunet Date: Fri Dec 13 11:03:23 2024 +0100 clk: amlogic: g12a: fix mmc A peripheral clock [ Upstream commit 0079e77c08de692cb20b38e408365c830a44b1ef ] The bit index of the peripheral clock for mmc A is wrong This was probably not a problem for mmc A as the peripheral is likely left enabled by the bootloader. No issues has been reported so far but it could be a problem, most likely some form of conflict between the ethernet and mmc A clock, breaking ethernet on init. Use the value provided by the documentation for mmc A before this becomes an actual problem. Fixes: 085a4ea93d54 ("clk: meson: g12a: add peripheral clock controller") Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20241213-amlogic-clk-g12a-mmca-fix-v1-1-5af421f58b64@baylibre.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit f29760cdca4bf6febf87c67e519a62faccccb983 Author: Laurentiu Mihalcea Date: Wed Feb 26 11:45:11 2025 -0500 clk: clk-imx8mp-audiomix: fix dsp/ocram_a clock parents [ Upstream commit 91be7d27099dedf813b80702e4ca117d1fb38ce6 ] The DSP and OCRAM_A modules from AUDIOMIX are clocked by AUDIO_AXI_CLK_ROOT, not AUDIO_AHB_CLK_ROOT. Update the clock data accordingly. Fixes: 6cd95f7b151c ("clk: imx: imx8mp: Add audiomix block control") Signed-off-by: Laurentiu Mihalcea Reviewed-by: Iuliana Prodan Reviewed-by: Peng Fan Link: https://lore.kernel.org/r/20250226164513.33822-3-laurentiumihalcea111@gmail.com Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 64bb7efb0c4c4e3e4bb6c8d6a24c0e662d0c1c86 Author: Bairavi Alagappan Date: Fri Mar 14 15:09:31 2025 +0000 crypto: qat - remove access to parity register for QAT GEN4 [ Upstream commit 92c6a707d82f0629debf1c21dd87717776d96af2 ] The firmware already handles parity errors reported by the accelerators by clearing them through the corresponding SSMSOFTERRORPARITY register. To ensure consistent behavior and prevent race conditions between the driver and firmware, remove the logic that checks the SSMSOFTERRORPARITY registers. Additionally, change the return type of the function adf_handle_rf_parr_err() to void, as it consistently returns false. Parity errors are recoverable and do not necessitate a device reset. Fixes: 895f7d532c84 ("crypto: qat - add handling of errors from ERRSOU2 for QAT GEN4") Signed-off-by: Bairavi Alagappan Reviewed-by: Andy Shevchenko Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4409e87cdc8b068c29a71db9fee43f024c8ee3bd Author: Andy Shevchenko Date: Tue Mar 18 12:57:14 2025 +0200 pinctrl: npcm8xx: Fix incorrect struct npcm8xx_pincfg assignment [ Upstream commit 113ec87b0f26a17b02c58aa2714a9b8f1020eed9 ] Sparse is not happy about implementation of the NPCM8XX_PINCFG() pinctrl-npcm8xx.c:1314:9: warning: obsolete array initializer, use C99 syntax pinctrl-npcm8xx.c:1315:9: warning: obsolete array initializer, use C99 syntax ... pinctrl-npcm8xx.c:1412:9: warning: obsolete array initializer, use C99 syntax pinctrl-npcm8xx.c:1413:9: warning: too many warnings which uses index-based assignment in a wrong way, i.e. it missed the equal sign and hence the index is simply ignored, while the entries are indexed naturally. This is not a problem as the pin numbering repeats the natural order, but it might be in case of shuffling the entries. Fix this by adding missed equal sign and reformat a bit for better readability. Fixes: acf4884a5717 ("pinctrl: nuvoton: add NPCM8XX pinctrl and GPIO driver") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/20250318105932.2090926-2-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 8ba426f170f1c7f28875d93a8374d7049d13946a Author: Alice Ryhl Date: Mon Mar 3 08:45:12 2025 +0000 rust: fix signature of rust_fmt_argument [ Upstream commit 901b3290bd4dc35e613d13abd03c129e754dd3dd ] Without this change, the rest of this series will emit the following error message: error[E0308]: `if` and `else` have incompatible types --> /rust/kernel/print.rs:22:22 | 21 | #[export] | --------- expected because of this 22 | unsafe extern "C" fn rust_fmt_argument( | ^^^^^^^^^^^^^^^^^ expected `u8`, found `i8` | = note: expected fn item `unsafe extern "C" fn(*mut u8, *mut u8, *mut c_void) -> *mut u8 {bindings::rust_fmt_argument}` found fn item `unsafe extern "C" fn(*mut i8, *mut i8, *const c_void) -> *mut i8 {print::rust_fmt_argument}` The error may be different depending on the architecture. To fix this, change the void pointer argument to use a const pointer, and change the imports to use crate::ffi instead of core::ffi for integer types. Fixes: 787983da7718 ("vsprintf: add new `%pA` format specifier") Reviewed-by: Tamir Duberstein Acked-by: Greg Kroah-Hartman Signed-off-by: Alice Ryhl Acked-by: Petr Mladek Link: https://lore.kernel.org/r/20250303-export-macro-v3-1-41fbad85a27f@google.com Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit c9fad5ce1ef90b0f5abf406da3cbc87eb93a73bf Author: Saket Kumar Bhaskar Date: Fri Jan 31 12:35:22 2025 +0530 selftests/bpf: Select NUMA_NO_NODE to create map [ Upstream commit 4107a1aeb20ed4cdad6a0d49de92ea0f933c71b7 ] On powerpc, a CPU does not necessarily originate from NUMA node 0. This contrasts with architectures like x86, where CPU 0 is not hot-pluggable, making NUMA node 0 a consistently valid node. This discrepancy can lead to failures when creating a map on NUMA node 0, which is initialized by default, if no CPUs are allocated from NUMA node 0. This patch fixes the issue by setting NUMA_NO_NODE (-1) for map creation for this selftest. Fixes: 96eabe7a40aa ("bpf: Allow selecting numa node during map creation") Signed-off-by: Saket Kumar Bhaskar Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/cf1f61468b47425ecf3728689bc9636ddd1d910e.1738302337.git.skb99@linux.ibm.com Signed-off-by: Sasha Levin commit 4d32504f7ae951600e216aac4e04c81b02421a9d Author: Jerome Brunet Date: Fri Dec 20 11:25:37 2024 +0100 clk: amlogic: gxbb: drop non existing 32k clock parent [ Upstream commit 7915d7d5407c026fa9343befb4d3343f7a345f97 ] The 32k clock reference a parent 'cts_slow_oscin' with a fixme note saying that this clock should be provided by AO controller. The HW probably has this clock but it does not exist at the moment in any controller implementation. Furthermore, referencing clock by the global name should be avoided whenever possible. There is no reason to keep this hack around, at least for now. Fixes: 14c735c8e308 ("clk: meson-gxbb: Add EE 32K Clock for CEC") Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20241220-amlogic-clk-gxbb-32k-fixes-v1-2-baca56ecf2db@baylibre.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit dc8477444ac654e53912e371a366cc40a0dd72a0 Author: Jerome Brunet Date: Fri Dec 13 15:30:17 2024 +0100 clk: amlogic: g12b: fix cluster A parent data [ Upstream commit 8995f8f108c3ac5ad52b12a6cfbbc7b3b32e9a58 ] Several clocks used by both g12a and g12b use the g12a cpu A clock hw pointer as clock parent. This is incorrect on g12b since the parents of cluster A cpu clock are different. Also the hw clock provided as parent to these children is not even registered clock on g12b. Fix the problem by reverting to the global namespace and let CCF pick the appropriate, as it is already done for other clocks, such as cpu_clk_trace_div. Fixes: 25e682a02d91 ("clk: meson: g12a: migrate to the new parent description method") Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20241213-amlogic-clk-g12a-cpua-parent-fix-v1-1-d8c0f41865fe@baylibre.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit 52f3ef292b7b14c6925bfe870094da78d2ac1fe2 Author: Prathamesh Shete Date: Thu Mar 6 10:35:42 2025 +0530 pinctrl: tegra: Set SFIO mode to Mux Register [ Upstream commit 17013f0acb322e5052ff9b9d0fab0ab5a4bfd828 ] Tegra devices have an 'sfsel' bit field that determines whether a pin operates in SFIO (Special Function I/O) or GPIO mode. Currently, tegra_pinctrl_gpio_disable_free() sets this bit when releasing a GPIO. However, tegra_pinctrl_set_mux() can be called independently in certain code paths where gpio_disable_free() is not invoked. In such cases, failing to set the SFIO mode could lead to incorrect pin configurations, resulting in functional issues for peripherals relying on SFIO. This patch ensures that whenever set_mux() is called, the SFIO mode is correctly set in the Mux Register if the 'sfsel' bit is present. This prevents situations where the pin remains in GPIO mode despite being configured for SFIO use. Fixes: 971dac7123c7 ("pinctrl: add a driver for NVIDIA Tegra") Signed-off-by: Prathamesh Shete Link: https://lore.kernel.org/20250306050542.16335-1-pshete@nvidia.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2aec4d9a79a74b0e759c9ed689859847732350c0 Author: Maher Sanalla Date: Thu Mar 13 16:20:17 2025 +0200 IB/mad: Check available slots before posting receive WRs [ Upstream commit 37826f0a8c2f6b6add5179003b8597e32a445362 ] The ib_post_receive_mads() function handles posting receive work requests (WRs) to MAD QPs and is called in two cases: 1) When a MAD port is opened. 2) When a receive WQE is consumed upon receiving a new MAD. Whereas, if MADs arrive during the port open phase, a race condition might cause an extra WR to be posted, exceeding the QP’s capacity. This leads to failures such as: infiniband mlx5_0: ib_post_recv failed: -12 infiniband mlx5_0: Couldn't post receive WRs infiniband mlx5_0: Couldn't start port infiniband mlx5_0: Couldn't open port 1 Fix this by checking the current receive count before posting a new WR. If the QP’s receive queue is full, do not post additional WRs. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Maher Sanalla Link: https://patch.msgid.link/c4984ba3c3a98a5711a558bccefcad789587ecf1.1741875592.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6d4e56e4c5817bb50d003b3079526768deab6999 Author: Herbert Xu Date: Fri Feb 14 10:31:25 2025 +0800 crypto: api - Fix larval relookup type and mask [ Upstream commit 7505436e2925d89a13706a295a6734d6cabb4b43 ] When the lookup is retried after instance construction, it uses the type and mask from the larval, which may not match the values used by the caller. For example, if the caller is requesting for a !NEEDS_FALLBACK algorithm, it may end up getting an algorithm that needs fallbacks. Fix this by making the caller supply the type/mask and using that for the lookup. Reported-by: Coiby Xu Fixes: 96ad59552059 ("crypto: api - Remove instance larval fulfilment") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit eae034cdcee923875b005c412eedacef5e22be96 Author: Sicelo A. Mhlongo Date: Mon Nov 25 17:29:30 2024 +0200 power: supply: bq27xxx_battery: do not update cached flags prematurely [ Upstream commit 45291874a762dbb12a619dc2efaf84598859007a ] Commit 243f8ffc883a1 ("power: supply: bq27xxx_battery: Notify also about status changes") intended to notify userspace when the status changes, based on the flags register. However, the cached state is updated too early, before the flags are tested for any changes. Remove the premature update. Fixes: 243f8ffc883a1 ("power: supply: bq27xxx_battery: Notify also about status changes") Signed-off-by: Sicelo A. Mhlongo Link: https://lore.kernel.org/r/20241125152945.47937-1-absicsz@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 005d8de09c71d98317da759b341395514e9e4068 Author: Luca Weiss Date: Mon Feb 17 23:05:18 2025 +0100 remoteproc: qcom_q6v5_mss: Handle platforms with one power domain [ Upstream commit 4641840341f37dc8231e0840ec1514b4061b4322 ] For example MSM8974 has mx voltage rail exposed as regulator and only cx voltage rail is exposed as power domain. This power domain (cx) is attached internally in power domain and cannot be attached in this driver. Fixes: 8750cf392394 ("remoteproc: qcom_q6v5_mss: Allow replacing regulators with power domains") Co-developed-by: Matti Lehtimäki Signed-off-by: Matti Lehtimäki Reviewed-by: Stephan Gerhold Signed-off-by: Luca Weiss Link: https://lore.kernel.org/r/20250217-msm8226-modem-v5-4-2bc74b80e0ae@lucaweiss.eu Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a114d25d584c14019d31dbf2163780c47415a187 Author: Cheng Xu Date: Thu Mar 6 20:04:40 2025 +0800 RDMA/erdma: Prevent use-after-free in erdma_accept_newconn() [ Upstream commit 83437689249e6a17b25e27712fbee292e42e7855 ] After the erdma_cep_put(new_cep) being called, new_cep will be freed, and the following dereference will cause a UAF problem. Fix this issue. Fixes: 920d93eac8b9 ("RDMA/erdma: Add connection management (CM) support") Signed-off-by: Markus Elfring Signed-off-by: Cheng Xu Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 257f0bdd5a4be80f192e6febdb9072d4e9859977 Author: Chiara Meiohas Date: Thu Mar 13 16:29:54 2025 +0200 RDMA/mlx5: Fix calculation of total invalidated pages [ Upstream commit 79195147644653ebffadece31a42181e4c48c07d ] When invalidating an address range in mlx5, there is an optimization to do UMR operations in chunks. Previously, the invalidation counter was incorrectly updated for the same indexes within a chunk. Now, the invalidation counter is updated only when a chunk is complete and mlx5r_umr_update_xlt() is called. This ensures that the counter accurately represents the number of pages invalidated using UMR. Fixes: a3de94e3d61e ("IB/mlx5: Introduce ODP diagnostic counters") Signed-off-by: Chiara Meiohas Reviewed-by: Michael Guralnik Link: https://patch.msgid.link/560deb2433318e5947282b070c915f3c81fef77f.1741875692.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit df45ae2a4f1cdfda00c032839e12092e1f32c05e Author: Roman Gushchin Date: Thu Feb 27 16:54:20 2025 +0000 RDMA/core: Don't expose hw_counters outside of init net namespace [ Upstream commit a1ecb30f90856b0be4168ad51b8875148e285c1f ] Commit 467f432a521a ("RDMA/core: Split port and device counter sysfs attributes") accidentally almost exposed hw counters to non-init net namespaces. It didn't expose them fully, as an attempt to read any of those counters leads to a crash like this one: [42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028 [42021.814463] #PF: supervisor read access in kernel mode [42021.819549] #PF: error_code(0x0000) - not-present page [42021.824636] PGD 0 P4D 0 [42021.827145] Oops: 0000 [#1] SMP PTI [42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX [42021.841697] Hardware name: XXX [42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core] [42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48 [42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287 [42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000 [42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0 [42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000 [42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530 [42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000 [42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000 [42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0 [42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42021.949324] Call Trace: [42021.951756] [42021.953842] [] ? show_regs+0x64/0x70 [42021.959030] [] ? __die+0x78/0xc0 [42021.963874] [] ? page_fault_oops+0x2b5/0x3b0 [42021.969749] [] ? exc_page_fault+0x1a2/0x3c0 [42021.975549] [] ? asm_exc_page_fault+0x26/0x30 [42021.981517] [] ? __pfx_show_hw_stats+0x10/0x10 [ib_core] [42021.988482] [] ? hw_stat_device_show+0x1e/0x40 [ib_core] [42021.995438] [] dev_attr_show+0x1e/0x50 [42022.000803] [] sysfs_kf_seq_show+0x81/0xe0 [42022.006508] [] seq_read_iter+0xf4/0x410 [42022.011954] [] vfs_read+0x16e/0x2f0 [42022.017058] [] ksys_read+0x6e/0xe0 [42022.022073] [] do_syscall_64+0x6a/0xa0 [42022.027441] [] entry_SYSCALL_64_after_hwframe+0x78/0xe2 The problem can be reproduced using the following steps: ip netns add foo ip netns exec foo bash cat /sys/class/infiniband/mlx4_0/hw_counters/* The panic occurs because of casting the device pointer into an ib_device pointer using container_of() in hw_stat_device_show() is wrong and leads to a memory corruption. However the real problem is that hw counters should never been exposed outside of the non-init net namespace. Fix this by saving the index of the corresponding attribute group (it might be 1 or 2 depending on the presence of driver-specific attributes) and zeroing the pointer to hw_counters group for compat devices during the initialization. With this fix applied hw_counters are not available in a non-init net namespace: find /sys/class/infiniband/mlx4_0/ -name hw_counters /sys/class/infiniband/mlx4_0/ports/1/hw_counters /sys/class/infiniband/mlx4_0/ports/2/hw_counters /sys/class/infiniband/mlx4_0/hw_counters ip netns add foo ip netns exec foo bash find /sys/class/infiniband/mlx4_0/ -name hw_counters Fixes: 467f432a521a ("RDMA/core: Split port and device counter sysfs attributes") Signed-off-by: Roman Gushchin Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Maher Sanalla Cc: linux-rdma@vger.kernel.org Cc: linux-kernel@vger.kernel.org Link: https://patch.msgid.link/20250227165420.3430301-1-roman.gushchin@linux.dev Reviewed-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit c9c2582c4cd15142e901b762304ab4b046e97dfb Author: Peter Geis Date: Wed Jan 15 01:26:22 2025 +0000 clk: rockchip: rk3328: fix wrong clk_ref_usb3otg parent [ Upstream commit a9e60f1ffe1ca57d6af6a2573e2f950e76efbf5b ] Correct the clk_ref_usb3otg parent to fix clock control for the usb3 controller on rk3328. Verified against the rk3328 trm, the rk3228h trm, and the rk3328 usb3 phy clock map. Fixes: fe3511ad8a1c ("clk: rockchip: add clock controller for rk3328") Signed-off-by: Peter Geis Reviewed-by: Dragan Simic Link: https://lore.kernel.org/r/20250115012628.1035928-2-pgwipeout@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit dcb5997ead6d999a76dac6e5f597e01d2f4aa7f3 Author: Tengda Wu Date: Wed Jan 22 10:28:38 2025 +0800 selftests/bpf: Fix freplace_link segfault in tailcalls prog test [ Upstream commit a63a631c9b5cb25a1c17dd2cb18c63df91e978b1 ] There are two bpf_link__destroy(freplace_link) calls in test_tailcall_bpf2bpf_freplace(). After the first bpf_link__destroy() is called, if the following bpf_map_{update,delete}_elem() throws an exception, it will jump to the "out" label and call bpf_link__destroy() again, causing double free and eventually leading to a segfault. Fix it by directly resetting freplace_link to NULL after the first bpf_link__destroy() call. Fixes: 021611d33e78 ("selftests/bpf: Add test to verify tailcall and freplace restrictions") Signed-off-by: Tengda Wu Signed-off-by: Andrii Nakryiko Reviewed-by: Leon Hwang Link: https://lore.kernel.org/bpf/20250122022838.1079157-1-wutengda@huaweicloud.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 25aa4fe297a54ae429ad8cba53e6087e4e31b40d Author: Michael Guralnik Date: Thu Mar 13 16:29:48 2025 +0200 RDMA/mlx5: Fix MR cache initialization error flow [ Upstream commit a0130ef84b00c68ba0b79ee974a0f01459741421 ] Destroy all previously created cache entries and work queue when rolling back the MR cache initialization upon an error. Fixes: 73d09b2fe833 ("RDMA/mlx5: Introduce mlx5r_cache_rb_key") Signed-off-by: Michael Guralnik Reviewed-by: Yishai Hadas Link: https://patch.msgid.link/c41d525fb3c72e28dd38511bf3aaccb5d584063e.1741875692.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit fb4206c76b99c485452f2b4c3196666c12022754 Author: Fabrizio Castro Date: Wed Mar 5 16:37:51 2025 +0000 pinctrl: renesas: rzg2l: Fix missing of_node_put() call [ Upstream commit a5779e625e2b377f16a6675c432aaf299ce5028c ] of_parse_phandle_with_fixed_args() requires its caller to call into of_node_put() on the node pointer from the output structure, but such a call is currently missing. Call into of_node_put() to rectify that. Fixes: c4c4637eb57f ("pinctrl: renesas: Add RZ/G2L pin and gpio controller driver") Signed-off-by: Fabrizio Castro Reviewed-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250305163753.34913-3-fabrizio.castro.jz@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 3980e3741a8c7e4ba4cc58f953f235e30fdd5ee7 Author: Fabrizio Castro Date: Wed Mar 5 16:37:53 2025 +0000 pinctrl: renesas: rza2: Fix missing of_node_put() call [ Upstream commit abcdeb4e299a11ecb5a3ea0cce00e68e8f540375 ] of_parse_phandle_with_fixed_args() requires its caller to call into of_node_put() on the node pointer from the output structure, but such a call is currently missing. Call into of_node_put() to rectify that. Fixes: b59d0e782706 ("pinctrl: Add RZ/A2 pin and gpio controller") Signed-off-by: Fabrizio Castro Reviewed-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250305163753.34913-5-fabrizio.castro.jz@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit e7b7f5a170d3480614d617d455b804c9e1d9cb50 Author: Tanya Agarwal Date: Tue Jan 14 19:42:04 2025 +0530 lib: 842: Improve error handling in sw842_compress() [ Upstream commit af324dc0e2b558678aec42260cce38be16cc77ca ] The static code analysis tool "Coverity Scan" pointed the following implementation details out for further development considerations: CID 1309755: Unused value In sw842_compress: A value assigned to a variable is never used. (CWE-563) returned_value: Assigning value from add_repeat_template(p, repeat_count) to ret here, but that stored value is overwritten before it can be used. Conclusion: Add error handling for the return value from an add_repeat_template() call. Fixes: 2da572c959dd ("lib: add software 842 compression/decompression") Signed-off-by: Tanya Agarwal Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8ed5381756def0ad83551a0e9686997abbf9ac39 Author: Hou Tao Date: Thu Feb 20 12:22:59 2025 +0800 bpf: Use preempt_count() directly in bpf_send_signal_common() [ Upstream commit b4a8b5bba712a711d8ca1f7d04646db63f9c88f5 ] bpf_send_signal_common() uses preemptible() to check whether or not the current context is preemptible. If it is preemptible, it will use irq_work to send the signal asynchronously instead of trying to hold a spin-lock, because spin-lock is sleepable under PREEMPT_RT. However, preemptible() depends on CONFIG_PREEMPT_COUNT. When CONFIG_PREEMPT_COUNT is turned off (e.g., CONFIG_PREEMPT_VOLUNTARY=y), !preemptible() will be evaluated as 1 and bpf_send_signal_common() will use irq_work unconditionally. Fix it by unfolding "!preemptible()" and using "preempt_count() != 0 || irqs_disabled()" instead. Fixes: 87c544108b61 ("bpf: Send signals asynchronously if !preemptible") Signed-off-by: Hou Tao Link: https://lore.kernel.org/r/20250220042259.1583319-1-houtao@huaweicloud.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 42efddee037b88a3b122c6bbd4dc7a6ca237c148 Author: Konrad Dybcio Date: Sat Jan 11 17:54:18 2025 +0100 clk: qcom: gcc-x1e80100: Unregister GCC_GPU_CFG_AHB_CLK/GCC_DISP_XO_CLK [ Upstream commit b60521eff227ef459e03879cbea2b2bd85a8d7af ] The GPU clock is required for CPU access to GPUSS registers. It was previously decided (on this and many more platforms) that the added overhead/hassle introduced by keeping track of it would not bring much measurable improvement in the power department. The display clock is basically the same story over again. Now, we're past that discussion and this commit is not trying to change that. Instead, the clocks are both force-enabled in .probe *and* registered with the common clock framework, resulting in them being toggled off after ignore_unused. Unregister said clocks to fix breakage when clk_ignore_unused is absent (as it should be). Fixes: 161b7c401f4b ("clk: qcom: Add Global Clock controller (GCC) driver for X1E80100") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250111-topic-x1e_fixups-v1-1-77dc39237c12@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 82484764ea9010b0a5e5c816b7be04863fffc2b8 Author: Luca Weiss Date: Tue Jan 28 22:53:59 2025 +0100 remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8226 [ Upstream commit ba785ff4162a65f18ed501019637a998b752b5ad ] MSM8226 requires the CX power domain, so use the msm8996_adsp_resource which has cx under proxy_pd_names and is otherwise equivalent. Suggested-by: Stephan Gerhold Fixes: fb4f07cc9399 ("remoteproc: qcom: pas: Add MSM8226 ADSP support") Signed-off-by: Luca Weiss Reviewed-by: Stephan Gerhold Link: https://lore.kernel.org/r/20250128-pas-singlepd-v1-1-85d9ae4b0093@lucaweiss.eu Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4a7e28e3523f2cb9a25a1a3dbafed04dbcafa464 Author: Akhil R Date: Mon Feb 24 14:46:08 2025 +0530 crypto: tegra - Set IV to NULL explicitly for AES ECB [ Upstream commit bde558220866e74f19450e16d9a2472b488dfedf ] It may happen that the variable req->iv may have stale values or zero sized buffer by default and may end up getting used during encryption/decryption. This inturn may corrupt the results or break the operation. Set the req->iv variable to NULL explicitly for algorithms like AES-ECB where IV is not used. Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7d25febb0e033e4c09bb4026378d35104f612f59 Author: Kees Bakker Date: Fri Feb 21 20:39:03 2025 +0100 RDMA/mana_ib: Ensure variable err is initialized [ Upstream commit be35a3127d60964b338da95c7bfaaf4a01b330d4 ] In the function mana_ib_gd_create_dma_region if there are no dma blocks to process the variable `err` remains uninitialized. Fixes: 0266a177631d ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter") Signed-off-by: Kees Bakker Link: https://patch.msgid.link/20250221195833.7516C16290A@bout3.ijzerbout.nl Reviewed-by: Long Li Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 088a200ebf465a9699f6fd854a691159a9af9e56 Author: Niklas Schnelle Date: Fri Feb 21 12:51:48 2025 +0100 s390: Remove ioremap_wt() and pgprot_writethrough() [ Upstream commit c94bff63e49302d4ce36502a85a2710a67332a4f ] It turns out that while s390 architecture calls its memory-I/O mapping variants write-through and write-back the implementation of ioremap_wt() and pgprot_writethrough() does not match Linux notion of ioremap_wt(). In particular Linux expects ioremap_wt() to be weaker still than ioremap_wc(), allowing not just gathering and re-ordering but also reads to be served from cache. Instead s390's implementation is equivalent to normal ioremap() while its ioremap_wc() allows re-ordering. Note that there are no known users of ioremap_wt() on s390 and the resulting behavior is in line with asm-generic defining ioremap_wt() as ioremap(), if undefined, so no breakage is expected. As s390 does not have a mapping type matching the Linux notion of ioremap_wt() and pgprot_writethrough(), simply drop them and rely on the asm-generic fallbacks instead. Fixes: b02002cc4c0f ("s390/pci: Implement ioremap_wc/prot() with MIO") Fixes: b43b3fff042d ("s390: mm: convert to GENERIC_IOREMAP") Acked-by: Heiko Carstens Signed-off-by: Niklas Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit bd717b4dea872df69eef7d7c08e76089d99744e2 Author: Vladimir Lypak Date: Sat Mar 15 16:26:18 2025 +0100 clk: qcom: gcc-msm8953: fix stuck venus0_core0 clock [ Upstream commit cdc59600bccf2cb4c483645438a97d4ec55f326b ] This clock can't be enable with VENUS_CORE0 GDSC turned off. But that GDSC is under HW control so it can be turned off at any moment. Instead of checking the dependent clock we can just vote for it to enable later when GDSC gets turned on. Fixes: 9bb6cfc3c77e6 ("clk: qcom: Add Global Clock Controller driver for MSM8953") Signed-off-by: Vladimir Lypak Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20250315-clock-fix-v1-2-2efdc4920dda@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 13a2312c53528865288ac1e7badf1d3360b40c45 Author: Akhil R Date: Mon Feb 24 14:46:07 2025 +0530 crypto: tegra - Fix CMAC intermediate result handling [ Upstream commit ce390d6c2675d2e24d798169a1a0e3cdbc076907 ] Saving and restoring of the intermediate results are needed if there is context switch caused by another ongoing request on the same engine. This is therefore not only to support import/export functionality. Hence, save and restore the intermediate result for every non-first task. Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 241d9965109b4a5805cac78248a80313084ce1a1 Author: Yue Haibing Date: Sat Jan 18 11:13:34 2025 +0800 pinctrl: nuvoton: npcm8xx: Fix error handling in npcm8xx_gpio_fw() [ Upstream commit d6c6fd77e5816e3f6689a2767cdd777797506f24 ] fwnode_irq_get() was changed to not return 0, fix this by checking for negative error, also update the error log. Fixes: acf4884a5717 ("pinctrl: nuvoton: add NPCM8XX pinctrl and GPIO driver") Signed-off-by: Yue Haibing Link: https://lore.kernel.org/20250118031334.243324-1-yuehaibing@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 24307866e0ac0a5ddb462e766ceda5e27a6fbbe3 Author: Will McVicker Date: Wed Feb 12 10:32:52 2025 -0800 clk: samsung: Fix UBSAN panic in samsung_clk_init() [ Upstream commit d19d7345a7bcdb083b65568a11b11adffe0687af ] With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due to dereferencing `ctx->clk_data.hws` before setting `ctx->clk_data.num = nr_clks`. Move that up to fix the crash. UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP Call trace: samsung_clk_init+0x110/0x124 (P) samsung_clk_init+0x48/0x124 (L) samsung_cmu_register_one+0x3c/0xa0 exynos_arm64_register_cmu+0x54/0x64 __gs101_cmu_top_of_clk_init_declare+0x28/0x60 ... Fixes: e620a1e061c4 ("drivers/clk: convert VL struct to struct_size") Signed-off-by: Will McVicker Link: https://lore.kernel.org/r/20250212183253.509771-1-willmcvicker@google.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 81d4e03116d3a5978bc322f89e0d404160d2ae7a Author: Luca Weiss Date: Fri Mar 14 09:24:31 2025 +0100 remoteproc: qcom: pas: add minidump_id to SC7280 WPSS [ Upstream commit d2909538bff0189d4d038f4e903c70be5f5c2bfc ] Add the minidump ID to the wpss resources, based on msm-5.4 devicetree. Fixes: 300ed425dfa9 ("remoteproc: qcom_q6v5_pas: Add SC7280 ADSP, CDSP & WPSS") Signed-off-by: Luca Weiss Link: https://lore.kernel.org/r/20250314-sc7280-wpss-minidump-v1-1-d869d53fd432@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b5d1970003cce8a911061217b1005f12d18990da Author: Claudiu Beznea Date: Wed Jan 15 16:20:58 2025 +0200 clk: renesas: r8a08g045: Check the source of the CPU PLL settings [ Upstream commit dc0f16c1b76293ac942a783e960abfd19e95fdf5 ] On the RZ/G3S SoC, the CPU PLL settings can be set and retrieved through the CPG_PLL1_CLK1 and CPG_PLL1_CLK2 registers. However, these settings are applied only when CPG_PLL1_SETTING.SEL_PLL1 is set to 0. Otherwise, the CPU PLL operates at the default frequency of 1.1 GHz. Hence add support to the PLL driver for returning the 1.1 GHz frequency when the CPU PLL is configured with the default frequency. Fixes: 01eabef547e6 ("clk: renesas: rzg2l: Add support for RZ/G3S PLL") Fixes: de60a3ebe410 ("clk: renesas: Add minimal boot support for RZ/G3S SoC") Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250115142059.1833063-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 8d6373f83f367dbed316ddeb178130a3a64b5b67 Author: David Hildenbrand Date: Fri Mar 21 12:23:23 2025 +0100 x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range() [ Upstream commit dc84bc2aba85a1508f04a936f9f9a15f64ebfb31 ] If track_pfn_copy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables. Consequently untrack_pfn() will see VM_PAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied. The easiest fix would be to simply clear the VM_PAT flag of the dst VMA if track_pfn_copy() fails. However, the whole thing is about "simply" clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy() and performed a reservation, but copying the page tables fails, we'll simply clear the VM_PAT flag, not properly undoing the reservation ... which is also wrong. So let's fix it properly: set the VM_PAT flag only if the reservation succeeded (leaving it clear initially), and undo the reservation if anything goes wrong while copying the page tables: clearing the VM_PAT flag after undoing the reservation. Note that any copied page table entries will get zapped when the VMA will get removed later, after copy_page_range() succeeded; as VM_PAT is not set then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be happy. Note that leaving these page tables in place without a reservation is not a problem, as we are aborting fork(); this process will never run. A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Call Trace: ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180 Likely this case was missed in: d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") ... and instead of undoing the reservation we simply cleared the VM_PAT flag. Keep the documentation of these functions in include/linux/pgtable.h, one place is more than sufficient -- we should clean that up for the other functions like track_pfn_remap/untrack_pfn separately. Fixes: d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") Fixes: 2ab640379a0a ("x86: PAT: hooks in generic vm code to help archs to track pfnmap regions - v3") Reported-by: xingwei lee Reported-by: yuxin wang Reported-by: Marius Fleischer Signed-off-by: David Hildenbrand Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: Rik van Riel Cc: "H. Peter Anvin" Cc: Linus Torvalds Cc: Andrew Morton Cc: linux-mm@kvack.org Link: https://lore.kernel.org/r/20250321112323.153741-1-david@redhat.com Closes: https://lore.kernel.org/lkml/CABOYnLx_dnqzpCW99G81DmOr+2UzdmZMk=T3uxwNxwz+R1RAwg@mail.gmail.com/ Closes: https://lore.kernel.org/lkml/CAJg=8jwijTP5fre8woS4JVJQ8iUA6v+iNcsOgtj9Zfpc3obDOQ@mail.gmail.com/ Signed-off-by: Sasha Levin commit 919206201aacda93ec1ea92a8d1bb0eaaa581165 Author: Viktor Malik Date: Thu Mar 13 13:28:52 2025 +0100 selftests/bpf: Fix string read in strncmp benchmark [ Upstream commit de07b182899227d5fd1ca7a1a7d495ecd453d49c ] The strncmp benchmark uses the bpf_strncmp helper and a hand-written loop to compare two strings. The values of the strings are filled from userspace. One of the strings is non-const (in .bss) while the other is const (in .rodata) since that is the requirement of bpf_strncmp. The problem is that in the hand-written loop, Clang optimizes the reads from the const string to always return 0 which breaks the benchmark. Use barrier_var to prevent the optimization. The effect can be seen on the strncmp-no-helper variant. Before this change: # ./bench strncmp-no-helper Setting up benchmark 'strncmp-no-helper'... Benchmark 'strncmp-no-helper' started. Iter 0 (112.309us): hits 0.000M/s ( 0.000M/prod), drops 0.000M/s, total operations 0.000M/s Iter 1 (-23.238us): hits 0.000M/s ( 0.000M/prod), drops 0.000M/s, total operations 0.000M/s Iter 2 ( 58.994us): hits 0.000M/s ( 0.000M/prod), drops 0.000M/s, total operations 0.000M/s Iter 3 (-30.466us): hits 0.000M/s ( 0.000M/prod), drops 0.000M/s, total operations 0.000M/s Iter 4 ( 29.996us): hits 0.000M/s ( 0.000M/prod), drops 0.000M/s, total operations 0.000M/s Iter 5 ( 16.949us): hits 0.000M/s ( 0.000M/prod), drops 0.000M/s, total operations 0.000M/s Iter 6 (-60.035us): hits 0.000M/s ( 0.000M/prod), drops 0.000M/s, total operations 0.000M/s Summary: hits 0.000 ± 0.000M/s ( 0.000M/prod), drops 0.000 ± 0.000M/s, total operations 0.000 ± 0.000M/s After this change: # ./bench strncmp-no-helper Setting up benchmark 'strncmp-no-helper'... Benchmark 'strncmp-no-helper' started. Iter 0 ( 77.711us): hits 5.534M/s ( 5.534M/prod), drops 0.000M/s, total operations 5.534M/s Iter 1 ( 11.215us): hits 6.006M/s ( 6.006M/prod), drops 0.000M/s, total operations 6.006M/s Iter 2 (-14.253us): hits 5.931M/s ( 5.931M/prod), drops 0.000M/s, total operations 5.931M/s Iter 3 ( 59.087us): hits 6.005M/s ( 6.005M/prod), drops 0.000M/s, total operations 6.005M/s Iter 4 (-21.379us): hits 6.010M/s ( 6.010M/prod), drops 0.000M/s, total operations 6.010M/s Iter 5 (-20.310us): hits 5.861M/s ( 5.861M/prod), drops 0.000M/s, total operations 5.861M/s Iter 6 ( 53.937us): hits 6.004M/s ( 6.004M/prod), drops 0.000M/s, total operations 6.004M/s Summary: hits 5.969 ± 0.061M/s ( 5.969M/prod), drops 0.000 ± 0.000M/s, total operations 5.969 ± 0.061M/s Fixes: 9c42652f8be3 ("selftests/bpf: Add benchmark for bpf_strncmp() helper") Suggested-by: Andrii Nakryiko Signed-off-by: Viktor Malik Signed-off-by: Andrii Nakryiko Acked-by: Hou Tao Link: https://lore.kernel.org/bpf/20250313122852.1365202-1-vmalik@redhat.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 652a3dfd8c2bfeff26f56325a44b666258a2062d Author: Andrii Nakryiko Date: Wed Feb 19 16:28:21 2025 -0800 libbpf: Fix hypothetical STT_SECTION extern NULL deref case [ Upstream commit e0525cd72b5979d8089fe524a071ea93fd011dc9 ] Fix theoretical NULL dereference in linker when resolving *extern* STT_SECTION symbol against not-yet-existing ELF section. Not sure if it's possible in practice for valid ELF object files (this would require embedded assembly manipulations, at which point BTF will be missing), but fix the s/dst_sym/dst_sec/ typo guarding this condition anyways. Fixes: faf6ed321cf6 ("libbpf: Add BPF static linker APIs") Fixes: a46349227cd8 ("libbpf: Add linker extern resolution support for functions and global variables") Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20250220002821.834400-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 73fd28b12d78bb1bebda737f7d1065d53c5af275 Author: Luca Weiss Date: Tue Jan 28 22:54:00 2025 +0100 remoteproc: qcom_q6v5_pas: Make single-PD handling more robust [ Upstream commit e917b73234b02aa4966325e7380d2559bf127ba9 ] Only go into the if condition for single-PD handling when there's actually just one power domain specified there. Otherwise it'll be an issue in the dts and we should fail in the regular code path. This also mirrors the latest changes in the qcom_q6v5_mss driver. Suggested-by: Stephan Gerhold Fixes: 17ee2fb4e856 ("remoteproc: qcom: pas: Vote for active/proxy power domains") Signed-off-by: Luca Weiss Reviewed-by: Stephan Gerhold Link: https://lore.kernel.org/r/20250128-pas-singlepd-v1-2-85d9ae4b0093@lucaweiss.eu Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 26c0229b604e0ddd21994418f791c33949121fb2 Author: Claudiu Beznea Date: Sat Feb 15 15:12:35 2025 +0200 pinctrl: renesas: rzg2l: Suppress binding attributes [ Upstream commit ea4065345643f3163e812e58ed8add2c75c3ee46 ] Suppress binding attributes for the rzg2l pinctrl driver, as it is an essential block for Renesas SoCs. Unbinding the driver leads to warnings from __device_links_no_driver() and can eventually render the system inaccessible. Fixes: c4c4637eb57f ("pinctrl: renesas: Add RZ/G2L pin and gpio controller driver") Signed-off-by: Claudiu Beznea Reviewed-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250215131235.228274-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit bfcca46f01ac8dae51dc1aceb507e919f74069fe Author: Zijun Hu Date: Tue Feb 25 21:58:06 2025 +0800 of: property: Increase NR_FWNODE_REFERENCE_ARGS [ Upstream commit eb50844d728f11e87491f7c7af15a4a737f1159d ] Currently, the following two macros have different values: // The maximal argument count for firmware node reference #define NR_FWNODE_REFERENCE_ARGS 8 // The maximal argument count for DT node reference #define MAX_PHANDLE_ARGS 16 It may cause firmware node reference's argument count out of range if directly assign DT node reference's argument count to firmware's. drivers/of/property.c:of_fwnode_get_reference_args() is doing the direct assignment, so may cause firmware's argument count @args->nargs got out of range, namely, in [9, 16]. Fix by increasing NR_FWNODE_REFERENCE_ARGS to 16 to meet DT requirement. Will align both macros later to avoid such inconsistency. Fixes: 3e3119d3088f ("device property: Introduce fwnode_property_get_reference_args") Signed-off-by: Zijun Hu Acked-by: Sakari Ailus Link: https://lore.kernel.org/r/20250225-fix_arg_count-v4-1-13cdc519eb31@quicinc.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 2df19f5f6f72da6f6ebab7cdb3a3b9f7686bb476 Author: Peng Fan Date: Wed Mar 19 18:01:05 2025 +0800 remoteproc: core: Clear table_sz when rproc_shutdown [ Upstream commit efdde3d73ab25cef4ff2d06783b0aad8b093c0e4 ] There is case as below could trigger kernel dump: Use U-Boot to start remote processor(rproc) with resource table published to a fixed address by rproc. After Kernel boots up, stop the rproc, load a new firmware which doesn't have resource table ,and start rproc. When starting rproc with a firmware not have resource table, `memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` will trigger dump, because rproc->cache_table is set to NULL during the last stop operation, but rproc->table_sz is still valid. This issue is found on i.MX8MP and i.MX9. Dump as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __pi_memcpy_generic+0x110/0x22c lr : rproc_start+0x88/0x1e0 Call trace: __pi_memcpy_generic+0x110/0x22c (P) rproc_boot+0x198/0x57c state_store+0x40/0x104 dev_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/0x1cc vfs_write+0x240/0x378 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xcc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c Clear rproc->table_sz to address the issue. Fixes: 9dc9507f1880 ("remoteproc: Properly deal with the resource table when detaching") Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20250319100106.3622619-1-peng.fan@oss.nxp.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 01fd737776ca0f17a96d83cd7f0840ce130b9a02 Author: Michael Guralnik Date: Thu Mar 13 16:29:51 2025 +0200 RDMA/mlx5: Fix page_size variable overflow [ Upstream commit f0c2427412b43cdf1b7b0944749ea17ddb97d5a5 ] Change all variables storing mlx5_umem_mkc_find_best_pgsz() result to unsigned long to support values larger than 31 and avoid overflow. For example: If we try to register 4GB of memory that is contiguous in physical memory, the driver will optimize the page_size and try to use an mkey with 4GB entity size. The 'unsigned int' page_size variable will overflow to '0' and we'll hit the WARN_ON() in alloc_cacheable_mr(). WARNING: CPU: 2 PID: 1203 at drivers/infiniband/hw/mlx5/mr.c:1124 alloc_cacheable_mr+0x22/0x580 [mlx5_ib] Modules linked in: mlx5_ib mlx5_core bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre rdma_rxe rdma_ucm ib_uverbs ib_ipoib ib_umad rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm fuse ib_core [last unloaded: mlx5_core] CPU: 2 UID: 70878 PID: 1203 Comm: rdma_resource_l Tainted: G W 6.14.0-rc4-dirty #43 Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:alloc_cacheable_mr+0x22/0x580 [mlx5_ib] Code: 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 41 52 53 48 83 ec 30 f6 46 28 04 4c 8b 77 08 75 21 <0f> 0b 49 c7 c2 ea ff ff ff 48 8d 65 d0 4c 89 d0 5b 41 5a 41 5c 41 RSP: 0018:ffffc900006ffac8 EFLAGS: 00010246 RAX: 0000000004c0d0d0 RBX: ffff888217a22000 RCX: 0000000000100001 RDX: 00007fb7ac480000 RSI: ffff8882037b1240 RDI: ffff8882046f0600 RBP: ffffc900006ffb28 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000007e0 R11: ffffea0008011d40 R12: ffff8882037b1240 R13: ffff8882046f0600 R14: ffff888217a22000 R15: ffffc900006ffe00 FS: 00007fb7ed013340(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb7ed1d8000 CR3: 00000001fd8f6006 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __warn+0x81/0x130 ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib] ? report_bug+0xfc/0x1e0 ? handle_bug+0x55/0x90 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib] create_real_mr+0x54/0x150 [mlx5_ib] ib_uverbs_reg_mr+0x17f/0x2a0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xca/0x140 [ib_uverbs] ib_uverbs_run_method+0x6d0/0x780 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x19b/0x360 [ib_uverbs] ? walk_system_ram_range+0x79/0xd0 ? ___pte_offset_map+0x1b/0x110 ? __pte_offset_map_lock+0x80/0x100 ib_uverbs_ioctl+0xac/0x110 [ib_uverbs] __x64_sys_ioctl+0x94/0xb0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fb7ecf0737b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 2a 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffdbe03ecc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffdbe03edb8 RCX: 00007fb7ecf0737b RDX: 00007ffdbe03eda0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffdbe03ed80 R08: 00007fb7ecc84010 R09: 00007ffdbe03eed4 R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffdbe03eed4 R13: 000000000000000c R14: 000000000000000c R15: 00007fb7ecc84150 Fixes: cef7dde8836a ("net/mlx5: Expand mkey page size to support 6 bits") Signed-off-by: Michael Guralnik Reviewed-by: Yishai Hadas Link: https://patch.msgid.link/2479a4a3f6fd9bd032e1b6d396274a89c4c5e22f.1741875692.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 51bcbe6cdaf06cbeaf2a5bac54e08d2661141e74 Author: Wenkai Lin Date: Wed Feb 5 11:56:28 2025 +0800 crypto: hisilicon/sec2 - fix for sec spec check [ Upstream commit f4f353cb7ae9bb43e34943edb693532a39118eca ] During encryption and decryption, user requests must be checked first, if the specifications that are not supported by the hardware are used, the software computing is used for processing. Fixes: 2f072d75d1ab ("crypto: hisilicon - Add aead support on SEC2") Signed-off-by: Wenkai Lin Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 71f4581c464b2f666ffebaa409b747b273ba9209 Author: Wenkai Lin Date: Wed Feb 5 11:56:27 2025 +0800 crypto: hisilicon/sec2 - fix for aead authsize alignment [ Upstream commit a49cc71e219040d771a8c1254879984f98192811 ] The hardware only supports authentication sizes that are 4-byte aligned. Therefore, the driver switches to software computation in this case. Fixes: 2f072d75d1ab ("crypto: hisilicon - Add aead support on SEC2") Signed-off-by: Wenkai Lin Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 0069c0e671ab57d096b66a127c1bc1e31595f0fe Author: Jerome Brunet Date: Fri Dec 20 11:25:36 2024 +0100 clk: amlogic: gxbb: drop incorrect flag on 32k clock [ Upstream commit f38f7fe4830c5cb4eac138249225f119e7939965 ] gxbb_32k_clk_div sets CLK_DIVIDER_ROUND_CLOSEST in the init_data flag which is incorrect. This is field is not where the divider flags belong. Thankfully, CLK_DIVIDER_ROUND_CLOSEST maps to bit 4 which is an unused clock flag, so there is no unintended consequence to this error. Effectively, the clock has been used without CLK_DIVIDER_ROUND_CLOSEST so far, so just drop it. Fixes: 14c735c8e308 ("clk: meson-gxbb: Add EE 32K Clock for CEC") Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20241220-amlogic-clk-gxbb-32k-fixes-v1-1-baca56ecf2db@baylibre.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit 46ea02988bb9d171bb2135dd0bb7ceeaef585424 Author: Akhil R Date: Mon Feb 24 14:46:10 2025 +0530 crypto: tegra - Use HMAC fallback when keyslots are full [ Upstream commit f80a2e2e77bedd0aa645a60f89b4f581c70accda ] The intermediate results for HMAC is stored in the allocated keyslot by the hardware. Dynamic allocation of keyslot during an operation is hence not possible. As the number of keyslots are limited in the hardware, fallback to the HMAC software implementation if keyslots are not available Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 057298d193342ef6c4a37d6f69cbccb45e7812f4 Author: Arnd Bergmann Date: Mon Feb 17 13:55:55 2025 +0100 crypto: bpf - Add MODULE_DESCRIPTION for skcipher [ Upstream commit f307c87ea06c64b87fcd3221a682cd713cde51e9 ] All modules should have a description, building with extra warnings enabled prints this outfor the for bpf_crypto_skcipher module: WARNING: modpost: missing MODULE_DESCRIPTION() in crypto/bpf_crypto_skcipher.o Add a description line. Fixes: fda4f71282b2 ("bpf: crypto: add skcipher to bpf crypto") Signed-off-by: Arnd Bergmann Reviewed-by: Vadim Fedorenko Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3e0d61cf588f1412d8516954c4a93f01c517ac38 Author: Akhil R Date: Mon Feb 24 14:46:04 2025 +0530 crypto: tegra - check return value for hash do_one_req [ Upstream commit dcf8b7e49b86738296c77fb58c123dd2d74a22a7 ] Initialize and check the return value in hash *do_one_req() functions and exit the function if there is an error. This fixes the 'uninitialized variable' warnings reported by testbots. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202412071747.flPux4oB-lkp@intel.com/ Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5d9147db00d3590ba9d2a8ff947da0c5a899590d Author: Akhil R Date: Mon Feb 24 14:46:01 2025 +0530 crypto: tegra - Use separate buffer for setkey [ Upstream commit bcfc8fc53f3acb3213fb9d28675244aa4ce208e0 ] The buffer which sends the commands to host1x was shared for all tasks in the engine. This causes a problem with the setkey() function as it gets called asynchronous to the crypto engine queue. Modifying the same cmdbuf in setkey() will corrupt the ongoing host1x task and in turn break the encryption/decryption operation. Hence use a separate cmdbuf for setkey(). Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f23dfee54b57a8d95d39a4f1a0e893f28dfbb668 Author: Bairavi Alagappan Date: Fri Mar 14 13:14:29 2025 +0000 crypto: qat - set parity error mask for qat_420xx [ Upstream commit f9555d18084985c80a91baa4fdb7d205b401a754 ] The field parerr_wat_wcp_mask in the structure adf_dev_err_mask enables the detection and reporting of parity errors for the wireless cipher and wireless authentication accelerators. Set the parerr_wat_wcp_mask field, which was inadvertently omitted during the initial enablement of the qat_420xx driver, to ensure that parity errors are enabled for those accelerators. In addition, fix the string used to report such errors that was inadvertently set to "ath_cph" (authentication and cipher). Fixes: fcf60f4bcf54 ("crypto: qat - add support for 420xx devices") Signed-off-by: Bairavi Alagappan Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 92936d50c5b8497606c1787181fee6fe01336d66 Author: Herbert Xu Date: Thu Feb 27 18:14:55 2025 +0800 crypto: iaa - Test the correct request flag [ Upstream commit fc4bd01d9ff592f620c499686245c093440db0e8 ] Test the correct flags for the MAY_SLEEP bit. Fixes: 2ec6761df889 ("crypto: iaa - Add support for deflate-iaa compression algorithm") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 238ece4937aa5f103bc65b55678b2b1b2700c3f8 Author: Danila Chernetsov Date: Wed Mar 19 01:30:11 2025 +0000 fbdev: sm501fb: Add some geometry checks. [ Upstream commit aee50bd88ea5fde1ff4cc021385598f81a65830c ] Added checks for xoffset, yoffset settings. Incorrect settings of these parameters can lead to errors in sm501fb_pan_ functions. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5fc404e47bdf ("[PATCH] fb: SM501 framebuffer driver") Signed-off-by: Danila Chernetsov Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 8356f45700829630a08aba497f694ec8788c7b55 Author: Arnd Bergmann Date: Tue Feb 25 17:44:23 2025 +0100 mdacon: rework dependency list [ Upstream commit 5bbcc7645f4b244ffb5ac6563fbe9d3d42194447 ] mdacon has roughly the same dependencies as vgacon but expresses them as a negative list instead of a positive list, with the only practical difference being PowerPC/CHRP, which uses vga16fb instead of vgacon. The CONFIG_MDA_CONSOLE description advises to only turn it on when vgacon is also used because MDA/Hercules-only systems should be using vgacon instead, so just change the list to enforce that directly for simplicity. The probing was broken from 2002 to 2008, this improves on the fix that was added then: If vgacon is a loadable module, then mdacon cannot be built-in now, and the list of systems that support vgacon is carried over. Fixes: 0b9cf3aa6b1e ("mdacon messing up default vc's - set default to vc13-16 again") Signed-off-by: Arnd Bergmann Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit d3ea050c153d87d88202498f2ba5fe5f458d7d6c Author: Arnd Bergmann Date: Tue Feb 25 17:44:22 2025 +0100 dummycon: fix default rows/cols [ Upstream commit beefaba1978c04ea2950d34236f58fe6cf6a7f58 ] dummycon fails to build on ARM/footbridge when the VGA console is disabled, since I got the dependencies slightly wrong in a previous patch: drivers/video/console/dummycon.c: In function 'dummycon_init': drivers/video/console/dummycon.c:27:25: error: 'CONFIG_DUMMY_CONSOLE_COLUMNS' undeclared (first use in this function); did you mean 'CONFIG_DUMMY_CONSOLE'? 27 | #define DUMMY_COLUMNS CONFIG_DUMMY_CONSOLE_COLUMNS drivers/video/console/dummycon.c:28:25: error: 'CONFIG_DUMMY_CONSOLE_ROWS' undeclared (first use in this function); did you mean 'CONFIG_DUMMY_CONSOLE'? 28 | #define DUMMY_ROWS CONFIG_DUMMY_CONSOLE_ROWS This only showed up after many thousand randconfig builds on Arm, and doesn't matter in practice, but should still be fixed. Address it by using the default row/columns on footbridge after all in that corner case. Fixes: 4293b0925149 ("dummycon: limit Arm console size hack to footbridge") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202409151512.LML1slol-lkp@intel.com/ Signed-off-by: Arnd Bergmann Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 9a14cacaf527ae49ccd2bde1287c5791d6e6c0cb Author: Markus Elfring Date: Thu Apr 13 21:35:36 2023 +0200 fbdev: au1100fb: Move a variable assignment behind a null pointer check [ Upstream commit 2df2c0caaecfd869b49e14f2b8df822397c5dd7f ] The address of a data structure member was determined before a corresponding null pointer check in the implementation of the function “au1100fb_setmode”. This issue was detected by using the Coccinelle software. Fixes: 3b495f2bb749 ("Au1100 FB driver uplift for 2.6.") Signed-off-by: Markus Elfring Acked-by: Uwe Kleine-König Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit b1c4bd166771767fa22595a39aad929abf2f1a74 Author: Ilpo Järvinen Date: Fri Mar 21 18:21:14 2025 +0200 PCI: pciehp: Don't enable HPIE when resuming in poll mode [ Upstream commit 527664f738afb6f2c58022cd35e63801e5dc7aec ] PCIe hotplug can operate in poll mode without interrupt handlers using a polling kthread only. eb34da60edee ("PCI: pciehp: Disable hotplug interrupt during suspend") failed to consider that and enables HPIE (Hot-Plug Interrupt Enable) unconditionally when resuming the Port. Only set HPIE if non-poll mode is in use. This makes pcie_enable_interrupt() match how pcie_enable_notification() already handles HPIE. Link: https://lore.kernel.org/r/20250321162114.3939-1-ilpo.jarvinen@linux.intel.com Fixes: eb34da60edee ("PCI: pciehp: Disable hotplug interrupt during suspend") Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Signed-off-by: Sasha Levin commit e23dfb926f5bfde70fcc13139165b4b214a5919a Author: Ilpo Järvinen Date: Thu Mar 20 16:28:37 2025 +0200 PCI: Fix BAR resizing when VF BARs are assigned [ Upstream commit 9ec19bfa78bd788945e2445b09de7b4482dee432 ] __resource_resize_store() attempts to release all resources of the device before attempting the resize. The loop, however, only covers standard BARs (< PCI_STD_NUM_BARS). If a device has VF BARs that are assigned, pci_reassign_bridge_resources() finds the bridge window still has some assigned child resources and returns -NOENT which makes pci_resize_resource() to detect an error and abort the resize. Change the release loop to cover all resources up to VF BARs which allows the resize operation to release the bridge windows and attempt to assigned them again with the different size. If SR-IOV is enabled, disallow resize as it requires releasing also IOV resources. Link: https://lore.kernel.org/r/20250320142837.8027-1-ilpo.jarvinen@linux.intel.com Fixes: 91fa127794ac ("PCI: Expose PCIe Resizable BAR support via sysfs") Reported-by: Michał Winiarski Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Reviewed-by: Alex Williamson Signed-off-by: Sasha Levin commit a1855c2ebb88b32d65b1b775ffb4a989df6f054d Author: Christophe JAILLET Date: Sat Mar 1 19:42:54 2025 +0100 PCI: histb: Fix an error handling path in histb_pcie_probe() [ Upstream commit b36fb50701619efca5f5450b355d42575cf532ed ] If an error occurs after a successful phy_init() call, then phy_exit() should be called. Add the missing call, as already done in the remove function. Fixes: bbd11bddb398 ("PCI: hisi: Add HiSilicon STB SoC PCIe controller driver") Signed-off-by: Christophe JAILLET [kwilczynski: remove unnecessary hipcie->phy NULL check from histb_pcie_probe() and squash a patch that removes similar NULL check for hipcie-phy from histb_pcie_remove() from https://lore.kernel.org/linux-pci/c369b5d25e17a44984ae5a889ccc28a59a0737f7.1742058005.git.christophe.jaillet@wanadoo.fr] Signed-off-by: Krzysztof Wilczyński Link: https://lore.kernel.org/r/8301fc15cdea5d2dac21f57613e8e6922fb1ad95.1740854531.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit b004cf517d8e9efadb0ba35cbae20067b59972a0 Author: Dan Carpenter Date: Wed Mar 5 18:00:07 2025 +0300 PCI: dwc: ep: Return -ENOMEM for allocation failures [ Upstream commit 8189aa56dbed0bfb46b7b30d4d231f57ab17b3f4 ] If the bitmap or memory allocations fail, then dw_pcie_ep_init_registers() will incorrectly return a success. Return -ENOMEM instead. Fixes: 869bc5253406 ("PCI: dwc: ep: Fix DBI access failure for drivers requiring refclk from host") Signed-off-by: Dan Carpenter [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Reviewed-by: Krzysztof Wilczyński Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/36dcb6fc-f292-4dd5-bd45-a8c6f9dc3df7@stanley.mountain Signed-off-by: Sasha Levin commit 3453bcaf2ca92659346bf8504c2b52b3993fbd79 Author: Thadeu Lima de Souza Cascardo Date: Wed Feb 5 10:06:38 2025 -0300 drm/amd/display: avoid NPD when ASIC does not support DMUB [ Upstream commit 42d9d7bed270247f134190ba0cb05bbd072f58c2 ] ctx->dmub_srv will de NULL if the ASIC does not support DMUB, which is tested in dm_dmub_sw_init. However, it will be dereferenced in dmub_hw_lock_mgr_cmd if should_use_dmub_lock returns true. This has been the case since dmub support has been added for PSR1. Fix this by checking for dmub_srv in should_use_dmub_lock. [ 37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058 [ 37.447808] #PF: supervisor read access in kernel mode [ 37.452959] #PF: error_code(0x0000) - not-present page [ 37.458112] PGD 0 P4D 0 [ 37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI [ 37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88 [ 37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023 [ 37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 <48> 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5 [ 37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202 [ 37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358 [ 37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000 [ 37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5 [ 37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000 [ 37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000 [ 37.551725] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000 [ 37.559814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0 [ 37.572697] Call Trace: [ 37.575152] [ 37.577258] ? __die_body+0x66/0xb0 [ 37.580756] ? page_fault_oops+0x3e7/0x4a0 [ 37.584861] ? exc_page_fault+0x3e/0xe0 [ 37.588706] ? exc_page_fault+0x5c/0xe0 [ 37.592550] ? asm_exc_page_fault+0x22/0x30 [ 37.596742] ? dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.601107] dcn10_cursor_lock+0x1e1/0x240 [ 37.605211] program_cursor_attributes+0x81/0x190 [ 37.609923] commit_planes_for_stream+0x998/0x1ef0 [ 37.614722] update_planes_and_stream_v2+0x41e/0x5c0 [ 37.619703] dc_update_planes_and_stream+0x78/0x140 [ 37.624588] amdgpu_dm_atomic_commit_tail+0x4362/0x49f0 [ 37.629832] ? srso_return_thunk+0x5/0x5f [ 37.633847] ? mark_held_locks+0x6d/0xd0 [ 37.637774] ? _raw_spin_unlock_irq+0x24/0x50 [ 37.642135] ? srso_return_thunk+0x5/0x5f [ 37.646148] ? lockdep_hardirqs_on+0x95/0x150 [ 37.650510] ? srso_return_thunk+0x5/0x5f [ 37.654522] ? _raw_spin_unlock_irq+0x2f/0x50 [ 37.658883] ? srso_return_thunk+0x5/0x5f [ 37.662897] ? wait_for_common+0x186/0x1c0 [ 37.666998] ? srso_return_thunk+0x5/0x5f [ 37.671009] ? drm_crtc_next_vblank_start+0xc3/0x170 [ 37.675983] commit_tail+0xf5/0x1c0 [ 37.679478] drm_atomic_helper_commit+0x2a2/0x2b0 [ 37.684186] drm_atomic_commit+0xd6/0x100 [ 37.688199] ? __cfi___drm_printfn_info+0x10/0x10 [ 37.692911] drm_atomic_helper_update_plane+0xe5/0x130 [ 37.698054] drm_mode_cursor_common+0x501/0x670 [ 37.702600] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10 [ 37.707572] drm_mode_cursor_ioctl+0x48/0x70 [ 37.711851] drm_ioctl_kernel+0xf2/0x150 [ 37.715781] drm_ioctl+0x363/0x590 [ 37.719189] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10 [ 37.724165] amdgpu_drm_ioctl+0x41/0x80 [ 37.728013] __se_sys_ioctl+0x7f/0xd0 [ 37.731685] do_syscall_64+0x87/0x100 [ 37.735355] ? vma_end_read+0x12/0xe0 [ 37.739024] ? srso_return_thunk+0x5/0x5f [ 37.743041] ? find_held_lock+0x47/0xf0 [ 37.746884] ? vma_end_read+0x12/0xe0 [ 37.750552] ? srso_return_thunk+0x5/0x5f [ 37.754565] ? lock_release+0x1c4/0x2e0 [ 37.758406] ? vma_end_read+0x12/0xe0 [ 37.762079] ? exc_page_fault+0x84/0xe0 [ 37.765921] ? srso_return_thunk+0x5/0x5f [ 37.769938] ? lockdep_hardirqs_on+0x95/0x150 [ 37.774303] ? srso_return_thunk+0x5/0x5f [ 37.778317] ? exc_page_fault+0x84/0xe0 [ 37.782163] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 37.787218] RIP: 0033:0x784aa5ec3059 [ 37.790803] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1d 48 8b 45 c8 64 48 2b 04 25 28 00 0 [ 37.809553] RSP: 002b:0000784a9cdf90e0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 37.817121] RAX: ffffffffffffffda RBX: 0000784a9cdf917c RCX: 0000784aa5ec3059 [ 37.824256] RDX: 0000784a9cdf917c RSI: 00000000c01c64a3 RDI: 0000000000000020 [ 37.831391] RBP: 0000784a9cdf9130 R08: 0000000000000100 R09: 0000000000ff0000 [ 37.838525] R10: 0000000000000000 R11: 0000000000000246 R12: 0000025c01606ed0 [ 37.845657] R13: 0000025c00030200 R14: 00000000c01c64a3 R15: 0000000000000020 [ 37.852799] [ 37.854992] Modules linked in: [ 37.864546] gsmi: Log Shutdown Reason 0x03 [ 37.868656] CR2: 0000000000000058 [ 37.871979] ---[ end trace 0000000000000000 ]--- [ 37.880976] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.885954] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 <48> 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5 [ 37.904703] RSP: 0018:ffff969442853300 EFLAGS: 00010202 [ 37.909933] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358 [ 37.917068] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000 [ 37.924201] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5 [ 37.931336] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000 [ 37.938469] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000 [ 37.945602] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000 [ 37.953689] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.959435] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0 [ 37.966570] Kernel panic - not syncing: Fatal exception [ 37.971901] Kernel Offset: 0x30200000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 37.982840] gsmi: Log Shutdown Reason 0x02 Fixes: b5c764d6ed55 ("drm/amd/display: Use HW lock mgr for PSR1") Signed-off-by: Thadeu Lima de Souza Cascardo Cc: Sun peng Li Cc: Tom Chung Cc: Daniel Wheeler Cc: Alex Deucher Reviewed-by: Rodrigo Siqueira Reviewed-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d877bf6eb39c1621563093ba1b30952ba6d95e08 Author: Dan Carpenter Date: Wed Jan 8 12:35:57 2025 +0300 drm/mediatek: dsi: fix error codes in mtk_dsi_host_transfer() [ Upstream commit dcb166ee43c3d594e7b73a24f6e8cf5663eeff2c ] There is a type bug because the return statement: return ret < 0 ? ret : recv_cnt; The issue is that ret is an int, recv_cnt is a u32 and the function returns ssize_t, which is a signed long. The way that the type promotion works is that the negative error codes are first cast to u32 and then to signed long. The error codes end up being positive instead of negative and the callers treat them as success. Fixes: 81cc7e51c4f1 ("drm/mediatek: Allow commands to be sent during video mode") Reported-by: kernel test robot Closes: https://lore.kernel.org/r/202412210801.iADw0oIH-lkp@intel.com/ Signed-off-by: Dan Carpenter Reviewed-by: Mattijs Korpershoek Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/b754a408-4f39-4e37-b52d-7706c132e27f@stanley.mountain/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 57a9fb47551b33cde7b76d17c0072c3b394f4620 Author: Douglas Anderson Date: Thu Jan 16 09:42:50 2025 -0800 drm/mediatek: dp: drm_err => dev_err in HPD path to avoid NULL ptr [ Upstream commit 106a6de46cf4887d535018185ec528ce822d6d84 ] The function mtk_dp_wait_hpd_asserted() may be called before the `mtk_dp->drm_dev` pointer is assigned in mtk_dp_bridge_attach(). Specifically it can be called via this callpath: - mtk_edp_wait_hpd_asserted - [panel probe] - dp_aux_ep_probe Using "drm" level prints anywhere in this callpath causes a NULL pointer dereference. Change the error message directly in mtk_dp_wait_hpd_asserted() to dev_err() to avoid this. Also change the error messages in mtk_dp_parse_capabilities(), which is called by mtk_dp_wait_hpd_asserted(). While touching these prints, also add the error code to them to make future debugging easier. Fixes: 7eacba9a083b ("drm/mediatek: dp: Add .wait_hpd_asserted() for AUX bus") Signed-off-by: Douglas Anderson Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20250116094249.1.I29b0b621abb613ddc70ab4996426a3909e1aa75f@changeid/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit e5838a2bf16fc669908769d74539499a25e1ccd9 Author: Jason-JH Lin Date: Mon Feb 24 13:12:21 2025 +0800 drm/mediatek: Fix config_updating flag never false when no mbox channel [ Upstream commit 4ba973c8bad04d59fd4efa62512f4d9cee131714 ] When CONFIG_MTK_CMDQ is enabled, if the display is controlled by the CPU while other hardware is controlled by the GCE, the display will encounter a mbox request channel failure. However, it will still enter the CONFIG_MTK_CMDQ statement, causing the config_updating flag to never be set to false. As a result, no page flip event is sent back to user space, and the screen does not update. Fixes: da03801ad08f ("drm/mediatek: Move mtk_crtc_finish_page_flip() to ddp_cmdq_cb()") Signed-off-by: Jason-JH Lin Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20250224051301.3538484-1-jason-jh.lin@mediatek.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 02e94069c3e9d2e59009663f83412c1bf3f230cc Author: Thippeswamy Havalige Date: Mon Feb 24 21:20:22 2025 +0530 PCI: xilinx-cpm: Fix IRQ domain leak in error path of probe [ Upstream commit 57b0302240741e73fe51f88404b3866e0d2933ad ] The IRQ domain allocated for the PCIe controller is not freed if resource_list_first_type() returns NULL, leading to a resource leak. This fix ensures properly cleaning up the allocated IRQ domain in the error path. Fixes: 49e427e6bdd1 ("Merge branch 'pci/host-probe-refactor'") Signed-off-by: Thippeswamy Havalige [kwilczynski: added missing Fixes: tag, refactored to use one of the goto labels] Signed-off-by: Krzysztof Wilczyński Link: https://lore.kernel.org/r/20250224155025.782179-2-thippeswamy.havalige@amd.com Signed-off-by: Sasha Levin commit 362b5879a7f33c9684955502b3b1212aa995d529 Author: Dan Carpenter Date: Fri Mar 7 11:46:34 2025 +0300 PCI: Remove stray put_device() in pci_register_host_bridge() [ Upstream commit 6e8d06e5096c80cbf41313b4a204f43071ca42be ] This put_device() was accidentally left over from when we changed the code from using device_register() to calling device_add(). Delete it. Link: https://lore.kernel.org/r/55b24870-89fb-4c91-b85d-744e35db53c2@stanley.mountain Fixes: 9885440b16b8 ("PCI: Fix pci_host_bridge struct device release/free handling") Signed-off-by: Dan Carpenter Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 7b40c5b938e980c0730e9f225c1837abf5cb15f0 Author: Christophe Leroy Date: Thu Mar 6 11:24:28 2025 +0100 powerpc/kexec: fix physical address calculation in clear_utlb_entry() [ Upstream commit 861efb8a48ee8b73ae4e8817509cd4e82fd52bc4 ] In relocate_32.S, function clear_utlb_entry() goes into real mode. To do so, it has to calculate the physical address based on the virtual address. To get the virtual address it uses 'bl' which is problematic (see commit c974809a26a1 ("powerpc/vdso: Avoid link stack corruption in __get_datapage()")). In addition, the calculation is done on a wrong address because 'bl' loads LR with the address of the following instruction, not the address of the target. So when the target is not the instruction following the 'bl' instruction, it may lead to unexpected behaviour. Fix it by re-writing the code so that is goes via another path which is based 'bcl 20,31,.+4' which is the right instruction to use for that. Fixes: 683430200315 ("powerpc/47x: Kernel support for KEXEC") Signed-off-by: Christophe Leroy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/dc4f9616fba9c05c5dbf9b4b5480eb1c362adc17.1741256651.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 7e754aa0daaf48e682148353537dd7dab7cb0e8f Author: Christophe Leroy Date: Wed Mar 5 00:02:39 2025 +0100 crypto: powerpc: Mark ghashp8-ppc.o as an OBJECT_FILES_NON_STANDARD [ Upstream commit 1e4d73d06c98f5a1af4f7591cf7c2c4eee5b94fa ] The following build warning has been reported: arch/powerpc/crypto/ghashp8-ppc.o: warning: objtool: .text+0x22c: unannotated intra-function call This happens due to commit bb7f054f4de2 ("objtool/powerpc: Add support for decoding all types of uncond branches") Disassembly of arch/powerpc/crypto/ghashp8-ppc.o shows: arch/powerpc/crypto/ghashp8-ppc.o: file format elf64-powerpcle Disassembly of section .text: 0000000000000140 : 140: f8 ff 00 3c lis r0,-8 ... 20c: 20 00 80 4e blr 210: 00 00 00 00 .long 0x0 214: 00 0c 14 00 .long 0x140c00 218: 00 00 04 00 .long 0x40000 21c: 00 00 00 00 .long 0x0 220: 47 48 41 53 rlwimi. r1,r26,9,1,3 224: 48 20 66 6f xoris r6,r27,8264 228: 72 20 50 6f xoris r16,r26,8306 22c: 77 65 72 49 bla 1726574 <== ... It corresponds to the following code in ghashp8-ppc.o : _GLOBAL(gcm_ghash_p8) lis 0,0xfff8 ... blr .long 0 .byte 0,12,0x14,0,0,0,4,0 .long 0 .size gcm_ghash_p8,.-gcm_ghash_p8 .byte 71,72,65,83,72,32,102,111,114,32,80,111,119,101,114,73,83,65,32,50,46,48,55,44,32,67,82,89,80,84,79,71,65,77,83,32,98,121,32,60,97,112,112,114,111,64,111,112,101,110,115,115,108,46,111,114,103,62,0 .align 2 .align 2 In fact this is raw data that is after the function end and that is not text so shouldn't be disassembled as text. But ghashp8-ppc.S is generated by a perl script and should have been marked as OBJECT_FILES_NON_STANDARD. Now that 'bla' is understood as a call instruction, that raw data is mis-interpreted as an infra-function call. Mark ghashp8-ppc.o as a OBJECT_FILES_NON_STANDARD to avoid this warning. Reported-by: Venkat Rao Bagalkote Closes: https://lore.kernel.org/all/8c4c3fc2-2bd7-4148-af68-2f504d6119e0@linux.ibm.com Fixes: 109303336a0c ("crypto: vmx - Move to arch/powerpc/crypto") Signed-off-by: Christophe Leroy Tested-By: Venkat Rao Bagalkote Reviewed-by: Sathvika Vasireddy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/7aa7eb73fe6bc95ac210510e22394ca0ae227b69.1741128786.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit a3030fcba3c8f37a2a7a2cc3674c70ac1434f999 Author: Rob Clark Date: Fri Feb 28 13:31:24 2025 -0800 drm/msm/a6xx: Fix a6xx indexed-regs in devcoreduump [ Upstream commit 06dd5d86c6aef1c7609ca3a5ffa4097e475e2213 ] Somehow, possibly as a result of rebase gone badly, setting nr_indexed_regs for pre-a650 a6xx devices lost the setting of nr_indexed_regs, resulting in values getting snapshot, but omitted from the devcoredump. Fixes: e997ae5f45ca ("drm/msm/a6xx: Mostly implement A7xx gpu_state") Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/640289/ Signed-off-by: Sasha Levin commit f42a78df889406efa7721db65a3c289d6afd0f15 Author: Vitaliy Shevtsov Date: Thu Feb 27 01:28:51 2025 +0500 drm/amd/display: fix type mismatch in CalculateDynamicMetadataParameters() [ Upstream commit c3c584c18c90a024a54716229809ba36424f9660 ] There is a type mismatch between what CalculateDynamicMetadataParameters() takes and what is passed to it. Currently this function accepts several args as signed long but it's called with unsigned integers and integer. On some systems where long is 32 bits and one of these unsigned int params is greater than INT_MAX it may cause passing input params as negative values. Fix this by changing these argument types from long to unsigned int and to int respectively. Also this will align the function's definition with similar functions in other dcn* drivers. Found by Linux Verification Center (linuxtesting.org) with Svace. Fixes: 6725a88f88a7 ("drm/amd/display: Add DCN3 DML") Signed-off-by: Vitaliy Shevtsov Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b8b5e2e770838741a139f2459d7e32ff9d7cea8f Author: Ashley Smith Date: Mon Mar 3 18:04:32 2025 +0000 drm/panthor: Update CS_STATUS_ defines to correct values [ Upstream commit c82734fbdc50dc9e568e8686622eaa4498acb81e ] Values for SC_STATUS_BLOCKED_REASON_ are documented in the G610 "Odin" GPU specification (CS_STATUS_BLOCKED_REASON register). This change updates the defines to the correct values. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Signed-off-by: Ashley Smith Reviewed-by: Liviu Dudau Reviewed-by: Adrián Larumbe Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20250303180444.3768993-1-ashley.smith@collabora.com Signed-off-by: Sasha Levin commit bcb48420044154abb983ea131acf5e47a1847587 Author: Nishanth Aravamudan Date: Fri Feb 7 14:56:00 2025 -0600 PCI: Avoid reset when disabled via sysfs [ Upstream commit 479380efe1625e251008d24b2810283db60d6fcd ] After d88f521da3ef ("PCI: Allow userspace to query and set device reset mechanism"), userspace can disable reset of specific PCI devices by writing an empty string to the sysfs reset_method file. However, pci_slot_resettable() does not check pci_reset_supported(), which means that pci_reset_function() will still reset the device even if userspace has disabled all the reset methods. I was able to reproduce this issue with a vfio device passed to a qemu guest, where I had disabled PCI reset via sysfs. Add an explicit check of pci_reset_supported() in both pci_slot_resettable() and pci_bus_resettable() to ensure both the reset status and reset execution are bypassed if an administrator disables it for a device. Link: https://lore.kernel.org/r/20250207205600.1846178-1-naravamudan@nvidia.com Fixes: d88f521da3ef ("PCI: Allow userspace to query and set device reset mechanism") Signed-off-by: Nishanth Aravamudan [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Cc: Alex Williamson Cc: Raphael Norwitz Cc: Amey Narkhede Cc: Jason Gunthorpe Cc: Yishai Hadas Cc: Shameer Kolothum Cc: Kevin Tian Signed-off-by: Sasha Levin commit 2a54a1a9c6c94eedd977f064742352c21b2d43fd Author: Feng Tang Date: Mon Mar 3 10:36:30 2025 +0800 PCI/portdrv: Only disable pciehp interrupts early when needed [ Upstream commit 9d7db4db19827380e225914618c0c1bf435ed2f5 ] Firmware developers reported that Linux issues two PCIe hotplug commands in very short intervals on an ARM server, which doesn't comply with the PCIe spec. According to PCIe r6.1, sec 6.7.3.2, if the Command Completed event is supported, software must wait for a command to complete or wait at least 1 second before sending a new command. In the failure case, the first PCIe hotplug command is from get_port_device_capability(), which sends a command to disable PCIe hotplug interrupts without waiting for its completion, and the second command comes from pcie_enable_notification() of pciehp driver, which enables hotplug interrupts again. Fix this by only disabling the hotplug interrupts when the pciehp driver is not enabled. Link: https://lore.kernel.org/r/20250303023630.78397-1-feng.tang@linux.alibaba.com Fixes: 2bd50dd800b5 ("PCI: PCIe: Disable PCIe port services during port initialization") Suggested-by: Lukas Wunner Signed-off-by: Feng Tang [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Reviewed-by: Kuppuswamy Sathyanarayanan Signed-off-by: Sasha Levin commit 2cf276e501c48b72ea0ee575def9f5586b0f47cc Author: Jim Quinlan Date: Fri Feb 14 12:39:33 2025 -0500 PCI: brcmstb: Fix potential premature regulator disabling [ Upstream commit b7de1b60ecab2f7b6f05d8116e93228a0bbb8563 ] The platform supports enabling and disabling regulators only on ports below the Root Complex. Thus, we need to verify this both when adding and removing the bus, otherwise regulators may be disabled prematurely when a bus further down the topology is removed. Fixes: 9e6be018b263 ("PCI: brcmstb: Enable child bus device regulators from DT") Signed-off-by: Jim Quinlan Reviewed-by: Florian Fainelli Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250214173944.47506-6-james.quinlan@broadcom.com [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit df63321a40cc98e52313cffbff376b8ae9ceffa7 Author: Jim Quinlan Date: Fri Feb 14 12:39:32 2025 -0500 PCI: brcmstb: Fix error path after a call to regulator_bulk_get() [ Upstream commit 3651ad5249c51cf7eee078e12612557040a6bdb4 ] If the regulator_bulk_get() returns an error and no regulators are created, we need to set their number to zero. If we don't do this and the PCIe link up fails, a call to the regulator_bulk_free() will result in a kernel panic. While at it, print the error value, as we cannot return an error upwards as the kernel will WARN() on an error from add_bus(). Fixes: 9e6be018b263 ("PCI: brcmstb: Enable child bus device regulators from DT") Signed-off-by: Jim Quinlan Reviewed-by: Florian Fainelli Link: https://lore.kernel.org/r/20250214173944.47506-5-james.quinlan@broadcom.com [kwilczynski: commit log, use comma in the message to match style with other similar messages] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 0fe63272c43ccb8f10e58d7b6a2c48cf0a0711b3 Author: Jim Quinlan Date: Fri Feb 14 12:39:30 2025 -0500 PCI: brcmstb: Use internal register to change link capability [ Upstream commit 0c97321e11e0e9e18546f828492758f6aaecec59 ] The driver has been mistakenly writing to a read-only (RO) configuration space register (PCI_EXP_LNKCAP) to change the PCIe link capability. Although harmless in this case, the proper write destination is an internal register that is reflected by PCI_EXP_LNKCAP. Thus, fix the brcm_pcie_set_gen() function to correctly update the link capability. Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver") Signed-off-by: Jim Quinlan Reviewed-by: Florian Fainelli Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250214173944.47506-3-james.quinlan@broadcom.com [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 4557922dbfcafc829b9c3a25495ea6d20bc120f0 Author: Jim Quinlan Date: Fri Feb 14 12:39:29 2025 -0500 PCI: brcmstb: Set generation limit before PCIe link up [ Upstream commit 72d36589c6b7bef6b30eb99fcb7082f72faca37f ] When the user elects to limit the PCIe generation via the appropriate devicetree property, apply the settings before the PCIe link up, not after. Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver") Signed-off-by: Jim Quinlan Reviewed-by: Florian Fainelli Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250214173944.47506-2-james.quinlan@broadcom.com [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit b23b73ea4c214ea91e1fef9b837295fcda7f15f4 Author: Hans Zhang <18255117159@163.com> Date: Sat Feb 15 00:57:24 2025 +0800 PCI: cadence-ep: Fix the driver to send MSG TLP for INTx without data payload [ Upstream commit 3ac47fbf4f6e8c3a7c3855fac68cc3246f90f850 ] Per the Cadence's "PCIe Controller IP for AX14" user guide, Version 1.04, Section 9.1.7.1, "AXI Subordinate to PCIe Address Translation Registers", Table 9.4, the bit 16 of the AXI Subordinate Address (axi_s_awaddr) when set corresponds to MSG with data, and when not set, to MSG without data. However, the driver is currently doing the opposite and due to this, the INTx is never received on the host. So, fix the driver to reflect the documentation and also make INTx work. Fixes: 37dddf14f1ae ("PCI: cadence: Add EndPoint Controller driver for Cadence PCIe controller") Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Hans Zhang Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250214165724.184599-1-18255117159@163.com [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit c0ef1c8ef70bfa3487ea84f794d7a1f0fea0735d Author: Srinivasan Shanmugam Date: Mon Feb 24 13:46:32 2025 +0530 drm/amdkfd: Fix Circular Locking Dependency in 'svm_range_cpu_invalidate_pagetables' [ Upstream commit fddc45026311c05a5355fd34b9dc0a1d7eaef4a2 ] This commit addresses a circular locking dependency in the svm_range_cpu_invalidate_pagetables function. The function previously held a lock while determining whether to perform an unmap or eviction operation, which could lead to deadlocks. Fixes the below: [ 223.418794] ====================================================== [ 223.418820] WARNING: possible circular locking dependency detected [ 223.418845] 6.12.0-amdstaging-drm-next-lol-050225 #14 Tainted: G U OE [ 223.418869] ------------------------------------------------------ [ 223.418889] kfdtest/3939 is trying to acquire lock: [ 223.418906] ffff8957552eae38 (&dqm->lock_hidden){+.+.}-{3:3}, at: evict_process_queues_cpsch+0x43/0x210 [amdgpu] [ 223.419302] but task is already holding lock: [ 223.419303] ffff8957556b83b0 (&prange->lock){+.+.}-{3:3}, at: svm_range_cpu_invalidate_pagetables+0x9d/0x850 [amdgpu] [ 223.419447] Console: switching to colour dummy device 80x25 [ 223.419477] [IGT] amd_basic: executing [ 223.419599] which lock already depends on the new lock. [ 223.419611] the existing dependency chain (in reverse order) is: [ 223.419621] -> #2 (&prange->lock){+.+.}-{3:3}: [ 223.419636] __mutex_lock+0x85/0xe20 [ 223.419647] mutex_lock_nested+0x1b/0x30 [ 223.419656] svm_range_validate_and_map+0x2f1/0x15b0 [amdgpu] [ 223.419954] svm_range_set_attr+0xe8c/0x1710 [amdgpu] [ 223.420236] svm_ioctl+0x46/0x50 [amdgpu] [ 223.420503] kfd_ioctl_svm+0x50/0x90 [amdgpu] [ 223.420763] kfd_ioctl+0x409/0x6d0 [amdgpu] [ 223.421024] __x64_sys_ioctl+0x95/0xd0 [ 223.421036] x64_sys_call+0x1205/0x20d0 [ 223.421047] do_syscall_64+0x87/0x140 [ 223.421056] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 223.421068] -> #1 (reservation_ww_class_mutex){+.+.}-{3:3}: [ 223.421084] __ww_mutex_lock.constprop.0+0xab/0x1560 [ 223.421095] ww_mutex_lock+0x2b/0x90 [ 223.421103] amdgpu_amdkfd_alloc_gtt_mem+0xcc/0x2b0 [amdgpu] [ 223.421361] add_queue_mes+0x3bc/0x440 [amdgpu] [ 223.421623] unhalt_cpsch+0x1ae/0x240 [amdgpu] [ 223.421888] kgd2kfd_start_sched+0x5e/0xd0 [amdgpu] [ 223.422148] amdgpu_amdkfd_start_sched+0x3d/0x50 [amdgpu] [ 223.422414] amdgpu_gfx_enforce_isolation_handler+0x132/0x270 [amdgpu] [ 223.422662] process_one_work+0x21e/0x680 [ 223.422673] worker_thread+0x190/0x330 [ 223.422682] kthread+0xe7/0x120 [ 223.422690] ret_from_fork+0x3c/0x60 [ 223.422699] ret_from_fork_asm+0x1a/0x30 [ 223.422708] -> #0 (&dqm->lock_hidden){+.+.}-{3:3}: [ 223.422723] __lock_acquire+0x16f4/0x2810 [ 223.422734] lock_acquire+0xd1/0x300 [ 223.422742] __mutex_lock+0x85/0xe20 [ 223.422751] mutex_lock_nested+0x1b/0x30 [ 223.422760] evict_process_queues_cpsch+0x43/0x210 [amdgpu] [ 223.423025] kfd_process_evict_queues+0x8a/0x1d0 [amdgpu] [ 223.423285] kgd2kfd_quiesce_mm+0x43/0x90 [amdgpu] [ 223.423540] svm_range_cpu_invalidate_pagetables+0x4a7/0x850 [amdgpu] [ 223.423807] __mmu_notifier_invalidate_range_start+0x1f5/0x250 [ 223.423819] copy_page_range+0x1e94/0x1ea0 [ 223.423829] copy_process+0x172f/0x2ad0 [ 223.423839] kernel_clone+0x9c/0x3f0 [ 223.423847] __do_sys_clone+0x66/0x90 [ 223.423856] __x64_sys_clone+0x25/0x30 [ 223.423864] x64_sys_call+0x1d7c/0x20d0 [ 223.423872] do_syscall_64+0x87/0x140 [ 223.423880] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 223.423891] other info that might help us debug this: [ 223.423903] Chain exists of: &dqm->lock_hidden --> reservation_ww_class_mutex --> &prange->lock [ 223.423926] Possible unsafe locking scenario: [ 223.423935] CPU0 CPU1 [ 223.423942] ---- ---- [ 223.423949] lock(&prange->lock); [ 223.423958] lock(reservation_ww_class_mutex); [ 223.423970] lock(&prange->lock); [ 223.423981] lock(&dqm->lock_hidden); [ 223.423990] *** DEADLOCK *** [ 223.423999] 5 locks held by kfdtest/3939: [ 223.424006] #0: ffffffffb82b4fc0 (dup_mmap_sem){.+.+}-{0:0}, at: copy_process+0x1387/0x2ad0 [ 223.424026] #1: ffff89575eda81b0 (&mm->mmap_lock){++++}-{3:3}, at: copy_process+0x13a8/0x2ad0 [ 223.424046] #2: ffff89575edaf3b0 (&mm->mmap_lock/1){+.+.}-{3:3}, at: copy_process+0x13e4/0x2ad0 [ 223.424066] #3: ffffffffb82e76e0 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: copy_page_range+0x1cea/0x1ea0 [ 223.424088] #4: ffff8957556b83b0 (&prange->lock){+.+.}-{3:3}, at: svm_range_cpu_invalidate_pagetables+0x9d/0x850 [amdgpu] [ 223.424365] stack backtrace: [ 223.424374] CPU: 0 UID: 0 PID: 3939 Comm: kfdtest Tainted: G U OE 6.12.0-amdstaging-drm-next-lol-050225 #14 [ 223.424392] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 223.424401] Hardware name: Gigabyte Technology Co., Ltd. X570 AORUS PRO WIFI/X570 AORUS PRO WIFI, BIOS F36a 02/16/2022 [ 223.424416] Call Trace: [ 223.424423] [ 223.424430] dump_stack_lvl+0x9b/0xf0 [ 223.424441] dump_stack+0x10/0x20 [ 223.424449] print_circular_bug+0x275/0x350 [ 223.424460] check_noncircular+0x157/0x170 [ 223.424469] ? __bfs+0xfd/0x2c0 [ 223.424481] __lock_acquire+0x16f4/0x2810 [ 223.424490] ? srso_return_thunk+0x5/0x5f [ 223.424505] lock_acquire+0xd1/0x300 [ 223.424514] ? evict_process_queues_cpsch+0x43/0x210 [amdgpu] [ 223.424783] __mutex_lock+0x85/0xe20 [ 223.424792] ? evict_process_queues_cpsch+0x43/0x210 [amdgpu] [ 223.425058] ? srso_return_thunk+0x5/0x5f [ 223.425067] ? mark_held_locks+0x54/0x90 [ 223.425076] ? evict_process_queues_cpsch+0x43/0x210 [amdgpu] [ 223.425339] ? srso_return_thunk+0x5/0x5f [ 223.425350] mutex_lock_nested+0x1b/0x30 [ 223.425358] ? mutex_lock_nested+0x1b/0x30 [ 223.425367] evict_process_queues_cpsch+0x43/0x210 [amdgpu] [ 223.425631] kfd_process_evict_queues+0x8a/0x1d0 [amdgpu] [ 223.425893] kgd2kfd_quiesce_mm+0x43/0x90 [amdgpu] [ 223.426156] svm_range_cpu_invalidate_pagetables+0x4a7/0x850 [amdgpu] [ 223.426423] ? srso_return_thunk+0x5/0x5f [ 223.426436] __mmu_notifier_invalidate_range_start+0x1f5/0x250 [ 223.426450] copy_page_range+0x1e94/0x1ea0 [ 223.426461] ? srso_return_thunk+0x5/0x5f [ 223.426474] ? srso_return_thunk+0x5/0x5f [ 223.426484] ? lock_acquire+0xd1/0x300 [ 223.426494] ? copy_process+0x1718/0x2ad0 [ 223.426502] ? srso_return_thunk+0x5/0x5f [ 223.426510] ? sched_clock_noinstr+0x9/0x10 [ 223.426519] ? local_clock_noinstr+0xe/0xc0 [ 223.426528] ? copy_process+0x1718/0x2ad0 [ 223.426537] ? srso_return_thunk+0x5/0x5f [ 223.426550] copy_process+0x172f/0x2ad0 [ 223.426569] kernel_clone+0x9c/0x3f0 [ 223.426577] ? __schedule+0x4c9/0x1b00 [ 223.426586] ? srso_return_thunk+0x5/0x5f [ 223.426594] ? sched_clock_noinstr+0x9/0x10 [ 223.426602] ? srso_return_thunk+0x5/0x5f [ 223.426610] ? local_clock_noinstr+0xe/0xc0 [ 223.426619] ? schedule+0x107/0x1a0 [ 223.426629] __do_sys_clone+0x66/0x90 [ 223.426643] __x64_sys_clone+0x25/0x30 [ 223.426652] x64_sys_call+0x1d7c/0x20d0 [ 223.426661] do_syscall_64+0x87/0x140 [ 223.426671] ? srso_return_thunk+0x5/0x5f [ 223.426679] ? common_nsleep+0x44/0x50 [ 223.426690] ? srso_return_thunk+0x5/0x5f [ 223.426698] ? trace_hardirqs_off+0x52/0xd0 [ 223.426709] ? srso_return_thunk+0x5/0x5f [ 223.426717] ? syscall_exit_to_user_mode+0xcc/0x200 [ 223.426727] ? srso_return_thunk+0x5/0x5f [ 223.426736] ? do_syscall_64+0x93/0x140 [ 223.426748] ? srso_return_thunk+0x5/0x5f [ 223.426756] ? up_write+0x1c/0x1e0 [ 223.426765] ? srso_return_thunk+0x5/0x5f [ 223.426775] ? srso_return_thunk+0x5/0x5f [ 223.426783] ? trace_hardirqs_off+0x52/0xd0 [ 223.426792] ? srso_return_thunk+0x5/0x5f [ 223.426800] ? syscall_exit_to_user_mode+0xcc/0x200 [ 223.426810] ? srso_return_thunk+0x5/0x5f [ 223.426818] ? do_syscall_64+0x93/0x140 [ 223.426826] ? syscall_exit_to_user_mode+0xcc/0x200 [ 223.426836] ? srso_return_thunk+0x5/0x5f [ 223.426844] ? do_syscall_64+0x93/0x140 [ 223.426853] ? srso_return_thunk+0x5/0x5f [ 223.426861] ? irqentry_exit+0x6b/0x90 [ 223.426869] ? srso_return_thunk+0x5/0x5f [ 223.426877] ? exc_page_fault+0xa7/0x2c0 [ 223.426888] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 223.426898] RIP: 0033:0x7f46758eab57 [ 223.426906] Code: ba 04 00 f3 0f 1e fa 64 48 8b 04 25 10 00 00 00 45 31 c0 31 d2 31 f6 bf 11 00 20 01 4c 8d 90 d0 02 00 00 b8 38 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 41 89 c0 85 c0 75 2c 64 48 8b 04 25 10 00 [ 223.426930] RSP: 002b:00007fff5c3e5188 EFLAGS: 00000246 ORIG_RAX: 0000000000000038 [ 223.426943] RAX: ffffffffffffffda RBX: 00007f4675f8c040 RCX: 00007f46758eab57 [ 223.426954] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000001200011 [ 223.426965] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 223.426975] R10: 00007f4675e81a50 R11: 0000000000000246 R12: 0000000000000001 [ 223.426986] R13: 00007fff5c3e5470 R14: 00007fff5c3e53e0 R15: 00007fff5c3e5410 [ 223.427004] v2: To resolve this issue, the allocation of the process context buffer (`proc_ctx_bo`) has been moved from the `add_queue_mes` function to the `pqm_create_queue` function. This change ensures that the buffer is allocated only when the first queue for a process is created and only if the Micro Engine Scheduler (MES) is enabled. (Felix) v3: Fix typo s/Memory Execution Scheduler (MES)/Micro Engine Scheduler in commit message. (Lijo) Fixes: 438b39ac74e2 ("drm/amdkfd: pause autosuspend when creating pdd") Cc: Jesse Zhang Cc: Yunxiang Li Cc: Philip Yang Cc: Alex Sierra Cc: Felix Kuehling Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 70f1dcc2177926c9876bafe4296e807d168a7ef6 Author: Marijn Suijten Date: Mon Feb 17 12:17:42 2025 +0100 drm/msm/dsi: Set PHY usescase (and mode) before registering DSI host [ Upstream commit 660c396c98c061f9696bebacc178b74072e80054 ] Ordering issues here cause an uninitialized (default STANDALONE) usecase to be programmed (which appears to be a MUX) in some cases when msm_dsi_host_register() is called, leading to the slave PLL in bonded-DSI mode to source from a clock parent (dsi1vco) that is off. This should seemingly not be a problem as the actual dispcc clocks from DSI1 that are muxed in the clock tree of DSI0 are way further down, this bit still seems to have an effect on them somehow and causes the right side of the panel controlled by DSI1 to not function. In an ideal world this code is refactored to no longer have such error-prone calls "across subsystems", and instead model the "PLL src" register field as a regular mux so that changing the clock parents programmatically or in DTS via `assigned-clock-parents` has the desired effect. But for the avid reader, the clocks that we *are* muxing into DSI0's tree are way further down, so if this bit turns out to be a simple mux between dsiXvco and out_div, that shouldn't have any effect as this whole tree is off anyway. Fixes: 57bf43389337 ("drm/msm/dsi: Pass down use case to PHY") Reviewed-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov Signed-off-by: Marijn Suijten Patchwork: https://patchwork.freedesktop.org/patch/637650/ Link: https://lore.kernel.org/r/20250217-drm-msm-initial-dualpipe-dsc-fixes-v3-2-913100d6103f@somainline.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 2af52e4d2e1970d744ad5f33a9a6d7ac260bb9fe Author: Marijn Suijten Date: Mon Feb 17 12:17:41 2025 +0100 drm/msm/dsi: Use existing per-interface slice count in DSC timing [ Upstream commit 14ad809ceb66d0874cbe4bd5ca9edf0de8d9ad96 ] When configuring the timing of DSI hosts (interfaces) in dsi_timing_setup() all values written to registers are taking bonded-mode into account by dividing the original mode width by 2 (half the data is sent over each of the two DSI hosts), but the full width instead of the interface width is passed as hdisplay parameter to dsi_update_dsc_timing(). Currently only msm_dsc_get_slices_per_intf() is called within dsi_update_dsc_timing() with the `hdisplay` argument which clearly documents that it wants the width of a single interface (which, again, in bonded DSI mode is half the total width of the mode) resulting in all subsequent values to be completely off. However, as soon as we start to pass the halved hdisplay into dsi_update_dsc_timing() we might as well discard msm_dsc_get_slices_per_intf() since the value it calculates is already available in dsc->slice_count which is per-interface by the current design of MSM DPU/DSI implementations and their use of the DRM DSC helpers. Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration") Reviewed-by: Dmitry Baryshkov Reviewed-by: Jessica Zhang Signed-off-by: Marijn Suijten Patchwork: https://patchwork.freedesktop.org/patch/637648/ Link: https://lore.kernel.org/r/20250217-drm-msm-initial-dualpipe-dsc-fixes-v3-1-913100d6103f@somainline.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit a47ee1884c5b6f13153f7871db223baeabf6407e Author: Krzysztof Kozlowski Date: Wed Jan 29 12:55:04 2025 +0100 drm/msm/dsi/phy: Program clock inverters in correct register [ Upstream commit baf49072877726616c7f5943a6b45eb86bfeca0a ] Since SM8250 all downstream sources program clock inverters in PLL_CLOCK_INVERTERS_1 register and leave the PLL_CLOCK_INVERTERS as reset value (0x0). The most recent Hardware Programming Guide for 3 nm, 4 nm, 5 nm and 7 nm PHYs also mention PLL_CLOCK_INVERTERS_1. Signed-off-by: Krzysztof Kozlowski Fixes: 1ef7c99d145c ("drm/msm/dsi: add support for 7nm DSI PHY/PLL") Reviewed-by: Dmitry Baryshkov Reported-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/634489/ Link: https://lore.kernel.org/r/20250129115504.40080-1-krzysztof.kozlowski@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 47a025046640157e1aa21150eb313517f2ab7241 Author: Dmitry Baryshkov Date: Thu Jan 23 14:43:33 2025 +0200 drm/msm/dpu: don't use active in atomic_check() [ Upstream commit 25b4614843bcc56ba150f7c99905125a019e656c ] The driver isn't supposed to consult crtc_state->active/active_check for resource allocation. Instead all resources should be allocated if crtc_state->enabled is set. Stop consulting active / active_changed in order to determine whether the hardware resources should be (re)allocated. Fixes: ccc862b957c6 ("drm/msm/dpu: Fix reservation failures in modeset") Reported-by: Simona Vetter Closes: https://lore.kernel.org/dri-devel/ZtW_S0j5AEr4g0QW@phenom.ffwll.local/ Reviewed-by: Simona Vetter Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/633393/ Link: https://lore.kernel.org/r/20250123-drm-dirty-modeset-v2-1-bbfd3a6cd1a4@linaro.org Signed-off-by: Sasha Levin commit a99219bbd69a2e9421e626f6b908d919a37b30e1 Author: Aurabindo Pillai Date: Fri Feb 21 09:45:12 2025 -0500 drm/amd/display: fix an indent issue in DML21 [ Upstream commit a1addcf8499a566496847f1e36e1cf0b4ad72a26 ] Remove extraneous tab and newline in dml2_core_dcn4.c that was reported by the bot Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202502211920.txUfwtSj-lkp@intel.com/ Fixes: 70839da6360 ("drm/amd/display: Add new DCN401 sources") Signed-off-by: Aurabindo Pillai Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8ba27aa51286a6b75b841eabb126293ca6c8dea3 Author: Tushar Dave Date: Thu Feb 6 19:03:38 2025 -0800 PCI/ACS: Fix 'pci=config_acs=' parameter [ Upstream commit 9cf8a952d57b422d3ff8a9a0163f8adf694f4b2b ] Commit 47c8846a49ba ("PCI: Extend ACS configurability") introduced bugs that fail to configure ACS ctrl to the value specified by the kernel parameter. Essentially there are two bugs: 1) When ACS is configured for multiple PCI devices using 'config_acs' kernel parameter, it results into error "PCI: Can't parse ACS command line parameter". This is due to a bug that doesn't preserve the ACS mask, but instead overwrites the mask with value 0. For example, using 'config_acs' to configure ACS ctrl for multiple BDFs fails: Kernel command line: pci=config_acs=1111011@0020:02:00.0;101xxxx@0039:00:00.0 "dyndbg=file drivers/pci/pci.c +p" PCI: Can't parse ACS command line parameter pci 0020:02:00.0: ACS mask = 0x007f pci 0020:02:00.0: ACS flags = 0x007b pci 0020:02:00.0: Configured ACS to 0x007b After this fix: Kernel command line: pci=config_acs=1111011@0020:02:00.0;101xxxx@0039:00:00.0 "dyndbg=file drivers/pci/pci.c +p" pci 0020:02:00.0: ACS mask = 0x007f pci 0020:02:00.0: ACS flags = 0x007b pci 0020:02:00.0: ACS control = 0x005f pci 0020:02:00.0: ACS fw_ctrl = 0x0053 pci 0020:02:00.0: Configured ACS to 0x007b pci 0039:00:00.0: ACS mask = 0x0070 pci 0039:00:00.0: ACS flags = 0x0050 pci 0039:00:00.0: ACS control = 0x001d pci 0039:00:00.0: ACS fw_ctrl = 0x0000 pci 0039:00:00.0: Configured ACS to 0x0050 2) In the bit manipulation logic, we copy the bit from the firmware settings when mask bit 0. For example, 'disable_acs_redir' fails to clear all three ACS P2P redir bits due to the wrong bit fiddling: Kernel command line: pci=disable_acs_redir=0020:02:00.0;0030:02:00.0;0039:00:00.0 "dyndbg=file drivers/pci/pci.c +p" pci 0020:02:00.0: ACS mask = 0x002c pci 0020:02:00.0: ACS flags = 0xffd3 pci 0020:02:00.0: Configured ACS to 0xfffb pci 0030:02:00.0: ACS mask = 0x002c pci 0030:02:00.0: ACS flags = 0xffd3 pci 0030:02:00.0: Configured ACS to 0xffdf pci 0039:00:00.0: ACS mask = 0x002c pci 0039:00:00.0: ACS flags = 0xffd3 pci 0039:00:00.0: Configured ACS to 0xffd3 After this fix: Kernel command line: pci=disable_acs_redir=0020:02:00.0;0030:02:00.0;0039:00:00.0 "dyndbg=file drivers/pci/pci.c +p" pci 0020:02:00.0: ACS mask = 0x002c pci 0020:02:00.0: ACS flags = 0xffd3 pci 0020:02:00.0: ACS control = 0x007f pci 0020:02:00.0: ACS fw_ctrl = 0x007b pci 0020:02:00.0: Configured ACS to 0x0053 pci 0030:02:00.0: ACS mask = 0x002c pci 0030:02:00.0: ACS flags = 0xffd3 pci 0030:02:00.0: ACS control = 0x005f pci 0030:02:00.0: ACS fw_ctrl = 0x005f pci 0030:02:00.0: Configured ACS to 0x0053 pci 0039:00:00.0: ACS mask = 0x002c pci 0039:00:00.0: ACS flags = 0xffd3 pci 0039:00:00.0: ACS control = 0x001d pci 0039:00:00.0: ACS fw_ctrl = 0x0000 pci 0039:00:00.0: Configured ACS to 0x0000 Link: https://lore.kernel.org/r/20250207030338.456887-1-tdave@nvidia.com Fixes: 47c8846a49ba ("PCI: Extend ACS configurability") Signed-off-by: Tushar Dave Signed-off-by: Bjorn Helgaas Reviewed-by: Jason Gunthorpe Reviewed-by: Kuppuswamy Sathyanarayanan Signed-off-by: Sasha Levin commit 91b0ab875128f9d20194a3d34919c2761a2c50e0 Author: John Keeping Date: Mon Feb 17 12:04:28 2025 +0000 drm/panel: ilitek-ili9882t: fix GPIO name in error message [ Upstream commit 4ce2c7e201c265df1c62a9190a98a98803208b8f ] This driver uses the enable-gpios property and it is confusing that the error message refers to reset-gpios. Use the correct name when the enable GPIO is not found. Fixes: e2450d32e5fb5 ("drm/panel: ili9882t: Break out as separate driver") Signed-off-by: John Keeping Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20250217120428.3779197-1-jkeeping@inmusicbrands.com Signed-off-by: Sasha Levin commit f556b6ba0ac5f8353287ce6ed761228f0b4fafb7 Author: Daniel Stodden Date: Sun Dec 22 19:39:08 2024 -0800 PCI/ASPM: Fix link state exit during switch upstream function removal [ Upstream commit cbf937dcadfd571a434f8074d057b32cd14fbea5 ] Before 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free"), we would free the ASPM link only after the last function on the bus pertaining to the given link was removed. That was too late. If function 0 is removed before sibling function, link->downstream would point to free'd memory after. After above change, we freed the ASPM parent link state upon any function removal on the bus pertaining to a given link. That is too early. If the link is to a PCIe switch with MFD on the upstream port, then removing functions other than 0 first would free a link which still remains parent_link to the remaining downstream ports. The resulting GPFs are especially frequent during hot-unplug, because pciehp removes devices on the link bus in reverse order. On that switch, function 0 is the virtual P2P bridge to the internal bus. Free exactly when function 0 is removed -- before the parent link is obsolete, but after all subordinate links are gone. Link: https://lore.kernel.org/r/e12898835f25234561c9d7de4435590d957b85d9.1734924854.git.dns@arista.com Fixes: 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free") Signed-off-by: Daniel Stodden Signed-off-by: Bjorn Helgaas [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 4f997843de7833b63ee62a3810546fa49bd17194 Author: AngeloGioacchino Del Regno Date: Mon Feb 17 16:48:12 2025 +0100 drm/mediatek: mtk_hdmi: Fix typo for aud_sampe_size member [ Upstream commit 72fcb88e7bbc053ed4fc74cebb0315b98a0f20c3 ] Rename member aud_sampe_size of struct hdmi_audio_param to aud_sample_size to fix a typo and enhance readability. This commit brings no functional changes. Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support") Reviewed-by: CK Hu Signed-off-by: AngeloGioacchino Del Regno Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20250217154836.108895-20-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 0fe9a58fa5d0cc141b31650ef05280031d11cdbb Author: AngeloGioacchino Del Regno Date: Mon Feb 17 16:48:10 2025 +0100 drm/mediatek: mtk_hdmi: Unregister audio platform device on failure [ Upstream commit 0be123cafc06eed0fd1227166a66e786434b0c50 ] The probe function of this driver may fail after registering the audio platform device: in that case, the state is not getting cleaned up, leaving this device registered. Adding up to the mix, should the probe function of this driver return a probe deferral for N times, we're registering up to N audio platform devices and, again, never freeing them up. To fix this, add a pointer to the audio platform device in the mtk_hdmi structure, and add a devm action to unregister it upon driver removal or probe failure. Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support") Reviewed-by: CK Hu Signed-off-by: AngeloGioacchino Del Regno Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20250217154836.108895-18-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 372e387c4f1c824aeb1893d4b76bb5c526535fa4 Author: Ilpo Järvinen Date: Mon Dec 16 19:56:08 2024 +0200 PCI: Remove add_align overwrite unrelated to size0 [ Upstream commit d06cc1e3809040e8250f69a4c656e3717e6b963c ] Commit 566f1dd52816 ("PCI: Relax bridge window tail sizing rules") relaxed bridge window tail alignment rule for the non-optional part (size0, no add_size/add_align). The change, however, also overwrote add_align, which is only related to case where optional size1 related entry is added into realloc head. Correct this by removing the add_align overwrite. Link: https://lore.kernel.org/r/20241216175632.4175-2-ilpo.jarvinen@linux.intel.com Fixes: 566f1dd52816 ("PCI: Relax bridge window tail sizing rules") Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Xiaochun Lee Signed-off-by: Sasha Levin commit 254f771c70678d4b2135140d3a8e65106713b57b Author: Kai-Heng Feng Date: Wed Dec 4 10:24:57 2024 +0800 PCI: Use downstream bridges for distributing resources [ Upstream commit 1a596ad00ffe9b37fc60a93cbdd4daead3bf95f3 ] 7180c1d08639 ("PCI: Distribute available resources for root buses, too") breaks BAR assignment on some devices: pci 0006:03:00.0: BAR 0 [mem 0x6300c0000000-0x6300c1ffffff 64bit pref]: assigned pci 0006:03:00.1: BAR 0 [mem 0x6300c2000000-0x6300c3ffffff 64bit pref]: assigned pci 0006:03:00.2: BAR 0 [mem size 0x00800000 64bit pref]: can't assign; no space pci 0006:03:00.0: VF BAR 0 [mem size 0x02000000 64bit pref]: can't assign; no space pci 0006:03:00.1: VF BAR 0 [mem size 0x02000000 64bit pref]: can't assign; no space The apertures of domain 0006 before 7180c1d08639: 6300c0000000-63ffffffffff : PCI Bus 0006:00 6300c0000000-6300c9ffffff : PCI Bus 0006:01 6300c0000000-6300c9ffffff : PCI Bus 0006:02 # 160MB 6300c0000000-6300c8ffffff : PCI Bus 0006:03 # 144MB 6300c0000000-6300c1ffffff : 0006:03:00.0 # 32MB 6300c2000000-6300c3ffffff : 0006:03:00.1 # 32MB 6300c4000000-6300c47fffff : 0006:03:00.2 # 8MB 6300c4800000-6300c67fffff : 0006:03:00.0 # 32MB 6300c6800000-6300c87fffff : 0006:03:00.1 # 32MB 6300c9000000-6300c9bfffff : PCI Bus 0006:04 # 12MB 6300c9000000-6300c9bfffff : PCI Bus 0006:05 # 12MB 6300c9000000-6300c91fffff : PCI Bus 0006:06 # 2MB 6300c9200000-6300c93fffff : PCI Bus 0006:07 # 2MB 6300c9400000-6300c95fffff : PCI Bus 0006:08 # 2MB 6300c9600000-6300c97fffff : PCI Bus 0006:09 # 2MB After 7180c1d08639: 6300c0000000-63ffffffffff : PCI Bus 0006:00 6300c0000000-6300c9ffffff : PCI Bus 0006:01 6300c0000000-6300c9ffffff : PCI Bus 0006:02 # 160MB 6300c0000000-6300c43fffff : PCI Bus 0006:03 # 68MB 6300c0000000-6300c1ffffff : 0006:03:00.0 # 32MB 6300c2000000-6300c3ffffff : 0006:03:00.1 # 32MB --- no space --- : 0006:03:00.2 # 8MB --- no space --- : 0006:03:00.0 # 32MB --- no space --- : 0006:03:00.1 # 32MB 6300c4400000-6300c4dfffff : PCI Bus 0006:04 # 10MB 6300c4400000-6300c4dfffff : PCI Bus 0006:05 # 10MB 6300c4400000-6300c45fffff : PCI Bus 0006:06 # 2MB 6300c4600000-6300c47fffff : PCI Bus 0006:07 # 2MB 6300c4800000-6300c49fffff : PCI Bus 0006:08 # 2MB 6300c4a00000-6300c4bfffff : PCI Bus 0006:09 # 2MB We can see that the window to 0006:03 gets shrunken too much and 0006:04 eats away the window for 0006:03:00.2. The offending commit distributes the upstream bridge's resources multiple times to every downstream bridge, hence makes the aperture smaller than desired because calculation of io_per_b, mmio_per_b and mmio_pref_per_b becomes incorrect. Instead, distribute downstream bridges' own resources to resolve the issue. Link: https://lore.kernel.org/r/20241204022457.51322-1-kaihengf@nvidia.com Fixes: 7180c1d08639 ("PCI: Distribute available resources for root buses, too") Link: https://bugzilla.kernel.org/show_bug.cgi?id=219540 Signed-off-by: Kai-Heng Feng Signed-off-by: Bjorn Helgaas Tested-by: Chia-Lin Kao (AceLan) Reviewed-by: Mika Westerberg Cc: Carol Soto Cc: Jonathan Cameron Cc: Chris Chiu Signed-off-by: Sasha Levin commit f2b099e945ee9961bf84120ccd770a982d68046a Author: Alex Deucher Date: Wed Feb 12 16:31:43 2025 -0500 drm/amdgpu/umsch: fix ucode check [ Upstream commit c917e39cbdcd9fff421184db6cc461cc58d52c17 ] Return an error if the IP version doesn't match otherwise we end up passing a NULL string to amdgpu_ucode_request. We should never hit this in practice today since we only enable the umsch code on the supported IP versions, but add a check to be safe. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202502130406.iWQ0eBug-lkp@intel.com/ Fixes: 020620424b27 ("drm/amd: Use a constant format string for amdgpu_ucode_request") Reviewed-by: Saleemkhan Jamadar Signed-off-by: Alex Deucher Cc: Arnd Bergmann Cc: Lang Yu Signed-off-by: Sasha Levin commit 2dbf9e3efcc0abacddd1f945717158242444d460 Author: Yang Wang Date: Wed Feb 5 15:46:42 2025 +0800 drm/amdgpu: refine smu send msg debug log format [ Upstream commit 8c6631234557515a7567c6251505a98e9793c8a6 ] remove unnecessary line breaks. [ 51.280860] amdgpu 0000:24:00.0: amdgpu: smu send message: GetEnabledSmuFeaturesHigh(13) param: 0x00000000, resp: 0x00000001, readval: 0x00003763 Fixes: 0cd2bc06de72 ("drm/amd/pm: enable amdgpu smu send message log") Signed-off-by: Yang Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2a07eab05d9d9fbd47d49523c86fb14aea848652 Author: Vitalii Mordan Date: Fri Feb 14 18:46:32 2025 +0300 gpu: cdns-mhdp8546: fix call balance of mhdp->clk handling routines [ Upstream commit f65727be3fa5f252c8d982d15023aab8255ded19 ] If the clock mhdp->clk was not enabled in cdns_mhdp_probe(), it should not be disabled in any path. The return value of clk_prepare_enable() is not checked. If mhdp->clk was not enabled, it may be disabled in the error path of cdns_mhdp_probe() (e.g., if cdns_mhdp_load_firmware() fails) or in cdns_mhdp_remove() after a successful cdns_mhdp_probe() call. Use the devm_clk_get_enabled() helper function to ensure proper call balance for mhdp->clk. Found by Linux Verification Center (linuxtesting.org) with Klever. Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge") Signed-off-by: Vitalii Mordan Reviewed-by: Dmitry Baryshkov Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20250214154632.1907425-1-mordan@ispras.ru Signed-off-by: Sasha Levin commit d5eb8e347905ab17788a7903fa1d3d06747355f5 Author: José Expósito Date: Wed Feb 12 09:49:12 2025 +0100 drm/vkms: Fix use after free and double free on init error [ Upstream commit ed15511a773df86205bda66c37193569575ae828 ] If the driver initialization fails, the vkms_exit() function might access an uninitialized or freed default_config pointer and it might double free it. Fix both possible errors by initializing default_config only when the driver initialization succeeded. Reported-by: Louis Chauvet Closes: https://lore.kernel.org/all/Z5uDHcCmAwiTsGte@louis-chauvet-laptop/ Fixes: 2df7af93fdad ("drm/vkms: Add vkms_config type") Signed-off-by: José Expósito Reviewed-by: Thomas Zimmermann Reviewed-by: Louis Chauvet Link: https://patchwork.freedesktop.org/patch/msgid/20250212084912.3196-1-jose.exposito89@gmail.com Signed-off-by: Louis Chauvet Signed-off-by: Sasha Levin commit b84d743c2393b33b2b327d9e0c198ff809dee80b Author: Tomi Valkeinen Date: Wed Jan 15 11:03:39 2025 +0200 drm: xlnx: zynqmp: Fix max dma segment size [ Upstream commit 28b529a98525123acd37372a04d21e87ec2edcf7 ] Fix "mapping sg segment longer than device claims to support" warning by setting the max segment size. Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem") Reviewed-by: Sean Anderson Tested-by: Sean Anderson Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20250115-xilinx-formats-v2-10-160327ca652a@ideasonboard.com Signed-off-by: Sasha Levin commit dd8e6445e4e33e0f363d614bd02a7e6195660bcc Author: Hermes Wu Date: Tue Jan 21 15:01:51 2025 +0800 drm/bridge: it6505: fix HDCP V match check is not performed correctly [ Upstream commit a5072fc77fb9e38fa9fd883642c83c3720049159 ] Fix a typo where V compare incorrectly compares av[] with av[] itself, which can result in HDCP failure. The loop of V compare is expected to iterate for 5 times which compare V array form av[0][] to av[4][]. It should check loop counter reach the last statement "i == 5" before return true Fixes: 0989c02c7a5c ("drm/bridge: it6505: fix HDCP CTS compare V matching") Signed-off-by: Hermes Wu Reviewed-by: Dmitry Baryshkov Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20250121-fix-hdcp-v-comp-v4-1-185f45c728dc@ite.com.tw Signed-off-by: Sasha Levin commit 69e90c1e33918877d3916a26b82febc13808d0da Author: Wayne Lin Date: Mon Jan 13 17:10:59 2025 +0800 drm/dp_mst: Fix drm RAD print [ Upstream commit 6bbce873a9c97cb12f5455c497be279ac58e707f ] [Why] The RAD of sideband message printed today is incorrect. For RAD stored within MST branch - If MST branch LCT is 1, it's RAD array is untouched and remained as 0. - If MST branch LCT is larger than 1, use nibble to store the up facing port number in cascaded sequence as illustrated below: u8 RAD[0] = (LCT_2_UFP << 4) | LCT_3_UFP RAD[1] = (LCT_4_UFP << 4) | LCT_5_UFP ... In drm_dp_mst_rad_to_str(), it wrongly to use BIT_MASK(4) to fetch the port number of one nibble. [How] Adjust the code by: - RAD array items are valuable only for LCT >= 1. - Use 0xF as the mask to replace BIT_MASK(4) V2: - Document how RAD is constructed (Imre) V3: - Adjust the comment for rad[] so kdoc formats it properly (Lyude) Fixes: 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests") Cc: Imre Deak Cc: Ville Syrjälä Cc: Harry Wentland Cc: Lyude Paul Reviewed-by: Lyude Paul Signed-off-by: Wayne Lin Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20250113091100.3314533-2-Wayne.Lin@amd.com Signed-off-by: Sasha Levin commit 5ffb6b9a1a0409a2e4dc6a89b8d911c3cdc47ac9 Author: John Keeping Date: Wed Jan 15 11:01:38 2025 +0000 drm/ssd130x: ensure ssd132x pitch is correct [ Upstream commit 229adcffdb54b13332d2afd2dc5d203418d50908 ] The bounding rectangle is adjusted to ensure it aligns to SSD132X_SEGMENT_WIDTH, which may adjust the pitch. Calculate the pitch after aligning the left and right edge. Fixes: fdd591e00a9c ("drm/ssd130x: Add support for the SSD132x OLED controller family") Signed-off-by: John Keeping Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20250115110139.1672488-3-jkeeping@inmusicbrands.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Sasha Levin commit 5a3461ca54db8d9f337c9c6af4a415de28b4b595 Author: John Keeping Date: Wed Jan 15 11:01:37 2025 +0000 drm/ssd130x: fix ssd132x encoding [ Upstream commit 1e14484677c8e87548f5f0d4eb8800e408004404 ] The ssd132x buffer is encoded one pixel per nibble, with two pixels in each byte. When encoding an 8-bit greyscale input, take the top 4-bits as the value and ensure the two pixels are distinct and do not overwrite each other. Fixes: fdd591e00a9c ("drm/ssd130x: Add support for the SSD132x OLED controller family") Signed-off-by: John Keeping Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20250115110139.1672488-2-jkeeping@inmusicbrands.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Sasha Levin commit a9c4366566e6f8f4b434bd62ce940cfcb07d0a54 Author: Javier Martinez Canillas Date: Tue Dec 31 12:44:58 2024 +0100 drm/ssd130x: Set SPI .id_table to prevent an SPI core warning [ Upstream commit 5d40d4fae6f2fb789f48207a9d4772bbee970b5c ] The only reason for the ssd130x-spi driver to have an spi_device_id table is that the SPI core always reports an "spi:" MODALIAS, even when the SPI device has been registered via a Device Tree Blob. Without spi_device_id table information in the module's metadata, module autoloading would not work because there won't be an alias that matches the MODALIAS reported by the SPI core. This spi_device_id table is not needed for device matching though, since the of_device_id table is always used in this case. For this reason, the struct spi_driver .id_table member is currently not set in the SPI driver. Because the spi_device_id table is always required for module autoloading, the SPI core checks during driver registration that both an of_device_id table and a spi_device_id table are present and that they contain the same entries for all the SPI devices. Not setting the .id_table member in the driver then confuses the core and leads to the following warning when the ssd130x-spi driver is registered: [ 41.091198] SPI driver ssd130x-spi has no spi_device_id for sinowealth,sh1106 [ 41.098614] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1305 [ 41.105862] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1306 [ 41.113062] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1307 [ 41.120247] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1309 [ 41.127449] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1322 [ 41.134627] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1325 [ 41.141784] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1327 [ 41.149021] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1331 To prevent the warning, set the .id_table even though it's not necessary. Since the check is done even for built-in drivers, drop the condition to only define the ID table when the driver is built as a module. Finally, rename the variable to use the "_spi_id" convention used for ID tables. Fixes: 74373977d2ca ("drm/solomon: Add SSD130x OLED displays SPI support") Reviewed-by: Dmitry Baryshkov Link: https://patchwork.freedesktop.org/patch/msgid/20241231114516.2063201-1-javierm@redhat.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Sasha Levin commit 950513eba9cb278c9edbfda5852b72bad1776499 Author: Geert Uytterhoeven Date: Tue Dec 10 15:18:46 2024 +0100 drm/bridge: ti-sn65dsi86: Fix multiple instances [ Upstream commit 574f5ee2c85a00a579549d50e9fc9c6c072ee4c4 ] Each bridge instance creates up to four auxiliary devices with different names. However, their IDs are always zero, causing duplicate filename errors when a system has multiple bridges: sysfs: cannot create duplicate filename '/bus/auxiliary/devices/ti_sn65dsi86.gpio.0' Fix this by using a unique instance ID per bridge instance. The instance ID is derived from the I2C adapter number and the bridge's I2C address, to support multiple instances on the same bus. Fixes: bf73537f411b ("drm/bridge: ti-sn65dsi86: Break GPIO and MIPI-to-eDP bridge into sub-drivers") Signed-off-by: Geert Uytterhoeven Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/7a68a0e3f927e26edca6040067fb653eb06efb79.1733840089.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 15291b561d8cc835a2eea76b394070cf8e072771 Author: Takashi Iwai Date: Fri Mar 21 18:26:52 2025 +0100 ALSA: timer: Don't take register_mutex with copy_from/to_user() [ Upstream commit 3424c8f53bc63c87712a7fc22dc13d0cc85fb0d6 ] The infamous mmap_lock taken in copy_from/to_user() can be often problematic when it's called inside another mutex, as they might lead to deadlocks. In the case of ALSA timer code, the bad pattern is with guard(mutex)(®ister_mutex) that covers copy_from/to_user() -- which was mistakenly introduced at converting to guard(), and it had been carefully worked around in the past. This patch fixes those pieces simply by moving copy_from/to_user() out of the register mutex lock again. Fixes: 3923de04c817 ("ALSA: pcm: oss: Use guard() for setup") Reported-by: syzbot+2b96f44164236dda0f3b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/67dd86c8.050a0220.25ae54.0059.GAE@google.com Link: https://patch.msgid.link/20250321172653.14310-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 11242f4b9baab6f856c2703ce777b1bf1c8bfe09 Author: Jayesh Choudhary Date: Tue Mar 18 17:05:24 2025 +0530 ASoC: ti: j721e-evm: Fix clock configuration for ti,j7200-cpb-audio compatible [ Upstream commit 45ff65e30deb919604e68faed156ad96ce7474d9 ] For 'ti,j7200-cpb-audio' compatible, there is support for only one PLL for 48k. For 11025, 22050, 44100 and 88200 sampling rates, due to absence of J721E_CLK_PARENT_44100, we get EINVAL while running any audio application. Add support for these rates by using the 48k parent clock and adjusting the clock for these rates later in j721e_configure_refclk. Fixes: 6748d0559059 ("ASoC: ti: Add custom machine driver for j721e EVM (CPB and IVI)") Signed-off-by: Jayesh Choudhary Link: https://patch.msgid.link/20250318113524.57100-1-j-choudhary@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f751361b3a15480978df3383ea54c95fc108ea96 Author: Takashi Iwai Date: Sat Mar 15 15:30:19 2025 +0100 ALSA: hda/realtek: Always honor no_shutup_pins [ Upstream commit 5a0c72c1da3cbc0cd4940a95d1be2830104c6edf ] The workaround for Dell machines to skip the pin-shutup for mic pins introduced alc_headset_mic_no_shutup() that is replaced from the generic snd_hda_shutup_pins() for certain codecs. The problem is that the call is done unconditionally even if spec->no_shutup_pins is set. This seems causing problems on other platforms like Lenovo. This patch corrects the behavior and the driver honors always spec->no_shutup_pins flag and skips alc_headset_mic_no_shutup() if it's set. Fixes: dad3197da7a3 ("ALSA: hda/realtek - Fixup headphone noise via runtime suspend") Reported-and-tested-by: Oleg Gorobets Link: https://patch.msgid.link/20250315143020.27184-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2050247d5ebfdf9f25aaf05e12aed00750082cfc Author: Maud Spierings Date: Wed Feb 26 15:19:13 2025 +0100 dt-bindings: vendor-prefixes: add GOcontroll [ Upstream commit 5f0d2de417166698c8eba433b696037ce04730da ] GOcontroll produces embedded linux systems and IO modules to use in these systems, add its prefix. Acked-by: Rob Herring (Arm) Signed-off-by: Maud Spierings Link: https://patch.msgid.link/20250226-initial_display-v2-2-23fafa130817@gocontroll.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7fdca6c0b12c29525208d99ea5863f00c8da7970 Author: Jiri Kosina Date: Wed Mar 12 09:08:22 2025 +0100 HID: remove superfluous (and wrong) Makefile entry for CONFIG_INTEL_ISH_FIRMWARE_DOWNLOADER [ Upstream commit fe0fb58325e519008e2606a5aa2cff7ad23e212d ] The line obj-$(INTEL_ISH_FIRMWARE_DOWNLOADER) += intel-ish-hid/ in top-level HID Makefile is both superfluous (as CONFIG_INTEL_ISH_FIRMWARE_DOWNLOADER depends on CONFIG_INTEL_ISH_HID, which contains intel-ish-hid/ already) and wrong (as it's missing the CONFIG_ prefix). Just remove it. Fixes: 91b228107da3e ("HID: intel-ish-hid: ISH firmware loader client driver") Reported-by: Jiri Slaby Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit da3ac4cf7f1330f5907299ae8886fdacc905dfea Author: Venkata Prasad Potturu Date: Tue Mar 11 00:02:01 2025 +0530 ASoC: amd: acp: Fix for enabling DMIC on acp platforms via _DSD entry [ Upstream commit 02e1cf7a352a3ba5f768849f2b4fcaaaa19f89e3 ] Add condition check to register ACP PDM sound card by reading _WOV acpi entry. Fixes: 09068d624c49 ("ASoC: amd: acp: fix for acp platform device creation failure") Signed-off-by: Venkata Prasad Potturu Link: https://patch.msgid.link/20250310183201.11979-15-venkataprasad.potturu@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 748a1118d20d49744ed45d4ad6cbdbe9dae5b79f Author: Vitaliy Shevtsov Date: Tue Mar 4 16:56:37 2025 +0500 ASoC: cs35l41: check the return value from spi_setup() [ Upstream commit ad5a0970f86d82e39ebd06d45a1f7aa48a1316f8 ] Currently the return value from spi_setup() is not checked for a failure. It is unlikely it will ever fail in this particular case but it is still better to add this check for the sake of completeness and correctness. This is cheap since it is performed once when the device is being probed. Handle spi_setup() return value. Found by Linux Verification Center (linuxtesting.org) with Svace. Fixes: 872fc0b6bde8 ("ASoC: cs35l41: Set the max SPI speed for the whole device") Signed-off-by: Vitaliy Shevtsov Link: https://patch.msgid.link/20250304115643.2748-1-v.shevtsov@mt-integration.ru Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5b6739341500c8dff9bb0dd3b1a62498de9cc021 Author: Armin Wolf Date: Wed Mar 5 06:30:07 2025 +0100 platform/x86: dell-ddv: Fix temperature calculation [ Upstream commit 7a248294a3145bc65eb0d8980a0a8edbb1b92db4 ] On the Dell Inspiron 3505 the battery temperature is always 0.1 degrees larger than the temperature show inside the OEM application. Emulate this behaviour to avoid showing strange looking values like 29.1 degrees. Fixes: 0331b1b0ba653 ("platform/x86: dell-ddv: Fix temperature scaling") Signed-off-by: Armin Wolf Reviewed-by: Sebastian Reichel Link: https://lore.kernel.org/r/20250305053009.378609-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 0654ea13976cbb526f80956246e236c6a5340629 Author: Ilpo Järvinen Date: Tue Mar 4 18:06:39 2025 +0200 platform/x86: dell-uart-backlight: Make dell_uart_bl_serdev_driver static [ Upstream commit 4878e0b14c3e31a87ab147bd2dae443394cb5a2c ] Sparse reports: dell-uart-backlight.c:328:29: warning: symbol 'dell_uart_bl_serdev_driver' was not declared. Should it be static? Fix it by making the symbol static. Fixes: 484bae9e4d6ac ("platform/x86: Add new Dell UART backlight driver") Reviewed-by: Mario Limonciello Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20250304160639.4295-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen Reviewed-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit a4f38bc600f3dc6b4144a7907d6dd563ecdc65e6 Author: Ilpo Järvinen Date: Tue Mar 4 18:06:38 2025 +0200 platform/x86: lenovo-yoga-tab2-pro-1380-fastcharger: Make symbol static [ Upstream commit 886ca11a0c70efe5627a18557062e8a44370d78f ] Sparse reports: lenovo-yoga-tab2-pro-1380-fastcharger.c:222:29: warning: symbol 'yt2_1380_fc_serdev_driver' was not declared. Should it be static? Fix that by making the symbol static. Fixes: b2ed33e8d486a ("platform/x86: Add lenovo-yoga-tab2-pro-1380-fastcharger driver") Reviewed-by: Mario Limonciello Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20250304160639.4295-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen Reviewed-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 4f42478af663725db424ac60f9f81c68c8ba07b7 Author: Andy Shevchenko Date: Mon Feb 24 14:36:25 2025 +0200 auxdisplay: panel: Fix an API misuse in panel.c [ Upstream commit 72e1c440c848624ad4cfac93d69d8a999a20355b ] Variable allocated by charlcd_alloc() should be released by charlcd_free(). The following patch changed kfree() to charlcd_free() to fix an API misuse. Reviewed-by: Geert Uytterhoeven Fixes: 718e05ed92ec ("auxdisplay: Introduce hd44780_common.[ch]") Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit f0a72629ccecad4ecc3d60132d82f5098077b97a Author: Joe Hattori Date: Thu Dec 5 11:06:21 2024 +0900 media: platform: allgro-dvt: unregister v4l2_device on the error path [ Upstream commit c2b96a6818159fba8a3bcc38262da9e77f9b3ec7 ] In allegro_probe(), the v4l2 device is not unregistered in the error path, which results in a memory leak. Fix it by calling v4l2_device_unregister() before returning error. Fixes: d74d4e2359ec ("media: allegro: move driver out of staging") Signed-off-by: Joe Hattori Reviewed-by: Michael Tretter Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit d34100049923f4d15f93120004f5849703208f99 Author: Benjamin Gaignard Date: Mon Jan 20 09:10:52 2025 +0100 media: verisilicon: HEVC: Initialize start_bit field [ Upstream commit 7fcb42b3835e90ef18d68555934cf72adaf58402 ] The HEVC driver needs to set the start_bit field explicitly to avoid causing corrupted frames when the VP9 decoder is used in parallel. The reason for this problem is that the VP9 and the HEVC decoder share this register. Fixes: cb5dd5a0fa51 ("media: hantro: Introduce G2/HEVC decoder") Signed-off-by: Benjamin Gaignard Tested-by: Nicolas Dufresne Reviewed-by: Nicolas Dufresne Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e161533964de0dd6c85c9308893e39f7e9237cf8 Author: Geert Uytterhoeven Date: Thu Feb 20 08:48:42 2025 +0100 auxdisplay: MAX6959 should select BITREVERSE [ Upstream commit fce85f3da08b76c1b052f53a9f6f9c40a8a10660 ] If CONFIG_BITREVERSE is not enabled: max6959.c:(.text+0x92): undefined reference to `byte_rev_table' Fixes: a9bcd02fa42217c7 ("auxdisplay: Add driver for MAX695x 7-segment LED controllers") Reported-by: kernel test robot Closes: https://lore.kernel.org/202502161703.3Vr4M7qg-lkp@intel.com/ Signed-off-by: Geert Uytterhoeven Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit d026245063d20f7650b35578318a298693dd91bd Author: Frieder Schrempf Date: Wed Dec 18 16:27:28 2024 +0100 regulator: pca9450: Fix enable register for LDO5 [ Upstream commit f5aab0438ef17f01c5ecd25e61ae6a03f82a4586 ] The LDO5 regulator has two configuration registers, but only LDO5CTRL_L contains the bits for enabling/disabling the regulator. Fixes: 0935ff5f1f0a ("regulator: pca9450: add pca9450 pmic driver") Signed-off-by: Frieder Schrempf Reviewed-by: Marek Vasut Link: https://patch.msgid.link/20241218152842.97483-6-frieder@fris.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f5852872eb298943062ab6c1c68e39c041aa255b Author: Vitaly Kuznetsov Date: Tue Dec 10 16:16:50 2024 +0100 x86/entry: Add __init to ia32_emulation_override_cmdline() [ Upstream commit d55f31e29047f2f987286d55928ae75775111fe7 ] ia32_emulation_override_cmdline() is an early_param() arg and these are only needed at boot time. In fact, all other early_param() functions in arch/x86 seem to have '__init' annotation and ia32_emulation_override_cmdline() is the only exception. Fixes: a11e097504ac ("x86: Make IA32_EMULATION boot time configurable") Signed-off-by: Vitaly Kuznetsov Signed-off-by: Dave Hansen Signed-off-by: Ingo Molnar Reviewed-by: Nikolay Borisov Link: https://lore.kernel.org/all/20241210151650.1746022-1-vkuznets%40redhat.com Signed-off-by: Sasha Levin commit 52e513a8850c39d320a1d14cd9ecc44b9c0803ba Author: Chao Gao Date: Mon Mar 17 22:06:11 2025 +0800 x86/fpu/xstate: Fix inconsistencies in guest FPU xfeatures [ Upstream commit dda366083e5ff307a4a728757db874bbfe7550be ] Guest FPUs manage vCPU FPU states. They are allocated via fpu_alloc_guest_fpstate() and are resized in fpstate_realloc() when XFD features are enabled. Since the introduction of guest FPUs, there have been inconsistencies in the kernel buffer size and xfeatures: 1. fpu_alloc_guest_fpstate() uses fpu_user_cfg since its introduction. See: 69f6ed1d14c6 ("x86/fpu: Provide infrastructure for KVM FPU cleanup") 36487e6228c4 ("x86/fpu: Prepare guest FPU for dynamically enabled FPU features") 2. __fpstate_reset() references fpu_kernel_cfg to set storage attributes. 3. fpu->guest_perm uses fpu_kernel_cfg, affecting fpstate_realloc(). A recent commit in the tip:x86/fpu tree partially addressed the inconsistency between (1) and (3) by using fpu_kernel_cfg for size calculation in (1), but left fpu_guest->xfeatures and fpu_guest->perm still referencing fpu_user_cfg: https://lore.kernel.org/all/20250218141045.85201-1-stanspas@amazon.de/ 1937e18cc3cf ("x86/fpu: Fix guest FPU state buffer allocation size") The inconsistencies within fpu_alloc_guest_fpstate() and across the mentioned functions cause confusion. Fix them by using fpu_kernel_cfg consistently in fpu_alloc_guest_fpstate(), except for fields related to the UABI buffer. Referencing fpu_kernel_cfg won't impact functionalities, as: 1. fpu_guest->perm is overwritten shortly in fpu_init_guest_permissions() with fpstate->guest_perm, which already uses fpu_kernel_cfg. 2. fpu_guest->xfeatures is solely used to check if XFD features are enabled. Including supervisor xfeatures doesn't affect the check. Fixes: 36487e6228c4 ("x86/fpu: Prepare guest FPU for dynamically enabled FPU features") Suggested-by: Chang S. Bae Signed-off-by: Chao Gao Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Oleg Nesterov Cc: Dave Hansen Cc: Juergen Gross Cc: Stefano Stabellini Cc: Paolo Bonzini Cc: Vitaly Kuznetsov Cc: Sean Christopherson Cc: David Woodhouse Link: https://lore.kernel.org/r/20250317140613.1761633-1-chao.gao@intel.com Signed-off-by: Sasha Levin commit b8650059708969829c1050165b1ad3b47d64a26b Author: Josh Poimboeuf Date: Fri Mar 14 12:28:59 2025 -0700 x86/traps: Make exc_double_fault() consistently noreturn [ Upstream commit 8085fcd78c1a3dbdf2278732579009d41ce0bc4e ] The CONFIG_X86_ESPFIX64 version of exc_double_fault() can return to its caller, but the !CONFIG_X86_ESPFIX64 version never does. In the latter case the compiler and/or objtool may consider it to be implicitly noreturn. However, due to the currently inflexible way objtool detects noreturns, a function's noreturn status needs to be consistent across configs. The current workaround for this issue is to suppress unreachable warnings for exc_double_fault()'s callers. Unfortunately that can result in ORC coverage gaps and potentially worse issues like inert static calls and silently disabled CPU mitigations. Instead, prevent exc_double_fault() from ever being implicitly marked noreturn by forcing a return behind a never-taken conditional. Until a more integrated noreturn detection method exists, this is likely the least objectionable workaround. Fixes: 55eeab2a8a11 ("objtool: Ignore exc_double_fault() __noreturn warnings") Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Brendan Jackman Link: https://lore.kernel.org/r/d1f4026f8dc35d0de6cc61f2684e0cb6484009d1.1741975349.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit 5108828fecfc2036335bff974257237f915136cd Author: Tao Chen Date: Fri Mar 14 11:00:36 2025 +0800 perf/ring_buffer: Allow the EPOLLRDNORM flag for poll [ Upstream commit c96fff391c095c11dc87dab35be72dee7d217cde ] The poll man page says POLLRDNORM is equivalent to POLLIN. For poll(), it seems that if user sets pollfd with POLLRDNORM in userspace, perf_poll will not return until timeout even if perf_output_wakeup called, whereas POLLIN returns. Fixes: 76369139ceb9 ("perf: Split up buffer handling from core code") Signed-off-by: Tao Chen Signed-off-by: Ingo Molnar Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: "H. Peter Anvin" Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250314030036.2543180-1-chen.dylane@linux.dev Signed-off-by: Sasha Levin commit 345957c1cfb85fbbe6307f8862b62ca8c37ae683 Author: Sebastian Andrzej Siewior Date: Wed Feb 12 11:36:18 2025 +0100 lockdep: Don't disable interrupts on RT in disable_irq_nosync_lockdep.*() [ Upstream commit 87886b32d669abc11c7be95ef44099215e4f5788 ] disable_irq_nosync_lockdep() disables interrupts with lockdep enabled to avoid false positive reports by lockdep that a certain lock has not been acquired with disabled interrupts. The user of this macros expects that a lock can be acquried without disabling interrupts because the IRQ line triggering the interrupt is disabled. This triggers a warning on PREEMPT_RT because after disable_irq_nosync_lockdep.*() the following spinlock_t now is acquired with disabled interrupts. On PREEMPT_RT there is no difference between spin_lock() and spin_lock_irq() so avoiding disabling interrupts in this case works for the two remaining callers as of today. Don't disable interrupts on PREEMPT_RT in disable_irq_nosync_lockdep.*(). Closes: https://lore.kernel.org/760e34f9-6034-40e0-82a5-ee9becd24438@roeck-us.net Fixes: e8106b941ceab ("[PATCH] lockdep: core, add enable/disable_irq_irqsave/irqrestore() APIs") Reported-by: Guenter Roeck Suggested-by: "Steven Rostedt (Google)" Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Peter Zijlstra (Intel) Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/20250212103619.2560503-2-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit c3a4c91a409e60db66f881c075743b39a86d2bdb Author: Rafael J. Wysocki Date: Thu Mar 13 17:00:00 2025 +0100 PM: sleep: Fix handling devices with direct_complete set on errors [ Upstream commit 03f1444016b71feffa1dfb8a51f15ba592f94b13 ] When dpm_suspend() fails, some devices with power.direct_complete set may not have been handled by device_suspend() yet, so runtime PM has not been disabled for them yet even though power.direct_complete is set. Since device_resume() expects that runtime PM has been disabled for all devices with power.direct_complete set, it will attempt to reenable runtime PM for the devices that have not been processed by device_suspend() which does not make sense. Had those devices had runtime PM disabled before device_suspend() had run, device_resume() would have inadvertently enable runtime PM for them, but this is not expected to happen because it would require ->prepare() callbacks to return positive values for devices with runtime PM disabled, which would be invalid. In practice, this issue is most likely benign because pm_runtime_enable() will not allow the "disable depth" counter to underflow, but it causes a warning message to be printed for each affected device. To allow device_resume() to distinguish the "direct complete" devices that have been processed by device_suspend() from those which have not been handled by it, make device_suspend() set power.is_suspended for "direct complete" devices. Next, move the power.is_suspended check in device_resume() before the power.direct_complete check in it to make it skip the "direct complete" devices that have not been handled by device_suspend(). This change is based on a preliminary patch from Saravana Kannan. Fixes: aae4518b3124 ("PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily") Link: https://lore.kernel.org/linux-pm/20241114220921.2529905-2-saravanak@google.com/ Reported-by: Saravana Kannan Signed-off-by: Rafael J. Wysocki Reviewed-by: Saravana Kannan Link: https://patch.msgid.link/12627587.O9o76ZdvQC@rjwysocki.net Signed-off-by: Sasha Levin commit 953d28a4f459fcbde2d08f51aeca19d6b0f179f3 Author: Chenyuan Yang Date: Wed Mar 12 23:36:11 2025 -0500 thermal: int340x: Add NULL check for adev [ Upstream commit 2542a3f70e563a9e70e7ded314286535a3321bdb ] Not all devices have an ACPI companion fwnode, so adev might be NULL. This is similar to the commit cd2fd6eab480 ("platform/x86: int3472: Check for adev == NULL"). Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in int3402_thermal_probe(). Note, under the same directory, int3400_thermal_probe() has such a check. Fixes: 77e337c6e23e ("Thermal: introduce INT3402 thermal driver") Signed-off-by: Chenyuan Yang Acked-by: Uwe Kleine-König Link: https://patch.msgid.link/20250313043611.1212116-1-chenyuan0y@gmail.com [ rjw: Subject edit, added Fixes: ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit a8a1bcc27d4607227088d80483164289b5348293 Author: James Morse Date: Tue Mar 11 18:36:46 2025 +0000 x86/resctrl: Fix allocation of cleanest CLOSID on platforms with no monitors [ Upstream commit a121798ae669351ec0697c94f71c3a692b2a755b ] Commit 6eac36bb9eb0 ("x86/resctrl: Allocate the cleanest CLOSID by searching closid_num_dirty_rmid") added logic that causes resctrl to search for the CLOSID with the fewest dirty cache lines when creating a new control group, if requested by the arch code. This depends on the values read from the llc_occupancy counters. The logic is applicable to architectures where the CLOSID effectively forms part of the monitoring identifier and so do not allow complete freedom to choose an unused monitoring identifier for a given CLOSID. This support missed that some platforms may not have these counters. This causes a NULL pointer dereference when creating a new control group as the array was not allocated by dom_data_init(). As this feature isn't necessary on platforms that don't have cache occupancy monitors, add this to the check that occurs when a new control group is allocated. Fixes: 6eac36bb9eb0 ("x86/resctrl: Allocate the cleanest CLOSID by searching closid_num_dirty_rmid") Signed-off-by: James Morse Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Shaopeng Tan Reviewed-by: David Hildenbrand Reviewed-by: Reinette Chatre Reviewed-by: Tony Luck Reviewed-by: Fenghua Yu Reviewed-by: Babu Moger Tested-by: Carl Worth # arm64 Tested-by: Shaopeng Tan Tested-by: Peter Newman Tested-by: Amit Singh Tomar # arm64 Tested-by: Shanker Donthineni # arm64 Tested-by: Babu Moger Link: https://lore.kernel.org/r/20250311183715.16445-2-james.morse@arm.com Signed-off-by: Sasha Levin commit 385a0265295f544c9e046a1ae03fd7c9cbd81063 Author: Qiuxu Zhuo Date: Mon Mar 10 09:14:03 2025 +0800 EDAC/ie31200: Fix the error path order of ie31200_init() [ Upstream commit 231e341036d9988447e3b3345cf741a98139199e ] The error path order of ie31200_init() is incorrect, fix it. Fixes: 709ed1bcef12 ("EDAC/ie31200: Fallback if host bridge device is already initialized") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Tested-by: Gary Wang Link: https://lore.kernel.org/r/20250310011411.31685-4-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 4294e94f43c7c51b1259bc55c62f71f336ae9bb9 Author: Qiuxu Zhuo Date: Mon Mar 10 09:14:02 2025 +0800 EDAC/ie31200: Fix the DIMM size mask for several SoCs [ Upstream commit 3427befbbca6b19fe0e37f91d66ce5221de70bf1 ] The DIMM size mask for {Sky, Kaby, Coffee} Lake is not bits{7:0}, but bits{5:0}. Fix it. Fixes: 953dee9bbd24 ("EDAC, ie31200_edac: Add Skylake support") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Tested-by: Gary Wang Link: https://lore.kernel.org/r/20250310011411.31685-3-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 67d079c0f29eaebc0d8d4efdfac7a509237b2e29 Author: Qiuxu Zhuo Date: Mon Mar 10 09:14:01 2025 +0800 EDAC/ie31200: Fix the size of EDAC_MC_LAYER_CHIP_SELECT layer [ Upstream commit d59d844e319d97682c8de29b88d2d60922a683b3 ] The EDAC_MC_LAYER_CHIP_SELECT layer pertains to the rank, not the DIMM. Fix its size to reflect the number of ranks instead of the number of DIMMs. Also delete the unused macros IE31200_{DIMMS,RANKS}. Fixes: 7ee40b897d18 ("ie31200_edac: Introduce the driver") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Tested-by: Gary Wang Link: https://lore.kernel.org/r/20250310011411.31685-2-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 96b4f2e97408198d6ce7de52f245dc6cb59662f2 Author: Tim Schumacher Date: Fri Mar 7 10:56:43 2025 +0100 selinux: Chain up tool resolving errors in install_policy.sh [ Upstream commit 6ae0042f4d3f331e841495eb0a3d51598e593ec2 ] Subshell evaluations are not exempt from errexit, so if a command is not available, `which` will fail and exit the script as a whole. This causes the helpful error messages to not be printed if they are tacked on using a `$?` comparison. Resolve the issue by using chains of logical operators, which are not subject to the effects of errexit. Fixes: e37c1877ba5b1 ("scripts/selinux: modernize mdp") Signed-off-by: Tim Schumacher Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 864750968d71c2a2659515e51d8800762931a29b Author: Li Huafei Date: Tue Oct 22 03:30:03 2024 +0800 watchdog/hardlockup/perf: Fix perf_event memory leak [ Upstream commit d6834d9c990333bfa433bc1816e2417f268eebbe ] During stress-testing, we found a kmemleak report for perf_event: unreferenced object 0xff110001410a33e0 (size 1328): comm "kworker/4:11", pid 288, jiffies 4294916004 hex dump (first 32 bytes): b8 be c2 3b 02 00 11 ff 22 01 00 00 00 00 ad de ...;...."....... f0 33 0a 41 01 00 11 ff f0 33 0a 41 01 00 11 ff .3.A.....3.A.... backtrace (crc 24eb7b3a): [<00000000e211b653>] kmem_cache_alloc_node_noprof+0x269/0x2e0 [<000000009d0985fa>] perf_event_alloc+0x5f/0xcf0 [<00000000084ad4a2>] perf_event_create_kernel_counter+0x38/0x1b0 [<00000000fde96401>] hardlockup_detector_event_create+0x50/0xe0 [<0000000051183158>] watchdog_hardlockup_enable+0x17/0x70 [<00000000ac89727f>] softlockup_start_fn+0x15/0x40 ... Our stress test includes CPU online and offline cycles, and updating the watchdog configuration. After reading the code, I found that there may be a race between cleaning up perf_event after updating watchdog and disabling event when the CPU goes offline: CPU0 CPU1 CPU2 (update watchdog) (hotplug offline CPU1) ... _cpu_down(CPU1) cpus_read_lock() // waiting for cpu lock softlockup_start_all smp_call_on_cpu(CPU1) softlockup_start_fn ... watchdog_hardlockup_enable(CPU1) perf create E1 watchdog_ev[CPU1] = E1 cpus_read_unlock() cpus_write_lock() cpuhp_kick_ap_work(CPU1) cpuhp_thread_fun ... watchdog_hardlockup_disable(CPU1) watchdog_ev[CPU1] = NULL dead_event[CPU1] = E1 __lockup_detector_cleanup for each dead_events_mask release each dead_event /* * CPU1 has not been added to * dead_events_mask, then E1 * will not be released */ CPU1 -> dead_events_mask cpumask_clear(&dead_events_mask) // dead_events_mask is cleared, E1 is leaked In this case, the leaked perf_event E1 matches the perf_event leak reported by kmemleak. Due to the low probability of problem recurrence (only reported once), I added some hack delays in the code: static void __lockup_detector_reconfigure(void) { ... watchdog_hardlockup_start(); cpus_read_unlock(); + mdelay(100); /* * Must be called outside the cpus locked section to prevent * recursive locking in the perf code. ... } void watchdog_hardlockup_disable(unsigned int cpu) { ... perf_event_disable(event); this_cpu_write(watchdog_ev, NULL); this_cpu_write(dead_event, event); + mdelay(100); cpumask_set_cpu(smp_processor_id(), &dead_events_mask); atomic_dec(&watchdog_cpus); ... } void hardlockup_detector_perf_cleanup(void) { ... perf_event_release_kernel(event); per_cpu(dead_event, cpu) = NULL; } + mdelay(100); cpumask_clear(&dead_events_mask); } Then, simultaneously performing CPU on/off and switching watchdog, it is almost certain to reproduce this leak. The problem here is that releasing perf_event is not within the CPU hotplug read-write lock. Commit: 941154bd6937 ("watchdog/hardlockup/perf: Prevent CPU hotplug deadlock") introduced deferred release to solve the deadlock caused by calling get_online_cpus() when releasing perf_event. Later, commit: efe951d3de91 ("perf/x86: Fix perf,x86,cpuhp deadlock") removed the get_online_cpus() call on the perf_event release path to solve another deadlock problem. Therefore, it is now possible to move the release of perf_event back into the CPU hotplug read-write lock, and release the event immediately after disabling it. Fixes: 941154bd6937 ("watchdog/hardlockup/perf: Prevent CPU hotplug deadlock") Signed-off-by: Li Huafei Signed-off-by: Ingo Molnar Cc: Thomas Gleixner Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20241021193004.308303-1-lihuafei1@huawei.com Signed-off-by: Sasha Levin commit b471631fa19af227d4bcc95c8c3372ff8f34476f Author: Kees Cook Date: Tue Mar 4 14:56:11 2025 -0800 kunit/stackinit: Use fill byte different from Clang i386 pattern [ Upstream commit d985e4399adffb58e10b38dbb5479ef29d53cde6 ] The byte initialization values used with -ftrivial-auto-var-init=pattern (CONFIG_INIT_STACK_ALL_PATTERN=y) depends on the compiler, architecture, and byte position relative to struct member types. On i386 with Clang, this includes the 0xFF value, which means it looks like nothing changes between the leaf byte filling pass and the expected "stack wiping" pass of the stackinit test. Use the byte fill value of 0x99 instead, fixing the test for i386 Clang builds. Reported-by: ernsteiswuerfel Closes: https://github.com/ClangBuiltLinux/linux/issues/2071 Fixes: 8c30d32b1a32 ("lib/test_stackinit: Handle Clang auto-initialization pattern") Tested-by: Nathan Chancellor Link: https://lore.kernel.org/r/20250304225606.work.030-kees@kernel.org Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit ff435a627342fd98feedcf58bbc01f904bbac146 Author: Atish Patra Date: Mon Mar 3 14:53:06 2025 -0800 RISC-V: KVM: Disable the kernel perf counter during configure [ Upstream commit bbb622488749478955485765ddff9d56be4a7e4b ] The perf event should be marked disabled during the creation as it is not ready to be scheduled until there is SBI PMU start call or config matching is called with auto start. Otherwise, event add/start gets called during perf_event_create_kernel_counter function. It will be enabled and scheduled to run via perf_event_enable during either the above mentioned scenario. Fixes: 0cb74b65d2e5 ("RISC-V: KVM: Implement perf support without sampling") Reviewed-by: Andrew Jones Signed-off-by: Atish Patra Link: https://lore.kernel.org/r/20250303-kvm_pmu_improve-v2-1-41d177e45929@rivosinc.com Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit e2bda794d38112fec91941001ee53500ff6e9f96 Author: Aaron Kling Date: Wed Feb 26 12:51:59 2025 -0600 cpufreq: tegra194: Allow building for Tegra234 [ Upstream commit 4a1e3bf61fc78ad100018adb573355303915dca3 ] Support was added for Tegra234 in the referenced commit, but the Kconfig was not updated to allow building for the arch. Fixes: 273bc890a2a8 ("cpufreq: tegra194: Add support for Tegra234") Signed-off-by: Aaron Kling Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 31d5665172b38e54f6e38b91409cc98be64da896 Author: Rafael J. Wysocki Date: Thu Feb 27 11:53:50 2025 +0100 PM: sleep: Adjust check before setting power.must_resume [ Upstream commit eeb87d17aceab7803a5a5bcb6cf2817b745157cf ] The check before setting power.must_resume in device_suspend_noirq() does not take power.child_count into account, but it should do that, so use pm_runtime_need_not_resume() in it for this purpose and adjust the comment next to it accordingly. Fixes: 107d47b2b95e ("PM: sleep: core: Simplify the SMART_SUSPEND flag handling") Signed-off-by: Rafael J. Wysocki Reviewed-by: Ulf Hansson Link: https://patch.msgid.link/3353728.44csPzL39Z@rjwysocki.net Signed-off-by: Sasha Levin commit 4d28c2ab2af5d04c8ad4e5f761093a7c30349e98 Author: Peter Zijlstra Date: Mon Nov 4 14:39:10 2024 +0100 lockdep/mm: Fix might_fault() lockdep check of current->mm->mmap_lock [ Upstream commit a1b65f3f7c6f7f0a08a7dba8be458c6415236487 ] Turns out that this commit, about 10 years ago: 9ec23531fd48 ("sched/preempt, mm/fault: Trigger might_sleep() in might_fault() with disabled pagefaults") ... accidentally (and unnessecarily) put the lockdep part of __might_fault() under CONFIG_DEBUG_ATOMIC_SLEEP=y. This is potentially notable because large distributions such as Ubuntu are running with !CONFIG_DEBUG_ATOMIC_SLEEP. Restore the debug check. [ mingo: Update changelog. ] Fixes: 9ec23531fd48 ("sched/preempt, mm/fault: Trigger might_sleep() in might_fault() with disabled pagefaults") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: Linus Torvalds Cc: Andrew Morton Link: https://lore.kernel.org/r/20241104135517.536628371@infradead.org Signed-off-by: Sasha Levin commit 9807270d7399498cbf84cba930e43bf54e6c40e6 Author: Kevin Loughlin Date: Fri Nov 22 20:23:22 2024 +0000 x86/sev: Add missing RIP_REL_REF() invocations during sme_enable() [ Upstream commit 72dafb567760320f2de7447cd6e979bf9d4e5d17 ] The following commit: 1c811d403afd ("x86/sev: Fix position dependent variable references in startup code") introduced RIP_REL_REF() to force RIP-relative accesses to global variables, as needed to prevent crashes during early SEV/SME startup code. For completeness, RIP_REL_REF() should be used with additional variables during sme_enable(): https://lore.kernel.org/all/CAMj1kXHnA0fJu6zh634=fbJswp59kSRAbhW+ubDGj1+NYwZJ-Q@mail.gmail.com/ Access these vars with RIP_REL_REF() to prevent problem reoccurence. Fixes: 1c811d403afd ("x86/sev: Fix position dependent variable references in startup code") Signed-off-by: Kevin Loughlin Signed-off-by: Ingo Molnar Reviewed-by: Ard Biesheuvel Reviewed-by: Tom Lendacky Cc: Dave Hansen Link: https://lore.kernel.org/r/20241122202322.977678-1-kevinloughlin@google.com Signed-off-by: Sasha Levin commit 3e14d9a4eb74561757b1e0fdd8293d37b738f8b7 Author: Arnd Bergmann Date: Wed Feb 26 22:37:14 2025 +0100 x86/platform: Only allow CONFIG_EISA for 32-bit [ Upstream commit 976ba8da2f3c2f1e997f4f620da83ae65c0e3728 ] The CONFIG_EISA menu was cleaned up in 2018, but this inadvertently brought the option back on 64-bit machines: ISA remains guarded by a CONFIG_X86_32 check, but EISA no longer depends on ISA. The last Intel machines ith EISA support used a 82375EB PCI/EISA bridge from 1993 that could be paired with the 440FX chipset on early Pentium-II CPUs, long before the first x86-64 products. Fixes: 6630a8e50105 ("eisa: consolidate EISA Kconfig entry in drivers/eisa") Signed-off-by: Arnd Bergmann Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250226213714.4040853-11-arnd@kernel.org Signed-off-by: Sasha Levin commit a086e7cde50988025d268778373f49dfc6e0b66c Author: Benjamin Berg Date: Wed Feb 26 14:31:36 2025 +0100 x86/fpu: Avoid copying dynamic FP state from init_task in arch_dup_task_struct() [ Upstream commit 5d3b81d4d8520efe888536b6906dc10fd1a228a8 ] The init_task instance of struct task_struct is statically allocated and may not contain the full FP state for userspace. As such, limit the copy to the valid area of both init_task and 'dst' and ensure all memory is initialized. Note that the FP state is only needed for userspace, and as such it is entirely reasonable for init_task to not contain parts of it. Fixes: 5aaeb5c01c5b ("x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and use it on x86") Signed-off-by: Benjamin Berg Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: H. Peter Anvin Cc: Oleg Nesterov Link: https://lore.kernel.org/r/20250226133136.816901-1-benjamin@sipsolutions.net ---- v2: - Fix code if arch_task_struct_size < sizeof(init_task) by using memcpy_and_pad. Signed-off-by: Sasha Levin commit 568aa554e760b4b1fb6a7e9de586bb78a43b1e84 Author: Stanislav Spassov Date: Tue Feb 18 14:10:45 2025 +0000 x86/fpu: Fix guest FPU state buffer allocation size [ Upstream commit 1937e18cc3cf27e2b3ef70e8c161437051ab7608 ] Ongoing work on an optimization to batch-preallocate vCPU state buffers for KVM revealed a mismatch between the allocation sizes used in fpu_alloc_guest_fpstate() and fpstate_realloc(). While the former allocates a buffer sized to fit the default set of XSAVE features in UABI form (as per fpu_user_cfg), the latter uses its ksize argument derived (for the requested set of features) in the same way as the sizes found in fpu_kernel_cfg, i.e. using the compacted in-kernel representation. The correct size to use for guest FPU state should indeed be the kernel one as seen in fpstate_realloc(). The original issue likely went unnoticed through a combination of UABI size typically being larger than or equal to kernel size, and/or both amounting to the same number of allocated 4K pages. Fixes: 69f6ed1d14c6 ("x86/fpu: Provide infrastructure for KVM FPU cleanup") Signed-off-by: Stanislav Spassov Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250218141045.85201-1-stanspas@amazon.de Signed-off-by: Sasha Levin commit 2c27c9e1d18a586a7ae015cb205ae67d807e6531 Author: Qiuxu Zhuo Date: Fri Feb 14 08:27:28 2025 +0800 EDAC/{skx_common,i10nm}: Fix some missing error reports on Emerald Rapids [ Upstream commit d9207cf7760f5f5599e9ff7eb0fedf56821a1d59 ] When doing error injection to some memory DIMMs on certain Intel Emerald Rapids servers, the i10nm_edac missed error reports for some memory DIMMs. Certain BIOS configurations may hide some memory controllers, and the i10nm_edac doesn't enumerate these hidden memory controllers. However, the ADXL decodes memory errors using memory controller physical indices even if there are hidden memory controllers. Therefore, the memory controller physical indices reported by the ADXL may mismatch the logical indices enumerated by the i10nm_edac, resulting in missed error reports for some memory DIMMs. Fix this issue by creating a mapping table from memory controller physical indices (used by the ADXL) to logical indices (used by the i10nm_edac) and using it to convert the physical indices to the logical indices during the error handling process. Fixes: c545f5e41225 ("EDAC/i10nm: Skip the absent memory controllers") Reported-by: Kevin Chang Tested-by: Kevin Chang Reported-by: Thomas Chen Tested-by: Thomas Chen Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://lore.kernel.org/r/20250214002728.6287-1-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit f381c92ab4ec265cbdf253b93de8c1932999e829 Author: Jie Zhan Date: Thu Feb 13 11:55:10 2025 +0800 cpufreq: governor: Fix negative 'idle_time' handling in dbs_update() [ Upstream commit 3698dd6b139dc37b35a9ad83d9330c1f99666c02 ] We observed an issue that the CPU frequency can't raise up with a 100% CPU load when NOHZ is off and the 'conservative' governor is selected. 'idle_time' can be negative if it's obtained from get_cpu_idle_time_jiffy() when NOHZ is off. This was found and explained in commit 9485e4ca0b48 ("cpufreq: governor: Fix handling of special cases in dbs_update()"). However, commit 7592019634f8 ("cpufreq: governors: Fix long idle detection logic in load calculation") introduced a comparison between 'idle_time' and 'samling_rate' to detect a long idle interval. While 'idle_time' is converted to int before comparison, it's actually promoted to unsigned again when compared with an unsigned 'sampling_rate'. Hence, this leads to wrong idle interval detection when it's in fact 100% busy and sets policy_dbs->idle_periods to a very large value. 'conservative' adjusts the frequency to minimum because of the large 'idle_periods', such that the frequency can't raise up. 'Ondemand' doesn't use policy_dbs->idle_periods so it fortunately avoids the issue. Correct negative 'idle_time' to 0 before any use of it in dbs_update(). Fixes: 7592019634f8 ("cpufreq: governors: Fix long idle detection logic in load calculation") Signed-off-by: Jie Zhan Reviewed-by: Chen Yu Link: https://patch.msgid.link/20250213035510.2402076-1-zhanjie9@hisilicon.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b576c4834d5a36ea74ba1335220de96e19386141 Author: Tianchen Ding Date: Tue Feb 11 14:36:59 2025 +0800 sched/eevdf: Force propagating min_slice of cfs_rq when {en,de}queue tasks [ Upstream commit 563bc2161b94571ea425bbe2cf69fd38e24cdedf ] When a task is enqueued and its parent cgroup se is already on_rq, this parent cgroup se will not be enqueued again, and hence the root->min_slice leaves unchanged. The same issue happens when a task is dequeued and its parent cgroup se has other runnable entities, and the parent cgroup se will not be dequeued. Force propagating min_slice when se doesn't need to be enqueued or dequeued. Ensure the se hierarchy always get the latest min_slice. Fixes: aef6987d8954 ("sched/eevdf: Propagate min_slice up the cgroup hierarchy") Signed-off-by: Tianchen Ding Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20250211063659.7180-1-dtcccc@linux.alibaba.com Signed-off-by: Sasha Levin commit 7b1d2454d0b6dd2b44d370caa163fbdde928c650 Author: zihan zhou <15645113830zzh@gmail.com> Date: Sat Feb 8 16:08:52 2025 +0800 sched: Cancel the slice protection of the idle entity [ Upstream commit f553741ac8c0e467a3b873e305f34b902e50b86d ] A wakeup non-idle entity should preempt idle entity at any time, but because of the slice protection of the idle entity, the non-idle entity has to wait, so just cancel it. This patch is aimed at minimizing the impact of SCHED_IDLE on SCHED_NORMAL. For example, a task with SCHED_IDLE policy that sleeps for 1s and then runs for 3 ms, running cyclictest on the same cpu, has a maximum latency of 3 ms, which is caused by the slice protection of the idle entity. It is unreasonable. With this patch, the cyclictest latency under the same conditions is basically the same on the cpu with idle processes and on empty cpu. [peterz: add helpers] Fixes: 63304558ba5d ("sched/eevdf: Curb wakeup-preemption") Signed-off-by: zihan zhou <15645113830zzh@gmail.com> Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Tested-by: Vincent Guittot Link: https://lkml.kernel.org/r/20250208080850.16300-1-15645113830zzh@gmail.com Signed-off-by: Sasha Levin commit 2d5c37dff4b08e19dbf419ade6bc225e016dc886 Author: Konstantin Andreev Date: Sun Jan 26 17:07:27 2025 +0300 smack: ipv4/ipv6: tcp/dccp/sctp: fix incorrect child socket label [ Upstream commit 6cce0cc3861337b3ad8d4ac131d6e47efa0954ec ] Since inception [1], SMACK initializes ipv* child socket security for connection-oriented communications (tcp/sctp/dccp) during accept() syscall, in the security_sock_graft() hook: | void smack_sock_graft(struct sock *sk, ...) | { | // only ipv4 and ipv6 are eligible here | // ... | ssp = sk->sk_security; // socket security | ssp->smk_in = skp; // process label: smk_of_current() | ssp->smk_out = skp; // process label: smk_of_current() | } This approach is incorrect for two reasons: A) initialization occurs too late for child socket security: The child socket is created by the kernel once the handshake completes (e.g., for tcp: after receiving ack for syn+ack). Data can legitimately start arriving to the child socket immediately, long before the application calls accept() on the socket. Those data are (currently — were) processed by SMACK using incorrect child socket security attributes. B) Incoming connection requests are handled using the listening socket's security, hence, the child socket must inherit the listening socket's security attributes. smack_sock_graft() initilizes the child socket's security with a process label, as is done for a new socket() But ... the process label is not necessarily the same as the listening socket label. A privileged application may legitimately set other in/out labels for a listening socket. When this happens, SMACK processes incoming packets using incorrect socket security attributes. In [2] Michael Lontke noticed (A) and fixed it in [3] by adding socket initialization into security_sk_clone_security() hook like | void smack_sk_clone_security(struct sock *oldsk, struct sock *newsk) | { | *(struct socket_smack *)newsk->sk_security = | *(struct socket_smack *)oldsk->sk_security; | } This initializes the child socket security with the parent (listening) socket security at the appropriate time. I was forced to revisit this old story because smack_sock_graft() was left in place by [3] and continues overwriting the child socket's labels with the process label, and there might be a reason for this, so I undertook a study. If the process label differs from the listening socket's labels, the following occurs for ipv4: assigning the smk_out is not accompanied by netlbl_sock_setattr, so the outgoing packet's cipso label does not change. So, the only effect of this assignment for interhost communications is a divergence between the program-visible “out” socket label and the cipso network label. For intrahost communications this label, however, becomes visible via secmark netfilter marking, and is checked for access rights by the client, receiving side. Assigning the smk_in affects both interhost and intrahost communications: the server begins to check access rights against an wrong label. Access check against wrong label (smk_in or smk_out), unsurprisingly fails, breaking the connection. The above affects protocols that calls security_sock_graft() during accept(), namely: {tcp,dccp,sctp}/{ipv4,ipv6} One extra security_sock_graft() caller, crypto/af_alg.c`af_alg_accept is not affected, because smack_sock_graft() does nothing for PF_ALG. To reproduce, assign non-default in/out labels to a listening socket, setup rules between these labels and client label, attempt to connect and send some data. Ipv6 specific: ipv6 packets do not convey SMACK labels. To reproduce the issue in interhost communications set opposite labels in /smack/ipv6host on both hosts. Ipv6 intrahost communications do not require tricking, because SMACK labels are conveyed via secmark netfilter marking. So, currently smack_sock_graft() is not useful, but harmful, therefore, I have removed it. This fixes the issue for {tcp,dccp}/{ipv4,ipv6}, but not sctp/{ipv4,ipv6}. Although this change is necessary for sctp+smack to function correctly, it is not sufficient because: sctp/ipv4 does not call security_sk_clone() and sctp/ipv6 ignores SMACK completely. These are separate issues, belong to other subsystem, and should be addressed separately. [1] 2008-02-04, Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") [2] Michael Lontke, 2022-08-31, SMACK LSM checks wrong object label during ingress network traffic Link: https://lore.kernel.org/linux-security-module/6324997ce4fc092c5020a4add075257f9c5f6442.camel@elektrobit.com/ [3] 2022-08-31, michael.lontke, commit 4ca165fc6c49 ("SMACK: Add sk_clone_security LSM hook") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 9d93922280f90f3ce5d7e041e4d6d5d8c54d433c Author: Konstantin Andreev Date: Fri Jan 17 19:36:42 2025 +0300 smack: dont compile ipv6 code unless ipv6 is configured [ Upstream commit bfcf4004bcbce2cb674b4e8dbd31ce0891766bac ] I want to be sure that ipv6-specific code is not compiled in kernel binaries if ipv6 is not configured. [1] was getting rid of "unused variable" warning, but, with that, it also mandated compilation of a handful ipv6- specific functions in ipv4-only kernel configurations: smk_ipv6_localhost, smack_ipv6host_label, smk_ipv6_check. Their compiled bodies are likely to be removed by compiler from the resulting binary, but, to be on the safe side, I remove them from the compiler view. [1] Fixes: 00720f0e7f28 ("smack: avoid unused 'sip' variable warning") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 40426fc0970e24b3f681b0d3bf040ab454d7e280 Author: zuoqian Date: Sat Jan 25 08:49:49 2025 +0000 cpufreq: scpi: compare kHz instead of Hz [ Upstream commit 4742da9774a416908ef8e3916164192c15c0e2d1 ] The CPU rate from clk_get_rate() may not be divisible by 1000 (e.g., 133333333). But the rate calculated from frequency(kHz) is always divisible by 1000 (e.g., 133333000). Comparing the rate causes a warning during CPU scaling: "cpufreq: __target_index: Failed to change cpu frequency: -5". When we choose to compare kHz here, the issue does not occur. Fixes: 343a8d17fa8d ("cpufreq: scpi: remove arm_big_little dependency") Signed-off-by: zuoqian Reviewed-by: Dan Carpenter Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit bc4d689a231dcf284bbcf6cad5541b2301cfe145 Author: Mike Rapoport (Microsoft) Date: Sun Jan 26 09:47:25 2025 +0200 x86/mm/pat: cpa-test: fix length for CPA_ARRAY test [ Upstream commit 33ea120582a638b2f2e380a50686c2b1d7cce795 ] The CPA_ARRAY test always uses len[1] as numpages argument to change_page_attr_set() although the addresses array is different each iteration of the test loop. Replace len[1] with len[i] to have numpages matching the addresses array. Fixes: ecc729f1f471 ("x86/mm/cpa: Add ARRAY and PAGES_ARRAY selftests") Signed-off-by: "Mike Rapoport (Microsoft)" Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20250126074733.1384926-2-rppt@kernel.org Signed-off-by: Sasha Levin commit 56ec918e6c86c1536870e4373e91eddd0c44245f Author: Eric Sandeen Date: Thu Feb 27 11:41:08 2025 -0600 watch_queue: fix pipe accounting mismatch [ Upstream commit f13abc1e8e1a3b7455511c4e122750127f6bc9b0 ] Currently, watch_queue_set_size() modifies the pipe buffers charged to user->pipe_bufs without updating the pipe->nr_accounted on the pipe itself, due to the if (!pipe_has_watch_queue()) test in pipe_resize_ring(). This means that when the pipe is ultimately freed, we decrement user->pipe_bufs by something other than what than we had charged to it, potentially leading to an underflow. This in turn can cause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM. To remedy this, explicitly account for the pipe usage in watch_queue_set_size() to match the number set via account_pipe_buffers() (It's unclear why watch_queue_set_size() does not update nr_accounted; it may be due to intentional overprovisioning in watch_queue_set_size()?) Fixes: e95aada4cb93d ("pipe: wakeup wr_wait after setting max_usage") Signed-off-by: Eric Sandeen Link: https://lore.kernel.org/r/206682a8-0604-49e5-8224-fdbe0c12b460@redhat.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 5d770250a6a9c0b854cad618cc16e17bead676f6 Author: Alexandre Frade Date: Mon Apr 7 16:41:55 2025 +0000 Linux 6.12.22-xanmod1 Signed-off-by: Alexandre Frade commit 2c47598397df075ca4e67f9b3d52bbf7b96f5706 Merge: e6670d29c234 55767d6e74ef Author: Alexandre Frade Date: Mon Apr 7 16:36:05 2025 +0000 Merge tag 'v6.12.22' into 6.12 This is the 6.12.22 stable release commit 55767d6e74ef155f43fff978ad4e2f69f3f8fad7 Author: Greg Kroah-Hartman Date: Mon Apr 7 10:08:37 2025 +0200 Linux 6.12.22 Link: https://lore.kernel.org/r/20250403151622.055059925@linuxfoundation.org Tested-by: Markus Reichelt Tested-by: Salvatore Bonaccorso Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Harshit Mogalapalli Signed-off-by: Greg Kroah-Hartman commit 9e6e83e1e2d01b99e70cd7812d7f758a8def9fc8 Author: Kent Overstreet Date: Sat Mar 29 19:01:09 2025 -0400 bcachefs: bch2_ioctl_subvolume_destroy() fixes [ Upstream commit 707549600c4a012ed71c0204a7992a679880bf33 ] bch2_evict_subvolume_inodes() was getting stuck - due to incorrectly pruning the dcache. Also, fix missing permissions checks. Reported-by: Alexander Viro Signed-off-by: Kent Overstreet Signed-off-by: Greg Kroah-Hartman commit a964484a3537f121edd94a0dfbe6ac853c0462cf Author: John Keeping Date: Mon Feb 24 12:18:30 2025 +0000 serial: 8250_dma: terminate correct DMA in tx_dma_flush() commit a26503092c75abba70a0be2aa01145ecf90c2a22 upstream. When flushing transmit side DMA, it is the transmit channel that should be terminated, not the receive channel. Fixes: 9e512eaaf8f40 ("serial: 8250: Fix fifo underflow on flush") Cc: stable Reported-by: Wentao Guan Signed-off-by: John Keeping Reviewed-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20250224121831.1429323-1-jkeeping@inmusicbrands.com Signed-off-by: Greg Kroah-Hartman commit 5f9176f82ec7d9f66f3892a330126de4ef66c2d6 Author: Cheick Traore Date: Thu Mar 20 16:25:40 2025 +0100 serial: stm32: do not deassert RS485 RTS GPIO prematurely commit 2790ce23951f0c497810c44ad60a126a59c8d84c upstream. If stm32_usart_start_tx is called with an empty xmit buffer, RTS GPIO could be deasserted prematurely, as bytes in TX FIFO are still transmitting. So this patch remove rts disable when xmit buffer is empty. Fixes: d7c76716169d ("serial: stm32: Use TC interrupt to deassert GPIO RTS in RS485 mode") Cc: stable Signed-off-by: Cheick Traore Link: https://lore.kernel.org/r/20250320152540.709091-1-cheick.traore@foss.st.com Signed-off-by: Greg Kroah-Hartman commit f86907583000c605bb2b1400ca77f2865aecc3c4 Author: Greg Kroah-Hartman Date: Wed Feb 19 14:40:56 2025 +0100 perf tools: Fix up some comments and code to properly use the event_source bus commit 0cced76a0276610e86e8b187c09f0e9ef85b9299 upstream. In sysfs, the perf events are all located in /sys/bus/event_source/devices/ but some places ended up hard-coding the location to be at the root of /sys/devices/ which could be very risky as you do not exactly know what type of device you are accessing in sysfs at that location. So fix this all up by properly pointing everything at the bus device list instead of the root of the sysfs devices/ tree. Cc: stable Signed-off-by: Greg Kroah-Hartman Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/2025021955-implant-excavator-179d@gregkh Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit b094e8e3988e02e8cef7a756c8d2cea9c12509ab Author: Luo Qiu Date: Mon Mar 17 18:14:38 2025 +0800 memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove commit 4676741a3464b300b486e70585c3c9b692be1632 upstream. This fixes the following crash: ================================================================== BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241 CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNED_MODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms] Call Trace: dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x27/0x320 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] print_report+0x3e/0x70 kasan_report+0xab/0xe0 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms] ? __pfx___schedule+0x10/0x10 ? kick_pool+0x3b/0x270 process_one_work+0x357/0x660 worker_thread+0x390/0x4c0 ? __pfx_worker_thread+0x10/0x10 kthread+0x190/0x1d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 161446: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x1a7/0x470 memstick_alloc_host+0x1f/0xe0 [memstick] rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms] platform_probe+0x60/0xe0 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 bus_probe_device+0xbd/0xd0 device_add+0x4a5/0x760 platform_device_add+0x189/0x370 mfd_add_device+0x587/0x5e0 mfd_add_devices+0xb1/0x130 rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb] usb_probe_interface+0x15c/0x460 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 rebind_marked_interfaces.isra.0+0xcc/0x110 usb_reset_device+0x352/0x410 usbdev_do_ioctl+0xe5c/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 161506: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x36/0x60 __kasan_slab_free+0x34/0x50 kfree+0x1fd/0x3b0 device_release+0x56/0xf0 kobject_cleanup+0x73/0x1c0 rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms] platform_remove+0x2f/0x50 device_release_driver_internal+0x24b/0x2e0 bus_remove_device+0x124/0x1d0 device_del+0x239/0x530 platform_device_del.part.0+0x19/0xe0 platform_device_unregister+0x1c/0x40 mfd_remove_devices_fn+0x167/0x170 device_for_each_child_reverse+0xc9/0x130 mfd_remove_devices+0x6e/0xa0 rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb] usb_unbind_interface+0xf3/0x3f0 device_release_driver_internal+0x24b/0x2e0 proc_disconnect_claim+0x13d/0x220 usbdev_do_ioctl+0xb5e/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x360 __irq_exit_rcu+0x114/0x130 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20 Second to last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x360 __irq_exit_rcu+0x114/0x130 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20 The buggy address belongs to the object at ffff888136335000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 896 bytes inside of freed 2048-byte region [ffff888136335000, ffff888136335800) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x136330 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f5(slab) raw: 0017ffffc0000040 ffff888100042f00 ffffea000417a000 dead000000000002 raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000 head: 0017ffffc0000040 ffff888100042f00 ffffea000417a000 dead000000000002 head: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000 head: 0017ffffc0000003 ffffea0004d8cc01 ffffffffffffffff 0000000000000000 head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888136335280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888136335300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888136335380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888136335400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888136335480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Fixes: 6827ca573c03 ("memstick: rtsx_usb_ms: Support runtime power management") Signed-off-by: Luo Qiu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/4B7BC3E6E291E6F2+20250317101438.25650-1-luoqiu@kylinsec.com.cn Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit a4931d9fb99eb5462f3eaa231999d279c40afb21 Author: Michal Pecio Date: Thu Mar 6 16:49:52 2025 +0200 usb: xhci: Apply the link chain quirk on NEC isoc endpoints commit bb0ba4cb1065e87f9cc75db1fa454e56d0894d01 upstream. Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment: [ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000] It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000. [ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000. [ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2 It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain. Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board. [ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0 Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set. The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times. No negative side effects seen in UVC recording and UAC playback with a few devices at full speed, high speed and SuperSpeed. The problem doesn't reproduce on the newer Renesas uPD720201/uPD720202 and on old Etron EJ168 and VIA VL805 (but the VL805 has other bug). [shorten line length of log snippets in commit messge -Mathias] Signed-off-by: Michal Pecio Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250306144954.3507700-14-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 6af20ac254cbd0e1178a3542767c9308e209eee5 Author: Michal Pecio Date: Thu Mar 6 16:49:42 2025 +0200 usb: xhci: Don't skip on Stopped - Length Invalid commit 58d0a3fab5f4fdc112c16a4c6d382f62097afd1c upstream. Up until commit d56b0b2ab142 ("usb: xhci: ensure skipped isoc TDs are returned when isoc ring is stopped") in v6.11, the driver didn't skip missed isochronous TDs when handling Stoppend and Stopped - Length Invalid events. Instead, it erroneously cleared the skip flag, which would cause the ring to get stuck, as future events won't match the missed TD which is never removed from the queue until it's cancelled. This buggy logic seems to have been in place substantially unchanged since the 3.x series over 10 years ago, which probably speaks first and foremost about relative rarity of this case in normal usage, but by the spec I see no reason why it shouldn't be possible. After d56b0b2ab142, TDs are immediately skipped when handling those Stopped events. This poses a potential problem in case of Stopped - Length Invalid, which occurs either on completed TDs (likely already given back) or Link and No-Op TRBs. Such event won't be recognized as matching any TD (unless it's the rare Link TRB inside a TD) and will result in skipping all pending TDs, giving them back possibly before they are done, risking isoc data loss and maybe UAF by HW. As a compromise, don't skip and don't clear the skip flag on this kind of event. Then the next event will skip missed TDs. A downside of not handling Stopped - Length Invalid on a Link inside a TD is that if the TD is cancelled, its actual length will not be updated to account for TRBs (silently) completed before the TD was stopped. I had no luck producing this sequence of completion events so there is no compelling demonstration of any resulting disaster. It may be a very rare, obscure condition. The sole motivation for this patch is that if such unlikely event does occur, I'd rather risk reporting a cancelled partially done isoc frame as empty than gamble with UAF. This will be fixed more properly by looking at Stopped event's TRB pointer when making skipping decisions, but such rework is unlikely to be backported to v6.12, which will stay around for a few years. Fixes: d56b0b2ab142 ("usb: xhci: ensure skipped isoc TDs are returned when isoc ring is stopped") Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250306144954.3507700-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit ed5760db3d8aad62b3ae0d2a7e6ca36dd18cdc2f Author: Dominique Martinet Date: Wed Mar 26 17:32:36 2025 +0900 net: usb: usbnet: restore usb%d name exception for local mac addresses commit 2ea396448f26d0d7d66224cb56500a6789c7ed07 upstream. commit 8a7d12d674ac ("net: usb: usbnet: fix name regression") assumed that local addresses always came from the kernel, but some devices hand out local mac addresses so we ended up with point-to-point devices with a mac set by the driver, renaming to eth%d when they used to be named usb%d. Userspace should not rely on device name, but for the sake of stability restore the local mac address check portion of the naming exception: point to point devices which either have no mac set by the driver or have a local mac handed out by the driver will keep the usb%d name. (some USB LTE modems are known to hand out a stable mac from the locally administered range; that mac appears to be random (different for mulitple devices) and can be reset with device-specific commands, so while such devices would benefit from getting a OUI reserved, we have to deal with these and might as well preserve the existing behavior to avoid breaking fragile openwrt configurations and such on upgrade.) Link: https://lkml.kernel.org/r/20241203130457.904325-1-asmadeus@codewreck.org Fixes: 8a7d12d674ac ("net: usb: usbnet: fix name regression") Cc: stable@vger.kernel.org Tested-by: Ahmed Naseef Signed-off-by: Dominique Martinet Acked-by: Oliver Neukum Link: https://patch.msgid.link/20250326-usbnet_rename-v2-1-57eb21fcff26@atmark-techno.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 52e05bea53c2f64432b4d00057a4325ee59e1e7c Author: Fabio Porcedda Date: Thu Feb 27 12:24:39 2025 +0100 net: usb: qmi_wwan: add Telit Cinterion FE990B composition commit e8cdd91926aac2c53a23925c538ad4c44be4201f upstream. Add the following Telit Cinterion FE990B composition: 0x10b0: rmnet + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (AT) + tty (diag) + DPL + QDSS (Qualcomm Debug SubSystem) + adb usb-devices: T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=10b0 Rev=05.15 S: Manufacturer=Telit Cinterion S: Product=FE990 S: SerialNumber=28c2595e C: #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8a(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none) E: Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none) E: Ad=8d(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable@vger.kernel.org Signed-off-by: Fabio Porcedda Link: https://patch.msgid.link/20250227112441.3653819-2-fabio.porcedda@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 666e78b47713f35210cbca394a5027508848ab32 Author: Fabio Porcedda Date: Wed Feb 5 18:16:46 2025 +0100 net: usb: qmi_wwan: add Telit Cinterion FN990B composition commit 9dba9a45f8ca64a7df32aada14c20a3153af1ac8 upstream. Add the following Telit Cinterion FN990B composition: 0x10d0: rmnet + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (AT) + tty (diag) + DPL + QDSS (Qualcomm Debug SubSystem) + adb T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 17 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=10d0 Rev=05.15 S: Manufacturer=Telit Cinterion S: Product=FN990 S: SerialNumber=43b38f19 C: #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8a(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none) E: Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none) E: Ad=8d(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable@vger.kernel.org Signed-off-by: Fabio Porcedda Link: https://patch.msgid.link/20250205171649.618162-3-fabio.porcedda@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 53a005d3019fdf45c8f88d845c29cac563e851f6 Author: Sherry Sun Date: Wed Mar 12 10:25:03 2025 +0800 tty: serial: fsl_lpuart: disable transmitter before changing RS485 related registers commit f5cb528d6441eb860250a2f085773aac4f44085e upstream. According to the LPUART reference manual, TXRTSE and TXRTSPOL of MODIR register only can be changed when the transmitter is disabled. So disable the transmitter before changing RS485 related registers and re-enable it after the change is done. Fixes: 67b01837861c ("tty: serial: lpuart: Add RS485 support for 32-bit uart flavour") Cc: stable Signed-off-by: Sherry Sun Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250312022503.1342990-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman commit 27bd86d139cea58eb7428a8e5fa556650694709d Author: Cameron Williams Date: Mon Mar 10 22:27:10 2025 +0000 tty: serial: 8250: Add Brainboxes XC devices commit 5c7e2896481a177bbda41d7850f05a9f5a8aee2b upstream. These ExpressCard devices use the OxPCIE chip and can be used with this driver. Signed-off-by: Cameron Williams Cc: stable Link: https://lore.kernel.org/r/DB7PR02MB3802907A9360F27F6CD67AAFC4D62@DB7PR02MB3802.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit 54f9a8dcab907e2661f49d3b2cac6956a384530f Author: Cameron Williams Date: Sun Feb 23 22:07:38 2025 +0000 tty: serial: 8250: Add some more device IDs commit be6a23650908e2f827f2e7839a3fbae41ccb5b63 upstream. These card IDs got missed the first time around. Cc: stable Signed-off-by: Cameron Williams Link: https://lore.kernel.org/r/DB7PR02MB380295BCC879CCF91315AC38C4C12@DB7PR02MB3802.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit 0fac51a2d14327faaee70590e7a7085c0ff5e0f7 Author: William Breathitt Gray Date: Wed Mar 5 19:01:19 2025 +0900 counter: microchip-tcb-capture: Fix undefined counter channel state on probe commit c0c9c73434666dc99ee156b25e7e722150bee001 upstream. Hardware initialize of the timer counter channel does not occur on probe thus leaving the Count in an undefined state until the first function_write() callback is executed. Fix this by performing the proper hardware initialization during probe. Fixes: 106b104137fd ("counter: Add microchip TCB capture counter") Reported-by: Csókás Bence Closes: https://lore.kernel.org/all/bfa70e78-3cc3-4295-820b-3925c26135cb@prolan.hu/ Link: https://lore.kernel.org/r/20250305-preset-capture-mode-microchip-tcb-capture-v1-1-632c95c6421e@kernel.org Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman commit 181a2ab650f77996c03ba0f5f208f6019ea1f15a Author: Fabrice Gasnier Date: Mon Feb 24 18:06:57 2025 +0100 counter: stm32-lptimer-cnt: fix error handling when enabling commit 8744dcd4fc7800de2eb9369410470bb2930d4c14 upstream. In case the stm32_lptim_set_enable_state() fails to update CMP and ARR, a timeout error is raised, by regmap_read_poll_timeout. It may happen, when the lptimer runs on a slow clock, and the clock is gated only few times during the polling. Badly, when this happen, STM32_LPTIM_ENABLE in CR register has been set. So the 'enable' state in sysfs wrongly lies on the counter being correctly enabled, due to CR is read as one in stm32_lptim_is_enabled(). To fix both issues: - enable the clock before writing CMP, ARR and polling ISR bits. It will avoid the possible timeout error. - clear the ENABLE bit in CR and disable the clock in the error path. Fixes: d8958824cf07 ("iio: counter: Add support for STM32 LPTimer") Signed-off-by: Fabrice Gasnier Link: https://lore.kernel.org/r/20250224170657.3368236-1-fabrice.gasnier@foss.st.com Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman commit 3ed38d0297fa448d130dc99e20eba8ff047cc229 Author: Dhruv Deshpande Date: Mon Mar 17 08:56:53 2025 +0000 ALSA: hda/realtek: Support mute LED on HP Laptop 15s-du3xxx commit 35ef1c79d2e09e9e5a66e28a66fe0df4368b0f3d upstream. The mute LED on this HP laptop uses ALC236 and requires a quirk to function. This patch enables the existing quirk for the device. Tested on my laptop and the LED behaviour works as intended. Cc: stable@vger.kernel.org Signed-off-by: Dhruv Deshpande Link: https://patch.msgid.link/20250317085621.45056-1-dhrv.d@proton.me Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2bb139e483f8cbe488d19d8c1135ac3615e2668c Author: Maxim Mikityanskiy Date: Tue Mar 18 18:15:16 2025 +0200 netfilter: socket: Lookup orig tuple for IPv6 SNAT commit 932b32ffd7604fb00b5c57e239a3cc4d901ccf6e upstream. nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socket_match() can correctly check whether the socket was transparent. However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this conntrack lookup, making xt_socket fail to match on the socket when the packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6. IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as pods' addresses are in the fd00::/8 ULA subnet and need to be replaced with the node's external address. Cilium leverages Envoy to enforce L7 policies, and Envoy uses transparent sockets. Cilium inserts an iptables prerouting rule that matches on `-m socket --transparent` and redirects the packets to localhost, but it fails to match SNATed IPv6 packets due to that missing conntrack lookup. Closes: https://github.com/cilium/cilium/issues/37932 Fixes: eb31628e37a0 ("netfilter: nf_tables: Add support for IPv6 NAT") Signed-off-by: Maxim Mikityanskiy Reviewed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 2c1674fb52b2e1a1d7be78888f1a747e70c05474 Author: Wayne Lin Date: Fri Oct 25 12:27:26 2024 +0800 drm/amd/display: Don't write DP_MSTM_CTRL after LT commit bc068194f548ef1f230d96c4398046bf59165992 upstream. [Why] Observe after suspend/resme, we can't light up mst monitors under specific mst hub. The reason is that driver still writes DPCD DP_MSTM_CTRL after LT. It's forbidden even we write the same value for that dpcd register. [How] We already resume the mst branch device dpcd settings during resume_mst_branch_status(). Leverage drm_dp_mst_topology_queue_probe() to only probe the topology, not calling drm_dp_mst_topology_mgr_resume() which will set DP_MSTM_CTRL as well. Reviewed-by: Jerry Zuo Signed-off-by: Wayne Lin Signed-off-by: Zaeem Mohamed Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman commit 95407304253a4bf03494d921c6913e220c26cc63 Author: Scott Mayhew Date: Tue Dec 10 07:25:54 2024 -0500 nfsd: fix legacy client tracking initialization commit de71d4e211eddb670b285a0ea477a299601ce1ca upstream. Get rid of the nfsd4_legacy_tracking_ops->init() call in check_for_legacy_methods(). That will be handled in the caller (nfsd4_client_tracking_init()). Otherwise, we'll wind up calling nfsd4_legacy_tracking_ops->init() twice, and the second time we'll trigger the BUG_ON() in nfsd4_init_recdir(). Fixes: 74fd48739d04 ("nfsd: new Kconfig option for legacy client tracking") Reported-by: Jur van der Burg Link: https://bugzilla.kernel.org/show_bug.cgi?id=219580 Signed-off-by: Scott Mayhew Reviewed-by: Jeff Layton Tested-by: Salvatore Bonaccorso Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 09691f367df44fe93255274d80a439f9bb3263fc Author: Minjoong Kim Date: Sat Mar 22 10:52:00 2025 +0000 atm: Fix NULL pointer dereference commit bf2986fcf82a449441f9ee4335df19be19e83970 upstream. When MPOA_cache_impos_rcvd() receives the msg, it can trigger Null Pointer Dereference Vulnerability if both entry and holding_time are NULL. Because there is only for the situation where entry is NULL and holding_time exists, it can be passed when both entry and holding_time are NULL. If these are NULL, the entry will be passd to eg_cache_put() as parameter and it is referenced by entry->use code in it. kasan log: [ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I [ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102 [ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470 [ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80 [ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006 [ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e [ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030 [ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88 [ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15 [ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068 [ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000 [ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0 [ 3.326430] Call Trace: [ 3.326725] [ 3.326927] ? die_addr+0x3c/0xa0 [ 3.327330] ? exc_general_protection+0x161/0x2a0 [ 3.327662] ? asm_exc_general_protection+0x26/0x30 [ 3.328214] ? vprintk_emit+0x15e/0x420 [ 3.328543] ? eg_cache_remove_entry+0xa5/0x470 [ 3.328910] ? eg_cache_remove_entry+0x9a/0x470 [ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10 [ 3.329664] ? console_unlock+0x107/0x1d0 [ 3.329946] ? __pfx_console_unlock+0x10/0x10 [ 3.330283] ? do_syscall_64+0xa6/0x1a0 [ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f [ 3.331090] ? __pfx_prb_read_valid+0x10/0x10 [ 3.331395] ? down_trylock+0x52/0x80 [ 3.331703] ? vprintk_emit+0x15e/0x420 [ 3.331986] ? __pfx_vprintk_emit+0x10/0x10 [ 3.332279] ? down_trylock+0x52/0x80 [ 3.332527] ? _printk+0xbf/0x100 [ 3.332762] ? __pfx__printk+0x10/0x10 [ 3.333007] ? _raw_write_lock_irq+0x81/0xe0 [ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10 [ 3.333614] msg_from_mpoad+0x1185/0x2750 [ 3.333893] ? __build_skb_around+0x27b/0x3a0 [ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10 [ 3.334501] ? __alloc_skb+0x1c0/0x310 [ 3.334809] ? __pfx___alloc_skb+0x10/0x10 [ 3.335283] ? _raw_spin_lock+0xe0/0xe0 [ 3.335632] ? finish_wait+0x8d/0x1e0 [ 3.335975] vcc_sendmsg+0x684/0xba0 [ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10 [ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10 [ 3.337056] ? fdget+0x176/0x3e0 [ 3.337348] __sys_sendto+0x4a2/0x510 [ 3.337663] ? __pfx___sys_sendto+0x10/0x10 [ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400 [ 3.338364] ? sock_ioctl+0x1bb/0x5a0 [ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20 [ 3.339017] ? __pfx_sock_ioctl+0x10/0x10 [ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10 [ 3.339727] ? selinux_file_ioctl+0xa4/0x260 [ 3.340166] __x64_sys_sendto+0xe0/0x1c0 [ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140 [ 3.340898] do_syscall_64+0xa6/0x1a0 [ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 3.341533] RIP: 0033:0x44a380 [ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00 [ 3.343078] RSP: 002b:00007ffc1d404098 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 3.343631] RAX: ffffffffffffffda RBX: 00007ffc1d404458 RCX: 000000000044a380 [ 3.344306] RDX: 000000000000019c RSI: 00007ffc1d4040b0 RDI: 0000000000000003 [ 3.344833] RBP: 00007ffc1d404260 R08: 0000000000000000 R09: 0000000000000000 [ 3.345381] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 [ 3.346015] R13: 00007ffc1d404448 R14: 00000000004c17d0 R15: 0000000000000001 [ 3.346503] [ 3.346679] Modules linked in: [ 3.346956] ---[ end trace 0000000000000000 ]--- [ 3.347315] RIP: 0010:eg_cache_remove_entry+0xa5/0x470 [ 3.347737] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80 [ 3.349157] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006 [ 3.349517] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e [ 3.350103] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030 [ 3.350610] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88 [ 3.351246] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15 [ 3.351785] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068 [ 3.352404] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000 [ 3.353099] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.353544] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0 [ 3.354072] note: ex[79] exited with irqs disabled [ 3.354458] note: ex[79] exited with preempt_count 1 Signed-off-by: Minjoong Kim Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250322105200.14981-1-pwn9uin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit dddd13f7f1678850b4ec1665213440f47d4e18da Author: Terry Junge Date: Fri Jan 17 16:58:38 2025 -0800 HID: hid-plantronics: Add mic mute mapping and generalize quirks commit 9821709af892be9fbf4ee9a50b2f3e0604295ce0 upstream. Add mapping for headset mute key events. Remove PLT_QUIRK_DOUBLE_VOLUME_KEYS quirk and made it generic. The quirk logic did not keep track of the actual previous key so any key event occurring in less than or equal to 5ms was ignored. Remove PLT_QUIRK_FOLLOWED_OPPOSITE_VOLUME_KEYS quirk. It had the same logic issue as the double key quirk and was actually masking the as designed behavior of most of the headsets. It's occurrence should be minimized with the ALSA control naming quirk that is part of the patch set. Signed-off-by: Terry Junge Cc: stable@vger.kernel.org Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit a532e7680878c8de293bfa8f2cbf9703df9b8395 Author: Terry Junge Date: Fri Jan 17 16:58:39 2025 -0800 ALSA: usb-audio: Add quirk for Plantronics headsets to fix control names commit 486f6205c233da1baa309bde5f634eb1f8319a33 upstream. Many Poly/Plantronics headset families name the feature, input, and/or output units in a such a way to produce control names that are not recognized by user space. As such, the volume and mute events do not get routed to the headset's audio controls. As an example from a product family: The microphone mute control is named Headset Microphone Capture Switch and the headset volume control is named Headset Earphone Playback Volume The quirk fixes these to become Headset Capture Switch Headset Playback Volume Signed-off-by: Terry Junge Reviewed-by: Takashi Iwai Cc: stable@vger.kernel.org Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman