commit a2b47f77e740a21dbdcb12e2f2ca3c840299545a Author: Greg Kroah-Hartman Date: Thu Jun 19 15:41:08 2025 +0200 Linux 6.15.3 Link: https://lore.kernel.org/r/20250617152451.485330293@linuxfoundation.org Tested-by: Christian Heusel Tested-by: Florian Fainelli Tested-by: Ronald Warsow Tested-by: Salvatore Bonaccorso Tested-by: Luna Jernberg Tested-by: Shuah Khan Tested-By: Achill Gilgenast Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Takeshi Ogasawara Tested-by: Peter Schneider Tested-by: Linux Kernel Functional Testing Tested-by: Hardik Garg Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman commit c12905482b621a0fa041ce4c4abe5e0cb0d2f744 Author: Arnd Bergmann Date: Mon May 5 07:24:52 2025 +0200 thermal/drivers/mediatek/lvts: Remove unused lvts_debugfs_exit commit 3159c96ac2cb3a104ce8ee5b8a4afe98e4b8fcad upstream. When debugfs is disabled, the function has no reference any more: drivers/thermal/mediatek/lvts_thermal.c:266:13: error: 'lvts_debugfs_exit' defined but not used [-Werror=unused-function] 266 | static void lvts_debugfs_exit(struct lvts_domain *lvts_td) { } | ^~~~~~~~~~~~~~~~~ Fixes: ef280c17a840 ("thermal/drivers/mediatek/lvts: Fix debugfs unregister on failure") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20250505052502.1812867-1-arnd@kernel.org Signed-off-by: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman commit 41ccd0006344dbe67c5c1fbdd5c6efc622e66314 Author: Andrew Price Date: Wed May 28 16:02:37 2025 +0100 gfs2: Don't clear sb->s_fs_info in gfs2_sys_fs_add commit 9126d2754c5e5d1818765811a10af0a14cf1fa0a upstream. When gfs2_sys_fs_add() fails, it sets sb->s_fs_info to NULL on its error path (see commit 0d515210b696 ("GFS2: Add kobject release method")). The intention seems to be to prevent dereferencing sb->s_fs_info once the object pointed to has been deallocated, but that would be better achieved by setting the pointer to NULL in free_sbd(). As a consequence, when the call to gfs2_sys_fs_add() fails in gfs2_fill_super(), sdp = GFS2_SB(inode) will evaluate to NULL in iput() -> gfs2_drop_inode(), and accessing sdp->sd_flags will be a NULL pointer dereference. Fix that by only setting sb->s_fs_info to NULL when actually freeing the object pointed to in free_sbd(). Fixes: ae9f3bd8259a ("gfs2: replace sd_aspace with sd_inode") Reported-by: syzbot+b12826218502df019f9d@syzkaller.appspotmail.com Signed-off-by: Andrew Price Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit a0c3c47f6b1bb613c74d4d1e64c1dd2d31bb60e5 Author: Kees Cook Date: Fri May 30 12:06:47 2025 -0700 overflow: Introduce __DEFINE_FLEX for having no initializer commit 5c78e793f78732b60276401f75cc1a101f9ad121 upstream. While not yet in the tree, there is a proposed patch[1] that was depending on the prior behavior of _DEFINE_FLEX, which did not have an explicit initializer. Provide this via __DEFINE_FLEX now, which can also have attributes applied (e.g. __uninitialized). Examples of the resulting initializer behaviors can be seen here: https://godbolt.org/z/P7Go8Tr33 Link: https://lore.kernel.org/netdev/20250520205920.2134829-9-anthony.l.nguyen@intel.com [1] Fixes: 47e36ed78406 ("overflow: Fix direct struct member initialization in _DEFINE_FLEX()") Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 4c6b328f96de18346abb06bc9fe0b8312a7366b9 Author: Oliver Neukum Date: Wed May 28 13:03:54 2025 +0200 net: usb: aqc111: debug info before sanitation commit d3faab9b5a6a0477d69c38bd11c43aa5e936f929 upstream. If we sanitize error returns, the debug statements need to come before that so that we don't lose information. Signed-off-by: Oliver Neukum Fixes: 405b0d610745 ("net: usb: aqc111: fix error handling of usbnet read calls") Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bb0507bbb1be74896666dbed71c8cdf1eb277436 Author: Arnd Bergmann Date: Fri May 23 14:09:43 2025 +0200 usb: misc: onboard_usb_dev: fix build warning for CONFIG_USB_ONBOARD_DEV_USB5744=n commit 662a9ece32add94469138ae66999ee16cb37a531 upstream. When the USB5744 option is disabled, the onboard_usb driver warns about unused functions: drivers/usb/misc/onboard_usb_dev.c:358:12: error: 'onboard_dev_5744_i2c_write_byte' defined but not used [-Werror=unused-function] 358 | static int onboard_dev_5744_i2c_write_byte(struct i2c_client *client, u16 addr, u8 data) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/usb/misc/onboard_usb_dev.c:313:12: error: 'onboard_dev_5744_i2c_read_byte' defined but not used [-Werror=unused-function] 313 | static int onboard_dev_5744_i2c_read_byte(struct i2c_client *client, u16 addr, u8 *data) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Extend the #ifdef block a little further to cover all of these functions. Ideally we'd use use if(IS_ENABLED()) instead, but that doesn't currently work because the i2c_transfer() and i2c_smbus_write_word_data() function declarations are hidden when CONFIG_I2C is disabled. Fixes: 1143d41922c0 ("usb: misc: onboard_usb_dev: Fix usb5744 initialization sequence") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20250523120947.2170302-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman commit 523e4e0ade60b4d8e36c91062a882c36d7ab5b6a Author: Nícolas F. R. A. Prado Date: Wed May 14 08:36:06 2025 -0400 regulator: dt-bindings: mt6357: Drop fixed compatible requirement commit 9cfdd7752ba5f8cc9b8191e8c9aeeec246241fa4 upstream. Some of the regulators on the MT6357 PMIC currently reference the fixed-regulator dt-binding, which enforces the presence of a regulator-fixed compatible. However since all regulators on the MT6357 PMIC are handled by a single mt6357-regulator driver, probed through MFD, the compatibles don't serve any purpose. In fact they cause failures in the DT kselftest since they aren't probed by the fixed regulator driver as would be expected. Furthermore this is the only dt-binding in this family like this: mt6359-regulator and mt6358-regulator don't require those compatibles. Commit d77e89b7b03f ("arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles") removed the compatibles from Devicetree, but missed updating the binding, which still requires them, introducing dt-binding errors. Remove the compatible requirement by referencing the plain regulator dt-binding instead to fix the dt-binding errors. Fixes: d77e89b7b03f ("arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles") Signed-off-by: Nícolas F. R. A. Prado Link: https://patch.msgid.link/20250514-mt6357-regulator-fixed-compatibles-removal-bindings-v1-1-2421e9cc6cc7@collabora.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 917677d599e269bf0495e1a314f16232ed586b7b Author: Al Viro Date: Fri Jun 6 18:31:03 2025 -0400 do_move_mount(): split the checks in subtree-of-our-ns and entire-anon cases commit 290da20e333955637f00647d9fff7c6e3c0b61e0 upstream. ... and fix the breakage in anon-to-anon case. There are two cases acceptable for do_move_mount() and mixing checks for those is making things hard to follow. One case is move of a subtree in caller's namespace. * source and destination must be in caller's namespace * source must be detachable from parent Another is moving the entire anon namespace elsewhere * source must be the root of anon namespace * target must either in caller's namespace or in a suitable anon namespace (see may_use_mount() for details). * target must not be in the same namespace as source. It's really easier to follow if tests are *not* mixed together... Reviewed-by: Christian Brauner Fixes: 3b5260d12b1f ("Don't propagate mounts into detached trees") Reported-by: Allison Karlitskaya Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit c3e3a011adebe5cfb286c7bdc5ff2f202b21e568 Author: Eric Dumazet Date: Wed Jun 4 13:38:26 2025 +0000 calipso: unlock rcu before returning -EAFNOSUPPORT commit 3cae906e1a6184cdc9e4d260e4dbdf9a118d94ad upstream. syzbot reported that a recent patch forgot to unlock rcu in the error path. Adopt the convention that netlbl_conn_setattr() is already using. Fixes: 6e9f2df1c550 ("calipso: Don't call calipso functions for AF_INET sk.") Reported-by: syzbot Signed-off-by: Eric Dumazet Cc: Kuniyuki Iwashima Acked-by: Paul Moore Link: https://patch.msgid.link/20250604133826.1667664-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d70d0373f92b3b1bf8c777ad68462e8d9b2d936b Author: Xin Li (Intel) Date: Mon Jun 9 01:40:53 2025 -0700 x86/fred/signal: Prevent immediate repeat of single step trap on return from SIGTRAP handler commit e34dbbc85d64af59176fe59fad7b4122f4330fe2 upstream. Clear the software event flag in the augmented SS to prevent immediate repeat of single step trap on return from SIGTRAP handler if the trap flag (TF) is set without an external debugger attached. Following is a typical single-stepping flow for a user process: 1) The user process is prepared for single-stepping by setting RFLAGS.TF = 1. 2) When any instruction in user space completes, a #DB is triggered. 3) The kernel handles the #DB and returns to user space, invoking the SIGTRAP handler with RFLAGS.TF = 0. 4) After the SIGTRAP handler finishes, the user process performs a sigreturn syscall, restoring the original state, including RFLAGS.TF = 1. 5) Goto step 2. According to the FRED specification: A) Bit 17 in the augmented SS is designated as the software event flag, which is set to 1 for FRED event delivery of SYSCALL, SYSENTER, or INT n. B) If bit 17 of the augmented SS is 1 and ERETU would result in RFLAGS.TF = 1, a single-step trap will be pending upon completion of ERETU. In step 4) above, the software event flag is set upon the sigreturn syscall, and its corresponding ERETU would restore RFLAGS.TF = 1. This combination causes a pending single-step trap upon completion of ERETU. Therefore, another #DB is triggered before any user space instruction is executed, which leads to an infinite loop in which the SIGTRAP handler keeps being invoked on the same user space IP. Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") Suggested-by: H. Peter Anvin (Intel) Signed-off-by: Xin Li (Intel) Signed-off-by: Dave Hansen Tested-by: Sohil Mehta Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250609084054.2083189-2-xin%40zytor.com Signed-off-by: Greg Kroah-Hartman commit cb002d6c8f06d6061e84b2109cb84416107a9fb9 Author: Roman Kisel Date: Wed May 7 11:22:25 2025 -0700 x86/hyperv: Fix APIC ID and VP index confusion in hv_snp_boot_ap() commit 86c48271e0d60c82665e9fd61277002391efcef7 upstream. To start an application processor in SNP-isolated guest, a hypercall is used that takes a virtual processor index. The hv_snp_boot_ap() function uses that START_VP hypercall but passes as VP index to it what it receives as a wakeup_secondary_cpu_64 callback: the APIC ID. As those two aren't generally interchangeable, that may lead to hung APs if the VP index and the APIC ID don't match up. Update the parameter names to avoid confusion as to what the parameter is. Use the APIC ID to the VP index conversion to provide the correct input to the hypercall. Cc: stable@vger.kernel.org Fixes: 44676bb9d566 ("x86/hyperv: Add smp support for SEV-SNP guest") Signed-off-by: Roman Kisel Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20250507182227.7421-2-romank@linux.microsoft.com Signed-off-by: Wei Liu Message-ID: <20250507182227.7421-2-romank@linux.microsoft.com> Signed-off-by: Greg Kroah-Hartman commit 73cfcc8445585b8af7e18be3c9246b851fdf336c Author: Thomas Gleixner Date: Wed Feb 26 16:01:57 2025 +0100 x86/iopl: Cure TIF_IO_BITMAP inconsistencies commit 8b68e978718f14fdcb080c2a7791c52a0d09bc6d upstream. io_bitmap_exit() is invoked from exit_thread() when a task exists or when a fork fails. In the latter case the exit_thread() cleans up resources which were allocated during fork(). io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with a NULL pointer dereference. There are two issues, which lead to that problem: 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork(). 2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated. This happens when a kernel thread is created in the context of a user space thread, which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the failed fork() case this has no impact because kernel threads including IO workers never return to user space and therefore never invoke tss_update_io_bitmap(). Cure this by adding the missing cleanups and checks: 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task. 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share(). For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked with inconsistent state. Fixes: ea5f1cd7ab49 ("x86/ioperm: Remove bitmap if all permissions dropped") Reported-by: syzbot+e2b1803445d236442e54@syzkaller.appspotmail.com Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/87wmdceom2.ffs@tglx Signed-off-by: Greg Kroah-Hartman commit dd7ff7ae4de4d56942d1b504a43724c4342b7325 Author: Stefano Stabellini Date: Mon May 12 14:54:52 2025 -0700 xen/arm: call uaccess_ttbr0_enable for dm_op hypercall commit 7f9bbc1140ff8796230bc2634055763e271fd692 upstream. dm_op hypercalls might come from userspace and pass memory addresses as parameters. The memory addresses typically correspond to buffers allocated in userspace to hold extra hypercall parameters. On ARM, when CONFIG_ARM64_SW_TTBR0_PAN is enabled, they might not be accessible by Xen, as a result ioreq hypercalls might fail. See the existing comment in arch/arm64/xen/hypercall.S regarding privcmd_call for reference. For privcmd_call, Linux calls uaccess_ttbr0_enable before issuing the hypercall thanks to commit 9cf09d68b89a. We need to do the same for dm_op. This resolves the problem. Cc: stable@kernel.org Fixes: 9cf09d68b89a ("arm64: xen: Enable user access before a privcmd hvc call") Signed-off-by: Stefano Stabellini Reviewed-by: Juergen Gross Message-ID: Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 53244759c5ba564e6be6863c64f6c88045305bcb Author: Dave Chinner Date: Thu May 1 09:27:24 2025 +1000 xfs: don't assume perags are initialised when trimming AGs commit 23be716b1c4f3f3a6c00ee38d51a57ef7db9ef7d upstream. When running fstrim immediately after mounting a V4 filesystem, the fstrim fails to trim all the free space in the filesystem. It only trims the first extent in the by-size free space tree in each AG and then returns. If a second fstrim is then run, it runs correctly and the entire free space in the filesystem is iterated and discarded correctly. The problem lies in the setup of the trim cursor - it assumes that pag->pagf_longest is valid without either reading the AGF first or checking if xfs_perag_initialised_agf(pag) is true or not. As a result, when a filesystem is mounted without reading the AGF (e.g. a clean mount on a v4 filesystem) and the first operation is a fstrim call, pag->pagf_longest is zero and so the free extent search starts at the wrong end of the by-size btree and exits after discarding the first record in the tree. Fix this by deferring the initialisation of tcur->count to after we have locked the AGF and guaranteed that the perag is properly initialised. We trigger this on tcur->count == 0 after locking the AGF, as this will only occur on the first call to xfs_trim_gather_extents() for each AG. If we need to iterate, tcur->count will be set to the length of the record we need to restart at, so we can use this to ensure we only sample a valid pag->pagf_longest value for the iteration. Signed-off-by: Dave Chinner Reviewed-by: Bill O'Donnell Reviewed-by: Darrick J. Wong Fixes: 89cfa899608f ("xfs: reduce AGF hold times during fstrim operations") Cc: # v6.6 Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit ea97c04a29dc9f6e4d8623d445eb3cf63abf4f4c Author: Steven Rostedt Date: Tue May 27 10:58:20 2025 -0400 ring-buffer: Move cpus_read_lock() outside of buffer->mutex commit c98cc9797b7009308fff73d41bc1d08642dab77a upstream. Running a modified trace-cmd record --nosplice where it does a mmap of the ring buffer when '--nosplice' is set, caused the following lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 6.15.0-rc7-test-00002-gfb7d03d8a82f #551 Not tainted ------------------------------------------------------ trace-cmd/1113 is trying to acquire lock: ffff888100062888 (&buffer->mutex){+.+.}-{4:4}, at: ring_buffer_map+0x11c/0xe70 but task is already holding lock: ffff888100a5f9f8 (&cpu_buffer->mapping_lock){+.+.}-{4:4}, at: ring_buffer_map+0xcf/0xe70 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #5 (&cpu_buffer->mapping_lock){+.+.}-{4:4}: __mutex_lock+0x192/0x18c0 ring_buffer_map+0xcf/0xe70 tracing_buffers_mmap+0x1c4/0x3b0 __mmap_region+0xd8d/0x1f70 do_mmap+0x9d7/0x1010 vm_mmap_pgoff+0x20b/0x390 ksys_mmap_pgoff+0x2e9/0x440 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #4 (&mm->mmap_lock){++++}-{4:4}: __might_fault+0xa5/0x110 _copy_to_user+0x22/0x80 _perf_ioctl+0x61b/0x1b70 perf_ioctl+0x62/0x90 __x64_sys_ioctl+0x134/0x190 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #3 (&cpuctx_mutex){+.+.}-{4:4}: __mutex_lock+0x192/0x18c0 perf_event_init_cpu+0x325/0x7c0 perf_event_init+0x52a/0x5b0 start_kernel+0x263/0x3e0 x86_64_start_reservations+0x24/0x30 x86_64_start_kernel+0x95/0xa0 common_startup_64+0x13e/0x141 -> #2 (pmus_lock){+.+.}-{4:4}: __mutex_lock+0x192/0x18c0 perf_event_init_cpu+0xb7/0x7c0 cpuhp_invoke_callback+0x2c0/0x1030 __cpuhp_invoke_callback_range+0xbf/0x1f0 _cpu_up+0x2e7/0x690 cpu_up+0x117/0x170 cpuhp_bringup_mask+0xd5/0x120 bringup_nonboot_cpus+0x13d/0x170 smp_init+0x2b/0xf0 kernel_init_freeable+0x441/0x6d0 kernel_init+0x1e/0x160 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 -> #1 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2a/0xd0 ring_buffer_resize+0x610/0x14e0 __tracing_resize_ring_buffer.part.0+0x42/0x120 tracing_set_tracer+0x7bd/0xa80 tracing_set_trace_write+0x132/0x1e0 vfs_write+0x21c/0xe80 ksys_write+0xf9/0x1c0 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (&buffer->mutex){+.+.}-{4:4}: __lock_acquire+0x1405/0x2210 lock_acquire+0x174/0x310 __mutex_lock+0x192/0x18c0 ring_buffer_map+0x11c/0xe70 tracing_buffers_mmap+0x1c4/0x3b0 __mmap_region+0xd8d/0x1f70 do_mmap+0x9d7/0x1010 vm_mmap_pgoff+0x20b/0x390 ksys_mmap_pgoff+0x2e9/0x440 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: &buffer->mutex --> &mm->mmap_lock --> &cpu_buffer->mapping_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&cpu_buffer->mapping_lock); lock(&mm->mmap_lock); lock(&cpu_buffer->mapping_lock); lock(&buffer->mutex); *** DEADLOCK *** 2 locks held by trace-cmd/1113: #0: ffff888106b847e0 (&mm->mmap_lock){++++}-{4:4}, at: vm_mmap_pgoff+0x192/0x390 #1: ffff888100a5f9f8 (&cpu_buffer->mapping_lock){+.+.}-{4:4}, at: ring_buffer_map+0xcf/0xe70 stack backtrace: CPU: 5 UID: 0 PID: 1113 Comm: trace-cmd Not tainted 6.15.0-rc7-test-00002-gfb7d03d8a82f #551 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0x6e/0xa0 print_circular_bug.cold+0x178/0x1be check_noncircular+0x146/0x160 __lock_acquire+0x1405/0x2210 lock_acquire+0x174/0x310 ? ring_buffer_map+0x11c/0xe70 ? ring_buffer_map+0x11c/0xe70 ? __mutex_lock+0x169/0x18c0 __mutex_lock+0x192/0x18c0 ? ring_buffer_map+0x11c/0xe70 ? ring_buffer_map+0x11c/0xe70 ? function_trace_call+0x296/0x370 ? __pfx___mutex_lock+0x10/0x10 ? __pfx_function_trace_call+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 ? _raw_spin_unlock+0x2d/0x50 ? ring_buffer_map+0x11c/0xe70 ? ring_buffer_map+0x11c/0xe70 ? __mutex_lock+0x5/0x18c0 ring_buffer_map+0x11c/0xe70 ? do_raw_spin_lock+0x12d/0x270 ? find_held_lock+0x2b/0x80 ? _raw_spin_unlock+0x2d/0x50 ? rcu_is_watching+0x15/0xb0 ? _raw_spin_unlock+0x2d/0x50 ? trace_preempt_on+0xd0/0x110 tracing_buffers_mmap+0x1c4/0x3b0 __mmap_region+0xd8d/0x1f70 ? ring_buffer_lock_reserve+0x99/0xff0 ? __pfx___mmap_region+0x10/0x10 ? ring_buffer_lock_reserve+0x99/0xff0 ? __pfx_ring_buffer_lock_reserve+0x10/0x10 ? __pfx_ring_buffer_lock_reserve+0x10/0x10 ? bpf_lsm_mmap_addr+0x4/0x10 ? security_mmap_addr+0x46/0xd0 ? lock_is_held_type+0xd9/0x130 do_mmap+0x9d7/0x1010 ? 0xffffffffc0370095 ? __pfx_do_mmap+0x10/0x10 vm_mmap_pgoff+0x20b/0x390 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? 0xffffffffc0370095 ksys_mmap_pgoff+0x2e9/0x440 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fb0963a7de2 Code: 00 00 00 0f 1f 44 00 00 41 f7 c1 ff 0f 00 00 75 27 55 89 cd 53 48 89 fb 48 85 ff 74 3b 41 89 ea 48 89 df b8 09 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 76 5b 5d c3 0f 1f 00 48 8b 05 e1 9f 0d 00 64 RSP: 002b:00007ffdcc8fb878 EFLAGS: 00000246 ORIG_RAX: 0000000000000009 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb0963a7de2 RDX: 0000000000000001 RSI: 0000000000001000 RDI: 0000000000000000 RBP: 0000000000000001 R08: 0000000000000006 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffdcc8fbe68 R14: 00007fb096628000 R15: 00005633e01a5c90 The issue is that cpus_read_lock() is taken within buffer->mutex. The memory mapped pages are taken with the mmap_lock held. The buffer->mutex is taken within the cpu_buffer->mapping_lock. There's quite a chain with all these locks, where the deadlock can be fixed by moving the cpus_read_lock() outside the taking of the buffer->mutex. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Vincent Donnefort Link: https://lore.kernel.org/20250527105820.0f45d045@gandalf.local.home Fixes: 117c39200d9d7 ("ring-buffer: Introducing ring-buffer mapping functions") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 0fc9a295cd8e59c3636e97395e7c74a9c89fee42 Author: Dmitry Antipov Date: Fri Jun 6 14:22:42 2025 +0300 ring-buffer: Fix buffer locking in ring_buffer_subbuf_order_set() commit 40ee2afafc1d9fe3aa44a6fbe440d78a5c96a72e upstream. Enlarge the critical section in ring_buffer_subbuf_order_set() to ensure that error handling takes place with per-buffer mutex held, thus preventing list corruption and other concurrency-related issues. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Tzvetomir Stoyanov Link: https://lore.kernel.org/20250606112242.1510605-1-dmantipov@yandex.ru Reported-by: syzbot+05d673e83ec640f0ced9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=05d673e83ec640f0ced9 Fixes: f9b94daa542a8 ("ring-buffer: Set new size of the ring buffer sub page") Signed-off-by: Dmitry Antipov Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit e018053632bad8ee0752242c7d2cffb0bbf45404 Author: Steven Rostedt Date: Wed May 28 12:15:55 2025 -0400 ring-buffer: Do not trigger WARN_ON() due to a commit_overrun commit 4fc78a7c9ca994e1da5d3940704d4e8f0ea8c5e4 upstream. When reading a memory mapped buffer the reader page is just swapped out with the last page written in the write buffer. If the reader page is the same as the commit buffer (the buffer that is currently being written to) it was assumed that it should never have missed events. If it does, it triggers a WARN_ON_ONCE(). But there just happens to be one scenario where this can legitimately happen. That is on a commit_overrun. A commit overrun is when an interrupt preempts an event being written to the buffer and then the interrupt adds so many new events that it fills and wraps the buffer back to the commit. Any new events would then be dropped and be reported as "missed_events". In this case, the next page to read is the commit buffer and after the swap of the reader page, the reader page will be the commit buffer, but this time there will be missed events and this triggers the following warning: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1127 at kernel/trace/ring_buffer.c:7357 ring_buffer_map_get_reader+0x49a/0x780 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 1127 Comm: trace-cmd Not tainted 6.15.0-rc7-test-00004-g478bc2824b45-dirty #564 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:ring_buffer_map_get_reader+0x49a/0x780 Code: 00 00 00 48 89 fe 48 c1 ee 03 80 3c 2e 00 0f 85 ec 01 00 00 4d 3b a6 a8 00 00 00 0f 85 8a fd ff ff 48 85 c0 0f 84 55 fe ff ff <0f> 0b e9 4e fe ff ff be 08 00 00 00 4c 89 54 24 58 48 89 54 24 50 RSP: 0018:ffff888121787dc0 EFLAGS: 00010002 RAX: 00000000000006a2 RBX: ffff888100062800 RCX: ffffffff8190cb49 RDX: ffff888126934c00 RSI: 1ffff11020200a15 RDI: ffff8881010050a8 RBP: dffffc0000000000 R08: 0000000000000000 R09: ffffed1024d26982 R10: ffff888126934c17 R11: ffff8881010050a8 R12: ffff888126934c00 R13: ffff8881010050b8 R14: ffff888101005000 R15: ffff888126930008 FS: 00007f95c8cd7540(0000) GS:ffff8882b576e000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f95c8de4dc0 CR3: 0000000128452002 CR4: 0000000000172ef0 Call Trace: ? __pfx_ring_buffer_map_get_reader+0x10/0x10 tracing_buffers_ioctl+0x283/0x370 __x64_sys_ioctl+0x134/0x190 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f95c8de48db Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00 RSP: 002b:00007ffe037ba110 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe037bb2b0 RCX: 00007f95c8de48db RDX: 0000000000000000 RSI: 0000000000005220 RDI: 0000000000000006 RBP: 00007ffe037ba180 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe037bb6f8 R14: 00007f95c9065000 R15: 00005575c7492c90 irq event stamp: 5080 hardirqs last enabled at (5079): [] _raw_spin_unlock_irqrestore+0x50/0x70 hardirqs last disabled at (5080): [] _raw_spin_lock_irqsave+0x63/0x70 softirqs last enabled at (4182): [] handle_softirqs+0x552/0x710 softirqs last disabled at (4159): [] __irq_exit_rcu+0x107/0x210 ---[ end trace 0000000000000000 ]--- The above was triggered by running on a kernel with both lockdep and KASAN as well as kmemleak enabled and executing the following command: # perf record -o perf-test.dat -a -- trace-cmd record --nosplice -e all -p function hackbench 50 With perf interjecting a lot of interrupts and trace-cmd enabling all events as well as function tracing, with lockdep, KASAN and kmemleak enabled, it could cause an interrupt preempting an event being written to add enough events to wrap the buffer. trace-cmd was modified to have --nosplice use mmap instead of reading the buffer. The way to differentiate this case from the normal case of there only being one page written to where the swap of the reader page received that one page (which is the commit page), check if the tail page is on the reader page. The difference between the commit page and the tail page is that the tail page is where new writes go to, and the commit page holds the first write that hasn't been committed yet. In the case of an interrupt preempting the write of an event and filling the buffer, it would move the tail page but not the commit page. Have the warning only trigger if the tail page is also on the reader page, and also print out the number of events dropped by a commit overrun as that can not yet be safely added to the page so that the reader can see there were events dropped. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Cc: Vincent Donnefort Link: https://lore.kernel.org/20250528121555.2066527e@gandalf.local.home Fixes: fe832be05a8ee ("ring-buffer: Have mmapped ring buffer keep track of missed events") Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 411bf2a07a19b9f531ae5e43b05a036b41f59946 Author: Jens Axboe Date: Tue May 27 07:28:53 2025 -0600 mm/filemap: use filemap_end_dropbehind() for read invalidation commit 25b065a744ff0c1099bb357be1c40030b5a14c07 upstream. Use the filemap_end_dropbehind() helper rather than calling folio_unmap_invalidate() directly, as we need to check if the folio has been redirtied or marked for writeback once the folio lock has been re-acquired. Cc: stable@vger.kernel.org Reported-by: Trond Myklebust Fixes: 8026e49bff9b ("mm/filemap: add read support for RWF_DONTCACHE") Link: https://lore.kernel.org/linux-fsdevel/ba8a9805331ce258a622feaca266b163db681a10.camel@hammerspace.com/ Signed-off-by: Jens Axboe Link: https://lore.kernel.org/20250527133255.452431-3-axboe@kernel.dk Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 0a471b280481dd63f03801d3b122ff5f6092b981 Author: Jens Axboe Date: Tue May 27 07:28:52 2025 -0600 mm/filemap: gate dropbehind invalidate on folio !dirty && !writeback commit 095f627add86a6ddda2c2cfd563b0ee05d0172b2 upstream. It's possible for the folio to either get marked for writeback or redirtied. Add a helper, filemap_end_dropbehind(), which guards the folio_unmap_invalidate() call behind check for the folio being both non-dirty and not under writeback AFTER the folio lock has been acquired. Use this helper folio_end_dropbehind_write(). Cc: stable@vger.kernel.org Reported-by: Al Viro Fixes: fb7d3bc41493 ("mm/filemap: drop streaming/uncached pages when writeback completes") Link: https://lore.kernel.org/linux-fsdevel/20250525083209.GS2023217@ZenIV/ Signed-off-by: Jens Axboe Link: https://lore.kernel.org/20250527133255.452431-2-axboe@kernel.dk Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 02689a8961869170600321a9de819351cc9e69be Author: Al Viro Date: Fri May 23 19:20:36 2025 -0400 Don't propagate mounts into detached trees commit 3b5260d12b1fe76b566fe182de8abc586b827ed0 upstream. All versions up to 6.14 did not propagate mount events into detached tree. Shortly after 6.14 a merge of vfs-6.15-rc1.mount.namespace (130e696aa68b) has changed that. Unfortunately, that has caused userland regressions (reported in https://lore.kernel.org/all/CAOYeF9WQhFDe+BGW=Dp5fK8oRy5AgZ6zokVyTj1Wp4EUiYgt4w@mail.gmail.com/) Straight revert wouldn't be an option - in particular, the variant in 6.14 had a bug that got fixed in d1ddc6f1d9f0 ("fix IS_MNT_PROPAGATING uses") and we don't want to bring the bug back. This is a modification of manual revert posted by Christian, with changes needed to avoid reintroducing the breakage in scenario described in d1ddc6f1d9f0. Cc: stable@vger.kernel.org Reported-by: Allison Karlitskaya Tested-by: Allison Karlitskaya Acked-by: Christian Brauner Co-developed-by: Christian Brauner Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 38363fcc3e133648ce1d44aaa8cdae5add7a4bd5 Author: Matthew Wilcox (Oracle) Date: Wed Apr 2 15:59:55 2025 +0100 9p: Add a migrate_folio method commit 03ddd7725ed1b39cf9251e1a420559f25dac49b3 upstream. The migration code used to be able to migrate dirty 9p folios by writing them back using writepage. When the writepage method was removed, we neglected to add a migrate_folio method, which means that dirty 9p folios have been unmovable ever since. This reduced our success at defragmenting memory on machines which use 9p heavily. Fixes: 80105ed2fd27 (9p: Use netfslib read/write_iter) Cc: stable@vger.kernel.org Cc: David Howells Cc: v9fs@lists.linux.dev Signed-off-by: "Matthew Wilcox (Oracle)" Link: https://lore.kernel.org/r/20250402150005.2309458-2-willy@infradead.org Acked-by: Dominique Martinet Reviewed-by: David Howells Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 1970d34b48cbeceb0c765984c9a6bb204c77f16a Author: RD Babiera Date: Tue May 6 23:28:53 2025 +0000 usb: typec: tcpm: move tcpm_queue_vdm_unlocked to asynchronous work commit 324d45e53f1a36c88bc649dc39e0c8300a41be0a upstream. A state check was previously added to tcpm_queue_vdm_unlocked to prevent a deadlock where the DisplayPort Alt Mode driver would be executing work and attempting to grab the tcpm_lock while the TCPM was holding the lock and attempting to unregister the altmode, blocking on the altmode driver's cancel_work_sync call. Because the state check isn't protected, there is a small window where the Alt Mode driver could determine that the TCPM is in a ready state and attempt to grab the lock while the TCPM grabs the lock and changes the TCPM state to one that causes the deadlock. The callstack is provided below: [110121.667392][ C7] Call trace: [110121.667396][ C7] __switch_to+0x174/0x338 [110121.667406][ C7] __schedule+0x608/0x9f0 [110121.667414][ C7] schedule+0x7c/0xe8 [110121.667423][ C7] kernfs_drain+0xb0/0x114 [110121.667431][ C7] __kernfs_remove+0x16c/0x20c [110121.667436][ C7] kernfs_remove_by_name_ns+0x74/0xe8 [110121.667442][ C7] sysfs_remove_group+0x84/0xe8 [110121.667450][ C7] sysfs_remove_groups+0x34/0x58 [110121.667458][ C7] device_remove_groups+0x10/0x20 [110121.667464][ C7] device_release_driver_internal+0x164/0x2e4 [110121.667475][ C7] device_release_driver+0x18/0x28 [110121.667484][ C7] bus_remove_device+0xec/0x118 [110121.667491][ C7] device_del+0x1e8/0x4ac [110121.667498][ C7] device_unregister+0x18/0x38 [110121.667504][ C7] typec_unregister_altmode+0x30/0x44 [110121.667515][ C7] tcpm_reset_port+0xac/0x370 [110121.667523][ C7] tcpm_snk_detach+0x84/0xb8 [110121.667529][ C7] run_state_machine+0x4c0/0x1b68 [110121.667536][ C7] tcpm_state_machine_work+0x94/0xe4 [110121.667544][ C7] kthread_worker_fn+0x10c/0x244 [110121.667552][ C7] kthread+0x104/0x1d4 [110121.667557][ C7] ret_from_fork+0x10/0x20 [110121.667689][ C7] Workqueue: events dp_altmode_work [110121.667697][ C7] Call trace: [110121.667701][ C7] __switch_to+0x174/0x338 [110121.667710][ C7] __schedule+0x608/0x9f0 [110121.667717][ C7] schedule+0x7c/0xe8 [110121.667725][ C7] schedule_preempt_disabled+0x24/0x40 [110121.667733][ C7] __mutex_lock+0x408/0xdac [110121.667741][ C7] __mutex_lock_slowpath+0x14/0x24 [110121.667748][ C7] mutex_lock+0x40/0xec [110121.667757][ C7] tcpm_altmode_enter+0x78/0xb4 [110121.667764][ C7] typec_altmode_enter+0xdc/0x10c [110121.667769][ C7] dp_altmode_work+0x68/0x164 [110121.667775][ C7] process_one_work+0x1e4/0x43c [110121.667783][ C7] worker_thread+0x25c/0x430 [110121.667789][ C7] kthread+0x104/0x1d4 [110121.667794][ C7] ret_from_fork+0x10/0x20 Change tcpm_queue_vdm_unlocked to queue for tcpm_queue_vdm_work, which can perform the state check while holding the TCPM lock while the Alt Mode lock is no longer held. This requires a new struct to hold the vdm data, altmode_vdm_event. Fixes: cdc9946ea637 ("usb: typec: tcpm: enforce ready state when queueing alt mode vdm") Cc: stable Signed-off-by: RD Babiera Reviewed-by: Heikki Krogerus Reviewed-by: Badhri Jagan Sridharan Link: https://lore.kernel.org/r/20250506232853.1968304-2-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman commit 8b19df96cd08abba6672a855b5adcea1e9c26dde Author: Amit Sunil Dhamne Date: Fri May 2 16:57:03 2025 -0700 usb: typec: tcpm/tcpci_maxim: Fix bounds check in process_rx() commit 0736299d090f5c6a1032678705c4bc0a9511a3db upstream. Register read of TCPC_RX_BYTE_CNT returns the total size consisting of: PD message (pending read) size + 1 Byte for Frame Type (SOP*) This is validated against the max PD message (`struct pd_message`) size without accounting for the extra byte for the frame type. Note that the struct pd_message does not contain a field for the frame_type. This results in false negatives when the "PD message (pending read)" is equal to the max PD message size. Fixes: 6f413b559f86 ("usb: typec: tcpci_maxim: Chip level TCPC driver") Signed-off-by: Amit Sunil Dhamne Signed-off-by: Badhri Jagan Sridharan Reviewed-by: Kyle Tso Cc: stable Link: https://lore.kernel.org/stable/20250502-b4-new-fix-pd-rx-count-v1-1-e5711ed09b3d%40google.com Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250502-b4-new-fix-pd-rx-count-v1-1-e5711ed09b3d@google.com Signed-off-by: Greg Kroah-Hartman commit 1d494a703c160a8ddba75dc6be45dce66716419c Author: Mathias Nyman Date: Wed May 14 16:25:20 2025 +0300 usb: Flush altsetting 0 endpoints before reinitializating them after reset. commit 89bb3dc13ac29a563f4e4c555e422882f64742bd upstream. usb core avoids sending a Set-Interface altsetting 0 request after device reset, and instead relies on calling usb_disable_interface() and usb_enable_interface() to flush and reset host-side of those endpoints. xHCI hosts allocate and set up endpoint ring buffers and host_ep->hcpriv during usb_hcd_alloc_bandwidth() callback, which in this case is called before flushing the endpoint in usb_disable_interface(). Call usb_disable_interface() before usb_hcd_alloc_bandwidth() to ensure URBs are flushed before new ring buffers for the endpoints are allocated. Otherwise host driver will attempt to find and remove old stale URBs from a freshly allocated new ringbuffer. Cc: stable Fixes: 4fe0387afa89 ("USB: don't send Set-Interface after reset") Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250514132520.225345-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 918f7d19d91d839c6efd92c6e289f35e187030e3 Author: Pawel Laszczak Date: Tue May 13 06:54:03 2025 +0000 usb: cdnsp: Fix issue with detecting USB 3.2 speed commit 2852788cfbe9ca1ab68509d65804413871f741f9 upstream. Patch adds support for detecting SuperSpeedPlus Gen1 x2 and SuperSpeedPlus Gen2 x2 speed. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable Signed-off-by: Pawel Laszczak Acked-by: Peter Chen Link: https://lore.kernel.org/r/PH7PR07MB95387AD98EDCA695FECE52BADD96A@PH7PR07MB9538.namprd07.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit f7cbf42ac5d6549f7df535686f229700c9cd155a Author: Pawel Laszczak Date: Tue May 13 05:30:09 2025 +0000 usb: cdnsp: Fix issue with detecting command completion event commit f4ecdc352646f7d23f348e5c544dbe3212c94fc8 upstream. In some cases, there is a small-time gap in which CMD_RING_BUSY can be cleared by controller but adding command completion event to event ring will be delayed. As the result driver will return error code. This behavior has been detected on usbtest driver (test 9) with configuration including ep1in/ep1out bulk and ep2in/ep2out isoc endpoint. Probably this gap occurred because controller was busy with adding some other events to event ring. The CMD_RING_BUSY is cleared to '0' when the Command Descriptor has been executed and not when command completion event has been added to event ring. To fix this issue for this test the small delay is sufficient less than 10us) but to make sure the problem doesn't happen again in the future the patch introduces 10 retries to check with delay about 20us before returning error code. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable Signed-off-by: Pawel Laszczak Acked-by: Peter Chen Link: https://lore.kernel.org/r/PH7PR07MB9538AA45362ACCF1B94EE9B7DD96A@PH7PR07MB9538.namprd07.prod.outlook.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit ec490d9e3278b83b1d0735bfbb40d0a7566f187e Author: Jonathan Stroud Date: Fri May 16 18:02:40 2025 +0530 usb: misc: onboard_usb_dev: Fix usb5744 initialization sequence commit 1143d41922c0f87504f095417ba1870167970143 upstream. Introduce i2c APIs to read/write for proper configuration register programming. It ensures that read-modify-write sequence is performed and reserved bit in Runtime Flags 2 register are not touched. Also legacy smbus block write inserted an extra count value into the i2c data stream which breaks the register write on the usb5744. Switching to new read/write i2c APIs fixes both issues. Fixes: 6782311d04df ("usb: misc: onboard_usb_dev: add Microchip usb5744 SMBus programming support") Cc: stable Signed-off-by: Jonathan Stroud Co-developed-by: Radhey Shyam Pandey Signed-off-by: Radhey Shyam Pandey Link: https://lore.kernel.org/r/1747398760-284021-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman commit 115cf028ae4cc2045867ab667eb2a32b91a5fd9f Author: Jiri Slaby (SUSE) Date: Thu May 22 07:38:35 2025 +0200 tty: serial: 8250_omap: fix TX with DMA for am33xx commit b495021a973e2468497689bd3e29b736747b896f upstream. Commit 1788cf6a91d9 ("tty: serial: switch from circ_buf to kfifo") introduced an error in the TX DMA handling for 8250_omap. When the OMAP_DMA_TX_KICK flag is set, the "skip_byte" is pulled from the kfifo and emitted directly in order to start the DMA. While the kfifo is updated, dma->tx_size is not decreased. This leads to uart_xmit_advance() called in omap_8250_dma_tx_complete() advancing the kfifo by one too much. In practice, transmitting N bytes has been seen to result in the last N-1 bytes being sent repeatedly. This change fixes the problem by moving all of the dma setup after the OMAP_DMA_TX_KICK handling and using kfifo_len() instead of the DMA size for the 4-byte cutoff check. This slightly changes the behaviour at buffer wraparound, but it still transmits the correct bytes somehow. Now, the "skip_byte" would no longer be accounted to the stats. As previously, dma->tx_size included also this skip byte, up->icount.tx was updated by aforementioned uart_xmit_advance() in omap_8250_dma_tx_complete(). Fix this by using the uart_fifo_out() helper instead of bare kfifo_get(). Based on patch by Mans Rullgard Signed-off-by: "Jiri Slaby (SUSE)" Fixes: 1788cf6a91d9 ("tty: serial: switch from circ_buf to kfifo") Link: https://lore.kernel.org/all/20250506150748.3162-1-mans@mansr.com/ Reported-by: Mans Rullgard Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250522053835.3495975-1-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman commit 75b5313c80c39a26d27cbb602f968a05576c36f9 Author: Wupeng Ma Date: Sat May 10 11:30:40 2025 +0800 VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify commit 1bd6406fb5f36c2bb1e96e27d4c3e9f4d09edde4 upstream. During our test, it is found that a warning can be trigger in try_grab_folio as follow: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]--- Digging into the source, context->notify_page may init by get_user_pages_fast and can be seen in vmci_ctx_unset_notify which will try to put_page. However get_user_pages_fast is not finished here and lead to following try_grab_folio warning. The race condition is shown as follow: cpu0 cpu1 vmci_host_do_set_notify vmci_host_setup_notify get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page); lockless_pages_from_mm gup_pgd_range gup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed __gup_longterm_locked __get_user_pages follow_trans_huge_pmd try_grab_folio // warn here To slove this, use local variable page to make notify_page can be seen after finish get_user_pages_fast. Fixes: a1d88436d53a ("VMCI: Fix two UVA mapping bugs") Cc: stable Closes: https://lore.kernel.org/all/e91da589-ad57-3969-d979-879bbd10dddd@huawei.com/ Signed-off-by: Wupeng Ma Link: https://lore.kernel.org/r/20250510033040.901582-1-mawupeng1@huawei.com Signed-off-by: Greg Kroah-Hartman commit 8062676015c0def219685d3b7e2b8441fde2212b Author: Dave Penkler Date: Wed May 21 14:16:55 2025 +0200 usb: usbtmc: Fix read_stb function and get_stb ioctl commit acb3dac2805d3342ded7dbbd164add32bbfdf21c upstream. The usbtmc488_ioctl_read_stb function relied on a positive return from usbtmc_get_stb to reset the srq condition in the driver. The USBTMC_IOCTL_GET_STB case tested for a positive return to return the stb to the user. Commit: ("usb: usbtmc: Fix erroneous get_stb ioctl error returns") changed the return value of usbtmc_get_stb to 0 on success instead of returning the value of usb_control_msg which is positive in the normal case. This change caused the function usbtmc488_ioctl_read_stb and the USBTMC_IOCTL_GET_STB ioctl to no longer function correctly. Change the test in usbtmc488_ioctl_read_stb to test for failure first and return the failure code immediately. Change the test for the USBTMC_IOCTL_GET_STB ioctl to test for 0 instead of a positive value. Fixes: cac01bd178d6 ("usb: usbtmc: Fix erroneous get_stb ioctl error returns") Cc: stable@vger.kernel.org Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250521121656.18174-3-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman commit 3728101f56ef54425a11027a3ddc2c3941d60b71 Author: Peter Korsgaard Date: Fri May 9 13:24:07 2025 +0100 nvmem: zynqmp_nvmem: unbreak driver after cleanup commit fe8abdd175d7b547ae1a612757e7902bcd62e9cf upstream. Commit 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup") changed the driver to expect the device pointer to be passed as the "context", but in nvmem the context parameter comes from nvmem_config.priv which is never set - Leading to null pointer exceptions when the device is accessed. Fixes: 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup") Cc: stable Signed-off-by: Peter Korsgaard Reviewed-by: Michal Simek Tested-by: Michal Simek Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250509122407.11763-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 460188bc042a3f40f72d34b9f7fc6ee66b0b757b Author: Oleg Nesterov Date: Fri Jun 13 19:26:50 2025 +0200 posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del() commit f90fff1e152dedf52b932240ebbd670d83330eca upstream. If an exiting non-autoreaping task has already passed exit_notify() and calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent or debugger right after unlock_task_sighand(). If a concurrent posix_cpu_timer_del() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cpu_timer_task_rcu() and/or lock_task_sighand() will fail. Add the tsk->exit_state check into run_posix_cpu_timers() to fix this. This fix is not needed if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, because exit_task_work() is called before exit_notify(). But the check still makes sense, task_work_add(&tsk->posix_cputimers_work.work) will fail anyway in this case. Cc: stable@vger.kernel.org Reported-by: Benoît Sevens Fixes: 0bdd2ed4138e ("sched: run_posix_cpu_timers: Don't check ->exit_state, use lock_task_sighand()") Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 601a8601caa6c1c7291eda3dd72d37ae30a08f60 Author: Madhavan Srinivasan Date: Sun May 11 09:41:11 2025 +0530 powerpc/kernel: Fix ppc_save_regs inclusion in build commit 93bd4a80efeb521314485a06d8c21157240497bb upstream. Recent patch fixed an old commit 'fc2a5a6161a2 ("powerpc/64s: ppc_save_regs is now needed for all 64s builds")' which is to include building of ppc_save_reg.c only when XMON and KEXEC_CORE and PPC_BOOK3S are enabled. This was valid, since ppc_save_regs was called only in replay_system_reset() of old irq.c which was under BOOK3S. But there has been multiple refactoring of irq.c and have added call to ppc_save_regs() from __replay_soft_interrupts -> replay_soft_interrupts which is part of irq_64.c included under CONFIG_PPC64. And since ppc_save_regs is called in CRASH_DUMP path as part of crash_setup_regs in kexec.h, CONFIG_PPC32 also needs it. So with this recent patch which enabled the building of ppc_save_regs.c caused a build break when none of these (XMON, KEXEC_CORE, BOOK3S) where enabled as part of config. Patch to enable building of ppc_save_regs.c by defaults. Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250511041111.841158-1-maddy@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 485e1b741eb838cbe1d6b0e81e5ab62ae6c095cf Author: Terry Junge Date: Wed Mar 12 15:23:31 2025 -0700 HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse() commit fe7f7ac8e0c708446ff017453add769ffc15deed upstream. Update struct hid_descriptor to better reflect the mandatory and optional parts of the HID Descriptor as per USB HID 1.11 specification. Note: the kernel currently does not parse any optional HID class descriptors, only the mandatory report descriptor. Update all references to member element desc[0] to rpt_desc. Add test to verify bLength and bNumDescriptors values are valid. Replace the for loop with direct access to the mandatory HID class descriptor member for the report descriptor. This eliminates the possibility of getting an out-of-bounds fault. Add a warning message if the HID descriptor contains any unsupported optional HID class descriptors. Reported-by: syzbot+c52569baf0c843f35495@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c52569baf0c843f35495 Fixes: f043bfc98c19 ("HID: usbhid: fix out-of-bounds bug") Cc: stable@vger.kernel.org Signed-off-by: Terry Junge Reviewed-by: Michael Kelley Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 362d8a268505120db68d66f3550c28f0c3e0bfa4 Author: David Heimann Date: Sun Jun 1 12:41:16 2025 -0400 ALSA: usb-audio: Add implicit feedback quirk for RODE AI-1 commit 6a3439a417b910e662c666993798e0691bc81147 upstream. The RODE AI-1 audio interface requires implicit feedback sync between playback endpoint 0x03 and feedback endpoint 0x84 on interface 3, but doesn't advertise this in its USB descriptors. Without this quirk, the device receives audio data but produces no output. Signed-off-by: David Heimann Cc: Link: https://patch.msgid.link/084dc88c-1193-4a94-a002-5599adff936c@app.fastmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 62066758d2ae169278e5d6aea5995b1b6f6ddeb5 Author: Takashi Iwai Date: Mon May 19 23:20:30 2025 +0200 ALSA: usb-audio: Kill timer properly at removal commit 0718a78f6a9f04b88d0dc9616cc216b31c5f3cf1 upstream. The USB-audio MIDI code initializes the timer, but in a rare case, the driver might be freed without the disconnect call. This leaves the timer in an active state while the assigned object is released via snd_usbmidi_free(), which ends up with a kernel warning when the debug configuration is enabled, as spotted by fuzzer. For avoiding the problem, put timer_shutdown_sync() at snd_usbmidi_free(), so that the timer can be killed properly. While we're at it, replace the existing timer_delete_sync() at the disconnect callback with timer_shutdown_sync(), too. Reported-by: syzbot+d8f72178ab6783a7daea@syzkaller.appspotmail.com Closes: https://lore.kernel.org/681c70d7.050a0220.a19a9.00c6.GAE@google.com Cc: Link: https://patch.msgid.link/20250519212031.14436-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e97340a70b13fc392fd367c050722087d5deadd6 Author: Francesco Dolcini Date: Thu Jun 5 15:03:02 2025 +0200 Revert "wifi: mwifiex: Fix HT40 bandwidth issue." commit 570896604f47d44d4ff6882d2a588428d2a6ef17 upstream. This reverts commit 4fcfcbe45734 ("wifi: mwifiex: Fix HT40 bandwidth issue.") That commit introduces a regression, when HT40 mode is enabled, received packets are lost, this was experience with W8997 with both SDIO-UART and SDIO-SDIO variants. From an initial investigation the issue solves on its own after some time, but it's not clear what is the reason. Given that this was just a performance optimization, let's revert it till we have a better understanding of the issue and a proper fix. Cc: Jeff Chen Cc: stable@vger.kernel.org Fixes: 4fcfcbe45734 ("wifi: mwifiex: Fix HT40 bandwidth issue.") Closes: https://lore.kernel.org/all/20250603203337.GA109929@francesco-nb/ Signed-off-by: Francesco Dolcini Link: https://patch.msgid.link/20250605130302.55555-1-francesco@dolcini.it [fix commit reference format] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 0ea714e49b1dea6e3cf3c1efb405103ea026cbb7 Author: Suleiman Souhlal Date: Fri Jun 6 16:45:38 2025 +0900 tools/resolve_btfids: Fix build when cross compiling kernel with clang. commit a298bbab903e3fb4cbe16d36d6195e68fad1b776 upstream. When cross compiling the kernel with clang, we need to override CLANG_CROSS_FLAGS when preparing the step libraries. Prior to commit d1d096312176 ("tools: fix annoying "mkdir -p ..." logs when building tools in parallel"), MAKEFLAGS would have been set to a value that wouldn't set a value for CLANG_CROSS_FLAGS, hiding the fact that we weren't properly overriding it. Fixes: 56a2df7615fa ("tools/resolve_btfids: Compile resolve_btfids as host program") Signed-off-by: Suleiman Souhlal Signed-off-by: Andrii Nakryiko Acked-by: Jiri Olsa Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20250606074538.1608546-1-suleiman@google.com Signed-off-by: Greg Kroah-Hartman commit 473fa7a12d038fe8ccf2a6f708c4fe5ce8621d32 Author: Mike Yuan Date: Wed Jun 4 15:03:42 2025 +0000 pidfs: never refuse ppid == 0 in PIDFD_GET_INFO commit b55eb6eb2a7427428c59b293a0900131fc849595 upstream. In systemd we spotted an issue after switching to ioctl(PIDFD_GET_INFO) for obtaining pid number the pidfd refers to, that for processes with a parent from outer pidns PIDFD_GET_INFO unexpectedly yields -ESRCH [1]. It turned out that there's an arbitrary check blocking this, which is not really sensible given getppid() happily returns 0 for such processes. Just drop the spurious check and userspace ought to handle ppid == 0 properly everywhere. [1] https://github.com/systemd/systemd/issues/37715 Fixes: cdda1f26e74b ("pidfd: add ioctl to retrieve pid info") Signed-off-by: Mike Yuan Link: https://lore.kernel.org/20250604150238.42664-1-me@yhndnzj.com Cc: Christian Brauner Cc: Luca Boccassi Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 98af4b6b983cd227a95c7677ca268c3b41c82b47 Author: Benno Lossin Date: Sun May 25 19:34:45 2025 +0200 rust: list: fix path of `assert_pinned!` commit eb71feaacaaca227ae8f91c8578cf831553c5ab5 upstream. Commit dbd5058ba60c ("rust: make pin-init its own crate") moved all items from pin-init into the pin-init crate, including the `assert_pinned!` macro. Thus fix the path of the sole user of the `assert_pinned!` macro. This occurrence was missed in the commit above, since it is in a macro rule that has no current users (although binder is a future user). Cc: stable@kernel.org Fixes: dbd5058ba60c ("rust: make pin-init its own crate") Signed-off-by: Benno Lossin Link: https://lore.kernel.org/r/20250525173450.853413-1-lossin@kernel.org [ Reworded slightly as discussed in the list. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 6545df4edb2cea7607887898da5130748f1b2d94 Author: Gary Guo Date: Sat May 17 09:55:59 2025 +0100 rust: compile libcore with edition 2024 for 1.87+ commit f4daa80d6be7d3c55ca72a8e560afc4e21f886aa upstream. Rust 1.87 (released on 2025-05-15) compiles core library with edition 2024 instead of 2021 [1]. Ensure that the edition matches libcore's expectation to avoid potential breakage. [ J3m3 reported in Zulip [2] that the `rust-analyzer` target was broken after this patch -- indeed, we need to avoid `core-cfgs` since those are passed to the `rust-analyzer` target. So, instead, I tweaked the patch to create a new `core-edition` variable and explicitly mention the `--edition` flag instead of reusing `core-cfg`s. In addition, pass a new argument using this new variable to `generate_rust_analyzer.py` so that we set the right edition there. By the way, for future reference: the `filter-out` change is needed for Rust < 1.87, since otherwise we would skip the `--edition=2021` we just added, ending up with no edition flag, and thus the compiler would default to the 2015 one. [2] https://rust-for-linux.zulipchat.com/#narrow/channel/291565/topic/x/near/520206547 - Miguel ] Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/138162 [1] Reported-by: est31 Closes: https://github.com/Rust-for-Linux/linux/issues/1163 Signed-off-by: Gary Guo Link: https://lore.kernel.org/r/20250517085600.2857460-1-gary@garyguo.net Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 25c80d7052ecd12c22799878a6e88f9a19c70308 Author: Miguel Ojeda Date: Tue May 20 20:55:55 2025 +0200 objtool/rust: relax slice condition to cover more `noreturn` Rust functions commit cbeaa41dfe26b72639141e87183cb23e00d4b0dd upstream. Developers are indeed hitting other of the `noreturn` slice symbols in Nova [1], thus relax the last check in the list so that we catch all of them, i.e. *_4core5slice5index22slice_index_order_fail *_4core5slice5index24slice_end_index_len_fail *_4core5slice5index26slice_start_index_len_fail *_4core5slice5index29slice_end_index_overflow_fail *_4core5slice5index31slice_start_index_overflow_fail These all exist since at least Rust 1.78.0, thus backport it too. See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions") for more details. Cc: stable@vger.kernel.org # Needed in 6.12.y and later. Cc: John Hubbard Cc: Timur Tabi Cc: Kane York Cc: Josh Poimboeuf Cc: Peter Zijlstra Reported-by: Joel Fernandes Fixes: 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions") Closes: https://lore.kernel.org/rust-for-linux/20250513180757.GA1295002@joelnvbox/ [1] Tested-by: Joel Fernandes Link: https://lore.kernel.org/r/20250520185555.825242-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 44c805e9d9c9a2101ea783979c1f571883830f5a Author: Thomas Weißschuh Date: Fri Jun 6 10:23:57 2025 +0200 uapi: bitops: use UAPI-safe variant of BITS_PER_LONG again commit 11fcf368506d347088e613edf6cd2604d70c454f upstream. Commit 1e7933a575ed ("uapi: Revert "bitops: avoid integer overflow in GENMASK(_ULL)"") did not take in account that the usage of BITS_PER_LONG in __GENMASK() was changed to __BITS_PER_LONG for UAPI-safety in commit 3c7a8e190bc5 ("uapi: introduce uapi-friendly macros for GENMASK"). BITS_PER_LONG can not be used in UAPI headers as it derives from the kernel configuration and not from the current compiler invocation. When building compat userspace code or a compat vDSO its value will be incorrect. Switch back to __BITS_PER_LONG. Fixes: 1e7933a575ed ("uapi: Revert "bitops: avoid integer overflow in GENMASK(_ULL)"") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh Signed-off-by: Yury Norov [NVIDIA] Signed-off-by: Greg Kroah-Hartman commit 02b3d0ea4b04bbc36768bcecdef031f2f3b07512 Author: Matthew Wilcox (Oracle) Date: Thu Jun 12 15:42:53 2025 +0100 block: Fix bvec_set_folio() for very large folios [ Upstream commit 5e223e06ee7c6d8f630041a0645ac90e39a42cc6 ] Similarly to 26064d3e2b4d ("block: fix adding folio to bio"), if we attempt to add a folio that is larger than 4GB, we'll silently truncate the offset and len. Widen the parameters to size_t, assert that the length is less than 4GB and set the first page that contains the interesting data rather than the first page of the folio. Fixes: 26db5ee15851 (block: add a bvec_set_folio helper) Signed-off-by: Matthew Wilcox (Oracle) Link: https://lore.kernel.org/r/20250612144255.2850278-1-willy@infradead.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 50cf0197d12eae21538fa29b1227a3cabb7db269 Author: Matthew Wilcox (Oracle) Date: Thu Jun 12 15:41:25 2025 +0100 bio: Fix bio_first_folio() for SPARSEMEM without VMEMMAP [ Upstream commit f826ec7966a63d48e16e0868af4e038bf9a1a3ae ] It is possible for physically contiguous folios to have discontiguous struct pages if SPARSEMEM is enabled and SPARSEMEM_VMEMMAP is not. This is correctly handled by folio_page_idx(), so remove this open-coded implementation. Fixes: 640d1930bef4 (block: Add bio_for_each_folio_all()) Signed-off-by: Matthew Wilcox (Oracle) Link: https://lore.kernel.org/r/20250612144126.2849931-1-willy@infradead.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 112356b1804ce5659d327baf74f60c3b5b275dae Author: Paulo Alcantara Date: Thu Jun 12 12:45:04 2025 -0300 smb: client: fix perf regression with deferred closes [ Upstream commit b64af6bcd3b0f3fc633d6a70adb0991737abfef4 ] Customer reported that one of their applications started failing to open files with STATUS_INSUFFICIENT_RESOURCES due to NetApp server hitting the maximum number of opens to same file that it would allow for a single client connection. It turned out the client was failing to reuse open handles with deferred closes because matching ->f_flags directly without masking off O_CREAT|O_EXCL|O_TRUNC bits first broke the comparision and then client ended up with thousands of deferred closes to same file. Those bits are already satisfied on the original open, so no need to check them against existing open handles. Reproducer: #include #include #include #include #include #include #define NR_THREADS 4 #define NR_ITERATIONS 2500 #define TEST_FILE "/mnt/1/test/dir/foo" static char buf[64]; static void *worker(void *arg) { int i, j; int fd; for (i = 0; i < NR_ITERATIONS; i++) { fd = open(TEST_FILE, O_WRONLY|O_CREAT|O_APPEND, 0666); for (j = 0; j < 16; j++) write(fd, buf, sizeof(buf)); close(fd); } } int main(int argc, char *argv[]) { pthread_t t[NR_THREADS]; int fd; int i; fd = open(TEST_FILE, O_WRONLY|O_CREAT|O_TRUNC, 0666); close(fd); memset(buf, 'a', sizeof(buf)); for (i = 0; i < NR_THREADS; i++) pthread_create(&t[i], NULL, worker, NULL); for (i = 0; i < NR_THREADS; i++) pthread_join(t[i], NULL); return 0; } Before patch: $ mount.cifs //srv/share /mnt/1 -o ... $ mkdir -p /mnt/1/test/dir $ gcc repro.c && ./a.out ... number of opens: 1391 After patch: $ mount.cifs //srv/share /mnt/1 -o ... $ mkdir -p /mnt/1/test/dir $ gcc repro.c && ./a.out ... number of opens: 1 Cc: linux-cifs@vger.kernel.org Cc: David Howells Cc: Jay Shin Cc: Pierguido Lambri Fixes: b8ea3b1ff544 ("smb: enable reuse of deferred file handles for write operations") Acked-by: Shyam Prasad N Signed-off-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit f73dfd9d7f4b48dd16cdef2d34b24c321926fcdb Author: Keith Busch Date: Wed Jun 11 13:53:43 2025 -0700 io_uring: consistently use rcu semantics with sqpoll thread [ Upstream commit c538f400fae22725580842deb2bef546701b64bd ] The sqpoll thread is dereferenced with rcu read protection in one place, so it needs to be annotated as an __rcu type, and should consistently use rcu helpers for access and assignment to make sparse happy. Since most of the accesses occur under the sqd->lock, we can use rcu_dereference_protected() without declaring an rcu read section. Provide a simple helper to get the thread from a locked context. Fixes: ac0b8b327a5677d ("io_uring: fix use-after-free of sq->thread in __io_uring_show_fdinfo()") Signed-off-by: Keith Busch Link: https://lore.kernel.org/r/20250611205343.1821117-1-kbusch@meta.com [axboe: fold in fix for register.c] Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6ffae5d53f704d300cc73b06b4ea99e4507f7cf1 Author: Christoph Hellwig Date: Wed Jun 11 06:44:16 2025 +0200 block: don't use submit_bio_noacct_nocheck in blk_zone_wplug_bio_work [ Upstream commit cf625013d8741c01407bbb4a60c111b61b9fa69d ] Bios queued up in the zone write plug have already gone through all all preparation in the submit_bio path, including the freeze protection. Submitting them through submit_bio_noacct_nocheck duplicates the work and can can cause deadlocks when freezing a queue with pending bio write plugs. Go straight to ->submit_bio or blk_mq_submit_bio to bypass the superfluous extra freeze protection and checks. Fixes: 9b1ce7f0c6f8 ("block: Implement zone append emulation") Reported-by: Bart Van Assche Signed-off-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Reviewed-by: Damien Le Moal Tested-by: Damien Le Moal Link: https://lore.kernel.org/r/20250611044416.2351850-1-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d0932758a0a77b38ba1b39564f3b7aba12407061 Author: Penglei Jiang Date: Tue Jun 10 10:18:01 2025 -0700 io_uring: fix use-after-free of sq->thread in __io_uring_show_fdinfo() [ Upstream commit ac0b8b327a5677dc6fecdf353d808161525b1ff0 ] syzbot reports: BUG: KASAN: slab-use-after-free in getrusage+0x1109/0x1a60 Read of size 8 at addr ffff88810de2d2c8 by task a.out/304 CPU: 0 UID: 0 PID: 304 Comm: a.out Not tainted 6.16.0-rc1 #1 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xd0/0x670 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? getrusage+0x1109/0x1a60 kasan_report+0xce/0x100 ? getrusage+0x1109/0x1a60 getrusage+0x1109/0x1a60 ? __pfx_getrusage+0x10/0x10 __io_uring_show_fdinfo+0x9fe/0x1790 ? ksys_read+0xf7/0x1c0 ? do_syscall_64+0xa4/0x260 ? vsnprintf+0x591/0x1100 ? __pfx___io_uring_show_fdinfo+0x10/0x10 ? __pfx_vsnprintf+0x10/0x10 ? mutex_trylock+0xcf/0x130 ? __pfx_mutex_trylock+0x10/0x10 ? __pfx_show_fd_locks+0x10/0x10 ? io_uring_show_fdinfo+0x57/0x80 io_uring_show_fdinfo+0x57/0x80 seq_show+0x38c/0x690 seq_read_iter+0x3f7/0x1180 ? inode_set_ctime_current+0x160/0x4b0 seq_read+0x271/0x3e0 ? __pfx_seq_read+0x10/0x10 ? __pfx__raw_spin_lock+0x10/0x10 ? __mark_inode_dirty+0x402/0x810 ? selinux_file_permission+0x368/0x500 ? file_update_time+0x10f/0x160 vfs_read+0x177/0xa40 ? __pfx___handle_mm_fault+0x10/0x10 ? __pfx_vfs_read+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? fdget_pos+0x24d/0x4b0 ksys_read+0xf7/0x1c0 ? __pfx_ksys_read+0x10/0x10 ? do_user_addr_fault+0x43b/0x9c0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0f74170fc9 Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 8b 8 RSP: 002b:00007fffece049e8 EFLAGS: 00000206 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0f74170fc9 RDX: 0000000000001000 RSI: 00007fffece049f0 RDI: 0000000000000004 RBP: 00007fffece05ad0 R08: 0000000000000000 R09: 00007fffece04d90 R10: 0000000000000000 R11: 0000000000000206 R12: 00005651720a1100 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 298: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_node_noprof+0xe8/0x330 copy_process+0x376/0x5e00 create_io_thread+0xab/0xf0 io_sq_offload_create+0x9ed/0xf20 io_uring_setup+0x12b0/0x1cc0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 22: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0xc4/0x360 rcu_core+0x5ff/0x19f0 handle_softirqs+0x18c/0x530 run_ksoftirqd+0x20/0x30 smpboot_thread_fn+0x287/0x6c0 kthread+0x30d/0x630 ret_from_fork+0xef/0x1a0 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x33/0x60 kasan_record_aux_stack+0x8c/0xa0 __call_rcu_common.constprop.0+0x68/0x940 __schedule+0xff2/0x2930 __cond_resched+0x4c/0x80 mutex_lock+0x5c/0xe0 io_uring_del_tctx_node+0xe1/0x2b0 io_uring_clean_tctx+0xb7/0x160 io_uring_cancel_generic+0x34e/0x760 do_exit+0x240/0x2350 do_group_exit+0xab/0x220 __x64_sys_exit_group+0x39/0x40 x64_sys_call+0x1243/0x1840 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff88810de2cb00 which belongs to the cache task_struct of size 3712 The buggy address is located 1992 bytes inside of freed 3712-byte region [ffff88810de2cb00, ffff88810de2d980) which is caused by the task_struct pointed to by sq->thread being released while it is being used in the function __io_uring_show_fdinfo(). Holding ctx->uring_lock does not prevent ehre relase or exit of sq->thread. Fix this by assigning and looking up ->thread under RCU, and grabbing a reference to the task_struct. This ensures that it cannot get released while fdinfo is using it. Reported-by: syzbot+531502bbbe51d2f769f4@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/682b06a5.a70a0220.3849cf.00b3.GAE@google.com Fixes: 3fcb9d17206e ("io_uring/sqpoll: statistics of the true utilization of sq threads") Signed-off-by: Penglei Jiang Link: https://lore.kernel.org/r/20250610171801.70960-1-superman.xpt@gmail.com [axboe: massage commit message] Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6314f004f1e88d231c9234c943b3ac480b0423d9 Author: Ming Lei Date: Mon May 5 22:17:42 2025 +0800 block: use q->elevator with ->elevator_lock held in elv_iosched_show() [ Upstream commit 94209d27d14104ed828ca88cd5403a99162fe51a ] Use q->elevator with ->elevator_lock held in elv_iosched_show(), since the local cached elevator reference may become stale after getting ->elevator_lock. Reviewed-by: Hannes Reinecke Reviewed-by: Nilay Shroff Reviewed-by: Christoph Hellwig Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20250505141805.2751237-5-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f957ad4c6822196ce0fd5c6e0ae03961b6e089e5 Author: Peter Zijlstra Date: Fri Jan 17 10:54:50 2025 +0100 perf: Ensure bpf_perf_link path is properly serialized [ Upstream commit 7ed9138a72829d2035ecbd8dbd35b1bc3c137c40 ] Ravi reported that the bpf_perf_link_attach() usage of perf_event_set_bpf_prog() is not serialized by ctx->mutex, unlike the PERF_EVENT_IOC_SET_BPF case. Reported-by: Ravi Bangoria Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Ravi Bangoria Link: https://lkml.kernel.org/r/20250307193305.486326750@infradead.org Signed-off-by: Sasha Levin commit 78ef650ab3b7ae94894a5ce396b5a14a0987a9bd Author: Pavel Begunkov Date: Fri May 9 12:12:48 2025 +0100 io_uring: fix spurious drain flushing [ Upstream commit fde04c7e2775feb0746301e0ef86a04d3598c3fe ] io_queue_deferred() is not tolerant to spurious calls not completing some requests. You can have an inflight drain-marked request and another request that came after and got queued into the drain list. Now, if io_queue_deferred() is called before the first request completes, it'll check the 2nd req with req_need_defer(), find that there is no drain flag set, and queue it for execution. To make io_queue_deferred() work, it should at least check sequences for the first request, and then we need also need to check if there is another drain request creating another bubble. Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/972bde11b7d4ef25b3f5e3fd34f80e4d2aa345b8.1746788718.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 87457ff0c4f198ab6db3f225b4be8963497ffaae Author: Daniel Wagner Date: Wed May 7 14:23:03 2025 +0200 nvmet-fcloop: access fcpreq only when holding reqlock [ Upstream commit 47a827cd7929d0550c3496d70b417fcb5649b27b ] The abort handling logic expects that the state and the fcpreq are only accessed when holding the reqlock lock. While at it, only handle the aborts in the abort handler. Signed-off-by: Daniel Wagner Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit e41b74ffc7cd6607ed8506b8b53b2eba29209658 Author: Filipe Manana Date: Wed Apr 16 16:00:28 2025 +0100 btrfs: exit after state split error at set_extent_bit() [ Upstream commit 41d69d4d78d8b179bf3bcdfc56d28a12b3a608d2 ] If split_state() returned an error we call extent_io_tree_panic() which will trigger a BUG() call. However if CONFIG_BUG is disabled, which is an uncommon and exotic scenario, then we fallthrough and hit a use after free when calling set_state_bits() since the extent state record which the local variable 'prealloc' points to was freed by split_state(). So jump to the label 'out' after calling extent_io_tree_panic() and set the 'prealloc' pointer to NULL since split_state() has already freed it when it hit an error. Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 2df944842ecdaa72b5d9124247f3b0de030ae06a Author: Christian Brauner Date: Fri Apr 4 21:02:28 2025 +0200 gfs2: pass through holder from the VFS for freeze/thaw [ Upstream commit 62a2175ddf7e72941868f164b7c1f92e00f213bd ] The filesystem's freeze/thaw functions can be called from contexts where the holder isn't userspace but the kernel, e.g., during systemd suspend/hibernate. So pass through the freeze/thaw flags from the VFS instead of hard-coding them. Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit effdcec367669b151f6077f046b4d2c3203a7ec0 Author: Filipe Manana Date: Thu Mar 20 16:05:50 2025 +0000 btrfs: fix fsync of files with no hard links not persisting deletion [ Upstream commit 5e85262e542d6da8898bb8563a724ad98f6fc936 ] If we fsync a file (or directory) that has no more hard links, because while a process had a file descriptor open on it, the file's last hard link was removed and then the process did an fsync against the file descriptor, after a power failure or crash the file still exists after replaying the log. This behaviour is incorrect since once an inode has no more hard links it's not accessible anymore and we insert an orphan item into its subvolume's tree so that the deletion of all its items is not missed in case of a power failure or crash. So after log replay the file shouldn't exist anymore, which is also the behaviour on ext4, xfs, f2fs and other filesystems. Fix this by not ignoring inodes with zero hard links at btrfs_log_inode_parent() and by committing an inode's delayed inode when we are not doing a fast fsync (either BTRFS_INODE_COPY_EVERYTHING or BTRFS_INODE_NEEDS_FULL_SYNC is set in the inode's runtime flags). This last step is necessary because when removing the last hard link we don't delete the corresponding ref (or extref) item, instead we record the change in the inode's delayed inode with the BTRFS_DELAYED_NODE_DEL_IREF flag, so that when the delayed inode is committed we delete the ref/extref item from the inode's subvolume tree - otherwise the logging code will log the last hard link and therefore upon log replay the inode is not deleted. The base code for a fstests test case that reproduces this bug is the following: . ./common/dmflakey _require_scratch _require_dm_target flakey _require_mknod _scratch_mkfs >>$seqres.full 2>&1 || _fail "mkfs failed" _require_metadata_journaling $SCRATCH_DEV _init_flakey _mount_flakey touch $SCRATCH_MNT/foo # Commit the current transaction and persist the file. _scratch_sync # A fifo to communicate with a background xfs_io process that will # fsync the file after we deleted its hard link while it's open by # xfs_io. mkfifo $SCRATCH_MNT/fifo tail -f $SCRATCH_MNT/fifo | \ $XFS_IO_PROG $SCRATCH_MNT/foo >>$seqres.full & XFS_IO_PID=$! # Give some time for the xfs_io process to open a file descriptor for # the file. sleep 1 # Now while the file is open by the xfs_io process, delete its only # hard link. rm -f $SCRATCH_MNT/foo # Now that it has no more hard links, make the xfs_io process fsync it. echo "fsync" > $SCRATCH_MNT/fifo # Terminate the xfs_io process so that we can unmount. echo "quit" > $SCRATCH_MNT/fifo wait $XFS_IO_PID unset XFS_IO_PID # Simulate a power failure and then mount again the filesystem to # replay the journal/log. _flakey_drop_and_remount # We don't expect the file to exist anymore, since it was fsynced when # it had no more hard links. [ -f $SCRATCH_MNT/foo ] && echo "file foo still exists" _unmount_flakey # success, all done echo "Silence is golden" status=0 exit A test case for fstests will be submitted soon. Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e680aadc16f24cd8963d03ac4d51e9b0c3f54e5b Author: Zijun Hu Date: Thu Apr 10 19:45:27 2025 +0800 fs/filesystems: Fix potential unsigned integer underflow in fs_name() [ Upstream commit 1363c134ade81e425873b410566e957fecebb261 ] fs_name() has @index as unsigned int, so there is underflow risk for operation '@index--'. Fix by breaking the for loop when '@index == 0' which is also more proper than '@index <= 0' for unsigned integer comparison. Signed-off-by: Zijun Hu Link: https://lore.kernel.org/20250410-fix_fs-v1-1-7c14ccc8ebaa@quicinc.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 8d9d32088e304e2bc444a3087cab0bbbd9951866 Author: Filipe Manana Date: Thu Apr 10 17:11:14 2025 +0100 btrfs: exit after state insertion failure at btrfs_convert_extent_bit() [ Upstream commit 3bf179e36da917c5d9bec71c714573ed1649b7c1 ] If insert_state() state failed it returns an error pointer and we call extent_io_tree_panic() which will trigger a BUG() call. However if CONFIG_BUG is disabled, which is an uncommon and exotic scenario, then we fallthrough and call cache_state() which will dereference the error pointer, resulting in an invalid memory access. So jump to the 'out' label after calling extent_io_tree_panic(), it also makes the code more clear besides dealing with the exotic scenario where CONFIG_BUG is disabled. Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 857e6b8b0d27350ed1c4d457a10382649e41df16 Author: Lucas De Marchi Date: Wed Jun 4 08:03:05 2025 -0700 drm/xe/lrc: Use a temporary buffer for WA BB [ Upstream commit 9c7632faad434c98f1f2cc06f3647a5a5d05ddbf ] In case the BO is in iomem, we can't simply take the vaddr and write to it. Instead, prepare a separate buffer that is later copied into io memory. Right now it's just a few words that could be using xe_map_write32(), but the intention is to grow the WA BB for other uses. Fixes: 617d824c5323 ("drm/xe: Add WA BB to capture active context utilization") Cc: Umesh Nerlige Ramappa Cc: Tvrtko Ursulin Reviewed-by: Matthew Brost Reviewed-by: Umesh Nerlige Ramappa Link: https://lore.kernel.org/r/20250604-wa-bb-fix-v1-1-0dfc5dafcef0@intel.com Signed-off-by: Lucas De Marchi (cherry picked from commit ef48715b2d3df17c060e23b9aa636af3d95652f8) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit bdb0bd6e4fef56d958e9e27455cebff423fa9c73 Author: Gal Pressman Date: Thu Jun 12 10:19:57 2025 +0300 net: ethtool: Don't check if RSS context exists in case of context 0 [ Upstream commit d78ebc772c7ceccf6e655ddb93099f49a1268af4 ] Context 0 (default context) always exists, there is no need to check whether it exists or not when adding a flow steering rule. The existing check fails when creating a flow steering rule for context 0 as it is not stored in the rss_ctx xarray. For example: $ ethtool --config-ntuple eth2 flow-type tcp4 dst-ip 194.237.147.23 dst-port 19983 context 0 loc 618 rmgr: Cannot insert RX class rule: Invalid argument Cannot insert classification rule An example usecase for this could be: - A high-priority rule (loc 0) directing specific port traffic to context 0. - A low-priority rule (loc 1) directing all other TCP traffic to context 1. This is a user-visible regression that was caught in our testing environment, it was not reported by a user yet. Fixes: de7f7582dff2 ("net: ethtool: prevent flow steering to RSS contexts which don't exist") Reviewed-by: Tariq Toukan Reviewed-by: Nimrod Oren Signed-off-by: Gal Pressman Reviewed-by: Joe Damato Reviewed-by: Edward Cree Link: https://patch.msgid.link/20250612071958.1696361-2-gal@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6837dd877270c57689bd866de9f3de14172c2439 Author: Jakub Kicinski Date: Wed Jun 11 10:46:43 2025 -0700 net: drv: netdevsim: don't napi_complete() from netpoll [ Upstream commit 1264971017b4d7141352a7fe29021bdfce5d885d ] netdevsim supports netpoll. Make sure we don't call napi_complete() from it, since it may not be scheduled. Breno reports hitting a warning in napi_complete_done(): WARNING: CPU: 14 PID: 104 at net/core/dev.c:6592 napi_complete_done+0x2cc/0x560 __napi_poll+0x2d8/0x3a0 handle_softirqs+0x1fe/0x710 This is presumably after netpoll stole the SCHED bit prematurely. Reported-by: Breno Leitao Fixes: 3762ec05a9fb ("netdevsim: add NAPI support") Tested-by: Breno Leitao Link: https://patch.msgid.link/20250611174643.2769263-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fed94bd51d62d2e0e006aa61480e94e5cd0582b0 Author: Eric Dumazet Date: Wed Jun 11 11:15:14 2025 +0000 net_sched: ets: fix a race in ets_qdisc_change() [ Upstream commit d92adacdd8c2960be856e0b82acc5b7c5395fddb ] Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Fixes: b05972f01e7d ("net: sched: tbf: don't call qdisc_put() while holding tree lock") Reported-by: Gerrard Tai Suggested-by: Gerrard Tai Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20250611111515.1983366-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6e82433ca8f996ef3b79983f645690202d7da482 Author: Eric Dumazet Date: Wed Jun 11 11:15:13 2025 +0000 net_sched: tbf: fix a race in tbf_change() [ Upstream commit 43eb466041216d25dedaef1c383ad7bd89929cbc ] Gerrard Tai reported a race condition in TBF, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Fixes: b05972f01e7d ("net: sched: tbf: don't call qdisc_put() while holding tree lock") Reported-by: Gerrard Tai Suggested-by: Gerrard Tai Signed-off-by: Eric Dumazet Cc: Zhengchao Shao Link: https://patch.msgid.link/20250611111515.1983366-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 444ad445df5496a785705019268a8a84b84484bb Author: Eric Dumazet Date: Wed Jun 11 11:15:12 2025 +0000 net_sched: red: fix a race in __red_change() [ Upstream commit 85a3e0ede38450ea3053b8c45d28cf55208409b8 ] Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Fixes: 0c8d13ac9607 ("net: sched: red: delay destroying child qdisc on replace") Reported-by: Gerrard Tai Suggested-by: Gerrard Tai Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20250611111515.1983366-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 93f9eeb678d4c9c1abf720b3615fa8299a490845 Author: Eric Dumazet Date: Wed Jun 11 11:15:11 2025 +0000 net_sched: prio: fix a race in prio_tune() [ Upstream commit d35acc1be3480505b5931f17e4ea9b7617fea4d3 ] Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Fixes: 7b8e0b6e6599 ("net: sched: prio: delay destroying child qdiscs on change") Reported-by: Gerrard Tai Suggested-by: Gerrard Tai Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20250611111515.1983366-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6cfc38a8bf5d1b808c72b88ea0619962378303d6 Author: Maxime Chevallier Date: Fri Jun 6 11:43:20 2025 +0200 net: phy: phy_caps: Don't skip better duplex macth on non-exact match [ Upstream commit d4e6cb324dcc952618fec6b25aa3fc7bfc2750b4 ] When performing a non-exact phy_caps lookup, we are looking for a supported mode that matches as closely as possible the passed speed/duplex. Blamed patch broke that logic by returning a match too early in case the caller asks for half-duplex, as a full-duplex linkmode may match first, and returned as a non-exact match without even trying to mach on half-duplex modes. Reported-by: Jijie Shao Closes: https://lore.kernel.org/netdev/20250603102500.4ec743cf@fedora/T/#m22ed60ca635c67dc7d9cbb47e8995b2beb5c1576 Tested-by: Jijie Shao Reviewed-by: Larysa Zaremba Fixes: fc81e257d19f ("net: phy: phy_caps: Allow looking-up link caps based on speed and duplex") Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20250606094321.483602-1-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e2c67651b2030e0a039f8aca75e97bcf4664d56f Author: Shahar Shitrit Date: Tue Jun 10 18:15:14 2025 +0300 net/mlx5e: Fix number of lanes to UNKNOWN when using data_rate_oper [ Upstream commit 875d7c160d60616ff06dedb70470ad199661efe7 ] When the link is up, either eth_proto_oper or ext_eth_proto_oper typically reports the active link protocol, from which both speed and number of lanes can be retrieved. However, in certain cases, such as when a NIC is connected via a non-standard cable, the firmware may not report the protocol. In such scenarios, the speed can still be obtained from the data_rate_oper field in PTYS register. Since data_rate_oper provides only speed information and lacks lane details, it is incorrect to derive the number of lanes from it. This patch corrects the behavior by setting the number of lanes to UNKNOWN instead of incorrectly using MAX_LANES when relying on data_rate_oper. Fixes: 7e959797f021 ("net/mlx5e: Enable lanes configuration when auto-negotiation is off") Signed-off-by: Shahar Shitrit Reviewed-by: Tariq Toukan Signed-off-by: Mark Bloch Link: https://patch.msgid.link/20250610151514.1094735-10-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b74a34d3095db53095b1bb031b267affded9bf3e Author: Jianbo Liu Date: Tue Jun 10 18:15:13 2025 +0300 net/mlx5e: Fix leak of Geneve TLV option object [ Upstream commit aa9c44b842096c553871bc68a8cebc7861fa192b ] Previously, a unique tunnel id was added for the matching on TC non-zero chains, to support inner header rewrite with goto action. Later, it was used to support VF tunnel offload for vxlan, then for Geneve and GRE. To support VF tunnel, a temporary mlx5_flow_spec is used to parse tunnel options. For Geneve, if there is TLV option, a object is created, or refcnt is added if already exists. But the temporary mlx5_flow_spec is directly freed after parsing, which causes the leak because no information regarding the object is saved in flow's mlx5_flow_spec, which is used to free the object when deleting the flow. To fix the leak, call mlx5_geneve_tlv_option_del() before free the temporary spec if it has TLV object. Fixes: 521933cdc4aa ("net/mlx5e: Support Geneve and GRE with VF tunnel offload") Signed-off-by: Jianbo Liu Reviewed-by: Tariq Toukan Reviewed-by: Alex Lazar Signed-off-by: Mark Bloch Link: https://patch.msgid.link/20250610151514.1094735-9-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 82d42826bf55f7c33f4468fb44b2f9c7b03ee5c6 Author: Vlad Dogaru Date: Tue Jun 10 18:15:11 2025 +0300 net/mlx5: HWS, make sure the uplink is the last destination [ Upstream commit b8335829518ec5988294280e37d735799209d70d ] When there are more than one destinations, we create a FW flow table and provide it with all the destinations. FW requires to have wire as the last destination in the list (if it exists), otherwise the operation fails with FW syndrome. This patch fixes the destination array action creation: if it contains a wire destination, it is moved to the end. Fixes: 504e536d9010 ("net/mlx5: HWS, added actions handling") Signed-off-by: Vlad Dogaru Reviewed-by: Yevgeny Kliteynik Signed-off-by: Mark Bloch Link: https://patch.msgid.link/20250610151514.1094735-7-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 84e4582bab4ce7bd75a676c147d18d8b1f609d80 Author: Yevgeny Kliteynik Date: Tue Jun 10 18:15:10 2025 +0300 net/mlx5: HWS, fix missing ip_version handling in definer [ Upstream commit b5e3c76f35ee7e814c2469c73406c5bbf110d89c ] Fix missing field handling in definer - outer IP version. Fixes: 74a778b4a63f ("net/mlx5: HWS, added definers handling") Signed-off-by: Yevgeny Kliteynik Signed-off-by: Mark Bloch Link: https://patch.msgid.link/20250610151514.1094735-6-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ec4bcb7add9e4e91c239bf639a89e8fc4e54f296 Author: Patrisious Haddad Date: Tue Jun 10 18:15:08 2025 +0300 net/mlx5: Fix return value when searching for existing flow group [ Upstream commit 8ec40e3f1f72bf8f8accf18020d487caa99f46a4 ] When attempting to add a rule to an existing flow group, if a matching flow group exists but is not active, the error code returned should be EAGAIN, so that the rule can be added to the matching flow group once it is active, rather than ENOENT, which indicates that no matching flow group was found. Fixes: bd71b08ec2ee ("net/mlx5: Support multiple updates of steering rules in parallel") Signed-off-by: Gavi Teitz Signed-off-by: Roi Dayan Signed-off-by: Patrisious Haddad Reviewed-by: Tariq Toukan Signed-off-by: Mark Bloch Link: https://patch.msgid.link/20250610151514.1094735-4-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 24db585d369f949f698e03d7d8017e5ae19d0497 Author: Amir Tzin Date: Tue Jun 10 18:15:07 2025 +0300 net/mlx5: Fix ECVF vports unload on shutdown flow [ Upstream commit 687560d8a9a2d654829ad0da1ec24242f1de711d ] Fix shutdown flow UAF when a virtual function is created on the embedded chip (ECVF) of a BlueField device. In such case the vport acl ingress table is not properly destroyed. ECVF functionality is independent of ecpf_vport_exists capability and thus functions mlx5_eswitch_(enable|disable)_pf_vf_vports() should not test it when enabling/disabling ECVF vports. kernel log: [] refcount_t: underflow; use-after-free. [] WARNING: CPU: 3 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0x124/0x220 ---------------- [] Call trace: [] refcount_warn_saturate+0x124/0x220 [] tree_put_node+0x164/0x1e0 [mlx5_core] [] mlx5_destroy_flow_table+0x98/0x2c0 [mlx5_core] [] esw_acl_ingress_table_destroy+0x28/0x40 [mlx5_core] [] esw_acl_ingress_lgcy_cleanup+0x80/0xf4 [mlx5_core] [] esw_legacy_vport_acl_cleanup+0x44/0x60 [mlx5_core] [] esw_vport_cleanup+0x64/0x90 [mlx5_core] [] mlx5_esw_vport_disable+0xc0/0x1d0 [mlx5_core] [] mlx5_eswitch_unload_ec_vf_vports+0xcc/0x150 [mlx5_core] [] mlx5_eswitch_disable_sriov+0x198/0x2a0 [mlx5_core] [] mlx5_device_disable_sriov+0xb8/0x1e0 [mlx5_core] [] mlx5_sriov_detach+0x40/0x50 [mlx5_core] [] mlx5_unload+0x40/0xc4 [mlx5_core] [] mlx5_unload_one_devl_locked+0x6c/0xe4 [mlx5_core] [] mlx5_unload_one+0x3c/0x60 [mlx5_core] [] shutdown+0x7c/0xa4 [mlx5_core] [] pci_device_shutdown+0x3c/0xa0 [] device_shutdown+0x170/0x340 [] __do_sys_reboot+0x1f4/0x2a0 [] __arm64_sys_reboot+0x2c/0x40 [] invoke_syscall+0x78/0x100 [] el0_svc_common.constprop.0+0x54/0x184 [] do_el0_svc+0x30/0xac [] el0_svc+0x48/0x160 [] el0t_64_sync_handler+0xa4/0x12c [] el0t_64_sync+0x1a4/0x1a8 [] --[ end trace 9c4601d68c70030e ]--- Fixes: a7719b29a821 ("net/mlx5: Add management of EC VF vports") Reviewed-by: Daniel Jurgens Reviewed-by: Moshe Shemesh Signed-off-by: Amir Tzin Signed-off-by: Mark Bloch Link: https://patch.msgid.link/20250610151514.1094735-3-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit abb9fb1a70d24988d2234838d4822b9676e3de94 Author: Moshe Shemesh Date: Tue Jun 10 18:15:06 2025 +0300 net/mlx5: Ensure fw pages are always allocated on same NUMA [ Upstream commit f37258133c1e95e61db532e14067e28b4881bf24 ] When firmware asks the driver to allocate more pages, using event of give_pages, the driver should always allocate it from same NUMA, the original device NUMA. Current code uses dev_to_node() which can result in different NUMA as it is changed by other driver flows, such as mlx5_dma_zalloc_coherent_node(). Instead, use saved numa node for allocating firmware pages. Fixes: 311c7c71c9bb ("net/mlx5e: Allocate DMA coherent memory on reader NUMA node") Signed-off-by: Moshe Shemesh Reviewed-by: Tariq Toukan Signed-off-by: Mark Bloch Link: https://patch.msgid.link/20250610151514.1094735-2-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6bf4723a19f133d853ea43e0f37bf266f591da43 Author: Luiz Augusto von Dentz Date: Wed Jun 11 16:36:27 2025 -0400 Bluetooth: MGMT: Fix sparse errors [ Upstream commit 7dd38ba4acbea9875b4ee061e20a26413e39d9f4 ] This fixes the following errors: net/bluetooth/mgmt.c:5400:59: sparse: sparse: incorrect type in argument 3 (different base types) @@ expected unsigned short [usertype] handle @@ got restricted __le16 [usertype] monitor_handle @@ net/bluetooth/mgmt.c:5400:59: sparse: expected unsigned short [usertype] handle net/bluetooth/mgmt.c:5400:59: sparse: got restricted __le16 [usertype] monitor_handle Fixes: e6ed54e86aae ("Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202506060347.ux2O1p7L-lkp@intel.com/ Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit b9db0c27e73b7c8a19384a44af527edfda74ff3d Author: Luiz Augusto von Dentz Date: Tue Jun 10 10:14:35 2025 -0400 Bluetooth: eir: Fix possible crashes on eir_create_adv_data [ Upstream commit 47c03902269aff377f959dc3fd94a9733aa31d6e ] eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking if that would fit. Link: https://github.com/bluez/bluez/issues/1117#issuecomment-2958244066 Fixes: 01ce70b0a274 ("Bluetooth: eir: Move EIR/Adv Data functions to its own file") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 15da883c010cbc2a84aec1738b6ad6ee477846de Author: Luiz Augusto von Dentz Date: Thu Jun 5 11:15:16 2025 -0400 Bluetooth: hci_sync: Fix broadcast/PA when using an existing instance [ Upstream commit 5725bc608252050ed8a4d47d59225b7dd73474c8 ] When using and existing adv_info instance for broadcast source it needs to be updated to periodic first before it can be reused, also in case the existing instance already have data hci_set_adv_instance_data cannot be used directly since it would overwrite the existing data so this reappend the original data after the Broadcast ID, if one was generated. Example: bluetoothctl># Add PBP to EA so it can be later referenced as the BIS ID bluetoothctl> advertise.service 0x1856 0x00 0x00 bluetoothctl> advertise on ... < HCI Command: LE Set Extended Advertising Data (0x08|0x0037) plen 13 Handle: 0x01 Operation: Complete extended advertising data (0x03) Fragment preference: Minimize fragmentation (0x01) Data length: 0x09 Service Data: Public Broadcast Announcement (0x1856) Data[2]: 0000 Flags: 0x06 LE General Discoverable Mode BR/EDR Not Supported ... bluetoothctl># Attempt to acquire Broadcast Source transport bluetoothctl>transport.acquire /org/bluez/hci0/pac_bcast0/fd0 ... < HCI Command: LE Set Extended Advertising Data (0x08|0x0037) plen 255 Handle: 0x01 Operation: Complete extended advertising data (0x03) Fragment preference: Minimize fragmentation (0x01) Data length: 0x0e Service Data: Broadcast Audio Announcement (0x1852) Broadcast ID: 11371620 (0xad8464) Service Data: Public Broadcast Announcement (0x1856) Data[2]: 0000 Flags: 0x06 LE General Discoverable Mode BR/EDR Not Supported Link: https://github.com/bluez/bluez/issues/1117 Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7d99cc0f8e6fa0f35570887899f178122a61d44e Author: Luiz Augusto von Dentz Date: Thu Jun 5 11:14:25 2025 -0400 Bluetooth: Fix NULL pointer deference on eir_get_service_data [ Upstream commit 20a2aa01f5aeb6daad9aeaa7c33dd512c58d81eb ] The len parameter is considered optional so it can be NULL so it cannot be used for skipping to next entry of EIR_SERVICE_DATA. Fixes: 8f9ae5b3ae80 ("Bluetooth: eir: Add helpers for managing service data") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4ded22f7f3ce9714ed72c3e9c68fea1cb9388ae7 Author: Jakub Raczynski Date: Mon Jun 9 17:31:47 2025 +0200 net/mdiobus: Fix potential out-of-bounds clause 45 read/write access [ Upstream commit 260388f79e94fb3026c419a208ece8358bb7b555 ] When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via C45 (clause 45) mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write. Fix that by adding address verification before C45 read/write operation. While this excludes this access from any statistics, it improves security of read/write operation. Fixes: 4e4aafcddbbf ("net: mdio: Add dedicated C45 API to MDIO bus drivers") Signed-off-by: Jakub Raczynski Reported-by: Wenjing Shan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 049af7ac45a6b407748ee0995278fd861e36df8f Author: Jakub Raczynski Date: Mon Jun 9 17:31:46 2025 +0200 net/mdiobus: Fix potential out-of-bounds read/write access [ Upstream commit 0e629694126ca388916f059453a1c36adde219c4 ] When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write. Fix that by adding address verification before read/write operation. While this excludes this access from any statistics, it improves security of read/write operation. Fixes: 080bb352fad00 ("net: phy: Maintain MDIO device and bus statistics") Signed-off-by: Jakub Raczynski Reported-by: Wenjing Shan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7a4b2ff36cf9fe5947a8971fdf55b5d100fd70ad Author: Carlos Fernandez Date: Mon Jun 9 09:26:26 2025 +0200 macsec: MACsec SCI assignment for ES = 0 [ Upstream commit d9816ec74e6d6aa29219d010bba3f780ba1d9d75 ] According to 802.1AE standard, when ES and SC flags in TCI are zero, used SCI should be the current active SC_RX. Current code uses the header MAC address. Without this patch, when ES flag is 0 (using a bridge or switch), header MAC will not fit the SCI and MACSec frames will be discarted. In order to test this issue, MACsec link should be stablished between two interfaces, setting SC and ES flags to zero and a port identifier different than one. For example, using ip macsec tools: ip link add link $ETH0 macsec0 type macsec port 11 send_sci off end_station off ip macsec add macsec0 tx sa 0 pn 2 on key 01 $ETH1_KEY ip macsec add macsec0 rx port 11 address $ETH1_MAC ip macsec add macsec0 rx port 11 address $ETH1_MAC sa 0 pn 2 on key 02 ip link set dev macsec0 up ip link add link $ETH1 macsec1 type macsec port 11 send_sci off end_station off ip macsec add macsec1 tx sa 0 pn 2 on key 01 $ETH0_KEY ip macsec add macsec1 rx port 11 address $ETH0_MAC ip macsec add macsec1 rx port 11 address $ETH0_MAC sa 0 pn 2 on key 02 ip link set dev macsec1 up Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Co-developed-by: Andreu Montiel Signed-off-by: Andreu Montiel Signed-off-by: Carlos Fernandez Reviewed-by: Subbaraya Sundeep Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fc7d81b4a9582c5c271c84da18e4bffb0cae1d69 Author: Gustavo Luiz Duarte Date: Mon Jun 9 11:24:20 2025 -0700 netconsole: fix appending sysdata when sysdata_fields == SYSDATA_RELEASE [ Upstream commit c85bf1975108d2e2431c11d1cb7e95aca587dfbe ] Before appending sysdata, prepare_extradata() checks if any feature is enabled in sysdata_fields (and exits early if none is enabled). When SYSDATA_RELEASE was introduced, we missed adding it to the list of features being checked against sysdata_fields in prepare_extradata(). The result was that, if only SYSDATA_RELEASE is enabled in sysdata_fields, we incorreclty exit early and fail to append the release. Instead of checking specific bits in sysdata_fields, check if sysdata_fields has ALL bit zeroed and exit early if true. This fixes case when only SYSDATA_RELEASE enabled and makes the code more general / less error prone in future feature implementation. Signed-off-by: Gustavo Luiz Duarte Reviewed-by: Breno Leitao Fixes: cfcc9239e78a ("netconsole: append release to sysdata") Link: https://patch.msgid.link/20250609-netconsole-fix-v1-1-17543611ae31@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1b367ba2f94251822577daed031d6b9a9e11ba91 Author: Michal Luczaj Date: Mon Jun 9 19:08:03 2025 +0200 net: Fix TOCTOU issue in sk_is_readable() [ Upstream commit 2660a544fdc0940bba15f70508a46cf9a6491230 ] sk->sk_prot->sock_is_readable is a valid function pointer when sk resides in a sockmap. After the last sk_psock_put() (which usually happens when socket is removed from sockmap), sk->sk_prot gets restored and sk->sk_prot->sock_is_readable becomes NULL. This makes sk_is_readable() racy, if the value of sk->sk_prot is reloaded after the initial check. Which in turn may lead to a null pointer dereference. Ensure the function pointer does not turn NULL after the check. Fixes: 8934ce2fd081 ("bpf: sockmap redirect ingress support") Suggested-by: Jakub Sitnicki Signed-off-by: Michal Luczaj Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20250609-skisreadable-toctou-v1-1-d0dfb2d62c37@rbox.co Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1a677d0ceb4a5d62117b711a8b2e0aee80d33015 Author: Yunhui Cui Date: Wed Jun 4 10:30:36 2025 +0800 ACPI: CPPC: Fix NULL pointer dereference when nosmp is used [ Upstream commit 15eece6c5b05e5f9db0711978c3e3b7f1a2cfe12 ] With nosmp in cmdline, other CPUs are not brought up, leaving their cpc_desc_ptr NULL. CPU0's iteration via for_each_possible_cpu() dereferences these NULL pointers, causing panic. Panic backtrace: [ 0.401123] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b8 ... [ 0.403255] [] cppc_allow_fast_switch+0x6a/0xd4 ... Kernel panic - not syncing: Attempted to kill init! Fixes: 3cc30dd00a58 ("cpufreq: CPPC: Enable fast_switch") Reported-by: Xu Lu Signed-off-by: Yunhui Cui Link: https://patch.msgid.link/20250604023036.99553-1-cuiyunhui@bytedance.com [ rjw: New subject ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 1fd4438ddcc4958ed24662d5125114299e19bae4 Author: Joe Damato Date: Tue Jun 3 16:34:01 2025 +0000 e1000: Move cancel_work_sync to avoid deadlock [ Upstream commit b4a8085ceefb7bbb12c2b71c55e71fc946c6929f ] Previously, e1000_down called cancel_work_sync for the e1000 reset task (via e1000_down_and_stop), which takes RTNL. As reported by users and syzbot, a deadlock is possible in the following scenario: CPU 0: - RTNL is held - e1000_close - e1000_down - cancel_work_sync (cancel / wait for e1000_reset_task()) CPU 1: - process_one_work - e1000_reset_task - take RTNL To remedy this, avoid calling cancel_work_sync from e1000_down (e1000_reset_task does nothing if the device is down anyway). Instead, call cancel_work_sync for e1000_reset_task when the device is being removed. Fixes: e400c7444d84 ("e1000: Hold RTNL when e1000_down can be called") Reported-by: syzbot+846bb38dc67fe62cc733@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/683837bf.a00a0220.52848.0003.GAE@google.com/ Reported-by: John Closes: https://lore.kernel.org/netdev/CAP=Rh=OEsn4y_2LvkO3UtDWurKcGPnZ_NPSXK=FbgygNXL37Sw@mail.gmail.com/ Signed-off-by: Joe Damato Acked-by: Stanislav Fomichev Acked-by: Jacob Keller Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit f20899b1a877e87defe88ffec31ae7de0613704c Author: Anton Nadezhdin Date: Tue May 20 10:42:16 2025 +0200 ice/ptp: fix crosstimestamp reporting [ Upstream commit a5a441ae283d54ec329aadc7426991dc32786d52 ] Set use_nsecs=true as timestamp is reported in ns. Lack of this result in smaller timestamp error window which cause error during phc2sys execution on E825 NICs: phc2sys[1768.256]: ioctl PTP_SYS_OFFSET_PRECISE: Invalid argument This problem was introduced in the cited commit which omitted setting use_nsecs to true when converting the ice driver to use convert_base_to_cs(). Testing hints (ethX is PF netdev): phc2sys -s ethX -c CLOCK_REALTIME -O 37 -m phc2sys[1769.256]: CLOCK_REALTIME phc offset -5 s0 freq -0 delay 0 Fixes: d4bea547ebb57 ("ice/ptp: Remove convert_art_to_tsc()") Signed-off-by: Anton Nadezhdin Reviewed-by: Aleksandr Loktionov Reviewed-by: Arkadiusz Kubalewski Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 325d50130db62122ef7d8744e7552444c6b4a10d Author: Ahmed Zaki Date: Thu Apr 24 15:50:13 2025 +0200 iavf: fix reset_task for early reset event [ Upstream commit 0c6f4631436ecea841f1583b98255aedd7495b18 ] If a reset event is received from the PF early in the init cycle, the state machine hangs for about 25 seconds. Reproducer: echo 1 > /sys/class/net/$PF0/device/sriov_numvfs ip link set dev $PF0 vf 0 mac $NEW_MAC The log shows: [792.620416] ice 0000:5e:00.0: Enabling 1 VFs [792.738812] iavf 0000:5e:01.0: enabling device (0000 -> 0002) [792.744182] ice 0000:5e:00.0: Enabling 1 VFs with 17 vectors and 16 queues per VF [792.839964] ice 0000:5e:00.0: Setting MAC 52:54:00:00:00:11 on VF 0. VF driver will be reinitialized [813.389684] iavf 0000:5e:01.0: Failed to communicate with PF; waiting before retry [818.635918] iavf 0000:5e:01.0: Hardware came out of reset. Attempting reinit. [818.766273] iavf 0000:5e:01.0: Multiqueue Enabled: Queue pair count = 16 Fix it by scheduling the reset task and making the reset task capable of resetting early in the init cycle. Fixes: ef8693eb90ae3 ("i40evf: refactor reset handling") Signed-off-by: Ahmed Zaki Tested-by: Przemek Kitszel Reviewed-by: Przemek Kitszel Signed-off-by: Marcin Szycik Reviewed-by: Simon Horman Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e172bbb296c6f82014f4d2d79b71c0be989a3ad3 Author: Robert Malz Date: Tue May 20 10:31:52 2025 +0200 i40e: retry VFLR handling if there is ongoing VF reset [ Upstream commit fb4e9239e029954a37a00818b21e837cebf2aa10 ] When a VFLR interrupt is received during a VF reset initiated from a different source, the VFLR may be not fully handled. This can leave the VF in an undefined state. To address this, set the I40E_VFLR_EVENT_PENDING bit again during VFLR handling if the reset is not yet complete. This ensures the driver will properly complete the VF reset in such scenarios. Fixes: 52424f974bc5 ("i40e: Fix VF hang when reset is triggered on another VF") Signed-off-by: Robert Malz Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 5ae6ccc8a31d53215695d1da5a0f466e8342519e Author: Robert Malz Date: Tue May 20 10:31:51 2025 +0200 i40e: return false from i40e_reset_vf if reset is in progress [ Upstream commit a2c90d63b71223d69a813333c1abf4fdacddbbe5 ] The function i40e_vc_reset_vf attempts, up to 20 times, to handle a VF reset request, using the return value of i40e_reset_vf as an indicator of whether the reset was successfully triggered. Currently, i40e_reset_vf always returns true, which causes new reset requests to be ignored if a different VF reset is already in progress. This patch updates the return value of i40e_reset_vf to reflect when another VF reset is in progress, allowing the caller to properly use the retry mechanism. Fixes: 52424f974bc5 ("i40e: Fix VF hang when reset is triggered on another VF") Signed-off-by: Robert Malz Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit cfe7aae528b4d101230784ce88969d3d28a6958a Author: Chen-Yu Tsai Date: Sat Jun 7 21:52:03 2025 +0800 pinctrl: sunxi: dt: Consider pin base when calculating bank number from pin [ Upstream commit 5558f27a58459a4038ebb23bcb5bd40c1e345c57 ] In prepare_function_table() when the pinctrl function table IRQ entries are generated, the pin bank is calculated from the absolute pin number; however the IRQ bank mux array is indexed from the first pin bank of the controller. For R_PIO controllers, this means the absolute pin bank is way off from the relative pin bank used for array indexing. Correct this by taking into account the pin base of the controller. Fixes: f5e2cd34b12f ("pinctrl: sunxi: allow reading mux values from DT") Signed-off-by: Chen-Yu Tsai Link: https://lore.kernel.org/20250607135203.2085226-1-wens@kernel.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 89292a66c5c7e5dc0ccd834e108593b6f8a8e5cf Author: Martin Blumenstingl Date: Mon Jun 9 22:27:51 2025 +0200 drm/meson: fix more rounding issues with 59.94Hz modes [ Upstream commit 0cee6c4d3518b2e757aedae78771f17149f57653 ] Commit 1017560164b6 ("drm/meson: use unsigned long long / Hz for frequency types") attempts to resolve video playback using 59.94Hz. using YUV420 by changing the clock calculation to use Hz instead of kHz (thus yielding more precision). The basic calculation itself is correct, however the comparisions in meson_vclk_vic_supported_freq() and meson_vclk_setup() don't work anymore for 59.94Hz modes (using the freq * 1000 / 1001 logic). For example, drm/edid specifies a 593407kHz clock for 3840x2160@59.94Hz. With the mentioend commit we convert this to Hz. Then meson_vclk tries to find a matchig "params" entry (as the clock setup code currently only supports specific frequencies) by taking the venc_freq from the params and calculating the "alt frequency" (used for the 59.94Hz modes) from it, which is: (594000000Hz * 1000) / 1001 = 593406593Hz Similar calculation is applied to the phy_freq (TMDS clock), which is 10 times the pixel clock. Implement a new meson_vclk_freqs_are_matching_param() function whose purpose is to compare if the requested and calculated frequencies. They may not match exactly (for the reasons mentioned above). Allow the clocks to deviate slightly to make the 59.94Hz modes again. Fixes: 1017560164b6 ("drm/meson: use unsigned long long / Hz for frequency types") Reported-by: Christian Hewitt Signed-off-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250609202751.962208-1-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 490a7de4337dd063dad07b0cff28a5748a945bd2 Author: Martin Blumenstingl Date: Sat Jun 7 00:10:31 2025 +0200 drm/meson: use vclk_freq instead of pixel_freq in debug print [ Upstream commit faf2f8382088e8c74bd6eeb236c8c9190e61615e ] meson_vclk_vic_supported_freq() has a debug print which includes the pixel freq. However, within the whole function the pixel freq is irrelevant, other than checking the end of the params array. Switch to printing the vclk_freq which is being compared / matched against the inputs to the function to avoid confusion when analyzing error reports from users. Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup") Signed-off-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250606221031.3419353-1-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 6e60a77ca1c2584b6c06cb924ab741baf9d6cc47 Author: Martin Blumenstingl Date: Fri Jun 6 22:37:29 2025 +0200 drm/meson: fix debug log statement when setting the HDMI clocks [ Upstream commit d17e61ab63fb7747b340d6a66bf1408cd5c6562b ] The "phy" and "vclk" frequency labels were swapped, making it more difficult to debug driver errors. Swap the label order to make them match with the actual frequencies printed to correct this. Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup") Signed-off-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250606203729.3311592-1-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit f8a4ee5a01eb12ef0c6f10bbf0829c0682e36039 Author: Gabriel Dalimonte Date: Sun Jun 1 12:45:36 2025 -0400 drm/vc4: fix infinite EPROBE_DEFER loop [ Upstream commit c0317ad44f45b3c1f0ff46a4e28d14c7bccdedf4 ] `vc4_hdmi_audio_init` calls `devm_snd_dmaengine_pcm_register` which may return EPROBE_DEFER. Calling `drm_connector_hdmi_audio_init` adds a child device. The driver model docs[1] state that adding a child device prior to returning EPROBE_DEFER may result in an infinite loop. [1] https://www.kernel.org/doc/html/v6.14/driver-api/driver-model/driver.html Fixes: 9640f1437a88 ("drm/vc4: hdmi: switch to using generic HDMI Codec infrastructure") Signed-off-by: Gabriel Dalimonte Link: https://lore.kernel.org/r/20250601-vc4-audio-inf-probe-v2-1-9ad43c7b6147@gmail.com Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit dc23a7de3ba4087f6bf5f91014e0e99975d4b122 Author: Haren Myneni Date: Tue Jun 10 07:42:27 2025 +0530 powerpc/vas: Return -EINVAL if the offset is non-zero in mmap() [ Upstream commit 0d67f0dee6c9176bc09a5482dd7346e3a0f14d0b ] The user space calls mmap() to map VAS window paste address and the kernel returns the complete mapped page for each window. So return -EINVAL if non-zero is passed for offset parameter to mmap(). See Documentation/arch/powerpc/vas-api.rst for mmap() restrictions. Co-developed-by: Jonathan Greental Signed-off-by: Jonathan Greental Reported-by: Jonathan Greental Fixes: dda44eb29c23 ("powerpc/vas: Add VAS user space API") Signed-off-by: Haren Myneni Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250610021227.361980-2-maddy@linux.ibm.com Signed-off-by: Sasha Levin commit bbd5a9ddb0f9750783a48a871c9e12c0b68c5f39 Author: Ritesh Harjani (IBM) Date: Tue Jun 10 07:42:26 2025 +0530 powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmap [ Upstream commit cd097df4596f3a1e9d75eb8520162de1eb8485b2 ] memtrace mmap issue has an out of bounds issue. This patch fixes the by checking that the requested mapping region size should stay within the allocated region size. Reported-by: Jonathan Greental Fixes: 08a022ad3dfa ("powerpc/powernv/memtrace: Allow mmaping trace buffers") Signed-off-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250610021227.361980-1-maddy@linux.ibm.com Signed-off-by: Sasha Levin commit 82448d4dcd8406dec688632a405fdcf7f170ec69 Author: Eric Dumazet Date: Fri Jun 6 16:51:27 2025 +0000 net_sched: sch_sfq: fix a potential crash on gso_skb handling [ Upstream commit 82ffbe7776d0ac084031f114167712269bf3d832 ] SFQ has an assumption of always being able to queue at least one packet. However, after the blamed commit, sch->q.len can be inflated by packets in sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followed by an immediate drop. Fix sfq_drop() to properly clear q->tail in this situation. Tested: ip netns add lb ip link add dev to-lb type veth peer name in-lb netns lb ethtool -K to-lb tso off # force qdisc to requeue gso_skb ip netns exec lb ethtool -K in-lb gro on # enable NAPI ip link set dev to-lb up ip -netns lb link set dev in-lb up ip addr add dev to-lb 192.168.20.1/24 ip -netns lb addr add dev in-lb 192.168.20.2/24 tc qdisc replace dev to-lb root sfq limit 100 ip netns exec lb netserver netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & Fixes: a53851e2c321 ("net: sched: explicit locking in gso_cpu fallback") Reported-by: Marcus Wichelmann Closes: https://lore.kernel.org/netdev/9da42688-bfaa-4364-8797-e9271f3bdaef@hetzner-cloud.de/ Signed-off-by: Eric Dumazet Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20250606165127.3629486-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5ad8649e4cc6b108fbca12b4ef249fc827468ddc Author: Alok Tiwari Date: Fri May 30 12:29:35 2025 -0700 scsi: iscsi: Fix incorrect error path labels for flashnode operations [ Upstream commit 9b17621366d210ffee83262a8754086ebbde5e55 ] Correct the error handling goto labels used when host lookup fails in various flashnode-related event handlers: - iscsi_new_flashnode() - iscsi_del_flashnode() - iscsi_login_flashnode() - iscsi_logout_flashnode() - iscsi_logout_flashnode_sid() scsi_host_put() is not required when shost is NULL, so jumping to the correct label avoids unnecessary operations. These functions previously jumped to the wrong goto label (put_host), which did not match the intended cleanup logic. Use the correct exit labels (exit_new_fnode, exit_del_fnode, etc.) to ensure proper error handling. Also remove the unused put_host label under iscsi_new_flashnode() as it is no longer needed. No functional changes beyond accurate error path correction. Fixes: c6a4bb2ef596 ("[SCSI] scsi_transport_iscsi: Add flash node mgmt support") Signed-off-by: Alok Tiwari Link: https://lore.kernel.org/r/20250530193012.3312911-1-alok.a.tiwari@oracle.com Reviewed-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit dc4de0295975d5184545ac0e0061a67bbc57511d Author: Lizhi Hou Date: Wed Jun 4 07:32:17 2025 -0700 accel/amdxdna: Fix incorrect PSP firmware size [ Upstream commit 779a0c9e06a91d0007f2a4f4071e3b9a8102b15e ] The incorrect PSP firmware size is used for initializing. It may cause error for newer version firmware. Fixes: 8c9ff1b181ba ("accel/amdxdna: Add a new driver for AMD AI Engine") Acked-by: Alex Deucher Signed-off-by: Lizhi Hou Link: https://lore.kernel.org/r/20250604143217.1386272-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit beabaff7e8fd547137b750cb7c3ba243b87874b3 Author: Wojciech Slenska Date: Fri May 23 12:14:37 2025 +0200 pinctrl: qcom: pinctrl-qcm2290: Add missing pins [ Upstream commit 315345610faee8a0568b522dba9e35067d1732ab ] Added the missing pins to the qcm2290_pins table. Signed-off-by: Wojciech Slenska Fixes: 48e049ef1238 ("pinctrl: qcom: Add QCM2290 pinctrl driver") Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/20250523101437.59092-1-wojciech.slenska@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 87c4766dfed077e9816f7e0356a19f97e917ace9 Author: Félix Piédallu Date: Fri Jun 6 15:37:25 2025 +0200 spi: omap2-mcspi: Disable multi-mode when the previous message kept CS asserted [ Upstream commit 10c24e0d2f7cd2bc8a847cf750f01301ce67dbc8 ] When the last transfer of a SPI message has the cs_change flag, the CS is kept asserted after the message. The next message can't use multi-mode because the CS will be briefly deasserted before the first transfer. Remove the early exit of the list_for_each_entry because the last transfer actually needs to be always checked. Fixes: d153ff4056cb ("spi: omap2-mcspi: Add support for MULTI-mode") Signed-off-by: Félix Piédallu Link: https://patch.msgid.link/20250606-cs_change_fix-v1-2-27191a98a2e5@non.se.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c5d01b57ea8e129f0b22198f8c0507ece0e0df2d Author: Félix Piédallu Date: Fri Jun 6 15:37:24 2025 +0200 spi: omap2-mcspi: Disable multi mode when CS should be kept asserted after message [ Upstream commit a5bf5272295d3f058adeee025d2a0b6625f8ba7b ] When the last transfer of a SPI message has the cs_change flag, the CS is kept asserted after the message. Multi-mode can't respect this as CS is deasserted by the hardware at the end of the message. Disable multi-mode when not applicable to the current message. Fixes: d153ff4056cb ("spi: omap2-mcspi: Add support for MULTI-mode") Signed-off-by: Félix Piédallu Link: https://patch.msgid.link/20250606-cs_change_fix-v1-1-27191a98a2e5@non.se.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 009753ee1509f7dd62bc06cf90fa36c7546df4cb Author: Dan Carpenter Date: Tue May 27 08:44:14 2025 +0300 regulator: max20086: Fix refcount leak in max20086_parse_regulators_dt() [ Upstream commit 06118ae36855b7d3d22688298e74a766ccf0cb7a ] There is a missing call to of_node_put() if devm_kcalloc() fails. Fix this by changing the code to use cleanup.h magic to drop the refcount. Fixes: 6b0cd72757c6 ("regulator: max20086: fix invalid memory access") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/aDVRLqgJWMxYU03G@stanley.mountain Reviewed-by: Laurent Pinchart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 65e1b3404c211dcfaea02698539cdcd26647130f Author: Miaoqing Pan Date: Wed Jun 4 13:52:50 2025 +0800 wifi: ath12k: fix uaf in ath12k_core_init() [ Upstream commit f3fe49dbddd73f0155a8935af47cb63693069dbe ] When the execution of ath12k_core_hw_group_assign() or ath12k_core_hw_group_create() fails, the registered notifier chain is not unregistered properly. Its memory is freed after rmmod, which may trigger to a use-after-free (UAF) issue if there is a subsequent access to this notifier chain. Fixes the issue by calling ath12k_core_panic_notifier_unregister() in failure cases. Call trace: notifier_chain_register+0x4c/0x1f0 (P) atomic_notifier_chain_register+0x38/0x68 ath12k_core_init+0x50/0x4e8 [ath12k] ath12k_pci_probe+0x5f8/0xc28 [ath12k] pci_device_probe+0xbc/0x1a8 really_probe+0xc8/0x3a0 __driver_probe_device+0x84/0x1b0 driver_probe_device+0x44/0x130 __driver_attach+0xcc/0x208 bus_for_each_dev+0x84/0x100 driver_attach+0x2c/0x40 bus_add_driver+0x130/0x260 driver_register+0x70/0x138 __pci_register_driver+0x68/0x80 ath12k_pci_init+0x30/0x68 [ath12k] ath12k_init+0x28/0x78 [ath12k] Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 6f245ea0ec6c ("wifi: ath12k: introduce device group abstraction") Signed-off-by: Miaoqing Pan Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20250604055250.1228501-1-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit d71ac5694b33c80f1de97d074f6fbdc6c01a9d61 Author: Baochen Qiang Date: Fri May 23 10:23:05 2025 +0800 wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850 [ Upstream commit 7588a893cde5385ad308400ff167d29a29913b3a ] GCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash on some specific platforms. Since this register is divergent for WCN7850 and QCN9274, move it to register table to allow different definitions. Then correct the register address for WCN7850 to fix this issue. Note IPQ5332 is not affected as it is not PCIe based device. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Reported-by: Parth Pancholi Closes: https://lore.kernel.org/all/86899b2235a59c9134603beebe08f2bb0b244ea0.camel@gmail.com Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Tested-by: Parth Pancholi Link: https://patch.msgid.link/20250523-ath12k-wrong-global-reset-addr-v1-1-3b06eb556196@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit fb17af997327277e9ed92435f4fe72693f401149 Author: P Praneesh Date: Fri Mar 21 16:22:40 2025 +0530 wifi: ath12k: refactor ath12k_hw_regs structure [ Upstream commit 5257324583e32fd5bd6bbb6c82b4f5880b842f99 ] IPQ5332 device have different register address values for the below registers: HAL_TCL1_RING_BASE_LSB HAL_TCL1_RING_BASE_MSB HAL_TCL2_RING_BASE_LSB HAL_SEQ_WCSS_UMAC_CE0_SRC_REG HAL_SEQ_WCSS_UMAC_CE0_DST_REG HAL_SEQ_WCSS_UMAC_CE1_SRC_REG HAL_SEQ_WCSS_UMAC_CE1_DST_REG Hence, refactor ath12k_hw_regs structure to accommodate these changes in IPQ5332. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.3.1-00130-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00210-QCAHKSWPL_SILICONZ-1 Signed-off-by: P Praneesh Co-developed-by: Balamurugan S Signed-off-by: Balamurugan S Reviewed-by: Vasanthakumar Thiagarajan Signed-off-by: Raj Kumar Bhagat Link: https://patch.msgid.link/20250321-ath12k-ahb-v12-3-bb389ed76ae5@quicinc.com Signed-off-by: Jeff Johnson Stable-dep-of: 7588a893cde5 ("wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850") Signed-off-by: Sasha Levin commit 27471a512caf8948960f3d2ddefd3d774bb7c92d Author: Rodrigo Gobbi Date: Thu May 22 17:01:12 2025 -0300 wifi: ath11k: validate ath11k_crypto_mode on top of ath11k_core_qmi_firmware_ready [ Upstream commit b0d226a60856a1b765bb9a3848c7b2322fd08c47 ] if ath11k_crypto_mode is invalid (not ATH11K_CRYPT_MODE_SW/ATH11K_CRYPT_MODE_HW), ath11k_core_qmi_firmware_ready() will not undo some actions that was previously started/configured. Do the validation as soon as possible in order to avoid undoing actions in that case and also to fix the following smatch warning: drivers/net/wireless/ath/ath11k/core.c:2166 ath11k_core_qmi_firmware_ready() warn: missing unwind goto? Signed-off-by: Rodrigo Gobbi Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202304151955.oqAetVFd-lkp@intel.com/ Fixes: aa2092a9bab3 ("ath11k: add raw mode and software crypto support") Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20250522200519.16858-1-rodrigo.gobbi.7@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit cfb834c6f3afc78e95e80d024785fe25ef12831b Author: Baochen Qiang Date: Thu Feb 20 16:24:45 2025 +0800 wifi: ath11k: move some firmware stats related functions outside of debugfs [ Upstream commit 72610ed7d79da17ee09102534d6c696a4ea8a08e ] Commit b488c766442f ("ath11k: report rssi of each chain to mac80211 for QCA6390/WCN6855") and commit c3b39553fc77 ("ath11k: add signal report to mac80211 for QCA6390 and WCN6855") call debugfs functions in mac ops. Those functions are no-ops if CONFIG_ATH11K_DEBUGFS is not enabled, thus cause wrong status reported. Move them to mac.c. Besides, since WMI_REQUEST_RSSI_PER_CHAIN_STAT and WMI_REQUEST_VDEV_STAT stats could also be requested via mac ops, process them directly in ath11k_update_stats_event(). Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.37 Fixes: b488c766442f ("ath11k: report rssi of each chain to mac80211 for QCA6390/WCN6855") Fixes: c3b39553fc77 ("ath11k: add signal report to mac80211 for QCA6390 and WCN6855") Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250220082448.31039-5-quic_bqiang@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 75aa65cd9e2f49d8ca9f63863bc82c81335bafd5 Author: Baochen Qiang Date: Thu Feb 20 16:24:44 2025 +0800 wifi: ath11k: don't wait when there is no vdev started [ Upstream commit 3b6d00fa883075dcaf49221538230e038a9c0b43 ] For WMI_REQUEST_VDEV_STAT request, firmware might split response into multiple events dut to buffer limit, hence currently in ath11k_debugfs_fw_stats_process() we wait until all events received. In case there is no vdev started, this results in that below condition would never get satisfied ((++ar->fw_stats.num_vdev_recvd) == total_vdevs_started) finally the requestor would be blocked until wait time out. The same applies to WMI_REQUEST_BCN_STAT request as well due to: ((++ar->fw_stats.num_bcn_recvd) == ar->num_started_vdevs) Change to check the number of started vdev first: if it is zero, finish wait directly; if not, follow the old way. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.37 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250220082448.31039-4-quic_bqiang@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit faea966f5a6801524fa341b33903c7014d48546e Author: Baochen Qiang Date: Thu Feb 20 16:24:43 2025 +0800 wifi: ath11k: don't use static variables in ath11k_debugfs_fw_stats_process() [ Upstream commit 2bcf73b2612dda7432f2c2eaad6679bd291791f2 ] Currently ath11k_debugfs_fw_stats_process() is using static variables to count firmware stat events. Taking num_vdev as an example, if for whatever reason ( say ar->num_started_vdevs is 0 or firmware bug etc.) the following condition (++num_vdev) == total_vdevs_started is not met, is_end is not set thus num_vdev won't be cleared. Next time when firmware stats is requested again, even if everything is working fine, we will fail due to the condition above will never be satisfied. The same applies to num_bcn as well. Change to use non-static counters so that we have a chance to clear them each time firmware stats is requested. Currently only ath11k_fw_stats_request() and ath11k_debugfs_fw_stats_request() are requesting firmware stats, so clear counters there. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.37 Fixes: da3a9d3c1576 ("ath11k: refactor debugfs code into debugfs.c") Signed-off-by: Baochen Qiang Acked-by: Kalle Valo Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250220082448.31039-3-quic_bqiang@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 913c7c2448e5cc90cdac1262b5e23fe1107535fa Author: Baochen Qiang Date: Thu Feb 20 16:24:42 2025 +0800 wifi: ath11k: avoid burning CPU in ath11k_debugfs_fw_stats_request() [ Upstream commit 9f6e82d11bb9692a90d20b10f87345598945c803 ] We get report [1] that CPU is running a hot loop in ath11k_debugfs_fw_stats_request(): 94.60% 0.00% i3status [kernel.kallsyms] [k] do_syscall_64 | --94.60%--do_syscall_64 | --94.55%--__sys_sendmsg ___sys_sendmsg ____sys_sendmsg netlink_sendmsg netlink_unicast genl_rcv netlink_rcv_skb genl_rcv_msg | --94.55%--genl_family_rcv_msg_dumpit __netlink_dump_start netlink_dump genl_dumpit nl80211_dump_station | --94.55%--ieee80211_dump_station sta_set_sinfo | --94.55%--ath11k_mac_op_sta_statistics ath11k_debugfs_get_fw_stats | --94.55%--ath11k_debugfs_fw_stats_request | |--41.73%--_raw_spin_lock_bh | |--22.74%--__local_bh_enable_ip | |--9.22%--_raw_spin_unlock_bh | --6.66%--srso_alias_safe_ret This is because, if for whatever reason ar->fw_stats_done is not set by ath11k_update_stats_event(), ath11k_debugfs_fw_stats_request() won't yield CPU before an up to 3s timeout. Change to completion mechanism to avoid CPU burning. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.37 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Reported-by: Yury Vostrikov Closes: https://lore.kernel.org/all/7324ac7a-8b7a-42a5-aa19-de52138ff638@app.fastmail.com/ # [1] Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250220082448.31039-2-quic_bqiang@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit d255701eb5fc852ed3b29fcd191d2a56e002005a Author: Casey Connolly Date: Tue Mar 18 20:50:27 2025 +0000 ath10k: snoc: fix unbalanced IRQ enable in crash recovery [ Upstream commit 1650d32b92b01db03a1a95d69ee74fcbc34d4b00 ] In ath10k_snoc_hif_stop() we skip disabling the IRQs in the crash recovery flow, but we still unconditionally call enable again in ath10k_snoc_hif_start(). We can't check the ATH10K_FLAG_CRASH_FLUSH bit since it is cleared before hif_start() is called, so instead check the ATH10K_SNOC_FLAG_RECOVERY flag and skip enabling the IRQs during crash recovery. This fixes unbalanced IRQ enable splats that happen after recovering from a crash. Fixes: 0e622f67e041 ("ath10k: add support for WCN3990 firmware crash recovery") Signed-off-by: Caleb Connolly Tested-by: Loic Poulain Link: https://patch.msgid.link/20250318205043.1043148-1-caleb.connolly@linaro.org Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit ef8fc007c28a30a4c0d90bf755e0f343d99bb392 Author: Jeongjun Park Date: Wed May 21 01:07:17 2025 +0900 ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use() [ Upstream commit 87f7ce260a3c838b49e1dc1ceedf1006795157a2 ] There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use. However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store(). ============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415 but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK *** .... ============================================ The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use(). The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 before unregistering vclocks, and all functions are already written this way. And in the function that uses ptp->n_vclocks, we already get ptp->n_vclocks_mux before unregistering vclocks. Therefore, we need to remove the redundant check for ptp->n_vclocks in ptp_vclock_in_use() to prevent recursive locking. Fixes: 73f37068d540 ("ptp: support ptp physical/virtual clocks conversion") Signed-off-by: Jeongjun Park Acked-by: Richard Cochran Link: https://patch.msgid.link/20250520160717.7350-1-aha310510@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1b6543cbf5e10a35ee3c17952ed1f066829964a6 Author: Jonas Gorski Date: Mon Jun 2 21:49:14 2025 +0200 net: dsa: b53: fix untagged traffic sent via cpu tagged with VID 0 [ Upstream commit 692eb9f8a5b71d852e873375d20cf5da7a046ea6 ] When Linux sends out untagged traffic from a port, it will enter the CPU port without any VLAN tag, even if the port is a member of a vlan filtering bridge with a PVID egress untagged VLAN. This makes the CPU port's PVID take effect, and the PVID's VLAN table entry controls if the packet will be tagged on egress. Since commit 45e9d59d3950 ("net: dsa: b53: do not allow to configure VLAN 0") we remove bridged ports from VLAN 0 when joining or leaving a VLAN aware bridge. But we also clear the untagged bit, causing untagged traffic from the controller to become tagged with VID 0 (and priority 0). Fix this by not touching the untagged map of VLAN 0. Additionally, always keep the CPU port as a member, as the untag map is only effective as long as there is at least one member, and we would remove it when bridging all ports and leaving no standalone ports. Since Linux (and the switch) treats VLAN 0 tagged traffic like untagged, the actual impact of this is rather low, but this also prevented earlier detection of the issue. Fixes: 45e9d59d3950 ("net: dsa: b53: do not allow to configure VLAN 0") Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20250602194914.1011890-1-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d7882db79135c829a922daf3571f33ea1e056ae3 Author: Luiz Augusto von Dentz Date: Tue May 20 15:42:21 2025 -0400 Bluetooth: MGMT: Protect mgmt_pending list with its own lock [ Upstream commit 6fe26f694c824b8a4dbf50c635bee1302e3f099c ] This uses a mutex to protect from concurrent access of mgmt_pending list which can cause crashes like: ================================================================== BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318 CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_address_description+0xa8/0x254 mm/kasan/report.c:408 print_report+0x68/0x84 mm/kasan/report.c:521 kasan_report+0xb0/0x110 mm/kasan/report.c:634 __asan_report_load2_noabort+0x20/0x2c mm/kasan/report_generic.c:379 hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 mgmt_pending_find+0x7c/0x140 net/bluetooth/mgmt_util.c:223 pending_find net/bluetooth/mgmt.c:947 [inline] remove_adv_monitor+0x44/0x1a4 net/bluetooth/mgmt.c:5445 hci_mgmt_cmd+0x780/0xc00 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x544/0xbb0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x25c/0x378 net/socket.c:1131 new_sync_write fs/read_write.c:591 [inline] vfs_write+0x62c/0x97c fs/read_write.c:684 ksys_write+0x120/0x210 fs/read_write.c:736 __do_sys_write fs/read_write.c:747 [inline] __se_sys_write fs/read_write.c:744 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:744 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Allocated by task 7037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x54 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x9c/0xb4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4327 [inline] __kmalloc_noprof+0x2fc/0x4c8 mm/slub.c:4339 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xc4/0x1f0 net/core/sock.c:2198 sk_alloc+0x44/0x3ac net/core/sock.c:2254 bt_sock_alloc+0x4c/0x300 net/bluetooth/af_bluetooth.c:148 hci_sock_create+0xa8/0x194 net/bluetooth/hci_sock.c:2202 bt_sock_create+0x14c/0x24c net/bluetooth/af_bluetooth.c:132 __sock_create+0x43c/0x91c net/socket.c:1541 sock_create net/socket.c:1599 [inline] __sys_socket_create net/socket.c:1636 [inline] __sys_socket+0xd4/0x1c0 net/socket.c:1683 __do_sys_socket net/socket.c:1697 [inline] __se_sys_socket net/socket.c:1695 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1695 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Freed by task 6607: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_free_info+0x58/0x70 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x68/0x88 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2380 [inline] slab_free mm/slub.c:4642 [inline] kfree+0x17c/0x474 mm/slub.c:4841 sk_prot_free net/core/sock.c:2237 [inline] __sk_destruct+0x4f4/0x760 net/core/sock.c:2332 sk_destruct net/core/sock.c:2360 [inline] __sk_free+0x320/0x430 net/core/sock.c:2371 sk_free+0x60/0xc8 net/core/sock.c:2382 sock_put include/net/sock.h:1944 [inline] mgmt_pending_free+0x88/0x118 net/bluetooth/mgmt_util.c:290 mgmt_pending_remove+0xec/0x104 net/bluetooth/mgmt_util.c:298 mgmt_set_powered_complete+0x418/0x5cc net/bluetooth/mgmt.c:1355 hci_cmd_sync_work+0x204/0x33c net/bluetooth/hci_sync.c:334 process_one_work+0x7e8/0x156c kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x958/0xed8 kernel/workqueue.c:3400 kthread+0x5fc/0x75c kernel/kthread.c:464 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847 Fixes: a380b6cff1a2 ("Bluetooth: Add generic mgmt helper API") Closes: https://syzkaller.appspot.com/bug?extid=0a7039d5d9986ff4ecec Closes: https://syzkaller.appspot.com/bug?extid=cc0cc52e7f43dc9e6df1 Reported-by: syzbot+0a7039d5d9986ff4ecec@syzkaller.appspotmail.com Tested-by: syzbot+0a7039d5d9986ff4ecec@syzkaller.appspotmail.com Tested-by: syzbot+cc0cc52e7f43dc9e6df1@syzkaller.appspotmail.com Signed-off-by: Dmitry Antipov Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 32aa2fbe319f33b0318ec6f4fceb63879771a286 Author: Luiz Augusto von Dentz Date: Tue Jun 3 16:12:39 2025 -0400 Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete [ Upstream commit e6ed54e86aae9e4f7286ce8d5c73780f91b48d1c ] This reworks MGMT_OP_REMOVE_ADV_MONITOR to not use mgmt_pending_add to avoid crashes like bellow: ================================================================== BUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406 Read of size 8 at addr ffff88801c53f318 by task kworker/u5:5/5341 CPU: 0 UID: 0 PID: 5341 Comm: kworker/u5:5 Not tainted 6.15.0-syzkaller-10402-g4cb6c8af8591 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406 hci_cmd_sync_work+0x261/0x3a0 net/bluetooth/hci_sync.c:334 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 5987: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] mgmt_pending_new+0x65/0x240 net/bluetooth/mgmt_util.c:252 mgmt_pending_add+0x34/0x120 net/bluetooth/mgmt_util.c:279 remove_adv_monitor+0x103/0x1b0 net/bluetooth/mgmt.c:5454 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x548/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5989: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2380 [inline] slab_free mm/slub.c:4642 [inline] kfree+0x18e/0x440 mm/slub.c:4841 mgmt_pending_foreach+0xc9/0x120 net/bluetooth/mgmt_util.c:242 mgmt_index_removed+0x10d/0x2f0 net/bluetooth/mgmt.c:9366 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314 __sys_bind_socket net/socket.c:1810 [inline] __sys_bind+0x2c3/0x3e0 net/socket.c:1841 __do_sys_bind net/socket.c:1846 [inline] __se_sys_bind net/socket.c:1844 [inline] __x64_sys_bind+0x7a/0x90 net/socket.c:1844 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 66bd095ab5d4 ("Bluetooth: advmon offload MSFT remove monitor") Closes: https://syzkaller.appspot.com/bug?extid=feb0dc579bbe30a13190 Reported-by: syzbot+feb0dc579bbe30a13190@syzkaller.appspotmail.com Tested-by: syzbot+feb0dc579bbe30a13190@syzkaller.appspotmail.com Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4b372e5414f49020aee85f973dae0068a9d9d9f6 Author: Chandrashekar Devegowda Date: Tue Jun 3 15:34:40 2025 +0530 Bluetooth: btintel_pcie: Reduce driver buffer posting to prevent race condition [ Upstream commit bf2ffc4d14db29cab781549912d2dc69127f4d3e ] Modify the driver to post 3 fewer buffers than the maximum rx buffers (64) allowed for the firmware. This change mitigates a hardware issue causing a race condition in the firmware, improving stability and data handling. Signed-off-by: Chandrashekar Devegowda Signed-off-by: Kiran K Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit bdc06cb53d47d74ee0853cc017b02e707aaa881e Author: Chandrashekar Devegowda Date: Tue Jun 3 15:34:39 2025 +0530 Bluetooth: btintel_pcie: Increase the tx and rx descriptor count [ Upstream commit 2dd711102ce69ae41f65d09c012441227d4aa983 ] This change addresses latency issues observed in HID use cases where events arrive in bursts. By increasing the Rx descriptor count to 64, the firmware can handle bursty data more effectively, reducing latency and preventing buffer overflows. Signed-off-by: Chandrashekar Devegowda Signed-off-by: Kiran K Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7aae7846496c56036e6c45191836893dd80f63de Author: Kiran K Date: Tue Jun 3 15:34:38 2025 +0530 Bluetooth: btintel_pcie: Fix driver not posting maximum rx buffers [ Upstream commit daabd276985055250528da97e9ce6d277d7009c2 ] The driver was posting only 6 rx buffers, despite the maximum rx buffers being defined as 16. Having fewer RX buffers caused firmware exceptions in HID use cases when events arrived in bursts. Exception seen on android 6.12 kernel. E Bluetooth: hci0: Received hw exception interrupt E Bluetooth: hci0: Received gp1 mailbox interrupt D Bluetooth: hci0: 00000000: ff 3e 87 80 03 01 01 01 03 01 0c 0d 02 1c 10 0e D Bluetooth: hci0: 00000010: 01 00 05 14 66 b0 28 b0 c0 b0 28 b0 ac af 28 b0 D Bluetooth: hci0: 00000020: 14 f1 28 b0 00 00 00 00 fa 04 00 00 00 00 40 10 D Bluetooth: hci0: 00000030: 08 00 00 00 7a 7a 7a 7a 47 00 fb a0 10 00 00 00 D Bluetooth: hci0: 00000000: 10 01 0a E Bluetooth: hci0: ---- Dump of debug registers — E Bluetooth: hci0: boot stage: 0xe0fb0047 E Bluetooth: hci0: ipc status: 0x00000004 E Bluetooth: hci0: ipc control: 0x00000000 E Bluetooth: hci0: ipc sleep control: 0x00000000 E Bluetooth: hci0: mbox_1: 0x00badbad E Bluetooth: hci0: mbox_2: 0x0000101c E Bluetooth: hci0: mbox_3: 0x00000008 E Bluetooth: hci0: mbox_4: 0x7a7a7a7a Signed-off-by: Chandrashekar Devegowda Signed-off-by: Kiran K Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 8e5e05c973f765e6e46f831527154563ea0ffefb Author: Pauli Virtanen Date: Sat May 31 18:24:58 2025 +0300 Bluetooth: hci_core: fix list_for_each_entry_rcu usage [ Upstream commit 308a3a8ce8ea41b26c46169f3263e50f5997c28e ] Releasing + re-acquiring RCU lock inside list_for_each_entry_rcu() loop body is not correct. Fix by taking the update-side hdev->lock instead. Fixes: c7eaf80bfb0c ("Bluetooth: Fix hci_link_tx_to RCU lock usage") Signed-off-by: Pauli Virtanen Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit bb37f795d01961286b8f768a6d7152f32b589067 Author: Sanjeev Yadav Date: Fri May 23 13:14:01 2025 -0700 scsi: core: ufs: Fix a hang in the error handler [ Upstream commit 8a3514d348de87a9d5e2ac00fbac4faae0b97996 ] ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before. Backtrace: __switch_to+0x174/0x338 __schedule+0x600/0x9e4 schedule+0x7c/0xe8 schedule_timeout+0xa4/0x1c8 io_schedule_timeout+0x48/0x70 wait_for_common_io+0xa8/0x160 //waiting on START_STOP wait_for_completion_io_timeout+0x10/0x20 blk_execute_rq+0xe4/0x1e4 scsi_execute_cmd+0x108/0x244 ufshcd_set_dev_pwr_mode+0xe8/0x250 __ufshcd_wl_resume+0x94/0x354 ufshcd_wl_runtime_resume+0x3c/0x174 scsi_runtime_resume+0x64/0xa4 rpm_resume+0x15c/0xa1c __pm_runtime_resume+0x4c/0x90 // Runtime resume ongoing ufshcd_err_handler+0x1a0/0xd08 process_one_work+0x174/0x808 worker_thread+0x15c/0x490 kthread+0xf4/0x1ec ret_from_fork+0x10/0x20 Signed-off-by: Sanjeev Yadav [ bvanassche: rewrote patch description ] Fixes: 62694735ca95 ("[SCSI] ufs: Add runtime PM support for UFS host controller driver") Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20250523201409.1676055-1-bvanassche@acm.org Reviewed-by: Peter Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e7d9e8f1341e332c7e16f89f53b486595e27c6e8 Author: Peter Griffin Date: Wed Apr 2 16:17:32 2025 +0100 pinctrl: samsung: add gs101 specific eint suspend/resume callbacks [ Upstream commit bdbe0a0f71003b997d6a2dbe4bc7b5b0438207c7 ] gs101 differs to other SoCs in that fltcon1 register doesn't always exist. Additionally the offset of fltcon0 is not fixed and needs to use the newly added eint_fltcon_offset variable. Fixes: 4a8be01a1a7a ("pinctrl: samsung: Add gs101 SoC pinctrl configuration") Cc: stable@vger.kernel.org # depends on the previous three patches Reviewed-by: André Draszik Signed-off-by: Peter Griffin Link: https://lore.kernel.org/r/20250402-pinctrl-fltcon-suspend-v6-3-78ce0d4eb30c@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit e526f7753e549484ec5d652ad6e42529deb724f6 Author: Peter Griffin Date: Wed Apr 2 16:17:31 2025 +0100 pinctrl: samsung: add dedicated SoC eint suspend/resume callbacks [ Upstream commit 77ac6b742eba063a5b6600cda67834a7a212281a ] Refactor the existing platform specific suspend/resume callback so that each SoC variant has it's own callback containing the SoC specific logic. This allows exynosautov920 to have a dedicated function for using eint_con_offset and eint_mask_offset. Also it is easily extendable for gs101 which will need dedicated logic for handling the varying register offset of fltcon0 via eint_fltcon_offset. Reviewed-by: André Draszik Signed-off-by: Peter Griffin Link: https://lore.kernel.org/r/20250402-pinctrl-fltcon-suspend-v6-2-78ce0d4eb30c@linaro.org Signed-off-by: Krzysztof Kozlowski Stable-dep-of: bdbe0a0f7100 ("pinctrl: samsung: add gs101 specific eint suspend/resume callbacks") Signed-off-by: Sasha Levin commit 57e204cdeeb671f225d662fa259a79e6065ad5b1 Author: Peter Griffin Date: Wed Apr 2 16:17:30 2025 +0100 pinctrl: samsung: refactor drvdata suspend & resume callbacks [ Upstream commit 3ade961e97f3b05dcdd9a4fabfe179c9e75571e0 ] This enables the clk_enable() and clk_disable() logic to be removed from each callback, but otherwise should have no functional impact. It is a prepatory patch so that the callbacks can become SoC specific. Signed-off-by: Peter Griffin Link: https://lore.kernel.org/r/20250402-pinctrl-fltcon-suspend-v6-1-78ce0d4eb30c@linaro.org Signed-off-by: Krzysztof Kozlowski Stable-dep-of: bdbe0a0f7100 ("pinctrl: samsung: add gs101 specific eint suspend/resume callbacks") Signed-off-by: Sasha Levin commit 32e1708dab890f7ec29d7bccf30b0460bfb63f23 Author: Gautham R. Shenoy Date: Thu May 29 17:18:25 2025 +0530 tools/power turbostat: Fix AMD package-energy reporting [ Upstream commit adb49732c8c63665dd3476e8e6b7c67a0f851245 ] commit 05a2f07db888 ("tools/power turbostat: read RAPL counters via perf") that adds support to read RAPL counters via perf defines the notion of a RAPL domain_id which is set to physical_core_id on platforms which support per_core_rapl counters (Eg: AMD processors Family 17h onwards) and is set to the physical_package_id on all the other platforms. However, the physical_core_id is only unique within a package and on platforms with multiple packages more than one core can have the same physical_core_id and thus the same domain_id. (For eg, the first cores of each package have the physical_core_id = 0). This results in all these cores with the same physical_core_id using the same entry in the rapl_counter_info_perdomain[]. Since rapl_perf_init() skips the perf-initialization for cores whose domain_ids have already been visited, cores that have the same physical_core_id always read the perf file corresponding to the physical_core_id of the first package and thus the package-energy is incorrectly reported to be the same value for different packages. Note: This issue only arises when RAPL counters are read via perf and not when they are read via MSRs since in the latter case the MSRs are read separately on each core. Fix this issue by associating each CPU with rapl_core_id which is unique across all the packages in the system. Fixes: 05a2f07db888 ("tools/power turbostat: read RAPL counters via perf") Signed-off-by: Gautham R. Shenoy Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit c74a5f8297321b2d57ed9b7f04df11efc525fb5e Author: Petr Pavlu Date: Tue Jun 3 15:02:09 2025 +0200 genksyms: Fix enum consts from a reference affecting new values [ Upstream commit c50a04f8f45c7f13972f9097622d1d929033ea8c ] Enumeration constants read from a symbol reference file can incorrectly affect new enumeration constants parsed from an actual input file. Example: $ cat test.c enum { E_A, E_B, E_MAX }; struct bar { int mem[E_MAX]; }; int foo(struct bar *a) {} __GENKSYMS_EXPORT_SYMBOL(foo); $ cat test.c | ./scripts/genksyms/genksyms -T test.0.symtypes #SYMVER foo 0x070d854d $ cat test.0.symtypes E#E_MAX 2 s#bar struct bar { int mem [ E#E_MAX ] ; } foo int foo ( s#bar * ) $ cat test.c | ./scripts/genksyms/genksyms -T test.1.symtypes -r test.0.symtypes :4: warning: foo: modversion changed because of changes in enum constant E_MAX #SYMVER foo 0x9c9dfd81 $ cat test.1.symtypes E#E_MAX ( 2 ) + 3 s#bar struct bar { int mem [ E#E_MAX ] ; } foo int foo ( s#bar * ) The __add_symbol() function includes logic to handle the incrementation of enumeration values, but this code is also invoked when reading a reference file. As a result, the variables last_enum_expr and enum_counter might be incorrectly set after reading the reference file, which later affects parsing of the actual input. Fix the problem by splitting the logic for the incrementation of enumeration values into a separate function process_enum() and call it from __add_symbol() only when processing non-reference data. Fixes: e37ddb825003 ("genksyms: Track changes to enum constants") Signed-off-by: Petr Pavlu Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 19554c79a2095ddde850906a067915c1ef3a4114 Author: Al Viro Date: Wed Jun 4 12:27:08 2025 -0400 do_change_type(): refuse to operate on unmounted/not ours mounts [ Upstream commit 12f147ddd6de7382dad54812e65f3f08d05809fc ] Ensure that propagation settings can only be changed for mounts located in the caller's mount namespace. This change aligns permission checking with the rest of mount(2). Reviewed-by: Christian Brauner Fixes: 07b20889e305 ("beginning of the shared-subtree proper") Reported-by: "Orlando, Noah" Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 38628ae06e2a37770cd794802a3f1310cf9846e3 Author: Al Viro Date: Sun Jun 1 20:11:06 2025 -0400 clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns [ Upstream commit c28f922c9dcee0e4876a2c095939d77fe7e15116 ] What we want is to verify there is that clone won't expose something hidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo" may be a result of MNT_LOCKED on a child, but it may also come from lacking admin rights in the userns of the namespace mount belongs to. clone_private_mnt() checks the former, but not the latter. There's a number of rather confusing CAP_SYS_ADMIN checks in various userns during the mount, especially with the new mount API; they serve different purposes and in case of clone_private_mnt() they usually, but not always end up covering the missing check mentioned above. Reviewed-by: Christian Brauner Reported-by: "Orlando, Noah" Fixes: 427215d85e8d ("ovl: prevent private clone if bind mount is not allowed") Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 7e56b53b6f17a7bcaab9f5f38215411920e6880f Author: KONDO KAZUMA(近藤　和真) Date: Thu May 15 12:18:30 2025 +0000 fs: allow clone_private_mount() for a path on real rootfs [ Upstream commit 4954346d80fb047cb78776d9f2ebd6a050f80c5f ] Mounting overlayfs with a directory on real rootfs (initramfs) as upperdir has failed with following message since commit db04662e2f4f ("fs: allow detached mounts in clone_private_mount()"). [ 4.080134] overlayfs: failed to clone upperpath Overlayfs mount uses clone_private_mount() to create internal mount for the underlying layers. The commit made clone_private_mount() reject real rootfs because it does not have a parent mount and is in the initial mount namespace, that is not an anonymous mount namespace. This issue can be fixed by modifying the permission check of clone_private_mount() following [1]. Reviewed-by: Christian Brauner Fixes: db04662e2f4f ("fs: allow detached mounts in clone_private_mount()") Link: https://lore.kernel.org/all/20250514190252.GQ2023217@ZenIV/ [1] Link: https://lore.kernel.org/all/20250506194849.GT2023217@ZenIV/ Suggested-by: Al Viro Signed-off-by: Kazuma Kondo Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 327d444c951752fcba2e960eef4c0226ba4d0edc Author: Al Viro Date: Tue Jun 3 17:57:27 2025 -0400 fix propagation graph breakage by MOVE_MOUNT_SET_GROUP move_mount(2) [ Upstream commit d8cc0362f918d020ca1340d7694f07062dc30f36 ] 9ffb14ef61ba "move_mount: allow to add a mount into an existing group" breaks assertions on ->mnt_share/->mnt_slave. For once, the data structures in question are actually documented. Documentation/filesystem/sharedsubtree.rst: All vfsmounts in a peer group have the same ->mnt_master. If it is non-NULL, they form a contiguous (ordered) segment of slave list. do_set_group() puts a mount into the same place in propagation graph as the old one. As the result, if old mount gets events from somewhere and is not a pure event sink, new one needs to be placed next to the old one in the slave list the old one's on. If it is a pure event sink, we only need to make sure the new one doesn't end up in the middle of some peer group. "move_mount: allow to add a mount into an existing group" ends up putting the new one in the beginning of list; that's definitely not going to be in the middle of anything, so that's fine for case when old is not marked shared. In case when old one _is_ marked shared (i.e. is not a pure event sink), that breaks the assumptions of propagation graph iterators. Put the new mount next to the old one on the list - that does the right thing in "old is marked shared" case and is just as correct as the current behaviour if old is not marked shared (kudos to Pavel for pointing that out - my original suggested fix changed behaviour in the "nor marked" case, which complicated things for no good reason). Reviewed-by: Christian Brauner Fixes: 9ffb14ef61ba ("move_mount: allow to add a mount into an existing group") Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 11b8e4e742dea9375152da4cab8fefcf230f1f48 Author: Al Viro Date: Sun May 4 13:28:37 2025 -0400 finish_automount(): don't leak MNT_LOCKED from parent to child [ Upstream commit bab77c0d191e241d2d59a845c7ed68bfa6e1b257 ] Intention for MNT_LOCKED had always been to protect the internal mountpoints within a subtree that got copied across the userns boundary, not the mountpoint that tree got attached to - after all, it _was_ exposed before the copying. For roots of secondary copies that is enforced in attach_recursive_mnt() - MNT_LOCKED is explicitly stripped for those. For the root of primary copy we are almost always guaranteed that MNT_LOCKED won't be there, so attach_recursive_mnt() doesn't bother. Unfortunately, one call chain got overlooked - triggering e.g. NFS referral will have the submount inherit the public flags from parent; that's fine for such things as read-only, nosuid, etc., but not for MNT_LOCKED. This is particularly pointless since the mount attached by finish_automount() is usually expirable, which makes any protection granted by MNT_LOCKED null and void; just wait for a while and that mount will go away on its own. Include MNT_LOCKED into the set of flags to be ignored by do_add_mount() - it really is an internal flag. Reviewed-by: Christian Brauner Fixes: 5ff9d8a65ce8 ("vfs: Lock in place mounts from more privileged users") Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 8fb8dd7505a9960e8c7122e3b19a4bb6aedcf1f1 Author: Stephen Brennan Date: Wed May 7 15:34:01 2025 -0700 fs: convert mount flags to enum [ Upstream commit 101f2bbab541116ab861b9c3ac0ece07a7eaa756 ] In prior kernel versions (5.8-6.8), commit 9f6c61f96f2d9 ("proc/mounts: add cursor") introduced MNT_CURSOR, a flag used by readers from /proc/mounts to keep their place while reading the file. Later, commit 2eea9ce4310d8 ("mounts: keep list of mounts in an rbtree") removed this flag and its value has since been repurposed. For debuggers iterating over the list of mounts, cursors should be skipped as they are irrelevant. Detecting whether an element is a cursor can be difficult. Since the MNT_CURSOR flag is a preprocessor constant, it's not present in debuginfo, and since its value is repurposed, we cannot hard-code it. For this specific issue, cursors are possible to detect in other ways, but ideally, we would be able to read the mount flag definitions out of the debuginfo. For that reason, convert the mount flags to an enum. Link: https://github.com/osandov/drgn/pull/496 Signed-off-by: Stephen Brennan Link: https://lore.kernel.org/20250507223402.2795029-1-stephen.s.brennan@oracle.com Signed-off-by: Christian Brauner Stable-dep-of: bab77c0d191e ("finish_automount(): don't leak MNT_LOCKED from parent to child") Signed-off-by: Sasha Levin commit 65b107ec5b9daba5f60e1ba96172b5b58df60ad0 Author: Al Viro Date: Sun Jun 1 14:02:26 2025 -0400 path_overmount(): avoid false negatives [ Upstream commit 5f31c549382bcddbbd754c72c5433b19420d485d ] Holding namespace_sem is enough to make sure that result remains valid. It is *not* enough to avoid false negatives from __lookup_mnt(). Mounts can be unhashed outside of namespace_sem (stuck children getting detached on final mntput() of lazy-umounted mount) and having an unrelated mount removed from the hash chain while we traverse it may end up with false negative from __lookup_mnt(). We need to sample and recheck the seqlock component of mount_lock... Bug predates the introduction of path_overmount() - it had come from the code in finish_automount() that got abstracted into that helper. Reviewed-by: Christian Brauner Fixes: 26df6034fdb2 ("fix automount/automount race properly") Fixes: 6ac392815628 ("fs: allow to mount beneath top mount") Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 287c7d34eedd37af1272dfb3b6e8656f4f026424 Author: Al Viro Date: Sun Jun 1 14:23:52 2025 -0400 fs/fhandle.c: fix a race in call of has_locked_children() [ Upstream commit 1f282cdc1d219c4a557f7009e81bc792820d9d9a ] may_decode_fh() is calling has_locked_children() while holding no locks. That's an oopsable race... The rest of the callers are safe since they are holding namespace_sem and are guaranteed a positive refcount on the mount in question. Rename the current has_locked_children() to __has_locked_children(), make it static and switch the fs/namespace.c users to it. Make has_locked_children() a wrapper for __has_locked_children(), calling the latter under read_seqlock_excl(&mount_lock). Reviewed-by: Christian Brauner Reviewed-by: Jeff Layton Fixes: 620c266f3949 ("fhandle: relax open_by_handle_at() permission checks") Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 43934322cda9a5130d888513e4825735bc1f53ca Author: Nitesh Shetty Date: Mon Apr 28 15:28:48 2025 +0530 iov_iter: use iov_offset for length calculation in iov_iter_aligned_bvec [ Upstream commit 334d7c4fb60cf21e0abac134d92fe49e9b04377e ] If iov_offset is non-zero, then we need to consider iov_offset in length calculation, otherwise we might pass smaller IOs such as 512 bytes, in below scenario [1]. This issue is reproducible using lib-uring test/fixed-seg.c application with fixed buffer on a 512 LBA formatted device. [1] At present we pass the alignment check, for 512 LBA formatted devices, len_mask = 511 when IO is smaller, i->count = 512 has an offset, i->io_offset = 3584 with bvec values, bvec->bv_offset = 256, bvec->bv_len = 3840. In short, the first 256 bytes are in the current page, next 256 bytes are in the another page. Ideally we expect to fail the IO. I can think of 2 userspace scenarios where we experience this. a: From userspace, we observe a different behaviour when device LBA size is 512 vs 4096 bytes. For 4096 LBA formatted device, I see the same liburing test [2] failing, whereas 512 the test passes without this. This is reproducible everytime. [2] https://github.com/axboe/liburing/ b: Although I was not able to reproduce the below condition, but I suspect below case should be possible from user space for devices with 512 LBA formatted device. Lets say from userspace while allocating a virtually single chunk of memory, if we get 2 physical chunk of memory, and IO happens to be at the boundary of first physical chunk with length crossing first chunk, then we allow IOs to proceed and hence we might map wrong physical address length and proceed with IO rather than failing. : --- a/test/fixed-seg.c : +++ b/test/fixed-seg.c : @@ -64,7 +64,7 @@ static int test(struct io_uring *ring, int fd, int : vec_off) : return T_EXIT_FAIL; : } : : - ret = read_it(ring, fd, 4096, vec_off); : + ret = read_it(ring, fd, 4096, 7*512 + 256); : if (ret) { : fprintf(stderr, "4096 0 failed\n"); : return T_EXIT_FAIL; Effectively this is a write crossing the page boundary. Link: https://lkml.kernel.org/r/20250428095849.11709-1-nj.shetty@samsung.com Fixes: 2263639f96f2 ("iov_iter: streamline iovec/bvec alignment iteration") Reviewed-by: Jens Axboe Reviewed-by: Anuj Gupta Signed-off-by: Nitesh Shetty Cc: Al Viro Cc: Christian Brauner Cc: Keith Busch Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 69c71b15802a291587c3fb512941c4b3f253f7cf Author: Yuuki NAGAO Date: Sat May 31 23:13:41 2025 +0900 ASoC: ti: omap-hdmi: Re-add dai_link->platform to fix card init [ Upstream commit bae071aa7bcd034054cec91666c80f812adeccd9 ] The removed dai_link->platform component cause a fail which is exposed at runtime. (ex: when a sound tool is used) This patch re-adds the dai_link->platform component to have a full card registered. Before this patch: $ aplay -l **** List of PLAYBACK Hardware Devices **** card 1: HDMI [HDMI], device 0: HDMI snd-soc-dummy-dai-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 $ speaker-test -D plughw:1,0 -t sine speaker-test 1.2.8 Playback device is plughw:1,0 Stream parameters are 48000Hz, S16_LE, 1 channels Sine wave rate is 440.0000Hz Playback open error: -22,Invalid argument After this patch which restores the platform component: $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: HDMI [HDMI], device 0: HDMI snd-soc-dummy-dai-0 [HDMI snd-soc-dummy-dai-0] Subdevices: 0/1 Subdevice #0: subdevice #0 -> Resolve the playback error. Fixes: 3b0db249cf8f ("ASoC: ti: remove unnecessary dai_link->platform") Signed-off-by: Yuuki NAGAO Link: https://patch.msgid.link/20250531141341.81164-1-wf.yn386@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2916794ffbce604cc2cda105f6b8a4a7c748dd7f Author: Cezary Rojewski Date: Fri May 30 16:10:23 2025 +0200 ASoC: Intel: avs: Verify content returned by parse_int_array() [ Upstream commit 93e246b6769bdacb09cfff4ea0f00fe5ab4f0d7a ] The first element of the returned array stores its length. If it is 0, any manipulation beyond the element at index 0 ends with null-ptr-deref. Fixes: 5a565ba23abe ("ASoC: Intel: avs: Probing and firmware tracing over debugfs") Reviewed-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20250530141025.2942936-8-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b234af87175a7d6663f03e638a66fe2e884b9323 Author: Cezary Rojewski Date: Fri May 30 16:10:22 2025 +0200 ASoC: Intel: avs: Verify kcalloc() status when setting constraints [ Upstream commit 5f342aeee2724d31046172eb5caab8e0e8afd57d ] All memory operations shall be checked. Fixes: f2f847461fb7 ("ASoC: Intel: avs: Constrain path based on BE capabilities") Reviewed-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20250530141025.2942936-7-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6e7e072fdfc3a5e2db3c3f7837956ad9419a3c4f Author: Amadeusz Sławiński Date: Fri May 30 16:10:21 2025 +0200 ASoC: Intel: avs: Fix paths in MODULE_FIRMWARE hints [ Upstream commit 9e3285be55e6c0829e451b4a341e3059da47ec9d ] The binaries for cAVS architecture are located in "intel/avs" subdirectory, not "intel". Fixes: 94aa347d34e0 ("ASoC: Intel: avs: Add MODULE_FIRMWARE to inform about FW") Reviewed-by: Cezary Rojewski Signed-off-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20250530141025.2942936-6-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1b99818b025f41ed307b05c437da8effc9638dfb Author: Cezary Rojewski Date: Mon Apr 7 13:23:46 2025 +0200 ASoC: Intel: avs: Relocate DSP status registers [ Upstream commit 75f3c607b1fa1f4d42cde8377cd2276ab01e287d ] The firmware status and error registers are not part of SRAM on ACE platforms. As these registers take part in IPC on ACE and cAVS platforms both, relocate the field denoting their offset to Host-IPC descriptor. In consequence, code remains cohesive with the ACE specs while still maintaining high readability for the cAVS platforms. Reviewed-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Acked-by: Liam Girdwood Link: https://patch.msgid.link/20250407112352.3720779-5-cezary.rojewski@intel.com Signed-off-by: Mark Brown Stable-dep-of: 9e3285be55e6 ("ASoC: Intel: avs: Fix paths in MODULE_FIRMWARE hints") Signed-off-by: Sasha Levin commit 85c3c6cf9a3f6944346e2640c4170e2981cd46b8 Author: Cezary Rojewski Date: Mon Apr 7 13:23:45 2025 +0200 ASoC: Intel: avs: Read HW capabilities when possible [ Upstream commit b9a3ec604993074eb6f5d08b14fb7913d1fae48b ] Starting with LunarLake (LNL) and onward, some hardware capabilities are visible to the sound driver directly. At the same time, these may no longer be visible to the AudioDSP firmware. Update resource allocation function to rely on the registers when possible. Reviewed-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Acked-by: Liam Girdwood Link: https://patch.msgid.link/20250407112352.3720779-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown Stable-dep-of: 9e3285be55e6 ("ASoC: Intel: avs: Fix paths in MODULE_FIRMWARE hints") Signed-off-by: Sasha Levin commit 49dcdee529bae3d8c4fe3f061cbf912afed4124a Author: Cezary Rojewski Date: Mon Apr 7 13:23:44 2025 +0200 ASoC: Intel: avs: Ignore Vendor-space manipulation for ACE [ Upstream commit acd2563f30886730757062b9b3efe8043daabbc3 ] A number of Vendor Specific registers utilized on cAVS architecture (SkyLake till RaptorLake) are not present on ACE hardware (MeteorLake onward). Similarly, certain recommended procedures do not apply. Adjust existing code to be ACE-friendly. Reviewed-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Acked-by: Liam Girdwood Link: https://patch.msgid.link/20250407112352.3720779-3-cezary.rojewski@intel.com Signed-off-by: Mark Brown Stable-dep-of: 9e3285be55e6 ("ASoC: Intel: avs: Fix paths in MODULE_FIRMWARE hints") Signed-off-by: Sasha Levin commit ea218ae05e60616531fe652650b98dcd3c328279 Author: Cezary Rojewski Date: Fri May 30 16:10:20 2025 +0200 ASoC: Intel: avs: Fix possible null-ptr-deref when initing hw [ Upstream commit 2f78724d4f0c665c83e202e3989d5333a2cb1036 ] Search result of avs_dai_find_path_template() shall be verified before being used. As 'template' is already known when avs_hw_constraints_init() is fired, drop the search entirely. Fixes: f2f847461fb7 ("ASoC: Intel: avs: Constrain path based on BE capabilities") Reviewed-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20250530141025.2942936-5-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 61dc63da2b1a899b5e3a6091b914ccad64708765 Author: Cezary Rojewski Date: Fri May 30 16:10:19 2025 +0200 ASoC: Intel: avs: Fix PPLCxFMT calculation [ Upstream commit 347c8d6db7c9d65d93ef226849b273823f54eaea ] HDAudio transfer types utilize SDxFMT for front-end (HOST) and PPLCxFMT for back-end (LINK) side when setting up the stream. BE's substream->runtime duplicates FE runtime so switch to using BE's hw_params to address incorrect format values on the LINK side when FE and BE formats differ. The problem is introduced with commit d070002a20fc ("ASoC: Intel: avs: HDA PCM BE operations") but the code has been shuffled around since then so direct 'Fixes:' tag does not apply. Reviewed-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20250530141025.2942936-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 50279a5447c1a667e6d7d480e45ca3070a55d860 Author: Cezary Rojewski Date: Mon Apr 7 13:23:48 2025 +0200 ASoC: Intel: avs: PCM operations for LNL-based platforms [ Upstream commit 716643786f140f2d68f22424c75b9198ffe14290 ] Starting from LNL platform the so-called non-HDAudio transfer types, e.g.: I2S/DMIC, utilize HDAudio LINK DMA rather than GPDMA for the data streaming. In essence, all transfer types now utilize HDAudio Link. Most of the existing code can be reused with the major difference being HDAudio Link query method: - fetch the Link by codec.addr in standard HDAudio transfer case - fetch the Link by LEPTR.ID in non-HDAudio transfer case To make the unification happen, store pointer to the Link in dma_data and utilize it in the common code. And to avoid confusion in transfer-type naming between cAVS-ACE 1.x (SkyLake till MeteorLake) and ACE 2.0+ architecture (LunarLake onward), use: - 'hda' for typical HDAudio transfer case - 'nonhda' for non-HDAudio transfer case, cAVS-ACE 1.x - 'althda' for non-HDAudio transfer case, ACE 2.0+ Reviewed-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Acked-by: Liam Girdwood Link: https://patch.msgid.link/20250407112352.3720779-7-cezary.rojewski@intel.com Signed-off-by: Mark Brown Stable-dep-of: 347c8d6db7c9 ("ASoC: Intel: avs: Fix PPLCxFMT calculation") Signed-off-by: Sasha Levin commit 2c9fc713d81d6880115ac23ee283e13afa467962 Author: Cezary Rojewski Date: Mon Apr 7 13:23:43 2025 +0200 ALSA: hda: Allow to fetch hlink by ID [ Upstream commit 318c9eef63dd30b59dc8d63c7205ae997aa1e524 ] Starting with LNL platform, Intel HDAudio Links carry IDs specifying non-HDAudio transfer type they help facilitate e.g.: 0xC0 for I2S as defined by AZX_REG_ML_LEPTR_ID_INTEL_SSP. The mechanism accounts for LEPTR register as it is Reserved if LCAP.ALT for given Link equals 0. Reviewed-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Acked-by: Liam Girdwood Link: https://patch.msgid.link/20250407112352.3720779-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown Stable-dep-of: 347c8d6db7c9 ("ASoC: Intel: avs: Fix PPLCxFMT calculation") Signed-off-by: Sasha Levin commit 5a38c07660b27304399f92984182f41de94d48c7 Author: Cezary Rojewski Date: Fri May 30 16:10:18 2025 +0200 ASoC: Intel: avs: Fix deadlock when the failing IPC is SET_D0IX [ Upstream commit 9ad1f3cd0d60444c69948854c7e50d2a61b63755 ] The procedure handling IPC timeouts and EXCEPTION_CAUGHT notification shall cancel any D0IX work before proceeding with DSP recovery. If SET_D0IX called from delayed_work is the failing IPC the procedure will deadlock. Conditionally skip cancelling the work to fix that. Fixes: 335c4cbd201d ("ASoC: Intel: avs: D0ix power state support") Reviewed-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20250530141025.2942936-3-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit babfbf80a9a8209ad44273660440994a1477ed15 Author: Cezary Rojewski Date: Fri May 30 16:10:17 2025 +0200 ASoC: codecs: hda: Fix RPM usage count underflow [ Upstream commit ff0045de4ee0288dec683690f66f2f369b7d3466 ] RPM manipulation in hda_codec_probe_complete()'s error path is superfluous and leads to RPM usage count underflow if the build-controls operation fails. hda_codec_probe_complete() is called in: 1) hda_codec_probe() for all non-HDMI codecs 2) in card->late_probe() for HDMI codecs Error path for hda_codec_probe() takes care of bus' RPM already. For 2) if late_probe() fails, ASoC performs card cleanup what triggers hda_codec_remote() - same treatment is in 1). Fixes: b5df2a7dca1c ("ASoC: codecs: Add HD-Audio codec driver") Reviewed-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20250530141025.2942936-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 63665a9bf8349e0baa688f70cd04ac9469413080 Author: Nitin Rawat Date: Mon May 26 21:08:12 2025 +0530 scsi: ufs: qcom: Prevent calling phy_exit() before phy_init() [ Upstream commit 7831003165d37ecb7b33843fcee05cada0359a82 ] Prevent calling phy_exit() before phy_init() to avoid abnormal power count and the following warning during boot up. [5.146763] phy phy-1d80000.phy.0: phy_power_on was called before phy_init Fixes: 7bac65687510 ("scsi: ufs: qcom: Power off the PHY if it was already powered on in ufs_qcom_power_up_sequence()") Signed-off-by: Nitin Rawat Link: https://lore.kernel.org/r/20250526153821.7918-2-quic_nitirawa@quicinc.com Reviewed-by: Konrad Dybcio Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2245ade1fcf2e8c87e6a9245a5817a023f2dce89 Author: Can Guo Date: Thu May 22 10:15:36 2025 +0800 scsi: ufs: qcom: Map devfreq OPP freq to UniPro Core Clock freq [ Upstream commit 8c5bcb3daeef9bc54c9939c36dca9a626126eb59 ] On some platforms, the devfreq OPP freq may be different than the unipro core clock freq. Implement ufs_qcom_opp_freq_to_clk_freq() and use it to find the unipro core clk freq. Fixes: c02fe9e222d1 ("scsi: ufs: qcom: Implement the freq_to_gear_speed() vop") Signed-off-by: Can Guo Co-developed-by: Ziqi Chen Signed-off-by: Ziqi Chen Link: https://lore.kernel.org/r/20250522021537.999107-3-quic_ziqichen@quicinc.com Reported-by: Luca Weiss Closes: https://lore.kernel.org/linux-arm-msm/D9FZ9U3AEXW4.1I12FX3YQ3JPW@fairphone.com/ Tested-by: Luca Weiss Reviewed-by: Bean Huo Tested-by: Loïc Minier Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b5873bc7fce1117e1661146502f6d3671d5af8a8 Author: Ziqi Chen Date: Thu May 22 10:15:35 2025 +0800 scsi: ufs: qcom: Check gear against max gear in vop freq_to_gear() [ Upstream commit 663d0c19f3acc0d697f623d34b8eb3b438bf2bda ] The vop freq_to_gear() may return a gear greater than the negotiated max gear. Return the negotiated max gear if the mapped gear is greater. Fixes: c02fe9e222d1 ("scsi: ufs: qcom: Implement the freq_to_gear_speed() vop") Signed-off-by: Ziqi Chen Link: https://lore.kernel.org/r/20250522021537.999107-2-quic_ziqichen@quicinc.com Reported-by: Neil Armstrong Closes: https://lore.kernel.org/all/c7f2476a-943a-4d73-ad80-802c91e5f880@linaro.org/ Tested-by: Neil Armstrong Reviewed-by: Bean Huo Tested-by: Loïc Minier Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4b0b4df9e8a18d594f51a4ff87f57e77b850a594 Author: Nylon Chen Date: Fri Apr 11 15:38:50 2025 +0800 riscv: misaligned: fix sleeping function called during misaligned access handling [ Upstream commit 61a74ad254628ccd9e88838c3c622885dfb6c588 ] Use copy_from_user_nofault() and copy_to_user_nofault() instead of copy_from/to_user functions in the misaligned access trap handlers. The following bug report was found when executing misaligned memory accesses: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:162 in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 115, name: two preempt_count: 0, expected: 0 CPU: 0 UID: 0 PID: 115 Comm: two Not tainted 6.14.0-rc5 #24 Hardware name: riscv-virtio,qemu (DT) Call Trace: [] dump_backtrace+0x1c/0x24 [] show_stack+0x28/0x34 [] dump_stack_lvl+0x4a/0x68 [] dump_stack+0x14/0x1c [] __might_resched+0xfa/0x104 [] __might_sleep+0x3e/0x62 [] __might_fault+0x1c/0x24 [] _copy_from_user+0x28/0xaa [] handle_misaligned_store+0x204/0x254 [] do_trap_store_misaligned+0x24/0xee [] handle_exception+0x146/0x152 Fixes: b686ecdeacf6 ("riscv: misaligned: Restrict user access to kernel memory") Fixes: 441381506ba7 ("riscv: misaligned: remove CONFIG_RISCV_M_MODE specific code") Signed-off-by: Zong Li Signed-off-by: Nylon Chen Link: https://lore.kernel.org/r/20250411073850.3699180-3-nylon.chen@sifive.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit a2fd22f51aad28c8dd1aee0d9ad6871f85131b29 Author: Daniele Ceraolo Spurio Date: Thu May 22 15:54:04 2025 -0700 drm/xe/pxp: Clarify PXP queue creation behavior if PXP is not ready [ Upstream commit 69a58ef4fa77759b0e0c2f79834fa51b00a50c0b ] The expected flow of operations when using PXP is to query the PXP status and wait for it to transition to "ready" before attempting to create an exec_queue. This flow is followed by the Mesa driver, but there is no guarantee that an incorrectly coded (or malicious) app will not attempt to create the queue first without querying the status. Therefore, we need to clarify what the expected behavior of the queue creation ioctl is in this scenario. Currently, the ioctl always fails with an -EBUSY code no matter the error, but for consistency it is better to distinguish between "failed to init" (-EIO) and "not ready" (-EBUSY), the same way the query ioctl does. Note that, while this is a change in the return code of an ioctl, the behavior of the ioctl in this particular corner case was not clearly spec'd, so no one should have been relying on it (and we know that Mesa, which is the only known userspace for this, didn't). v2: Minor rework of the doc (Rodrigo) Fixes: 72d479601d67 ("drm/xe/pxp/uapi: Add userspace and LRC support for PXP-using queues") Signed-off-by: Daniele Ceraolo Spurio Cc: John Harrison Cc: José Roberto de Souza Reviewed-by: José Roberto de Souza Reviewed-by: John Harrison Acked-by: Rodrigo Vivi Link: https://lore.kernel.org/r/20250522225401.3953243-7-daniele.ceraolospurio@intel.com (cherry picked from commit 21784ca96025b62d95b670b7639ad70ddafa69b8) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 235e422d19022c8b8fb5ad7e3fbb7eb1657b1c54 Author: Daniele Ceraolo Spurio Date: Thu May 22 15:54:03 2025 -0700 drm/xe/pxp: Use the correct define in the set_property_funcs array [ Upstream commit 6bf4d5649230ca65725ec4793333fb5eba18d646 ] The define of the extension type was accidentally used instead of the one of the property itself. They're both zero, so no functional issue, but we should use the correct define for code correctness. Fixes: 41a97c4a1294 ("drm/xe/pxp/uapi: Add API to mark a BO as using PXP") Signed-off-by: Daniele Ceraolo Spurio Cc: John Harrison Reviewed-by: John Harrison Link: https://lore.kernel.org/r/20250522225401.3953243-6-daniele.ceraolospurio@intel.com (cherry picked from commit 1d891ee820fd0fbb4101eacb0d922b5050a24933) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 484231215fa88a10b45195069583e4b7b57fb3c3 Author: Thomas Hellström Date: Wed May 28 18:41:05 2025 +0200 drm/xe: Rework eviction rejection of bound external bos [ Upstream commit 5cc3325584c425069c1c3355c775314d64bf8770 ] For preempt_fence mode VM's we're rejecting eviction of shared bos during VM_BIND. However, since we do this in the move() callback, we're getting an eviction failure warning from TTM. The TTM callback intended for these things is eviction_valuable(). However, the latter doesn't pass in the struct ttm_operation_ctx needed to determine whether the caller needs this. Instead, attach the needed information to the vm under the vm->resv, until we've been able to update TTM to provide the needed information. And add sufficient lockdep checks to prevent misuse and races. v2: - Fix a copy-paste error in xe_vm_clear_validating() v3: - Fix kerneldoc errors. Signed-off-by: Thomas Hellström Fixes: 0af944f0e308 ("drm/xe: Reject BO eviction if BO is bound to current VM") Reviewed-by: Matthew Brost Link: https://lore.kernel.org/r/20250528164105.234718-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 9d5558649f68e2e84a87a909631b30e15ca0f8ec) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit e8951661ae9359c3b4a582cbe787f37506ed92cc Author: Arnd Bergmann Date: Thu May 29 10:23:56 2025 -0700 drm/xe/vsec: fix CONFIG_INTEL_VSEC dependency [ Upstream commit 2182f358fb138f81a586ffdddd510f2a4fc61702 ] The XE driver can be built with or without VSEC support, but fails to link as built-in if vsec is in a loadable module: x86_64-linux-ld: vmlinux.o: in function `xe_vsec_init': (.text+0x1e83e16): undefined reference to `intel_vsec_register' The normal fix for this is to add a 'depends on INTEL_VSEC || !INTEL_VSEC', forcing XE to be a loadable module as well, but that causes a circular dependency: symbol DRM_XE depends on INTEL_VSEC symbol INTEL_VSEC depends on X86_PLATFORM_DEVICES symbol X86_PLATFORM_DEVICES is selected by DRM_XE The problem here is selecting a symbol from another subsystem, so change that as well and rephrase the 'select' into the corresponding dependency. Since X86_PLATFORM_DEVICES is 'default y', there is no change to defconfig builds here. Fixes: 0c45e76fcc62 ("drm/xe/vsec: Support BMG devices") Signed-off-by: Arnd Bergmann Reviewed-by: Lucas De Marchi Link: https://lore.kernel.org/r/20250529172355.2395634-2-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi (cherry picked from commit e4931f8be347ec5f19df4d6d33aea37145378c42) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit f5e6a6a8aa46d44ec7a240766cf3b7dd077718b9 Author: Matthew Auld Date: Wed May 14 16:24:26 2025 +0100 drm/xe/vm: move xe_svm_init() earlier [ Upstream commit 8cf8cde41ad01150afbd1327ad1942387787f7fd ] In xe_vm_close_and_put() we need to be able to call xe_svm_fini(), however during vm creation we can call this on the error path, before having actually initialised the svm state, leading to various splats followed by a fatal NPD. Fixes: 6fd979c2f331 ("drm/xe: Add SVM init / close / fini to faulting VMs") Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4967 Signed-off-by: Matthew Auld Cc: Matthew Brost Reviewed-by: Matthew Brost Link: https://lore.kernel.org/r/20250514152424.149591-4-matthew.auld@intel.com (cherry picked from commit 4f296d77cf49fcb5f90b4674123ad7f3a0676165) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit cd4cd09810211fa23609c5c1018352e9e1cd8e5a Author: Ido Schimmel Date: Wed Jun 4 14:32:52 2025 +0300 seg6: Fix validation of nexthop addresses [ Upstream commit 7632fedb266d93ed0ed9f487133e6c6314a9b2d1 ] The kernel currently validates that the length of the provided nexthop address does not exceed the specified length. This can lead to the kernel reading uninitialized memory if user space provided a shorter length than the specified one. Fix by validating that the provided length exactly matches the specified one. Fixes: d1df6fd8a1d2 ("ipv6: sr: define core operations for seg6local lightweight tunnel") Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20250604113252.371528-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8a29ae8428a5c26f0b4471c2057d9e9415c53109 Author: Eric Dumazet Date: Wed Jun 4 10:58:15 2025 +0000 net: prevent a NULL deref in rtnl_create_link() [ Upstream commit feafc73f3e6ae73371777a037d41d2e31c929636 ] At the time rtnl_create_link() is running, dev->netdev_ops is NULL, we must not use netdev_lock_ops() or risk a NULL deref if CONFIG_NET_SHAPER is defined. Use netif_set_group() instead of dev_set_group(). RIP: 0010:netdev_need_ops_lock include/net/netdev_lock.h:33 [inline] RIP: 0010:netdev_lock_ops include/net/netdev_lock.h:41 [inline] RIP: 0010:dev_set_group+0xc0/0x230 net/core/dev_api.c:82 Call Trace: rtnl_create_link+0x748/0xd10 net/core/rtnetlink.c:3674 rtnl_newlink_create+0x25c/0xb00 net/core/rtnetlink.c:3813 __rtnl_newlink net/core/rtnetlink.c:3940 [inline] rtnl_newlink+0x16d6/0x1c70 net/core/rtnetlink.c:4055 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6944 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x75b/0x8d0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] Reported-by: syzbot+9fc858ba0312b42b577e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6840265f.a00a0220.d4325.0009.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Fixes: 7e4d784f5810 ("net: hold netdev instance lock during rtnetlink operations") Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20250604105815.1516973-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7acb2f063fc5ef0767b2594fd48d039e6792872b Author: Eric Dumazet Date: Wed Jun 4 09:39:28 2025 +0000 net: annotate data-races around cleanup_net_task [ Upstream commit 535caaca921c653b1f9838fbd5c4e9494cafc3d9 ] from_cleanup_net() reads cleanup_net_task locklessly. Add READ_ONCE()/WRITE_ONCE() annotations to avoid a potential KCSAN warning, even if the race is harmless. Fixes: 0734d7c3d93c ("net: expedite synchronize_net() for cleanup_net()") Signed-off-by: Eric Dumazet Reviewed-by: Jason Xing Link: https://patch.msgid.link/20250604093928.1323333-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b20f409d29dd4dca8d1fb1cddc4106ddbab334c5 Author: Jakub Kicinski Date: Tue Jun 3 18:20:55 2025 -0700 selftests: drv-net: tso: make bkg() wait for socat to quit [ Upstream commit e6854be4d80ea266a7be64a65a0322bcdfa72807 ] Commit 846742f7e32f ("selftests: drv-net: add a warning for bkg + shell + terminate") added a warning for bkg() used with terminate=True. The tso test was missed as we didn't have it running anywhere in NIPA. Add exit_wait=True, to avoid: # Warning: combining shell and terminate is risky! # SIGTERM may not reach the child on zsh/ksh! getting printed twice for every variant. Fixes: 0d0f4174f6c8 ("selftests: drv-net: add a simple TSO test") Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20250604012055.891431-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 26284a9043904d75e7d64315715c6a37c868db75 Author: Jakub Kicinski Date: Tue Jun 3 18:20:31 2025 -0700 selftests: drv-net: tso: fix the GRE device name [ Upstream commit c68804c934e3197e34560744854c57cf88dff8e7 ] The device type for IPv4 GRE is "gre" not "ipgre", unlike for IPv6 which uses "ip6gre". Not sure how I missed this when writing the test, perhaps because all HW I have access to is on an IPv6-only network. Fixes: 0d0f4174f6c8 ("selftests: drv-net: add a simple TSO test") Reviewed-by: Simon Horman Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20250604012031.891242-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit aba544ff9ec522e120b1b3d8b32efa4e6d16d4d7 Author: Mirco Barone Date: Thu Jun 5 14:06:16 2025 +0200 wireguard: device: enable threaded NAPI [ Upstream commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e ] Enable threaded NAPI by default for WireGuard devices in response to low performance behavior that we observed when multiple tunnels (and thus multiple wg devices) are deployed on a single host. This affects any kind of multi-tunnel deployment, regardless of whether the tunnels share the same endpoints or not (i.e., a VPN concentrator type of gateway would also be affected). The problem is caused by the fact that, in case of a traffic surge that involves multiple tunnels at the same time, the polling of the NAPI instance of all these wg devices tends to converge onto the same core, causing underutilization of the CPU and bottlenecking performance. This happens because NAPI polling is hosted by default in softirq context, but the WireGuard driver only raises this softirq after the rx peer queue has been drained, which doesn't happen during high traffic. In this case, the softirq already active on a core is reused instead of raising a new one. As a result, once two or more tunnel softirqs have been scheduled on the same core, they remain pinned there until the surge ends. In our experiments, this almost always leads to all tunnel NAPIs being handled on a single core shortly after a surge begins, limiting scalability to less than 3× the performance of a single tunnel, despite plenty of unused CPU cores being available. The proposed mitigation is to enable threaded NAPI for all WireGuard devices. This moves the NAPI polling context to a dedicated per-device kernel thread, allowing the scheduler to balance the load across all available cores. On our 32-core gateways, enabling threaded NAPI yields a ~4× performance improvement with 16 tunnels, increasing throughput from ~13 Gbps to ~48 Gbps. Meanwhile, CPU usage on the receiver (which is the bottleneck) jumps from 20% to 100%. We have found no performance regressions in any scenario we tested. Single-tunnel throughput remains unchanged. More details are available in our Netdev paper. Link: https://netdevconf.info/0x18/docs/netdev-0x18-paper23-talk-paper.pdf Signed-off-by: Mirco Barone Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Signed-off-by: Jason A. Donenfeld Link: https://patch.msgid.link/20250605120616.2808744-1-Jason@zx2c4.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ac08fcacd29bee33ed9ad1da15f5828bc3c7477c Author: Jakub Kicinski Date: Tue Jun 3 06:53:57 2025 -0700 netlink: specs: rt-link: decode ip6gre [ Upstream commit 8af7a919c52f02514a145f995cbdf0deadb8075a ] Driver tests now require GRE tunnels, while we don't configure them with YNL, YNL will complain when it sees link types it doesn't recognize. Teach it decoding ip6gre tunnels. The attrs are largely the same as IPv4 GRE. Correct the type of encap-limit, but note that this attr is only used in ip6gre, so the mistake didn't matter until now. Fixes: 0d0f4174f6c8 ("selftests: drv-net: add a simple TSO test") Signed-off-by: Jakub Kicinski Reviewed-by: Donald Hunter Link: https://patch.msgid.link/20250603135357.502626-3-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3c8745e7bd9da77749e37eea9577f51c017dd8ad Author: Jakub Kicinski Date: Tue Jun 3 06:53:56 2025 -0700 netlink: specs: rt-link: add missing byte-order properties [ Upstream commit de92258e3b22bd4ce920715cc91f09d788e5badf ] A number of fields in the ip tunnels are lacking the big-endian designation. I suspect this is not intentional, as decoding the ports with the right endian seems objectively beneficial. Fixes: 6ffdbb93a59c ("netlink: specs: rt_link: decode ip6tnl, vti and vti6 link attrs") Fixes: 077b6022d24b ("doc/netlink/specs: Add sub-message type to rt_link family") Signed-off-by: Jakub Kicinski Reviewed-by: Donald Hunter Link: https://patch.msgid.link/20250603135357.502626-2-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bee6f128b741baa1b6d3bae07ec53e92fbf034bc Author: Daniele Palmas Date: Tue Jun 3 11:12:04 2025 +0200 net: wwan: mhi_wwan_mbim: use correct mux_id for multiplexing [ Upstream commit 501fe52aa908c96f2c9b8d54767938a1a5960354 ] Recent Qualcomm chipsets like SDX72/75 require MBIM sessionId mapping to muxId in the range (0x70-0x8F) for the PCIe tethered use. This has been partially addressed by the referenced commit, mapping the default data call to muxId = 112, but the multiplexed data calls scenario was not properly considered, mapping sessionId = 1 to muxId 1, while it should have been 113. Fix this by moving the session_id assignment logic to mhi_mbim_newlink, in order to map sessionId = n to muxId = n + WDS_BIND_MUX_DATA_PORT_MUX_ID. Fixes: 65bc58c3dcad ("net: wwan: mhi: make default data link id configurable") Signed-off-by: Daniele Palmas Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20250603091204.2802840-1-dnlplm@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8e15454d58e7ff87da65f45c6f0a584e61eaff17 Author: Lachlan Hodges Date: Tue Jun 3 15:35:38 2025 +1000 wifi: cfg80211/mac80211: correctly parse S1G beacon optional elements [ Upstream commit 1e1f706fc2ce90eaaf3480b3d5f27885960d751c ] S1G beacons are not traditional beacons but a type of extension frame. Extension frames contain the frame control and duration fields, followed by zero or more optional fields before the frame body. These optional fields are distinct from the variable length elements. The presence of optional fields is indicated in the frame control field. To correctly locate the elements offset, the frame control must be parsed to identify which optional fields are present. Currently, mac80211 parses S1G beacons based on fixed assumptions about the frame layout, without inspecting the frame control field. This can result in incorrect offsets to the "variable" portion of the frame. Properly parse S1G beacon frames by using the field lengths defined in IEEE 802.11-2024, section 9.3.4.3, ensuring that the elements offset is calculated accurately. Fixes: 9eaffe5078ca ("cfg80211: convert S1G beacon to scan results") Fixes: cd418ba63f0c ("mac80211: convert S1G beacon to scan results") Signed-off-by: Lachlan Hodges Link: https://patch.msgid.link/20250603053538.468562-1-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 290a9bcfb434b108aad6786fe9105bbe2263c870 Author: Jonas Gorski Date: Mon Jun 2 21:39:53 2025 +0200 net: dsa: b53: do not touch DLL_IQQD on bcm53115 [ Upstream commit bc1a65eb81a21e2aa3c3dca058ee8adf687b6ef5 ] According to OpenMDK, bit 2 of the RGMII register has a different meaning for BCM53115 [1]: "DLL_IQQD 1: In the IDDQ mode, power is down0: Normal function mode" Configuring RGMII delay works without setting this bit, so let's keep it at the default. For other chips, we always set it, so not clearing it is not an issue. One would assume BCM53118 works the same, but OpenMDK is not quite sure what this bit actually means [2]: "BYPASS_IMP_2NS_DEL #1: In the IDDQ mode, power is down#0: Normal function mode1: Bypass dll65_2ns_del IP0: Use dll65_2ns_del IP" So lets keep setting it for now. [1] https://github.com/Broadcom-Network-Switching-Software/OpenMDK/blob/master/cdk/PKG/chip/bcm53115/bcm53115_a0_defs.h#L19871 [2] https://github.com/Broadcom-Network-Switching-Software/OpenMDK/blob/master/cdk/PKG/chip/bcm53118/bcm53118_a0_defs.h#L14392 Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch") Signed-off-by: Jonas Gorski Link: https://patch.msgid.link/20250602193953.1010487-6-jonas.gorski@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d4280f0853d93e1dc095a16071d17e29e23805eb Author: Jonas Gorski Date: Mon Jun 2 21:39:52 2025 +0200 net: dsa: b53: allow RGMII for bcm63xx RGMII ports [ Upstream commit 5ea0d42c1980e6d10e5cb56a78021db5bfcebaaf ] Add RGMII to supported interfaces for BCM63xx RGMII ports so they can be actually used in RGMII mode. Without this, phylink will fail to configure them: [ 3.580000] b53-switch 10700000.switch GbE3 (uninitialized): validation of rgmii with support 0000000,00000000,00000000,000062ff and advertisement 0000000,00000000,00000000,000062ff failed: -EINVAL [ 3.600000] b53-switch 10700000.switch GbE3 (uninitialized): failed to connect to PHY: -EINVAL [ 3.610000] b53-switch 10700000.switch GbE3 (uninitialized): error -22 setting up PHY for tree 0, switch 0, port 4 Fixes: ce3bf94871f7 ("net: dsa: b53: add support for BCM63xx RGMIIs") Reviewed-by: Florian Fainelli Signed-off-by: Jonas Gorski Link: https://patch.msgid.link/20250602193953.1010487-5-jonas.gorski@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 87ae93e421fd488bcc2b7dde395c1ddaaeb48985 Author: Jonas Gorski Date: Mon Jun 2 21:39:51 2025 +0200 net: dsa: b53: do not configure bcm63xx's IMP port interface [ Upstream commit 75f4f7b2b13008803f84768ff90396f9d7553221 ] The IMP port is not a valid RGMII interface, but hard wired to internal, so we shouldn't touch the undefined register B53_RGMII_CTRL_IMP. While this does not seem to have any side effects, let's not touch it at all, so limit RGMII configuration on bcm63xx to the actual RGMII ports. Fixes: ce3bf94871f7 ("net: dsa: b53: add support for BCM63xx RGMIIs") Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250602193953.1010487-4-jonas.gorski@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bda4c94206cdd8cc327d499e857362bcbb86c0ce Author: Jonas Gorski Date: Sat May 10 11:22:11 2025 +0200 net: dsa: b53: implement setting ageing time [ Upstream commit e39d14a760c039af0653e3df967e7525413924a0 ] b53 supported switches support configuring ageing time between 1 and 1,048,575 seconds, so add an appropriate setter. This allows b53 to pass the FDB learning test for both vlan aware and vlan unaware bridges. Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250510092211.276541-1-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 75f4f7b2b130 ("net: dsa: b53: do not configure bcm63xx's IMP port interface") Signed-off-by: Sasha Levin commit 2953f17ad12c4ae1f7cf50948c3e3aaf386276c3 Author: Jonas Gorski Date: Mon Jun 2 21:39:50 2025 +0200 net: dsa: b53: do not enable RGMII delay on bcm63xx [ Upstream commit 4af523551d876ab8b8057d1e5303a860fd736fcb ] bcm63xx's RGMII ports are always in MAC mode, never in PHY mode, so we shouldn't enable any delays and let the PHY handle any delays as necessary. This fixes using RGMII ports with normal PHYs like BCM54612E, which will handle the delay in the PHY. Fixes: ce3bf94871f7 ("net: dsa: b53: add support for BCM63xx RGMIIs") Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250602193953.1010487-3-jonas.gorski@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2dbccf1eb8c04b84ee3afdb1d6b787db02e7befc Author: Jonas Gorski Date: Mon Jun 2 21:39:49 2025 +0200 net: dsa: b53: do not enable EEE on bcm63xx [ Upstream commit 1237c2d4a8db79dfd4369bff6930b0e385ed7d5c ] BCM63xx internal switches do not support EEE, but provide multiple RGMII ports where external PHYs may be connected. If one of these PHYs are EEE capable, we may try to enable EEE for the MACs, which then hangs the system on access of the (non-existent) EEE registers. Fix this by checking if the switch actually supports EEE before attempting to configure it. Fixes: 22256b0afb12 ("net: dsa: b53: Move EEE functions to b53") Reviewed-by: Florian Fainelli Tested-by: Álvaro Fernández Rojas Signed-off-by: Jonas Gorski Link: https://patch.msgid.link/20250602193953.1010487-2-jonas.gorski@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e75920b2374a58ca888750ce83b2c55b12538d27 Author: Meghana Malladi Date: Tue Jun 3 10:59:04 2025 +0530 net: ti: icssg-prueth: Fix swapped TX stats for MII interfaces. [ Upstream commit 919d763d609428c2680ec8159257d9655f002f89 ] In MII mode, Tx lines are swapped for port0 and port1, which means Tx port0 receives data from PRU1 and the Tx port1 receives data from PRU0. This is an expected hardware behavior and reading the Tx stats needs to be handled accordingly in the driver. Update the driver to read Tx stats from the PRU1 for port0 and PRU0 for port1. Fixes: c1e10d5dc7a1 ("net: ti: icssg-prueth: Add ICSSG Stats") Signed-off-by: Meghana Malladi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250603052904.431203-1-m-malladi@ti.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 33d06d3a741fed698742b9f333ea323e9a8a89d8 Author: Florian Westphal Date: Fri May 30 12:34:02 2025 +0200 netfilter: nf_nat: also check reverse tuple to obtain clashing entry [ Upstream commit 50d9ce9679dd50df2dc51ada717fa875bc248fad ] The logic added in the blamed commit was supposed to only omit nat source port allocation if neither the existing nor the new entry are subject to NAT. However, its not enough to lookup the conntrack based on the proposed tuple, we must also check the reverse direction. Otherwise there are esoteric cases where the collision is in the reverse direction because that colliding connection has a port rewrite, but the new entry doesn't. In this case, we only check the new entry and then erronously conclude that no clash exists anymore. The existing (udp) tuple is: a:p -> b:P, with nat translation to s:P, i.e. pure daddr rewrite, reverse tuple in conntrack table is s:P -> a:p. When another UDP packet is sent directly to s, i.e. a:p->s:P, this is correctly detected as a colliding entry: tuple is taken by existing reply tuple in reverse direction. But the colliding conntrack is only searched for with unreversed direction, and we can't find such entry matching a:p->s:P. The incorrect conclusion is that the clashing entry has timed out and that no port address translation is required. Such conntrack will then be discarded at nf_confirm time because the proposed reverse direction clashes with an existing mapping in the conntrack table. Search for the reverse tuple too, this will then check the NAT bits of the colliding entry and triggers port reallocation. Followp patch extends nft_nat.sh selftest to cover this scenario. The IPS_SEQ_ADJUST change is also a bug fix: Instead of checking for SEQ_ADJ this tested for SEEN_REPLY and ASSURED by accident -- _BIT is only for use with the test_bit() API. This bug has little consequence in practice, because the sequence number adjustments are only useful for TCP which doesn't support clash resolution. The existing test case (conntrack_reverse_clash.sh) exercise a race condition path (parallel conntrack creation on different CPUs), so the colliding entries have neither SEEN_REPLY nor ASSURED set. Thanks to Yafang Shao and Shaun Brady for an initial investigation of this bug. Fixes: d8f84a9bc7c4 ("netfilter: nf_nat: don't try nat source port reallocation for reverse dir clash") Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1795 Reported-by: Yafang Shao Reported-by: Shaun Brady Signed-off-by: Florian Westphal Tested-by: Yafang Shao Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 8068e1e42b46518ce680dc6470bcd710efc3fa0a Author: Florian Westphal Date: Fri May 23 14:20:44 2025 +0200 netfilter: nf_set_pipapo_avx2: fix initial map fill [ Upstream commit ea77c397bff8b6d59f6d83dae1425b08f465e8b5 ] If the first field doesn't cover the entire start map, then we must zero out the remainder, else we leak those bits into the next match round map. The early fix was incomplete and did only fix up the generic C implementation. A followup patch adds a test case to nft_concat_range.sh. Fixes: 791a615b7ad2 ("netfilter: nf_set_pipapo: fix initial map fill") Signed-off-by: Florian Westphal Reviewed-by: Stefano Brivio Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit ab1e799b1b42f530db6266d08a27cbc90eafc45e Author: Michael Walle Date: Tue May 20 09:41:10 2025 +0200 drm/panel-simple: fix the warnings for the Evervision VGG644804 [ Upstream commit 5dc1ea903588a73fb03b3a3e5a041a7c63a4bccd ] The panel lacked the connector type which causes a warning. Adding the connector type reveals wrong bus_flags and bits per pixel. Fix all of it. Fixes: 1319f2178bdf ("drm/panel-simple: add Evervision VGG644804 panel entry") Signed-off-by: Michael Walle Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250520074110.655114-1-mwalle@kernel.org Signed-off-by: Sasha Levin commit a26ec8e16958b6dd37dac9daf5fb6978fe0cb0b8 Author: Miri Korenblit Date: Wed Jun 4 06:13:19 2025 +0300 wifi: iwlwifi: mld: avoid panic on init failure [ Upstream commit 960c7e6d388034d219dafffa6da0a5c2ccd5ff30 ] In case of an error during init, in_hw_restart will be set, but it will never get cleared. Instead, we will retry to init again, and then we will act like we are in a restart when we are actually not. This causes (among others) to a NULL pointer dereference when canceling rx_omi::finished_work, that was not even initialized, because we thought that we are in hw_restart. Set in_hw_restart to true only if the fw is running, then we know that FW was loaded successfully and we are not going to the retry loop. Fixes: 7391b2a4f7db ("wifi: iwlwifi: rework firmware error handling") Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250604061200.e0040e0a4b09.Iae469a0abe6bfa3c26d8a88c066bad75c2e8f121@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 604981bbaba174d3922a2f80b31026fc15df7f51 Author: Dibin Moolakadan Subrahmanian Date: Wed May 28 12:15:56 2025 +0530 drm/i915/display: Fix u32 overflow in SNPS PHY HDMI PLL setup [ Upstream commit 791d76005de0ab556b590473eb4cbfede727fce0 ] When configuring the HDMI PLL, calculations use DIV_ROUND_UP_ULL and DIV_ROUND_DOWN_ULL macros, which internally rely on do_div. However, do_div expects a 32-bit (u32) divisor, and at higher data rates, the divisor can exceed this limit. This leads to incorrect division results and ultimately misconfigured PLL values. This fix replaces do_div calls with div64_base64 calls where diviser can exceed u32 limit. Fixes: 5947642004bf ("drm/i915/display: Add support for SNPS PHY HDMI PLL algorithm for DG2") Cc: Ankit Nautiyal Cc: Suraj Kandpal Cc: Jani Nikula Signed-off-by: Dibin Moolakadan Subrahmanian Reviewed-by: Ankit Nautiyal Signed-off-by: Ankit Nautiyal Link: https://lore.kernel.org/r/20250528064557.4172149-1-dibin.moolakadan.subrahmanian@intel.com (cherry picked from commit ce924116e43ffbfa544d82976c4b9d11bcde9334) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit c741a7ef68023ac800054e2131c3e22e647fd7e3 Author: Alok Tiwari Date: Mon Jun 2 03:34:29 2025 -0700 gve: add missing NULL check for gve_alloc_pending_packet() in TX DQO [ Upstream commit 12c331b29c7397ac3b03584e12902990693bc248 ] gve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo() did not check for this case before dereferencing the returned pointer. Add a missing NULL check to prevent a potential NULL pointer dereference when allocation fails. This improves robustness in low-memory scenarios. Fixes: a57e5de476be ("gve: DQO: Add TX path") Signed-off-by: Alok Tiwari Reviewed-by: Mina Almasry Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c3dec8c01341e8013da2db66176cd72c9e90190e Author: Pavel Begunkov Date: Tue May 20 16:14:49 2025 +0100 nvme: fix implicit bool to flags conversion [ Upstream commit c4b680ac2863821e19d360fca62f78b68b1c8ece ] nvme_map_user_request() takes flags as the last argument, but nvme_uring_cmd_io() shoves a bool "vec" into it. It behaves as expected because bool is converted to 0/1 and NVME_IOCTL_VEC is defined as 1, but it's better to pass flags explicitly. Fixes: 7b7fdb8e2dbc1 ("nvme: replace the "bool vec" arguments with flags in the ioctl path") Signed-off-by: Pavel Begunkov Reviewed-by: Jens Axboe Reviewed-by: Keith Busch Reviewed-by: Anuj Gupta Reviewed-by: Kanchan Joshi Reviewed-by: Chaitanya Kulkarni Reviewed-by: Caleb Sander Mateos Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 75141d56b6268fd5c801c0035a1d4adfd24cfe69 Author: Keith Busch Date: Tue May 20 13:20:37 2025 -0700 nvme: fix command limits status code [ Upstream commit 10f4a7cd724e34b7a6ff96e57ac49dc0cadececc ] The command specific status code, 0x183, was introduced in the NVMe 2.0 specification defined to "Command Size Limits Exceeded" and only ever applied to DSM and Copy commands. Fix the name and, remove the incorrect translation to error codes and special treatment in the target code for it. Fixes: 3b7c33b28a44d4 ("nvme.h: add Write Zeroes definitions") Cc: Chaitanya Kulkarni Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 0400f95a5e1b99197bb3dcd18527184325751d0e Author: Caleb Sander Mateos Date: Tue Jun 3 12:47:51 2025 -0600 block: flip iter directions in blk_rq_integrity_map_user() [ Upstream commit 43a67dd812c5d3de163c0b6971046b4a4b633d3f ] blk_rq_integrity_map_user() creates the ubuf iter with ITER_DEST for write-direction operations and ITER_SOURCE for read-direction ones. This is backwards; writes use the user buffer as a source for metadata and reads use it as a destination. Switch to the rq_data_dir() helper, which maps writes to ITER_SOURCE (WRITE) and reads to ITER_DEST(READ). Signed-off-by: Caleb Sander Mateos Fixes: fe8f4ca7107e ("block: modify bio_integrity_map_user to accept iov_iter as argument") Link: https://lore.kernel.org/r/20250603184752.1185676-1-csander@purestorage.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c7d216830d49952fc849bd5363ae1b029c3a1e0e Author: Rafael J. Wysocki Date: Tue Jun 3 18:19:27 2025 +0200 PM: sleep: Fix power.is_suspended cleanup for direct-complete devices [ Upstream commit d46c4c839c20a599a0eb8d73708ce401f9c7d06d ] Commit 03f1444016b7 ("PM: sleep: Fix handling devices with direct_complete set on errors") caused power.is_suspended to be set for devices with power.direct_complete set, but it forgot to ensure the clearing of that flag for them in device_resume(), so power.is_suspended is still set for them during the next system suspend-resume cycle. If that cycle is aborted in dpm_suspend(), the subsequent invocation of dpm_resume() will trigger a device_resume() call for every device and because power.is_suspended is set for the devices in question, they will not be skipped by device_resume() as expected which causes scary error messages to be logged (as appropriate). To address this issue, move the clearing of power.is_suspended in device_resume() immediately after the power.is_suspended check so it will be always cleared for all devices processed by that function. Fixes: 03f1444016b7 ("PM: sleep: Fix handling devices with direct_complete set on errors") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4280 Reported-and-tested-by: Chris Bainbridge Signed-off-by: Rafael J. Wysocki Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/4990586.GXAFRqVoOG@rjwysocki.net Signed-off-by: Sasha Levin commit c29a9dc44cbd53156c85dce671b1ac8dabf9eb1b Author: Vitaly Prosyak Date: Tue May 6 16:45:33 2025 -0400 drm/amdgpu/gfx10: Refine Cleaner Shader for GFX10.1.10 [ Upstream commit d26625d034fb8d596f0488472969493fa02d03f3 ] This patch updates the cleaner shader, which is responsible for initializing GPU resources such as Local Data Share (LDS), Vector General Purpose Registers (VGPRs), and Scalar General Purpose Registers (SGPRs). Changes include adjustments to register clearing and shader configuration. - Updated GPU resource initialization addresses in the cleaner shader from `be803080` to `be803000`. - Simplified the logic in the SGPR clearing section, ensuring all SGPRs are set to zero. Fixes: 25961bad9212 ("drm/amdgpu/gfx10: Add cleaner shader for GFX10.1.10") Cc: Christian König Cc: Alex Deucher Signed-off-by: Manu Rastogi Signed-off-by: Vitaly Prosyak Signed-off-by: Srinivasan Shanmugam Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 620ab4d6215de0b25227f9fff1a8c7fb66837cb8 Author: Przemek Kitszel Date: Fri Apr 4 12:23:21 2025 +0200 iavf: get rid of the crit lock [ Upstream commit 120f28a6f314fef7f282c99f196923fe44081cad ] Get rid of the crit lock. That frees us from the error prone logic of try_locks. Thanks to netdev_lock() by Jakub it is now easy, and in most cases we were protected by it already - replace crit lock by netdev lock when it was not the case. Lockdep reports that we should cancel the work under crit_lock [splat1], and that was the scheme we have mostly followed since [1] by Slawomir. But when that is done we still got into deadlocks [splat2]. So instead we should look at the bigger problem, namely "weird locking/scheduling" of the iavf. The first step to fix that is to remove the crit lock. I will followup with a -next series that simplifies scheduling/tasks. Cancel the work without netdev lock (weird unlock+lock scheme), to fix the [splat2] (which would be totally ugly if we would kept the crit lock). Extend protected part of iavf_watchdog_task() to include scheduling more work. Note that the removed comment in iavf_reset_task() was misplaced, it belonged to inside of the removed if condition, so it's gone now. [splat1] - w/o this patch - The deadlock during VF removal: WARNING: possible circular locking dependency detected sh/3825 is trying to acquire lock: ((work_completion)(&(&adapter->watchdog_task)->work)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470 but task is already holding lock: (&adapter->crit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf] which lock already depends on the new lock. [splat2] - when cancelling work under crit lock, w/o this series, see [2] for the band aid attempt WARNING: possible circular locking dependency detected sh/3550 is trying to acquire lock: ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 but task is already holding lock: (&dev->lock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf] which lock already depends on the new lock. [1] fc2e6b3b132a ("iavf: Rework mutexes for better synchronisation") [2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a Fixes: d1639a17319b ("iavf: fix a deadlock caused by rtnl and driver's lock circular dependencies") Signed-off-by: Przemek Kitszel Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 5c9f23bac8b9c057df51659ede6a23f049b385da Author: Przemek Kitszel Date: Fri Apr 4 12:23:20 2025 +0200 iavf: sprinkle netdev_assert_locked() annotations [ Upstream commit 05702b5c949bd46243181833d4726f4c5e95f5e3 ] Lockdep annotations help in general, but here it is extra good, as next commit will remove crit lock. Reviewed-by: Jacob Keller Signed-off-by: Przemek Kitszel Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Stable-dep-of: 120f28a6f314 ("iavf: get rid of the crit lock") Signed-off-by: Sasha Levin commit 47709f87e054fee797ff8c718938fc41b31f0c5c Author: Przemek Kitszel Date: Fri Apr 4 12:23:19 2025 +0200 iavf: extract iavf_watchdog_step() out of iavf_watchdog_task() [ Upstream commit 257a8241ad7f4dc312494f69e3bc79a5598b4514 ] Finish up easy refactor of watchdog_task, total for this + prev two commits is: 1 file changed, 47 insertions(+), 82 deletions(-) Signed-off-by: Przemek Kitszel Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Stable-dep-of: 120f28a6f314 ("iavf: get rid of the crit lock") Signed-off-by: Sasha Levin commit 352a46081e4147222aa472f75c2f7c04406a816e Author: Przemek Kitszel Date: Fri Apr 4 12:23:18 2025 +0200 iavf: simplify watchdog_task in terms of adminq task scheduling [ Upstream commit ecb4cd0461accc446d20a7a167f39ed2fd5e9b0e ] Simplify the decision whether to schedule adminq task. The condition is the same, but it is executed in more scenarios. Note that movement of watchdog_done label makes this commit a bit surprising. (Hence not squashing it to anything bigger). Reviewed-by: Jacob Keller Signed-off-by: Przemek Kitszel Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Stable-dep-of: 120f28a6f314 ("iavf: get rid of the crit lock") Signed-off-by: Sasha Levin commit dae1e290290b01b1476b2f5ba17759a88e2929e5 Author: Przemek Kitszel Date: Fri Apr 4 12:23:17 2025 +0200 iavf: centralize watchdog requeueing itself [ Upstream commit 099418da91b7d3d46ddcccbb03075cc4f1ba2d44 ] Centralize the unlock(critlock); unlock(netdev); queue_delayed_work(watchog_task); pattern to one place. Reviewed-by: Jacob Keller Signed-off-by: Przemek Kitszel Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Stable-dep-of: 120f28a6f314 ("iavf: get rid of the crit lock") Signed-off-by: Sasha Levin commit 89e7dd465fe61cda21f0f5cc0b98d5f1566fe33c Author: Przemek Kitszel Date: Fri Apr 4 12:23:16 2025 +0200 iavf: iavf_suspend(): take RTNL before netdev_lock() [ Upstream commit dba35a4bb4a3da5696f2a179b7d695dc3ea25fb8 ] Fix an obvious violation of lock ordering. Jakub's [1] added netdev_lock() call that is wrong ordered wrt RTNL, but the Fixes tag points to crit_lock being wrongly placed (by lockdep standards). Actual reason we got it wrong is dated back to critical section managed by pure flag checks, which is with us since the very beginning. [1] afc664987ab3 ("eth: iavf: extend the netdev_lock usage") Fixes: 5ac49f3c2702 ("iavf: use mutexes for locking of critical sections") Reviewed-by: Jacob Keller Signed-off-by: Przemek Kitszel Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit f304434e5f7a90efd1130081a77c0b1ff7769db5 Author: Lorenzo Bianconi Date: Mon Jun 2 12:55:37 2025 +0200 net: airoha: Initialize PPE UPDMEM source-mac table [ Upstream commit a869d3a5eb011a9cf9bd864f31f5cf27362de8c7 ] UPDMEM source-mac table is a key-value map used to store devices mac addresses according to the port identifier. UPDMEM source mac table is used during IPv6 traffic hw acceleration since PPE entries, for space constraints, do not contain the full source mac address but just the identifier in the UPDMEM source-mac table. Configure UPDMEM source-mac table with device mac addresses and set the source-mac ID field for PPE IPv6 entries in order to select the proper device mac address as source mac for L3 IPv6 hw accelerated traffic. Fixes: 00a7678310fe ("net: airoha: Introduce flowtable offload support") Signed-off-by: Lorenzo Bianconi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250602-airoha-flowtable-ipv6-fix-v2-1-3287f8b55214@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6c8f62776b5a002daca7ba12dd9ce149351faea9 Author: Lorenzo Bianconi Date: Wed May 21 09:16:39 2025 +0200 net: airoha: Add the capability to allocate hfwd descriptors in SRAM [ Upstream commit c683e378c0907e66cee939145edf936c254ff1e3 ] In order to improve packet processing and packet forwarding performances, EN7581 SoC supports consuming SRAM instead of DRAM for hw forwarding descriptors queue. For downlink hw accelerated traffic request to consume SRAM memory for hw forwarding descriptors queue. Signed-off-by: Lorenzo Bianconi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250521-airopha-desc-sram-v3-4-a6e9b085b4f0@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: a869d3a5eb01 ("net: airoha: Initialize PPE UPDMEM source-mac table") Signed-off-by: Sasha Levin commit 8fd973681f033564173468733856f898235e928a Author: Bui Quang Minh Date: Sun Jun 1 21:29:13 2025 +0700 selftests: net: build net/lib dependency in all target [ Upstream commit d3f2a9587ebe68f5067f9ff624f9a83dfb911f60 ] We have the logic to include net/lib automatically for net related selftests. However, currently, this logic is only in install target which means only `make install` will have net/lib included. This commit adds the logic to all target so that all `make`, `make run_tests` and `make install` will have net/lib included in net related selftests. Signed-off-by: Bui Quang Minh Link: https://patch.msgid.link/20250601142914.13379-1-minhquangbui99@gmail.com Fixes: b86761ff6374 ("selftests: net: add scaffolding for Netlink tests in Python") Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e7c0c7353b477eca8582b9fa2bdd2507834be1fe Author: Ronak Doshi Date: Fri May 30 15:27:00 2025 +0000 vmxnet3: correctly report gso type for UDP tunnels [ Upstream commit 982d30c30eaa2ec723df42e3bf526c014c1dbb88 ] Commit 3d010c8031e3 ("udp: do not accept non-tunnel GSO skbs landing in a tunnel") added checks in linux stack to not accept non-tunnel GRO packets landing in a tunnel. This exposed an issue in vmxnet3 which was not correctly reporting GRO packets for tunnel packets. This patch fixes this issue by setting correct GSO type for the tunnel packets. Currently, vmxnet3 does not support reporting inner fields for LRO tunnel packets. The issue is not seen for egress drivers that do not use skb inner fields. The workaround is to enable tnl-segmentation offload on the egress interfaces if the driver supports it. This problem pre-exists this patch fix and can be addressed as a separate future patch. Fixes: dacce2be3312 ("vmxnet3: add geneve and vxlan tunnel offload support") Signed-off-by: Ronak Doshi Acked-by: Guolin Yang Link: https://patch.msgid.link/20250530152701.70354-1-ronak.doshi@broadcom.com [pabeni@redhat.com: dropped the changelog] Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 66542e9430c625f878a5b5dc0fe41e3458d614bf Author: Jinjian Song Date: Fri May 30 11:16:48 2025 +0800 net: wwan: t7xx: Fix napi rx poll issue [ Upstream commit 905fe0845bb27e4eed2ca27ea06e6c4847f1b2b1 ] When driver handles the napi rx polling requests, the netdev might have been released by the dellink logic triggered by the disconnect operation on user plane. However, in the logic of processing skb in polling, an invalid netdev is still being used, which causes a panic. BUG: kernel NULL pointer dereference, address: 00000000000000f1 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:dev_gro_receive+0x3a/0x620 [...] Call Trace: ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x4f/0xa0 ? asm_exc_page_fault+0x22/0x30 ? __pfx_t7xx_ccmni_recv_skb+0x10/0x10 [mtk_t7xx (HASH:1400 7)] ? dev_gro_receive+0x3a/0x620 napi_gro_receive+0xad/0x170 t7xx_ccmni_recv_skb+0x48/0x70 [mtk_t7xx (HASH:1400 7)] t7xx_dpmaif_napi_rx_poll+0x590/0x800 [mtk_t7xx (HASH:1400 7)] net_rx_action+0x103/0x470 irq_exit_rcu+0x13a/0x310 sysvec_apic_timer_interrupt+0x56/0x90 Fixes: 5545b7b9f294 ("net: wwan: t7xx: Add NAPI support") Signed-off-by: Jinjian Song Link: https://patch.msgid.link/20250530031648.5592-1-jinjian.song@fibocom.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a04302867094bdc6efac1b598370fc47cf3f2388 Author: Shiming Cheng Date: Fri May 30 09:26:08 2025 +0800 net: fix udp gso skb_segment after pull from frag_list [ Upstream commit 3382a1ed7f778db841063f5d7e317ac55f9e7f72 ] Commit a1e40ac5b5e9 ("net: gso: fix udp gso fraglist segmentation after pull from frag_list") detected invalid geometry in frag_list skbs and redirects them from skb_segment_list to more robust skb_segment. But some packets with modified geometry can also hit bugs in that code. We don't know how many such cases exist. Addressing each one by one also requires touching the complex skb_segment code, which risks introducing bugs for other types of skbs. Instead, linearize all these packets that fail the basic invariants on gso fraglist skbs. That is more robust. If only part of the fraglist payload is pulled into head_skb, it will always cause exception when splitting skbs by skb_segment. For detailed call stack information, see below. Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify fraglist skbs, breaking these invariants. In extreme cases they pull one part of data into skb linear. For UDP, this causes three payloads with lengths of (11,11,10) bytes were pulled tail to become (12,10,10) bytes. The skbs no longer meets the above SKB_GSO_FRAGLIST conditions because payload was pulled into head_skb, it needs to be linearized before pass to regular skb_segment. skb_segment+0xcd0/0xd14 __udp_gso_segment+0x334/0x5f4 udp4_ufo_fragment+0x118/0x15c inet_gso_segment+0x164/0x338 skb_mac_gso_segment+0xc4/0x13c __skb_gso_segment+0xc4/0x124 validate_xmit_skb+0x9c/0x2c0 validate_xmit_skb_list+0x4c/0x80 sch_direct_xmit+0x70/0x404 __dev_queue_xmit+0x64c/0xe5c neigh_resolve_output+0x178/0x1c4 ip_finish_output2+0x37c/0x47c __ip_finish_output+0x194/0x240 ip_finish_output+0x20/0xf4 ip_output+0x100/0x1a0 NF_HOOK+0xc4/0x16c ip_forward+0x314/0x32c ip_rcv+0x90/0x118 __netif_receive_skb+0x74/0x124 process_backlog+0xe8/0x1a4 __napi_poll+0x5c/0x1f8 net_rx_action+0x154/0x314 handle_softirqs+0x154/0x4b8 [118.376811] [C201134] rxq0_pus: [name:bug&]kernel BUG at net/core/skbuff.c:4278! [118.376829] [C201134] rxq0_pus: [name:traps&]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [118.470774] [C201134] rxq0_pus: [name:mrdump&]Kernel Offset: 0x178cc00000 from 0xffffffc008000000 [118.470810] [C201134] rxq0_pus: [name:mrdump&]PHYS_OFFSET: 0x40000000 [118.470827] [C201134] rxq0_pus: [name:mrdump&]pstate: 60400005 (nZCv daif +PAN -UAO) [118.470848] [C201134] rxq0_pus: [name:mrdump&]pc : [0xffffffd79598aefc] skb_segment+0xcd0/0xd14 [118.470900] [C201134] rxq0_pus: [name:mrdump&]lr : [0xffffffd79598a5e8] skb_segment+0x3bc/0xd14 [118.470928] [C201134] rxq0_pus: [name:mrdump&]sp : ffffffc008013770 Fixes: a1e40ac5b5e9 ("gso: fix udp gso fraglist segmentation after pull from frag_list") Signed-off-by: Shiming Cheng Reviewed-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e24c5d08a202b96f46f1baf9b5985b11d1000336 Author: Yongting Lin Date: Tue May 27 23:12:22 2025 +0800 um: Fix tgkill compile error on old host OSes [ Upstream commit fd054188999ff19746cc09f4e0f196a113964db9 ] tgkill is a quite old syscall since kernel 2.5.75, but unfortunately glibc doesn't support it before 2.30. Thus some systems fail to compile the latest UserMode Linux. Here is the compile error I encountered when I tried to compile UML in my system shipped with glibc-2.28. CALL scripts/checksyscalls.sh CC arch/um/os-Linux/sigio.o In file included from arch/um/os-Linux/sigio.c:17: arch/um/os-Linux/sigio.c: In function ‘write_sigio_thread’: arch/um/os-Linux/sigio.c:49:19: error: implicit declaration of function ‘tgkill’; did you mean ‘kill’? [-Werror=implicit-function-declaration] CATCH_EINTR(r = tgkill(pid, pid, SIGIO)); ^~~~~~ ./arch/um/include/shared/os.h:21:48: note: in definition of macro ‘CATCH_EINTR’ #define CATCH_EINTR(expr) while ((errno = 0, ((expr) < 0)) && (errno == EINTR)) ^~~~ cc1: some warnings being treated as errors Fix it by Replacing glibc call with raw syscall. Fixes: 33c9da5dfb18 ("um: Rewrite the sigio workaround based on epoll and tgkill") Signed-off-by: Yongting Lin Link: https://patch.msgid.link/20250527151222.40371-1-linyongting@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 5233b0657fa60e2622eb966d37275e4945c3696b Author: Jesus Narvaez Date: Wed May 28 16:05:51 2025 -0700 drm/i915/guc: Handle race condition where wakeref count drops below 0 [ Upstream commit 0323a5127e7c534cfc88efe0f850a0cb777e938b ] There is a rare race condition when preparing for a reset where guc_lrc_desc_unpin() could be in the process of deregistering a context while a different thread is scrubbing outstanding contexts and it alters the context state and does a wakeref put. Then, if there is a failure with deregister_context(), a second wakeref put could occur. As a result the wakeref count could drop below 0 and fail an INTEL_WAKEREF_BUG_ON() check. Therefore if there is a failure with deregister_context(), undo the context state changes and do a wakeref put only if the context was set to be destroyed earlier. v2: Expand comment to better explain change. (Daniele) v3: Removed addition to the original comment. (Daniele) Fixes: 2f2cc53b5fe7 ("drm/i915/guc: Close deregister-context race against CT-loss") Signed-off-by: Jesus Narvaez Cc: Daniele Ceraolo Spurio Cc: Alan Previn Cc: Anshuman Gupta Cc: Mousumi Jana Cc: Rodrigo Vivi Cc: Matt Roper Reviewed-by: Daniele Ceraolo Spurio Signed-off-by: John Harrison Link: https://lore.kernel.org/r/20250528230551.1855177-1-jesus.narvaez@intel.com (cherry picked from commit f36a75aba1c3176d177964bca76f86a075d2943a) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit 91adc20742dd2a744f57d24c0b84f7abe4bf7b27 Author: Jouni Högander Date: Mon May 26 15:05:11 2025 +0300 drm/i915/psr: Fix using wrong mask in REG_FIELD_PREP [ Upstream commit 57d63c6cd0851d3af612a556ec61b0f2a9bd522f ] Wrong mask is used in PORT_ALPM_LFPS_CTL_FIRST_LFPS_HALF_CYCLE_DURATION and PORT_ALPM_LFPS_CTL_LAST_LFPS_HALF_CYCLE_DURATION. Fixes: 295099580f04 ("drm/i915/psr: Add missing ALPM AUX-Less register definitions") Signed-off-by: Jouni Högander Reviewed-by: Ankit Nautiyal Link: https://lore.kernel.org/r/20250526120512.1702815-12-jouni.hogander@intel.com (cherry picked from commit 8097128a40ff378761034ec72cdbf6f46e466dc0) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit 17b7dbbd0afb25ed082e90d2b09fdf3ca5cd5571 Author: Jesus Narvaez Date: Wed May 14 15:52:24 2025 -0700 drm/i915/guc: Check if expecting reply before decrementing outstanding_submission_g2h [ Upstream commit c557fd1050f6691dde36818dfc1a4c415c42901b ] When sending a H2G message where a reply is expected in guc_submission_send_busy_loop(), outstanding_submission_g2h is incremented before the send. However, if there is an error sending the message, outstanding_submission_g2h is decremented without checking if a reply is expected. Therefore, check if reply is expected when there is a failure before decrementing outstanding_submission_g2h. Fixes: 2f2cc53b5fe7 ("drm/i915/guc: Close deregister-context race against CT-loss") Signed-off-by: Jesus Narvaez Cc: Daniele Ceraolo Spurio Cc: Alan Previn Cc: Anshuman Gupta Cc: Mousumi Jana Cc: Rodrigo Vivi Cc: Matt Roper Reviewed-by: Daniele Ceraolo Spurio Signed-off-by: John Harrison Link: https://lore.kernel.org/r/20250514225224.4142684-1-jesus.narvaez@intel.com (cherry picked from commit a6a26786f22a4ab0227bcf610510c4c9c2df0808) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit a8452696877a3958fe1e43b99889f9d3c9f56b56 Author: Paul Chaignon Date: Thu May 29 12:28:35 2025 +0200 bpf: Fix L4 csum update on IPv6 in CHECKSUM_COMPLETE [ Upstream commit ead7f9b8de65632ef8060b84b0c55049a33cfea1 ] In Cilium, we use bpf_csum_diff + bpf_l4_csum_replace to, among other things, update the L4 checksum after reverse SNATing IPv6 packets. That use case is however not currently supported and leads to invalid skb->csum values in some cases. This patch adds support for IPv6 address changes in bpf_l4_csum_update via a new flag. When calling bpf_l4_csum_replace in Cilium, it ends up calling inet_proto_csum_replace_by_diff: 1: void inet_proto_csum_replace_by_diff(__sum16 *sum, struct sk_buff *skb, 2: __wsum diff, bool pseudohdr) 3: { 4: if (skb->ip_summed != CHECKSUM_PARTIAL) { 5: csum_replace_by_diff(sum, diff); 6: if (skb->ip_summed == CHECKSUM_COMPLETE && pseudohdr) 7: skb->csum = ~csum_sub(diff, skb->csum); 8: } else if (pseudohdr) { 9: *sum = ~csum_fold(csum_add(diff, csum_unfold(*sum))); 10: } 11: } The bug happens when we're in the CHECKSUM_COMPLETE state. We've just updated one of the IPv6 addresses. The helper now updates the L4 header checksum on line 5. Next, it updates skb->csum on line 7. It shouldn't. For an IPv6 packet, the updates of the IPv6 address and of the L4 checksum will cancel each other. The checksums are set such that computing a checksum over the packet including its checksum will result in a sum of 0. So the same is true here when we update the L4 checksum on line 5. We'll update it as to cancel the previous IPv6 address update. Hence skb->csum should remain untouched in this case. The same bug doesn't affect IPv4 packets because, in that case, three fields are updated: the IPv4 address, the IP checksum, and the L4 checksum. The change to the IPv4 address and one of the checksums still cancel each other in skb->csum, but we're left with one checksum update and should therefore update skb->csum accordingly. That's exactly what inet_proto_csum_replace_by_diff does. This special case for IPv6 L4 checksums is also described atop inet_proto_csum_replace16, the function we should be using in this case. This patch introduces a new bpf_l4_csum_replace flag, BPF_F_IPV6, to indicate that we're updating the L4 checksum of an IPv6 packet. When the flag is set, inet_proto_csum_replace_by_diff will skip the skb->csum update. Fixes: 7d672345ed295 ("bpf: add generic bpf_csum_diff helper") Signed-off-by: Paul Chaignon Acked-by: Daniel Borkmann Link: https://patch.msgid.link/96a6bc3a443e6f0b21ff7b7834000e17fb549e05.1748509484.git.paul.chaignon@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3904dfba2913835cf4ac1ba6b5dd44ce89171aa7 Author: Paul Chaignon Date: Tue Apr 8 11:00:51 2025 +0200 bpf: Clarify the meaning of BPF_F_PSEUDO_HDR [ Upstream commit 5a15a050df714959f0d5a57ac3201bd1c6594984 ] In the bpf_l4_csum_replace helper, the BPF_F_PSEUDO_HDR flag should only be set if the modified header field is part of the pseudo-header. If you modify for example the UDP ports and pass BPF_F_PSEUDO_HDR, inet_proto_csum_replace4 will update skb->csum even though it shouldn't (the port and the UDP checksum updates null each other). Signed-off-by: Paul Chaignon Link: https://lore.kernel.org/r/5126ef84ba75425b689482cbc98bffe75e5d8ab0.1744102490.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov Stable-dep-of: ead7f9b8de65 ("bpf: Fix L4 csum update on IPv6 in CHECKSUM_COMPLETE") Signed-off-by: Sasha Levin commit 4649767d62afed95981328c2fea2198b1146e784 Author: Paul Chaignon Date: Thu May 29 12:28:05 2025 +0200 net: Fix checksum update for ILA adj-transport [ Upstream commit 6043b794c7668c19dabc4a93c75b924a19474d59 ] During ILA address translations, the L4 checksums can be handled in different ways. One of them, adj-transport, consist in parsing the transport layer and updating any found checksum. This logic relies on inet_proto_csum_replace_by_diff and produces an incorrect skb->csum when in state CHECKSUM_COMPLETE. This bug can be reproduced with a simple ILA to SIR mapping, assuming packets are received with CHECKSUM_COMPLETE: $ ip a show dev eth0 14: eth0@if15: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 62:ae:35:9e:0f:8d brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet6 3333:0:0:1::c078/64 scope global valid_lft forever preferred_lft forever inet6 fd00:10:244:1::c078/128 scope global nodad valid_lft forever preferred_lft forever inet6 fe80::60ae:35ff:fe9e:f8d/64 scope link proto kernel_ll valid_lft forever preferred_lft forever $ ip ila add loc_match fd00:10:244:1 loc 3333:0:0:1 \ csum-mode adj-transport ident-type luid dev eth0 Then I hit [fd00:10:244:1::c078]:8000 with a server listening only on [3333:0:0:1::c078]:8000. With the bug, the SYN packet is dropped with SKB_DROP_REASON_TCP_CSUM after inet_proto_csum_replace_by_diff changed skb->csum. The translation and drop are visible on pwru [1] traces: IFACE TUPLE FUNC eth0:9 [fd00:10:244:3::3d8]:51420->[fd00:10:244:1::c078]:8000(tcp) ipv6_rcv eth0:9 [fd00:10:244:3::3d8]:51420->[fd00:10:244:1::c078]:8000(tcp) ip6_rcv_core eth0:9 [fd00:10:244:3::3d8]:51420->[fd00:10:244:1::c078]:8000(tcp) nf_hook_slow eth0:9 [fd00:10:244:3::3d8]:51420->[fd00:10:244:1::c078]:8000(tcp) inet_proto_csum_replace_by_diff eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) tcp_v6_early_demux eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) ip6_route_input eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) ip6_input eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) ip6_input_finish eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) ip6_protocol_deliver_rcu eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) raw6_local_deliver eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) ipv6_raw_deliver eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) tcp_v6_rcv eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) __skb_checksum_complete eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) kfree_skb_reason(SKB_DROP_REASON_TCP_CSUM) eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) skb_release_head_state eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) skb_release_data eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) skb_free_head eth0:9 [fd00:10:244:3::3d8]:51420->[3333:0:0:1::c078]:8000(tcp) kfree_skbmem This is happening because inet_proto_csum_replace_by_diff is updating skb->csum when it shouldn't. The L4 checksum is updated such that it "cancels" the IPv6 address change in terms of checksum computation, so the impact on skb->csum is null. Note this would be different for an IPv4 packet since three fields would be updated: the IPv4 address, the IP checksum, and the L4 checksum. Two would cancel each other and skb->csum would still need to be updated to take the L4 checksum change into account. This patch fixes it by passing an ipv6 flag to inet_proto_csum_replace_by_diff, to skip the skb->csum update if we're in the IPv6 case. Note the behavior of the only other user of inet_proto_csum_replace_by_diff, the BPF subsystem, is left as is in this patch and fixed in the subsequent patch. With the fix, using the reproduction from above, I can confirm skb->csum is not touched by inet_proto_csum_replace_by_diff and the TCP SYN proceeds to the application after the ILA translation. Link: https://github.com/cilium/pwru [1] Fixes: 65d7ab8de582 ("net: Identifier Locator Addressing module") Signed-off-by: Paul Chaignon Acked-by: Daniel Borkmann Link: https://patch.msgid.link/b5539869e3550d46068504feb02d37653d939c0b.1748509484.git.paul.chaignon@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d5e3bfdba0dc419499b801937128957f77503761 Author: Alexis Lothoré Date: Thu May 29 11:07:24 2025 +0200 net: stmmac: make sure that ptp_rate is not 0 before configuring EST [ Upstream commit cbefe2ffa7784525ec5d008ba87c7add19ec631a ] If the ptp_rate recorded earlier in the driver happens to be 0, this bogus value will propagate up to EST configuration, where it will trigger a division by 0. Prevent this division by 0 by adding the corresponding check and error code. Suggested-by: Maxime Chevallier Signed-off-by: Alexis Lothoré Fixes: 8572aec3d0dc ("net: stmmac: Add basic EST support for XGMAC") Link: https://patch.msgid.link/20250529-stmmac_tstamp_div-v4-2-d73340a794d5@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 379cd990dfe752b38fcf46034698a9a150626c7a Author: Alexis Lothoré Date: Thu May 29 11:07:23 2025 +0200 net: stmmac: make sure that ptp_rate is not 0 before configuring timestamping [ Upstream commit 030ce919e114a111e83b7976ecb3597cefd33f26 ] The stmmac platform drivers that do not open-code the clk_ptp_rate value after having retrieved the default one from the device-tree can end up with 0 in clk_ptp_rate (as clk_get_rate can return 0). It will eventually propagate up to PTP initialization when bringing up the interface, leading to a divide by 0: Division by zero in kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22 Hardware name: STM32 (Device Tree Support) Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x6c/0x8c dump_stack_lvl from Ldiv0_64+0x8/0x18 Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4 stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c stmmac_hw_setup from __stmmac_open+0x18c/0x434 __stmmac_open from stmmac_open+0x3c/0xbc stmmac_open from __dev_open+0xf4/0x1ac __dev_open from __dev_change_flags+0x1cc/0x224 __dev_change_flags from dev_change_flags+0x24/0x60 dev_change_flags from ip_auto_config+0x2e8/0x11a0 ip_auto_config from do_one_initcall+0x84/0x33c do_one_initcall from kernel_init_freeable+0x1b8/0x214 kernel_init_freeable from kernel_init+0x24/0x140 kernel_init from ret_from_fork+0x14/0x28 Exception stack(0xe0815fb0 to 0xe0815ff8) Prevent this division by 0 by adding an explicit check and error log about the actual issue. While at it, remove the same check from stmmac_ptp_register, which then becomes duplicate Fixes: 19d857c9038e ("stmmac: Fix calculations for ptp counters when clock input = 50Mhz.") Signed-off-by: Alexis Lothoré Reviewed-by: Yanteng Si Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20250529-stmmac_tstamp_div-v4-1-d73340a794d5@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1e72069fb33d4032c329d4cfee901f20b8faa75f Author: Álvaro Fernández Rojas Date: Thu May 29 14:44:06 2025 +0200 net: dsa: tag_brcm: legacy: fix pskb_may_pull length [ Upstream commit efdddc4484859082da6c7877ed144c8121c8ea55 ] BRCM_LEG_PORT_ID was incorrectly used for pskb_may_pull length. The correct check is BRCM_LEG_TAG_LEN + VLAN_HLEN, or 10 bytes. Fixes: 964dbf186eaa ("net: dsa: tag_brcm: add support for legacy tags") Signed-off-by: Álvaro Fernández Rojas Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250529124406.2513779-1-noltari@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 73be96915373d54b8b9441666056bc21036fda00 Author: Emil Tantilov Date: Thu May 8 11:47:15 2025 -0700 idpf: avoid mailbox timeout delays during reset [ Upstream commit 9dc63d8ff182150d7d7b318ab9389702a2c0a292 ] Mailbox operations are not possible while the driver is in reset. Operations that require MBX exchange with the control plane will result in long delays if executed while a reset is in progress: ethtool -L combined 8& echo 1 > /sys/class/net//device/reset idpf 0000:83:00.0: HW reset detected idpf 0000:83:00.0: Device HW Reset initiated idpf 0000:83:00.0: Transaction timed-out (op:504 cookie:be00 vc_op:504 salt:be timeout:2000ms) idpf 0000:83:00.0: Transaction timed-out (op:508 cookie:bf00 vc_op:508 salt:bf timeout:2000ms) idpf 0000:83:00.0: Transaction timed-out (op:512 cookie:c000 vc_op:512 salt:c0 timeout:2000ms) idpf 0000:83:00.0: Transaction timed-out (op:510 cookie:c100 vc_op:510 salt:c1 timeout:2000ms) idpf 0000:83:00.0: Transaction timed-out (op:509 cookie:c200 vc_op:509 salt:c2 timeout:60000ms) idpf 0000:83:00.0: Transaction timed-out (op:509 cookie:c300 vc_op:509 salt:c3 timeout:60000ms) idpf 0000:83:00.0: Transaction timed-out (op:505 cookie:c400 vc_op:505 salt:c4 timeout:60000ms) idpf 0000:83:00.0: Failed to configure queues for vport 0, -62 Disable mailbox communication in case of a reset, unless it's done during a driver load, where the virtchnl operations are needed to configure the device. Fixes: 8077c727561aa ("idpf: add controlq init and reset checks") Co-developed-by: Joshua Hay Signed-off-by: Joshua Hay Signed-off-by: Emil Tantilov Reviewed-by: Ahmed Zaki Reviewed-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e47d842adcbfc16dc0fe8f0d8c27a63484363099 Author: Brian Vazquez Date: Thu May 1 17:06:17 2025 +0000 idpf: fix a race in txq wakeup [ Upstream commit 7292af042bcf22e2c18b96ed250f78498a5b28ab ] Add a helper function to correctly handle the lockless synchronization when the sender needs to block. The paradigm is if (no_resources()) { stop_queue(); barrier(); if (!no_resources()) restart_queue(); } netif_subqueue_maybe_stop already handles the paradigm correctly, but the code split the check for resources in three parts, the first one (descriptors) followed the protocol, but the other two (completions and tx_buf) were only doing the first part and so race prone. Luckily netif_subqueue_maybe_stop macro already allows you to use a function to evaluate the start/stop conditions so the fix only requires the right helper function to evaluate all the conditions at once. The patch removes idpf_tx_maybe_stop_common since it's no longer needed and instead adjusts separately the conditions for singleq and splitq. Note that idpf_tx_buf_hw_update doesn't need to check for resources since that will be covered in idpf_tx_splitq_frame. To reproduce: Reduce the threshold for pending completions to increase the chances of hitting this pause by changing your kernel: drivers/net/ethernet/intel/idpf/idpf_txrx.h -#define IDPF_TX_COMPLQ_OVERFLOW_THRESH(txcq) ((txcq)->desc_count >> 1) +#define IDPF_TX_COMPLQ_OVERFLOW_THRESH(txcq) ((txcq)->desc_count >> 4) Use pktgen to force the host to push small pkts very aggressively: ./pktgen_sample02_multiqueue.sh -i eth1 -s 100 -6 -d $IP -m $MAC \ -p 10000-10000 -t 16 -n 0 -v -x -c 64 Fixes: 6818c4d5b3c2 ("idpf: add splitq start_xmit") Reviewed-by: Jacob Keller Reviewed-by: Madhu Chittim Signed-off-by: Josh Hay Signed-off-by: Brian Vazquez Signed-off-by: Luigi Rizzo Reviewed-by: Simon Horman Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 4d65cfa6d0129534ce4b64365c77d01aef59146e Author: Michal Kubiak Date: Tue May 13 12:55:29 2025 +0200 ice: fix rebuilding the Tx scheduler tree for large queue counts [ Upstream commit 73145e6d81070d34a21431c9e0d7aaf2f29ca048 ] The current implementation of the Tx scheduler allows the tree to be rebuilt as the user adds more Tx queues to the VSI. In such a case, additional child nodes are added to the tree to support the new number of queues. Unfortunately, this algorithm does not take into account that the limit of the VSI support node may be exceeded, so an additional node in the VSI layer may be required to handle all the requested queues. Such a scenario occurs when adding XDP Tx queues on machines with many CPUs. Although the driver still respects the queue limit returned by the FW, the Tx scheduler was unable to add those queues to its tree and returned one of the errors below. Such a scenario occurs when adding XDP Tx queues on machines with many CPUs (e.g. at least 321 CPUs, if there is already 128 Tx/Rx queue pairs). Although the driver still respects the queue limit returned by the FW, the Tx scheduler was unable to add those queues to its tree and returned the following errors: Failed VSI LAN queue config for XDP, error: -5 or: Failed to set LAN Tx queue context, error: -22 Fix this problem by extending the tree rebuild algorithm to check if the current VSI node can support the requested number of queues. If it cannot, create as many additional VSI support nodes as necessary to handle all the required Tx queues. Symmetrically, adjust the VSI node removal algorithm to remove all nodes associated with the given VSI. Also, make the search for the next free VSI node more restrictive. That is, add queue group nodes only to the VSI support nodes that have a matching VSI handle. Finally, fix the comment describing the tree update algorithm to better reflect the current scenario. Fixes: b0153fdd7e8a ("ice: update VSI config dynamically") Reviewed-by: Dawid Osuchowski Reviewed-by: Przemek Kitszel Signed-off-by: Michal Kubiak Reviewed-by: Simon Horman Tested-by: Jesse Brandeburg Tested-by: Saritha Sanigani (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 4e68afb05566a94980ba3fa5f48ace89e1a8b99d Author: Michal Kubiak Date: Tue May 13 12:55:28 2025 +0200 ice: create new Tx scheduler nodes for new queues only [ Upstream commit 6fa2942578472c9cab13a8fc1dae0d830193e0a1 ] The current implementation of the Tx scheduler tree attempts to create nodes for all Tx queues, ignoring the fact that some queues may already exist in the tree. For example, if the VSI already has 128 Tx queues and the user requests for 16 new queues, the Tx scheduler will compute the tree for 272 queues (128 existing queues + 144 new queues), instead of 144 queues (128 existing queues and 16 new queues). Fix that by modifying the node count calculation algorithm to skip the queues that already exist in the tree. Fixes: 5513b920a4f7 ("ice: Update Tx scheduler tree for VSI multi-Tx queue support") Reviewed-by: Dawid Osuchowski Reviewed-by: Przemek Kitszel Reviewed-by: Jacob Keller Signed-off-by: Michal Kubiak Reviewed-by: Simon Horman Tested-by: Jesse Brandeburg Tested-by: Saritha Sanigani (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 0e061abaad1498c5b76c10c594d4359ceb6b9145 Author: Michal Kubiak Date: Tue May 13 12:55:27 2025 +0200 ice: fix Tx scheduler error handling in XDP callback [ Upstream commit 0153f36041b8e52019ebfa8629c13bf8f9b0a951 ] When the XDP program is loaded, the XDP callback adds new Tx queues. This means that the callback must update the Tx scheduler with the new queue number. In the event of a Tx scheduler failure, the XDP callback should also fail and roll back any changes previously made for XDP preparation. The previous implementation had a bug that not all changes made by the XDP callback were rolled back. This caused the crash with the following call trace: [ +9.549584] ice 0000:ca:00.0: Failed VSI LAN queue config for XDP, error: -5 [ +0.382335] Oops: general protection fault, probably for non-canonical address 0x50a2250a90495525: 0000 [#1] SMP NOPTI [ +0.010710] CPU: 103 UID: 0 PID: 0 Comm: swapper/103 Not tainted 6.14.0-net-next-mar-31+ #14 PREEMPT(voluntary) [ +0.010175] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022 [ +0.010946] RIP: 0010:__ice_update_sample+0x39/0xe0 [ice] [...] [ +0.002715] Call Trace: [ +0.002452] [ +0.002021] ? __die_body.cold+0x19/0x29 [ +0.003922] ? die_addr+0x3c/0x60 [ +0.003319] ? exc_general_protection+0x17c/0x400 [ +0.004707] ? asm_exc_general_protection+0x26/0x30 [ +0.004879] ? __ice_update_sample+0x39/0xe0 [ice] [ +0.004835] ice_napi_poll+0x665/0x680 [ice] [ +0.004320] __napi_poll+0x28/0x190 [ +0.003500] net_rx_action+0x198/0x360 [ +0.003752] ? update_rq_clock+0x39/0x220 [ +0.004013] handle_softirqs+0xf1/0x340 [ +0.003840] ? sched_clock_cpu+0xf/0x1f0 [ +0.003925] __irq_exit_rcu+0xc2/0xe0 [ +0.003665] common_interrupt+0x85/0xa0 [ +0.003839] [ +0.002098] [ +0.002106] asm_common_interrupt+0x26/0x40 [ +0.004184] RIP: 0010:cpuidle_enter_state+0xd3/0x690 Fix this by performing the missing unmapping of XDP queues from q_vectors and setting the XDP rings pointer back to NULL after all those queues are released. Also, add an immediate exit from the XDP callback in case of ring preparation failure. Fixes: efc2214b6047 ("ice: Add support for XDP") Reviewed-by: Dawid Osuchowski Reviewed-by: Przemek Kitszel Reviewed-by: Jacob Keller Signed-off-by: Michal Kubiak Reviewed-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Jesse Brandeburg Tested-by: Saritha Sanigani (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit b21d6998a618f53e576dd2eb404021495703ad45 Author: Luiz Augusto von Dentz Date: Wed May 28 14:53:11 2025 -0400 Bluetooth: L2CAP: Fix not responding with L2CAP_CR_LE_ENCRYPTION [ Upstream commit 03dba9cea72f977e873e4e60e220fa596959dd8f ] Depending on the security set the response to L2CAP_LE_CONN_REQ shall be just L2CAP_CR_LE_ENCRYPTION if only encryption when BT_SECURITY_MEDIUM is selected since that means security mode 2 which doesn't require authentication which is something that is covered in the qualification test L2CAP/LE/CFC/BV-25-C. Link: https://github.com/bluez/bluez/issues/1270 Fixes: 27e2d4c8d28b ("Bluetooth: Add basic LE L2CAP connect request receiving support") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 9eeafd16d76a7642d12b3442a26c15cd345e12f7 Author: Dmitry Antipov Date: Thu May 22 21:16:02 2025 +0300 Bluetooth: MGMT: reject malformed HCI_CMD_SYNC commands [ Upstream commit 03f1700b9b4d4f2fed3165370f3c23db76553178 ] In 'mgmt_hci_cmd_sync()', check whether the size of parameters passed in 'struct mgmt_cp_hci_cmd_sync' matches the total size of the data (i.e. 'sizeof(struct mgmt_cp_hci_cmd_sync)' plus trailing bytes). Otherwise, large invalid 'params_len' will cause 'hci_cmd_sync_alloc()' to do 'skb_put_data()' from an area beyond the one actually passed to 'mgmt_hci_cmd_sync()'. Reported-by: syzbot+5fe2d5bfbfbec0b675a0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5fe2d5bfbfbec0b675a0 Fixes: 827af4787e74 ("Bluetooth: MGMT: Add initial implementation of MGMT_OP_HCI_CMD_SYNC") Signed-off-by: Dmitry Antipov Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 08f450057328e3c5f86daf574c1b70999b3774e3 Author: Álvaro Fernández Rojas Date: Thu May 29 15:09:15 2025 +0200 spi: bcm63xx-hsspi: fix shared reset [ Upstream commit 3d6d84c8f2f66d3fd6a43a1e2ce8e6b54c573960 ] Some bmips SoCs (bcm6362, bcm63268) share the same SPI reset for both SPI and HSSPI controllers, so reset shouldn't be exclusive. Fixes: 0eeadddbf09a ("spi: bcm63xx-hsspi: add reset support") Reported-by: Jonas Gorski Signed-off-by: Álvaro Fernández Rojas Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250529130915.2519590-3-noltari@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1b9e202b5102fe65caabc90f3a585e4058cef90a Author: Álvaro Fernández Rojas Date: Thu May 29 15:09:14 2025 +0200 spi: bcm63xx-spi: fix shared reset [ Upstream commit 5ad20e3d8cfe3b2e42bbddc7e0ebaa74479bb589 ] Some bmips SoCs (bcm6362, bcm63268) share the same SPI reset for both SPI and HSSPI controllers, so reset shouldn't be exclusive. Fixes: 38807adeaf1e ("spi: bcm63xx-spi: add reset support") Reported-by: Jonas Gorski Signed-off-by: Álvaro Fernández Rojas Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250529130915.2519590-2-noltari@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4e20c86cc7b436da97ddafc4de910d8f1191c68c Author: Yu Kuai Date: Tue May 27 16:14:07 2025 +0800 md/raid1,raid10: don't handle IO error for REQ_RAHEAD and REQ_NOWAIT [ Upstream commit 9f346f7d4ea73692b82f5102ca8698e4040469ea ] IO with REQ_RAHEAD or REQ_NOWAIT can fail early, even if the storage medium is fine, hence record badblocks or remove the disk from array does not make sense. This problem if found by lvm2 test lvcreate-large-raid, where dm-zero will fail read ahead IO directly. Fixes: e879a0d9cb08 ("md/raid1,raid10: don't ignore IO flags") Reported-and-tested-by: Mikulas Patocka Closes: https://lore.kernel.org/all/34fa755d-62c8-4588-8ee1-33cb1249bdf2@redhat.com/ Link: https://lore.kernel.org/linux-raid/20250527081407.3004055-1-yukuai1@huaweicloud.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 250154b79714595ecc1104ba357a11e51dea5b63 Author: Horatiu Vultur Date: Wed May 28 11:36:19 2025 +0200 net: lan966x: Make sure to insert the vlan tags also in host mode [ Upstream commit 27eab4c644236a9324084a70fe79e511cbd07393 ] When running these commands on DUT (and similar at the other end) ip link set dev eth0 up ip link add link eth0 name eth0.10 type vlan id 10 ip addr add 10.0.0.1/24 dev eth0.10 ip link set dev eth0.10 up ping 10.0.0.2 The ping will fail. The reason why is failing is because, the network interfaces for lan966x have a flag saying that the HW can insert the vlan tags into the frames(NETIF_F_HW_VLAN_CTAG_TX). Meaning that the frames that are transmitted don't have the vlan tag inside the skb data, but they have it inside the skb. We already get that vlan tag and put it in the IFH but the problem is that we don't configure the HW to rewrite the frame when the interface is in host mode. The fix consists in actually configuring the HW to insert the vlan tag if it is different than 0. Reviewed-by: Maxime Chevallier Fixes: 6d2c186afa5d ("net: lan966x: Add vlan support.") Signed-off-by: Horatiu Vultur Link: https://patch.msgid.link/20250528093619.3738998-1-horatiu.vultur@microchip.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b7516919625b473e977e4d4c0715620316912c57 Author: Dan Carpenter Date: Wed May 28 11:11:09 2025 +0300 net/mlx4_en: Prevent potential integer overflow calculating Hz [ Upstream commit 54d34165b4f786d7fea8412a18fb4a54c1eab623 ] The "freq" variable is in terms of MHz and "max_val_cycles" is in terms of Hz. The fact that "max_val_cycles" is a u64 suggests that support for high frequency is intended but the "freq_khz * 1000" would overflow the u32 type if we went above 4GHz. Use unsigned long long type for the mutliplication to prevent that. Fixes: 31c128b66e5b ("net/mlx4_en: Choose time-stamping shift value according to HW frequency") Signed-off-by: Dan Carpenter Reviewed-by: Simon Horman Link: https://patch.msgid.link/aDbFHe19juIJKjsb@stanley.mountain Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0918e3b62f8675a24ef0b9c250b600302252ba58 Author: Yanqing Wang Date: Wed May 28 15:53:51 2025 +0800 driver: net: ethernet: mtk_star_emac: fix suspend/resume issue [ Upstream commit ba99c627aac85bc746fb4a6e2d79edb3ad100326 ] Identify the cause of the suspend/resume hang: netif_carrier_off() is called during link state changes and becomes stuck while executing linkwatch_work(). To resolve this issue, call netif_device_detach() during the Ethernet suspend process to temporarily detach the network device from the kernel and prevent the suspend/resume hang. Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver") Signed-off-by: Yanqing Wang Signed-off-by: Macpaul Lin Signed-off-by: Biao Huang Link: https://patch.msgid.link/20250528075351.593068-1-macpaul.lin@mediatek.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9ff60e0d9974dccf24e89bcd3ee7933e538d929f Author: Charalampos Mitrodimas Date: Tue May 27 16:35:44 2025 +0000 net: tipc: fix refcount warning in tipc_aead_encrypt [ Upstream commit f29ccaa07cf3d35990f4d25028cc55470d29372b ] syzbot reported a refcount warning [1] caused by calling get_net() on a network namespace that is being destroyed (refcount=0). This happens when a TIPC discovery timer fires during network namespace cleanup. The recently added get_net() call in commit e279024617134 ("net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done") attempts to hold a reference to the network namespace. However, if the namespace is already being destroyed, its refcount might be zero, leading to the use-after-free warning. Replace get_net() with maybe_get_net(), which safely checks if the refcount is non-zero before incrementing it. If the namespace is being destroyed, return -ENODEV early, after releasing the bearer reference. [1]: https://lore.kernel.org/all/68342b55.a70a0220.253bc2.0091.GAE@google.com/T/#m12019cf9ae77e1954f666914640efa36d52704a2 Reported-by: syzbot+f0c4a4aba757549ae26c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68342b55.a70a0220.253bc2.0091.GAE@google.com/T/#m12019cf9ae77e1954f666914640efa36d52704a2 Fixes: e27902461713 ("net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done") Signed-off-by: Charalampos Mitrodimas Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20250527-net-tipc-warning-v2-1-df3dc398a047@posteo.net Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1850cf73f2717f059b38bef8bc3fe775d61ccf50 Author: Alok Tiwari Date: Tue May 27 06:08:16 2025 -0700 gve: Fix RX_BUFFERS_POSTED stat to report per-queue fill_cnt [ Upstream commit f41a94aade120dc60322865f363cee7865f2df01 ] Previously, the RX_BUFFERS_POSTED stat incorrectly reported the fill_cnt from RX queue 0 for all queues, resulting in inaccurate per-queue statistics. Fix this by correctly indexing priv->rx[idx].fill_cnt for each RX queue. Fixes: 24aeb56f2d38 ("gve: Add Gvnic stats AQ command and ethtool show/set-priv-flags.") Signed-off-by: Alok Tiwari Link: https://patch.msgid.link/20250527130830.1812903-1-alok.a.tiwari@oracle.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8501d814a674c68bfa49ea15be5a4fbd37acb498 Author: Quentin Schulz Date: Tue May 27 13:56:23 2025 +0200 net: stmmac: platform: guarantee uniqueness of bus_id [ Upstream commit eb7fd7aa35bfcc1e1fda4ecc42ccfcb526cdc780 ] bus_id is currently derived from the ethernetX alias. If one is missing for the device, 0 is used. If ethernet0 points to another stmmac device or if there are 2+ stmmac devices without an ethernet alias, then bus_id will be 0 for all of those. This is an issue because the bus_id is used to generate the mdio bus id (new_bus->id in drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c stmmac_mdio_register) and this needs to be unique. This allows to avoid needing to define ethernet aliases for devices with multiple stmmac controllers (such as the Rockchip RK3588) for multiple stmmac devices to probe properly. Obviously, the bus_id isn't guaranteed to be stable across reboots if no alias is set for the device but that is easily fixed by simply adding an alias if this is desired. Fixes: 25c83b5c2e82 ("dt:net:stmmac: Add support to dwmac version 3.610 and 3.710") Signed-off-by: Quentin Schulz Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20250527-stmmac-mdio-bus_id-v2-1-a5ca78454e3c@cherry.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4ab8c0f8905c9c4d05e7f437e65a9a365573ff02 Author: Dong Chenchen Date: Tue May 27 19:41:52 2025 +0800 page_pool: Fix use-after-free in page_pool_recycle_in_ring [ Upstream commit 271683bb2cf32e5126c592b5d5e6a756fa374fd9 ] syzbot reported a uaf in page_pool_recycle_in_ring: BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943 CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #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 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline] _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline] page_pool_recycle_in_ring net/core/page_pool.c:707 [inline] page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826 page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline] page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline] napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036 skb_pp_recycle net/core/skbuff.c:1047 [inline] skb_free_head net/core/skbuff.c:1094 [inline] skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125 skb_release_all net/core/skbuff.c:1190 [inline] __kfree_skb net/core/skbuff.c:1204 [inline] sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242 kfree_skb_reason include/linux/skbuff.h:1263 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline] root cause is: page_pool_recycle_in_ring ptr_ring_produce spin_lock(&r->producer_lock); WRITE_ONCE(r->queue[r->producer++], ptr) //recycle last page to pool page_pool_release page_pool_scrub page_pool_empty_ring ptr_ring_consume page_pool_return_page //release all page __page_pool_destroy free_percpu(pool->recycle_stats); free(pool) //free spin_unlock(&r->producer_lock); //pool->ring uaf read recycle_stat_inc(pool, ring); page_pool can be free while page pool recycle the last page in ring. Add producer-lock barrier to page_pool_release to prevent the page pool from being free before all pages have been recycled. recycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not enabled, which will trigger Wempty-body build warning. Add definition for pool stat macro to fix warning. Suggested-by: Jakub Kicinski Link: https://lore.kernel.org/netdev/20250513083123.3514193-1-dongchenchen2@huawei.com Fixes: ff7d6b27f894 ("page_pool: refurbish version of page_pool code") Reported-by: syzbot+204a4382fcb3311f3858@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=204a4382fcb3311f3858 Signed-off-by: Dong Chenchen Reviewed-by: Toke Høiland-Jørgensen Reviewed-by: Mina Almasry Link: https://patch.msgid.link/20250527114152.3119109-1-dongchenchen2@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 798acdc241a270a3d959fc7ab2b377226d02a83f Author: Tengteng Yang Date: Tue May 27 11:04:19 2025 +0800 Fix sock_exceed_buf_limit not being triggered in __sk_mem_raise_allocated [ Upstream commit 8542d6fac25c03b4bf36b2d762cfe60fda8491bb ] When a process under memory pressure is not part of any cgroup and the charged flag is false, trace_sock_exceed_buf_limit was not called as expected. This regression was introduced by commit 2def8ff3fdb6 ("sock: Code cleanup on __sk_mem_raise_allocated()"). The fix changes the default value of charged to true while preserving existing logic. Fixes: 2def8ff3fdb6 ("sock: Code cleanup on __sk_mem_raise_allocated()") Signed-off-by: Abel Wu Signed-off-by: Tengteng Yang Link: https://patch.msgid.link/20250527030419.67693-1-yangtengteng@bytedance.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c57aa95bba918c7cd399f9830e1fedcadfb46b26 Author: Rodrigo Vivi Date: Wed May 21 12:51:48 2025 -0400 drm/xe: Add missing documentation of rpa_freq [ Upstream commit 40493d97b329f8185c0f04dc0ef2b9ffc58e7f3b ] While at it, already adjust the rpe_freq frequency, to highlight that both are calculated by PCODE at runtime. Fixes: c6aac2fa77a3 ("drm/xe: Introduce the RPa information") Cc: Vinay Belgaumkar Cc: Lucas De Marchi Reviewed-by: Lucas De Marchi Reviewed-by: Vinay Belgaumkar Link: https://lore.kernel.org/r/20250521165146.39616-4-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit 39578fa40420fb11dbe4f42225a347e945d8fd0e) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 2350c3f81b79f0800b4adf7380161a1ca9f59f2e Author: Rodrigo Vivi Date: Wed May 21 12:51:47 2025 -0400 drm/xe: Make xe_gt_freq part of the Documentation [ Upstream commit 55f8aa083604ce098c9d6a0911c6bcde15d03a80 ] The documentation was created with the creation of the component, however it has never been actually shown in the actual Documentation. While doing this, fixes the identation style, to avoid new warnings while building htmldocs. Fixes: bef52b5c7a19 ("drm/xe: Create a xe_gt_freq component for raw management and sysfs") Reviewed-by: Lucas De Marchi Link: https://lore.kernel.org/r/20250521165146.39616-3-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit af53f0fd99c3bbb3afd29f1612c9e88c5a92cc01) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 2e826a8588e267e4468700ddd499ea9442e41f3c Author: Heiko Stuebner Date: Wed May 28 00:51:19 2025 +0200 drm/bridge: analogix_dp: Fix clk-disable removal [ Upstream commit fd03f82a026cc03cb8051a8c6487c99f96c9029f ] Commit 6579a03e68ff ("drm/bridge: analogix_dp: Remove the unnecessary calls to clk_disable_unprepare() during probing") removed the mismatched clock_disable calls from analogix_dp_probe. But that patch was created and sent before commit e5e9fa9f7aad ("drm/bridge: analogix_dp: Add support to get panel from the DP AUX bus") was merged, so couldn't know about this change. So in the original patch the last change is if (ret) { dev_err(&pdev->dev, "failed to request irq\n"); - goto err_disable_clk; + return ERR_PTR(ret); } disable_irq(dp->irq); return dp; - -err_disable_clk: - clk_disable_unprepare(dp->clock); - return ERR_PTR(ret); } EXPORT_SYMBOL_GPL(analogix_dp_probe); the analogix_dp_core.c actually now has the runtime-pm handling between disable_irq() and return do introducing another goto err_clk_disable there. So remove that one too and return an error pointer, to not create build breakage. Fixes: 6579a03e68ff ("drm/bridge: analogix_dp: Remove the unnecessary calls to clk_disable_unprepare() during probing") Signed-off-by: Heiko Stuebner Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250527225120.3361663-1-heiko@sntech.de Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit b841e7ddceb8205684d8067375fb3100d64b9ef4 Author: Damon Ding Date: Mon Mar 10 18:41:07 2025 +0800 drm/bridge: analogix_dp: Add support to get panel from the DP AUX bus [ Upstream commit e5e9fa9f7aad4ad7eedb6359baea9193531bf4ac ] The main modification is moving the DP AUX initialization from function analogix_dp_bind() to analogix_dp_probe(). In order to get the EDID of eDP panel during probing, it is also needed to advance PM operations to ensure that eDP controller and phy are prepared for AUX transmission. Signed-off-by: Damon Ding Reviewed-by: Dmitry Baryshkov Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20250310104114.2608063-7-damon.ding@rock-chips.com Signed-off-by: Dmitry Baryshkov Stable-dep-of: fd03f82a026c ("drm/bridge: analogix_dp: Fix clk-disable removal") Signed-off-by: Sasha Levin commit 7b0a3da39e7d95e406417857109e54c2ac93351d Author: Damon Ding Date: Mon Mar 10 18:41:03 2025 +0800 drm/bridge: analogix_dp: Remove CONFIG_PM related check in analogix_dp_bind()/analogix_dp_unbind() [ Upstream commit c71db051142a74b255cb61b84d8fedae3b70952f ] Remove the check related to CONFIG_PM in order to make the code more concise, as the CONFIG_PM should be a required option for many drivers. In addition, it is preferable to use devm_pm_runtime_enable() instead of manually invoking pm_runtime_enable() followed by pm_runtime_disable(). Suggested-by: Douglas Anderson Reviewed-by: Douglas Anderson Signed-off-by: Damon Ding Link: https://lore.kernel.org/r/20250310104114.2608063-3-damon.ding@rock-chips.com Signed-off-by: Dmitry Baryshkov Stable-dep-of: fd03f82a026c ("drm/bridge: analogix_dp: Fix clk-disable removal") Signed-off-by: Sasha Levin commit 6bb773d15837692f6c1624c9a513601b38764a48 Author: Karol Wachowski Date: Thu May 15 11:41:24 2025 +0200 accel/ivpu: Reorder Doorbell Unregister and Command Queue Destruction [ Upstream commit 4557cc834712eca4eae7adbd9f0a06bdd8f79c99 ] Refactor ivpu_cmdq_unregister() to ensure the doorbell is unregistered before destroying the command queue. The NPU firmware requires doorbells to be unregistered prior to command queue destruction. If doorbell remains registered when command queue destroy command is sent firmware will automatically unregister the doorbell, making subsequent unregister attempts no-operations (NOPs). Ensure compliance with firmware expectations by moving the doorbell unregister call ahead of the command queue destruction logic, thus preventing unnecessary NOP operation. Fixes: 465a3914b254 ("accel/ivpu: Add API for command queue create/destroy/submit") Signed-off-by: Karol Wachowski Reviewed-by: Jeff Hugo Signed-off-by: Jacek Lawrynowicz Link: https://lore.kernel.org/r/20250515094124.255141-1-jacek.lawrynowicz@linux.intel.com Signed-off-by: Sasha Levin commit e0930ed863233439f8276c81a5cbb463f06e6f25 Author: Damon Ding Date: Sun Mar 2 16:30:43 2025 +0800 drm/bridge: analogix_dp: Remove the unnecessary calls to clk_disable_unprepare() during probing [ Upstream commit 6579a03e68ffa5feb2d2823dea16ca7466f6de16 ] With the commit f37952339cc2 ("drm/bridge: analogix_dp: handle clock via runtime PM"), the PM operations can help enable/disable the clock. The err_disable_clk label and clk_disable_unprepare() operations are no longer necessary because the analogix_dp_resume() will not be called during probing. Fixes: f37952339cc2 ("drm/bridge: analogix_dp: handle clock via runtime PM") Suggested-by: Douglas Anderson Reviewed-by: Douglas Anderson Signed-off-by: Damon Ding Reviewed-by: Heiko Stuebner Link: https://lore.kernel.org/r/20250302083043.3197235-1-damon.ding@rock-chips.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 933f3eab1d489af8d734bff855b10d29dd5968a4 Author: Nicolas Frattaroli Date: Tue May 27 19:57:08 2025 +0200 drm/connector: only call HDMI audio helper plugged cb if non-null [ Upstream commit be9b3f9a54101c19226c25ba7163d291183777a0 ] On driver remove, sound/soc/codecs/hdmi-codec.c calls the plugged_cb with NULL as the callback function and codec_dev, as seen in its hdmi_remove function. The HDMI audio helper then happily tries calling said null function pointer, and produces an Oops as a result. Fix this by only executing the callback if fn is non-null. This means the .plugged_cb and .plugged_cb_dev members still get appropriately cleared. Fixes: baf616647fe6 ("drm/connector: implement generic HDMI audio helpers") Signed-off-by: Nicolas Frattaroli Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250527-hdmi-audio-helper-remove-fix-v1-1-6cf77de364d8@collabora.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 966229c6bac9b4a35116fc03dfd235d260073a24 Author: Ming Lei Date: Tue May 27 23:34:05 2025 +0800 loop: add file_start_write() and file_end_write() [ Upstream commit 39d86db34e41b96bd86f1955cd0ce6cd9c5fca4c ] file_start_write() and file_end_write() should be added around ->write_iter(). Recently we switch to ->write_iter() from vfs_iter_write(), and the implied file_start_write() and file_end_write() are lost. Also we never add them for dio code path, so add them back for covering both. Cc: Jeff Moyer Fixes: f2fed441c69b ("loop: stop using vfs_iter_{read,write} for buffered I/O") Fixes: bc07c10a3603 ("block: loop: support DIO & AIO") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20250527153405.837216-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d32e4b0546b2b0570cdd67ec95750697cbb86e6e Author: Greg Kroah-Hartman Date: Wed May 21 15:35:24 2025 +0200 USB: typec: fix const issue in typec_match() [ Upstream commit ae4432e01dd967a64f6670a152d91d5328032726 ] typec_match() takes a const pointer, and then decides to cast it away into a non-const one, which is not a good thing to do overall. Fix this up by properly setting the pointers to be const to preserve that attribute. Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/2025052126-scholar-stainless-ad55@gregkh Fixes: d69d80484598 ("driver core: have match() callback in struct bus_type take a const *") Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 84dfe77602e81392ea07303673ea30fa7ac2fefd Author: Greg Kroah-Hartman Date: Wed May 21 15:41:40 2025 +0200 USB: gadget: udc: fix const issue in gadget_match_driver() [ Upstream commit 5f5cc794fac605afd3bef8065e33096aeacf6257 ] gadget_match_driver() takes a const pointer, and then decides to cast it away into a non-const one, which is not a good thing to do overall. Fix this up by properly setting the pointers to be const to preserve that attribute. Fixes: d69d80484598 ("driver core: have match() callback in struct bus_type take a const *") Link: https://lore.kernel.org/r/2025052139-rash-unsaddle-7c5e@gregkh Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2ff84314be02bd8e00244cb40125625e3d1dc1af Author: Marcus Folkesson Date: Mon Apr 28 08:54:11 2025 +0200 iio: adc: mcp3911: fix device dependent mappings for conversion result registers [ Upstream commit f62c49d8f32d6ce8871b01795498352775aa61db ] The conversion result registers differs between devices. Make sure the mapping is correct by using a device dependent .get_raw() callback function. Fixes: 732ad34260d3 ("iio: adc: mcp3911: add support for the whole MCP39xx family") Co-developed-by: Lukas Rauber Signed-off-by: Lukas Rauber Signed-off-by: Marcus Folkesson Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20250428-mcp3911-fixes-v2-1-406e39330c3d@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit aae3f30240c03593532e382e2ad02a3568a01fb3 Author: Marius Cristea Date: Thu Apr 24 11:06:33 2025 +0300 iio: adc: PAC1934: fix typo in documentation link [ Upstream commit 52c43d80fa8370eb877fc63b1fc1eec67e1b1410 ] Fix a typo,(PAC1934 -> PAC193X), into the link from an application note related to the ACPI device definition. Fixes: 0fb528c8255b ("iio: adc: adding support for PAC193x") Reported-by: Matteo Martelli Closes: https://patch.msgid.link/172794015844.2520.11909797050797595912@njaxe.localdomain Signed-off-by: Marius Cristea Reviewed-by: David Lechner Link: https://patch.msgid.link/20250424-pac1934-doc_link-v1-1-9832445cb270@microchip.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 34627b25251cf6c081494de8148179bf223094c4 Author: Hans de Goede Date: Wed May 7 11:07:28 2025 +0200 mei: vsc: Cast tx_buf to (__be32 *) when passed to cpu_to_be32_array() [ Upstream commit 97ce0fe2b7240d47d9124daa92217e478c21a3ba ] Commit f88c0c72ffb0 ("mei: vsc: Use struct vsc_tp_packet as vsc-tp tx_buf and rx_buf type") changed the type of tx_buf from "void *" to "struct vsc_tp_packet *" and added a cast to (u32 *) when passing it to cpu_to_be32_array() and the same change was made for rx_buf. This triggers the type-check warning in sparse: vsc-tp.c:327:28: sparse: expected restricted __be32 [usertype] *dst vsc-tp.c:327:28: sparse: got unsigned int [usertype] * vsc-tp.c:343:42: sparse: expected restricted __be32 const [usertype] *src vsc-tp.c:343:42: sparse: got unsigned int [usertype] * Fix this by casting to (__be32 *) instead. Note actually changing the type of the buffers to "be32 *" is not an option this buffer does actually contain a "struct vsc_tp_packet" and is used as such most of the time. vsc_tp_rom_xfer() re-uses the buffers as just dumb arrays of 32 bit words to talk to the device before the firmware has booted, to avoid needing to allocate a separate buffer. Fixes: f88c0c72ffb0 ("mei: vsc: Use struct vsc_tp_packet as vsc-tp tx_buf and rx_buf type") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202505071634.kZ0I7Va6-lkp@intel.com/ Signed-off-by: Hans de Goede Reviewed-by: Sakari Ailus Link: https://lore.kernel.org/r/20250507090728.115910-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d7e380af93ba9188f5bc118a17416d8c76c546c5 Author: Roxana Nicolescu Date: Thu May 1 20:05:00 2025 +0000 char: tlclk: Fix correct sysfs directory path for tlclk [ Upstream commit 46a4d12a005c58317e89b5644774c683365dc2ca ] The tlckl driver does not create a platform device anymore. It was recently changed to use a faux device instead. Therefore the sysfs path has changed from /sys/devices/platform/telco_clock to /sys/devices/faux/telco_clock. Fixes: 72239a78f9f5 ("tlclk: convert to use faux_device") Signed-off-by: Roxana Nicolescu Link: https://lore.kernel.org/r/20250501200457.18506-1-nicolescu.roxana@protonmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 35187d96bc03992121f94707749160090f9e6942 Author: Roxana Nicolescu Date: Tue May 6 11:00:07 2025 +0000 misc: lis3lv02d: Fix correct sysfs directory path for lis3lv02d [ Upstream commit 7b386d7454b610534026b279aa150e5a9e584082 ] The lis3lv02d driver does not create a platform device anymore. It was recently changed to use a faux device instead. Therefore the sysfs path has changed from /sys/devices/platform/lis3lv02d to /sys/devices/faux/lis3lv02d. Fixes: 3b18ccb5472b ("misc: lis3lv02d: convert to use faux_device") Signed-off-by: Roxana Nicolescu Link: https://lore.kernel.org/r/20250506110002.36477-1-nicolescu.roxana@protonmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a687bcb724082af94fdae5c3387da1801ab3a4f5 Author: Christian Schrefl Date: Sat May 17 13:06:15 2025 +0200 rust: miscdevice: fix typo in MiscDevice::ioctl documentation [ Upstream commit 81e9edc1a8d657291409d70d93361d8277d226d8 ] Fixes one small typo (`utilties` to `utilities`) in the documentation of `MiscDevice::ioctl`. Fixes: f893691e7426 ("rust: miscdevice: add base miscdevice abstraction") Signed-off-by: Christian Schrefl Reviewed-by: Benno Lossin Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20250517-rust_miscdevice_fix_typo-v1-1-8c30a6237ba9@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8c797936a763adaabdb199bbbec63017d238e2cf Author: Dave Penkler Date: Tue May 20 17:51:00 2025 +0200 staging: gpib: Fix secondary address restriction [ Upstream commit 5aac95320d0f17f1098960e903ce5e087f42bc70 ] GPIB secondary addresses have valid values between 0 and 31 inclusive. The Make Secondary Address function MSA, used to form the protocol byte, was using the gpib_address_restrict function erroneously restricting the address range to 0 through 30. Remove the call to gpib_address_restrict and simply trim the address to 5 bits. Fixes: 2da03e7e31aa ("staging: gpib: Add user api include files") Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250520155100.5808-1-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cb4b635efb78c5cdfab13b6037144aab901078d9 Author: Dave Penkler Date: Fri May 2 09:21:48 2025 +0200 staging: gpib: Fix PCMCIA config identifier [ Upstream commit 034a456869a071c635a9997e0bf3947a6cb20b25 ] The PCMCIA config identifier in the ines_exit_module function was never changed because it was misspelled in the original commit. Update the config parameter to use the correct identifier from gpib/Kconfig Fixes: bb1bd92fa0f2 ("staging: gpib: Add ines GPIB driver") Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250502072150.32714-2-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d7a3c36a955d06c31bc1359397be5a1c1a1e80e7 Author: Nicolas Pitre Date: Thu May 15 11:30:52 2025 -0400 vt: remove VT_RESIZE and VT_RESIZEX from vt_compat_ioctl() [ Upstream commit c4c7ead7b86c1e7f11c64915b7e5bb6d2e242691 ] They are listed amon those cmd values that "treat 'arg' as an integer" which is wrong. They should instead fall into the default case. Probably nobody ever relied on that code since 2009 but still. Fixes: e92166517e3c ("tty: handle VT specific compat ioctls in vt driver") Signed-off-by: Nicolas Pitre Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/pr214s15-36r8-6732-2pop-159nq85o48r7@syhkavp.arg Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ed42ee1ed05ff2f4c36938379057413a40c56680 Author: Yeoreum Yun Date: Wed May 14 17:19:51 2025 +0100 coresight: prevent deactivate active config while enabling the config [ Upstream commit 408c97c4a5e0b634dcd15bf8b8808b382e888164 ] While enable active config via cscfg_csdev_enable_active_config(), active config could be deactivated via configfs' sysfs interface. This could make UAF issue in below scenario: CPU0 CPU1 (sysfs enable) load module cscfg_load_config_sets() activate config. // sysfs (sys_active_cnt == 1) ... cscfg_csdev_enable_active_config() lock(csdev->cscfg_csdev_lock) // here load config activate by CPU1 unlock(csdev->cscfg_csdev_lock) deactivate config // sysfs (sys_activec_cnt == 0) cscfg_unload_config_sets() unload module // access to config_desc which freed // while unloading module. cscfg_csdev_enable_config To address this, use cscfg_config_desc's active_cnt as a reference count which will be holded when - activate the config. - enable the activated config. and put the module reference when config_active_cnt == 0. Fixes: f8cce2ff3c04 ("coresight: syscfg: Add API to activate and enable configurations") Suggested-by: Suzuki K Poulose Signed-off-by: Yeoreum Yun Reviewed-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250514161951.3427590-4-yeoreum.yun@arm.com Signed-off-by: Sasha Levin commit 42f8afb0b161631fd1d814d017f75f955475ad41 Author: Yeoreum Yun Date: Wed May 14 17:19:50 2025 +0100 coresight: holding cscfg_csdev_lock while removing cscfg from csdev [ Upstream commit 53b9e2659719b04f5ba7593f2af0f2335f75e94a ] There'll be possible race scenario for coresight config: CPU0 CPU1 (perf enable) load module cscfg_load_config_sets() activate config. // sysfs (sys_active_cnt == 1) ... cscfg_csdev_enable_active_config() lock(csdev->cscfg_csdev_lock) deactivate config // sysfs (sys_activec_cnt == 0) cscfg_unload_config_sets() cscfg_remove_owned_csdev_configs() // here load config activate by CPU1 unlock(csdev->cscfg_csdev_lock) iterating config_csdev_list could be raced with config_csdev_list's entry delete. To resolve this race , hold csdev->cscfg_csdev_lock() while cscfg_remove_owned_csdev_configs() Fixes: 02bd588e12df ("coresight: configuration: Update API to permit dynamic load/unload") Signed-off-by: Yeoreum Yun Reviewed-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250514161951.3427590-3-yeoreum.yun@arm.com Signed-off-by: Sasha Levin commit c7f2b00d5e17e3702c59cbe2070543aa1f8eb96e Author: Yeoreum Yun Date: Wed May 14 17:19:49 2025 +0100 coresight/etm4: fix missing disable active config [ Upstream commit 895b12b7d7b8c651f73f57a1ea040d35aa7048cb ] When etm4 device is disabled via sysfs, it should disable its active count. Fixes: 7ebd0ec6cf94 ("coresight: configfs: Allow configfs to activate configuration") Signed-off-by: Yeoreum Yun Reviewed-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250514161951.3427590-2-yeoreum.yun@arm.com Signed-off-by: Sasha Levin commit b22f48a3a7fd98248b6cb8a9c4a29cf6e0520261 Author: Leo Yan Date: Mon May 19 18:49:44 2025 +0100 coresight: etm4x: Fix timestamp bit field handling [ Upstream commit ee811bc733be5c57a2bfecdf2f6f5d4db466200a ] Timestamps in the trace data appear as all zeros on recent kernels, although the feature works correctly on old kernels (e.g., v6.12). Since commit c382ee674c8b ("arm64/sysreg/tools: Move TRFCR definitions to sysreg"), the TRFCR_ELx_TS_{VIRTUAL|GUEST_PHYSICAL|PHYSICAL} macros were updated to remove the bit shift. As a result, the driver no longer shifts bits when operates the timestamp field. Fix this by using the FIELD_PREP() and FIELD_GET() helpers. Reported-by: Tamas Zsoldos Fixes: c382ee674c8b ("arm64/sysreg/tools: Move TRFCR definitions to sysreg") Signed-off-by: Leo Yan Reviewed-by: James Clark Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250519174945.2245271-2-leo.yan@arm.com Signed-off-by: Sasha Levin commit f9809df09f74de1abe4c538f29e38a4f6a5735a3 Author: Mao Jinlong Date: Tue May 6 23:37:16 2025 -0700 coresight: tmc: fix failure to disable/enable ETF after reading [ Upstream commit d23bc38e8aa4efbd617bf660bb1a25fee9f6c177 ] ETF may fail to re-enable after reading, and driver->reading will not be set to false, this will cause failure to enable/disable to ETF. This change set driver->reading to false even if re-enabling fail. Fixes: 669c4614236a ("coresight: tmc: Don't enable TMC when it's not ready.") Co-developed-by: Yuanfang Zhang Signed-off-by: Yuanfang Zhang Signed-off-by: Mao Jinlong [ Added a comment to explain why we ignore the error ] Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250507063716.1945213-1-quic_jinlmao@quicinc.com Signed-off-by: Sasha Levin commit 6c3b9e1167d072ce2d01cafec7866647cf8d3616 Author: Antoniu Miclaus Date: Fri May 9 13:16:57 2025 +0300 iio: adc: ad4851: fix ad4858 chan pointer handling [ Upstream commit 499a8cee812588905cc940837e69918c1649a19e ] The pointer returned from ad4851_parse_channels_common() is incremented internally as each channel is populated. In ad4858_parse_channels(), the same pointer was further incremented while setting ext_scan_type fields for each channel. This resulted in indio_dev->channels being set to a pointer past the end of the allocated array, potentially causing memory corruption or undefined behavior. Fix this by iterating over the channels using an explicit index instead of incrementing the pointer. This preserves the original base pointer and ensures all channel metadata is set correctly. Fixes: 6250803fe2ec ("iio: adc: ad4851: add ad485x driver") Signed-off-by: Antoniu Miclaus Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20250509101657.6742-1-antoniu.miclaus@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 967a479803b4165d998b0e3195158615b991ca3e Author: Angelo Dureghello Date: Wed Apr 9 11:16:54 2025 +0200 iio: dac: adi-axi-dac: fix bus read [ Upstream commit 921fece3268c3bf2e8c20dd17ff9e5454fa16fda ] Fix bus read function. Testing the driver, on a random basis, wrong reads was detected, mainly by a wrong DAC chip ID read at first boot. Before reading the expected value from the AXI regmap, need always to wait for busy flag to be cleared. Fixes: e61d7178429a ("iio: dac: adi-axi-dac: extend features") Signed-off-by: Angelo Dureghello Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20250409-ad3552r-fix-bus-read-v2-1-34d3b21e8ca0@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit eb4c74eaa6e2d15f3bbd32941c9d2a25b29a718d Author: Qasim Ijaz Date: Tue Apr 22 16:37:37 2025 +0100 fpga: fix potential null pointer deref in fpga_mgr_test_img_load_sgt() [ Upstream commit 6ebf1982038af12f3588417e4fd0417d2551da28 ] fpga_mgr_test_img_load_sgt() allocates memory for sgt using kunit_kzalloc() however it does not check if the allocation failed. It then passes sgt to sg_alloc_table(), which passes it to __sg_alloc_table(). This function calls memset() on sgt in an attempt to zero it out. If the allocation fails then sgt will be NULL and the memset will trigger a NULL pointer dereference. Fix this by checking the allocation with KUNIT_ASSERT_NOT_ERR_OR_NULL(). Reviewed-by: Marco Pagani Fixes: ccbc1c302115 ("fpga: add an initial KUnit suite for the FPGA Manager") Signed-off-by: Qasim Ijaz Acked-by: Xu Yilun Link: https://lore.kernel.org/r/20250422153737.5264-1-qasdev00@gmail.com Signed-off-by: Xu Yilun Signed-off-by: Sasha Levin commit 798d78a2cd73b52850e77ab668a5d3dc64ba040b Author: Alexander Sverdlin Date: Mon Mar 31 18:36:40 2025 +0200 counter: interrupt-cnt: Protect enable/disable OPs with mutex [ Upstream commit 7351312632e831e51383f48957d47712fae791ef ] Enable/disable seems to be racy on SMP, consider the following scenario: CPU0 CPU1 interrupt_cnt_enable_write(true) { if (priv->enabled == enable) return 0; if (enable) { priv->enabled = true; interrupt_cnt_enable_write(false) { if (priv->enabled == enable) return 0; if (enable) { priv->enabled = true; enable_irq(priv->irq); } else { disable_irq(priv->irq) priv->enabled = false; } enable_irq(priv->irq); } else { disable_irq(priv->irq); priv->enabled = false; } The above would result in priv->enabled == false, but IRQ left enabled. Protect both write (above race) and read (to propagate the value on SMP) callbacks with a mutex. Signed-off-by: Alexander Sverdlin Fixes: a55ebd47f21f ("counter: add IRQ or GPIO based counter") Acked-by: Oleksij Rempel Link: https://lore.kernel.org/r/20250331163642.2382651-1-alexander.sverdlin@siemens.com Signed-off-by: William Breathitt Gray Signed-off-by: Sasha Levin commit f4d006a65aa5a8c9952bc0e2a579981712947445 Author: Yabin Cui Date: Tue Apr 29 16:13:00 2025 -0700 coresight: core: Disable helpers for devices that fail to enable [ Upstream commit f6028eeeb5e4cf86f93f805098c84974a79bba8a ] When enabling a SINK or LINK type coresight device fails, the associated helpers should be disabled. Fixes: 6148652807ba ("coresight: Enable and disable helper devices adjacent to the path") Signed-off-by: Yabin Cui Suggested-by: Suzuki K Poulose Reviewed-by: James Clark Reviewed-by: Mike Leach Reviewed-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250429231301.1952246-3-yabinc@google.com Signed-off-by: Sasha Levin commit d5f1bd703e485ed60389e296b4e7fd40d7bdfcc9 Author: Yabin Cui Date: Tue Apr 29 16:12:59 2025 -0700 coresight: catu: Introduce refcount and spinlock for enabling/disabling [ Upstream commit a03a0a08c6fe5e50c1b12ea41b9e228e7f649c22 ] When tracing ETM data on multiple CPUs concurrently via the perf interface, the CATU device is shared across different CPU paths. This can lead to race conditions when multiple CPUs attempt to enable or disable the CATU device simultaneously. To address these race conditions, this patch introduces the following changes: 1. The enable and disable operations for the CATU device are not reentrant. Therefore, a spinlock is added to ensure that only one CPU can enable or disable a given CATU device at any point in time. 2. A reference counter is used to manage the enable/disable state of the CATU device. The device is enabled when the first CPU requires it and is only disabled when the last CPU finishes using it. This ensures the device remains active as long as at least one CPU needs it. Fixes: fcacb5c154ba ("coresight: Introduce support for Coresight Address Translation Unit") Signed-off-by: Yabin Cui Reviewed-by: James Clark Reviewed-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250429231301.1952246-2-yabinc@google.com Signed-off-by: Sasha Levin commit bece2360488b24effcf1e33a09d95607c99d7a4f Author: Junhao He Date: Wed Sep 18 11:53:27 2024 +0800 coresight: Fixes device's owner field for registered using coresight_init_driver() [ Upstream commit 9f52aecc952ddf307571517d5c91136c8c4e87c9 ] The coresight_init_driver() of the coresight-core module is called from the sub coresgiht device (such as tmc/stm/funnle/...) module. It calls amba_driver_register() and Platform_driver_register(), which are macro functions that use the coresight-core's module to initialize the caller's owner field. Therefore, when the sub coresight device calls coresight_init_driver(), an incorrect THIS_MODULE value is captured. The sub coesgiht modules can be removed while their callbacks are running, resulting in a general protection failure. Add module parameter to coresight_init_driver() so can be called with the module of the callback. Fixes: 075b7cd7ad7d ("coresight: Add helpers registering/removing both AMBA and platform drivers") Signed-off-by: Junhao He Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20240918035327.9710-1-hejunhao3@huawei.com Signed-off-by: Sasha Levin commit 30aea6b925ec8995094c8dd7e1e3d8d0234f3cfe Author: WangYuli Date: Wed Apr 16 11:45:48 2025 +0800 MIPS: Loongson64: Add missing '#interrupt-cells' for loongson64c_ls7a [ Upstream commit 6d223b8ffcd1593d032b71875def2daa71c53111 ] Similar to commit 98a9e2ac3755 ("MIPS: Loongson64: DTS: Fix msi node for ls7a"). Fix follow warnings: arch/mips/boot/dts/loongson/loongson64c_4core_ls7a.dts:28.31-36.4: Warning (interrupt_provider): /bus@10000000/msi-controller@2ff00000: Missing '#interrupt-cells' in interrupt provider arch/mips/boot/dts/loongson/loongson64c_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider' Fixes: 24af105962c8 ("MIPS: Loongson64: DeviceTree for LS7A PCH") Tested-by: WangYuli Signed-off-by: WangYuli Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit e3d530173b70514d4390a94f9f979acad689b70a Author: Chenyuan Yang Date: Thu Apr 17 14:50:32 2025 -0500 usb: acpi: Prevent null pointer dereference in usb_acpi_add_usb4_devlink() [ Upstream commit 73fb0ec9436ae87bcae067ce35d6cdd72bade86c ] As demonstrated by the fix for update_port_device_state, commit 12783c0b9e2c ("usb: core: Prevent null pointer dereference in update_port_device_state"), usb_hub_to_struct_hub() can return NULL in certain scenarios, such as during hub driver unbind or teardown race conditions, even if the underlying usb_device structure exists. Plus, all other places that call usb_hub_to_struct_hub() in the same file do check for NULL return values. If usb_hub_to_struct_hub() returns NULL, the subsequent access to hub->ports[udev->portnum - 1] will cause a null pointer dereference. Signed-off-by: Chenyuan Yang Fixes: f1bfb4a6fed6 ("usb: acpi: add device link between tunneled USB3 device and USB4 Host Interface") Acked-by: Alan Stern Link: https://lore.kernel.org/r/20250417195032.1811338-1-chenyuan0y@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7fc479fb5ad219306dad9190131188fb2dcdea00 Author: Uwe Kleine-König Date: Mon Mar 17 12:52:47 2025 +0100 iio: adc: ad7124: Fix 3dB filter frequency reading [ Upstream commit 8712e4986e7ce42a14c762c4c350f290989986a5 ] The sinc4 filter has a factor 0.23 between Output Data Rate and f_{3dB} and for sinc3 the factor is 0.272 according to the data sheets for ad7124-4 (Rev. E.) and ad7124-8 (Rev. F). Fixes: cef2760954cf ("iio: adc: ad7124: add 3db filter") Signed-off-by: Uwe Kleine-König Reviewed-by: Marcelo Schmitt Link: https://patch.msgid.link/20250317115247.3735016-6-u.kleine-koenig@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit e13e663f884ada40128671f7e61dae2eb75fdb55 Author: Brian Pellegrino Date: Fri Mar 28 13:48:31 2025 -0400 iio: filter: admv8818: Support frequencies >= 2^32 [ Upstream commit 9016776f1301627de78a633bda7c898425a56572 ] This patch allows writing u64 values to the ADMV8818's high and low-pass filter frequencies. It includes the following changes: - Rejects negative frequencies in admv8818_write_raw. - Adds a write_raw_get_fmt function to admv8818's iio_info, returning IIO_VAL_INT_64 for the high and low-pass filter 3dB frequency channels. Fixes: f34fe888ad05 ("iio:filter:admv8818: add support for ADMV8818") Signed-off-by: Brian Pellegrino Signed-off-by: Sam Winchenbach Link: https://patch.msgid.link/20250328174831.227202-7-sam.winchenbach@framepointer.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 1e1cfb92e546ec8adb2c196876c8d8d2621b5db0 Author: Sam Winchenbach Date: Fri Mar 28 13:48:29 2025 -0400 iio: filter: admv8818: fix range calculation [ Upstream commit d542db7095d322bfcdc8e306db6f8c48358c9619 ] Search for the minimum error while ensuring that the LPF corner frequency is greater than the target, and the HPF corner frequency is lower than the target This fixes issues where the range calculations were suboptimal. Add two new DTS properties to set the margin between the input frequency and the calculated corner frequency Below is a generated table of the differences between the old algorithm and the new. This is a sweep from 0 to 20 GHz in 10 MHz steps. === HPF === freq = 1750 MHz, 3db: bypass => 1750 MHz freq = 3400 MHz, 3db: 3310 => 3400 MHz freq = 3410 MHz, 3db: 3310 => 3400 MHz freq = 3420 MHz, 3db: 3310 => 3400 MHz freq = 3660 MHz, 3db: 3550 => 3656 MHz freq = 6600 MHz, 3db: 6479 => 6600 MHz freq = 6610 MHz, 3db: 6479 => 6600 MHz freq = 6620 MHz, 3db: 6479 => 6600 MHz freq = 6630 MHz, 3db: 6479 => 6600 MHz freq = 6640 MHz, 3db: 6479 => 6600 MHz freq = 6650 MHz, 3db: 6479 => 6600 MHz freq = 6660 MHz, 3db: 6479 => 6600 MHz freq = 6670 MHz, 3db: 6479 => 6600 MHz freq = 6680 MHz, 3db: 6479 => 6600 MHz freq = 6690 MHz, 3db: 6479 => 6600 MHz freq = 6700 MHz, 3db: 6479 => 6600 MHz freq = 6710 MHz, 3db: 6479 => 6600 MHz freq = 6720 MHz, 3db: 6479 => 6600 MHz freq = 6730 MHz, 3db: 6479 => 6600 MHz freq = 6960 MHz, 3db: 6736 => 6960 MHz freq = 6970 MHz, 3db: 6736 => 6960 MHz freq = 6980 MHz, 3db: 6736 => 6960 MHz freq = 6990 MHz, 3db: 6736 => 6960 MHz freq = 7320 MHz, 3db: 7249 => 7320 MHz freq = 7330 MHz, 3db: 7249 => 7320 MHz freq = 7340 MHz, 3db: 7249 => 7320 MHz freq = 7350 MHz, 3db: 7249 => 7320 MHz freq = 7360 MHz, 3db: 7249 => 7320 MHz freq = 7370 MHz, 3db: 7249 => 7320 MHz freq = 7380 MHz, 3db: 7249 => 7320 MHz freq = 7390 MHz, 3db: 7249 => 7320 MHz freq = 7400 MHz, 3db: 7249 => 7320 MHz freq = 7410 MHz, 3db: 7249 => 7320 MHz freq = 7420 MHz, 3db: 7249 => 7320 MHz freq = 7430 MHz, 3db: 7249 => 7320 MHz freq = 7440 MHz, 3db: 7249 => 7320 MHz freq = 7450 MHz, 3db: 7249 => 7320 MHz freq = 7460 MHz, 3db: 7249 => 7320 MHz freq = 7470 MHz, 3db: 7249 => 7320 MHz freq = 7480 MHz, 3db: 7249 => 7320 MHz freq = 7490 MHz, 3db: 7249 => 7320 MHz freq = 7500 MHz, 3db: 7249 => 7320 MHz freq = 12500 MHz, 3db: 12000 => 12500 MHz === LPF === freq = 2050 MHz, 3db: bypass => 2050 MHz freq = 2170 MHz, 3db: 2290 => 2170 MHz freq = 2290 MHz, 3db: 2410 => 2290 MHz freq = 2410 MHz, 3db: 2530 => 2410 MHz freq = 2530 MHz, 3db: 2650 => 2530 MHz freq = 2650 MHz, 3db: 2770 => 2650 MHz freq = 2770 MHz, 3db: 2890 => 2770 MHz freq = 2890 MHz, 3db: 3010 => 2890 MHz freq = 3010 MHz, 3db: 3130 => 3010 MHz freq = 3130 MHz, 3db: 3250 => 3130 MHz freq = 3250 MHz, 3db: 3370 => 3250 MHz freq = 3260 MHz, 3db: 3370 => 3350 MHz freq = 3270 MHz, 3db: 3370 => 3350 MHz freq = 3280 MHz, 3db: 3370 => 3350 MHz freq = 3290 MHz, 3db: 3370 => 3350 MHz freq = 3300 MHz, 3db: 3370 => 3350 MHz freq = 3310 MHz, 3db: 3370 => 3350 MHz freq = 3320 MHz, 3db: 3370 => 3350 MHz freq = 3330 MHz, 3db: 3370 => 3350 MHz freq = 3340 MHz, 3db: 3370 => 3350 MHz freq = 3350 MHz, 3db: 3370 => 3350 MHz freq = 3370 MHz, 3db: 3490 => 3370 MHz freq = 3490 MHz, 3db: 3610 => 3490 MHz freq = 3610 MHz, 3db: 3730 => 3610 MHz freq = 3730 MHz, 3db: 3850 => 3730 MHz freq = 3850 MHz, 3db: 3870 => 3850 MHz freq = 3870 MHz, 3db: 4130 => 3870 MHz freq = 4130 MHz, 3db: 4390 => 4130 MHz freq = 4390 MHz, 3db: 4650 => 4390 MHz freq = 4650 MHz, 3db: 4910 => 4650 MHz freq = 4910 MHz, 3db: 5170 => 4910 MHz freq = 5170 MHz, 3db: 5430 => 5170 MHz freq = 5430 MHz, 3db: 5690 => 5430 MHz freq = 5690 MHz, 3db: 5950 => 5690 MHz freq = 5950 MHz, 3db: 6210 => 5950 MHz freq = 6210 MHz, 3db: 6470 => 6210 MHz freq = 6470 MHz, 3db: 6730 => 6470 MHz freq = 6730 MHz, 3db: 6990 => 6730 MHz freq = 6990 MHz, 3db: 7250 => 6990 MHz freq = 7000 MHz, 3db: 7250 => 7000 MHz freq = 7250 MHz, 3db: 7400 => 7250 MHz freq = 7400 MHz, 3db: 7800 => 7400 MHz freq = 7800 MHz, 3db: 8200 => 7800 MHz freq = 8200 MHz, 3db: 8600 => 8200 MHz freq = 8600 MHz, 3db: 9000 => 8600 MHz freq = 9000 MHz, 3db: 9400 => 9000 MHz freq = 9400 MHz, 3db: 9800 => 9400 MHz freq = 9800 MHz, 3db: 10200 => 9800 MHz freq = 10200 MHz, 3db: 10600 => 10200 MHz freq = 10600 MHz, 3db: 11000 => 10600 MHz freq = 11000 MHz, 3db: 11400 => 11000 MHz freq = 11400 MHz, 3db: 11800 => 11400 MHz freq = 11800 MHz, 3db: 12200 => 11800 MHz freq = 12200 MHz, 3db: 12600 => 12200 MHz freq = 12210 MHz, 3db: 12600 => 12550 MHz freq = 12220 MHz, 3db: 12600 => 12550 MHz freq = 12230 MHz, 3db: 12600 => 12550 MHz freq = 12240 MHz, 3db: 12600 => 12550 MHz freq = 12250 MHz, 3db: 12600 => 12550 MHz freq = 12260 MHz, 3db: 12600 => 12550 MHz freq = 12270 MHz, 3db: 12600 => 12550 MHz freq = 12280 MHz, 3db: 12600 => 12550 MHz freq = 12290 MHz, 3db: 12600 => 12550 MHz freq = 12300 MHz, 3db: 12600 => 12550 MHz freq = 12310 MHz, 3db: 12600 => 12550 MHz freq = 12320 MHz, 3db: 12600 => 12550 MHz freq = 12330 MHz, 3db: 12600 => 12550 MHz freq = 12340 MHz, 3db: 12600 => 12550 MHz freq = 12350 MHz, 3db: 12600 => 12550 MHz freq = 12360 MHz, 3db: 12600 => 12550 MHz freq = 12370 MHz, 3db: 12600 => 12550 MHz freq = 12380 MHz, 3db: 12600 => 12550 MHz freq = 12390 MHz, 3db: 12600 => 12550 MHz freq = 12400 MHz, 3db: 12600 => 12550 MHz freq = 12410 MHz, 3db: 12600 => 12550 MHz freq = 12420 MHz, 3db: 12600 => 12550 MHz freq = 12430 MHz, 3db: 12600 => 12550 MHz freq = 12440 MHz, 3db: 12600 => 12550 MHz freq = 12450 MHz, 3db: 12600 => 12550 MHz freq = 12460 MHz, 3db: 12600 => 12550 MHz freq = 12470 MHz, 3db: 12600 => 12550 MHz freq = 12480 MHz, 3db: 12600 => 12550 MHz freq = 12490 MHz, 3db: 12600 => 12550 MHz freq = 12500 MHz, 3db: 12600 => 12550 MHz freq = 12510 MHz, 3db: 12600 => 12550 MHz freq = 12520 MHz, 3db: 12600 => 12550 MHz freq = 12530 MHz, 3db: 12600 => 12550 MHz freq = 12540 MHz, 3db: 12600 => 12550 MHz freq = 12550 MHz, 3db: 12600 => 12550 MHz freq = 12600 MHz, 3db: 13000 => 12600 MHz freq = 12610 MHz, 3db: 13000 => 12970 MHz freq = 12620 MHz, 3db: 13000 => 12970 MHz freq = 12630 MHz, 3db: 13000 => 12970 MHz freq = 12640 MHz, 3db: 13000 => 12970 MHz freq = 12650 MHz, 3db: 13000 => 12970 MHz freq = 12660 MHz, 3db: 13000 => 12970 MHz freq = 12670 MHz, 3db: 13000 => 12970 MHz freq = 12680 MHz, 3db: 13000 => 12970 MHz freq = 12690 MHz, 3db: 13000 => 12970 MHz freq = 12700 MHz, 3db: 13000 => 12970 MHz freq = 12710 MHz, 3db: 13000 => 12970 MHz freq = 12720 MHz, 3db: 13000 => 12970 MHz freq = 12730 MHz, 3db: 13000 => 12970 MHz freq = 12740 MHz, 3db: 13000 => 12970 MHz freq = 12750 MHz, 3db: 13000 => 12970 MHz freq = 12760 MHz, 3db: 13000 => 12970 MHz freq = 12770 MHz, 3db: 13000 => 12970 MHz freq = 12780 MHz, 3db: 13000 => 12970 MHz freq = 12790 MHz, 3db: 13000 => 12970 MHz freq = 12800 MHz, 3db: 13000 => 12970 MHz freq = 12810 MHz, 3db: 13000 => 12970 MHz freq = 12820 MHz, 3db: 13000 => 12970 MHz freq = 12830 MHz, 3db: 13000 => 12970 MHz freq = 12840 MHz, 3db: 13000 => 12970 MHz freq = 12850 MHz, 3db: 13000 => 12970 MHz freq = 12860 MHz, 3db: 13000 => 12970 MHz freq = 12870 MHz, 3db: 13000 => 12970 MHz freq = 12880 MHz, 3db: 13000 => 12970 MHz freq = 12890 MHz, 3db: 13000 => 12970 MHz freq = 12900 MHz, 3db: 13000 => 12970 MHz freq = 12910 MHz, 3db: 13000 => 12970 MHz freq = 12920 MHz, 3db: 13000 => 12970 MHz freq = 12930 MHz, 3db: 13000 => 12970 MHz freq = 12940 MHz, 3db: 13000 => 12970 MHz freq = 12950 MHz, 3db: 13000 => 12970 MHz freq = 12960 MHz, 3db: 13000 => 12970 MHz freq = 12970 MHz, 3db: 13000 => 12970 MHz freq = 13000 MHz, 3db: 13390 => 13000 MHz freq = 13390 MHz, 3db: 13810 => 13390 MHz freq = 13810 MHz, 3db: 14230 => 13810 MHz freq = 14230 MHz, 3db: 14650 => 14230 MHz freq = 14650 MHz, 3db: 15070 => 14650 MHz freq = 15070 MHz, 3db: 15490 => 15070 MHz freq = 15490 MHz, 3db: 15910 => 15490 MHz freq = 15910 MHz, 3db: 16330 => 15910 MHz freq = 16330 MHz, 3db: 16750 => 16330 MHz freq = 16750 MHz, 3db: 17170 => 16750 MHz freq = 17170 MHz, 3db: 17590 => 17170 MHz freq = 17590 MHz, 3db: 18010 => 17590 MHz freq = 18010 MHz, 3db: 18430 => 18010 MHz freq = 18430 MHz, 3db: 18850 => 18430 MHz freq = 18850 MHz, 3db: bypass => 18850 MHz Fixes: f34fe888ad05 ("iio:filter:admv8818: add support for ADMV8818") Signed-off-by: Sam Winchenbach Link: https://patch.msgid.link/20250328174831.227202-5-sam.winchenbach@framepointer.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 35e5c0cc4dfdcca31727ea264754115a1c6060fd Author: Sam Winchenbach Date: Fri Mar 28 13:48:28 2025 -0400 iio: filter: admv8818: fix integer overflow [ Upstream commit fb6009a28d77edec4eb548b5875dae8c79b88467 ] HZ_PER_MHZ is only unsigned long. This math overflows, leading to incorrect results. Fixes: f34fe888ad05 ("iio:filter:admv8818: add support for ADMV8818") Signed-off-by: Sam Winchenbach Link: https://patch.msgid.link/20250328174831.227202-4-sam.winchenbach@framepointer.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 900bf5135aa8e0f9b4385fe80c363902b2907777 Author: Sam Winchenbach Date: Fri Mar 28 13:48:27 2025 -0400 iio: filter: admv8818: fix band 4, state 15 [ Upstream commit ef0ce24f590ac075d5eda11f2d6434b303333ed6 ] Corrects the upper range of LPF Band 4 from 18.5 GHz to 18.85 GHz per the ADMV8818 datasheet Fixes: f34fe888ad05 ("iio:filter:admv8818: add support for ADMV8818") Signed-off-by: Sam Winchenbach Link: https://patch.msgid.link/20250328174831.227202-3-sam.winchenbach@framepointer.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit d2ef2fac35b6140fcdff0d26b6194780240538e2 Author: Mario Limonciello Date: Fri Apr 11 10:14:44 2025 -0500 thunderbolt: Fix a logic error in wake on connect [ Upstream commit 1a760d10ded372d113a0410c42be246315bbc2ff ] commit a5cfc9d65879c ("thunderbolt: Add wake on connect/disconnect on USB4 ports") introduced a sysfs file to control wake up policy for a given USB4 port that defaulted to disabled. However when testing commit 4bfeea6ec1c02 ("thunderbolt: Use wake on connect and disconnect over suspend") I found that it was working even without making changes to the power/wakeup file (which defaults to disabled). This is because of a logic error doing a bitwise or of the wake-on-connect flag with device_may_wakeup() which should have been a logical AND. Adjust the logic so that policy is only applied when wakeup is actually enabled. Fixes: a5cfc9d65879c ("thunderbolt: Add wake on connect/disconnect on USB4 ports") Signed-off-by: Mario Limonciello Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit e1b144aebe6fb898d96ced8c990d7aa38fda4a7a Author: Henry Martin Date: Thu Apr 3 15:03:39 2025 +0800 serial: Fix potential null-ptr-deref in mlb_usio_probe() [ Upstream commit 86bcae88c9209e334b2f8c252f4cc66beb261886 ] devm_ioremap() can return NULL on error. Currently, mlb_usio_probe() does not check for this case, which could result in a NULL pointer dereference. Add NULL check after devm_ioremap() to prevent this issue. Fixes: ba44dc043004 ("serial: Add Milbeaut serial control") Signed-off-by: Henry Martin Link: https://lore.kernel.org/r/20250403070339.64990-1-bsdhenrymartin@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6bab152e817fd41b9e178fa6b275354795c9703d Author: Lad Prabhakar Date: Mon Apr 7 11:50:02 2025 +0100 usb: renesas_usbhs: Reorder clock handling and power management in probe [ Upstream commit ffb34a60ce86656ba12d46e91f1ccc71dd221251 ] Reorder the initialization sequence in `usbhs_probe()` to enable runtime PM before accessing registers, preventing potential crashes due to uninitialized clocks. Currently, in the probe path, registers are accessed before enabling the clocks, leading to a synchronous external abort on the RZ/V2H SoC. The problematic call flow is as follows: usbhs_probe() usbhs_sys_clock_ctrl() usbhs_bset() usbhs_write() iowrite16() <-- Register access before enabling clocks Since `iowrite16()` is performed without ensuring the required clocks are enabled, this can lead to access errors. To fix this, enable PM runtime early in the probe function and ensure clocks are acquired before register access, preventing crashes like the following on RZ/V2H: [13.272640] Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP [13.280814] Modules linked in: cec renesas_usbhs(+) drm_kms_helper fuse drm backlight ipv6 [13.289088] CPU: 1 UID: 0 PID: 195 Comm: (udev-worker) Not tainted 6.14.0-rc7+ #98 [13.296640] Hardware name: Renesas RZ/V2H EVK Board based on r9a09g057h44 (DT) [13.303834] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [13.310770] pc : usbhs_bset+0x14/0x4c [renesas_usbhs] [13.315831] lr : usbhs_probe+0x2e4/0x5ac [renesas_usbhs] [13.321138] sp : ffff8000827e3850 [13.324438] x29: ffff8000827e3860 x28: 0000000000000000 x27: ffff8000827e3ca0 [13.331554] x26: ffff8000827e3ba0 x25: ffff800081729668 x24: 0000000000000025 [13.338670] x23: ffff0000c0f08000 x22: 0000000000000000 x21: ffff0000c0f08010 [13.345783] x20: 0000000000000000 x19: ffff0000c3b52080 x18: 00000000ffffffff [13.352895] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000827e36ce [13.360009] x14: 00000000000003d7 x13: 00000000000003d7 x12: 0000000000000000 [13.367122] x11: 0000000000000000 x10: 0000000000000aa0 x9 : ffff8000827e3750 [13.374235] x8 : ffff0000c1850b00 x7 : 0000000003826060 x6 : 000000000000001c [13.381347] x5 : 000000030d5fcc00 x4 : ffff8000825c0000 x3 : 0000000000000000 [13.388459] x2 : 0000000000000400 x1 : 0000000000000000 x0 : ffff0000c3b52080 [13.395574] Call trace: [13.398013] usbhs_bset+0x14/0x4c [renesas_usbhs] (P) [13.403076] platform_probe+0x68/0xdc [13.406738] really_probe+0xbc/0x2c0 [13.410306] __driver_probe_device+0x78/0x120 [13.414653] driver_probe_device+0x3c/0x154 [13.418825] __driver_attach+0x90/0x1a0 [13.422647] bus_for_each_dev+0x7c/0xe0 [13.426470] driver_attach+0x24/0x30 [13.430032] bus_add_driver+0xe4/0x208 [13.433766] driver_register+0x68/0x130 [13.437587] __platform_driver_register+0x24/0x30 [13.442273] renesas_usbhs_driver_init+0x20/0x1000 [renesas_usbhs] [13.448450] do_one_initcall+0x60/0x1d4 [13.452276] do_init_module+0x54/0x1f8 [13.456014] load_module+0x1754/0x1c98 [13.459750] init_module_from_file+0x88/0xcc [13.464004] __arm64_sys_finit_module+0x1c4/0x328 [13.468689] invoke_syscall+0x48/0x104 [13.472426] el0_svc_common.constprop.0+0xc0/0xe0 [13.477113] do_el0_svc+0x1c/0x28 [13.480415] el0_svc+0x30/0xcc [13.483460] el0t_64_sync_handler+0x10c/0x138 [13.487800] el0t_64_sync+0x198/0x19c [13.491453] Code: 2a0103e1 12003c42 12003c63 8b010084 (79400084) [13.497522] ---[ end trace 0000000000000000 ]--- Fixes: f1407d5c66240 ("usb: renesas_usbhs: Add Renesas USBHS common code") Signed-off-by: Lad Prabhakar Reviewed-by: Yoshihiro Shimoda Tested-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20250407105002.107181-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9219079c52821246b2395bd30a4a2ffb9681e9e6 Author: Andrea Righi Date: Tue Jun 3 10:22:01 2025 +0200 sched_ext: idle: Skip cross-node search with !CONFIG_NUMA [ Upstream commit 9960be72a54cf0e4d47abdd4cacd1278835a3bb4 ] In the idle CPU selection logic, attempting cross-node searches adds unnecessary complexity when CONFIG_NUMA is disabled. Since there's no meaningful concept of nodes in this case, simplify the logic by restricting the idle CPU search to the current node only. Fixes: 48849271e6611 ("sched_ext: idle: Per-node idle cpumasks") Signed-off-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 55ebe901711323eebde8ccf983b4330bf2b7517b Author: Jerome Brunet Date: Thu Apr 24 10:34:04 2025 +0200 PCI: endpoint: Retain fixed-size BAR size as well as aligned size [ Upstream commit 793908d60b8745c386b9f4e29eb702f74ceb0886 ] When allocating space for an endpoint function on a BAR with a fixed size, the size saved in 'struct pci_epf_bar.size' should be the fixed size as expected by pci_epc_set_bar(). However, if pci_epf_alloc_space() increased the allocation size to accommodate iATU alignment requirements, it previously saved the larger aligned size in .size, which broke pci_epc_set_bar(). To solve this, keep the fixed BAR size in .size and save the aligned size in a new .aligned_size for use when deallocating it. Fixes: 2a9a801620ef ("PCI: endpoint: Add support to specify alignment for buffers allocated to BARs") Signed-off-by: Jerome Brunet [mani: commit message fixup] Signed-off-by: Manivannan Sadhasivam [bhelgaas: more specific subject, commit log, wrap comment to match file] Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20250424-pci-ep-size-alignment-v5-1-2d4ec2af23f5@baylibre.com Signed-off-by: Sasha Levin commit 99155d36a3ddf46cb5b48b974d95d5b49daef224 Author: Miguel Ojeda Date: Mon Mar 24 22:03:54 2025 +0100 rust: pci: fix docs related to missing Markdown code spans [ Upstream commit 1dbaf8b1bafb8557904eb54b98bb323a3061dd2c ] In particular: - Add missing Markdown code spans. - Improve title for `DeviceId`, adding a link to the struct in the C side, rather than referring to `bindings::`. - Convert `TODO` from documentation to a normal comment, and put code in block. This was found using the Clippy `doc_markdown` lint, which we may want to enable. Fixes: 1bd8b6b2c5d3 ("rust: pci: add basic PCI device / driver abstractions") Reviewed-by: Benno Lossin Acked-by: Danilo Krummrich Link: https://lore.kernel.org/r/20250324210359.1199574-8-ojeda@kernel.org [ Prefixed link text with `struct`. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit f8ca072c3e2d9808d1a7c3317b4777a13f001bc2 Author: Liu Dalin Date: Fri May 9 16:44:16 2025 +0800 rtc: loongson: Add missing alarm notifications for ACPI RTC events [ Upstream commit 5af9f1fa576874b24627d4c05e3a84672204c200 ] When an application sets and enables an alarm on Loongson RTC devices, the alarm notification fails to propagate to userspace because the ACPI event handler omits calling rtc_update_irq(). As a result, processes waiting via select() or poll() on RTC device files fail to receive alarm notifications. The ACPI interrupt is also triggered multiple times. In loongson_rtc_handler, we need to clear TOY_MATCH0_REG to resolve this issue. Fixes: 09471d8f5b39 ("rtc: loongson: clear TOY_MATCH0_REG in loongson_rtc_isr()") Fixes: 1b733a9ebc3d ("rtc: Add rtc driver for the Loongson family chips") Signed-off-by: Liu Dalin Reviewed-by: Binbin Zhou Link: https://lore.kernel.org/r/20250509084416.7979-1-liudalin@kylinsec.com.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit b3ad6d23fec23fbef382ce9ea640c37446593cf5 Author: Brian Norris Date: Wed Apr 9 11:53:13 2025 -0700 PCI/pwrctrl: Cancel outstanding rescan work when unregistering [ Upstream commit 8b926f237743f020518162c62b93cb7107a2b5eb ] It's possible to trigger use-after-free here by: (a) forcing rescan_work_func() to take a long time and (b) utilizing a pwrctrl driver that may be unloaded for some reason Cancel outstanding work to ensure it is finished before we allow our data structures to be cleaned up. [bhelgaas: tidy commit log] Fixes: 8f62819aaace ("PCI/pwrctl: Rescan bus on a separate thread") Signed-off-by: Brian Norris Signed-off-by: Brian Norris Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Acked-by: Bartosz Golaszewski Cc: Konrad Dybcio Link: https://patch.msgid.link/20250409115313.1.Ia319526ed4ef06bec3180378c9a008340cec9658@changeid Signed-off-by: Sasha Levin commit 4e0abf270c62cb5c6e2bf6ea4c599b56b457354f Author: Bjorn Helgaas Date: Thu May 22 18:21:08 2025 -0500 PCI/DPC: Log Error Source ID only when valid [ Upstream commit a0b62cc310239c7f1323fb20bd3789f21bdd8615 ] DPC Error Source ID is only valid when the DPC Trigger Reason indicates that DPC was triggered due to reception of an ERR_NONFATAL or ERR_FATAL Message (PCIe r6.0, sec 7.9.14.5). When DPC was triggered by ERR_NONFATAL (PCI_EXP_DPC_STATUS_TRIGGER_RSN_NFE) or ERR_FATAL (PCI_EXP_DPC_STATUS_TRIGGER_RSN_FE) from a downstream device, log the Error Source ID (decoded into domain/bus/device/function). Don't print the source otherwise, since it's not valid. For DPC trigger due to reception of ERR_NONFATAL or ERR_FATAL, the dmesg logging changes: - pci 0000:00:01.0: DPC: containment event, status:0x000d source:0x0200 - pci 0000:00:01.0: DPC: ERR_FATAL detected + pci 0000:00:01.0: DPC: containment event, status:0x000d, ERR_FATAL received from 0000:02:00.0 and when DPC triggered for other reasons, where DPC Error Source ID is undefined, e.g., unmasked uncorrectable error: - pci 0000:00:01.0: DPC: containment event, status:0x0009 source:0x0200 - pci 0000:00:01.0: DPC: unmasked uncorrectable error detected + pci 0000:00:01.0: DPC: containment event, status:0x0009: unmasked uncorrectable error detected Previously the "containment event" message was at KERN_INFO and the "%s detected" message was at KERN_WARNING. Now the single message is at KERN_WARNING. Fixes: 26e515713342 ("PCI: Add Downstream Port Containment driver") Signed-off-by: Bjorn Helgaas Tested-by: Krzysztof Wilczyński Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Jonathan Cameron Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/20250522232339.1525671-3-helgaas@kernel.org Signed-off-by: Sasha Levin commit 2d50d734cad39c1fcf115520f72285aee63a3228 Author: Bjorn Helgaas Date: Thu May 22 18:21:07 2025 -0500 PCI/DPC: Initialize aer_err_info before using it [ Upstream commit a424b598e6a6c1e69a2bb801d6fd16e805ab2c38 ] Previously the struct aer_err_info "info" was allocated on the stack without being initialized, so it contained junk except for the fields we explicitly set later. Initialize "info" at declaration so it starts as all zeros. Fixes: 8aefa9b0d910 ("PCI/DPC: Print AER status in DPC event handling") Signed-off-by: Bjorn Helgaas Tested-by: Krzysztof Wilczyński Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Ilpo Järvinen Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20250522232339.1525671-2-helgaas@kernel.org Signed-off-by: Sasha Levin commit d9470e94f1511b0b592d6d669089c871072d0df7 Author: Zhe Qiao Date: Wed Apr 30 14:06:03 2025 +0800 PCI/ACPI: Fix allocated memory release on error in pci_acpi_scan_root() [ Upstream commit 631b2af2f35737750af284be22e63da56bf20139 ] In the pci_acpi_scan_root() function, when creating a PCI bus fails, we need to free up the previously allocated memory, which can avoid invalid memory usage and save resources. Fixes: 789befdfa389 ("arm64: PCI: Migrate ACPI related functions to pci-acpi.c") Signed-off-by: Zhe Qiao [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Acked-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20250430060603.381504-1-qiaozhe@iscas.ac.cn Signed-off-by: Sasha Levin commit 643db430f4cbd91dd2b63c49d62d0abb6debc13b Author: Henry Martin Date: Wed Apr 2 10:39:00 2025 +0800 dmaengine: ti: Add NULL check in udma_probe() [ Upstream commit fd447415e74bccd7362f760d4ea727f8e1ebfe91 ] devm_kasprintf() returns NULL when memory allocation fails. Currently, udma_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: 25dcb5dd7b7c ("dmaengine: ti: New driver for K3 UDMA") Signed-off-by: Henry Martin Reviewed-by: Nathan Lynch Acked-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20250402023900.43440-1-bsdhenrymartin@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ce841128837fff4da55c63447bbdee196f38aab0 Author: Bard Liao Date: Thu May 8 14:20:29 2025 +0800 soundwire: only compute port params in specific stream states [ Upstream commit 62ada17a6217a50fbd1b23f10899890f56effc97 ] Currently, sdw_compute_master_ports() is blindly called for every single Manager runtime. However, we should not take into account the stream's bandwidth if the stream is just allocated or already deprepared. Fixes: 25befdf32aa4 ("soundwire: generic_bandwidth_allocation: count the bandwidth of active streams only") Link: https://github.com/thesofproject/linux/issues/5398 Signed-off-by: Bard Liao Reviewed-by: Ranjani Sridharan Reviewed-by: Péter Ujfalusi Link: https://lore.kernel.org/r/20250508062029.6596-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f006ad318fa7c52c3daa978a04a8782f3dc6f2da Author: Kathiravan Thirumoorthy Date: Tue Apr 15 09:52:51 2025 +0530 phy: qcom-qusb2: reuse the IPQ6018 settings for IPQ5424 [ Upstream commit 25c36b54eafc98b3ef004e2037cea1328d9b8bc5 ] With the settings used in the commit 9c56a1de296e ("phy: qcom-qusb2: add QUSB2 support for IPQ5424"), compliance test cases especially eye-diagram (Host High-speed Signal Quality) tests are failing. Reuse the IPQ6018 settings for IPQ5424 as mentioned in the Hardware Design Document which helps to meet all the complaince requirement test cases. Fixes: 9c56a1de296e ("phy: qcom-qusb2: add QUSB2 support for IPQ5424") Signed-off-by: Kathiravan Thirumoorthy Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250415-revert_hs_phy_settings-v3-2-3a8f86211b59@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 1ec47c5f3cb2d475828754f7b751c40e465b8d69 Author: Kathiravan Thirumoorthy Date: Tue Apr 15 09:52:50 2025 +0530 Revert "phy: qcom-qusb2: add QUSB2 support for IPQ5424" [ Upstream commit 8a040e13afd94a1f91acaf8e0505769d4f7f5af4 ] With the current settings, compliance tests especially eye diagram (Host High-speed Signal Quality) tests are failing. Reuse the IPQ6018 settings to overcome this issue, as mentioned in the Hardware Design Document. So revert the change which introduced the new settings and reuse the IPQ6018 settings in the subsequent patch. Fixes: 9c56a1de296e ("phy: qcom-qusb2: add QUSB2 support for IPQ5424") Signed-off-by: Kathiravan Thirumoorthy Link: https://lore.kernel.org/r/20250415-revert_hs_phy_settings-v3-1-3a8f86211b59@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 0c33117f00c8c5363c22676931b22ae5041f7603 Author: Chenyuan Yang Date: Mon Apr 14 07:50:50 2025 -0500 phy: qcom-qmp-usb: Fix an NULL vs IS_ERR() bug [ Upstream commit d14402a38c2d868cacb1facaf9be908ca6558e59 ] The qmp_usb_iomap() helper function currently returns the raw result of devm_ioremap() for non-exclusive mappings. Since devm_ioremap() may return a NULL pointer and the caller only checks error pointers with IS_ERR(), NULL could bypass the check and lead to an invalid dereference. Fix the issue by checking if devm_ioremap() returns NULL. When it does, qmp_usb_iomap() now returns an error pointer via IOMEM_ERR_PTR(-ENOMEM), ensuring safe and consistent error handling. Signed-off-by: Chenyuan Yang Fixes: a5d6b1ac56cb ("phy: qcom-qmp-usb: fix memleak on probe deferral") CC: Johan Hovold CC: Krzysztof Kozlowski Reviewed-by: Johan Hovold Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250414125050.2118619-1-chenyuan0y@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c7686afd37c93c7d26221ad70e5e43b3fd01505a Author: Richard Zhu Date: Wed Apr 16 16:13:14 2025 +0800 PCI: imx6: Save and restore the LUT setting during suspend/resume for i.MX95 SoC [ Upstream commit e4d66131caaf18d7c3c69914513f4be0519ddaaf ] The look up table (LUT) setting would be lost during the PCIe suspend on i.MX95 SoC. So to ensure proper functionality after resume, save it during suspend and restore it while resuming. Fixes: 9d6b1bd6b3c8 ("PCI: imx6: Add i.MX8MQ, i.MX8Q and i.MX95 PM support") Signed-off-by: Richard Zhu [mani: subject and description rewording] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20250416081314.3929794-8-hongxing.zhu@nxp.com Signed-off-by: Sasha Levin commit 16c529aac3270f60597f01153f3779e0c7b7fab0 Author: Hector Martin Date: Tue Apr 1 10:17:11 2025 +0100 PCI: apple: Use gpiod_set_value_cansleep in probe flow [ Upstream commit 7334364f9de79a9a236dd0243ba574b8d2876e89 ] We're allowed to sleep here, so tell the GPIO core by using gpiod_set_value_cansleep instead of gpiod_set_value. Fixes: 1e33888fbe44 ("PCI: apple: Add initial hardware bring-up") Signed-off-by: Hector Martin Signed-off-by: Alyssa Rosenzweig Signed-off-by: Marc Zyngier Signed-off-by: Manivannan Sadhasivam Tested-by: Janne Grunau Reviewed-by: Rob Herring (Arm) Reviewed-by: Manivannan Sadhasivam Acked-by: Alyssa Rosenzweig Link: https://patch.msgid.link/20250401091713.2765724-12-maz@kernel.org Signed-off-by: Sasha Levin commit f8fc38df71cf43208a5c0d9d50244506cdd59be3 Author: Hans Zhang <18255117159@163.com> Date: Sat Apr 19 21:30:58 2025 +0800 PCI: cadence: Fix runtime atomic count underflow [ Upstream commit 8805f32a96d3b97cef07999fa6f52112678f7e65 ] If the call to pci_host_probe() in cdns_pcie_host_setup() fails, PM runtime count is decremented in the error path using pm_runtime_put_sync(). But the runtime count is not incremented by this driver, but only by the callers (cdns_plat_pcie_probe/j721e_pcie_probe). And the callers also decrement the runtime PM count in their error path. So this leads to the below warning from the PM core: "runtime PM usage count underflow!" So fix it by getting rid of pm_runtime_put_sync() in the error path and directly return the errno. Fixes: 49e427e6bdd1 ("Merge branch 'pci/host-probe-refactor'") Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20250419133058.162048-1-18255117159@163.com Signed-off-by: Sasha Levin commit 5448c2f6b1cad0f38c90ffd5494b8aa4a570edc7 Author: Jerome Brunet Date: Fri Mar 28 15:30:44 2025 +0100 PCI: rcar-gen4: set ep BAR4 fixed size [ Upstream commit b584ab12d59f646b9254b2b16ff197d612fd4935 ] On rcar-gen4, the ep BAR4 has a fixed size of 256B. Document this constraint in the epc features of the platform. Fixes: e311b3834dfa ("PCI: rcar-gen4: Add endpoint mode support") Signed-off-by: Jerome Brunet Signed-off-by: Manivannan Sadhasivam Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20250328-rcar-gen4-bar4-v1-1-10bb6ce9ee7f@baylibre.com Signed-off-by: Sasha Levin commit 17844456ebee8aff13ab14c1f9e1ff56573e4fb7 Author: Jensen Huang Date: Fri Mar 28 18:58:22 2025 +0800 PCI: rockchip: Fix order of rockchip_pci_core_rsts [ Upstream commit c7540e5423d7f588c7210a9941ceb6a836963ccc ] The order of rockchip_pci_core_rsts introduced in the offending commit followed the previous comment that warned not to reorder them. But the commit failed to take into account that reset_control_bulk_deassert() deasserts the resets in reverse order. So this leads to the link getting downgraded to 2.5 GT/s. Hence, restore the deassert order and also add back the comments for rockchip_pci_core_rsts. Tested on NanoPC-T4 with Samsung 970 Pro. Fixes: 18715931a5c0 ("PCI: rockchip: Simplify reset control handling by using reset_control_bulk*() function") Signed-off-by: Jensen Huang [mani: reworded the commit message and the comment above rockchip_pci_core_rsts] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Manivannan Sadhasivam Acked-by: Shawn Lin Link: https://patch.msgid.link/20250328105822.3946767-1-jensenhuang@friendlyarm.com Signed-off-by: Sasha Levin commit 33d2596e6e46d96406c80c0931f3cfae23e5d6f9 Author: Wilfred Mallawa Date: Mon Apr 14 10:15:06 2025 +1000 PCI: Print the actual delay time in pci_bridge_wait_for_secondary_bus() [ Upstream commit d24eba726aadf8778f2907dd42281c6380b0ccaa ] Print the delay amount that pcie_wait_for_link_delay() is invoked with instead of the hardcoded 1000ms value in the debug info print. Fixes: 7b3ba09febf4 ("PCI/PM: Shorten pci_bridge_wait_for_secondary_bus() wait time for slow links") Signed-off-by: Wilfred Mallawa Signed-off-by: Bjorn Helgaas Reviewed-by: Damien Le Moal Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Mika Westerberg Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/20250414001505.21243-2-wilfred.opensource@gmail.com Signed-off-by: Sasha Levin commit 9d684cbe9cb6addf2fe29695b1541c3e5493b8ab Author: Lukas Wunner Date: Thu Apr 10 17:27:12 2025 +0200 PCI: pciehp: Ignore Link Down/Up caused by Secondary Bus Reset [ Upstream commit 2af781a9edc4ef5f6684c0710cc3542d9be48b31 ] When a Secondary Bus Reset is issued at a hotplug port, it causes a Data Link Layer State Changed event as a side effect. On hotplug ports using in-band presence detect, it additionally causes a Presence Detect Changed event. These spurious events should not result in teardown and re-enumeration of the device in the slot. Hence commit 2e35afaefe64 ("PCI: pciehp: Add reset_slot() method") masked the Presence Detect Changed Enable bit in the Slot Control register during a Secondary Bus Reset. Commit 06a8d89af551 ("PCI: pciehp: Disable link notification across slot reset") additionally masked the Data Link Layer State Changed Enable bit. However masking those bits only disables interrupt generation (PCIe r6.2 sec 6.7.3.1). The events are still visible in the Slot Status register and picked up by the IRQ handler if it runs during a Secondary Bus Reset. This can happen if the interrupt is shared or if an unmasked hotplug event occurs, e.g. Attention Button Pressed or Power Fault Detected. The likelihood of this happening used to be small, so it wasn't much of a problem in practice. That has changed with the recent introduction of bandwidth control in v6.13-rc1 with commit 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller"): Bandwidth control shares the interrupt with PCIe hotplug. A Secondary Bus Reset causes a Link Bandwidth Notification, so the hotplug IRQ handler runs, picks up the masked events and tears down the device in the slot. As a result, Joel reports VFIO passthrough failure of a GPU, which Ilpo root-caused to the incorrect handling of masked hotplug events. Clearly, a more reliable way is needed to ignore spurious hotplug events. For Downstream Port Containment, a new ignore mechanism was introduced by commit a97396c6eb13 ("PCI: pciehp: Ignore Link Down/Up caused by DPC"). It has been working reliably for the past four years. Adapt it for Secondary Bus Resets. Introduce two helpers to annotate code sections which cause spurious link changes: pci_hp_ignore_link_change() and pci_hp_unignore_link_change() Use those helpers in lieu of masking interrupts in the Slot Control register. Introduce a helper to check whether such a code section is executing concurrently and if so, await it: pci_hp_spurious_link_change() Invoke the helper in the hotplug IRQ thread pciehp_ist(). Re-use the IRQ thread's existing code which ignores DPC-induced link changes unless the link is unexpectedly down after reset recovery or the device was replaced during the bus reset. That code block in pciehp_ist() was previously only executed if a Data Link Layer State Changed event has occurred. Additionally execute it for Presence Detect Changed events. That's necessary for compatibility with PCIe r1.0 hotplug ports because Data Link Layer State Changed didn't exist before PCIe r1.1. DPC was added with PCIe r3.1 and thus DPC-capable hotplug ports always support Data Link Layer State Changed events. But the same cannot be assumed for Secondary Bus Reset, which already existed in PCIe r1.0. Secondary Bus Reset is only one of many causes of spurious link changes. Others include runtime suspend to D3cold, firmware updates or FPGA reconfiguration. The new pci_hp_{,un}ignore_link_change() helpers may be used by all kinds of drivers to annotate such code sections, hence their declarations are publicly visible in . A case in point is the Mellanox Ethernet driver which disables a firmware reset feature if the Ethernet card is attached to a hotplug port, see commit 3d7a3f2612d7 ("net/mlx5: Nack sync reset request when HotPlug is enabled"). Going forward, PCIe hotplug will be able to cope gracefully with all such use cases once the code sections are properly annotated. The new helpers internally use two bits in struct pci_dev's priv_flags as well as a wait_queue. This mirrors what was done for DPC by commit a97396c6eb13 ("PCI: pciehp: Ignore Link Down/Up caused by DPC"). That may be insufficient if spurious link changes are caused by multiple sources simultaneously. An example might be a Secondary Bus Reset issued by AER during FPGA reconfiguration. If this turns out to happen in real life, support for it can easily be added by replacing the PCI_LINK_CHANGING flag with an atomic_t counter incremented by pci_hp_ignore_link_change() and decremented by pci_hp_unignore_link_change(). Instead of awaiting a zero PCI_LINK_CHANGING flag, the pci_hp_spurious_link_change() helper would then simply await a zero counter. Fixes: 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller") Reported-by: Joel Mathew Thomas Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219765 Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Tested-by: Joel Mathew Thomas Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/d04deaf49d634a2edf42bf3c06ed81b4ca54d17b.1744298239.git.lukas@wunner.de Signed-off-by: Sasha Levin commit 33513c7b99d9488bf1161ceae0768a2aab225fa2 Author: Lukas Wunner Date: Thu Apr 10 17:27:11 2025 +0200 PCI: pciehp: Ignore Presence Detect Changed caused by DPC [ Upstream commit c3be50f7547ccb533284b22f74baf37d3379843e ] Commit a97396c6eb13 ("PCI: pciehp: Ignore Link Down/Up caused by DPC") amended PCIe hotplug to not bring down the slot upon Data Link Layer State Changed events caused by Downstream Port Containment. However Keith reports off-list that if the slot uses in-band presence detect (i.e. Presence Detect State is derived from Data Link Layer Link Active), DPC also causes a spurious Presence Detect Changed event. This needs to be ignored as well. Unfortunately there's no register indicating that in-band presence detect is used. PCIe r5.0 sec 7.5.3.10 introduced the In-Band PD Disable bit in the Slot Control Register. The PCIe hotplug driver sets this bit on ports supporting it. But older ports may still use in-band presence detect. If in-band presence detect can be disabled, Presence Detect Changed events occurring during DPC must not be ignored because they signal device replacement. On all other ports, device replacement cannot be detected reliably because the Presence Detect Changed event could be a side effect of DPC. On those (older) ports, perform a best-effort device replacement check by comparing the Vendor ID, Device ID and other data in Config Space with the values cached in struct pci_dev. Use the existing helper pciehp_device_replaced() to accomplish this. It is currently #ifdef'ed to CONFIG_PM_SLEEP in pciehp_core.c, so move it to pciehp_hpc.c where most other functions accessing config space reside. Reported-by: Keith Busch Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/fa264ff71952915c4e35a53c89eb0cde8455a5c5.1744298239.git.lukas@wunner.de Stable-dep-of: 2af781a9edc4 ("PCI: pciehp: Ignore Link Down/Up caused by Secondary Bus Reset") Signed-off-by: Sasha Levin commit 0f743e05157670994774ba906369bb818e334f1a Author: Cristian Ciocaltea Date: Tue Mar 18 14:35:38 2025 +0200 phy: rockchip: samsung-hdptx: Do no set rk_hdptx_phy->rate in case of errors [ Upstream commit 1f4d382769e3b38dfc498c806811dae856e40f31 ] Ensure rk_hdptx_ropll_tmds_cmn_config() updates hdptx->rate only after all the other operations have been successful. Fixes: c4b09c562086 ("phy: phy-rockchip-samsung-hdptx: Add clock provider support") Signed-off-by: Cristian Ciocaltea Link: https://lore.kernel.org/r/20250318-phy-sam-hdptx-bpc-v6-4-8cb1678e7663@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 70fdc1af006b406e49ac4536b9dc73d61d2a3ee7 Author: Cristian Ciocaltea Date: Tue Mar 18 14:35:37 2025 +0200 phy: rockchip: samsung-hdptx: Fix clock ratio setup [ Upstream commit 0422253ac1919fea8292381c85f11a9decff1bb1 ] The switch from 1/10 to 1/40 clock ratio must happen when exceeding the 340 MHz rate limit of HDMI 1.4, i.e. when entering the HDMI 2.0 domain, and not before. Therefore, use the correct comparison operator '>' instead of '>=' when checking the max rate. While at it, introduce a define for this rate limit constant. Fixes: 553be2830c5f ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver") Reviewed-by: Dmitry Baryshkov Signed-off-by: Cristian Ciocaltea Link: https://lore.kernel.org/r/20250318-phy-sam-hdptx-bpc-v6-3-8cb1678e7663@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 5de0311844c06801ae5fce13d2c2a57132ce576b Author: Wolfram Sang Date: Thu Feb 27 14:42:56 2025 +0100 rtc: sh: assign correct interrupts with DT [ Upstream commit 8f2efdbc303fe7baa83843d3290dd6ea5ba3276c ] The DT bindings for this driver define the interrupts in the order as they are numbered in the interrupt controller. The old platform_data, however, listed them in a different order. So, for DT based platforms, they are mixed up. Assign them specifically for DT, so we can keep the bindings stable. After the fix, 'rtctest' passes again on the Renesas Genmai board (RZ-A1 / R7S72100). Fixes: dab5aec64bf5 ("rtc: sh: add support for rza series") Signed-off-by: Wolfram Sang Link: https://lore.kernel.org/r/20250227134256.9167-11-wsa+renesas@sang-engineering.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 9eb3b74f49fa1ce2ce00cd6c4c0fdc2ad81b4c16 Author: Danilo Krummrich Date: Sat Mar 15 16:43:02 2025 +0100 rust: alloc: add missing invariant in Vec::set_len() [ Upstream commit fb1bf1067de979c89ae33589e0466d6ce0dde204 ] When setting a new length, we have to justify that the set length represents the exact number of elements stored in the vector. Reviewed-by: Benno Lossin Reported-by: Alice Ryhl Closes: https://lore.kernel.org/rust-for-linux/20250311-iov-iter-v1-4-f6c9134ea824@google.com Fixes: 2aac4cd7dae3 ("rust: alloc: implement kernel `Vec` type") Link: https://lore.kernel.org/r/20250315154436.65065-2-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit c13b779d26b3702fba8f7d5fe757aba5bda85fd0 Author: Pali Rohár Date: Thu Dec 26 19:55:13 2024 +0100 cifs: Fix validation of SMB1 query reparse point response [ Upstream commit 56e84c64fc257a95728ee73165456b025c48d408 ] Validate the SMB1 query reparse point response per [MS-CIFS] section 2.2.7.2 NT_TRANSACT_IOCTL. NT_TRANSACT_IOCTL response contains one word long setup data after which is ByteCount member. So check that SetupCount is 1 before trying to read and use ByteCount member. Output setup data contains ReturnedDataLen member which is the output length of executed IOCTL command by remote system. So check that output was not truncated before transferring over network. Change MaxSetupCount of NT_TRANSACT_IOCTL request from 4 to 1 as io_rsp structure already expects one word long output setup data. This should prevent server sending incompatible structure (in case it would be extended in future, which is unlikely). Change MaxParameterCount of NT_TRANSACT_IOCTL request from 2 to 0 as NT IOCTL does not have any documented output parameters and this function does not parse any output parameters at all. Fixes: ed3e0a149b58 ("smb: client: implement ->query_reparse_point() for SMB1") Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 821a88c86640e5b493f4da148eacbc1858c08a9d Author: Ian Rogers Date: Wed May 28 21:39:37 2025 -0700 perf callchain: Always populate the addr_location map when adding IP [ Upstream commit a913ef6fd883c05bd6538ed21ee1e773f0d750b7 ] Dropping symbols also meant the callchain maps wasn't populated, but the callchain map is needed to find the DSO. Plumb the symbols option better, falling back to thread__find_map() rather than thread__find_symbol() when symbols are disabled. Fixes: 02b2705017d2e5ad ("perf callchain: Allow symbols to be optional when resolving a callchain") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Athira Rajeev Cc: Ben Gainey Cc: Chaitanya S Prakash Cc: Charlie Jenkins Cc: Chun-Tse Shao Cc: Colin Ian King Cc: Dmitriy Vyukov Cc: Dr. David Alan Gilbert Cc: Graham Woodward Cc: Howard Chu Cc: Ilkka Koskinen Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: John Garry Cc: Kajol Jain Cc: Kan Liang Cc: Krzysztof Łopatowski Cc: Leo Yan Cc: Levi Yun Cc: Li Huafei Cc: linux-arm-kernel@lists.infradead.org Cc: Mark Rutland Cc: Martin Liška Cc: Masami Hiramatsu Cc: Matt Fleming Cc: Mike Leach Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Song Liu Cc: Steinar H. Gunderson Cc: Stephen Brennan Cc: Steve Clevenger Cc: Thomas Falcon Cc: Veronika Molnarova Cc: Weilin Wang Cc: Will Deacon Cc: Yicong Yang Cc: Yujie Liu Cc: Zhongqiu Han Cc: Zixian Cai Link: https://lore.kernel.org/r/20250529044000.759937-2-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b05dc9f757ecfb8790409d23e449e70232d34a85 Author: Amir Goldstein Date: Sun May 25 12:47:31 2025 +0200 exportfs: require ->fh_to_parent() to encode connectable file handles [ Upstream commit 5402c4d4d2000a9baa30c1157c97152ec6383733 ] When user requests a connectable file handle explicitly with the AT_HANDLE_CONNECTABLE flag, fail the request if filesystem (e.g. nfs) does not know how to decode a connected non-dir dentry. Fixes: c374196b2b9f ("fs: name_to_handle_at() support for "explicit connectable" file handles") Signed-off-by: Amir Goldstein Link: https://lore.kernel.org/20250525104731.1461704-1-amir73il@gmail.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit aefd954dd83e0f635266e82d2d0f8e257600f230 Author: Pekka Ristola Date: Tue May 27 20:48:55 2025 +0000 rust: file: mark `LocalFile` as `repr(transparent)` [ Upstream commit 15ecd83dc06277385ad71dc7ea26911d9a79acaf ] Unsafe code in `LocalFile`'s methods assumes that the type has the same layout as the inner `bindings::file`. This is not guaranteed by the default struct representation in Rust, but requires specifying the `transparent` representation. The `File` struct (which also wraps `bindings::file`) is already marked as `repr(transparent)`, so this change makes their layouts equivalent. Fixes: 851849824bb5 ("rust: file: add Rust abstraction for `struct file`") Closes: https://github.com/Rust-for-Linux/linux/issues/1165 Signed-off-by: Pekka Ristola Link: https://lore.kernel.org/20250527204636.12573-1-pekkarr@protonmail.com Reviewed-by: Benno Lossin Reviewed-by: Alice Ryhl Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 61009dd2252ab4391d44a240e891f1e04c00b9ca Author: Alistair Popple Date: Fri May 23 14:37:49 2025 +1000 fs/dax: Fix "don't skip locked entries when scanning entries" [ Upstream commit dd59137bfe70cf3646021b4721e430213b9c71bd ] Commit 6be3e21d25ca ("fs/dax: don't skip locked entries when scanning entries") introduced a new function, wait_entry_unlocked_exclusive(), which waits for the current entry to become unlocked without advancing the XArray iterator state. Waiting for the entry to become unlocked requires dropping the XArray lock. This requires calling xas_pause() prior to dropping the lock which leaves the xas in a suitable state for the next iteration. However this has the side-effect of advancing the xas state to the next index. Normally this isn't an issue because xas_for_each() contains code to detect this state and thus avoid advancing the index a second time on the next loop iteration. However both callers of and wait_entry_unlocked_exclusive() itself subsequently use the xas state to reload the entry. As xas_pause() updated the state to the next index this will cause the current entry which is being waited on to be skipped. This caused the following warning to fire intermittently when running xftest generic/068 on an XFS filesystem with FS DAX enabled: [ 35.067397] ------------[ cut here ]------------ [ 35.068229] WARNING: CPU: 21 PID: 1640 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0xd8/0x1e0 [ 35.069717] Modules linked in: nd_pmem dax_pmem nd_btt nd_e820 libnvdimm [ 35.071006] CPU: 21 UID: 0 PID: 1640 Comm: fstest Not tainted 6.15.0-rc7+ #77 PREEMPT(voluntary) [ 35.072613] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/204 [ 35.074845] RIP: 0010:truncate_folio_batch_exceptionals+0xd8/0x1e0 [ 35.075962] Code: a1 00 00 00 f6 47 0d 20 0f 84 97 00 00 00 4c 63 e8 41 39 c4 7f 0b eb 61 49 83 c5 01 45 39 ec 7e 58 42 f68 [ 35.079522] RSP: 0018:ffffb04e426c7850 EFLAGS: 00010202 [ 35.080359] RAX: 0000000000000000 RBX: ffff9d21e3481908 RCX: ffffb04e426c77f4 [ 35.081477] RDX: ffffb04e426c79e8 RSI: ffffb04e426c79e0 RDI: ffff9d21e34816e8 [ 35.082590] RBP: ffffb04e426c79e0 R08: 0000000000000001 R09: 0000000000000003 [ 35.083733] R10: 0000000000000000 R11: 822b53c0f7a49868 R12: 000000000000001f [ 35.084850] R13: 0000000000000000 R14: ffffb04e426c78e8 R15: fffffffffffffffe [ 35.085953] FS: 00007f9134c87740(0000) GS:ffff9d22abba0000(0000) knlGS:0000000000000000 [ 35.087346] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 35.088244] CR2: 00007f9134c86000 CR3: 000000040afff000 CR4: 00000000000006f0 [ 35.089354] Call Trace: [ 35.089749] [ 35.090168] truncate_inode_pages_range+0xfc/0x4d0 [ 35.091078] truncate_pagecache+0x47/0x60 [ 35.091735] xfs_setattr_size+0xc7/0x3e0 [ 35.092648] xfs_vn_setattr+0x1ea/0x270 [ 35.093437] notify_change+0x1f4/0x510 [ 35.094219] ? do_truncate+0x97/0xe0 [ 35.094879] do_truncate+0x97/0xe0 [ 35.095640] path_openat+0xabd/0xca0 [ 35.096278] do_filp_open+0xd7/0x190 [ 35.096860] do_sys_openat2+0x8a/0xe0 [ 35.097459] __x64_sys_openat+0x6d/0xa0 [ 35.098076] do_syscall_64+0xbb/0x1d0 [ 35.098647] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 35.099444] RIP: 0033:0x7f9134d81fc1 [ 35.100033] Code: 75 57 89 f0 25 00 00 41 00 3d 00 00 41 00 74 49 80 3d 2a 26 0e 00 00 74 6d 89 da 48 89 ee bf 9c ff ff ff5 [ 35.102993] RSP: 002b:00007ffcd41e0d10 EFLAGS: 00000202 ORIG_RAX: 0000000000000101 [ 35.104263] RAX: ffffffffffffffda RBX: 0000000000000242 RCX: 00007f9134d81fc1 [ 35.105452] RDX: 0000000000000242 RSI: 00007ffcd41e1200 RDI: 00000000ffffff9c [ 35.106663] RBP: 00007ffcd41e1200 R08: 0000000000000000 R09: 0000000000000064 [ 35.107923] R10: 00000000000001a4 R11: 0000000000000202 R12: 0000000000000066 [ 35.109112] R13: 0000000000100000 R14: 0000000000100000 R15: 0000000000000400 [ 35.110357] [ 35.110769] irq event stamp: 8415587 [ 35.111486] hardirqs last enabled at (8415599): [] __up_console_sem+0x52/0x60 [ 35.113067] hardirqs last disabled at (8415610): [] __up_console_sem+0x37/0x60 [ 35.114575] softirqs last enabled at (8415300): [] handle_softirqs+0x315/0x3f0 [ 35.115933] softirqs last disabled at (8415291): [] __irq_exit_rcu+0xa1/0xc0 [ 35.117316] ---[ end trace 0000000000000000 ]--- Fix this by using xas_reset() instead, which is equivalent in implementation to xas_pause() but does not advance the XArray state. Fixes: 6be3e21d25ca ("fs/dax: don't skip locked entries when scanning entries") Signed-off-by: Alistair Popple Link: https://lore.kernel.org/20250523043749.1460780-1-apopple@nvidia.com Reviewed-by: Dan Williams Reviewed-by: Jan Kara Cc: Dan Williams Cc: Alison Schofield Cc: "Matthew Wilcow (Oracle)" Cc: Balbir Singh Cc: "Darrick J. Wong" Cc: Dave Chinner Cc: David Hildenbrand Cc: Jan Kara Cc: John Hubbard Cc: Ted Ts'o Cc: Alexander Viro Cc: Christian Brauner Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit ed0bdac5eb1bd21500eb0fc9368e15c5890a7b7a Author: Anubhav Shelat Date: Thu May 29 10:33:35 2025 -0400 perf trace: Set errpid to false for rseq and set_robust_list [ Upstream commit 8c56bfe53bd881c7b598c54a3a06216743c57bbc ] The 'rseq' and 'set_robust_list' syscalls don't return a pid, so set errpid for both to false. Fixes: 0c1019e3463b263a ("perf trace: Mark the 'rseq' arg in the rseq syscall as coming from user space") Fixes: 1de5b5dcb8353f36 ("perf trace: Mark the 'head' arg in the set_robust_list syscall as coming from user space") Signed-off-by: Anubhav Shelat Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Dapeng Mi Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250529143334.1469669-2-ashelat@redhat.com [ Remove explicit .errpid = false, omitting its initialization zeroes it, as noted by Namhyung ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 3f28e08941e340ecdea818323777a909c40f824c Author: NeilBrown Date: Fri May 9 10:46:43 2025 +1000 nfs_localio: change nfsd_file_put_local() to take a pointer to __rcu pointer [ Upstream commit c25a89770d1f216dcedfc2d25d56b604f62ce0bd ] Instead of calling xchg() and unrcu_pointer() before nfsd_file_put_local(), we now pass pointer to the __rcu pointer and call xchg() and unrcu_pointer() inside that function. Where unrcu_pointer() is currently called the internals of "struct nfsd_file" are not known and that causes older compilers such as gcc-8 to complain. In some cases we have a __kernel (aka normal) pointer not an __rcu pointer so we need to cast it to __rcu first. This is strictly a weakening so no information is lost. Somewhat surprisingly, this cast is accepted by gcc-8. This has the pleasing result that the cmpxchg() which sets ro_file and rw_file, and also the xchg() which clears them, are both now in the nfsd code. Reported-by: Pali Rohár Reported-by: Vincent Mailhol Fixes: 86e00412254a ("nfs: cache all open LOCALIO nfsd_file(s) in client") Signed-off-by: NeilBrown Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 0965a7f65808c2b940e53d5559e14476464554e3 Author: NeilBrown Date: Fri May 9 10:46:42 2025 +1000 nfs_localio: protect race between nfs_uuid_put() and nfs_close_local_fh() [ Upstream commit 21fb44034695185f1dcbcb37354c842cabfe83c1 ] nfs_uuid_put() and nfs_close_local_fh() can race if a "struct nfs_file_localio" is released at the same time that nfsd calls nfs_localio_invalidate_clients(). It is important that neither of these functions completes after the other has started looking at a given nfs_file_localio and before it finishes. If nfs_uuid_put() exits while nfs_close_local_fh() is closing ro_file and rw_file it could return to __nfd_file_cache_purge() while some files are still referenced so the purge may not succeed. If nfs_close_local_fh() exits while nfsd_uuid_put() is still closing the files then the "struct nfs_file_localio" could be freed while nfsd_uuid_put() is still looking at it. This side is currently handled by copying the pointers out of ro_file and rw_file before deleting from the list in nfsd_uuid. We need to preserve this while ensuring that nfsd_uuid_put() does wait for nfs_close_local_fh(). This patch use nfl->uuid and nfl->list to provide the required interlock. nfs_uuid_put() removes the nfs_file_localio from the list, then drops locks and puts the two files, then reclaims the spinlock and sets ->nfs_uuid to NULL. nfs_close_local_fh() operates in the reverse order, setting ->nfs_uuid to NULL, then closing the files, then unlinking from the list. If nfs_uuid_put() finds that ->nfs_uuid is already NULL, it waits for the nfs_file_localio to be removed from the list. If nfs_close_local_fh() find that it has already been unlinked it waits for ->nfs_uuid to become NULL. This ensure that one of the two tries to close the files, but they each waits for the other. As nfs_uuid_put() is making the list empty, change from a list_for_each_safe loop to a while that always takes the first entry. This makes the intent more clear. Also don't move the list to a temporary local list as this would defeat the guarantees required for the interlock. Fixes: 86e00412254a ("nfs: cache all open LOCALIO nfsd_file(s) in client") Signed-off-by: NeilBrown Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 04ecb3e05ddd4efc9610081fe54a73ee7df2ae0f Author: NeilBrown Date: Fri May 9 10:46:41 2025 +1000 nfs_localio: duplicate nfs_close_local_fh() [ Upstream commit 74fc55ab2a6a0c71628fcf3b9783aae7119b5199 ] nfs_close_local_fh() is called from two different places for quite different use case. It is called from nfs_uuid_put() when the nfs_uuid is being detached - possibly because the nfs server is not longer serving that filesystem. In this case there will always be an nfs_uuid and so rcu_read_lock() is not needed. It is also called when the nfs_file_localio is no longer needed. In this case there may not be an active nfs_uuid. These two can race, and handling the race properly while avoiding excessive locking will require different handling on each side. This patch prepares the way by opencoding nfs_close_local_fh() into nfs_uuid_put(), then simplifying the code there as befits the context. Fixes: 86e00412254a ("nfs: cache all open LOCALIO nfsd_file(s) in client") Signed-off-by: NeilBrown Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 986a21ace186433e0397a59491646edad8c8d636 Author: NeilBrown Date: Fri May 9 10:46:40 2025 +1000 nfs_localio: simplify interface to nfsd for getting nfsd_file [ Upstream commit e6f7e1487ab528a6c653bd0d42812ff2942846cd ] The nfsd_localio_operations structure contains nfsd_file_get() to get a reference to an nfsd_file. This is only used in one place, where nfsd_open_local_fh() is also used. This patch combines the two, calling nfsd_open_local_fh() passing a pointer to where the nfsd_file pointer might be stored. If there is a pointer there an nfsd_file_get() can get a reference, that reference is returned. If not a new nfsd_file is acquired, stored at the pointer, and returned. When we store a reference we also increase the refcount on the net, as that refcount is decrements when we clear the stored pointer. We now get an extra reference *before* storing the new nfsd_file at the given location. This avoids possible races with the nfsd_file being freed before the final reference can be taken. This patch moves the rcu_dereference() needed after fetching from ro_file or rw_file into the nfsd code where the 'struct nfs_file' is fully defined. This avoids an error reported by older versions of gcc such as gcc-8 which complain about rcu_dereference() use in contexts where the structure (which will supposedly be accessed) is not fully defined. Reported-by: Pali Rohár Reported-by: Vincent Mailhol Fixes: 86e00412254a ("nfs: cache all open LOCALIO nfsd_file(s) in client") Signed-off-by: NeilBrown Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 9afc61e93d94fc805476b8a1c885c291d97341b3 Author: NeilBrown Date: Fri May 9 10:46:39 2025 +1000 nfs_localio: always hold nfsd net ref with nfsd_file ref [ Upstream commit 77e82fb2c6c27c122e785f543ae0062f7783c886 ] Having separate nfsd_file_put and nfsd_file_put_local in struct nfsd_localio_operations doesn't make much sense. The difference is that nfsd_file_put doesn't drop a reference to the nfs_net which is what keeps nfsd from shutting down. Currently, if nfsd tries to shutdown it will invalidate the files stored in the list from the nfs_uuid and this will drop all references to the nfsd net that the client holds. But the client could still hold some references to nfsd_files for active IO. So nfsd might think is has completely shut down local IO, but hasn't and has no way to wait for those active IO requests to complete. So this patch changes nfsd_file_get to nfsd_file_get_local and has it increase the ref count on the nfsd net and it replaces all calls to ->nfsd_put_file to ->nfsd_put_file_local. It also changes ->nfsd_open_local_fh to return with the refcount on the net elevated precisely when a valid nfsd_file is returned. This means that whenever the client holds a valid nfsd_file, there will be an associated count on the nfsd net, and so the count can only reach zero when all nfsd_files have been returned. nfs_local_file_put() is changed to call nfs_to_nfsd_file_put_local() instead of replacing calls to one with calls to the other because this will help a later patch which changes nfs_to_nfsd_file_put_local() to take an __rcu pointer while nfs_local_file_put() doesn't. Fixes: 86e00412254a ("nfs: cache all open LOCALIO nfsd_file(s) in client") Signed-off-by: NeilBrown Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 2b12ad4306d4bbbc69a9ff511c1fc93f5c49f2ee Author: NeilBrown Date: Fri May 9 10:46:38 2025 +1000 nfs_localio: use cmpxchg() to install new nfs_file_localio [ Upstream commit ed9be317330c7390df7db9e1d046698c02001bd2 ] Rather than using nfs_uuid.lock to protect installing a new ro_file or rw_file, change to use cmpxchg(). Removing the file already uses xchg() so this improves symmetry and also makes the code a little simpler. Also remove the optimisation of not taking the lock, and not removing the nfs_file_localio from the linked list, when both ->ro_file and ->rw_file are already NULL. Given that ->nfs_uuid was not NULL, it is extremely unlikely that neither ->ro_file or ->rw_file is NULL so this optimisation can be of little value and it complicates understanding of the code - why can the list_del_init() be skipped? Finally, move the assignment of NULL to ->nfs_uuid until after the last action on the nfs_file_localio (the list_del_init). As soon as this is NULL a racing nfs_close_local_fh() can bypass all the locking and go on to free the nfs_file_localio, so we must be certain to be finished with it first. Fixes: 86e00412254a ("nfs: cache all open LOCALIO nfsd_file(s) in client") Signed-off-by: NeilBrown Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 062feb506caf231b7e5164dcc28709465081256a Author: NeilBrown Date: Mon May 26 14:08:25 2025 +1000 nfs: fix incorrect handling of large-number NFS errors in nfs4_do_mkdir() [ Upstream commit dd862da61e91123ca745e06c03ba39ce71a929d9 ] A recent commit introduced nfs4_do_mkdir() which reports an error from nfs4_call_sync() by returning it with ERR_PTR(). This is a problem as nfs4_call_sync() can return negative NFS-specific errors with values larger than MAX_ERRNO (4095). One example is NFS4ERR_DELAY which has value 10008. This "pointer" gets to PTR_ERR_OR_ZERO() in nfs4_proc_mkdir() which chooses ZERO because it isn't in the range of value errors. Ultimately the pointer is dereferenced. This patch changes nfs4_do_mkdir() to report the dentry pointer and status separately - pointer as a return value, status in an "int *" parameter. The same separation is used for _nfs4_proc_mkdir() and the two are combined only in nfs4_proc_mkdir() after the status has passed through nfs4_handle_exception(), which ensures the error code does not exceed MAX_ERRNO. It also fixes a problem in the even when nfs4_handle_exception() updated the error value, the original 'alias' was still returned. Reported-by: Anna Schumaker Fixes: 8376583b84a1 ("nfs: change mkdir inode_operation to return alternate dentry if needed.") Signed-off-by: NeilBrown Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit b5da66f6154a0c61e69c8b059eb40bc56b3321ab Author: Li Lingfeng Date: Tue Mar 4 21:05:33 2025 +0800 nfs: ignore SB_RDONLY when remounting nfs [ Upstream commit 80c4de6ab44c14e910117a02f2f8241ffc6ec54a ] In some scenarios, when mounting NFS, more than one superblock may be created. The final superblock used is the last one created, but only the first superblock carries the ro flag passed from user space. If a ro flag is added to the superblock via remount, it will trigger the issue described in Link[1]. Link[2] attempted to address this by marking the superblock as ro during the initial mount. However, this introduced a new problem in scenarios where multiple mount points share the same superblock: [root@a ~]# mount /dev/sdb /mnt/sdb [root@a ~]# echo "/mnt/sdb *(rw,no_root_squash)" > /etc/exports [root@a ~]# echo "/mnt/sdb/test_dir2 *(ro,no_root_squash)" >> /etc/exports [root@a ~]# systemctl restart nfs-server [root@a ~]# mount -t nfs -o rw 127.0.0.1:/mnt/sdb/test_dir1 /mnt/test_mp1 [root@a ~]# mount | grep nfs4 127.0.0.1:/mnt/sdb/test_dir1 on /mnt/test_mp1 type nfs4 (rw,relatime,... [root@a ~]# mount -t nfs -o ro 127.0.0.1:/mnt/sdb/test_dir2 /mnt/test_mp2 [root@a ~]# mount | grep nfs4 127.0.0.1:/mnt/sdb/test_dir1 on /mnt/test_mp1 type nfs4 (ro,relatime,... 127.0.0.1:/mnt/sdb/test_dir2 on /mnt/test_mp2 type nfs4 (ro,relatime,... [root@a ~]# When mounting the second NFS, the shared superblock is marked as ro, causing the previous NFS mount to become read-only. To resolve both issues, the ro flag is no longer applied to the superblock during remount. Instead, the ro flag on the mount is used to control whether the mount point is read-only. Fixes: 281cad46b34d ("NFS: Create a submount rpc_op") Link[1]: https://lore.kernel.org/all/20240604112636.236517-3-lilingfeng@huaweicloud.com/ Link[2]: https://lore.kernel.org/all/20241130035818.1459775-1-lilingfeng3@huawei.com/ Signed-off-by: Li Lingfeng Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 93cf676a1750ebee4474eaa8ac0496dc0d4ffb11 Author: Li Lingfeng Date: Tue Mar 4 21:05:32 2025 +0800 nfs: clear SB_RDONLY before getting superblock [ Upstream commit 8cd9b785943c57a136536250da80ba1eb6f8eb18 ] As described in the link, commit 52cb7f8f1778 ("nfs: ignore SB_RDONLY when mounting nfs") removed the check for the ro flag when determining whether to share the superblock, which caused issues when mounting different subdirectories under the same export directory via NFSv3. However, this change did not affect NFSv4. For NFSv3: 1) A single superblock is created for the initial mount. 2) When mounted read-only, this superblock carries the SB_RDONLY flag. 3) Before commit 52cb7f8f1778 ("nfs: ignore SB_RDONLY when mounting nfs"): Subsequent rw mounts would not share the existing ro superblock due to flag mismatch, creating a new superblock without SB_RDONLY. After the commit: The SB_RDONLY flag is ignored during superblock comparison, and this leads to sharing the existing superblock even for rw mounts. Ultimately results in write operations being rejected at the VFS layer. For NFSv4: 1) Multiple superblocks are created and the last one will be kept. 2) The actually used superblock for ro mounts doesn't carry SB_RDONLY flag. Therefore, commit 52cb7f8f1778 doesn't affect NFSv4 mounts. Clear SB_RDONLY before getting superblock when NFS_MOUNT_UNSHARED is not set to fix it. Fixes: 52cb7f8f1778 ("nfs: ignore SB_RDONLY when mounting nfs") Closes: https://lore.kernel.org/all/12d7ea53-1202-4e21-a7ef-431c94758ce5@app.fastmail.com/T/ Signed-off-by: Li Lingfeng Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 987bfcd718fdad5af916a86abbc38abb588d3ffa Author: Anubhav Shelat Date: Thu Apr 3 12:04:12 2025 -0400 perf trace: Always print return value for syscalls returning a pid [ Upstream commit c7a48ea9b919e2fa0e4a1d9938fdb03e9afe276c ] The syscalls that were consistently observed were set_robust_list and rseq. This is because perf cannot find their child process. This change ensures that the return value is always printed. Before: 0.256 ( 0.001 ms): set_robust_list(head: 0x7f09c77dba20, len: 24) = 0.259 ( 0.001 ms): rseq(rseq: 0x7f09c77dc0e0, rseq_len: 32, sig: 1392848979) = After: 0.270 ( 0.002 ms): set_robust_list(head: 0x7f0bb14a6a20, len: 24) = 0 0.273 ( 0.002 ms): rseq(rseq: 0x7f0bb14a70e0, rseq_len: 32, sig: 1392848979) = 0 Committer notes: As discussed in the thread in the Link: tag below, these two don't return a pid, but for syscalls returning one, we need to print the result and if we manage to find the children in 'perf trace' data structures, then print its name as well. Fixes: 11c8e39f5133aed9 ("perf trace: Infrastructure to show COMM strings for syscalls returning PIDs") Reviewed-by: Howard Chu Signed-off-by: Anubhav Shelat Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Dapeng Mi Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Michael Petlan Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250403160411.159238-2-ashelat@redhat.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 284325d47b2f314652226685d374a86510b60d0f Author: Dapeng Mi Date: Thu Apr 3 06:08:10 2025 +0000 perf record: Fix incorrect --user-regs comments [ Upstream commit a4a859eb6704a8aa46aa1cec5396c8d41383a26b ] The comment of "--user-regs" option is not correct, fix it. "on interrupt," -> "in user space," Fixes: 84c417422798c897 ("perf record: Support direct --user-regs arguments") Reviewed-by: Ian Rogers Signed-off-by: Dapeng Mi Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Ingo Molnar Cc: Kan Liang Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250403060810.196028-1-dapeng1.mi@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit e9b2bd232e6466466f263207db0be0e81313f580 Author: David Hildenbrand Date: Fri May 16 14:39:46 2025 +0200 s390/uv: Improve splitting of large folios that cannot be split while dirty [ Upstream commit ab73b29efd36f8916c6cc9954e912c4723c9a1b0 ] Currently, starting a PV VM on an iomap-based filesystem with large folio support, such as XFS, will not work. We'll be stuck in unpack_one()->gmap_make_secure(), because we can't seem to make progress splitting the large folio. The problem is that we require a writable PTE but a writable PTE under such filesystems will imply a dirty folio. So whenever we have a writable PTE, we'll have a dirty folio, and dirty iomap folios cannot currently get split, because split_folio()->split_huge_page_to_list_to_order()->filemap_release_folio() will fail in iomap_release_folio(). So we will not make any progress splitting such large folios. Until dirty folios can be split more reliably, let's manually trigger writeback of the problematic folio using filemap_write_and_wait_range(), and retry the split immediately afterwards exactly once, before looking up the folio again. Should this logic be part of split_folio()? Likely not; most split users don't have to split so eagerly to make any progress. For now, this seems to affect xfs, zonefs and erofs, and this patch makes it work again (tested on xfs only). While this could be considered a fix for commit 6795801366da ("xfs: Support large folios"), commit df2f9708ff1f ("zonefs: enable support for large folios") and commit ce529cc25b18 ("erofs: enable large folios for iomap mode"), before commit eef88fe45ac9 ("s390/uv: Split large folios in gmap_make_secure()"), we did not try splitting large folios at all. So it's all rather part of making SE compatible with file systems that support large folios. But to have some "Fixes:" tag, let's just use eef88fe45ac9. Not CCing stable, because there are a lot of dependencies, and it simply not working is not critical in stable kernels. Reported-by: Sebastian Mitterle Closes: https://issues.redhat.com/browse/RHEL-58218 Fixes: eef88fe45ac9 ("s390/uv: Split large folios in gmap_make_secure()") Signed-off-by: David Hildenbrand Link: https://lore.kernel.org/r/20250516123946.1648026-4-david@redhat.com Message-ID: <20250516123946.1648026-4-david@redhat.com> Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Signed-off-by: Sasha Levin commit dce163aa5aacb8face7a2187f45eb611ece829d3 Author: David Hildenbrand Date: Fri May 16 14:39:45 2025 +0200 s390/uv: Always return 0 from s390_wiggle_split_folio() if successful [ Upstream commit bd428b8c79ed8e8658570e70c62c0092500e2eac ] Let's consistently return 0 if the operation was successful, and just detect ourselves whether splitting is required -- folio_test_large() is a cheap operation. Update the documentation. Should we simply always return -EAGAIN instead of 0, so we don't have to handle it in the caller? Not sure, staring at the documentation, this way looks a bit cleaner. Signed-off-by: David Hildenbrand Link: https://lore.kernel.org/r/20250516123946.1648026-3-david@redhat.com Message-ID: <20250516123946.1648026-3-david@redhat.com> Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Stable-dep-of: ab73b29efd36 ("s390/uv: Improve splitting of large folios that cannot be split while dirty") Signed-off-by: Sasha Levin commit 65ef2ca5185cb61b6399cd8d1010ef32ac2d244d Author: David Hildenbrand Date: Fri May 16 14:39:44 2025 +0200 s390/uv: Don't return 0 from make_hva_secure() if the operation was not successful [ Upstream commit 3ec8a8330a1aa846dffbf1d64479213366c55b54 ] If s390_wiggle_split_folio() returns 0 because splitting a large folio succeeded, we will return 0 from make_hva_secure() even though a retry is required. Return -EAGAIN in that case. Otherwise, we'll return 0 from gmap_make_secure(), and consequently from unpack_one(). In kvm_s390_pv_unpack(), we assume that unpacking succeeded and skip unpacking this page. Later on, we run into issues and fail booting the VM. So far, this issue was only observed with follow-up patches where we split large pagecache XFS folios. Maybe it can also be triggered with shmem? We'll cleanup s390_wiggle_split_folio() a bit next, to also return 0 if no split was required. Fixes: d8dfda5af0be ("KVM: s390: pv: fix race when making a page secure") Cc: stable@vger.kernel.org Signed-off-by: David Hildenbrand Link: https://lore.kernel.org/r/20250516123946.1648026-2-david@redhat.com Message-ID: <20250516123946.1648026-2-david@redhat.com> Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Stable-dep-of: ab73b29efd36 ("s390/uv: Improve splitting of large folios that cannot be split while dirty") Signed-off-by: Sasha Levin commit 7ab6a125ae2da012d199c92820850a6922fe6be1 Author: Ian Rogers Date: Tue May 27 20:26:31 2025 -0700 perf symbol: Fix use-after-free in filename__read_build_id [ Upstream commit fef8f648bb47726d96a5701fe31ed606268da73d ] The same buf is used for the program headers and reading notes. As the notes memory may be reallocated then this corrupts the memory pointed to by the phdr. Using the same buffer is in any case a logic error. Rather than deal with the duplicated code, introduce an elf32 boolean and a union for either the elf32 or elf64 headers that are in use. Let the program headers have their own memory and grow the buffer for notes as necessary. Before `perf list -j` compiled with asan would crash with: ``` ==4176189==ERROR: AddressSanitizer: heap-use-after-free on address 0x5160000070b8 at pc 0x555d3b15075b bp 0x7ffebb5a8090 sp 0x7ffebb5a8088 READ of size 8 at 0x5160000070b8 thread T0 #0 0x555d3b15075a in filename__read_build_id tools/perf/util/symbol-minimal.c:212:25 #1 0x555d3ae43aff in filename__sprintf_build_id tools/perf/util/build-id.c:110:8 ... 0x5160000070b8 is located 312 bytes inside of 560-byte region [0x516000006f80,0x5160000071b0) freed by thread T0 here: #0 0x555d3ab21840 in realloc (perf+0x264840) (BuildId: 12dff2f6629f738e5012abdf0e90055518e70b5e) #1 0x555d3b1506e7 in filename__read_build_id tools/perf/util/symbol-minimal.c:206:11 ... previously allocated by thread T0 here: #0 0x555d3ab21423 in malloc (perf+0x264423) (BuildId: 12dff2f6629f738e5012abdf0e90055518e70b5e) #1 0x555d3b1503a2 in filename__read_build_id tools/perf/util/symbol-minimal.c:182:9 ... ``` Note: this bug is long standing and not introduced by the other asan fix in commit fa9c4977fbfb ("perf symbol-minimal: Fix double free in filename__read_build_id"). Fixes: b691f64360ecec49 ("perf symbols: Implement poor man's ELF parser") Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250528032637.198960-2-irogers@google.com Cc: Mark Rutland Cc: Gary Guo Cc: Alex Gaynor Cc: Boqun Feng Cc: Howard Chu Cc: Alice Ryhl Cc: Dmitry Vyukov Cc: Peter Zijlstra Cc: Adrian Hunter Cc: Weilin Wang Cc: Andreas Hindborg Cc: Arnaldo Carvalho de Melo Cc: Danilo Krummrich Cc: Jiri Olsa Cc: Namhyung Kim Cc: Miguel Ojeda Cc: James Clark Cc: Jiapeng Chong Cc: Andi Kleen Cc: Alexander Shishkin Cc: Kan Liang Cc: Stephen Brennan Cc: Benno Lossin Cc: Björn Roy Baron Cc: Ingo Molnar Cc: Trevor Gross Cc: linux-kernel@vger.kernel.org Cc: linux-perf-users@vger.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit d07d27e47786a8a63e13a469072811b7a7da3b18 Author: Ian Rogers Date: Tue May 27 14:50:35 2025 -0700 perf pmu: Avoid segv for missing name/alias_name in wildcarding [ Upstream commit 2a2a7f5e7deffa363b438308812989ded126a48a ] The pmu name or alias_name fields may be NULL and should be skipped if so. This is done in all loops of perf_pmu___name_match except the final wildcard loop which was an oversight. Fixes: 63e287131cf0c59b ("perf pmu: Rename name matching for no suffix or wildcard variants") Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250527215035.187992-1-irogers@google.com [ Fixup the Fixes: tag to the right commit ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 68a233b4fcd8a0fce4bb0c13670b5f2cc42a6529 Author: Jens Axboe Date: Tue May 27 17:01:31 2025 -0600 iomap: don't lose folio dropbehind state for overwrites [ Upstream commit 34ecde3c56066ba79e5ec3d93c5b14ea83e3603e ] DONTCACHE I/O must have the completion punted to a workqueue, just like what is done for unwritten extents, as the completion needs task context to perform the invalidation of the folio(s). However, if writeback is started off filemap_fdatawrite_range() off generic_sync() and it's an overwrite, then the DONTCACHE marking gets lost as iomap_add_to_ioend() don't look at the folio being added and no further state is passed down to help it know that this is a dropbehind/DONTCACHE write. Check if the folio being added is marked as dropbehind, and set IOMAP_IOEND_DONTCACHE if that is the case. Then XFS can factor this into the decision making of completion context in xfs_submit_ioend(). Additionally include this ioend flag in the NOMERGE flags, to avoid mixing it with unrelated IO. Since this is the 3rd flag that will cause XFS to punt the completion to a workqueue, add a helper so that each one of them can get appropriately commented. This fixes extra page cache being instantiated when the write performed is an overwrite, rather than newly instantiated blocks. Fixes: b2cd5ae693a3 ("iomap: make buffered writes work with RWF_DONTCACHE") Signed-off-by: Jens Axboe Link: https://lore.kernel.org/5153f6e8-274d-4546-bf55-30a5018e0d03@kernel.dk Reviewed-by: Dave Chinner Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 5169ac06ba136603a603ac0d850a3fa2e44f784d Author: Jason-JH Lin Date: Mon Apr 21 11:55:47 2025 +0800 mailbox: mtk-cmdq: Refine GCE_GCTL_VALUE setting [ Upstream commit 9fcebcb37c3e0a4b6eb40768cc5a5faebf166fbe ] Add cmdq_gctl_value_toggle() to configure GCE_CTRL_BY_SW and GCE_DDR_EN together in the same GCE_GCTL_VALUE register. For the SoCs whose GCE is located in MMINFRA and uses MMINFRA_AO power, this allows it to be written without enabling the clocks. Otherwise, all GCE registers should be written after the GCE clocks are enabled. Move this function into cmdq_runtime_resume() and cmdq_runtime_suspend() to ensure it is called when the GCE clock is enabled. Fixes: 7abd037aa581 ("mailbox: mtk-cmdq: add gce ddr enable support flow") Signed-off-by: Jason-JH Lin Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 1dcaf07ba68a80b12d9b2ae464c3e65112d54fef Author: Peng Fan Date: Sun May 25 16:47:24 2025 +0800 mailbox: imx: Fix TXDB_V2 sending [ Upstream commit f5cb07ec6aabd1bb56adbdeb5f0d70cb524db2cd ] i.MX95 features several processing domains, Cortex-M7, Cortex-A55 secure, Cortex-A55 non-secure. Each domain could communicate with SCMI firmware with a dedicated MU. But the current NXP SCMI firmware is not a RTOS, all processing logic codes are in interrupt context. So if high priority Cortex-M7 is communicating with SCMI firmware and requires a bit more time to handle the SCMI call, Linux MU TXDB_V2 will be timeout with high possiblity in 1000us(the current value in imx-mailbox.c). Per NXP SCMI firmware design, if timeout, there is no recover logic, so SCMI agents should never timeout and always wait until the check condition met. Based on the upper reason, enlarge the timeout value to 10ms which is less chance to timeout, and retry if timeout really happends. Fixes: 5bfe4067d350 ("mailbox: imx: support channel type tx doorbell v2") Signed-off-by: Peng Fan Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit fda73c907cd5a26846ebc3e4201ba376b632fcc4 Author: Yue Haibing Date: Fri Apr 11 15:57:47 2025 +0800 mailbox: mchp-ipc-sbi: Fix COMPILE_TEST build error [ Upstream commit d635ba4207c31940398c41caa0cedd80f3b9c9c7 ] If COMPILE_TEST is y but RISCV_SBI is n, build fails: drivers/mailbox/mailbox-mchp-ipc-sbi.c: In function 'mchp_ipc_sbi_chan_send': drivers/mailbox/mailbox-mchp-ipc-sbi.c:119:23: error: storage size of 'ret' isn't known struct sbiret ret; ^~~ CC drivers/nvmem/lpc18xx_otp.o drivers/mailbox/mailbox-mchp-ipc-sbi.c:121:15: error: implicit declaration of function 'sbi_ecall' [-Werror=implicit-function-declaration] ret = sbi_ecall(SBI_EXT_MICROCHIP_TECHNOLOGY, command, channel, ^~~~~~~~~ move COMPILE_TEST to ARCH_MICROCHIP dependency as other drivers. Fixes: e4b1d67e7141 ("mailbox: add Microchip IPC support") Signed-off-by: Yue Haibing Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 7dd8665953a40ad502c17db912b4f0f81cdfbe56 Author: Leo Yan Date: Mon Mar 31 18:27:59 2025 +0100 perf tests switch-tracking: Fix timestamp comparison [ Upstream commit 628e124404b3db5e10e17228e680a2999018ab33 ] The test might fail on the Arm64 platform with the error: # perf test -vvv "Track with sched_switch" Missing sched_switch events # The issue is caused by incorrect handling of timestamp comparisons. The comparison result, a signed 64-bit value, was being directly cast to an int, leading to incorrect sorting for sched events. The case does not fail everytime, usually I can trigger the failure after run 20 ~ 30 times: # while true; do perf test "Track with sched_switch"; done 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : FAILED! 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok 106: Track with sched_switch : FAILED! 106: Track with sched_switch : Ok 106: Track with sched_switch : Ok I used cross compiler to build Perf tool on my host machine and tested on Debian / Juno board. Generally, I think this issue is not very specific to GCC versions. As both internal CI and my local env can reproduce the issue. My Host Build compiler: # aarch64-linux-gnu-gcc --version aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0 Juno Board: # lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm Fix this by explicitly returning 0, 1, or -1 based on whether the result is zero, positive, or negative. Fixes: d44bc558297222d9 ("perf tests: Add a test for tracking with sched_switch") Reviewed-by: Ian Rogers Signed-off-by: Leo Yan Cc: Adrian Hunter Cc: James Clark Cc: Kan Liang Cc: Namhyung Kim Link: https://lore.kernel.org/r/20250331172759.115604-1-leo.yan@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b5dbb53c888e5d5099c1a7038aaa2e6c765a9ac6 Author: David Howells Date: Fri May 23 08:57:52 2025 +0100 netfs: Fix undifferentiation of DIO reads from unbuffered reads [ Upstream commit db26d62d79e4068934ad0dccdb92715df36352b9 ] On cifs, "DIO reads" (specified by O_DIRECT) need to be differentiated from "unbuffered reads" (specified by cache=none in the mount parameters). The difference is flagged in the protocol and the server may behave differently: Windows Server will, for example, mandate that DIO reads are block aligned. Fix this by adding a NETFS_UNBUFFERED_READ to differentiate this from NETFS_DIO_READ, parallelling the write differentiation that already exists. cifs will then do the right thing. Fixes: 016dc8516aec ("netfs: Implement unbuffered/DIO read support") Signed-off-by: David Howells Link: https://lore.kernel.org/3444961.1747987072@warthog.procyon.org.uk Reviewed-by: "Paulo Alcantara (Red Hat)" Reviewed-by: Viacheslav Dubeyko cc: Steve French cc: netfs@lists.linux.dev cc: v9fs@lists.linux.dev cc: linux-afs@lists.infradead.org cc: linux-cifs@vger.kernel.org cc: ceph-devel@vger.kernel.org cc: linux-nfs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 7a506ec1caa6a992b84f5bebedf32ecbd739989a Author: Alexey Gladkov Date: Sat Apr 26 18:16:32 2025 +0200 mfd: stmpe-spi: Correct the name used in MODULE_DEVICE_TABLE [ Upstream commit 59d60c16ed41475f3b5f7b605e75fbf8e3628720 ] The name used in the macro does not exist. drivers/mfd/stmpe-spi.c:132:26: error: use of undeclared identifier 'stmpe_id' 132 | MODULE_DEVICE_TABLE(spi, stmpe_id); Fixes: e789995d5c61 ("mfd: Add support for STMPE SPI interface") Signed-off-by: Alexey Gladkov Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/79d5a847303e45a46098f2d827d3d8a249a32be3.1745591072.git.legion@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit a430cc3d229b60bb66892708fcb5bca4b6e4399a Author: Christophe JAILLET Date: Mon Apr 21 17:00:35 2025 +0200 mfd: exynos-lpass: Fix another error handling path in exynos_lpass_probe() [ Upstream commit f41cc37f4bc0e8cd424697bf6e26586cadcf4b9b ] If devm_of_platform_populate() fails, some clean-up needs to be done, as already done in the remove function. Add a new devm_add_action_or_reset() to fix the leak in the probe and remove the need of a remove function. Fixes: c695abab2429 ("mfd: Add Samsung Exynos Low Power Audio Subsystem driver") Signed-off-by: Christophe JAILLET Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/69471e839efc0249a504492a8de3497fcdb6a009.1745247209.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 3f33b744f471f37e8f73508c519eb3917a60a8f2 Author: Christophe JAILLET Date: Mon Apr 21 17:00:34 2025 +0200 mfd: exynos-lpass: Avoid calling exynos_lpass_disable() twice in exynos_lpass_remove() [ Upstream commit b70b84556eeca5262d290e8619fe0af5b7664a52 ] exynos_lpass_disable() is called twice in the remove function. Remove one of these calls. Fixes: 90f447170c6f ("mfd: exynos-lpass: Add runtime PM support") Signed-off-by: Christophe JAILLET Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/74d69e8de10308c9855db6d54155a3de4b11abfd.1745247209.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit df7747431661c96c9c785d0fb1a9a26c3142af38 Author: Christophe JAILLET Date: Mon Apr 21 17:00:33 2025 +0200 mfd: exynos-lpass: Fix an error handling path in exynos_lpass_probe() [ Upstream commit 484f0f59f09edd1f6fa63703c12eb30d72a519ac ] If an error occurs after a successful regmap_init_mmio(), regmap_exit() should be called as already done in the .remove() function. Switch to devm_regmap_init_mmio() to avoid the leak and simplify the .remove() function. Fixes: c414df12bdf7 ("mfd: exynos-lpass: Add missing remove() function") Signed-off-by: Christophe JAILLET Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/38414eecb1096840946756ae86887aea2a489c1b.1745247209.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 329ba1cb402ac328224965b8fc7a554a5150908e Author: David Howells Date: Mon May 19 10:07:04 2025 +0100 netfs: Fix wait/wake to be consistent about the waitqueue used [ Upstream commit 2b1424cd131cfaba4cf7040473133d26cddac088 ] Fix further inconsistencies in the use of waitqueues (clear_and_wake_up_bit() vs private waitqueue). Move some of this stuff from the read and write sides into common code so that it can be done in fewer places. To make this work, async I/O needs to set NETFS_RREQ_OFFLOAD_COLLECTION to indicate that a workqueue will do the collecting and places that call the wait function need to deal with it returning the amount transferred. Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use one work item") Signed-off-by: David Howells Link: https://lore.kernel.org/20250519090707.2848510-5-dhowells@redhat.com cc: Marc Dionne cc: Steve French cc: Ihor Solodrai cc: Eric Van Hensbergen cc: Latchesar Ionkov cc: Dominique Martinet cc: Christian Schoenebeck cc: Paulo Alcantara cc: Jeff Layton cc: v9fs@lists.linux.dev cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 1a8360c2eed3b292ed654c2ac61b09de4a80e298 Author: David Howells Date: Mon May 19 10:07:03 2025 +0100 netfs: Fix the request's work item to not require a ref [ Upstream commit 20d72b00ca814d748f5663484e5c53bb2bf37a3a ] When the netfs_io_request struct's work item is queued, it must be supplied with a ref to the work item struct to prevent it being deallocated whilst on the queue or whilst it is being processed. This is tricky to manage as we have to get a ref before we try and queue it and then we may find it's already queued and is thus already holding a ref - in which case we have to try and get rid of the ref again. The problem comes if we're in BH or IRQ context and need to drop the ref: if netfs_put_request() reduces the count to 0, we have to do the cleanup - but the cleanup may need to wait. Fix this by adding a new work item to the request, ->cleanup_work, and dispatching that when the refcount hits zero. That can then synchronously cancel any outstanding work on the main work item before doing the cleanup. Adding a new work item also deals with another problem upstream where it's sometimes changing the work func in the put function and requeuing it - which has occasionally in the past caused the cleanup to happen incorrectly. As a bonus, this allows us to get rid of the 'was_async' parameter from a bunch of functions. This indicated whether the put function might not be permitted to sleep. Fixes: 3d3c95046742 ("netfs: Provide readahead and readpage netfs helpers") Signed-off-by: David Howells Link: https://lore.kernel.org/20250519090707.2848510-4-dhowells@redhat.com cc: Paulo Alcantara cc: Marc Dionne cc: Steve French cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 3f844fa87d47c17deecb0f07b625c6fdd96fd009 Author: Paulo Alcantara Date: Mon May 19 10:07:02 2025 +0100 netfs: Fix setting of transferred bytes with short DIO reads [ Upstream commit 34eb98c6598c4057640ca56dd1fad6555187473a ] A netfslib request comprises an ordered stream of subrequests that, when doing an unbuffered/DIO read, are contiguous. The subrequests may be performed in parallel, but may not be fully completed. For instance, if we try and make a 256KiB DIO read from a 3-byte file with a 64KiB rsize and 256KiB bsize, netfslib will attempt to make a read of 256KiB, broken up into four 64KiB subreads, with the expectation that the first will be short and the subsequent three be completely devoid - but we do all four on the basis that the file may have been changed by a third party. The read-collection code, however, walks through all the subreqs and advances the notion of how much data has been read in the stream to the start of each subreq plus its amount transferred (which are 3, 0, 0, 0 for the example above) - which gives an amount apparently read of 3*64KiB - which is incorrect. Fix the collection code to cut short the calculation of the transferred amount with the first short subrequest in an unbuffered read; everything beyond that must be ignored as there's a hole that cannot be filled. This applies both to shortness due to hitting the EOF and shortness due to an error. This is achieved by setting a flag on the request when we collect the first short subrequest (collection is done in ascending order). This can be tested by mounting a cifs volume with rsize=65536,bsize=262144 and doing a 256k DIO read of a very small file (e.g. 3 bytes). read() should return 3, not >3. This problem came in when netfs_read_collection() set rreq->transferred to stream->transferred, even for DIO. Prior to that, netfs_rreq_assess_dio() just went over the list and added up the subreqs till it met a short one - but now the subreqs are discarded earlier. Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use one work item") Reported-by: Nicolas Baranger Closes: https://lore.kernel.org/all/10bec2430ed4df68bde10ed95295d093@3xo.fr/ Signed-off-by: "Paulo Alcantara (Red Hat)" Signed-off-by: David Howells Link: https://lore.kernel.org/20250519090707.2848510-3-dhowells@redhat.com cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit bd0edaf99a920b1a9decd773179caacacb61d0fd Author: David Howells Date: Mon May 19 10:07:01 2025 +0100 netfs: Fix oops in write-retry from mis-resetting the subreq iterator [ Upstream commit 4481f7f2b3df123ec77e828c849138f75cff2bf2 ] Fix the resetting of the subrequest iterator in netfs_retry_write_stream() to use the iterator-reset function as the iterator may have been shortened by a previous retry. In such a case, the amount of data to be written by the subrequest is not "subreq->len" but "subreq->len - subreq->transferred". Without this, KASAN may see an error in iov_iter_revert(): BUG: KASAN: slab-out-of-bounds in iov_iter_revert lib/iov_iter.c:633 [inline] BUG: KASAN: slab-out-of-bounds in iov_iter_revert+0x443/0x5a0 lib/iov_iter.c:611 Read of size 4 at addr ffff88802912a0b8 by task kworker/u32:7/1147 CPU: 1 UID: 0 PID: 1147 Comm: kworker/u32:7 Not tainted 6.15.0-rc6-syzkaller-00052-g9f35e33144ae #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events_unbound netfs_write_collection_worker Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 iov_iter_revert lib/iov_iter.c:633 [inline] iov_iter_revert+0x443/0x5a0 lib/iov_iter.c:611 netfs_retry_write_stream fs/netfs/write_retry.c:44 [inline] netfs_retry_writes+0x166d/0x1a50 fs/netfs/write_retry.c:231 netfs_collect_write_results fs/netfs/write_collect.c:352 [inline] netfs_write_collection_worker+0x23fd/0x3830 fs/netfs/write_collect.c:374 process_one_work+0x9cf/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fixes: cd0277ed0c18 ("netfs: Use new folio_queue data type and iterator instead of xarray iter") Reported-by: syzbot+25b83a6f2c702075fcbc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=25b83a6f2c702075fcbc Signed-off-by: David Howells Link: https://lore.kernel.org/20250519090707.2848510-2-dhowells@redhat.com Tested-by: syzbot+25b83a6f2c702075fcbc@syzkaller.appspotmail.com cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 031fa5c9198929fd3a40bb7fb655f31ff71de86a Author: Dan Carpenter Date: Wed Apr 23 20:22:05 2025 +0300 rpmsg: qcom_smd: Fix uninitialized return variable in __qcom_smd_send() [ Upstream commit 5de775df3362090a6e90046d1f2d83fe62489aa0 ] The "ret" variable isn't initialized if we don't enter the loop. For example, if "channel->state" is not SMD_CHANNEL_OPENED. Fixes: 33e3820dda88 ("rpmsg: smd: Use spinlock in tx path") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/aAkhvV0nSbrsef1P@stanley.mountain Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4af0ad194c6f3a955706ea124ca595fdab2eec0c Author: Beleswar Padhi Date: Tue May 13 11:14:37 2025 +0530 remoteproc: k3-r5: Refactor sequential core power up/down operations [ Upstream commit 701177511abd295e0fc2499796e466d8ff12165c ] The existing implementation of the waiting mechanism in "k3_r5_cluster_rproc_init()" waits for the "released_from_reset" flag to be set as part of the firmware boot process in "k3_r5_rproc_start()". The "k3_r5_cluster_rproc_init()" function is invoked in the probe routine which causes unexpected failures in cases where the firmware is unavailable at boot time, resulting in probe failure and removal of the remoteproc handles in the sysfs paths. To address this, the waiting mechanism is refactored out of the probe routine into the appropriate "k3_r5_rproc_{prepare/unprepare}()" functions. This allows the probe routine to complete without depending on firmware booting, while still maintaining the required power-synchronization between cores. Further, this wait mechanism is dropped from "k3_r5_rproc_{start/stop}()" functions as they deal with Core Run/Halt operations, and as such, there is no constraint in Running or Halting the cores of a cluster in order. Fixes: 61f6f68447ab ("remoteproc: k3-r5: Wait for core0 power-up before powering up core1") Signed-off-by: Beleswar Padhi Tested-by: Judith Mendez Reviewed-by: Andrew Davis Link: https://lore.kernel.org/r/20250513054510.3439842-4-b-padhi@ti.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit c3267ee7ac02eba431efe07ac680c36b744c3489 Author: Siddharth Vadapalli Date: Tue May 13 11:14:36 2025 +0530 remoteproc: k3-dsp: Drop check performed in k3_dsp_rproc_{mbox_callback/kick} [ Upstream commit 349d62ab207f55f039c3ddb40b36e95c2f0b3ed0 ] Commit ea1d6fb5b571 ("remoteproc: k3-dsp: Acquire mailbox handle during probe routine") introduced a check in the "k3_dsp_rproc_mbox_callback()" and "k3_dsp_rproc_kick()" callbacks, causing them to exit if the remote core's state is "RPROC_DETACHED". However, the "__rproc_attach()" function that is responsible for attaching to a remote core, updates the state of the remote core to "RPROC_ATTACHED" only after invoking "rproc_start_subdevices()". The "rproc_start_subdevices()" function triggers the probe of the Virtio RPMsg devices associated with the remote core, which require that the "k3_dsp_rproc_kick()" and "k3_dsp_rproc_mbox_callback()" callbacks are functional. Hence, drop the check in the callbacks. Fixes: ea1d6fb5b571 ("remoteproc: k3-dsp: Acquire mailbox handle during probe routine") Signed-off-by: Siddharth Vadapalli Signed-off-by: Beleswar Padhi Tested-by: Judith Mendez Reviewed-by: Andrew Davis Link: https://lore.kernel.org/r/20250513054510.3439842-3-b-padhi@ti.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit aa33fd51cb50f886f41b924e1c0e568f365b683d Author: Siddharth Vadapalli Date: Tue May 13 11:14:35 2025 +0530 remoteproc: k3-r5: Drop check performed in k3_r5_rproc_{mbox_callback/kick} [ Upstream commit 9995dbfc2235efabdb3759606d522e1a7ec3bdcb ] Commit f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during probe routine") introduced a check in the "k3_r5_rproc_mbox_callback()" and "k3_r5_rproc_kick()" callbacks, causing them to exit if the remote core's state is "RPROC_DETACHED". However, the "__rproc_attach()" function that is responsible for attaching to a remote core, updates the state of the remote core to "RPROC_ATTACHED" only after invoking "rproc_start_subdevices()". The "rproc_start_subdevices()" function triggers the probe of the Virtio RPMsg devices associated with the remote core, which require that the "k3_r5_rproc_kick()" and "k3_r5_rproc_mbox_callback()" callbacks are functional. Hence, drop the check in the callbacks. Fixes: f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during probe routine") Signed-off-by: Siddharth Vadapalli Signed-off-by: Beleswar Padhi Tested-by: Judith Mendez Reviewed-by: Andrew Davis Link: https://lore.kernel.org/r/20250513054510.3439842-2-b-padhi@ti.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit e54bd0f3238fc2c967defc6d80a64029599c9952 Author: James Clark Date: Tue May 13 10:57:30 2025 +0100 perf tools: Fix arm64 source package build [ Upstream commit aea3496bbc7c20037ecc35411264de109d700fc7 ] Syscall tables are generated from rules in the kernel tree. Add the related files to the MANIFEST to fix the Perf source package build. Reported-by: Arnaldo Carvalho de Melo Fixes: bfb713ea53c746b0 ("perf tools: Fix arm64 build by generating unistd_64.h") Signed-off-by: James Clark Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250513-james-perf-src-pkg-fix-v1-1-bcfd0486dbd6@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1c2a25b5cfb7b72d7d7cebba317dfb458f69ec7e Author: Dan Carpenter Date: Wed Apr 2 13:59:51 2025 +0300 remoteproc: qcom_wcnss_iris: Add missing put_device() on error in probe [ Upstream commit 0cb4b1b97041d8a1f773425208ded253c1cb5869 ] The device_del() call matches with the device_add() but we also need to call put_device() to trigger the qcom_iris_release(). Fixes: 1fcef985c8bd ("remoteproc: qcom: wcnss: Fix race with iris probe") Signed-off-by: Dan Carpenter Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/4604f7e0-3217-4095-b28a-3ff8b5afad3a@stanley.mountain Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b29c324b8a4f84338a07da6706d43e0a1b87dba7 Author: Adrian Hunter Date: Mon May 12 12:39:32 2025 +0300 perf scripts python: exported-sql-viewer.py: Fix pattern matching with Python 3 [ Upstream commit 17e548405a81665fd14cee960db7d093d1396400 ] The script allows the user to enter patterns to find symbols. The pattern matching characters are converted for use in SQL. For PostgreSQL the conversion involves using the Python maketrans() method which is slightly different in Python 3 compared with Python 2. Fix to work in Python 3. Fixes: beda0e725e5f06ac ("perf script python: Add Python3 support to exported-sql-viewer.py") Signed-off-by: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Tony Jones Link: https://lore.kernel.org/r/20250512093932.79854-4-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 8b0c60e6e85e7d08bbb7660c2219368ba2fa8a42 Author: Adrian Hunter Date: Mon May 12 12:39:30 2025 +0300 perf intel-pt: Fix PEBS-via-PT data_src [ Upstream commit e00eac6b5b6d956f38d8880c44bf7fd9954063c3 ] The Fixes commit did not add support for decoding PEBS-via-PT data_src. Fix by adding support. PEBS-via-PT is a feature of some E-core processors, starting with processors based on Tremont microarchitecture. Because the kernel only supports Intel PT features that are on all processors, there is no support for PEBS-via-PT on hybrids. Currently that leaves processors based on Tremont, Gracemont and Crestmont, however there are no events on Tremont that produce data_src information, and for Gracemont and Crestmont there are only: mem-loads event=0xd0,umask=0x5,ldlat=3 mem-stores event=0xd0,umask=0x6 Affected processors include Alder Lake N (Gracemont), Sierra Forest (Crestmont) and Grand Ridge (Crestmont). Example: # perf record -d -e intel_pt/branch=0/ -e mem-loads/aux-output/pp uname Before: # perf.before script --itrace=o -Fdata_src 0 |OP No|LVL N/A|SNP N/A|TLB N/A|LCK No|BLK N/A 0 |OP No|LVL N/A|SNP N/A|TLB N/A|LCK No|BLK N/A After: # perf script --itrace=o -Fdata_src 10268100142 |OP LOAD|LVL L1 hit|SNP None|TLB L1 or L2 hit|LCK No|BLK N/A 10450100442 |OP LOAD|LVL L2 hit|SNP None|TLB L2 miss|LCK No|BLK N/A Fixes: 975846eddf907297 ("perf intel-pt: Add memory information to synthesized PEBS sample") Reviewed-by: Kan Liang Signed-off-by: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Jiri Olsa Cc: Namhyung Kim Link: https://lore.kernel.org/r/20250512093932.79854-2-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7ba4b429105bf28336d6ed1c2762a3837f7ca659 Author: Michael Petlan Date: Mon Jan 13 19:26:00 2025 +0100 perf tests: Fix 'perf report' tests installation [ Upstream commit 4bfe27140edf8dd1322326c79f5ae8d29ff7e43d ] There was a copy-paste mistake in the installation commands. Also, we need to install stderr-whitelist.txt file, which contains allowed messages that are printed on stderr and should not cause test fail. Fixes: 097fe67df1aa9cc7 ("perf testsuite: Install perf-report tests in the 'make install-tests -C tools/perf' target") Signed-off-by: Michael Petlan Cc: Ian Rogers Cc: Namhyung Kim Link: https://lore.kernel.org/r/20250113182605.130719-6-vmolnaro@redhat.com Signed-off-by: Veronika Molnarova Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f3bdca84c7ade1b6a61ad06ddb682360dbdab20b Author: Namhyung Kim Date: Wed Apr 2 22:42:13 2025 -0700 perf trace: Fix leaks of 'struct thread' in set_filter_loop_pids() [ Upstream commit 30d20fb1f84ad5c92706fe2c6cbb2d4cc293e671 ] I've found some leaks from 'perf trace -a'. It seems there are more leaks but this is what I can find for now. Fixes: 082ab9a18e532864 ("perf trace: Filter out 'sshd' in the tracer ancestry in syswide tracing") Reviewed-by: Howard Chu Signed-off-by: Namhyung Kim Cc: Adrian Hunter Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250403054213.7021-1-namhyung@kernel.org [ split from a larget patch ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 832af8a252d37d7bdf0b34a648d40a82662102e0 Author: Namhyung Kim Date: Wed Apr 2 22:42:13 2025 -0700 perf trace: Fix leaks of 'struct thread' in fprintf_sys_enter() [ Upstream commit bb3de7fa988c1b315ab8e87dc74e0d088284f142 ] I've found some leaks from 'perf trace -a'. It seems there are more leaks but this is what I can find for now. Fixes: 70351029b55677eb ("perf thread: Add support for reading the e_machine type for a thread") Reviewed-by: Howard Chu Signed-off-by: Namhyung Kim Cc: Adrian Hunter Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250403054213.7021-1-namhyung@kernel.org [ split from a larget patch ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b7e80128bbf42c2f254d235f32b0c1cd2c042f38 Author: Benjamin Marzinski Date: Tue Apr 22 19:47:38 2025 -0400 dm-flakey: make corrupting read bios work [ Upstream commit 13e79076c89f6e96a6cca8f6df38b40d025907b4 ] dm-flakey corrupts the read bios in the endio function. However, the corrupt_bio_* functions checked bio_has_data() to see if there was data to corrupt. Since this was the endio function, there was no data left to complete, so bio_has_data() was always false. Fix this by saving a copy of the bio's bi_iter in flakey_map(), and using this to initialize the iter for corrupting the read bios. This patch also skips cloning the bio for write bios with no data. Reported-by: Kent Overstreet Fixes: a3998799fb4df ("dm flakey: add corrupt_bio_byte feature") Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit b1731277cbceba04f27b28cb7e182353dde855df Author: Benjamin Marzinski Date: Tue Apr 22 19:47:36 2025 -0400 dm-flakey: error all IOs when num_features is absent [ Upstream commit 40ed054f39bc99eac09871c33198e501f4acdf24 ] dm-flakey would error all IOs if num_features was 0, but if it was absent, dm-flakey would never error any IO. Fix this so that no num_features works the same as num_features set to 0. Fixes: aa7d7bc99fed7 ("dm flakey: add an "error_reads" option") Reported-by: Kent Overstreet Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit ac8acb0bfd98a1c65f3ca9a3e217a766124eebd8 Author: Benjamin Marzinski Date: Thu Apr 10 15:49:42 2025 -0400 dm: limit swapping tables for devices with zone write plugs [ Upstream commit 121218bef4c1df165181f5cd8fc3a2246bac817e ] dm_revalidate_zones() only allowed new or previously unzoned devices to call blk_revalidate_disk_zones(). If the device was already zoned, disk->nr_zones would always equal md->nr_zones, so dm_revalidate_zones() returned without doing any work. This would make the zoned settings for the device not match the new table. If the device had zone write plug resources, it could run into errors like bdev_zone_is_seq() reading invalid memory because disk->conv_zones_bitmap was the wrong size. If the device doesn't have any zone write plug resources, calling blk_revalidate_disk_zones() will always correctly update device. If blk_revalidate_disk_zones() fails, it can still overwrite or clear the current disk->nr_zones value. In this case, DM must restore the previous value of disk->nr_zones, so that the zoned settings will continue to match the previous value that it fell back to. If the device already has zone write plug resources, blk_revalidate_disk_zones() will not correctly update them, if it is called for arbitrary zoned device changes. Since there is not much need for this ability, the easiest solution is to disallow any table reloads that change the zoned settings, for devices that already have zone plug resources. Specifically, if a device already has zone plug resources allocated, it can only switch to another zoned table that also emulates zone append. Also, it cannot change the device size or the zone size. A device can switch to an error target. Fixes: bb37d77239af2 ("dm: introduce zone append emulation") Reviewed-by: Damien Le Moal Tested-by: Damien Le Moal Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit d19bc1b4dd5f322980b1f05f79b2ea4f0db10920 Author: Benjamin Marzinski Date: Thu Apr 10 15:49:41 2025 -0400 dm: fix dm_blk_report_zones [ Upstream commit 37f53a2c60d03743e0eacf7a0c01c279776fef4e ] If dm_get_live_table() returned NULL, dm_put_live_table() was never called. Also, it is possible that md->zone_revalidate_map will change while calling this function. Only read it once, so that we are always using the same value. Otherwise we might miss a call to dm_put_live_table(). Finally, while md->zone_revalidate_map is set and a process is calling blk_revalidate_disk_zones() to set up the zone append emulation resources, it is possible that another process, perhaps triggered by blkdev_report_zones_ioctl(), will call dm_blk_report_zones(). If blk_revalidate_disk_zones() fails, these resources can be freed while the other process is still using them, causing a use-after-free error. blk_revalidate_disk_zones() will only ever be called when initially setting up the zone append emulation resources, such as when setting up a zoned dm-crypt table for the first time. Further table swaps will not set md->zone_revalidate_map or call blk_revalidate_disk_zones(). However it must be called using the new table (referenced by md->zone_revalidate_map) and the new queue limits while the DM device is suspended. dm_blk_report_zones() needs some way to distinguish between a call from blk_revalidate_disk_zones(), which must be allowed to use md->zone_revalidate_map to access this not yet activated table, and all other calls to dm_blk_report_zones(), which should not be allowed while the device is suspended and cannot use md->zone_revalidate_map, since the zone resources might be freed by the process currently calling blk_revalidate_disk_zones(). Solve this by tracking the process that sets md->zone_revalidate_map in dm_revalidate_zones() and only allowing that process to make use of it in dm_blk_report_zones(). Fixes: f211268ed1f9b ("dm: Use the block layer zone append emulation") Reviewed-by: Damien Le Moal Tested-by: Damien Le Moal Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 6a2eb44bbe66e7de2cee3b69a9e609c72bdac5d1 Author: Ian Rogers Date: Thu May 1 00:00:03 2025 -0700 perf symbol-minimal: Fix double free in filename__read_build_id [ Upstream commit fa9c4977fbfbca182f9e410d57b3f98356a9d917 ] Running the "perf script task-analyzer tests" with address sanitizer showed a double free: ``` FAIL: "test_csv_extended_times" Error message: "Failed to find required string:'Out-Out;'." ================================================================= ==19190==ERROR: AddressSanitizer: attempting double-free on 0x50b000017b10 in thread T0: #0 0x55da9601c78a in free (perf+0x26078a) (BuildId: e7ef50e08970f017a96fde6101c5e2491acc674a) #1 0x55da96640c63 in filename__read_build_id tools/perf/util/symbol-minimal.c:221:2 0x50b000017b10 is located 0 bytes inside of 112-byte region [0x50b000017b10,0x50b000017b80) freed by thread T0 here: #0 0x55da9601ce40 in realloc (perf+0x260e40) (BuildId: e7ef50e08970f017a96fde6101c5e2491acc674a) #1 0x55da96640ad6 in filename__read_build_id tools/perf/util/symbol-minimal.c:204:10 previously allocated by thread T0 here: #0 0x55da9601ca23 in malloc (perf+0x260a23) (BuildId: e7ef50e08970f017a96fde6101c5e2491acc674a) #1 0x55da966407e7 in filename__read_build_id tools/perf/util/symbol-minimal.c:181:9 SUMMARY: AddressSanitizer: double-free (perf+0x26078a) (BuildId: e7ef50e08970f017a96fde6101c5e2491acc674a) in free ==19190==ABORTING FAIL: "invocation of perf script report task-analyzer --csv-summary csvsummary --summary-extended command failed" Error message: "" FAIL: "test_csvsummary_extended" Error message: "Failed to find required string:'Out-Out;'." ---- end(-1) ---- 132: perf script task-analyzer tests : FAILED! ``` The buf_size if always set to phdr->p_filesz, but that may be 0 causing a free and realloc to return NULL. This is treated in filename__read_build_id like a failure and the buffer is freed again. To avoid this problem only grow buf, meaning the buf_size will never be 0. This also reduces the number of memory (re)allocations. Fixes: b691f64360ecec49 ("perf symbols: Implement poor man's ELF parser") Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250501070003.22251-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7eeb3df6f07a886bdfd52757ede127a59a8784dc Author: Alexei Safin Date: Thu Apr 24 23:26:54 2025 +0300 hwmon: (asus-ec-sensors) check sensor index in read_string() [ Upstream commit 25be318324563c63cbd9cb53186203a08d2f83a1 ] Prevent a potential invalid memory access when the requested sensor is not found. find_ec_sensor_index() may return a negative value (e.g. -ENOENT), but its result was used without checking, which could lead to undefined behavior when passed to get_sensor_info(). Add a proper check to return -EINVAL if sensor_index is negative. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d0ddfd241e57 ("hwmon: (asus-ec-sensors) add driver for ASUS EC") Signed-off-by: Alexei Safin Link: https://lore.kernel.org/r/20250424202654.5902-1-a.safin@rosa.ru [groeck: Return error code returned from find_ec_sensor_index] Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 49482f4a39620f6afedcd3f6aa9e0d558b6a460b Author: Mikhail Arkhipov Date: Wed Apr 9 00:39:06 2025 +0300 mtd: nand: ecc-mxic: Fix use of uninitialized variable ret [ Upstream commit d95846350aac72303036a70c4cdc69ae314aa26d ] If ctx->steps is zero, the loop processing ECC steps is skipped, and the variable ret remains uninitialized. It is later checked and returned, which leads to undefined behavior and may cause unpredictable results in user space or kernel crashes. This scenario can be triggered in edge cases such as misconfigured geometry, ECC engine misuse, or if ctx->steps is not validated after initialization. Initialize ret to zero before the loop to ensure correct and safe behavior regardless of the ctx->steps value. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 48e6633a9fa2 ("mtd: nand: mxic-ecc: Add Macronix external ECC engine support") Signed-off-by: Mikhail Arkhipov Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 4bfb6060e29376966c0006fdf7b4aaf9ec23d4ac Author: Thomas Richter Date: Thu Apr 24 15:33:10 2025 +0200 perf tests metric-only perf stat: Fix tests 84 and 86 s390 [ Upstream commit ccd4b5cdf00f358acae9f396d13029e7ae78522e ] On s390x KVM and z/VM machines the CPU Measurement Facility is not available. Events cycles and instructions do not exist. Running above tests on s390 KVM and z/VM guests always fail with this error: # ./perf test 84 86 84: perf stat JSON output linter : FAILED! 86: perf stat STD output linter : FAILED! # Root cause is command: # perf stat -j --metric-only -e instructions,cycles -- true {"metric-value" : "none"} # Which fails due to unsupported events and returns "none". Do not execute this test case on s390 KVM and z/VM machines. Output after: # ./perf test 84 86 84: perf stat JSON output linter : Ok 86: perf stat STD output linter : Ok # Fixes: 45a86d017adf4d6c ("perf test: Add --metric-only to perf stat output tests") Suggested-by: Heiko Carstens Suggested-by: Sumanth Korikkar Reviewed-by: Sumanth Korikkar Signed-off-by: Thomas Richter Cc: Alexander Gordeev Cc: Namhyung Kim Cc: Vasily Gorbik Link: https://lore.kernel.org/r/20250424133310.37452-1-tmricht@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 980f15017894f7a8a2d4217bc6696428d4d1dc6a Author: Ian Rogers Date: Tue Apr 22 22:03:58 2025 -0700 perf tool_pmu: Fix aggregation on duration_time [ Upstream commit 68cb1567439fa325ba980f3b5b67f95d3953eafd ] evsel__count_has_error() fails counters when the enabled or running time are 0. The duration_time event reads 0 when the cpu_map_idx != 0 to avoid aggregating time over CPUs. Change the enable and running time to always have a ratio of 100% so that evsel__count_has_error won't fail. Before: ``` $ sudo /tmp/perf/perf stat --per-core -a -M UNCORE_FREQ sleep 1 Performance counter stats for 'system wide': S0-D0-C0 1 2,615,819,485 UNC_CLOCK.SOCKET # 2.61 UNCORE_FREQ S0-D0-C0 2 duration_time 1.002111784 seconds time elapsed ``` After: ``` $ perf stat --per-core -a -M UNCORE_FREQ sleep 1 Performance counter stats for 'system wide': S0-D0-C0 1 758,160,296 UNC_CLOCK.SOCKET # 0.76 UNCORE_FREQ S0-D0-C0 2 1,003,438,246 duration_time 1.002486017 seconds time elapsed ``` Note: the metric reads the value a different way and isn't impacted. Fixes: 240505b2d0adcdc8 ("perf tool_pmu: Factor tool events into their own PMU") Reported-by: Stephane Eranian Reviewed-by: James Clark Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Thomas Richter Link: https://lore.kernel.org/r/20250423050358.94310-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 0af01ed5d0607a81101d906d2677999b7c4db719 Author: Sean Christopherson Date: Tue Apr 1 09:34:40 2025 -0700 x86/irq: Ensure initial PIR loads are performed exactly once [ Upstream commit 600e9606046ac3b9b7a3f0500d08a179df84c45e ] Ensure the PIR is read exactly once at the start of handle_pending_pir(), to guarantee that checking for an outstanding posted interrupt in a given chuck doesn't reload the chunk from the "real" PIR. Functionally, a reload is benign, but it would defeat the purpose of pre-loading into a copy. Fixes: 1b03d82ba15e ("x86/irq: Install posted MSI notification handler") Reviewed-by: Thomas Gleixner Link: https://lore.kernel.org/r/20250401163447.846608-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit 1944078e50a2ea288eb085aca44cbba4feacc90d Author: Geert Uytterhoeven Date: Thu Apr 10 10:30:57 2025 +0200 HID: HID_APPLETB_BL should depend on X86 [ Upstream commit de7ad66b16b4d397593eafbbb09e9557b558a7e3 ] The Apple Touch Bar is only present on x86 MacBook Pros. Hence add a dependency on X86, to prevent asking the user about this driver when configuring a kernel for a different architecture. Fixes: 1fd41e5e3d7cc556 ("HID: hid-appletb-bl: add driver for the backlight of Apple Touch Bars") Signed-off-by: Geert Uytterhoeven Reviewed-by: Aditya Garg Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 632145e230f10f7ae8f3797b22b20dc0de89e49a Author: Geert Uytterhoeven Date: Thu Apr 10 10:30:56 2025 +0200 HID: HID_APPLETB_KBD should depend on X86 [ Upstream commit 2a647d400afecdf12ba5905424e1337fbc2d6750 ] The Apple Touch Bar is only present on x86 MacBook Pros. Hence add a dependency on X86, to prevent asking the user about this driver when configuring a kernel for a different architecture. Fixes: 8e9b9152cfbdc2a9 ("HID: hid-appletb-kbd: add driver for the keyboard mode of Apple Touch Bars") Signed-off-by: Geert Uytterhoeven Reviewed-by: Aditya Garg Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 9617e02ca67f560e9c106beec6e0ea9afb47179e Author: Wentao Guan Date: Thu Apr 17 21:50:23 2025 +0800 HID: intel-thc-hid: intel-quicki2c: pass correct arguments to acpi_evaluate_object [ Upstream commit 37d66cf07871927ea682c491b9e9a12dd73e6b5b ] Delete unused argument, pass correct argument to acpi_evaluate_object. Log: intel_quicki2c 0000:00:10.0: enabling device (0000 -> 0002) ACPI: \_SB.PC00.THC0.ICRS: 1 arguments were passed to a non-method ACPI object (Buffer) (20230628/nsarguments-211) ACPI: \_SB.PC00.THC0.ISUB: 1 arguments were passed to a non-method ACPI object (Buffer) (20230628/nsarguments-211) Fixes: 5282e45ccbfa ("HID: intel-thc-hid: intel-quicki2c: Add THC QuickI2C ACPI interfaces") Signed-off-by: Wentao Guan Signed-off-by: WangYuli Reviewed-by: Even Xu Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 4a715be3fe80b68fa55cb3569af3d294be101626 Author: Henry Martin Date: Tue Apr 1 17:16:47 2025 +0800 backlight: pm8941: Add NULL check in wled_configure() [ Upstream commit e12d3e1624a02706cdd3628bbf5668827214fa33 ] devm_kasprintf() returns NULL when memory allocation fails. Currently, wled_configure() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: f86b77583d88 ("backlight: pm8941: Convert to using %pOFn instead of device_node.name") Signed-off-by: Henry Martin Reviewed-by: Dmitry Baryshkov Reviewed-by: "Daniel Thompson (RISCstar)" Link: https://lore.kernel.org/r/20250401091647.22784-1-bsdhenrymartin@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 3119faa5ad50e91345fe4ed9517a2c03ba76450b Author: Benjamin Marzinski Date: Thu Apr 10 15:49:40 2025 -0400 dm: handle failures in dm_table_set_restrictions [ Upstream commit 4ea30ec6fb3bb598bd1df04cdfab13b1140074d2 ] If dm_table_set_restrictions() fails while swapping tables, device-mapper will continue using the previous table. It must be sure to leave the mapped_device in it's previous state on failure. Otherwise device-mapper could end up using the old table with settings from the unused table. Do not update the mapped device in dm_set_zones_restrictions(). Wait till after dm_table_set_restrictions() is sure to succeed to update the md zoned settings. Do the same with the dax settings, and if dm_revalidate_zones() fails, restore the original queue limits. Fixes: 7f91ccd8a608d ("dm: Call dm_revalidate_zones() after setting the queue limits") Reviewed-by: Damien Le Moal Tested-by: Damien Le Moal Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 32e26cc61ed9b882ea4ce74353283c535ab22566 Author: Benjamin Marzinski Date: Thu Apr 10 15:49:39 2025 -0400 dm: free table mempools if not used in __bind [ Upstream commit e8819e7f03470c5b468720630d9e4e1d5b99159e ] With request-based dm, the mempools don't need reloading when switching tables, but the unused table mempools are not freed until the active table is finally freed. Free them immediately if they are not needed. Fixes: 29dec90a0f1d9 ("dm: fix bio_set allocation") Reviewed-by: Damien Le Moal Tested-by: Damien Le Moal Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 5e87a26a7f0a5ef1ed05cd2d78f467fcfecba7ae Author: Benjamin Marzinski Date: Thu Apr 10 15:49:38 2025 -0400 dm: don't change md if dm_table_set_restrictions() fails [ Upstream commit 9eb7109a5bfc5b8226e9517e9f3cc6d414391884 ] __bind was changing the disk capacity, geometry and mempools of the mapped device before calling dm_table_set_restrictions() which could fail, forcing dm to drop the new table. Failing here would leave the device using the old table but with the wrong capacity and mempools. Move dm_table_set_restrictions() earlier in __bind(). Since it needs the capacity to be set, save the old version and restore it on failure. Fixes: bb37d77239af2 ("dm: introduce zone append emulation") Reviewed-by: Damien Le Moal Tested-by: Damien Le Moal Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit ac1dad53aca4810e3401a14d02c76a7c6398c98d Author: Arnaldo Carvalho de Melo Date: Wed Apr 9 21:58:19 2025 -0300 perf ui browser hists: Set actions->thread before calling do_zoom_thread() [ Upstream commit 1741189d843a1d5ef38538bc52a3760e2e46cb2e ] In 7cecb7fe8388d5c3 ("perf hists: Move sort__has_comm into struct perf_hpp_list") it assumes that act->thread is set prior to calling do_zoom_thread(). This doesn't happen when we use ESC or the Left arrow key to Zoom out of a specific thread, making this operation not to work and we get stuck into the thread zoom. In 6422184b087ff435 ("perf hists browser: Simplify zooming code using pstack_peek()") it says no need to set actions->thread, and at that point that was true, but in 7cecb7fe8388d5c3 a actions->thread == NULL check was added before the zoom out of thread could kick in. We can zoom out using the alternative 't' thread zoom toggle hotkey to finally set actions->thread before calling do_zoom_thread() and zoom out, but lets also fix the ESC/Zoom out of thread case. Fixes: 7cecb7fe8388d5c3 ("perf hists: Move sort__has_comm into struct perf_hpp_list") Reported-by: Ingo Molnar Tested-by: Ingo Molnar Cc: Adrian Hunter Cc: Ian Rogers Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Link: https://lore.kernel.org/r/Z_TYux5fUg2pW-pF@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 38b7e7c15515c80d5e4d6919798a63ea3cc0b2d9 Author: Arnaldo Carvalho de Melo Date: Tue Apr 8 15:03:11 2025 -0300 tools build: Don't show libbfd build status as it is opt-in [ Upstream commit e0eb84cd518084582c0d1db5d904f31b16902fdc ] Since dd317df072071903 ("perf build: Make binutil libraries opt in") doesn't try to build with binutils libraries, so showing that it is OFF when building causes just distraction, remove it from FEATURES_DISPLAY. For people that for some reason notice that there is always 'perf -vv', a short hand for 'perf version --build-options' and 'perf check feature libbfd' that now explains why it is not built: $ perf check feature libbfd libbfd: [ OFF ] # HAVE_LIBBFD_SUPPORT ( tip: Deprecated, license incompatibility, use BUILD_NONDISTRO=1 and install binutils-dev[el] ) $ Fixes: dd317df072071903 ("perf build: Make binutil libraries opt in") Tested-by: Ingo Molnar Cc: Adrian Hunter Cc: Dmitriy Vyukov Cc: Howard Chu Cc: Ian Rogers Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/Z--pWmTHGb62_83e@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 9f54a3878959729b15c4a4a10dabafccba634ff7 Author: Arnaldo Carvalho de Melo Date: Tue Apr 8 11:37:20 2025 -0300 perf build: Warn when libdebuginfod devel files are not available [ Upstream commit 4fce4b91fd1aabb326c46e237eb4b19ab72598f8 ] While working on 'perf version --build-options' I noticed that: $ perf version --build-options perf version 6.15.rc1.g312a07a00d31 aio: [ on ] # HAVE_AIO_SUPPORT bpf: [ on ] # HAVE_LIBBPF_SUPPORT bpf_skeletons: [ on ] # HAVE_BPF_SKEL debuginfod: [ OFF ] # HAVE_DEBUGINFOD_SUPPORT And looking at tools/perf/Makefile.config I also noticed that it is not opt-in, meaning we will attempt to build with it in all normal cases. So add the usual warning at build time to let the user know that something recommended is missing, now we see: Makefile.config:563: No elfutils/debuginfod.h found, no debuginfo server support, please install elfutils-debuginfod-client-devel or equivalent And after following the recommendation: $ perf check feature debuginfod debuginfod: [ on ] # HAVE_DEBUGINFOD_SUPPORT $ ldd ~/bin/perf | grep debuginfo libdebuginfod.so.1 => /lib64/libdebuginfod.so.1 (0x00007fee5cf5f000) $ With this feature on several perf tools will fetch what is needed and not require all the contents of the debuginfo packages, for instance: # rpm -qa | grep kernel-debuginfo # pahole --running_kernel_vmlinux pahole: couldn't find a vmlinux that matches the running kernel HINT: Maybe you're inside a container or missing a debuginfo package? # # perf trace -e open* perf probe --vars icmp_rcv 0.000 ( 0.005 ms): perf/97391 openat(dfd: CWD, filename: "/etc/ld.so.cache", flags: RDONLY|CLOEXEC) = 3 0.014 ( 0.004 ms): perf/97391 openat(dfd: CWD, filename: "/lib64/libm.so.6", flags: RDONLY|CLOEXEC) = 3 32130.100 ( 0.008 ms): perf/97391 openat(dfd: CWD, filename: "/root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo") = 3 Available variables at icmp_rcv @ struct sk_buff* skb # # pahole --running_kernel_vmlinux /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo # file /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=aa3c82b4a13f9c0e0301bebb20fe958c4db6f362, with debug_info, not stripped # ls -la /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo -r--------. 1 root root 475401512 Mar 27 21:00 /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo # Then, cached: # perf stat --null perf probe --vars icmp_rcv Available variables at icmp_rcv @ struct sk_buff* skb Performance counter stats for 'perf probe --vars icmp_rcv': 0.671389041 seconds time elapsed 0.519176000 seconds user 0.150860000 seconds sys Fixes: c7a14fdcb3fa7736 ("perf build-ids: Fall back to debuginfod query if debuginfo not found") Tested-by: Ingo Molnar Cc: Adrian Hunter Cc: Dmitriy Vyukov Cc: Howard Chu Cc: Ian Rogers Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Frank Ch. Eigler Link: https://lore.kernel.org/r/Z_dkNDj9EPFwPqq1@gmail.com [ Folded patch from Ingo to have the debian/ubuntu devel package added build warning message ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 4c775e56c0cb07ccb5d88ea0d1beea7f42cb4b27 Author: Arnaldo Carvalho de Melo Date: Tue Apr 8 15:03:11 2025 -0300 tools build: Don't show libunwind build status as it is opt-in [ Upstream commit a3a40391292273cf78a7920c119cdc386d694c38 ] Since 13e17c9ff49119aa ("perf build: Make libunwind opt-in rather than opt-out") doesn't try to build with libunwind, so showing that it is OFF when building causes just distraction, remove it from FEATURES_DISPLAY. For people that for some reason notice that there is always 'perf -vv', a short hand for 'perf version --build-options' and 'perf check feature libunwind' that now explains why it is not built: $ perf check feature libunwind libunwind: [ OFF ] # HAVE_LIBUNWIND_SUPPORT ( tip: Deprecated, use LIBUNWIND=1 and install libunwind-dev[el] to build with it ) $ Fixes: 13e17c9ff49119aa ("perf build: Make libunwind opt-in rather than opt-out") Reported-by: Ingo Molnar Tested-by: Ingo Molnar Cc: Adrian Hunter Cc: Dmitriy Vyukov Cc: Howard Chu Cc: Ian Rogers Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/Z--pWmTHGb62_83e@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1227324427b55311fa6a70c91616d5e420f6ff93 Author: Arnaldo Carvalho de Melo Date: Fri Apr 4 15:37:45 2025 -0300 tools build: Don't set libunwind as available if test-all.c build succeeds [ Upstream commit 6559b83e4e71ba77461c8d6e6af7b89693c8e677 ] The tools/build/feature/test-all.c file tries to detect the expected, most common set of libraries/features we expect to have available to build perf with. At some point libunwind was deemed not to be part of that set of libries, but the patches making it to be opt-in ended up forgetting some details, fix one more. Testing it: $ rm -rf /tmp/build/$(basename $PWD)/ ; mkdir -p /tmp/build/$(basename $PWD)/ $ rpm -q libunwind-devel libunwind-devel-1.8.0-3.fc40.x86_64 $ make -k LIBUNWIND=1 CORESIGHT=1 O=/tmp/build/$(basename $PWD)/ -C tools/perf install-bin |& grep unwind && ldd ~/bin/perf | grep unwind ... libunwind: [ on ] CC /tmp/build/perf-tools-next/arch/x86/tests/dwarf-unwind.o CC /tmp/build/perf-tools-next/arch/x86/util/unwind-libunwind.o CC /tmp/build/perf-tools-next/util/arm64-frame-pointer-unwind-support.o CC /tmp/build/perf-tools-next/tests/dwarf-unwind.o CC /tmp/build/perf-tools-next/util/unwind-libunwind-local.o CC /tmp/build/perf-tools-next/util/unwind-libunwind.o libunwind-x86_64.so.8 => /lib64/libunwind-x86_64.so.8 (0x00007f615a549000) libunwind.so.8 => /lib64/libunwind.so.8 (0x00007f615a52f000) $ sudo rpm -e libunwind-devel $ rm -rf /tmp/build/$(basename $PWD)/ ; mkdir -p /tmp/build/$(basename $PWD)/ $ make -k LIBUNWIND=1 CORESIGHT=1 O=/tmp/build/$(basename $PWD)/ -C tools/perf install-bin |& grep unwind && ldd ~/bin/perf | grep unwind Makefile.config:653: No libunwind found. Please install libunwind-dev[el] >= 1.1 and/or set LIBUNWIND_DIR ... libunwind: [ OFF ] CC /tmp/build/perf-tools-next/arch/x86/tests/dwarf-unwind.o CC /tmp/build/perf-tools-next/arch/x86/util/unwind-libdw.o CC /tmp/build/perf-tools-next/util/arm64-frame-pointer-unwind-support.o CC /tmp/build/perf-tools-next/tests/dwarf-unwind.o CC /tmp/build/perf-tools-next/util/unwind-libdw.o $ Should be in a separate patch, but tired now, so also adding a message about the need to use LIBUNWIND=1 in the output when its not available, so done here as well. So, now when the devel files are not available we get: $ make -k LIBUNWIND=1 CORESIGHT=1 O=/tmp/build/$(basename $PWD)/ -C tools/perf install-bin |& grep unwind && ldd ~/bin/perf | grep unwind Makefile.config:653: No libunwind found. Please install libunwind-dev[el] >= 1.1 and/or set LIBUNWIND_DIR and set LIBUNWIND=1 in the make command line as it is opt-in now ... libunwind: [ OFF ] $ Fixes: 13e17c9ff49119aa ("perf build: Make libunwind opt-in rather than opt-out") Reported-by: Ingo Molnar Tested-by: Ingo Molnar Cc: Adrian Hunter Cc: Dmitriy Vyukov Cc: Ian Rogers Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/Z_AnsW9oJzFbhIFC@x1 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit a255510f001905cfef7095aaadcfa3feb78e15c6 Author: Kees Cook Date: Fri May 30 15:18:28 2025 -0700 randstruct: gcc-plugin: Fix attribute addition [ Upstream commit f39f18f3c3531aa802b58a20d39d96e82eb96c14 ] Based on changes in the 2021 public version of the randstruct out-of-tree GCC plugin[1], more carefully update the attributes on resulting decls, to avoid tripping checks in GCC 15's comptypes_check_enum_int() when it has been configured with "--enable-checking=misc": arch/arm64/kernel/kexec_image.c:132:14: internal compiler error: in comptypes_check_enum_int, at c/c-typeck.cc:1519 132 | const struct kexec_file_ops kexec_image_ops = { | ^~~~~~~~~~~~~~ internal_error(char const*, ...), at gcc/gcc/diagnostic-global-context.cc:517 fancy_abort(char const*, int, char const*), at gcc/gcc/diagnostic.cc:1803 comptypes_check_enum_int(tree_node*, tree_node*, bool*), at gcc/gcc/c/c-typeck.cc:1519 ... Link: https://archive.org/download/grsecurity/grsecurity-3.1-5.10.41-202105280954.patch.gz [1] Reported-by: Thiago Jung Bauermann Closes: https://github.com/KSPP/linux/issues/367 Closes: https://lore.kernel.org/lkml/20250530000646.104457-1-thiago.bauermann@linaro.org/ Reported-by: Ingo Saitz Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104745 Fixes: 313dd1b62921 ("gcc-plugins: Add the randstruct plugin") Tested-by: Thiago Jung Bauermann Link: https://lore.kernel.org/r/20250530221824.work.623-kees@kernel.org Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 4fb27da8a1508111057ca110d0bde80c396dd5cb Author: Kees Cook Date: Sat Apr 26 00:37:52 2025 -0700 randstruct: gcc-plugin: Remove bogus void member [ Upstream commit e136a4062174a9a8d1c1447ca040ea81accfa6a8 ] When building the randomized replacement tree of struct members, the randstruct GCC plugin would insert, as the first member, a 0-sized void member. This appears as though it was done to catch non-designated ("unnamed") static initializers, which wouldn't be stable since they depend on the original struct layout order. This was accomplished by having the side-effect of the "void member" tripping an assert in GCC internals (count_type_elements) if the member list ever needed to be counted (e.g. for figuring out the order of members during a non-designated initialization), which would catch impossible type (void) in the struct: security/landlock/fs.c: In function ‘hook_file_ioctl_common’: security/landlock/fs.c:1745:61: internal compiler error: in count_type_elements, at expr.cc:7075 1745 | .u.op = &(struct lsm_ioctlop_audit) { | ^ static HOST_WIDE_INT count_type_elements (const_tree type, bool for_ctor_p) { switch (TREE_CODE (type)) ... case VOID_TYPE: default: gcc_unreachable (); } } However this is a redundant safety measure since randstruct uses the __designated_initializer attribute both internally and within the __randomized_layout attribute macro so that this would be enforced by the compiler directly even when randstruct was not enabled (via -Wdesignated-init). A recent change in Landlock ended up tripping the same member counting routine when using a full-struct copy initializer as part of an anonymous initializer. This, however, is a false positive as the initializer is copying between identical structs (and hence identical layouts). The "path" member is "struct path", a randomized struct, and is being copied to from another "struct path", the "f_path" member: landlock_log_denial(landlock_cred(file->f_cred), &(struct landlock_request) { .type = LANDLOCK_REQUEST_FS_ACCESS, .audit = { .type = LSM_AUDIT_DATA_IOCTL_OP, .u.op = &(struct lsm_ioctlop_audit) { .path = file->f_path, .cmd = cmd, }, }, ... As can be seen with the coming randstruct KUnit test, there appears to be no behavioral problems with this kind of initialization when the void member is removed from the randstruct GCC plugin, so remove it. Reported-by: "Dr. David Alan Gilbert" Closes: https://lore.kernel.org/lkml/Z_PRaKx7q70MKgCA@gallifrey/ Reported-by: Mark Brown Closes: https://lore.kernel.org/lkml/20250407-kbuild-disable-gcc-plugins-v1-1-5d46ae583f5e@kernel.org/ Reported-by: WangYuli Closes: https://lore.kernel.org/lkml/337D5D4887277B27+3c677db3-a8b9-47f0-93a4-7809355f1381@uniontech.com/ Fixes: 313dd1b62921 ("gcc-plugins: Add the randstruct plugin") Signed-off-by: Kees Cook Stable-dep-of: f39f18f3c353 ("randstruct: gcc-plugin: Fix attribute addition") Signed-off-by: Sasha Levin commit 57f7a1da0ec06d8579accaf77762d0128d13e4af Author: Henry Martin Date: Thu Apr 24 15:16:48 2025 +0800 watchdog: lenovo_se30_wdt: Fix possible devm_ioremap() NULL pointer dereference in lenovo_se30_wdt_probe() [ Upstream commit a4e2401438a26131ecff9be6a3a1d4cbfea66f9a ] devm_ioremap() returns NULL on error. Currently, lenovo_se30_wdt_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_ioremap() to prevent this issue. Fixes: c284153a2c55 ("watchdog: lenovo_se30_wdt: Watchdog driver for Lenovo SE30 platform") Signed-off-by: Henry Martin Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20250424071648.89016-1-bsdhenrymartin@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 53784073cbad18f75583fd3da9ffdfc4d1f05405 Author: Sergey Shtylyov Date: Wed May 14 23:35:58 2025 +0300 fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod() [ Upstream commit 3f6dae09fc8c306eb70fdfef70726e1f154e173a ] In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000, cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's then passed to fb_cvt_hperiod(), where it's used as a divider -- division by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to avoid such overflow... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: 96fe6a2109db ("[PATCH] fbdev: Add VESA Coordinated Video Timings (CVT) support") Signed-off-by: Sergey Shtylyov Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit b6d171e598307bda5054d9c34da88b015e0f4f77 Author: Kees Cook Date: Wed May 28 11:26:22 2025 -0700 ubsan: integer-overflow: depend on BROKEN to keep this out of CI [ Upstream commit d6a0e0bfecccdcecb08defe75a137c7262352102 ] Depending on !COMPILE_TEST isn't sufficient to keep this feature out of CI because we can't stop it from being included in randconfig builds. This feature is still highly experimental, and is developed in lock-step with Clang's Overflow Behavior Types[1]. Depend on BROKEN to keep it from being enabled by anyone not expecting it. Link: https://discourse.llvm.org/t/rfc-v2-clang-introduce-overflowbehaviortypes-for-wrapping-and-non-wrapping-arithmetic/86507 [1] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202505281024.f42beaa7-lkp@intel.com Fixes: 557f8c582a9b ("ubsan: Reintroduce signed overflow sanitizer") Acked-by: Eric Biggers Link: https://lore.kernel.org/r/20250528182616.work.296-kees@kernel.org Reviewed-by: Nathan Chancellor Acked-by: Marco Elver Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 45b2e8b0fdd280aba04c3cc869e9ae500c44e4b7 Author: Henry Martin Date: Thu May 15 16:00:44 2025 +0930 soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop() [ Upstream commit f1706e0e1a74b095cbc60375b9b1e6205f5f4c98 ] devm_kasprintf() returns NULL when memory allocation fails. Currently, aspeed_lpc_enable_snoop() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev") Signed-off-by: Henry Martin Link: https://patch.msgid.link/20250401074647.21300-1-bsdhenrymartin@gmail.com [arj: Fix Fixes: tag to use subject from 3772e5da4454] Signed-off-by: Andrew Jeffery Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit e5d0bfd2ee215f382fdd647974b1428b25dc408f Author: Su Hui Date: Thu May 15 16:00:43 2025 +0930 soc: aspeed: lpc: Fix impossible judgment condition [ Upstream commit d9f0a97e859bdcef51f9c187b1eb712eb13fd3ff ] smatch error： drivers/soc/aspeed/aspeed-lpc-snoop.c:169 aspeed_lpc_snoop_config_irq() warn: platform_get_irq() does not return zero platform_get_irq() return non-zero IRQ number or negative error code, change '!lpc_snoop->irq' to 'lpc_snoop->irq < 0' to fix this. Fixes: 9f4f9ae81d0a ("drivers/misc: add Aspeed LPC snoop driver") Signed-off-by: Su Hui Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/20231027020703.1231875-1-suhui@nfschina.com Signed-off-by: Andrew Jeffery Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit b56ee5d79be1d99000a6424da932c83eeed53b05 Author: Joel Stanley Date: Thu May 15 16:00:42 2025 +0930 ARM: aspeed: Don't select SRAM [ Upstream commit e4f59f873c3ffe2a0150e11115a83e2dfb671dbf ] The ASPEED devices have SRAM, but don't require it for basic function (or any function; there's no known users of the driver). Fixes: 8c2ed9bcfbeb ("arm: Add Aspeed machine") Signed-off-by: Joel Stanley Link: https://patch.msgid.link/20250115103942.421429-1-joel@jms.id.au Signed-off-by: Andrew Jeffery Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 9b4129780a9d1246e803b6b112c5ee76c4f65a4a Author: Julien Massot Date: Wed May 14 10:19:58 2025 +0200 arm64: dts: mt6359: Rename RTC node to match binding expectations [ Upstream commit cfe035d8662cfbd6edff9bd89c4b516bbb34c350 ] Rename the node 'mt6359rtc' to 'rtc', as required by the binding. Fix the following dtb-check error: mediatek/mt8395-radxa-nio-12l.dtb: pmic: 'mt6359rtc' do not match any of the regexes: 'pinctrl-[0-9]+' Fixes: 3b7d143be4b7 ("arm64: dts: mt6359: add PMIC MT6359 related nodes") Signed-off-by: Julien Massot Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20250514-mt8395-dtb-errors-v2-3-d67b9077c59a@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit a38c42d49334820d5f0bb60263cba1bd899571b3 Author: Thuan Nguyen Date: Mon May 19 06:43:24 2025 +0000 arm64: dts: renesas: white-hawk-ard-audio: Fix TPU0 groups [ Upstream commit 652eea251dd852f02cef6223f367220acb3d1867 ] White Hawk ARD audio uses a clock generated by the TPU, but commit 3d144ef10a44 ("pinctrl: renesas: r8a779g0: Fix TPU suffixes") renamed pin group "tpu_to0_a" to "tpu_to0_b". Update DTS accordingly otherwise the sound driver does not receive a clock signal. Fixes: 3d144ef10a448f89 ("pinctrl: renesas: r8a779g0: Fix TPU suffixes") Signed-off-by: Thuan Nguyen Signed-off-by: Duy Nguyen Reviewed-by: Geert Uytterhoeven Acked-by: Kuninori Morimoto Link: https://lore.kernel.org/TYCPR01MB8740608B675365215ADB0374B49CA@TYCPR01MB8740.jpnprd01.prod.outlook.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 8fe34788c8fc23e9eadf5254eaabf9634d5e9001 Author: Konrad Dybcio Date: Thu Mar 27 02:47:14 2025 +0100 arm64: dts: qcom: qcs615: Fix up UFS clocks [ Upstream commit ea172f61f4fdb17aaaf8def980ee309a3b727eea ] The clocks are out of order with the bindings' expectations. Reorder them to resolve the errors. Fixes: a6a9d10e7969 ("arm64: dts: qcom: qcs615: add UFS node") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250327-topic-more_dt_bindings_fixes-v2-12-b763d958545f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8c3ece5ca8361b7404a396e3e8748e797be79ef7 Author: Konrad Dybcio Date: Thu Mar 27 02:47:06 2025 +0100 arm64: dts: qcom: msm8998: Remove mdss_hdmi_phy phandle argument [ Upstream commit 7ebdb205d4b9dd839a93a9b8975ce8ccf86b882a ] The node has #clock-cells = <0>, as it only provides a single clock output. This leads to a turbo sneaky bug, where the dt checker shows that we have additional clocks in the array: clock-controller@c8c0000: clocks: [[3, 0], [39, 178], [156, 1], [156, 0], [157, 1], [157, 0], [158], [0], [0], [0], [39, 184]] is too long ..which happens due to dtc interpreting <&mdss_hdmi_phy 0> as <&mdss_hdmi_phy>, <0> after taking cells into account. Remove the superfluous argument to both silence the warning and fix the index-based lookup of subsequent entries in "clocks". Fixes: 2150c87db80c ("arm64: dts: qcom: msm8998: add HDMI nodes") Reviewed-by: Dmitry Baryshkov Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250327-topic-more_dt_bindings_fixes-v2-4-b763d958545f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d0c194350c4d65445a74d61fb51bf6e74c615045 Author: Krzysztof Kozlowski Date: Tue Apr 8 11:32:06 2025 +0200 arm64: dts: qcom: msm8998: Use the header with DSI phy clock IDs [ Upstream commit f4220c41decc1944ef319c859840aa5405eee6fa ] Use the header with DSI phy clock IDs to make code more readable. Reviewed-by: Dmitry Baryshkov Reviewed-by: Neil Armstrong Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250408-dts-qcom-dsi-phy-clocks-v2-9-73b482a6dd02@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: 7ebdb205d4b9 ("arm64: dts: qcom: msm8998: Remove mdss_hdmi_phy phandle argument") Signed-off-by: Sasha Levin commit 82f94fdb918025da9dc1d9c20994defd00ab5076 Author: Dmitry Baryshkov Date: Fri Feb 7 22:41:18 2025 +0200 arm64: dts: qcom: qcm2290: fix (some) of QUP interconnects [ Upstream commit e07d2d57a1c7254d25597dcdd34f318a91ec9398 ] While adding interconnect support for the QCM2290 platform some of them got the c&p error, rogue MASTER_APPSS_PROC for the config_noc interconnect. Turn that into SLAVE_QUP_0 as expected. Fixes: 5b970ff0193d ("arm64: dts: qcom: qcm2290: Hook up interconnects") Reported-by: Konrad Dybcio Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250207-rb1-bt-v4-4-d810fc8c94a9@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1a6dbc7d7b7c14cf97aad4a62eed86e693b4e116 Author: Quentin Schulz Date: Fri Apr 25 17:18:10 2025 +0200 arm64: dts: rockchip: disable unrouted USB controllers and PHY on RK3399 Puma with Haikou [ Upstream commit febd8c6ab52c683b447fe22fc740918c86feae43 ] The u2phy0_host port is the part of the USB PHY0 (namely the HOST0_DP/DM lanes) which routes directly to the USB2.0 HOST controller[1]. The other lanes of the PHY are routed to the USB3.0 OTG controller (dwc3), which we do use. The HOST0_DP/DM lanes aren't routed on RK3399 Puma so let's simply disable the USB2.0 controllers. USB3 OTG has been known to be unstable on RK3399 Puma Haikou for a while, one of the recurring issues being that only USB2 is detected and not USB3 in host mode. Reading the justification above and seeing that we are keeping u2phy0_host in the Haikou carrierboard DTS probably may have bothered you since it should be changed to u2phy0_otg. The issue is that if it's switched to that, USB OTG on Haikou is entirely broken. I have checked the routing in the Gerber file, the lanes are going to the expected ball pins (that is, NOT HOST0_DP/DM). u2phy0_host is for sure the wrong part of the PHY to use, but it's the only one that works at the moment for that board so keep it until we figure out what exactly is broken. No intended functional change. [1] https://rockchip.fr/Rockchip%20RK3399%20TRM%20V1.3%20Part2.pdf Chapter 2 USB2.0 PHY Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Signed-off-by: Quentin Schulz Signed-off-by: Lukasz Czechowski Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-5-4a76a474a010@thaumatec.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit e298135b68daed0a62c3419096294d644eda62ef Author: Quentin Schulz Date: Fri Apr 25 17:18:09 2025 +0200 arm64: dts: rockchip: disable unrouted USB controllers and PHY on RK3399 Puma [ Upstream commit 3373af1d76bacd054b37f3e10266dd335ce425f8 ] The u2phy1_host port is the part of the USB PHY1 (namely the HOST1_DP/DM lanes) which routes directly to the USB2.0 HOST controller[1]. The other lanes of the PHY are routed to the USB3.0 OTG controller (dwc3), which we do use. The HOST1_DP/DM lanes aren't routed on RK3399 Puma so let's simply disable the USB2.0 controllers and associated part in USB2.0 PHY. No intended functional change. [1] https://rockchip.fr/Rockchip%20RK3399%20TRM%20V1.3%20Part2.pdf Chapter 2 USB2.0 PHY Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Signed-off-by: Quentin Schulz Signed-off-by: Lukasz Czechowski Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-4-4a76a474a010@thaumatec.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit e5a87be0575db641d48ddd78f37d3658e52e91a0 Author: Pengyu Luo Date: Sat Apr 5 18:55:28 2025 +0800 arm64: dts: qcom: sm8650: add the missing l2 cache node [ Upstream commit 4becd72352b6861de0c24074a8502ca85080fd63 ] Only two little a520s share the same L2, every a720 has their own L2 cache. Fixes: d2350377997f ("arm64: dts: qcom: add initial SM8650 dtsi") Signed-off-by: Pengyu Luo Reviewed-by: Konrad Dybcio Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20250405105529.309711-1-mitltlatltl@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d2b2217a28c475c1c4adbb3cea5dc0fdc5406c60 Author: Vignesh Raman Date: Mon May 12 18:49:24 2025 +0530 arm64: defconfig: mediatek: enable PHY drivers [ Upstream commit f52cd248d844f9451858992f924988ac413fdc7e ] The mediatek display driver fails to probe on mt8173-elm-hana and mt8183-kukui-jacuzzi-juniper-sku16 in v6.14-rc4 due to missing PHY configurations. Commit 924d66011f24 ("drm/mediatek: stop selecting foreign drivers") stopped selecting the MediaTek PHY drivers, requiring them to be explicitly enabled in defconfig. Enable the following PHY drivers for MediaTek platforms: CONFIG_PHY_MTK_HDMI=m for HDMI display CONFIG_PHY_MTK_MIPI_DSI=m for DSI display CONFIG_PHY_MTK_DP=m for DP display Fixes: 924d66011f24 ("drm/mediatek: stop selecting foreign drivers") Reviewed-by: Nícolas F. R. A. Prado Signed-off-by: Vignesh Raman Link: https://lore.kernel.org/r/20250512131933.1247830-1-vignesh.raman@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit f0e080573e47144baee228bd2b09a36124c6cd64 Author: Dmitry Baryshkov Date: Tue Mar 18 15:22:03 2025 +0200 ARM: dts: qcom: apq8064: move replicator out of soc node [ Upstream commit f2420037d90a8354594b3da541e19dcbb60c75e1 ] The CoreSight static replicator device isn't a part of the system MMIO bus, as such it should not be a part of the soc node. Follow the example of other platforms and move it out of the soc bus to the top-level (and reoder ports to follow alphabetic order). Fixes: 7a5c275fd821 ("ARM: dts: qcom: Add apq8064 CoreSight components") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250318-fix-nexus-4-v2-10-bcedd1406790@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e04a59e5b397214c6c8b55b51d2ca8f88cab2188 Author: Dmitry Baryshkov Date: Tue Mar 18 15:22:00 2025 +0200 ARM: dts: qcom: apq8064 merge hw splinlock into corresponding syscon device [ Upstream commit 325c6a441ae1f8fcb1db9bb945b8bdbd3142141e ] Follow up the expected way of describing the SFPB hwspinlock and merge hwspinlock node into corresponding syscon node, fixing several dt-schema warnings. Fixes: 24a9baf933dc ("ARM: dts: qcom: apq8064: Add hwmutex and SMEM nodes") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250318-fix-nexus-4-v2-7-bcedd1406790@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2320c3dc151608d33f6d63d49ce166c6d5053afe Author: Dmitry Baryshkov Date: Tue Mar 18 15:21:59 2025 +0200 ARM: dts: qcom: apq8064: add missing clocks to the timer node [ Upstream commit 4b0eb149df58b6750cd8113e5ee5b3ac7cc51743 ] In order to fix DT schema warning and describe hardware properly, add missing sleep clock to the timer node. Fixes: f335b8af4fd5 ("ARM: dts: qcom: Add initial APQ8064 SoC and IFC6410 board device trees") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250318-fix-nexus-4-v2-6-bcedd1406790@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 52888dbb30964a6262adac1a886236e32c34d42f Author: Andre Przywara Date: Mon May 5 17:47:27 2025 +0100 dt-bindings: vendor-prefixes: Add Liontron name [ Upstream commit 9baa27a2e9fc746143ab686b6dbe2d515284a4c5 ] Liontron is a company based in Shenzen, China, making industrial development boards and embedded computers, mostly using Rockchip and Allwinner SoCs. Add their name to the list of vendors. Signed-off-by: Andre Przywara Acked-by: Rob Herring (Arm) Link: https://patch.msgid.link/20250505164729.18175-2-andre.przywara@arm.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 73ca3e3649947a4602f174178e8d94471b2d9482 Author: Robin Murphy Date: Fri Apr 25 14:39:28 2025 +0100 bus: fsl_mc: Fix driver_managed_dma check [ Upstream commit 152f33ee30ee6a7f4c15bedd7529dc5945315547 ] Since it's not currently safe to take device_lock() in the IOMMU probe path, that can race against really_probe() setting dev->driver before attempting to bind. The race itself isn't so bad, since we're only concerned with dereferencing dev->driver itself anyway, but sadly my attempt to implement the check with minimal churn leads to a kind of TOCTOU issue, where dev->driver becomes valid after to_fsl_mc_driver(NULL) is already computed, and thus the check fails to work as intended. Will and I both hit this with the platform bus, but the pattern here is the same, so fix it for correctness too. Reported-by: Will McVicker Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path") Signed-off-by: Robin Murphy Reviewed-by: Will McVicker Link: https://lore.kernel.org/r/20250425133929.646493-3-robin.murphy@arm.com Signed-off-by: Christophe Leroy Signed-off-by: Sasha Levin commit 873d47114fd5e5a1cad2018843671537cc71ac84 Author: Ioana Ciornei Date: Tue Apr 8 13:58:09 2025 +0300 bus: fsl-mc: fix double-free on mc_dev [ Upstream commit d694bf8a9acdbd061596f3e7549bc8cb70750a60 ] The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable. In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed. This commit introduces back the following checkpatch warning which is a false-positive. WARNING: kfree(NULL) is safe and this check is probably not required + if (mc_bus) + kfree(mc_bus); Fixes: a042fbed0290 ("staging: fsl-mc: simplify couple of deallocations") Signed-off-by: Ioana Ciornei Link: https://lore.kernel.org/r/20250408105814.2837951-2-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy Signed-off-by: Sasha Levin commit 1fb0f6aa3e88bf772fe7df580cef2724fae06ca7 Author: Ryusuke Konishi Date: Tue Apr 29 02:37:08 2025 +0900 nilfs2: do not propagate ENOENT error from nilfs_btree_propagate() [ Upstream commit 8e39fbb1edbb4ec9d7c1124f403877fc167fcecd ] In preparation for writing logs, in nilfs_btree_propagate(), which makes parent and ancestor node blocks dirty starting from a modified data block or b-tree node block, if the starting block does not belong to the b-tree, i.e. is isolated, nilfs_btree_do_lookup() called within the function fails with -ENOENT. In this case, even though -ENOENT is an internal code, it is propagated to the log writer via nilfs_bmap_propagate() and may be erroneously returned to system calls such as fsync(). Fix this issue by changing the error code to -EINVAL in this case, and having the bmap layer detect metadata corruption and convert the error code appropriately. Link: https://lkml.kernel.org/r/20250428173808.6452-3-konishi.ryusuke@gmail.com Fixes: 1f5abe7e7dbc ("nilfs2: replace BUG_ON and BUG calls triggerable from ioctl") Signed-off-by: Ryusuke Konishi Cc: Wentao Liang Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 46e784bd1d5532d575e4a7a95c35bf6cd2be4ab8 Author: Wentao Liang Date: Tue Apr 29 02:37:07 2025 +0900 nilfs2: add pointer check for nilfs_direct_propagate() [ Upstream commit f43f02429295486059605997bc43803527d69791 ] Patch series "nilfs2: improve sanity checks in dirty state propagation". This fixes one missed check for block mapping anomalies and one improper return of an error code during a preparation step for log writing, thereby improving checking for filesystem corruption on writeback. This patch (of 2): In nilfs_direct_propagate(), the printer get from nilfs_direct_get_ptr() need to be checked to ensure it is not an invalid pointer. If the pointer value obtained by nilfs_direct_get_ptr() is NILFS_BMAP_INVALID_PTR, means that the metadata (in this case, i_bmap in the nilfs_inode_info struct) that should point to the data block at the buffer head of the argument is corrupted and the data block is orphaned, meaning that the file system has lost consistency. Add a value check and return -EINVAL when it is an invalid pointer. Link: https://lkml.kernel.org/r/20250428173808.6452-1-konishi.ryusuke@gmail.com Link: https://lkml.kernel.org/r/20250428173808.6452-2-konishi.ryusuke@gmail.com Fixes: 36a580eb489f ("nilfs2: direct block mapping") Signed-off-by: Wentao Liang Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 574d654fa5c00ce2bfc3fc7784e531c64fa72153 Author: Murad Masimov Date: Wed Apr 2 09:56:27 2025 +0300 ocfs2: fix possible memory leak in ocfs2_finish_quota_recovery [ Upstream commit cdc3ed3035d0fe934aa1d9b78ce256752fd3bb7d ] If ocfs2_finish_quota_recovery() exits due to an error before passing all rc_list elements to ocfs2_recover_local_quota_file() then it can lead to a memory leak as rc_list may still contain elements that have to be freed. Release all memory allocated by ocfs2_add_recovery_chunk() using ocfs2_free_quota_recovery() instead of kfree(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Link: https://lkml.kernel.org/r/20250402065628.706359-2-m.masimov@mt-integration.ru Fixes: 2205363dce74 ("ocfs2: Implement quota recovery") Signed-off-by: Murad Masimov Reviewed-by: Jan Kara Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 295ab18c2dbce8d0ac6ecf7c5187e16e1ac8b282 Author: Phillip Lougher Date: Wed Apr 9 03:47:47 2025 +0100 Squashfs: check return result of sb_min_blocksize [ Upstream commit 734aa85390ea693bb7eaf2240623d41b03705c84 ] Syzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug. Syzkaller forks multiple processes which after mounting the Squashfs filesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in the process of mounting a Squashfs filesystem on /dev/loop0, the failure occurs. When this happens the following code in squashfs_fill_super() fails. ---- msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE); msblk->devblksize_log2 = ffz(~msblk->devblksize); ---- sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0. As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2 is set to 64. This subsequently causes the UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') This commit adds a check for a 0 return by sb_min_blocksize(). Link: https://lkml.kernel.org/r/20250409024747.876480-1-phillip@squashfs.org.uk Fixes: 0aa666190509 ("Squashfs: super block operations") Reported-by: syzbot+65761fc25a137b9c8c6e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67f0dd7a.050a0220.0a13.0230.GAE@google.com/ Signed-off-by: Phillip Lougher Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 6b05e92c02c7634d0ac7219354b8f428dbaf9ff9 Author: Barnabás Czémán Date: Mon Apr 21 04:04:17 2025 +0200 soc: qcom: smp2p: Fix fallback to qcom,ipc parse [ Upstream commit 421777a02bbd9cdabe0ae05a69ee06253150589d ] mbox_request_channel() returning value was changed in case of error. It uses returning value of of_parse_phandle_with_args(). It is returning with -ENOENT instead of -ENODEV when no mboxes property exists. Fixes: 24fdd5074b20 ("mailbox: use error ret code of of_parse_phandle_with_args()") Signed-off-by: Barnabás Czémán Reviewed-by: Stephan Gerhold Tested-by: Stephan Gerhold # msm8939 Link: https://lore.kernel.org/r/20250421-fix-qcom-smd-v1-2-574d071d3f27@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8ac35b8fbe100659543e5939f76954b82cf90dce Author: Prasanth Babu Mantena Date: Wed May 7 10:37:01 2025 +0530 arm64: dts: ti: k3-j721e-common-proc-board: Enable OSPI1 on J721E [ Upstream commit 6b8deb2ff0d31848c43a73f6044e69ba9276b3ec ] J721E SoM has MT25QU512AB Serial NOR flash connected to OSPI1 controller. Enable ospi1 node in device tree. Fixes: 73676c480b72 ("arm64: dts: ti: k3-j721e: Enable OSPI nodes at the board level") Signed-off-by: Prasanth Babu Mantena Link: https://lore.kernel.org/r/20250507050701.3007209-1-p-mantena@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit f9650f682b50efe61cd97b2acb0cc9ffd451b265 Author: Aaron Kling Date: Sun Apr 20 09:35:37 2025 -0500 arm64: tegra: Add uartd serial alias for Jetson TX1 module [ Upstream commit dfb25484bd73c8590954ead6fd58a1587ba3bbc5 ] If a serial-tegra interface does not have an alias, the driver fails to probe with an error: serial-tegra 70006300.serial: failed to get alias id, errno -19 This prevents the bluetooth device from being accessible. Fixes: 6eba6471bbb7 ("arm64: tegra: Wire up Bluetooth on Jetson TX1 module") Signed-off-by: Aaron Kling Reviewed-by: Tomasz Maciej Nowak Link: https://lore.kernel.org/r/20250420-tx1-bt-v1-1-153cba105a4e@gmail.com Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 43c60d58533367ed9fa6ed944cc1a41bf842c704 Author: Aaron Kling Date: Mon Apr 28 20:51:47 2025 -0500 arm64: tegra: Drop remaining serial clock-names and reset-names [ Upstream commit 4cd763297c2203c6ba587d7d4a9105f96597b998 ] The referenced commit only removed some of the names, missing all that weren't in use at the time. The commit removes the rest. Fixes: 71de0a054d0e ("arm64: tegra: Drop serial clock-names and reset-names") Signed-off-by: Aaron Kling Link: https://lore.kernel.org/r/20250428-tegra-serial-fixes-v1-1-4f47c5d85bf6@gmail.com Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit cf495b1aae81001f26393cd95c94b06f6d6f4bdc Author: Geert Uytterhoeven Date: Wed May 7 15:31:55 2025 +0200 arm64: dts: renesas: white-hawk-single: Improve Ethernet TSN description [ Upstream commit 8ffec7d62c6956199f442dac3b2d5d02231c3977 ] - Add the missing "ethernet3" alias for the Ethernet TSN port, so U-Boot will fill its local-mac-address property based on the "eth3addr" environment variable (if set), avoiding a random MAC address being assigned by the OS, - Rename the numerical Ethernet PHY label to "tsn0_phy", to avoid future conflicts, and for consistency with the "avbN_phy" labels. Fixes: 3d8e475bd7a724a9 ("arm64: dts: renesas: white-hawk-single: Wire-up Ethernet TSN") Signed-off-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund Link: https://lore.kernel.org/367f10a18aa196ff1c96734dd9bd5634b312c421.1746624368.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 311c364b196e075491cf760ee8c2cda27534a4a0 Author: Peter Robinson Date: Tue May 6 23:25:28 2025 +0100 arm64: dts: rockchip: Update eMMC for NanoPi R5 series [ Upstream commit 8eca9e979a1efbcc3d090f6eb3f4da621e7c87e0 ] Add the 3.3v and 1.8v regulators that are connected to the eMMC on the R5 series devices, as well as adding the eMMC data strobe, and enable eMMC HS200 mode as the Foresee FEMDNN0xxG-A3A55 modules support it. Fixes: c8ec73b05a95d ("arm64: dts: rockchip: create common dtsi for NanoPi R5 series") Signed-off-by: Peter Robinson Reviewed-by: Diederik de Haas Link: https://lore.kernel.org/r/20250506222531.625157-1-pbrobinson@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit e31c0c425b70db8cf63c5f43da3a02a02a7de5b0 Author: Andre Przywara Date: Mon May 5 21:24:16 2025 +0100 arm64: dts: allwinner: a100: set maximum MMC frequency [ Upstream commit d8f10550448b03d3c5c6d9392119205c65ebfc89 ] The manual for the Allwinner A133 SoC mentions that the maximum supported MMC frequency is 150 MHz, for all of the MMC devices. Describe that in the DT entry, to help drivers setting the right interface frequency. Fixes: fcfbb8d9ec58 ("arm64: allwinner: a100: Add MMC related nodes") Signed-off-by: Andre Przywara Link: https://patch.msgid.link/20250505202416.23753-1-andre.przywara@arm.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit ac21d13b6629b28a7cca3f53939a84137d13a01e Author: Peter Robinson Date: Tue May 6 20:56:55 2025 +0100 arm64: dts: rockchip: Add vcc-supply to SPI flash on rk3566-rock3c [ Upstream commit a706a593cb19796f31d3a888423ef1a71885ae72 ] As described in the radxa_rock_3c_v1400_schematic.pdf, the SPI Flash's VCC connector is connected to VCCIO_FLASH and according to the that same schematic, that belongs to the VCC_1V8 power source. This fixes the following warning: spi-nor spi4.0: supply vcc not found, using dummy regulator Fixes: ee219017ddb5 ("arm64: dts: rockchip: Add Radxa ROCK 3C") Signed-off-by: Peter Robinson Link: https://lore.kernel.org/r/20250506195702.593044-1-pbrobinson@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit d9219a2f23a7afdf6e1db55fc533d2d999f58556 Author: Abel Vesa Date: Tue Apr 22 14:25:23 2025 +0300 arm64: dts: qcom: x1e001de-devkit: Fix pin config for USB0 retimer vregs [ Upstream commit 635d0c8edf26994dc1dcbc09add9423aa61869b0 ] Describe the missing power source, bias and direction for each of the USB0 retimer gpio-controlled voltage regulators related pin configuration. Fixes: 019e1ee32fec ("arm64: dts: qcom: x1e001de-devkit: Enable external DP support") Reviewed-by: Konrad Dybcio Signed-off-by: Abel Vesa Reviewed-by: Johan Hovold Link: https://lore.kernel.org/r/20250422-x1e001de-devkit-dts-fix-retimer-gpios-v2-2-0129c4f2b6d7@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8abb25127ffd3757b88773a6b5b193d235722ad7 Author: Abel Vesa Date: Tue Apr 22 14:25:22 2025 +0300 arm64: dts: qcom: x1e001de-devkit: Describe USB retimers resets pin configs [ Upstream commit f76fdcd2550991c854a698a9f881b1579455fc0a ] Currently, on the X Elite Devkit, the pin configuration of the reset gpios for all three PS8830 USB retimers are left configured by the bootloader. Fix that by describing their pin configuration. Fixes: 019e1ee32fec ("arm64: dts: qcom: x1e001de-devkit: Enable external DP support") Reviewed-by: Konrad Dybcio Signed-off-by: Abel Vesa Reviewed-by: Johan Hovold Link: https://lore.kernel.org/r/20250422-x1e001de-devkit-dts-fix-retimer-gpios-v2-1-0129c4f2b6d7@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5a95d17f5928683bda30afc5af2096ad458aa944 Author: Alexey Minnekhanov Date: Sun May 4 14:51:20 2025 +0300 arm64: dts: qcom: sda660-ifc6560: Fix dt-validate warning [ Upstream commit f5110806b41eaa0eb0ab1bf2787876a580c6246c ] If you remove clocks property, you should remove clock-names, too. Fixes warning with dtbs check: 'clocks' is a dependency of 'clock-names' Fixes: 34279d6e3f32c ("arm64: dts: qcom: sdm660: Add initial Inforce IFC6560 board support") Signed-off-by: Alexey Minnekhanov Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250504115120.1432282-4-alexeymin@postmarketos.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d94e9e8f94ffc32087fe2982bdec4426be914d40 Author: Alexey Minnekhanov Date: Sun May 4 14:51:19 2025 +0300 arm64: dts: qcom: sdm660-lavender: Add missing USB phy supply [ Upstream commit dbf62a117a1b7f605a98dd1fd1fd6c85ec324ea0 ] Fixes the following dtbs check error: phy@c012000: 'vdda-pll-supply' is a required property Fixes: e5d3e752b050e ("arm64: dts: qcom: sdm660-xiaomi-lavender: Add USB") Signed-off-by: Alexey Minnekhanov Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250504115120.1432282-3-alexeymin@postmarketos.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3288529e52e6cc5bc334748d22e4e120b7328cc0 Author: Julien Massot Date: Mon May 5 15:23:39 2025 +0200 arm64: dts: mt6359: Add missing 'compatible' property to regulators node [ Upstream commit 1fe38d2a19950fa6dbc384ee8967c057aef9faf4 ] The 'compatible' property is required by the 'mfd/mediatek,mt6397.yaml' binding. Add it to fix the following dtb-check error: mediatek/mt8395-radxa-nio-12l.dtb: pmic: regulators: 'compatible' is a required property Fixes: 3b7d143be4b7 ("arm64: dts: mt6359: add PMIC MT6359 related nodes") Signed-off-by: Julien Massot Link: https://lore.kernel.org/r/20250505-mt8395-dtb-errors-v1-3-9c4714dcdcdb@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 6b0b2645cfb923dec6d6eadafbf0e74b2b85ebdd Author: Louis-Alexis Eyraud Date: Fri May 2 15:17:19 2025 +0200 arm64: dts: mediatek: mt8390-genio-common: Set ssusb2 default dual role mode to host [ Upstream commit f9167f15dd4e70b124023a2f7ba2b09401b3b6ff ] On the Mediatek Genio 510-EVK and 700-EVK boards, ssusb2 controller is one but has two ports: one is routed to the M.2 slot, the other is on the RPi header who does support full OTG. Since Mediatek Genio 700-EVK USB support was added, dual role mode property is set to otg for ssusb2. This config prevents the M.2 Wifi/Bluetooth module, present on those boards and exposing Bluetooth as an USB device to be properly detected at startup as the default role is device. To keep the OTG functionality and make the M.2 module be detected at the same time, add role-switch-default-mode property set to host and also fix the polarity of GPIO associated to the USB connector, so the ssusb2 controller role is properly set to host when the other port is unused. Fixes: 1afaeca17238 ("arm64: dts: mediatek: mt8390-genio-700: Add USB, TypeC Controller, MUX") Signed-off-by: Louis-Alexis Eyraud Link: https://lore.kernel.org/r/20250502-mtk-genio-510-700-fix-bt-detection-v2-1-870aa2145480@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 6b08c4132e27eec68b43d927d4abc984ba593df9 Author: Nícolas F. R. A. Prado Date: Fri May 2 11:32:10 2025 -0400 arm64: dts: mediatek: mt6357: Drop regulator-fixed compatibles [ Upstream commit d77e89b7b03fb945b4353f2dcc4a70b34baa7bcb ] Some of the regulators in the MT6357 PMIC dtsi have compatible set to regulator-fixed, even though they don't serve any purpose: all those regulators are handled as a whole by the mt6357-regulator driver. In fact this is the only dtsi in this family of chips where this is the case: mt6359 and mt6358 don't have any such compatibles. A side-effect caused by this is that the DT kselftest, which is supposed to identify nodes with compatibles that can be probed, but haven't, shows these nodes as failures. Remove the useless compatibles to move the dtsi in line with the others in its family and fix the DT kselftest failures. Fixes: 55749bb478f8 ("arm64: dts: mediatek: add mt6357 device-tree") Signed-off-by: Nícolas F. R. A. Prado Link: https://lore.kernel.org/r/20250502-mt6357-regulator-fixed-compatibles-removal-v1-1-a582c16743fe@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 28e1021edea10fa9a7502fb7d0e26812b0d539f9 Author: Adam Ford Date: Tue Apr 15 20:01:31 2025 -0500 arm64: dts: imx8mn-beacon: Set SAI5 MCLK direction to output for HDMI audio [ Upstream commit a747c4dd2a60c4d0179b372032a4b98548135096 ] The HDMI bridge chip fails to generate an audio source due to the SAI5 master clock (MCLK) direction not being set to output. This prevents proper clocking of the HDMI audio interface. Add the `fsl,sai-mclk-direction-output` property to the SAI5 node to ensure the MCLK is driven by the SoC, resolving the HDMI sound issue. Fixes: 1d6880ceef43 ("arm64: dts: imx8mn-beacon: Add HDMI video with sound") Signed-off-by: Adam Ford Reviewed-by: Frank Li Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 876cbf18c1ad2e81f42ec88f5d710b3f524153b8 Author: Adam Ford Date: Tue Apr 15 20:01:30 2025 -0500 arm64: dts: imx8mm-beacon: Set SAI5 MCLK direction to output for HDMI audio [ Upstream commit 8c716f80dfe8cd6ed9a2696847cea1affeeff6ff ] The HDMI bridge chip fails to generate an audio source due to the SAI5 master clock (MCLK) direction not being set to output. This prevents proper clocking of the HDMI audio interface. Add the `fsl,sai-mclk-direction-output` property to the SAI5 node to ensure the MCLK is driven by the SoC, resolving the HDMI sound issue. Fixes: 8ad7d14d99f3 ("arm64: dts: imx8mm-beacon: Add HDMI video with sound") Signed-off-by: Adam Ford Reviewed-by: Frank Li Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit e4564e711d8e9fee1aafc924ed4011164792d5d1 Author: Adam Ford Date: Tue Apr 15 20:01:29 2025 -0500 arm64: dts: imx8mp-beacon: Fix RTC capacitive load [ Upstream commit 6821ee17537938e919e8b86a541aae451f73165b ] Although not noticeable when used every day, the RTC appears to drift when left to sit over time. This is due to the capacitive load not being properly set. Fix RTC drift by correcting the capacitive load setting from 7000 to 12500, which matches the actual hardware configuration. Fixes: 25a5ccdce767 ("arm64: dts: freescale: Introduce imx8mp-beacon-kit") Signed-off-by: Adam Ford Reviewed-by: Frank Li Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 09856f1dd862a2ce00c589fdf11ed2eb96373027 Author: Adam Ford Date: Tue Apr 15 20:01:28 2025 -0500 arm64: dts: imx8mn-beacon: Fix RTC capacitive load [ Upstream commit c3f03bec30efd5082b55876846d57b5d17dae7b9 ] Although not noticeable when used every day, the RTC appears to drift when left to sit over time. This is due to the capacitive load not being properly set. Fix RTC drift by correcting the capacitive load setting from 7000 to 12500, which matches the actual hardware configuration. Fixes: 36ca3c8ccb53 ("arm64: dts: imx: Add Beacon i.MX8M Nano development kit") Signed-off-by: Adam Ford Reviewed-by: Frank Li Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 4a730a7598d9c9c7db0a980695203172b977e691 Author: Adam Ford Date: Tue Apr 15 20:01:27 2025 -0500 arm64: dts: imx8mm-beacon: Fix RTC capacitive load [ Upstream commit 2e98d456666d63f897ba153210bcef9d78ba0f3a ] Although not noticeable when used every day, the RTC appears to drift when left to sit over time. This is due to the capacitive load not being properly set. Fix RTC drift by correcting the capacitive load setting from 7000 to 12500, which matches the actual hardware configuration. Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development kit") Signed-off-by: Adam Ford Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 4b795ceaebbae821480b68323f60e38adda0eb9e Author: Pin-yen Lin Date: Wed Apr 23 12:03:39 2025 +0800 arm64: dts: mt8183: Add port node to mt8183.dtsi [ Upstream commit d15059f7be59f887c1a370037cc2337c2ff2ad56 ] Add the port node to fix the binding schema check. Also update mt8183-kukui to reference the new port node. Fixes: 88ec840270e6 ("arm64: dts: mt8183: Add dsi node") Fixes: 27eaf34df364 ("arm64: dts: mt8183: config dsi node") Signed-off-by: Pin-yen Lin Link: https://lore.kernel.org/r/20250423040354.2847447-1-treapking@chromium.org Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit f038a682a570888764b238000a723b8a302b99a9 Author: André Draszik Date: Wed Mar 19 05:38:24 2025 +0000 firmware: exynos-acpm: silence EPROBE_DEFER error on boot [ Upstream commit 53734383a73888e6d765aa07f4523802fdf1ee10 ] This driver emits error messages when client drivers are trying to get an interface handle to this driver here before this driver has completed _probe(). Given this driver returns -EPROBE_DEFER in that case, this is not an error and shouldn't be emitted to the log, similar to how dev_err_probe() behaves, so just remove them. This change also allows us to simplify the logic around releasing of the acpm_np handle. Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Signed-off-by: André Draszik Link: https://lore.kernel.org/r/20250319-acpm-fixes-v2-2-ac2c1bcf322b@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit c3953771dc2edab676e6481fc780fa906ee2aa9d Author: André Draszik Date: Wed Mar 19 05:38:23 2025 +0000 firmware: exynos-acpm: fix reading longer results [ Upstream commit 67af3cd813695fd3e6432b0849c453250c4685aa ] ACPM commands that return more than 8 bytes currently don't work correctly, as this driver ignores any such returned bytes. This is evident in at least acpm_pmic_bulk_read(), where up to 8 registers can be read back and those 8 register values are placed starting at &xfer->rxd[8]. The reason is that xfter->rxlen is initialized with the size of a pointer (8 bytes), rather than the size of the byte array that pointer points to (16 bytes) Update the code such that we set the number of bytes expected to be the size of the rx buffer. Note1: While different commands have different lengths rx buffers, we have to specify the same length for all rx buffers since acpm_get_rx() assumes they're all the same length. Note2: The different commands also have different lengths tx buffers, but before switching the code to use the minimum possible length, some more testing would have to be done to ensure this works correctly in all situations. It seems wiser to just apply this fix here without additional logic changes for now. Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Reviewed-by: Tudor Ambarus Signed-off-by: André Draszik Link: https://lore.kernel.org/r/20250319-acpm-fixes-v2-1-ac2c1bcf322b@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 4c14c9e2c714b1ce494699b8b5cd85ee66714502 Author: Alexey Minnekhanov Date: Tue Apr 15 16:01:01 2025 +0300 arm64: dts: qcom: sdm660-xiaomi-lavender: Add missing SD card detect GPIO [ Upstream commit 2eca6af66709de0d1ba14cdf8b6d200a1337a3a2 ] During initial porting these cd-gpios were missed. Having card detect is beneficial because driver does not need to do polling every second and it can just use IRQ. SD card detection in U-Boot is also fixed by this. Fixes: cf85e9aee210 ("arm64: dts: qcom: sdm660-xiaomi-lavender: Add eMMC and SD") Signed-off-by: Alexey Minnekhanov Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250415130101.1429281-1-alexeymin@postmarketos.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d95d216655a15607199605e750c089889d1c020a Author: AngeloGioacchino Del Regno Date: Wed Apr 2 11:06:15 2025 +0200 arm64: dts: mediatek: mt8195: Reparent vdec1/2 and venc1 power domains [ Upstream commit 394f29033324e2317bfd6a7ed99b9a60832b36a2 ] By hardware, the first and second core of the video decoder IP need the VDEC_SOC to be powered up in order to be able to be accessed (both internally, by firmware, and externally, by the kernel). Similarly, for the video encoder IP, the second core needs the first core to be powered up in order to be accessible. Fix that by reparenting the VDEC1/2 power domains to be children of VDEC0 (VDEC_SOC), and the VENC1 to be a child of VENC0. Fixes: 2b515194bf0c ("arm64: dts: mt8195: Add power domains controller") Reviewed-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20250402090615.25871-3-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit a4f9b05a7ec5c2eb45111ce6380a42616c8c9f86 Author: Chen-Yu Tsai Date: Tue Apr 8 17:23:02 2025 +0800 arm64: dts: mediatek: mt8188: Fix IOMMU device for rdma0 [ Upstream commit 267623000d11f6d483214be2484555f600393a12 ] Based on the comments in the MT8188 IOMMU binding header, the rdma0 device specifies the wrong IOMMU device for the IOMMU port it is tied to: This SoC have two MM IOMMU HWs, this is the connected information: iommu-vdo: larb0/2/5/9/10/11A/11C/13/16B/17B/19/21 iommu-vpp: larb1/3/4/6/7/11B/12/14/15/16A/17A/23/27 rdma0's endpoint is M4U_PORT_L1_DISP_RDMA0 (on larb1), which should use iommu-vpp, but it is currently tied to iommu-vdo. Somehow this went undetected until recently in Linux v6.15-rc1 with some IOMMU subsystem framework changes that caused the IOMMU to no longer work. The IOMMU would fail to probe if any devices associated with it could not be successfully attached. Prior to these changes, only the end device would be left without an IOMMU attached. Fixes: 7075b21d1a8e ("arm64: dts: mediatek: mt8188: Add display nodes for vdosys0") Signed-off-by: Chen-Yu Tsai Reviewed-by: Jason-JH Lin Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20250408092303.3563231-1-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 4e1131a18ffd6b9a862829106d880e1389b3afe3 Author: Wolfram Sang Date: Wed Apr 2 23:04:46 2025 +0200 ARM: dts: at91: at91sam9263: fix NAND chip selects [ Upstream commit c72ede1c24be689733bcd2233a3a56f2478429c8 ] NAND did not work on my USB-A9263. I discovered that the offending commit converted the PIO bank for chip selects wrongly, so all A9263 boards need to be fixed. Fixes: 1004a2977bdc ("ARM: dts: at91: Switch to the new NAND bindings") Signed-off-by: Wolfram Sang Reviewed-by: Alexandre Belloni Link: https://lore.kernel.org/r/20250402210446.5972-2-wsa+renesas@sang-engineering.com Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit e733178af2eb00d594cb45e3b0ed8f59d6ef63c5 Author: Wolfram Sang Date: Fri Apr 4 13:27:43 2025 +0200 ARM: dts: at91: usb_a9263: fix GPIO for Dataflash chip select [ Upstream commit 67ba341e57ab158423818ed33bfa1c40eb0e5e7e ] Dataflash did not work on my board. After checking schematics and using the proper GPIO, it works now. Also, make it active low to avoid: flash@0 enforce active low on GPIO handle Fixes: 2432d201468d ("ARM: at91: dt: usb-a9263: add dataflash support") Signed-off-by: Wolfram Sang Link: https://lore.kernel.org/r/20250404112742.67416-2-wsa+renesas@sang-engineering.com Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit cb4f48794f321b19078c982c3e2228e8ca753238 Author: Chukun Pan Date: Tue Apr 1 17:00:09 2025 +0800 arm64: dts: rockchip: Move SHMEM memory to reserved memory on rk3588 [ Upstream commit 8ecd096d018be8a6bd3bd930f3a41a85db66a67d ] 0x0 to 0xf0000000 are SDRAM memory areas where 0x10f000 is located. So move the SHMEM memory of arm_scmi to the reserved memory node. Fixes: c9211fa2602b ("arm64: dts: rockchip: Add base DT for rk3588 SoC") Signed-off-by: Chukun Pan Link: https://lore.kernel.org/r/20250401090009.733771-2-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 2f5b6e87ca5b691913fd5b8b34c781212e048250 Author: Chukun Pan Date: Tue Apr 1 18:00:18 2025 +0800 arm64: dts: rockchip: Add missing uart3 interrupt for RK3528 [ Upstream commit a37d21a9b45e47ed6bc1f94e738096c07db78a07 ] The interrupt of uart3 node on rk3528 is missing, fix it. Fixes: 7983e6c379a9 ("arm64: dts: rockchip: Add base DT for rk3528 SoC") Reviewed-by: Yao Zi Signed-off-by: Chukun Pan Link: https://lore.kernel.org/r/20250401100020.944658-2-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 4f8763e6cde4324e017af315feec341620aa584c Author: Luca Weiss Date: Fri Mar 14 09:21:16 2025 +0100 arm64: dts: qcom: sm8650: Fix domain-idle-state for CPU2 [ Upstream commit 9bb5ca464100e7c8f2d740148088f60e04fed8ed ] On SM8650 the CPUs 0-1 are "silver" (Cortex-A520), CPU 2-6 are "gold" (Cortex-A720) and CPU 7 is "gold-plus" (Cortex-X4). So reference the correct "gold" idle-state for CPU core 2. Fixes: d2350377997f ("arm64: dts: qcom: add initial SM8650 dtsi") Signed-off-by: Luca Weiss Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250314-sm8650-cpu2-sleep-v1-1-31d5c7c87a5d@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit fba1e4552c84a443ec8a4e55165390aed32f3593 Author: Tingguo Cheng Date: Fri Jan 17 11:24:31 2025 +0800 arm64: dts: qcom: qcs615: remove disallowed property in spmi bus node [ Upstream commit 54040a3e3da67ef0e014e5f04f9f3fe680fc4b55 ] Remove the unevaluated 'cell-index' property from qcs615-ride.dtb spmi@c440000 to fix the Devicetree validation error reported by the kernel test robot. Reported-by: kernel test robot Closes: https://lore.kernel.org/r/202412272210.GpGmqcPC-lkp@intel.com/ Fixes: 27554e2bef4d ("arm64: dts: qcom: qcs615: Adds SPMI support") Signed-off-by: Tingguo Cheng Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250117-fix-kernel-test-robot-unexpected-property-issue-v2-1-0b68cf481249@quicinc.com [bjorn: Fixes commit message wording about LKP] Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 94440b35e91c14f211c41fda802c1310a8efa89a Author: Varadarajan Narayanan Date: Fri Feb 7 13:05:45 2025 +0530 arm64: dts: qcom: ipq9574: Fix USB vdd info [ Upstream commit 4f4c905e6a2a4e884f4e9b7326c94fac3500e0f9 ] USB phys in ipq9574 use the 'L5' regulator. The commit ec4f047679d5 ("arm64: dts: qcom: ipq9574: Enable USB") incorrectly specified it as 'L2'. Because of this when the phy module turns off/on its regulators, the wrong regulator is turned off/on resulting in 2 issues, namely the correct regulator related to the USB phy is not turned off/on and the module powered by the incorrect regulator is affected. Fixes: ec4f047679d5 ("arm64: dts: qcom: ipq9574: Enable USB") Signed-off-by: Varadarajan Narayanan Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250207073545.1768990-2-quic_varada@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e05848481b734740173c37b73f30926f0f1bae54 Author: Stephan Gerhold Date: Tue Dec 3 18:44:02 2024 +0100 arm64: dts: qcom: sc8280xp-x13s: Drop duplicate DMIC supplies [ Upstream commit a2e617f4e6981aa514a569e927f90b0d39bb31b2 ] The WCD938x codec provides two controls for each of the MIC_BIASn outputs: - "MIC BIASn" enables an internal regulator to generate the output with a configurable voltage (qcom,micbiasN-microvolt). - "VA MIC BIASn" enables "pull-up mode" that bypasses the internal regulator and directly outputs fixed 1.8V from the VDD_PX pin. This is intended for low-power VA (voice activation) use cases. The audio-routing setup for the ThinkPad X13s currently specifies both as power supplies for the DMICs, but only one of them can be active at the same time. In practice, only the internal regulator is used with the current setup because the driver prefers it over pull-up mode. Make this more clear by dropping the redundant routes to the pull-up "VA MIC BIASn" supply. There is no functional difference except that we skip briefly switching to pull-up mode when shutting down the microphone. Fixes: 2e498f35c385 ("arm64: dts: qcom: sc8280xp-x13s: fix va dmic dai links and routing") Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20241203-x1e80100-va-mic-bias-v1-1-0dfd4d9b492c@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7610e299ffbc4e177e9df096b6951cc4df55c00b Author: Jyothi Kumar Seerapu Date: Wed Mar 12 16:13:58 2025 +0530 arm64: dts: qcom: sm8750: Correct clocks property for uart14 node [ Upstream commit 515551e65635b988f2afa9e8683a6b57d6cfba36 ] Correct the clocks property for the uart14 node to fix UART functionality on QUP2_SE6. The current failure is due to an incorrect clocks assignment. Change the clocks property to GCC_QUPV3_WRAP2_S6_CLK to resolve the issue. Signed-off-by: Jyothi Kumar Seerapu Reviewed-by: Konrad Dybcio Fixes: 068c3d3c83be ("arm64: dts: qcom: Add base SM8750 dtsi") Link: https://lore.kernel.org/r/20250312104358.2558-1-quic_jseerapu@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a211058c6022d4a8d0d9e302a2b45c83c6668019 Author: Xilin Wu Date: Sat Mar 8 18:27:51 2025 +0800 arm64: dts: qcom: sm8250: Fix CPU7 opp table [ Upstream commit 28f997b89967afdc0855d8aa7538b251fb44f654 ] There is a typo in cpu7_opp9. Fix it to get rid of the following errors. [ 0.198043] cpu cpu7: Voltage update failed freq=1747200 [ 0.198052] cpu cpu7: failed to update OPP for freq=1747200 Fixes: 8e0e8016cb79 ("arm64: dts: qcom: sm8250: Add CPU opp tables") Signed-off-by: Xilin Wu Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250308-fix-sm8250-cpufreq-v1-1-8a0226721399@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9db98d2ca196b83d5c16d2b8d039aee4b922c478 Author: Maulik Shah Date: Wed Feb 26 12:21:27 2025 +0530 arm64: dts: qcom: sm8750: Fix cluster hierarchy for idle states [ Upstream commit 778dc0f876c70b3d781a49981560ec88e1b7083a ] SM8750 have two different clusters. cluster0 have CPU 0-5 as child and cluster1 have CPU 6-7 as child. Each cluster requires its own idle state and power domain in order to achieve complete domain sleep state. However only single cluster idle state is added mapping CPU 0-7 to the same power domain. Fix this by correctly mapping each CPU to respective cluster power domain and make cluster1 power domain use same domain idle state as cluster0 since both use same idle state parameters. Fixes: 068c3d3c83be ("arm64: dts: qcom: Add base SM8750 dtsi") Signed-off-by: Maulik Shah Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250226-sm8750_cluster_idle-v2-1-ef0ac81e242f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8e26aecdd5170482ba566532687bb156629e7bb2 Author: Manikanta Mylavarapu Date: Thu Mar 13 12:44:22 2025 +0530 arm64: dts: qcom: ipq9574: fix the msi interrupt numbers of pcie3 [ Upstream commit c87d58bc7f831bf3d887e6ec846246cb673c2e50 ] The MSI interrupt numbers of the PCIe3 controller are incorrect. Due to this, the functional bring up of the QDSP6 processor on the PCIe endpoint has failed. Correct the MSI interrupt numbers to properly bring up the QDSP6 processor on the PCIe endpoint. Fixes: d80c7fbfa908 ("arm64: dts: qcom: ipq9574: Add PCIe PHYs and controller nodes") Signed-off-by: Manikanta Mylavarapu Link: https://lore.kernel.org/r/20250313071422.510-1-quic_mmanikan@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4cc706cc9d12ba0887e5220d13d302e247b7f75e Author: Luca Weiss Date: Wed Feb 12 18:03:47 2025 +0100 arm64: dts: qcom: sm8350: Reenable crypto & cryptobam [ Upstream commit 75eefd474469abf95aa9ef6da8161d69f86b98b4 ] When num-channels and qcom,num-ees is not provided in devicetree, the driver will try to read these values from the registers during probe but this fails if the interconnect is not on and then crashes the system. So we can provide these properties in devicetree (queried after patching BAM driver to enable the necessary interconnect) so we can probe cryptobam without reading registers and then also use the QCE as expected. Fixes: 4d29db204361 ("arm64: dts: qcom: sm8350: fix BAM DMA crash and reboot") Fixes: f1040a7fe8f0 ("arm64: dts: qcom: sm8350: Add Crypto Engine support") Signed-off-by: Luca Weiss Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20250212-bam-dma-fixes-v1-1-f560889e65d8@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5927e89cc40d4e634623c2bbbb79e0581235ac88 Author: Dzmitry Sankouski Date: Tue Feb 25 19:38:56 2025 +0300 arm64: dts: qcom: sdm845-starqltechn: remove excess reserved gpios [ Upstream commit fb5fce873b952f8b1c5f7edcabcc8611ef45ea7a ] Starqltechn has 2 reserved gpio ranges <27 4>, <85 4>. <27 4> is spi for eSE(embedded Secure Element). <85 4> is spi for fingerprint. Remove excess reserved gpio regions. Fixes: d711b22eee55 ("arm64: dts: qcom: starqltechn: add initial device tree for starqltechn") Reviewed-by: Konrad Dybcio Signed-off-by: Dzmitry Sankouski Link: https://lore.kernel.org/r/20250225-starqltechn_integration_upstream-v9-5-a5d80375cb66@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7e8142870d35d07bb11821cde6d7cfb5e584e0bf Author: Dzmitry Sankouski Date: Tue Feb 25 19:38:55 2025 +0300 arm64: dts: qcom: sdm845-starqltechn: refactor node order [ Upstream commit cba1dd3d851ebc1b6c5ae4000208a9753320694b ] Fixes: d711b22eee55 ("arm64: dts: qcom: starqltechn: add initial device tree for starqltechn") Signed-off-by: Dzmitry Sankouski Link: https://lore.kernel.org/r/20250225-starqltechn_integration_upstream-v9-4-a5d80375cb66@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 59cb1654f78378534626c04525abf8290e4dbd22 Author: Dzmitry Sankouski Date: Tue Feb 25 19:38:54 2025 +0300 arm64: dts: qcom: sdm845-starqltechn: fix usb regulator mistake [ Upstream commit 242e4126ee007b95765c21a9d74651fdcf221f2b ] Usb regulator was wrongly pointed to vreg_l1a_0p875. However, on starqltechn it's powered from vreg_l5a_0p8. Fixes: d711b22eee55 ("arm64: dts: qcom: starqltechn: add initial device tree for starqltechn") Reviewed-by: Konrad Dybcio Signed-off-by: Dzmitry Sankouski Link: https://lore.kernel.org/r/20250225-starqltechn_integration_upstream-v9-3-a5d80375cb66@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0dec196ee3968da6a411795370a21ca7556f7d88 Author: Dzmitry Sankouski Date: Tue Feb 25 19:38:53 2025 +0300 arm64: dts: qcom: sdm845-starqltechn: remove wifi [ Upstream commit 2d3dd4b237638853b8a99353401ab8d88a6afb6c ] Starqltechn has broadcom chip for wifi, so sdm845 wifi part can be disabled. Fixes: d711b22eee55 ("arm64: dts: qcom: starqltechn: add initial device tree for starqltechn") Reviewed-by: Konrad Dybcio Signed-off-by: Dzmitry Sankouski Fixes: d711b22eee55 ("arm64: dts: qcom: starqltechn: add initial device tree for starqltechn") Reviewed-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20250225-starqltechn_integration_upstream-v9-2-a5d80375cb66@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3194c159d25f81c1d190d9364322b0ed8ee127a1 Author: Konrad Dybcio Date: Tue Mar 4 18:10:46 2025 +0100 arm64: dts: qcom: x1e80100-romulus: Keep L12B and L15B always on [ Upstream commit 0783c8b3c06b9cf16b5108d558e2faffb8c533b7 ] These regulators power some electronic components onboard. They're most likely kept online by other pieces of firmware, but you can never be sure enough. Fixes: 09d77be56093 ("arm64: dts: qcom: Add support for X1-based Surface Laptop 7 devices") Reported-by: Johan Hovold Signed-off-by: Konrad Dybcio Reviewed-by: Johan Hovold Link: https://lore.kernel.org/r/20250304-topic-sl7_vregs_aon-v1-1-b2dc706e4157@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c6b9e9b965e54ea63700747ef1d22c76965b77c7 Author: Neil Armstrong Date: Thu Feb 27 10:00:33 2025 +0100 arm64: dts: qcom: sm8650: add missing cpu-cfg interconnect path in the mdss node [ Upstream commit f22be5c1dd3e12519e3f3b80c14d10b90be2c2fc ] The bindings requires the mdp0-mem and the cpu-cfg interconnect path, add the missing cpu-cfg path to fix the dtbs check error and also to ensure that MDSS has enough bandwidth to let HLOS write config registers. Fixes: 9fa33cbca3d2 ("arm64: dts: qcom: sm8650: correct MDSS interconnects") Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250227-topic-sm8x50-mdss-interconnect-bindings-fix-v5-2-bf6233c6ebe5@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2b5b8fc253049356f118122483bfe31910b0f6d5 Author: Neil Armstrong Date: Thu Feb 27 10:00:32 2025 +0100 arm64: dts: qcom: sm8550: add missing cpu-cfg interconnect path in the mdss node [ Upstream commit 327d489d1ecaf16182952f079cc21f04cf83f967 ] The bindings requires the mdp0-mem and the cpu-cfg interconnect path, add the missing cpu-cfg path to fix the dtbs check error and also to ensure that MDSS has enough bandwidth to let HLOS write config registers. Fixes: b8591df49cde ("arm64: dts: qcom: sm8550: correct MDSS interconnects") Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250227-topic-sm8x50-mdss-interconnect-bindings-fix-v5-1-bf6233c6ebe5@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cdf4a8eefdd8fd3ac24c4a72ceda85e298775b5a Author: Neil Armstrong Date: Wed Jan 15 14:43:53 2025 +0100 arm64: dts: qcom: sm8550: use ICC tag for all interconnect phandles [ Upstream commit 54df5e52777e1126862778a2796c3809df85acd7 ] Use the proper QCOM_ICC_TAG_ define instead of passing 0 in all interconnect paths phandle third argument. Use QCOM_ICC_TAG_ALWAYS which is the fallback mask if 0 is used as third phandle argument. Signed-off-by: Neil Armstrong Acked-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250115-topic-sm8x50-upstream-dt-icc-update-v1-1-eaa8b10e2af7@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: 327d489d1eca ("arm64: dts: qcom: sm8550: add missing cpu-cfg interconnect path in the mdss node") Signed-off-by: Sasha Levin commit 7cf1c47bf404e424441d0932aac79ad95e392093 Author: Krzysztof Kozlowski Date: Tue Jan 28 12:53:33 2025 +0100 arm64: dts: qcom: qcs8300: Partially revert "arm64: dts: qcom: qcs8300: add QCrypto nodes" [ Upstream commit cdc117c40537c5babfa7f261360d5a98e434d59e ] Partially revert commit a86d84409947 ("arm64: dts: qcom: qcs8300: add QCrypto nodes") by dropping the untested QCE device node. Devicetree bindings test failures were reported on mailing list on 16th of January and after two weeks still no fixes: qcs8300-ride.dtb: crypto@1dfa000: compatible: 'oneOf' conditional failed, one must be fixed: ... 'qcom,qcs8300-qce' is not one of ['qcom,ipq4019-qce', 'qcom,sm8150-qce'] Reported-by: Rob Herring Closes: https://lore.kernel.org/all/CAL_JsqL0HzzGXnCD+z4GASeXNsBxrdw8-qyfHj8S+C2ucK6EPQ@mail.gmail.com/ Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250128115333.95021-2-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b567568eb7c31e11a39c0169682fa423c68aff32 Author: Krzysztof Kozlowski Date: Tue Jan 28 12:53:32 2025 +0100 arm64: dts: qcom: sa8775p: Partially revert "arm64: dts: qcom: sa8775p: add QCrypto nodes" [ Upstream commit 92979f12a201c54ea94b8b3c9f0737c33bb45e23 ] Partially revert commit 7ff3da43ef44 ("arm64: dts: qcom: sa8775p: add QCrypto nodes") by dropping the untested QCE device node. Devicetree bindings test failures were reported on mailing list on 16th of January and after two weeks still no fixes: sa8775p-ride.dtb: crypto@1dfa000: compatible: 'oneOf' conditional failed, one must be fixed: ... 'qcom,sa8775p-qce' is not one of ['qcom,ipq4019-qce', 'qcom,sm8150-qce'] Reported-by: Rob Herring Closes: https://lore.kernel.org/all/CAL_JsqJG_w9jyWjVR=QnPuJganG4uj9+9cEXZ__UAiCw2ZYZZA@mail.gmail.com/ Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250128115333.95021-1-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3926326d5b7b50a4c33975d412a6f5e09dfdddbd Author: Neil Armstrong Date: Mon Feb 3 14:23:18 2025 +0100 arm64: dts: qcom: sm8650: setup gpu thermal with higher temperatures [ Upstream commit 2250f65b32565eb8b757e89248c75977f370f498 ] On the SM8650, the dynamic clock and voltage scaling (DCVS) for the GPU is done from the HLOS, but the GPU can achieve a much higher temperature before failing according the reference downstream implementation. Set higher temperatures in the GPU trip points corresponding to the temperatures provided by Qualcomm in the dowstream source, much closer to the junction temperature and with a higher critical temperature trip in the case the HLOS DCVS cannot handle the temperature surge. The tsens MAX_THRESHOLD is set to 120C on those platforms, so set the hot to 110C to leave a chance to HLOS to react and critical to 115C to avoid the monitor thermal shutdown. Fixes: 497624ed5506 ("arm64: dts: qcom: sm8650: Throttle the GPU when overheating") Signed-off-by: Neil Armstrong Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250203-topic-sm8650-thermal-cpu-idle-v4-2-65e35f307301@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3eba8ec6cd0ad62bbaff55f76586f86d25758f26 Author: Mark Kettenis Date: Thu Jan 9 21:52:31 2025 +0100 arm64: dts: qcom: x1e80100: Mark usb_2 as dma-coherent [ Upstream commit 45bd6ff900cfe5038e2718a900f153ded3fa5392 ] Make this USB controller consistent with the others on this platform. Fixes: 4af46b7bd66f ("arm64: dts: qcom: x1e80100: Add USB nodes") Signed-off-by: Mark Kettenis Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250109205232.92336-1-kettenis@openbsd.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9389c0bee53e084a9b702fa341e4d0da55139c4c Author: Zhiguo Niu Date: Wed May 14 16:45:49 2025 +0800 f2fs: fix to correct check conditions in f2fs_cross_rename [ Upstream commit 9883494c45a13dc88d27dde4f988c04823b42a2f ] Should be "old_dir" here. Fixes: 5c57132eaf52 ("f2fs: support project quota") Signed-off-by: Zhiguo Niu Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 59471c123498efedc36ae2780f29c1cde13b583b Author: Zhiguo Niu Date: Wed May 14 16:45:48 2025 +0800 f2fs: use d_inode(dentry) cleanup dentry->d_inode [ Upstream commit a6c397a31f58a1d577c2c8d04b624e9baa31951c ] no logic changes. Signed-off-by: Zhiguo Niu Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Stable-dep-of: 9883494c45a1 ("f2fs: fix to correct check conditions in f2fs_cross_rename") Signed-off-by: Sasha Levin commit b0802f3bee526c58494170fb64afdf893a0415c4 Author: Chao Yu Date: Fri May 23 11:25:45 2025 +0800 f2fs: fix to skip f2fs_balance_fs() if checkpoint is disabled [ Upstream commit c836d3b8d94e3dd381e7d4bb918875084f85715e ] Syzbot reports a f2fs bug as below: INFO: task syz-executor328:5856 blocked for more than 144 seconds. Not tainted 6.15.0-rc6-syzkaller-00208-g3c21441eeffc #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor328 state:D stack:24392 pid:5856 tgid:5832 ppid:5826 task_flags:0x400040 flags:0x00004006 Call Trace: context_switch kernel/sched/core.c:5382 [inline] __schedule+0x168f/0x4c70 kernel/sched/core.c:6767 __schedule_loop kernel/sched/core.c:6845 [inline] schedule+0x165/0x360 kernel/sched/core.c:6860 io_schedule+0x81/0xe0 kernel/sched/core.c:7742 f2fs_balance_fs+0x4b4/0x780 fs/f2fs/segment.c:444 f2fs_map_blocks+0x3af1/0x43b0 fs/f2fs/data.c:1791 f2fs_expand_inode_data+0x653/0xaf0 fs/f2fs/file.c:1872 f2fs_fallocate+0x4f5/0x990 fs/f2fs/file.c:1975 vfs_fallocate+0x6a0/0x830 fs/open.c:338 ioctl_preallocate fs/ioctl.c:290 [inline] file_ioctl fs/ioctl.c:-1 [inline] do_vfs_ioctl+0x1b8f/0x1eb0 fs/ioctl.c:885 __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is after commit 84b5bb8bf0f6 ("f2fs: modify f2fs_is_checkpoint_ready logic to allow more data to be written with the CP disable"), we will get chance to allow f2fs_is_checkpoint_ready() to return true once below conditions are all true: 1. checkpoint is disabled 2. there are not enough free segments 3. there are enough free blocks Then it will cause f2fs_balance_fs() to trigger foreground GC. void f2fs_balance_fs(struct f2fs_sb_info *sbi, bool need) ... if (!f2fs_is_checkpoint_ready(sbi)) return; And the testcase mounts f2fs image w/ gc_merge,checkpoint=disable, so deadloop will happen through below race condition: - f2fs_do_shutdown - vfs_fallocate - gc_thread_func - file_start_write - __sb_start_write(SB_FREEZE_WRITE) - f2fs_fallocate - f2fs_expand_inode_data - f2fs_map_blocks - f2fs_balance_fs - prepare_to_wait - wake_up(gc_wait_queue_head) - io_schedule - bdev_freeze - freeze_super - sb->s_writers.frozen = SB_FREEZE_WRITE; - sb_wait_write(sb, SB_FREEZE_WRITE); - if (sbi->sb->s_writers.frozen >= SB_FREEZE_WRITE) continue; : cause deadloop This patch fix to add check condition in f2fs_balance_fs(), so that if checkpoint is disabled, we will just skip trigger foreground GC to avoid such deadloop issue. Meanwhile let's remove f2fs_is_checkpoint_ready() check condition in f2fs_balance_fs(), since it's redundant, due to the main logic in the function is to check: a) whether checkpoint is disabled b) there is enough free segments f2fs_balance_fs() still has all logics after f2fs_is_checkpoint_ready()'s removal. Reported-by: syzbot+aa5bb5f6860e08a60450@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/682d743a.a00a0220.29bc26.0289.GAE@google.com Fixes: 84b5bb8bf0f6 ("f2fs: modify f2fs_is_checkpoint_ready logic to allow more data to be written with the CP disable") Cc: Qi Han Signed-off-by: Chao Yu Reviewed-by: Zhiguo Niu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 33fe531cb20ce07f78cf9d8605cf2579d3d75794 Author: Horatiu Vultur Date: Fri May 23 10:27:16 2025 +0200 net: phy: mscc: Stop clearing the the UDPv4 checksum for L2 frames [ Upstream commit 57a92d14659df3e7e7e0052358c8cc68bbbc3b5e ] We have noticed that when PHY timestamping is enabled, L2 frames seems to be modified by changing two 2 bytes with a value of 0. The place were these 2 bytes seems to be random(or I couldn't find a pattern). In most of the cases the userspace can ignore these frames but if for example those 2 bytes are in the correction field there is nothing to do. This seems to happen when configuring the HW for IPv4 even that the flow is not enabled. These 2 bytes correspond to the UDPv4 checksum and once we don't enable clearing the checksum when using L2 frames then the frame doesn't seem to be changed anymore. Fixes: 7d272e63e0979d ("net: phy: mscc: timestamping and PHC support") Signed-off-by: Horatiu Vultur Link: https://patch.msgid.link/20250523082716.2935895-1-horatiu.vultur@microchip.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3c1906a3d50cb94fd0a10e97a1c0a40c0f033cb7 Author: Faicker Mo Date: Fri May 23 03:41:43 2025 +0000 net: openvswitch: Fix the dead loop of MPLS parse [ Upstream commit 0bdc924bfb319fb10d1113cbf091fc26fb7b1f99 ] The unexpected MPLS packet may not end with the bottom label stack. When there are many stacks, The label count value has wrapped around. A dead loop occurs, soft lockup/CPU stuck finally. stack backtrace: UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26 index -1 is out of range for type '__be32 [3]' CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-Ubuntu Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021 Call Trace: show_stack+0x52/0x5c dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x36 __ubsan_handle_out_of_bounds.cold+0x44/0x49 key_extract_l3l4+0x82a/0x840 [openvswitch] ? kfree_skbmem+0x52/0xa0 key_extract+0x9c/0x2b0 [openvswitch] ovs_flow_key_extract+0x124/0x350 [openvswitch] ovs_vport_receive+0x61/0xd0 [openvswitch] ? kernel_init_free_pages.part.0+0x4a/0x70 ? get_page_from_freelist+0x353/0x540 netdev_port_receive+0xc4/0x180 [openvswitch] ? netdev_port_receive+0x180/0x180 [openvswitch] netdev_frame_hook+0x1f/0x40 [openvswitch] __netif_receive_skb_core.constprop.0+0x23a/0xf00 __netif_receive_skb_list_core+0xfa/0x240 netif_receive_skb_list_internal+0x18e/0x2a0 napi_complete_done+0x7a/0x1c0 bnxt_poll+0x155/0x1c0 [bnxt_en] __napi_poll+0x30/0x180 net_rx_action+0x126/0x280 ? bnxt_msix+0x67/0x80 [bnxt_en] handle_softirqs+0xda/0x2d0 irq_exit_rcu+0x96/0xc0 common_interrupt+0x8e/0xa0 Fixes: fbdcdd78da7c ("Change in Openvswitch to support MPLS label depth of 3 in ingress direction") Signed-off-by: Faicker Mo Acked-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/259D3404-575D-4A6D-B263-1DF59A67CF89@zenlayer.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e2ec310c7a50271843c585e27ef14e48c66ce649 Author: Kuniyuki Iwashima Date: Thu May 22 15:18:56 2025 -0700 calipso: Don't call calipso functions for AF_INET sk. [ Upstream commit 6e9f2df1c550ead7cecb3e450af1105735020c92 ] syzkaller reported a null-ptr-deref in txopt_get(). [0] The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo, so struct ipv6_pinfo was NULL there. However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6 is always set in inet6_create(), meaning the socket was not IPv6 one. The root cause is missing validation in netlbl_conn_setattr(). netlbl_conn_setattr() switches branches based on struct sockaddr.sa_family, which is passed from userspace. However, netlbl_conn_setattr() does not check if the address family matches the socket. The syzkaller must have called connect() for an IPv6 address on an IPv4 socket. We have a proper validation in tcp_v[46]_connect(), but security_socket_connect() is called in the earlier stage. Let's copy the validation to netlbl_conn_setattr(). [0]: Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:txopt_get include/net/ipv6.h:390 [inline] RIP: 0010: Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00 RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00c RDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070 RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9e R10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00 R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80 FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0 PKRU: 80000000 Call Trace: calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557 netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177 selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569 selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline] selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615 selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931 security_socket_connect+0x50/0xa0 security/security.c:4598 __sys_connect_file+0xa4/0x190 net/socket.c:2067 __sys_connect+0x12c/0x170 net/socket.c:2088 __do_sys_connect net/socket.c:2098 [inline] __se_sys_connect net/socket.c:2095 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:2095 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f901b61a12d Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12d RDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003 RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000 Modules linked in: Fixes: ceba1832b1b2 ("calipso: Set the calipso socket label to match the secattr.") Reported-by: syzkaller Reported-by: John Cheung Closes: https://lore.kernel.org/netdev/CAP=Rh=M1LzunrcQB1fSGauMrJrhL6GGps5cPAKzHJXj6GQV+-g@mail.gmail.com/ Signed-off-by: Kuniyuki Iwashima Acked-by: Paul Moore Link: https://patch.msgid.link/20250522221858.91240-1-kuniyu@amazon.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f1fca0eae5a0573f226f46c6871260278e7dda12 Author: Hariprasad Kelam Date: Thu May 22 17:28:42 2025 +0530 octeontx2-pf: QOS: Refactor TC_HTB_LEAF_DEL_LAST callback [ Upstream commit 67af4ec948e8ce3ea53a9cf614d01fddf172e56d ] This patch addresses below issues, 1. Active traffic on the leaf node must be stopped before its send queue is reassigned to the parent. This patch resolves the issue by marking the node as 'Inner'. 2. During a system reboot, the interface receives TC_HTB_LEAF_DEL and TC_HTB_LEAF_DEL_LAST callbacks to delete its HTB queues. In the case of TC_HTB_LEAF_DEL_LAST, although the same send queue is reassigned to the parent, the current logic still attempts to update the real number of queues, leadning to below warnings New queues can't be registered after device unregistration. WARNING: CPU: 0 PID: 6475 at net/core/net-sysfs.c:1714 netdev_queue_update_kobjects+0x1e4/0x200 Fixes: 5e6808b4c68d ("octeontx2-pf: Add support for HTB offload") Signed-off-by: Hariprasad Kelam Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250522115842.1499666-1-hkelam@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 49ef400435071d14ebdc1577de923cb90e4e7f8c Author: Hariprasad Kelam Date: Thu May 22 15:17:41 2025 +0530 octeontx2-pf: QOS: Perform cache sync on send queue teardown [ Upstream commit 479c58016099d19686e36f6c50f912360839a7fa ] QOS is designed to create a new send queue whenever a class is created, ensuring proper shaping and scheduling. However, when multiple send queues are created and deleted in a loop, SMMU errors are observed. This patch addresses the issue by performing an data cache sync during the teardown of QOS send queues. Fixes: ab6dddd2a669 ("octeontx2-pf: qos send queues management") Signed-off-by: Hariprasad Kelam Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250522094742.1498295-1-hkelam@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit cdbabd316c5a4a9b0fda6aafe491e2db17fbb95d Author: Horatiu Vultur Date: Thu May 22 13:57:22 2025 +0200 net: phy: mscc: Fix memory leak when using one step timestamping [ Upstream commit 846992645b25ec4253167e3f931e4597eb84af56 ] Fix memory leak when running one-step timestamping. When running one-step sync timestamping, the HW is configured to insert the TX time into the frame, so there is no reason to keep the skb anymore. As in this case the HW will never generate an interrupt to say that the frame was timestamped, then the frame will never released. Fix this by freeing the frame in case of one-step timestamping. Fixes: 7d272e63e0979d ("net: phy: mscc: timestamping and PHC support") Signed-off-by: Horatiu Vultur Link: https://patch.msgid.link/20250522115722.2827199-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit be0cb02add593d6dc228fc736bfe0426bbcea885 Author: Thangaraj Samynathan Date: Mon May 26 11:00:48 2025 +0530 net: lan743x: Fix PHY reset handling during initialization and WOL [ Upstream commit 82d1096ca8b5dbb3158d707e6fb3ad21c3403a49 ] Remove lan743x_phy_init from lan743x_hardware_init as it resets the PHY registers, causing WOL to fail on subsequent attempts. Add a call to lan743x_hw_reset_phy in the probe function to ensure the PHY is reset during device initialization. Fixes: 23f0703c125be ("lan743x: Add main source files for new lan743x driver") Signed-off-by: Thangaraj Samynathan Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250526053048.287095-3-thangaraj.s@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 53ae47782c0dd8bbae2ed3b9780a4a9d673a5a49 Author: Thangaraj Samynathan Date: Mon May 26 11:00:47 2025 +0530 net: lan743x: rename lan743x_reset_phy to lan743x_hw_reset_phy [ Upstream commit 68927eb52d0af04863584930db06075d2610e194 ] rename the function to lan743x_hw_reset_phy to better describe it operation. Fixes: 23f0703c125be ("lan743x: Add main source files for new lan743x driver") Signed-off-by: Thangaraj Samynathan Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250526053048.287095-2-thangaraj.s@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 41fcc5b78df9e227e652551fbd598b9e13b187c2 Author: Greg Kroah-Hartman Date: Thu May 22 13:21:47 2025 +0200 net: phy: fix up const issues in to_mdio_device() and to_phy_device() [ Upstream commit e9cb929670a1e98b592b30f03f06e9e20110f318 ] Both to_mdio_device() and to_phy_device() "throw away" the const pointer attribute passed to them and return a non-const pointer, which generally is not a good thing overall. Fix this up by using container_of_const() which was designed for this very problem. Cc: Alexander Lobakin Cc: Andrew Lunn Cc: Heiner Kallweit Cc: Russell King Fixes: 7eab14de73a8 ("mdio, phy: fix -Wshadow warnings triggered by nested container_of()") Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2025052246-conduit-glory-8fc9@gregkh Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4adeac4a1f3b7a99ce4ef0c18b1ba75539e58ea9 Author: Jeremy Kerr Date: Mon May 26 10:44:33 2025 +0800 net: mctp: start tx queue on netdev open [ Upstream commit 126cd7852a62c6fab11a4a4cb6fa96421929ab69 ] We stop queues in ndo_stop, so they need to be restarted in ndo_open. This allows us to resume tx after a link down/up cycle. Suggested-by: Nitin Singh Fixes: 0791c0327a6e ("net: mctp: Add MCTP USB transport driver") Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20250526-dev-mctp-usb-v1-1-c7bd6cb75aa0@codeconstruct.com.au Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4318108368d55ce1bf79341718095aa66a236758 Author: Christophe JAILLET Date: Sat May 24 09:29:11 2025 +0200 net: airoha: Fix an error handling path in airoha_alloc_gdm_port() [ Upstream commit c59783780c8ad66f6076a9a7c74df3e006e29519 ] If register_netdev() fails, the error handling path of the probe will not free the memory allocated by the previous airoha_metadata_dst_alloc() call because port->dev->reg_state will not be NETREG_REGISTERED. So, an explicit airoha_metadata_dst_free() call is needed in this case to avoid a memory leak. Fixes: af3cf757d5c9 ("net: airoha: Move DSA tag in DMA descriptor") Signed-off-by: Christophe JAILLET Acked-by: Lorenzo Bianconi Reviewed-by: Simon Horman Link: https://patch.msgid.link/1b94b91345017429ed653e2f05d25620dc2823f9.1746715755.git.christophe.jaillet@wanadoo.fr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 034bc4a2a72dea2cfcaf24c6bae03c38ad5a0b87 Author: Wei Fang Date: Fri May 23 16:37:59 2025 +0800 net: phy: clear phydev->devlink when the link is deleted [ Upstream commit 0795b05a59b1371b18ffbf09d385296b12e9f5d5 ] There is a potential crash issue when disabling and re-enabling the network port. When disabling the network port, phy_detach() calls device_link_del() to remove the device link, but it does not clear phydev->devlink, so phydev->devlink is not a NULL pointer. Then the network port is re-enabled, but if phy_attach_direct() fails before calling device_link_add(), the code jumps to the "error" label and calls phy_detach(). Since phydev->devlink retains the old value from the previous attach/detach cycle, device_link_del() uses the old value, which accesses a NULL pointer and causes a crash. The simplified crash log is as follows. [ 24.702421] Call trace: [ 24.704856] device_link_put_kref+0x20/0x120 [ 24.709124] device_link_del+0x30/0x48 [ 24.712864] phy_detach+0x24/0x168 [ 24.716261] phy_attach_direct+0x168/0x3a4 [ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c [ 24.725140] phylink_of_phy_connect+0x1c/0x34 Therefore, phydev->devlink needs to be cleared when the device link is deleted. Fixes: bc66fa87d4fd ("net: phy: Add link between phy dev and mac dev") Signed-off-by: Wei Fang Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250523083759.3741168-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ac49b7560b4b08b1e4043a29214cc7ad77644c00 Author: Yonghong Song Date: Fri May 23 21:13:35 2025 -0700 bpf: Do not include stack ptr register in precision backtracking bookkeeping [ Upstream commit e2d2115e56c4a02377189bfc3a9a7933552a7b0f ] Yi Lai reported an issue ([1]) where the following warning appears in kernel dmesg: [ 60.643604] verifier backtracking bug [ 60.643635] WARNING: CPU: 10 PID: 2315 at kernel/bpf/verifier.c:4302 __mark_chain_precision+0x3a6c/0x3e10 [ 60.648428] Modules linked in: bpf_testmod(OE) [ 60.650471] CPU: 10 UID: 0 PID: 2315 Comm: test_progs Tainted: G OE 6.15.0-rc4-gef11287f8289-dirty #327 PREEMPT(full) [ 60.654385] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 60.656682] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 60.660475] RIP: 0010:__mark_chain_precision+0x3a6c/0x3e10 [ 60.662814] Code: 5a 30 84 89 ea e8 c4 d9 01 00 80 3d 3e 7d d8 04 00 0f 85 60 fa ff ff c6 05 31 7d d8 04 01 48 c7 c7 00 58 30 84 e8 c4 06 a5 ff <0f> 0b e9 46 fa ff ff 48 ... [ 60.668720] RSP: 0018:ffff888116cc7298 EFLAGS: 00010246 [ 60.671075] RAX: 54d70e82dfd31900 RBX: ffff888115b65e20 RCX: 0000000000000000 [ 60.673659] RDX: 0000000000000001 RSI: 0000000000000004 RDI: 00000000ffffffff [ 60.676241] RBP: 0000000000000400 R08: ffff8881f6f23bd3 R09: 1ffff1103ede477a [ 60.678787] R10: dffffc0000000000 R11: ffffed103ede477b R12: ffff888115b60ae8 [ 60.681420] R13: 1ffff11022b6cbc4 R14: 00000000fffffff2 R15: 0000000000000001 [ 60.684030] FS: 00007fc2aedd80c0(0000) GS:ffff88826fa8a000(0000) knlGS:0000000000000000 [ 60.686837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 60.689027] CR2: 000056325369e000 CR3: 000000011088b002 CR4: 0000000000370ef0 [ 60.691623] Call Trace: [ 60.692821] [ 60.693960] ? __pfx_verbose+0x10/0x10 [ 60.695656] ? __pfx_disasm_kfunc_name+0x10/0x10 [ 60.697495] check_cond_jmp_op+0x16f7/0x39b0 [ 60.699237] do_check+0x58fa/0xab10 ... Further analysis shows the warning is at line 4302 as below: 4294 /* static subprog call instruction, which 4295 * means that we are exiting current subprog, 4296 * so only r1-r5 could be still requested as 4297 * precise, r0 and r6-r10 or any stack slot in 4298 * the current frame should be zero by now 4299 */ 4300 if (bt_reg_mask(bt) & ~BPF_REGMASK_ARGS) { 4301 verbose(env, "BUG regs %x\n", bt_reg_mask(bt)); 4302 WARN_ONCE(1, "verifier backtracking bug"); 4303 return -EFAULT; 4304 } With the below test (also in the next patch): __used __naked static void __bpf_jmp_r10(void) { asm volatile ( "r2 = 2314885393468386424 ll;" "goto +0;" "if r2 <= r10 goto +3;" "if r1 >= -1835016 goto +0;" "if r2 <= 8 goto +0;" "if r3 <= 0 goto +0;" "exit;" ::: __clobber_all); } SEC("?raw_tp") __naked void bpf_jmp_r10(void) { asm volatile ( "r3 = 0 ll;" "call __bpf_jmp_r10;" "r0 = 0;" "exit;" ::: __clobber_all); } The following is the verifier failure log: 0: (18) r3 = 0x0 ; R3_w=0 2: (85) call pc+2 caller: R10=fp0 callee: frame1: R1=ctx() R3_w=0 R10=fp0 5: frame1: R1=ctx() R3_w=0 R10=fp0 ; asm volatile (" \ @ verifier_precision.c:184 5: (18) r2 = 0x20202000256c6c78 ; frame1: R2_w=0x20202000256c6c78 7: (05) goto pc+0 8: (bd) if r2 <= r10 goto pc+3 ; frame1: R2_w=0x20202000256c6c78 R10=fp0 9: (35) if r1 >= 0xffe3fff8 goto pc+0 ; frame1: R1=ctx() 10: (b5) if r2 <= 0x8 goto pc+0 mark_precise: frame1: last_idx 10 first_idx 0 subseq_idx -1 mark_precise: frame1: regs=r2 stack= before 9: (35) if r1 >= 0xffe3fff8 goto pc+0 mark_precise: frame1: regs=r2 stack= before 8: (bd) if r2 <= r10 goto pc+3 mark_precise: frame1: regs=r2,r10 stack= before 7: (05) goto pc+0 mark_precise: frame1: regs=r2,r10 stack= before 5: (18) r2 = 0x20202000256c6c78 mark_precise: frame1: regs=r10 stack= before 2: (85) call pc+2 BUG regs 400 The main failure reason is due to r10 in precision backtracking bookkeeping. Actually r10 is always precise and there is no need to add it for the precision backtracking bookkeeping. One way to fix the issue is to prevent bt_set_reg() if any src/dst reg is r10. Andrii suggested to go with push_insn_history() approach to avoid explicitly checking r10 in backtrack_insn(). This patch added push_insn_history() support for cond_jmp like 'rX rY' operations. In check_cond_jmp_op(), if any of rX or rY is a stack pointer, push_insn_history() will record such information, and later backtrack_insn() will do bt_set_reg() properly for those register(s). [1] https://lore.kernel.org/bpf/Z%2F8q3xzpU59CIYQE@ly-workstation/ Reported by: Yi Lai Fixes: 407958a0e980 ("bpf: encapsulate precision backtracking bookkeeping") Signed-off-by: Yonghong Song Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250524041335.4046126-1-yonghong.song@linux.dev Signed-off-by: Sasha Levin commit 0b9bb52796b239de6792d0d68cdc6eb505ebff96 Author: KaFai Wan Date: Mon May 26 21:33:58 2025 +0800 bpf: Avoid __bpf_prog_ret0_warn when jit fails [ Upstream commit 86bc9c742426a16b52a10ef61f5b721aecca2344 ] syzkaller reported an issue: WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357 Modules linked in: CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39 RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357 Call Trace: bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105 ... When creating bpf program, 'fp->jit_requested' depends on bpf_jit_enable. This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not set and bpf_jit_enable is set to 1, causing the arch to attempt JIT the prog, but jit failed due to FAULT_INJECTION. As a result, incorrectly treats the program as valid, when the program runs it calls `__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1). Reported-by: syzbot+0903f6d7f285e41cdf10@syzkaller.appspotmail.com Closes: https://lore.kernel.org/bpf/6816e34e.a70a0220.254cdc.002c.GAE@google.com Fixes: fa9dd599b4da ("bpf: get rid of pure_initcall dependency to enable jits") Signed-off-by: KaFai Wan Link: https://lore.kernel.org/r/20250526133358.2594176-1-mannkafai@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 920b6720bb63893b81516c0c45884a8350f9e4bf Author: Israel Rukshin Date: Tue Apr 22 13:33:45 2025 +0300 virtio-pci: Fix result size returned for the admin command completion [ Upstream commit 9ef41ebf787fcbde99ac404ae473f8467641f983 ] The result size returned by virtio_pci_admin_dev_parts_get() is 8 bytes larger than the actual result data size. This occurs because the result_sg_size field of the command is filled with the result length from virtqueue_get_buf(), which includes both the data size and an additional 8 bytes of status. This oversized result size causes two issues: 1. The state transferred to the destination includes 8 bytes of extra data at the end. 2. The allocated buffer in the kernel may be smaller than the returned size, leading to failures when reading beyond the allocated size. The commit fixes this by subtracting the status size from the result of virtqueue_get_buf(). This fix has been tested through live migrations with virtio-net, virtio-net-transitional, and virtio-blk devices. Fixes: 704806ca400e ("virtio: Extend the admin command to include the result size") Signed-off-by: Israel Rukshin Reviewed-by: Parav Pandit Reviewed-by: Max Gurtovoy Message-Id: <1745318025-23103-1-git-send-email-israelr@nvidia.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 2dd4781c5af99415ebbd2f7cc763feb109863c05 Author: Stanislav Fomichev Date: Wed May 21 20:11:28 2025 -0700 af_packet: move notifier's packet_dev_mc out of rcu critical section [ Upstream commit d8d85ef0a631df9127f202e6371bb33a0b589952 ] Syzkaller reports the following issue: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578 __mutex_lock+0x106/0xe80 kernel/locking/mutex.c:746 team_change_rx_flags+0x38/0x220 drivers/net/team/team_core.c:1781 dev_change_rx_flags net/core/dev.c:9145 [inline] __dev_set_promiscuity+0x3f8/0x590 net/core/dev.c:9189 netif_set_promiscuity+0x50/0xe0 net/core/dev.c:9201 dev_set_promiscuity+0x126/0x260 net/core/dev_api.c:286 packet_dev_mc net/packet/af_packet.c:3698 [inline] packet_dev_mclist_delete net/packet/af_packet.c:3722 [inline] packet_notifier+0x292/0xa60 net/packet/af_packet.c:4247 notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2214 [inline] call_netdevice_notifiers net/core/dev.c:2228 [inline] unregister_netdevice_many_notify+0x15d8/0x2330 net/core/dev.c:11972 rtnl_delete_link net/core/rtnetlink.c:3522 [inline] rtnl_dellink+0x488/0x710 net/core/rtnetlink.c:3564 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6955 netlink_rcv_skb+0x219/0x490 net/netlink/af_netlink.c:2534 Calling `PACKET_ADD_MEMBERSHIP` on an ops-locked device can trigger the `NETDEV_UNREGISTER` notifier, which may require disabling promiscuous and/or allmulti mode. Both of these operations require acquiring the netdev instance lock. Move the call to `packet_dev_mc` outside of the RCU critical section. The `mclist` modifications (add, del, flush, unregister) are protected by the RTNL, not the RCU. The RCU only protects the `sklist` and its associated `sks`. The delayed operation on the `mclist` entry remains within the RTNL. Reported-by: syzbot+b191b5ccad8d7a986286@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b191b5ccad8d7a986286 Fixes: ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations") Signed-off-by: Stanislav Fomichev Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20250522031129.3247266-1-stfomichev@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit cc94336dc3f3b2ac05ff7b093af71eb5c6e406cd Author: Suraj Gupta Date: Wed May 21 23:46:08 2025 +0530 net: xilinx: axienet: Fix Tx skb circular buffer occupancy check in dmaengine xmit [ Upstream commit 32374234ab0101881e7d0c6a8ef7ebce566c46c9 ] In Dmaengine flow, driver maintains struct skbuf_dma_descriptor rings each element of which corresponds to a skb. In Tx datapath, compare available space in skb ring with number of skbs instead of skb fragments. Replace x * (MAX_SKB_FRAGS) in netif_txq_completed_wake() and netif_txq_maybe_stop() with x * (1 skb) to fix the comparison. Fixes: 6a91b846af85 ("net: axienet: Introduce dmaengine support") Signed-off-by: Suraj Gupta Reviewed-by: Sean Anderson Link: https://patch.msgid.link/20250521181608.669554-1-suraj.gupta2@amd.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 33b58a27ba69cb33bc247bac9e10da5f9ad9cb64 Author: Horatiu Vultur Date: Wed May 21 14:41:59 2025 +0200 net: lan966x: Fix 1-step timestamping over ipv4 or ipv6 [ Upstream commit 57ee9584fd8606deef66d7b65fa4dcf94f6843aa ] When enabling 1-step timestamping for ptp frames that are over udpv4 or udpv6 then the inserted timestamp is added at the wrong offset in the frame, meaning that will modify the frame at the wrong place, so the frame will be malformed. To fix this, the HW needs to know which kind of frame it is to know where to insert the timestamp. For that there is a field in the IFH that says the PDU_TYPE, which can be NONE which is the default value, IPV4 or IPV6. Therefore make sure to set the PDU_TYPE so the HW knows where to insert the timestamp. Like I mention before the issue is not seen with L2 frames because by default the PDU_TYPE has a value of 0, which represents the L2 frames. Fixes: 77eecf25bd9d2f ("net: lan966x: Update extraction/injection for timestamping") Signed-off-by: Horatiu Vultur Link: https://patch.msgid.link/20250521124159.2713525-1-horatiu.vultur@microchip.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8b05aa3692e45b8249379dc52b14acc6a104d2e5 Author: Jack Morgenstein Date: Wed May 21 14:36:02 2025 +0300 RDMA/cma: Fix hang when cma_netevent_callback fails to queue_work [ Upstream commit 92a251c3df8ea1991cd9fe00f1ab0cfce18d7711 ] The cited commit fixed a crash when cma_netevent_callback was called for a cma_id while work on that id from a previous call had not yet started. The work item was re-initialized in the second call, which corrupted the work item currently in the work queue. However, it left a problem when queue_work fails (because the item is still pending in the work queue from a previous call). In this case, cma_id_put (which is called in the work handler) is therefore not called. This results in a userspace process hang (zombie process). Fix this by calling cma_id_put() if queue_work fails. Fixes: 45f5dcdd0497 ("RDMA/cma: Fix workqueue crash in cma_netevent_work_handler") Link: https://patch.msgid.link/r/4f3640b501e48d0166f312a64fdadf72b059bd04.1747827103.git.leon@kernel.org Signed-off-by: Jack Morgenstein Signed-off-by: Feng Liu Reviewed-by: Vlad Dumitrescu Signed-off-by: Leon Romanovsky Reviewed-by: Sharath Srinivasan Reviewed-by: Kalesh AP Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 17bada47e9ac3621c28e0ffa89af8279fedea00a Author: Stefano Garzarella Date: Wed May 21 14:17:05 2025 +0200 vsock/virtio: fix `rx_bytes` accounting for stream sockets [ Upstream commit 45ca7e9f0730ae36fc610e675b990e9cc9ca0714 ] In `struct virtio_vsock_sock`, we maintain two counters: - `rx_bytes`: used internally to track how many bytes have been read. This supports mechanisms like .stream_has_data() and sock_rcvlowat(). - `fwd_cnt`: used for the credit mechanism to inform available receive buffer space to the remote peer. These counters are updated via virtio_transport_inc_rx_pkt() and virtio_transport_dec_rx_pkt(). Since the beginning with commit 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko"), we call virtio_transport_dec_rx_pkt() in virtio_transport_stream_do_dequeue() only when we consume the entire packet, so partial reads, do not update `rx_bytes` and `fwd_cnt`. This is fine for `fwd_cnt`, because we still have space used for the entire packet, and we don't want to update the credit for the other peer until we free the space of the entire packet. However, this causes `rx_bytes` to be stale on partial reads. Previously, this didn’t cause issues because `rx_bytes` was used only by .stream_has_data(), and any unread portion of a packet implied data was still available. However, since commit 93b808876682 ("virtio/vsock: fix logic which reduces credit update messages"), we now rely on `rx_bytes` to determine if a credit update should be sent when the data in the RX queue drops below SO_RCVLOWAT value. This patch fixes the accounting by updating `rx_bytes` with the number of bytes actually read, even on partial reads, while leaving `fwd_cnt` untouched until the packet is fully consumed. Also introduce a new `buf_used` counter to check that the remote peer is honoring the given credit; this was previously done via `rx_bytes`. Fixes: 93b808876682 ("virtio/vsock: fix logic which reduces credit update messages") Signed-off-by: Stefano Garzarella Link: https://patch.msgid.link/20250521121705.196379-1-sgarzare@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit cd8bef963aaff980abca9755433ae783c979cfc6 Author: Subbaraya Sundeep Date: Wed May 21 16:00:43 2025 +0530 octeontx2-af: Send Link events one by one [ Upstream commit ba5cb47b56e5d89f0a5eb5163ffbfda1e3e7cef0 ] Send link events one after another otherwise new message is overwriting the message which is being processed by PF. Fixes: a88e0f936ba9 ("octeontx2: Detect the mbox up or down message via register") Signed-off-by: Subbaraya Sundeep Reviewed-by: Michal Swiatkowski Reviewed-by: Simon Horman Link: https://patch.msgid.link/1747823443-404-1-git-send-email-sbhatta@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7c01863b1c47f040d9674171e77789a423b9b128 Author: Nikita Zhandarovich Date: Tue May 20 14:32:39 2025 +0300 net: usb: aqc111: fix error handling of usbnet read calls [ Upstream commit 405b0d610745fb5e84fc2961d9b960abb9f3d107 ] Syzkaller, courtesy of syzbot, identified an error (see report [1]) in aqc111 driver, caused by incomplete sanitation of usb read calls' results. This problem is quite similar to the one fixed in commit 920a9fa27e78 ("net: asix: add proper error handling of usb read errors"). For instance, usbnet_read_cmd() may read fewer than 'size' bytes, even if the caller expected the full amount, and aqc111_read_cmd() will not check its result properly. As [1] shows, this may lead to MAC address in aqc111_bind() being only partly initialized, triggering KMSAN warnings. Fix the issue by verifying that the number of bytes read is as expected and not less. [1] Partial syzbot report: BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:208 [inline] BUG: KMSAN: uninit-value in usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 is_valid_ether_addr include/linux/etherdevice.h:208 [inline] usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] really_probe+0x4d1/0xd90 drivers/base/dd.c:658 __driver_probe_device+0x268/0x380 drivers/base/dd.c:800 ... Uninit was stored to memory at: dev_addr_mod+0xb0/0x550 net/core/dev_addr_lists.c:582 __dev_addr_set include/linux/netdevice.h:4874 [inline] eth_hw_addr_set include/linux/etherdevice.h:325 [inline] aqc111_bind+0x35f/0x1150 drivers/net/usb/aqc111.c:717 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 ... Uninit was stored to memory at: ether_addr_copy include/linux/etherdevice.h:305 [inline] aqc111_read_perm_mac drivers/net/usb/aqc111.c:663 [inline] aqc111_bind+0x794/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] ... Local variable buf.i created at: aqc111_read_perm_mac drivers/net/usb/aqc111.c:656 [inline] aqc111_bind+0x221/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 Reported-by: syzbot+3b6b9ff7b80430020c7b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3b6b9ff7b80430020c7b Tested-by: syzbot+3b6b9ff7b80430020c7b@syzkaller.appspotmail.com Fixes: df2d59a2ab6c ("net: usb: aqc111: Add support for getting and setting of MAC address") Signed-off-by: Nikita Zhandarovich Link: https://patch.msgid.link/20250520113240.2369438-1-n.zhandarovich@fintech.ru Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 5ccf9e2c51f1253a99795df8943a6bba5ef99058 Author: Radim Krčmář Date: Fri May 23 12:47:28 2025 +0200 RISC-V: KVM: lock the correct mp_state during reset [ Upstream commit 7917be170928189fefad490d1a1237fdfa6b856f ] Currently, the kvm_riscv_vcpu_sbi_system_reset() function locks vcpu->arch.mp_state_lock when updating tmp->arch.mp_state.mp_state which is incorrect hence fix it. Fixes: 2121cadec45a ("RISCV: KVM: Introduce mp_state_lock to avoid lock inversion") Signed-off-by: Radim Krčmář Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20250523104725.2894546-4-rkrcmar@ventanamicro.com Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit 6601a4e8d43b7b2015780732484d0a73c7159b49 Author: Fernando Fernandez Mancera Date: Wed May 21 11:41:08 2025 +0200 netfilter: nft_tunnel: fix geneve_opt dump [ Upstream commit 22a9613de4c29d7d0770bfb8a5a9d73eb8df7dad ] When dumping a nft_tunnel with more than one geneve_opt configured the netlink attribute hierarchy should be as follow: NFTA_TUNNEL_KEY_OPTS | |--NFTA_TUNNEL_KEY_OPTS_GENEVE | | | |--NFTA_TUNNEL_KEY_GENEVE_CLASS | |--NFTA_TUNNEL_KEY_GENEVE_TYPE | |--NFTA_TUNNEL_KEY_GENEVE_DATA | |--NFTA_TUNNEL_KEY_OPTS_GENEVE | | | |--NFTA_TUNNEL_KEY_GENEVE_CLASS | |--NFTA_TUNNEL_KEY_GENEVE_TYPE | |--NFTA_TUNNEL_KEY_GENEVE_DATA | |--NFTA_TUNNEL_KEY_OPTS_GENEVE ... Otherwise, userspace tools won't be able to fetch the geneve options configured correctly. Fixes: 925d844696d9 ("netfilter: nft_tunnel: add support for geneve opts") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 011d1c563e8225e3141e18e806a6d59be6d5ff10 Author: Florian Westphal Date: Wed May 21 11:38:48 2025 +0200 netfilter: nf_tables: nft_fib: consistent l3mdev handling [ Upstream commit 9a119669fb1924cd9658c16da39a5a585e129e50 ] fib has two modes: 1. Obtain output device according to source or destination address 2. Obtain the type of the address, e.g. local, unicast, multicast. 'fib daddr type' should return 'local' if the address is configured in this netns or unicast otherwise. 'fib daddr . iif type' should return 'local' if the address is configured on the input interface or unicast otherwise, i.e. more restrictive. However, if the interface is part of a VRF, then 'fib daddr type' returns unicast even if the address is configured on the incoming interface. This is broken for both ipv4 and ipv6. In the ipv4 case, inet_dev_addr_type must only be used if the 'iif' or 'oif' (strict mode) was requested. Else inet_addr_type_dev_table() needs to be used and the correct dev argument must be passed as well so the correct fib (vrf) table is used. In the ipv6 case, the bug is similar, without strict mode, dev is NULL so .flowi6_l3mdev will be set to 0. Add a new 'nft_fib_l3mdev_master_ifindex_rcu()' helper and use that to init the .l3mdev structure member. For ipv6, use it from nft_fib6_flowi_init() which gets called from both the 'type' and the 'route' mode eval functions. This provides consistent behaviour for all modes for both ipv4 and ipv6: If strict matching is requested, the input respectively output device of the netfilter hooks is used. Otherwise, use skb->dev to obtain the l3mdev ifindex. Without this, most type checks in updated nft_fib.sh selftest fail: FAIL: did not find veth0 . 10.9.9.1 . local in fibtype4 FAIL: did not find veth0 . dead:1::1 . local in fibtype6 FAIL: did not find veth0 . dead:9::1 . local in fibtype6 FAIL: did not find tvrf . 10.0.1.1 . local in fibtype4 FAIL: did not find tvrf . 10.9.9.1 . local in fibtype4 FAIL: did not find tvrf . dead:1::1 . local in fibtype6 FAIL: did not find tvrf . dead:9::1 . local in fibtype6 FAIL: fib expression address types match (iif in vrf) (fib errounously returns 'unicast' for all of them, even though all of these addresses are local to the vrf). Fixes: f6d0cbcf09c5 ("netfilter: nf_tables: add fib expression") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 7c0a16f6ea2b1c82a03bccd5d1bdb4a7bbd4d987 Author: Jiayuan Chen Date: Fri May 16 22:17:12 2025 +0800 bpf, sockmap: Avoid using sk_socket after free when sending [ Upstream commit 8259eb0e06d8f64c700f5fbdb28a5c18e10de291 ] The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected. Race conditions: ''' CPU0 CPU1 backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here ''' The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } ''' Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions. With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work. If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync(). In summary, we require synchronization to coordinate the backlog thread and close() thread. The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... ''' Fixes: 4b4647add7d3 ("sock_map: avoid race between sock_map_close and sk_psock_put") Reported-by: Michal Luczaj Signed-off-by: Jiayuan Chen Signed-off-by: Martin KaFai Lau Reviewed-by: John Fastabend Link: https://lore.kernel.org/r/20250516141713.291150-1-jiayuan.chen@linux.dev Signed-off-by: Sasha Levin commit 7b8526bb489780ccc0caffc446ecabec83cfe568 Author: Kees Cook Date: Tue May 20 09:31:35 2025 -0700 Bluetooth: btintel: Check dsbr size from EFI variable [ Upstream commit 3aa1dc3c9060e335e82e9c182bf3d1db29220b1b ] Since the size of struct btintel_dsbr is already known, we can just start there instead of querying the EFI variable size. If the final result doesn't match what we expect also fail. This fixes a stack buffer overflow when the EFI variable is larger than struct btintel_dsbr. Reported-by: zepta Closes: https://lore.kernel.org/all/CAPBS6KoaWV9=dtjTESZiU6KK__OZX0KpDk-=JEH8jCHFLUYv3Q@mail.gmail.com Fixes: eb9e749c0182 ("Bluetooth: btintel: Allow configuring drive strength of BRI") Signed-off-by: Kees Cook Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c6cbc5c12b185a16e871662042c9d2169f94f18c Author: Dmitry Antipov Date: Tue May 20 11:42:30 2025 +0300 Bluetooth: MGMT: iterate over mesh commands in mgmt_mesh_foreach() [ Upstream commit 3bb88524b7d030160bb3c9b35f928b2778092111 ] In 'mgmt_mesh_foreach()', iterate over mesh commands rather than generic mgmt ones. Compile tested only. Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh") Signed-off-by: Dmitry Antipov Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit e81d71c235d1ec5c693d7138d7bbcd485a232ca5 Author: Li RongQing Date: Wed May 21 11:46:47 2025 +0800 vfio/type1: Fix error unwind in migration dirty bitmap allocation [ Upstream commit 4518e5a60c7fbf0cdff393c2681db39d77b4f87e ] When setting up dirty page tracking at the vfio IOMMU backend for device migration, if an error is encountered allocating a tracking bitmap, the unwind loop fails to free previously allocated tracking bitmaps. This occurs because the wrong loop index is used to generate the tracking object. This results in unintended memory usage for the life of the current DMA mappings where bitmaps were successfully allocated. Use the correct loop index to derive the tracking object for freeing during unwind. Fixes: d6a4c185660c ("vfio iommu: Implementation of ioctl for dirty pages tracking") Signed-off-by: Li RongQing Link: https://lore.kernel.org/r/20250521034647.2877-1-lirongqing@baidu.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit edc2fe00c6dfe811771adbbf09d36b8a3f8fd5dd Author: Florian Westphal Date: Wed May 21 11:38:47 2025 +0200 netfilter: nf_tables: nft_fib_ipv6: fix VRF ipv4/ipv6 result discrepancy [ Upstream commit 8b53f46eb430fe5b42d485873b85331d2de2c469 ] With a VRF, ipv4 and ipv6 FIB expression behave differently. fib daddr . iif oif Will return the input interface name for ipv4, but the real device for ipv6. Example: If VRF device name is tvrf and real (incoming) device is veth0. First round is ok, both ipv4 and ipv6 will yield 'veth0'. But in the second round (incoming device will be set to "tvrf"), ipv4 will yield "tvrf" whereas ipv6 returns "veth0" for the second round too. This makes ipv6 behave like ipv4. A followup patch will add a test case for this, without this change it will fail with: get element inet t fibif6iif { tvrf . dead:1::99 . tvrf } ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ FAIL: did not find tvrf . dead:1::99 . tvrf in fibif6iif Alternatively we could either not do anything at all or change ipv4 to also return the lower/real device, however, nft (userspace) doc says "iif: if fib lookup provides a route then check its output interface is identical to the packets input interface." which is what the nft fib ipv4 behaviour is. Fixes: f6d0cbcf09c5 ("netfilter: nf_tables: add fib expression") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 2c2e34fa81c22f245d7c32867377b807be0223ed Author: Florian Westphal Date: Fri May 16 16:12:13 2025 +0200 netfilter: xtables: support arpt_mark and ipv6 optstrip for iptables-nft only builds [ Upstream commit c38eb2973c18d34a8081d173a6ad298461f4a37c ] Its now possible to build a kernel that has no support for the classic xtables get/setsockopt interfaces and builtin tables. In this case, we have CONFIG_IP6_NF_MANGLE=n and CONFIG_IP_NF_ARPTABLES=n. For optstript, the ipv6 code is so small that we can enable it if netfilter ipv6 support exists. For mark, check if either classic arptables or NFT_ARP_COMPAT is set. Fixes: a9525c7f6219 ("netfilter: xtables: allow xtables-nft only builds") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit b397b309456b7671dbb0a18d9d32dfb8d93fb8f0 Author: Di Shen Date: Tue May 20 13:49:43 2025 +0800 bpf: Revert "bpf: remove unnecessary rcu_read_{lock,unlock}() in multi-uprobe attach logic" [ Upstream commit 4e2e6841ff761cc15a54e8bebcf35d7325ec78a2 ] This reverts commit 4a8f635a6054. Althought get_pid_task() internally already calls rcu_read_lock() and rcu_read_unlock(), the find_vpid() was not. The documentation for find_vpid() clearly states: "Must be called with the tasklist_lock or rcu_read_lock() held." Add proper rcu_read_lock/unlock() to protect the find_vpid(). Fixes: 4a8f635a6054 ("bpf: remove unnecessary rcu_read_{lock,unlock}() in multi-uprobe attach logic") Reported-by: Xuewen Yan Signed-off-by: Di Shen Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20250520054943.5002-1-xuewen.yan@unisoc.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 62d5bfd0b441eb0ec341a3624ed212bacca25859 Author: Shayne Chen Date: Thu May 15 11:29:51 2025 +0800 wifi: mt76: fix available_antennas setting [ Upstream commit 249173e94dd5edef9e704f89513de7d9715ddf22 ] Check if available_antennas_tx and available_antennas_rx are already set during the per-chip initialization phase; otherwise, they could be overwritten with incorrect values. Fixes: 69d54ce7491d ("wifi: mt76: mt7996: switch to single multi-radio wiphy") Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20250515032952.1653494-8-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 07e6672128e25303fb352ecfad70331ef0efb487 Author: Shayne Chen Date: Thu May 15 11:29:50 2025 +0800 wifi: mt76: mt7996: fix RX buffer size of MCU event [ Upstream commit 42cb27af34de4acf680606fad2c1f2932110591f ] Some management frames are first processed by the firmware and then passed to the driver through the MCU event rings. In CONNAC3, event rings do not support scatter-gather and have a size limitation of 2048 bytes. If a packet sized between 1728 and 2048 bytes arrives from an event ring, the ring will hang because the driver attempts to use scatter-gather to process it. To fix this, include the size of struct skb_shared_info in the MCU RX buffer size to prevent scatter-gather from being used for event skb in mt76_dma_rx_fill_buf(). Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Co-developed-by: Peter Chiu Signed-off-by: Peter Chiu Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20250515032952.1653494-7-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 6cb11d753204a5ce234b554e93562d46e9622e4f Author: Peter Chiu Date: Thu May 15 11:29:48 2025 +0800 wifi: mt76: mt7996: fix invalid NSS setting when TX path differs from NSS [ Upstream commit d5012734fc4bd5371e2e8dea8c2f3d28287573b8 ] The maximum TX path and NSS may differ on a band. For example, one variant of the MT7992 has 5 TX paths and 4 NSS on the 5 GHz band. To address this, add orig_antenna_mask to record the maximum NSS and prevent setting an invalid NSS in mt7996_set_antenna(). Fixes: 69d54ce7491d ("wifi: mt76: mt7996: switch to single multi-radio wiphy") Signed-off-by: Peter Chiu Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20250515032952.1653494-5-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3263de3744de447a745e9870640d476be3675764 Author: Peter Chiu Date: Thu May 15 11:29:46 2025 +0800 wifi: mt76: mt7996: set EHT max ampdu length capability [ Upstream commit 8b2f574845e33d02e7fbad2d3192a8b717567afa ] Set the max AMPDU length in the EHT MAC CAP. Without this patch, the peer station cannot obtain the correct capability, which prevents achieving peak throughput on the 2 GHz band. Fixes: 1816ad9381e0 ("wifi: mt76: mt7996: add max mpdu len capability") Signed-off-by: Peter Chiu Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20250515032952.1653494-3-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 1b0585a84ff55464a4a727af5fddccae319f5c1b Author: Howard Hsu Date: Thu May 15 11:29:45 2025 +0800 wifi: mt76: mt7996: fix beamformee SS field [ Upstream commit 5c78949fc7cd772d483a8abe126fe90937c0f002 ] Fix the beamformee SS field for the mt7996, mt7992 and mt7990 chipsets. For the mt7992, this value shall be set to 0x4, while the others shall be set to 0x3. Fixes: 5b20557593d4 ("wifi: mt76: connac: adjust phy capabilities based on band constraints") Signed-off-by: Howard Hsu Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20250515032952.1653494-2-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7a1c36a70eb6d3901fc048a07abec1e4a8f9a195 Author: Michael Lo Date: Mon Apr 14 09:39:54 2025 +0800 wifi: mt76: mt7925: ensure all MCU commands wait for response [ Upstream commit aa97ff5782cf01cf2163593e1f57bbde63a06047 ] Modify MCU command sending functions to wait for a response, ensuring consistent behavior across all commands and improves reliability by confirming that each command is processed successfully. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Michael Lo Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250414013954.1151774-3-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit dca019fa8f59220bb642b517ae0801bb7687f3cc Author: Ming Yen Hsieh Date: Mon Apr 14 09:39:53 2025 +0800 wifi: mt76: mt7925: refine the sniffer commnad [ Upstream commit bd02eebfc0b3502fe8322cf229b4c801416d1007 ] Remove a duplicate call to `mt76_mcu_send_msg` to fix redundant operations in the sniffer command handling. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250414013954.1151774-2-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 63b450ea55a4e2ed44beba89eb14978abd060a62 Author: Ming Yen Hsieh Date: Mon Apr 14 09:39:52 2025 +0800 wifi: mt76: mt7925: prevent multiple scan commands [ Upstream commit 122f270aca2c86d7de264ab67161c845e0691d73 ] Add a check to ensure only one scan command is active at a time by testing the MT76_HW_SCANNING state. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250414013954.1151774-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d825ed9fd768be10d52beba6f57a4b50c0c154aa Author: Henry Martin Date: Mon Apr 7 14:19:00 2025 +0800 wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init() [ Upstream commit efb95439c1477bbc955cacd0179c35e7861b437c ] devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7915_mmio_wed_init(). Fixes: 4f831d18d12d ("wifi: mt76: mt7915: enable WED RX support") Signed-off-by: Henry Martin Link: https://patch.msgid.link/20250407061900.85317-1-bsdhenrymartin@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit af861c6dea2ef06845a5c7672999a06c06099735 Author: Henry Martin Date: Mon Apr 7 11:23:49 2025 +0800 wifi: mt76: mt7996: Fix null-ptr-deref in mt7996_mmio_wed_init() [ Upstream commit 8f30e2b059757d8711a823e4c9c023db62a1d171 ] devm_ioremap() returns NULL on error. Currently, mt7996_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7996_mmio_wed_init() Fixes: 83eafc9251d6 ("wifi: mt76: mt7996: add wed tx support") Signed-off-by: Henry Martin Link: https://patch.msgid.link/20250407032349.83360-1-bsdhenrymartin@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f9b8bd88620d94b058b9583580d1cd89c4041323 Author: Feng Jiang Date: Wed Apr 2 14:24:15 2025 +0800 wifi: mt76: scan: Fix 'mlink' dereferenced before IS_ERR_OR_NULL check [ Upstream commit 7e1fcf687c2fb22ad25cf3fae322a37452f5f560 ] Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202504011739.HvUKtUUe-lkp@intel.com/ Fixes: 3ba20af886d1 ("wifi: mt76: scan: set vif offchannel link for scanning/roc") Signed-off-by: Feng Jiang Link: https://patch.msgid.link/20250402062415.25434-1-jiangfeng@kylinos.cn Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 4e83956ad117c160317f9bd7f53c66503d716d2b Author: Pauli Virtanen Date: Sat May 3 17:08:21 2025 +0300 Bluetooth: separate CIS_LINK and BIS_LINK link types [ Upstream commit 23205562ffc8de20f57afdd984858cab29e77968 ] Use separate link type id for unicast and broadcast ISO connections. These connection types are handled with separate HCI commands, socket API is different, and hci_conn has union fields that are different in the two cases, so they shall not be mixed up. Currently in most places it is attempted to distinguish ucast by bacmp(&c->dst, BDADDR_ANY) but it is wrong as dst is set for bcast sink hci_conn in iso_conn_ready(). Additionally checking sync_handle might be OK, but depends on details of bcast conn configuration flow. To avoid complicating it, use separate link types. Fixes: f764a6c2c1e4 ("Bluetooth: ISO: Add broadcast support") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 932d9f87a2a4da2f846b043e2d26aff7db69e325 Author: Luiz Augusto von Dentz Date: Fri Apr 11 12:37:50 2025 -0400 Bluetooth: ISO: Fix not using SID from adv report [ Upstream commit e2d471b7806b09744d65a64bcf41337468f2443b ] Up until now it has been assumed that the application would be able to enter the advertising SID in sockaddr_iso_bc.bc_sid, but userspace has no access to SID since the likes of MGMT_EV_DEVICE_FOUND cannot carry it, so it was left unset (0x00) which means it would be unable to synchronize if the broadcast source is using a different SID e.g. 0x04: > HCI Event: LE Meta Event (0x3e) plen 57 LE Extended Advertising Report (0x0d) Num reports: 1 Entry 0 Event type: 0x0000 Props: 0x0000 Data status: Complete Address type: Random (0x01) Address: 0B:82:E8:50:6D:C8 (Non-Resolvable) Primary PHY: LE 1M Secondary PHY: LE 2M SID: 0x04 TX power: 127 dBm RSSI: -55 dBm (0xc9) Periodic advertising interval: 180.00 msec (0x0090) Direct address type: Public (0x00) Direct address: 00:00:00:00:00:00 (OUI 00-00-00) Data length: 0x1f 06 16 52 18 5b 0b e1 05 16 56 18 04 00 11 30 4c ..R.[....V....0L 75 69 7a 27 73 20 53 32 33 20 55 6c 74 72 61 uiz's S23 Ultra Service Data: Broadcast Audio Announcement (0x1852) Broadcast ID: 14748507 (0xe10b5b) Service Data: Public Broadcast Announcement (0x1856) Data[2]: 0400 Unknown EIR field 0x30[16]: 4c75697a27732053323320556c747261 < HCI Command: LE Periodic Advertising Create Sync (0x08|0x0044) plen 14 Options: 0x0000 Use advertising SID, Advertiser Address Type and address Reporting initially enabled SID: 0x00 (<- Invalid) Adv address type: Random (0x01) Adv address: 0B:82:E8:50:6D:C8 (Non-Resolvable) Skip: 0x0000 Sync timeout: 20000 msec (0x07d0) Sync CTE type: 0x0000 So instead this changes now allow application to set HCI_SID_INVALID which will make hci_le_pa_create_sync to wait for a report, update the conn->sid using the report SID and only then issue PA create sync command: < HCI Command: LE Periodic Advertising Create Sync Options: 0x0000 Use advertising SID, Advertiser Address Type and address Reporting initially enabled SID: 0x04 Adv address type: Random (0x01) Adv address: 0B:82:E8:50:6D:C8 (Non-Resolvable) Skip: 0x0000 Sync timeout: 20000 msec (0x07d0) Sync CTE type: 0x0000 > HCI Event: LE Meta Event (0x3e) plen 16 LE Periodic Advertising Sync Established (0x0e) Status: Success (0x00) Sync handle: 64 Advertising SID: 0x04 Advertiser address type: Random (0x01) Advertiser address: 0B:82:E8:50:6D:C8 (Non-Resolvable) Advertiser PHY: LE 2M (0x02) Periodic advertising interval: 180.00 msec (0x0090) Advertiser clock accuracy: 0x05 Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 23205562ffc8 ("Bluetooth: separate CIS_LINK and BIS_LINK link types") Signed-off-by: Sasha Levin commit 63145c84d6b9110f68775728d4469bf07a451470 Author: Qasim Ijaz Date: Mon Apr 21 12:13:44 2025 +0100 wifi: mt76: mt7996: avoid null deref in mt7996_stop_phy() [ Upstream commit a0bdd3d1b94d22dd9d255fd148eb9183ea0a822f ] In mt7996_stop_phy() the mt7996_phy structure is dereferenced before the null sanity check which could lead to a null deref. Fix by moving the dereference operation after the sanity check. Fixes: 69d54ce7491d ("wifi: mt76: mt7996: switch to single multi-radio wiphy") Signed-off-by: Qasim Ijaz Link: https://patch.msgid.link/20250421111344.11484-1-qasdev00@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 83a422c8169eef95aef57f7ddc467bb126d9ae81 Author: Qasim Ijaz Date: Mon Apr 21 12:25:44 2025 +0100 wifi: mt76: mt7996: avoid NULL pointer dereference in mt7996_set_monitor() [ Upstream commit cb423ddad0f6e6f55b1700422ab777b25597cc83 ] The function mt7996_set_monitor() dereferences phy before the NULL sanity check. Fix this to avoid NULL pointer dereference by moving the dereference after the check. Fixes: 69d54ce7491d ("wifi: mt76: mt7996: switch to single multi-radio wiphy") Signed-off-by: Qasim Ijaz Link: https://patch.msgid.link/20250421112544.13430-1-qasdev00@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b623ad5972d3e264dd7dae389dec32f0dc70dd90 Author: Qasim Ijaz Date: Mon Apr 21 12:05:50 2025 +0100 wifi: mt76: mt7996: prevent uninit return in mt7996_mac_sta_add_links [ Upstream commit d9bc625861d490cb76ae8af86fac6f8ab0655a18 ] If link_conf_dereference_protected() or mt7996_vif_link() or link_sta_dereference_protected() fail the code jumps to the error_unlink label and returns ret which is uninitialised. Fix this by setting err before jumping to error_unlink. Fixes: c7e4fc362443 ("wifi: mt76: mt7996: Update mt7996_mcu_add_sta to MLO support") Fixes: dd82a9e02c05 ("wifi: mt76: mt7996: Rely on mt7996_sta_link in sta_add/sta_remove callbacks") Signed-off-by: Qasim Ijaz Link: https://patch.msgid.link/20250421110550.9839-1-qasdev00@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 8340cb173750c1ea99cd643006b72f8b0e6c21f2 Author: Charles Han Date: Mon Apr 7 17:55:51 2025 +0800 wifi: mt76: mt7996: Add NULL check in mt7996_thermal_init [ Upstream commit caf4b347c5dc40fdd125793b5e82ba9fc4de5275 ] devm_kasprintf() can return a NULL pointer on failure,but this returned value in mt7996_thermal_init() is not checked. Add NULL check in mt7996_thermal_init(), to handle kernel NULL pointer dereference error. Fixes: 69d54ce7491d ("wifi: mt76: mt7996: switch to single multi-radio wiphy") Signed-off-by: Charles Han Link: https://patch.msgid.link/20250407095551.32127-1-hanchunchao@inspur.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3c68444b2a1e0b2cb5c5d4e4230ea0c38a3cf147 Author: Dan Carpenter Date: Fri Mar 21 17:35:40 2025 +0300 wifi: mt76: mt7925: Fix logical vs bitwise typo [ Upstream commit 88224119863c39fa67581874e1ba218fa56113b4 ] This was supposed to be & instead of &&. Fixes: f0317215b367 ("wifi: mt76: mt7925: add EHT control support based on the CLC data") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/d323a443-4e81-4064-8563-b62274b53ef4@stanley.mountain Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 72275c888f8962b406ee9c6885c79bf68cca5a63 Author: Michal Koutný Date: Mon May 5 14:12:00 2025 +0200 kernfs: Relax constraint in draining guard [ Upstream commit 071d8e4c2a3b0999a9b822e2eb8854784a350f8a ] The active reference lifecycle provides the break/unbreak mechanism but the active reference is not truly active after unbreak -- callers don't use it afterwards but it's important for proper pairing of kn->active counting. Assuming this mechanism is in place, the WARN check in kernfs_should_drain_open_files() is too sensitive -- it may transiently catch those (rightful) callers between kernfs_unbreak_active_protection() and kernfs_put_active() as found out by Chen Ridong: kernfs_remove_by_name_ns kernfs_get_active // active=1 __kernfs_remove // active=0x80000002 kernfs_drain ... wait_event //waiting (active == 0x80000001) kernfs_break_active_protection // active = 0x80000001 // continue kernfs_unbreak_active_protection // active = 0x80000002 ... kernfs_should_drain_open_files // warning occurs kernfs_put_active To avoid the false positives (mind panic_on_warn) remove the check altogether. (This is meant as quick fix, I think active reference break/unbreak may be simplified with larger rework.) Fixes: bdb2fd7fc56e1 ("kernfs: Skip kernfs_drain_open_files() more aggressively") Link: https://lore.kernel.org/r/kmmrseckjctb4gxcx2rdminrjnq2b4ipf7562nvfd432ld5v5m@2byj5eedkb2o/ Cc: Chen Ridong Signed-off-by: Michal Koutný Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20250505121201.879823-1-mkoutny@suse.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2772b6726f01a3c2d69e9eacfb6789ec34d800c7 Author: Kalesh AP Date: Tue May 20 09:29:09 2025 +0530 RDMA/bnxt_re: Fix return code of bnxt_re_configure_cc [ Upstream commit 990b5c07f677a0b633b41130a70771337c18343e ] Driver currently supports modifying GEN0_EXT0 CC parameters through debugfs hook. Fixed to return -EOPNOTSUPP instead of -EINVAL in bnxt_re_configure_cc() when the user tries to modify any other CC parameters. Fixes: 656dff55da19 ("RDMA/bnxt_re: Congestion control settings using debugfs hook") Signed-off-by: Kalesh AP Link: https://patch.msgid.link/20250520035910.1061918-4-kalesh-anakkur.purayil@broadcom.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 47ec7f85591d5b5e696e4a69f968c86e027f688b Author: Gautam R A Date: Tue May 20 09:29:08 2025 +0530 RDMA/bnxt_re: Fix missing error handling for tx_queue [ Upstream commit e3d57a00d4d1f36689e9eab80b60d5024361efec ] bnxt_re_fill_gen0_ext0() did not return an error when attempting to modify CMDQ_MODIFY_ROCE_CC_MODIFY_MASK_TX_QUEUE, leading to silent failures. Fixed this by returning -EOPNOTSUPP for tx_queue modifications and ensuring proper error propagation in bnxt_re_configure_cc(). Fixes: 656dff55da19 ("RDMA/bnxt_re: Congestion control settings using debugfs hook") Signed-off-by: Gautam R A Link: https://patch.msgid.link/20250520035910.1061918-3-kalesh-anakkur.purayil@broadcom.com Reviewed-by: Kalesh AP Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 10c30e005c5fe885545f6fb22f38f6605d2d28a0 Author: Gautam R A Date: Tue May 20 09:29:07 2025 +0530 RDMA/bnxt_re: Fix incorrect display of inactivity_cp in debugfs output [ Upstream commit 58d7a965bb2b014d467445d38cdb07099b1f0f77 ] The inactivity_cp parameter in debugfs was not being read or written correctly, resulting in "Invalid argument" errors. Fixed this by ensuring proper mapping of inactivity_cp in both the map_cc_config_offset_gen0_ext0 and bnxt_re_fill_gen0_ext0() functions. Fixes: 656dff55da19 ("RDMA/bnxt_re: Congestion control settings using debugfs hook") Signed-off-by: Gautam R A Link: https://patch.msgid.link/20250520035910.1061918-2-kalesh-anakkur.purayil@broadcom.com Reviewed-by: Kalesh AP Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d383ae6a95143e0d9b5c022da01a7be71d708549 Author: Shivasharan S Date: Wed May 14 02:09:41 2025 -0700 scsi: mpt3sas: Fix _ctl_get_mpt_mctp_passthru_adapter() to return IOC pointer [ Upstream commit 9ad5249b37b59baaf2da1014f397c2e23b605075 ] Fix _ctl_get_mpt_mctp_passthru_adapter() to return the correct IOC pointer to caller based on dev_index. Signed-off-by: Shivasharan S Link: https://lore.kernel.org/r/1747213781-31545-1-git-send-email-shivasharan.srikanteshwara@broadcom.com Fixes: c72be4b5bb7c ("scsi: mpt3sas: Add support for MCTP Passthrough commands") Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 42982d90f2752eda78408b8d96e0de96acbd9a53 Author: ping.gao Date: Fri May 16 16:38:12 2025 +0800 scsi: ufs: mcq: Delete ufshcd_release_scsi_cmd() in ufshcd_mcq_abort() [ Upstream commit 53755903b9357e69b2dd6a02fafbb1e30c741895 ] After UFS_ABORT_TASK has been processed successfully, the host will generate MCQ IRQ for ABORT TAG with response OCS_ABORTED. This results in ufshcd_compl_one_cqe() calling ufshcd_release_scsi_cmd(). But ufshcd_mcq_abort() already calls ufshcd_release_scsi_cmd(), resulting in __ufshcd_release() being called twice. This means hba->clk_gating.active_reqs will be decreased twice, making it go negative. Delete ufshcd_release_scsi_cmd() in ufshcd_mcq_abort(). Fixes: f1304d442077 ("scsi: ufs: mcq: Added ufshcd_mcq_abort()") Signed-off-by: ping.gao Link: https://lore.kernel.org/r/20250516083812.3894396-1-ping.gao@samsung.com Reviewed-by: Peter Wang Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 416f37da8df37a5b67ff7d0d9fb5d781e692f64a Author: Hao Chang Date: Sat Mar 29 10:40:29 2025 +0800 pinctrl: mediatek: Fix the invalid conditions [ Upstream commit 86dee87f4b2e6ac119b03810e58723d0b27787a4 ] The variable count_reg_names is defined as an int type and cannot be directly compared to an unsigned int. To resolve this issue, first verify the correctness of count_reg_names. Link: https://lore.kernel.org/all/5ae93d42e4c4e70fb33bf35dcc37caebf324c8d3.camel@mediatek.com/T/ Signed-off-by: Hao Chang Signed-off-by: Qingliang Li Link: https://lore.kernel.org/20250329024533.5279-1-ot_chhao.chang@mediatek.com Signed-off-by: Linus Walleij Stable-dep-of: 1c9977b26347 ("pinctrl: mediatek: eint: Fix invalid pointer dereference for v1 platforms") Signed-off-by: Sasha Levin commit 5a85c21f812e02cb00ca07007d88acdd42d08c46 Author: Toke Høiland-Jørgensen Date: Wed Apr 2 13:22:16 2025 +0200 wifi: ath9k_htc: Abort software beacon handling if disabled [ Upstream commit ac4e317a95a1092b5da5b9918b7118759342641c ] A malicious USB device can send a WMI_SWBA_EVENTID event from an ath9k_htc-managed device before beaconing has been enabled. This causes a device-by-zero error in the driver, leading to either a crash or an out of bounds read. Prevent this by aborting the handling in ath9k_htc_swba() if beacons are not enabled. Reported-by: Robert Morris Closes: https://lore.kernel.org/r/88967.1743099372@localhost Fixes: 832f6a18fc2a ("ath9k_htc: Add beacon slots") Signed-off-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20250402112217.58533-1-toke@toke.dk Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 53e8e8e909f7c3a77857d09d2b733a42547f57ee Author: Longfang Liu Date: Sat May 10 16:11:54 2025 +0800 hisi_acc_vfio_pci: bugfix live migration function without VF device driver [ Upstream commit 2777a40998deb36f96b6afc48bd397cf58a4edf0 ] If the VF device driver is not loaded in the Guest OS and we attempt to perform device data migration, the address of the migrated data will be NULL. The live migration recovery operation on the destination side will access a null address value, which will cause access errors. Therefore, live migration of VMs without added VF device drivers does not require device data migration. In addition, when the queue address data obtained by the destination is empty, device queue recovery processing will not be performed. Fixes: b0eed085903e ("hisi_acc_vfio_pci: Add support for VFIO live migration") Signed-off-by: Longfang Liu Reviewed-by: Shameer Kolothum Link: https://lore.kernel.org/r/20250510081155.55840-6-liulongfang@huawei.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit a1779a96378dca7960eb13058a035a267dd39976 Author: Longfang Liu Date: Sat May 10 16:11:53 2025 +0800 hisi_acc_vfio_pci: bugfix the problem of uninstalling driver [ Upstream commit db6525a8573957faea28850392f4744e5f8f7a53 ] In a live migration scenario. If the number of VFs at the destination is greater than the source, the recovery operation will fail and qemu will not be able to complete the process and exit after shutting down the device FD. This will cause the driver to be unable to be unloaded normally due to abnormal reference counting of the live migration driver caused by the abnormal closing operation of fd. Therefore, make sure the migration file descriptor references are always released when the device is closed. Fixes: b0eed085903e ("hisi_acc_vfio_pci: Add support for VFIO live migration") Signed-off-by: Longfang Liu Reviewed-by: Shameer Kolothum Link: https://lore.kernel.org/r/20250510081155.55840-5-liulongfang@huawei.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit f3cb7a7ba4324cd344f701b83eb87f3e0a397eb1 Author: Longfang Liu Date: Sat May 10 16:11:52 2025 +0800 hisi_acc_vfio_pci: bugfix cache write-back issue [ Upstream commit e63c466398731bb7867f42f44b76fa984de59db2 ] At present, cache write-back is placed in the device data copy stage after stopping the device operation. Writing back to the cache at this stage will cause the data obtained by the cache to be written back to be empty. In order to ensure that the cache data is written back successfully, the data needs to be written back into the stop device stage. Fixes: b0eed085903e ("hisi_acc_vfio_pci: Add support for VFIO live migration") Signed-off-by: Longfang Liu Reviewed-by: Shameer Kolothum Link: https://lore.kernel.org/r/20250510081155.55840-4-liulongfang@huawei.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit a01f82deb1e15bf0fafb3afb045a21169d9b5ede Author: Longfang Liu Date: Sat May 10 16:11:51 2025 +0800 hisi_acc_vfio_pci: add eq and aeq interruption restore [ Upstream commit 3495cec0787721ba7a9d5c19d0bbb66d182de584 ] In order to ensure that the task packets of the accelerator device are not lost during the migration process, it is necessary to send an EQ and AEQ command to the device after the live migration is completed and to update the completion position of the task queue. Let the device recheck the completed tasks data and if there are uncollected packets, device resend a task completion interrupt to the software. Fixes: b0eed085903e ("hisi_acc_vfio_pci: Add support for VFIO live migration") Signed-off-by: Longfang Liu Reviewed-by: Shameer Kolothum Link: https://lore.kernel.org/r/20250510081155.55840-3-liulongfang@huawei.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 7710c883eb8cb5cf510ca47ec0e26c6cb7e94a4f Author: Longfang Liu Date: Sat May 10 16:11:50 2025 +0800 hisi_acc_vfio_pci: fix XQE dma address error [ Upstream commit 8bb7170c5a055ea17c6857c256ee73c10ff872eb ] The dma addresses of EQE and AEQE are wrong after migration and results in guest kernel-mode encryption services failure. Comparing the definition of hardware registers, we found that there was an error when the data read from the register was combined into an address. Therefore, the address combination sequence needs to be corrected. Even after fixing the above problem, we still have an issue where the Guest from an old kernel can get migrated to new kernel and may result in wrong data. In order to ensure that the address is correct after migration, if an old magic number is detected, the dma address needs to be updated. Fixes: b0eed085903e ("hisi_acc_vfio_pci: Add support for VFIO live migration") Signed-off-by: Longfang Liu Reviewed-by: Shameer Kolothum Link: https://lore.kernel.org/r/20250510081155.55840-2-liulongfang@huawei.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 1089f65b2de78c7837ef6b4f26146a5a5b0b9749 Author: Rajat Soni Date: Wed Apr 30 10:25:38 2025 +0530 wifi: ath12k: fix memory leak in ath12k_service_ready_ext_event [ Upstream commit 89142d34d5602c7447827beb181fa06eb08b9d5c ] Currently, in ath12k_service_ready_ext_event(), svc_rdy_ext.mac_phy_caps is not freed in the failure case, causing a memory leak. The following trace is observed in kmemleak: unreferenced object 0xffff8b3eb5789c00 (size 1024): comm "softirq", pid 0, jiffies 4294942577 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 7b 00 00 10 ............{... 01 00 00 00 00 00 00 00 01 00 00 00 1f 38 00 00 .............8.. backtrace (crc 44e1c357): __kmalloc_noprof+0x30b/0x410 ath12k_wmi_mac_phy_caps_parse+0x84/0x100 [ath12k] ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k] ath12k_wmi_svc_rdy_ext_parse+0x308/0x4c0 [ath12k] ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k] ath12k_service_ready_ext_event.isra.0+0x44/0xd0 [ath12k] ath12k_wmi_op_rx+0x2eb/0xd70 [ath12k] ath12k_htc_rx_completion_handler+0x1f4/0x330 [ath12k] ath12k_ce_recv_process_cb+0x218/0x300 [ath12k] ath12k_pci_ce_workqueue+0x1b/0x30 [ath12k] process_one_work+0x219/0x680 bh_worker+0x198/0x1f0 tasklet_action+0x13/0x30 handle_softirqs+0xca/0x460 __irq_exit_rcu+0xbe/0x110 irq_exit_rcu+0x9/0x30 Free svc_rdy_ext.mac_phy_caps in the error case to fix this memory leak. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Rajat Soni Signed-off-by: Raj Kumar Bhagat Link: https://patch.msgid.link/20250430-wmi-mem-leak-v1-1-fcc9b49c2ddc@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5d0cb07da3e22906a25722d14301a360b31f13be Author: Yingying Tang Date: Wed Apr 23 11:26:49 2025 +0530 wifi: ath12k: Reorder and relocate the release of resources in ath12k_core_deinit() [ Upstream commit aabd3be90579ed088aa34f0584ab6836c735c76f ] Ath12k panic notifier is registered in driver loading process. But it is not unregistered if ATH12K_FLAG_QMI_FAIL is set(e.g. load BDF failed) and unload driver. It causes a dirty node in panic notifier list since ath12k panic notifier is not unregistered from list but the buffer of this node is freed in driver unloading process. If load driver again there will be a page fault error due to this dirty node in panic notifier list. This issue is caused by asymmetry between ath12k_core_init() and ath12k_core_deinit(). Reorder and relocate the release of resources in ath12k_core_deinit() to avoid this asymmetry issue. Call Trace: ? show_regs+0x67/0x70 ? __die_body+0x20/0x70 ? __die+0x2b/0x40 ? page_fault_oops+0x15d/0x500 ? search_bpf_extables+0x63/0x90 ? notifier_chain_register+0x21/0xe0 ? search_exception_tables+0x5f/0x70 ? kernelmode_fixup_or_oops.isra.0+0x61/0x80 ? __bad_area_nosemaphore+0x179/0x240 ? bad_area_nosemaphore+0x16/0x20 ? do_user_addr_fault+0x312/0x7f0 ? prb_read_valid+0x1c/0x30 ? exc_page_fault+0x78/0x180 ? asm_exc_page_fault+0x27/0x30 ? notifier_chain_register+0x21/0xe0 ? notifier_chain_register+0x55/0xe0 atomic_notifier_chain_register+0x2c/0x50 ath12k_core_init+0x7e/0x110 [ath12k] ath12k_pci_probe+0xaba/0xba0 [ath12k] Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0-02903-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 809055628bce8 ("wifi: ath12k: add panic handler") Signed-off-by: Yingying Tang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250423055650.16230-2-quic_yintang@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 161c4ee0977de27b5654aa92b791196d4c661c8d Author: P Praneesh Date: Thu Apr 24 11:21:04 2025 +0530 wifi: ath12k: Fix invalid RSSI values in station dump [ Upstream commit 3126f1c52af5bc8d40d2c984907daeb501f6b739 ] When processing a "station dump" command, the driver retrieves RSSI values from the HAL_PHYRX_RSSI_LEGACY TLV received from the monitor destination ring, and reports them to userspace. Currently, the RSSI values reported are improper because the hardware has not been configured to update them properly. To fix this, enable the HTT_RX_FILTER_TLV_FLAGS_PPDU_START_USER_INFO in the filter setup to ensure the correct RSSI values are returned in the HAL_PHYRX_RSSI_LEGACY TLV, resulting in correct RSSI values being reported to userspace. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: P Praneesh Signed-off-by: Sowjanya vardhineni Reviewed-by: Mahendran P Link: https://patch.msgid.link/20250424055104.2503723-1-quic_svardhin@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 1006c939df3840a59a743b1d7b50b5ed81bfca28 Author: Rolf Eike Beer Date: Mon May 12 15:10:44 2025 +0200 iommu: remove duplicate selection of DMAR_TABLE [ Upstream commit 9548feff840a05d61783e6316d08ed37e115f3b1 ] This is already done in intel/Kconfig. Fixes: 70bad345e622 ("iommu: Fix compilation without CONFIG_IOMMU_INTEL") Signed-off-by: Rolf Eike Beer Reviewed-by: Lu Baolu Link: https://lore.kernel.org/r/2232605.Mh6RI2rZIc@devpool92.emlix.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a7d2fce4c0ea38dbfcb0c30b8bfc3c5991bfd758 Author: Chin-Yen Lee Date: Tue May 13 20:52:03 2025 +0800 wifi: rtw89: fix firmware scan delay unit for WiFi 6 chips [ Upstream commit 3cc35394fac15d533639c9c9e42f28d28936a4a0 ] The scan delay unit of firmware command for WiFi 6 chips is microsecond, but is wrong set now and lead to abnormal work for net-detect. Correct the unit to avoid the error. Fixes: e99dd80c8a18 ("wifi: rtw89: wow: add delay option for net-detect") Signed-off-by: Chin-Yen Lee Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250513125203.6858-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit 9febcc8bded8be0d7efd8237fcef599b6d93b788 Author: Alexey Kodanev Date: Tue May 13 12:13:04 2025 +0000 wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds [ Upstream commit 4c2c372de2e108319236203cce6de44d70ae15cd ] Set the size to 6 instead of 2, since 'para' array is passed to 'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads 5 bytes: void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data) { ... SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data); SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1)); ... SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4)); Detected using the static analysis tool - Svace. Fixes: 4136214f7c46 ("rtw88: add BT co-existence support") Signed-off-by: Alexey Kodanev Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250513121304.124141-1-aleksei.kodanev@bell-sw.com Signed-off-by: Sasha Levin commit e3a7cb7542c142a17e51c5216f58189466e158ae Author: Ping-Ke Shih Date: Fri May 9 09:34:33 2025 +0800 wifi: rtw89: pci: enlarge retry times of RX tag to 1000 [ Upstream commit dda27a47c036d981ec664ac57e044a21035ffe12 ] RX tag is sequence number to ensure RX DMA is complete. On platform Gigabyte X870 AORUS ELITE WIFI7, sometimes it needs longer retry times to complete RX DMA, or driver throws warnings and connection drops: rtw89_8922ae 0000:07:00.0: failed to update 162 RXBD info: -11 rtw89_8922ae 0000:07:00.0: failed to update 163 RXBD info: -11 rtw89_8922ae 0000:07:00.0: failed to update 32 RXBD info: -11 rtw89_8922ae 0000:07:00.0: failed to release TX skbs Fixes: 0bc7d1d4e63c ("wifi: rtw89: pci: validate RX tag for RXQ and RPQ") Reported-by: Samuel Reyes Closes: https://lore.kernel.org/linux-wireless/f4355539f3ac46bbaf9c586d059a8cbb@realtek.com/T/#t Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250509013433.7573-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit e1e0f046041474004dc6ebce5ce1d3e86556291d Author: Ping-Ke Shih Date: Tue May 6 09:53:56 2025 +0800 wifi: rtw89: pci: configure manual DAC mode via PCI config API only [ Upstream commit a70cf04b08f44f41bce14659aa7012674b15d9de ] To support 36-bit DMA, configure chip proprietary bit via PCI config API or chip DBI interface. However, the PCI device mmap isn't set yet and the DBI is also inaccessible via mmap, so only if the bit can be accessible via PCI config API, chip can support 36-bit DMA. Otherwise, fallback to 32-bit DMA. With NULL mmap address, kernel throws trace: BUG: unable to handle page fault for address: 0000000000001090 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 71 Comm: irq/26-pciehp Tainted: G OE 6.14.2-061402-generic #202504101348 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE RIP: 0010:rtw89_pci_ops_write16+0x12/0x30 [rtw89_pci] RSP: 0018:ffffb0ffc0acf9d8 EFLAGS: 00010206 RAX: ffffffffc158f9c0 RBX: ffff94865e702020 RCX: 0000000000000000 RDX: 0000000000000718 RSI: 0000000000001090 RDI: ffff94865e702020 RBP: ffffb0ffc0acf9d8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000015 R13: 0000000000000719 R14: ffffb0ffc0acfa1f R15: ffffffffc1813060 FS: 0000000000000000(0000) GS:ffff9486f3480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001090 CR3: 0000000090440001 CR4: 00000000000626f0 Call Trace: rtw89_pci_read_config_byte+0x6d/0x120 [rtw89_pci] rtw89_pci_cfg_dac+0x5b/0xb0 [rtw89_pci] rtw89_pci_probe+0xa96/0xbd0 [rtw89_pci] ? __pfx___device_attach_driver+0x10/0x10 ? __pfx___device_attach_driver+0x10/0x10 local_pci_probe+0x47/0xa0 pci_call_probe+0x5d/0x190 pci_device_probe+0xa7/0x160 really_probe+0xf9/0x370 ? pm_runtime_barrier+0x55/0xa0 __driver_probe_device+0x8c/0x140 driver_probe_device+0x24/0xd0 __device_attach_driver+0xcd/0x170 bus_for_each_drv+0x99/0x100 __device_attach+0xb4/0x1d0 device_attach+0x10/0x20 pci_bus_add_device+0x59/0x90 pci_bus_add_devices+0x31/0x80 pciehp_configure_device+0xaa/0x170 pciehp_enable_slot+0xd6/0x240 pciehp_handle_presence_or_link_change+0xf1/0x180 pciehp_ist+0x162/0x1c0 irq_thread_fn+0x24/0x70 irq_thread+0xef/0x1c0 ? __pfx_irq_thread_fn+0x10/0x10 ? __pfx_irq_thread_dtor+0x10/0x10 ? __pfx_irq_thread+0x10/0x10 kthread+0xfc/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x47/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fixes: 1fd4b3fe52ef ("wifi: rtw89: pci: support 36-bit PCI DMA address") Reported-by: Bitterblue Smith Closes: https://lore.kernel.org/linux-wireless/ccaf49b6-ff41-4917-90f1-f53cadaaa0da@gmail.com/T/#u Closes: https://github.com/openwrt/openwrt/issues/17025 Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250506015356.7995-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit 6e5e2f46c50e7d8cca7d21fd00599f0481699e24 Author: Ilya Leoshkevich Date: Mon May 12 14:26:15 2025 +0200 s390/bpf: Store backchain even for leaf progs [ Upstream commit 5f55f2168432298f5a55294831ab6a76a10cb3c3 ] Currently a crash in a leaf prog (caused by a bug) produces the following call trace: [<000003ff600ebf00>] bpf_prog_6df0139e1fbf2789_fentry+0x20/0x78 [<0000000000000000>] 0x0 This is because leaf progs do not store backchain. Fix by making all progs do it. This is what GCC and Clang-generated code does as well. Now the call trace looks like this: [<000003ff600eb0f2>] bpf_prog_6df0139e1fbf2789_fentry+0x2a/0x80 [<000003ff600ed096>] bpf_trampoline_201863462940+0x96/0xf4 [<000003ff600e3a40>] bpf_prog_05f379658fdd72f2_classifier_0+0x58/0xc0 [<000003ffe0aef070>] bpf_test_run+0x210/0x390 [<000003ffe0af0dc2>] bpf_prog_test_run_skb+0x25a/0x668 [<000003ffe038a90e>] __sys_bpf+0xa46/0xdb0 [<000003ffe038ad0c>] __s390x_sys_bpf+0x44/0x50 [<000003ffe0defea8>] __do_syscall+0x150/0x280 [<000003ffe0e01d5c>] system_call+0x74/0x98 Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend") Signed-off-by: Ilya Leoshkevich Link: https://lore.kernel.org/r/20250512122717.54878-1-iii@linux.ibm.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5482e58bc1f131a84c2cd993429e2a71778e7a58 Author: Vincent Knecht Date: Mon Apr 14 18:45:12 2025 +0200 clk: qcom: gcc-msm8939: Fix mclk0 & mclk1 for 24 MHz [ Upstream commit 9e7acf70cf6aa7b22f67d911f50a8cd510e8fb00 ] Fix mclk0 & mclk1 parent map to use correct GPLL6 configuration and freq_tbl to use GPLL6 instead of GPLL0 so that they tick at 24 MHz. Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Suggested-by: Stephan Gerhold Reviewed-by: Konrad Dybcio Reviewed-by: Bryan O'Donoghue Signed-off-by: Vincent Knecht Link: https://lore.kernel.org/r/20250414-gcc-msm8939-fixes-mclk-v2-resend2-v2-1-5ddcf572a6de@mailoo.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 90842d6a5bd94741a0ed435cdfeea975a739654a Author: Rob Herring (Arm) Date: Wed May 7 10:42:31 2025 -0500 dt-bindings: soc: fsl,qman-fqd: Fix reserved-memory.yaml reference [ Upstream commit 1090c38bbfd9ab7f22830c0e8a5c605e7d4ef084 ] The reserved-memory.yaml reference needs the full path. No warnings were generated because the example has the wrong compatible string, so fix that too. Fixes: 304a90c4f75d ("dt-bindings: soc: fsl: Convert q(b)man-* to yaml format") Acked-by: Conor Dooley Link: https://lore.kernel.org/r/20250507154231.1590634-1-robh@kernel.org Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 18e8cbbae79cb35bdce8a01c889827b9799c762e Author: Tao Chen Date: Tue May 13 12:27:47 2025 +0800 bpf: Fix WARN() in get_bpf_raw_tp_regs [ Upstream commit 3880cdbed1c4607e378f58fa924c5d6df900d1d3 ] syzkaller reported an issue: WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 Tracepoint like trace_mmap_lock_acquire_returned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARN_ON_ONCE will be triggered. As Alexei suggested, remove the WARN_ON_ONCE first. Fixes: 9594dc3c7e71 ("bpf: fix nested bpf tracepoints with per-cpu data") Reported-by: syzbot+45b0c89a0fc7ae8dbadc@syzkaller.appspotmail.com Suggested-by: Alexei Starovoitov Signed-off-by: Tao Chen Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250513042747.757042-1-chen.dylane@linux.dev Closes: https://lore.kernel.org/bpf/8bc2554d-1052-4922-8832-e0078a033e1d@gmail.com Signed-off-by: Sasha Levin commit 288c39286f759314ee8fb3a80a858179b4f306da Author: Andy Shevchenko Date: Thu May 8 23:08:07 2025 +0300 pinctrl: at91: Fix possible out-of-boundary access [ Upstream commit 762ef7d1e6eefad9896560bfcb9bcf7f1b6df9c1 ] at91_gpio_probe() doesn't check that given OF alias is not available or something went wrong when trying to get it. This might have consequences when accessing gpio_chips array with that value as an index. Note, that BUG() can be compiled out and hence won't actually perform the required checks. Fixes: 6732ae5cb47c ("ARM: at91: add pinctrl support") Signed-off-by: Andy Shevchenko Closes: https://lore.kernel.org/r/202505052343.UHF1Zo93-lkp@intel.com/ Link: https://lore.kernel.org/20250508200807.1384558-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c38ecf4075a6ebda47d0dae0b2f445573b201f7f Author: Lijuan Gao Date: Tue May 6 14:23:01 2025 +0800 pinctrl: qcom: correct the ngpios entry for QCS8300 [ Upstream commit 32b5361a0d10627343b2ded76f05e5d591627fd6 ] Correct the ngpios entry to account for the UFS_RESET pin, which is expected to be wired to the reset pin of the primary UFS memory and is exported as GPIOs in addition to the real GPIOs, allowing the UFS driver to toggle it. Fixes: 0c4cd2cc87c8 ("pinctrl: qcom: add the tlmm driver for QCS8300 platforms") Reviewed-by: Konrad Dybcio Signed-off-by: Lijuan Gao Link: https://lore.kernel.org/20250506-correct_gpio_ranges-v3-4-49a7d292befa@quicinc.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 7d2c69bd3fe691d9d647086012b9c28fcd335bfa Author: Lijuan Gao Date: Tue May 6 14:23:00 2025 +0800 pinctrl: qcom: correct the ngpios entry for QCS615 [ Upstream commit d18cdb975ba8aad7046ff82df1a963fa21082a45 ] Correct the ngpios entry to account for the UFS_RESET pin being exported as a GPIO in addition to the real GPIOs, allowing the UFS driver to toggle it. Fixes: b698f36a9d40 ("pinctrl: qcom: add the tlmm driver for QCS615 platform") Reviewed-by: Konrad Dybcio Signed-off-by: Lijuan Gao Link: https://lore.kernel.org/20250506-correct_gpio_ranges-v3-3-49a7d292befa@quicinc.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 879beb3f03f8f1340f4921eb9e65fa6931bf22d2 Author: Anton Protopopov Date: Sat May 10 18:20:11 2025 +0000 libbpf: Use proper errno value in nlattr [ Upstream commit fd5fd538a1f4b34cee6823ba0ddda2f7a55aca96 ] Return value of the validate_nla() function can be propagated all the way up to users of libbpf API. In case of error this libbpf version of validate_nla returns -1 which will be seen as -EPERM from user's point of view. Instead, return a more reasonable -EINVAL. Fixes: bbf48c18ee0c ("libbpf: add error reporting in XDP") Suggested-by: Andrii Nakryiko Signed-off-by: Anton Protopopov Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250510182011.2246631-1-a.s.protopopov@gmail.com Signed-off-by: Sasha Levin commit 52d12296c5d5df940fc2e8bfb8e0fcd5d4fae3d6 Author: Jiayuan Chen Date: Fri Apr 25 13:59:57 2025 +0800 ktls, sockmap: Fix missing uncharge operation [ Upstream commit 79f0c39ae7d3dc628c01b02f23ca5d01f9875040 ] When we specify apply_bytes, we divide the msg into multiple segments, each with a length of 'send', and every time we send this part of the data using tcp_bpf_sendmsg_redir(), we use sk_msg_return_zero() to uncharge the memory of the specified 'send' size. However, if the first segment of data fails to send, for example, the peer's buffer is full, we need to release all of the msg. When releasing the msg, we haven't uncharged the memory of the subsequent segments. This modification does not make significant logical changes, but only fills in the missing uncharge places. This issue has existed all along, until it was exposed after we added the apply test in test_sockmap: commit 3448ad23b34e ("selftests/bpf: Add apply_bytes test to test_txmsg_redir_wait_sndmem in test_sockmap") Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Reported-by: Cong Wang Closes: https://lore.kernel.org/bpf/aAmIi0vlycHtbXeb@pop-os.localdomain/T/#t Signed-off-by: Jiayuan Chen Signed-off-by: Martin KaFai Lau Acked-by: John Fastabend Reviewed-by: Cong Wang Link: https://lore.kernel.org/r/20250425060015.6968-2-jiayuan.chen@linux.dev Signed-off-by: Sasha Levin commit 85193dc3595e5ca6eaf4ed65f7f6163abcba3d8f Author: Dan Carpenter Date: Wed Apr 30 11:05:40 2025 +0300 of: unittest: Unlock on error in unittest_data_add() [ Upstream commit 493e6cb63a21e9f009dc4c209fd311f2bb777656 ] The of_overlay_mutex_unlock() was accidentally deleted if "of_root" is NULL. Change this to a goto unlock. Fixes: d1eabd218ede ("of: unittest: treat missing of_root as error instead of fixing up") Signed-off-by: Dan Carpenter Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/aBHZ1DvXiBcZkWmk@stanley.mountain Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 2e0c0292593793be6b62d86d3e2f1d9beea13193 Author: Miaoqian Lin Date: Wed May 7 10:53:07 2025 -0400 tracing: Fix error handling in event_trigger_parse() [ Upstream commit c5dd28e7fb4f63475b50df4f58311df92939d011 ] According to trigger_data_alloc() doc, trigger_data_free() should be used to free an event_trigger_data object. This fixes a mismatch introduced when kzalloc was replaced with trigger_data_alloc without updating the corresponding deallocation calls. Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Andrew Morton Cc: Mathieu Desnoyers Cc: Tom Zanussi Link: https://lore.kernel.org/20250507145455.944453325@goodmis.org Link: https://lore.kernel.org/20250318112737.4174-1-linmq006@gmail.com Fixes: e1f187d09e11 ("tracing: Have existing event_command.parse() implementations use helpers") Signed-off-by: Miaoqian Lin [ SDR: Changed event_trigger_alloc/free() to trigger_data_alloc/free() ] Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit ad031f83d7209e0504cd71ccd92e449501e05495 Author: Steven Rostedt Date: Wed May 7 10:53:06 2025 -0400 tracing: Rename event_trigger_alloc() to trigger_data_alloc() [ Upstream commit f2947c4b7d0f235621c5daf78aecfbd6e22c05e5 ] The function event_trigger_alloc() creates an event_trigger_data descriptor and states that it needs to be freed via event_trigger_free(). This is incorrect, it needs to be freed by trigger_data_free() as event_trigger_free() adds ref counting. Rename event_trigger_alloc() to trigger_data_alloc() and state that it needs to be freed via trigger_data_free(). This naming convention was introducing bugs. Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Tom Zanussi Link: https://lore.kernel.org/20250507145455.776436410@goodmis.org Fixes: 86599dbe2c527 ("tracing: Add helper functions to simplify event_command.parse() callback handling") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 72089e524b77715538d8a22c9a5629ae0dad0d5f Author: Luis Gerhorst Date: Thu May 1 09:35:52 2025 +0200 selftests/bpf: Fix caps for __xlated/jited_unpriv [ Upstream commit cf15cdc0f0f39a5c6315200808ec3e3995b0c2d2 ] Currently, __xlated_unpriv and __jited_unpriv do not work because the BPF syscall will overwrite info.jited_prog_len and info.xlated_prog_len with 0 if the process is not bpf_capable(). This bug was not noticed before, because there is no test that actually uses __xlated_unpriv/__jited_unpriv. To resolve this, simply restore the capabilities earlier (but still after loading the program). Adding this here unconditionally is fine because the function first checks that the capabilities were initialized before attempting to restore them. This will be important later when we add tests that check whether a speculation barrier was inserted in the correct location. Signed-off-by: Luis Gerhorst Fixes: 9c9f73391310 ("selftests/bpf: allow checking xlated programs in verifier_* tests") Fixes: 7d743e4c759c ("selftests/bpf: __jited test tag to check disassembly after jit") Acked-by: Kumar Kartikeya Dwivedi Tested-by: Eduard Zingerman Link: https://lore.kernel.org/r/20250501073603.1402960-2-luis.gerhorst@fau.de Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 74bee33834d0c90bed208baad01a018402b11e17 Author: Peilin Ye Date: Wed May 7 03:43:19 2025 +0000 selftests/bpf: Avoid passing out-of-range values to __retval() [ Upstream commit 6e492ffcab6064cd7b317dc1f49fb9f92407aaa7 ] Currently, we pass 0x1234567890abcdef to __retval() for the following two tests: verifier_load_acquire/load_acquire_64 verifier_store_release/store_release_64 However, the upper 32 bits of that value are being ignored, since __retval() expects an int. Actually, the tests would still pass even if I change '__retval(0x1234567890abcdef)' to e.g. '__retval(0x90abcdef)'. Restructure the tests a bit to test the entire 64-bit values properly. Do the same to their 8-, 16- and 32-bit variants as well to keep the style consistent. Fixes: ff3afe5da998 ("selftests/bpf: Add selftests for load-acquire and store-release instructions") Acked-by: Björn Töpel Reviewed-by: Pu Lehui Tested-by: Björn Töpel # QEMU/RVA23 Signed-off-by: Peilin Ye Link: https://lore.kernel.org/r/d67f4c6f6ee0d0388cbce1f4892ec4176ee2d604.1746588351.git.yepeilin@google.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 49993db7103c70d9f4cf5d060431b96fe5011118 Author: Hans Zhang <18255117159@163.com> Date: Wed May 7 00:31:11 2025 +0800 efi/libstub: Describe missing 'out' parameter in efi_load_initrd [ Upstream commit c8e1927e7f7d63721e32ec41d27ccb0eb1a1b0fc ] The function efi_load_initrd() had a documentation warning due to the missing description for the 'out' parameter. Add the parameter description to the kernel-doc comment to resolve the warning and improve API documentation. Fixes the following compiler warning: drivers/firmware/efi/libstub/efi-stub-helper.c:611: warning: Function parameter or struct member 'out' not described in 'efi_load_initrd' Fixes: f4dc7fffa987 ("efi: libstub: unify initrd loading between architectures") Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 20d7644798f8bbb399f0b67071a9fe73d7ef8e62 Author: Tomas Glozar Date: Wed Apr 30 16:46:51 2025 +0200 rtla: Define _GNU_SOURCE in timerlat_bpf.c [ Upstream commit 8020361d51eea5145402e450d91b083bccdcd874 ] Newer versions of glibc include a definition of struct sched_attr in bits/sched.h (included through sched.h which is included by rtla). Commit 0eecee340672 ("tools/rtla: fix collision with glibc sched_attr/sched_set_attr") has modified the definition of struct sched_attr in utils.h, so that it is only applied with older versions of glibc that do not define it, in order to prevent build failure. The definition in bits/sched.h depends on _GNU_SOURCE. timerlat_bpf.c does not define _GNU_SOURCE, making it fall back to the definition in utils.h. The latter has two fields less, leading to shifted offsets of struct timerlat_params in timerlat_bpf_init. Because of the shift, timerlat_bpf_init incorrectly reads params->entries as 0 for timerlat-hist and disables the creation of histogram maps, causing breakage in BPF sample collection mode: $ rtla timerlat hist -d 1s Error pulling BPF data Fix the issue by also defining _GNU_SOURCE in timerlat_bpf.c. Cc: John Kacur Cc: Luis Goncalves Link: https://lore.kernel.org/20250430144651.621766-1-tglozar@redhat.com Fixes: e34293ddcebd ("rtla/timerlat: Add BPF skeleton to collect samples") Signed-off-by: Tomas Glozar Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit d2549b5f84cddae85a5f817979f18a5e839f938e Author: Ilan Peer Date: Sat May 3 22:44:32 2025 +0300 wifi: iwlfiwi: mvm: Fix the rate reporting [ Upstream commit 8f7561209eda7d6998708f06376e8dd2dc52f3b8 ] The rate validation in mac80211 considers a rate to be valid iff both the rate index and the count are positive. When the rate scaling is managed in the driver and not enough traffic passed to set the actual rate, the driver set the rate to be the optimal rate. However, the rate count is not set and thus the rate is considered not valid. Fix it by setting the count to 1. Fixes: 3e99b4d28219 ("wifi: mac80211: Sanity check tx bitrate if not provided by driver") Signed-off-by: Ilan Peer Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250503224232.0d1d1e022d63.I76833c14ba1d66f9bea5c32b25a54d8b36f229ba@changeid Signed-off-by: Sasha Levin commit 3f30dc4fa6f777f0938eade438a065cd6f12de17 Author: Richard Fitzgerald Date: Thu Mar 27 12:52:14 2025 +0000 clk: test: Forward-declare struct of_phandle_args in kunit/clk.h [ Upstream commit 7a0c1872ee7db25d711ac29a55f36844a7108308 ] Add a forward-declare of struct of_phandle_args to prevent the compiler warning: ../include/kunit/clk.h:29:63: warning: ‘struct of_phandle_args’ declared inside parameter list will not be visible outside of this definition or declaration struct clk_hw *(*get)(struct of_phandle_args *clkspec, void *data), Signed-off-by: Richard Fitzgerald Link: https://lore.kernel.org/r/20250327125214.82598-1-rf@opensource.cirrus.com Fixes: a82fcb16d977 ("clk: test: Add test managed of_clk_add_hw_provider()") Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 1b69a5299f28ce8e6afa37c3690dbc14c3a1f53f Author: Henry Martin Date: Wed Apr 2 10:05:13 2025 +0800 clk: bcm: rpi: Add NULL check in raspberrypi_clk_register() [ Upstream commit 73c46d9a93d071ca69858dea3f569111b03e549e ] devm_kasprintf() returns NULL when memory allocation fails. Currently, raspberrypi_clk_register() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: 93d2725affd6 ("clk: bcm: rpi: Discover the firmware clocks") Signed-off-by: Henry Martin Reviewed-by: Dave Stevenson Link: https://lore.kernel.org/r/20250402020513.42628-1-bsdhenrymartin@gmail.com Reviewed-by: Stefan Wahren Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 2b67d70847060d556abc6b11f62b8b7c5ac31575 Author: YiFei Zhu Date: Mon Apr 28 21:15:36 2025 +0000 bpftool: Fix regression of "bpftool cgroup tree" EINVAL on older kernels [ Upstream commit 43745d11bfd9683abdf08ad7a5cc403d6a9ffd15 ] If cgroup_has_attached_progs queries an attach type not supported by the running kernel, due to the kernel being older than the bpftool build, it would encounter an -EINVAL from BPF_PROG_QUERY syscall. Prior to commit 98b303c9bf05 ("bpftool: Query only cgroup-related attach types"), this EINVAL would be ignored by the function, allowing the function to only consider supported attach types. The commit changed so that, instead of querying all attach types, only attach types from the array `cgroup_attach_types` is queried. The assumption is that because these are only cgroup attach types, they should all be supported. Unfortunately this assumption may be false when the kernel is older than the bpftool build, where the attach types queried by bpftool is not yet implemented in the kernel. This would result in errors such as: $ bpftool cgroup tree CgroupPath ID AttachType AttachFlags Name Error: can't query bpf programs attached to /sys/fs/cgroup: Invalid argument This patch restores the logic of ignoring EINVAL from prior to that patch. Fixes: 98b303c9bf05 ("bpftool: Query only cgroup-related attach types") Reported-by: Sagarika Sharma Reported-by: Minh-Anh Nguyen Signed-off-by: YiFei Zhu Signed-off-by: Andrii Nakryiko Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20250428211536.1651456-1-zhuyifei@google.com Signed-off-by: Sasha Levin commit 17cfd35d4794872e5d1a93bf1c6dc9f3f0c61acb Author: Luca Weiss Date: Fri Apr 25 14:12:58 2025 +0200 clk: qcom: gpucc-sm6350: Add *_wait_val values for GDSCs [ Upstream commit d988b0b866c2aeb23aa74022b5bbd463165a7a33 ] Compared to the msm-4.19 driver the mainline GDSC driver always sets the bits for en_rest, en_few & clk_dis, and if those values are not set per-GDSC in the respective driver then the default value from the GDSC driver is used. The downstream driver only conditionally sets clk_dis_wait_val if qcom,clk-dis-wait-val is given in devicetree. Correct this situation by explicitly setting those values. For all GDSCs the reset value of those bits are used, with the exception of gpu_cx_gdsc which has an explicit value (qcom,clk-dis-wait-val = <8>). Fixes: 013804a727a0 ("clk: qcom: Add GPU clock controller driver for SM6350") Signed-off-by: Luca Weiss Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20250425-sm6350-gdsc-val-v1-4-1f252d9c5e4e@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 01bcd3eb3ef744f0804951445e9961fdf5772306 Author: Luca Weiss Date: Fri Apr 25 14:12:57 2025 +0200 clk: qcom: gcc-sm6350: Add *_wait_val values for GDSCs [ Upstream commit afdfd829a99e467869e3ca1955fb6c6e337c340a ] Compared to the msm-4.19 driver the mainline GDSC driver always sets the bits for en_rest, en_few & clk_dis, and if those values are not set per-GDSC in the respective driver then the default value from the GDSC driver is used. The downstream driver only conditionally sets clk_dis_wait_val if qcom,clk-dis-wait-val is given in devicetree. Correct this situation by explicitly setting those values. For all GDSCs the reset value of those bits are used. Fixes: 131abae905df ("clk: qcom: Add SM6350 GCC driver") Signed-off-by: Luca Weiss Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20250425-sm6350-gdsc-val-v1-3-1f252d9c5e4e@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 77e73917867b631bfbb5e31a8d108c299c1ef368 Author: Luca Weiss Date: Fri Apr 25 14:12:56 2025 +0200 clk: qcom: dispcc-sm6350: Add *_wait_val values for GDSCs [ Upstream commit 673989d27123618afab56df1143a75454178b4ae ] Compared to the msm-4.19 driver the mainline GDSC driver always sets the bits for en_rest, en_few & clk_dis, and if those values are not set per-GDSC in the respective driver then the default value from the GDSC driver is used. The downstream driver only conditionally sets clk_dis_wait_val if qcom,clk-dis-wait-val is given in devicetree. Correct this situation by explicitly setting those values. For all GDSCs the reset value of those bits are used. Fixes: 837519775f1d ("clk: qcom: Add display clock controller driver for SM6350") Signed-off-by: Luca Weiss Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20250425-sm6350-gdsc-val-v1-2-1f252d9c5e4e@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d29df0c1307dd937d404ebeecec02a6c68f4c89e Author: Luca Weiss Date: Fri Apr 25 14:12:55 2025 +0200 clk: qcom: camcc-sm6350: Add *_wait_val values for GDSCs [ Upstream commit e7b1c13280ad866f3b935f6c658713c41db61635 ] Compared to the msm-4.19 driver the mainline GDSC driver always sets the bits for en_rest, en_few & clk_dis, and if those values are not set per-GDSC in the respective driver then the default value from the GDSC driver is used. The downstream driver only conditionally sets clk_dis_wait_val if qcom,clk-dis-wait-val is given in devicetree. Correct this situation by explicitly setting those values. For all GDSCs the reset value of those bits are used. Fixes: 80f5451d9a7c ("clk: qcom: Add camera clock controller driver for SM6350") Signed-off-by: Luca Weiss Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20250425-sm6350-gdsc-val-v1-1-1f252d9c5e4e@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 740dab2338f70d93aa8235db5a9541d846d7b21c Author: Steven Rostedt Date: Mon Apr 7 12:38:51 2025 -0400 tracing: Move histogram trigger variables from stack to per CPU structure [ Upstream commit 7ab0fc61ce73040f89b12d76a8279995ec283541 ] The histogram trigger has three somewhat large arrays on the kernel stack: unsigned long entries[HIST_STACKTRACE_DEPTH]; u64 var_ref_vals[TRACING_MAP_VARS_MAX]; char compound_key[HIST_KEY_SIZE_MAX]; Checking the function event_hist_trigger() stack frame size, it currently uses 816 bytes for its stack frame due to these variables! Instead, allocate a per CPU structure that holds these arrays for each context level (normal, softirq, irq and NMI). That is, each CPU will have 4 of these structures. This will be allocated when the first histogram trigger is enabled and freed when the last is disabled. When the histogram callback triggers, it will request this structure. The request will disable preemption, get the per CPU structure at the index of the per CPU variable, and increment that variable. The callback will use the arrays in this structure to perform its work and then release the structure. That in turn will simply decrement the per CPU index and enable preemption. Moving the variables from the kernel stack to the per CPU structure brings the stack frame of event_hist_trigger() down to just 112 bytes. Cc: Mathieu Desnoyers Cc: Tom Zanussi Link: https://lore.kernel.org/20250407123851.74ea8d58@gandalf.local.home Fixes: 067fe038e70f6 ("tracing: Add variable reference handling to hist triggers") Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit f15264821d02ad80864f72ffc3df847167b72199 Author: Qinxin Xia Date: Tue Apr 22 19:29:51 2025 +0800 iommu/arm-smmu-v3: Fix incorrect return in arm_smmu_attach_dev [ Upstream commit be5a2d3f8f9738ea1426e7d2243707164ed5bac2 ] After commit 48e7b8e284e5 ("iommu/arm-smmu-v3: Remove arm_smmu_domain_finalise() during attach"), an error code is not returned on the attach path when the smmu does not match with the domain. This causes problems with VFIO because vfio_iommu_type1_attach_group() relies on this check to determine domain compatability. Re-instate the -EINVAL return value when the SMMU doesn't match on the device attach path. Fixes: 48e7b8e284e5 ("iommu/arm-smmu-v3: Remove arm_smmu_domain_finalise() during attach") Signed-off-by: Qinxin Xia Link: https://lore.kernel.org/r/20250422112951.2027969-1-xiaqinxin@huawei.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 1340a95ec972a45272cfda2a5856372cdf0cf00a Author: Anton Protopopov Date: Fri May 2 19:30:31 2025 +0000 bpf: Fix uninitialized values in BPF_{CORE,PROBE}_READ [ Upstream commit 41d4ce6df3f4945341ec509a840cc002a413b6cc ] With the latest LLVM bpf selftests build will fail with the following error message: progs/profiler.inc.h:710:31: error: default initialization of an object of type 'typeof ((parent_task)->real_cred->uid.val)' (aka 'const unsigned int') leaves the object uninitialized and is incompatible with C++ [-Werror,-Wdefault-const-init-unsafe] 710 | proc_exec_data->parent_uid = BPF_CORE_READ(parent_task, real_cred, uid.val); | ^ tools/testing/selftests/bpf/tools/include/bpf/bpf_core_read.h:520:35: note: expanded from macro 'BPF_CORE_READ' 520 | ___type((src), a, ##__VA_ARGS__) __r; \ | ^ This happens because BPF_CORE_READ (and other macro) declare the variable __r using the ___type macro which can inherit const modifier from intermediate types. Fix this by using __typeof_unqual__, when supported. (And when it is not supported, the problem shouldn't appear, as older compilers haven't complained.) Fixes: 792001f4f7aa ("libbpf: Add user-space variants of BPF_CORE_READ() family of macros") Fixes: a4b09a9ef945 ("libbpf: Add non-CO-RE variants of BPF_CORE_READ() macro family") Signed-off-by: Anton Protopopov Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250502193031.3522715-1-a.s.protopopov@gmail.com Signed-off-by: Sasha Levin commit 0a7790cbba654e925243571cf2f24d61603d3ed3 Author: Patrisious Haddad Date: Mon Apr 28 14:34:07 2025 +0300 RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction [ Upstream commit 5d2ea5aebbb2f3ebde4403f9c55b2b057e5dd2d6 ] Upon RQ destruction if the firmware command fails which is the last resource to be destroyed some SW resources were already cleaned regardless of the failure. Now properly rollback the object to its original state upon such failure. In order to avoid a use-after free in case someone tries to destroy the object again, which results in the following kernel trace: refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE) CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : refcount_warn_saturate+0xf4/0x148 lr : refcount_warn_saturate+0xf4/0x148 sp : ffff80008b81b7e0 x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001 x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00 x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000 x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006 x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f x14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78 x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90 x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff x5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600 Call trace: refcount_warn_saturate+0xf4/0x148 mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib] mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib] mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib] ib_destroy_wq_user+0x30/0xc0 [ib_core] uverbs_free_wq+0x28/0x58 [ib_uverbs] destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs] uverbs_destroy_uobject+0x48/0x240 [ib_uverbs] __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs] uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs] ib_uverbs_close+0x2c/0x100 [ib_uverbs] __fput+0xd8/0x2f0 __fput_sync+0x50/0x70 __arm64_sys_close+0x40/0x90 invoke_syscall.constprop.0+0x74/0xd0 do_el0_svc+0x48/0xe8 el0_svc+0x44/0x1d0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x1a4/0x1a8 Fixes: e2013b212f9f ("net/mlx5_core: Add RQ and SQ event handling") Signed-off-by: Patrisious Haddad Link: https://patch.msgid.link/3181433ccdd695c63560eeeb3f0c990961732101.1745839855.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit fc096a0cd2017cb0aa1e7fb83131410af9283910 Author: Vlad Dumitrescu Date: Mon Apr 28 14:30:18 2025 +0300 IB/cm: Drop lockdep assert and WARN when freeing old msg [ Upstream commit 7590649ee7af381a9d1153143026dec124c5798e ] The send completion handler can run after cm_id has advanced to another message. The cm_id lock is not needed in this case, but a recent change re-used cm_free_priv_msg(), which asserts that the lock is held and WARNs if the cm_id's currently outstanding msg is different than the one being freed. Fixes: 1e5159219076 ("IB/cm: Do not hold reference on cm_id unless needed") Signed-off-by: Vlad Dumitrescu Reviewed-by: Sean Hefty Link: https://patch.msgid.link/0c364c29142f72b7875fdeba51f3c9bd6ca863ee.1745839788.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 43fe1181f738295624696ae9ff611790edb65b5e Author: Pablo Neira Ayuso Date: Tue Apr 22 21:52:43 2025 +0200 netfilter: nft_set_pipapo: prevent overflow in lookup table allocation [ Upstream commit 4c5c6aa9967dbe55bd017bb509885928d0f31206 ] When calculating the lookup table size, ensure the following multiplication does not overflow: - desc->field_len[] maximum value is U8_MAX multiplied by NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case. - NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case. - sizeof(unsigned long), from sizeof(*f->lt), lt in struct nft_pipapo_field. Then, use check_mul_overflow() to multiply by bucket size and then use check_add_overflow() to the alignment for avx2 (if needed). Finally, add lt_size_check_overflow() helper and use it to consolidate this. While at it, replace leftover allocation using the GFP_KERNEL to GFP_KERNEL_ACCOUNT for consistency, in pipapo_resize(). Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges") Signed-off-by: Pablo Neira Ayuso Reviewed-by: Stefano Brivio Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 4d6ae1842cb29719e2866470aadf4742382acfea Author: Zhongqiu Duan Date: Thu Apr 17 15:49:30 2025 +0000 netfilter: nft_quota: match correctly when the quota just depleted [ Upstream commit bfe7cfb65c753952735c3eed703eba9a8b96a18d ] The xt_quota compares skb length with remaining quota, but the nft_quota compares it with consumed bytes. The xt_quota can match consumed bytes up to quota at maximum. But the nft_quota break match when consumed bytes equal to quota. i.e., nft_quota match consumed bytes in [0, quota - 1], not [0, quota]. Fixes: 795595f68d6c ("netfilter: nft_quota: dump consumed quota") Signed-off-by: Zhongqiu Duan Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 43d262c2ab19f8b1f28ea2e47f71613a02744e0e Author: Huajian Yang Date: Thu Apr 17 17:29:53 2025 +0800 netfilter: bridge: Move specific fragmented packet to slow_path instead of dropping it [ Upstream commit aa04c6f45b9224b949aa35d4fa5f8d0ba07b23d4 ] The config NF_CONNTRACK_BRIDGE will change the bridge forwarding for fragmented packets. The original bridge does not know that it is a fragmented packet and forwards it directly, after NF_CONNTRACK_BRIDGE is enabled, function nf_br_ip_fragment and br_ip6_fragment will check the headroom. In original br_forward, insufficient headroom of skb may indeed exist, but there's still a way to save the skb in the device driver after dev_queue_xmit.So droping the skb will change the original bridge forwarding in some cases. Fixes: 3c171f496ef5 ("netfilter: bridge: add connection tracking system") Signed-off-by: Huajian Yang Reviewed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit a6b02ec0a44da529fbf75f13590d9275d1fc0b61 Author: Lorenzo Bianconi Date: Mon Apr 28 17:44:02 2025 +0200 bpf: Allow XDP dev-bound programs to perform XDP_REDIRECT into maps [ Upstream commit 714070c4cb7a10ff57450a618a936775f3036245 ] In the current implementation if the program is dev-bound to a specific device, it will not be possible to perform XDP_REDIRECT into a DEVMAP or CPUMAP even if the program is running in the driver NAPI context and it is not attached to any map entry. This seems in contrast with the explanation available in bpf_prog_map_compatible routine. Fix the issue introducing __bpf_prog_map_compatible utility routine in order to avoid bpf_prog_is_dev_bound() check running bpf_check_tail_call() at program load time (bpf_prog_select_runtime()). Continue forbidding to attach a dev-bound program to XDP maps (BPF_MAP_TYPE_PROG_ARRAY, BPF_MAP_TYPE_DEVMAP and BPF_MAP_TYPE_CPUMAP). Fixes: 3d76a4d3d4e59 ("bpf: XDP metadata RX kfuncs") Signed-off-by: Lorenzo Bianconi Signed-off-by: Martin KaFai Lau Acked-by: Stanislav Fomichev Signed-off-by: Sasha Levin commit d19aa5c648eebb0e243f9f8e58d30a56da91e186 Author: Anton Protopopov Date: Wed Apr 30 12:08:20 2025 +0000 libbpf: Use proper errno value in linker [ Upstream commit 358b1c0f56ebb6996fcec7dcdcf6bae5dcbc8b6c ] Return values of the linker_append_sec_data() and the linker_append_elf_relos() functions are propagated all the way up to users of libbpf API. In some error cases these functions return -1 which will be seen as -EPERM from user's point of view. Instead, return a more reasonable -EINVAL. Fixes: faf6ed321cf6 ("libbpf: Add BPF static linker APIs") Signed-off-by: Anton Protopopov Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250430120820.2262053-1-a.s.protopopov@gmail.com Signed-off-by: Sasha Levin commit a12b3932683a960ffdde1f4f1332eda349d0b04b Author: T.J. Mercier Date: Mon Apr 28 18:02:54 2025 +0000 selftests/bpf: Fix kmem_cache iterator draining [ Upstream commit 38d976c32d85ef12dcd2b8a231196f7049548477 ] The closing parentheses around the read syscall is misplaced, causing single byte reads from the iterator instead of buf sized reads. While the end result is the same, many more read calls than necessary are performed. $ tools/testing/selftests/bpf/vmtest.sh "./test_progs -t kmem_cache_iter" 145/1 kmem_cache_iter/check_task_struct:OK 145/2 kmem_cache_iter/check_slabinfo:OK 145/3 kmem_cache_iter/open_coded_iter:OK 145 kmem_cache_iter:OK Summary: 1/3 PASSED, 0 SKIPPED, 0 FAILED Fixes: a496d0cdc84d ("selftests/bpf: Add a test for kmem_cache_iter") Signed-off-by: T.J. Mercier Signed-off-by: Martin KaFai Lau Acked-by: Song Liu Acked-by: Namhyung Kim Link: https://patch.msgid.link/20250428180256.1482899-1-tjmercier@google.com Signed-off-by: Sasha Levin commit f22ead0ca9ddee28be8f072e748c4dd1f5653b53 Author: David Howells Date: Mon Apr 28 11:22:06 2025 +0100 crypto/krb5: Fix change to use SG miter to use offset [ Upstream commit eed848871c96d4b5a7b06307755b75abd0cc7a06 ] The recent patch to make the rfc3961 simplified code use sg_miter rather than manually walking the scatterlist to hash the contents of a buffer described by that scatterlist failed to take the starting offset into account. This is indicated by the selftests reporting: krb5: Running aes128-cts-hmac-sha256-128 mic krb5: !!! TESTFAIL crypto/krb5/selftest.c:446 krb5: MIC mismatch Fix this by calling sg_miter_skip() before doing the loop to advance by the offset. This only affects packet signing modes and not full encryption in RxGK because, for full encryption, the message digest is handled inside the authenc and krb5enc drivers. Note: Nothing in linus/master uses the krb5lib, though the bug is there. It is used by AF_RXRPC's RxGK implementation in -next, no need to backport. Fixes: da6f9bf40ac2 ("crypto: krb5 - Use SG miter instead of doing it by hand") Reported-by: Marc Dionne Signed-off-by: David Howells cc: Chuck Lever cc: Simon Horman cc: linux-afs@lists.infradead.org Acked-by: Herbert Xu Link: https://patch.msgid.link/3824017.1745835726@warthog.procyon.org.uk Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 31224199316f488c8385c5dcdccf7bd80f675b81 Author: Yi Zhang Date: Wed Apr 23 13:32:28 2025 -0500 scsi: smartpqi: Fix smp_processor_id() call trace for preemptible kernels [ Upstream commit 42d033cf4b517e91c187ad2fbd7b30fdc6d2d62c ] Correct kernel call trace when calling smp_processor_id() when called in preemptible kernels by using raw_smp_processor_id(). smp_processor_id() checks to see if preemption is disabled and if not, issue an error message followed by a call to dump_stack(). Brief example of call trace: kernel: check_preemption_disabled: 436 callbacks suppressed kernel: BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u1025:0/2354 kernel: caller is pqi_scsi_queue_command+0x183/0x310 [smartpqi] kernel: CPU: 129 PID: 2354 Comm: kworker/u1025:0 kernel: ... kernel: Workqueue: writeback wb_workfn (flush-253:0) kernel: Call Trace: kernel: kernel: dump_stack_lvl+0x34/0x48 kernel: check_preemption_disabled+0xdd/0xe0 kernel: pqi_scsi_queue_command+0x183/0x310 [smartpqi] kernel: ... Fixes: 283dcc1b142e ("scsi: smartpqi: add counter for parity write stream requests") Reviewed-by: Scott Benesh Reviewed-by: Mike McGowen Tested-by: Don Brace Signed-off-by: Yi Zhang Signed-off-by: Don Brace Link: https://lore.kernel.org/r/20250423183229.538572-5-don.brace@microchip.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4f09940b5581e44069eb31a66cf7f05c3c35ed04 Author: Justin Tee Date: Fri Apr 25 12:48:03 2025 -0700 scsi: lpfc: Avoid potential ndlp use-after-free in dev_loss_tmo_callbk [ Upstream commit b5162bb6aa1ec04dff4509b025883524b6d7e7ca ] Smatch detected a potential use-after-free of an ndlp oject in dev_loss_tmo_callbk during driver unload or fatal error handling. Fix by reordering code to avoid potential use-after-free if initial nodelist reference has been previously removed. Fixes: 4281f44ea8bf ("scsi: lpfc: Prevent NDLP reference count underflow in dev_loss_tmo callback") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-scsi/41c1d855-9eb5-416f-ac12-8b61929201a3@stanley.mountain/ Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20250425194806.3585-6-justintee8345@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a2b4ddc8d83d78159e3778352cf515971b34169a Author: Chao Yu Date: Thu Apr 10 11:10:19 2025 +0800 f2fs: zone: fix to calculate first_zoned_segno correctly [ Upstream commit dc6d9ef57fcf42fac1b3be4bff5ac5b3f1e8f9f3 ] A zoned device can has both conventional zones and sequential zones, so we should not treat first segment of zoned device as first_zoned_segno, instead, we need to check zone type for each zone during traversing zoned device to find first_zoned_segno. Otherwise, for below case, first_zoned_segno will be 0, which could be wrong. create_null_blk 512 2 1024 1024 mkfs.f2fs -m /dev/nullb0 Testcase: export SCRIPTS_PATH=/share/git/scripts test multiple devices w/ zoned device for ((i=0;i<8;i++)) do { zonesize=$((2<<$i)) conzone=$((4096/$zonesize)) seqzone=$((4096/$zonesize)) $SCRIPTS_PATH/nullblk_create.sh 512 $zonesize $conzone $seqzone mkfs.f2fs -f -m /dev/vdb -c /dev/nullb0 mount /dev/vdb /mnt/f2fs touch /mnt/f2fs/file f2fs_io pinfile set /mnt/f2fs/file $((8589934592*2)) stat /mnt/f2fs/file df cat /proc/fs/f2fs/vdb/segment_info umount /mnt/f2fs $SCRIPTS_PATH/nullblk_remove.sh 0 } done test single zoned device for ((i=0;i<8;i++)) do { zonesize=$((2<<$i)) conzone=$((4096/$zonesize)) seqzone=$((4096/$zonesize)) $SCRIPTS_PATH/nullblk_create.sh 512 $zonesize $conzone $seqzone mkfs.f2fs -f -m /dev/nullb0 mount /dev/nullb0 /mnt/f2fs touch /mnt/f2fs/file f2fs_io pinfile set /mnt/f2fs/file $((8589934592*2)) stat /mnt/f2fs/file df cat /proc/fs/f2fs/nullb0/segment_info umount /mnt/f2fs $SCRIPTS_PATH/nullblk_remove.sh 0 } done Fixes: 9703d69d9d15 ("f2fs: support file pinning for zoned devices") Cc: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 21f3f2b982f2f2ab99bf2770cf0b67363b659d3b Author: Chao Yu Date: Mon Apr 14 18:52:37 2025 +0800 f2fs: fix to detect gcing page in f2fs_is_cp_guaranteed() [ Upstream commit aa1be8dd64163eca4dde7fd2557eb19927a06a47 ] Jan Prusakowski reported a f2fs bug as below: f2fs/007 will hang kernel during testing w/ below configs: kernel 6.12.18 (from pixel-kernel/android16-6.12) export MKFS_OPTIONS="-O encrypt -O extra_attr -O project_quota -O quota" export F2FS_MOUNT_OPTIONS="test_dummy_encryption,discard,fsync_mode=nobarrier,reserve_root=32768,checkpoint_merge,atgc" cat /proc//stack f2fs_wait_on_all_pages+0xa3/0x130 do_checkpoint+0x40c/0x5d0 f2fs_write_checkpoint+0x258/0x550 kill_f2fs_super+0x14f/0x190 deactivate_locked_super+0x30/0xb0 cleanup_mnt+0xba/0x150 task_work_run+0x59/0xa0 syscall_exit_to_user_mode+0x12d/0x130 do_syscall_64+0x57/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e cat /sys/kernel/debug/f2fs/status - IO_W (CP: -256, Data: 256, Flush: ( 0 0 1), Discard: ( 0 0)) cmd: 0 undiscard: 0 CP IOs reference count becomes negative. The root cause is: After 4961acdd65c9 ("f2fs: fix to tag gcing flag on page during block migration"), we will tag page w/ gcing flag for raw page of cluster during its migration. However, if the inode is both encrypted and compressed, during ioc_decompress(), it will tag page w/ gcing flag, and it increase F2FS_WB_DATA reference count: - f2fs_write_multi_page - f2fs_write_raw_page - f2fs_write_single_page - do_write_page - f2fs_submit_page_write - WB_DATA_TYPE(bio_page, fio->compressed_page) : bio_page is encrypted, so mapping is NULL, and fio->compressed_page is NULL, it returns F2FS_WB_DATA - inc_page_count(.., F2FS_WB_DATA) Then, during end_io(), it decrease F2FS_WB_CP_DATA reference count: - f2fs_write_end_io - f2fs_compress_write_end_io - fscrypt_pagecache_folio : get raw page from encrypted page - WB_DATA_TYPE(&folio->page, false) : raw page has gcing flag, it returns F2FS_WB_CP_DATA - dec_page_count(.., F2FS_WB_CP_DATA) In order to fix this issue, we need to detect gcing flag in raw page in f2fs_is_cp_guaranteed(). Fixes: 4961acdd65c9 ("f2fs: fix to tag gcing flag on page during block migration") Reported-by: Jan Prusakowski Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit d93198513eada13158d1498aa9f8d0627490c49b Author: Chao Yu Date: Mon Apr 14 18:52:36 2025 +0800 f2fs: clean up w/ fscrypt_is_bounce_page() [ Upstream commit 0c708e35cf26449ca317fcbfc274704660b6d269 ] Just cleanup, no logic changes. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Stable-dep-of: aa1be8dd6416 ("f2fs: fix to detect gcing page in f2fs_is_cp_guaranteed()") Signed-off-by: Sasha Levin commit f1e573d7dafd9cc03b7fb8988f841716fecc8bb9 Author: Hangbin Liu Date: Thu Apr 24 04:22:38 2025 +0000 bonding: assign random address if device address is same as bond [ Upstream commit 5c3bf6cba7911f470afd748606be5c03a9512fcc ] This change addresses a MAC address conflict issue in failover scenarios, similar to the problem described in commit a951bc1e6ba5 ("bonding: correct the MAC address for 'follow' fail_over_mac policy"). In fail_over_mac=follow mode, the bonding driver expects the formerly active slave to swap MAC addresses with the newly active slave during failover. However, under certain conditions, two slaves may end up with the same MAC address, which breaks this policy: 1) ip link set eth0 master bond0 -> bond0 adopts eth0's MAC address (MAC0). 2) ip link set eth1 master bond0 -> eth1 is added as a backup with its own MAC (MAC1). 3) ip link set eth0 nomaster -> eth0 is released and restores its MAC (MAC0). -> eth1 becomes the active slave, and bond0 assigns MAC0 to eth1. 4) ip link set eth0 master bond0 -> eth0 is re-added to bond0, now both eth0 and eth1 have MAC0. This results in a MAC address conflict and violates the expected behavior of the failover policy. To fix this, we assign a random MAC address to any newly added slave if its current MAC address matches that of the bond. The original (permanent) MAC address is saved and will be restored when the device is released from the bond. This ensures that each slave has a unique MAC address during failover transitions, preserving the integrity of the fail_over_mac=follow policy. Fixes: 3915c1e8634a ("bonding: Add "follow" option to fail_over_mac") Signed-off-by: Hangbin Liu Acked-by: Jay Vosburgh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 231123516968a09f2be95b635e6ddd0aa9bf4d44 Author: Jason Gunthorpe Date: Fri Apr 25 10:08:37 2025 -0300 iommu: Protect against overflow in iommu_pgsize() [ Upstream commit e586e22974d2b7acbef3c6c3e01b2d5ce69efe33 ] On a 32 bit system calling: iommu_map(0, 0x40000000) When using the AMD V1 page table type with a domain->pgsize of 0xfffff000 causes iommu_pgsize() to miscalculate a result of: size=0x40000000 count=2 count should be 1. This completely corrupts the mapping process. This is because the final test to adjust the pagesize malfunctions when the addition overflows. Use check_add_overflow() to prevent this. Fixes: b1d99dc5f983 ("iommu: Hook up '->unmap_pages' driver callback") Signed-off-by: Jason Gunthorpe Reviewed-by: Lu Baolu Link: https://lore.kernel.org/r/0-v1-3ad28fc2e3a3+163327-iommu_overflow_pgsize_jgg@nvidia.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit b4dcc631a6e478ac038cd35738028e3753fb504e Author: Arnd Bergmann Date: Wed Apr 23 18:48:16 2025 +0200 iommu/io-pgtable-arm: dynamically allocate selftest device struct [ Upstream commit fa26198d30f3cdd7627ce47362057848219de765 ] In general a 'struct device' is way too large to be put on the kernel stack. Apparently something just caused it to grow a slightly larger, which pushed the arm_lpae_do_selftests() function over the warning limit in some configurations: drivers/iommu/io-pgtable-arm.c:1423:19: error: stack frame size (1032) exceeds limit (1024) in 'arm_lpae_do_selftests' [-Werror,-Wframe-larger-than] 1423 | static int __init arm_lpae_do_selftests(void) | ^ Change the function to use a dynamically allocated faux_device instead of the on-stack device structure. Fixes: ca25ec247aad ("iommu/io-pgtable-arm: Remove iommu_dev==NULL special case") Link: https://lore.kernel.org/all/ab75a444-22a1-47f5-b3c0-253660395b5a@arm.com/ Signed-off-by: Arnd Bergmann Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/20250423164826.2931382-1-arnd@kernel.org Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 0971b82fb2803ee5468c721586912c5c95eee4ba Author: Arnd Bergmann Date: Wed Apr 23 18:40:02 2025 +0200 iommu: ipmmu-vmsa: avoid Wformat-security warning [ Upstream commit 33647d0be323f9e2f27cd1e86de5cfd965cec654 ] iommu_device_sysfs_add() requires a constant format string, otherwise a W=1 build produces a warning: drivers/iommu/ipmmu-vmsa.c:1093:62: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] 1093 | ret = iommu_device_sysfs_add(&mmu->iommu, &pdev->dev, NULL, dev_name(&pdev->dev)); | ^~~~~~~~~~~~~~~~~~~~ drivers/iommu/ipmmu-vmsa.c:1093:62: note: treat the string as an argument to avoid this 1093 | ret = iommu_device_sysfs_add(&mmu->iommu, &pdev->dev, NULL, dev_name(&pdev->dev)); | ^ | "%s", This was an old bug but I saw it now because the code was changed as part of commit d9d3cede4167 ("iommu/ipmmu-vmsa: Register in a sensible order"). Fixes: 7af9a5fdb9e0 ("iommu/ipmmu-vmsa: Use iommu_device_sysfs_add()/remove()") Signed-off-by: Arnd Bergmann Reviewed-by: Geert Uytterhoeven Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20250423164006.2661372-1-arnd@kernel.org Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 07d74c1c976d496bc3b1f0c70e157795e8a7d9d8 Author: Jonathan Wiepert Date: Thu Apr 24 18:14:57 2025 -0400 Use thread-safe function pointer in libbpf_print [ Upstream commit 91dbac4076537b464639953c055c460d2bdfc7ea ] This patch fixes a thread safety bug where libbpf_print uses the global variable storing the print function pointer rather than the local variable that had the print function set via __atomic_load_n. Fixes: f1cb927cdb62 ("libbpf: Ensure print callback usage is thread-safe") Signed-off-by: Jonathan Wiepert Signed-off-by: Andrii Nakryiko Acked-by: Mykyta Yatsenko Link: https://lore.kernel.org/bpf/20250424221457.793068-1-jonathan.wiepert@gmail.com Signed-off-by: Sasha Levin commit c5a5553e3b5261cc68fd25d4ce1510f959ab2f1f Author: Tao Chen Date: Thu Apr 24 00:39:01 2025 +0800 libbpf: Remove sample_period init in perf_buffer [ Upstream commit 64821d25f05ac468d435e61669ae745ce5a633ea ] It seems that sample_period is not used in perf buffer. Actually, only wakeup_events are meaningful to enable events aggregation for wakeup notification. Remove sample_period setting code to avoid confusion. Fixes: fb84b8224655 ("libbpf: add perf buffer API") Signed-off-by: Tao Chen Signed-off-by: Andrii Nakryiko Acked-by: Jiri Olsa Acked-by: Namhyung Kim Link: https://lore.kernel.org/bpf/20250423163901.2983689-1-chen.dylane@linux.dev Signed-off-by: Sasha Levin commit a02347dbd0874bff5ad33dfad34ae4ccfa4c76c3 Author: Miri Korenblit Date: Wed Apr 23 09:16:29 2025 +0300 wifi: iwlwifi: re-add IWL_AMSDU_8K case [ Upstream commit bdd6d93d7a109ba1080336fe07d0b4eb815efaf9 ] This case in iwl_trans_get_rb_size_order was accidently combined with the IWL_AMSDU_12K case. Fix this. Fixes: 7391b2a4f7db ("wifi: iwlwifi: rework firmware error handling") Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250423091408.ef19205aa358.Ifbf89e7b7391cd7070267b7360c53230b3b2c57c@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 220735551a40109222f2f900dc90290f8aca0143 Author: Feng Yang Date: Thu Apr 17 09:48:46 2025 +0800 libbpf: Fix event name too long error [ Upstream commit 4dde20b1aa85d69c4281eaac9a7cfa7d2b62ecf0 ] When the binary path is excessively long, the generated probe_name in libbpf exceeds the kernel's MAX_EVENT_NAME_LEN limit (64 bytes). This causes legacy uprobe event attachment to fail with error code -22. The fix reorders the fields to place the unique ID before the name. This ensures that even if truncation occurs via snprintf, the unique ID remains intact, preserving event name uniqueness. Additionally, explicit checks with MAX_EVENT_NAME_LEN are added to enforce length constraints. Before Fix: ./test_progs -t attach_probe/kprobe-long_name ...... libbpf: failed to add legacy kprobe event for 'bpf_testmod_looooooooooooooooooooooooooooooong_name+0x0': -EINVAL libbpf: prog 'handle_kprobe': failed to create kprobe 'bpf_testmod_looooooooooooooooooooooooooooooong_name+0x0' perf event: -EINVAL test_attach_kprobe_long_event_name:FAIL:attach_kprobe_long_event_name unexpected error: -22 test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec #13/11 attach_probe/kprobe-long_name:FAIL #13 attach_probe:FAIL ./test_progs -t attach_probe/uprobe-long_name ...... libbpf: failed to add legacy uprobe event for /root/linux-bpf/bpf-next/tools/testing/selftests/bpf/test_progs:0x13efd9: -EINVAL libbpf: prog 'handle_uprobe': failed to create uprobe '/root/linux-bpf/bpf-next/tools/testing/selftests/bpf/test_progs:0x13efd9' perf event: -EINVAL test_attach_uprobe_long_event_name:FAIL:attach_uprobe_long_event_name unexpected error: -22 #13/10 attach_probe/uprobe-long_name:FAIL #13 attach_probe:FAIL After Fix: ./test_progs -t attach_probe/uprobe-long_name #13/10 attach_probe/uprobe-long_name:OK #13 attach_probe:OK Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED ./test_progs -t attach_probe/kprobe-long_name #13/11 attach_probe/kprobe-long_name:OK #13 attach_probe:OK Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED Fixes: 46ed5fc33db9 ("libbpf: Refactor and simplify legacy kprobe code") Fixes: cc10623c6810 ("libbpf: Add legacy uprobe attaching support") Signed-off-by: Hengqi Chen Signed-off-by: Feng Yang Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250417014848.59321-2-yangfeng59949@163.com Signed-off-by: Sasha Levin commit 124df6eef122a580052a0bf3bbc362886bd283e1 Author: Yihang Li Date: Mon Apr 14 16:08:44 2025 +0800 scsi: hisi_sas: Call I_T_nexus after soft reset for SATA disk [ Upstream commit e4d953ca557e02edd3aed7390043e1b8ad1c9723 ] In commit 21c7e972475e ("scsi: hisi_sas: Disable SATA disk phy for severe I_T nexus reset failure"), if the softreset fails upon certain conditions, the PHY connected to the disk is disabled directly. Manual recovery is required, which is inconvenient for users in actual use. In addition, SATA disks do not support simultaneous connection of multiple hosts. Therefore, when multiple controllers are connected to a SATA disk at the same time, the controller which is connected later failed to issue an ATA softreset to the SATA disk. As a result, the PHY associated with the disk is disabled and cannot be automatically recovered. Now that, we will not focus on the execution result of softreset. No matter whether the execution is successful or not, we will directly carry out I_T_nexus_reset. Fixes: 21c7e972475e ("scsi: hisi_sas: Disable SATA disk phy for severe I_T nexus reset failure") Signed-off-by: Yihang Li Link: https://lore.kernel.org/r/20250414080845.1220997-4-liyihang9@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ffb6487ed83fb0e5795ef46c127b1ab1d072fbae Author: Junxian Huang Date: Mon Apr 21 21:27:49 2025 +0800 RDMA/hns: Include hnae3.h in hns_roce_hw_v2.h [ Upstream commit 2b11d33de23262cb20d1dcb24b586dbb8f54d463 ] hns_roce_hw_v2.h has a direct dependency on hnae3.h due to the inline function hns_roce_write64(), but it doesn't include this header currently. This leads to that files including hns_roce_hw_v2.h must also include hnae3.h to avoid compilation errors, even if they themselves don't really rely on hnae3.h. This doesn't make sense, hns_roce_hw_v2.h should include hnae3.h directly. Fixes: d3743fa94ccd ("RDMA/hns: Fix the chip hanging caused by sending doorbell during reset") Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20250421132750.1363348-6-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 294bf7985b2b714b990b69b3804b389aae96dd7b Author: Zhu Yanjun Date: Sat Apr 19 10:07:41 2025 +0200 RDMA/rxe: Fix "trying to register non-static key in rxe_qp_do_cleanup" bug [ Upstream commit 1c7eec4d5f3b39cdea2153abaebf1b7229a47072 ] Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 assign_lock_key kernel/locking/lockdep.c:986 [inline] register_lock_class+0x4a3/0x4c0 kernel/locking/lockdep.c:1300 __lock_acquire+0x99/0x1ba0 kernel/locking/lockdep.c:5110 lock_acquire kernel/locking/lockdep.c:5866 [inline] lock_acquire+0x179/0x350 kernel/locking/lockdep.c:5823 __timer_delete_sync+0x152/0x1b0 kernel/time/timer.c:1644 rxe_qp_do_cleanup+0x5c3/0x7e0 drivers/infiniband/sw/rxe/rxe_qp.c:815 execute_in_process_context+0x3a/0x160 kernel/workqueue.c:4596 __rxe_cleanup+0x267/0x3c0 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_qp+0x3f7/0x5f0 drivers/infiniband/sw/rxe/rxe_verbs.c:604 create_qp+0x62d/0xa80 drivers/infiniband/core/verbs.c:1250 ib_create_qp_kernel+0x9f/0x310 drivers/infiniband/core/verbs.c:1361 ib_create_qp include/rdma/ib_verbs.h:3803 [inline] rdma_create_qp+0x10c/0x340 drivers/infiniband/core/cma.c:1144 rds_ib_setup_qp+0xc86/0x19a0 net/rds/ib_cm.c:600 rds_ib_cm_initiate_connect+0x1e8/0x3d0 net/rds/ib_cm.c:944 rds_rdma_cm_event_handler_cmn+0x61f/0x8c0 net/rds/rdma_transport.c:109 cma_cm_event_handler+0x94/0x300 drivers/infiniband/core/cma.c:2184 cma_work_handler+0x15b/0x230 drivers/infiniband/core/cma.c:3042 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 The root cause is as below: In the function rxe_create_qp, the function rxe_qp_from_init is called to create qp, if this function rxe_qp_from_init fails, rxe_cleanup will be called to handle all the allocated resources, including the timers: retrans_timer and rnr_nak_timer. The function rxe_qp_from_init calls the function rxe_qp_init_req to initialize the timers: retrans_timer and rnr_nak_timer. But these timers are initialized in the end of rxe_qp_init_req. If some errors occur before the initialization of these timers, this problem will occur. The solution is to check whether these timers are initialized or not. If these timers are not initialized, ignore these timers. Fixes: 8700e3e7c485 ("Soft RoCE driver") Reported-by: syzbot+4edb496c3cad6e953a31@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4edb496c3cad6e953a31 Signed-off-by: Zhu Yanjun Link: https://patch.msgid.link/20250419080741.1515231-1-yanjun.zhu@linux.dev Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6bfe7ae9bbd9734751b853e2d2e1c13e8b46fd2d Author: Maharaja Kennadyrajan Date: Wed Apr 16 07:47:24 2025 +0530 wifi: ath12k: fix node corruption in ar->arvifs list [ Upstream commit 823435bd23108d6f8be89ea2d025c0e2e3769c51 ] In current WLAN recovery code flow, ath12k_core_halt() only reinitializes the "arvifs" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head "arvifs", but the next of the list head "arvifs" no longer points to that list node. When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath12k_mac_vdev_delete(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic. The fix is to remove and reinitialize all vif list nodes from the list head "arvifs" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath12k_mac_vdev_delete() can execute normally. Call trace: __list_del_entry_valid_or_report+0xd4/0x100 (P) ath12k_mac_remove_link_interface.isra.0+0xf8/0x2e4 [ath12k] ath12k_scan_vdev_clean_work+0x40/0x164 [ath12k] cfg80211_wiphy_work+0xfc/0x100 process_one_work+0x164/0x2d0 worker_thread+0x254/0x380 kthread+0xfc/0x100 ret_from_fork+0x10/0x20 The change is mostly copied from the ath11k patch: https://lore.kernel.org/all/20250320053145.3445187-1-quic_stonez@quicinc.com/ Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Maharaja Kennadyrajan Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250416021724.2162519-1-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 2563069baf243cadc76dc64d9085606742c4b282 Author: Maharaja Kennadyrajan Date: Wed Apr 16 07:34:14 2025 +0530 wifi: ath12k: Prevent sending WMI commands to firmware during firmware crash [ Upstream commit e9e094a9734ea3bd4d4d117c915ccf129ac61ba1 ] Currently, we encounter the following kernel call trace when a firmware crash occurs. This happens because the host sends WMI commands to the firmware while it is in recovery, causing the commands to fail and resulting in the kernel call trace. Set the ATH12K_FLAG_CRASH_FLUSH and ATH12K_FLAG_RECOVERY flags when the host driver receives the firmware crash notification from MHI. This prevents sending WMI commands to the firmware during recovery. Call Trace: dump_stack_lvl+0x75/0xc0 register_lock_class+0x6be/0x7a0 ? __lock_acquire+0x644/0x19a0 __lock_acquire+0x95/0x19a0 lock_acquire+0x265/0x310 ? ath12k_ce_send+0xa2/0x210 [ath12k] ? find_held_lock+0x34/0xa0 ? ath12k_ce_send+0x56/0x210 [ath12k] _raw_spin_lock_bh+0x33/0x70 ? ath12k_ce_send+0xa2/0x210 [ath12k] ath12k_ce_send+0xa2/0x210 [ath12k] ath12k_htc_send+0x178/0x390 [ath12k] ath12k_wmi_cmd_send_nowait+0x76/0xa0 [ath12k] ath12k_wmi_cmd_send+0x62/0x190 [ath12k] ath12k_wmi_pdev_bss_chan_info_request+0x62/0xc0 [ath1 ath12k_mac_op_get_survey+0x2be/0x310 [ath12k] ieee80211_dump_survey+0x99/0x240 [mac80211] nl80211_dump_survey+0xe7/0x470 [cfg80211] ? kmalloc_reserve+0x59/0xf0 genl_dumpit+0x24/0x70 netlink_dump+0x177/0x360 __netlink_dump_start+0x206/0x280 genl_family_rcv_msg_dumpit.isra.22+0x8a/0xe0 ? genl_family_rcv_msg_attrs_parse.isra.23+0xe0/0xe0 ? genl_op_lock.part.12+0x10/0x10 ? genl_dumpit+0x70/0x70 genl_rcv_msg+0x1d0/0x290 ? nl80211_del_station+0x330/0x330 [cfg80211] ? genl_get_cmd_both+0x50/0x50 netlink_rcv_skb+0x4f/0x100 genl_rcv+0x1f/0x30 netlink_unicast+0x1b6/0x260 netlink_sendmsg+0x31a/0x450 __sock_sendmsg+0xa8/0xb0 ____sys_sendmsg+0x1e4/0x260 ___sys_sendmsg+0x89/0xe0 ? local_clock_noinstr+0xb/0xc0 ? rcu_is_watching+0xd/0x40 ? kfree+0x1de/0x370 ? __sys_sendmsg+0x7a/0xc0 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: a9b46dd2e483 ("wifi: ath12k: Add firmware coredump collection support") Signed-off-by: Maharaja Kennadyrajan Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250416020414.2161545-1-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 98bf5da4bc06adce2fb86dc9aeadae3272a82cee Author: Rameshkumar Sundaram Date: Wed Apr 16 01:28:11 2025 +0530 wifi: ath12k: fix wrong handling of CCMP256 and GCMP ciphers [ Upstream commit f5d6b15d9503263d9425dcde9cc2fd401a32b0f2 ] Currently for CCMP256, GCMP128 and GCMP256 ciphers, in ath12k_install_key() IEEE80211_KEY_FLAG_GENERATE_IV_MGMT is not set and in ath12k_mac_mgmt_tx_wmi() a length of IEEE80211_CCMP_MIC_LEN is reserved for all ciphers. This results in unexpected drop of protected management frames in case either of above 3 ciphers is used. The reason is, without IEEE80211_KEY_FLAG_GENERATE_IV_MGMT set, mac80211 will not generate CCMP/GCMP headers in TX frame for ath12k. Also MIC length reserved is wrong and such frames are dropped by hardware. Fix this by setting IEEE80211_KEY_FLAG_GENERATE_IV_MGMT flag for above ciphers and by reserving proper MIC length for those ciphers. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Rameshkumar Sundaram Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250415195812.2633923-2-rameshkumar.sundaram@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 124bd8cea02395a1a140f1dcc5e57c65cdd428af Author: P Praneesh Date: Wed Apr 2 23:59:17 2025 +0530 wifi: ath12k: replace the usage of rx desc with rx_info [ Upstream commit bd00cc7e8a4c1048d14c9a9e9790c582119785fb ] In ath12k_dp_rx_h_mpdu(), during the undecap to native wifi mode, the rx descriptor memory is overwritten. After this function call, any subsequent accesses to rx descriptor related memory yield invalid values. Fix this by replacing instances where rx_desc was used with the pre-cached information in rx_info. This ensures that the values populated from the rx descriptor are accurate and prevents invalid memory access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Co-developed-by: Karthikeyan Periyasamy Signed-off-by: Karthikeyan Periyasamy Signed-off-by: P Praneesh Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250402182917.2715596-3-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson Stable-dep-of: f5d6b15d9503 ("wifi: ath12k: fix wrong handling of CCMP256 and GCMP ciphers") Signed-off-by: Sasha Levin commit 3ff947186f8fef9e9dfc97625ee23eda6a768b0e Author: P Praneesh Date: Wed Apr 2 23:59:16 2025 +0530 wifi: ath12k: add rx_info to capture required field from rx descriptor [ Upstream commit e88e6e3c9ada84ceed3fa223ce11af94fcaf3ad3 ] In ath12k_dp_rx_h_mpdu(), as part of undecap to native wifi mode, the rx descriptor memory is getting overwritten. After this function call, all the rx descriptor related memory accesses give invalid values. To handle this scenario, introduce a new structure ath12k_dp_rx_info which pre-caches all the required fields from the rx descriptor before calling ath12k_dp_rx_h_ppdu(). This rx_info structure will be used in the next patch. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Co-developed-by: Karthikeyan Periyasamy Signed-off-by: Karthikeyan Periyasamy Signed-off-by: P Praneesh Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250402182917.2715596-2-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson Stable-dep-of: f5d6b15d9503 ("wifi: ath12k: fix wrong handling of CCMP256 and GCMP ciphers") Signed-off-by: Sasha Levin commit b05e7e6ada85c233be49ad65affe621068a1f9fa Author: P Praneesh Date: Mon Mar 24 11:55:13 2025 +0530 wifi: ath12k: change the status update in the monitor Rx [ Upstream commit 5393dcb4520911f2b4a980e7e3c2c0de2bbf9ec7 ] Currently, in the monitor Rx path, status is filled from the RX TLV header present in the MSDU data. This logic is inherited from ath11k. However, in the ath12k 802.11be hardware, the Rx TLV header is not present in the MSDU data. This information is reported under various TLV tags. Therefore, avoid the existing status filling by accumulating the needed information in the PPDU information structure and fill the status. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh Tested-by: Nicolas Escande Reviewed-by: Vasanthakumar Thiagarajan Signed-off-by: Karthikeyan Periyasamy Link: https://patch.msgid.link/20250324062518.2752822-6-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson Stable-dep-of: f5d6b15d9503 ("wifi: ath12k: fix wrong handling of CCMP256 and GCMP ciphers") Signed-off-by: Sasha Levin commit 5d743c3d89ce73172722079379f04cbbb02731b5 Author: Karthikeyan Periyasamy Date: Mon Mar 24 11:55:12 2025 +0530 wifi: ath12k: Replace band define G with GHZ where appropriate [ Upstream commit 6a88093f79ea0b131e5feab9cdc045a007fad26e ] Currently, band define and enum are with the word 'G'. Replace it with more appropriate 'GHZ' for clarity and correctness. No functional changes. Only compile tested. Reviewed-by: Vasanthakumar Thiagarajan Signed-off-by: Karthikeyan Periyasamy Link: https://patch.msgid.link/20250324062518.2752822-5-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson Stable-dep-of: f5d6b15d9503 ("wifi: ath12k: fix wrong handling of CCMP256 and GCMP ciphers") Signed-off-by: Sasha Levin commit f3de1a1a799dca01dc61538a2426ef2d9405309f Author: P Praneesh Date: Mon Mar 24 11:55:11 2025 +0530 wifi: ath12k: Avoid fetch Error bitmap and decap format from Rx TLV [ Upstream commit a6621bf6397ae6981b5041ba0a127e7dbeade746 ] Currently, error bitmap and decap format information are fetched from the MSDU Rx TLV data. This logic is inherited from ath11k. However, for ath12k 802.11be hardware, the Rx TLV will not be present in the MSDU data. Instead, this information is reported separately under the MSDU END TLV tag. Therefore, remove the existing fetch code, handle the MSDU END TLV tag and fetch the above information to store it in the mon_mpdu data structure for use in the merge MSDU procedure. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh Tested-by: Nicolas Escande Reviewed-by: Vasanthakumar Thiagarajan Signed-off-by: Karthikeyan Periyasamy Link: https://patch.msgid.link/20250324062518.2752822-4-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson Stable-dep-of: f5d6b15d9503 ("wifi: ath12k: fix wrong handling of CCMP256 and GCMP ciphers") Signed-off-by: Sasha Levin commit 648f34a8d3c0b547004c17628ccde3abeb6b9f99 Author: P Praneesh Date: Mon Mar 24 11:55:10 2025 +0530 wifi: ath12k: Add extra TLV tag parsing support in monitor Rx path [ Upstream commit 3973cda5ef496fd412fdec2c7c3403ac90e391b8 ] Currently, the monitor Rx parser handler is inherited from the ath11k. However, the ath12k 802.11be hardware does not report the Rx TLV header in the MSDU data. Instead, the hardware reports those TLVs under the following TLV tags: 1. Buffer address 2. MPDU start 3. MPDU end 4. MSDU end Therefore, add support for parsing the above TLVs in the Rx monitor path and use this information for MSDU buffer and status updates. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh Tested-by: Nicolas Escande Reviewed-by: Vasanthakumar Thiagarajan Signed-off-by: Karthikeyan Periyasamy Link: https://patch.msgid.link/20250324062518.2752822-3-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson Stable-dep-of: f5d6b15d9503 ("wifi: ath12k: fix wrong handling of CCMP256 and GCMP ciphers") Signed-off-by: Sasha Levin commit 3add30f43b0137f91ef5104c3aa7427e36b007d8 Author: Ramasamy Kaliappan Date: Wed Apr 16 00:11:02 2025 +0530 wifi: ath12k: Fix the QoS control field offset to build QoS header [ Upstream commit 8599d4cc4191c8c1af34207a8b9414acca4afb59 ] Currently, in the mac80211 layer, received EAPOL packets are dropped when the HT control field is present in the QoS header. This issue arises due to an incorrect QoS control field offset used to build the QoS header in the MSDU data, leading to a corrupted header in the mac80211 layer. This issue also applies to other frames that contain the QoS control field, such as QoS data or Null frames. To resolve this, use ieee80211_get_qos_ctl() to obtain the correct QoS control offset from the MSDU data. Additionally, ensure the QoS control header is copied in little-endian format within the MSDU data. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Ramasamy Kaliappan Signed-off-by: Nithyanantham Paramasivam Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250415184102.2707300-1-nithyanantham.paramasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit c77ea4e216440f21ffbf293b28c4d46ded9ccf98 Author: P Praneesh Date: Wed Apr 16 07:49:03 2025 +0530 wifi: ath12k: Add MSDU length validation for TKIP MIC error [ Upstream commit 763216fe6c5df95d122c71ef34c342427c987820 ] In the WBM error path, while processing TKIP MIC errors, MSDU length is fetched from the hal_rx_desc's msdu_end. This MSDU length is directly passed to skb_put() without validation. In stress test scenarios, the WBM error ring may receive invalid descriptors, which could lead to an invalid MSDU length. To fix this, add a check to drop the skb when the calculated MSDU length is greater than the skb size. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: P Praneesh Signed-off-by: Nithyanantham Paramasivam Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250416021903.3178962-1-nithyanantham.paramasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5f09d16cd57764c95c8548fe5b70672c9ac01127 Author: Sarika Sharma Date: Tue Apr 8 10:23:27 2025 +0530 wifi: ath12k: fix invalid access to memory [ Upstream commit 9f17747fbda6fca934854463873c4abf8061491d ] In ath12k_dp_rx_msdu_coalesce(), rxcb is fetched from skb and boolean is_continuation is part of rxcb. Currently, after freeing the skb, the rxcb->is_continuation accessed again which is wrong since the memory is already freed. This might lead use-after-free error. Hence, fix by locally defining bool is_continuation from rxcb, so that after freeing skb, is_continuation can be used. Compile tested only. Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Sarika Sharma Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250408045327.1632222-1-quic_sarishar@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 1111e612c5f8b6e1a21091bbfcd26776c4318554 Author: P Praneesh Date: Fri Apr 11 11:31:51 2025 +0530 wifi: ath12k: Handle error cases during extended skb allocation [ Upstream commit 37a068fc9dc4feb8d76e8896bb33883d06c11a6b ] Currently, in the case of extended skb allocation, the buffer is freed before the DMA unmap operation. This premature deletion can result in skb->data corruption, as the memory region could be re-allocated for other purposes. Fix this issue by reordering the failure cases by calling dma_unmap_single() first, then followed by the corresponding kfree_skb(). This helps avoid data corruption in case of failures in dp_tx(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: P Praneesh Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250411060154.1388159-2-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit fc48ca82ff15d4bf7940460a2b271178eaf6be20 Author: Dmitry Antipov Date: Tue Apr 15 12:07:20 2025 +0300 wifi: rtw88: do not ignore hardware read error during DPK [ Upstream commit 20d3c19bd8f9b498173c198eadf54580c8caa336 ] In 'rtw8822c_dpk_cal_coef1()', do not ignore error returned by 'check_hw_ready()' but issue a warning to denote possible DPK issue. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5227c2ee453d ("rtw88: 8822c: add SW DPK support") Suggested-by: Ping-Ke Shih Signed-off-by: Dmitry Antipov Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250415090720.194048-1-dmantipov@yandex.ru Signed-off-by: Sasha Levin commit c2a306f51fa3ad8f7b0a6af0e1f4b25471044369 Author: Zhen XIN Date: Thu Apr 10 15:42:16 2025 +0000 wifi: rtw88: sdio: call rtw_sdio_indicate_tx_status unconditionally [ Upstream commit fc5f5a0ec463ae6a07850428bd3082947e01d276 ] The rtw88-sdio do not work in AP mode due to the lack of TX status report for management frames. Make the invocation of rtw_sdio_indicate_tx_status unconditional and cover all packet queues Tested-on: rtl8723ds Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets") Signed-off-by: Zhen XIN Reviewed-by: Martin Blumenstingl Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250410154217.1849977-2-zhen.xin@nokia-sbell.com Signed-off-by: Sasha Levin commit 7a0ba7b2c2cb4af8a9b1fe2bdb7f2da82e3cec0a Author: Zhen XIN Date: Thu Apr 10 15:42:17 2025 +0000 wifi: rtw88: sdio: map mgmt frames to queue TX_DESC_QSEL_MGMT [ Upstream commit b2effcdc237979dcc533d446a792fc54fd0e1213 ] The rtw88-sdio do not work in AP mode due to the lack of TX status report for management frames. Map the management frames to queue TX_DESC_QSEL_MGMT, which enables the chip to generate TX reports for these frames Tested-on: rtl8723ds Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets") Signed-off-by: Zhen XIN Reviewed-by: Martin Blumenstingl Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250410154217.1849977-3-zhen.xin@nokia-sbell.com Signed-off-by: Sasha Levin commit d679fb0876e448db8b51f666563fcbde2d373d12 Author: Cosmin Ratiu Date: Fri Apr 11 10:49:58 2025 +0300 bonding: Fix multiple long standing offload races [ Upstream commit d2fddbd3479928e52061e1c8dd302006b6283ce8 ] Refactor the bonding ipsec offload operations to fix a number of long-standing control plane races between state migration and user deletion and a few other issues. xfrm state deletion can happen concurrently with bond_change_active_slave() operation. This manifests itself as a bond_ipsec_del_sa() call with x->lock held, followed by a bond_ipsec_free_sa() a bit later from a wq. The alternate path of these calls coming from xfrm_dev_state_flush() can't happen, as that needs the RTNL lock and bond_change_active_slave() already holds it. 1. bond_ipsec_del_sa_all() might call xdo_dev_state_delete() a second time on an xfrm state that was concurrently killed. This is bad. 2. bond_ipsec_add_sa_all() can add a state on the new device, but pending bond_ipsec_free_sa() calls from the old device will then hit the WARN_ON() and then, worse, call xdo_dev_state_free() on the new device without a corresponding xdo_dev_state_delete(). 3. Resolve a sleeping in atomic context introduced by the mentioned "Fixes" commit. bond_ipsec_del_sa_all() and bond_ipsec_add_sa_all() now acquire x->lock and check for x->km.state to help with problems 1 and 2. And since xso.real_dev is now a private pointer managed by the bonding driver in xfrm state, make better use of it to fully fix problems 1 and 2. In bond_ipsec_del_sa_all(), set xso.real_dev to NULL while holding both the mutex and x->lock, which makes sure that neither bond_ipsec_del_sa() nor bond_ipsec_free_sa() could run concurrently. Fix problem 3 by moving the list cleanup (which requires the mutex) from bond_ipsec_del_sa() (called from atomic context) to bond_ipsec_free_sa() Finally, simplify bond_ipsec_del_sa() and bond_ipsec_free_sa() by using xso->real_dev directly, since it's now protected by locks and can be trusted to always reflect the offload device. Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to mutex") Signed-off-by: Cosmin Ratiu Reviewed-by: Leon Romanovsky Reviewed-by: Nikolay Aleksandrov Reviewed-by: Hangbin Liu Tested-by: Hangbin Liu Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit d50cc6afb2a88ca2a4366f79c7ff8068a966fc6e Author: Cosmin Ratiu Date: Fri Apr 11 10:49:57 2025 +0300 bonding: Mark active offloaded xfrm_states [ Upstream commit fd4e41ebf66cb8b43de2f640b97314c4ee3b4499 ] When the active link is changed for a bond device, the existing xfrm states need to be migrated over to the new link. This is done with: - bond_ipsec_del_sa_all() goes through the offloaded states list and removes all of them from hw. - bond_ipsec_add_sa_all() re-offloads all states to the new device. But because the offload status of xfrm states isn't marked in any way, there can be bugs. When all bond links are down, bond_ipsec_del_sa_all() unoffloads everything from the previous active link. If the same link then comes back up, nothing gets reoffloaded by bond_ipsec_add_sa_all(). This results in a stack trace like this a bit later when user space removes the offloaded rules, because mlx5e_xfrm_del_state() is asked to remove a rule that's no longer offloaded: [] Call Trace: [] [] ? __warn+0x7d/0x110 [] ? mlx5e_xfrm_del_state+0x90/0xa0 [mlx5_core] [] ? report_bug+0x16d/0x180 [] ? handle_bug+0x4f/0x90 [] ? exc_invalid_op+0x14/0x70 [] ? asm_exc_invalid_op+0x16/0x20 [] ? mlx5e_xfrm_del_state+0x73/0xa0 [mlx5_core] [] ? mlx5e_xfrm_del_state+0x90/0xa0 [mlx5_core] [] bond_ipsec_del_sa+0x1ab/0x200 [bonding] [] xfrm_dev_state_delete+0x1f/0x60 [] __xfrm_state_delete+0x196/0x200 [] xfrm_state_delete+0x21/0x40 [] xfrm_del_sa+0x69/0x110 [] xfrm_user_rcv_msg+0x11d/0x300 [] ? release_pages+0xca/0x140 [] ? copy_to_user_tmpl.part.0+0x110/0x110 [] netlink_rcv_skb+0x54/0x100 [] xfrm_netlink_rcv+0x31/0x40 [] netlink_unicast+0x1fc/0x2d0 [] netlink_sendmsg+0x1e4/0x410 [] __sock_sendmsg+0x38/0x60 [] sock_write_iter+0x94/0xf0 [] vfs_write+0x338/0x3f0 [] ksys_write+0xba/0xd0 [] do_syscall_64+0x4c/0x100 [] entry_SYSCALL_64_after_hwframe+0x4b/0x53 There's also another theoretical bug: Calling bond_ipsec_del_sa_all() multiple times can result in corruption in the driver implementation if the double-free isn't tolerated. This isn't nice. Before the "Fixes" commit, xs->xso.real_dev was set to NULL when an xfrm state was unoffloaded from a device, but a race with netdevsim's .xdo_dev_offload_ok() accessing real_dev was considered a sufficient reason to not set real_dev to NULL anymore. This unfortunately introduced the new bugs. Since .xdo_dev_offload_ok() was significantly refactored by [1] and there are no more users in the stack of xso.real_dev, that race is now gone and xs->xso.real_dev can now once again be used to represent which device (if any) currently holds the offloaded rule. Go one step further and set real_dev after add/before delete calls, to catch any future driver misuses of real_dev. [1] https://lore.kernel.org/netdev/cover.1739972570.git.leon@kernel.org/ Fixes: f8cde9805981 ("bonding: fix xfrm real_dev null pointer dereference") Signed-off-by: Cosmin Ratiu Reviewed-by: Leon Romanovsky Reviewed-by: Nikolay Aleksandrov Reviewed-by: Hangbin Liu Tested-by: Hangbin Liu Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 877e87a450cfe655c7bf6175368631d76eedbe14 Author: Cosmin Ratiu Date: Fri Apr 11 10:49:56 2025 +0300 xfrm: Add explicit dev to .xdo_dev_state_{add,delete,free} [ Upstream commit 43eca05b6a3b917c600e10cc6b06bfa57fa57401 ] Previously, device driver IPSec offload implementations would fall into two categories: 1. Those that used xso.dev to determine the offload device. 2. Those that used xso.real_dev to determine the offload device. The first category didn't work with bonding while the second did. In a non-bonding setup the two pointers are the same. This commit adds explicit pointers for the offload netdevice to .xdo_dev_state_add() / .xdo_dev_state_delete() / .xdo_dev_state_free() which eliminates the confusion and allows drivers from the first category to work with bonding. xso.real_dev now becomes a private pointer managed by the bonding driver. Signed-off-by: Cosmin Ratiu Reviewed-by: Leon Romanovsky Reviewed-by: Nikolay Aleksandrov Signed-off-by: Steffen Klassert Stable-dep-of: fd4e41ebf66c ("bonding: Mark active offloaded xfrm_states") Signed-off-by: Sasha Levin commit baab28f90ddca048e72af8013a50da9b63af03b7 Author: Cosmin Ratiu Date: Fri Apr 11 10:49:54 2025 +0300 xfrm: Use xdo.dev instead of xdo.real_dev [ Upstream commit 25ac138f58e7d5c8bffa31e8891418d2819180c4 ] The policy offload struct was reused from the state offload and real_dev was copied from dev, but it was never set to anything else. Simplify the code by always using xdo.dev for policies. Signed-off-by: Cosmin Ratiu Reviewed-by: Leon Romanovsky Reviewed-by: Nikolay Aleksandrov Signed-off-by: Steffen Klassert Stable-dep-of: fd4e41ebf66c ("bonding: Mark active offloaded xfrm_states") Signed-off-by: Sasha Levin commit 8fa26547de4f1a01fec07b2ce4d334856d27811d Author: Cosmin Ratiu Date: Fri Apr 11 10:49:53 2025 +0300 net/mlx5: Avoid using xso.real_dev unnecessarily [ Upstream commit d79444e8c3d40b11f5e155e5591d53bd1e512e1f ] xso.real_dev is the active device of an offloaded xfrm state and is managed by bonding. As such, it's subject to change when states are migrated to a new device. Using it in places other than offloading/unoffloading the states is risky. This commit saves the device into the driver-specific struct mlx5e_ipsec_sa_entry and switches mlx5e_ipsec_init_macs() and mlx5e_ipsec_netevent_event() to make use of it. Additionally, mlx5e_xfrm_update_stats() used xso.real_dev to validate that correct net locks are held. But in a bonding config, the net of the master device is the same as the underlying devices, and the net is already a local var, so use that instead. The only remaining references to xso.real_dev are now in the .xdo_dev_state_add() / .xdo_dev_state_delete() path. Signed-off-by: Cosmin Ratiu Reviewed-by: Leon Romanovsky Reviewed-by: Nikolay Aleksandrov Signed-off-by: Steffen Klassert Stable-dep-of: fd4e41ebf66c ("bonding: Mark active offloaded xfrm_states") Signed-off-by: Sasha Levin commit 0e84dc981b3b84553d7a1616e912e03153d82ac3 Author: Viktor Malik Date: Tue Apr 15 17:50:14 2025 +0200 libbpf: Fix buffer overflow in bpf_object__init_prog [ Upstream commit ee684de5c1b0ac01821320826baec7da93f3615b ] As shown in [1], it is possible to corrupt a BPF ELF file such that arbitrary BPF instructions are loaded by libbpf. This can be done by setting a symbol (BPF program) section offset to a large (unsigned) number such that
overflows and points before the section data in the memory. Consider the situation below where: - prog_start = sec_start + symbol_offset <-- size_t overflow here - prog_end = prog_start + prog_size prog_start sec_start prog_end sec_end | | | | v v v v .....................|################################|............ The report in [1] also provides a corrupted BPF ELF which can be used as a reproducer: $ readelf -S crash Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align ... [ 2] uretprobe.mu[...] PROGBITS 0000000000000000 00000040 0000000000000068 0000000000000000 AX 0 0 8 $ readelf -s crash Symbol table '.symtab' contains 8 entries: Num: Value Size Type Bind Vis Ndx Name ... 6: ffffffffffffffb8 104 FUNC GLOBAL DEFAULT 2 handle_tp Here, the handle_tp prog has section offset ffffffffffffffb8, i.e. will point before the actual memory where section 2 is allocated. This is also reported by AddressSanitizer: ================================================================= ==1232==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7c7302fe0000 at pc 0x7fc3046e4b77 bp 0x7ffe64677cd0 sp 0x7ffe64677490 READ of size 104 at 0x7c7302fe0000 thread T0 #0 0x7fc3046e4b76 in memcpy (/lib64/libasan.so.8+0xe4b76) #1 0x00000040df3e in bpf_object__init_prog /src/libbpf/src/libbpf.c:856 #2 0x00000040df3e in bpf_object__add_programs /src/libbpf/src/libbpf.c:928 #3 0x00000040df3e in bpf_object__elf_collect /src/libbpf/src/libbpf.c:3930 #4 0x00000040df3e in bpf_object_open /src/libbpf/src/libbpf.c:8067 #5 0x00000040f176 in bpf_object__open_file /src/libbpf/src/libbpf.c:8090 #6 0x000000400c16 in main /poc/poc.c:8 #7 0x7fc3043d25b4 in __libc_start_call_main (/lib64/libc.so.6+0x35b4) #8 0x7fc3043d2667 in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x3667) #9 0x000000400b34 in _start (/poc/poc+0x400b34) 0x7c7302fe0000 is located 64 bytes before 104-byte region [0x7c7302fe0040,0x7c7302fe00a8) allocated by thread T0 here: #0 0x7fc3046e716b in malloc (/lib64/libasan.so.8+0xe716b) #1 0x7fc3045ee600 in __libelf_set_rawdata_wrlock (/lib64/libelf.so.1+0xb600) #2 0x7fc3045ef018 in __elf_getdata_rdlock (/lib64/libelf.so.1+0xc018) #3 0x00000040642f in elf_sec_data /src/libbpf/src/libbpf.c:3740 The problem here is that currently, libbpf only checks that the program end is within the section bounds. There used to be a check `while (sec_off < sec_sz)` in bpf_object__add_programs, however, it was removed by commit 6245947c1b3c ("libbpf: Allow gaps in BPF program sections to support overriden weak functions"). Add a check for detecting the overflow of `sec_off + prog_sz` to bpf_object__init_prog to fix this issue. [1] https://github.com/lmarch2/poc/blob/main/libbpf/libbpf.md Fixes: 6245947c1b3c ("libbpf: Allow gaps in BPF program sections to support overriden weak functions") Reported-by: lmarch2 <2524158037@qq.com> Signed-off-by: Viktor Malik Signed-off-by: Andrii Nakryiko Reviewed-by: Shung-Hsi Yu Link: https://github.com/lmarch2/poc/blob/main/libbpf/libbpf.md Link: https://lore.kernel.org/bpf/20250415155014.397603-1-vmalik@redhat.com Signed-off-by: Sasha Levin commit feec357c102205fee8b3e9d99170c1ef5cfae908 Author: Hari Kalavakunta Date: Wed Apr 9 18:23:08 2025 -0700 net: ncsi: Fix GCPS 64-bit member variables [ Upstream commit e8a1bd8344054ce27bebf59f48e3f6bc10bc419b ] Correct Get Controller Packet Statistics (GCPS) 64-bit wide member variables, as per DSP0222 v1.0.0 and forward specs. The Driver currently collects these stats, but they are yet to be exposed to the user. Therefore, no user impact. Statistics fixes: Total Bytes Received (byte range 28..35) Total Bytes Transmitted (byte range 36..43) Total Unicast Packets Received (byte range 44..51) Total Multicast Packets Received (byte range 52..59) Total Broadcast Packets Received (byte range 60..67) Total Unicast Packets Transmitted (byte range 68..75) Total Multicast Packets Transmitted (byte range 76..83) Total Broadcast Packets Transmitted (byte range 84..91) Valid Bytes Received (byte range 204..11) Signed-off-by: Hari Kalavakunta Reviewed-by: Paul Fertser Link: https://patch.msgid.link/20250410012309.1343-1-kalavakunta.hari.prasad@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 5cfa1b65b372fea30c30009990a46d19b420785f Author: Charles Han Date: Tue Mar 25 17:49:32 2025 +0800 pinctrl: qcom: tlmm-test: Fix potential null dereference in tlmm kunit test [ Upstream commit 1938be9fbad1bd87a1dcd9c3ca88e454565f0609 ] kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL check may lead to NULL dereference. Add a NULL check for grp. Fixes: c7984dc0a2b9 ("pinctrl: qcom: Add test case for TLMM interrupt handling") Signed-off-by: Charles Han Link: https://lore.kernel.org/20250325094932.4733-1-hanchunchao@inspur.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 001f9fd029a61714618eadb09960fa6f79e508dc Author: Vlad Dogaru Date: Thu Apr 10 22:17:31 2025 +0300 net/mlx5: HWS, Fix matcher action template attach [ Upstream commit 36ef2575e78d1a3c699dc3f1c9dee9be742c9bdd ] The procedure of attaching an action template to an existing matcher had a few issues: 1. Attaching accidentally overran the `at` array in bwc_matcher, which would result in memory corruption. This bug wasn't triggered, but it is possible to trigger it by attaching action templates beyond the initial buffer size of 8. Fix this by converting to a dynamically sized buffer and reallocating if needed. 2. Similarly, the `at` array inside the native matcher was never reallocated. Fix this the same as above. 3. The bwc layer treated any error in action template attach as a signal that the matcher should be rehashed to account for a larger number of action STEs. In reality, there are other unrelated errors that can arise and they should be propagated upstack. Fix this by adding a `need_rehash` output parameter that's orthogonal to error codes. Fixes: 2111bb970c78 ("net/mlx5: HWS, added backward-compatible API handling") Signed-off-by: Vlad Dogaru Reviewed-by: Yevgeny Kliteynik Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Reviewed-by: Michal Kubiak Link: https://patch.msgid.link/1744312662-356571-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c30ae60f41f9edd6e1b5cad41cf28ce04dae39e4 Author: Toke Høiland-Jørgensen Date: Wed Apr 9 12:41:37 2025 +0200 page_pool: Track DMA-mapped pages and unmap them when destroying the pool [ Upstream commit ee62ce7a1d909ccba0399680a03c2dee83bcae95 ] When enabling DMA mapping in page_pool, pages are kept DMA mapped until they are released from the pool, to avoid the overhead of re-mapping the pages every time they are used. This causes resource leaks and/or crashes when there are pages still outstanding while the device is torn down, because page_pool will attempt an unmap through a non-existent DMA device on the subsequent page return. To fix this, implement a simple tracking of outstanding DMA-mapped pages in page pool using an xarray. This was first suggested by Mina[0], and turns out to be fairly straight forward: We simply store pointers to pages directly in the xarray with xa_alloc() when they are first DMA mapped, and remove them from the array on unmap. Then, when a page pool is torn down, it can simply walk the xarray and unmap all pages still present there before returning, which also allows us to get rid of the get/put_device() calls in page_pool. Using xa_cmpxchg(), no additional synchronisation is needed, as a page will only ever be unmapped once. To avoid having to walk the entire xarray on unmap to find the page reference, we stash the ID assigned by xa_alloc() into the page structure itself, using the upper bits of the pp_magic field. This requires a couple of defines to avoid conflicting with the POINTER_POISON_DELTA define, but this is all evaluated at compile-time, so does not affect run-time performance. The bitmap calculations in this patch gives the following number of bits for different architectures: - 23 bits on 32-bit architectures - 21 bits on PPC64 (because of the definition of ILLEGAL_POINTER_VALUE) - 32 bits on other 64-bit architectures Stashing a value into the unused bits of pp_magic does have the effect that it can make the value stored there lie outside the unmappable range (as governed by the mmap_min_addr sysctl), for architectures that don't define ILLEGAL_POINTER_VALUE. This means that if one of the pointers that is aliased to the pp_magic field (such as page->lru.next) is dereferenced while the page is owned by page_pool, that could lead to a dereference into userspace, which is a security concern. The risk of this is mitigated by the fact that (a) we always clear pp_magic before releasing a page from page_pool, and (b) this would need a use-after-free bug for struct page, which can have many other risks since page->lru.next is used as a generic list pointer in multiple places in the kernel. As such, with this patch we take the position that this risk is negligible in practice. For more discussion, see[1]. Since all the tracking added in this patch is performed on DMA map/unmap, no additional code is needed in the fast path, meaning the performance overhead of this tracking is negligible there. A micro-benchmark shows that the total overhead of the tracking itself is about 400 ns (39 cycles(tsc) 395.218 ns; sum for both map and unmap[2]). Since this cost is only paid on DMA map and unmap, it seems like an acceptable cost to fix the late unmap issue. Further optimisation can narrow the cases where this cost is paid (for instance by eliding the tracking when DMA map/unmap is a no-op). The extra memory needed to track the pages is neatly encapsulated inside xarray, which uses the 'struct xa_node' structure to track items. This structure is 576 bytes long, with slots for 64 items, meaning that a full node occurs only 9 bytes of overhead per slot it tracks (in practice, it probably won't be this efficient, but in any case it should be an acceptable overhead). [0] https://lore.kernel.org/all/CAHS8izPg7B5DwKfSuzz-iOop_YRbk3Sd6Y4rX7KBG9DcVJcyWg@mail.gmail.com/ [1] https://lore.kernel.org/r/20250320023202.GA25514@openwall.com [2] https://lore.kernel.org/r/ae07144c-9295-4c9d-a400-153bb689fe9e@huawei.com Reported-by: Yonglong Liu Closes: https://lore.kernel.org/r/8743264a-9700-4227-a556-5f931c720211@huawei.com Fixes: ff7d6b27f894 ("page_pool: refurbish version of page_pool code") Suggested-by: Mina Almasry Reviewed-by: Mina Almasry Reviewed-by: Jesper Dangaard Brouer Tested-by: Jesper Dangaard Brouer Tested-by: Qiuling Ren Tested-by: Yuying Ma Tested-by: Yonglong Liu Acked-by: Jesper Dangaard Brouer Signed-off-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20250409-page-pool-track-dma-v9-2-6a9ef2e0cba8@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cfddb2467265e12e575359e35d1d7062d89b022b Author: Toke Høiland-Jørgensen Date: Wed Apr 9 12:41:36 2025 +0200 page_pool: Move pp_magic check into helper functions [ Upstream commit cd3c93167da0e760b5819246eae7a4ea30fd014b ] Since we are about to stash some more information into the pp_magic field, let's move the magic signature checks into a pair of helper functions so it can be changed in one place. Reviewed-by: Mina Almasry Tested-by: Yonglong Liu Acked-by: Jesper Dangaard Brouer Reviewed-by: Ilias Apalodimas Signed-off-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20250409-page-pool-track-dma-v9-1-6a9ef2e0cba8@redhat.com Signed-off-by: Jakub Kicinski Stable-dep-of: ee62ce7a1d90 ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool") Signed-off-by: Sasha Levin commit ccc28c0397f75a3ec9539cceed9db014d7b73869 Author: Chao Yu Date: Tue Apr 8 20:22:08 2025 +0800 f2fs: fix to do sanity check on sbi->total_valid_block_count [ Upstream commit 05872a167c2cab80ef186ef23cc34a6776a1a30c ] syzbot reported a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/f2fs.h:2521! RIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521 Call Trace: f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695 truncate_dnode+0x417/0x740 fs/f2fs/node.c:973 truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014 f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197 f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888 f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112 notify_change+0xbca/0xe90 fs/attr.c:552 do_truncate+0x222/0x310 fs/open.c:65 handle_truncate fs/namei.c:3466 [inline] do_open fs/namei.c:3849 [inline] path_openat+0x2e4f/0x35d0 fs/namei.c:4004 do_filp_open+0x284/0x4e0 fs/namei.c:4031 do_sys_openat2+0x12b/0x1d0 fs/open.c:1429 do_sys_open fs/open.c:1444 [inline] __do_sys_creat fs/open.c:1522 [inline] __se_sys_creat fs/open.c:1516 [inline] __x64_sys_creat+0x124/0x170 fs/open.c:1516 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94 The reason is: in fuzzed image, sbi->total_valid_block_count is inconsistent w/ mapped blocks indexed by inode, so, we should not trigger panic for such case, instead, let's print log and set fsck flag. Fixes: 39a53e0ce0df ("f2fs: add superblock and major in-memory structure") Reported-by: syzbot+8b376a77b2f364097fbe@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/67f3c0b2.050a0220.396535.0547.GAE@google.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit b282923c4ff411083cc048b3e742f9be05f1a3f5 Author: yohan.joung Date: Fri Apr 4 08:21:06 2025 +0900 f2fs: prevent the current section from being selected as a victim during GC [ Upstream commit d26fecb03e1f1069480d41fa2a6cea87ebbb89b8 ] When selecting a victim using next_victim_seg in a large section, the selected section might already have been cleared and designated as the new current section, making it actively in use. This behavior causes inconsistency between the SIT and SSA. F2FS-fs (dm-54): Inconsistent segment (70961) type [0, 1] in SSA and SIT Call trace: dump_backtrace+0xe8/0x10c show_stack+0x18/0x28 dump_stack_lvl+0x50/0x6c dump_stack+0x18/0x28 f2fs_stop_checkpoint+0x1c/0x3c do_garbage_collect+0x41c/0x271c f2fs_gc+0x27c/0x828 gc_thread_func+0x290/0x88c kthread+0x11c/0x164 ret_from_fork+0x10/0x20 issue scenario segs_per_sec=2 - seg#0 and seg#1 are all dirty - all valid blocks are removed in seg#1 - gc select this sec and next_victim_seg=seg#0 - migrate seg#0, next_victim_seg=seg#1 - checkpoint -> sec(seg#0, seg#1) becomes free - allocator assigns sec(seg#0, seg#1) to curseg - gc tries to migrate seg#1 Fixes: e3080b0120a1 ("f2fs: support subsectional garbage collection") Signed-off-by: yohan.joung Signed-off-by: Chao Yu Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 75d98902f353a50ad7691e80e0f5e93baa5b9c72 Author: Jaegeuk Kim Date: Fri Apr 4 19:03:03 2025 +0000 f2fs: clean up unnecessary indentation [ Upstream commit 05d3273ad03fa5ea1177b4f3dfeeb6de4899b504 ] No functional change. Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Stable-dep-of: d26fecb03e1f ("f2fs: prevent the current section from being selected as a victim during GC") Signed-off-by: Sasha Levin commit a16866506a9d2e35b593c9862ae207f08199f6a4 Author: Aditya Kumar Singh Date: Tue Apr 8 11:36:32 2025 +0530 wifi: ath12k: fix ATH12K_FLAG_REGISTERED flag handling [ Upstream commit 6af396942bf132a1a49523e8fe2f816dc1ebd913 ] Commit a5686ae820fa ("wifi: ath12k: move ATH12K_FLAG_REGISTERED handling to ath12k_mac_register()") relocated the setting of the ATH12K_FLAG_REGISTERED flag to the ath12k_mac_register() function. However, this function only accesses the first device (ab) via ag->ab[0], resulting in the flag being set only for the first device in the group. Similarly, ath12k_mac_unregister() only unsets the flag for the first device. The flag should actually be set for all devices in the group to avoid issues during recovery. Hence, move setting and clearing of this flag in the function ath12k_core_hw_group_start() and ath12k_core_hw_group_stop() respectively. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: a5686ae820fa ("wifi: ath12k: move ATH12K_FLAG_REGISTERED handling to ath12k_mac_register()") Signed-off-by: Aditya Kumar Singh Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-4-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 497ac4b33b968798fdbae410f88c3382f3cd8a0a Author: Aditya Kumar Singh Date: Tue Apr 8 11:36:29 2025 +0530 wifi: ath12k: fix SLUB BUG - Object already free in ath12k_reg_free() [ Upstream commit 6d019abc402f58b25a7cab30b2d9af2f3173e4df ] During rmmod of ath12k module with SLUB debug enabled, following print is seen - ============================================================================= BUG kmalloc-1k (Not tainted): Object already free ----------------------------------------------------------------------------- Allocated in ath12k_reg_build_regd+0x94/0xa20 [ath12k] age=10470 cpu=0 pid=0 __kmalloc_noprof+0xf4/0x368 ath12k_reg_build_regd+0x94/0xa20 [ath12k] ath12k_wmi_op_rx+0x199c/0x2c14 [ath12k] ath12k_htc_rx_completion_handler+0x398/0x554 [ath12k] ath12k_ce_per_engine_service+0x248/0x368 [ath12k] ath12k_pci_ce_workqueue+0x28/0x50 [ath12k] process_one_work+0x14c/0x28c bh_worker+0x22c/0x27c workqueue_softirq_action+0x80/0x90 tasklet_action+0x14/0x3c handle_softirqs+0x108/0x240 __do_softirq+0x14/0x20 Freed in ath12k_reg_free+0x40/0x74 [ath12k] age=136 cpu=2 pid=166 kfree+0x148/0x248 ath12k_reg_free+0x40/0x74 [ath12k] ath12k_core_hw_group_destroy+0x68/0xac [ath12k] ath12k_core_deinit+0xd8/0x124 [ath12k] ath12k_pci_remove+0x6c/0x130 [ath12k] pci_device_remove+0x44/0xe8 device_remove+0x4c/0x80 device_release_driver_internal+0x1d0/0x22c driver_detach+0x50/0x98 bus_remove_driver+0x70/0xf4 driver_unregister+0x30/0x60 pci_unregister_driver+0x24/0x9c ath12k_pci_exit+0x18/0x24 [ath12k] __arm64_sys_delete_module+0x1a0/0x2a8 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 Slab 0xfffffdffc0033600 objects=10 used=6 fp=0xffff000000cdcc00 flags=0x3fffe0000000240(workingset|head|node=0|zone=0|lastcpupid=0x1ffff) Object 0xffff000000cdcc00 @offset=19456 fp=0xffff000000cde400 [...] This issue arises because in ath12k_core_hw_group_destroy(), each device calls ath12k_core_soc_destroy() for itself and all its partners within the same group. Since ath12k_core_hw_group_destroy() is invoked for each device, this results in a double free condition, eventually causing the SLUB bug. To resolve this, set the freed pointers to NULL. And since there could be a race condition to read these pointers, guard these with the available mutex lock. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 6f245ea0ec6c ("wifi: ath12k: introduce device group abstraction") Signed-off-by: Aditya Kumar Singh Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-1-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 8c4a200d03574bfcbf54fdb7ba5968b58ad2e0b3 Author: Dan Carpenter Date: Wed Apr 9 14:01:25 2025 +0300 wifi: ath12k: Fix buffer overflow in debugfs [ Upstream commit 8c7a5031a6b0d42e640fbd2d5d05f61f74e32dce ] If the user tries to write more than 32 bytes then it results in memory corruption. Fortunately, this is debugfs so it's limited to root users. Fixes: 3f73c24f28b3 ("wifi: ath12k: Add support to enable debugfs_htt_stats") Signed-off-by: Dan Carpenter Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/35daefbd-d493-41d9-b192-96177d521b40@stanley.mountain Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 53c6682da17969b8bed4c1954480362e3800d25b Author: Ramya Gnanasekar Date: Wed Apr 9 20:53:41 2025 +0530 wifi: ath12k: Fix WMI tag for EHT rate in peer assoc [ Upstream commit 1a0e65750b55d2cf5de4a9bf7d6d55718784bdb7 ] Incorrect WMI tag is used for EHT rate update from host to firmware while encoding peer assoc WMI. Correct the WMI tag used for EHT rate update from WMI_TAG_HE_RATE_SET to the proper tag. This ensures firmware does not mistakenly update HE rate during parsing. Found during code review. Compile tested only. Fixes: 5b70ec6036c1 ("wifi: ath12k: add WMI support for EHT peer") Signed-off-by: Ramya Gnanasekar Link: https://patch.msgid.link/20250409152341.944628-1-ramya.gnanasekar@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 43995b028c1c327041ef22ad7e0837cb2c23aecf Author: Aaradhana Sahu Date: Thu Apr 3 13:52:06 2025 +0530 wifi: ath12k: Resolve multicast packet drop by populating key_cipher in ath12k_install_key() [ Upstream commit d61c0b3c63462d17e63e5a2b4815e0f1ad17f57e ] Currently, the key_cipher in the ath12k_vif structure, which represents the group cipher of the MLD AP, is populated when the link address matches the ieee80211_vif address within ath12k_install_key(). However, in MLD AP, the link address and ieee80211_vif address can differ. Due to this key_cipher is not populated and multicast packets don't get the correct cipher information and resulting multicast packets drop. To fix this, compare the link address with the arvif->bssid instead of the ieee80211_vif address. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Fixes: 3dd2c68f206ef ("wifi: ath12k: prepare vif data structure for MLO handling") Signed-off-by: Aaradhana Sahu Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250403082207.3323938-2-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit f44bcf5204af1632275cf57050691fd24c676f49 Author: Raj Kumar Bhagat Date: Thu Apr 3 15:34:29 2025 +0530 wifi: ath12k: fix cleanup path after mhi init [ Upstream commit 6177c97fb6f05bf0473a2806e3bece7e77693209 ] Currently, the 'err_pci_msi_free' label is misplaced, causing the cleanup sequence to be incorrect. Fix this by moving the 'err_pci_msi_free' label to the correct position after 'err_irq_affinity_cleanup'. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Fixes: a3012f206d07 ("wifi: ath12k: set IRQ affinity to CPU0 in case of one MSI vector") Signed-off-by: Raj Kumar Bhagat Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250403-ath12k-cleanup-v1-1-ad8f67b0e9cf@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit b9c9f16a00bf956d6cc4908f6c4f4fbaee0beb6b Author: Christian Marangi Date: Thu Apr 10 12:04:03 2025 +0200 net: phy: mediatek: permit to compile test GE SOC PHY driver [ Upstream commit e5566162af8b9690e096d2e6089e4ed955a0d13d ] When commit 462a3daad679 ("net: phy: mediatek: fix compile-test dependencies") fixed the dependency, it should have also introduced an or on COMPILE_TEST to permit this driver to be compile-tested even if NVMEM_MTK_EFUSE wasn't selected. The driver makes use of NVMEM API that are always compiled (return error) so the driver can actually be compiled even without that config. Fix and simplify the dependency condition of this kernel config. Fixes: 462a3daad679 ("net: phy: mediatek: fix compile-test dependencies") Acked-by: Daniel Golle Reviewed-by: Andrew Lunn Signed-off-by: Christian Marangi Acked-by: Arnd Bergmann Link: https://patch.msgid.link/20250410100410.348-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8d9431b0d11a5030aa1ce477defee455b3821701 Author: Chao Yu Date: Tue Mar 25 16:06:46 2025 +0800 f2fs: zone: fix to avoid inconsistence in between SIT and SSA [ Upstream commit 773704c1ef96a8b70d0d186ab725f50548de82c4 ] w/ below testcase, it will cause inconsistence in between SIT and SSA. create_null_blk 512 2 1024 1024 mkfs.f2fs -m /dev/nullb0 mount /dev/nullb0 /mnt/f2fs/ touch /mnt/f2fs/file f2fs_io pinfile set /mnt/f2fs/file fallocate -l 4GiB /mnt/f2fs/file F2FS-fs (nullb0): Inconsistent segment (0) type [1, 0] in SSA and SIT CPU: 5 UID: 0 PID: 2398 Comm: fallocate Tainted: G O 6.13.0-rc1 #84 Tainted: [O]=OOT_MODULE Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 Call Trace: dump_stack_lvl+0xb3/0xd0 dump_stack+0x14/0x20 f2fs_handle_critical_error+0x18c/0x220 [f2fs] f2fs_stop_checkpoint+0x38/0x50 [f2fs] do_garbage_collect+0x674/0x6e0 [f2fs] f2fs_gc_range+0x12b/0x230 [f2fs] f2fs_allocate_pinning_section+0x5c/0x150 [f2fs] f2fs_expand_inode_data+0x1cc/0x3c0 [f2fs] f2fs_fallocate+0x3c3/0x410 [f2fs] vfs_fallocate+0x15f/0x4b0 __x64_sys_fallocate+0x4a/0x80 x64_sys_call+0x15e8/0x1b80 do_syscall_64+0x68/0x130 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f9dba5197ca F2FS-fs (nullb0): Stopped filesystem due to reason: 4 The reason is f2fs_gc_range() may try to migrate block in curseg, however, its SSA block is not uptodate due to the last summary block data is still in cache of curseg. In this patch, we add a condition in f2fs_gc_range() to check whether section is opened or not, and skip block migration for opened section. Fixes: 9703d69d9d15 ("f2fs: support file pinning for zoned devices") Reviewed-by: Daeho Jeong Cc: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit e9c1299d813fc04668042690f2c3cc76d013959a Author: Jiayuan Chen Date: Mon Apr 7 22:21:22 2025 +0800 bpf, sockmap: Fix panic when calling skb_linearize [ Upstream commit 5ca2e29f6834c64c0e5a9ccf1278c21fb49b827e ] The panic can be reproduced by executing the command: ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000 Then a kernel panic was captured: ''' [ 657.460555] kernel BUG at net/core/skbuff.c:2178! [ 657.462680] Tainted: [W]=WARN [ 657.463287] Workqueue: events sk_psock_backlog ... [ 657.469610] [ 657.469738] ? die+0x36/0x90 [ 657.469916] ? do_trap+0x1d0/0x270 [ 657.470118] ? pskb_expand_head+0x612/0xf40 [ 657.470376] ? pskb_expand_head+0x612/0xf40 [ 657.470620] ? do_error_trap+0xa3/0x170 [ 657.470846] ? pskb_expand_head+0x612/0xf40 [ 657.471092] ? handle_invalid_op+0x2c/0x40 [ 657.471335] ? pskb_expand_head+0x612/0xf40 [ 657.471579] ? exc_invalid_op+0x2d/0x40 [ 657.471805] ? asm_exc_invalid_op+0x1a/0x20 [ 657.472052] ? pskb_expand_head+0xd1/0xf40 [ 657.472292] ? pskb_expand_head+0x612/0xf40 [ 657.472540] ? lock_acquire+0x18f/0x4e0 [ 657.472766] ? find_held_lock+0x2d/0x110 [ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10 [ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470 [ 657.473537] ? __pfx___lock_release.isra.0+0x10/0x10 [ 657.473826] __pskb_pull_tail+0xfd/0x1d20 [ 657.474062] ? __kasan_slab_alloc+0x4e/0x90 [ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510 [ 657.475392] ? __kasan_kmalloc+0xaa/0xb0 [ 657.476010] sk_psock_backlog+0x5cf/0xd70 [ 657.476637] process_one_work+0x858/0x1a20 ''' The panic originates from the assertion BUG_ON(skb_shared(skb)) in skb_linearize(). A previous commit(see Fixes tag) introduced skb_get() to avoid race conditions between skb operations in the backlog and skb release in the recvmsg path. However, this caused the panic to always occur when skb_linearize is executed. The "--rx-strp 100000" parameter forces the RX path to use the strparser module which aggregates data until it reaches 100KB before calling sockmap logic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize. To fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue. ''' sk_psock_backlog: sk_psock_handle_skb skb_get(skb) <== we move it into 'sk_psock_skb_ingress_enqueue' sk_psock_skb_ingress____________ ↓ | | → sk_psock_skb_ingress_self | sk_psock_skb_ingress_enqueue sk_psock_verdict_apply_________________↑ skb_linearize ''' Note that for verdict_apply path, the skb_get operation is unnecessary so we add 'take_ref' param to control it's behavior. Fixes: a454d84ee20b ("bpf, sockmap: Fix skb refcnt race after locking changes") Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20250407142234.47591-4-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit f585747905c0ae8d02bf63932fa95daa19c44a64 Author: Jiayuan Chen Date: Mon Apr 7 22:21:21 2025 +0800 bpf, sockmap: fix duplicated data transmission [ Upstream commit 3b4f14b794287be137ea2c6158765d1ea1e018a4 ] In the !ingress path under sk_psock_handle_skb(), when sending data to the remote under snd_buf limitations, partial skb data might be transmitted. Although we preserved the partial transmission state (offset/length), the state wasn't properly consumed during retries. This caused the retry path to resend the entire skb data instead of continuing from the previous offset, resulting in data overlap at the receiver side. Fixes: 405df89dd52c ("bpf, sockmap: Improved check for empty queue") Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20250407142234.47591-3-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 603943f022a7fe5cc83ca7005faf34798fb7853f Author: Jiayuan Chen Date: Wed Feb 19 13:20:14 2025 +0800 bpf: fix ktls panic with sockmap [ Upstream commit 54a3ecaeeeae8176da8badbd7d72af1017032c39 ] [ 2172.936997] ------------[ cut here ]------------ [ 2172.936999] kernel BUG at lib/iov_iter.c:629! ...... [ 2172.944996] PKRU: 55555554 [ 2172.945155] Call Trace: [ 2172.945299] [ 2172.945428] ? die+0x36/0x90 [ 2172.945601] ? do_trap+0xdd/0x100 [ 2172.945795] ? iov_iter_revert+0x178/0x180 [ 2172.946031] ? iov_iter_revert+0x178/0x180 [ 2172.946267] ? do_error_trap+0x7d/0x110 [ 2172.946499] ? iov_iter_revert+0x178/0x180 [ 2172.946736] ? exc_invalid_op+0x50/0x70 [ 2172.946961] ? iov_iter_revert+0x178/0x180 [ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20 [ 2172.947446] ? iov_iter_revert+0x178/0x180 [ 2172.947683] ? iov_iter_revert+0x5c/0x180 [ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840 [ 2172.948206] tls_sw_sendmsg+0x52/0x80 [ 2172.948420] ? inet_sendmsg+0x1f/0x70 [ 2172.948634] __sys_sendto+0x1cd/0x200 [ 2172.948848] ? find_held_lock+0x2b/0x80 [ 2172.949072] ? syscall_trace_enter+0x140/0x270 [ 2172.949330] ? __lock_release.isra.0+0x5e/0x170 [ 2172.949595] ? find_held_lock+0x2b/0x80 [ 2172.949817] ? syscall_trace_enter+0x140/0x270 [ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190 [ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0 [ 2172.951036] __x64_sys_sendto+0x24/0x30 [ 2172.951382] do_syscall_64+0x90/0x170 ...... After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase, e.g., when the BPF program executes bpf_msg_push_data(). If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes, it will return -ENOSPC and attempt to roll back to the non-zero copy logic. However, during rollback, msg->msg_iter is reset, but since msg_pl->sg.size has been increased, subsequent executions will exceed the actual size of msg_iter. ''' iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size); ''' The changes in this commit are based on the following considerations: 1. When cork_bytes is set, rolling back to non-zero copy logic is pointless and can directly go to zero-copy logic. 2. We can not calculate the correct number of bytes to revert msg_iter. Assume the original data is "abcdefgh" (8 bytes), and after 3 pushes by the BPF program, it becomes 11-byte data: "abc?de?fgh?". Then, we set cork_bytes to 6, which means the first 6 bytes have been processed, and the remaining 5 bytes "?fgh?" will be cached until the length meets the cork_bytes requirement. However, some data in "?fgh?" is not within 'sg->msg_iter' (but in msg_pl instead), especially the data "?" we pushed. So it doesn't seem as simple as just reverting through an offset of msg_iter. 3. For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs, the user-space send() doesn't return an error, and the returned length is the same as the input length parameter, even if some data is cached. Additionally, I saw that the current non-zero-copy logic for handling corking is written as: ''' line 1177 else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end; ''' So it's ok to just return 'copied' without error when a "cork" situation occurs. Fixes: fcb14cb1bdac ("new iov_iter flavour - ITER_UBUF") Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Signed-off-by: Jiayuan Chen Acked-by: John Fastabend Link: https://lore.kernel.org/r/20250219052015.274405-2-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 0bab1415fcb6c0aa1032cbc7ee1d3fb140998f05 Author: Saket Kumar Bhaskar Date: Wed Apr 9 15:26:33 2025 +0530 selftests/bpf: Fix bpf_nf selftest failure [ Upstream commit 967e8def1100cb4b08c28a54d27ce69563fdf281 ] For systems with missing iptables-legacy tool this selftest fails. Add check to find if iptables-legacy tool is available and skip the test if the tool is missing. Fixes: de9c8d848d90 ("selftests/bpf: S/iptables/iptables-legacy/ in the bpf_nf and xdp_synproxy test") Signed-off-by: Saket Kumar Bhaskar Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250409095633.33653-1-skb99@linux.ibm.com Signed-off-by: Sasha Levin commit 2e4a42b33ac6be8deb9e9dccf75d1a2f53959ca1 Author: Tao Chen Date: Mon Apr 7 11:57:52 2025 +0800 bpf: Check link_create.flags parameter for multi_uprobe [ Upstream commit a76116f422c442ab691b4dcabb25613486d34360 ] The link_create.flags are currently not used for multi-uprobes, so return -EINVAL if it is set, same as for other attach APIs. We allow target_fd to have an arbitrary value for multi-uprobe, though, as there are existing users (libbpf) relying on this. Fixes: 89ae89f53d20 ("bpf: Add multi uprobe link") Signed-off-by: Tao Chen Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250407035752.1108927-2-chen.dylane@linux.dev Signed-off-by: Sasha Levin commit 4966cd0c097d182d130aaa508be2209a32db247f Author: Tao Chen Date: Mon Apr 7 11:57:51 2025 +0800 bpf: Check link_create.flags parameter for multi_kprobe [ Upstream commit 243911982aa9faf4361aa952f879331ad66933fe ] The link_create.flags are currently not used for multi-kprobes, so return -EINVAL if it is set, same as for other attach APIs. We allow target_fd, on the other hand, to have an arbitrary value for multi-kprobe, as there are existing users (libbpf) relying on this. Fixes: 0dcac2725406 ("bpf: Add multi kprobe link") Signed-off-by: Tao Chen Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250407035752.1108927-1-chen.dylane@linux.dev Signed-off-by: Sasha Levin commit 857b240047628ade6cf24cd28813a7b86bc52d9c Author: Jacob Moroni Date: Thu Feb 20 17:56:12 2025 +0000 IB/cm: use rwlock for MAD agent lock [ Upstream commit 4dab26bed543584577b64b36aadb8b5b165bf44f ] In workloads where there are many processes establishing connections using RDMA CM in parallel (large scale MPI), there can be heavy contention for mad_agent_lock in cm_alloc_msg. This contention can occur while inside of a spin_lock_irq region, leading to interrupts being disabled for extended durations on many cores. Furthermore, it leads to the serialization of rdma_create_ah calls, which has negative performance impacts for NICs which are capable of processing multiple address handle creations in parallel. The end result is the machine becoming unresponsive, hung task warnings, netdev TX timeouts, etc. Since the lock appears to be only for protection from cm_remove_one, it can be changed to a rwlock to resolve these issues. Reproducer: Server: for i in $(seq 1 512); do ucmatose -c 32 -p $((i + 5000)) & done Client: for i in $(seq 1 512); do ucmatose -c 32 -p $((i + 5000)) -s 10.2.0.52 & done Fixes: 76039ac9095f ("IB/cm: Protect cm_dev, cm_ports and mad_agent with kref and lock") Link: https://patch.msgid.link/r/20250220175612.2763122-1-jmoroni@google.com Signed-off-by: Jacob Moroni Acked-by: Eric Dumazet Reviewed-by: Zhu Yanjun Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit cd29608db6c1a6ddb75c2069d00f5caba5e5aa2b Author: P Praneesh Date: Wed Apr 2 23:35:43 2025 +0530 wifi: ath12k: Fix invalid memory access while forming 802.11 header [ Upstream commit be908d2360341f8bbc982fff5a5e4f8030c17f74 ] While forming the 802.11 header from the rx descriptor, skb_push() is performed for the 802.11 header length and then calls ath12k_dp_rx_desc_get_dot11_hdr(). Since skb_push() moves the skb->data pointer backwards by the 802.11 header length, the rx descriptor points to a different memory area than intended, causing invalid information to be fetched from the rx descriptor. Also, when IV and ICV are not stripped from the given MSDU, mac80211 performs PN validation for these MSDUs, which requires the crypto header. Before forming the crypto header from the given rx descriptor, skb_push() is performed for the crypto header length, which overwrites the memory pointed to by the rx descriptor, causing invalid information to form the 802.11 header. Fix these issues by moving all rx descriptor accesses before the skb_push() operation which ensures the proper 802.11 headers are generated from the given rx descriptor and removing ath12k_dp_rxdesc_get_mpdu_frame_ctrl() for filling frame control, as this information is already fetched by ath12k_dp_rx_desc_get_dot11_hdr(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Co-developed-by: Karthikeyan Periyasamy Signed-off-by: Karthikeyan Periyasamy Signed-off-by: P Praneesh Link: https://patch.msgid.link/20250402180543.2670947-1-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit f7758cce853fcad005f433009b2d0efba3e7dfe2 Author: P Praneesh Date: Wed Apr 2 23:27:14 2025 +0530 wifi: ath12k: Fix memory corruption during MLO multicast tx [ Upstream commit 6f8a27a584b23e9dedefd6cb110dd2587b84a6d4 ] The struct sk_buff's control buffer is shared by mac80211's struct ieee80211_tx_info and ath12k's struct ath12k_skb_cb. When the driver wants to transmit an skb, it caches all the mac80211-specific information from struct ieee80211_tx_info, then performs a memset on the control buffer before writing the ath12k-specific information using struct ath12k_skb_cb. However, during multicast tx, the key is being filled into the driver data, which overwrites some crucial members like link_id and flags in struct ath12k_skb_cb. This causes invalid information retrieval when the driver accesses these fields during ath12k_dp_tx(). Fix this issue by removing the key filling logic during MLO multicast tx, as it is not used anywhere in the tx path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 2f50de725677 ("wifi: ath12k: Add support for MLO Multicast handling in driver") Signed-off-by: P Praneesh Link: https://patch.msgid.link/20250402175714.2667270-1-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit b47b5236599aad43a488f82b3aeb369f1084dfe4 Author: P Praneesh Date: Wed Apr 2 23:10:32 2025 +0530 wifi: ath12k: Fix memory leak during vdev_id mismatch [ Upstream commit 75ec94db880b1e4b4f9182885d60db0db6e2ee56 ] Currently driver enables vdev_id check as part of the bank configuration in ath12k_dp_tx_get_vdev_bank_config(). This check ensures that the vdev_id configured in the bank register aligns with the vdev_id in the packet's address search table within the firmware. If there is a mismatch, the firmware forwards the packet with the HTT status HAL_WBM_REL_HTT_TX_COMP_STATUS_VDEVID_MISMATCH. Since driver does not handle this vdev_id mismatch HTT status, the corresponding buffers are not freed properly, causing a memory leak. Fix this issue by adding handling to free the buffers when a vdev_id mismatch HTT status is encountered. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ- Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: P Praneesh Link: https://patch.msgid.link/20250402174032.2651221-1-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 94c2cccad82b870b87a6c9735cc85a4f1818706a Author: Carlos Llamas Date: Sun Mar 30 21:13:23 2025 +0000 libbpf: Fix implicit memfd_create() for bionic [ Upstream commit 75011ad69bc54396703867b5434f1622343a848e ] Since memfd_create() is not consistently available across different bionic libc implementations, using memfd_create() directly can break some Android builds: tools/lib/bpf/linker.c:576:7: error: implicit declaration of function 'memfd_create' [-Werror,-Wimplicit-function-declaration] 576 | fd = memfd_create(filename, 0); | ^ To fix this, relocate and inline the sys_memfd_create() helper so that it can be used in "linker.c". Similar issues were previously fixed by commit 9fa5e1a180aa ("libbpf: Call memfd_create() syscall directly"). Fixes: 6d5e5e5d7ce1 ("libbpf: Extend linker API to support in-memory ELF files") Signed-off-by: Carlos Llamas Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250330211325.530677-1-cmllamas@google.com Signed-off-by: Sasha Levin commit 6d6cb27fe146061f2512e904618f5e005bb7bb6a Author: Stone Zhang Date: Thu Mar 20 13:31:45 2025 +0800 wifi: ath11k: fix node corruption in ar->arvifs list [ Upstream commit 31e98e277ae47f56632e4d663b1d4fd12ba33ea8 ] In current WLAN recovery code flow, ath11k_core_halt() only reinitializes the "arvifs" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head "arvifs", but the next of the list head "arvifs" no longer points to that list node. When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath11k_mac_op_remove_interface(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic. The fix is to remove and reinitialize all vif list nodes from the list head "arvifs" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath11k_mac_op_remove_interface() can execute normally. Call trace: __list_del_entry_valid_or_report+0xb8/0xd0 ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k] drv_remove_interface+0x48/0x194 [mac80211] ieee80211_do_stop+0x6e0/0x844 [mac80211] ieee80211_stop+0x44/0x17c [mac80211] __dev_close_many+0xac/0x150 __dev_change_flags+0x194/0x234 dev_change_flags+0x24/0x6c devinet_ioctl+0x3a0/0x670 inet_ioctl+0x200/0x248 sock_do_ioctl+0x60/0x118 sock_ioctl+0x274/0x35c __arm64_sys_ioctl+0xac/0xf0 invoke_syscall+0x48/0x114 ... Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Stone Zhang Link: https://patch.msgid.link/20250320053145.3445187-1-quic_stonez@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 3f919f76893069ec3c7475acaeb611eb31fca22d Author: Karthikeyan Periyasamy Date: Mon Mar 24 11:55:15 2025 +0530 wifi: ath12k: fix NULL access in assign channel context handler [ Upstream commit ea24531d00f782f4e659e8c74578b7ac144720ca ] Currently, when ath12k_mac_assign_vif_to_vdev() fails, the radio handle (ar) gets accessed from the link VIF handle (arvif) for debug logging, This is incorrect. In the fail scenario, radio handle is NULL. Fix the NULL access, avoid radio handle access by moving to the hardware debug logging helper function (ath12k_hw_warn). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 90570ba4610b ("wifi: ath12k: do not return invalid link id for scan link") Reviewed-by: Vasanthakumar Thiagarajan Signed-off-by: Karthikeyan Periyasamy Link: https://patch.msgid.link/20250324062518.2752822-8-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 2d07a98c5f70c3b61abc86dfacdb86a0a78089fe Author: Jocelyn Falempe Date: Fri Apr 18 18:48:16 2025 +0200 drm/panic: Use a decimal fifo to avoid u64 by u64 divide [ Upstream commit 675008f196ca5c8d8413204e861cc2a2238581aa ] On 32bits ARM, u64/u64 is not supported [1], so change the algorithm to use a simple fifo with decimal digits as u8 instead. This is slower but should compile on all architecture. Link: https://lore.kernel.org/dri-devel/CANiq72ke45eOwckMhWHvmwxc03dxr4rnxxKvx+HvWdBLopZfrQ@mail.gmail.com/ [1] Reported-by: Miguel Ojeda Closes: https://lore.kernel.org/dri-devel/CANiq72ke45eOwckMhWHvmwxc03dxr4rnxxKvx+HvWdBLopZfrQ@mail.gmail.com/ Fixes: ccb8ce526807 ("ARM: 9441/1: rust: Enable Rust support for ARMv7") Signed-off-by: Jocelyn Falempe Link: https://lore.kernel.org/r/20250418165059.560503-1-jfalempe@redhat.com Acked-by: Javier Martinez Canillas Signed-off-by: Sasha Levin commit fc71fa9e080a445e5a26692740df2b63387ce96b Author: Miguel Ojeda Date: Mon Mar 3 10:32:42 2025 +0100 drm/panic: clean Clippy warning [ Upstream commit 57145afa3326947154c3a890b1118774b55212a0 ] Clippy warns: error: manual implementation of an assign operation --> drivers/gpu/drm/drm_panic_qr.rs:418:25 | 418 | self.carry = self.carry % pow; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: replace it with: `self.carry %= pow` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#assign_op_pattern Thus clean it up. Fixes: dbed4a797e00 ("drm/panic: Better binary encoding in QR code") Signed-off-by: Miguel Ojeda Reviewed-by: Alice Ryhl Reviewed-by: Jocelyn Falempe Signed-off-by: Jocelyn Falempe Link: https://patchwork.freedesktop.org/patch/msgid/20250303093242.1011790-1-ojeda@kernel.org Stable-dep-of: 675008f196ca ("drm/panic: Use a decimal fifo to avoid u64 by u64 divide") Signed-off-by: Sasha Levin commit 3f5d6a0317db61a7660575ea82f4c6f8571b2e46 Author: Aradhya Bhatia Date: Fri May 16 14:19:02 2025 +0000 drm/xe/guc: Make creation of SLPC debugfs files conditional [ Upstream commit e22d7acf9f47b01c9a538f3dac5c8e8d46fbca96 ] Platforms that do not support SLPC are exempted from the GuC PC support. The GuC PC does not get initialized, and neither do its BOs get created. This causes a problem because the GuC PC debugfs file is still being created. Whenever the file is attempted to read, it causes a NULL pointer dereference on the supposed BO of the GuC PC. So, make the creation of SLPC debugfs files conditional to when SLPC features are supported. Fixes: aaab5404b16f ("drm/xe: Introduce GuC PC debugfs") Suggested-by: Matt Roper Reviewed-by: Tejas Upadhyay Reviewed-by: Stuart Summers Signed-off-by: Aradhya Bhatia Link: https://lore.kernel.org/r/20250516141902.5614-1-aradhya.bhatia@intel.com Signed-off-by: Matt Roper (cherry picked from commit 17486cf3df5320752cc67ee8bcb2379d1b9de76c) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 1b9dc8d2525544b7a88d31a748878d71dc6f7288 Author: Michal Wajdeczko Date: Thu Apr 3 16:26:34 2025 +0200 drm/xe/guc: Don't expose GuC privileged debugfs files if VF [ Upstream commit 387444984d7b53dbaee263887cad4ea7c8e57b34 ] Some of the GuC debugfs files require access to the data that is not available on the VFs. Don't expose those files on the VF driver. Signed-off-by: Michal Wajdeczko Reviewed-by: Lucas De Marchi Link: https://lore.kernel.org/r/20250403142635.1821-3-michal.wajdeczko@intel.com Stable-dep-of: e22d7acf9f47 ("drm/xe/guc: Make creation of SLPC debugfs files conditional") Signed-off-by: Sasha Levin commit a2a03a255904746f0914ff1d46a2a2a06a6c452b Author: Michal Wajdeczko Date: Thu Apr 3 16:26:33 2025 +0200 drm/xe/guc: Refactor GuC debugfs initialization [ Upstream commit e15826bb3c2c5377eedc757f2adec8dcaa5255f7 ] We don't have to drmm_kmalloc() local copy of debugfs_list to write there our pointer to the struct xe_guc as we can extract pointer to the struct xe_gt from the grandparent debugfs entry, in similar way to what we did for GT debugfs files. Note that there is no change in file/directory structure, just refactored how files are created and how functions are called. Signed-off-by: Michal Wajdeczko Reviewed-by: Lucas De Marchi Link: https://lore.kernel.org/r/20250403142635.1821-2-michal.wajdeczko@intel.com Stable-dep-of: e22d7acf9f47 ("drm/xe/guc: Make creation of SLPC debugfs files conditional") Signed-off-by: Sasha Levin commit 420d4544f73c1ddbd0abaf4e22b9e380ceffb912 Author: Roger Pau Monne Date: Wed May 14 10:04:26 2025 +0200 xen/x86: fix initial memory balloon target [ Upstream commit 74287971dbb3fe322bb316afd9e7fb5807e23bee ] When adding extra memory regions as ballooned pages also adjust the balloon target, otherwise when the balloon driver is started it will populate memory to match the target value and consume all the extra memory regions added. This made the usage of the Xen `dom0_mem=,max:` command line parameter for dom0 not work as expected, as the target won't be adjusted and when the balloon is started it will populate memory straight to the 'max:' value. It would equally affect domUs that have memory != maxmem. Kernels built with CONFIG_XEN_UNPOPULATED_ALLOC are not affected, because the extra memory regions are consumed by the unpopulated allocation driver, and then balloon_add_regions() becomes a no-op. Reported-by: John Fixes: 87af633689ce ('x86/xen: fix balloon target initialization for PVH dom0') Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Tested-by: Marek Marczykowski-Górecki Message-ID: <20250514080427.28129-1-roger.pau@citrix.com> Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 9d394de375c37cf86d9e74139d342465876e4145 Author: Chuck Lever Date: Mon Apr 28 15:36:49 2025 -0400 svcrdma: Reduce the number of rdma_rw contexts per-QP [ Upstream commit 59243315890578a040a2d50ae9e001a2ef2fcb62 ] There is an upper bound on the number of rdma_rw contexts that can be created per QP. This invisible upper bound is because rdma_create_qp() adds one or more additional SQEs for each ctxt that the ULP requests via qp_attr.cap.max_rdma_ctxs. The QP's actual Send Queue length is on the order of the sum of qp_attr.cap.max_send_wr and a factor times qp_attr.cap.max_rdma_ctxs. The factor can be up to three, depending on whether MR operations are required before RDMA Reads. This limit is not visible to RDMA consumers via dev->attrs. When the limit is surpassed, QP creation fails with -ENOMEM. For example: svcrdma's estimate of the number of rdma_rw contexts it needs is three times the number of pages in RPCSVC_MAXPAGES. When MAXPAGES is about 260, the internally-computed SQ length should be: 64 credits + 10 backlog + 3 * (3 * 260) = 2414 Which is well below the advertised qp_max_wr of 32768. If RPCSVC_MAXPAGES is increased to 4MB, that's 1040 pages: 64 credits + 10 backlog + 3 * (3 * 1040) = 9434 However, QP creation fails. Dynamic printk for mlx5 shows: calc_sq_size:618:(pid 1514): send queue size (9326 * 256 / 64 -> 65536) exceeds limits(32768) Although 9326 is still far below qp_max_wr, QP creation still fails. Because the total SQ length calculation is opaque to RDMA consumers, there doesn't seem to be much that can be done about this except for consumers to try to keep the requested rdma_rw ctxt count low. Fixes: 2da0f610e733 ("svcrdma: Increase the per-transport rw_ctx count") Reviewed-by: NeilBrown Reviewed-by: Christoph Hellwig Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 87b6745c5c85ac4de083ab1756f86d12f31c7d14 Author: Detlev Casanova Date: Fri Apr 25 15:24:47 2025 -0400 media: verisilicon: Free post processor buffers on error [ Upstream commit 11beb0fc346e00c412b3bfd19013206f6b655604 ] During initialization, the post processor allocates the same number of buffers as the buf queue. As the init function is called in streamon(), if an allocation fails, streamon will return an error and streamoff() will not be called, keeping all post processor buffers allocated. To avoid that, all post proc buffers are freed in case of an allocation error. Fixes: 26711491a807 ("media: verisilicon: Refactor postprocessor to store more buffers") Signed-off-by: Detlev Casanova Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit dbc6aa697897f90b3db85526f19b94cca967bb1a Author: AngeloGioacchino Del Regno Date: Thu Apr 3 12:47:39 2025 +0200 drm/mediatek: mtk_drm_drv: Unbind secondary mmsys components on err [ Upstream commit 94c933716567084bfb9e79dcd81eb2b2308e84e1 ] When calling component_bind_all(), if a component that is included in the list fails, all of those that have been successfully bound will be unbound, but this driver has two components lists for two actual devices, as in, each mmsys instance has its own components list. In case mmsys0 (or actually vdosys0) is able to bind all of its components, but the secondary one fails, all of the components of the first are kept bound, while the ones of mmsys1/vdosys1 are correctly cleaned up. This is not right because, in case of a failure, the components are re-bound for all of the mmsys/vdosys instances without caring about the ones that were previously left in a bound state. Fix that by calling component_unbind_all() on all of the previous component masters that succeeded binding all subdevices when any of the other masters errors out. Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support") Reviewed-by: Chen-Yu Tsai Signed-off-by: AngeloGioacchino Del Regno Link: https://patchwork.kernel.org/project/dri-devel/patch/20250403104741.71045-4-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 4f52f695ca1a42cc39edba9d422b326ca642968e Author: AngeloGioacchino Del Regno Date: Thu Apr 3 12:47:38 2025 +0200 drm/mediatek: Fix kobject put for component sub-drivers [ Upstream commit 80805b62ea5b95eda54c225b989f929ca0691ab0 ] In function mtk_drm_get_all_drm_priv(), this driver is incrementing the refcount for the sub-drivers of mediatek-drm with a call to device_find_child() when taking a reference to all of those child devices. When the component bind fails multiple times this results in a refcount_t overflow, as the reference count is never decremented: fix that by adding a call to put_device() for all of the mmsys devices in a loop, in error cases of mtk_drm_bind() and in the mtk_drm_unbind() callback. Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support") Reviewed-by: Chen-Yu Tsai Signed-off-by: AngeloGioacchino Del Regno Link: https://patchwork.kernel.org/project/dri-devel/patch/20250403104741.71045-3-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit fa04e6f37ac9ceb6a018fbd719d596a8b3f74b94 Author: AngeloGioacchino Del Regno Date: Thu Apr 3 12:47:37 2025 +0200 drm/mediatek: mtk_drm_drv: Fix kobject put for mtk_mutex device ptr [ Upstream commit 22918591fb747a6d16801e74a170cf98e886f83b ] This driver is taking a kobject for mtk_mutex only once per mmsys device for each drm-mediatek driver instance, differently from the behavior with other components, but it is decrementing the kobj's refcount in a loop and once per mmsys: this is not right and will result in a refcount_t underflow warning when mediatek-drm returns multiple probe deferrals in one boot (or when manually bound and unbound). Besides that, the refcount for mutex_dev was not decremented for error cases in mtk_drm_bind(), causing another refcount_t warning but this time for overflow, when the failure happens not during driver bind but during component bind. In order to fix one of the reasons why this is happening, remove the put_device(xx->mutex_dev) loop from the mtk_drm_kms_init()'s put_mutex_dev label (and drop the label) and add a single call to correctly free the single incremented refcount of mutex_dev to the mtk_drm_unbind() function to fix the refcount_t underflow. Moreover, add the same call to the error cases in mtk_drm_bind() to fix the refcount_t overflow. Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support") Reviewed-by: Chen-Yu Tsai Signed-off-by: AngeloGioacchino Del Regno Link: https://patchwork.kernel.org/project/dri-devel/patch/20250403104741.71045-2-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 4881c5fc4ac2a76479ebe1f5625d3253e5de6841 Author: Imre Deak Date: Fri May 9 21:03:28 2025 +0300 drm/i915/dp_mst: Use the correct connector while computing the link BPP limit on MST [ Upstream commit a92e390e0d438e021de0e52065121484b6cca675 ] Atm, on an MST link in DSC mode intel_dp_compute_config_link_bpp_limits() calculates the maximum link bpp limit using the MST root connector's DSC capabilities. That's not correct in general: the decompression could be performed by a branch device downstream of the root branch device or the sink itself. Fix the above by passing to intel_dp_compute_config_link_bpp_limits() the actual connector being modeset, containing the correct DSC capabilities. Cc: Ankit Nautiyal Fixes: 1c5b72daff46 ("drm/i915/dp: Set the DSC link limits in intel_dp_compute_config_link_bpp_limits") Reviewed-by: Ankit Nautiyal Reviewed-by: Luca Coelho Signed-off-by: Imre Deak Link: https://lore.kernel.org/r/20250509180340.554867-2-imre.deak@intel.com (cherry picked from commit 266e2fcfe2ea0d062ea392cd22f6250ae0d11c04) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit 26c730d17564686329cbbd4caed6cfbe8a9f0156 Author: Aleksandrs Vinarskis Date: Thu May 8 00:59:01 2025 +0200 drm/msm/dp: Prepare for link training per-segment for LTTPRs [ Upstream commit 7513ccb8840b54e35579f3c2cce08c3443a6e2d4 ] Per-segment link training requires knowing the number of LTTPRs (if any) present. Store the count during LTTPRs' initialization. Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling") Reviewed-by: Abel Vesa Reviewed-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov Signed-off-by: Aleksandrs Vinarskis Tested-by: Jessica Zhang # SA8775P Tested-by: Johan Hovold Tested-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/652306/ Link: https://lore.kernel.org/r/20250507230113.14270-4-alex.vinarskis@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit f9b8d26214c1997d40b4eb4a0509770a0e0f9649 Author: Aleksandrs Vinarskis Date: Thu May 8 00:59:00 2025 +0200 drm/msm/dp: Account for LTTPRs capabilities [ Upstream commit c156fe2dd46774321c8eaaff9a6f04b64e6b9742 ] Take into account LTTPR capabilities when selecting maximum allowed link rate, number of data lines. Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling") Reviewed-by: Abel Vesa Reviewed-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov Signed-off-by: Aleksandrs Vinarskis Tested-by: Jessica Zhang # SA8775P Tested-by: Johan Hovold Tested-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/652302/ Link: https://lore.kernel.org/r/20250507230113.14270-3-alex.vinarskis@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit d657bc51fe4507c60a16835a579c1fd66b1c5ec7 Author: Aleksandrs Vinarskis Date: Thu May 8 00:58:59 2025 +0200 drm/msm/dp: Fix support of LTTPR initialization [ Upstream commit 9351d3d302060d114de2f0c648579c0aadbd8f72 ] Initialize LTTPR before msm_dp_panel_read_sink_caps, as DPTX shall (re)read DPRX caps after LTTPR detection, as required by DP 2.1a, Section 3.6.7.6.1. Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling") Reviewed-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov Signed-off-by: Aleksandrs Vinarskis Tested-by: Jessica Zhang # SA8775P Tested-by: Johan Hovold Tested-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/652301/ Link: https://lore.kernel.org/r/20250507230113.14270-2-alex.vinarskis@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 294167f862fc89899805a33e06ba5682f0c6eebb Author: Konrad Dybcio Date: Mon May 5 13:13:40 2025 +0200 drm/msm/a6xx: Disable rgb565_predicator on Adreno 7c3 [ Upstream commit 5a9c1bea011fb42088ba08ceaa252fb20e695626 ] This feature is supposed to be enabled with UBWC v4 or later. Implementations of this SKU feature an effective UBWC version of 3, so disable it, in line with the BSP kernel. Reported-by: Dmitry Baryshkov Reviewed-by: Akhil P Oommen Fixes: 192f4ee3e408 ("drm/msm/a6xx: Add support for Adreno 7c Gen 3 gpu") Signed-off-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/651759/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit f1d93b5584f50756078007679a5def4d8b44ee0c Author: Terry Tritton Date: Fri May 9 12:56:22 2025 +0100 selftests/seccomp: fix negative_ENOSYS tracer tests on arm32 [ Upstream commit 73989c998814d82c71d523c104c398925470d59e ] TRACE_syscall.ptrace.negative_ENOSYS and TRACE_syscall.seccomp.negative_ENOSYS on arm32 are being reported as failures instead of skipping. The teardown_trace_fixture function sets the test to KSFT_FAIL in case of a non 0 return value from the tracer process. Due to _metadata now being shared between the forked processes the tracer is returning the KSFT_SKIP value set by the tracee which is non 0. Remove the setting of the _metadata.exit_code in teardown_trace_fixture. Fixes: 24cf65a62266 ("selftests/harness: Share _metadata between forked processes") Signed-off-by: Terry Tritton Link: https://lore.kernel.org/r/20250509115622.64775-1-terry.tritton@linaro.org Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 6f5f53048d3b761d694430632d3a03977273e987 Author: Anand Moon Date: Mon Apr 7 12:02:03 2025 +0530 perf/amlogic: Replace smp_processor_id() with raw_smp_processor_id() in meson_ddr_pmu_create() [ Upstream commit 097469a2b0f12b91b4f27b9e9e4f2c46484cde30 ] The Amlogic DDR PMU driver meson_ddr_pmu_create() function incorrectly uses smp_processor_id(), which assumes disabled preemption. This leads to kernel warnings during module loading because meson_ddr_pmu_create() can be called in a preemptible context. Following kernel warning and stack trace: [ 31.745138] [ T2289] BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/2289 [ 31.745154] [ T2289] caller is debug_smp_processor_id+0x28/0x38 [ 31.745172] [ T2289] CPU: 4 UID: 0 PID: 2289 Comm: (udev-worker) Tainted: GW 6.14.0-0-MANJARO-ARM #1 59519addcbca6ba8de735e151fd7b9e97aac7ff0 [ 31.745181] [ T2289] Tainted: [W]=WARN [ 31.745183] [ T2289] Hardware name: Hardkernel ODROID-N2Plus (DT) [ 31.745188] [ T2289] Call trace: [ 31.745191] [ T2289] show_stack+0x28/0x40 (C) [ 31.745199] [ T2289] dump_stack_lvl+0x4c/0x198 [ 31.745205] [ T2289] dump_stack+0x20/0x50 [ 31.745209] [ T2289] check_preemption_disabled+0xec/0xf0 [ 31.745213] [ T2289] debug_smp_processor_id+0x28/0x38 [ 31.745216] [ T2289] meson_ddr_pmu_create+0x200/0x560 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745237] [ T2289] g12_ddr_pmu_probe+0x20/0x38 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745246] [ T2289] platform_probe+0x98/0xe0 [ 31.745254] [ T2289] really_probe+0x144/0x3f8 [ 31.745258] [ T2289] __driver_probe_device+0xb8/0x180 [ 31.745261] [ T2289] driver_probe_device+0x54/0x268 [ 31.745264] [ T2289] __driver_attach+0x11c/0x288 [ 31.745267] [ T2289] bus_for_each_dev+0xfc/0x160 [ 31.745274] [ T2289] driver_attach+0x34/0x50 [ 31.745277] [ T2289] bus_add_driver+0x160/0x2b0 [ 31.745281] [ T2289] driver_register+0x78/0x120 [ 31.745285] [ T2289] __platform_driver_register+0x30/0x48 [ 31.745288] [ T2289] init_module+0x30/0xfe0 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745298] [ T2289] do_one_initcall+0x11c/0x438 [ 31.745303] [ T2289] do_init_module+0x68/0x228 [ 31.745311] [ T2289] load_module+0x118c/0x13a8 [ 31.745315] [ T2289] __arm64_sys_finit_module+0x274/0x390 [ 31.745320] [ T2289] invoke_syscall+0x74/0x108 [ 31.745326] [ T2289] el0_svc_common+0x90/0xf8 [ 31.745330] [ T2289] do_el0_svc+0x2c/0x48 [ 31.745333] [ T2289] el0_svc+0x60/0x150 [ 31.745337] [ T2289] el0t_64_sync_handler+0x80/0x118 [ 31.745341] [ T2289] el0t_64_sync+0x1b8/0x1c0 Changes replaces smp_processor_id() with raw_smp_processor_id() to ensure safe CPU ID retrieval in preemptible contexts. Cc: Jiucheng Xu Fixes: 2016e2113d35 ("perf/amlogic: Add support for Amlogic meson G12 SoC DDR PMU driver") Signed-off-by: Anand Moon Link: https://lore.kernel.org/r/20250407063206.5211-1-linux.amoon@gmail.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 56c938959f14143979ca7987ee21e56c90c3350f Author: Nicolas Dufresne Date: Thu Apr 10 16:43:47 2025 -0400 media: synopsys: hdmirx: Count dropped frames [ Upstream commit 57c8d79adf05244b171964d1d6c7e6fabbe5f5fd ] The sequence number communicate the lost frames to userspace. For this reason, it must be incremented even when a frame is skipped. This allows userspace such as GStreamer to report the loss. Fixes: 7b59b132ad439 ("media: platform: synopsys: Add support for HDMI input driver") Signed-off-by: Nicolas Dufresne Reviewed-by: Dmitry Osipenko Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit faed83b30d5f15d8fa02fd674586eb11d88b9369 Author: Nicolas Dufresne Date: Thu Apr 10 16:43:46 2025 -0400 media: synopsys: hdmirx: Renamed frame_idx to sequence [ Upstream commit 0400bee67f49753b878c2576c02c1bc454f091ed ] This variable is used to fill the v4l2_buffer.sequence, let's name it the exact same way to reduce confusion. No functional changes. Fixes: 7b59b132ad439 ("media: platform: synopsys: Add support for HDMI input driver") Signed-off-by: Nicolas Dufresne Reviewed-by: Dmitry Osipenko Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 36d7e404fbbd934b25e4b21afb3c9198a750cd92 Author: Kees Cook Date: Fri May 2 15:41:57 2025 -0700 scsi: qedf: Use designated initializer for struct qed_fcoe_cb_ops [ Upstream commit d8720235d5b5cad86c1f07f65117ef2a96f8bec7 ] Recent fixes to the randstruct GCC plugin allowed it to notice that this structure is entirely function pointers and is therefore subject to randomization, but doing so requires that it always use designated initializers. Explicitly specify the "common" member as being initialized. Silences: drivers/scsi/qedf/qedf_main.c:702:9: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init] 702 | { | ^ Fixes: 035f7f87b729 ("randstruct: Enable Clang support") Link: https://lore.kernel.org/r/20250502224156.work.617-kees@kernel.org Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 1f523638b7ac3f03ea172bb14f702ab472b2062c Author: Gustavo A. R. Silva Date: Thu May 1 18:44:43 2025 -0600 overflow: Fix direct struct member initialization in _DEFINE_FLEX() [ Upstream commit 47e36ed7840661a9f7fb53554a1b04a5f8daffea ] Currently, to statically initialize the struct members of the `type` object created by _DEFINE_FLEX(), the internal `obj` member must be explicitly referenced at the call site. See: struct flex { int a; int b; struct foo flex_array[]; }; _DEFINE_FLEX(struct flex, instance, flex_array, FIXED_SIZE, = { .obj = { .a = 0, .b = 1, }, }); This leaks _DEFINE_FLEX() internal implementation details and make the helper harder to use and read. Fix this and allow for a more natural and intuitive C99 init-style: _DEFINE_FLEX(struct flex, instance, flex_array, FIXED_SIZE, = { .a = 0, .b = 1, }); Note that before these changes, the `initializer` argument was optional, but now it's required. Also, update "counter" member initialization in DEFINE_FLEX(). Fixes: 26dd68d293fd ("overflow: add DEFINE_FLEX() for on-stack allocs") Signed-off-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/aBQVeyKfLOkO9Yss@kspp Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 41a3ecfb0526416189cc6208b2b6525556af7118 Author: Mark Rutland Date: Thu May 8 14:26:41 2025 +0100 kselftest/arm64: fp-ptrace: Fix expected FPMR value when PSTATE.SM is changed [ Upstream commit 78b23877dbba7dbcda2b89383d17bed82ce8f663 ] The fp-ptrace test suite expects that FPMR is set to zero when PSTATE.SM is changed via ptrace, but ptrace has never altered FPMR in this way, and the test logic erroneously relies upon (and has concealed) a bug where task_fpsimd_load() would unexpectedly and non-deterministically clobber FPMR. Using ptrace, FPMR can only be altered by writing to the NT_ARM_FPMR regset. The value of PSTATE.SM can be altered by writing to the NT_ARM_SVE or NT_ARM_SSVE regsets, and/or by changing the SME vector length (when writing to the NT_ARM_SVE, NT_ARM_SSVE, or NT_ARM_ZA regsets), but none of these writes will change the value of FPMR. The task_fpsimd_load() bug was introduced with the initial FPMR support in commit: 203f2b95a882 ("arm64/fpsimd: Support FEAT_FPMR") The incorrect FPMR test code was introduced in commit: 7dbd26d0b22d ("kselftest/arm64: Add FPMR coverage to fp-ptrace") Subsequently, the task_fpsimd_load() bug was fixed in commit: e5fa85fce08b ("arm64/fpsimd: Don't corrupt FPMR when streaming mode changes") ... whereupon the fp-ptrace FPMR tests started failing reliably, e.g. | # # Mismatch in saved FPMR: 915058000 != 0 | # not ok 25 SVE write, SVE 64->64, SME 64/0->64/1 Fix this by changing the test to expect that FPMR is *NOT* changed when PSTATE.SM is changed via ptrace, matching the extant behaviour. I've chosen to update the test code rather than modifying ptrace to zero FPMR when PSTATE.SM changes. Not zeroing FPMR is simpler overall, and allows the NT_ARM_FPMR regset to be handled independently from other regsets, leaving less scope for error. Fixes: 7dbd26d0b22d ("kselftest/arm64: Add FPMR coverage to fp-ptrace") Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: David Spickett Cc: Luis Machado Cc: Marc Zyngier Cc: Mark Brown Cc: Will Deacon Link: https://lore.kernel.org/r/20250508132644.1395904-22-mark.rutland@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 894eafea66c32a0dff717793b2537387020e213b Author: Huang Yiwei Date: Wed May 7 12:57:57 2025 +0800 firmware: SDEI: Allow sdei initialization without ACPI_APEI_GHES [ Upstream commit 59529bbe642de4eb2191a541d9b4bae7eb73862e ] SDEI usually initialize with the ACPI table, but on platforms where ACPI is not used, the SDEI feature can still be used to handle specific firmware calls or other customized purposes. Therefore, it is not necessary for ARM_SDE_INTERFACE to depend on ACPI_APEI_GHES. In commit dc4e8c07e9e2 ("ACPI: APEI: explicit init of HEST and GHES in acpi_init()"), to make APEI ready earlier, sdei_init was moved into acpi_ghes_init instead of being a standalone initcall, adding ACPI_APEI_GHES dependency to ARM_SDE_INTERFACE. This restricts the flexibility and usability of SDEI. This patch corrects the dependency in Kconfig and splits sdei_init() into two separate functions: sdei_init() and acpi_sdei_init(). sdei_init() will be called by arch_initcall and will only initialize the platform driver, while acpi_sdei_init() will initialize the device from acpi_ghes_init() when ACPI is ready. This allows the initialization of SDEI without ACPI_APEI_GHES enabled. Fixes: dc4e8c07e9e2 ("ACPI: APEI: explicit init of HEST and GHES in apci_init()") Cc: Shuai Xue Signed-off-by: Huang Yiwei Reviewed-by: Shuai Xue Reviewed-by: Gavin Shan Acked-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20250507045757.2658795-1-quic_hyiwei@quicinc.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit d2323763148448510c32c1e43eb3843b4215ba43 Author: Harry Wentland Date: Mon Apr 28 16:26:20 2025 -0400 drm/amd/display: Don't check for NULL divisor in fixpt code [ Upstream commit d01ca8708d95a561f6462a15cad94a2c0bec7042 ] [Why] We check for a NULL divisor but don't act on it. This check does nothing other than throw a warning. It does confuse static checkers though: See https://lkml.org/lkml/2025/4/26/371 [How] Drop the ASSERTs in both DC and SPL variants. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Fixes: 6efc0ab3b05d ("drm/amd/display: add back quality EASF and ISHARP and dc dependency changes") Signed-off-by: Harry Wentland Cc: Linus Torvalds Cc: Leo Li Cc: Alex Deucher Acked-by: Alex Deucher Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d0e3476889c6a800c0d4504b16b795cd0508527a Author: Biju Das Date: Wed Feb 5 11:21:35 2025 +0000 drm/tegra: rgb: Fix the unbound reference count [ Upstream commit 3c3642335065c3bde0742b0edc505b6ea8fdc2b3 ] The of_get_child_by_name() increments the refcount in tegra_dc_rgb_probe, but the driver does not decrement the refcount during unbind. Fix the unbound reference count using devm_add_action_or_reset() helper. Fixes: d8f4a9eda006 ("drm: Add NVIDIA Tegra20 support") Signed-off-by: Biju Das Signed-off-by: Thierry Reding Link: https://lore.kernel.org/r/20250205112137.36055-1-biju.das.jz@bp.renesas.com Signed-off-by: Sasha Levin commit 89eb6c953f116a62d21780e07985c9ebe055947c Author: Kees Cook Date: Fri Apr 25 23:14:32 2025 -0700 drm/vkms: Adjust vkms_state->active_planes allocation type [ Upstream commit 258aebf100540d36aba910f545d4d5ddf4ecaf0b ] In preparation for making the kmalloc family of allocators type aware, we need to make sure that the returned type from the allocation matches the type of the variable being assigned. (Before, the allocator would always return "void *", which can be implicitly cast to any pointer type.) The assigned type is "struct vkms_plane_state **", but the returned type will be "struct drm_plane **". These are the same size (pointer size), but the types don't match. Adjust the allocation type to match the assignment. Signed-off-by: Kees Cook Reviewed-by: Louis Chauvet Fixes: 8b1865873651 ("drm/vkms: totally reworked crc data tracking") Link: https://lore.kernel.org/r/20250426061431.work.304-kees@kernel.org Signed-off-by: Louis Chauvet Signed-off-by: Sasha Levin commit bdfcaa2de6ebb94ef04a0db6c630f929546a1ca7 Author: Biju Das Date: Thu Nov 16 12:24:24 2023 +0000 drm: rcar-du: Fix memory leak in rcar_du_vsps_init() [ Upstream commit 91e3bf09a90bb4340c0c3c51396e7531555efda4 ] The rcar_du_vsps_init() doesn't free the np allocated by of_parse_phandle_with_fixed_args() for the non-error case. Fix memory leak for the non-error case. While at it, replace the label 'error'->'done' as it applies to non-error case as well and update the error check condition for rcar_du_vsp_init() to avoid breakage in future, if it returns positive value. Fixes: 3e81374e2014 ("drm: rcar-du: Support multiple sources from the same VSP") Signed-off-by: Biju Das Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20231116122424.80136-1-biju.das.jz@bp.renesas.com Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 96895c839dacacc47543dd19b0fa5ab5f09e179f Author: Dmitry Baryshkov Date: Sat Mar 1 11:24:56 2025 +0200 drm/msm/dpu: remove DSC feature bit for PINGPONG on MSM8953 [ Upstream commit 5232a29ebc74df4abf790147a06db451d824cd92 ] The MSM8953 platform doesn't have DSC blocks nor does have it DSC registers in the PINGPONG block. Drop the DPU_PINGPONG_DSC feature bit from the PINGPONG's feature mask and, as it is the only remaining bit, drop the .features assignment completely. Fixes: 7a6109ce1c2c ("drm/msm/dpu: Add support for MSM8953") Reported-by: Abhinav Kumar Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/640303/ Link: https://lore.kernel.org/r/20250301-dpu-fix-catalog-v2-3-498271be8b50@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 3261bf1486729f788b4d3f50492f8399e6f48d30 Author: Dmitry Baryshkov Date: Sat Mar 1 11:24:55 2025 +0200 drm/msm/dpu: remove DSC feature bit for PINGPONG on MSM8917 [ Upstream commit 5be98120115c46907921e29344291628cf79912a ] The MSM8917 platform doesn't have DSC blocks nor does have it DSC registers in the PINGPONG block. Drop the DPU_PINGPONG_DSC feature bit from the PINGPONG's feature mask and, as it is the only remaining bit, drop the .features assignment completely. Fixes: 62af6e1cb596 ("drm/msm/dpu: Add support for MSM8917") Reported-by: Abhinav Kumar Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/640301/ Link: https://lore.kernel.org/r/20250301-dpu-fix-catalog-v2-2-498271be8b50@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 09fddeed6d173125cbba954292bc547aee2afa65 Author: Dmitry Baryshkov Date: Sat Mar 1 11:24:54 2025 +0200 drm/msm/dpu: remove DSC feature bit for PINGPONG on MSM8937 [ Upstream commit b43c524134e0b0ae38acecc4e1dc585940ff6f88 ] The MSM8937 platform doesn't have DSC blocks nor does have it DSC registers in the PINGPONG block. Drop the DPU_PINGPONG_DSC feature bit from the PINGPONG's feature mask and, as it is the only remaining bit, drop the .features assignment completely. Fixes: c079680bb0fa ("drm/msm/dpu: Add support for MSM8937") Reported-by: Abhinav Kumar Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/640299/ Link: https://lore.kernel.org/r/20250301-dpu-fix-catalog-v2-1-498271be8b50@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit df32f4765b20ed9d33843fae8d2814c809acd282 Author: Dmitry Baryshkov Date: Fri Apr 25 22:49:09 2025 +0300 drm/msm/dpu: enable SmartDMA on SC8180X [ Upstream commit 8dcccd7a156ffb3157de7f527cc7c6100e9a455a ] Reworking of the catalog dropped the SmartDMA feature bit on the SC8180X platform. Renable SmartDMA support on this SoC. Fixes: 460c410f02e4 ("drm/msm/dpu: duplicate sdm845 catalog entries") Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/650421/ Link: https://lore.kernel.org/r/20250425-dpu-rework-vig-masks-v2-2-c71900687d08@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit a30456c4cb5a5c3281938aff98947b2c759a553e Author: Dmitry Baryshkov Date: Fri Apr 25 22:49:08 2025 +0300 drm/msm/dpu: enable SmartDMA on SM8150 [ Upstream commit 6a2343de0b6f70a21bf503ac4688dc905cb068e1 ] Reworking of the catalog dropped the SmartDMA feature bit on the SM8150 platform. Renable SmartDMA support on this SoC. Fixes: 460c410f02e4 ("drm/msm/dpu: duplicate sdm845 catalog entries") Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/650418/ Link: https://lore.kernel.org/r/20250425-dpu-rework-vig-masks-v2-1-c71900687d08@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 03b71e45846eb864cec8cc278399f23c8d834ee9 Author: Neill Kapron Date: Sun Apr 27 09:40:58 2025 +0000 selftests/seccomp: fix syscall_restart test for arm compat [ Upstream commit 797002deed03491215a352ace891749b39741b69 ] The inconsistencies in the systcall ABI between arm and arm-compat can can cause a failure in the syscall_restart test due to the logic attempting to work around the differences. The 'machine' field for an ARM64 device running in compat mode can report 'armv8l' or 'armv8b' which matches with the string 'arm' when only examining the first three characters of the string. This change adds additional validation to the workaround logic to make sure we only take the arm path when running natively, not in arm-compat. Fixes: 256d0afb11d6 ("selftests/seccomp: build and pass on arm64") Signed-off-by: Neill Kapron Link: https://lore.kernel.org/r/20250427094103.3488304-2-nkapron@google.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit e3d0c562573ad87fec405fd3ad187cea703bc2bd Author: Mark Rutland Date: Wed Apr 30 18:32:40 2025 +0100 arm64/fpsimd: Avoid warning when sve_to_fpsimd() is unused [ Upstream commit f699c66691fb7e08a5a631c5baf5f2a19b7a6468 ] Historically fpsimd_to_sve() and sve_to_fpsimd() were (conditionally) called by functions which were defined regardless of CONFIG_ARM64_SVE. Hence it was necessary that both fpsimd_to_sve() and sve_to_fpsimd() were always defined and not guarded by ifdeffery. As a result of the removal of fpsimd_signal_preserve_current_state() in commit: 929fa99b1215966f ("arm64/fpsimd: signal: Always save+flush state early") ... sve_to_fpsimd() has no callers when CONFIG_ARM64_SVE=n, resulting in a build-time warnign that it is unused: | arch/arm64/kernel/fpsimd.c:676:13: warning: unused function 'sve_to_fpsimd' [-Wunused-function] | 676 | static void sve_to_fpsimd(struct task_struct *task) | | ^~~~~~~~~~~~~ | 1 warning generated. In contrast, fpsimd_to_sve() still has callers which are defined when CONFIG_ARM64_SVE=n, and it would be awkward to hide this behind ifdeffery and/or to use stub functions. For now, suppress the warning by marking both fpsimd_to_sve() and sve_to_fpsimd() as 'static inline', as we usually do for stub functions. The compiler will no longer warn if either function is unused. Aside from suppressing the warning, there should be no functional change as a result of this patch. Link: https://lore.kernel.org/linux-arm-kernel/20250429194600.GA26883@willie-the-truck/ Reported-by: Will Deacon Fixes: 929fa99b1215 ("arm64/fpsimd: signal: Always save+flush state early") Signed-off-by: Mark Rutland Cc: Marc Zyngier Cc: Mark Brown Cc: Will Deacon Link: https://lore.kernel.org/r/20250430173240.4023627-1-mark.rutland@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit b3b9e722582981039124bfc3251d12d724619e0c Author: Kornel Dulęba Date: Thu Apr 17 11:47:54 2025 +0000 arm64: Support ARM64_VA_BITS=52 when setting ARCH_MMAP_RND_BITS_MAX [ Upstream commit f101c56447717c595d803894ba0e215f56c6fba4 ] When the 52-bit virtual addressing was introduced the select like ARCH_MMAP_RND_BITS_MAX logic was never updated to account for it. Because of that the rnd max bits knob is set to the default value of 18 when ARM64_VA_BITS=52. Fix this by setting ARCH_MMAP_RND_BITS_MAX to the same value that would be used if 48-bit addressing was used. Higher values can't used here because 52-bit addressing is used only if the caller provides a hint to mmap, with a fallback to 48-bit. The knob in question is an upper bound for what the user can set in /proc/sys/vm/mmap_rnd_bits, which in turn is used to determine how many random bits can be inserted into the base address used for mmap allocations. Since 48-bit allocations are legal with ARM64_VA_BITS=52, we need to make sure that the base address is small enough to facilitate this. Fixes: b6d00d47e81a ("arm64: mm: Introduce 52-bit Kernel VAs") Signed-off-by: Kornel Dulęba Reviewed-by: Anshuman Khandual Link: https://lore.kernel.org/r/20250417114754.3238273-1-korneld@google.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 205f4f44a7cc305f83a60da961bc2034b0fca980 Author: Miaoqian Lin Date: Tue Mar 18 23:17:12 2025 +0800 firmware: psci: Fix refcount leak in psci_dt_init [ Upstream commit 7ff37d29fd5c27617b9767e1b8946d115cf93a1e ] Fix a reference counter leak in psci_dt_init() where of_node_put(np) was missing after of_find_matching_node_and_match() when np is unavailable. Fixes: d09a0011ec0d ("drivers: psci: Allow PSCI node to be disabled") Signed-off-by: Miaoqian Lin Reviewed-by: Gavin Shan Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20250318151712.28763-1-linmq006@gmail.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit de3ef06c553902d27d2916d86553ef7d551e46b0 Author: Finn Thain Date: Thu Apr 24 10:07:26 2025 +1000 m68k: mac: Fix macintosh_config for Mac II [ Upstream commit 52ae3f5da7e5adbe3d1319573b55dac470abb83c ] When booted on my Mac II, the kernel prints this: Detected Macintosh model: 6 Apple Macintosh Unknown The catch-all entry ("Unknown") is mac_data_table[0] which is only needed in the unlikely event that the bootinfo model ID can't be matched. When model ID is 6, the search should begin and end at mac_data_table[1]. Fix the off-by-one error that causes this problem. Cc: Joshua Thompson Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Finn Thain Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/d0f30a551064ca4810b1c48d5a90954be80634a9.1745453246.git.fthain@linux-m68k.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 599facc46884ac876f8cd65aababd669f45ac876 Author: Kees Cook Date: Tue Apr 15 15:52:49 2025 -0700 watchdog: exar: Shorten identity name to fit correctly [ Upstream commit 8e28276a569addb8a2324439ae473848ee52b056 ] The static initializer for struct watchdog_info::identity is too long and gets initialized without a trailing NUL byte. Since the length of "identity" is part of UAPI and tied to ioctls, just shorten the name of the device. Avoids the warning seen with GCC 15's -Wunterminated-string-initialization option: drivers/watchdog/exar_wdt.c:224:27: warning: initializer-string for array of 'unsigned char' truncates NUL terminator but destination lacks 'nonstring' attribute (33 chars into 32 available) [-Wunterminated-string-initialization] 224 | .identity = "Exar/MaxLinear XR28V38x Watchdog", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fixes: 81126222bd3a ("watchdog: Exar/MaxLinear XR28V38x driver") Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20250415225246.work.458-kees@kernel.org Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit b7c88cf9c2c26ce6745a4f5badfff7e4fb4375f2 Author: Thomas Weißschuh Date: Wed Apr 16 14:44:19 2025 +0200 kunit/usercopy: Disable u64 test on 32-bit SPARC [ Upstream commit 0d6efa20e384a41a7f4afdcd8a0aec442c19d33e ] usercopy of 64 bit values does not work on 32-bit SPARC: # usercopy_test_valid: EXPECTATION FAILED at lib/tests/usercopy_kunit.c:209 Expected val_u64 == 0x5a5b5c5d6a6b6c6d, but val_u64 == 1515936861 (0x5a5b5c5d) 0x5a5b5c5d6a6b6c6d == 6510899242581322861 (0x5a5b5c5d6a6b6c6d) Disable the test. Fixes: 4c5d7bc63775 ("usercopy: Add tests for all get_user() sizes") Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20250416-kunit-sparc-usercopy-v1-1-a772054db3af@linutronix.de Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 3fd74b07e8a7557544b24f93cc4f67f8c9169e94 Author: Lizhi Xu Date: Tue Apr 15 17:26:37 2025 +0800 fs/ntfs3: Add missing direct_IO in ntfs_aops_cmpr [ Upstream commit 8b26c8c376b29cf29710fbfd093df194cefe26ad ] The ntfs3 can use the page cache directly, so its address_space_operations need direct_IO. Exit ntfs_direct_IO() if it is a compressed file. Fixes: b432163ebd15 ("fs/ntfs3: Update inode->i_mapping->a_ops on compression state") Reported-by: syzbot+e36cc3297bd3afd25e19@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e36cc3297bd3afd25e19 Signed-off-by: Lizhi Xu Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 4ecd0cde89feee26525ccdf1af0c1ae156ca010b Author: Andrey Vatoropin Date: Tue Mar 18 13:42:18 2025 +0000 fs/ntfs3: handle hdr_first_de() return value [ Upstream commit af5cab0e5b6f8edb0be51a9f47f3f620e0b4fd70 ] The hdr_first_de() function returns a pointer to a struct NTFS_DE. This pointer may be NULL. To handle the NULL error effectively, it is important to implement an error handler. This will help manage potential errors consistently. Additionally, error handling for the return value already exists at other points where this function is called. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Andrey Vatoropin Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 14fd6d6da3a41dbd9eb4c9fa2159e48370cbdb21 Author: Jose Maria Casanova Crespo Date: Fri Apr 25 14:25:08 2025 +0200 drm/v3d: client ranges from axi_ids are different with V3D 7.1 [ Upstream commit a22e0051f9eb2281b181218d97f77cebc299310d ] The client mask has been reduced from 8 bits on V3D 4.1 to 7 bits on V3D 7.1, so the ranges for each client are not compatible. On V3D 7.1, the CSD client can also report MMU errors. Therefore, add its AXI ID to the IDs list. Fixes: 0ad5bc1ce463 ("drm/v3d: fix up register addresses for V3D 7.x") Signed-off-by: Jose Maria Casanova Crespo Reviewed-by: Maíra Canal Link: https://lore.kernel.org/r/20250425122522.18425-2-jmcasanova@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 67c6d96d2bb949fc47d2b81efc614aebe84f73d8 Author: Jose Maria Casanova Crespo Date: Fri Apr 25 14:25:07 2025 +0200 drm/v3d: fix client obtained from axi_ids on V3D 4.1 [ Upstream commit d0e4c6537005dd106b101d4434a0c3dafd936d05 ] In the case of MMU errors caused by the TFU unit, the client that causes the MMU error is expected to be reported. But in the case of MMU TFU errors, a non existing client was being reported. This happened because the client calculation was taking into account more than the bits 0-7 from the axi_id that were representing the client. [ 27.845132] v3d fec00000.v3d: MMU error from client ? (13) at 0x3bb1000, pte invalid Masking the bits and using the correct axi_id ranges fixes the calculation to report the real guilty client on V3D 4.1 and 4.2. Make the MMU error print axi_id with hexadecimal as used in the ranges. Fixes: 38c2c7917adc ("drm/v3d: Fix and extend MMU error handling.") Signed-off-by: Jose Maria Casanova Crespo Reviewed-by: Maíra Canal Link: https://lore.kernel.org/r/20250425122522.18425-1-jmcasanova@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 7e33ba1175603b04802710ce6d9060eaa5039e76 Author: Maíra Canal Date: Mon Mar 17 22:01:09 2025 -0300 drm/v3d: Associate a V3D tech revision to all supported devices [ Upstream commit 76dbd0973c555037931d2ed055a4a69e592caad4 ] The V3D driver currently determines the GPU tech version (33, 41...) by reading a register. This approach has worked so far since this information wasn’t needed before powering on the GPU. V3D 7.1 introduces new registers that must be written to power on the GPU, requiring us to know the V3D version beforehand. To address this, associate each supported SoC with the corresponding VideoCore GPU version as part of the device data. To prevent possible mistakes, add an assertion to verify that the version specified in the device data matches the one reported by the hardware. If there is a mismatch, the kernel will trigger a warning. With the goal of maintaining consistency around the driver, use `enum v3d_gen` to assign values to `v3d->ver` and for comparisons with other V3D generations. Note that all mentions of unsupported or non-existing V3D generations (such as V3D 4.0) were removed by this commit and replaced with supported generations without functional changes. Reviewed-by: Iago Toral Quiroga Reviewed-by: Stefan Wahren Signed-off-by: Maíra Canal Link: https://patchwork.freedesktop.org/patch/msgid/20250317-v3d-gpu-reset-fixes-v6-1-f3ee7717ed17@igalia.com Stable-dep-of: d0e4c6537005 ("drm/v3d: fix client obtained from axi_ids on V3D 4.1") Signed-off-by: Sasha Levin commit 75a5b01b6437ae1854cc14b8e0f81200035c7138 Author: Christophe JAILLET Date: Fri Apr 18 08:48:16 2025 +0200 drm/bridge: lt9611uxc: Fix an error handling path in lt9611uxc_probe() [ Upstream commit b848cd418aebdb313364b4843f41fae82281a823 ] If lt9611uxc_audio_init() fails, some resources still need to be released before returning the error code. Use the existing error handling path. Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge") Signed-off-by: Christophe JAILLET Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/f167608e392c6b4d7d7f6e45e3c21878feb60cbd.1744958833.git.christophe.jaillet@wanadoo.fr Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit b6d6a26b162798e657f15045f624fb4832bdd8c8 Author: Casey Connolly Date: Sat Apr 19 18:31:44 2025 +0200 drm/panel: samsung-sofef00: Drop s6e3fc2x01 support [ Upstream commit e1eb7293ab4107e9e19fa609835e657fe30dfec7 ] We never properly supported this panel and always used the wrong init sequence. Drop support so we can move it to it's own proper driver. Fixes: 5933baa36e26 ("drm/panel/samsung-sofef00: Add panel for OnePlus 6/T devices") Signed-off-by: Casey Connolly Signed-off-by: David Heidelberg Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250419-drop-s6e3fc2x01-support-v1-1-05edfe0d27aa@ixit.cz Signed-off-by: Sasha Levin commit 7662022dd5a9849d6e060a19391ad896ece4b96f Author: Srinivasan Shanmugam Date: Thu Apr 17 21:05:35 2025 +0530 drm/amdgpu: Refine Cleaner Shader MEC firmware version for GFX10.1.x GPUs [ Upstream commit d30f61076268fd7ce01e4ec9e4d84bfaf90365f7 ] Update the minimum firmware version for the Cleaner Shader in the gfx_v10_0_sw_init function. This change adjusts the minimum required firmware version for the MEC firmware from 152 to 151, allowing for broader compatibility with GFX10.1 GPUs. Fixes: 25961bad9212 ("drm/amdgpu/gfx10: Add cleaner shader for GFX10.1.10") Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 498129a868ce966af277841f7e32e9f76b3779ad Author: Hongbo Yao Date: Tue Apr 1 13:42:48 2025 +0800 perf: arm-ni: Fix missing platform_set_drvdata() [ Upstream commit fc5106088d6db75df61308ef6de314d1f7959646 ] Add missing platform_set_drvdata in arm_ni_probe(), otherwise calling platform_get_drvdata() in remove returns NULL. Fixes: 4d5a7680f2b4 ("perf: Add driver for Arm NI-700 interconnect PMU") Signed-off-by: Hongbo Yao Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/20250401054248.3985814-1-andy.xu@hj-micro.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 72caf9886e9c1731cf7bfe3eabc308b9268b21d6 Author: Hongbo Yao Date: Thu Apr 3 15:09:18 2025 +0800 perf: arm-ni: Unregister PMUs on probe failure [ Upstream commit 7f57afde6a44d9e044885e1125034edd4fda02e8 ] When a resource allocation fails in one clock domain of an NI device, we need to properly roll back all previously registered perf PMUs in other clock domains of the same device. Otherwise, it can lead to kernel panics. Calling arm_ni_init+0x0/0xff8 [arm_ni] @ 2374 arm-ni ARMHCB70:00: Failed to request PMU region 0x1f3c13000 arm-ni ARMHCB70:00: probe with driver arm-ni failed with error -16 list_add corruption: next->prev should be prev (fffffd01e9698a18), but was 0000000000000000. (next=ffff10001a0decc8). pstate: 6340009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : list_add_valid_or_report+0x7c/0xb8 lr : list_add_valid_or_report+0x7c/0xb8 Call trace: __list_add_valid_or_report+0x7c/0xb8 perf_pmu_register+0x22c/0x3a0 arm_ni_probe+0x554/0x70c [arm_ni] platform_probe+0x70/0xe8 really_probe+0xc6/0x4d8 driver_probe_device+0x48/0x170 __driver_attach+0x8e/0x1c0 bus_for_each_dev+0x64/0xf0 driver_add+0x138/0x260 bus_add_driver+0x68/0x138 __platform_driver_register+0x2c/0x40 arm_ni_init+0x14/0x2a [arm_ni] do_init_module+0x36/0x298 ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops - BUG: Fatal exception SMP: stopping secondary CPUs Fixes: 4d5a7680f2b4 ("perf: Add driver for Arm NI-700 interconnect PMU") Signed-off-by: Hongbo Yao Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/20250403070918.4153839-1-andy.xu@hj-micro.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit abc7c588c68bc528132910636707c92c80bfbc6a Author: Boris Brezillon Date: Mon Apr 14 15:01:20 2025 +0200 drm/panthor: Fix the panthor_gpu_coherency_init() error path [ Upstream commit 938aaed555f3add76531cd204e2d4128ecb84ace ] The panthor_gpu_coherency_init() call has been moved around, but the error path hasn't been adjusted accordingly. Make sure we undo what has been done before this call in case of failure. Fixes: 7d5a3b22f5b5 ("drm/panthor: Call panthor_gpu_coherency_init() after PM resume()") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/dri-devel/4da470aa-4f84-460e-aff8-dabc8cc4da15@stanley.mountain/T/#t Reviewed-by: Steven Price Reviewed-by: Liviu Dudau Link: https://lore.kernel.org/r/20250414130120.581274-1-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 582a04abbd3061331e25c36facc10b5908352ec8 Author: Lizhi Hou Date: Wed Apr 9 14:00:13 2025 -0700 accel/amdxdna: Fix incorrect size of ERT_START_NPU commands [ Upstream commit 6c161732ea6467c6dea0c35810ca8e8d1ae135f1 ] When multiple ERT_START_NPU commands are combined in one buffer, the buffer size calculation is incorrect. Also, the condition to make sure the buffer size is not beyond 4K is also fixed. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Reviewed-by: Jacek Lawrynowicz Reviewed-by: Maciej Falkowski Signed-off-by: Lizhi Hou Link: https://lore.kernel.org/r/20250409210013.10854-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 84bd2b049cc4dfccb5e20833b4e4eef5d79ec691 Author: Boris Brezillon Date: Fri Apr 4 10:09:31 2025 +0200 drm/panthor: Update panthor_mmu::irq::mask when needed [ Upstream commit 8ba64cf2f358079d09faba7529aad2b0a46c7903 ] When we clear the faulty bits in the AS mask, we also need to update the panthor_mmu::irq::mask field otherwise our IRQ handler won't get called again until the GPU is reset. Changes in v2: - Add Liviu's R-b Changes in v3: - Add Steve's R-b Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block") Reviewed-by: Liviu Dudau Reviewed-by: Steven Price Link: https://lore.kernel.org/r/20250404080933.2912674-4-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 73bdbf12fbd4a067fd624d3bddd989c09a0a21c0 Author: Boris Brezillon Date: Fri Apr 4 10:09:30 2025 +0200 drm/panthor: Call panthor_gpu_coherency_init() after PM resume() [ Upstream commit 7d5a3b22f5b58ef89ab8770d7a44c24eecde8d66 ] When the device is coherent, panthor_gpu_coherency_init() will read GPU_COHERENCY_FEATURES to make sure the GPU supports the ACE-Lite coherency protocol, which will fail if the clocks/power-domains are not enabled when the read is done. Move the panthor_gpu_coherency_init() call after the device has been resumed to prevent that. Changes in v2: - Add Liviu's R-b Changes in v3: - Add Steve's R-b Fixes: dd7db8d911a1 ("drm/panthor: Explicitly set the coherency mode") Reviewed-by: Liviu Dudau Reviewed-by: Steven Price Link: https://lore.kernel.org/r/20250404080933.2912674-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 94bc1f753220d3af101ab14b97b1a465e36776ed Author: Boris Brezillon Date: Fri Apr 4 10:09:29 2025 +0200 drm/panthor: Fix GPU_COHERENCY_ACE[_LITE] definitions [ Upstream commit d1df2907fb69df56aad8e4a0734dac0778c234a7 ] GPU_COHERENCY_ACE and GPU_COHERENCY_ACE_LITE definitions have been swapped. Changes in v2: - New patch Changes in v3: - Add Steve's R-b Reported-by: Liviu Dudau Fixes: 546b366600ef ("drm/panthor: Add GPU register definitions") Reviewed-by: Steven Price Reviewed-by: Liviu Dudau Link: https://lore.kernel.org/r/20250404080933.2912674-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 06111746ea7a7a41409aad2f175ca3a02482b80e Author: Mark Rutland Date: Wed Apr 9 17:40:06 2025 +0100 arm64/fpsimd: Fix merging of FPSIMD state during signal return [ Upstream commit c94f2f326146a34066a0070ed90b8bc656b1842f ] For backwards compatibility reasons, when a signal return occurs which restores SVE state, the effective lower 128 bits of each of the SVE vector registers are restored from the corresponding FPSIMD vector register in the FPSIMD signal frame, overriding the values in the SVE signal frame. This is intended to be the case regardless of streaming mode. To make this happen, restore_sve_fpsimd_context() uses fpsimd_update_current_state() to merge the lower 128 bits from the FPSIMD signal frame into the SVE register state. Unfortunately, fpsimd_update_current_state() performs this merging dependent upon TIF_SVE, which is not always correct for streaming SVE register state: * When restoring non-streaming SVE register state there is no observable problem, as the signal return code configures TIF_SVE and the saved fp_type to match before calling fpsimd_update_current_state(), which observes either: - TIF_SVE set AND fp_type == FP_STATE_SVE - TIF_SVE clear AND fp_type == FP_STATE_FPSIMD * On systems which have SME but not SVE, TIF_SVE cannot be set. Thus the merging will never happen for the streaming SVE register state. * On systems which have SVE and SME, TIF_SVE can be set and cleared independently of PSTATE.SM. Thus the merging may or may not happen for streaming SVE register state. As TIF_SVE can be cleared non-deterministically during syscalls (including at the start of sigreturn()), the merging may occur non-deterministically from the perspective of userspace. This logic has been broken since its introduction in commit: 85ed24dad2904f7c ("arm64/sme: Implement streaming SVE signal handling") ... at which point both fpsimd_signal_preserve_current_state() and fpsimd_update_current_state() only checked TIF SVE. When PSTATE.SM==1 and TIF_SVE was clear, signal delivery would place stale FPSIMD state into the FPSIMD signal frame, and signal return would not merge this into the restored register state. Subsequently, signal delivery was fixed as part of commit: 61da7c8e2a602f66 ("arm64/signal: Don't assume that TIF_SVE means we saved SVE state") ... but signal restore was not given a corresponding fix, and when TIF_SVE was clear, signal restore would still fail to merge the FPSIMD state into the restored SVE register state. The 'Fixes' tag did not indicate that this had been broken since its introduction. Fix this by merging the FPSIMD state dependent upon the saved fp_type, matching what we (currently) do during signal delivery. As described above, when backporting this commit, it will also be necessary to backport commit: 61da7c8e2a602f66 ("arm64/signal: Don't assume that TIF_SVE means we saved SVE state") ... and prior to commit: baa8515281b30861 ("arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE") ... it will be necessary for fpsimd_signal_preserve_current_state() and fpsimd_update_current_state() to consider both TIF_SVE and thread_sm_enabled(¤t->thread), in place of the saved fp_type. Fixes: 85ed24dad290 ("arm64/sme: Implement streaming SVE signal handling") Signed-off-by: Mark Rutland Cc: Marc Zyngier Cc: Mark Brown Cc: Will Deacon Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20250409164010.3480271-10-mark.rutland@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 00a1a3fb553338eb74585d7df7b2bec20c80845a Author: Mark Rutland Date: Wed Apr 9 17:40:05 2025 +0100 arm64/fpsimd: Reset FPMR upon exec() [ Upstream commit a90878f297d3dba906a6261deccb1bd4a791ba52 ] An exec() is expected to reset all FPSIMD/SVE/SME state, and barring special handling of the vector lengths, the state is expected to reset to zero. This reset is handled in fpsimd_flush_thread(), which the core exec() code calls via flush_thread(). When support was added for FPMR, no logic was added to fpsimd_flush_thread() to reset the FPMR value, and thus it is erroneously inherited across an exec(). Add the missing reset of FPMR. Fixes: 203f2b95a882 ("arm64/fpsimd: Support FEAT_FPMR") Signed-off-by: Mark Rutland Cc: Marc Zyngier Cc: Mark Brown Cc: Will Deacon Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20250409164010.3480271-9-mark.rutland@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit a305821f597ec943849d3e53924adb88c61ed682 Author: Mark Rutland Date: Wed Apr 9 17:40:04 2025 +0100 arm64/fpsimd: Avoid clobbering kernel FPSIMD state with SMSTOP [ Upstream commit 01098d893fa8a6edb2b56e178b798e3e6b674f02 ] On system with SME, a thread's kernel FPSIMD state may be erroneously clobbered during a context switch immediately after that state is restored. Systems without SME are unaffected. If the CPU happens to be in streaming SVE mode before a context switch to a thread with kernel FPSIMD state, fpsimd_thread_switch() will restore the kernel FPSIMD state using fpsimd_load_kernel_state() while the CPU is still in streaming SVE mode. When fpsimd_thread_switch() subsequently calls fpsimd_flush_cpu_state(), this will execute an SMSTOP, causing an exit from streaming SVE mode. The exit from streaming SVE mode will cause the hardware to reset a number of FPSIMD/SVE/SME registers, clobbering the FPSIMD state. Fix this by calling fpsimd_flush_cpu_state() before restoring the kernel FPSIMD state. Fixes: e92bee9f861b ("arm64/fpsimd: Avoid erroneous elide of user state reload") Signed-off-by: Mark Rutland Cc: Ard Biesheuvel Cc: Mark Brown Cc: Will Deacon Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20250409164010.3480271-8-mark.rutland@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 87135d60ecf4fefc657d2e6bc8d00a638f08a570 Author: Mark Brown Date: Wed Apr 9 17:40:03 2025 +0100 arm64/fpsimd: Don't corrupt FPMR when streaming mode changes [ Upstream commit e5fa85fce08b21ed41643cb7968bf66bbd0532e3 ] When the effective value of PSTATE.SM is changed from 0 to 1 or from 1 to 0 by any method, an entry or exit to/from streaming SVE mode is performed, and hardware automatically resets a number of registers. As of ARM DDI 0487 L.a, this means: * All implemented bits of the SVE vector registers are set to zero. * All implemented bits of the SVE predicate registers are set to zero. * All implemented bits of FFR are set to zero, if FFR is implemented in the new mode. * FPSR is set to 0x0000_0000_0800_009f. * FPMR is set to 0, if FPMR is implemented. Currently task_fpsimd_load() restores FPMR before restoring SVCR (which is an accessor for PSTATE.{SM,ZA}), and so the restored value of FPMR may be clobbered if the restored value of PSTATE.SM happens to differ from the initial value of PSTATE.SM. Fix this by moving the restore of FPMR later. Note: this was originally posted as [1]. Fixes: 203f2b95a882 ("arm64/fpsimd: Support FEAT_FPMR") Signed-off-by: Mark Brown Link: https://lore.kernel.org/linux-arm-kernel/20241204-arm64-sme-reenable-v2-2-bae87728251d@kernel.org/ [ Rutland: rewrite commit message ] Signed-off-by: Mark Rutland Link: https://lore.kernel.org/r/20250409164010.3480271-7-mark.rutland@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit c4a4786d93e99517d6f10ed56b9ffba4ce88d3b3 Author: Mark Brown Date: Wed Apr 9 17:40:02 2025 +0100 arm64/fpsimd: Discard stale CPU state when handling SME traps [ Upstream commit d3eaab3c70905c5467e5c4ea403053d67505adeb ] The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state incorrectly, and a race with preemption can result in a task having TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SME traps enabled). This can result in warnings from do_sme_acc() where SME traps are not expected while TIF_SME is set: | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); This is very similar to the SVE issue we fixed in commit: 751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps") The race can occur when the SME trap handler is preempted before and after manipulating the saved FPSIMD/SVE/SME state, starting and ending on the same CPU, e.g. | void do_sme_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SME clear, SME traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); | | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | unsigned long vq_minus_one = | sve_vq_from_vl(task_get_sme_vl(current)) - 1; | sme_set_vq(vq_minus_one); | | fpsimd_bind_task_to_cpu(); | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SME traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | } Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace. Note: this was originallly posted as [1]. Fixes: 8bd7f91c03d8 ("arm64/sme: Implement traps and syscall handling for SME") Reported-by: Mark Rutland Signed-off-by: Mark Brown Link: https://lore.kernel.org/linux-arm-kernel/20241204-arm64-sme-reenable-v2-1-bae87728251d@kernel.org/ [ Rutland: rewrite commit message ] Signed-off-by: Mark Rutland Cc: Marc Zyngier Cc: Will Deacon Link: https://lore.kernel.org/r/20250409164010.3480271-6-mark.rutland@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit f99eac1e9874c31f68dd088dbccca810daee6863 Author: Mark Rutland Date: Wed Apr 9 17:39:58 2025 +0100 arm64/fpsimd: Avoid RES0 bits in the SME trap handler [ Upstream commit 95507570fb2f75544af69760cd5d8f48fc5c7f20 ] The SME trap handler consumes RES0 bits from the ESR when determining the reason for the trap, and depends upon those bits reading as zero. This may break in future when those RES0 bits are allocated a meaning and stop reading as zero. For SME traps taken with ESR_ELx.EC == 0b011101, the specific reason for the trap is indicated by ESR_ELx.ISS.SMTC ("SME Trap Code"). This field occupies bits [2:0] of ESR_ELx.ISS, and as of ARM DDI 0487 L.a, bits [24:3] of ESR_ELx.ISS are RES0. ESR_ELx.ISS itself occupies bits [24:0] of ESR_ELx. Extract the SMTC field specifically, matching the way we handle ESR_ELx fields elsewhere, and ensuring that the handler is future-proof. Fixes: 8bd7f91c03d8 ("arm64/sme: Implement traps and syscall handling for SME") Signed-off-by: Mark Rutland Cc: Marc Zyngier Cc: Mark Brown Cc: Will Deacon Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20250409164010.3480271-2-mark.rutland@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit b20a022de996d4cbb22f5671c5979e649a034e73 Author: Jonas Karlman Date: Tue Feb 25 10:40:33 2025 +0100 media: rkvdec: Fix frame size enumeration [ Upstream commit f270005b99fa19fee9a6b4006e8dee37c10f1944 ] The VIDIOC_ENUM_FRAMESIZES ioctl should return all frame sizes (i.e. width and height in pixels) that the device supports for the given pixel format. It doesn't make a lot of sense to return the frame-sizes in a stepwise manner, which is used to enforce hardware alignments requirements for CAPTURE buffers, for coded formats. Instead, applications should receive an indication, about the maximum supported frame size for that hardware decoder, via a continuous frame-size enumeration. Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") Suggested-by: Alex Bee Signed-off-by: Jonas Karlman Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a4ff7391c8b75b1541900bd9d0c238e558c11fb3 Author: Charles Han Date: Thu Mar 27 12:04:35 2025 +0800 drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table [ Upstream commit 820116a39f96bdc7d426c33a804b52f53700a919 ] The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced. Fixes: b3892e2bb519 ("drm/amd/pp: Use atombios api directly in powerplay (v2)") Fixes: 5f92b48cf62c ("drm/amd/pm: add mc register table initialization") Signed-off-by: Charles Han Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8359b1df16cb866aa5e697836330deb0a8b1c175 Author: Maxime Ripard Date: Thu Apr 3 15:33:33 2025 +0200 drm/vc4: tests: Retry pv-muxing tests when EDEADLK [ Upstream commit d5be7722d1736827a850556fd4d93e0fe2608c15 ] Some functions used by the HVS->PV muxing tests can return with EDEADLK, meaning the entire sequence should be restarted. It's not a fatal error and we should treat it as a recoverable error, and recover, instead of failing the test like we currently do. Fixes: 76ec18dc5afa ("drm/vc4: tests: Add unit test suite for the PV muxing") Reviewed-by: Maíra Canal Link: https://lore.kernel.org/r/20250403-drm-vc4-kunit-failures-v2-4-e09195cc8840@kernel.org Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit e13c4a28e8ecb9a5043774d9636fb609d5d778fd Author: Maxime Ripard Date: Thu Apr 3 15:33:32 2025 +0200 drm/vc4: tests: Stop allocating the state in test init [ Upstream commit 7e0351ae91ed2b6178abbfae96c3c6aaa1652567 ] The vc4-pv-muxing-combinations and vc5-pv-muxing-combinations test suites use a common test init function which, in part, allocates the drm atomic state the test will use. That allocation relies on drm_kunit_helper_atomic_state_alloc(), and thus requires a struct drm_modeset_acquire_ctx. This context will then be stored in the allocated state->acquire_ctx field. However, the context is local to the test init function, and is cleared as soon as drm_kunit_helper_atomic_state_alloc() is done. We thus end up with an dangling pointer to a cleared context in state->acquire_ctx for our test to consumes. We should really allocate the context and the state in the test functions, so we can also control when we're done with it. Fixes: 30188df0c387 ("drm/tests: Drop drm_kunit_helper_acquire_ctx_alloc()") Reviewed-by: Maíra Canal Link: https://lore.kernel.org/r/20250403-drm-vc4-kunit-failures-v2-3-e09195cc8840@kernel.org Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit aea146b5bc3937e0208366628ca5e79fa8bd41d1 Author: Maxime Ripard Date: Thu Apr 3 15:33:30 2025 +0200 drm/vc4: tests: Use return instead of assert [ Upstream commit 9e26a3740cc08ef8bcdc5e5d824792cd677affce ] The vc4_mock_atomic_add_output() and vc4_mock_atomic_del_output() assert that the functions they are calling didn't fail. Since some of them can return EDEADLK, we can't properly deal with it. Since both functions are expected to return an int, and all caller check the return value, let's just properly propagate the errors when they occur. Fixes: f759f5b53f1c ("drm/vc4: tests: Introduce a mocking infrastructure") Fixes: 76ec18dc5afa ("drm/vc4: tests: Add unit test suite for the PV muxing") Reviewed-by: Maíra Canal Link: https://lore.kernel.org/r/20250403-drm-vc4-kunit-failures-v2-1-e09195cc8840@kernel.org Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 0ae03b2e11f26fdaf35394db9181d96f399e9e9e Author: Badal Nilawar Date: Thu Mar 27 21:49:14 2025 +0530 drm/xe/d3cold: Set power state to D3Cold during s2idle/s3 [ Upstream commit f945dd89fa8da3f662508165453dafdb4035d9d3 ] According to pci core guidelines, pci_save_config is recommended when the driver explicitly needs to set the pci power state. As of now xe kmd is only doing pci_save_config while entering to s2idle/s3 state, which makes pci core think that device driver has already applied required pci power state. This leads to GPU remain in D0 state. To fix the issue setting the pci power state to D3Cold. Fixes:dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Rafael J. Wysocki Cc: Rodrigo Vivi Signed-off-by: Badal Nilawar Signed-off-by: Anshuman Gupta Reviewed-by: Rodrigo Vivi Link: https://lore.kernel.org/r/20250327161914.432552-1-badal.nilawar@intel.com Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 99abee83b1f83fea59545b9b587923bc28abf4bc Author: Stefan Wahren Date: Mon Mar 17 17:12:23 2025 +0000 drm/vc4: hdmi: Call HDMI hotplug helper on disconnect [ Upstream commit 34f051accedb642087fdcf19b3501fe150fbee49 ] drm_atomic_helper_connector_hdmi_hotplug() must be called regardless of the connection status, otherwise the HDMI audio disconnect event won't be notified. Fixes: 2ea9ec5d2c20 ("drm/vc4: hdmi: use drm_atomic_helper_connector_hdmi_hotplug()") Suggested-by: Dmitry Baryshkov Signed-off-by: Stefan Wahren Reviewed-by: Maxime Ripard Signed-off-by: David Turner Link: https://patchwork.freedesktop.org/patch/msgid/20250317-vc4_hotplug-v4-2-2af625629186@raspberrypi.com Signed-off-by: Dave Stevenson Signed-off-by: Sasha Levin commit 289ce5d9621ae63f41c451389f675eb82a353659 Author: Ian Forbes Date: Thu Jan 23 14:44:24 2025 -0600 drm/vmwgfx: Fix dumb buffer leak [ Upstream commit f42c09e614f1bda96f5690be8d0bb273234febbc ] Dumb buffers were not being freed because the GEM reference that was acquired in gb_surface_define was not dropped like it is in the 2D case. Dropping this ref uncovered a few additional issues with freeing the resources associated with dirty tracking in vmw_bo_free/release. Additionally the TTM object associated with the surface were also leaking which meant that when the ttm_object_file was closed at process exit the destructor unreferenced an already destroyed surface. The solution is to remove the destructor from the vmw_user_surface associated with the dumb_buffer and immediately unreferencing the TTM object which his removes it from the ttm_object_file. This also allows the early return in vmw_user_surface_base_release for the dumb buffer case to be removed as it should no longer occur. The chain of references now has the GEM handle(s) owning the dumb buffer. The GEM handles have a singular GEM reference to the vmw_bo which is dropped when all handles are closed. When the GEM reference count hits zero the vmw_bo is freed which then unreferences the surface via vmw_resource_release in vmw_bo_release. Fixes: d6667f0ddf46 ("drm/vmwgfx: Fix handling of dumb buffers") Signed-off-by: Ian Forbes Reviewed-by: Zack Rusin Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20250123204424.836896-1-ian.forbes@broadcom.com Signed-off-by: Sasha Levin commit 926cd7ab2f3aede5c37f7cc9332dc0fa23296000 Author: Vignesh Raman Date: Fri Feb 28 18:56:18 2025 +0530 drm/ci: fix merge request rules [ Upstream commit 10646ddac2917b31c985ceff0e4982c42a9c924b ] Merge request pipelines were only created when changes were made to drivers/gpu/drm/ci/, causing MRs that didn't touch this path to break. Fix MR pipeline rules to trigger jobs for all changes. Run jobs automatically for marge-bot and scheduled pipelines, but in all other cases run manually. Also remove CI_PROJECT_NAMESPACE checks specific to mesa. Fixes: df54f04f2020 ("drm/ci: update gitlab rules") Signed-off-by: Vignesh Raman Reviewed-by: Daniel Stone Signed-off-by: Helen Koike Link: https://patchwork.freedesktop.org/patch/msgid/20250228132620.556079-1-vignesh.raman@collabora.com Signed-off-by: Sasha Levin commit e1ef25a10362982da95c6d8b1a7ea3d0e6242478 Author: Arnd Bergmann Date: Thu Feb 27 14:20:32 2025 +0100 drm: xlnx: zynqmp_dpsub: fix Kconfig dependencies for ASoC [ Upstream commit f9f087d946266bc5da7c3a17bd8fd9d01969e3cf ] The new audio code fails to build when sounds support is in a loadable module but the GPU driver is built-in: x86_64-linux-ld: zynqmp_dp_audio.c:(.text+0x6a8): undefined reference to `devm_snd_soc_register_card' x86_64-linux-ld: drivers/gpu/drm/xlnx/zynqmp_dp_audio.o:(.rodata+0x1bc): undefined reference to `snd_soc_info_volsw' x86_64-linux-ld: drivers/gpu/drm/xlnx/zynqmp_dp_audio.o:(.rodata+0x1f0): undefined reference to `snd_soc_get_volsw' x86_64-linux-ld: drivers/gpu/drm/xlnx/zynqmp_dp_audio.o:(.rodata+0x1f4): undefined reference to `snd_soc_put_volsw' Change the Kconfig dependency to disallow the sound support in this configuration. Fixes: 3ec5c1579305 ("drm: xlnx: zynqmp_dpsub: Add DP audio support") Signed-off-by: Arnd Bergmann Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20250227132036.1136600-1-arnd@kernel.org Signed-off-by: Sasha Levin commit d0926e679761fb259acba3ee09a1de69e1a94502 Author: Keisuke Nishimura Date: Tue Feb 25 15:52:23 2025 +0100 drm/vmwgfx: Add error path for xa_store in vmw_bo_add_detached_resource [ Upstream commit 3282422bf251db541fe07c548ca304130d37d754 ] The xa_store() may fail due to memory allocation failure because there is no guarantee that the index is already used. This fix introduces new paths to handle the error. This patch also aligns the order of function calls by calling vmw_bo_add_detached_resource() before ttm_prime_object_init() in order to allow consistent error handling. Fixes: d6667f0ddf46 ("drm/vmwgfx: Fix handling of dumb buffers") Signed-off-by: Keisuke Nishimura Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20250225145223.34773-1-keisuke.nishimura@inria.fr Signed-off-by: Sasha Levin commit 1d17acfc019a6a831b4656094b4de5dca8b80886 Author: Ian Forbes Date: Fri Feb 28 14:06:33 2025 -0600 drm/vmwgfx: Add seqno waiter for sync_files [ Upstream commit 0039a3b35b10d9c15d3d26320532ab56cc566750 ] Because sync_files are passive waiters they do not participate in the processing of fences like the traditional vmw_fence_wait IOCTL. If userspace exclusively uses sync_files for synchronization then nothing in the kernel actually processes fence updates as interrupts for fences are masked and ignored if the kernel does not indicate to the SVGA device that there are active waiters. This oversight results in a bug where the entire GUI can freeze waiting on a sync_file that will never be signalled as we've masked the interrupts to signal its completion. This bug is incredibly racy as any process which interacts with the fencing code via the 3D stack can process the stuck fences on behalf of the stuck process causing it to run again. Even a simple app like eglinfo is enough to resume the stuck process. Usually this bug is seen at a login screen like GDM because there are no other 3D apps running. By adding a seqno waiter we re-enable interrupt based processing of the dma_fences associated with the sync_file which is signalled as part of a dma_fence_callback. This has likely been broken since it was initially added to the kernel in 2017 but has gone unnoticed until mutter recently started using sync_files heavily over the course of 2024 as part of their explicit sync support. Fixes: c906965dee22 ("drm/vmwgfx: Add export fence to file descriptor support") Signed-off-by: Ian Forbes Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20250228200633.642417-1-ian.forbes@broadcom.com Signed-off-by: Sasha Levin commit ccc3d68b92be89c30ba42ac62d2a141bd0c2b457 Author: Alexandre Ghiti Date: Thu May 22 16:13:56 2025 +0200 ACPI: platform_profile: Avoid initializing on non-ACPI platforms [ Upstream commit dd133162c9cff5951a692fab9811fadf46a46457 ] The platform profile driver is loaded even on platforms that do not have ACPI enabled. The initialization of the sysfs entries was recently moved from platform_profile_register() to the module init call, and those entries need acpi_kobj to be initialized which is not the case when ACPI is disabled. This results in the following warning: WARNING: CPU: 5 PID: 1 at fs/sysfs/group.c:131 internal_create_group+0xa22/0xdd8 Modules linked in: CPU: 5 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.15.0-rc7-dirty #6 PREEMPT Tainted: [W]=WARN Hardware name: riscv-virtio,qemu (DT) epc : internal_create_group+0xa22/0xdd8 ra : internal_create_group+0xa22/0xdd8 Call Trace: internal_create_group+0xa22/0xdd8 sysfs_create_group+0x22/0x2e platform_profile_init+0x74/0xb2 do_one_initcall+0x198/0xa9e kernel_init_freeable+0x6d8/0x780 kernel_init+0x28/0x24c ret_from_fork+0xe/0x18 Fix this by checking if ACPI is enabled before trying to create sysfs entries. Fixes: 77be5cacb2c2 ("ACPI: platform_profile: Create class for ACPI platform profile") Signed-off-by: Alexandre Ghiti Reviewed-by: Arnd Bergmann Reviewed-by: Mark Pearson Link: https://patch.msgid.link/20250522141410.31315-1-alexghiti@rivosinc.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 9841a465b88080063a6a3db7a439929384febee9 Author: Greg Kroah-Hartman Date: Thu May 22 12:08:05 2025 +0200 ALSA: core: fix up bus match const issues. [ Upstream commit 62f134ab190c5fd5c9f68fe638ad8e13bb8a4cb4 ] In commit d69d80484598 ("driver core: have match() callback in struct bus_type take a const *"), the match bus callback was changed to have the driver be a const pointer. Unfortunately that const attribute was thrown away when container_of() is called, which is not correct and was not caught by the compiler due to how container_of() is implemented. Fix this up by correctly preserving the const attribute of the driver passed to the bus match function which requires the hdac_driver match function to also take a const pointer for the driver structure. Cc: Jaroslav Kysela Cc: Takashi Iwai Fixes: d69d80484598 ("driver core: have match() callback in struct bus_type take a const *") Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2025052204-hyphen-thermal-3e72@gregkh Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 04d39b014fe0fe311463ad652d38eac6f014dbac Author: David Thompson Date: Tue Mar 18 17:47:47 2025 -0400 EDAC/bluefield: Don't use bluefield_edac_readl() result on error [ Upstream commit ea3b0b7f541b9511abe2b89547c95458804f38e2 ] The bluefield_edac_readl() routine returns an uninitialized result on error paths. In those cases the calling routine should not use the uninitialized result. The driver should simply log the error, and then return early. Fixes: e41967575474 ("EDAC/bluefield: Use Arm SMC for EMI access on BlueField-2") Signed-off-by: David Thompson Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Shravan Kumar Ramani Link: https://lore.kernel.org/20250318214747.12271-1-davthompson@nvidia.com Signed-off-by: Sasha Levin commit 294c85e7109d93f161bc369897bba8b9950fbe91 Author: Martin Povišer Date: Sun May 18 20:50:46 2025 +1000 ASoC: apple: mca: Constrain channels according to TDM mask [ Upstream commit e717c661e2d1a660e96c40b0fe9933e23a1d7747 ] We don't (and can't) configure the hardware correctly if the number of channels exceeds the weight of the TDM mask. Report that constraint in startup of FE. Fixes: 3df5d0d97289 ("ASoC: apple: mca: Start new platform driver") Signed-off-by: Martin Povišer Signed-off-by: James Calligeros Link: https://patch.msgid.link/20250518-mca-fixes-v1-1-ee1015a695f6@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1018fdbf5d4c5ecdd14d623a3ad54b4a85ee2ba6 Author: Geert Uytterhoeven Date: Fri May 16 15:32:06 2025 +0200 spi: sh-msiof: Fix maximum DMA transfer size [ Upstream commit 0941d5166629cb766000530945e54b4e49680c68 ] The maximum amount of data to transfer in a single DMA request is calculated from the FIFO sizes (which is technically not 100% correct, but a simplification, as it is limited by the maximum word count values in the Transmit and Control Data Registers). However, in case there is both data to transmit and to receive, the transmit limit is overwritten by the receive limit. Fix this by using the minimum applicable FIFO size instead. Move the calculation outside the loop, so it is not repeated for each individual DMA transfer. As currently tx_fifo_size is always equal to rx_fifo_size, this bug had no real impact. Fixes: fe78d0b7691c0274 ("spi: sh-msiof: Fix FIFO size to 64 word from 256 word") Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/d9961767a97758b2614f2ee8afe1bd56dc900a60.1747401908.git.geert+renesas@glider.be Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 00e4ea01c751c0e94594561e7a4054344e27e560 Author: Armin Wolf Date: Thu Apr 10 18:54:55 2025 +0200 ACPI: thermal: Execute _SCP before reading trip points [ Upstream commit 3f7cd28ae3d1a1d6f151178469cfaef1b07fdbcc ] As specified in section 11.4.13 of the ACPI specification the operating system is required to evaluate the _ACx and _PSV objects after executing the _SCP control method. Move the execution of the _SCP control method before the invocation of acpi_thermal_get_trip_points() to avoid missing updates to the _ACx and _PSV objects. Fixes: b09872a652d3 ("ACPI: thermal: Fold acpi_thermal_get_info() into its caller") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20250410165456.4173-3-W_Armin@gmx.de Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 9b8f454872f160d08c183d7dde6086b46bd51bd5 Author: Armin Wolf Date: Thu Apr 10 18:54:54 2025 +0200 ACPI: OSI: Stop advertising support for "3.0 _SCP Extensions" [ Upstream commit 8cf4fdac9bdead7bca15fc56fdecdf78d11c3ec6 ] As specified in section 5.7.2 of the ACPI specification the feature group string "3.0 _SCP Extensions" implies that the operating system evaluates the _SCP control method with additional parameters. However the ACPI thermal driver evaluates the _SCP control method without those additional parameters, conflicting with the above feature group string advertised to the firmware thru _OSI. Stop advertising support for this feature string to avoid confusing the ACPI firmware. Fixes: e5f660ebef68 ("ACPI / osi: Collect _OSI handling into one single file") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20250410165456.4173-2-W_Armin@gmx.de Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 3346e88278b4ca74c72d35be63f361ad88028b9a Author: AngeloGioacchino Del Regno Date: Wed Apr 2 10:38:52 2025 +0200 thermal/drivers/mediatek/lvts: Fix debugfs unregister on failure [ Upstream commit b49825661af93d9b8d7236f914803f136896f8fd ] When running the probe function for this driver, the function lvts_debugfs_init() gets called in lvts_domain_init() which, in turn, gets called in lvts_probe() before registering threaded interrupt handlers. Even though it's unlikely, the last call may fail and, if it does, there's nothing removing the already created debugfs folder and files. In order to fix that, instead of calling the lvts debugfs cleanup function upon failure, register a devm action that will take care of calling that upon failure or driver removal. Since devm was used, also delete the call to lvts_debugfs_exit() in the lvts_remove() callback, as now that's done automatically. Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver") Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20250402083852.20624-1-angelogioacchino.delregno@collabora.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit a2d539827d5d7481b6604c7ad809bf32d4d4d8ed Author: Gabor Juhos Date: Thu May 1 18:19:16 2025 +0200 spi: spi-qpic-snand: validate user/chip specific ECC properties [ Upstream commit 65cb56d49f6edea409600a3c61effc70ee5d43d8 ] The driver only supports 512 bytes ECC step size and 4 bit ECC strength at the moment, however it does not reject unsupported step/strength configurations. Due to this, whenever the driver is used with a flash chip which needs stronger ECC protection, the following warning is shown in the kernel log: [ 0.574648] spi-nand spi0.0: GigaDevice SPI NAND was found. [ 0.635748] spi-nand spi0.0: 256 MiB, block size: 128 KiB, page size: 2048, OOB size: 128 [ 0.649079] nand: WARNING: (null): the ECC used on your system is too weak compared to the one required by the NAND chip Although the message indicates that something is wrong, but it often gets unnoticed, which can cause serious problems. For example when the user writes something into the flash chip despite the warning, the written data may won't be readable by the bootloader or by the boot ROM. In the worst case, when the attached SPI NAND chip is the boot device, the board may not be able to boot anymore. Also, it is not even possible to create a backup of the flash, because reading its content results in bogus data. For example, dumping the first page of the flash gives this: # hexdump -C -n 2048 /dev/mtd0 00000000 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000040 0f 0f 0f 0f 0f 0f 0f 0d 0f 0f 0f 0f 0f 0f 0f 0f |................| 00000050 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 000001c0 0f 0f 0f 0f ff 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| 000001d0 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000200 0f 0f 0f 0f f5 5b ff ff 0f 0f 0f 0f 0f 0f 0f 0f |.....[..........| 00000210 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 000002f0 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 1f 0f 0f |................| 00000300 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 000003c0 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f ff 0f 0f 0f |................| 000003d0 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000400 0f 0f 0f 0f 0f 0f 0f 0f e9 74 c9 06 f5 5b ff ff |.........t...[..| 00000410 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 000005d0 0f 0f 0f 0f ff 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| 000005e0 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000600 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f c6 be 0f c3 |................| 00000610 e9 74 c9 06 f5 5b ff ff 0f 0f 0f 0f 0f 0f 0f 0f |.t...[..........| 00000620 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000770 0f 0f 0f 0f 8f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| 00000780 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000800 # Doing the same by using the downstream kernel results in different output: # hexdump -C -n 2048 /dev/mtd0 00000000 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000800 # This patch adds some sanity checks to the code to prevent using the driver with unsupported ECC step/strength configurations. After the change, probing of the driver fails in such cases: [ 0.655038] spi-nand spi0.0: GigaDevice SPI NAND was found. [ 0.659159] spi-nand spi0.0: 256 MiB, block size: 128 KiB, page size: 2048, OOB size: 128 [ 0.669138] qcom_snand 79b0000.spi: only 4 bits ECC strength is supported [ 0.677476] nand: No suitable ECC configuration [ 0.689909] spi-nand spi0.0: probe with driver spi-nand failed with error -95 This helps to avoid the aforementioned hassles until support for 8 bit ECC strength gets implemented. Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface") Signed-off-by: Gabor Juhos Link: https://patch.msgid.link/20250501-qpic-snand-validate-ecc-v1-1-532776581a66@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 652277e82d6ebf6eb0c1d229b1c59abb0b546ed6 Author: Gabor Juhos Date: Thu Mar 20 19:11:59 2025 +0100 spi: spi-qpic-snand: use kmalloc() for OOB buffer allocation [ Upstream commit f48d80503504257682e493dc17408f2f0b47bcfa ] The qcom_spi_ecc_init_ctx_pipelined() function allocates zeroed memory for the OOB buffer, then it fills the buffer with '0xff' bytes right after the allocation. In this case zeroing the memory during allocation is superfluous, so use kmalloc() instead of kzalloc() to avoid that. Signed-off-by: Gabor Juhos Link: https://patch.msgid.link/20250320-qpic-snand-kmalloc-v1-1-94e267550675@gmail.com Signed-off-by: Mark Brown Stable-dep-of: 65cb56d49f6e ("spi: spi-qpic-snand: validate user/chip specific ECC properties") Signed-off-by: Sasha Levin commit d1ddcc5551ac4808e1199bf1ac819cd089e5fc86 Author: Rafael J. Wysocki Date: Fri May 9 14:51:47 2025 +0200 PM: sleep: Print PM debug messages during hibernation [ Upstream commit 1b17d4525bca3916644c41e01522df8fa0f8b90b ] Commit cdb8c100d8a4 ("include/linux/suspend.h: Only show pm_pr_dbg messages at suspend/resume") caused PM debug messages to only be printed during system-wide suspend and resume in progress, but it forgot about hibernation. Address this by adding a check for hibernation in progress to pm_debug_messages_should_print(). Fixes: cdb8c100d8a4 ("include/linux/suspend.h: Only show pm_pr_dbg messages at suspend/resume") Signed-off-by: Rafael J. Wysocki Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/4998903.GXAFRqVoOG@rjwysocki.net Signed-off-by: Sasha Levin commit a239e3d296727817d5225a0af48065fc8050f543 Author: Jiaqing Zhao Date: Fri May 9 17:06:33 2025 +0000 x86/mtrr: Check if fixed-range MTRRs exist in mtrr_save_fixed_ranges() [ Upstream commit 824c6384e8d9275d4ec7204f3f79a4ac6bc10379 ] When suspending, save_processor_state() calls mtrr_save_fixed_ranges() to save fixed-range MTRRs. On platforms without fixed-range MTRRs like the ACRN hypervisor which has removed fixed-range MTRR emulation, accessing these MSRs will trigger an unchecked MSR access error. Make sure fixed-range MTRRs are supported before access to prevent such error. Since mtrr_state.have_fixed is only set when MTRRs are present and enabled, checking the CPU feature flag in mtrr_save_fixed_ranges() is unnecessary. Fixes: 3ebad5905609 ("[PATCH] x86: Save and restore the fixed-range MTRRs of the BSP when suspending") Signed-off-by: Jiaqing Zhao Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/20250509170633.3411169-2-jiaqing.zhao@linux.intel.com Signed-off-by: Sasha Levin commit c0e1adf4053ba2de499db00269c8dadf2382ff2a Author: Bence Csókás Date: Thu Mar 27 20:59:27 2025 +0100 spi: atmel-quadspi: Fix unbalanced pm_runtime by using devm_ API [ Upstream commit 8856eafcc05ecf54d6dd2b6c67804fefd276472c ] Fix unbalanced PM in error path of `atmel_qspi_probe()` by using `devm_pm_runtime_*()` functions. Reported-by: Alexander Dahl Closes: https://lore.kernel.org/linux-spi/20250110-paycheck-irregular-bcddab1276c7@thorsis.com/ Fixes: 5af42209a4d2 ("spi: atmel-quadspi: Add support for sama7g5 QSPI") Signed-off-by: Bence Csókás Link: https://patch.msgid.link/20250327195928.680771-4-csokas.bence@prolan.hu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c3102581a71d74b4740a1c0b4cfc8d7faade93f1 Author: Bence Csókás Date: Thu Mar 27 20:59:26 2025 +0100 PM: runtime: Add new devm functions [ Upstream commit 73db799bf5efc5a04654bb3ff6c9bf63a0dfa473 ] Add `devm_pm_runtime_set_active_enabled()` and `devm_pm_runtime_get_noresume()` for simplifying common cases in drivers. Signed-off-by: Bence Csókás Link: https://patch.msgid.link/20250327195928.680771-3-csokas.bence@prolan.hu Signed-off-by: Rafael J. Wysocki Stable-dep-of: 8856eafcc05e ("spi: atmel-quadspi: Fix unbalanced pm_runtime by using devm_ API") Signed-off-by: Sasha Levin commit 7d74f6cf7449f8fe880c9f5734a61a250f0ecd16 Author: Mingcong Bai Date: Thu Apr 17 15:39:46 2025 +0800 ACPI: resource: fix a typo for MECHREVO in irq1_edge_low_force_override[] [ Upstream commit 113e04276018bd13978051d8b05a613b4d390cc9 ] The vendor name for MECHREVO was incorrectly spelled in commit b53f09ecd602 ("ACPI: resource: Do IRQ override on MECHREV GM7XG0M"). Correct this typo in this trivial patch. Fixes: b53f09ecd602 ("ACPI: resource: Do IRQ override on MECHREV GM7XG0M") Signed-off-by: Mingcong Bai Link: https://patch.msgid.link/20250417073947.47419-1-jeffbai@aosc.io Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 71fd4767e9a2540c4c4507ee8b5f3f5431118b2e Author: Zijun Hu Date: Mon May 5 17:26:51 2025 +0800 PM: wakeup: Delete space in the end of string shown by pm_show_wakelocks() [ Upstream commit f0050a3e214aa941b78ad4caf122a735a24d81a6 ] pm_show_wakelocks() is called to generate a string when showing attributes /sys/power/wake_(lock|unlock), but the string ends with an unwanted space that was added back by mistake by commit c9d967b2ce40 ("PM: wakeup: simplify the output logic of pm_show_wakelocks()"). Remove the unwanted space. Fixes: c9d967b2ce40 ("PM: wakeup: simplify the output logic of pm_show_wakelocks()") Signed-off-by: Zijun Hu Link: https://patch.msgid.link/20250505-fix_power-v1-1-0f7f2c2f338c@quicinc.com [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 63626222b331b2a2f9540d9f286ed649f57bb316 Author: Vijendar Mukunda Date: Fri May 2 21:12:41 2025 +0530 ASoC: SOF: amd: add missing acp descriptor field [ Upstream commit 7c2bad7b95db5b4b978853cd4dd042ae3ec83e63 ] Add missing acp descriptor field acp_error_stat for ACP7.0 platform. Fixes: 490be7ba2a01 ("ASoC: SOF: amd: add support for acp7.0 based platform") Signed-off-by: Vijendar Mukunda Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Link: https://patch.msgid.link/20250502154445.3008598-3-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c386c80239449213f75b109663a93413205b4f67 Author: Thorsten Blum Date: Sat Apr 26 16:13:41 2025 +0200 ASoC: Intel: avs: Fix kcalloc() sizes [ Upstream commit d20df86b056b95845f6ed52da1010059202a0c23 ] rlist, clist, and slist are allocated using sizeof(pointer) instead of sizeof(*pointer). Fix the allocations by using sizeof(*pointer) and avoid overallocating memory on 64-bit systems. Fixes: f2f847461fb7 ("ASoC: Intel: avs: Constrain path based on BE capabilities") Signed-off-by: Thorsten Blum Reviewed-by: Amadeusz Sławiński Link: https://patch.msgid.link/20250426141342.94134-2-thorsten.blum@linux.dev Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 31dfe21b2c46c7140d9171ee3114e0d91b9dc2ca Author: Kees Cook Date: Fri Apr 25 23:25:12 2025 -0700 ASoC: SOF: ipc4-pcm: Adjust pipeline_list->pipelines allocation type [ Upstream commit 00a371adbbfb46db561db85a9d7b53b2363880a1 ] In preparation for making the kmalloc family of allocators type aware, we need to make sure that the returned type from the allocation matches the type of the variable being assigned. (Before, the allocator would always return "void *", which can be implicitly cast to any pointer type.) The assigned type is "struct snd_sof_pipeline **", but the returned type will be "struct snd_sof_widget **". These are the same size allocation (pointer size) but the types don't match. Adjust the allocation type to match the assignment. Signed-off-by: Kees Cook Fixes: 9c04363d222b ("ASoC: SOF: Introduce struct snd_sof_pipeline") Acked-by: Peter Ujfalusi Link: https://patch.msgid.link/20250426062511.work.859-kees@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c0805147153aea78a207d1490dbba9701f39eee0 Author: Benson Leung Date: Mon Apr 28 17:48:28 2025 +0000 platform/chrome: cros_ec_typec: Set Pin Assignment E in DP PORT VDO [ Upstream commit a9635ef0ca12e7914f42bfa7ca6a019f606c2817 ] Pin C and D are used on C-to-C cable applications including docks, and for USB-C adapters that convert from DP over USB-C to other video standards. Pin Assignment E is intended to be used with adapter from USB-C to DP plugs or receptacles. All Chromebook USB-C DFPs support DisplayPort Alternate Mode as the DP Source with support for all 3 pin assignments. Pin Assignment E is required in order to support if the user attaches a Pin E C-to-DP cable. Without this, the displayport.c alt mode driver will error out of dp_altmode_probe with an -ENODEV, as it cannot find a compatible matching pin assignment between the DFP_D and UFP_D. Fixes: dbb3fc0ffa95 ("platform/chrome: cros_ec_typec: Displayport support") Signed-off-by: Benson Leung Reviewed-by: Jameson Thies Reviewed-by: Abhishek Pandit-Subedi Link: https://lore.kernel.org/r/20250428174828.13939-1-bleung@chromium.org Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit 7f16be2b2927fdcfe40b596b7411c46d23a82034 Author: Dan Carpenter Date: Fri Mar 21 17:34:06 2025 +0300 power: supply: max77705: Fix workqueue error handling in probe [ Upstream commit 11741b8e382d34b13277497ab91123d8b0b5c2db ] The create_singlethread_workqueue() doesn't return error pointers, it returns NULL. Also cleanup the workqueue on the error paths. Fixes: a6a494c8e3ce ("power: supply: max77705: Add charger driver for Maxim 77705") Signed-off-by: Dan Carpenter Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/547656e3-4a5f-4f2e-802b-4edcb7c576b0@stanley.mountain Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 14cbdd64f3870cf0a2d94b87919b9056448c59a0 Author: Yaxiong Tian Date: Fri Apr 18 09:06:13 2025 +0800 PM: EM: Fix potential division-by-zero error in em_compute_costs() [ Upstream commit 179c0c7044a378198adb36f2a12410ab68cc730a ] When the device is of a non-CPU type, table[i].performance won't be initialized in the previous em_init_performance(), resulting in division by zero when calculating costs in em_compute_costs(). Since the 'cost' algorithm is only used for EAS energy efficiency calculations and is currently not utilized by other device drivers, we should add the _is_cpu_device(dev) check to prevent this division-by-zero issue. Fixes: 1b600da51073 ("PM: EM: Optimize em_cpu_energy() and remove division") Signed-off-by: Yaxiong Tian Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/tencent_7F99ED4767C1AF7889D0D8AD50F34859CE06@qq.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 36fd041c11fa57cf8cf5890525617bef848cfdb4 Author: Alexander Shiyan Date: Fri Mar 7 08:38:09 2025 +0300 power: reset: at91-reset: Optimize at91_reset() [ Upstream commit 62d48983f215bf1dd48665913318101fa3414dcf ] This patch adds a small optimization to the low-level at91_reset() function, which includes: - Removes the extra branch, since the following store operations already have proper condition checks. - Removes the definition of the clobber register r4, since it is no longer used in the code. Fixes: fcd0532fac2a ("power: reset: at91-reset: make at91sam9g45_restart() generic") Signed-off-by: Alexander Shiyan Reviewed-by: Alexandre Belloni Link: https://lore.kernel.org/r/20250307053809.20245-1-eagle.alexander923@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit ccd0ecc13090d6faf574c136d6fb8e42046f3e68 Author: Vishwaroop A Date: Wed Apr 16 11:06:03 2025 +0000 spi: tegra210-quad: modify chip select (CS) deactivation [ Upstream commit d8966b65413390d1b5b706886987caac05fbe024 ] Modify the chip select (CS) deactivation and inter-transfer delay execution only during the DATA_TRANSFER phase when the cs_change flag is not set. This ensures proper CS handling and timing between transfers while eliminating redundant operations. Fixes: 1b8342cc4a38 ("spi: tegra210-quad: combined sequence mode") Signed-off-by: Vishwaroop A Link: https://patch.msgid.link/20250416110606.2737315-4-va@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cb796521476ed7c21f0446cbff265d801de498e7 Author: Vishwaroop A Date: Wed Apr 16 11:06:02 2025 +0000 spi: tegra210-quad: remove redundant error handling code [ Upstream commit 400d9f1a27cc2fceabdb1ed93eaf0b89b6d32ba5 ] Remove unnecessary error handling code that terminated transfers and executed delay on errors. This code was redundant as error handling is already done at a higher level in the SPI core. Fixes: 1b8342cc4a38 ("spi: tegra210-quad: combined sequence mode") Signed-off-by: Vishwaroop A Link: https://patch.msgid.link/20250416110606.2737315-3-va@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d7f6f73454b4d039079aecae8c336fa01872bf4b Author: Vishwaroop A Date: Wed Apr 16 11:06:01 2025 +0000 spi: tegra210-quad: Fix X1_X2_X4 encoding and support x4 transfers [ Upstream commit dcb06c638a1174008a985849fa30fc0da7d08904 ] This patch corrects the QSPI_COMMAND_X1_X2_X4 and QSPI_ADDRESS_X1_X2_X4 macros to properly encode the bus width for x1, x2, and x4 transfers. Although these macros were previously incorrect, they were not being used in the driver, so no functionality was affected. The patch updates tegra_qspi_cmd_config() and tegra_qspi_addr_config() function calls to use the actual bus width from the transfer, instead of hardcoding it to 0 (which implied x1 mode). This change enables proper support for x1, x2, and x4 data transfers by correctly configuring the interface width for commands and addresses. These modifications improve the QSPI driver's flexibility and prepare it for future use cases that may require different bus widths for commands and addresses. Fixes: 1b8342cc4a38 ("spi: tegra210-quad: combined sequence mode") Signed-off-by: Vishwaroop A Link: https://patch.msgid.link/20250416110606.2737315-2-va@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1725a4f49e530bdb62d57a57da2639b0efac7f37 Author: Qiuxu Zhuo Date: Thu Apr 17 23:07:19 2025 +0800 EDAC/{skx_common,i10nm}: Fix the loss of saved RRL for HBM pseudo channel 0 [ Upstream commit eeed3e03f4261e5e381a72ae099ff00ccafbb437 ] When enabling the retry_rd_err_log (RRL) feature during the loading of the i10nm_edac driver with the module parameter retry_rd_err_log=2 (Linux RRL control mode), the default values of the control bits of RRL are saved so that they can be restored during the unloading of the driver. In the current code, the RRL of pseudo channel 1 of HBM overwrites pseudo channel 0 during the loading of the driver, resulting in the loss of saved RRL for pseudo channel 0. This causes the RRL of pseudo channel 0 of HBM to be wrongly restored with the values from pseudo channel 1 when unloading the driver. Fix this issue by creating two separate groups of RRL control registers per channel to save default RRL settings of two {sub-,pseudo-}channels. Fixes: acd4cf68fefe ("EDAC/i10nm: Retrieve and print retry_rd_err_log registers for HBM") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Tested-by: Feng Xu Link: https://lore.kernel.org/r/20250417150724.1170168-3-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 31ef6f7c9aee3be78d63789653e92350f2537f93 Author: Qiuxu Zhuo Date: Thu Apr 17 23:07:18 2025 +0800 EDAC/skx_common: Fix general protection fault [ Upstream commit 20d2d476b3ae18041be423671a8637ed5ffd6958 ] After loading i10nm_edac (which automatically loads skx_edac_common), if unload only i10nm_edac, then reload it and perform error injection testing, a general protection fault may occur: mce: [Hardware Error]: Machine check events logged Oops: general protection fault ... ... Workqueue: events mce_gen_pool_process RIP: 0010:string+0x53/0xe0 ... Call Trace: ? die_addr+0x37/0x90 ? exc_general_protection+0x1e7/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? string+0x53/0xe0 vsnprintf+0x23e/0x4c0 snprintf+0x4d/0x70 skx_adxl_decode+0x16a/0x330 [skx_edac_common] skx_mce_check_error.part.0+0xf8/0x220 [skx_edac_common] skx_mce_check_error+0x17/0x20 [skx_edac_common] ... The issue arose was because the variable 'adxl_component_count' (inside skx_edac_common), which counts the ADXL components, was not reset. During the reloading of i10nm_edac, the count was incremented by the actual number of ADXL components again, resulting in a count that was double the real number of ADXL components. This led to an out-of-bounds reference to the ADXL component array, causing the general protection fault above. Fix this issue by resetting the 'adxl_component_count' in adxl_put(), which is called during the unloading of {skx,i10nm}_edac. Fixes: 123b15863550 ("EDAC, i10nm: make skx_common.o a separate module") Reported-by: Feng Xu Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Tested-by: Feng Xu Link: https://lore.kernel.org/r/20250417150724.1170168-2-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 183e7329d41d7a8e298f48b6b0eb81102a8654de Author: Julien Massot Date: Thu Apr 17 10:44:33 2025 +0200 ASoC: mediatek: mt8195: Set ETDM1/2 IN/OUT to COMP_DUMMY() [ Upstream commit 7af317f7faaab09d5a78f24605057d11f5955115 ] ETDM2_IN_BE and ETDM1_OUT_BE are defined as COMP_EMPTY(), in the case the codec dai_name will be null. Avoid a crash if the device tree is not assigning a codec to these links. [ 1.179936] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 1.181065] Mem abort info: [ 1.181420] ESR = 0x0000000096000004 [ 1.181892] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.182576] SET = 0, FnV = 0 [ 1.182964] EA = 0, S1PTW = 0 [ 1.183367] FSC = 0x04: level 0 translation fault [ 1.183983] Data abort info: [ 1.184406] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1.185097] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.185766] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.186439] [0000000000000000] user address but active_mm is swapper [ 1.187239] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 1.188029] Modules linked in: [ 1.188420] CPU: 7 UID: 0 PID: 70 Comm: kworker/u32:1 Not tainted 6.14.0-rc4-next-20250226+ #85 [ 1.189515] Hardware name: Radxa NIO 12L (DT) [ 1.190065] Workqueue: events_unbound deferred_probe_work_func [ 1.190808] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.191683] pc : __pi_strcmp+0x24/0x140 [ 1.192170] lr : mt8195_mt6359_soc_card_probe+0x224/0x7b0 [ 1.192854] sp : ffff800083473970 [ 1.193271] x29: ffff800083473a10 x28: 0000000000001008 x27: 0000000000000002 [ 1.194168] x26: ffff800082408960 x25: ffff800082417db0 x24: ffff800082417d88 [ 1.195065] x23: 000000000000001e x22: ffff800082dbf480 x21: ffff800082dc07b8 [ 1.195961] x20: 0000000000000000 x19: 0000000000000013 x18: 00000000ffffffff [ 1.196858] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000006 [ 1.197755] x14: ffff800082407af0 x13: 6e6f69737265766e x12: 692d6b636f6c6374 [ 1.198651] x11: 0000000000000002 x10: ffff80008240b920 x9 : 0000000000000018 [ 1.199547] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000 [ 1.200443] x5 : 0000000000000000 x4 : 8080808080000000 x3 : 303933383978616d [ 1.201339] x2 : 0000000000000000 x1 : ffff80008240b920 x0 : 0000000000000000 [ 1.202236] Call trace: [ 1.202545] __pi_strcmp+0x24/0x140 (P) [ 1.203029] mtk_soundcard_common_probe+0x3bc/0x5b8 [ 1.203644] platform_probe+0x70/0xe8 [ 1.204106] really_probe+0xc8/0x3a0 [ 1.204556] __driver_probe_device+0x84/0x160 [ 1.205104] driver_probe_device+0x44/0x130 [ 1.205630] __device_attach_driver+0xc4/0x170 [ 1.206189] bus_for_each_drv+0x8c/0xf8 [ 1.206672] __device_attach+0xa8/0x1c8 [ 1.207155] device_initial_probe+0x1c/0x30 [ 1.207681] bus_probe_device+0xb0/0xc0 [ 1.208165] deferred_probe_work_func+0xa4/0x100 [ 1.208747] process_one_work+0x158/0x3e0 [ 1.209254] worker_thread+0x2c4/0x3e8 [ 1.209727] kthread+0x134/0x1f0 [ 1.210136] ret_from_fork+0x10/0x20 [ 1.210589] Code: 54000401 b50002c6 d503201f f86a6803 (f8408402) [ 1.211355] ---[ end trace 0000000000000000 ]--- Signed-off-by: Julien Massot Fixes: e70b8dd26711 ("ASoC: mediatek: mt8195: Remove afe-dai component and rework codec link") Reviewed-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20250417-mt8395-audio-sof-v1-2-30587426e5dd@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 98dc82ae5b197bf1a5548c5e01996261104fff25 Author: Hector Martin Date: Sun Apr 6 09:15:08 2025 +1000 ASoC: tas2764: Enable main IRQs [ Upstream commit dd50f0e38563f15819059c923bf142200453e003 ] IRQ handling was added in commit dae191fb957f ("ASoC: tas2764: Add IRQ handling") however that same commit masks all interrupts coming from the chip. Unmask the "main" interrupts so that we can see and deal with a number of errors including clock, voltage, and current. Fixes: dae191fb957f ("ASoC: tas2764: Add IRQ handling") Reviewed-by: Neal Gompa Signed-off-by: Hector Martin Signed-off-by: James Calligeros Link: https://patch.msgid.link/20250406-apple-codec-changes-v5-4-50a00ec850a3@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d1c661043a3139164045f6032bd49a0bd2088ac2 Author: Martin Povišer Date: Sun Apr 6 09:15:07 2025 +1000 ASoC: tas2764: Reinit cache on part reset [ Upstream commit 592ab3936b096da5deb64d4c906edbeb989174d6 ] When the part is reset in component_probe, do not forget to reinit the regcache, otherwise the cache can get out of sync with the part's actual state. This fix is similar to commit 0a0342ede303 ("ASoC: tas2770: Reinit regcache on reset") which concerned the tas2770 driver. Fixes: 827ed8a0fa50 ("ASoC: tas2764: Add the driver for the TAS2764") Reviewed-by: Neal Gompa Signed-off-by: Martin Povišer Signed-off-by: James Calligeros Link: https://patch.msgid.link/20250406-apple-codec-changes-v5-3-50a00ec850a3@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8bfc1d3ed69f5f48a42d4fd2b084bcaf40043a66 Author: Daniil Tatianin Date: Tue Apr 1 21:43:11 2025 +0300 ACPICA: exserial: don't forget to handle FFixedHW opregions for reading [ Upstream commit 0f8af0356a45547683a216e4921006a3c6a6d922 ] The initial commit that introduced support for FFixedHW operation regions did add a special case in the AcpiExReadSerialBus If, but forgot to actually handle it inside the switch, so add the missing case to prevent reads from failing with AE_AML_INVALID_SPACE_ID. Link: https://github.com/acpica/acpica/pull/998 Fixes: ee64b827a9a ("ACPICA: Add support for FFH Opregion special context data") Signed-off-by: Daniil Tatianin Link: https://patch.msgid.link/20250401184312.599962-1-d-tatianin@yandex-team.ru Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 8959b098e138bb87e85cc4cd93d6630a40c3e597 Author: Herbert Xu Date: Mon May 19 18:29:38 2025 +0800 crypto: api - Redo lookup on EEXIST [ Upstream commit 0a3cf32da469ff1df6e016f5f82b439a63d14461 ] When two crypto algorithm lookups occur at the same time with different names for the same algorithm, e.g., ctr(aes-generic) and ctr(aes), they will both be instantiated. However, only one of them can be registered. The second instantiation will fail with EEXIST. Avoid failing the second lookup by making it retry, but only once because there are tricky names such as gcm_base(ctr(aes),ghash) that will always fail, despite triggering instantiation and EEXIST. Reported-by: Ingo Franzki Fixes: 2825982d9d66 ("[CRYPTO] api: Added event notification") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2be0abcf8fef614c615e4de4b6a622632c953583 Author: Andreas Gruenbacher Date: Fri Mar 28 22:47:02 2025 +0100 gfs2: Don't start unnecessary transactions during log flush [ Upstream commit 5a90f8d499225512a385585ffe3e28f687263d47 ] Commit 8d391972ae2d ("gfs2: Remove __gfs2_writepage()") changed the log flush code in gfs2_ail1_start_one() to call aops->writepages() instead of aops->writepage(). For jdata inodes, this means that we will now try to reserve log space and start a transaction before we can determine that the pages in question have already been journaled. When this happens in the context of gfs2_logd(), it can now appear that not enough log space is available for freeing up log space, and we will lock up. Fix that by issuing journal writes directly instead of going through aops->writepages() in the log flush code. Fixes: 8d391972ae2d ("gfs2: Remove __gfs2_writepage()") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit a5b50bfc177eac3e5eaaa5205b5ed6e70810bebc Author: Andreas Gruenbacher Date: Wed Mar 26 22:21:08 2025 +0100 gfs2: Move gfs2_trans_add_databufs [ Upstream commit d50a64e3c55e59e45e415c65531b0d76ad4cea36 ] Move gfs2_trans_add_databufs() to trans.c. Pass in a glock instead of a gfs2_inode. Signed-off-by: Andreas Gruenbacher Stable-dep-of: 5a90f8d49922 ("gfs2: Don't start unnecessary transactions during log flush") Signed-off-by: Sasha Levin commit 6a740abc981a8d4d8d931deea1dc253e614c9cf7 Author: Tzung-Bi Shih Date: Tue May 20 08:20:49 2025 +0000 kunit: Fix wrong parameter to kunit_deactivate_static_stub() [ Upstream commit 772e50a76ee664e75581624f512df4e45582605a ] kunit_deactivate_static_stub() accepts real_fn_addr instead of replacement_addr. In the case, it always passes NULL to kunit_deactivate_static_stub(). Fix it. Link: https://lore.kernel.org/r/20250520082050.2254875-1-tzungbi@kernel.org Fixes: e047c5eaa763 ("kunit: Expose 'static stub' API to redirect functions") Signed-off-by: Tzung-Bi Shih Reviewed-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 74c84deec50a9c1dc66dcffcd1a0e32262b6701f Author: Xuewen Yan Date: Mon Mar 3 18:52:39 2025 +0800 sched/fair: Fixup wake_up_sync() vs DELAYED_DEQUEUE [ Upstream commit aa3ee4f0b7541382c9f6f43f7408d73a5d4f4042 ] Delayed dequeued feature keeps a sleeping task enqueued until its lag has elapsed. As a result, it stays also visible in rq->nr_running. So when in wake_affine_idle(), we should use the real running-tasks in rq to check whether we should place the wake-up task to current cpu. On the other hand, add a helper function to return the nr-delayed. Fixes: 152e11f6df29 ("sched/fair: Implement delayed dequeue") Signed-off-by: Xuewen Yan Reviewed-and-tested-by: Tianchen Ding Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Link: https://lore.kernel.org/r/20250303105241.17251-2-xuewen.yan@unisoc.com Signed-off-by: Sasha Levin commit c5a15c74124ae1649323d2a4e856e942c1ca9b1e Author: Ovidiu Panait Date: Fri May 16 15:06:56 2025 +0300 crypto: sun8i-ce - move fallback ahash_request to the end of the struct [ Upstream commit c822831b426307a6ca426621504d3c7f99765a39 ] 'struct ahash_request' has a flexible array at the end, so it must be the last member in a struct, to avoid overwriting other struct members. Therefore, move 'fallback_req' to the end of the 'sun8i_ce_hash_reqctx' struct. Fixes: 56f6d5aee88d ("crypto: sun8i-ce - support hash algorithms") Signed-off-by: Ovidiu Panait Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e2acafff6d0852ffba97c5c78a149986887fde01 Author: Herbert Xu Date: Thu May 15 16:34:04 2025 +0800 crypto: xts - Only add ecb if it is not already there [ Upstream commit 270b6f13454cb7f2f7058c50df64df409c5dcf55 ] Only add ecb to the cipher name if it isn't already ecb. Also use memcmp instead of strncmp since these strings are all stored in an array of length CRYPTO_MAX_ALG_NAME. Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e71b6f780009861e4314e46b4ce4ec9f9ed64fbb Author: Herbert Xu Date: Thu May 15 16:28:08 2025 +0800 crypto: lrw - Only add ecb if it is not already there [ Upstream commit 3d73909bddc2ebb3224a8bc2e5ce00e9df70c15d ] Only add ecb to the cipher name if it isn't already ecb. Also use memcmp instead of strncmp since these strings are all stored in an array of length CRYPTO_MAX_ALG_NAME. Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202505151503.d8a6cf10-lkp@intel.com Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 6a950a7f15aa3e4965cab62e9bc7a06f62fd341f Author: Yongliang Gao Date: Sun Feb 16 16:41:09 2025 +0800 rcu/cpu_stall_cputime: fix the hardirq count for x86 architecture [ Upstream commit da6b85598af30e9fec34d82882d7e1e39f3da769 ] When counting the number of hardirqs in the x86 architecture, it is essential to add arch_irq_stat_cpu to ensure accuracy. For example, a CPU loop within the rcu_read_lock function. Before: [ 70.910184] rcu: INFO: rcu_preempt self-detected stall on CPU [ 70.910436] rcu: 3-....: (4999 ticks this GP) idle=*** [ 70.910711] rcu: hardirqs softirqs csw/system [ 70.910870] rcu: number: 0 657 0 [ 70.911024] rcu: cputime: 0 0 2498 ==> 2498(ms) [ 70.911278] rcu: (t=5001 jiffies g=3677 q=29 ncpus=8) After: [ 68.046132] rcu: INFO: rcu_preempt self-detected stall on CPU [ 68.046354] rcu: 2-....: (4999 ticks this GP) idle=*** [ 68.046628] rcu: hardirqs softirqs csw/system [ 68.046793] rcu: number: 2498 663 0 [ 68.046951] rcu: cputime: 0 0 2496 ==> 2496(ms) [ 68.047244] rcu: (t=5000 jiffies g=3825 q=4 ncpus=8) Fixes: be42f00b73a0 ("rcu: Add RCU stall diagnosis information") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202501090842.SfI6QPGS-lkp@intel.com/ Signed-off-by: Yongliang Gao Reviewed-by: Neeraj Upadhyay Link: https://lore.kernel.org/r/20250216084109.3109837-1-leonylgao@gmail.com Signed-off-by: Boqun Feng Signed-off-by: Joel Fernandes Signed-off-by: Sasha Levin commit 9f451bcb35131c622faa00f15a3bd61db096b757 Author: Filipe Manana Date: Wed May 14 10:30:58 2025 +0100 btrfs: fix wrong start offset for delalloc space release during mmap write [ Upstream commit 17a85f520469a1838379de8ad24f63e778f7c277 ] If we're doing a mmap write against a folio that has i_size somewhere in the middle and we have multiple sectors in the folio, we may have to release excess space previously reserved, for the range going from the rounded up (to sector size) i_size to the folio's end offset. We are calculating the right amount to release and passing it to btrfs_delalloc_release_space(), but we are passing the wrong start offset of that range - we're passing the folio's start offset instead of the end offset, plus 1, of the range for which we keep the reservation. This may result in releasing more space then we should and eventually trigger an underflow of the data space_info's bytes_may_use counter. So fix this by passing the start offset as 'end + 1' instead of 'page_start' to btrfs_delalloc_release_space(). Fixes: d0b7da88f640 ("Btrfs: btrfs_page_mkwrite: Reserve space in sectorsized units") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 14266a7623530dd835db9500a1d7d78b7216b6e2 Author: Filipe Manana Date: Fri May 9 17:08:50 2025 +0100 btrfs: fix invalid data space release when truncating block in NOCOW mode [ Upstream commit d3914d6030aa6be2993dfc223d096ff93018c236 ] If when truncating a block we fail to reserve data space and then we proceed anyway because we can do a NOCOW write, if we later get an error when trying to get the folio from the inode's mapping, we end up releasing data space that we haven't reserved, screwing up the bytes_may_use counter from the data space_info, eventually resulting in an underflow when all other reservations done by other tasks are released, if any, or right away if there are no other reservations at the moment. This is because when we get an error when trying to grab the block's folio we call btrfs_delalloc_release_space(), which releases metadata (which we have reserved) and data (which we haven't reserved). Fix this by calling btrfs_delalloc_release_space() only if we did reserve data space, that is, if we aren't falling back to NOCOW, meaning the local variable @only_release_metadata has a false value, otherwise release only metadata by calling btrfs_delalloc_release_metadata(). Fixes: 6d4572a9d71d ("btrfs: allow btrfs_truncate_block() to fallback to nocow for data space reservation") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit be6188b7ba14311b18ce546048852be5c8b9e936 Author: Qu Wenruo Date: Mon May 5 18:56:18 2025 +0930 btrfs: scrub: fix a wrong error type when metadata bytenr mismatches [ Upstream commit f2c19541e421b3235efc515dad88b581f00592ae ] When the bytenr doesn't match for a metadata tree block, we will report it as an csum error, which is incorrect and should be reported as a metadata error instead. Fixes: a3ddbaebc7c9 ("btrfs: scrub: introduce a helper to verify one metadata block") Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit d42baa6e8f79902475ad6acbcaa7e0369d3e8eda Author: Qu Wenruo Date: Thu May 1 08:37:54 2025 +0930 btrfs: scrub: update device stats when an error is detected [ Upstream commit ec1f3a207cdf314eae4d4ae145f1ffdb829f0652 ] [BUG] Since the migration to the new scrub_stripe interface, scrub no longer updates the device stats when hitting an error, no matter if it's a read or checksum mismatch error. E.g: BTRFS info (device dm-2): scrub: started on devid 1 BTRFS error (device dm-2): unable to fixup (regular) error at logical 13631488 on dev /dev/mapper/test-scratch1 physical 13631488 BTRFS warning (device dm-2): checksum error at logical 13631488 on dev /dev/mapper/test-scratch1, physical 13631488, root 5, inode 257, offset 0, length 4096, links 1 (path: file) BTRFS error (device dm-2): unable to fixup (regular) error at logical 13631488 on dev /dev/mapper/test-scratch1 physical 13631488 BTRFS warning (device dm-2): checksum error at logical 13631488 on dev /dev/mapper/test-scratch1, physical 13631488, root 5, inode 257, offset 0, length 4096, links 1 (path: file) BTRFS info (device dm-2): scrub: finished on devid 1 with status: 0 Note there is no line showing the device stats error update. [CAUSE] In the migration to the new scrub_stripe interface, we no longer call btrfs_dev_stat_inc_and_print(). [FIX] - Introduce a new bitmap for metadata generation errors * A new bitmap @meta_gen_error_bitmap is introduced to record which blocks have metadata generation mismatch errors. * A new counter for that bitmap @init_nr_meta_gen_errors, is also introduced to store the number of generation mismatch errors that are found during the initial read. This is for the error reporting at scrub_stripe_report_errors(). * New dedicated error message for unrepaired generation mismatches * Update @meta_gen_error_bitmap if a transid mismatch is hit - Add btrfs_dev_stat_inc_and_print() calls to the following call sites * scrub_stripe_report_errors() * scrub_write_endio() This is only for the write errors. This means there is a minor behavior change: - The timing of device stats error message Since we concentrate the error messages at scrub_stripe_report_errors(), the device stats error messages will all show up in one go, after the detailed scrub error messages: BTRFS error (device dm-2): unable to fixup (regular) error at logical 13631488 on dev /dev/mapper/test-scratch1 physical 13631488 BTRFS warning (device dm-2): checksum error at logical 13631488 on dev /dev/mapper/test-scratch1, physical 13631488, root 5, inode 257, offset 0, length 4096, links 1 (path: file) BTRFS error (device dm-2): unable to fixup (regular) error at logical 13631488 on dev /dev/mapper/test-scratch1 physical 13631488 BTRFS warning (device dm-2): checksum error at logical 13631488 on dev /dev/mapper/test-scratch1, physical 13631488, root 5, inode 257, offset 0, length 4096, links 1 (path: file) BTRFS error (device dm-2): bdev /dev/mapper/test-scratch1 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0 BTRFS error (device dm-2): bdev /dev/mapper/test-scratch1 errs: wr 0, rd 0, flush 0, corrupt 2, gen 0 Fixes: e02ee89baa66 ("btrfs: scrub: switch scrub_simple_mirror() to scrub_stripe infrastructure") Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 234ac83e16296d4fb0c26884999821fe5ce8c0ae Author: Gaurav Batra Date: Mon May 12 17:46:53 2025 -0500 powerpc/pseries/iommu: Fix kmemleak in TCE table userspace view [ Upstream commit d36e3f11fe8b55b801bdbe84ad51f612b1bd84da ] When a device is opened by a userspace driver, via VFIO interface, DMA window is created. This DMA window has TCE Table and a corresponding data for userview of TCE table. When the userspace driver closes the device, all the above infrastructure is free'ed and the device control given back to kernel. Both DMA window and TCE table is getting free'ed. But due to a code bug, userview of the TCE table is not getting free'ed. This is resulting in a memory leak. Befow is the information from KMEMLEAK unreferenced object 0xc008000022af0000 (size 16777216): comm "senlib_unit_tes", pid 9346, jiffies 4294983174 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): kmemleak_vmalloc+0xc8/0x1a0 __vmalloc_node_range+0x284/0x340 vzalloc+0x58/0x70 spapr_tce_create_table+0x4b0/0x8d0 tce_iommu_create_table+0xcc/0x170 [vfio_iommu_spapr_tce] tce_iommu_create_window+0x144/0x2f0 [vfio_iommu_spapr_tce] tce_iommu_ioctl.part.0+0x59c/0xc90 [vfio_iommu_spapr_tce] vfio_fops_unl_ioctl+0x88/0x280 [vfio] sys_ioctl+0xf4/0x160 system_call_exception+0x164/0x310 system_call_vectored_common+0xe8/0x278 unreferenced object 0xc008000023b00000 (size 4194304): comm "senlib_unit_tes", pid 9351, jiffies 4294984116 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): kmemleak_vmalloc+0xc8/0x1a0 __vmalloc_node_range+0x284/0x340 vzalloc+0x58/0x70 spapr_tce_create_table+0x4b0/0x8d0 tce_iommu_create_table+0xcc/0x170 [vfio_iommu_spapr_tce] tce_iommu_create_window+0x144/0x2f0 [vfio_iommu_spapr_tce] tce_iommu_create_default_window+0x88/0x120 [vfio_iommu_spapr_tce] tce_iommu_ioctl.part.0+0x57c/0xc90 [vfio_iommu_spapr_tce] vfio_fops_unl_ioctl+0x88/0x280 [vfio] sys_ioctl+0xf4/0x160 system_call_exception+0x164/0x310 system_call_vectored_common+0xe8/0x278 Fixes: f431a8cde7f1 ("powerpc/iommu: Reimplement the iommu_table_group_ops for pSeries") Signed-off-by: Gaurav Batra Reviewed-by: Nilay Shroff Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250512224653.35697-1-gbatra@linux.ibm.com Signed-off-by: Sasha Levin commit cd04beb9ce2773a16057248bb4fa424068ae3807 Author: Sheng Yong Date: Thu May 15 09:48:37 2025 +0800 erofs: avoid using multiple devices with different type [ Upstream commit 9748f2f54f66743ac77275c34886a9f890e18409 ] For multiple devices, both primary and extra devices should be the same type. `erofs_init_device` has already guaranteed that if the primary is a file-backed device, extra devices should also be regular files. However, if the primary is a block device while the extra device is a file-backed device, `erofs_init_device` will get an ENOTBLK, which is not treated as an error in `erofs_fc_get_tree`, and that leads to an UAF: erofs_fc_get_tree get_tree_bdev_flags(erofs_fc_fill_super) erofs_read_superblock erofs_init_device // sbi->dif0 is not inited yet, // return -ENOTBLK deactivate_locked_super free(sbi) if (err is -ENOTBLK) sbi->dif0.file = filp_open() // sbi UAF So if -ENOTBLK is hitted in `erofs_init_device`, it means the primary device must be a block device, and the extra device is not a block device. The error can be converted to -EINVAL. Fixes: fb176750266a ("erofs: add file-backed mount support") Signed-off-by: Sheng Yong Reviewed-by: Gao Xiang Reviewed-by: Hongbo Li Link: https://lore.kernel.org/r/20250515014837.3315886-1-shengyong1@xiaomi.com Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 480d4cdfcb2db69226dc6f0142fa86ecdb736b4c Author: Hongbo Li Date: Wed May 7 09:40:15 2025 +0000 erofs: fix file handle encoding for 64-bit NIDs [ Upstream commit 510de8363f2c3d8e67fa9dfb2366e821382036e0 ] EROFS uses NID to indicate the on-disk inode offset, which can exceed 32 bits. However, the default encode_fh uses the ino32, thus it doesn't work if the image is larger than 128GiB. Let's introduce our own helpers to encode file handles. It's easy to reproduce: 1. prepare an erofs image with nid bigger than U32_MAX 2. mount -t erofs foo.img /mnt/erofs 3. set exportfs with configuration: /mnt/erofs *(rw,sync, no_root_squash) 4. mount -t nfs $IP:/mnt/erofs /mnt/nfs 5. md5sum /mnt/nfs/foo # foo is the file which nid bigger than U32_MAX. # you will get ESTALE error. In the case of overlayfs, the underlying filesystem's file handle is encoded in ovl_fb.fid, which is similar to NFS's case. If the NID of file is larger than U32_MAX, the overlay will get -ESTALE error when calls exportfs_decode_fh. Fixes: 3e917cc305c6 ("erofs: make filesystem exportable") Signed-off-by: Hongbo Li Reviewed-by: Gao Xiang Link: https://lore.kernel.org/r/20250507094015.14007-1-lihongbo22@huawei.com Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 4e83332fe515dcdc6728ffd34319f6a5569b7984 Author: Herbert Xu Date: Sat May 10 18:43:33 2025 +0800 crypto: marvell/cesa - Avoid empty transfer descriptor [ Upstream commit 1bafd82d9a40cf09c6c40f1c09cc35b7050b1a9f ] The user may set req->src even if req->nbytes == 0. If there is no data to hash from req->src, do not generate an empty TDMA descriptor. Fixes: db509a45339f ("crypto: marvell/cesa - add TDMA support") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c9610dda42bd382a96f97e68825cb5f66cd9e1dc Author: Herbert Xu Date: Sat May 10 18:41:31 2025 +0800 crypto: marvell/cesa - Handle zero-length skcipher requests [ Upstream commit 8a4e047c6cc07676f637608a9dd675349b5de0a7 ] Do not access random memory for zero-length skcipher requests. Just return 0. Fixes: f63601fd616a ("crypto: marvell/cesa - add a new driver for Marvell's CESA") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4398787d04454600dd4466831f430ec84dcc4d31 Author: Nícolas F. R. A. Prado Date: Wed Apr 30 10:55:49 2025 -0400 kselftest: cpufreq: Get rid of double suspend in rtcwake case [ Upstream commit 23b88515a318680337f21d0a2fceee8038ccffc8 ] Commit 0b631ed3ce92 ("kselftest: cpufreq: Add RTC wakeup alarm") added support for automatic wakeup in the suspend routine of the cpufreq kselftest by using rtcwake, however it left the manual power state change in the common path. The end result is that when running the cpufreq kselftest with '-t suspend_rtc' or '-t hibernate_rtc', the system will go to sleep and be woken up by the RTC, but then immediately go to sleep again with no wakeup programmed, so it will sleep forever in an automated testing setup. Fix this by moving the manual power state change so that it only happens when not using rtcwake. Link: https://lore.kernel.org/r/20250430-ksft-cpufreq-suspend-rtc-double-fix-v1-1-dc17a729c5a7@collabora.com Fixes: 0b631ed3ce92 ("kselftest: cpufreq: Add RTC wakeup alarm") Signed-off-by: Nícolas F. R. A. Prado Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 24c9cb53e682a5a34c5794d1855cfd98c4f64787 Author: Yu Kuai Date: Tue May 6 14:17:56 2025 +0800 brd: fix discard end sector [ Upstream commit a26a339a654b9403f0ee1004f1db4c2b2a355460 ] brd_do_discard() just aligned start sector to page, this can only work if the discard size if at least one page. For example: blkdiscard /dev/ram0 -o 5120 -l 1024 In this case, size = (1024 - (8192 - 5120)), which is a huge value. Fix the problem by round_down() the end sector. Fixes: 9ead7efc6f3f ("brd: implement discard support") Signed-off-by: Yu Kuai Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20250506061756.2970934-4-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit da7042b9a42e43af422b4da2e7e1d7168a32cf51 Author: Yu Kuai Date: Tue May 6 14:17:55 2025 +0800 brd: fix aligned_sector from brd_do_discard() [ Upstream commit d4099f8893b057ad7e8d61df76bdeaf807ebd679 ] The calculation is just wrong, fix it by round_up(). Fixes: 9ead7efc6f3f ("brd: implement discard support") Signed-off-by: Yu Kuai Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20250506061756.2970934-3-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5387b3e0be28fe43800399b073d204838e49f7c5 Author: Masami Hiramatsu (Google) Date: Mon Apr 28 10:48:10 2025 +0900 x86/insn: Fix opcode map (!REX2) superscript tags [ Upstream commit ca698ec2f07873a448d53c580795c4e023c75393 ] Commit: 159039af8c07 ("x86/insn: x86/insn: Add support for REX2 prefix to the instruction decoder opcode map") added (!REX2) superscript with a space, but the correct format requires ',' for concatination with other superscript tags. Add ',' to generate correct insn attribute tables. I confirmed with following command: arch/x86/lib/x86-opcode-map.txt | grep e8 | head -n 1 [0xe8] = INAT_MAKE_IMM(INAT_IMM_VWORD32) | INAT_FORCE64 | INAT_NO_REX2, Fixes: 159039af8c07 ("x86/insn: x86/insn: Add support for REX2 prefix to the instruction decoder opcode map") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Ingo Molnar Cc: H. Peter Anvin Cc: Adrian Hunter Cc: Peter Zijlstra Link: https://lore.kernel.org/r/174580489027.388420.15539375184727726142.stgit@devnote2 Signed-off-by: Sasha Levin commit 1cdad40ab51572f8e3830dc0f000fc9ae29c9abb Author: Ahmed S. Darwish Date: Tue May 6 07:04:13 2025 +0200 x86/cpu: Sanitize CPUID(0x80000000) output [ Upstream commit cc663ba3fe383a628a812f893cc98aafff39ab04 ] CPUID(0x80000000).EAX returns the max extended CPUID leaf available. On x86-32 machines without an extended CPUID range, a CPUID(0x80000000) query will just repeat the output of the last valid standard CPUID leaf on the CPU; i.e., a garbage values. Current tip:x86/cpu code protects against this by doing: eax = cpuid_eax(0x80000000); c->extended_cpuid_level = eax; if ((eax & 0xffff0000) == 0x80000000) { // CPU has an extended CPUID range. Check for 0x80000001 if (eax >= 0x80000001) { cpuid(0x80000001, ...); } } This is correct so far. Afterwards though, the same possibly broken EAX value is used to check the availability of other extended CPUID leaves: if (c->extended_cpuid_level >= 0x80000007) ... if (c->extended_cpuid_level >= 0x80000008) ... if (c->extended_cpuid_level >= 0x8000000a) ... if (c->extended_cpuid_level >= 0x8000001f) ... which is invalid. Fix this by immediately setting the CPU's max extended CPUID leaf to zero if CPUID(0x80000000).EAX doesn't indicate a valid CPUID extended range. While at it, add a comment, similar to kernel/head_32.S, clarifying the CPUID(0x80000000) sanity check. References: 8a50e5135af0 ("x86-32: Use symbolic constants, safer CPUID when enabling EFER.NX") Fixes: 3da99c977637 ("x86: make (early)_identify_cpu more the same between 32bit and 64 bit") Signed-off-by: Ahmed S. Darwish Signed-off-by: Ingo Molnar Cc: Andrew Cooper Cc: H. Peter Anvin Cc: John Ogness Cc: x86-cpuid@lists.linux.dev Link: https://lore.kernel.org/r/20250506050437.10264-3-darwi@linutronix.de Signed-off-by: Sasha Levin commit 31a559510b9d90be14d6c5332f377747cccaa4be Author: Zizhi Wo Date: Thu Apr 17 21:20:52 2025 +0800 blk-throttle: Fix wrong tg->[bytes/io]_disp update in __tg_update_carryover() [ Upstream commit f66cf69eb8765341bbeff0e92a7d0d2027f62452 ] In commit 6cc477c36875 ("blk-throttle: carry over directly"), the carryover bytes/ios was be carried to [bytes/io]_disp. However, its update mechanism has some issues. In __tg_update_carryover(), we calculate "bytes" and "ios" to represent the carryover, but the computation when updating [bytes/io]_disp is incorrect. And if the sq->nr_queued is empty, we may not update tg->[bytes/io]_disp to 0 in tg_update_carryover(). We should set it to 0 in non carryover case. This patch fixes the issue. Fixes: 6cc477c36875 ("blk-throttle: carry over directly") Signed-off-by: Zizhi Wo Reviewed-by: Yu Kuai Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20250417132054.2866409-2-wozizhi@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5974f45fa24cf4743748b3994dfa122db795d18e Author: Ovidiu Panait Date: Thu May 1 22:06:50 2025 +0300 crypto: sun8i-ce - undo runtime PM changes during driver removal [ Upstream commit 9334f427576e6d361a409959b52246b0aa10476f ] The pm_runtime_use_autosuspend() call must be undone with pm_runtime_dont_use_autosuspend() at driver exit, but this is not currently handled in the driver. To fix this issue and at the same time simplify error handling, switch to devm_pm_runtime_enable(). It will call both pm_runtime_disable() and pm_runtime_dont_use_autosuspend() during driver removal. Fixes: 06f751b61329 ("crypto: allwinner - Add sun8i-ce Crypto Engine") Signed-off-by: Ovidiu Panait Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7dba640f278e02810b72d9edae1b4c4af889aff6 Author: Nam Cao Date: Fri Apr 11 17:09:43 2025 +0200 selftests: coredump: Raise timeout to 2 minutes [ Upstream commit c6e888d02d51d1e9f9abf1587e6a5618375cac9f ] The test's runtime (nearly 20s) is dangerously close to the limit (30s) on qemu-system-riscv64: $ time ./stackdump_test > /dev/null real 0m19.210s user 0m0.077s sys 0m0.359s There could be machines slower than qemu-system-riscv64. Therefore raise the test timeout to 2 minutes to be safe. Fixes: 15858da53542 ("selftests: coredump: Add stackdump test") Signed-off-by: Nam Cao Link: https://lore.kernel.org/dd636084d55e7828782728d087fa2298dcab1c8b.1744383419.git.namcao@linutronix.de Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit a44b5e75f727c418add2a4589a92f1242229122c Author: Nam Cao Date: Fri Apr 11 17:09:42 2025 +0200 selftests: coredump: Fix test failure for slow machines [ Upstream commit 6f5bf9f37f06668ead446e2997f2b431db8963ce ] The test waits for coredump to finish by busy-waiting for the stack_values file to be created. The maximum wait time is 10 seconds. This doesn't work for slow machine (qemu-system-riscv64), because coredump takes longer. Fix it by waiting for the crashing child process to finish first. Fixes: 15858da53542 ("selftests: coredump: Add stackdump test") Signed-off-by: Nam Cao Link: https://lore.kernel.org/ee657f3fc8e19657cf7aaa366552d6347728f371.1744383419.git.namcao@linutronix.de Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit d9b9da94022620c531094ef2bff78449cc72610e Author: Nam Cao Date: Fri Apr 11 17:09:41 2025 +0200 selftests: coredump: Properly initialize pointer [ Upstream commit e194d2067c958827810a7a7282dff8773633ad8c ] The buffer pointer "line" is not initialized. This pointer is passed to getline(). It can still work if the stack is zero-initialized, because getline() can work with a NULL pointer as buffer. But this is obviously broken. This bug shows up while running the test on a riscv64 machine. Fix it by properly initializing the pointer. Fixes: 15858da53542 ("selftests: coredump: Add stackdump test") Signed-off-by: Nam Cao Link: https://lore.kernel.org/4fb9b6fb3e0040481bacc258c44b4aab5c4df35d.1744383419.git.namcao@linutronix.de Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit f6e90139f79ff024c98bb0fa2b53c2686098ed9f Author: Annie Li Date: Wed Apr 30 05:34:24 2025 +0000 x86/microcode/AMD: Do not return error when microcode update is not necessary [ Upstream commit b43dc4ab097859c24e2a6993119c927cffc856aa ] After 6f059e634dcd("x86/microcode: Clarify the late load logic"), if the load is up-to-date, the AMD side returns UCODE_OK which leads to load_late_locked() returning -EBADFD. Handle UCODE_OK in the switch case to avoid this error. [ bp: Massage commit message. ] Fixes: 6f059e634dcd ("x86/microcode: Clarify the late load logic") Signed-off-by: Annie Li Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/20250430053424.77438-1-jiayanli@google.com Signed-off-by: Sasha Levin commit d947affa9213ea28081048ce761700fc3957490e Author: John Stultz Date: Tue Apr 29 08:07:26 2025 -0700 sched/core: Tweak wait_task_inactive() to force dequeue sched_delayed tasks [ Upstream commit b7ca5743a2604156d6083b88cefacef983f3a3a6 ] It was reported that in 6.12, smpboot_create_threads() was taking much longer then in 6.6. I narrowed down the call path to: smpboot_create_threads() -> kthread_create_on_cpu() -> kthread_bind() -> __kthread_bind_mask() ->wait_task_inactive() Where in wait_task_inactive() we were regularly hitting the queued case, which sets a 1 tick timeout, which when called multiple times in a row, accumulates quickly into a long delay. I noticed disabling the DELAY_DEQUEUE sched feature recovered the performance, and it seems the newly create tasks are usually sched_delayed and left on the runqueue. So in wait_task_inactive() when we see the task p->se.sched_delayed, manually dequeue the sched_delayed task with DEQUEUE_DELAYED, so we don't have to constantly wait a tick. Fixes: 152e11f6df29 ("sched/fair: Implement delayed dequeue") Reported-by: peter-yc.chang@mediatek.com Signed-off-by: John Stultz Signed-off-by: Peter Zijlstra (Intel) Tested-by: K Prateek Nayak Link: https://lkml.kernel.org/r/20250429150736.3778580-1-jstultz@google.com Signed-off-by: Sasha Levin commit a0731b83e16111dcfa589f7d54aa042bb6fb8332 Author: Eddie James Date: Tue Feb 11 10:20:54 2025 -0600 powerpc/crash: Fix non-smp kexec preparation [ Upstream commit 882b25af265de8e05c66f72b9a29f6047102958f ] In non-smp configurations, crash_kexec_prepare is never called in the crash shutdown path. One result of this is that the crashing_cpu variable is never set, preventing crash_save_cpu from storing the NT_PRSTATUS elf note in the core dump. Fixes: c7255058b543 ("powerpc/crash: save cpu register data in crash_smp_send_stop()") Signed-off-by: Eddie James Reviewed-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250211162054.857762-1-eajames@linux.ibm.com Signed-off-by: Sasha Levin commit 409bcfdc5551e0454bfaacc141c39f51abc5d85d Author: Jiri Slaby (SUSE) Date: Thu Apr 17 12:53:05 2025 +0200 powerpc: do not build ppc_save_regs.o always [ Upstream commit 497b7794aef03d525a5be05ae78dd7137c6861a5 ] The Fixes commit below tried to add CONFIG_PPC_BOOK3S to one of the conditions to enable the build of ppc_save_regs.o. But it failed to do so, in fact. The commit omitted to add a dollar sign. Therefore, ppc_save_regs.o is built always these days (as "(CONFIG_PPC_BOOK3S)" is never an empty string). Fix this by adding the missing dollar sign. Signed-off-by: Jiri Slaby (SUSE) Fixes: fc2a5a6161a2 ("powerpc/64s: ppc_save_regs is now needed for all 64s builds") Acked-by: Stephen Rothwell Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250417105305.397128-1-jirislaby@kernel.org Signed-off-by: Sasha Levin commit f8af2bb62ef4e8217971e48683e5baf382cde212 Author: Corentin Labbe Date: Sun Apr 27 13:12:36 2025 +0200 crypto: sun8i-ss - do not use sg_dma_len before calling DMA functions [ Upstream commit 2dfc7cd74a5e062a5405560447517e7aab1c7341 ] When testing sun8i-ss with multi_v7_defconfig, all CBC algorithm fail crypto selftests. This is strange since on sunxi_defconfig, everything was ok. The problem was in the IV setup loop which never run because sg_dma_len was 0. Fixes: 359e893e8af4 ("crypto: sun8i-ss - rework handling of IV") Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4051250e5db489f8ad65fc337e2677b9b568ac72 Author: Ovidiu Panait Date: Fri Apr 25 15:45:14 2025 +0300 crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare() [ Upstream commit f31adc3e356f7350d4a4d68c98d3f60f2f6e26b3 ] Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare(): 1] If dma_map_sg() fails for areq->dst, the device driver would try to free DMA memory it has not allocated in the first place. To fix this, on the "theend_sgs" error path, call dma unmap only if the corresponding dma map was successful. 2] If the dma_map_single() call for the IV fails, the device driver would try to free an invalid DMA memory address on the "theend_iv" path: ------------[ cut here ]------------ DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90 Modules linked in: skcipher_example(O+) CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G O 6.15.0-rc3+ #24 PREEMPT Tainted: [O]=OOT_MODULE Hardware name: OrangePi Zero2 (DT) pc : check_unmap+0x123c/0x1b90 lr : check_unmap+0x123c/0x1b90 ... Call trace: check_unmap+0x123c/0x1b90 (P) debug_dma_unmap_page+0xac/0xc0 dma_unmap_page_attrs+0x1f4/0x5fc sun8i_ce_cipher_do_one+0x1bd4/0x1f40 crypto_pump_work+0x334/0x6e0 kthread_worker_fn+0x21c/0x438 kthread+0x374/0x664 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- To fix this, check for !dma_mapping_error() before calling dma_unmap_single() on the "theend_iv" path. Fixes: 06f751b61329 ("crypto: allwinner - Add sun8i-ce Crypto Engine") Signed-off-by: Ovidiu Panait Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2c350809b8090723b4c9d62906f0d62509ee6571 Author: Qing Wang Date: Sat Apr 5 22:16:35 2025 +0800 perf/core: Fix broken throttling when max_samples_per_tick=1 [ Upstream commit f51972e6f8b9a737b2b3eb588069acb538fa72de ] According to the throttling mechanism, the pmu interrupts number can not exceed the max_samples_per_tick in one tick. But this mechanism is ineffective when max_samples_per_tick=1, because the throttling check is skipped during the first interrupt and only performed when the second interrupt arrives. Perhaps this bug may cause little influence in one tick, but if in a larger time scale, the problem can not be underestimated. When max_samples_per_tick = 1: Allowed-interrupts-per-second max-samples-per-second default-HZ ARCH 200 100 100 X86 500 250 250 ARM64 ... Obviously, the pmu interrupt number far exceed the user's expect. Fixes: e050e3f0a71b ("perf: Fix broken interrupt rate throttling") Signed-off-by: Qing Wang Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20250405141635.243786-3-wangqing7171@gmail.com Signed-off-by: Sasha Levin commit 7887a8e503de6a09ea6d02993aca77037f969466 Author: Andreas Gruenbacher Date: Fri Apr 18 16:41:52 2025 +0200 gfs2: deallocate inodes in gfs2_create_inode [ Upstream commit 2c63986dd35fa9eb0d7d1530b5eb2244b7296e22 ] When creating and destroying inodes, we are relying on the inode hash table to make sure that for a given inode number, only a single inode will exist. We then link that inode to its inode and iopen glock and let those glocks point back at the inode. However, when iget_failed() is called, the inode is removed from the inode hash table before gfs_evict_inode() is called, and uniqueness is no longer guaranteed. Commit f1046a472b70 ("gfs2: gl_object races fix") was trying to work around that problem by detaching the inode glock from the inode before calling iget_failed(), but that broke the inode deallocation code in gfs_evict_inode(). To fix that, deallocate partially created inodes in gfs2_create_inode() instead of relying on gfs_evict_inode() for doing that. This means that gfs2_evict_inode() and its helper functions will no longer see partially created inodes, and so some simplifications are possible there. Fixes: 9ffa18884cce ("gfs2: gl_object races fix") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit b94c3058f1c1d4355398ede8c12917ecf581599a Author: Andreas Gruenbacher Date: Fri Apr 18 01:09:32 2025 +0200 gfs2: Move GIF_ALLOC_FAILED check out of gfs2_ea_dealloc [ Upstream commit 0cc617a54dfe6b44624c9a03e2e11a24eb9bc720 ] Don't check for the GIF_ALLOC_FAILED flag in gfs2_ea_dealloc() and pass that information explicitly instead. This allows for a cleaner follow-up patch. Signed-off-by: Andreas Gruenbacher Stable-dep-of: 2c63986dd35f ("gfs2: deallocate inodes in gfs2_create_inode") Signed-off-by: Sasha Levin commit 4ec522525263eb3eeb404a3a9ea36ed325c14d9a Author: Andreas Gruenbacher Date: Thu Apr 17 22:41:40 2025 +0200 gfs2: Move gfs2_dinode_dealloc [ Upstream commit bcd18105fb34e27c097f222733dba9a3e79f191c ] Move gfs2_dinode_dealloc() and its helper gfs2_final_release_pages() from super.c to inode.c. Signed-off-by: Andreas Gruenbacher Stable-dep-of: 2c63986dd35f ("gfs2: deallocate inodes in gfs2_create_inode") Signed-off-by: Sasha Levin commit 9fe47aaf495723ca33cec3d59d2687c741d26ded Author: Andreas Gruenbacher Date: Fri Apr 18 16:40:58 2025 +0200 gfs2: gfs2_create_inode error handling fix [ Upstream commit af4044fd0b77e915736527dd83011e46e6415f01 ] When gfs2_create_inode() finds a directory, make sure to return -EISDIR. Fixes: 571a4b57975a ("GFS2: bugger off early if O_CREAT open finds a directory") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 67c02d33ab1a091064861ecb6050a4012aaa073f Author: Andreas Gruenbacher Date: Sun Apr 6 00:31:37 2025 +0200 gfs2: replace sd_aspace with sd_inode [ Upstream commit ae9f3bd8259a0a8f67be2420e66bb05fbb95af48 ] Currently, sdp->sd_aspace and the per-inode metadata address spaces use sb->s_bdev->bd_mapping->host as their ->host; folios in those address spaces will thus appear to be on bdev rather than on gfs2 filesystems. This is a problem because gfs2 doesn't support cgroup writeback (SB_I_CGROUPWB), but bdev does. Fix that by using a "dummy" gfs2 inode as ->host in those address spaces. When coming from a folio, folio->mapping->host->i_sb will then be a gfs2 super block and the SB_I_CGROUPWB flag will not be set in sb->s_iflags. Based on a previous version from Bob Peterson from several years ago. Thanks to Tetsuo Handa, Jan Kara, and Rafael Aquini for helping figure this out. Fixes: aaa2cacf8184 ("writeback: add lockdep annotation to inode_to_wb()") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 4ad1035fd31ccb4b8831336712e010efbd0396e7 Author: Sandipan Das Date: Fri Apr 18 09:13:03 2025 +0530 perf/x86/amd/uncore: Prevent UMC counters from saturating [ Upstream commit 2492e5aba2be064d0604ae23ae0770ecc0168192 ] Unlike L3 and DF counters, UMC counters (PERF_CTRs) set the Overflow bit (bit 48) and saturate on overflow. A subsequent pmu->read() of the event reports an incorrect accumulated count as there is no difference between the previous and the current values of the counter. To avoid this, inspect the current counter value and proactively reset the corresponding PERF_CTR register on every pmu->read(). Combined with the periodic reads initiated by the hrtimer, the counters never get a chance saturate but the resolution reduces to 47 bits. Fixes: 25e56847821f ("perf/x86/amd/uncore: Add memory controller support") Signed-off-by: Sandipan Das Signed-off-by: Ingo Molnar Reviewed-by: Song Liu Acked-by: Peter Zijlstra Link: https://lore.kernel.org/r/dee9c8af2c6d66814cf4c6224529c144c620cf2c.1744906694.git.sandipan.das@amd.com Signed-off-by: Sasha Levin commit 323ceb7c6d356d87734ad2d3b733311e72b60163 Author: Sandipan Das Date: Fri Apr 18 09:12:59 2025 +0530 perf/x86/amd/uncore: Remove unused 'struct amd_uncore_ctx::node' member [ Upstream commit 4f81cc2d1bf91a49d33eb6578b58db2518deef01 ] Fixes: d6389d3ccc13 ("perf/x86/amd/uncore: Refactor uncore management") Signed-off-by: Sandipan Das Signed-off-by: Ingo Molnar Acked-by: Peter Zijlstra Link: https://lore.kernel.org/r/30f9254c2de6c4318dd0809ef85a1677f68eef10.1744906694.git.sandipan.das@amd.com Signed-off-by: Sasha Levin commit ff5b0a1302a8473b5d091e0b4f2322ebafa6b282 Author: David Gow Date: Wed Apr 16 17:38:25 2025 +0800 kunit: qemu_configs: Disable faulting tests on 32-bit SPARC [ Upstream commit 1d31d536871fe8b16c8c0de58d201c78e21eb3a2 ] The 32-bit sparc configuration (--arch sparc) crashes on the kunit_fault_test. It's known that some architectures don't handle deliberate segfaults in kernel mode well, so there's a config switch to disable tests which rely upon it by default. Use this for the sparc config, making sure the default config for it passes. Link: https://lore.kernel.org/r/20250416093826.1550040-1-davidgow@google.com Fixes: 87c9c1631788 ("kunit: tool: add support for QEMU") Signed-off-by: David Gow Reviewed-by: Thomas Weißschuh Tested-by: Thomas Weißschuh Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit a650f84d8c2c4b01576e796355c05b33a7d7d7f0 Author: Thomas Weißschuh Date: Tue Apr 15 15:38:05 2025 +0200 kunit: qemu_configs: sparc: Explicitly enable CONFIG_SPARC32=y [ Upstream commit d16b3d0fb43cb0f9eb21b35c2d2c870b3f38ab1d ] The configuration generated by kunit ends up with a 32bit configuration. A new kunit configuration for 64bit is to be added. To make the difference clearer spell out the variant in the kunit reference config. Link: https://lore.kernel.org/r/20250415-kunit-qemu-sparc64-v1-1-253906f61102@linutronix.de Signed-off-by: Thomas Weißschuh Reviewed-by: David Gow Signed-off-by: Shuah Khan Stable-dep-of: 1d31d536871f ("kunit: qemu_configs: Disable faulting tests on 32-bit SPARC") Signed-off-by: Sasha Levin commit d2c5e001aac2065e0b2c3be0ba38390898798eae Author: Herbert Xu Date: Sat Apr 12 18:57:22 2025 +0800 crypto: zynqmp-sha - Add locking [ Upstream commit c7e68043620e0d5f89a37e573c667beab72d2937 ] The hardwrae is only capable of one hash at a time, so add a lock to make sure that it isn't used concurrently. Fixes: 7ecc3e34474b ("crypto: xilinx - Add Xilinx SHA3 driver") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 40466ce607897f92a910ec2af67b3a543e0f4e2b Author: Lukas Wunner Date: Mon Apr 7 21:32:42 2025 +0200 crypto: ecdsa - Fix NIST P521 key size reported by KEYCTL_PKEY_QUERY [ Upstream commit 6b7f9397c98c72902f9364056413c73fe6dee1d8 ] When user space issues a KEYCTL_PKEY_QUERY system call for a NIST P521 key, the key_size is incorrectly reported as 528 bits instead of 521. That's because the key size obtained through crypto_sig_keysize() is in bytes and software_key_query() multiplies by 8 to yield the size in bits. The underlying assumption is that the key size is always a multiple of 8. With the recent addition of NIST P521, that's no longer the case. Fix by returning the key_size in bits from crypto_sig_keysize() and adjusting the calculations in software_key_query(). The ->key_size() callbacks of sig_alg algorithms now return the size in bits, whereas the ->digest_size() and ->max_size() callbacks return the size in bytes. This matches with the units in struct keyctl_pkey_query. Fixes: a7d45ba77d3d ("crypto: ecdsa - Register NIST P521 and extend test suite") Signed-off-by: Lukas Wunner Reviewed-by: Stefan Berger Reviewed-by: Ignat Korchagin Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e8bb8220006871b00adc125238094a2451cfde7a Author: Lukas Wunner Date: Mon Apr 7 21:32:41 2025 +0200 crypto: ecdsa - Fix enc/dec size reported by KEYCTL_PKEY_QUERY [ Upstream commit 3828485e1c7b111290122ab6e083c2a37132b5c2 ] KEYCTL_PKEY_QUERY system calls for ecdsa keys return the key size as max_enc_size and max_dec_size, even though such keys cannot be used for encryption/decryption. They're exclusively for signature generation or verification. Only rsa keys with pkcs1 encoding can also be used for encryption or decryption. Return 0 instead for ecdsa keys (as well as ecrdsa keys). Signed-off-by: Lukas Wunner Reviewed-by: Stefan Berger Reviewed-by: Ignat Korchagin Signed-off-by: Herbert Xu Stable-dep-of: 6b7f9397c98c ("crypto: ecdsa - Fix NIST P521 key size reported by KEYCTL_PKEY_QUERY") Signed-off-by: Sasha Levin commit e594f9ceef47d0888379d9d41f8236871988fbd0 Author: Peter Zijlstra Date: Wed Mar 19 22:23:23 2025 +0100 sched: Fix trace_sched_switch(.prev_state) [ Upstream commit 8feb053d53194382fcfb68231296fdc220497ea6 ] Gabriele noted that in case of signal_pending_state(), the tracepoint sees a stale task-state. Fixes: fa2c3254d7cf ("sched/tracing: Don't re-read p->state when emitting sched_switch event") Reported-by: Gabriele Monaco Signed-off-by: Peter Zijlstra (Intel) Cc: Valentin Schneider Signed-off-by: Sasha Levin commit 9fb9eb996d726df69a9e7eb144df648000e89963 Author: Ovidiu Panait Date: Tue Apr 1 22:23:16 2025 +0300 crypto: sun8i-ce-hash - fix error handling in sun8i_ce_hash_run() [ Upstream commit ea4dd134ef332bd9e3e734c1ba0a1521f436b678 ] Rework error handling in sun8i_ce_hash_run() to unmap the dma buffers in case of failure. Currently, the dma unmap functions are not called if the function errors out at various points. Fixes: 56f6d5aee88d1 ("crypto: sun8i-ce - support hash algorithms") Signed-off-by: Ovidiu Panait Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5b5c635e1a0a9d94ff09a509f886904fc5a2c77a Author: Herbert Xu Date: Mon Mar 24 12:04:18 2025 +0800 crypto: iaa - Do not clobber req->base.data [ Upstream commit cc98d8ce934b99789d30421957fd6a20fffb1c22 ] The req->base.data field is for the user and must not be touched by the driver, unless you save it first. The iaa driver doesn't seem to be using the req->base.data value so just remove the assignment. Fixes: 09646c98d0bf ("crypto: iaa - Add irq support for the crypto async interface") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit cc1e608ab5d78f4ab1081575923618b98033b65d Author: Andrew Cooper Date: Wed Apr 2 18:24:58 2025 +0100 x86/idle: Remove MFENCEs for X86_BUG_CLFLUSH_MONITOR in mwait_idle_with_hints() and prefer_mwait_c1_over_halt() [ Upstream commit 1f13c60d84e880df6698441026e64f84c7110c49 ] The following commit, 12 years ago: 7e98b7192046 ("x86, idle: Use static_cpu_has() for CLFLUSH workaround, add barriers") added barriers around the CLFLUSH in mwait_idle_with_hints(), justified with: ... and add memory barriers around it since the documentation is explicit that CLFLUSH is only ordered with respect to MFENCE. This also triggered, 11 years ago, the same adjustment in: f8e617f45829 ("sched/idle/x86: Optimize unnecessary mwait_idle() resched IPIs") during development, although it failed to get the static_cpu_has_bug() treatment. X86_BUG_CLFLUSH_MONITOR (a.k.a the AAI65 errata) is specific to Intel CPUs, and the SDM currently states: Executions of the CLFLUSH instruction are ordered with respect to each other and with respect to writes, locked read-modify-write instructions, and fence instructions[1]. With footnote 1 reading: Earlier versions of this manual specified that executions of the CLFLUSH instruction were ordered only by the MFENCE instruction. All processors implementing the CLFLUSH instruction also order it relative to the other operations enumerated above. i.e. The SDM was incorrect at the time, and barriers should not have been inserted. Double checking the original AAI65 errata (not available from intel.com any more) shows no mention of barriers either. Note: If this were a general codepath, the MFENCEs would be needed, because AMD CPUs of the same vintage do sport otherwise-unordered CLFLUSHs. Remove the unnecessary barriers. Furthermore, use a plain alternative(), rather than static_cpu_has_bug() and/or no optimisation. The workaround is a single instruction. Use an explicit %rax pointer rather than a general memory operand, because MONITOR takes the pointer implicitly in the same way. [ mingo: Cleaned up the commit a bit. ] Fixes: 7e98b7192046 ("x86, idle: Use static_cpu_has() for CLFLUSH workaround, add barriers") Signed-off-by: Andrew Cooper Signed-off-by: Ingo Molnar Acked-by: Dave Hansen Acked-by: Borislav Petkov (AMD) Cc: "H. Peter Anvin" Cc: Peter Zijlstra Cc: Rik van Riel Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Brian Gerst Cc: Juergen Gross Cc: Rafael J. Wysocki Link: https://lore.kernel.org/r/20250402172458.1378112-1-andrew.cooper3@citrix.com Signed-off-by: Sasha Levin commit 3931f9c8f830901bb12a94691c28d23a79fb55cc Author: Ahmed S. Darwish Date: Mon Mar 24 15:20:22 2025 +0100 tools/x86/kcpuid: Fix error handling [ Upstream commit 116edfe173d0c59ec2aa87fb91f2f31d477b61b3 ] Error handling in kcpuid is unreliable. On malloc() failures, the code prints an error then just goes on. The error messages are also printed to standard output instead of standard error. Use err() and errx() from to direct all error messages to standard error and automatically exit the program. Use err() to include the errno information, and errx() otherwise. Use warnx() for warnings. While at it, alphabetically reorder the header includes. [ mingo: Fix capitalization in the help text while at it. ] Fixes: c6b2f240bf8d ("tools/x86: Add a kcpuid tool to show raw CPU features") Reported-by: Remington Brasga Signed-off-by: Ahmed S. Darwish Signed-off-by: Ingo Molnar Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Josh Poimboeuf Link: https://lore.kernel.org/r/20250324142042.29010-2-darwi@linutronix.de Closes: https://lkml.kernel.org/r/20240926223557.2048-1-rbrasga@uci.edu Signed-off-by: Sasha Levin