summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-11-27sysctl: Discriminate between kernel and user converter paramsJoel Granados
Rename converter parameter to indicate data flow direction: "lvalp" to "u_ptr" indicating a user space parsed value pointer. "valp" to "k_ptr" indicating a kernel storage value pointer. This facilitates the identification of discrepancies between direction (copy to kernel or copy to user space) and the modified variable. This is a preparation commit for when the converter functions are exposed to the rest of the kernel. Signed-off-by: Joel Granados <joel.granados@kernel.org>
2025-11-27sysctl: Indicate the direction of operation with macro namesJoel Granados
Replace the "write" integer parameter with SYSCTL_USER_TO_KERN() and SYSCTL_KERN_TO_USER() that clearly indicate data flow direction in sysctl operations. "write" originates in proc_sysctl.c (proc_sys_{read,write}) and can take one of two values: "0" or "1" when called from proc_sys_read and proc_sys_write respectively. When write has a value of zero, data is "written" to a user space buffer from a kernel variable (usually ctl_table->data). Whereas when write has a value greater than zero, data is "written" to an internal kernel variable from a user space buffer. Remove this ambiguity by introducing macros that clearly indicate the direction of the "write". The write mode names in sysctl_writes_mode are left unchanged as these directly relate to the sysctl_write_strict file in /proc/sys where the word "write" unambiguously refers to writing to a file. Signed-off-by: Joel Granados <joel.granados@kernel.org>
2025-11-27sysctl: Remove superfluous __do_proc_* indirectionJoel Granados
Remove "__" from __do_proc_do{intvec,uintvec,ulongvec_minmax} internal functions and delete their corresponding do_proc_do* wrappers. These indirections are unnecessary as they do not add extra logic nor do they indicate a layer separation. Signed-off-by: Joel Granados <joel.granados@kernel.org>
2025-11-27sysctl: Remove superfluous tbl_data param from "dovec" functionsJoel Granados
Remove superfluous tbl_data param from do_proc_douintvec{,_r,_w} and __do_proc_do{intvec,uintvec,ulongvec_minmax}. There is no need to pass it as it is always contained within the ctl_table struct. Signed-off-by: Joel Granados <joel.granados@kernel.org>
2025-11-27sysctl: Replace void pointer with const pointer to ctl_tableJoel Granados
* Replace void* data in the converter functions with a const struct ctl_table* table as it was only getting forwarding values from ctl_table->extra{1,2}. * Remove the void* data in the do_proc_* functions as they already had a pointer to the ctl_table. * Remove min/max structures do_proc_do{uint,int}vec_minmax_conv_param; the min/max values get passed directly in ctl_table. * Keep min/max initialization in extra{1,2} in proc_dou8vec_minmax. * The do_proc_douintvec was adjusted outside sysctl.c as it is exported to fs/pipe.c. Signed-off-by: Joel Granados <joel.granados@kernel.org>
2025-11-27KVM: s390: Enable and disable interrupts in entry codeHeiko Carstens
Move enabling and disabling of interrupts around the SIE instruction to entry code. Enabling interrupts only after the __TI_sie flag has been set guarantees that the SIE instruction is not executed if an interrupt happens between enabling interrupts and the execution of the SIE instruction. Interrupt handlers and machine check handler forward the PSW to the sie_exit label in such cases. This is a prerequisite for VIRT_XFER_TO_GUEST_WORK to prevent that guest context is entered when e.g. a scheduler IPI, indicating that a reschedule is required, happens right before the SIE instruction, which could lead to long delays. Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Tested-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2025-11-27KVM: s390: Add signal_exits counterAndrew Donnellan
Add a signal_exits counter for s390, as exists on arm64, loongarch, mips, powerpc, riscv and x86. This is used by kvm_handle_signal_exit(), which we will use when we later enable CONFIG_VIRT_XFER_TO_GUEST_WORK. Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2025-11-27staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsingNavaneeth K
The Extended Supported Rates (ESR) IE handling in OnBeacon accessed *(p + 1 + ielen) and *(p + 2 + ielen) without verifying that these offsets lie within the received frame buffer. A malformed beacon with an ESR IE positioned at the end of the buffer could cause an out-of-bounds read, potentially triggering a kernel panic. Add a boundary check to ensure that the ESR IE body and the subsequent bytes are within the limits of the frame before attempting to access them. This prevents OOB reads caused by malformed beacon frames. Signed-off-by: Navaneeth K <knavaneeth786@gmail.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-27staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsingNavaneeth K
The Supported Rates IE length from an incoming Association Request frame was used directly as the memcpy() length when copying into a fixed-size 16-byte stack buffer (supportRate). A malicious station can advertise an IE length larger than 16 bytes, causing a stack buffer overflow. Clamp ie_len to the buffer size before copying the Supported Rates IE, and correct the bounds check when merging Extended Supported Rates to prevent a second potential overflow. This prevents kernel stack corruption triggered by malformed association requests. Signed-off-by: Navaneeth K <knavaneeth786@gmail.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-27staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parserNavaneeth K
The Information Element (IE) parser rtw_get_ie() trusted the length byte of each IE without validating that the IE body (len bytes after the 2-byte header) fits inside the remaining frame buffer. A malformed frame can advertise an IE length larger than the available data, causing the parser to increment its pointer beyond the buffer end. This results in out-of-bounds reads or, depending on the pattern, an infinite loop. Fix by validating that (offset + 2 + len) does not exceed the limit before accepting the IE or advancing to the next element. This prevents OOB reads and ensures the parser terminates safely on malformed frames. Signed-off-by: Navaneeth K <knavaneeth786@gmail.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-27drm/xe: Move VRAM MM debugfs creation to tile levelPiotr Piórkowski
Previously, VRAM TTM resource manager debugfs entries (vram0_mm / vram1_mm) were created globally in the XE debugfs root directory. But technically, each tile has an associated VRAM TTM manager, which it can own. Let's create VRAM memory manager debugfs entries directly under each tile's debugfs directory for better alignment with the per-tile memory layout. Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20251127073643.144379-1-piotr.piorkowski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2025-11-27drm/xe/xe_sriov_packet: Return int from pf_descriptor_initJonathan Cavitt
pf_descriptor_init currently returns a size_t, which is an unsigned integer data type. This conflicts with it returning a negative errno value on failure. Make it return an int instead. This mirrors how pf_trailer_init is used later. Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Alex Zuo <alex.zuo@intel.com> Link: https://patch.msgid.link/20251117190114.69953-2-jonathan.cavitt@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2025-11-27x86/mm: Delete disabled debug codeBrendan Jackman
This code doesn't run. Since 2008: 4f9c11dd49fb ("x86, 64-bit: adjust mapping of physical pagetables to work with Xen") the kernel has gained more flexible logging and tracing capabilities; presumably if anyone wanted to take advantage of this log message they would have got rid of the "if (0)" so they could use these capabilities. Since they haven't, just delete it. Signed-off-by: Brendan Jackman <jackmanb@google.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20251003-x86-init-cleanup-v1-1-f2b7994c2ad6@google.com
2025-11-27refscale: Exercise DEFINE_STATIC_SRCU_FAST() and init_srcu_struct_fast()Paul E. McKenney
This commit updates the initialization for the "srcu-fast" scale type to use DEFINE_STATIC_SRCU_FAST() when reader_flavor is equal to SRCU_READ_FLAVOR_FAST. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: <bpf@vger.kernel.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2025-11-27rcutorture: Make srcu{,d}_torture_init() announce the SRCU typePaul E. McKenney
This commit causes rcutorture's srcu_torture_init() and srcud_torture_init() functions to announce on the console log which variant of SRCU is being tortured, for example: "torture: srcud_torture_init fast SRCU". [ paulmck: Apply feedback from kernel test robot. ] Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2025-11-27srcu: Create an SRCU-fast-updown APIPaul E. McKenney
This commit creates an SRCU-fast-updown API, including DEFINE_SRCU_FAST_UPDOWN(), DEFINE_STATIC_SRCU_FAST_UPDOWN(), __init_srcu_struct_fast_updown(), init_srcu_struct_fast_updown(), srcu_read_lock_fast_updown(), srcu_read_unlock_fast_updown(), __srcu_read_lock_fast_updown(), and __srcu_read_unlock_fast_updown(). These are initially identical to their SRCU-fast counterparts, but both SRCU-fast and SRCU-fast-updown will be optimized in different directions by later commits. SRCU-fast will lack any sort of srcu_down_read() and srcu_up_read() APIs, which will enable extremely efficient NMI safety. For its part, SRCU-fast-updown will not be NMI safe, which will enable reasonably efficient implementations of srcu_down_read_fast() and srcu_up_read_fast(). This API fork happens to meet two different future use cases. * SRCU-fast will become the reimplementation basis for RCU-TASK-TRACE for consolidation. Since RCU-TASK-TRACE must be NMI safe, SRCU-fast must be as well. * SRCU-fast-updown will be needed for uretprobes code in order to get rid of the read-side memory barriers while still allowing entering the reader at task level while exiting it in a timer handler. This commit also adds rcutorture tests for the new APIs. This (annoyingly) needs to be in the same commit for bisectability. With this commit, the 0x8 value tests SRCU-fast-updown. However, most SRCU-fast testing will be via the RCU Tasks Trace wrappers. [ paulmck: Apply s/0x8/0x4/ missing change per Boqun Feng feedback. ] [ paulmck: Apply Akira Yokosawa feedback. ] Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: <bpf@vger.kernel.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2025-11-27ACPI: PM: Fix a spelling mistakeChu Guangqing
Fix spelling by replacing "interrups" with "interrupts". Signed-off-by: Chu Guangqing <chuguangqing@inspur.com> [ rjw: Changelog edits ] Link: https://patch.msgid.link/20251125022403.2614-1-chuguangqing@inspur.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-27ACPI: LPSS: Fix a spelling mistakeChu Guangqing
Fix spelling by replacing "successfull" with "successful". Signed-off-by: Chu Guangqing <chuguangqing@inspur.com> [ rjw: Changelog edits ] Link: https://patch.msgid.link/20251125021431.2243-1-chuguangqing@inspur.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-27mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in ↵Kuniyuki Iwashima
mptcp_do_fastclose(). syzbot reported divide-by-zero in __tcp_select_window() by MPTCP socket. [0] We had a similar issue for the bare TCP and fixed in commit 499350a5a6e7 ("tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0"). Let's apply the same fix to mptcp_do_fastclose(). [0]: Oops: divide error: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 RIP: 0010:__tcp_select_window+0x824/0x1320 net/ipv4/tcp_output.c:3336 Code: ff ff ff 44 89 f1 d3 e0 89 c1 f7 d1 41 01 cc 41 21 c4 e9 a9 00 00 00 e8 ca 49 01 f8 e9 9c 00 00 00 e8 c0 49 01 f8 44 89 e0 99 <f7> 7c 24 1c 41 29 d4 48 bb 00 00 00 00 00 fc ff df e9 80 00 00 00 RSP: 0018:ffffc90003017640 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88807b469e40 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90003017730 R08: ffff888033268143 R09: 1ffff1100664d028 R10: dffffc0000000000 R11: ffffed100664d029 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 000055557faa0500(0000) GS:ffff888126135000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f64a1912ff8 CR3: 0000000072122000 CR4: 00000000003526f0 Call Trace: <TASK> tcp_select_window net/ipv4/tcp_output.c:281 [inline] __tcp_transmit_skb+0xbc7/0x3aa0 net/ipv4/tcp_output.c:1568 tcp_transmit_skb net/ipv4/tcp_output.c:1649 [inline] tcp_send_active_reset+0x2d1/0x5b0 net/ipv4/tcp_output.c:3836 mptcp_do_fastclose+0x27e/0x380 net/mptcp/protocol.c:2793 mptcp_disconnect+0x238/0x710 net/mptcp/protocol.c:3253 mptcp_sendmsg_fastopen+0x2f8/0x580 net/mptcp/protocol.c:1776 mptcp_sendmsg+0x1774/0x1980 net/mptcp/protocol.c:1855 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xe5/0x270 net/socket.c:742 __sys_sendto+0x3bd/0x520 net/socket.c:2244 __do_sys_sendto net/socket.c:2251 [inline] __se_sys_sendto net/socket.c:2247 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2247 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f66e998f749 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffff9acedb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f66e9be5fa0 RCX: 00007f66e998f749 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007ffff9acee10 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f66e9be5fa0 R14: 00007f66e9be5fa0 R15: 0000000000000006 </TASK> Fixes: ae155060247b ("mptcp: fix duplicate reset on fastclose") Reported-by: syzbot+3a92d359bc2ec6255a33@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69260882.a70a0220.d98e3.00b4.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251125195331.309558-1-kuniyu@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-27RDMA/rxe: reclassify sockets in order to avoid false positives from lockdepStefan Metzmacher
While developing IPPROTO_SMBDIRECT support for the code under fs/smb/common/smbdirect [1], I noticed false positives like this: [+0,003927] ============================================ [+0,000532] WARNING: possible recursive locking detected [+0,000611] 6.18.0-rc5-metze-kasan-lockdep.02+ #1 Tainted: G OE [+0,000835] -------------------------------------------- [+0,000729] ksmbd:r5445/3609 is trying to acquire lock: [+0,000709] ffff88800b9570f8 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x52/0x360 [+0,000831] but task is already holding lock: [+0,000684] ffff88800654af78 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: smbdirect_sk_close+0x122/0x790 [smbdirect] [+0,000928] other info that might help us debug this: [+0,005552] Possible unsafe locking scenario: [+0,000723] CPU0 [+0,000359] ---- [+0,000377] lock(k-sk_lock-AF_INET); [+0,000478] lock(k-sk_lock-AF_INET); [+0,000498] *** DEADLOCK *** [+0,001012] May be due to missing lock nesting notation [+0,000831] 3 locks held by ksmbd:r5445/3609: [+0,000484] #0: ffff88800654af78 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: smbdirect_sk_close+0x122/0x790 [smbdirect] [+0,001000] #1: ffff888020a40458 (&id_priv->handler_mutex){+.+.}-{4:4}, at: rdma_lock_handler+0x17/0x30 [rdma_cm] [+0,000982] #2: ffff888020a40350 (&id_priv->qp_mutex){+.+.}-{4:4}, at: rdma_destroy_qp+0x5d/0x1f0 [rdma_cm] [+0,000934] stack backtrace: [+0,000589] CPU: 0 UID: 0 PID: 3609 Comm: ksmbd:r5445 Kdump: loaded Tainted: G OE 6.18.0-rc5-metze-kasan-lockdep.02+ #1 PREEMPT(voluntary) [+0,000023] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [+0,000004] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 ... [+0,000010] print_deadlock_bug+0x245/0x330 [+0,000014] validate_chain+0x32a/0x590 [+0,000012] __lock_acquire+0x535/0xc30 [+0,000013] lock_acquire.part.0+0xb3/0x240 [+0,000017] ? inet_shutdown+0x52/0x360 [+0,000013] ? srso_alias_return_thunk+0x5/0xfbef5 [+0,000007] ? mark_held_locks+0x46/0x90 [+0,000012] lock_acquire+0x60/0x140 [+0,000006] ? inet_shutdown+0x52/0x360 [+0,000028] lock_sock_nested+0x3b/0xf0 [+0,000009] ? inet_shutdown+0x52/0x360 [+0,000008] inet_shutdown+0x52/0x360 [+0,000010] kernel_sock_shutdown+0x5b/0x90 [+0,000011] rxe_qp_do_cleanup+0x4ef/0x810 [rdma_rxe] [+0,000043] ? __pfx_rxe_qp_do_cleanup+0x10/0x10 [rdma_rxe] [+0,000030] execute_in_process_context+0x2b/0x170 [+0,000013] rxe_qp_cleanup+0x1c/0x30 [rdma_rxe] [+0,000021] __rxe_cleanup+0x1cf/0x2e0 [rdma_rxe] [+0,000036] ? __pfx___rxe_cleanup+0x10/0x10 [rdma_rxe] [+0,000020] ? srso_alias_return_thunk+0x5/0xfbef5 [+0,000006] ? __kasan_check_read+0x11/0x20 [+0,000012] rxe_destroy_qp+0xe1/0x230 [rdma_rxe] [+0,000035] ib_destroy_qp_user+0x217/0x450 [ib_core] [+0,000074] rdma_destroy_qp+0x83/0x1f0 [rdma_cm] [+0,000034] smbdirect_connection_destroy_qp+0x98/0x2e0 [smbdirect] [+0,000017] ? __pfx_smb_direct_logging_needed+0x10/0x10 [ksmbd] [+0,000044] smbdirect_connection_destroy+0x698/0xed0 [smbdirect] [+0,000023] ? __pfx_smbdirect_connection_destroy+0x10/0x10 [smbdirect] [+0,000033] ? __pfx_smb_direct_logging_needed+0x10/0x10 [ksmbd] [+0,000031] smbdirect_connection_destroy_sync+0x42b/0x9f0 [smbdirect] [+0,000029] ? mark_held_locks+0x46/0x90 [+0,000012] ? __pfx_smbdirect_connection_destroy_sync+0x10/0x10 [smbdirect] [+0,000019] ? srso_alias_return_thunk+0x5/0xfbef5 [+0,000007] ? trace_hardirqs_on+0x64/0x70 [+0,000029] ? srso_alias_return_thunk+0x5/0xfbef5 [+0,000010] ? srso_alias_return_thunk+0x5/0xfbef5 [+0,000006] ? __smbdirect_connection_schedule_disconnect+0x339/0x4b0 [+0,000021] smbdirect_sk_destroy+0xb0/0x680 [smbdirect] [+0,000024] ? srso_alias_return_thunk+0x5/0xfbef5 [+0,000006] ? trace_hardirqs_on+0x64/0x70 [+0,000006] ? srso_alias_return_thunk+0x5/0xfbef5 [+0,000005] ? __local_bh_enable_ip+0xba/0x150 [+0,000011] sk_common_release+0x66/0x340 [+0,000010] smbdirect_sk_close+0x12a/0x790 [smbdirect] [+0,000023] ? ip_mc_drop_socket+0x1e/0x240 [+0,000013] inet_release+0x10a/0x240 [+0,000011] smbdirect_sock_release+0x502/0xe80 [smbdirect] [+0,000015] ? srso_alias_return_thunk+0x5/0xfbef5 [+0,000024] sock_release+0x91/0x1c0 [+0,000010] smb_direct_free_transport+0x31/0x50 [ksmbd] [+0,000025] ksmbd_conn_free+0x1d0/0x240 [ksmbd] [+0,000040] smb_direct_disconnect+0xb2/0x120 [ksmbd] [+0,000023] ? srso_alias_return_thunk+0x5/0xfbef5 [+0,000018] ksmbd_conn_handler_loop+0x94e/0xf10 [ksmbd] ... I'll also add reclassify to the smbdirect socket code [1], but I think it's better to have it in both direction (below and above the RDMA layer). [1] https://git.samba.org/?p=metze/linux/wip.git;a=shortlog;h=refs/heads/master-ipproto-smbdirect Cc: Zhu Yanjun <zyjzyj2000@gmail.com> Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Leon Romanovsky <leon@kernel.org> Cc: linux-rdma@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-cifs@vger.kernel.org Signed-off-by: Stefan Metzmacher <metze@samba.org> Link: https://patch.msgid.link/20251127105614.2040922-1-metze@samba.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-11-27net: stmmac: dwmac: Disable flushing frames on Rx Buffer UnavailableRohan G Thomas
In Store and Forward mode, flushing frames when the receive buffer is unavailable, can cause the MTL Rx FIFO to go out of sync. This results in buffering of a few frames in the FIFO without triggering Rx DMA from transferring the data to the system memory until another packet is received. Once the issue happens, for a ping request, the packet is forwarded to the system memory only after we receive another packet and hece we observe a latency equivalent to the ping interval. 64 bytes from 192.168.2.100: seq=1 ttl=64 time=1000.344 ms Also, we can observe constant gmacgrp_debug register value of 0x00000120, which indicates "Reading frame data". The issue is not reproducible after disabling frame flushing when Rx buffer is unavailable. But in that case, the Rx DMA enters a suspend state due to buffer unavailability. To resume operation, software must write to the receive_poll_demand register after adding new descriptors, which reactivates the Rx DMA. This issue is observed in the socfpga platforms which has dwmac1000 IP like Arria 10, Cyclone V and Agilex 7. Issue is reproducible after running iperf3 server at the DUT for UDP lower packet sizes. Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com> Reviewed-by: Matthew Gerlach <matthew.gerlach@altera.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20251126-a10_ext_fix-v1-1-d163507f646f@altera.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-27platform/x86/amd/pmf: Use devm_mutex_init() for mutex initializationShyam Sundar S K
Replace mutex_init() with the devm_mutex_init(), to ensure proper mutex cleanup during probe failure and driver removal. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20251119085813.546813-2-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-11-27platform/x86/amd/pmf: Add BIOS_INPUTS_MAX macro to replace hardcoded array sizeShyam Sundar S K
Define a new macro BIOS_INPUTS_MAX, to represent the maximum number of BIOS input values. Replace hardcoded array sizes in relevant structures with this macro to improve readability and maintainability. Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Tested-by: Yijun Shen <Yijun.Shen@Dell.com> Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20251119085813.546813-1-Shyam-sundar.S-k@amd.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-11-27iommupt: Avoid a compiler bug with sw_bitJason Gunthorpe
gcc 13, in some cases, gets confused if the __builtin_constant_p() is inside the switch. It thinks that bitnr can have the value max+1 and fails. Lift the check outside the switch to avoid it. Fixes: ef7bfe5bbffd ("iommupt/x86: Support SW bits and permit PT_FEAT_DMA_INCOHERENT") Fixes: 5448c1558f60 ("iommupt: Add the Intel VT-d second stage page table format") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511242012.I7g504Ab-lkp@intel.com/ Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-27selftests: af_unix: remove unused stdlib.h includeSunday Adelodun
The unix_connreset.c test included <stdlib.h>, but no symbol from that header is used. This causes a fatal build error under certain linux-next configurations where stdlib.h is not available. Remove the unused include to fix the build. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202511221800.hcgCKvVa-lkp@intel.com/ Signed-off-by: Sunday Adelodun <adelodunolaoluwa@yahoo.com> Link: https://patch.msgid.link/20251125113648.25903-1-adelodunolaoluwa@yahoo.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-27spi: dt-bindings: airoha: add compatible for EN7523Mikhail Kshevetskiy
Add dt-bindings documentation of SPI NAND controller for Airoha EN7523 SoC platform. Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20251125234047.1101985-3-mikhail.kshevetskiy@iopsys.eu Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-27spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was short to GNDMikhail Kshevetskiy
Airoha EN7523 specific bug -------------------------- We found that some serial console may pull TX line to GROUND during board boot time. Airoha uses TX line as one of its bootstrap pins. On the EN7523 SoC this may lead to booting in RESERVED boot mode. It was found that some flashes operates incorrectly in RESERVED mode. Micron and Skyhigh flashes are definitely affected by the issue, Winbond flashes are not affected. Details: -------- DMA reading of odd pages on affected flashes operates incorrectly. Page reading offset (start of the page) on hardware level is replaced by 0x10. Thus results in incorrect data reading. As result OS loading becomes impossible. Usage of UBI make things even worse. On attaching, UBI will detects corruptions (because of wrong reading of odd pages) and will try to recover. For recovering UBI will erase and write 'damaged' blocks with a valid information. This will destroy all UBI data. Non-DMA reading is OK. This patch detects booting in reserved mode, turn off DMA and print big fat warning. It's worth noting that the boot configuration is preserved across reboots. Therefore, to boot normally, you should do the following: - disconnect the serial console from the board, - power cycle the board. Fixes: a403997c12019 ("spi: airoha: add SPI-NAND Flash controller driver") Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Link: https://patch.msgid.link/20251125234047.1101985-2-mikhail.kshevetskiy@iopsys.eu Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-27firmware: cs_dsp: Use kvzalloc() to allocate control cachesRichard Fitzgerald
Use kvzalloc() instead of kzalloc() to allocate memory to cache the content of a firmware control. Most firmware controls are only small, typically a few bytes. But on some firmware there can be much larger controls for coefficient or model data. The overhead of kvzalloc() is negligible because most control allocs can be satisfied by the normal kmalloc() that kvzalloc() will try first. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20251127103947.1094934-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-27firmware: cs_dsp: Take pwr_lock around reading controls debugfsRichard Fitzgerald
In cs_dsp_debugfs_read_controls_show() take the pwr_lock mutex around the list walk. This protects against debugfs returning a partial set of new controls if those controls are being added to the list while it is being walked. Controls are never deleted from this list, and are only added to the end of the list. So there was never a danger of following a stale pointer to garbage. The worst case was that the printed list is truncated if it saw an entry that was the list end just before a new entry was appended to the list. With the original code, the truncated list from the debugfs could show only _some_ of the new entries. This could be confusing because it appears that some new entries are missing. Adding the mutex means that the debugfs read provides an atomic view. Either it shows the old content before any of the new controls were added; or it shows the new content after all the new controls are added. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20251127113238.1251352-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-27ASoC: Intel: catpt: Do not block the system from suspendingCezary Rojewski
Even if something goes wrong when performing suspend on DSP, from the system perspective the component is not critical enough to block the suspend operation entirely. Leaving recovery to next resume() suffices. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/20251126095523.3925364-7-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-27ASoC: Intel: catpt: Do not ignore errors on runtime resumeCezary Rojewski
If pm_runtime_resume_and_get() fails, follow up pm_runtime_xxx() operate on device in erroneous state. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/20251126095523.3925364-6-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-27ASoC: Intel: catpt: Fix probing order of driver componentsCezary Rojewski
catpt_dai_pcm_new() is called during the bring up sequence of the machine board device which is a different device to the parent (DSP) device yet utilizes pm_runtime_xxx() against it in order to send IPCs. If the parent's pm_runtime is not configured before that happens, errors will occur. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20251126095523.3925364-5-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-27ASoC: Intel: catpt: Fix error path in hw_params()Cezary Rojewski
Do not leave any resources hanging on the DSP side if applying user settings fails. Fixes: 768a3a3b327d ("ASoC: Intel: catpt: Optimize applying user settings") Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20251126095523.3925364-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-27ASoC: Intel: catpt: Switch to resource_xxx() APICezary Rojewski
There is a number of interfaces available for manipulating instances of struct resource. To improve readability, move away from manual editing in favor of the common interface. While at it, adjust spacing so that both code blocks, while found in separate functions, looks cohesive. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20251126095523.3925364-3-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-27ASoC: Intel: catpt: Fix offset checksCezary Rojewski
Verify if the entire block is found within DRAM, not just the start of it. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20251126095523.3925364-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-27spi: nxp-fspi: Propagate fwnode in ACPI case as wellAndy Shevchenko
Propagate fwnode of the ACPI device to the SPI controller Linux device. Currently only OF case propagates fwnode to the controller. While at it, replace several calls to dev_fwnode() with a single one cached in a local variable, and unify checks for fwnode type by using is_*_node() APIs. Fixes: 55ab8487e01d ("spi: spi-nxp-fspi: Add ACPI support") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Haibo Chen <haibo.chen@nxp.com> Link: https://patch.msgid.link/20251126202501.2319679-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-27regulator: rtq2208: Correct LDO2 logic judgment bitsChiYuan Huang
The LDO2 judgement bit position should be 7, not 6. Cc: stable@vger.kernel.org Reported-by: Yoon Dong Min <dm.youn@telechips.com> Fixes: b65439d90150 ("regulator: rtq2208: Fix the LDO DVS capability") Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://patch.msgid.link/faadb009f84b88bfcabe39fc5009c7357b00bbe2.1764209258.git.cy_huang@richtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-27regulator: rtq2208: Correct buck group2 phase mapping logicChiYuan Huang
Correct buck group2 H and F mapping logic. Cc: stable@vger.kernel.org Reported-by: Yoon Dong Min <dm.youn@telechips.com> Fixes: 1742e7e978ba ("regulator: rtq2208: Fix incorrect buck converter phase mapping") Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://patch.msgid.link/8527ae02a72b754d89b7580a5fe7474d6f80f5c3.1764209258.git.cy_huang@richtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-27configfs: Constify ct_item_ops in struct config_item_typeChristophe JAILLET
Make 'ct_item_ops' const in struct config_item_type. This allows constification of many structures which hold some function pointers. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/f43cb57418a7f59e883be8eedc7d6abe802a2094.1761390472.git.christophe.jaillet@wanadoo.fr Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-11-27configfs: Constify ct_group_ops in struct config_item_typeChristophe JAILLET
Make 'ct_group_ops' const in struct config_item_type. This allows constification of many structures which hold some function pointers. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/6b720cf407e8a6d30f35beb72e031b2553d1ab7e.1761390472.git.christophe.jaillet@wanadoo.fr Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-11-27Merge branch 'net-fec-fix-some-ptp-related-issues'Paolo Abeni
Wei Fang says: ==================== net: fec: fix some PTP related issues There are some issues which were introduced by the commit 350749b909bf ("net: fec: Add support for periodic output signal of PPS"). See each patch for more details. ==================== Link: https://patch.msgid.link/20251125085210.1094306-1-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-27net: fec: do not register PPS event for PEROUTWei Fang
There are currently two situations that can trigger the PTP interrupt, one is the PPS event, the other is the PEROUT event. However, the irq handler fec_pps_interrupt() does not check the irq event type and directly registers a PPS event into the system, but the event may be a PEROUT event. This is incorrect because PEROUT is an output signal, while PPS is the input of the kernel PPS system. Therefore, add a check for the event type, if pps_enable is true, it means that the current event is a PPS event, and then the PPS event is registered. Fixes: 350749b909bf ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20251125085210.1094306-5-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-27net: fec: do not allow enabling PPS and PEROUT simultaneouslyWei Fang
In the current driver, PPS and PEROUT use the same channel to generate the events, so they cannot be enabled at the same time. Otherwise, the later configuration will overwrite the earlier configuration. Therefore, when configuring PPS, the driver will check whether PEROUT is enabled. Similarly, when configuring PEROUT, the driver will check whether PPS is enabled. Fixes: 350749b909bf ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20251125085210.1094306-4-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-27net: fec: do not update PEROUT if it is enabledWei Fang
If the previously set PEROUT is already active, updating it will cause the new PEROUT to start immediately instead of at the specified time. This is because fep->reload_period is updated whithout check whether the PEROUT is enabled, and the old PEROUT is not disabled. Therefore, the pulse period will be updated immediately in the pulse interrupt handler fec_pps_interrupt(). Currently, the driver does not support directly updating PEROUT and it will make the logic be more complicated. To fix the current issue, add a check before enabling the PEROUT, the driver will return an error if PEROUT is enabled. If users wants to update a new PEROUT, they should disable the old PEROUT first. Fixes: 350749b909bf ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20251125085210.1094306-3-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-27net: fec: cancel perout_timer when PEROUT is disabledWei Fang
The PEROUT allows the user to set a specified future time to output the periodic signal. If the future time is far from the current time, the FEC driver will use hrtimer to configure PEROUT one second before the future time. However, the hrtimer will not be canceled if the PEROUT is disabled before the hrtimer expires. So the PEROUT will be configured when the hrtimer expires, which is not as expected. Therefore, cancel the hrtimer in fec_ptp_pps_disable() to fix this issue. Fixes: 350749b909bf ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20251125085210.1094306-2-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-27net: mctp: unconditionally set skb->dev on dst outputJeremy Kerr
On transmit, we are currently relying on skb->dev being set by mctp_local_output() when we first set up the skb destination fields. However, forwarded skbs do not use the local_output path, so will retain their incoming netdev as their ->dev on tx. This does not work when we're forwarding between interfaces. Set skb->dev unconditionally in the transmit path, to allow for proper forwarding. We keep the skb->dev initialisation in mctp_local_output(), as we use it for fragmentation. Fixes: 269936db5eb3 ("net: mctp: separate routing database from routing operations") Suggested-by: Vince Chang <vince_chang@aspeedtech.com> Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20251125-dev-forward-v1-1-54ecffcd0616@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-27RDMA/siw: reclassify sockets in order to avoid false positives from lockdepStefan Metzmacher
While developing IPPROTO_SMBDIRECT support for the code under fs/smb/common/smbdirect [1], I noticed false positives like this: [T79] ====================================================== [T79] WARNING: possible circular locking dependency detected [T79] 6.18.0-rc4-metze-kasan-lockdep.01+ #1 Tainted: G OE [T79] ------------------------------------------------------ [T79] kworker/2:0/79 is trying to acquire lock: [T79] ffff88801f968278 (sk_lock-AF_INET){+.+.}-{0:0}, at: sock_set_reuseaddr+0x14/0x70 [T79] but task is already holding lock: [T79] ffffffffc10f7230 (lock#9){+.+.}-{4:4}, at: rdma_listen+0x3d2/0x740 [rdma_cm] [T79] which lock already depends on the new lock. [T79] the existing dependency chain (in reverse order) is: [T79] -> #1 (lock#9){+.+.}-{4:4}: [T79] __lock_acquire+0x535/0xc30 [T79] lock_acquire.part.0+0xb3/0x240 [T79] lock_acquire+0x60/0x140 [T79] __mutex_lock+0x1af/0x1c10 [T79] mutex_lock_nested+0x1b/0x30 [T79] cma_get_port+0xba/0x7d0 [rdma_cm] [T79] rdma_bind_addr_dst+0x598/0x9a0 [rdma_cm] [T79] cma_bind_addr+0x107/0x320 [rdma_cm] [T79] rdma_resolve_addr+0xa3/0x830 [rdma_cm] [T79] destroy_lease_table+0x12b/0x420 [ksmbd] [T79] ksmbd_NTtimeToUnix+0x3e/0x80 [ksmbd] [T79] ndr_encode_posix_acl+0x6e9/0xab0 [ksmbd] [T79] ndr_encode_v4_ntacl+0x53/0x870 [ksmbd] [T79] __sys_connect_file+0x131/0x1c0 [T79] __sys_connect+0x111/0x140 [T79] __x64_sys_connect+0x72/0xc0 [T79] x64_sys_call+0xe7d/0x26a0 [T79] do_syscall_64+0x93/0xff0 [T79] entry_SYSCALL_64_after_hwframe+0x76/0x7e [T79] -> #0 (sk_lock-AF_INET){+.+.}-{0:0}: [T79] check_prev_add+0xf3/0xcd0 [T79] validate_chain+0x466/0x590 [T79] __lock_acquire+0x535/0xc30 [T79] lock_acquire.part.0+0xb3/0x240 [T79] lock_acquire+0x60/0x140 [T79] lock_sock_nested+0x3b/0xf0 [T79] sock_set_reuseaddr+0x14/0x70 [T79] siw_create_listen+0x145/0x1540 [siw] [T79] iw_cm_listen+0x313/0x5b0 [iw_cm] [T79] cma_iw_listen+0x271/0x3c0 [rdma_cm] [T79] rdma_listen+0x3b1/0x740 [rdma_cm] [T79] cma_listen_on_dev+0x46a/0x750 [rdma_cm] [T79] rdma_listen+0x4b0/0x740 [rdma_cm] [T79] ksmbd_rdma_init+0x12b/0x270 [ksmbd] [T79] ksmbd_conn_transport_init+0x26/0x70 [ksmbd] [T79] server_ctrl_handle_work+0x1e5/0x280 [ksmbd] [T79] process_one_work+0x86c/0x1930 [T79] worker_thread+0x6f0/0x11f0 [T79] kthread+0x3ec/0x8b0 [T79] ret_from_fork+0x314/0x400 [T79] ret_from_fork_asm+0x1a/0x30 [T79] other info that might help us debug this: [T79] Possible unsafe locking scenario: [T79] CPU0 CPU1 [T79] ---- ---- [T79] lock(lock#9); [T79] lock(sk_lock-AF_INET); [T79] lock(lock#9); [T79] lock(sk_lock-AF_INET); [T79] *** DEADLOCK *** [T79] 5 locks held by kworker/2:0/79: [T79] #0: ffff88800120b158 ((wq_completion)events_long){+.+.}-{0:0}, at: process_one_work+0xfca/0x1930 [T79] #1: ffffc9000474fd00 ((work_completion)(&ctrl->ctrl_work)) {+.+.}-{0:0}, at: process_one_work+0x804/0x1930 [T79] #2: ffffffffc11307d0 (ctrl_lock){+.+.}-{4:4}, at: server_ctrl_handle_work+0x21/0x280 [ksmbd] [T79] #3: ffffffffc11347b0 (init_lock){+.+.}-{4:4}, at: ksmbd_conn_transport_init+0x18/0x70 [ksmbd] [T79] #4: ffffffffc10f7230 (lock#9){+.+.}-{4:4}, at: rdma_listen+0x3d2/0x740 [rdma_cm] [T79] stack backtrace: [T79] CPU: 2 UID: 0 PID: 79 Comm: kworker/2:0 Kdump: loaded Tainted: G OE 6.18.0-rc4-metze-kasan-lockdep.01+ #1 PREEMPT(voluntary) [T79] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [T79] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [T79] Workqueue: events_long server_ctrl_handle_work [ksmbd] ... [T79] print_circular_bug+0xfd/0x130 [T79] check_noncircular+0x150/0x170 [T79] check_prev_add+0xf3/0xcd0 [T79] validate_chain+0x466/0x590 [T79] __lock_acquire+0x535/0xc30 [T79] ? srso_alias_return_thunk+0x5/0xfbef5 [T79] lock_acquire.part.0+0xb3/0x240 [T79] ? sock_set_reuseaddr+0x14/0x70 [T79] ? srso_alias_return_thunk+0x5/0xfbef5 [T79] ? __kasan_check_write+0x14/0x30 [T79] ? srso_alias_return_thunk+0x5/0xfbef5 [T79] ? apparmor_socket_post_create+0x180/0x700 [T79] lock_acquire+0x60/0x140 [T79] ? sock_set_reuseaddr+0x14/0x70 [T79] lock_sock_nested+0x3b/0xf0 [T79] ? sock_set_reuseaddr+0x14/0x70 [T79] sock_set_reuseaddr+0x14/0x70 [T79] siw_create_listen+0x145/0x1540 [siw] [T79] ? srso_alias_return_thunk+0x5/0xfbef5 [T79] ? local_clock_noinstr+0xe/0xd0 [T79] ? __pfx_siw_create_listen+0x10/0x10 [siw] [T79] ? trace_preempt_on+0x4c/0x130 [T79] ? __raw_spin_unlock_irqrestore+0x4a/0x90 [T79] ? srso_alias_return_thunk+0x5/0xfbef5 [T79] ? preempt_count_sub+0x52/0x80 [T79] iw_cm_listen+0x313/0x5b0 [iw_cm] [T79] cma_iw_listen+0x271/0x3c0 [rdma_cm] [T79] ? srso_alias_return_thunk+0x5/0xfbef5 [T79] rdma_listen+0x3b1/0x740 [rdma_cm] [T79] ? _raw_spin_unlock+0x2c/0x60 [T79] ? __pfx_rdma_listen+0x10/0x10 [rdma_cm] [T79] ? rdma_restrack_add+0x12c/0x630 [ib_core] [T79] ? srso_alias_return_thunk+0x5/0xfbef5 [T79] cma_listen_on_dev+0x46a/0x750 [rdma_cm] [T79] rdma_listen+0x4b0/0x740 [rdma_cm] [T79] ? __pfx_rdma_listen+0x10/0x10 [rdma_cm] [T79] ? cma_get_port+0x30d/0x7d0 [rdma_cm] [T79] ? srso_alias_return_thunk+0x5/0xfbef5 [T79] ? rdma_bind_addr_dst+0x598/0x9a0 [rdma_cm] [T79] ksmbd_rdma_init+0x12b/0x270 [ksmbd] [T79] ? __pfx_ksmbd_rdma_init+0x10/0x10 [ksmbd] [T79] ? srso_alias_return_thunk+0x5/0xfbef5 [T79] ? srso_alias_return_thunk+0x5/0xfbef5 [T79] ? register_netdevice_notifier+0x1dc/0x240 [T79] ksmbd_conn_transport_init+0x26/0x70 [ksmbd] [T79] server_ctrl_handle_work+0x1e5/0x280 [ksmbd] [T79] process_one_work+0x86c/0x1930 [T79] ? __pfx_process_one_work+0x10/0x10 [T79] ? srso_alias_return_thunk+0x5/0xfbef5 [T79] ? assign_work+0x16f/0x280 [T79] worker_thread+0x6f0/0x11f0 I was not able to reproduce this as I was testing with various runs switching siw and rxe as well as IPPROTO_SMBDIRECT sockets, while the above stack used siw with the non IPPROTO_SMBDIRECT patches [1]. Even if this patch doesn't solve the above I think it's a good idea to reclassify the sockets used by siw, I also send patches for rxe to reclassify, as well as my IPPROTO_SMBDIRECT socket patches [1] will do it, this should minimize potential false positives. [1] https://git.samba.org/?p=metze/linux/wip.git;a=shortlog;h=refs/heads/master-ipproto-smbdirect Cc: Bernard Metzler <bernard.metzler@linux.dev> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Leon Romanovsky <leon@kernel.org> Cc: linux-rdma@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-cifs@vger.kernel.org Signed-off-by: Stefan Metzmacher <metze@samba.org> Link: https://patch.msgid.link/20251126150842.1837072-1-metze@samba.org Acked-by: Bernard Metzler <bernard.metzler@linux.dev> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-11-27platform/x86: serial-multi-instantiate: Add IRQ_RESOURCE_OPT for IRQ missing ↵Baojun Xu
projects The tas2781-hda supports multi-projects. In some projects, GpioInt() was dropped due to no IRQ connection. See the example code below: Device (SPKR) { Name (_ADR, One) Name (_HID, "TXNW2781") Method (_CRS, 0, NotSerialized) { Name (RBUF, ResourceTemplate () { I2cSerialBusV2 (0x0038, ...) I2cSerialBusV2 (0x0039, ...) // GpioInt (Edge, ...) { 0x0000 } //"GpioInt (...) {}" was commented out due to no IRQ connection. }) Return (RBUF) } } But in smi_i2c_probe(), smi_spi_probe() (serial-multi-instantiate.c), if looking for IRQ by smi_get_irq() fails, it will return an error, will not add new device, and cause smi_probe() to fail: [ 2.356546] Serial bus multi instantiate pseudo device driver TXNW2781:00: error -ENXIO: IRQ index 0 not found [ 2.356561] Serial bus multi instantiate pseudo device driver TXNW2781:00: error -ENXIO: Error requesting irq at index 0 So, we need to add an exception case for these situations. BTW, this patch will take effect on both I2C and SPI devices. Signed-off-by: Baojun Xu <baojun.xu@ti.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20251126141434.11110-1-baojun.xu@ti.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-11-27debugfs: Remove broken no-mount modeAaron Thompson
debugfs access modes were added in Linux 5.10 (Dec 2020) [1], but the no-mount mode has behaved effectively the same as the off mode since Linux 5.12 (Apr 2021) [2]. The only difference is the specific error code returned by the debugfs_create_* functions, which is -ENOENT in no-mount mode and -EPERM in off mode. Given that no-mount hasn't worked for several years with no complaints, just remove it. [1] a24c6f7bc923 ("debugfs: Add access restriction option") [2] bc6de804d36b ("debugfs: be more robust at handling improper input in debugfs_lookup()") 56348560d495 ("debugfs: do not attempt to create a new file before the filesystem is initalized") Signed-off-by: Aaron Thompson <dev@aaront.org> Link: https://patch.msgid.link/20251120102222.18371-3-dev@null.aaront.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-27debugfs: Remove redundant access mode checksAaron Thompson
debugfs_get_tree() can only be called if debugfs itself calls simple_pin_fs() or register_filesystem(), and those call paths also check the access mode. debugfs_start_creating() checks the access mode so the checks in the debugfs_create_* functions are unnecessary. An upcoming change will affect debugfs_allow, so doing this cleanup first will make that change simpler. Signed-off-by: Aaron Thompson <dev@aaront.org> Link: https://patch.msgid.link/20251120102222.18371-2-dev@null.aaront.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.51.0) at 2026-11-10 11:58:53 +0000