commit b6f4f5d1d0bc739faaec609d122512270e84f541 Author: Alexandre Frade Date: Wed Mar 4 15:39:09 2026 +0000 Linux 6.18.16-rt-xanmod1 Signed-off-by: Alexandre Frade commit 992f810598f41d09055b0e41b0ec6c28440bc07d Author: Alexandre Frade Date: Wed Jan 7 22:19:29 2026 +0000 XANMOD: .gitlab-ci: Change to rt build jobs [6.18.16-xanmod1+] Signed-off-by: Alexandre Frade commit 9b005b5bcea651fc485ef3241d104eac99114240 Author: Alexandre Frade Date: Wed Mar 4 15:36:40 2026 +0000 Revert "XANMOD: .gitlab-ci: Add x64v1 build job" This reverts commit b08c1bc8e691a2d215a433eb2be4cfaa7af1e716. commit 9a56296d6e89f9daa61b5a6601f78381a19072fc Merge: be4b851fc083 2d6f4902b79b Author: Alexandre Frade Date: Wed Mar 4 15:35:21 2026 +0000 Merge branch '6.18' into 6.18-rt commit be4b851fc0832f8a1414916367a0d054160b5775 Author: Alexandre Frade Date: Wed Mar 4 15:30:09 2026 +0000 Revert "XANMOD: .gitlab-ci: Change to rt build jobs" This reverts commit 8b3cf2ccd750f5c25b3d74c598985966f1304675. commit 2d6f4902b79b84527badd20b9f4367c986964fc0 Author: Alexandre Frade Date: Wed Mar 4 15:09:03 2026 +0000 Linux 6.18.16-xanmod1 Signed-off-by: Alexandre Frade commit 4ca2a06e81fe0b621760354539f50a547901df2c Merge: da178b638723 6258e292d746 Author: Alexandre Frade Date: Wed Mar 4 15:08:15 2026 +0000 Merge tag 'v6.18.16' into 6.18 Linux 6.18.16 commit 6258e292d7463f96d0f06dff2a39093a54c9d16f Author: Sasha Levin Date: Wed Mar 4 07:24:37 2026 -0500 Linux 6.18.16 Signed-off-by: Sasha Levin Tested-by: Hardik Garg Tested-by: Miguel Ojeda Tested-by: Shuah Khan Tested-by: Mark Brown Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Barry K. Nathan Tested-by: Shung-Hsi Yu Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Justin M. Forbes Tested-by: Brett Mastbergen Tested-by: Brett A C Sheffield commit 0ac822bf990244874a4f8c1cbbc5857f9f8458be Author: Srinivasan Shanmugam Date: Fri Jan 9 18:01:23 2026 +0530 drm/amdgpu: Refactor amdgpu_gem_va_ioctl for Handling Last Fence Update and Timeline Management v7 [ Upstream commit efdc66fe12b07e7b7d28650bd8d4f7e3bb92c5d4 ] When GPU memory mappings are updated, the driver returns a fence so userspace knows when the update is finished. The previous refactor could pick the wrong fence or rely on checks that are not safe for GPU mappings that stay valid even when memory is missing. In some cases this could return an invalid fence or cause fence reference counting problems. Fix this by (v5,v6, per Christian): - Starting from the VM’s existing last update fence, so a valid and meaningful fence is always returned even when no new work is required. - Selecting the VM-level fence only for always-valid / PRT mappings using the required combined bo_va + bo guard. - Using the per-BO page table update fence for normal MAP and REPLACE operations. - For UNMAP and CLEAR, returning the fence provided by amdgpu_vm_clear_freed(), which may remain unchanged when nothing needs clearing. - Keeping fence reference counting balanced. v7: Drop the extra bo_va/bo NULL guard since amdgpu_vm_is_bo_always_valid() handles NULL BOs correctly (including PRT). (Christian) This makes VM timeline fences correct and prevents crashes caused by incorrect fence handling. Fixes: bd8150a1b337 ("drm/amdgpu: Refactor amdgpu_gem_va_ioctl for Handling Last Fence Update and Timeline Management v4") Suggested-by: Christian König Signed-off-by: Srinivasan Shanmugam Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f1ba620f9e8d7291f80c0554e4b820f5fb30e819 Author: Johan Hovold Date: Fri Jan 16 17:29:50 2026 +0100 most: core: fix leak on early registration failure [ Upstream commit 2c198c272f9c9213b0fdf6b4a879f445c574f416 ] A recent commit fixed a resource leak on early registration failures but for some reason left out the first error path which still leaks the resources associated with the interface. Fix up also the first error path so that the interface is always released on errors. Fixes: 1f4c9d8a1021 ("most: core: fix resource leak in most_register_interface error paths") Fixes: 723de0f9171e ("staging: most: remove device from interface structure") Cc: Christian Gromm Cc: Navaneeth K Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260116162950.21578-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c954666a0707966400f81de65b79de1fd96ada25 Author: Marc Zyngier Date: Thu Feb 26 08:22:32 2026 +0000 arm64: Fix sampling the "stable" virtual counter in preemptible section [ Upstream commit e5cb94ba5f96d691d8885175d4696d6ae6bc5ec9 ] Ben reports that when running with CONFIG_DEBUG_PREEMPT, using __arch_counter_get_cntvct_stable() results in well deserves warnings, as we access a per-CPU variable without preemption disabled. Fix the issue by disabling preemption on reading the counter. We can probably do a lot better by not disabling preemption on systems that do not require horrible workarounds to return a valid counter value, but this plugs the issue for the time being. Fixes: 29cc0f3aa7c6 ("arm64: Force the use of CNTVCT_EL0 in __delay()") Reported-by: Ben Horgan Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/aZw3EGs4rbQvbAzV@e134344.arm.com Tested-by: Ben Horgan Tested-by: André Draszik Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 164f57cd0ac86d26a062a0befc80042d866dfbff Author: Darrick J. Wong Date: Wed Feb 18 15:25:35 2026 -0800 xfs: fix copy-paste error in previous fix [ Upstream commit e764dd439d68cfc16724e469db390d779ab49521 ] Chris Mason noticed that there is a copy-paste error in a recent change to xrep_dir_teardown that nulls out pointers after freeing the resources. Fixes: ba408d299a3bb3c ("xfs: only call xf{array,blob}_destroy if we have a valid pointer") Link: https://lore.kernel.org/linux-xfs/20260205194211.2307232-1-clm@meta.com/ Reported-by: Chris Mason Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin commit ea39bac434c51f6502256baaac9bb9a46c4df144 Author: Jani Nikula Date: Mon Dec 15 14:09:08 2025 +0200 drm/i915/wakeref: clean up INTEL_WAKEREF_PUT_* flag macros [ Upstream commit 524696a19e34598c9173fdd5b32fb7e5d16a91d3 ] Commit 469c1c9eb6c9 ("kernel-doc: Issue warnings that were silently discarded") started emitting warnings for cases that were previously silently discarded. One such case is in intel_wakeref.h: Warning: drivers/gpu/drm/i915/intel_wakeref.h:156 expecting prototype for __intel_wakeref_put(). Prototype was for INTEL_WAKEREF_PUT_ASYNC() instead Arguably kernel-doc should be able to handle this, as it's valid C, but having the flags defined between the function declarator and the body is just asking for trouble. Move the INTEL_WAKEREF_PUT_* macros away from there, making kernel-doc's life easier. While at it, reduce the unnecessary abstraction levels by removing the enum, and append _MASK to INTEL_WAKEREF_PUT_DELAY for clarity. Cc: Andy Shevchenko Cc: Jonathan Corbet Acked-by: Randy Dunlap Tested-by: Randy Dunlap Link: https://patch.msgid.link/20251215120908.3515578-1-jani.nikula@intel.com Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit b0bc1aaf938d95c2d6bca423a86cbd953a676140 Author: Sasha Levin Date: Sat Feb 28 10:35:45 2026 -0500 Revert "ACPI: processor: Update cpuidle driver check in __acpi_processor_start()" This reverts commit 0089ce1c056aee547115bdc25c223f8f88c08498 which is upstream commit 6cfed39c2ce64ac024bbde458a9727105e0b8c66. This commit is causing a suspend regression on systems such as the Asus Zephyrus G14 (GA402RJ) with Ryzen 7 6700H: when suspending, the display turns off but the device fails to fully power down. This is not seen with v7.0-rc1 which indicates that there are changes missing. Therefore, revert this change. Link: https://lore.kernel.org/all/lA7Dz_m7_nCF8KkRyEOcSCLg799Mm9_DN2r9hx7ISjw32OoKiB1r_YjGHIFX8vgqxpOkVJ8d_yHb-VsGAvIWC942D4-zdWxAIP4_k6ZIQi8=@protonmail.com/ Fixes: 0089ce1c056a ("ACPI: processor: Update cpuidle driver check in __acpi_processor_start()") Reported-by: Athul Krishna Signed-off-by: Sasha Levin commit b9f13e55168c1602142f052a3dca33c65ff67440 Author: Nathan Chancellor Date: Tue Jan 6 16:08:18 2026 -0700 ALSA: pcm: Revert bufs move in snd_pcm_xfern_frames_ioctl() [ Upstream commit 0585c53b21541cd6b17ad5ab41b371a0d52e358c ] When building with clang older than 17 targeting architectures that use asm goto for their get_user() and put_user(), such as arm64, after commit f3d233daf011 ("ALSA: pcm: Relax __free() variable declarations"), there are bogus errors around skipping over a variable declared with the cleanup attribute: sound/core/pcm_native.c:3308:6: error: cannot jump from this asm goto statement to one of its possible targets if (put_user(result, &_xfern->result)) ^ ... arch/arm64/include/asm/uaccess.h:298:2: note: expanded from macro '__put_mem_asm' asm goto( ^ sound/core/pcm_native.c:3295:6: note: possible target of asm goto statement if (put_user(0, &_xfern->result)) ^ ... sound/core/pcm_native.c:3300:8: note: jump exits scope of variable with __attribute__((cleanup)) void *bufs __free(kfree) = ^ clang-17 fixed a bug in clang's jump scope checker [1] where all labels in a function were checked as valid targets for all asm goto instances in a function, regardless of whether they were actual targets in a paricular asm goto's provided list of labels. To workaround this, revert the change done to snd_pcm_xfern_frames_ioctl() by commit f3d233daf011 ("ALSA: pcm: Relax __free() variable declarations") to avoid a variable declared with cleanup from existing between multiple uses of asm goto. There are no other uses of cleanup in this function so there should be low risk from moving this variable back to the top of the function. Link: https://github.com/ClangBuiltLinux/linux/issues/1886 [1] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512190802.i4Jzbcsl-lkp@intel.com/ Signed-off-by: Nathan Chancellor Link: https://patch.msgid.link/20260106-pcm_native-revert-var-move-free-for-old-clang-v1-1-06a03693423d@kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6789db2c8e2fa12397f2fb1f2577142efd5513f5 Author: Koichiro Den Date: Wed Jan 7 13:24:57 2026 +0900 NTB: ntb_transport: Fix too small buffer for debugfs_name [ Upstream commit 6a4b50585d74fe45d3ade1e3e86ba8aae79761a5 ] The buffer used for "qp%d" was only 4 bytes, which truncates names like "qp10" to "qp1" and causes multiple queues to share the same directory. Enlarge the buffer and use sizeof() to avoid truncation. Fixes: fce8a7bb5b4b ("PCI-Express Non-Transparent Bridge Support") Cc: # v3.9+ Reviewed-by: Frank Li Reviewed-by: Dave Jiang Signed-off-by: Koichiro Den Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 358cb7055e03de6d84057287460eb05dd46a9069 Author: Philipp Stanner Date: Mon Feb 16 14:16:15 2026 +0100 rust: list: Add unsafe blocks for container_of and safety comments [ Upstream commit 97b281d7edb2ae662365be2809cd728470119720 ] impl_list_item_mod.rs calls container_of! without unsafe blocks at a couple of places. Since container_of! is unsafe, the blocks are strictly necessary. The problem was so far not visible because the "unsafe-op-in-unsafe-fn" check is a lint rather than a hard compiler error, and Rust suppresses lints triggered inside of a macro from another crate. Thus, the error becomes only visible once someone from within the kernel crate tries to use linked lists: error[E0133]: call to unsafe function `core::ptr::mut_ptr::::byte_sub` is unsafe and requires unsafe block --> rust/kernel/lib.rs:252:29 | 252 | let container_ptr = field_ptr.byte_sub(offset).cast::<$Container>(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function | ::: rust/kernel/drm/jq.rs:98:1 | 98 | / impl_list_item! { 99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; } 100 | | } | |_- in this macro invocation | note: an unsafe function restricts its caller, but its body is safe by default --> rust/kernel/list/impl_list_item_mod.rs:216:13 | 216 | unsafe fn view_value(me: *mut $crate::list::ListLinks<$num>) -> *const Self { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ::: rust/kernel/drm/jq.rs:98:1 | 98 | / impl_list_item! { 99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; } 100 | | } | |_- in this macro invocation = note: requested on the command line with `-D unsafe-op-in-unsafe-fn` = note: this error originates in the macro `$crate::container_of` which comes from the expansion of the macro `impl_list_item` Therefore, add unsafe blocks to container_of! calls to fix the issue. [ As discussed, let's fix the build for those that want to use the macro within the `kernel` crate now and we can discuss the proper safety comments afterwards. Thus I removed the ones from the patch. However, we cannot just avoid the comments with `CLIPPY=1`, so I provided placeholders for now, like we did in the past. They were also needed for an `unsafe impl`. While I am not happy about it, it isn't worse than the current status (the comments were meant to be there), and at least this shows what is missing -- our pre-existing "good first issue" [1] may motivate new contributors to complete them properly. Finally, I moved one of the existing safety comments one line down so that Clippy could locate it. Link: https://github.com/Rust-for-Linux/linux/issues/351 [1] - Miguel ] Cc: stable@vger.kernel.org Fixes: c77f85b347dd ("rust: list: remove OFFSET constants") Suggested-by: Alice Ryhl Signed-off-by: Philipp Stanner Reviewed-by: Gary Guo Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260216131613.45344-3-phasta@kernel.org [ Fixed formatting. Reworded to fix the lint suppression explanation. Indent build error. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 49ffdc3589d82d410f134c75c739c4fb44c6a233 Author: Petr Pavlu Date: Thu Feb 19 17:27:02 2026 +0100 tracing: Wake up poll waiters for hist files when removing an event [ Upstream commit 9678e53179aa7e907360f5b5b275769008a69b80 ] The event_hist_poll() function attempts to verify whether an event file is being removed, but this check may not occur or could be unnecessarily delayed. This happens because hist_poll_wakeup() is currently invoked only from event_hist_trigger() when a hist command is triggered. If the event file is being removed, no associated hist command will be triggered and a waiter will be woken up only after an unrelated hist command is triggered. Fix the issue by adding a call to hist_poll_wakeup() in remove_event_file_dir() after setting the EVENT_FILE_FL_FREED flag. This ensures that a task polling on a hist file is woken up and receives EPOLLERR. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Cc: Tom Zanussi Acked-by: Masami Hiramatsu (Google) Link: https://patch.msgid.link/20260219162737.314231-3-petr.pavlu@suse.com Fixes: 1bd13edbbed6 ("tracing/hist: Add poll(POLLIN) support on hist file") Signed-off-by: Petr Pavlu Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit d4e45ca6db6786f40a72daf7a44bf54dcc237f31 Author: Petr Pavlu Date: Thu Feb 19 17:27:01 2026 +0100 tracing: Fix checking of freed trace_event_file for hist files [ Upstream commit f0a0da1f907e8488826d91c465f7967a56a95aca ] The event_hist_open() and event_hist_poll() functions currently retrieve a trace_event_file pointer from a file struct by invoking event_file_data(), which simply returns file->f_inode->i_private. The functions then check if the pointer is NULL to determine whether the event is still valid. This approach is flawed because i_private is assigned when an eventfs inode is allocated and remains set throughout its lifetime. Instead, the code should call event_file_file(), which checks for EVENT_FILE_FL_FREED. Using the incorrect access function may result in the code potentially opening a hist file for an event that is being removed or becoming stuck while polling on this file. Correct the access method to event_file_file() in both functions. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Cc: Tom Zanussi Link: https://patch.msgid.link/20260219162737.314231-2-petr.pavlu@suse.com Fixes: 1bd13edbbed6 ("tracing/hist: Add poll(POLLIN) support on hist file") Signed-off-by: Petr Pavlu Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit c71ea5a712339de402569f00d5af3f010ce786dc Author: Steven Rostedt Date: Wed Feb 18 10:42:44 2026 -0500 fgraph: Do not call handlers direct when not using ftrace_ops [ Upstream commit f4ff9f646a4d373f9e895c2f0073305da288bc0a ] The function graph tracer was modified to us the ftrace_ops of the function tracer. This simplified the code as well as allowed more features of the function graph tracer. Not all architectures were converted over as it required the implementation of HAVE_DYNAMIC_FTRACE_WITH_ARGS to implement. For those architectures, it still did it the old way where the function graph tracer handle was called by the function tracer trampoline. The handler then had to check the hash to see if the registered handlers wanted to be called by that function or not. In order to speed up the function graph tracer that used ftrace_ops, if only one callback was registered with function graph, it would call its function directly via a static call. Now, if the architecture does not support the use of using ftrace_ops and still has the ftrace function trampoline calling the function graph handler, then by doing a direct call it removes the check against the handler's hash (list of functions it wants callbacks to), and it may call that handler for functions that the handler did not request calls for. On 32bit x86, which does not support the ftrace_ops use with function graph tracer, it shows the issue: ~# trace-cmd start -p function -l schedule ~# trace-cmd show # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 2) * 11898.94 us | schedule(); 3) # 1783.041 us | schedule(); 1) | schedule() { ------------------------------------------ 1) bash-8369 => kworker-7669 ------------------------------------------ 1) | schedule() { ------------------------------------------ 1) kworker-7669 => bash-8369 ------------------------------------------ 1) + 97.004 us | } 1) | schedule() { [..] Now by starting the function tracer is another instance: ~# trace-cmd start -B foo -p function This causes the function graph tracer to trace all functions (because the function trace calls the function graph tracer for each on, and the function graph trace is doing a direct call): ~# trace-cmd show # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 1) 1.669 us | } /* preempt_count_sub */ 1) + 10.443 us | } /* _raw_spin_unlock_irqrestore */ 1) | tick_program_event() { 1) | clockevents_program_event() { 1) 1.044 us | ktime_get(); 1) 6.481 us | lapic_next_event(); 1) + 10.114 us | } 1) + 11.790 us | } 1) ! 181.223 us | } /* hrtimer_interrupt */ 1) ! 184.624 us | } /* __sysvec_apic_timer_interrupt */ 1) | irq_exit_rcu() { 1) 0.678 us | preempt_count_sub(); When it should still only be tracing the schedule() function. To fix this, add a macro FGRAPH_NO_DIRECT to be set to 0 when the architecture does not support function graph use of ftrace_ops, and set to 1 otherwise. Then use this macro to know to allow function graph tracer to call the handlers directly or not. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Mark Rutland Link: https://patch.msgid.link/20260218104244.5f14dade@gandalf.local.home Fixes: cc60ee813b503 ("function_graph: Use static_call and branch to optimize entry function") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 5026010110a5ad2268d8c23e1e286ab7c736f7ac Author: Masami Hiramatsu (Google) Date: Mon Feb 16 18:30:15 2026 +0900 tracing: ring-buffer: Fix to check event length before using [ Upstream commit 912b0ee248c529a4f45d1e7f568dc1adddbf2a4a ] Check the event length before adding it for accessing next index in rb_read_data_buffer(). Since this function is used for validating possibly broken ring buffers, the length of the event could be broken. In that case, the new event (e + len) can point a wrong address. To avoid invalid memory access at boot, check whether the length of each event is in the possible range before using it. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Fixes: 5f3b6e839f3c ("ring-buffer: Validate boot range memory events") Link: https://patch.msgid.link/177123421541.142205.9414352170164678966.stgit@devnote2 Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit bc77986f3cb7476637052edf2d87137fa39f153d Author: Daniil Dulov Date: Fri Feb 13 13:01:30 2026 +0300 ring-buffer: Fix possible dereference of uninitialized pointer [ Upstream commit f1547779402c4cd67755c33616b7203baa88420b ] There is a pointer head_page in rb_meta_validate_events() which is not initialized at the beginning of a function. This pointer can be dereferenced if there is a failure during reader page validation. In this case the control is passed to "invalid" label where the pointer is dereferenced in a loop. To fix the issue initialize orig_head and head_page before calling rb_validate_buffer. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: stable@vger.kernel.org Reported-by: kernel test robot Reported-by: Dan Carpenter Acked-by: Masami Hiramatsu (Google) Link: https://patch.msgid.link/20260213100130.2013839-1-d.dulov@aladdin.ru Closes: https://lore.kernel.org/r/202406130130.JtTGRf7W-lkp@intel.com/ Fixes: 5f3b6e839f3c ("ring-buffer: Validate boot range memory events") Signed-off-by: Daniil Dulov Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit c692db813a7e3b7c3c17d6e9a3ad2a018bf1142b Author: Michael Thalmeier Date: Wed Feb 18 09:30:00 2026 +0100 net: nfc: nci: Fix parameter validation for packet data [ Upstream commit 571dcbeb8e635182bb825ae758399831805693c2 ] Since commit 9c328f54741b ("net: nfc: nci: Add parameter validation for packet data") communication with nci nfc chips is not working any more. The mentioned commit tries to fix access of uninitialized data, but failed to understand that in some cases the data packet is of variable length and can therefore not be compared to the maximum packet length given by the sizeof(struct). Fixes: 9c328f54741b ("net: nfc: nci: Add parameter validation for packet data") Cc: stable@vger.kernel.org Signed-off-by: Michael Thalmeier Reported-by: syzbot+740e04c2a93467a0f8c8@syzkaller.appspotmail.com Link: https://patch.msgid.link/20260218083000.301354-1-michael.thalmeier@hale.at Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b1e034af484a4b58a16af19d6777a2ce8d6fd24b Author: Alex Deucher Date: Mon Feb 16 10:02:32 2026 -0500 drm/amdgpu: keep vga memory on MacBooks with switchable graphics [ Upstream commit 096bb75e13cc508d3915b7604e356bcb12b17766 ] On Intel MacBookPros with switchable graphics, when the iGPU is enabled, the address of VRAM gets put at 0 in the dGPU's virtual address space. This is non-standard and seems to cause issues with the cursor if it ends up at 0. We have the framework to reserve memory at 0 in the address space, so enable it here if the vram start address is 0. Reviewed-and-tested-by: Mario Kleiner Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4302 Cc: stable@vger.kernel.org Cc: Mario Kleiner Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 832f430b6b33705e9cc80d1dddf20c89e88386f3 Author: Charlene Liu Date: Thu Feb 5 20:28:49 2026 -0500 drm/amd/display: Correct logic check error for fastboot [ Upstream commit b6a65009e7ce3f0cc72da18f186adb60717b51a0 ] [Why] Fix fastboot broken in driver. This is caused by an open source backport change 7495962c. from the comment, the intended check is to disable fastboot for pre-DCN10. but the logic check is reversed, and causes fastboot to be disabled on all DCN10 and after. fastboot is for driver trying to pick up bios used hw setting and bypass reprogramming the hw if dc_validate_boot_timing() condition meets. Fixes: 7495962cbceb ("drm/amd/display: Disable fastboot on DCE 6 too") Cc: stable@vger.kernel.org Reviewed-by: Mario Limonciello Reviewed-by: Ovidiu Bunea Signed-off-by: Charlene Liu Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 53002567af57b3624e3dcf5df683ddaa1a69e8e4 Author: Marc Zyngier Date: Fri Feb 13 14:16:19 2026 +0000 arm64: Force the use of CNTVCT_EL0 in __delay() [ Upstream commit 29cc0f3aa7c64d3b3cb9d94c0a0984ba6717bf72 ] Quentin forwards a report from Hyesoo Yu, describing an interesting problem with the use of WFxT in __delay() when a vcpu is loaded and that KVM is *not* in VHE mode (either nVHE or hVHE). In this case, CNTVOFF_EL2 is set to a non-zero value to reflect the state of the guest virtual counter. At the same time, __delay() is using get_cycles() to read the counter value, which is indirected to reading CNTPCT_EL0. The core of the issue is that WFxT is using the *virtual* counter, while the kernel is using the physical counter, and that the offset introduces a really bad discrepancy between the two. Fix this by forcing the use of CNTVCT_EL0, making __delay() consistent irrespective of the value of CNTVOFF_EL2. Reported-by: Hyesoo Yu Reported-by: Quentin Perret Reviewed-by: Quentin Perret Fixes: 7d26b0516a0d ("arm64: Use WFxT for __delay() when possible") Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/ktosachvft2cgqd5qkukn275ugmhy6xrhxur4zqpdxlfr3qh5h@o3zrfnsq63od Cc: stable@vger.kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 0ec0156b3fa6a4cac18239d475dec1033953e816 Author: Benno Lossin Date: Sun Feb 15 14:22:30 2026 +0100 rust: pin-init: replace clippy `expect` with `allow` [ Upstream commit a58b8764aed9648357b1c5b6368c9943ba33b7f9 ] `clippy` has changed behavior in [1] (Rust 1.95) where it no longer warns about the `let_and_return` lint when a comment is placed between the let binding and the return expression. Nightly thus fails to build, because the expectation is no longer fulfilled. Thus replace the expectation with an `allow`. [ The errors were: error: this lint expectation is unfulfilled --> rust/pin-init/src/lib.rs:1279:10 | 1279 | #[expect(clippy::let_and_return)] | ^^^^^^^^^^^^^^^^^^^^^^ | = note: `-D unfulfilled-lint-expectations` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unfulfilled_lint_expectations)]` error: this lint expectation is unfulfilled --> rust/pin-init/src/lib.rs:1295:10 | 1295 | #[expect(clippy::let_and_return)] | ^^^^^^^^^^^^^^^^^^^^^^ - Miguel ] Link: https://github.com/rust-lang/rust-clippy/pull/16461 [1] Signed-off-by: Benno Lossin Cc: stable@vger.kernel.org # Needed in 6.18.y and later. Link: https://patch.msgid.link/20260215132232.1549861-1-lossin@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit dddc9e67fc4546674caae55ab97137adbf37d8d1 Author: Benno Lossin Date: Sat Feb 14 10:27:40 2026 +0100 rust: irq: add `'static` bounds to irq callbacks [ Upstream commit 621609f1e5ca43a75edd497dd1c28bd84aa66433 ] These callback functions take a generic `T` that is used in the body as the generic argument in `Registration` and `ThreadedRegistration`. Those types require `T: 'static`, but due to a compiler bug this requirement isn't propagated to the function. Thus add the bound. This was caught in the upstream Rust CI [1]. [ The three errors looked similar and will start appearing with Rust 1.95.0 (expected 2026-04-16). The first one was: error[E0310]: the parameter type `T` may not live long enough Error: --> rust/kernel/irq/request.rs:266:43 | 266 | let registration = unsafe { &*(ptr as *const Registration) }; | ^^^^^^^^^^^^^^^^^^^^^^ | | | the parameter type `T` must be valid for the static lifetime... | ...so that the type `T` will meet its required lifetime bounds | help: consider adding an explicit lifetime bound | 264 | unsafe extern "C" fn handle_irq_callback(_irq: i32, ptr: *mut c_void) -> c_uint { | +++++++++ - Miguel ] Link: https://github.com/rust-lang/rust/pull/149389 [1] Signed-off-by: Benno Lossin Cc: stable@vger.kernel.org Fixes: 29e16fcd67ee ("rust: irq: add &Device argument to irq callbacks") Reviewed-by: Gary Guo Reviewed-by: Daniel Almeida Acked-by: Danilo Krummrich Link: https://lore.kernel.org/rust-for-linux/20260217222425.8755-1-cole@unwrap.rs/ Link: https://patch.msgid.link/20260214092740.3201946-1-lossin@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit a94f096e28bfc7975163a6b80f1c8f323efe317a Author: Kai Aizen Date: Wed Feb 18 17:36:41 2026 +0000 io_uring/zcrx: fix user_ref race between scrub and refill paths [ Upstream commit 003049b1c4fb8aabb93febb7d1e49004f6ad653b ] The io_zcrx_put_niov_uref() function uses a non-atomic check-then-decrement pattern (atomic_read followed by separate atomic_dec) to manipulate user_refs. This is serialized against other callers by rq_lock, but io_zcrx_scrub() modifies the same counter with atomic_xchg() WITHOUT holding rq_lock. On SMP systems, the following race exists: CPU0 (refill, holds rq_lock) CPU1 (scrub, no rq_lock) put_niov_uref: atomic_read(uref) - 1 // window opens atomic_xchg(uref, 0) - 1 return_niov_freelist(niov) [PUSH #1] // window closes atomic_dec(uref) - wraps to -1 returns true return_niov(niov) return_niov_freelist(niov) [PUSH #2: DOUBLE-FREE] The same niov is pushed to the freelist twice, causing free_count to exceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds write (a u32 value) past the kvmalloc'd freelist array into the adjacent slab object. Fix this by replacing the non-atomic read-then-dec in io_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically tests and decrements user_refs. This makes the operation safe against concurrent atomic_xchg from scrub without requiring scrub to acquire rq_lock. Fixes: 34a3e60821ab ("io_uring/zcrx: implement zerocopy receive pp memory provider") Cc: stable@vger.kernel.org Signed-off-by: Kai Aizen [pavel: removed a warning and a comment] Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 581a8f0f3338b0f3c411479a1d6b6b7abf658469 Author: Ard Biesheuvel Date: Tue Feb 17 12:09:35 2026 +0100 x86/kexec: Copy ACPI root pointer address from config table [ Upstream commit e00ac9e5afb5d80c0168ec88d8e8662a54af8249 ] Dave reports that kexec may fail when the first kernel boots via the EFI stub but without EFI runtime services, as in that case, the RSDP address field in struct bootparams is never assigned. Kexec copies this value into the version of struct bootparams that it provides to the incoming kernel, which may have no other means to locate the ACPI root pointer. So take the value from the EFI config tables if no root pointer has been set in the first kernel's struct bootparams. Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot") Cc: # v6.1 Reported-by: Dave Young Tested-by: Dave Young Link: https://lore.kernel.org/linux-efi/aZQg_tRQmdKNadCg@darkstar.users.ipa.redhat.com/ Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 54f463494eb5bf193ef7d904a493474c451734df Author: Bartosz Golaszewski Date: Thu Feb 12 14:35:05 2026 +0100 gpio: sysfs: fix chip removal with GPIOs exported over sysfs [ Upstream commit 6766f59012301f1bf3f46c6e7149caca45d92309 ] Currently if we export a GPIO over sysfs and unbind the parent GPIO controller, the exported attribute will remain under /sys/class/gpio because once we remove the parent device, we can no longer associate the descriptor with it in gpiod_unexport() and never drop the final reference. Rework the teardown code: provide an unlocked variant of gpiod_unexport() and remove all exported GPIOs with the sysfs_lock taken before unregistering the parent device itself. This is done to prevent any new exports happening before we unregister the device completely. Cc: stable@vger.kernel.org Fixes: 1cd53df733c2 ("gpio: sysfs: don't look up exported lines as class devices") Link: https://patch.msgid.link/20260212133505.81516-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 4ece5eb4836f8ff03b9004dc2430a7169f282851 Author: Ruitong Liu Date: Sat Feb 14 01:59:48 2026 +0800 net/sched: act_skbedit: fix divide-by-zero in tcf_skbedit_hash() [ Upstream commit be054cc66f739a9ba615dba9012a07fab8e7dd6f ] Commit 38a6f0865796 ("net: sched: support hash selecting tx queue") added SKBEDIT_F_TXQ_SKBHASH support. The inclusive range size is computed as: mapping_mod = queue_mapping_max - queue_mapping + 1; The range size can be 65536 when the requested range covers all possible u16 queue IDs (e.g. queue_mapping=0 and queue_mapping_max=U16_MAX). That value cannot be represented in a u16 and previously wrapped to 0, so tcf_skbedit_hash() could trigger a divide-by-zero: queue_mapping += skb_get_hash(skb) % params->mapping_mod; Compute mapping_mod in a wider type and reject ranges larger than U16_MAX to prevent params->mapping_mod from becoming 0 and avoid the crash. Fixes: 38a6f0865796 ("net: sched: support hash selecting tx queue") Cc: stable@vger.kernel.org # 6.12+ Signed-off-by: Ruitong Liu Link: https://patch.msgid.link/20260213175948.1505257-1-cnitlrt@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1b1d3c5d58a80a19d017a409aa2308162bab5bbf Author: Thomas Fourier Date: Fri Feb 13 17:43:39 2026 +0100 net: ethernet: ec_bhf: Fix dma_free_coherent() dma handle [ Upstream commit ffe68c3766997d82e9ccaf1cdbd47eba269c4aa2 ] dma_free_coherent() in error path takes priv->rx_buf.alloc_len as the dma handle. This would lead to improper unmapping of the buffer. Change the dma handle to priv->rx_buf.alloc_phys. Fixes: 6af55ff52b02 ("Driver for Beckhoff CX5020 EtherCAT master module.") Cc: Signed-off-by: Thomas Fourier Link: https://patch.msgid.link/20260213164340.77272-2-fourier.thomas@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ffba51100ff61792fefbae11ca38ac1987a818dd Author: Jia Yao Date: Thu Feb 5 16:15:29 2026 +0000 drm/xe: Add bounds check on pat_index to prevent OOB kernel read in madvise [ Upstream commit fbbe32618e97eff81577a01eb7d9adcd64a216d7 ] When user provides a bogus pat_index value through the madvise IOCTL, the xe_pat_index_get_coh_mode() function performs an array access without validating bounds. This allows a malicious user to trigger an out-of-bounds kernel read from the xe->pat.table array. The vulnerability exists because the validation in madvise_args_are_sane() directly calls xe_pat_index_get_coh_mode(xe, args->pat_index.val) without first checking if pat_index is within [0, xe->pat.n_entries). Although xe_pat_index_get_coh_mode() has a WARN_ON to catch this in debug builds, it still performs the unsafe array access in production kernels. v2(Matthew Auld) - Using array_index_nospec() to mitigate spectre attacks when the value is used v3(Matthew Auld) - Put the declarations at the start of the block Fixes: ada7486c5668 ("drm/xe: Implement madvise ioctl for xe") Reviewed-by: Matthew Auld Cc: # v6.18+ Cc: Matthew Brost Cc: Shuicheng Lin Cc: Himal Prasad Ghimiray Cc: "Thomas Hellström" Cc: Rodrigo Vivi Cc: Matthew Auld Signed-off-by: Jia Yao Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260205161529.1819276-1-jia.yao@intel.com (cherry picked from commit 944a3329b05510d55c69c2ef455136e2fc02de29) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit ea33c43c2e403ae0a627a67613ed14f90bbebca0 Author: Nathan Chancellor Date: Mon Feb 16 16:29:54 2026 -0700 kbuild: rpm-pkg: Disable automatic requires for manual debuginfo package [ Upstream commit f94711255a73d8938cf3bb405a0af3a4d2700ed1 ] Stefano reports that after commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually"), building with an rpm package using rpm 4.20.0 fails with: RPM build errors: Dependency tokens must begin with alpha-numeric, '_' or '/': #�) = 0x0d000002 Dependency tokens must begin with alpha-numeric, '_' or '/': �) = 0x0d000000 Dependency tokens must begin with alpha-numeric, '_' or '/': ) = 0x7c0e000000 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) = 0x3130363230322000 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) = 0x4728203a43434800 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) = 0x3130363230322000 Unknown rich dependency op 'Hat': (Red Hat 15.2.1-7)) = 0x4728203a43434800 This error comes from the automatic requirements feature of rpm. The -debuginfo subpackage has no dependencies, so disable this feature with 'AutoReq: 0' for this subpackage, avoiding the error. This matches the official %_debug_template macro that rpm provides. While automatic provides should be default enabled, be explicit like %_debug_template does. Additionally, while in the area, add the manual debug information package to the Development/Debug group, further aligning with %_debug_template. Cc: stable@vger.kernel.org Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Reported-by: Stefano Garzarella Closes: https://lore.kernel.org/CAGxU2F7FFNgb781_A7a1oL63n9Oy8wsyWceKhUpeZ6mLk=focw@mail.gmail.com/ Tested-by: Stefano Garzarella Link: https://patch.msgid.link/20260216-improve-manual-debuginfo-template-v1-1-e584b3f8d3be@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit caa055b579cd49f4a50cb157a1b94a5d566d2b3d Author: Gustavo Salvini Date: Tue Feb 10 12:51:56 2026 -0300 ASoC: amd: yc: Add DMI quirk for ASUS Vivobook Pro 15X M6501RR [ Upstream commit ff9cadd1a2c0b2665b7377ac79540d66f212e7e3 ] The ASUS Vivobook Pro 15X (M6501RR) with AMD Ryzen 9 6900HX has an internal DMIC that is not detected without a DMI quirk entry, as the BIOS does not set the AcpDmicConnected ACPI _DSD property. Adding the DMI entry enables the ACP6x DMIC machine driver to probe successfully. Cc: stable@vger.kernel.org Signed-off-by: Gustavo Salvini Link: https://patch.msgid.link/20260210155156.29079-1-guspatagonico@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 422adc95ea9a8a68898fc349727da8611cf657b1 Author: Asbjørn Sloth Tønnesen Date: Mon Feb 16 10:27:18 2026 +0000 io_uring/cmd_net: fix too strict requirement on ioctl [ Upstream commit 600b665b903733bd60334e86031b157cc823ee55 ] Attempting SOCKET_URING_OP_SETSOCKOPT on an AF_NETLINK socket resulted in an -EOPNOTSUPP, as AF_NETLINK doesn't have an ioctl in its struct proto, but only in struct proto_ops. Prior to the blamed commit, io_uring_cmd_sock() only had two cmd_op operations, both requiring ioctl, thus the check was warranted. Since then, 4 new cmd_op operations have been added, none of which depend on ioctl. This patch moves the ioctl check, so it only applies to the original operations. AFAICT, the ioctl requirement was unintentional, and it wasn't visible in the blamed patch within 3 lines of context. Cc: stable@vger.kernel.org Fixes: a5d2f99aff6b ("io_uring/cmd: Introduce SOCKET_URING_OP_GETSOCKOPT") Signed-off-by: Asbjørn Sloth Tønnesen Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 89f3d2d5413514037f1e285f4bcfcf622b5b667e Author: Ethan Tidmore Date: Fri Feb 13 22:45:31 2026 -0600 gpio: nomadik: Add missing IS_ERR() check [ Upstream commit 58433885ee99e8c96757e82ccf6d50646c4dfe09 ] The function gpio_device_get_desc() can return an error pointer and is not checked for one. Add check for error pointer. Fixes: ddeb66d2cb10f ("gpio: nomadik: don't print out global GPIO numbers in debugfs callbacks") Cc: stable@vger.kernel.org Signed-off-by: Ethan Tidmore Link: https://patch.msgid.link/20260214044531.43539-1-ethantidmore06@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 7c9ce68192eef14c777cb6ce17155d2eb2431aea Author: Shyam Prasad N Date: Sat Feb 14 15:59:13 2026 +0530 cifs: some missing initializations on replay [ Upstream commit 14f66f44646333d2bfd7ece36585874fd72f8286 ] In several places in the code, we have a label to signify the start of the code where a request can be replayed if necessary. However, some of these places were missing the necessary reinitializations of certain local variables before replay. This change makes sure that these variables get initialized after the label. Cc: stable@vger.kernel.org Reported-by: Yuchan Nam Tested-by: Yuchan Nam Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Sasha Levin commit f1ae403324311e143ef20e53cf9a5f01e312f7c9 Author: Pavel Begunkov Date: Sat Feb 14 22:19:32 2026 +0000 io_uring/zcrx: fix sgtable leak on mapping failures [ Upstream commit a983aae397767e9da931128ff2b5bf9066513ce3 ] In an unlikely case when io_populate_area_dma() fails, which could only happen on a PAGE_POOL_32BIT_ARCH_WITH_64BIT_DMA machine, io_zcrx_map_area() will have an initialised and not freed table. It was supposed to be cleaned up in the error path, but !is_mapped prevents that. Fixes: 439a98b972fbb ("io_uring/zcrx: deduplicate area mapping") Cc: stable@vger.kernel.org Reported-by: Jens Axboe Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit bcf40ce4666507703216de00a45e56155cc56f4e Author: Thomas Zimmermann Date: Mon Feb 9 17:15:43 2026 +0100 fbcon: Remove struct fbcon_display.inverse [ Upstream commit 30baedeeeab524172abc0b58cb101e8df86b5be8 ] The field inverse in struct fbcon_display is unused. Remove it. Signed-off-by: Thomas Zimmermann Cc: # v6.0+ Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit c61afb99c8289b9cd61c514bffda1f95bfc78044 Author: René Rebe Date: Thu Feb 5 16:49:58 2026 +0100 fbdev: ffb: fix corrupted video output on Sun FFB1 [ Upstream commit b28da0d092461ac239ff034a8ac3129320177ba3 ] Fix Sun FFB1 corrupted video out ([1] and [2]) by disabling overlay and initializing window mode to a known state. The issue never appeared on my FFB2+/vertical nor Elite3D/M6. It could also depend on the PROM version. /SUNW,ffb@1e,0: FFB at 000001fc00000000, type 11, DAC pnum[236c] rev[10] manuf_rev[4] X (II) /dev/fb0: Detected FFB1, Z-buffer, Single-buffered. X (II) /dev/fb0: BT9068 (PAC1) ramdac detected (with normal cursor control) X (II) /dev/fb0: Detected Creator/Creator3D [1] https://www.instagram.com/p/DUTcSmSjSem/ [2] https://chaos.social/@ReneRebe/116023241660154102 Signed-off-by: René Rebe Cc: stable@kernel.org Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 69290f2d3999c5fa1a7f5d5593cfc5461fa3ee64 Author: Weigang He Date: Fri Jan 16 09:57:51 2026 +0000 fbdev: of: display_timing: fix refcount leak in of_get_display_timings() [ Upstream commit eacf9840ae1285a1ef47eb0ce16d786e542bd4d7 ] of_parse_phandle() returns a device_node with refcount incremented, which is stored in 'entry' and then copied to 'native_mode'. When the error paths at lines 184 or 192 jump to 'entryfail', native_mode's refcount is not decremented, causing a refcount leak. Fix this by changing the goto target from 'entryfail' to 'timingfail', which properly calls of_node_put(native_mode) before cleanup. Fixes: cc3f414cf2e4 ("video: add of helper for display timings/videomode") Cc: stable@vger.kernel.org Signed-off-by: Weigang He Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 40c1ff25025150ff6d7ec7ad441fcfd6d070ee76 Author: Thomas Fourier Date: Mon Jan 12 15:00:27 2026 +0100 fbdev: vt8500lcdfb: fix missing dma_free_coherent() [ Upstream commit 88b3b9924337336a31cefbe99a22ed09401be74a ] fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not freed if the error path is reached. Fixes: e7b995371fe1 ("video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb") Cc: Signed-off-by: Thomas Fourier Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 11a93180a70bb3095a9bd80d113d9277e30d9959 Author: Andrey Vatoropin Date: Wed Dec 17 09:11:05 2025 +0000 fbcon: check return value of con2fb_acquire_newinfo() [ Upstream commit 011a0502801c8536f64141a2b61362c14f456544 ] If fbcon_open() fails when called from con2fb_acquire_newinfo() then info->fbcon_par pointer remains NULL which is later dereferenced. Add check for return value of the function con2fb_acquire_newinfo() to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d1baa4ffa677 ("fbcon: set_con2fb_map fixes") Cc: stable@vger.kernel.org Signed-off-by: Andrey Vatoropin Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 0a08a7fa123c0c53d391833ad1c0757ee89d4ad2 Author: Hans de Goede Date: Sun Dec 21 17:57:40 2025 +0100 fbdev: Use device_create_with_groups() to fix sysfs groups registration race [ Upstream commit 68eeb0871e986ae5462439dae881e3a27bcef85f ] The fbdev sysfs attributes are registered after sending the uevent for the device creation, leaving a race window where e.g. udev rules may not be able to access the sysfs attributes because the registration is not done yet. Fix this by switching to device_create_with_groups(). This also results in a nice cleanup. After switching to device_create_with_groups() all that is left of fb_init_device() is setting the drvdata and that can be passed to device_create[_with_groups]() too. After which fb_init_device() can be completely removed. Dropping fb_init_device() + fb_cleanup_device() in turn allows removing fb_info.class_flag as they were the only user of this field. Fixes: 5fc830d6aca1 ("fbdev: Register sysfs groups through device_add_group") Cc: stable@vger.kernel.org Cc: Shixiong Ou Signed-off-by: Hans de Goede Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 861fb0cc95d5dd9225b3d594133ee0204ebe18fa Author: Cui Chao Date: Fri Feb 13 14:03:47 2026 +0800 mm: numa_memblks: Identify the accurate NUMA ID of CFMW [ Upstream commit f043a93fff9e3e3e648b6525483f59104b0819fa ] In some physical memory layout designs, the address space of CFMW (CXL Fixed Memory Window) resides between multiple segments of system memory belonging to the same NUMA node. In numa_cleanup_meminfo, these multiple segments of system memory are merged into a larger numa_memblk. When identifying which NUMA node the CFMW belongs to, it may be incorrectly assigned to the NUMA node of the merged system memory. When a CXL RAM region is created in userspace, the memory capacity of the newly created region is not added to the CFMW-dedicated NUMA node. Instead, it is accumulated into an existing NUMA node (e.g., NUMA0 containing RAM). This makes it impossible to clearly distinguish between the two types of memory, which may affect memory-tiering applications. Example memory layout: Physical address space: 0x00000000 - 0x1FFFFFFF System RAM (node0) 0x20000000 - 0x2FFFFFFF CXL CFMW (node2) 0x40000000 - 0x5FFFFFFF System RAM (node0) 0x60000000 - 0x7FFFFFFF System RAM (node1) After numa_cleanup_meminfo, the two node0 segments are merged into one: 0x00000000 - 0x5FFFFFFF System RAM (node0) // CFMW is inside the range 0x60000000 - 0x7FFFFFFF System RAM (node1) So the CFMW (0x20000000-0x2FFFFFFF) will be incorrectly assigned to node0. To address this scenario, accurately identifying the correct NUMA node can be achieved by checking whether the region belongs to both numa_meminfo and numa_reserved_meminfo. While this issue is only observed in a QEMU configuration, and no known end users are impacted by this problem, it is likely that some firmware implementation is leaving memory map holes in a CXL Fixed Memory Window. CXL hotplug depends on mapping free window capacity, and it seems to be only a coincidence to have not hit this problem yet. Fixes: 779dd20cfb56 ("cxl/region: Add region creation support") Signed-off-by: Cui Chao Cc: stable@vger.kernel.org Reviewed-by: Jonathan Cameron Reviewed-by: Gregory Price Reviewed-by: Dan Williams Link: https://patch.msgid.link/20260213060347.2389818-2-cuichao1753@phytium.com.cn Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit e90346a2f1e8917d5760a44a1f61c44e3b36d96b Author: Qanux Date: Wed Feb 11 12:04:12 2026 +0800 ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() [ Upstream commit 6db8b56eed62baacaf37486e83378a72635c04cc ] On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00). Fixes: 9ee11f0fff20 ("ipv6: ioam: Data plane support for Pre-allocated Trace") Cc: stable@vger.kernel.org Signed-off-by: Junxi Qian Reviewed-by: Justin Iurman Link: https://patch.msgid.link/20260211040412.86195-1-qjx1298677004@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3d01d8a2cc64ab0745c9454865da6493e0bb07d6 Author: Nathan Chancellor Date: Fri Feb 13 01:45:13 2026 -0500 kbuild: rpm-pkg: Fix manual debuginfo generation when using .src.rpm [ Upstream commit afdfb71c018e9a0aa2e51fb8186d3fb1acdd3f0e ] Commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") added uses of OBJCOPY and READELF, variables from Kbuild. These variables are defined and work properly when using the binrpm-pkg target because rpmbuild is run within Kbuild. However, these variables are not defined when building from a source RPM package generated with the srcrpm-pkg target, breaking the build when generating the debug info subpackage. Define a default value for these variables so that these commands respect the value from Kbuild but continue to work when built from a source RPM package. Cc: stable@vger.kernel.org Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Reported-by: Lukas Herbolt Closes: https://lore.kernel.org/20260212135855.147906-2-lukas@herbolt.com/ Tested-by: Lukas Herbolt Link: https://patch.msgid.link/20260213-fix-debuginfo-srcrpm-pkg-v1-1-45cd0c0501b9@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 39824c8ce0c257154a07d18e49ae6618094a31fa Author: Nathan Chancellor Date: Tue Feb 10 00:04:49 2026 -0700 kernel: rpm-pkg: Restore find-debuginfo.sh approach to -debuginfo package [ Upstream commit ffe9ac1ad56df8f915896b97bd7645f522c47ce9 ] Commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") effectively reverted commit a7c699d090a1 ("kbuild: rpm-pkg: build a debuginfo RPM") but the approach it took is not safe for older RPM releases. Restore commit a7c699d090a1 ("kbuild: rpm-pkg: build a debuginfo RPM") for the !CONFIG_MODULE_SIG case to allow more environments and configurations to take advantage of the separate debug information package process. Cc: stable@vger.kernel.org Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Tested-by: Stefano Garzarella Tested-by: Steve French Tested-by: Juergen Gross Acked-by: Nicolas Schier Link: https://patch.msgid.link/20260210-kbuild-fix-debuginfo-rpm-v1-2-0730b92b14bc@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 0ee1887b524ce14ce1e45031adfe8ee7eda3f072 Author: Nathan Chancellor Date: Tue Feb 10 00:04:48 2026 -0700 kbuild: rpm-pkg: Restrict manual debug package creation [ Upstream commit 6d6b8b0e28c468263d7fcb071e5cb284ae343df2 ] Commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") moved away from the built-in RPM machinery for generating -debuginfo packages to a more manual way to be compatible with module signing, as the built-in machinery strips the modules after the installation process, breaking the signatures. Unfortunately, prior to rpm 4.20.0, there is a bug where a custom %files directive is ignored for a -debuginfo subpackage [1], meaning builds using older versions of RPM (such as on RHEL9 or RHEL10) fail with: Checking for unpackaged file(s): /usr/lib/rpm/check-files .../rpmbuild/BUILDROOT/kernel-6.19.0_dirty-1.x86_64 error: Installed (but unpackaged) file(s) found: /debuginfo.list /usr/lib/debug/.build-id/09/748c214974bfba1522d434a7e0a02e2fd7f29b.debug /usr/lib/debug/.build-id/0b/b96dd9c7d3689d82e56d2e73b46f53103cc6c7.debug /usr/lib/debug/.build-id/0e/979a2f34967c7437fd30aabb41de1f0c8b6a66.debug ... To workaround this, restrict the manual debug info package creation process to when it is necessary (CONFIG_MODULE_SIG=y) and possible (when using RPM >= 4.20.0). A follow up change will restore the RPM debuginfo creation process using a separate internal flag to allow the package to be built in more situations, as RPM 4.20.0 is a fairly recent version and the built-in -debuginfo generation works fine when module signing is disabled. Cc: stable@vger.kernel.org Fixes: 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") Link: https://github.com/rpm-software-management/rpm/commit/49f906998f3cf1f4152162ca61ac0869251c380f [1] Reported-by: Steve French Closes: https://lore.kernel.org/CAH2r5mugbrHTwnaQwQiYEUVwbtqmvFYf0WZiLrrJWpgT8iwftw@mail.gmail.com/ Tested-by: Stefano Garzarella Tested-by: Steve French Tested-by: Juergen Gross Acked-by: Nicolas Schier Link: https://patch.msgid.link/20260210-kbuild-fix-debuginfo-rpm-v1-1-0730b92b14bc@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 972495bc37be3dea1848c0e31f0fb144385bbae4 Author: Mickaël Salaün Date: Thu Feb 12 14:35:43 2026 +0100 kbuild: Fix CC_CAN_LINK detection [ Upstream commit be55899b71630c79ad01df54c92e467e47644f87 ] Most samples cannot be build on some environments because they depend on CC_CAN_LINK, which is set according to the result of scripts/cc-can-link.sh called by cc_can_link_user. Because cc-can-link.sh must now build without warning, it may fail because it is calling printf() with an empty string: + cat + gcc -m32 -Werror -Wl,--fatal-warnings -x c - -o /dev/null : In function ‘main’: :4:9: error: zero-length gnu_printf format string [-Werror=format-zero-length] cc1: all warnings being treated as errors Fix this warning and the samples build by actually printing something. Cc: stable@vger.kernel.org Fixes: d81d9d389b9b ("kbuild: don't enable CC_CAN_LINK if the dummy program generates warnings") Signed-off-by: Mickaël Salaün Reviewed-by: Nicolas Schier Reviewed-by: Thomas Weißschuh Link: https://patch.msgid.link/20260212133544.1331437-1-mic@digikod.net Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit f8d02862e520baea496f9277aefbcadf95a25c8f Author: Shengming Hu Date: Fri Feb 13 14:29:32 2026 +0800 function_graph: Restore direct mode when callbacks drop to one [ Upstream commit 53b2fae90ff01fede6520ca744ed5e8e366497ba ] When registering a second fgraph callback, direct path is disabled and array loop is used instead. When ftrace_graph_active falls back to one, we try to re-enable direct mode via ftrace_graph_enable_direct(true, ...). But ftrace_graph_enable_direct() incorrectly disables the static key rather than enabling it. This leaves fgraph_do_direct permanently off after first multi-callback transition, so direct fast mode is never restored. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260213142932519cuWSpEXeS4-UnCvNXnK2P@zte.com.cn Fixes: cc60ee813b503 ("function_graph: Use static_call and branch to optimize entry function") Signed-off-by: Shengming Hu Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit e4ff4e3ffcf9d5aad380cdd1d8cdc008bb34f97d Author: Duoming Zhou Date: Tue Feb 10 17:45:37 2026 +0800 atm: fore200e: fix use-after-free in tasklets during device removal [ Upstream commit 8930878101cd40063888a68af73b1b0f8b6c79bc ] When the PCA-200E or SBA-200E adapter is being detached, the fore200e is deallocated. However, the tx_tasklet or rx_tasklet may still be running or pending, leading to use-after-free bug when the already freed fore200e is accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet(). One of the race conditions can occur as follows: CPU 0 (cleanup) | CPU 1 (tasklet) fore200e_pca_remove_one() | fore200e_interrupt() fore200e_shutdown() | tasklet_schedule() kfree(fore200e) | fore200e_tx_tasklet() | fore200e-> // UAF Fix this by ensuring tx_tasklet or rx_tasklet is properly canceled before the fore200e is released. Add tasklet_kill() in fore200e_shutdown() to synchronize with any pending or running tasklets. Moreover, since fore200e_reset() could prevent further interrupts or data transfers, the tasklet_kill() should be placed after fore200e_reset() to prevent the tasklet from being rescheduled in fore200e_interrupt(). Finally, it only needs to do tasklet_kill() when the fore200e state is greater than or equal to FORE200E_STATE_IRQ, since tasklets are uninitialized in earlier states. In a word, the tasklet_kill() should be placed in the FORE200E_STATE_IRQ branch within the switch...case structure. This bug was identified through static analysis. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@kernel.org Suggested-by: Jijie Shao Signed-off-by: Duoming Zhou Reviewed-by: Jijie Shao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260210094537.9767-1-duoming@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 41023fc00f3702f9a5fafcfbb2b39e8f5d8ef5ed Author: Ethan Nelson-Moore Date: Mon Feb 9 18:12:34 2026 -0800 net: intel: fix PCI device ID conflict between i40e and ipw2200 [ Upstream commit d03e094473ecdeb68d853752ba467abe13e1de44 ] The ID 8086:104f is matched by both i40e and ipw2200. The same device ID should not be in more than one driver, because in that case, which driver is used is unpredictable. Fix this by taking advantage of the fact that i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200 devices use PCI_CLASS_NETWORK_OTHER to differentiate the devices. Fixes: 2e45d3f4677a ("i40e: Add support for X710 B/P & SFP+ cards") Cc: stable@vger.kernel.org Acked-by: Johannes Berg Signed-off-by: Ethan Nelson-Moore Reviewed-by: Aleksandr Loktionov Link: https://patch.msgid.link/20260210021235.16315-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 23b82b7a26182ad840ae67d390d7ec9771e8c00f Author: Mikhail Gavrilov Date: Sat Feb 7 22:36:14 2026 +0500 mm/page_alloc: clear page->private in free_pages_prepare() [ Upstream commit ac1ea219590c09572ed5992dc233bbf7bb70fef9 ] Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use. Link: https://lkml.kernel.org/r/20260207173615.146159-1-mikhail.v.gavrilov@gmail.com Fixes: 3b8000ae185c ("mm/vmalloc: huge vmalloc backing pages should be split rather than compound") Signed-off-by: Mikhail Gavrilov Suggested-by: Zi Yan Acked-by: Zi Yan Acked-by: David Hildenbrand (Arm) Reviewed-by: Vlastimil Babka Cc: Brendan Jackman Cc: Chris Li Cc: Hugh Dickins Cc: Johannes Weiner Cc: Kairui Song Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Nicholas Piggin Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit e116e19c95845133a4f194dfad3678758d0b6689 Author: Bing Jiao Date: Wed Jan 14 20:53:02 2026 +0000 mm/vmscan: fix demotion targets checks in reclaim/demotion [ Upstream commit 1aceed565ff172fc0331dd1d5e7e65139b711139 ] Patch series "mm/vmscan: fix demotion targets checks in reclaim/demotion", v9. This patch series addresses two issues in demote_folio_list(), can_demote(), and next_demotion_node() in reclaim/demotion. 1. demote_folio_list() and can_demote() do not correctly check demotion target against cpuset.mems_effective, which will cause (a) pages to be demoted to not-allowed nodes and (b) pages fail demotion even if the system still has allowed demotion nodes. Patch 1 fixes this bug by updating cpuset_node_allowed() and mem_cgroup_node_allowed() to return effective_mems, allowing directly logic-and operation against demotion targets. 2. next_demotion_node() returns a preferred demotion target, but it does not check the node against allowed nodes. Patch 2 ensures that next_demotion_node() filters against the allowed node mask and selects the closest demotion target to the source node. This patch (of 2): Fix two bugs in demote_folio_list() and can_demote() due to incorrect demotion target checks against cpuset.mems_effective in reclaim/demotion. Commit 7d709f49babc ("vmscan,cgroup: apply mems_effective to reclaim") introduces the cpuset.mems_effective check and applies it to can_demote(). However: 1. It does not apply this check in demote_folio_list(), which leads to situations where pages are demoted to nodes that are explicitly excluded from the task's cpuset.mems. 2. It checks only the nodes in the immediate next demotion hierarchy and does not check all allowed demotion targets in can_demote(). This can cause pages to never be demoted if the nodes in the next demotion hierarchy are not set in mems_effective. These bugs break resource isolation provided by cpuset.mems. This is visible from userspace because pages can either fail to be demoted entirely or are demoted to nodes that are not allowed in multi-tier memory systems. To address these bugs, update cpuset_node_allowed() and mem_cgroup_node_allowed() to return effective_mems, allowing directly logic-and operation against demotion targets. Also update can_demote() and demote_folio_list() accordingly. Bug 1 reproduction: Assume a system with 4 nodes, where nodes 0-1 are top-tier and nodes 2-3 are far-tier memory. All nodes have equal capacity. Test script: echo 1 > /sys/kernel/mm/numa/demotion_enabled mkdir /sys/fs/cgroup/test echo +cpuset > /sys/fs/cgroup/cgroup.subtree_control echo "0-2" > /sys/fs/cgroup/test/cpuset.mems echo $$ > /sys/fs/cgroup/test/cgroup.procs swapoff -a # Expectation: Should respect node 0-2 limit. # Observation: Node 3 shows significant allocation (MemFree drops) stress-ng --oomable --vm 1 --vm-bytes 150% --mbind 0,1 Bug 2 reproduction: Assume a system with 6 nodes, where nodes 0-2 are top-tier, node 3 is a far-tier node, and nodes 4-5 are the farthest-tier nodes. All nodes have equal capacity. Test script: echo 1 > /sys/kernel/mm/numa/demotion_enabled mkdir /sys/fs/cgroup/test echo +cpuset > /sys/fs/cgroup/cgroup.subtree_control echo "0-2,4-5" > /sys/fs/cgroup/test/cpuset.mems echo $$ > /sys/fs/cgroup/test/cgroup.procs swapoff -a # Expectation: Pages are demoted to Nodes 4-5 # Observation: No pages are demoted before oom. stress-ng --oomable --vm 1 --vm-bytes 150% --mbind 0,1,2 Link: https://lkml.kernel.org/r/20260114205305.2869796-1-bingjiao@google.com Link: https://lkml.kernel.org/r/20260114205305.2869796-2-bingjiao@google.com Fixes: 7d709f49babc ("vmscan,cgroup: apply mems_effective to reclaim") Signed-off-by: Bing Jiao Acked-by: Shakeel Butt Cc: Axel Rasmussen Cc: David Hildenbrand Cc: Gregory Price Cc: Johannes Weiner Cc: Joshua Hahn Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Qi Zheng Cc: Roman Gushchin Cc: Suren Baghdasaryan Cc: Tejun Heo Cc: Vlastimil Babka Cc: Waiman Long Cc: Wei Xu Cc: Yuanchu Xie Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8adaff87db143583e08eec4f4e7788f1ef8af94d Author: Andrii Nakryiko Date: Tue Feb 10 11:27:38 2026 -0800 procfs: fix possible double mmput() in do_procmap_query() [ Upstream commit 61dc9f776705d6db6847c101b98fa4f0e9eb6fa3 ] When user provides incorrectly sized buffer for build ID for PROCMAP_QUERY we return with -ENAMETOOLONG error. After recent changes this condition happens later, after we unlocked mmap_lock/per-VMA lock and did mmput(), so original goto out is now wrong and will double-mmput() mm_struct. Fix by jumping further to clean up only vm_file and name_buf. Link: https://lkml.kernel.org/r/20260210192738.3041609-1-andrii@kernel.org Fixes: b5cbacd7f86f ("procfs: avoid fetching build ID while holding VMA lock") Signed-off-by: Andrii Nakryiko Reported-by: Ruikai Peng Reported-by: Thomas Gleixner Tested-by: Thomas Gleixner Reviewed-by: Shakeel Butt Reported-by: syzbot+237b5b985b78c1da9600@syzkaller.appspotmail.com Cc: Ruikai Peng Closes: https://lkml.kernel.org/r/CAFD3drOJANTZPuyiqMdqpiRwOKnHwv5QgMNZghCDr-WxdiHvMg@mail.gmail.com Closes: https://lore.kernel.org/all/698aaf3c.050a0220.3b3015.0088.GAE@google.com/T/#u Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit f64491066c662fd3cd8b5ebcd296879ea33dfb62 Author: Harry Yoo Date: Mon Feb 9 15:26:39 2026 +0900 mm/page_alloc: skip debug_check_no_{obj,locks}_freed with FPI_TRYLOCK [ Upstream commit 338ad1e84d15078a9ae46d7dd7466329ae0bfa61 ] When CONFIG_DEBUG_OBJECTS_FREE is enabled, debug_check_no_{obj,locks}_freed() functions are called. Since both of them spin on a lock, they are not safe to be called if the FPI_TRYLOCK flag is specified. This leads to a lockdep splat: ================================ WARNING: inconsistent lock state 6.19.0-rc5-slab-for-next+ #326 Tainted: G N -------------------------------- inconsistent {INITIAL USE} -> {IN-NMI} usage. kunit_try_catch/9046 [HC2[2]:SC0[0]:HE0:SE1] takes: ffffffff84ed6bf8 (&obj_hash[i].lock){-.-.}-{2:2}, at: __debug_check_no_obj_freed+0xe0/0x300 {INITIAL USE} state was registered at: lock_acquire+0xd9/0x2f0 _raw_spin_lock_irqsave+0x4c/0x80 __debug_object_init+0x9d/0x1f0 debug_object_init+0x34/0x50 __init_work+0x28/0x40 init_cgroup_housekeeping+0x151/0x210 init_cgroup_root+0x3d/0x140 cgroup_init_early+0x30/0x240 start_kernel+0x3e/0xcd0 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0xf3/0x140 common_startup_64+0x13e/0x148 irq event stamp: 2998 hardirqs last enabled at (2997): [] exc_nmi+0x11a/0x240 hardirqs last disabled at (2998): [] sysvec_irq_work+0x11/0x110 softirqs last enabled at (1416): [] __irq_exit_rcu+0x132/0x1c0 softirqs last disabled at (1303): [] __irq_exit_rcu+0x132/0x1c0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&obj_hash[i].lock); lock(&obj_hash[i].lock); *** DEADLOCK *** Rename free_pages_prepare() to __free_pages_prepare(), add an fpi_t parameter, and skip those checks if FPI_TRYLOCK is set. To keep the fpi_t definition in mm/page_alloc.c, add a wrapper function free_pages_prepare() that always passes FPI_NONE and use it in mm/compaction.c. Link: https://lkml.kernel.org/r/20260209062639.16577-1-harry.yoo@oracle.com Fixes: 8c57b687e833 ("mm, bpf: Introduce free_pages_nolock()") Signed-off-by: Harry Yoo Reviewed-by: Vlastimil Babka Acked-by: Zi Yan Cc: Alexei Starovoitov Cc: Brendan Jackman Cc: Johannes Weiner Cc: Michal Hocko Cc: Sebastian Andrzej Siewior Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 5eac1322a7b14b8cd05ec896618278b90fba7f39 Author: Joshua Hahn Date: Fri Jan 16 15:40:36 2026 -0500 mm/hugetlb: restore failed global reservations to subpool [ Upstream commit 1d3f9bb4c8af70304d19c22e30f5d16a2d589bb5 ] Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") fixed an underflow error for hstate->resv_huge_pages caused by incorrectly attributing globally requested pages to the subpool's reservation. Unfortunately, this fix also introduced the opposite problem, which would leave spool->used_hpages elevated if the globally requested pages could not be acquired. This is because while a subpool's reserve pages only accounts for what is requested and allocated from the subpool, its "used" counter keeps track of what is consumed in total, both from the subpool and globally. Thus, we need to adjust spool->used_hpages in the other direction, and make sure that globally requested pages are uncharged from the subpool's used counter. Each failed allocation attempt increments the used_hpages counter by how many pages were requested from the global pool. Ultimately, this renders the subpool unusable, as used_hpages approaches the max limit. The issue can be reproduced as follows: 1. Allocate 4 hugetlb pages 2. Create a hugetlb mount with max=4, min=2 3. Consume 2 pages globally 4. Request 3 pages from the subpool (2 from subpool + 1 from global) 4.1 hugepage_subpool_get_pages(spool, 3) succeeds. used_hpages += 3 4.2 hugetlb_acct_memory(h, 1) fails: no global pages left used_hpages -= 2 5. Subpool now has used_hpages = 1, despite not being able to successfully allocate any hugepages. It believes it can now only allocate 3 more hugepages, not 4. With each failed allocation attempt incrementing the used counter, the subpool eventually reaches a point where its used counter equals its max counter. At that point, any future allocations that try to allocate hugeTLB pages from the subpool will fail, despite the subpool not having any of its hugeTLB pages consumed by any user. Once this happens, there is no way to make the subpool usable again, since there is no way to decrement the used counter as no process is really consuming the hugeTLB pages. The underflow issue that the original commit fixes still remains fixed as well. Without this fix, used_hpages would keep on leaking if hugetlb_acct_memory() fails. Link: https://lkml.kernel.org/r/20260116204037.2270096-1-joshua.hahnjy@gmail.com Fixes: a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") Signed-off-by: Joshua Hahn Acked-by: Usama Arif Cc: David Hildenbrand Cc: "Liam R. Howlett" Cc: Lorenzo Stoakes Cc: Ma Wupeng Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Oscar Salvador Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Waiman Long Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 89a9389ad70d3c69538e59d87df67d407aef4c26 Author: Pierre-Eric Pelloux-Prayer Date: Mon Feb 9 18:54:45 2026 +0100 drm/amdgpu: fix sync handling in amdgpu_dma_buf_move_notify [ Upstream commit b18fc0ab837381c1a6ef28386602cd888f2d9edf ] Invalidating a dmabuf will impact other users of the shared BO. In the scenario where process A moves the BO, it needs to inform process B about the move and process B will need to update its page table. The commit fixes a synchronisation bug caused by the use of the ticket: it made amdgpu_vm_handle_moved behave as if updating the page table immediately was correct but in this case it's not. An example is the following scenario, with 2 GPUs and glxgears running on GPU0 and Xorg running on GPU1, on a system where P2P PCI isn't supported: glxgears: export linear buffer from GPU0 and import using GPU1 submit frame rendering to GPU0 submit tiled->linear blit Xorg: copy of linear buffer The sequence of jobs would be: drm_sched_job_run # GPU0, frame rendering drm_sched_job_queue # GPU0, blit drm_sched_job_done # GPU0, frame rendering drm_sched_job_run # GPU0, blit move linear buffer for GPU1 access # amdgpu_dma_buf_move_notify -> update pt # GPU0 It this point the blit job on GPU0 is still running and would likely produce a page fault. Cc: stable@vger.kernel.org Fixes: a448cb003edc ("drm/amdgpu: implement amdgpu_gem_prime_move_notify v2") Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit be9c5e7af6b3a9920c4570d6309483972a1cc6e3 Author: Leo Li Date: Mon Nov 3 11:14:59 2025 -0500 drm/amd/display: Increase DCN35 SR enter/exit latency [ Upstream commit 318917e1d8ecc89f820f4fabf79935f4fed718cd ] [Why & How] On Framework laptops with DDR5 modules, underflow can be observed. It's unclear why it only occurs on specific desktop contents. However, increasing enter/exit latencies by 3us seems to resolve it. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4463 Reviewed-by: Nicholas Kazlauskas Signed-off-by: Leo Li Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit cc54e0eeee01ae88adaaae370ccb8091b8b4f2af Author: Jens Axboe Date: Wed Feb 11 15:12:13 2026 -0700 io_uring/openclose: fix io_pipe_fixed() slot tracking for specific slots [ Upstream commit f4d0668b38d8784f33a9a36c72ed5d0078247538 ] __io_fixed_fd_install() returns 0 on success for non-alloc mode (specific slot), not the slot index. io_pipe_fixed() used this return value directly as the slot index in fds[], which can cause the reported values returned via copy_to_user() to be incorrect, or the error path operating on the incorrect direct descriptor. Fix by computing the actual 0-based slot index (slot - 1) for specific slot mode, while preserving the existing behavior for auto-alloc mode where __io_fixed_fd_install() already returns the allocated index. Cc: stable@vger.kernel.org Fixes: 53db8a71ecb4 ("io_uring: add support for IORING_OP_PIPE") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 749b5e65ab699e8630070bfba2f44be18db69626 Author: Jens Axboe Date: Wed Feb 11 15:12:03 2026 -0700 io_uring/filetable: clamp alloc_hint to the configured alloc range [ Upstream commit a6bded921ed35f21b3f6bd8e629bf488499ca442 ] Explicit fixed file install/remove operations on slots outside the configured alloc range can corrupt alloc_hint via io_file_bitmap_set() and io_file_bitmap_clear(), which unconditionally update alloc_hint to the bit position. This causes subsequent auto-allocations to fall outside the configured range. For example, if the alloc range is [10, 20) and a file is removed at slot 2, alloc_hint gets set to 2. The next auto-alloc then starts searching from slot 2, potentially returning a slot below the range. Fix this by clamping alloc_hint to [file_alloc_start, file_alloc_end) at the top of io_file_bitmap_get() before starting the search. Cc: stable@vger.kernel.org Fixes: 6e73dffbb93c ("io_uring: let to set a range for file slot allocation") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e18d1a82a62e817a9eec6593bca13869f5ccf715 Author: Sam Edwards Date: Sun Jan 25 18:30:53 2026 -0800 ceph: fix write storm on fscrypted files [ Upstream commit cac190c7674fea71620d754ffcdaaeed7c551dbc ] CephFS stores file data across multiple RADOS objects. An object is the atomic unit of storage, so the writeback code must clean only folios that belong to the same object with each OSD request. CephFS also supports RAID0-style striping of file contents: if enabled, each object stores multiple unbroken "stripe units" covering different portions of the file; if disabled, a "stripe unit" is simply the whole object. The stripe unit is (usually) reported as the inode's block size. Though the writeback logic could, in principle, lock all dirty folios belonging to the same object, its current design is to lock only a single stripe unit at a time. Ever since this code was first written, it has determined this size by checking the inode's block size. However, the relatively-new fscrypt support needed to reduce the block size for encrypted inodes to the crypto block size (see 'fixes' commit), which causes an unnecessarily high number of write operations (~1024x as many, with 4MiB objects) and correspondingly degraded performance. Fix this (and clarify intent) by using i_layout.stripe_unit directly in ceph_define_write_size() so that encrypted inodes are written back with the same number of operations as if they were unencrypted. This patch depends on the preceding commit ("ceph: do not propagate page array emplacement errors as batch errors") for correctness. While it applies cleanly on its own, applying it alone will introduce a regression. This dependency is only relevant for kernels where ce80b76dd327 ("ceph: introduce ceph_process_folio_batch() method") has been applied; stable kernels without that commit are unaffected. Cc: stable@vger.kernel.org Fixes: 94af0470924c ("ceph: add some fscrypt guardrails") Signed-off-by: Sam Edwards Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 746840c87d76b614b14d9337c466ff022fc49823 Author: Sam Edwards Date: Sun Jan 25 18:30:52 2026 -0800 ceph: do not propagate page array emplacement errors as batch errors [ Upstream commit 707104682e3c163f7c14cdd6b07a3e95fb374759 ] When fscrypt is enabled, move_dirty_folio_in_page_array() may fail because it needs to allocate bounce buffers to store the encrypted versions of each folio. Each folio beyond the first allocates its bounce buffer with GFP_NOWAIT. Failures are common (and expected) under this allocation mode; they should flush (not abort) the batch. However, ceph_process_folio_batch() uses the same `rc` variable for its own return code and for capturing the return codes of its routine calls; failing to reset `rc` back to 0 results in the error being propagated out to the main writeback loop, which cannot actually tolerate any errors here: once `ceph_wbc.pages` is allocated, it must be passed to ceph_submit_write() to be freed. If it survives until the next iteration (e.g. due to the goto being followed), ceph_allocate_page_array()'s BUG_ON() will oops the worker. Note that this failure mode is currently masked due to another bug (addressed next in this series) that prevents multiple encrypted folios from being selected for the same write. For now, just reset `rc` when redirtying the folio to prevent errors in move_dirty_folio_in_page_array() from propagating. Note that move_dirty_folio_in_page_array() is careful never to return errors on the first folio, so there is no need to check for that. After this change, ceph_process_folio_batch() no longer returns errors; its only remaining failure indicator is `locked_pages == 0`, which the caller already handles correctly. Cc: stable@vger.kernel.org Fixes: ce80b76dd327 ("ceph: introduce ceph_process_folio_batch() method") Signed-off-by: Sam Edwards Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 0b9c58126ad1f7283cc55a5140d603c14ea3860f Author: Masami Hiramatsu (Google) Date: Tue Feb 10 17:43:43 2026 +0900 tracing: Reset last_boot_info if ring buffer is reset [ Upstream commit 804c4a2209bcf6ed4c45386f033e4d0f7c5bfda5 ] Commit 32dc0042528d ("tracing: Reset last-boot buffers when reading out all cpu buffers") resets the last_boot_info when user read out all data via trace_pipe* files. But it is not reset when user resets the buffer from other files. (e.g. write `trace` file) Reset it when the corresponding ring buffer is reset too. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Link: https://patch.msgid.link/177071302364.2293046.17895165659153977720.stgit@mhiramat.tok.corp.google.com Fixes: 32dc0042528d ("tracing: Reset last-boot buffers when reading out all cpu buffers") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 127f9481ea77ba21e687c14922ac94fa79b13997 Author: Masami Hiramatsu (Google) Date: Tue Feb 10 17:43:36 2026 +0900 tracing: Fix to set write permission to per-cpu buffer_size_kb [ Upstream commit f844282deed7481cf2f813933229261e27306551 ] Since the per-cpu buffer_size_kb file is writable for changing per-cpu ring buffer size, the file should have the write access permission. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Link: https://patch.msgid.link/177071301597.2293046.11683339475076917920.stgit@mhiramat.tok.corp.google.com Fixes: 21ccc9cd7211 ("tracing: Disable "other" permission bits in the tracefs files") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 316d9fe71fb18bc9b1dba464fdb68dd201315eba Author: Kevin Hao Date: Sun Feb 8 16:45:52 2026 +0800 net: macb: Fix tx/rx malfunction after phy link down and up [ Upstream commit bf9cf80cab81e39701861a42877a28295ade266f ] In commit 99537d5c476c ("net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open()"), the mog_init_rings() callback was moved from macb_mac_link_up() to macb_open() to resolve a deadlock issue. However, this change introduced a tx/rx malfunction following phy link down and up events. The issue arises from a mismatch between the software queue->tx_head, queue->tx_tail, queue->rx_prepared_head, and queue->rx_tail values and the hardware's internal tx/rx queue pointers. According to the Zynq UltraScale TRM [1], when tx/rx is disabled, the internal tx queue pointer resets to the value in the tx queue base address register, while the internal rx queue pointer remains unchanged. The following is quoted from the Zynq UltraScale TRM: When transmit is disabled, with bit [3] of the network control register set low, the transmit-buffer queue pointer resets to point to the address indicated by the transmit-buffer queue base address register. Disabling receive does not have the same effect on the receive-buffer queue pointer. Additionally, there is no need to reset the RBQP and TBQP registers in a phy event callback. Therefore, move macb_init_buffers() to macb_open(). In a phy link up event, the only required action is to reset the tx software head and tail pointers to align with the hardware's behavior. [1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm Fixes: 99537d5c476c ("net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open()") Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260208-macb-init-ring-v1-1-939a32c14635@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4cbc8dc736c72110df16aa2bb766abcdcd149fd4 Author: Kevin Hao Date: Sat Feb 7 14:21:46 2026 +0800 net: ti: icssg-prueth: Add optional dependency on HSR [ Upstream commit e3998b6e90f875f19bf758053d79ccfd41880173 ] Commit 95540ad6747c ("net: ti: icssg-prueth: Add support for HSR frame forward offload") introduced support for offloading HSR frame forwarding, which relies on functions such as is_hsr_master() provided by the HSR module. Although HSR provides stubs for configurations with HSR disabled, this driver still requires an optional dependency on HSR. Otherwise, build failures will occur when icssg-prueth is built-in while HSR is configured as a module. ld.lld: error: undefined symbol: is_hsr_master >>> referenced by icssg_prueth.c:710 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:710) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_del_mcast) in archive vmlinux.a >>> referenced by icssg_prueth.c:681 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:681) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_add_mcast) in archive vmlinux.a >>> referenced by icssg_prueth.c:1812 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:1812) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(prueth_netdevice_event) in archive vmlinux.a ld.lld: error: undefined symbol: hsr_get_port_ndev >>> referenced by icssg_prueth.c:712 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:712) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_del_mcast) in archive vmlinux.a >>> referenced by icssg_prueth.c:712 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:712) >>> drivers/net/etherneteth_hsr_del_mcast) in archive vmlinux.a >>> referenced by icssg_prueth.c:683 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:683) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_add_mcast) in archive vmlinux.a >>> referenced 1 more times Fixes: 95540ad6747c ("net: ti: icssg-prueth: Add support for HSR frame forward offload") Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260207-icssg-dep-v3-1-8c47c1937f81@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6d389382ee655128056fbdab86baad8495ffbf33 Author: Bo Sun Date: Fri Feb 6 21:09:24 2026 +0800 octeontx2-af: CGX: fix bitmap leaks [ Upstream commit 3def995c4ede842adf509c410e92d09a0cedc965 ] The RX/TX flow-control bitmaps (rx_fc_pfvf_bmap and tx_fc_pfvf_bmap) are allocated by cgx_lmac_init() but never freed in cgx_lmac_exit(). Unbinding and rebinding the driver therefore triggers kmemleak: unreferenced object (size 16): backtrace: rvu_alloc_bitmap cgx_probe Free both bitmaps during teardown. Fixes: e740003874ed ("octeontx2-af: Flow control resource management") Cc: stable@vger.kernel.org Signed-off-by: Bo Sun Reviewed-by: Vadim Fedorenko Reviewed-by: Jijie Shao Link: https://patch.msgid.link/20260206130925.1087588-2-bo@mboxify.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d8a522085d09b30aba1016daf1dddac37c0f0285 Author: Thomas Fourier Date: Fri Feb 6 09:53:33 2026 +0100 net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean() [ Upstream commit 36bd7d5deef936c4e1e3cd341598140e5c14c1d3 ] The priv->rx_buffer and priv->tx_buffer are alloc'd together as contiguous buffers in uhdlc_init() but freed as two buffers in uhdlc_memclean(). Change the cleanup to only call dma_free_coherent() once on the whole buffer. Reviewed-by: Christophe Leroy (CS GROUP) Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC") Cc: Signed-off-by: Thomas Fourier Link: https://patch.msgid.link/20260206085334.21195-2-fourier.thomas@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 938cf039a68353a2ee1950659d662342e02ba94b Author: Ethan Nelson-Moore Date: Thu Feb 5 23:17:14 2026 -0800 net: ethernet: marvell: skge: remove incorrect conflicting PCI ID [ Upstream commit d01103fdcb871fd83fd06ef5803d576507c6a801 ] The ID 1186:4302 is matched by both r8169 and skge. The same device ID should not be in more than one driver, because in that case, which driver is used is unpredictable. I downloaded the latest drivers for all hardware revisions of the D-Link DGE-530T from D-Link's website, and the only drivers which contain this ID are Realtek drivers. Therefore, remove this device ID from skge. In the kernel bug report which requested addition of this device ID, someone created a patch to add the ID to skge. Then, it was pointed out that this device is an "r8169 in disguise", and a patch was created to add it to r8169. Somehow, both of these patches got merged. See the link below. Link: https://bugzilla.kernel.org/show_bug.cgi?id=38862 Fixes: c074304c2bcf ("add pci-id for DGE-530T") Cc: stable@vger.kernel.org Signed-off-by: Ethan Nelson-Moore Link: https://patch.msgid.link/20260206071724.15268-1-enelsonmoore@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 78dd793ae6dcf55ed3f416c28346033e1eb5f379 Author: Tiezhu Yang Date: Tue Feb 10 19:31:17 2026 +0800 LoongArch: Disable instrumentation for setup_ptwalker() [ Upstream commit 7cb37af61f09c9cfd90c43c9275307c16320cbf2 ] According to Documentation/dev-tools/kasan.rst, software KASAN modes use compiler instrumentation to insert validity checks. Such instrumentation might be incompatible with some parts of the kernel, and therefore needs to be disabled, just use the attribute __no_sanitize_address to disable instrumentation for the low level function setup_ptwalker(). Otherwise bringing up the secondary CPUs failed when CONFIG_KASAN is set (especially when PTW is enabled), here are the call chains: smpboot_entry() start_secondary() cpu_probe() per_cpu_trap_init() tlb_init() setup_tlb_handler() setup_ptwalker() The reason is the PGD registers are configured in setup_ptwalker(), but KASAN instrumentation may cause TLB exceptions before that. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 76a0e30a1cea1e0f9d7f875d175ce2e70966c038 Author: Tiezhu Yang Date: Tue Feb 10 19:31:13 2026 +0800 LoongArch: Guard percpu handler under !CONFIG_PREEMPT_RT [ Upstream commit 70b0faae3590c628a98a627a10e5d211310169d4 ] After commit 88fd2b70120d ("LoongArch: Fix sleeping in atomic context for PREEMPT_RT"), it should guard percpu handler under !CONFIG_PREEMPT_RT to avoid redundant operations. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 0811b951377e32c06ed47c579cd1ceda59165d40 Author: Tiezhu Yang Date: Tue Feb 10 19:31:13 2026 +0800 LoongArch: Use %px to print unmodified unwinding address [ Upstream commit 77403a06d845db1caf9a6b0867b43e9dd8de8e4a ] Currently, use %p to prevent leaking information about the kernel memory layout when printing the PC address, but the kernel log messages are not useful to debug problem if bt_address() returns 0. Given that the type of "pc" variable is unsigned long, it should use %px to print the unmodified unwinding address. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 7a6b754bddd346d9c5e83ef95fd87f40538f9835 Author: Huacai Chen Date: Tue Feb 10 19:31:13 2026 +0800 LoongArch: Prefer top-down allocation after arch_mem_init() [ Upstream commit 2172d6ebac9372eb01fe4505a53e18cb061e103b ] Currently we use bottom-up allocation after sparse_init(), the reason is sparse_init() need a lot of memory, and bottom-up allocation may exhaust precious low memory (below 4GB). On the other hand, SWIOTLB and CMA need low memories for DMA32, so swiotlb_init() and dma_contiguous_reserve() need bottom-up allocation. Since swiotlb_init() and dma_contiguous_reserve() are both called in arch_mem_init(), we no longer need bottom-up allocation after that. So we set the allocation policy to top-down at the end of arch_mem_init(), in order to avoid later memory allocations (such as KASAN) exhaust low memory. This solve at least two problems: 1. Some buggy BIOSes use 0xfd000000~0xfe000000 for secondary CPUs, but didn't reserve this range, which causes smpboot failures. 2. Some DMA32 devices, such as Loongson-DRM and OHCI, cannot work with KASAN enabled. Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 61a56df2fbaad3a4d00f0c6a904b5d1ee8982eb4 Author: John Garry Date: Tue Feb 10 19:31:12 2026 +0800 LoongArch: Make cpumask_of_node() robust against NUMA_NO_NODE [ Upstream commit 94b0c831eda778ae9e4f2164a8b3de485d8977bb ] The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE - which is a valid index - so add a check for this. Cc: stable@vger.kernel.org Signed-off-by: John Garry Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 353dd9934447b9193643ae1afd938607a74d4915 Author: Harry Yoo Date: Tue Feb 10 17:18:59 2026 +0900 mm/slab: do not access current->mems_allowed_seq if !allow_spin [ Upstream commit 144080a5823b2dbd635acb6decf7ab23182664f3 ] Lockdep complains when get_from_any_partial() is called in an NMI context, because current->mems_allowed_seq is seqcount_spinlock_t and not NMI-safe: ================================ WARNING: inconsistent lock state 6.19.0-rc5-kfree-rcu+ #315 Tainted: G N -------------------------------- inconsistent {INITIAL USE} -> {IN-NMI} usage. kunit_try_catch/9989 [HC1[1]:SC0[0]:HE0:SE1] takes: ffff889085799820 (&____s->seqcount#3){.-.-}-{0:0}, at: ___slab_alloc+0x58f/0xc00 {INITIAL USE} state was registered at: lock_acquire+0x185/0x320 kernel_init_freeable+0x391/0x1150 kernel_init+0x1f/0x220 ret_from_fork+0x736/0x8f0 ret_from_fork_asm+0x1a/0x30 irq event stamp: 56 hardirqs last enabled at (55): [] _raw_spin_unlock_irq+0x27/0x70 hardirqs last disabled at (56): [] __schedule+0x2a8a/0x6630 softirqs last enabled at (0): [] copy_process+0x1dc1/0x6a10 softirqs last disabled at (0): [<0000000000000000>] 0x0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&____s->seqcount#3); lock(&____s->seqcount#3); *** DEADLOCK *** According to Documentation/locking/seqlock.rst, seqcount_t is not NMI-safe and seqcount_latch_t should be used when read path can interrupt the write-side critical section. In this case, do not access current->mems_allowed_seq and avoid retry. Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().") Cc: stable@vger.kernel.org Signed-off-by: Harry Yoo Link: https://patch.msgid.link/20260210081900.329447-2-harry.yoo@oracle.com Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin commit f843be76420412fd987d9ec945fbd46a72fe095b Author: Miguel Ojeda Date: Fri Feb 6 21:45:35 2026 +0100 rust: kbuild: pass `-Zunstable-options` for Rust 1.95.0 [ Upstream commit 0a9be83e57de0d0ca8ca4ec610bc344f17a8e5e7 ] Custom target specifications are unstable, but starting with Rust 1.95.0, `rustc` requires to explicitly pass `-Zunstable-options` to use them [1]: error: error loading target specification: custom targets are unstable and require `-Zunstable-options` | = help: run `rustc --print target-list` for a list of built-in targets David (Rust compiler team lead), writes: "We're destabilising custom targets to allow us to move forward with build-std without accidentally exposing functionality that we'd like to revisit prior to committing to. I'll start a thread on Zulip to discuss with the RfL team how we can come up with an alternative for them." Thus pass it. Cc: David Wood Cc: Wesley Wiser 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/151534 [1] Reviewed-by: Gary Guo Tested-by: Gary Guo Link: https://patch.msgid.link/20260206204535.39431-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 2d11f9cff0a7ba17687ef9d4cf15527d8f57492c Author: Ankit Nautiyal Date: Fri Dec 26 10:03:59 2025 +0530 drm/i915/quirks: Fix device id for QUIRK_EDP_LIMIT_RATE_HBR2 entry [ Upstream commit 510e7261a7bcd6232e90f0b6b9f93303bdd29f8a ] Update the device ID for Dell XPS 13 7390 2-in-1 in the quirk `QUIRK_EDP_LIMIT_RATE_HBR2` entry. The previous ID (0x8a12) was incorrect; the correct ID is 0x8a52. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 Fixes: 21c586d9233a ("drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2") Cc: Jani Nikula Cc: Ville Syrjälä Cc: Ankit Nautiyal Cc: # v6.18+ Signed-off-by: Ankit Nautiyal Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/20251226043359.2553-1-ankit.k.nautiyal@intel.com (cherry picked from commit c7c30c4093cc11ff66672471f12599a555708343) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit 69e59a87bab0ea31ab2a584fc65e12dafacf8953 Author: ethanwu Date: Thu Sep 25 18:42:05 2025 +0800 ceph: supply snapshot context in ceph_zero_partial_object() [ Upstream commit f16bd3fa74a2084ee7e16a8a2be7e7399b970907 ] The ceph_zero_partial_object function was missing proper snapshot context for its OSD write operations, which could lead to data inconsistencies in snapshots. Reproducer: ../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' mount -t ceph fs_a@.a=/ /mnt/mycephfs/ -o conf=./ceph.conf dd if=/dev/urandom of=/mnt/mycephfs/foo bs=64K count=1 mkdir /mnt/mycephfs/.snap/snap1 md5sum /mnt/mycephfs/.snap/snap1/foo fallocate -p -o 0 -l 4096 /mnt/mycephfs/foo echo 3 > /proc/sys/vm/drop/caches md5sum /mnt/mycephfs/.snap/snap1/foo # get different md5sum!! Cc: stable@vger.kernel.org Fixes: ad7a60de882ac ("ceph: punch hole support") Signed-off-by: ethanwu Reviewed-by: Viacheslav Dubeyko Tested-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit a2d53aee3fe2de8dec25806070cbda43daf6a32f Author: Jiaxun Yang Date: Thu Feb 5 10:08:42 2026 +0000 MIPS: rb532: Fix MMIO UART resource registration [ Upstream commit e93bb4b76cfefb302534246e892c7667491cb8cc ] Since commit 6e690d54cfa8 ("serial: 8250: fix return error code in serial8250_request_std_resource()"), registering an 8250 MMIO port without mapbase no longer works, as the resource range is derived from mapbase/mapsize. Populate mapbase and mapsize accordingly. Also drop ugly membase KSEG1 pointer and set UPF_IOREMAP instead, letting the 8250 core perform the ioremap. Fixes: 6e690d54cfa8 ("serial: 8250: fix return error code in serial8250_request_std_resource()") Cc: stable@vger.kernel.org Reported-by: Waldemar Brodkorb Link: https://lore.kernel.org/linux-mips/aX-d0ShTplHKZT33@waldemar-brodkorb.de/ Signed-off-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 3969db6b22e3d90d8c5f22ac1a7fe0350a94c136 Author: Shyam Prasad N Date: Sun Feb 1 00:21:13 2026 +0530 cifs: Fix locking usage for tcon fields [ Upstream commit 96c4af418586ee9a6aab61738644366426e05316 ] We used to use the cifs_tcp_ses_lock to protect a lot of objects that are not just the server, ses or tcon lists. We later introduced srv_lock, ses_lock and tc_lock to protect fields within the corresponding structs. This was done to provide a more granular protection and avoid unnecessary serialization. There were still a couple of uses of cifs_tcp_ses_lock to provide tcon fields. In this patch, I've replaced them with tc_lock. Cc: stable@vger.kernel.org Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 80a2e762b21774da69fcf42184835525a7e4a8d9 Author: Carlos Song Date: Fri Jan 23 18:54:58 2026 +0800 i2c: imx-lpi2c: fix SMBus block read NACK after byte count [ Upstream commit efdc383d1cc28d45cbf5a23b5ffa997010aaacb4 ] The LPI2C controller sends a NACK at the end of a receive command unless another receive command is already queued in MTDR. During SMBus block reads, this causes the controller to NACK immediately after receiving the block length byte, aborting the transfer before the data bytes are read. Fix this by queueing a second receive command as soon as the block length byte is received, keeping MTDR non-empty and ensuring continuous ACKs. The initial receive command reads the block length, and the subsequent command reads the remaining data bytes according to the reported length. Fixes: a55fa9d0e42e ("i2c: imx-lpi2c: add low power i2c bus driver") Signed-off-by: Carlos Song Cc: # v4.10+ Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260123105459.3448822-1-carlos.song@nxp.com Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 5e227857fcd942a1ea439272e636b126a97f593c Author: Shengming Hu Date: Mon Jan 19 21:59:05 2026 +0800 watchdog/softlockup: fix sample ring index wrap in need_counting_irqs() [ Upstream commit cafe4074a7221dca2fa954dd1ab0cf99b6318e23 ] cpustat_tail indexes cpustat_util[], which is a NUM_SAMPLE_PERIODS-sized ring buffer. need_counting_irqs() currently wraps the index using NUM_HARDIRQ_REPORT, which only happens to match NUM_SAMPLE_PERIODS. Use NUM_SAMPLE_PERIODS for the wrap to keep the ring math correct even if the NUM_HARDIRQ_REPORT or NUM_SAMPLE_PERIODS changes. Link: https://lkml.kernel.org/r/tencent_7068189CB6D6689EB353F3D17BF5A5311A07@qq.com Fixes: e9a9292e2368 ("watchdog/softlockup: Report the most frequent interrupts") Signed-off-by: Shengming Hu Reviewed-by: Petr Mladek Cc: Ingo Molnar Cc: Mark Brown Cc: Thomas Gleixner Cc: Zhang Run Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit d14871ce0b400ae137067b04d6559c8136aab5e0 Author: Alan Maguire Date: Fri Jan 16 09:17:30 2026 +0000 kcsan, compiler_types: avoid duplicate type issues in BPF Type Format [ Upstream commit 9dc052234da736f7749f19ab6936342ec7dbe3ac ] Enabling KCSAN is causing a large number of duplicate types in BTF for core kernel structs like task_struct [1]. This is due to the definition in include/linux/compiler_types.h `#ifdef __SANITIZE_THREAD__ ... `#define __data_racy volatile .. `#else ... `#define __data_racy ... `#endif Because some objects in the kernel are compiled without KCSAN flags (KCSAN_SANITIZE) we sometimes get the empty __data_racy annotation for objects; as a result we get multiple conflicting representations of the associated structs in DWARF, and these lead to multiple instances of core kernel types in BTF since they cannot be deduplicated due to the additional modifier in some instances. Moving the __data_racy definition under CONFIG_KCSAN avoids this problem, since the volatile modifier will be present for both KCSAN and KCSAN_SANITIZE objects in a CONFIG_KCSAN=y kernel. Link: https://lkml.kernel.org/r/20260116091730.324322-1-alan.maguire@oracle.com Fixes: 31f605a308e6 ("kcsan, compiler_types: Introduce __data_racy type qualifier") Signed-off-by: Alan Maguire Reported-by: Nilay Shroff Tested-by: Nilay Shroff Suggested-by: Marco Elver Reviewed-by: Marco Elver Acked-by: Yonghong Song Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Bart van Assche Cc: Daniel Borkman Cc: Eduard Zingerman Cc: Hao Luo Cc: Heiko Carstens Cc: "H. Peter Anvin" Cc: Jason A. Donenfeld Cc: Jiri Olsa Cc: John Fastabend Cc: Kees Cook Cc: KP Singh Cc: Martin KaFai Lau Cc: Miguel Ojeda Cc: Naman Jain Cc: Nathan Chancellor Cc: "Paul E . McKenney" Cc: Peter Zijlstra Cc: Stanislav Fomichev Cc: Uros Bizjak Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 677490a6bd4c63acdf6f48e4aaf6a23d7e6a446f Author: Ethan Tidmore Date: Mon Feb 2 14:54:29 2026 -0600 staging: rtl8723bs: fix null dereference in find_network [ Upstream commit 41460a19654c32d39fd0e3a3671cd8d4b7b8479f ] The variable pwlan has the possibility of being NULL when passed into rtw_free_network_nolock() which would later dereference the variable. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Ethan Tidmore Link: https://patch.msgid.link/20260202205429.20181-1-ethantidmore06@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7e4d88e36e5d0b8ffda637999cbca64c81701a81 Author: Matthieu Baerts (NGI0) Date: Thu Feb 5 18:34:21 2026 +0100 mptcp: pm: in-kernel: always set ID as avail when rm endp [ Upstream commit d191101dee25567c2af3b28565f45346c33d65f5 ] Syzkaller managed to find a combination of actions that was generating this warning: WARNING: net/mptcp/pm_kernel.c:1074 at __mark_subflow_endp_available net/mptcp/pm_kernel.c:1074 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1446 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1474 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags+0x5de/0x640 net/mptcp/pm_kernel.c:1538, CPU#1: syz.7.48/2535 Modules linked in: CPU: 1 UID: 0 PID: 2535 Comm: syz.7.48 Not tainted 6.18.0-03987-gea5f5e676cf5 #17 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 25.10 PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1074 [inline] RIP: 0010:mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1446 [inline] RIP: 0010:mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1474 [inline] RIP: 0010:mptcp_pm_nl_set_flags+0x5de/0x640 net/mptcp/pm_kernel.c:1538 Code: 89 c7 e8 c5 8c 73 fe e9 f7 fd ff ff 49 83 ef 80 e8 b7 8c 73 fe 4c 89 ff be 03 00 00 00 e8 4a 29 e3 fe eb ac e8 a3 8c 73 fe 90 <0f> 0b 90 e9 3d ff ff ff e8 95 8c 73 fe b8 a1 ff ff ff eb 1a e8 89 RSP: 0018:ffffc9001535b820 EFLAGS: 00010287 netdevsim0: tun_chr_ioctl cmd 1074025677 RAX: ffffffff82da294d RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc900096d0000 RSI: 00000000000006d6 RDI: 00000000000006d7 netdevsim0: linktype set to 823 RBP: ffff88802cdb2240 R08: 00000000000104ae R09: ffffffffffffffff R10: ffffffff82da27d4 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88801246d8c0 R14: ffffc9001535b8b8 R15: ffff88802cdb1800 FS: 00007fc6ac5a76c0(0000) GS:ffff8880f90c8000(0000) knlGS:0000000000000000 netlink: 'syz.3.50': attribute type 5 has an invalid length. CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 netlink: 1232 bytes leftover after parsing attributes in process `syz.3.50'. CR2: 0000200000010000 CR3: 0000000025b1a000 CR4: 0000000000350ef0 Call Trace: mptcp_pm_set_flags net/mptcp/pm_netlink.c:277 [inline] mptcp_pm_nl_set_flags_doit+0x1d7/0x210 net/mptcp/pm_netlink.c:282 genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x4ab/0x5b0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0xc9/0xf0 net/socket.c:733 ____sys_sendmsg+0x272/0x3b0 net/socket.c:2608 ___sys_sendmsg+0x2de/0x320 net/socket.c:2662 __sys_sendmsg net/socket.c:2694 [inline] __do_sys_sendmsg net/socket.c:2699 [inline] __se_sys_sendmsg net/socket.c:2697 [inline] __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2697 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xed/0x360 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc6adb66f6d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 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 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fc6ac5a6ff8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fc6addf5fa0 RCX: 00007fc6adb66f6d RDX: 0000000000048084 RSI: 00002000000002c0 RDI: 000000000000000e RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 netlink: 'syz.5.51': attribute type 2 has an invalid length. R13: 00007fff25e91fe0 R14: 00007fc6ac5a7ce4 R15: 00007fff25e920d7 The actions that caused that seem to be: - Create an MPTCP endpoint for address A without any flags - Create a new MPTCP connection from address A - Remove the MPTCP endpoint: the corresponding subflows will be removed - Recreate the endpoint with the same ID, but with the subflow flag - Change the same endpoint to add the fullmesh flag In this case, msk->pm.local_addr_used has been kept to 0 as expected, but the corresponding bit in msk->pm.id_avail_bitmap was still unset after having removed the endpoint, causing the splat later on. When removing an endpoint, the corresponding endpoint ID was only marked as available for "signal" types with an announced address, plus all "subflow" types, but not the other types like an endpoint corresponding to the initial subflow. In these cases, re-creating an endpoint with the same ID didn't signal/create anything. Here, adding the fullmesh flag was creating the splat when calling __mark_subflow_endp_available() from mptcp_pm_nl_fullmesh(), because msk->pm.local_addr_used was set to 0 while the ID was marked as used. To fix this issue, the corresponding bit in msk->pm.id_avail_bitmap can always be set as available when removing an MPTCP in-kernel endpoint. In other words, moving the call to __set_bit() to do it in all cases, except for "subflow" types where this bit is handled in a dedicated helper. Note: instead of adding a new spin_(un)lock_bh that would be taken in all cases, do all the actions requiring the spin lock under the same block. This modification potentially fixes another issue reported by syzbot, see [1]. But without a reproducer or more details about what exactly happened before, it is hard to confirm. Fixes: e255683c06df ("mptcp: pm: re-using ID of unused removed ADD_ADDR") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/606 Reported-by: syzbot+f56f7d56e2c6e11a01b6@syzkaller.appspotmail.com Closes: https://lore.kernel.org/68fcfc4a.050a0220.346f24.02fb.GAE@google.com [1] Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260205-net-mptcp-misc-fixes-6-19-rc8-v2-1-c2720ce75c34@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2f33f77397dd1aea6574d4620e3c2a6e64b6de89 Author: Haoxiang Li Date: Fri Dec 19 21:19:26 2025 +0800 parisc: kernel: replace kfree() with put_device() in create_tree_node() [ Upstream commit dcf69599c47f29ce0a99117eb3f9ddcd2c4e78b6 ] If device_register() fails, put_device() is the correct way to drop the device reference. Found by code review. Fixes: 1070c9655b90 ("[PA-RISC] Fix must_check warnings in drivers.c") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit bd435f4b738130d732ef64e0e57e45185f77165d Author: Jinhui Guo Date: Fri Dec 12 22:55:28 2025 +0800 PCI: Fix pci_slot_trylock() error handling [ Upstream commit 9368d1ee62829b08aa31836b3ca003803caf0b72 ] Commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails. Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } } After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug. This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread. Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path. [Same patch later posted by Keith at https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com] Fixes: a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") Signed-off-by: Jinhui Guo Signed-off-by: Bjorn Helgaas Reviewed-by: Dan Williams Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251212145528.2555-1-guojinhui.liam@bytedance.com Signed-off-by: Sasha Levin commit 627f0ea6537ce7dc502100be65046c98bbf90b71 Author: Ilpo Järvinen Date: Tue Feb 3 19:21:38 2026 +0200 PCI: Don't claim disabled bridge windows [ Upstream commit 2ecc1bf14e2fdaff78bd1b8e7ed3dba336a3fad5 ] The commit 8278c6914306 ("PCI: Preserve bridge window resource type flags") changed bridge window resource behavior such that flags are no longer zero if the bridge window is not valid or is disabled (mainly to preserve the type flags for later use). If a bridge window has its limit smaller than base address, pci_read_bridge_*() sets both IORESOURCE_UNSET and IORESOURCE_DISABLED to indicate the bridge window exists but is not valid with the current base and limit configuration. The code in pci_claim_bridge_resources() still depends on the old behavior of checking validity of the bridge window solely based on !r->flags, whereas after 8278c6914306, also IORESOURCE_DISABLED may indicate bridge window addresses are not valid. While pci_claim_resource() does check IORESOURCE_UNSET, pci_claim_bridge_resource() attempts to clip the resource if pci_claim_resource() fails, which is not correct for bridge window resources that are not valid. As pci_bus_clip_resource() performs clipping regardless of flags and then clears IORESOURCE_UNSET, it should not be called unless the resource is valid. The problem is visible in this log: pci 0000:20:00.0: PCI bridge to [bus 21] pci 0000:20:00.0: bridge window [io size 0x0000 disabled]: can't claim; no address assigned pci 0000:20:00.0: [io 0x0000-0xffffffffffffffff disabled] clipped to [io 0x0000-0xffff disabled] Add IORESOURCE_DISABLED check in pci_claim_bridge_resources() to only claim bridge windows that appear to have a valid configuration. Fixes: 8278c6914306 ("PCI: Preserve bridge window resource type flags") Reported-by: Sizhe Liu Link: https://lore.kernel.org/all/20260203023545.2753811-1-liusizhe5@huawei.com Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/4d9228d6-a230-6ddf-e300-fbf42d523863@linux.intel.com Signed-off-by: Sasha Levin commit 29739ec197ed66535bc0b86f14ab66c5f4512138 Author: Kevin Hao Date: Thu Feb 5 10:47:03 2026 +0800 net: cpsw_new: Fix potential unregister of netdev that has not been registered yet [ Upstream commit 9d724b34fbe13b71865ad0906a4be97571f19cf5 ] If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly. Fixes: ed3525eda4c4 ("net: ethernet: ti: introduce cpsw switchdev based driver part 1 - dual-emac") Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Reviewed-by: Alexander Sverdlin Link: https://patch.msgid.link/20260205-cpsw-error-path-v1-2-6e58bae6b299@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 299b825716b82f4c032adfb041f1d7c24f6b9e5f Author: Kevin Hao Date: Thu Feb 5 10:47:02 2026 +0800 net: cpsw_new: Fix unnecessary netdev unregistration in cpsw_probe() error path [ Upstream commit 62db84b7efa63b78aed9fdbdae90f198771be94c ] The current error handling in cpsw_probe() has two issues: - cpsw_unregister_ports() may be called before cpsw_register_ports() has been executed. - cpsw_unregister_ports() is already invoked within cpsw_register_ports() in case of a register_netdev() failure, but the error path would call it again. Fixes: ed3525eda4c4 ("net: ethernet: ti: introduce cpsw switchdev based driver part 1 - dual-emac") Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Reviewed-by: Alexander Sverdlin Link: https://patch.msgid.link/20260205-cpsw-error-path-v1-1-6e58bae6b299@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fc58ef30e0a1524ce72a8e873d773ba3b0830c7d Author: Yifan Zhang Date: Mon Feb 2 13:17:39 2026 +0800 drm/amdgpu: Protect GPU register accesses in powergated state in some paths [ Upstream commit 39fc2bc4da0082c226cbee331f0a5d44db3997da ] Ungate GPU CG/PG in device_fini_hw and device_halt to protect GPU register accesses, e.g. GC registers are accessed in amdgpu_irq_disable_all() and amdgpu_fence_driver_hw_fini(). Signed-off-by: Yifan Zhang Acked-by: Alex Deucher Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit bfcd6b53e1f4feb182952f4ff9a137c36ceaf20b Author: Sunday Clement Date: Mon Feb 2 12:41:39 2026 -0500 drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set() [ Upstream commit 8a70a26c9f34baea6c3199a9862ddaff4554a96d ] The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8 bytes via memset without checking the buffer size parameter. This allows unprivileged userspace to trigger an out-of bounds kernel memory write by passing a small buffer, leading to potential privilege escalation. Signed-off-by: Sunday Clement Reviewed-by: Alexander Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit d58f8d4dcfb1c81c15afc3b8bbfd34846ae84982 Author: Daniel Hodges Date: Tue Feb 3 09:56:21 2026 -0500 tipc: fix RCU dereference race in tipc_aead_users_dec() [ Upstream commit 6a65c0cb0ff20b3cbc5f1c87b37dd22cdde14a1c ] tipc_aead_users_dec() calls rcu_dereference(aead) twice: once to store in 'tmp' for the NULL check, and again inside the atomic_add_unless() call. Use the already-dereferenced 'tmp' pointer consistently, matching the correct pattern used in tipc_aead_users_inc() and tipc_aead_users_set(). Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Cc: stable@vger.kernel.org Reviewed-by: Eric Dumazet Signed-off-by: Daniel Hodges Link: https://patch.msgid.link/20260203145621.17399-1-git@danielhodges.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ead66f2ed16f3e61aea352f0094433ee05cf3e2d Author: Andrea Scian Date: Wed Feb 4 18:41:44 2026 +0100 mtd: rawnand: pl353: Fix software ECC support [ Upstream commit 89b831ebdaca0df4ca3b226f7e7a1d1db1629060 ] We need to set also write_page_raw in ecc structure to allow choosing SW ECC instead of HW one, otherwise write operation fail. Fixes: 08d8c62164a322 ("mtd: rawnand: pl353: Add support for the ARM PL353 SMC NAND controller") Signed-off-by: Andrea Scian Cc: stable@kernel.org Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 9799f977759e427811d1844fa536e23b351e3411 Author: Jisheng Zhang Date: Thu Jan 29 10:15:34 2026 +0800 usb: dwc2: fix resume failure if dr_mode is host [ Upstream commit a52e4f2dff413b58c7200e89bb6540bd995e1269 ] commit 13b1f8e25bfd1 ("usb: dwc2: Force mode optimizations") removed the dwc2_force_mode(hsotg, true) in dwc2_force_dr_mode() if dr_mode is host. But this brings a bug: the controller fails to resume back as host, further debugging shows that the controller is resumed as peripheral. The reason is dwc2_force_dr_mode() missed the host mode forcing, and when resuming from s2ram, GINTSTS is 0 by default, dwc2_is_device_mode in dwc2_resume() misreads this as the controller is in peripheral mode. Fix the resume failure by adding back the dwc2_force_mode(hsotg, true). Then an obvious question is: why this bug hasn't been observed and fixed for about six years? There are two resons: most dwc2 platforms set the dr_mode as otg; Some platforms don't have suspend & resume support yet. Fixes: 13b1f8e25bfd1 ("usb: dwc2: Force mode optimizations") Cc: stable Signed-off-by: Jisheng Zhang Link: https://patch.msgid.link/20260129021534.10411-1-jszhang@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2333653ef854c2cc124077f71a8526f03bf6e06a Author: Prashanth K Date: Wed Feb 4 11:11:55 2026 +0530 usb: dwc3: gadget: Move vbus draw to workqueue context [ Upstream commit 54aaa3b387c2f580a99dc86a9cc2eb6dfaf599a7 ] Currently dwc3_gadget_vbus_draw() can be called from atomic context, which in turn invokes power-supply-core APIs. And some these PMIC APIs have operations that may sleep, leading to kernel panic. Fix this by moving the vbus_draw into a workqueue context. Fixes: 99288de36020 ("usb: dwc3: add an alternate path in vbus_draw callback") Cc: stable Tested-by: Samuel Wu Acked-by: Thinh Nguyen Signed-off-by: Prashanth K Link: https://patch.msgid.link/20260204054155.3063825-1-prashanth.k@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 76096f156fe9dc9fbd6e4618088706e91b9b0a6c Author: Johan Hovold Date: Thu Nov 27 14:47:02 2025 +0100 mux: mmio: fix regmap leak on probe failure [ Upstream commit 3c4ae63073d84abee5d81ce46d86a94e9dae9c89 ] The mmio regmap that may be allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind. Fixes: 61de83fd8256 ("mux: mmio: Do not use syscon helper to build regmap") Cc: stable@vger.kernel.org # 6.16 Cc: Andrew Davis Signed-off-by: Johan Hovold Acked-by: Andrew Davis Link: https://patch.msgid.link/20251127134702.1915-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e4010282364fcca44e297587f7f3401673b63143 Author: Niklas Cassel Date: Tue Jan 27 16:10:39 2026 +0100 PCI: dwc: Fix msg_atu_index assignment [ Upstream commit 58fbf08935d9c4396417e5887df89a4e681fa7e3 ] When dw_pcie_iatu_setup() configures outbound address translation for both type PCIE_ATU_TYPE_MEM and PCIE_ATU_TYPE_IO, the iATU index to use is incremented before calling dw_pcie_prog_outbound_atu(). However for msg_atu_index, the index is not incremented before use, causing the iATU index to be the same as the last configured iATU index, which means that it will incorrectly use the same iATU index that is already in use, breaking outbound address translation. In total there are three problems with this code: -It assigns msg_atu_index the same index that was used for the last outbound address translation window, rather than incrementing the index before assignment. -The index should only be incremented (and msg_atu_index assigned) if the use_atu_msg feature is actually requested/in use (pp->use_atu_msg is set). -If the use_atu_msg feature is requested/in use, and there are no outbound iATUs available, the code should return an error, as otherwise when this this feature is used, it will use an iATU index that is out of bounds. Fixes: e1a4ec1a9520 ("PCI: dwc: Add generic MSG TLP support for sending PME_Turn_Off when system suspend") Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Tested-by: Maciej W. Rozycki Reviewed-by: Damien Le Moal Reviewed-by: Hans Zhang Reviewed-by: Frank Li Reviewed-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260127151038.1484881-6-cassel@kernel.org Signed-off-by: Sasha Levin commit b355d927109f1fa04883c2cbf7ed4a1c151bce3c Author: Rong Zhang Date: Sun Feb 1 05:32:59 2026 +0800 MIPS: Loongson2ef: Use pcibios_align_resource() to block io range [ Upstream commit 32ec465103527ede09b640cd0ab0636dc58827fb ] Loongson2ef reserves io range below 0x4000 (LOONGSON_PCI_IO_START) while ISA-mode only IDE controller on the south bridge still has a hard dependency on ISA IO ports. The reservation was done by lifting loongson_pci_io_resource.start onto 0x4000. Prior to commit ae81aad5c2e1 ("MIPS: PCI: Use pci_enable_resources()"), the arch specific pcibios_enable_resources() did not check if the resources were claimed, which diverges from what PCI core checks, effectively hiding the fact that IDE IO resources were not properly within the resource tree. After starting to use pcibios_enable_resources() from PCI core, enabling IDE controller fails: pata_cs5536 0000:00:0e.2: BAR 0 [io 0x01f0-0x01f7]: not claimed; can't enable device pata_cs5536 0000:00:0e.2: probe with driver pata_cs5536 failed with error -22 MIPS PCI code already has support for enforcing lower bounds using PCIBIOS_MIN_IO in pcibios_align_resource() without altering the IO window start address itself. Make Loongson2ef PCI code use PCIBIOS_MIN_IO too. Fixes: ae81aad5c2e1 ("MIPS: PCI: Use pci_enable_resources()") Cc: stable@vger.kernel.org Tested-by: Beiyan Yun Tested-by: Yao Zi Signed-off-by: Rong Zhang Acked-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 3b8fa431e035424edfad93ccfb996fe158c2f53c Author: Rong Zhang Date: Sun Feb 1 05:32:58 2026 +0800 MIPS: Loongson2ef: Register PCI controller in early stage [ Upstream commit 6a00c043af07492502ba7a2263ddc4cdb01b66a7 ] We are about to set loongson_pci_io_resource.start to 0 and adopt PCIBIOS_MIN_IO. As the first step, PCI controller needs to be registered in early stage to make it the root of other resources (e.g., i8259) and prevent resource conflicts. Register it in plat_mem_setup() instead of arch_initcall(). Fixes: ae81aad5c2e1 ("MIPS: PCI: Use pci_enable_resources()") Cc: stable@vger.kernel.org Tested-by: Beiyan Yun Tested-by: Yao Zi Signed-off-by: Rong Zhang Acked-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 222afcca91f36beb956ca4906352734c21e7b2d1 Author: Harry Yoo Date: Tue Jan 13 15:18:37 2026 +0900 mm/slab: use unsigned long for orig_size to ensure proper metadata align [ Upstream commit b85f369b81aed457acbea4ad3314218254a72fd2 ] When both KASAN and SLAB_STORE_USER are enabled, accesses to struct kasan_alloc_meta fields can be misaligned on 64-bit architectures. This occurs because orig_size is currently defined as unsigned int, which only guarantees 4-byte alignment. When struct kasan_alloc_meta is placed after orig_size, it may end up at a 4-byte boundary rather than the required 8-byte boundary on 64-bit systems. Note that 64-bit architectures without HAVE_EFFICIENT_UNALIGNED_ACCESS are assumed to require 64-bit accesses to be 64-bit aligned. See HAVE_64BIT_ALIGNED_ACCESS and commit adab66b71abf ("Revert: "ring-buffer: Remove HAVE_64BIT_ALIGNED_ACCESS"") for more details. Change orig_size from unsigned int to unsigned long to ensure proper alignment for any subsequent metadata. This should not waste additional memory because kmalloc objects are already aligned to at least ARCH_KMALLOC_MINALIGN. Closes: https://lore.kernel.org/all/aPrLF0OUK651M4dk@hyeyoo Suggested-by: Andrey Ryabinin Cc: stable@vger.kernel.org Fixes: 6edf2576a6cc ("mm/slub: enable debugging memory wasting of kmalloc") Signed-off-by: Harry Yoo Closes: https://lore.kernel.org/all/aPrLF0OUK651M4dk@hyeyoo/ Link: https://patch.msgid.link/20260113061845.159790-2-harry.yoo@oracle.com Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin commit 29659497e10012d811021bba2d2dd6021ec7ba91 Author: Harry Yoo Date: Mon Jan 26 21:57:14 2026 +0900 mm/slab: avoid allocating slabobj_ext array from its own slab [ Upstream commit 280ea9c3154b2af7d841f992c9fc79e9d6534e03 ] When allocating slabobj_ext array in alloc_slab_obj_exts(), the array can be allocated from the same slab we're allocating the array for. This led to obj_exts_in_slab() incorrectly returning true [1], although the array is not allocated from wasted space of the slab. Vlastimil Babka observed that this problem should be fixed even when ignoring its incompatibility with obj_exts_in_slab(), because it creates slabs that are never freed as there is always at least one allocated object. To avoid this, use the next kmalloc size or large kmalloc when the array can be allocated from the same cache we're allocating the array for. In case of random kmalloc caches, there are multiple kmalloc caches for the same size and the cache is selected based on the caller address. Because it is fragile to ensure the same caller address is passed to kmalloc_slab(), kmalloc_noprof(), and kmalloc_node_noprof(), bump the size to (s->object_size + 1) when the sizes are equal, instead of directly comparing the kmem_cache pointers. Note that this doesn't happen when memory allocation profiling is disabled, as when the allocation of the array is triggered by memory cgroup (KMALLOC_CGROUP), the array is allocated from KMALLOC_NORMAL. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202601231457.f7b31e09-lkp@intel.com [1] Cc: stable@vger.kernel.org Fixes: 4b8736964640 ("mm/slab: add allocation accounting into slab allocation and free paths") Signed-off-by: Harry Yoo Link: https://patch.msgid.link/20260126125714.88008-1-harry.yoo@oracle.com Reviewed-by: Hao Li Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin commit 78d8e2d6352e8317686ee3a44811ac14c415a57d Author: Thomas Yen Date: Fri Jan 30 00:51:51 2026 +0800 scsi: ufs: core: Flush exception handling work when RPM level is zero [ Upstream commit f8ef441811ec413717f188f63d99182f30f0f08e ] Ensure that the exception event handling work is explicitly flushed during suspend when the runtime power management level is set to UFS_PM_LVL_0. When the RPM level is zero, the device power mode and link state both remain active. Previously, the UFS core driver bypassed flushing exception event handling jobs in this configuration. This created a race condition where the driver could attempt to access the host controller to handle an exception after the system had already entered a deep power-down state, resulting in a system crash. Explicitly flush this work and disable auto BKOPs before the suspend callback proceeds. This guarantees that pending exception tasks complete and prevents illegal hardware access during the power-down sequence. Fixes: 57d104c153d3 ("ufs: add UFS power management support") Signed-off-by: Thomas Yen Cc: Stable Tree Reviewed-by: Peter Wang Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260129165156.956601-1-thomasyen@google.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 08c7eadd8a934a1968e1aeeee8b61b853b99fb3a Author: Robin Murphy Date: Tue Feb 3 14:07:29 2026 +0000 perf/arm-cmn: Reject unsupported hardware configurations [ Upstream commit 36c0de02575ce59dfd879eb4ef63d53a68bbf9ce ] So far we've been fairly lax about accepting both unknown CMN models (at least with a warning), and unknown revisions of those which we do know, as although things do frequently change between releases, typically enough remains the same to be somewhat useful for at least some basic bringup checks. However, we also make assumptions of the maximum supported sizes and numbers of things in various places, and there's no guarantee that something new might not be bigger and lead to nasty array overflows. Make sure we only try to run on things that actually match our assumptions and so will not risk memory corruption. We have at least always failed on completely unknown node types, so update that error message for clarity and consistency too. Cc: stable@vger.kernel.org Fixes: 7819e05a0dce ("perf/arm-cmn: Revamp model detection") Reviewed-by: Ilkka Koskinen Signed-off-by: Robin Murphy Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 500778df9e4c313190368908ff40c23948508e97 Author: Peng Fan Date: Thu Jan 29 09:44:48 2026 +0800 remoteproc: imx_rproc: Fix invalid loaded resource table detection [ Upstream commit 26aa5295010ffaebcf8f1991c53fa7cf2ee1b20d ] imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded resource table even when the current firmware does not provide one. When the device tree contains a "rsc-table" entry, priv->rsc_table is non-NULL and denotes where a resource table would be located if one is present in memory. However, when the current firmware has no resource table, rproc->table_ptr is NULL. The function still returns priv->rsc_table, and the remoteproc core interprets this as a valid loaded resource table. Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when there is no resource table for the current firmware (i.e. when rproc->table_ptr is NULL). This aligns the function's semantics with the remoteproc core: a loaded resource table is only reported when a valid table_ptr exists. With this change, starting firmware without a resource table no longer triggers a crash. Fixes: e954a1bd1610 ("remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table") Cc: stable@vger.kernel.org Signed-off-by: Peng Fan Acked-by: Daniel Baluta Link: https://lore.kernel.org/r/20260129-imx-rproc-fix-v3-1-fc4e41e6e750@nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 4c0382b86600e3079a15842e8791ffcc69cdeef4 Author: jinbaohong Date: Wed Jan 28 07:06:38 2026 +0000 btrfs: continue trimming remaining devices on failure [ Upstream commit 912d1c6680bdb40b72b1b9204706f32b6eb842c3 ] Commit 93bba24d4b5a ("btrfs: Enhance btrfs_trim_fs function to handle error better") intended to make device trimming continue even if one device fails, tracking failures and reporting them at the end. However, it used 'break' instead of 'continue', causing the loop to exit on the first device failure. Fix this by replacing 'break' with 'continue'. Fixes: 93bba24d4b5a ("btrfs: Enhance btrfs_trim_fs function to handle error better") CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Qu Wenruo Signed-off-by: Robbie Ko Signed-off-by: jinbaohong Reviewed-by: Filipe Manana Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f4951c56d59c2f07cbefeb4b6bac75c58d364af1 Author: Naohiro Aota Date: Fri Jan 23 21:41:35 2026 +0900 btrfs: zoned: fixup last alloc pointer after extent removal for DUP [ Upstream commit e2d848649e64de39fc1b9c64002629b4daa1105d ] When a block group is composed of a sequential write zone and a conventional zone, we recover the (pseudo) write pointer of the conventional zone using the end of the last allocated position. However, if the last extent in a block group is removed, the last extent position will be smaller than the other real write pointer position. Then, that will cause an error due to mismatch of the write pointers. We can fixup this case by moving the alloc_offset to the corresponding write pointer position. Fixes: c0d90a79e8e6 ("btrfs: zoned: fix alloc_offset calculation for partly conventional block groups") CC: stable@vger.kernel.org # 6.16+ Reviewed-by: Johannes Thumshirn Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 72f6529487a378d24d664167076d85d8f30c12d1 Author: Naohiro Aota Date: Wed Dec 17 20:14:04 2025 +0900 btrfs: zoned: fixup last alloc pointer after extent removal for RAID1 [ Upstream commit dda3ec9ee6b3e120603bff1b798f25b51e54ac5d ] When a block group is composed of a sequential write zone and a conventional zone, we recover the (pseudo) write pointer of the conventional zone using the end of the last allocated position. However, if the last extent in a block group is removed, the last extent position will be smaller than the other real write pointer position. Then, that will cause an error due to mismatch of the write pointers. We can fixup this case by moving the alloc_offset to the corresponding write pointer position. Fixes: 568220fa9657 ("btrfs: zoned: support RAID0/1/10 on top of raid stripe tree") CC: stable@vger.kernel.org # 6.12+ Reviewed-by: Johannes Thumshirn Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 25afd2a1ee4d2d5470dc0945ff412e2625eb867a Author: Sun YangKai Date: Wed Jan 14 11:47:02 2026 +0800 btrfs: fix periodic reclaim condition [ Upstream commit 19eff93dc738e8afaa59cb374b44bb5a162e6c2d ] Problems with current implementation: 1. reclaimable_bytes is signed while chunk_sz is unsigned, causing negative reclaimable_bytes to trigger reclaim unexpectedly 2. The "space must be freed between scans" assumption breaks the two-scan requirement: first scan marks block groups, second scan reclaims them. Without the second scan, no reclamation occurs. Instead, track actual reclaim progress: pause reclaim when block groups will be reclaimed, and resume only when progress is made. This ensures reclaim continues until no further progress can be made. And resume periodic reclaim when there's enough free space. And we take care if reclaim is making any progress now, so it's unnecessary to set periodic_reclaim_ready to false when failed to reclaim a block group. Fixes: 813d4c6422516 ("btrfs: prevent pathological periodic reclaim loops") CC: stable@vger.kernel.org # 6.12+ Suggested-by: Boris Burkov Reviewed-by: Boris Burkov Signed-off-by: Sun YangKai Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit da86ca15d7389ee0b5df08e8f70c39354e6b8a4b Author: Marek Vasut Date: Thu Jan 22 00:26:38 2026 +0100 clk: rs9: Reserve 8 struct clk_hw slots for for 9FGV0841 [ Upstream commit 5ec820fc28d0b8a0f3890d476b1976f20e8343cc ] The 9FGV0841 has 8 outputs and registers 8 struct clk_hw, make sure there are 8 slots for those newly registered clk_hw pointers, else there is going to be out of bounds write when pointers 4..7 are set into struct rs9_driver_data .clk_dif[4..7] field. Since there are other structure members past this struct clk_hw pointer array, writing to .clk_dif[4..7] fields corrupts both the struct rs9_driver_data content and data around it, sometimes without crashing the kernel. However, the kernel does surely crash when the driver is unbound or during suspend. Fix this, increase the struct clk_hw pointer array size to the maximum output count of 9FGV0841, which is the biggest chip that is supported by this driver. Cc: stable@vger.kernel.org Fixes: f0e5e1800204 ("clk: rs9: Add support for 9FGV0841") Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/CAMuHMdVyQpOBT+Ho+mXY07fndFN9bKJdaaWGn91WOFnnYErLyg@mail.gmail.com Signed-off-by: Marek Vasut Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 4ce27e86d641cafab11df1078c3eb84539f13395 Author: Breno Leitao Date: Wed Jan 28 10:16:11 2026 -0800 uprobes: Fix incorrect lockdep condition in filter_chain() [ Upstream commit a56a38fd9196fc89401e498d70b7aa9c9679fa6e ] The list_for_each_entry_rcu() in filter_chain() uses rcu_read_lock_trace_held() as the lockdep condition, but the function holds consumer_rwsem, not the RCU trace lock. This gives me the following output when running with some locking debug option enabled: kernel/events/uprobes.c:1141 RCU-list traversed in non-reader section!! filter_chain register_for_each_vma uprobe_unregister_nosync __probe_event_disable Remove the incorrect lockdep condition since the rwsem provides sufficient protection for the list traversal. Fixes: cc01bd044e6a ("uprobes: travers uprobe's consumer list locklessly under SRCU protection") Signed-off-by: Breno Leitao Signed-off-by: Peter Zijlstra (Intel) Acked-by: Oleg Nesterov Acked-by: Andrii Nakryiko Acked-by: Masami Hiramatsu (Google) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260128-uprobe_rcu-v2-1-994ea6d32730@debian.org Signed-off-by: Sasha Levin commit 956d54e07ca7788ffcbcf1e5bc947665a17dd844 Author: Marco Elver Date: Fri Jan 30 14:28:24 2026 +0100 arm64: Fix non-atomic __READ_ONCE() with CONFIG_LTO=y [ Upstream commit bb0c99e08ab9aa6d04b40cb63c72db9950d51749 ] The implementation of __READ_ONCE() under CONFIG_LTO=y incorrectly qualified the fallback "once" access for types larger than 8 bytes, which are not atomic but should still happen "once" and suppress common compiler optimizations. The cast `volatile typeof(__x)` applied the volatile qualifier to the pointer type itself rather than the pointee. This created a volatile pointer to a non-volatile type, which violated __READ_ONCE() semantics. Fix this by casting to `volatile typeof(*__x) *`. With a defconfig + LTO + debug options build, we see the following functions to be affected: xen_manage_runstate_time (884 -> 944 bytes) xen_steal_clock (248 -> 340 bytes) ^-- use __READ_ONCE() to load vcpu_runstate_info structs Fixes: e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when CONFIG_LTO=y") Cc: stable@vger.kernel.org Reviewed-by: Boqun Feng Signed-off-by: Marco Elver Tested-by: David Laight Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit bea1d373098b22d7142da48750ce5526096425bc Author: Niklas Schnelle Date: Tue Dec 16 23:14:03 2025 +0100 PCI/IOV: Fix race between SR-IOV enable/disable and hotplug [ Upstream commit a5338e365c4559d7b4d7356116b0eb95b12e08d5 ] Commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV") tried to fix a race between the VF removal inside sriov_del_vfs() and concurrent hot unplug by taking the PCI rescan/remove lock in sriov_del_vfs(). Similarly the PCI rescan/remove lock was also taken in sriov_add_vfs() to protect addition of VFs. This approach however causes deadlock on trying to remove PFs with SR-IOV enabled because PFs disable SR-IOV during removal and this removal happens under the PCI rescan/remove lock. So the original fix had to be reverted. Instead of taking the PCI rescan/remove lock in sriov_add_vfs() and sriov_del_vfs(), fix the race that occurs with SR-IOV enable and disable vs hotplug higher up in the callchain by taking the lock in sriov_numvfs_store() before calling into the driver's sriov_configure() callback. Fixes: 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV") Reported-by: Benjamin Block Signed-off-by: Niklas Schnelle Signed-off-by: Bjorn Helgaas Reviewed-by: Benjamin Block Reviewed-by: Gerd Bayer Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251216-revert_sriov_lock-v3-2-dac4925a7621@linux.ibm.com Signed-off-by: Sasha Levin commit 40f67686a5002c0c322fac918406bbc8d9c2ec2f Author: Niklas Schnelle Date: Tue Dec 16 23:14:02 2025 +0100 Revert "PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV" [ Upstream commit 2fa119c0e5e528453ebae9e70740e8d2d8c0ed5a ] This reverts commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"), which causes a deadlock by recursively taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of pci_stop_and_remove_bus_device(). For example with the following sequence of commands: $ echo > /sys/bus/pci/devices//sriov_numvfs $ echo 1 > /sys/bus/pci/devices//remove A trimmed trace of the deadlock on a mlx5 device is as below: zsh/5715 is trying to acquire lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140 but task is already holding lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80 ... Call Trace: [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110 [<00000259779c844e>] print_deadlock_bug+0x31e/0x330 [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0 [<00000259779bffac>] lock_acquire+0x14c/0x350 [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520 [<000002597896413c>] mutex_lock_nested+0x3c/0x50 [<00000259784a07e4>] sriov_disable+0x34/0x140 [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core] [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core] [<00000259784857fc>] pci_device_remove+0x3c/0xa0 [<000002597851012e>] device_release_driver_internal+0x18e/0x280 [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0 [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80 [<00000259784972c2>] remove_store+0x72/0x90 [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200 [<0000025977d7241c>] vfs_write+0x24c/0x300 [<0000025977d72696>] ksys_write+0x86/0x110 [<000002597895b61c>] __do_syscall+0x14c/0x400 [<000002597896e0ee>] system_call+0x6e/0x90 This alone is not a complete fix as it restores the issue the cited commit tried to solve. A new fix will be provided as a follow on. Fixes: 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV") Reported-by: Benjamin Block Signed-off-by: Niklas Schnelle Signed-off-by: Bjorn Helgaas Reviewed-by: Benjamin Block Acked-by: Gerd Bayer Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251216-revert_sriov_lock-v3-1-dac4925a7621@linux.ibm.com Signed-off-by: Sasha Levin commit f86582890bd7a72a75293e4abbf84c17bca4e754 Author: Evangelos Petrongonas Date: Tue Jan 20 17:59:11 2026 +0000 kho: skip memoryless NUMA nodes when reserving scratch areas [ Upstream commit 427b2535f51342de3156babc6bdc3f3b7dd2c707 ] kho_reserve_scratch() iterates over all online NUMA nodes to allocate per-node scratch memory. On systems with memoryless NUMA nodes (nodes that have CPUs but no memory), memblock_alloc_range_nid() fails because there is no memory available on that node. This causes KHO initialization to fail and kho_enable to be set to false. Some ARM64 systems have NUMA topologies where certain nodes contain only CPUs without any associated memory. These configurations are valid and should not prevent KHO from functioning. Fix this by only counting nodes that have memory (N_MEMORY state) and skip memoryless nodes in the per-node scratch allocation loop. Link: https://lkml.kernel.org/r/20260120175913.34368-1-epetron@amazon.de Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers"). Signed-off-by: Evangelos Petrongonas Reviewed-by: Pratyush Yadav Reviewed-by: Mike Rapoport (Microsoft) Reviewed-by: Pasha Tatashin Cc: Alexander Graf Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit fdf605f64f824c1b363b591dca96b6ea2bdef607 Author: Vasily Gorbik Date: Mon Jan 26 12:20:46 2026 +0100 crash_dump: fix dm_crypt keys locking and ref leak [ Upstream commit 96a54b8ffc8c4567c32fe0b6996669f1132b026d ] crash_load_dm_crypt_keys() reads dm-crypt volume keys from the user keyring. It uses user_key_payload_locked() without holding key->sem, which makes lockdep complain when kexec_file_load() assembles the crash image: ============================= WARNING: suspicious RCU usage ----------------------------- ./include/keys/user-type.h:53 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by kexec/4875. stack backtrace: Call Trace: dump_stack_lvl+0x5d/0x80 lockdep_rcu_suspicious.cold+0x4e/0x96 crash_load_dm_crypt_keys+0x314/0x390 bzImage64_load+0x116/0x9a0 ? __lock_acquire+0x464/0x1ba0 __do_sys_kexec_file_load+0x26a/0x4f0 do_syscall_64+0xbd/0x430 entry_SYSCALL_64_after_hwframe+0x77/0x7f In addition, the key returned by request_key() is never key_put()'d, leaking a key reference on each load attempt. Take key->sem while copying the payload and drop the key reference afterwards. Link: https://lkml.kernel.org/r/patch.git-2d4d76083a5c.your-ad-here.call-01769426386-ext-2560@work.hours Fixes: 479e58549b0f ("crash_dump: store dm crypt keys in kdump reserved memory") Signed-off-by: Vasily Gorbik Cc: Baoquan He Cc: Coiby Xu Cc: Dave Young Cc: Vivek Goyal Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 36eb314184a0ae74dd42914b47d2b9fc43be8034 Author: Li Chen Date: Tue Jan 20 20:40:04 2026 +0800 kexec: derive purgatory entry from symbol [ Upstream commit 480e1d5c64bb14441f79f2eb9421d5e26f91ea3d ] kexec_load_purgatory() derives image->start by locating e_entry inside an SHF_EXECINSTR section. If the purgatory object contains multiple executable sections with overlapping sh_addr, the entrypoint check can match more than once and trigger a WARN. Derive the entry section from the purgatory_start symbol when present and compute image->start from its final placement. Keep the existing e_entry fallback for purgatories that do not expose the symbol. WARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#10: kexec/1784 Call Trace: bzImage64_load+0x133/0xa00 __do_sys_kexec_file_load+0x2b3/0x5c0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e [me@linux.beauty: move helper to avoid forward declaration, per Baoquan] Link: https://lkml.kernel.org/r/20260128043511.316860-1-me@linux.beauty Link: https://lkml.kernel.org/r/20260120124005.148381-1-me@linux.beauty Fixes: 8652d44f466a ("kexec: support purgatories with .text.hot sections") Signed-off-by: Li Chen Acked-by: Baoquan He Cc: Alexander Graf Cc: Eric Biggers Cc: Li Chen Cc: Philipp Rudo Cc: Ricardo Ribalda Delgado Cc: Ross Zwisler Cc: Sourabh Jain Cc: Steven Rostedt Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 3bdc3766aafb052aef4baadef455a84c1c0a059d Author: Heming Zhao Date: Wed Dec 10 09:57:24 2025 +0800 ocfs2: fix reflink preserve cleanup issue [ Upstream commit 5138c936c2c82c9be8883921854bc6f7e1177d8c ] commit c06c303832ec ("ocfs2: fix xattr array entry __counted_by error") doesn't handle all cases and the cleanup job for preserved xattr entries still has bug: - the 'last' pointer should be shifted by one unit after cleanup an array entry. - current code logic doesn't cleanup the first entry when xh_count is 1. Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3. Link: https://lkml.kernel.org/r/20251210015725.8409-2-heming.zhao@suse.com Fixes: 0fe9b66c65f3 ("ocfs2: Add preserve to reflink.") Signed-off-by: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit e5a732bfe29451e16abf9c6f07ce5948b22f3d59 Author: Haoxiang Li Date: Wed Jan 21 09:35:08 2026 +0800 rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net() [ Upstream commit 666183dcdd9ad3b8156a1df7f204f728f720380f ] When idtab allocation fails, net is not registered with rio_add_net() yet, so kfree(net) is sufficient to release the memory. Set mport->net to NULL to avoid dangling pointer. Link: https://lkml.kernel.org/r/20260121013508.195836-1-lihaoxiang@isrc.iscas.ac.cn Fixes: e6b585ca6e81 ("rapidio: move net allocation into core code") Signed-off-by: Haoxiang Li Reviewed-by: Andrew Morton Cc: Alexandre Bounine Cc: Matt Porter Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 9f7a5aee917132ba352726420187bca7f6532f62 Author: Nathan Chancellor Date: Fri Jan 16 16:26:27 2026 -0700 compiler-clang.h: require LLVM 19.1.0 or higher for __typeof_unqual__ [ Upstream commit e8d899d301346a5591c9d1af06c3c9b3501cf84b ] When building the kernel using a version of LLVM between llvmorg-19-init (the first commit of the LLVM 19 development cycle) and the change in LLVM that actually added __typeof_unqual__ for all C modes [1], which might happen during a bisect of LLVM, there is a build failure: In file included from arch/x86/kernel/asm-offsets.c:9: In file included from include/linux/crypto.h:15: In file included from include/linux/completion.h:12: In file included from include/linux/swait.h:7: In file included from include/linux/spinlock.h:56: In file included from include/linux/preempt.h:79: arch/x86/include/asm/preempt.h:61:2: error: call to undeclared function '__typeof_unqual__'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 61 | raw_cpu_and_4(__preempt_count, ~PREEMPT_NEED_RESCHED); | ^ arch/x86/include/asm/percpu.h:478:36: note: expanded from macro 'raw_cpu_and_4' 478 | #define raw_cpu_and_4(pcp, val) percpu_binary_op(4, , "and", (pcp), val) | ^ arch/x86/include/asm/percpu.h:210:3: note: expanded from macro 'percpu_binary_op' 210 | TYPEOF_UNQUAL(_var) pto_tmp__; \ | ^ include/linux/compiler.h:248:29: note: expanded from macro 'TYPEOF_UNQUAL' 248 | # define TYPEOF_UNQUAL(exp) __typeof_unqual__(exp) | ^ The current logic of CC_HAS_TYPEOF_UNQUAL just checks for a major version of 19 but half of the 19 development cycle did not have support for __typeof_unqual__. Harden the logic of CC_HAS_TYPEOF_UNQUAL to avoid this error by only using __typeof_unqual__ with a released version of LLVM 19, which is greater than or equal to 19.1.0 with LLVM's versioning scheme that matches GCC's [2]. Link: https://github.com/llvm/llvm-project/commit/cc308f60d41744b5920ec2e2e5b25e1273c8704b [1] Link: https://github.com/llvm/llvm-project/commit/4532617ae420056bf32f6403dde07fb99d276a49 [2] Link: https://lkml.kernel.org/r/20260116-require-llvm-19-1-for-typeof_unqual-v1-1-3b9a4a4b212b@kernel.org Fixes: ac053946f5c4 ("compiler.h: introduce TYPEOF_UNQUAL() macro") Signed-off-by: Nathan Chancellor Cc: Bill Wendling Cc: Justin Stitt Cc: Uros Bizjak Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit d83396624fda6fcc8620d0c2a4d141b4865cb203 Author: William Tambe Date: Thu Dec 11 12:38:19 2025 -0800 mm/highmem: fix __kmap_to_page() build error [ Upstream commit 94350fe6cad77b46c3dcb8c96543bef7647efbc0 ] This changes fixes following build error which is a miss from ef6e06b2ef87 ("highmem: fix kmap_to_page() for kmap_local_page() addresses"). mm/highmem.c:184:66: error: 'pteval' undeclared (first use in this function); did you mean 'pte_val'? 184 | idx = arch_kmap_local_map_idx(i, pte_pfn(pteval)); In __kmap_to_page(), pteval is used but does not exist in the function. (akpm: affects xtensa only) Link: https://lkml.kernel.org/r/SJ0PR07MB86317E00EC0C59DA60935FDCD18DA@SJ0PR07MB8631.namprd07.prod.outlook.com Fixes: ef6e06b2ef87 ("highmem: fix kmap_to_page() for kmap_local_page() addresses") Signed-off-by: William Tambe Reviewed-by: Max Filippov Cc: Chris Zankel Cc: Max Filippov Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 491f04be585c6295e4de8648b65cbaaf1989e98d Author: Emanuele Ghidoli Date: Fri Jan 30 08:11:35 2026 +0100 power: reset: tdx-ec-poweroff: fix restart [ Upstream commit 562357a6310f79e45844c3e980d410a1e8e02ce6 ] During testing, restart occasionally failed on Toradex modules. The issue was traced to an interaction between the EC-based reset/poweroff handler and the PSCI restart handler. While the embedded controller is resetting or powering off the module, the PSCI code may still be invoked, triggering an I2C transaction to the PMIC. This can leave the PMIC I2C in a frozen state. Add a delay after issuing the EC reset or power-off command to give the controller time to complete the operation and avoid falling back to another restart/poweroff provider. Also print an error message if sending the command to the embedded controller fails. Fixes: 18672fe12367 ("power: reset: add Toradex Embedded Controller") Cc: stable@vger.kernel.org Signed-off-by: Emanuele Ghidoli Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20260130071208.1184239-1-ghidoliemanuele@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit bc1492651253e59936eab1858efa9033c8086ed7 Author: David LaPorte Date: Thu Jan 29 17:33:22 2026 -0800 mtd: spinand: Disable continuous read during probe [ Upstream commit b4af7d194dc879353829f3c56988a68fbba1fbdd ] Macronix serial NAND devices with continuous read support do not clear the configuration register on soft reset and lack a hardware reset pin. When continuous read is interrupted (e.g., during reboot), the feature remains enabled at the device level. With continuous read enabled, the OOB area becomes inaccessible and all reads are instead directed to the main area. As a result, during partition allocation as part of MTD device registration, the first two bytes of the main area for the master block are read and indicate that the block is bad. This process repeats for every subsequent block for the partition. All reads and writes that reference the BBT find no good blocks and fail. The only paths for recovery from this state are triggering the continuous read feature by way of raw MTD reads or through a NAND device power drain. Disable continuous read explicitly during spinand probe to ensure quiescent feature state. Fixes: 631cfdd0520d ("mtd: spi-nand: Add continuous read support") Cc: stable@vger.kernel.org Signed-off-by: David LaPorte Reviewed-by: Gunnar Kudrjavets Reviewed-by: Mikhail Kshevetskiy Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 5a435b0e460988f70e17fd248c47774b4bfa66ab Author: Antoniu Miclaus Date: Thu Jan 29 17:01:45 2026 +0200 iio: gyro: itg3200: Fix unchecked return value in read_raw [ Upstream commit b79b24f578cdb2d657db23e5fafe82c7e6a36b72 ] The return value from itg3200_read_reg_s16() is stored in ret but never checked. The function unconditionally returns IIO_VAL_INT, ignoring potential I2C read failures. This causes garbage data to be returned to userspace when the read fails, with no error reported. Add proper error checking to propagate the failure to callers. Fixes: 9dbf091da080 ("iio: gyro: Add itg3200") Signed-off-by: Antoniu Miclaus Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 9b85c8f624b0f8cf9b932f5a65dacd56a1f47a72 Author: Guangshuo Li Date: Tue Sep 23 21:32:35 2025 +0800 powerpc/smp: Add check for kcalloc() failure in parse_thread_groups() [ Upstream commit 33c1c6d8a28a2761ac74b0380b2563cf546c2a3a ] As kcalloc() may fail, check its return value to avoid a NULL pointer dereference when passing it to of_property_read_u32_array(). Fixes: 790a1662d3a26 ("powerpc/smp: Parse ibm,thread-groups with multiple properties") Cc: stable@vger.kernel.org Reviewed-by: Christophe Leroy Signed-off-by: Guangshuo Li Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250923133235.1862108-1-lgs201920130244@gmail.com Signed-off-by: Sasha Levin commit 7441d35d14d9a3d66d925d90cb73c75394e6d454 Author: Eugenio Pérez Date: Mon Jan 19 15:32:54 2026 +0100 vhost: move vdpa group bound check to vhost_vdpa [ Upstream commit cd025c1e876b4e262e71398236a1550486a73ede ] Remove duplication by consolidating these here. This reduces the posibility of a parent driver missing them. While we're at it, fix a bug in vdpa_sim where a valid ASID can be assigned to a group equal to ngroups, causing an out of bound write. Cc: stable@vger.kernel.org Fixes: bda324fd037a ("vdpasim: control virtqueue support") Acked-by: Jason Wang Signed-off-by: Eugenio Pérez Signed-off-by: Michael S. Tsirkin Message-Id: <20260119143306.1818855-2-eperezma@redhat.com> Signed-off-by: Sasha Levin commit dfcbe019516512b67def86706cc01833e3ba1a47 Author: Leo Yan Date: Fri Jan 23 13:32:03 2026 +0000 tools: Fix bitfield dependency failure [ Upstream commit a537c0da168a08b0b6a7f7bd9e75f4cc8d45ff57 ] A perf build failure was reported by Thomas Voegtle on stable kernel v6.6.120: CC tests/sample-parsing.o CC util/intel-pt-decoder/intel-pt-pkt-decoder.o CC util/perf-regs-arch/perf_regs_csky.o CC util/arm-spe-decoder/arm-spe-pkt-decoder.o CC util/perf-regs-arch/perf_regs_loongarch.o In file included from util/arm-spe-decoder/arm-spe-pkt-decoder.h:10, from util/arm-spe-decoder/arm-spe-pkt-decoder.c:14: /local/git/linux-stable-rc/tools/include/linux/bitfield.h: In function ‘le16_encode_bits’: /local/git/linux-stable-rc/tools/include/linux/bitfield.h:166:31: error: implicit declaration of function ‘cpu_to_le16’; did you mean ‘htole16’? [-Werror=implicit-function-declaration] ____MAKE_OP(le##size,u##size,cpu_to_le##size,le##size##_to_cpu) \ ^~~~~~~~~ /local/git/linux-stable-rc/tools/include/linux/bitfield.h:149:9: note: in definition of macro ‘____MAKE_OP’ return to((v & field_mask(field)) * field_multiplier(field)); \ ^~ /local/git/linux-stable-rc/tools/include/linux/bitfield.h:170:1: note: in expansion of macro ‘__MAKE_OP’ __MAKE_OP(16) Fix this by including linux/kernel.h, which provides the required definitions. The issue was not found on the mainline due to the relevant C files have included kernel.h. It'd be good to merge this change on mainline as well for robustness. Closes: https://lore.kernel.org/stable/3a44500b-d7c8-179f-61f6-e51cb50d3512@lio96.de/ Fixes: 64d86c03e1441742 ("perf arm-spe: Extend branch operations") Reported-by: Hamza Mahfooz Reported-by: Thomas Voegtle Signed-off-by: Leo Yan Cc: Greg Kroah-Hartman Cc: Ian Rogers Cc: James Clark Cc: Leo Yan Cc: Namhyung Kim To: Sasha Levin Cc: stable@vger.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 461242507181e4050868a20d1fa6b27f4b00d003 Author: Joey Gouly Date: Tue Jan 27 13:39:26 2026 +0000 arm64: poe: fix stale POR_EL0 values for ptrace [ Upstream commit 1f3b950492db411e6c30ee0076b61ef2694c100a ] If a process wrote to POR_EL0 and then crashed before a context switch happened, the coredump would contain an incorrect value for POR_EL0. The value read in poe_get() would be a stale value left in thread.por_el0. Fix this by reading the value from the system register, if the target thread is the current thread. This matches what gcs/fpsimd do. Fixes: 175198199262 ("arm64/ptrace: add support for FEAT_POE") Reported-by: David Spickett Cc: stable@vger.kernel.org Signed-off-by: Joey Gouly Cc: Kevin Brodsky Cc: Mark Rutland Reviewed-by: Kevin Brodsky Acked-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit e9051992fd21fd6091edfc9423718018d80360a0 Author: Benjamin Marzinski Date: Tue Jan 27 19:12:24 2026 -0500 dm mpath: make pg_init_delay_msecs settable [ Upstream commit 218b16992a37ea97b9e09b7659a25a864fb9976f ] "pg_init_delay_msecs X" can be passed as a feature in the multipath table and is used to set m->pg_init_delay_msecs in parse_features(). However, alloc_multipath_stage2(), which is called after parse_features(), resets m->pg_init_delay_msecs to its default value. Instead, set m->pg_init_delay_msecs in alloc_multipath(), which is called before parse_features(), to avoid overwriting a value passed in by the table. Signed-off-by: Benjamin Marzinski Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit b662f91e216fded3d52e48e05e848a92c3bb8f72 Author: Haoxiang Li Date: Sat Jan 24 18:20:54 2026 +0800 bus: fsl-mc: fix an error handling in fsl_mc_device_add() [ Upstream commit 52f527d0916bcdd7621a0c9e7e599b133294d495 ] In fsl_mc_device_add(), device_initialize() is called first. put_device() should be called to drop the reference if error occurs. And other resources would be released via put_device -> fsl_mc_device_release. So remove redundant kfree() in error handling path. Fixes: bbf9d17d9875 ("staging: fsl-mc: Freescale Management Complex (fsl-mc) bus driver") Cc: stable@vger.kernel.org Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/b767348e-d89c-416e-acea-1ebbff3bea20@stanley.mountain/ Signed-off-by: Su Hui Suggested-by: Christophe Leroy (CS GROUP) Signed-off-by: Haoxiang Li Reviewed-by: Ioana Ciornei Link: https://lore.kernel.org/r/20260124102054.1613093-1-lihaoxiang@isrc.iscas.ac.cn Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit ab81f9f3319e081b4a3201bbf7a846b7a4c10a04 Author: Jens Axboe Date: Tue Jan 27 21:01:41 2026 -0700 io_uring/net: don't continue send bundle if poll was required for retry [ Upstream commit 806ae939c41e5da1d94a1e2b31f5702e96b6c3e3 ] If a send bundle has picked a bunch of buffers, then it needs to send all of those to be complete. This may require poll arming, if the send buffer ends up being full. Once a send bundle has been poll armed, no further bundles should be attempted. This allows a current bundle to complete even though it needs to go through polling to do so, but it will not allow another bundle to be started once that has happened. Ideally we would abort a bundle if it was only partially sent, but as some parts of it already went out on the wire, this obviously isn't feasible. Not continuing more bundle attempts post encountering a full socket buffer is the second best thing. Cc: stable@vger.kernel.org Fixes: a05d1f625c7a ("io_uring/net: support bundles for send") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit bce59008b23479b470ba07ee550c3c9b7cf2fdb8 Author: Vlastimil Babka Date: Fri Jan 23 07:52:39 2026 +0100 mm/slab: add rcu_barrier() to kvfree_rcu_barrier_on_cache() [ Upstream commit b55b423e8518361124ff0a9e15df431b3682ee4f ] After we submit the rcu_free sheaves to call_rcu() we need to make sure the rcu callbacks complete. kvfree_rcu_barrier() does that via flush_all_rcu_sheaves() but kvfree_rcu_barrier_on_cache() doesn't. Fix that. This currently causes no issues because the caches with sheaves we have are never destroyed. The problem flagged by kernel test robot was reported for a patch that enables sheaves for (almost) all caches, and occurred only with CONFIG_KASAN. Harry Yoo found the root cause [1]: It turns out the object freed by sheaf_flush_unused() was in KASAN percpu quarantine list (confirmed by dumping the list) by the time __kmem_cache_shutdown() returns an error. Quarantined objects are supposed to be flushed by kasan_cache_shutdown(), but things go wrong if the rcu callback (rcu_free_sheaf_nobarn()) is processed after kasan_cache_shutdown() finishes. That's why rcu_barrier() in __kmem_cache_shutdown() didn't help, because it's called after kasan_cache_shutdown(). Calling rcu_barrier() in kvfree_rcu_barrier_on_cache() guarantees that it'll be added to the quarantine list before kasan_cache_shutdown() is called. So it's a valid fix! [1] https://lore.kernel.org/all/aWd6f3jERlrB5yeF@hyeyoo/ Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202601121442.c530bed3-lkp@intel.com Fixes: 0f35040de593 ("mm/slab: introduce kvfree_rcu_barrier_on_cache() for cache destruction") Cc: stable@vger.kernel.org Reviewed-by: Harry Yoo Tested-by: Harry Yoo Reviewed-by: Suren Baghdasaryan Reviewed-by: Liam R. Howlett Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin commit f42941d60f01ad59b1eff78b35ea33711a60a4d0 Author: Haotien Hsu Date: Sat Jan 24 01:31:21 2026 +0800 usb: gadget: tegra-xudc: Add handling for BLCG_COREPLL_PWRDN [ Upstream commit 1132e90840abf3e7db11f1d28199e9fbc0b0e69e ] The COREPLL_PWRDN bit in the BLCG register must be set when the XUSB device controller is powergated and cleared when it is unpowergated. If this bit is not explicitly controlled, the core PLL may remain in an incorrect power state across suspend/resume or ELPG transitions. Therefore, update the driver to explicitly control this bit during powergate transitions. Fixes: 49db427232fe ("usb: gadget: Add UDC driver for tegra XUSB device mode controller") Cc: stable Signed-off-by: Haotien Hsu Signed-off-by: Wayne Chang Link: https://patch.msgid.link/20260123173121.4093902-1-waynec@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1afe45f89d54b7183768ebbbbf14238ec187ab5c Author: Deepanshu Kartikey Date: Mon Jan 12 16:06:12 2026 +0530 mm/vmalloc: prevent RCU stalls in kasan_release_vmalloc_node [ Upstream commit 5747435e0fd474c24530ef1a6822f47e7d264b27 ] When CONFIG_PAGE_OWNER is enabled, freeing KASAN shadow pages during vmalloc cleanup triggers expensive stack unwinding that acquires RCU read locks. Processing a large purge_list without rescheduling can cause the task to hold CPU for extended periods (10+ seconds), leading to RCU stalls and potential OOM conditions. The issue manifests in purge_vmap_node() -> kasan_release_vmalloc_node() where iterating through hundreds or thousands of vmap_area entries and freeing their associated shadow pages causes: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P6229/1:b..l ... task:kworker/0:17 state:R running task stack:28840 pid:6229 ... kasan_release_vmalloc_node+0x1ba/0xad0 mm/vmalloc.c:2299 purge_vmap_node+0x1ba/0xad0 mm/vmalloc.c:2299 Each call to kasan_release_vmalloc() can free many pages, and with page_owner tracking, each free triggers save_stack() which performs stack unwinding under RCU read lock. Without yielding, this creates an unbounded RCU critical section. Add periodic cond_resched() calls within the loop to allow: - RCU grace periods to complete - Other tasks to run - Scheduler to preempt when needed The fix uses need_resched() for immediate response under load, with a batch count of 32 as a guaranteed upper bound to prevent worst-case stalls even under light load. Link: https://lkml.kernel.org/r/20260112103612.627247-1-kartikey406@gmail.com Signed-off-by: Deepanshu Kartikey Reported-by: syzbot+d8d4c31d40f868eaea30@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d8d4c31d40f868eaea30 Link: https://lore.kernel.org/all/20260112084723.622910-1-kartikey406@gmail.com/T/ [v1] Suggested-by: Uladzislau Rezki Reviewed-by: Uladzislau Rezki (Sony) Cc: Hillf Danton Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit d4a132f121c591b60dbaf57ea91f1faf11631fbc Author: Harshit Mogalapalli Date: Tue Dec 30 22:16:09 2025 -0800 x86/kexec: add a sanity check on previous kernel's ima kexec buffer [ Upstream commit c5489d04337b47e93c0623e8145fcba3f5739efd ] When the second-stage kernel is booted via kexec with a limiting command line such as "mem=", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail. Link: https://lkml.kernel.org/r/20251231061609.907170-4-harshit.m.mogalapalli@oracle.com Signed-off-by: Harshit Mogalapalli Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec") Reported-by: Paul Webb Reviewed-by: Mimi Zohar Cc: Alexander Graf Cc: Ard Biesheuvel Cc: Baoquan He Cc: Borislav Betkov Cc: guoweikang Cc: Henry Willard Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jiri Bohac Cc: Joel Granados Cc: Jonathan McDowell Cc: Mike Rapoport Cc: Sohil Mehta Cc: Sourabh Jain Cc: Thomas Gleinxer Cc: Yifei Liu Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 1ca6530f07d4ae1786a2a42b169f0903df995134 Author: Harshit Mogalapalli Date: Tue Dec 30 22:16:08 2025 -0800 of/kexec: refactor ima_get_kexec_buffer() to use ima_validate_range() [ Upstream commit 4d02233235ed0450de9c10fcdcf3484e3c9401ce ] Refactor the OF/DT ima_get_kexec_buffer() to use a generic helper to validate the address range. No functional change intended. Link: https://lkml.kernel.org/r/20251231061609.907170-3-harshit.m.mogalapalli@oracle.com Signed-off-by: Harshit Mogalapalli Reviewed-by: Mimi Zohar Cc: Alexander Graf Cc: Ard Biesheuvel Cc: Baoquan He Cc: Borislav Betkov Cc: guoweikang Cc: Henry Willard Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jiri Bohac Cc: Joel Granados Cc: Jonathan McDowell Cc: Mike Rapoport Cc: Paul Webb Cc: Sohil Mehta Cc: Sourabh Jain Cc: Thomas Gleinxer Cc: Yifei Liu Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 9e1f51c1ad57cc76a0e8b5eb27038f8973fff4fa Author: Harshit Mogalapalli Date: Tue Dec 30 22:16:07 2025 -0800 ima: verify the previous kernel's IMA buffer lies in addressable RAM [ Upstream commit 10d1c75ed4382a8e79874379caa2ead8952734f9 ] Patch series "Address page fault in ima_restore_measurement_list()", v3. When the second-stage kernel is booted via kexec with a limiting command line such as "mem=" we observe a pafe fault that happens. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) not-present page This happens on x86_64 only, as this is already fixed in aarch64 in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") This patch (of 3): When the second-stage kernel is booted with a limiting command line (e.g. "mem="), the IMA measurement buffer handed over from the previous kernel may fall outside the addressable RAM of the new kernel. Accessing such a buffer can fault during early restore. Introduce a small generic helper, ima_validate_range(), which verifies that a physical [start, end] range for the previous-kernel IMA buffer lies within addressable memory: - On x86, use pfn_range_is_mapped(). - On OF based architectures, use page_is_ram(). Link: https://lkml.kernel.org/r/20251231061609.907170-1-harshit.m.mogalapalli@oracle.com Link: https://lkml.kernel.org/r/20251231061609.907170-2-harshit.m.mogalapalli@oracle.com Signed-off-by: Harshit Mogalapalli Reviewed-by: Mimi Zohar Cc: Alexander Graf Cc: Ard Biesheuvel Cc: Borislav Betkov Cc: guoweikang Cc: Henry Willard Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jiri Bohac Cc: Joel Granados Cc: Jonathan McDowell Cc: Mike Rapoport Cc: Paul Webb Cc: Sohil Mehta Cc: Sourabh Jain Cc: Thomas Gleinxer Cc: Yifei Liu Cc: Baoquan He Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 995240f823a320ecb16afe0429b23793145dfab2 Author: Ilpo Järvinen Date: Fri Dec 19 19:40:14 2025 +0200 PCI: Fix bridge window alignment with optional resources [ Upstream commit 7e90360e6d4599795b6f4e094e20d0bdf3b2615f ] pbus_size_mem() has two alignments, one for required resources in min_align and another in add_align that takes account optional resources. The add_align is applied to the bridge window through the realloc_head list. It can happen, however, that add_align is larger than min_align but calculated size1 and size0 are equal due to extra tailroom (e.g., hotplug reservation, tail alignment), and therefore no entry is created to the realloc_head list. Without the bridge appearing in the realloc head, add_align is lost when pbus_size_mem() returns. The problem is visible in this log for 0000:05:00.0 which lacks add_size ... add_align ... line that would indicate it was added into the realloc_head list: pci 0000:05:00.0: PCI bridge to [bus 06-16] ... pci 0000:06:00.0: bridge window [mem 0x00100000-0x001fffff] to [bus 07] requires relaxed alignment rules pci 0000:06:06.0: bridge window [mem 0x00100000-0x001fffff] to [bus 0a] requires relaxed alignment rules pci 0000:06:07.0: bridge window [mem 0x00100000-0x003fffff] to [bus 0b] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x00800000-0x00ffffff 64bit pref] to [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] add_size 100000 add_align 1000000 pci 0000:06:0c.0: bridge window [mem 0x00100000-0x001fffff] to [bus 15] requires relaxed alignment rules pci 0000:06:0d.0: bridge window [mem 0x00100000-0x001fffff] to [bus 16] requires relaxed alignment rules pci 0000:06:0d.0: bridge window [mem 0x00100000-0x001fffff] to [bus 16] requires relaxed alignment rules pci 0000:05:00.0: bridge window [mem 0xd4800000-0xd97fffff]: assigned pci 0000:05:00.0: bridge window [mem 0x1060000000-0x10607fffff 64bit pref]: assigned pci 0000:06:08.0: bridge window [mem size 0x04900000]: can't assign; no space pci 0000:06:08.0: bridge window [mem size 0x04900000]: failed to assign While this bug itself seems old, it has likely become more visible after the relaxed tail alignment that does not grossly overestimate the size needed for the bridge window. Make sure add_align > min_align too results in adding an entry into the realloc head list. In addition, add handling to the cases where add_size is zero while only alignment differs. Fixes: d74b9027a4da ("PCI: Consider additional PF's IOV BAR alignment in sizing and assigning") Reported-by: Malte Schröder Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Malte Schröder Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251219174036.16738-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit 26da747e754c60ed94808b7017ed94a0a3c2a706 Author: Krzysztof Kozlowski Date: Fri Jan 16 17:08:43 2026 +0000 nvmem: Drop OF node reference on nvmem_add_one_cell() failure [ Upstream commit f397bc0781553d01b4cdba506c09334a31cb0ec5 ] If nvmem_add_one_cell() failed, the ownership of "child" (or "info.np"), thus its OF reference, is not passed further and function should clean up by putting the reference it got via earlier of_node_get(). Note that this is independent of references obtained via for_each_child_of_node() loop. Fixes: 50014d659617 ("nvmem: core: use nvmem_add_one_cell() in nvmem_add_cells_from_of()") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260116170846.733558-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2eb988d5c8f8e962b2daf41c9f702f849df4ceac Author: Anthony Iliopoulos Date: Mon Dec 22 14:30:05 2025 -0500 nfsd: fix return error code for nfsd_map_name_to_[ug]id [ Upstream commit 404d779466646bf1461f2090ff137e99acaecf42 ] idmap lookups can time out while the cache is waiting for a userspace upcall reply. In that case cache_check() returns -ETIMEDOUT to callers. The nfsd_map_name_to_[ug]id functions currently proceed with attempting to map the id to a kuid despite a potentially temporary failure to perform the idmap lookup. This results in the code returning the error NFSERR_BADOWNER which can cause client operations to return to userspace with failure. Fix this by returning the failure status before attempting kuid mapping. This will return NFSERR_JUKEBOX on idmap lookup timeout so that clients can retry the operation instead of aborting it. Fixes: 65e10f6d0ab0 ("nfsd: Convert idmap to use kuids and kgids") Cc: stable@vger.kernel.org Signed-off-by: Anthony Iliopoulos Reviewed-by: NeilBrown Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 6689272b826186b0e9dc099a63bc9ba96ca164e2 Author: Olga Kornievskaia Date: Fri Dec 19 12:59:55 2025 -0500 NFSD: fix setting FMODE_NOCMTIME in nfs4_open_delegation [ Upstream commit 41b0a87bc60d5ccfa8575481ddb4d4d8758507fa ] fstests generic/215 and generic/407 were failing because the server wasn't updating mtime properly. When deleg attribute support is not compiled in and thus no attribute delegation was given, the server was skipping updating mtime and ctime because FMODE_NOCMTIME was uncoditionally set for the write delegation. Fixes: e5e9b24ab8fa ("nfsd: freeze c/mtime updates with outstanding WRITE_ATTRS delegation") Cc: stable@vger.kernel.org Signed-off-by: Olga Kornievskaia Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 9a6f8cd28bb9bb6ed86a6df19331fb08016dee7f Author: Jack Wang Date: Tue Jan 20 11:24:56 2026 +0100 md/bitmap: fix GPF in write_page caused by resize race [ Upstream commit 46ef85f854dfa9d5226b3c1c46493d79556c9589 ] A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod] This is a use-after-free race between bitmap_daemon_work() and __bitmap_resize(). The daemon iterates over `bitmap->storage.filemap` without locking, while the resize path frees that storage via md_bitmap_file_unmap(). `quiesce()` does not stop the md thread, allowing concurrent access to freed pages. Fix by holding `mddev->bitmap_info.mutex` during the bitmap update. Link: https://lore.kernel.org/linux-raid/20260120102456.25169-1-jinpu.wang@ionos.com Closes: https://lore.kernel.org/linux-raid/CAMGffE=Mbfp=7xD_hYxXk1PAaCZNSEAVeQGKGy7YF9f2S4=NEA@mail.gmail.com/T/#u Cc: stable@vger.kernel.org Fixes: d60b479d177a ("md/bitmap: add bitmap_resize function to allow bitmap resizing.") Signed-off-by: Jack Wang Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit b04baa848c0543b240b1bd8aecff470382f6f154 Author: Darrick J. Wong Date: Fri Jan 23 09:27:40 2026 -0800 xfs: check for deleted cursors when revalidating two btrees [ Upstream commit 55e03b8cbe2783ec9acfb88e8adb946ed504e117 ] The free space and inode btree repair functions will rebuild both btrees at the same time, after which it needs to evaluate both btrees to confirm that the corruptions are gone. However, Jiaming Zhang ran syzbot and produced a crash in the second xchk_allocbt call. His root-cause analysis is as follows (with minor corrections): In xrep_revalidate_allocbt(), xchk_allocbt() is called twice (first for BNOBT, second for CNTBT). The cause of this issue is that the first call nullified the cursor required by the second call. Let's first enter xrep_revalidate_allocbt() via following call chain: xfs_file_ioctl() -> xfs_ioc_scrubv_metadata() -> xfs_scrub_metadata() -> `sc->ops->repair_eval(sc)` -> xrep_revalidate_allocbt() xchk_allocbt() is called twice in this function. In the first call: /* Note that sc->sm->sm_type is XFS_SCRUB_TYPE_BNOPT now */ xchk_allocbt() -> xchk_btree() -> `bs->scrub_rec(bs, recp)` -> xchk_allocbt_rec() -> xchk_allocbt_xref() -> xchk_allocbt_xref_other() since sm_type is XFS_SCRUB_TYPE_BNOBT, pur is set to &sc->sa.cnt_cur. Kernel called xfs_alloc_get_rec() and returned -EFSCORRUPTED. Call chain: xfs_alloc_get_rec() -> xfs_btree_get_rec() -> xfs_btree_check_block() -> (XFS_IS_CORRUPT || XFS_TEST_ERROR), the former is false and the latter is true, return -EFSCORRUPTED. This should be caused by ioctl$XFS_IOC_ERROR_INJECTION I guess. Back to xchk_allocbt_xref_other(), after receiving -EFSCORRUPTED from xfs_alloc_get_rec(), kernel called xchk_should_check_xref(). In this function, *curpp (points to sc->sa.cnt_cur) is nullified. Back to xrep_revalidate_allocbt(), since sc->sa.cnt_cur has been nullified, it then triggered null-ptr-deref via xchk_allocbt() (second call) -> xchk_btree(). So. The bnobt revalidation failed on a cross-reference attempt, so we deleted the cntbt cursor, and then crashed when we tried to revalidate the cntbt. Therefore, check for a null cntbt cursor before that revalidation, and mark the repair incomplete. Also we can ignore the second tree entirely if the first tree was rebuilt but is already corrupt. Apply the same fix to xrep_revalidate_iallocbt because it has the same problem. Cc: r772577952@gmail.com Link: https://lore.kernel.org/linux-xfs/CANypQFYU5rRPkTy=iG5m1Lp4RWasSgrHXAh3p8YJojxV0X15dQ@mail.gmail.com/T/#m520c7835fad637eccf843c7936c200589427cc7e Cc: # v6.8 Fixes: dbfbf3bdf639a2 ("xfs: repair inode btrees") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Tested-by: Jiaming Zhang Signed-off-by: Sasha Levin commit 2b658d1249666cc55af9484dcf5f45ca438d4ecc Author: Darrick J. Wong Date: Fri Jan 23 09:27:38 2026 -0800 xfs: check return value of xchk_scrub_create_subord [ Upstream commit ca27313fb3f23e4ac18532ede4ec1c7cc5814c4a ] Fix this function to return NULL instead of a mangled ENOMEM, then fix the callers to actually check for a null pointer and return ENOMEM. Most of the corrections here are for code merged between 6.2 and 6.10. Cc: r772577952@gmail.com Cc: # v6.12 Fixes: 1a5f6e08d4e379 ("xfs: create subordinate scrub contexts for xchk_metadata_inode_subtype") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Tested-by: Jiaming Zhang Signed-off-by: Sasha Levin commit c9ccefacae0d8091683447bc338bd7741417039d Author: Darrick J. Wong Date: Fri Jan 23 09:27:37 2026 -0800 xfs: only call xf{array,blob}_destroy if we have a valid pointer [ Upstream commit ba408d299a3bb3c5309f40c5326e4fb83ead4247 ] Only call the xfarray and xfblob destructor if we have a valid pointer, and be sure to null out that pointer afterwards. Note that this patch fixes a large number of commits, most of which were merged between 6.9 and 6.10. Cc: r772577952@gmail.com Cc: # v6.12 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Tested-by: Jiaming Zhang Signed-off-by: Sasha Levin commit c2ce8d9a3b9899e780eb959c53b34e6f8094b9c7 Author: Raag Jadav Date: Sat Jan 24 13:44:54 2026 +0530 pinctrl: intel: Add code name documentation [ Upstream commit fc32c5725fbe1164d353400389d3e29d19960a3a ] Intel pinctrl drivers support large set of platforms and the IPs are often reused by their different variants, but it's currently not possible to figure out the exact driver that supports specific variant. Add user friendly documentation for them. Cc: stable@vger.kernel.org Reported-by: Guido Trentalancia Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220056 Signed-off-by: Raag Jadav Acked-by: Mika Westerberg Acked-by: Guido Trentalancia [andy: added Oxford comma] Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 733cbc3aa97e71cc70847e75c925b364cc9b04a6 Author: Manikanta Maddireddy Date: Thu Jan 8 11:57:47 2026 +0530 PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functions [ Upstream commit 8754dd7639ab0fd68c3ab9d91c7bdecc3e5740a8 ] struct configfs_item_operations callbacks are defined like the following: int (*allow_link)(struct config_item *src, struct config_item *target); void (*drop_link)(struct config_item *src, struct config_item *target); While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specify the parameters in the correct order, pci_primary_epc_epf_unlink() and pci_secondary_epc_epf_unlink() specify the parameters in the wrong order, leading to the below kernel crash when using the unlink command in configfs: Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintk_default+0x38/0x4c vprintk+0xc4/0xe0 pci_epf_unbind+0xdc/0x108 configfs_unlink+0xe0/0x208+0x44/0x74 vfs_unlink+0x120/0x29c __arm64_sys_unlinkat+0x3c/0x90 invoke_syscall+0x48/0x134 do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0 Fixes: e85a2d783762 ("PCI: endpoint: Add support in configfs to associate two EPCs with EPF") Signed-off-by: Manikanta Maddireddy [mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Reviewed-by: Frank Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260108062747.1870669-1-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 57536ff0a6bd69a5808d682925202babdb5ddc13 Author: Vasiliy Kovalev Date: Sat Jan 24 01:28:01 2026 +0300 KVM: x86: Add SRCU protection for reading PDPTRs in __get_sregs2() [ Upstream commit 95d848dc7e639988dbb385a8cba9b484607cf98c ] Add SRCU read-side protection when reading PDPTR registers in __get_sregs2(). Reading PDPTRs may trigger access to guest memory: kvm_pdptr_read() -> svm_cache_reg() -> load_pdptrs() -> kvm_vcpu_read_guest_page() -> kvm_vcpu_gfn_to_memslot() kvm_vcpu_gfn_to_memslot() dereferences memslots via __kvm_memslots(), which uses srcu_dereference_check() and requires either kvm->srcu or kvm->slots_lock to be held. Currently only vcpu->mutex is held, triggering lockdep warning: ============================= WARNING: suspicious RCU usage in kvm_vcpu_gfn_to_memslot 6.12.59+ #3 Not tainted include/linux/kvm_host.h:1062 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by syz.5.1717/15100: #0: ff1100002f4b00b0 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x1d5/0x1590 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xf0/0x120 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x1e3/0x270 kernel/locking/lockdep.c:6824 __kvm_memslots include/linux/kvm_host.h:1062 [inline] __kvm_memslots include/linux/kvm_host.h:1059 [inline] kvm_vcpu_memslots include/linux/kvm_host.h:1076 [inline] kvm_vcpu_gfn_to_memslot+0x518/0x5e0 virt/kvm/kvm_main.c:2617 kvm_vcpu_read_guest_page+0x27/0x50 virt/kvm/kvm_main.c:3302 load_pdptrs+0xff/0x4b0 arch/x86/kvm/x86.c:1065 svm_cache_reg+0x1c9/0x230 arch/x86/kvm/svm/svm.c:1688 kvm_pdptr_read arch/x86/kvm/kvm_cache_regs.h:141 [inline] __get_sregs2 arch/x86/kvm/x86.c:11784 [inline] kvm_arch_vcpu_ioctl+0x3e20/0x4aa0 arch/x86/kvm/x86.c:6279 kvm_vcpu_ioctl+0x856/0x1590 virt/kvm/kvm_main.c:4663 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xbd/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Suggested-by: Sean Christopherson Cc: stable@vger.kernel.org Fixes: 6dba94035203 ("KVM: x86: Introduce KVM_GET_SREGS2 / KVM_SET_SREGS2") Signed-off-by: Vasiliy Kovalev Link: https://patch.msgid.link/20260123222801.646123-1-kovalev@altlinux.org Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit aaaea528d476852f21ec51fc752d9b8364552a2c Author: Lyude Paul Date: Thu Jan 22 17:10:37 2026 -0500 rust/drm: Fix Registration::{new,new_foreign_owned}() docs [ Upstream commit 638eeda8abaa3e6afe6bd5758ef8045a7f33b9a0 ] Looks like we've actually had a malformed rustdoc reference in the rustdocs for Registration::new_foreign_owned() for a while that, when fixed, still couldn't resolve properly because it refers to a private item. This is probably leftover from when Registration::new() was public, so drop the documentation from that function and fixup the documentation for Registration::new_foreign_owned(). Signed-off-by: Lyude Paul Acked-by: Danilo Krummrich Fixes: 0600032c54b7 ("rust: drm: add DRM driver registration") Cc: # v6.16+ Link: https://patch.msgid.link/20260122221037.3462081-1-lyude@redhat.com Signed-off-by: Sasha Levin commit 71cfbc15c91a666a4e9852b2d0378dc9224b7ab3 Author: Janne Grunau Date: Fri Jan 23 10:20:34 2026 -0800 spmi: apple: Add "apple,t8103-spmi" compatible [ Upstream commit 6c54b0a801dd8227237ba0bf0728bb42681cf027 ] After discussion with the devicetree maintainers we agreed to not extend lists with the generic compatible "apple,spmi" anymore [1]. Use "apple,t8103-spmi" as base compatible as it is the SoC the driver and bindings were written for. [1]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/ Fixes: 77ca75e80c71 ("spmi: add a spmi driver for Apple SoC") Cc: stable@vger.kernel.org Reviewed-by: Neal Gompa Signed-off-by: Janne Grunau Signed-off-by: Stephen Boyd Link: https://patch.msgid.link/20260123182039.224314-7-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 18e9cf2259b4157fd282b323514375f2f6a59edb Author: Darrick J. Wong Date: Fri Jan 23 09:27:37 2026 -0800 xfs: get rid of the xchk_xfile_*_descr calls [ Upstream commit 60382993a2e18041f88c7969f567f168cd3b4de3 ] The xchk_xfile_*_descr macros call kasprintf, which can fail to allocate memory if the formatted string is larger than 16 bytes (or whatever the nofail guarantees are nowadays). Some of them could easily exceed that, and Jiaming Zhang found a few places where that can happen with syzbot. The descriptions are debugging aids and aren't required to be unique, so let's just pass in static strings and eliminate this path to failure. Note this patch touches a number of commits, most of which were merged between 6.6 and 6.14. Cc: r772577952@gmail.com Cc: # v6.12 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Tested-by: Jiaming Zhang Signed-off-by: Sasha Levin commit d1a3cc775c6e2b5e1235922581395263e5309983 Author: Darrick J. Wong Date: Fri Jan 23 09:27:33 2026 -0800 xfs: fix remote xattr valuelblk check [ Upstream commit bd3138e8912c9db182eac5fed1337645a98b7a4f ] In debugging other problems with generic/753, it turns out that it's possible for the system go to down in the middle of a remote xattr set operation such that the leaf block entry is marked incomplete and valueblk is set to zero. Make this no longer a failure. Cc: # v4.15 Fixes: 13791d3b833428 ("xfs: scrub extended attribute leaf space") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 652d815b856c68760e61a9920b1c00e55b7ab24b Author: Darrick J. Wong Date: Fri Jan 23 09:27:33 2026 -0800 xfs: fix the xattr scrub to detect freemap/entries array collisions [ Upstream commit 6fed8270448c246e706921c177e9633013dd3fcf ] In the previous patches, we observed that it's possible for there to be freemap entries with zero size but a nonzero base. This isn't an inconsistency per se, but older kernels can get confused by this and corrupt the block, leading to corruption. If we see this, flag the xattr structure for optimization so that it gets rebuilt. Cc: # v4.15 Fixes: 13791d3b833428 ("xfs: scrub extended attribute leaf space") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 43f3b18679615a93bd848afde3602ba160637a46 Author: Darrick J. Wong Date: Fri Jan 23 09:27:31 2026 -0800 xfs: fix freemap adjustments when adding xattrs to leaf blocks [ Upstream commit 3eefc0c2b78444b64feeb3783c017d6adc3cd3ce ] xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and the previous patch that resets zero length freemap entries to have base = 0. Cc: # v2.6.12 Fixes: 1da177e4c3f415 ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit f31a8334e1c54b126fcecf98645a49b6bc5ad399 Author: Darrick J. Wong Date: Fri Jan 23 09:27:30 2026 -0800 xfs: delete attr leaf freemap entries when empty [ Upstream commit 6f13c1d2a6271c2e73226864a0e83de2770b6f34 ] Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the "pushed-up" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap. It looks like this bug has been in the codebase for quite a long time. Cc: # v2.6.12 Fixes: 1da177e4c3f415 ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit d54f00547c210940e53110338da00fc82228d2b2 Author: Wayne Chang Date: Thu Jan 15 18:36:21 2026 +0800 usb: host: tegra: Remove manual wake IRQ disposal [ Upstream commit ef548189fd3f44786fb813af0018cc8b3bbed2b9 ] We found that calling irq_dispose_mapping() caused a kernel warning when removing the driver. The IRQs are obtained using platform_get_irq(), which returns a Linux virtual IRQ number directly managed by the device core, not by the OF subsystem. Therefore, the driver should not call irq_dispose_mapping() for these IRQs. Fixes: 5df186e2ef11 ("usb: xhci: tegra: Support USB wakeup function for Tegra234") Cc: stable@vger.kernel.org Signed-off-by: Wayne Chang Signed-off-by: Wei-Cheng Chen Link: https://patch.msgid.link/20260115103621.587366-1-weichengc@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a50006e7ba0e31b49a00a3d4fef89161298f866e Author: Nicolin Chen Date: Wed Jan 14 17:12:43 2026 -0800 iommu/arm-smmu-v3: Do not set disable_ats unless vSTE is Translate [ Upstream commit a45dd34663025c75652b27e384e91c9c05ba1d80 ] A vSTE may have three configuration types: Abort, Bypass, and Translate. An Abort vSTE wouldn't enable ATS, but the other two might. It makes sense for a Transalte vSTE to rely on the guest vSTE.EATS field. For a Bypass vSTE, it would end up with an S2-only physical STE, similar to an attachment to a regular S2 domain. However, the nested case always disables ATS following the Bypass vSTE, while the regular S2 case always enables ATS so long as arm_smmu_ats_supported(master) == true. Note that ATS is needed for certain VM centric workloads and historically non-vSMMU cases have relied on this automatic enablement. So, having the nested case behave differently causes problems. To fix that, add a condition to disable_ats, so that it might enable ATS for a Bypass vSTE, aligning with the regular S2 case. Fixes: f27298a82ba0 ("iommu/arm-smmu-v3: Allow ATS for IOMMU_DOMAIN_NESTED") Cc: stable@vger.kernel.org Suggested-by: Jason Gunthorpe Signed-off-by: Nicolin Chen Reviewed-by: Pranjal Shrivastava Reviewed-by: Jason Gunthorpe Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 779e0c250a6b8a0a2c1e2f39bedfb159100d113d Author: Jason Gunthorpe Date: Thu Jan 15 10:23:30 2026 -0800 iommu/arm-smmu-v3: Mark EATS_TRANS safe when computing the update sequence [ Upstream commit 7cad800485956a263318930613f8f4a084af8c70 ] If VM wants to toggle EATS_TRANS off at the same time as changing the CFG, hypervisor will see EATS change to 0 and insert a V=0 breaking update into the STE even though the VM did not ask for that. In bare metal, EATS_TRANS is ignored by CFG=ABORT/BYPASS, which is why this does not cause a problem until we have the nested case where CFG is always a variation of S2 trans that does use EATS_TRANS. Relax the rules for EATS_TRANS sequencing, we don't need it to be exact as the enclosing code will always disable ATS at the PCI device when changing EATS_TRANS. This ensures there are no ATS transactions that can race with an EATS_TRANS change so we don't need to carefully sequence these bits. Fixes: 1e8be08d1c91 ("iommu/arm-smmu-v3: Support IOMMU_DOMAIN_NESTED") Cc: stable@vger.kernel.org Signed-off-by: Jason Gunthorpe Reviewed-by: Shuai Xue Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 3f73325f4548beee0a1f1d378ffe74ca1748570d Author: Jason Gunthorpe Date: Thu Jan 15 10:23:29 2026 -0800 iommu/arm-smmu-v3: Mark STE MEV safe when computing the update sequence [ Upstream commit f3c1d372dbb8e5a86923f20db66deabef42bfc9d ] Nested CD tables set the MEV bit to try to reduce multi-fault spamming on the hypervisor. Since MEV is in STE word 1 this causes a breaking update sequence that is not required and impacts real workloads. For the purposes of STE updates the value of MEV doesn't matter, if it is set/cleared early or late it just results in a change to the fault reports that must be supported by the kernel anyhow. The spec says: Note: Software must expect, and be able to deal with, coalesced fault records even when MEV == 0. So mark STE MEV safe when computing the update sequence, to avoid creating a breaking update. Fixes: da0c56520e88 ("iommu/arm-smmu-v3: Set MEV bit in nested STE for DoS mitigations") Cc: stable@vger.kernel.org Signed-off-by: Jason Gunthorpe Reviewed-by: Shuai Xue Reviewed-by: Mostafa Saleh Reviewed-by: Pranjal Shrivastava Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit efd59553e477fe139f9981ab36a899869dae9294 Author: Jason Gunthorpe Date: Thu Jan 15 10:23:28 2026 -0800 iommu/arm-smmu-v3: Add update_safe bits to fix STE update sequence [ Upstream commit 2781f2a930abb5d27f80b8afbabfa19684833b65 ] C_BAD_STE was observed when updating nested STE from an S1-bypass mode to an S1DSS-bypass mode. As both modes enabled S2, the used bit is slightly different than the normal S1-bypass and S1DSS-bypass modes. As a result, fields like MEV and EATS in S2's used list marked the word1 as a critical word that requested a STE.V=0. This breaks a hitless update. However, both MEV and EATS aren't critical in terms of STE update. One controls the merge of the events and the other controls the ATS that is managed by the driver at the same time via pci_enable_ats(). Add an arm_smmu_get_ste_update_safe() to allow STE update algorithm to relax those fields, avoiding the STE update breakages. After this change, entry_set has no caller checking its return value, so change it to void. Note that this change is required by both MEV and EATS fields, which were introduced in different kernel versions. So add get_update_safe() first. MEV and EATS will be added to arm_smmu_get_ste_update_safe() separately. Fixes: 1e8be08d1c91 ("iommu/arm-smmu-v3: Support IOMMU_DOMAIN_NESTED") Cc: stable@vger.kernel.org Signed-off-by: Jason Gunthorpe Reviewed-by: Shuai Xue Reviewed-by: Mostafa Saleh Reviewed-by: Pranjal Shrivastava Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit a8e88edfd69df7b63c882aa53e61e7c078806ad7 Author: Francesco Lavra Date: Mon Jan 19 11:23:16 2026 +0100 iio: accel: adxl380: Avoid reading more entries than present in FIFO [ Upstream commit c1b14015224cfcccd5356333763f2f4f401bd810 ] The interrupt handler reads FIFO entries in batches of N samples, where N is the number of scan elements that have been enabled. However, the sensor fills the FIFO one sample at a time, even when more than one channel is enabled. Therefore,the number of entries reported by the FIFO status registers may not be a multiple of N; if this number is not a multiple, the number of entries read from the FIFO may exceed the number of entries actually present. To fix the above issue, round down the number of FIFO entries read from the status registers so that it is always a multiple of N. Fixes: df36de13677a ("iio: accel: add ADXL380 driver") Signed-off-by: Francesco Lavra Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 48281492144919f6662b1fbcce2e850c123ddf1b Author: Brian Norris Date: Thu Jan 22 09:48:15 2026 -0800 PCI/PM: Prevent runtime suspend until devices are fully initialized [ Upstream commit 51c0996dadaea20d73eb0495aeda9cb0422243e8 ] Previously, it was possible for a PCI device to be runtime-suspended before it was fully initialized. When that happened, the suspend process could save invalid device state, for example, before BAR assignment. Restoring the invalid state during resume may leave the device non-functional. Prevent runtime suspend for PCI devices until they are fully initialized by deferring pm_runtime_enable(). More details on how exactly this may occur: 1. PCI device is created by pci_scan_slot() or similar 2. As part of pci_scan_slot(), pci_pm_init() puts the device in D0 and prevents runtime suspend prevented via pm_runtime_forbid() 3. pci_device_add() adds the underlying 'struct device' via device_add(), which means user space can allow runtime suspend, e.g., echo auto > /sys/bus/pci/devices/.../power/control 4. PCI device receives BAR configuration (pci_assign_unassigned_bus_resources(), etc.) 5. pci_bus_add_device() applies final fixups, saves device state, and tries to attach a driver The device may potentially be suspended between #3 and #5, so this is racy with user space (udev or similar). Many PCI devices are enumerated at subsys_initcall time and so will not race with user space, but devices created later by hotplug or modular pwrctrl or host controller drivers are susceptible to this race. More runtime PM details at the first Link: below. Link: https://lore.kernel.org/all/0e35a4e1-894a-47c1-9528-fc5ffbafd9e2@samsung.com/ Signed-off-by: Brian Norris [bhelgaas: update comments per https://lore.kernel.org/r/CAJZ5v0iBNOmMtqfqEbrYyuK2u+2J2+zZ-iQd1FvyCPjdvU2TJg@mail.gmail.com] Signed-off-by: Bjorn Helgaas Tested-by: Marek Szyprowski Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260122094815.v5.1.I60a53c170a8596661883bd2b4ef475155c7aa72b@changeid Signed-off-by: Sasha Levin commit d6e866f3a183e8c7c05d29a5426420a603351f9d Author: Alexey Charkov Date: Wed Jan 21 11:42:13 2026 +0400 arm64: dts: rockchip: Explicitly request UFS reset pin on RK3576 [ Upstream commit 79a3286e61829fc43abdd6e3beb31b24930c7af6 ] Rockchip RK3576 UFS controller uses a dedicated pin to reset the connected UFS device, which can operate either in a hardware controlled mode or as a GPIO pin. Power-on default is GPIO mode, but the boot ROM reconfigures it to a hardware controlled mode if it uses UFS to load the next boot stage. Given that existing bindings (and rk3576.dtsi) expect a GPIO-controlled device reset, request the required pin config explicitly. The pin is requested with pull-down enabled, which is in line with the SoC power-on default and helps ensure that the attached UFS chip stays in reset until the driver takes over the control of the respective GPIO line. This doesn't appear to affect Linux, but it does affect U-boot: Before: => md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ < ... snip ... > => ufs init ufshcd-rockchip ufshc@2a2d0000: [RX, TX]: gear=[3, 3], lane[2, 2], pwr[FASTAUTO_MODE, FASTAUTO_MODE], rate = 2 => md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ After: => md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ < ... snip ...> => ufs init ufshcd-rockchip ufshc@2a2d0000: [RX, TX]: gear=[3, 3], lane[2, 2], pwr[FASTAUTO_MODE, FASTAUTO_MODE], rate = 2 => md.l 0x2604b398 2604b398: 00000010 00000000 00000000 00000000 ................ (0x2604b398 is the respective pin mux register, with its BIT0 driving the mode of UFS_RST: unset = GPIO, set = hardware controlled UFS_RST) This helps ensure that GPIO-driven device reset actually fires when the system requests it, not when whatever black box magic inside the UFSHC decides to reset the flash chip. Cc: stable@vger.kernel.org Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC") Reported-by: Quentin Schulz Reviewed-by: Quentin Schulz Signed-off-by: Alexey Charkov Link: https://patch.msgid.link/20260121-ufs-rst-v3-1-35839bcb4ca7@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 8d8a878ef60801d867119b3df6a93e2982d62a71 Author: Gao Xiang Date: Mon Dec 29 17:29:47 2025 +0800 erofs: fix incorrect early exits in volume label handling [ Upstream commit 3afa4da38802a4cba1c23848a32284e7e57b831b ] Crafted EROFS images containing valid volume labels can trigger incorrect early returns, leading to folio reference leaks. However, this does not cause system crashes or other severe issues. Fixes: 1cf12c717741 ("erofs: Add support for FS_IOC_GETFSLABEL") Cc: stable@kernel.org Reviewed-by: Hongbo Li Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 041b5163bb9b2e81050bcd885b3373bf2f42d5f5 Author: Gao Xiang Date: Mon Dec 29 17:29:46 2025 +0800 erofs: fix incorrect early exits for invalid metabox-enabled images [ Upstream commit 643575d5a4f24b23b0c54aa20aa74a4abed8ff5e ] Crafted EROFS images with metadata compression enabled can trigger incorrect early returns, leading to folio reference leaks. However, this does not cause system crashes or other severe issues. Fixes: 414091322c63 ("erofs: implement metadata compression") Cc: stable@kernel.org Reviewed-by: Hongbo Li Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 70746336cae662d949f3e152f97d56312e19f7bf Author: Johan Hovold Date: Fri Dec 19 12:07:14 2025 +0100 mfd: omap-usb-host: Fix OF populate on driver rebind [ Upstream commit 24804ba508a3e240501c521685a1c4eb9f574f8e ] Since commit c6e126de43e7 ("of: Keep track of populated platform devices") child devices will not be created by of_platform_populate() if the devices had previously been deregistered individually so that the OF_POPULATED flag is still set in the corresponding OF nodes. Switch to using of_platform_depopulate() instead of open coding so that the child devices are created if the driver is rebound. Fixes: c6e126de43e7 ("of: Keep track of populated platform devices") Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Johan Hovold Reviewed-by: Andreas Kemnade Link: https://patch.msgid.link/20251219110714.23919-1-johan@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 26946602744082934d93e94bf168dd7bcbef6d39 Author: Johan Hovold Date: Fri Dec 19 12:09:47 2025 +0100 mfd: qcom-pm8xxx: Fix OF populate on driver rebind [ Upstream commit 27a8acea47a93fea6ad0e2df4c20a9b51490e4d9 ] Since commit c6e126de43e7 ("of: Keep track of populated platform devices") child devices will not be created by of_platform_populate() if the devices had previously been deregistered individually so that the OF_POPULATED flag is still set in the corresponding OF nodes. Switch to using of_platform_depopulate() instead of open coding so that the child devices are created if the driver is rebound. Fixes: c6e126de43e7 ("of: Keep track of populated platform devices") Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Johan Hovold Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20251219110947.24101-1-johan@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit a1e9e299c0d9ea42ab1067b39fb72e976d3f1bdb Author: Janne Grunau Date: Wed Dec 31 10:42:12 2025 +0100 mfd: macsmc: Initialize mutex [ Upstream commit 414f65d6736342c77d4ec5e7373039f4a09250dd ] Initialize struct apple_smc's mutex in apple_smc_probe(). Using the mutex uninitialized surprisingly resulted only in occasional NULL pointer dereferences in apple_smc_read() calls from the probe() functions of sub devices. Cc: stable@vger.kernel.org Fixes: e038d985c9823 ("mfd: Add Apple Silicon System Management Controller") Signed-off-by: Janne Grunau Reviewed-by: Sven Peter Reviewed-by: Neal Gompa Link: https://patch.msgid.link/20251231-macsmc-mutex_init-v2-1-5818c9dc9b29@jannau.net Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 89bdcd39ae8b1ffd7000897b30d152729b68d49d Author: Kory Maincent (TI.com) Date: Thu Dec 18 16:06:28 2025 +0100 mfd: tps65219: Implement LOCK register handling for TPS65214 [ Upstream commit d3fcf276b501a82d4504fd5b1ed40249546530d1 ] The TPS65214 PMIC variant has a LOCK_REG register that prevents writes to nearly all registers when locked. Unlock the registers at probe time and leave them unlocked permanently. This approach is justified because: - Register locking is very uncommon in typical system operation - No code path is expected to lock the registers during runtime - Adding a custom regmap write function would add overhead to every register write, including voltage changes triggered by CPU OPP transitions from the cpufreq governor which could happen quite frequently Cc: stable@vger.kernel.org Fixes: 7947219ab1a2d ("mfd: tps65219: Add support for TI TPS65214 PMIC") Reviewed-by: Andrew Davis Signed-off-by: Kory Maincent (TI.com) Link: https://patch.msgid.link/20251218-fix_tps65219-v5-1-8bb511417f3a@bootlin.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 9b02e3fec3a7fcb990b4d3bd3b13d7edf123dca6 Author: Douglas Anderson Date: Wed Dec 10 11:30:03 2025 -0800 mfd: core: Add locking around 'mfd_of_node_list' [ Upstream commit 20117c92bcf9c11afd64d7481d8f94fdf410726e ] Manipulating a list in the kernel isn't safe without some sort of mutual exclusion. Add a mutex any time we access / modify 'mfd_of_node_list' to prevent possible crashes. Cc: stable@vger.kernel.org Fixes: 466a62d7642f ("mfd: core: Make a best effort attempt to match devices with the correct of_nodes") Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20251210113002.1.I6ceaca2cfb7eb25737012b166671f516696be4fd@changeid Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 25056a2fc07fafbba3933a58ec829f5e59d42c19 Author: Zenghui Yu (Huawei) Date: Wed Jan 21 18:16:31 2026 +0800 KVM: arm64: nv: Return correct RES0 bits for FGT registers [ Upstream commit 2eb80a2eee18762a33aa770d742d64fe47852c7e ] We had extended the sysreg masking infrastructure to more general registers, instead of restricting it to VNCR-backed registers, since commit a0162020095e ("KVM: arm64: Extend masking facility to arbitrary registers"). Fix kvm_get_sysreg_res0() to reflect this fact. Note that we're sure that we only deal with FGT registers in kvm_get_sysreg_res0(), the if (sr < __VNCR_START__) is actually a never false, which should probably be removed later. Fixes: 69c19e047dfe ("KVM: arm64: Add TCR2_EL2 to the sysreg arrays") Signed-off-by: Zenghui Yu (Huawei) Link: https://patch.msgid.link/20260121101631.41037-1-zenghui.yu@linux.dev Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 8722a8fb7ed9242029531b880851f43163482fcc Author: Yi Liu Date: Thu Jan 22 09:48:53 2026 +0800 iommu/vt-d: Flush piotlb for SVM and Nested domain [ Upstream commit 04b1b069f151e793767755f58b51670bff00cbc1 ] Besides the paging domains that use FS, SVM and Nested domains need to use piotlb invalidation descriptor as well. Fixes: b33125296b50 ("iommu/vt-d: Create unique domain ops for each stage") Cc: stable@vger.kernel.org Signed-off-by: Yi Liu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20251223065824.6164-1-yi.l.liu@intel.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 9deaacc8dcaddb6ddc5b52e1e63b457450ec0f94 Author: Jinhui Guo Date: Thu Jan 22 09:48:51 2026 +0800 iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode [ Upstream commit 10e60d87813989e20eac1f3eda30b3bae461e7f9 ] Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") relies on pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system. For example, if a VM fails to connect to the PCIe device, "virsh destroy" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd. Call Trace: qi_submit_sync qi_flush_dev_iotlb intel_pasid_tear_down_entry device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput Although pci_device_is_present() is slower than pci_dev_is_disconnected(), it still takes only ~70 µs on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase. Besides, devtlb_invalidation_with_pasid() is called only in the paths below, which are far less frequent than memory map/unmap. 1. mm-struct release 2. {attach,release}_dev 3. set/remove PASID 4. dirty-tracking setup The gain in system stability far outweighs the negligible cost of using pci_device_is_present() instead of pci_dev_is_disconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions. Fixes: 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") Cc: stable@vger.kernel.org Signed-off-by: Jinhui Guo Link: https://lore.kernel.org/r/20251211035946.2071-3-guojinhui.liam@bytedance.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 69c32df23bed6001864779b965fa009bcd9a26de Author: Michal Pecio Date: Wed Oct 15 13:36:42 2025 +0200 media: uvcvideo: Return queued buffers on start_streaming() failure [ Upstream commit 4cf3b6fd54ebb1ebc977bdc47fb6cfcf9a471a22 ] Return buffers if streaming fails to start due to uvc_pm_get() error. This bug may be responsible for a warning I got running while :; do yavta -c3 /dev/video0; done on an xHCI controller which failed under this workload. I had no luck reproducing this warning again to confirm. xhci_hcd 0000:09:00.0: HC died; cleaning up usb 13-2: USB disconnect, device number 2 WARNING: CPU: 2 PID: 29386 at drivers/media/common/videobuf2/videobuf2-core.c:1803 vb2_start_streaming+0xac/0x120 Fixes: 7dd56c47784a ("media: uvcvideo: Remove stream->is_streaming field") Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio Reviewed-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20251015133642.3dede646.michal.pecio@gmail.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 97330e31ea1646a9fae568c2a5bbf2f0d41d10bf Author: Eric Biggers Date: Fri Jan 16 19:02:36 2026 -0800 dm: fix excessive blk-crypto operations for invalid keys [ Upstream commit d6d0e6b9d54532264761405a1ba8ea5bd293acb1 ] dm_exec_wrappedkey_op() passes through the derive_sw_secret, import_key, generate_key, and prepare_key blk-crypto operations to an underlying device. Currently, it calls the operation on every underlying device until one returns success. This logic is flawed when the operation is expected to fail, such as an invalid key being passed to derive_sw_secret. That can happen if userspace passes an invalid key to the FS_IOC_ADD_ENCRYPTION_KEY ioctl. When that happens on a device-mapper device that consists of many dm-linear targets, a lot of unnecessary key unwrapping requests get sent to the underlying key wrapping hardware. Fix this by considering the first device only. As already documented in the comment, it was already checked that all underlying devices support wrapped keys, so this should be fine. Fixes: e93912786e50 ("dm: pass through operations on wrapped inline crypto keys") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit f122f2b3ce9dbde60bf7ab0b180fe4a01f9d9bc4 Author: Benjamin Gaignard Date: Wed Jan 14 10:07:10 2026 +0100 media: verisilicon: AV1: Fix tile info buffer size [ Upstream commit a505ca2db89ad92a8d8d27fa68ebafb12e04a679 ] Each tile info is composed of: row_sb, col_sb, start_pos and end_pos (4 bytes each). So the total required memory is AV1_MAX_TILES * 16 bytes. Use the correct #define to allocate the buffer and avoid writing tile info in non-allocated memory. Signed-off-by: Benjamin Gaignard Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: stable@vger.kernel.org Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 457121c01f609b9934addbb04d5c1ef638c71c61 Author: Christoph Hellwig Date: Fri Jan 9 16:17:40 2026 +0100 xfs: remove xfs_attr_leaf_hasname [ Upstream commit 3a65ea768b8094e4699e72f9ab420eb9e0f3f568 ] The calling convention of xfs_attr_leaf_hasname() is problematic, because it returns a NULL buffer when xfs_attr3_leaf_read fails, a valid buffer when xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and a non-NULL buffer pointer for an already released buffer when xfs_attr3_leaf_lookup_int fails with other error values. Fix this by simply open coding xfs_attr_leaf_hasname in the callers, so that the buffer release code is done by each caller of xfs_attr3_leaf_read. Cc: stable@vger.kernel.org # v5.19+ Fixes: 07120f1abdff ("xfs: Add xfs_has_attr and subroutines") Reported-by: Mark Tinguely Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin commit 00195330d172e95e338898d8b23670c76f0c0c0a Author: Darrick J. Wong Date: Thu Dec 18 18:40:50 2025 -0800 xfs: mark data structures corrupt on EIO and ENODATA [ Upstream commit f39854a3fb2f06dc69b81ada002b641ba5b4696b ] I learned a few things this year: first, blk_status_to_errno can return ENODATA for critical media errors; and second, the scrub code doesn't mark data structures as corrupt on ENODATA or EIO. Currently, scrub failing to capture these errors isn't all that impactful -- the checking code will exit to userspace with EIO/ENODATA, and xfs_scrub will log a complaint and exit with nonzero status. Most people treat fsck tools failing as a sign that the fs is corrupt, but online fsck should mark the metadata bad and keep moving. Cc: stable@vger.kernel.org # v4.15 Fixes: 4700d22980d459 ("xfs: create helpers to record and deal with scrub problems") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin commit aacb5f183eac5d3cc3de3f2b17f3145d5bcdf149 Author: Richard Zhu Date: Wed Jan 14 16:33:00 2026 +0800 PCI: dwc: Skip waiting for L2/L3 Ready if dw_pcie_rp::skip_l23_wait is true [ Upstream commit 58a17b2647ba5aac47e3ffafd0a9b92bf4a9bcbe ] In NXP i.MX6QP and i.MX7D SoCs, LTSSM registers are not accessible once PME_Turn_Off message is broadcasted to the link. So there is no way to verify whether the link has entered L2/L3 Ready state or not. Hence, add a new flag 'dw_pcie_rp::skip_l23_ready' and set it to 'true' for the above mentioned SoCs. This flag when set, will allow the DWC core to skip polling for L2/L3 Ready state and just wait for 10ms as recommended in the PCIe spec r6.0, sec 5.3.3.2.1. Fixes: a528d1a72597 ("PCI: imx6: Use DWC common suspend resume method") Signed-off-by: Richard Zhu [mani: renamed flag to skip_l23_ready and reworded description] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260114083300.3689672-2-hongxing.zhu@nxp.com Signed-off-by: Sasha Levin commit 42d9509161d0539767ba875f3ef6b4b3c0b425ed Author: Xu Yang Date: Tue Jan 20 19:16:46 2026 +0800 phy: fsl-imx8mq-usb: set platform driver data [ Upstream commit debf8326a435ac746f48173e4742a574810f1ff4 ] Add missing platform_set_drvdata() as the data will be used in remove(). Fixes: b58f0f86fd61 ("phy: fsl-imx8mq-usb: add tca function driver for imx95") Cc: stable@vger.kernel.org Signed-off-by: Xu Yang Reviewed-by: Frank Li Link: https://patch.msgid.link/20260120111646.3159766-1-xu.yang_2@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 5e27e7f22978538bbe12f95d462c18e0002bfa73 Author: Loic Poulain Date: Thu Dec 18 16:13:07 2025 +0100 drm/bridge: anx7625: Fix invalid EDID size [ Upstream commit 1d5362145de96b5d00d590605cc94cdfa572b405 ] DRM checks EDID block count against allocated size in drm_edid_valid function. We have to allocate the right EDID size instead of the max size to prevent the EDID to be reported as invalid. Cc: stable@kernel.org Fixes: 7c585f9a71aa ("drm/bridge: anx7625: use struct drm_edid more") Reviewed-by: Dmitry Baryshkov Signed-off-by: Loic Poulain Link: https://patch.msgid.link/20251218151307.95491-1-loic.poulain@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 6236c1cd9fdf433d39ed28b2491ccdfe7ae95061 Author: Sanjay Yadav Date: Thu Jan 8 17:02:29 2026 +0530 drm/buddy: Prevent BUG_ON by validating rounded allocation [ Upstream commit 5488a29596cdba93a60a79398dc9b69d5bdadf92 ] When DRM_BUDDY_CONTIGUOUS_ALLOCATION is set, the requested size is rounded up to the next power-of-two via roundup_pow_of_two(). Similarly, for non-contiguous allocations with large min_block_size, the size is aligned up via round_up(). Both operations can produce a rounded size that exceeds mm->size, which later triggers BUG_ON(order > mm->max_order). Example scenarios: - 9G CONTIGUOUS allocation on 10G VRAM memory: roundup_pow_of_two(9G) = 16G > 10G - 9G allocation with 8G min_block_size on 10G VRAM memory: round_up(9G, 8G) = 16G > 10G Fix this by checking the rounded size against mm->size. For non-contiguous or range allocations where size > mm->size is invalid, return -EINVAL immediately. For contiguous allocations without range restrictions, allow the request to fall through to the existing __alloc_contig_try_harder() fallback. This ensures invalid user input returns an error or uses the fallback path instead of hitting BUG_ON. v2: (Matt A) - Add Fixes, Cc stable, and Closes tags for context Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6712 Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation") Cc: # v6.7+ Cc: Christian König Cc: Arunpravin Paneer Selvam Suggested-by: Matthew Auld Signed-off-by: Sanjay Yadav Reviewed-by: Matthew Auld Reviewed-by: Arunpravin Paneer Selvam Signed-off-by: Arunpravin Paneer Selvam Link: https://patch.msgid.link/20260108113227.2101872-5-sanjay.kumar.yadav@intel.com Signed-off-by: Sasha Levin commit ca666795bd61aafad72a9917b18f216ac0958cab Author: Li Wang Date: Sun Dec 21 20:26:38 2025 +0800 selftests/mm/charge_reserved_hugetlb: drop mount size for hugetlbfs [ Upstream commit 1aa1dd9cc595917882fb6db67725442956f79607 ] charge_reserved_hugetlb.sh mounts a hugetlbfs instance at /mnt/huge with a fixed size of 256M. On systems with large base hugepages (e.g. 512MB), this is smaller than a single hugepage, so the hugetlbfs mount ends up with zero capacity (often visible as size=0 in mount output). As a result, write_to_hugetlbfs fails with ENOMEM and the test can hang waiting for progress. === Error log === # uname -r 6.12.0-xxx.el10.aarch64+64k #./charge_reserved_hugetlb.sh -cgroup-v2 # ----------------------------------------- ... # nr hugepages = 10 # writing cgroup limit: 5368709120 # writing reseravation limit: 5368709120 ... # write_to_hugetlbfs: Error mapping the file: Cannot allocate memory # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 ... # mount |grep /mnt/huge none on /mnt/huge type hugetlbfs (rw,relatime,seclabel,pagesize=512M,size=0) # grep -i huge /proc/meminfo ... HugePages_Total: 10 HugePages_Free: 10 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 524288 kB Hugetlb: 5242880 kB Drop the mount args with 'size=256M', so the filesystem capacity is sufficient regardless of HugeTLB page size. Link: https://lkml.kernel.org/r/20251221122639.3168038-3-liwang@redhat.com Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests") Signed-off-by: Li Wang Acked-by: David Hildenbrand (Red Hat) Acked-by: Waiman Long Cc: Mark Brown Cc: Shuah Khan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit a39b9928fdfd5086cadc92758cf834d5c8543e01 Author: Vlastimil Babka Date: Fri Dec 19 17:31:57 2025 +0100 mm, page_alloc, thp: prevent reclaim for __GFP_THISNODE THP allocations [ Upstream commit 9c9828d3ead69416d731b1238802af31760c823e ] Since commit cc638f329ef6 ("mm, thp: tweak reclaim/compaction effort of local-only and all-node allocations"), THP page fault allocations have settled on the following scheme (from the commit log): 1. local node only THP allocation with no reclaim, just compaction. 2. for madvised VMA's or when synchronous compaction is enabled always - THP allocation from any node with effort determined by global defrag setting and VMA madvise 3. fallback to base pages on any node Recent customer reports however revealed we have a gap in step 1 above. What we have seen is excessive reclaim due to THP page faults on a NUMA node that's close to its high watermark, while other nodes have plenty of free memory. The problem with step 1 is that it promises no reclaim after the compaction attempt, however reclaim is only avoided for certain compaction outcomes (deferred, or skipped due to insufficient free base pages), and not e.g. when compaction is actually performed but fails (we did see compact_fail vmstat counter increasing). THP page faults can therefore exhibit a zone_reclaim_mode-like behavior, which is not the intention. Thus add a check for __GFP_THISNODE that corresponds to this exact situation and prevents continuing with reclaim/compaction once the initial compaction attempt isn't successful in allocating the page. Note that commit cc638f329ef6 has not introduced this over-reclaim possibility; it appears to exist in some form since commit 2f0799a0ffc0 ("mm, thp: restore node-local hugepage allocations"). Followup commits b39d0ee2632d ("mm, page_alloc: avoid expensive reclaim when compaction may not succeed") and cc638f329ef6 have moved in the right direction, but left the abovementioned gap. Link: https://lkml.kernel.org/r/20251219-costly-noretry-thisnode-fix-v1-1-e1085a4a0c34@suse.cz Fixes: 2f0799a0ffc0 ("mm, thp: restore node-local hugepage allocations") Signed-off-by: Vlastimil Babka Acked-by: Michal Hocko Acked-by: Johannes Weiner Acked-by: Pedro Falcato Acked-by: Zi Yan Cc: Brendan Jackman Cc: "David Hildenbrand (Red Hat)" Cc: David Rientjes Cc: Joshua Hahn Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit e14d5a99b1a6c573972724760c5644ee7b35fd4c Author: Mauro Carvalho Chehab Date: Mon Jan 19 13:04:57 2026 +0100 docs: kdoc: avoid error_count overflows [ Upstream commit 802774d8539fa73487190ec45438777a3c38d424 ] The glibc library limits the return code to 8 bits. We need to stick to this limit when using sys.exit(error_count). Signed-off-by: Mauro Carvalho Chehab Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet Message-ID: <233d1674db99ed8feb405a2f781de350f0fba0ac.1768823489.git.mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin commit faccf9c1464aadebfdfe85ce74d48eed9df779a9 Author: Luca Ceresoli Date: Fri Jan 9 08:31:32 2026 +0100 drm: of: drm_of_panel_bridge_remove(): fix device_node leak [ Upstream commit a4b4385d0523e39a7c058cb5a6c8269e513126ca ] drm_of_panel_bridge_remove() uses of_graph_get_remote_node() to get a device_node but does not put the node reference. Fixes: c70087e8f16f ("drm/drm_of: add drm_of_panel_bridge_remove function") Cc: stable@vger.kernel.org # v4.15 Acked-by: Maxime Ripard Link: https://patch.msgid.link/20260109-drm-bridge-alloc-getput-drm_of_find_bridge-2-v2-1-8bad3ef90b9f@bootlin.com Signed-off-by: Luca Ceresoli Signed-off-by: Sasha Levin commit 77f69aa4deb18bab808407e5305a4571389cbf71 Author: Vishnu Reddy Date: Mon Dec 29 12:01:25 2025 +0530 media: iris: Prevent output buffer queuing before stream-on completes [ Upstream commit 2c73cfd0cfc44ffe331ccb81f6ac45fc399d9ddb ] During normal playback, stream-on for input is followed by output, and only after input stream-on does actual streaming begin. However, when gst-play performs a seek, both input and output streams are stopped, and on restart, output stream-on occurs first. At this point, firmware has not yet started streaming. Queuing output buffers before the firmware begins streaming causes it to process buffers in an invalid state, leading to an error response. These buffers are returned to the driver as errors, forcing the driver into an error state and stopping playback. Fix this by deferring output buffer queuing until stream-on completes. Input buffers can still be queued before stream-on as required. Fixes: 92e007ca5ab6 ("media: iris: Add V4L2 streaming support for encoder video device") Signed-off-by: Vishnu Reddy Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 72846441c5f6396de9face04e77fa3d28e9915b6 Author: Dikshita Agarwal Date: Mon Dec 29 12:01:24 2025 +0530 media: iris: gen2: Add sanity check for session stop [ Upstream commit 9aa8d63d09cfc44d879427cc5ba308012ca4ab8e ] In iris_kill_session, inst->state is set to IRIS_INST_ERROR and session_close is executed, which will kfree(inst_hfi_gen2->packet). If stop_streaming is called afterward, it will cause a crash. Add a NULL check for inst_hfi_gen2->packet before sendling STOP packet to firmware to fix that. Fixes: 11712ce70f8e ("media: iris: implement vb2 streaming ops") Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 7cde76db8883ec8a3d1456068079ecadbfb15ca5 Author: Dikshita Agarwal Date: Mon Dec 29 12:01:22 2025 +0530 media: iris: gen1: Destroy internal buffers after FW releases [ Upstream commit 1dabf00ee206eceb0f08a1fe5d1ce635f9064338 ] After the firmware releases internal buffers, the driver was not destroying them. This left stale allocations that were no longer used, especially across resolution changes where new buffers are allocated per the updated requirements. As a result, memory was wasted until session close. Destroy internal buffers once the release response is received from the firmware. Fixes: 73702f45db81 ("media: iris: allocate, initialize and queue internal buffers") Reviewed-by: Bryan O'Donoghue Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 64e88089a2940dcabc42c1e1f0c71bbf0bfe0ad7 Author: Dikshita Agarwal Date: Mon Dec 29 12:01:21 2025 +0530 media: iris: Skip resolution set on first IPSC [ Upstream commit 811dbc546f47559dc9d2098c612acfd47e32479e ] The resolution property is not supposed to be set during reconfig. Existing iris_drc_pending(inst) check is insufficient, as it doesn't cover the first port setting change. Extend the conditional check to also skip resolution setting when the instance is in IRIS_INST_SUB_FIRST_IPSC. Fixes: caf205548769 ("media: iris: Avoid updating frame size to firmware during reconfig") Reviewed-by: Bryan O'Donoghue Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 45b30f65feeb4d5570d5337793bb0f298be813d2 Author: Dikshita Agarwal Date: Mon Dec 29 12:01:20 2025 +0530 media: iris: Add buffer to list only after successful allocation [ Upstream commit 2d0bbd982dfdd67da488a772f7a8a1bdca7642bf ] Move `list_add_tail()` to after `dma_alloc_attrs()` succeeds when creating internal buffers. Previously, the buffer was enqueued in `buffers->list` before the DMA allocation. If the allocation failed, the function returned `-ENOMEM` while leaving a partially initialized buffer in the list, which could lead to inconsistent state and potential leaks. By adding the buffer to the list only after `dma_alloc_attrs()` succeeds, we ensure the list contains only valid, fully initialized buffers. Fixes: 73702f45db81 ("media: iris: allocate, initialize and queue internal buffers") Reviewed-by: Bryan O'Donoghue Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b59ec89f9cdf326633b49f0a810224cdfd4f2923 Author: Val Packett Date: Thu Dec 25 20:09:10 2025 -0300 media: iris: use fallback size when S_FMT is called without width/height [ Upstream commit 4980721cb97d6c47700ab61a048ac8819cfeec87 ] According to 4.5.1.5 of the M2M stateful decoder UAPI documentation, providing the width and the height to S_FMT is "required only if it cannot be parsed from the stream", otherwise they can be left as 0 and the S_FMT implementation is expected to return a valid placeholder resolution that would let REQBUFS succeed. iris was missing the fallback, so clients like rpi-ffmpeg wouldn't work. Fix by adding an explicit fallback to defaults. Fixes: b530b95de22c ("media: iris: implement s_fmt, g_fmt and try_fmt ioctls") Link: https://github.com/jc-kynesim/rpi-ffmpeg/issues/103 Reviewed-by: Dikshita Agarwal Signed-off-by: Val Packett Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 101f2b3cd0b6155b144c3d2ff90228802adc35f0 Author: Ricardo Ribalda Date: Tue Dec 23 10:02:58 2025 +0000 media: iris: Fix fps calculation [ Upstream commit 71fe80364a6584f404556ac9a6a4aca4ab80fb5b ] iris_venc_s_param() uses do_div to divide two 64 bits operators, this is wrong. Luckily for us, both of the operators fit in 32 bits, so we can use a normal division. Now that we are at it, mark the fps smaller than 1 as invalid, the code does not seem to handle them properly. The following cocci warning is fixed with this patch: ./platform/qcom/iris/iris_venc.c:378:1-7: WARNING: do_div() does a 64-by-32 division, please consider using div64_u64 instead Fixes: 4ff586ff28e3 ("media: iris: Add support for G/S_PARM for encoder video device") Reviewed-by: Dikshita Agarwal Cc: stable@vger.kernel.org Signed-off-by: Ricardo Ribalda Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 0cd7ca8e96034908ab46fe997c2dd987690f7f15 Author: Vishnu Reddy Date: Mon Oct 6 14:48:19 2025 +0530 media: iris: Fix ffmpeg corrupted frame error [ Upstream commit 89f7cf35901138d9828d981ce64c131a3da6e867 ] When the ffmpeg decoder is running, the driver receives the V4L2_BUF_FLAG_KEYFRAME flag in the input buffer. The driver then forwards this flag information to the firmware. The firmware, in turn, copies the input buffer flags directly into the output buffer flags. Upon receiving the output buffer from the firmware, the driver observes that the buffer contains the HFI_BUFFERFLAG_DATACORRUPT flag. The root cause is that both V4L2_BUF_FLAG_KEYFRAME and HFI_BUFFERFLAG_DATACORRUPT are the same value. As a result, the driver incorrectly interprets the output frame as corrupted, even though the frame is actually valid. This misinterpretation causes the driver to report an error and skip good frames, leading to missing frames in the final video output and triggering ffmpeg's "corrupt decoded frame" error. To resolve this issue, the input buffer flags should not be sent to the firmware during decoding, since the firmware does not require this information. Fixes: 17f2a485ca67 ("media: iris: implement vb2 ops for buf_queue and firmware response") Cc: stable@vger.kernel.org Signed-off-by: Vishnu Reddy Reviewed-by: Dikshita Agarwal Reviewed-by: Bryan O'Donoghue Reviewed-by: Vikash Garodia Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit bd4f8fa216182f33c06d4c1e162975a0c42fb14e Author: Dikshita Agarwal Date: Mon Dec 29 12:01:23 2025 +0530 Revert "media: iris: Add sanity check for stop streaming" [ Upstream commit 370e19042fb8ac68109f8bdb0fdd8118baf39318 ] This reverts commit ad699fa78b59241c9d71a8cafb51525f3dab04d4. Revert the check that skipped stop_streaming when the instance was in IRIS_INST_ERROR, as it caused multiple regressions: 1. Buffers were not returned to vb2 when the instance was already in error state, triggering warnings in the vb2 core because buffer completion was skipped. 2. If a session failed early (e.g. unsupported configuration), the instance transitioned to IRIS_INST_ERROR. When userspace attempted to stop streaming for cleanup, stop_streaming was skipped due to the added check, preventing proper teardown and leaving the firmware in an inconsistent state. Fixes: ad699fa78b59 ("media: iris: Add sanity check for stop streaming") Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit f3bf86dec1d8f0da85508f85c466b38e62f58d59 Author: Dikshita Agarwal Date: Tue Nov 25 11:04:19 2025 +0530 media: venus: vdec: restrict EOS addr quirk to IRIS2 only [ Upstream commit 63c072e2937e6c9995df1b6a28523ed2ae68d364 ] On SM8250 (IRIS2) with firmware older than 1.0.087, the firmware could not handle a dummy device address for EOS buffers, so a NULL device address is sent instead. The existing check used IS_V6() alongside a firmware version gate: if (IS_V6(core) && is_fw_rev_or_older(core, 1, 0, 87)) fdata.device_addr = 0; else fdata.device_addr = 0xdeadb000; However, SC7280 which is also V6, uses a firmware string of the form "1.0.", which the version parser translates to 1.0.0. This unintentionally satisfies the `is_fw_rev_or_older(..., 1, 0, 87)` condition on SC7280. Combined with IS_V6() matching there as well, the quirk is incorrectly applied to SC7280, causing VP9 decode failures. Constrain the check to IRIS2 (SM8250) only, which is the only platform that needed this quirk, by replacing IS_V6() with IS_IRIS2(). This restores correct behavior on SC7280 (no forced NULL EOS buffer address). Fixes: 47f867cb1b63 ("media: venus: fix EOS handling in decoder stop command") Cc: stable@vger.kernel.org Reported-by: Mecid Closes: https://github.com/qualcomm-linux/kernel-topics/issues/222 Co-developed-by: Renjiang Han Signed-off-by: Renjiang Han Signed-off-by: Dikshita Agarwal Tested-by: Renjiang Han Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit fa71c413854bd2bcccb909aa2c9d9ed931c61707 Author: Renjiang Han Date: Thu Dec 11 15:20:39 2025 +0530 media: venus: vdec: fix error state assignment for zero bytesused [ Upstream commit 93ecd6ee95c38cb533fa25f48d3c1c8cb69f410f ] When hfi_session_flush is issued, all queued buffers are returned to the V4L2 driver. Some of these buffers are not processed and have bytesused = 0. Currently, the driver marks such buffers as error even during drain operations, which can incorrectly flag EOS buffers. Only capture buffers with zero payload (and not EOS) should be marked with VB2_BUF_STATE_ERROR. The check is performed inside the non-EOS branch to ensure correct handling. Fixes: 51df3c81ba10b ("media: venus: vdec: Mark flushed buffers with error state") Signed-off-by: Renjiang Han Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 21fde0b4b166d1d14493a3fc6190114448be7748 Author: Jun Yan Date: Fri Jan 16 23:12:53 2026 +0800 arm64: dts: rockchip: Do not enable hdmi_sound node on Pinebook Pro [ Upstream commit b18247f9dab735c9c2d63823d28edc9011e7a1ad ] Remove the redundant enabling of the hdmi_sound node in the Pinebook Pro board dts file, because the HDMI output is unused on this device. [1][2] This change also eliminates the following kernel log warning, which is caused by the unenabled dependent node of hdmi_sound that ultimately results in the node's probe failure: platform hdmi-sound: deferred probe pending: asoc-simple-card: parse error [1] https://files.pine64.org/doc/PinebookPro/pinebookpro_v2.1_mainboard_schematic.pdf [2] https://files.pine64.org/doc/PinebookPro/pinebookpro_schematic_v21a_20220419.pdf Cc: stable@vger.kernel.org Fixes: 5a65505a69884 ("arm64: dts: rockchip: Add initial support for Pinebook Pro") Signed-off-by: Jun Yan Reviewed-by: Peter Robinson Reviewed-by: Dragan Simic Link: https://patch.msgid.link/20260116151253.9223-1-jerrysteve1101@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 428966f1151f36c7701f2ebc1323e86a449467de Author: Dirk Behme Date: Mon Jan 19 08:08:38 2026 +0100 drm/tyr: fix register name in error print [ Upstream commit 793e8f7d52814e096f63373eca643d2672366a5a ] The `..IRQ..` register is printed here. Not the `..INT..` one. Correct this. Cc: stable@vger.kernel.org Fixes: cf4fd52e3236 ("rust: drm: Introduce the Tyr driver for Arm Mali GPUs") Link: https://lore.kernel.org/rust-for-linux/A04F0357-896E-4ACC-BC0E-DEE8608CE518@collabora.com/ Signed-off-by: Dirk Behme Link: https://patch.msgid.link/20260119070838.3219739-1-dirk.behme@de.bosch.com [aliceryhl: update commit message prefix] [aliceryhl: add cc stable as per Miguel's suggestion] Signed-off-by: Alice Ryhl Signed-off-by: Sasha Levin commit 1a09db973ac6b7cdfa279faa6e4c642cdeb63df2 Author: John Keeping Date: Thu Jan 8 18:47:48 2026 +0000 rtc: pcf8563: use correct of_node for output clock [ Upstream commit a380a02ea3ddc69c1c1ccca3882748dee33ec3d3 ] When switching to regmap, the i2c_client pointer was removed from struct pcf8563 so this function switched to using the RTC device instead. But the RTC device is a child of the original I2C device and does not have an associated of_node. Reference the correct device's of_node to ensure that the output clock can be found when referenced by other devices and so that the override clock name is read correctly. Cc: stable@vger.kernel.org Fixes: 00f1bb9b8486b ("rtc: pcf8563: Switch to regmap") Signed-off-by: John Keeping Link: https://patch.msgid.link/20260108184749.3413348-1-jkeeping@inmusicbrands.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit dfe2dbe3950f6a41ac0ecf543084a225e9b418fd Author: Matt Whitlock Date: Sun Jan 18 13:36:15 2026 -0500 dm-unstripe: fix mapping bug when there are multiple targets in a table [ Upstream commit 83c10e8dd43628d0bf86486616556cd749a3c310 ] The "unstriped" device-mapper target incorrectly calculates the sector offset on the mapped device when the target's origin is not zero. Take for example this hypothetical concatenation of the members of a two-disk RAID0: linearized: 0 2097152 unstriped 2 128 0 /dev/md/raid0 0 linearized: 2097152 2097152 unstriped 2 128 1 /dev/md/raid0 0 The intent in this example is to create a single device named /dev/mapper/linearized that comprises all of the chunks of the first disk of the RAID0 set, followed by all of the chunks of the second disk of the RAID0 set. This fails because dm-unstripe.c's map_to_core function does its computations based on the sector number within the mapper device rather than the sector number within the target. The bug turns invisible when the target's origin is at sector zero of the mapper device, as is the common case. In the example above, however, what happens is that the first half of the mapper device gets mapped correctly to the first disk of the RAID0, but the second half of the mapper device gets mapped past the end of the RAID0 device, and accesses to any of those sectors return errors. Signed-off-by: Matt Whitlock Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Fixes: 18a5bf270532 ("dm: add unstriped target") Signed-off-by: Sasha Levin commit 38625191f32f77a9d5fc7cc15f4f9b78768bfb33 Author: Mikulas Patocka Date: Mon Jan 19 15:06:02 2026 +0100 dm-integrity: fix recalculation in bitmap mode [ Upstream commit 118ba36e446c01e3cd34b3eedabf1d9436525e1d ] There's a logic quirk in the handling of suspend in the bitmap mode: This is the sequence of calls if we are reloading a dm-integrity table: * dm_integrity_ctr reads a superblock with the flag SB_FLAG_DIRTY_BITMAP set. * dm_integrity_postsuspend initializes a journal and clears the flag SB_FLAG_DIRTY_BITMAP. * dm_integrity_resume sees the superblock with SB_FLAG_DIRTY_BITMAP set - thus it interprets the journal as if it were a bitmap. This quirk causes recalculation problem if the user increases the size of the device in the bitmap mode. Fix this by reading a fresh copy on the superblock in dm_integrity_resume. This commit also fixes another logic quirk - the branch that sets bitmap bits if the device was extended should only be executed if the flag SB_FLAG_DIRTY_BITMAP is set. Signed-off-by: Mikulas Patocka Tested-by: Ondrej Kozina Fixes: 468dfca38b1a ("dm integrity: add a bitmap mode") Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 76801c3dfca0ac6339a23e9615b5f23e25b8644c Author: Bartosz Golaszewski Date: Thu Dec 4 10:44:12 2025 +0100 reset: gpio: suppress bind attributes in sysfs [ Upstream commit 16de4c6a8fe9ff497ca1aba33ef0dbee09f11952 ] This is a special device that's created dynamically and is supposed to stay in memory forever. We also currently don't have a devlink between it and the actual reset consumer. Suppress sysfs bind attributes so that user-space can't unbind the device because - as of now - it will cause a use-after-free splat from any user that puts the reset control handle. Fixes: cee544a40e44 ("reset: gpio: Add GPIO-based reset controller") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski Reviewed-by: Krzysztof Kozlowski Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit 2097ce274bbc572c2123f818a20df4981e318b15 Author: Jouni Högander Date: Thu Jan 15 09:00:39 2026 +0200 drm/i915/psr: Don't enable Panel Replay on sink if globally disabled [ Upstream commit 69f83f167463bad26104af7fbc114ce1f80366b0 ] With some panels informing support for Panel Replay we are observing problems if having Panel Replay enable bit set on sink when forced to use PSR instead of Panel Replay. Avoid these problems by not setting Panel Replay enable bit in sink when Panel Replay is globally disabled during link training. I.e. disabled by module parameter. The enable bit is still set when disabling Panel Replay via debugfs interface. Added note comment about this. Fixes: 68f3a505b367 ("drm/i915/psr: Enable Panel Replay on sink always when it's supported") Cc: Mika Kahola Cc: Jani Nikula Cc: Rodrigo Vivi Cc: # v6.15+ Signed-off-by: Jouni Högander Reviewed-by: Mika Kahola Link: https://patch.msgid.link/20260115070039.368965-1-jouni.hogander@intel.com (cherry picked from commit c5a52cd04e24f0ae53fda26f74ab027b8c548e0e) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit 4caae8168d1b808c7d4ff481295292e3f97f90fb Author: Joonwon Kang Date: Wed Nov 26 06:22:50 2025 +0000 mailbox: Prevent out-of-bounds access in fw_mbox_index_xlate() [ Upstream commit fcd7f96c783626c07ee3ed75fa3739a8a2052310 ] Although it is guided that `#mbox-cells` must be at least 1, there are many instances of `#mbox-cells = <0>;` in the device tree. If that is the case and the corresponding mailbox controller does not provide `fw_xlate` and of_xlate` function pointers, `fw_mbox_index_xlate()` will be used by default and out-of-bounds accesses could occur due to lack of bounds check in that function. Cc: stable@vger.kernel.org Signed-off-by: Joonwon Kang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 2c89064ecf6767b0ead5d133bd69bbcbfb5f8da2 Author: Niklas Schnelle Date: Thu Jan 8 16:45:53 2026 +0100 s390/pci: Handle futile config accesses of disabled devices directly [ Upstream commit 84d875e69818bed600edccb09be4a64b84a34a54 ] On s390 PCI busses and slots with multiple functions may have holes because PCI functions are passed-through by the hypervisor on a per function basis and some functions may be in standby or reserved. This fact is indicated by returning true from the hypervisor_isolated_pci_functions() helper and triggers common code to scan all possible devfn values. Via pci_scan_single_device() this in turn causes config reads for the device and vendor IDs, even for PCI functions which are in standby and thereofore disabled. So far these futile config reads, as well as potentially writes, which can never succeed were handled by the PCI load/store instructions themselves. This works as the platform just returns an error for a disabled and thus not usable function handle. It does cause spamming of error logs and additional overhead though. Instead check if the used function handle is enabled in zpci_cfg_load() and zpci_cfg_write() and if not enable directly return -ENODEV. Also refactor zpci_cfg_load() and zpci_cfg_store() slightly to accommodate the new logic while meeting modern kernel style guidelines. Cc: stable@vger.kernel.org Fixes: a50297cf8235 ("s390/pci: separate zbus creation from scanning") Signed-off-by: Niklas Schnelle Reviewed-by: Benjamin Block Reviewed-by: Farhan Ali Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit b7bbd20d55cef6d4cca7285f607050a67cd4b680 Author: Haoxiang Li Date: Thu Jan 15 13:05:42 2026 +0800 clk: tegra: tegra124-emc: Fix potential memory leak in tegra124_clk_register_emc() [ Upstream commit fce0d0bd9c20fefd180ea9e8362d619182f97a1d ] If clk_register() fails, call kfree to release "tegra". Fixes: 2db04f16b589 ("clk: tegra: Add EMC clock driver") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Brian Masney Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 26b1c59da576a7e86bdf6675923f0ca3bfbe3f70 Author: Shawn Lin Date: Fri Jan 16 08:55:31 2026 +0800 arm64: dts: rockchip: Fix SD card support for RK3576 EVB1 [ Upstream commit 7226664bf952c4cfddccd74b154a7d994608d153 ] When runtime suspend is enabled, the associated power domain is powered off, which resets the registers, including the power control bit. As a result, the card loses power during runtime suspend. The card should still be able to process I/O with the help of mmc_blk_mq_rw_recovery(), which is suboptimal. To address this issue, we must use vmmc-supply with a GPIO based method to maintain power to the card. Also, add cd-gpios method to make hot-plug work correctly during idle periods. Fixes: f135a1a07352 ("arm64: dts: rockchip: Add rk3576 evb1 board") Cc: stable@vger.kernel.org Signed-off-by: Shawn Lin Link: https://patch.msgid.link/1768524932-163929-5-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit fed39f0d316f8675dd23cd659d971f63be5fdcd8 Author: Mehdi Djait Date: Thu Jan 8 14:57:38 2026 +0100 media: i2c: ov01a10: Fix digital gain range [ Upstream commit 91848c99ed6a98daf77f4cb7d44cf3f13bc6998f ] Digital gain wraps-around at the maximum of 16838 / 0x3fff. Fix the maximum digital gain by setting it to 0x3fff. Signed-off-by: Mehdi Djait Reviewed-by: Hans de Goede Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 4be6112c79b2257b1f763a67405580e396a82fe9 Author: Alain Volmat Date: Fri Dec 19 15:30:36 2025 +0100 media: stm32: dcmipp: byteproc: disable compose for all bayers [ Upstream commit 3363aa2640f1738ad7fc56ea56f5e0301ad97196 ] Avoid possibility to perform compose on all frames which mbus code is within the bayer range or jpeg format. Fixes: 822c72eb1519 ("media: stm32: dcmipp: add bayer 10~14 bits formats") Cc: stable@vger.kernel.org Signed-off-by: Alain Volmat Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 49c7d405c6cad84ec3f5c8d29e86b6e6ba3aee9e Author: Alain Volmat Date: Fri Dec 19 15:30:35 2025 +0100 media: stm32: dcmipp: bytecap: clear all interrupts upon stream stop [ Upstream commit 222f1279edd9008ee35b62de156ddac84e31443c ] Ensure that there are no pending interrupts after we have stopped the pipeline. Indeed, it could happen that new interrupt has been generated during the stop_streaming processing hence clear them in order to avoid getting a new interrupt right from the start of a next start_streaming. Fixes: 28e0f3772296 ("media: stm32-dcmipp: STM32 DCMIPP camera interface driver") Cc: stable@vger.kernel.org Signed-off-by: Alain Volmat Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 23ad54f2551f7b07cac2c1a08a106deab8778ffa Author: Alain Volmat Date: Mon Dec 15 13:10:19 2025 +0100 media: stm32: dcmipp: avoid naming clock if only one is needed [ Upstream commit 2f130245f2143fa8f4da77071f844911d2c69319 ] When DCMIPP requires only a single clock (kclk), avoid relying on its name to obtain it. The introduction of MP25 support added the mclk, which necessitated naming the first clock kclk. However, this breaks backward compatibility with existing MP13 device trees that do not specify clock names. Fixes: 686f27f7ea37 ("media: stm32: dcmipp: add core support for the stm32mp25") Signed-off-by: Alain Volmat Cc: Stable@vger.kernel.org # 6.14.x: 7f487562af49 media: stm32: dcmipp: correct ret type in dcmipp_graph_notify_bound Cc: Stable@vger.kernel.org # 6.14.x: c715dd62da30 media: stm32: dcmipp: add has_csi2 & needs_mclk in match data Cc: Stable@vger.kernel.org # 6.14.x: Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit d13418d75e1774c07e2096298714bcc64d77d576 Author: Shawn Lin Date: Fri Jan 16 08:55:29 2026 +0800 soc: rockchip: grf: Support multiple grf to be handled [ Upstream commit 75fb63ae031211e9264ac888fabc2ca9cd3fcccf ] Currently, only the first matched node will be handled. This leads to jtag switching broken for RK3576, as rk3576-sys-grf is found before rk3576-ioc-grf. Change the code to scan all the possible node to fix the problem. Fixes: e1aaecacfa13 ("soc: rockchip: grf: Add rk3576 default GRF values") Cc: stable@vger.kernel.org Cc: Detlev Casanova Signed-off-by: Shawn Lin Tested-by: Marco Schirrmeister Link: https://patch.msgid.link/1768524932-163929-3-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 833fd7ad595ffc369b5437d45198fd90faf53642 Author: Shawn Lin Date: Fri Jan 16 08:55:28 2026 +0800 soc: rockchip: grf: Fix wrong RK3576_IOCGRF_MISC_CON definition [ Upstream commit 3cdc30c42d4a87444f6c7afbefd6a9381c4caa27 ] RK3576_IOCGRF_MISC_CON is IOC_GRF + 0x40F0, fix it. Fixes: e1aaecacfa13 ("soc: rockchip: grf: Add rk3576 default GRF values") Cc: stable@vger.kernel.org Cc: Detlev Casanova Signed-off-by: Shawn Lin Reviewed-by: Chaoyi Chen Tested-by: Marco Schirrmeister Link: https://patch.msgid.link/1768524932-163929-2-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 9785b31beb335a86a5bd8e17de8713386096c38b Author: Janne Grunau Date: Wed Dec 31 13:22:00 2025 +0100 clk: clk-apple-nco: Add "apple,t8103-nco" compatible [ Upstream commit ef9b3b4dbe767e4ac642a88dc0507927ac545047 ] After discussion with the devicetree maintainers we agreed to not extend lists with the generic compatible "apple,nco" anymore [1]. Use "apple,t8103-nco" as base compatible as it is the SoC the driver and bindings were written for. [1]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/ Fixes: 6641057d5dba ("clk: clk-apple-nco: Add driver for Apple NCO") Cc: stable@vger.kernel.org Acked-by: Stephen Boyd Reviewed-by: Neal Gompa Signed-off-by: Janne Grunau Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit ef6647586deb772e5ec1311c1a96dbe21ad47575 Author: Johan Hovold Date: Fri Dec 19 12:01:19 2025 +0100 bus: omap-ocp2scp: fix OF populate on driver rebind [ Upstream commit 5eb63e9bb65d88abde647ced50fe6ad40c11de1a ] Since commit c6e126de43e7 ("of: Keep track of populated platform devices") child devices will not be created by of_platform_populate() if the devices had previously been deregistered individually so that the OF_POPULATED flag is still set in the corresponding OF nodes. Switch to using of_platform_depopulate() instead of open coding so that the child devices are created if the driver is rebound. Fixes: c6e126de43e7 ("of: Keep track of populated platform devices") Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20251219110119.23507-1-johan@kernel.org Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit d464cf1ed900d47c85393d40b00017b6adfc2e6c Author: Yosry Ahmed Date: Sat Jan 10 00:48:18 2026 +0000 KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation [ Upstream commit 127ccae2c185f62e6ecb4bf24f9cb307e9b9c619 ] Commit cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01. As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB. Fixes: cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state") Cc: Maxim Levitsky Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260110004821.3411245-2-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit b7db9953c2f8da37de498198623b05b46f8e2ca0 Author: Wentao Liang Date: Tue Jan 13 01:47:16 2026 +0000 soc: ti: pruss: Fix double free in pruss_clk_mux_setup() [ Upstream commit 80db65d4acfb9ff12d00172aed39ea8b98261aad ] In the pruss_clk_mux_setup(), the devm_add_action_or_reset() indirectly calls pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np) on the error path. However, after the devm_add_action_or_reset() returns, the of_node_put(clk_mux_np) is called again, causing a double free. Fix by returning directly, to avoid the duplicate of_node_put(). Fixes: ba59c9b43c86 ("soc: ti: pruss: support CORECLK_MUX and IEPCLK_MUX") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260113014716.2464741-1-vulab@iscas.ac.cn Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit ab1ac24c407e4df326d7154a4deadd444e9209d9 Author: Johan Hovold Date: Thu Nov 27 14:49:42 2025 +0100 soc: ti: k3-socinfo: Fix regmap leak on probe failure [ Upstream commit c933138d45176780fabbbe7da263e04d5b3e525d ] The mmio regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind. Fixes: a5caf03188e4 ("soc: ti: k3-socinfo: Do not use syscon helper to build regmap") Cc: stable@vger.kernel.org # 6.15 Cc: Andrew Davis Signed-off-by: Johan Hovold Acked-by: Andrew Davis Link: https://patch.msgid.link/20251127134942.2121-1-johan@kernel.org Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit b1c1a2637ebd675aa2d71fee8c70da8791d73850 Author: Michael Liang Date: Fri Jan 9 15:52:54 2026 -0700 dm: clear cloned request bio pointer when last clone bio completes [ Upstream commit fb8a6c18fb9a6561f7a15b58b272442b77a242dd ] Stale rq->bio values have been observed to cause double-initialization of cloned bios in request-based device-mapper targets, leading to use-after-free and double-free scenarios. One such case occurs when using dm-multipath on top of a PCIe NVMe namespace, where cloned request bios are freed during blk_complete_request(), but rq->bio is left intact. Subsequent clone teardown then attempts to free the same bios again via blk_rq_unprep_clone(). The resulting double-free path looks like: nvme_pci_complete_batch() nvme_complete_batch() blk_mq_end_request_batch() blk_complete_request() // called on a DM clone request bio_endio() // first free of all clone bios ... rq->end_io() // end_clone_request() dm_complete_request(tio->orig) dm_softirq_done() dm_done() dm_end_request() blk_rq_unprep_clone() // second free of clone bios Fix this by clearing the clone request's bio pointer when the last cloned bio completes, ensuring that later teardown paths do not attempt to free already-released bios. Signed-off-by: Michael Liang Reviewed-by: Mohamed Khalfella Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 9e30eb22e03a43d610598a6b4285e9b2947d9c3e Author: Mikulas Patocka Date: Mon Jan 12 21:15:27 2026 +0100 dm-integrity: fix a typo in the code for write/discard race [ Upstream commit c698b7f417801fcd79f0dc844250b3361d38e6b8 ] If we send a write followed by a discard, it may be possible that the discarded data end up being overwritten by the previous write from the journal. The code tries to prevent that, but there was a typo in this logic that made it not being activated as it should be. Note that if we end up here the second time (when discard_retried is true), it means that the write bio is actually racing with the discard bio, and in this situation it is not specified which of them should win. Cc: stable@vger.kernel.org Fixes: 31843edab7cb ("dm integrity: improve discard in journal mode") Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit e3704ce5d7156ee837461be99841f312c64700b0 Author: Srinivas Pandruvada Date: Tue Jan 6 22:02:56 2026 -0800 platform/x86: ISST: Store and restore all domains data [ Upstream commit dc7901b5a1563a9c9eb29b3b0b0dac3162065cd8 ] The suspend/resume callbacks currently only store and restore the configuration for power domain 0. However, other power domains may also have modified configurations that need to be preserved across suspend/ resume cycles. Extend the store/restore functionality to handle all power domains. Fixes: 91576acab020 ("platform/x86: ISST: Add suspend/resume callbacks") Signed-off-by: Srinivas Pandruvada CC: stable@vger.kernel.org Link: https://patch.msgid.link/20260107060256.1634188-3-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 067d784870eeddf6b4b5fd083348c4b7a17c4eee Author: Srinivas Pandruvada Date: Tue Jan 6 22:02:55 2026 -0800 platform/x86: ISST: Add missing write block check [ Upstream commit 0e5aef2795008c80c515f6fa04e377c6e5715958 ] If writes are blocked, then return error during SST-CP enable command. Add missing write block check in this code path. Fixes: 8bed9ff7dbcc ("platform/x86: ISST: Process read/write blocked feature status") Signed-off-by: Srinivas Pandruvada Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260107060256.1634188-2-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 5ca94abfe5a0fa66379c9e356c8f04d142ed7baf Author: Bingbu Cao Date: Tue Dec 23 15:23:03 2025 +0800 media: staging/ipu7: Fix the loop bound in l2 table alloc [ Upstream commit 98cc19a353abc8b48b7d58fd7a455e09e7c3aba3 ] This patch fixes the incorrect loop bound in alloc_l2_pt(). When initializing L2 page table entries, the loop was incorrectly using ISP_L1PT_PTES instead of ISP_L2PT_PTES though the ISP_L1PT_PTES is equal to ISP_L2PT_PTES. Fixes: 71d81c25683a ("media: staging/ipu7: add IPU7 DMA APIs and MMU mapping") Cc: stable@vger.kernel.org Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 08440d792f97d43a5e263e48c7936ab5b476bc89 Author: Bingbu Cao Date: Tue Dec 23 15:23:02 2025 +0800 media: staging/ipu7: Update CDPHY register settings [ Upstream commit f7923e6bafcad686adb51cc100ba1860f8b43922 ] Some CPHY settings needs to updated according to the latest guide from SNPS. This patch program 45ohm for tuning resistance to fix CPHY problem and update the ITMINRX and GMODE for CPHY. Cc: Stable@vger.kernel.org Fixes: a516d36bdc3d ("media: staging/ipu7: add IPU7 input system device driver") Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 8603922f08d95f313290ff9173f86a88d6678f59 Author: Bingbu Cao Date: Tue Dec 23 15:23:01 2025 +0800 media: staging/ipu7: Call synchronous RPM suspend in probe failure [ Upstream commit 1433e6ccc25e9ea596683ab66e1c51f37fc7d491 ] If firmware authentication failed during driver probe, driver call an asynchronous API to suspend the psys device but the bus device will be removed soon, thus runtime PM of bus device will be disabled soon, that will cancel the suspend request, so use synchronous suspend to make sure the runtime suspend before disabling its RPM. IPU7 hardware has constraints that the PSYS device must be powered off before ISYS, otherwise it will cause machine check error. Cc: Stable@vger.kernel.org Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver") Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9a8c3cd8a0bbfd04bce15c41ad01e425c9e8d844 Author: Bingbu Cao Date: Tue Dec 23 15:23:00 2025 +0800 media: staging/ipu7: Ignore interrupts when device is suspended [ Upstream commit 9ad65684b9285c5d66fb417d50e91a25ef8c994d ] IPU7 devices have shared interrupts with others. In some case when IPU7 device is suspended, driver get unexpected interrupt and invalid irq status 0xffffffff from ISR_STATUS and PB LOCAL_STATUS registers as interrupt is triggered from other device on shared irq line. In order to avoid this issue use pm_runtime_get_if_active() to check if IPU7 device is resumed, ignore the invalid irq status and use synchronize_irq() in suspend. Cc: Stable@vger.kernel.org Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver") Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 364759ccc3fb49754758c585c530407f96683030 Author: Bingbu Cao Date: Tue Dec 23 15:22:59 2025 +0800 media: ipu6: Fix RPM reference leak in probe error paths [ Upstream commit 6099f78e4c9223f4de4169d2fd1cded01279da1a ] Several error paths in ipu6_pci_probe() were jumping directly to out_ipu6_bus_del_devices without releasing the runtime PM reference. Add pm_runtime_put_sync() before cleaning up other resources. Cc: Stable@vger.kernel.org Fixes: 25fedc021985 ("media: intel/ipu6: add Intel IPU6 PCI device driver") Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 39b9626b0559d417efe5b1066ec3c973c5e690f1 Author: Bingbu Cao Date: Tue Dec 23 15:22:58 2025 +0800 media: ipu6: Fix typo and wrong constant in ipu6-mmu.c [ Upstream commit 3e0fcc91277d5af114a58aaa68f34b44e8d8a411 ] Fix two coding errors in ipu6-mmu.c: 1. Fix syntax error in page_table_dump() where the closing parenthesis and semicolon were swapped in the TBL_PHYS_ADDR macro call. 2. Fix incorrect loop bound in alloc_l2_pt(). When initializing L2 page table entries, the loop was incorrectly using ISP_L1PT_PTES instead of ISP_L2PT_PTES. Fixes: 9163d83573e4 ("media: intel/ipu6: add IPU6 DMA mapping API and MMU table") Cc: stable@vger.kernel.org Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 605e9a9471d28bcf0025897de44e4254bb559c87 Author: Ricardo Ribalda Date: Wed Dec 10 07:53:43 2025 +0000 media: dw9714: Fix powerup sequence [ Upstream commit 401aec35ac7bd04b4018a519257b945abb88e26c ] We have experienced seen multiple I2C errors while doing stress test on the module: dw9714 i2c-PRP0001:01: dw9714_vcm_resume I2C failure: -5 dw9714 i2c-PRP0001:01: I2C write fail Inspecting the powerup sequence we found that it does not match the documentation at: https://blog.arducam.com/downloads/DW9714A-DONGWOON(Autofocus_motor_manual).pdf """ (2) DW9714A requires waiting time of 12ms after power on. During this waiting time, the offset calibration of internal amplifier is operating for minimization of output offset current . """ This patch increases the powerup delay to follow the documentation. Fixes: 9d00ccabfbb5 ("media: i2c: dw9714: Fix occasional probe errors") Signed-off-by: Ricardo Ribalda Reviewed-by: Hans de Goede Tested-by: Neil Sun Reported-by: Naomi Huang Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit fa69b9a87f898c5e4cea790fdf2fba434fcab6ae Author: Xiaolei Wang Date: Fri Dec 5 15:19:18 2025 +0800 media: i2c: ov5647: use our own mutex for the ctrl lock [ Upstream commit 973e42fd5d2b397bff34f0c249014902dbf65912 ] __v4l2_ctrl_handler_setup() and __v4l2_ctrl_modify_range() contains an assertion to verify that the v4l2_ctrl_handler::lock is held, as it should only be called when the lock has already been acquired. Therefore use our own mutex for the ctrl lock, otherwise a warning will be reported. Fixes: 4974c2f19fd8 ("media: ov5647: Support gain, exposure and AWB controls") Cc: stable@vger.kernel.org Signed-off-by: Xiaolei Wang [Sakari Ailus: Fix a minor conflict.] Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e26aba7c0e9e61cfe807aa2f7477ead513f965c7 Author: Sakari Ailus Date: Tue Dec 30 19:22:02 2025 +0200 media: ccs: Fix setting initial sub-device state [ Upstream commit 31e5191aa11931b53e1242acef4f4375f00ca523 ] Fix setting sub-device state for non-source sub-devices. Fixes: 5755be5f15d9 ("media: v4l2-subdev: Rename .init_cfg() operation to .init_state()") Cc: stable@vger.kernel.org # for v6.8 and later Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 78d2c1ca071de461c07c9df43e865ddc957cda98 Author: Jai Luthra Date: Mon Dec 22 13:45:29 2025 +0530 media: i2c: ov5647: Fix PIXEL_RATE value for VGA mode [ Upstream commit c063632b494b02e891442d10f17e37b7fcfab9b3 ] The pixel rate for VGA (640x480) mode is configured in the mode's table to be 58.333 MPix/s instead of 55 MPix/s, so fix it. Fixes: 911f4516ee2b ("media: ov5647: Support V4L2_CID_PIXEL_RATE") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/CAPY8ntA2TCf9FuB6Nk%2BOn%2By6N_PMuYPAOAr3Yx8YESwe4skWvw@mail.gmail.com/ Suggested-by: Dave Stevenson Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1b593da3e54c81e91deee8a16861c5c49919e3b5 Author: David Plowman Date: Mon Dec 22 13:45:28 2025 +0530 media: i2c: ov5647: Sensor should report RAW color space [ Upstream commit f007586b1e89dcea40168415d0422cb7a0fc31b1 ] As this sensor captures RAW bayer frames, the colorspace should be V4L2_COLORSPACE_RAW instead of SRGB. Fixes: a8df5af695a1 ("media: ov5647: Add SGGBR10_1X10 modes") Cc: stable@vger.kernel.org Signed-off-by: David Plowman Reviewed-by: Jacopo Mondi Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit ff90942181d00c3f234664eb758351e6b30a5318 Author: David Plowman Date: Mon Dec 22 13:45:27 2025 +0530 media: i2c: ov5647: Correct minimum VBLANK value [ Upstream commit 1438248c5a82c86b4e1f0311c3bb827af747a8cf ] Trial and error reveals that the minimum vblank value appears to be 24 (the OV5647 data sheet does not give any clues). This fixes streaming lock-ups in full resolution mode. Fixes: 2512c06441e3 ("media: ov5647: Support V4L2_CID_VBLANK control") Cc: stable@vger.kernel.org Signed-off-by: David Plowman Reviewed-by: Jacopo Mondi Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 8f5082ee17730320db46b873f75b5ea6ad3675b7 Author: David Plowman Date: Mon Dec 22 13:45:26 2025 +0530 media: i2c: ov5647: Correct pixel array offset [ Upstream commit a4e62e597f21bb37db0ad13aca486094e9188167 ] The top offset in the pixel array is actually 6 (see page 3-1 of the OV5647 data sheet). Fixes: 14f70a3232aa ("media: ov5647: Add support for get_selection()") Cc: stable@vger.kernel.org Signed-off-by: David Plowman Reviewed-by: Jacopo Mondi Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 8ecb21c20387cc0c8aa00489a21ccc69f6b0f5d1 Author: Jai Luthra Date: Mon Dec 22 13:45:25 2025 +0530 media: i2c: ov5647: Initialize subdev before controls [ Upstream commit eee13cbccacb6d0a3120c126b8544030905b069d ] In ov5647_init_controls() we call v4l2_get_subdevdata, but it is initialized by v4l2_i2c_subdev_init() in the probe, which currently happens after init_controls(). This can result in a segfault if the error condition is hit, and we try to access i2c_client, so fix the order. Fixes: 4974c2f19fd8 ("media: ov5647: Support gain, exposure and AWB controls") Cc: stable@vger.kernel.org Suggested-by: Jacopo Mondi Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a8ff58cc8c7514c278ba0ea2c787d4bf9eeb355d Author: Sakari Ailus Date: Tue Nov 25 00:24:48 2025 +0200 media: ccs: Avoid possible division by zero [ Upstream commit 679f0b7b6a409750a25754c8833e268e5fdde742 ] Calculating maximum M for scaler configuration involves dividing by MIN_X_OUTPUT_SIZE limit register's value. Albeit the value is presumably non-zero, the driver was missing the check it in fact was. Fix this. Reported-by: Josh Poimboeuf Closes: https://lore.kernel.org/all/ahukd6b3wonye3zgtptvwzvrxldcruazs2exfvll6etjhmcxyj@vq3eh6pd375b/ Fixes: ccfc97bdb5ae ("[media] smiapp: Add driver") Cc: stable@vger.kernel.org # for 5.15 and later Signed-off-by: Sakari Ailus Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor # build Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit fade67c88870f497a13ed450ba01f7236c92dd9b Author: Alper Ak Date: Mon Dec 29 10:52:17 2025 +0300 media: qcom: camss: vfe: Fix out-of-bounds access in vfe_isr_reg_update() [ Upstream commit d965919af524e68cb2ab1a685872050ad2ee933d ] vfe_isr() iterates using MSM_VFE_IMAGE_MASTERS_NUM(7) as the loop bound and passes the index to vfe_isr_reg_update(). However, vfe->line[] array is defined with VFE_LINE_NUM_MAX(4): struct vfe_line line[VFE_LINE_NUM_MAX]; When index is 4, 5, 6, the access to vfe->line[line_id] exceeds the array bounds and resulting in out-of-bounds memory access. Fix this by using separate loops for output lines and write masters. Fixes: 4edc8eae715c ("media: camss: Add initial support for VFE hardware version Titan 480") Signed-off-by: Alper Ak Cc: stable@vger.kernel.org Reviewed-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e5d08efceffc8d956914e9be03f51882c006c9cc Author: Hans de Goede Date: Tue Oct 14 19:40:14 2025 +0200 media: i2c: ov01a10: Fix test-pattern disabling [ Upstream commit 409fb57c1b3deada4b8e153eb6344afb3c2dfb9c ] When the test-pattern control gets set to 0 (Disabled) 0 should be written to the test-pattern register, rather then doing nothing. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Reviewed-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9466dc871c45a3d89a8aa88418f065fe438c80b8 Author: Hans de Goede Date: Tue Oct 14 19:40:13 2025 +0200 media: i2c: ov01a10: Fix passing stream instead of pad to v4l2_subdev_state_get_format() [ Upstream commit f8563a375e7fba7c776eb591d4498be592c19098 ] The 2 argument version of v4l2_subdev_state_get_format() takes the pad as second argument, not the stream. Fixes: bc0e8d91feec ("media: v4l: subdev: Switch to stream-aware state functions") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit be04fe430bb0f942bf06b6ed7b224fd4f12de715 Author: Hans de Goede Date: Tue Oct 14 19:40:12 2025 +0200 media: i2c: ov01a10: Add missing v4l2_subdev_cleanup() calls [ Upstream commit 0dfec6e30c334364145d0acb38bb8c216b9a7a78 ] Add missing v4l2_subdev_cleanup() calls to cleanup after v4l2_subdev_init_finalize(). Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Reviewed-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2195f2be8307f293a2735157d8eb73519e54fd23 Author: Hans de Goede Date: Tue Oct 14 19:40:11 2025 +0200 media: i2c: ov01a10: Fix analogue gain range [ Upstream commit 109e0feacaeca5ec2dd71d7d17c73232ce5cbddc ] A analogue maximum gain of 0xffff / 65525 seems unlikely and testing indeed shows that the gain control wraps-around at 16383, so set the maximum gain to 0x3fff / 16383. The minimum gain of 0x100 is correct. Setting bits 8-11 to 0x0 results in the same gain values as setting these bits to 0x1, with bits 0-7 still increasing the gain when going from 0x000 - 0x0ff in the exact same range as when going from 0x100 - 0x1ff. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait [Sakari Ailus: mention analogue gain and update the limit from 4096.] Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e148cdc0f12288e22b70e5ec9fff6b3026ed173e Author: Hans de Goede Date: Tue Oct 14 19:40:10 2025 +0200 media: i2c: ov01a10: Fix reported pixel-rate value [ Upstream commit 9c632eebf6af4cb7b0f85503fe1ebc5176ff0db1 ] CSI lanes are double-clocked so with a single lane at 400MHZ the resulting pixel-rate for 10-bits pixels is 400 MHz * 2 / 10 = 80 MHz, not 40 MHz. This also matches with the observed frame-rate of 60 fps with the default vblank setting: 80000000 / (1488 * 896) = 60. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 8df26a76497f0744dd701f6a0e0eb0dae56ea44d Author: Hans de Goede Date: Tue Oct 14 19:40:09 2025 +0200 media: i2c: ov01a10: Fix the horizontal flip control [ Upstream commit ada20c3db0db4f2834d9515f6105111871f04a4d ] During sensor calibration I noticed that with the hflip control set to false/disabled the image was mirrored. So it seems that the horizontal flip control is inverted and needs to be set to 1 to not flip (just like the similar problem recently fixed on the ov08x40 sensor). Invert the hflip control to fix the sensor mirroring by default. As the comment above the newly added OV01A10_MEDIA_BUS_FMT define explains the control being inverted also means that the native Bayer-order of the sensor actually is GBRG not BGGR, but so as to not break userspace the Bayer-order is kept at BGGR. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 377a7756914364d72550fc86ca0f404ef1d96141 Author: Abdun Nihaal Date: Tue Dec 23 11:19:01 2025 +0530 media: i2c/tw9906: Fix potential memory leak in tw9906_probe() [ Upstream commit cad237b6c875fbee5d353a2b289e98d240d17ec8 ] In one of the error paths in tw9906_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path. Cc: stable@vger.kernel.org Fixes: a000e9a02b58 ("[media] tw9906: add Techwell tw9906 video decoder") Signed-off-by: Abdun Nihaal Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit cc7aeed33e4f55c76f35f0fca73e4dfe12a63a3a Author: Abdun Nihaal Date: Tue Dec 23 11:18:13 2025 +0530 media: i2c/tw9903: Fix potential memory leak in tw9903_probe() [ Upstream commit 9cea16fea47e5553f51d10957677ff735b1eff03 ] In one of the error paths in tw9903_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path. Cc: stable@vger.kernel.org Fixes: 0890ec19c65d ("[media] tw9903: add new tw9903 video decoder") Signed-off-by: Abdun Nihaal Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 280da29ff603407715d3efa2ab3bba2057cbadb7 Author: Haoxiang Li Date: Wed Dec 10 16:52:30 2025 +0800 media: cx25821: Add missing unmap in snd_cx25821_hw_params() [ Upstream commit 863f50d583445c3c8b28a0fc4bb9c18fd9656f41 ] In error path, add cx25821_alsa_dma_unmap() to release the resource acquired by cx25821_alsa_dma_map() Fixes: 8d8e6d6005de ("[media] cx28521: drop videobuf abuse in cx25821-alsa") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9544b73cad4ee667fed6a60f71570c58a870a735 Author: Haoxiang Li Date: Wed Dec 10 11:02:17 2025 +0800 media: cx23885: Add missing unmap in snd_cx23885_hw_params() [ Upstream commit 141c81849fab2ad4d6e3fdaff7cbaa873e8b5eb2 ] In error path, add cx23885_alsa_dma_unmap() to release the resource acquired by cx23885_alsa_dma_map(). Fixes: 9529a4b0cf49 ("[media] cx23885: drop videobuf abuse in cx23885-alsa") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1ce8c2a8f050a23240553c8bae628ac623f9dbc1 Author: Haoxiang Li Date: Wed Dec 10 10:53:48 2025 +0800 media: cx88: Add missing unmap in snd_cx88_hw_params() [ Upstream commit dbc527d980f7ba8559de38f8c1e4158c71a78915 ] In error path, add cx88_alsa_dma_unmap() to release resource acquired by cx88_alsa_dma_map(). Fixes: b2c75abde0de ("[media] cx88: drop videobuf abuse in cx88-alsa") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1d8558a232ecb187e8e0328d6347a125f437a0fc Author: Shaurya Rane Date: Thu Nov 27 00:34:10 2025 +0530 media: radio-keene: fix memory leak in error path [ Upstream commit b8bf939d77c0cd01118e953bbf554e0fa15e9006 ] Fix a memory leak in usb_keene_probe(). The v4l2 control handler is initialized and controls are added, but if v4l2_device_register() or video_register_device() fails afterward, the handler was never freed, leaking memory. Add v4l2_ctrl_handler_free() call in the err_v4l2 error path to ensure the control handler is properly freed for all error paths after it is initialized. Reported-by: syzbot+a41b73dce23962a74c72@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a41b73dce23962a74c72 Fixes: 1bf20c3a0c61 ("[media] radio-keene: add a driver for the Keene FM Transmitter") Cc: stable@vger.kernel.org Signed-off-by: Shaurya Rane Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9e3b9d2472b36ba80d985a7dab9764accf5de049 Author: Benjamin Gaignard Date: Thu Jan 8 14:29:46 2026 +0100 media: verisilicon: AV1: Set IDR flag for intra_only frame type [ Upstream commit 1c1b79f40ee4444fa1ac96079751608b724c6b2b ] Intra_only frame could be considered as a key frame so Instantaneous Decoding Refresh (IDR) flag must be set of the both case and not only for key frames. Signed-off-by: Benjamin Gaignard Reported-by: Jianfeng Liu Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: stable@vger.kernel.org Reviewed-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1af2853b4e97fd95262fdef311b2334337069bc9 Author: Alper Ak Date: Sat Dec 27 11:40:37 2025 +0300 media: rockchip: rga: Fix possible ERR_PTR dereference in rga_buf_init() [ Upstream commit 81f8e0e6a2e115df9274d0289779f8fca694479c ] rga_get_frame() can return ERR_PTR(-EINVAL) when buffer type is unsupported or invalid. rga_buf_init() does not check the return value and unconditionally dereferences the pointer when accessing f->size. Add proper ERR_PTR checking and return the error to prevent dereferencing an invalid pointer. Fixes: 6040702ade23 ("media: rockchip: rga: allocate DMA descriptors per buffer") Cc: stable@vger.kernel.org Signed-off-by: Alper Ak Reviewed-by: Michael Tretter Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit fe1c50fadc4eba1869a6ee3488208fe1c8305d7a Author: Ming Qian Date: Tue Dec 23 14:27:52 2025 +0800 media: amphion: Drop min_queued_buffers assignment [ Upstream commit 5633ec763a2a18cef6c5ac9250e4f4b8786e7999 ] The min_queued_buffers field controls when start_streaming() is called by the vb2 core (it delays the callback until at least N buffers are queued). Setting it to 1 affects the timing of start_streaming(), which breaks the seek flow in decoder scenarios and causes test failures. The current driver implementation does not rely on this minimum buffer requirement and handles streaming start correctly with the default value of 0, so remove these assignments. Fixes: 3cd084519c6f ("media: amphion: add vpu v4l2 m2m support") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Reviewed-by: Nicolas Dufresne Reviewed-by: Frank Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a2ac388aa830a9ccfa35c2b1bbaabd2c47932e37 Author: Janne Grunau Date: Thu Jan 8 22:04:01 2026 +0100 arm64: dts: apple: t8112-j473: Keep the HDMI port powered on [ Upstream commit 3e4e729325131fe6f7473a0673f7d8cdde53f5a0 ] Add the display controller and DPTX phy power-domains to the framebuffer node to keep the framebuffer and display out working after device probing finished. The OS has more control about the display pipeline used for the HDMI output on M2 based devices. The HDMI output is driven by an integrated DisplayPort to HDMI converter (Parade PS190). The DPTX phy is now controlled by the OS and no longer by firmware running on the display co-processor. This allows using the second display controller on the second USB type-c port or tunneling 2 DisplayPort connections over USB4/Thunderbolt. The m1n1 bootloader uses the second display controller to drive the HDMI output. Adjust for this difference compared to the notebooks as well. Fixes: 2d5ce3fbef32 ("arm64: dts: apple: t8112: Initial t8112 (M2) device trees") Cc: stable@vger.kernel.org Signed-off-by: Janne Grunau Link: https://patch.msgid.link/20260108-apple-dt-pmgr-fixes-v1-1-cfdce629c0a8@jannau.net Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit e75e091a331e98e85b8a98886e8ad79905a55cdf Author: Christian Brauner Date: Mon Jan 12 16:47:08 2026 +0100 fs: ensure that internal tmpfs mount gets mount id zero [ Upstream commit a2062463e894039a6fdc2334b96afd91d44b64a8 ] and the rootfs get mount id one as it always has. Before we actually mount the rootfs we create an internal tmpfs mount which has mount id zero but is never exposed anywhere. Continue that "tradition". Link: https://patch.msgid.link/20260112-work-immutable-rootfs-v2-1-88dd1c34a204@kernel.org Fixes: 7f9bfafc5f49 ("fs: use xarray for old mount id") Reviewed-by: Jeff Layton Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 1acb28123e57b50d737377f400f57eec889fe5e4 Author: Günther Noack Date: Fri Jan 9 13:25:58 2026 +0100 HID: logitech-hidpp: Check maxfield in hidpp_get_report_length() [ Upstream commit 1547d41f9f19d691c2c9ce4c29f746297baef9e9 ] Do not crash when a report has no fields. Fake USB gadgets can send their own HID report descriptors and can define report structures without valid fields. This can be used to crash the kernel over USB. Cc: stable@vger.kernel.org Signed-off-by: Günther Noack Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit d5512ce892f774d37c53082adadfcad04f21b50e Author: Günther Noack Date: Fri Jan 9 11:58:08 2026 +0100 HID: prodikeys: Check presence of pm->input_ep82 [ Upstream commit cee8337e1bad168136aecfe6416ecd7d3aa7529a ] Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, pm->input_ep82 stays NULL, which leads to a crash later. This does not happen with the real device, but can be provoked by imposing as one. Cc: stable@vger.kernel.org Signed-off-by: Günther Noack Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 5bbe266272d86c0657e8253600f3d5b74fb7b2ae Author: Günther Noack Date: Fri Jan 9 11:57:14 2026 +0100 HID: magicmouse: Do not crash on missing msc->input [ Upstream commit 17abd396548035fbd6179ee1a431bd75d49676a7 ] Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, msc->input stays NULL, leading to a crash at a later time. Detect this condition in the input_configured() hook and reject the device. This is not supposed to happen with actual magic mouse devices, but can be provoked by imposing as a magic mouse USB device. Cc: stable@vger.kernel.org Signed-off-by: Günther Noack Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 1d46d07458dba369daf61fb643d40a62c8423d8e Author: Oliver Neukum Date: Wed Nov 19 10:09:57 2025 +0100 HID: hid-pl: handle probe errors [ Upstream commit 3756a272d2cf356d2203da8474d173257f5f8521 ] Errors in init must be reported back or we'll follow a NULL pointer the first time FF is used. Fixes: 20eb127906709 ("hid: force feedback driver for PantherLord USB/PS2 2in1 Adapter") Cc: stable@vger.kernel.org Signed-off-by: Oliver Neukum Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 4a1afa32145b559d090f168f7e42ceef388d9f78 Author: Bartosz Golaszewski Date: Tue Jan 6 09:52:53 2026 +0100 pinctrl: meson: amlogic-a4: mark the GPIO controller as sleeping [ Upstream commit d6df4abe95a409e812c5d9af9657fe63ac299e3a ] The GPIO controller is configured as non-sleeping but it uses generic pinctrl helpers which use a mutex for synchronization. This will cause lockdep splats when used together with shared GPIOs going through the GPIO shared proxy driver. Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs") Cc: stable@vger.kernel.org Reported-by: Martin Blumenstingl Closes: https://lore.kernel.org/all/CAFBinCAc7CO8gfNQakCu3LfkYXuyTd2iRpMRm8EKXSL0mwOnJw@mail.gmail.com/ Signed-off-by: Bartosz Golaszewski Reviewed-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit e3e6e2e4d66e5a87696cfd6c060f55194f47630d Author: Breno Leitao Date: Tue Jan 6 02:16:35 2026 -0800 arm64: Disable branch profiling for all arm64 code [ Upstream commit f22c81bebf8bda6e54dc132df0ed54f6bf8756f9 ] The arm64 kernel doesn't boot with annotated branches (PROFILE_ANNOTATED_BRANCHES) enabled and CONFIG_DEBUG_VIRTUAL together. Bisecting it, I found that disabling branch profiling in arch/arm64/mm solved the problem. Narrowing down a bit further, I found that physaddr.c is the file that needs to have branch profiling disabled to get the machine to boot. I suspect that it might invoke some ftrace helper very early in the boot process and ftrace is still not enabled(!?). Rather than playing whack-a-mole with individual files, disable branch profiling for the entire arch/arm64 tree, similar to what x86 already does in arch/x86/Kbuild. Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao Acked-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 969e5e13ff5c18603f21d1f9f64ec9194e141ac0 Author: Sean Christopherson Date: Tue Dec 16 08:17:54 2025 -0800 KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeeding [ Upstream commit fc3ba56385d03501eb582e4b86691ba378e556f9 ] Drop the WARN in svm_set_nested_state() on nested_svm_load_cr3() failing as it is trivially easy to trigger from userspace by modifying CPUID after loading CR3. E.g. modifying the state restoration selftest like so: --- tools/testing/selftests/kvm/x86/state_test.c +++ tools/testing/selftests/kvm/x86/state_test.c @@ -280,7 +280,16 @@ int main(int argc, char *argv[]) /* Restore state in a new VM. */ vcpu = vm_recreate_with_one_vcpu(vm); - vcpu_load_state(vcpu, state); + + if (stage == 4) { + state->sregs.cr3 = BIT(44); + vcpu_load_state(vcpu, state); + + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36); + __vcpu_nested_state_set(vcpu, &state->nested); + } else { + vcpu_load_state(vcpu, state); + } /* * Restore XSAVE state in a dummy vCPU, first without doing generates: WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd] Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm] CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd] Call Trace: kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm] kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x61/0xad0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Simply delete the WARN instead of trying to prevent userspace from shoving "illegal" state into CR3. For better or worse, KVM's ABI allows userspace to set CPUID after SREGS, and vice versa, and KVM is very permissive when it comes to guest CPUID. I.e. attempting to enforce the virtual CPU model when setting CPUID could break userspace. Given that the WARN doesn't provide any meaningful protection for KVM or benefit for userspace, simply drop it even though the odds of breaking userspace are minuscule. Opportunistically delete a spurious newline. Fixes: b222b0b88162 ("KVM: nSVM: refactor the CR3 reload on migration") Cc: stable@vger.kernel.org Cc: Yosry Ahmed Reviewed-by: Yosry Ahmed Link: https://patch.msgid.link/20251216161755.1775409-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit 662fae91c30b12d0d641f546b3133747fcd73c78 Author: Sean Christopherson Date: Tue Dec 30 12:59:48 2025 -0800 KVM: x86: Return "unsupported" instead of "invalid" on access to unsupported PV MSR [ Upstream commit 5bb9ac1865123356337a389af935d3913ee917ed ] Return KVM_MSR_RET_UNSUPPORTED instead of '1' (which for all intents and purposes means "invalid") when rejecting accesses to KVM PV MSRs to adhere to KVM's ABI of allowing host reads and writes of '0' to MSRs that are advertised to userspace via KVM_GET_MSR_INDEX_LIST, even if the vCPU model doesn't support the MSR. E.g. running a QEMU VM with -cpu host,-kvmclock,kvm-pv-enforce-cpuid yields: qemu: error: failed to set MSR 0x12 to 0x0 qemu: target/i386/kvm/kvm.c:3301: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. Fixes: 66570e966dd9 ("kvm: x86: only provide PV features if enabled in guest's CPUID") Cc: stable@vger.kernel.org Reviewed-by: Jim Mattson Link: https://patch.msgid.link/20251230205948.4094097-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit e28f45102510aa6b679a38c0e1d523fc0914dd24 Author: Nam Cao Date: Wed Jan 7 10:02:30 2026 +0000 powerpc/pseries: Fix MSI-X allocation failure when quota is exceeded [ Upstream commit c0215e2d72debcd9cbc1c002fb012d50a3140387 ] Nilay reported that since commit daaa574aba6f ("powerpc/pseries/msi: Switch to msi_create_parent_irq_domain()"), the NVMe driver cannot enable MSI-X when the device's MSI-X table size is larger than the firmware's MSI quota for the device. This is because the commit changes how rtas_prepare_msi_irqs() is called: - Before, it is called when interrupts are allocated at the global interrupt domain with nvec_in being the number of allocated interrupts. rtas_prepare_msi_irqs() can return a positive number and the allocation will be retried. - Now, it is called at the creation of per-device interrupt domain with nvec_in being the number of interrupts that the device supports. If rtas_prepare_msi_irqs() returns positive, domain creation just fails. For Nilay's NVMe driver case, rtas_prepare_msi_irqs() returns a positive number (the quota). This causes per-device interrupt domain creation to fail and thus the NVMe driver cannot enable MSI-X. Rework to make this scenario works again: - pseries_msi_ops_prepare() only prepares as many interrupts as the quota permit. - pseries_irq_domain_alloc() fails if the device's quota is exceeded. Now, if the quota is exceeded, pseries_msi_ops_prepare() will only prepare as allowed by the quota. If device drivers attempt to allocate more interrupts than the quota permits, pseries_irq_domain_alloc() will return an error code and msi_handle_pci_fail() will allow device drivers a retry. Reported-by: Nilay Shroff Closes: https://lore.kernel.org/linuxppc-dev/6af2c4c2-97f6-4758-be33-256638ef39e5@linux.ibm.com/ Fixes: daaa574aba6f ("powerpc/pseries/msi: Switch to msi_create_parent_irq_domain()") Signed-off-by: Nam Cao Cc: stable@vger.kernel.org Tested-by: Nilay Shroff Acked-by: Nilay Shroff Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260107100230.1466093-1-namcao@linutronix.de Signed-off-by: Sasha Levin commit 58bd8c5f67a3cd3d10577cf6ba738f16115b5b4c Author: Yeoreum Yun Date: Mon Dec 1 10:51:18 2025 +0000 arm64: kernel: initialize missing kexec_buf->random field [ Upstream commit 15dd20dda979ebab72f6df97845828e78d63ab91 ] Commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") introduced the kexec_buf->random field to enable random placement of kexec_buf. However, this field was never properly initialized for kexec images that do not need to be placed randomly, leading to the following UBSAN warning: [ +0.364528] ------------[ cut here ]------------ [ +0.000019] UBSAN: invalid-load in ./include/linux/kexec.h:210:12 [ +0.000131] load of value 2 is not a valid value for type 'bool' (aka '_Bool') [ +0.000003] CPU: 4 UID: 0 PID: 927 Comm: kexec Not tainted 6.18.0-rc7+ #3 PREEMPT(full) [ +0.000002] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 [ +0.000000] Call trace: [ +0.000001] show_stack+0x24/0x40 (C) [ +0.000006] __dump_stack+0x28/0x48 [ +0.000002] dump_stack_lvl+0x7c/0xb0 [ +0.000002] dump_stack+0x18/0x34 [ +0.000001] ubsan_epilogue+0x10/0x50 [ +0.000002] __ubsan_handle_load_invalid_value+0xc8/0xd0 [ +0.000003] locate_mem_hole_callback+0x28c/0x2a0 [ +0.000003] kexec_locate_mem_hole+0xf4/0x2f0 [ +0.000001] kexec_add_buffer+0xa8/0x178 [ +0.000002] image_load+0xf0/0x258 [ +0.000001] __arm64_sys_kexec_file_load+0x510/0x718 [ +0.000002] invoke_syscall+0x68/0xe8 [ +0.000001] el0_svc_common+0xb0/0xf8 [ +0.000002] do_el0_svc+0x28/0x48 [ +0.000001] el0_svc+0x40/0xe8 [ +0.000002] el0t_64_sync_handler+0x84/0x140 [ +0.000002] el0t_64_sync+0x1bc/0x1c0 To address this, initialise kexec_buf->random field properly. Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Suggested-by: Breno Leitao Cc: stable@vger.kernel.org Signed-off-by: Yeoreum Yun Reviewed-by: Breno Leitao Link: https://lore.kernel.org/all/oninomspajhxp4omtdapxnckxydbk2nzmrix7rggmpukpnzadw@c67o7njgdgm3/ [1] Link: https://lore.kernel.org/all/20250825180531.94bfb86a26a43127c0a1296f@linux-foundation.org/ [2] Link: https://lkml.kernel.org/r/20250826-akpm-v1-1-3c831f0e3799@debian.org Signed-off-by: Breno Leitao Suggested-by: Andrew Morton Signed-off-by: Andrew Morton Reviewed-by: Pratyush Yadav Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit c053b301a0b2d7e6f12fe3c435044458c7b8e656 Author: Wentao Liang Date: Wed Dec 17 14:21:22 2025 +0000 ARM: omap2: Fix reference count leaks in omap_control_init() [ Upstream commit 93a04ab480c8bbcb7d9004be139c538c8a0c1bc8 ] The of_get_child_by_name() function increments the reference count of child nodes, causing multiple reference leaks in omap_control_init(): 1. scm_conf node never released in normal/error paths 2. clocks node leak when checking existence 3. Missing scm_conf release before np in error paths Fix these leaks by adding proper of_node_put() calls and separate error handling. Fixes: e5b635742e98 ("ARM: OMAP2+: control: add syscon support for register accesses") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Andreas Kemnade Link: https://patch.msgid.link/20251217142122.1861292-1-vulab@iscas.ac.cn Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit 5d83ae6ccdc95ab1751cf6206fe8b197ec6abadb Author: Krzysztof Kozlowski Date: Mon Dec 29 12:57:35 2025 +0100 arm64: dts: qcom: sm8750: Fix BAM DMA probing [ Upstream commit 1c6192ec9c4ab8bdb7b2cf8763b7ef7e38671ffe ] Bindings always required "qcom,num-ees" and "num-channels" properties, as reported by dtbs_check: sm8750-mtp.dtb: dma-controller@1dc4000 (qcom,bam-v1.7.4): 'anyOf' conditional failed, one must be fixed: 'qcom,powered-remotely' is a required property 'num-channels' is a required property 'qcom,num-ees' is a required property 'clocks' is a required property 'clock-names' is a required property However since commit 5068b5254812 ("dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees") missing properties are actually fatal and BAM does not probe: bam-dma-engine 1dc4000.dma-controller: num-channels unspecified in dt bam-dma-engine 1dc4000.dma-controller: probe with driver bam-dma-engine failed with error -22 Fixes: eeb0f3e4ea67 ("arm64: dts: qcom: sm8750: Add QCrypto nodes") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251229115734.205744-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b965b990c191325e59d20bbe46a6e37989aa7fc5 Author: Abel Vesa Date: Wed Dec 24 12:53:29 2025 +0200 arm64: dts: qcom: x1e80100: Add missing TCSR ref clock to the DP PHYs [ Upstream commit 0907cab01ff9746ecf08592edd9bd85d2636be58 ] The DP PHYs on X1E80100 need the ref clock which is provided by the TCSR CC. The current X Elite devices supported upstream work fine without this clock, because the boot firmware leaves this clock enabled. But we should not rely on that. Also, even though this change breaks the ABI, it is needed in order to make the driver disables this clock along with the other ones, for a proper bring-down of the entire PHY. So lets attach it to each of the DP PHYs in order to do that. Cc: stable@vger.kernel.org # v6.9 Fixes: 1940c25eaa63 ("arm64: dts: qcom: x1e80100: Add display nodes") Reviewed-by: Bjorn Andersson Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20251224-phy-qcom-edp-add-missing-refclk-v5-3-3f45d349b5ac@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit adae1932f01a56a14c3da493ab044e06a1892084 Author: Benjamin Gaignard Date: Tue Dec 9 11:34:17 2025 +0100 media: verisilicon: AV1: Fix tx mode bit setting [ Upstream commit cb3f945c012ab152fd2323e0df34c2b640071738 ] AV1 specification describes 3 possibles tx modes: 4x4 only, largest and select. The hardware allows 5 possibles tx modes: 4x4 only, 8x8, 16x16, 32x32 and select. Since the both aren't exactly matching we need to add a mapping function to set the correct mode on hardware. Signed-off-by: Benjamin Gaignard Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: stable@vger.kernel.org Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 93adedf67b07f4f1639fb0e4a4707720c8425425 Author: Benjamin Gaignard Date: Tue Dec 9 11:34:01 2025 +0100 media: verisilicon: AV1: Fix enable cdef computation [ Upstream commit e0f99b810e1181374370f91cd996d761549e147f ] If all the fields of the CDEF parameters are zero (which is the default), then av1_enable_cdef register needs to be unset (despite the V4L2_AV1_SEQUENCE_FLAG_ENABLE_CDEF possibly being set). Signed-off-by: Benjamin Gaignard Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: stable@vger.kernel.org Reported-by: Jianfeng Liu Closes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4786 Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil [hverkuil: dropped Link tag since it just duplicated the Closes: URL] Signed-off-by: Sasha Levin commit ea316b784fe6a61b29131c98cddb24e651b1dcbc Author: Jackson Lee Date: Wed Nov 19 15:25:47 2025 +0900 media: chips-media: wave5: Fix Null reference while testing fluster [ Upstream commit e66ff2b08e4ee1c4d3b84f24818e5bcc178cc3a4 ] When multi instances are created/destroyed, many interrupts happens and structures for decoder are removed. "struct vpu_instance" this structure is shared for all flow in the decoder, so if the structure is not protected by lock, Null dereference could happens sometimes. IRQ Handler was spilt to two phases and Lock was added as well. Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Tested-by: Brandon Brnich Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 27cb12b7dc88c51582094eeb2b65b0e94603e411 Author: Jackson Lee Date: Wed Nov 19 15:25:46 2025 +0900 media: chips-media: wave5: Fix SError of kernel panic when closed [ Upstream commit cbb9c0d50e471483cced55f5b7db4569dcd959a6 ] SError of kernel panic rarely happened while testing fluster. The root cause was to enter suspend mode because timeout of autosuspend delay happened. [ 48.834439] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError [ 48.834455] CPU: 0 UID: 0 PID: 1067 Comm: v4l2h265dec0:sr Not tainted 6.12.9-gc9e21a1ebd75-dirty #7 [ 48.834461] Hardware name: ti Texas Instruments J721S2 EVM/Texas Instruments J721S2 EVM, BIOS 2025.01-00345-gbaf3aaa8ecfa 01/01/2025 [ 48.834464] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 48.834468] pc : wave5_dec_clr_disp_flag+0x40/0x80 [wave5] [ 48.834488] lr : wave5_dec_clr_disp_flag+0x40/0x80 [wave5] [ 48.834495] sp : ffff8000856e3a30 [ 48.834497] x29: ffff8000856e3a30 x28: ffff0008093f6010 x27: ffff000809158130 [ 48.834504] x26: 0000000000000000 x25: ffff00080b625000 x24: ffff000804a9ba80 [ 48.834509] x23: ffff000802343028 x22: ffff000809158150 x21: ffff000802218000 [ 48.834513] x20: ffff0008093f6000 x19: ffff0008093f6000 x18: 0000000000000000 [ 48.834518] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff74009618 [ 48.834523] x14: 000000010000000c x13: 0000000000000000 x12: 0000000000000000 [ 48.834527] x11: ffffffffffffffff x10: ffffffffffffffff x9 : ffff000802343028 [ 48.834532] x8 : ffff00080b6252a0 x7 : 0000000000000038 x6 : 0000000000000000 [ 48.834536] x5 : ffff00080b625060 x4 : 0000000000000000 x3 : 0000000000000000 [ 48.834541] x2 : 0000000000000000 x1 : ffff800084bf0118 x0 : ffff800084bf0000 [ 48.834547] Kernel panic - not syncing: Asynchronous SError Interrupt [ 48.834549] CPU: 0 UID: 0 PID: 1067 Comm: v4l2h265dec0:sr Not tainted 6.12.9-gc9e21a1ebd75-dirty #7 [ 48.834554] Hardware name: ti Texas Instruments J721S2 EVM/Texas Instruments J721S2 EVM, BIOS 2025.01-00345-gbaf3aaa8ecfa 01/01/2025 [ 48.834556] Call trace: [ 48.834559] dump_backtrace+0x94/0xec [ 48.834574] show_stack+0x18/0x24 [ 48.834579] dump_stack_lvl+0x38/0x90 [ 48.834585] dump_stack+0x18/0x24 [ 48.834588] panic+0x35c/0x3e0 [ 48.834592] nmi_panic+0x40/0x8c [ 48.834595] arm64_serror_panic+0x64/0x70 [ 48.834598] do_serror+0x3c/0x78 [ 48.834601] el1h_64_error_handler+0x34/0x4c [ 48.834605] el1h_64_error+0x64/0x68 [ 48.834608] wave5_dec_clr_disp_flag+0x40/0x80 [wave5] [ 48.834615] wave5_vpu_dec_clr_disp_flag+0x54/0x80 [wave5] [ 48.834622] wave5_vpu_dec_buf_queue+0x19c/0x1a0 [wave5] [ 48.834628] __enqueue_in_driver+0x3c/0x74 [videobuf2_common] [ 48.834639] vb2_core_qbuf+0x508/0x61c [videobuf2_common] [ 48.834646] vb2_qbuf+0xa4/0x168 [videobuf2_v4l2] [ 48.834656] v4l2_m2m_qbuf+0x80/0x238 [v4l2_mem2mem] [ 48.834666] v4l2_m2m_ioctl_qbuf+0x18/0x24 [v4l2_mem2mem] [ 48.834673] v4l_qbuf+0x48/0x5c [videodev] [ 48.834704] __video_do_ioctl+0x180/0x3f0 [videodev] [ 48.834725] video_usercopy+0x2ec/0x68c [videodev] [ 48.834745] video_ioctl2+0x18/0x24 [videodev] [ 48.834766] v4l2_ioctl+0x40/0x60 [videodev] [ 48.834786] __arm64_sys_ioctl+0xa8/0xec [ 48.834793] invoke_syscall+0x44/0x100 [ 48.834800] el0_svc_common.constprop.0+0xc0/0xe0 [ 48.834804] do_el0_svc+0x1c/0x28 [ 48.834809] el0_svc+0x30/0xd0 [ 48.834813] el0t_64_sync_handler+0xc0/0xc4 [ 48.834816] el0t_64_sync+0x190/0x194 [ 48.834820] SMP: stopping secondary CPUs [ 48.834831] Kernel Offset: disabled [ 48.834833] CPU features: 0x08,00002002,80200000,4200421b [ 48.834837] Memory Limit: none [ 49.161404] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]--- Fixes: 2092b3833487 ("media: chips-media: wave5: Support runtime suspend/resume") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Tested-by: Brandon Brnich Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 526816f2e331954d80fed8b37fa94efbbdde2b8d Author: Xulin Sun Date: Thu Dec 4 17:41:53 2025 +0800 media: chips-media: wave5: Fix device cleanup order to prevent kernel panic [ Upstream commit b74cedac643b02aefa7da881b58a3792859d9748 ] Move video device unregistration to the beginning of the remove function to ensure all video operations are stopped before cleaning up the worker thread and disabling PM runtime. This prevents hardware register access after the device has been powered down. In polling mode, the hrtimer periodically triggers wave5_vpu_timer_callback() which queues work to the kthread worker. The worker executes wave5_vpu_irq_work_fn() which reads hardware registers via wave5_vdi_read_register(). The original cleanup order disabled PM runtime and powered down hardware before unregistering video devices. When autosuspend triggers and powers off the hardware, the video devices are still registered and the worker thread can still be triggered by the hrtimer, causing it to attempt reading registers from powered-off hardware. This results in a bus error (synchronous external abort) and kernel panic. This causes random kernel panics during encoding operations: Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP Modules linked in: wave5 rpmsg_ctrl rpmsg_char ... CPU: 0 UID: 0 PID: 1520 Comm: vpu_irq_thread Tainted: G M W pc : wave5_vdi_read_register+0x10/0x38 [wave5] lr : wave5_vpu_irq_work_fn+0x28/0x60 [wave5] Call trace: wave5_vdi_read_register+0x10/0x38 [wave5] kthread_worker_fn+0xd8/0x238 kthread+0x104/0x120 ret_from_fork+0x10/0x20 Code: aa1e03e9 d503201f f9416800 8b214000 (b9400000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: synchronous external abort: Fatal exception Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Xulin Sun Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit cc8071b1bac6568ea09d54be2d4f74dba80e17f8 Author: Xulin Sun Date: Thu Dec 4 17:41:52 2025 +0800 media: chips-media: wave5: Fix kthread worker destruction in polling mode [ Upstream commit 5a0c122e834b2f7f029526422c71be922960bf03 ] Fix the cleanup order in polling mode (irq < 0) to prevent kernel warnings during module removal. Cancel the hrtimer before destroying the kthread worker to ensure work queues are empty. In polling mode, the driver uses hrtimer to periodically trigger wave5_vpu_timer_callback() which queues work via kthread_queue_work(). The kthread_destroy_worker() function validates that both work queues are empty with WARN_ON(!list_empty(&worker->work_list)) and WARN_ON(!list_empty(&worker->delayed_work_list)). The original code called kthread_destroy_worker() before hrtimer_cancel(), creating a race condition where the timer could fire during worker destruction and queue new work, triggering the WARN_ON. This causes the following warning on every module unload in polling mode: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1034 at kernel/kthread.c:1430 kthread_destroy_worker+0x84/0x98 Modules linked in: wave5(-) rpmsg_ctrl rpmsg_char ... Call trace: kthread_destroy_worker+0x84/0x98 wave5_vpu_remove+0xc8/0xe0 [wave5] platform_remove+0x30/0x58 ... ---[ end trace 0000000000000000 ]--- Fixes: ed7276ed2fd0 ("media: chips-media: wave5: Add hrtimer based polling support") Cc: stable@vger.kernel.org Signed-off-by: Xulin Sun Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 3a278a55ead50db2444c8f01410c7f5a68723990 Author: Xulin Sun Date: Thu Dec 4 17:41:51 2025 +0800 media: chips-media: wave5: Fix PM runtime usage count underflow [ Upstream commit 9cf4452e824c1e2d41c9c0b13cc8a32a0a7dec38 ] Replace pm_runtime_put_sync() with pm_runtime_dont_use_autosuspend() in the remove path to properly pair with pm_runtime_use_autosuspend() from probe. This allows pm_runtime_disable() to handle reference count cleanup correctly regardless of current suspend state. The driver calls pm_runtime_put_sync() unconditionally in remove, but the device may already be suspended due to autosuspend configured in probe. When autosuspend has already suspended the device, the usage count is 0, and pm_runtime_put_sync() decrements it to -1. This causes the following warning on module unload: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 963 at kernel/kthread.c:1430 kthread_destroy_worker+0x84/0x98 ... vdec 30210000.video-codec: Runtime PM usage count underflow! Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Xulin Sun Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a62ba5aa9ee95fd953583e95e519badf0b76ecf3 Author: Haoxiang Li Date: Wed Oct 8 17:01:56 2025 +0800 media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove() [ Upstream commit f128bab57b8018e526b7eda854ca20069863af47 ] In mtk_mdp_probe(), vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak. Fixes: c8eb2d7e8202 ("[media] media: Add Mediatek MDP Driver") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b3fc99fe5b25613dd61c57bc70b8479adff4f60d Author: Haoxiang Li Date: Wed Oct 8 16:55:03 2025 +0800 media: mtk-mdp: Fix error handling in probe function [ Upstream commit 8a8a3232abac5b972058a5f2cb3e33199d2a8648 ] Add mtk_mdp_unregister_m2m_device() on the error handling path to prevent resource leak. Add check for the return value of vpu_get_plat_device() to prevent null pointer dereference. And vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak. Fixes: c8eb2d7e8202 ("[media] media: Add Mediatek MDP Driver") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit d659f72af5666a6ea35cf30764bae4b0571151b2 Author: Irui Wang Date: Sun Sep 7 17:35:56 2025 +0800 media: mediatek: encoder: Fix uninitialized scalar variable issue [ Upstream commit 88e935de7cf8795d7a6a51385db87ecb361a7050 ] UNINIT checker finds some instances of variables that are used without being initialized, for example using the uninitialized value enc_result.is_key_frm can result in unpredictable behavior, so initialize these variables after declaring. Fixes: 4e855a6efa54 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver") Cc: stable@vger.kernel.org Signed-off-by: Irui Wang Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e2a45398bba352f1c9124a7d04e01d1cab94409e Author: Ricardo Ribalda Date: Wed Nov 19 20:17:36 2025 +0000 media: uvcvideo: Fix support for V4L2_CTRL_FLAG_HAS_WHICH_MIN_MAX [ Upstream commit 4238bd6dc6ba36f44d89a60338223d5a4f708cbf ] The VIDIOC_G_EXT_CTRLS with which V4L2_CTRL_WHICH_(MIN|MAX)_VAL can only work for controls that have previously announced support for it. This patch fixes the following v4l2-compliance error: info: checking extended control 'User Controls' (0x00980001) fail: v4l2-test-controls.cpp(980): ret != EINVAL (got 13) test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL Fixes: 39d2c891c96e ("media: uvcvideo: support V4L2_CTRL_WHICH_MIN/MAX_VAL") Cc: stable@vger.kernel.org Signed-off-by: Ricardo Ribalda Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 451cc650e40e8c3222d37877a9e4be0fcaacb9c8 Author: Eric Biggers Date: Fri Dec 19 11:29:08 2025 -0800 dm-verity: correctly handle dm_bufio_client_create() failure [ Upstream commit 119f4f04186fa4f33ee6bd39af145cdaff1ff17f ] If either of the calls to dm_bufio_client_create() in verity_fec_ctr() fails, then dm_bufio_client_destroy() is later called with an ERR_PTR() argument. That causes a crash. Fix this. Fixes: a739ff3f543a ("dm verity: add support for forward error correction") Cc: stable@vger.kernel.org Reviewed-by: Sami Tolvanen Signed-off-by: Eric Biggers Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 2e170d8bb3b3cd67b4ae1f5ce237f87a50726d17 Author: Alexey Minnekhanov Date: Sun Nov 16 04:12:35 2025 +0300 arm64: dts: qcom: sdm630: Add missing MDSS reset [ Upstream commit 0c1d1591f898d54eaa4c8f2a1535ab21bf4e42e4 ] If the OS does not support recovering the state left by the bootloader it needs a way to reset display hardware, so that it can start from a clean state. Add a reference to the relevant reset. It fixes display init issue appeared in Linux v6.17: without reset device boots into black screen and you need to turn display off/on to "fix" it. Also sometimes it can boot into solid blue color with these messages in kernel log: hw recovery is not complete for ctl:2 [drm:dpu_encoder_phys_vid_prepare_for_kickoff:569] [dpu error]enc33 intf1 ctl 2 reset failure: -22 [drm:dpu_encoder_frame_done_timeout:2727] [dpu error]enc33 frame done timeout Fixes: 0e789b491ba0 ("pmdomain: core: Leave powered-on genpds on until sync_state") Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Alexey Minnekhanov Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20251116-sdm660-mdss-reset-v2-3-6219bec0a97f@postmarketos.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c2b9214c34f5710c04c695c6781d04dd2ef25c47 Author: Abel Vesa Date: Wed Dec 24 12:53:28 2025 +0200 phy: qcom: edp: Make the number of clocks flexible [ Upstream commit 7d51b709262c5aa31d2b9cd31444112c1b2dae03 ] On X Elite, the DP PHY needs another clock called ref, while all other platforms do not. The current X Elite devices supported upstream work fine without this clock, because the boot firmware leaves this clock enabled. But we should not rely on that. Also, even though this change breaks the ABI, it is needed in order to make the driver disables this clock along with the other ones, for a proper bring-down of the entire PHY. So in order to handle these clocks on different platforms, make the driver get all the clocks regardless of how many there are provided. Cc: stable@vger.kernel.org # v6.10 Fixes: db83c107dc29 ("phy: qcom: edp: Add v6 specific ops and X1E80100 platform support") Reviewed-by: Dmitry Baryshkov Reviewed-by: Bjorn Andersson Signed-off-by: Abel Vesa Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-missing-refclk-v5-2-3f45d349b5ac@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 6cc6c73a87c33b557794a4b3891ebcdaff49b30c Author: Ilpo Järvinen Date: Mon Dec 8 16:56:54 2025 +0200 PCI: Use resource_set_range() that correctly sets ->end [ Upstream commit 11721c45a8266a9d0c9684153d20e37159465f96 ] __pci_read_base() sets resource start and end addresses when resource is larger than 4G but pci_bus_addr_t or resource_size_t are not capable of representing 64-bit PCI addresses. This creates a problematic resource that has non-zero flags but the start and end addresses do not yield to resource size of 0 but 1. Replace custom resource addresses setup with resource_set_range() that correctly sets end address as -1 which results in resource_size() returning 0. For consistency, also use resource_set_range() in the other branch that does size based resource setup. Fixes: 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than 4GB") Link: https://lore.kernel.org/all/20251207215359.28895-1-ansuelsmth@gmail.com/T/#m990492684913c5a158ff0e5fc90697d8ad95351b Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Cc: Christian Marangi Link: https://patch.msgid.link/20251208145654.5294-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit fcfdf9794afea11698cd4f0f3acfeefa400b76f8 Author: Niklas Cassel Date: Mon Dec 22 07:42:13 2025 +0100 Revert "PCI: dwc: Don't wait for link up if driver can detect Link Up event" [ Upstream commit 142d5869f6eec3110adda0ad2d931f5b3c22371d ] This reverts commit 8d3bf19f1b585a3cc0027f508b64c33484db8d0d. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. So revert the change that skipped dw_pcie_wait_for_link() if the Link up IRQ was used by a vendor glue driver. Suggested-by: Manivannan Sadhasivam Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Tested-by: Shawn Lin Acked-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-14-cassel@kernel.org Signed-off-by: Sasha Levin commit f956c3c101e20b31cca9553a0662c98bd92d5502 Author: Niklas Cassel Date: Mon Dec 22 07:42:12 2025 +0100 Revert "PCI: qcom: Enumerate endpoints based on Link up event in 'global_irq' interrupt" [ Upstream commit 9a9793b55854422652ea92625e48277c4651c0fd ] This reverts commit 4581403f67929d02c197cb187c4e1e811c9e762a. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. The long term plan is to migrate this driver to the upcoming pwrctrl APIs that are supposed to handle this problem elegantly. Suggested-by: Manivannan Sadhasivam Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Tested-by: Shawn Lin Acked-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-13-cassel@kernel.org Signed-off-by: Sasha Levin commit 46adbe1c144e3927b6a4d44f2c64e12b57f32198 Author: Niklas Cassel Date: Mon Dec 22 07:42:11 2025 +0100 Revert "PCI: qcom: Enable MSI interrupts together with Link up if 'Global IRQ' is supported" [ Upstream commit 7ebdefb87942073679e56cfbc5a72e8fc5441bfc ] This reverts commit ba4a2e2317b9faeca9193ed6d3193ddc3cf2aba3. Since the Link up IRQ support is going away, revert the MSI logic that got added for it too. Suggested-by: Manivannan Sadhasivam Signed-off-by: Niklas Cassel [mani: reworded the description] Signed-off-by: Manivannan Sadhasivam Tested-by: Shawn Lin Acked-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-12-cassel@kernel.org Signed-off-by: Sasha Levin commit d6fecafe7b2331fc9783c1958d3e6dd127a45111 Author: Niklas Cassel Date: Mon Dec 22 07:42:10 2025 +0100 Revert "PCI: qcom: Don't wait for link if we can detect Link Up" [ Upstream commit e9ce5b3804436301ab343bc14203a4c14b336d1b ] This reverts commit 36971d6c5a9a134c15760ae9fd13c6d5f9a36abb. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. The long term plan is to migrate this driver to the upcoming pwrctrl APIs that are supposed to handle this problem elegantly. Suggested-by: Manivannan Sadhasivam Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Tested-by: Shawn Lin Acked-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-11-cassel@kernel.org Signed-off-by: Sasha Levin commit 77ac28b38a86009675f0cddf3717aeb8630a7a0f Author: Niklas Cassel Date: Mon Dec 22 07:42:08 2025 +0100 Revert "PCI: dw-rockchip: Don't wait for link since we can detect Link Up" [ Upstream commit fc6298086bfacaa7003b0bd1da4e4f42b29f7d77 ] This reverts commit ec9fd499b9c60a187ac8d6414c3c343c77d32e42. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. The long term plan is to migrate this driver to the upcoming pwrctrl APIs that are supposed to handle this problem elegantly. Suggested-by: Manivannan Sadhasivam Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Tested-by: Shawn Lin Acked-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-9-cassel@kernel.org Signed-off-by: Sasha Levin commit 4cccf815bcccaebc496d0529a43deb76d74d642d Author: Tvrtko Ursulin Date: Mon Dec 8 19:15:50 2025 +0100 drm/xe: Fix ggtt fb alignment [ Upstream commit a61bf068f1fe359203f1af191cb523b77dc32752 ] Pass the correct alignment from intel_fb_pin_to_ggtt() down to __xe_pin_fb_vma(). Signed-off-by: Tvrtko Ursulin Reported-by: Ville Syrjälä Closes: https://lore.kernel.org/intel-xe/aNL_RgLy13fXJbYx@intel.com/ Cc: Juha-Pekka Heikkila Reviewed-by: Ville Syrjälä Fixes: b0228a337de8 ("drm/xe/display: align framebuffers according to hw requirements") Cc: # v6.13+ Signed-off-by: Thomas Hellström Link: https://patch.msgid.link/20251208181550.6618-1-tursulin@igalia.com Signed-off-by: Sasha Levin commit cdf8bbbd9017adcfb91ad9a902198d4b507719a9 Author: Thomas Zimmermann Date: Fri Dec 12 17:00:36 2025 +0100 drm/tests: shmem: Hold reservation lock around purge [ Upstream commit 3f41307d589c2f25d556d47b165df808124cd0c4 ] Acquire and release the GEM object's reservation lock around calls to the object's purge operation. The tests use drm_gem_shmem_purge_locked(), which led to errors such as show below. [ 58.709128] WARNING: CPU: 1 PID: 1354 at drivers/gpu/drm/drm_gem_shmem_helper.c:515 drm_gem_shmem_purge_locked+0x51c/0x740 Only export the new helper drm_gem_shmem_purge() for Kunit tests. This is not an interface for regular drivers. Signed-off-by: Thomas Zimmermann Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions") Cc: dri-devel@lists.freedesktop.org Cc: # v6.16+ Reviewed-by: Boris Brezillon Link: https://patch.msgid.link/20251212160317.287409-6-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 9cc77691b5fd615625955cedf726da57543088f1 Author: Thomas Zimmermann Date: Fri Dec 12 17:00:35 2025 +0100 drm/tests: shmem: Hold reservation lock around madvise [ Upstream commit 607d07d8cc0b835a8701259f08a03dc149b79b4f ] Acquire and release the GEM object's reservation lock around calls to the object's madvide operation. The tests use drm_gem_shmem_madvise_locked(), which led to errors such as show below. [ 58.339389] WARNING: CPU: 1 PID: 1352 at drivers/gpu/drm/drm_gem_shmem_helper.c:499 drm_gem_shmem_madvise_locked+0xde/0x140 Only export the new helper drm_gem_shmem_madvise() for Kunit tests. This is not an interface for regular drivers. Signed-off-by: Thomas Zimmermann Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions") Cc: dri-devel@lists.freedesktop.org Cc: # v6.16+ Reviewed-by: Boris Brezillon Link: https://patch.msgid.link/20251212160317.287409-5-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 6b953d92f2f29e74b125617c6f00300fa1bed97e Author: Thomas Zimmermann Date: Fri Dec 12 17:00:34 2025 +0100 drm/tests: shmem: Hold reservation lock around vmap/vunmap [ Upstream commit cda83b099f117f2a28a77bf467af934cb39e49cf ] Acquire and release the GEM object's reservation lock around vmap and vunmap operations. The tests use vmap_locked, which led to errors such as show below. [ 122.292030] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:390 drm_gem_shmem_vmap_locked+0x3a3/0x6f0 [ 122.468066] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:293 drm_gem_shmem_pin_locked+0x1fe/0x350 [ 122.563504] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:234 drm_gem_shmem_get_pages_locked+0x23c/0x370 [ 122.662248] WARNING: CPU: 2 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:452 drm_gem_shmem_vunmap_locked+0x101/0x330 Only export the new vmap/vunmap helpers for Kunit tests. These are not interfaces for regular drivers. Signed-off-by: Thomas Zimmermann Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions") Cc: dri-devel@lists.freedesktop.org Cc: # v6.16+ Reviewed-by: Boris Brezillon Link: https://patch.msgid.link/20251212160317.287409-4-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 595227cf408fbcc0d11862e57f697dc701dad63a Author: Thomas Zimmermann Date: Fri Dec 12 17:00:33 2025 +0100 drm/tests: shmem: Add clean-up action to unpin pages [ Upstream commit b47b9ecef309459278eb52f02b50eefdeaac4f6d ] Automatically unpin pages on cleanup. The test currently fails with the error [ 58.246263] drm-kunit-mock-device drm_gem_shmem_test_get_sg_table.drm-kunit-mock-device: [drm] drm_WARN_ON(refcount_read(&shmem->pages_pin_count)) while cleaning up the GEM object. The pin count has to be zero at this point. Signed-off-by: Thomas Zimmermann Fixes: d586b535f144 ("drm/shmem-helper: Add and use pages_pin_count") Cc: dri-devel@lists.freedesktop.org Cc: # v6.16+ Reviewed-by: Boris Brezillon Link: https://patch.msgid.link/20251212160317.287409-3-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 496e765b7205949d38dc66010bd54cd3f0a808ee Author: Thomas Zimmermann Date: Fri Dec 12 17:00:32 2025 +0100 drm/tests: shmem: Swap names of export tests [ Upstream commit 89f23d42006630dd94c01a8c916f8c648141ad8e ] GEM SHMEM has 2 helpers for exporting S/G tables. Swap the names of the rsp. tests, so that each matches the helper it tests. Signed-off-by: Thomas Zimmermann Fixes: 93032ae634d4 ("drm/test: add a test suite for GEM objects backed by shmem") Cc: dri-devel@lists.freedesktop.org Cc: # v6.8+ Reviewed-by: Boris Brezillon Link: https://patch.msgid.link/20251212160317.287409-2-tzimmermann@suse.de Signed-off-by: Sasha Levin commit bfcee87fd1756d5eecfba51b451a8866d6d7d7a2 Author: Thadeu Lima de Souza Cascardo Date: Mon Dec 15 16:05:50 2025 -0300 fpga: dfl: use subsys_initcall to allow built-in drivers to be added [ Upstream commit 267f53140c9d0bf270bbe0148082e9b8e5011273 ] The dfl code adds a bus. If it is built-in and there is a built-in driver as well, the dfl module_init may be called after the driver module_init, leading to a failure to register the driver as the bus has not been added yet. Use subsys_initcall, which guarantees it will be called before the drivers init code. Without the fix, we see failures like this: [ 0.479475] Driver 'intel-m10-bmc' was unable to register with bus_type 'dfl' because the bus was not initialized. Cc: stable@vger.kernel.org Fixes: 9ba3a0aa09fe ("fpga: dfl: create a dfl bus type to support DFL devices") Signed-off-by: Thadeu Lima de Souza Cascardo Link: https://lore.kernel.org/r/20251215-dfl_subsys-v1-1-21807bad6b10@igalia.com Reviewed-by: Xu Yilun Signed-off-by: Xu Yilun Signed-off-by: Sasha Levin commit a0eb5f82212b3c1fba87a15dced7129cb22dafcb Author: Peter Ujfalusi Date: Wed Dec 17 16:39:41 2025 +0200 ASoC: SOF: ipc4-control: Keep the payload size up to date [ Upstream commit ebcfdbe4add923dfb690e6fb9d158da87ae0b6bf ] When the bytes data is read from the firmware, the size of the payload can be different than what it was previously. For example when the topology did not contained payload data at all for the control, the data size was 0. For get operation allow maximum size of payload to be read and then update the sizes according to the completed message. Similarly, keep the size in sync when updating the data in firmware. With the change we will be able to read data from firmware for bytes controls which did not had initial payload defined in topology. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c7bf344a83a10ea60c5052651b2b46a360d36463 Author: Peter Ujfalusi Date: Wed Dec 17 16:39:40 2025 +0200 ASoC: SOF: ipc4-control: Use the correct size for scontrol->ipc_control_data [ Upstream commit c1876fc33c5976837e4c73719c7582617efc6919 ] The size of the data behind scontrol->ipc_control_data is stored in scontrol->size, use this when copying data for backup/restore. Fixes: db38d86d0c54 ("ASoC: sof: Improve sof_ipc4_bytes_ext_put function") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a704a1a4394b5877b9adc31b2c3165ad0b541896 Author: Peter Ujfalusi Date: Wed Dec 17 16:39:39 2025 +0200 ASoC: SOF: ipc4-topology: Correct the allocation size for bytes controls [ Upstream commit a653820700b81c9e6f05ac23b7969ecec1a18e85 ] The size of the data behind of scontrol->ipc_control_data for bytes controls is: [1] sizeof(struct sof_ipc4_control_data) + // kernel only struct [2] sizeof(struct sof_abi_hdr)) + payload The max_size specifies the size of [2] and it is coming from topology. Change the function to take this into account and allocate adequate amount of memory behind scontrol->ipc_control_data. With the change we will allocate [1] amount more memory to be able to hold the full size of data. Fixes: a382082ff74b ("ASoC: SOF: ipc4-topology: Add support for TPLG_CTL_BYTES") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c5fb5db719c7b634325a828f88dde57e726af04e Author: Peter Ujfalusi Date: Wed Dec 17 16:39:38 2025 +0200 ASoC: SOF: ipc4-control: If there is no data do not send bytes update [ Upstream commit 2fa74713744dc5e908fff851c20f5f89fd665fb7 ] When the bytes control have no data (payload) then there is no need to send an IPC message as there is nothing to send. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ab8c0de60f16d7e0b162ccbbb35fcf1f277c97c2 Author: Chia-I Wu Date: Thu Dec 4 09:45:45 2025 -0800 drm/panthor: fix for dma-fence safe access rules [ Upstream commit efe24898485c5c831e629d9c6fb9350c35cb576f ] Commit 506aa8b02a8d6 ("dma-fence: Add safe access helpers and document the rules") details the dma-fence safe access rules. The most common culprit is that drm_sched_fence_get_timeline_name may race with group_free_queue. Signed-off-by: Chia-I Wu Reviewed-by: Boris Brezillon Reviewed-by: Liviu Dudau Reviewed-by: Steven Price Cc: stable@vger.kernel.org # v6.17+ Signed-off-by: Steven Price Link: https://patch.msgid.link/20251204174545.399059-1-olvaffe@gmail.com Signed-off-by: Sasha Levin commit a803cfad1f23c04cf9d5500b533afb4e2585a03e Author: Francesco Dolcini Date: Tue Dec 9 09:41:25 2025 +0100 arm64: dts: ti: am62p-verdin: Fix SD regulator startup delay [ Upstream commit de86dbc0fb00bd3773db4b05d9f5926f0faa2244 ] The power switch used to power the SD card interface might have more than 2ms turn-on time, increase the startup delay to 20ms to prevent failures. Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P") Cc: stable@vger.kernel.org Signed-off-by: Francesco Dolcini Link: https://patch.msgid.link/20251209084126.33282-1-francesco@dolcini.it Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 0bcfebb83b5460d5be4e5c9dfb19cdaf3d4cb1db Author: Mehdi Ben Hadj Khelifa Date: Mon Dec 1 23:23:07 2025 +0100 hfsplus: ensure sb->s_fs_info is always cleaned up [ Upstream commit 126fb0ce99431126b44a6c360192668c818f641f ] When hfsplus was converted to the new mount api a bug was introduced by changing the allocation pattern of sb->s_fs_info. If setup_bdev_super() fails after a new superblock has been allocated by sget_fc(), but before hfsplus_fill_super() takes ownership of the filesystem-specific s_fs_info data it was leaked. Fix this by freeing sb->s_fs_info in hfsplus_kill_super(). Cc: stable@vger.kernel.org Fixes: 432f7c78cb00 ("hfsplus: convert hfsplus to use the new mount api") Reported-by: Viacheslav Dubeyko Tested-by: Viacheslav Dubeyko Signed-off-by: Christian Brauner Signed-off-by: Mehdi Ben Hadj Khelifa Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20251201222843.82310-3-mehdi.benhadjkhelifa@gmail.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 428093cfa8b2b4c4d14985c2b82cd5080dba9fbe Author: Chris Brandt Date: Fri Nov 14 14:45:29 2025 -0500 clk: renesas: rzg2l: Select correct div round macro [ Upstream commit f9451374dcfdfe669ee55b58ee6c11e8638980e4 ] Variable foutvco_rate is an unsigned long, not an unsigned long long. Cc: stable@kernel.org Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/CAMuHMdVf7dSeqAhtyxDCFuCheQRzwS-8996Rr2Ntui21uiBgdA@mail.gmail.com Fixes: dabf72b85f29 ("clk: renesas: rzg2l: Fix FOUTPOSTDIV clk") Signed-off-by: Chris Brandt Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251114194529.3304361-1-chris.brandt@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 01dfc5abfa4df8bced3524663d502bfad81df457 Author: Chris Brandt Date: Fri Nov 14 14:37:11 2025 -0500 clk: renesas: rzg2l: Fix intin variable size [ Upstream commit a00655d98cd885472c311f01dff3e668d1288d0a ] INTIN is a 12-bit register value, so u8 is too small. Fixes: 1561380ee72f ("clk: renesas: rzg2l: Add FOUTPOSTDIV clk support") Cc: stable@vger.kernel.org Reported-by: Hugo Villeneuve Closes: https://lore.kernel.org/20251107113058.f334957151d1a8dd94dd740b@hugovil.com Signed-off-by: Chris Brandt Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251114193711.3277912-1-chris.brandt@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 2e4a70f3c30910427e5ea848b799066d67b963d5 Author: Gui-Dong Han Date: Wed Dec 3 01:49:48 2025 +0800 rpmsg: core: fix race in driver_override_show() and use core helper [ Upstream commit 42023d4b6d2661a40ee2dcf7e1a3528a35c638ca ] The driver_override_show function reads the driver_override string without holding the device_lock. However, the store function modifies and frees the string while holding the device_lock. This creates a race condition where the string can be freed by the store function while being read by the show function, leading to a use-after-free. To fix this, replace the rpmsg_string_attr macro with explicit show and store functions. The new driver_override_store uses the standard driver_set_override helper. Since the introduction of driver_set_override, the comments in include/linux/rpmsg.h have stated that this helper must be used to set or clear driver_override, but the implementation was not updated until now. Because driver_set_override modifies and frees the string while holding the device_lock, the new driver_override_show now correctly holds the device_lock during the read operation to prevent the race. Additionally, since rpmsg_string_attr has only ever been used for driver_override, removing the macro simplifies the code. Fixes: 39e47767ec9b ("rpmsg: Add driver_override device attribute for rpmsg_device") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han Link: https://lore.kernel.org/r/20251202174948.12693-1-hanguidong02@gmail.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit f0a83d0a4b7c127d32ac06d607a9214937716129 Author: Vahagn Vardanian Date: Wed Feb 25 14:06:18 2026 +0100 netfilter: nf_conntrack_h323: fix OOB read in decode_choice() [ Upstream commit baed0d9ba91d4f390da12d5039128ee897253d60 ] In decode_choice(), the boundary check before get_len() uses the variable `len`, which is still 0 from its initialization at the top of the function: unsigned int type, ext, len = 0; ... if (ext || (son->attr & OPEN)) { BYTE_ALIGN(bs); if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */ return H323_ERROR_BOUND; len = get_len(bs); /* OOB read */ When the bitstream is exactly consumed (bs->cur == bs->end), the check nf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent get_len() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well. This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nf_conntrack_h323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer. Fix this by checking for 2 bytes (the maximum that get_len() may read) instead of the uninitialized `len`. This matches the pattern used at every other get_len() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len(). Fixes: ec8a8f3c31dd ("netfilter: nf_ct_h323: Extend nf_h323_error_boundary to work on bits as well") Signed-off-by: Vahagn Vardanian Signed-off-by: Florian Westphal Link: https://patch.msgid.link/20260225130619.1248-2-fw@strlen.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 89764cf44544e943230f5e03b8c40a90da26537c Author: Junrui Luo Date: Tue Feb 24 19:05:56 2026 +0800 dpaa2-switch: validate num_ifs to prevent out-of-bounds write [ Upstream commit 8a5752c6dcc085a3bfc78589925182e4e98468c5 ] The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes() but never validates it against DPSW_MAX_IF (64). This value controls iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices into the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reports num_ifs >= 64, the loop can write past the array bounds. Add a bound check for num_ifs in dpaa2_switch_init(). dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all ports match the flood filter, the loop fills all 64 slots and the control interface write overflows by one entry. The check uses >= because num_ifs == DPSW_MAX_IF is also functionally broken. build_if_id_bitmap() silently drops any ID >= 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |= ... Fixes: 539dda3c5d19 ("staging: dpaa2-switch: properly setup switching domains") Signed-off-by: Junrui Luo Reviewed-by: Ioana Ciornei Link: https://patch.msgid.link/SYBPR01MB78812B47B7F0470B617C408AAF74A@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4cb163e9efcac4cd35c3043e097f25081a5c015c Author: Jakub Kicinski Date: Mon Feb 23 15:51:00 2026 -0800 net: consume xmit errors of GSO frames [ Upstream commit 7aa767d0d3d04e50ae94e770db7db8197f666970 ] udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min. These tests use veth to simulate GRO. They attach a trivial ("return XDP_PASS;") XDP program to the veth to force TSO off and NAPI on. Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]). In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck. The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok | ok ok ok \\ snd_nxt "x" means packet lost by veth, and "ok" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent. So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above). Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely. We have multiple ways to fix this. 1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great. 2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer. 3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss? 4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-"networks" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix? Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link). Link: https://lore.kernel.org/CANn89iJcLepEin7EtBETrZ36bjoD9LrR=k4cfwWh046GB+4f9A@mail.gmail.com Fixes: 1f59533f9ca5 ("qdisc: validate frames going through the direct_xmit path") Signed-off-by: Jakub Kicinski Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260223235100.108939-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 57957bc7f1865778ec9b1618e15515feb6df7eb4 Author: Jianbo Liu Date: Tue Feb 24 13:46:52 2026 +0200 net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query [ Upstream commit 859380694f434597407632c29f30fdb5e763e6cc ] Fix a "scheduling while atomic" bug in mlx5e_ipsec_init_macs() by replacing mlx5_query_mac_address() with ether_addr_copy() to get the local MAC address directly from netdev->dev_addr. The issue occurs because mlx5_query_mac_address() queries the hardware which involves mlx5_cmd_exec() that can sleep, but it is called from the mlx5e_ipsec_handle_event workqueue which runs in atomic context. The MAC address is already available in netdev->dev_addr, so no need to query hardware. This avoids the sleeping call and resolves the bug. Call trace: BUG: scheduling while atomic: kworker/u112:2/69344/0x00000200 __schedule+0x7ab/0xa20 schedule+0x1c/0xb0 schedule_timeout+0x6e/0xf0 __wait_for_common+0x91/0x1b0 cmd_exec+0xa85/0xff0 [mlx5_core] mlx5_cmd_exec+0x1f/0x50 [mlx5_core] mlx5_query_nic_vport_mac_address+0x7b/0xd0 [mlx5_core] mlx5_query_mac_address+0x19/0x30 [mlx5_core] mlx5e_ipsec_init_macs+0xc1/0x720 [mlx5_core] mlx5e_ipsec_build_accel_xfrm_attrs+0x422/0x670 [mlx5_core] mlx5e_ipsec_handle_event+0x2b9/0x460 [mlx5_core] process_one_work+0x178/0x2e0 worker_thread+0x2ea/0x430 Fixes: cee137a63431 ("net/mlx5e: Handle ESN update events") Signed-off-by: Jianbo Liu Reviewed-by: Leon Romanovsky Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260224114652.1787431-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f72f646a555247c4005a2c7c7e9cdc693c540b7b Author: Shay Drory Date: Tue Feb 24 13:46:51 2026 +0200 net/mlx5: Fix missing devlink lock in SRIOV enable error path [ Upstream commit 60253042c0b87b61596368489c44d12ba720d11c ] The cited commit miss to add locking in the error path of mlx5_sriov_enable(). When pci_enable_sriov() fails, mlx5_device_disable_sriov() is called to clean up. This cleanup function now expects to be called with the devlink instance lock held. Add the missing devl_lock(devlink) and devl_unlock(devlink) Fixes: 84a433a40d0e ("net/mlx5: Lock mlx5 devlink reload callbacks") Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260224114652.1787431-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5226e227271a2049172dfb2ae7e2fea9e0a9b5db Author: Shay Drory Date: Tue Feb 24 13:46:50 2026 +0200 net/mlx5: E-switch, Clear legacy flag when moving to switchdev [ Upstream commit d7073e8b978ae925f1f0f08754f33f84d8547ea7 ] The cited commit introduced MLX5_PRIV_FLAGS_SWITCH_LEGACY to identify when a transition to legacy mode is requested via devlink. However, the logic failed to clear this flag if the mode was subsequently changed back to MLX5_ESWITCH_OFFLOADS (switchdev). Consequently, if a user toggled from legacy to switchdev, the flag remained set, leaving the driver with wrong state indicating Fix this by explicitly clearing the MLX5_PRIV_FLAGS_SWITCH_LEGACY bit when the requested mode is MLX5_ESWITCH_OFFLOADS. Fixes: 2a4f56fbcc47 ("net/mlx5e: Keep netdev when leave switchdev for devlink set legacy only") Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260224114652.1787431-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f0ed27a3315f70ef4740c4f761bf5f9573b90ecf Author: Shay Drory Date: Tue Feb 24 13:46:49 2026 +0200 net/mlx5: LAG, disable MPESW in lag_disable_change() [ Upstream commit bd7b9f83fb9f85228c3ac9748d9cba9fab7fb5a2 ] mlx5_lag_disable_change() unconditionally called mlx5_disable_lag() when LAG was active, which is incorrect for MLX5_LAG_MODE_MPESW. Hnece, call mlx5_disable_mpesw() when running in MPESW mode. Fixes: a32327a3a02c ("net/mlx5: Lag, Control MultiPort E-Switch single FDB mode") Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260224114652.1787431-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 858914d1ad190f1b3535c816cbaebb22d1887065 Author: Shay Drory Date: Tue Feb 24 13:46:48 2026 +0200 net/mlx5: DR, Fix circular locking dependency in dump [ Upstream commit 2700b7e603af39ca55fe9fc876ca123efd44680f ] Fix a circular locking dependency between dbg_mutex and the domain rx/tx mutexes that could lead to a deadlock. The dump path in dr_dump_domain_all() was acquiring locks in the order: dbg_mutex -> rx.mutex -> tx.mutex While the table/matcher creation paths acquire locks in the order: rx.mutex -> tx.mutex -> dbg_mutex This inverted lock ordering creates a circular dependency. Fix this by changing dr_dump_domain_all() to acquire the domain lock before dbg_mutex, matching the order used in mlx5dr_table_create() and mlx5dr_matcher_create(). Lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 6.19.0-rc6net_next_e817c4e #1 Not tainted ------------------------------------------------------ sos/30721 is trying to acquire lock: ffff888102df5900 (&dmn->info.rx.mutex){+.+.}-{4:4}, at: dr_dump_start+0x131/0x450 [mlx5_core] but task is already holding lock: ffff888102df5bc0 (&dmn->dump_info.dbg_mutex){+.+.}-{4:4}, at: dr_dump_start+0x10b/0x450 [mlx5_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&dmn->dump_info.dbg_mutex){+.+.}-{4:4}: __mutex_lock+0x91/0x1060 mlx5dr_matcher_create+0x377/0x5e0 [mlx5_core] mlx5_cmd_dr_create_flow_group+0x62/0xd0 [mlx5_core] mlx5_create_flow_group+0x113/0x1c0 [mlx5_core] mlx5_chains_create_prio+0x453/0x2290 [mlx5_core] mlx5_chains_get_table+0x2e2/0x980 [mlx5_core] esw_chains_create+0x1e6/0x3b0 [mlx5_core] esw_create_offloads_fdb_tables.cold+0x62/0x63f [mlx5_core] esw_offloads_enable+0x76f/0xd20 [mlx5_core] mlx5_eswitch_enable_locked+0x35a/0x500 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x561/0x950 [mlx5_core] devlink_nl_eswitch_set_doit+0x67/0xe0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x188/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x1ed/0x2c0 netlink_sendmsg+0x210/0x450 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x70/0xd00 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #1 (&dmn->info.tx.mutex){+.+.}-{4:4}: __mutex_lock+0x91/0x1060 mlx5dr_table_create+0x11d/0x530 [mlx5_core] mlx5_cmd_dr_create_flow_table+0x62/0x140 [mlx5_core] __mlx5_create_flow_table+0x46f/0x960 [mlx5_core] mlx5_create_flow_table+0x16/0x20 [mlx5_core] esw_create_offloads_fdb_tables+0x136/0x240 [mlx5_core] esw_offloads_enable+0x76f/0xd20 [mlx5_core] mlx5_eswitch_enable_locked+0x35a/0x500 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x561/0x950 [mlx5_core] devlink_nl_eswitch_set_doit+0x67/0xe0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x188/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x1ed/0x2c0 netlink_sendmsg+0x210/0x450 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x70/0xd00 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #0 (&dmn->info.rx.mutex){+.+.}-{4:4}: __lock_acquire+0x18b6/0x2eb0 lock_acquire+0xd3/0x2c0 __mutex_lock+0x91/0x1060 dr_dump_start+0x131/0x450 [mlx5_core] seq_read_iter+0xe3/0x410 seq_read+0xfb/0x130 full_proxy_read+0x53/0x80 vfs_read+0xba/0x330 ksys_read+0x65/0xe0 do_syscall_64+0x70/0xd00 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dmn->dump_info.dbg_mutex); lock(&dmn->info.tx.mutex); lock(&dmn->dump_info.dbg_mutex); lock(&dmn->info.rx.mutex); *** DEADLOCK *** Fixes: 9222f0b27da2 ("net/mlx5: DR, Add support for dumping steering info") Signed-off-by: Shay Drory Reviewed-by: Yevgeny Kliteynik Reviewed-by: Alex Vesker Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260224114652.1787431-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bce42728ac4887060a24a585c5122fbd24939db7 Author: Tetsuo Handa Date: Tue Feb 24 14:57:08 2026 +0200 team: avoid NETDEV_CHANGEMTU event when unregistering slave [ Upstream commit bb4c698633c0e19717586a6524a33196cff01a32 ] syzbot is reporting unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 3 ref_tracker: netdev@ffff88807dcf8618 has 1/2 users at __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline] netdev_hold include/linux/netdevice.h:4429 [inline] inetdev_init+0x201/0x4e0 net/ipv4/devinet.c:286 inetdev_event+0x251/0x1610 net/ipv4/devinet.c:1600 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_mtu net/core/dev.c:2318 [inline] netif_set_mtu_ext+0x5aa/0x800 net/core/dev.c:9886 netif_set_mtu+0xd7/0x1b0 net/core/dev.c:9907 dev_set_mtu+0x126/0x260 net/core/dev_api.c:248 team_port_del+0xb07/0xcb0 drivers/net/team/team_core.c:1333 team_del_slave drivers/net/team/team_core.c:1936 [inline] team_device_event+0x207/0x5b0 drivers/net/team/team_core.c:2929 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2281 [inline] call_netdevice_notifiers net/core/dev.c:2295 [inline] __dev_change_net_namespace+0xcb7/0x2050 net/core/dev.c:12592 do_setlink+0x2ce/0x4590 net/core/rtnetlink.c:3060 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x15a9/0x1be0 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894 problem. Ido Schimmel found steps to reproduce ip link add name team1 type team ip link add name dummy1 mtu 1499 master team1 type dummy ip netns add ns1 ip link set dev dummy1 netns ns1 ip -n ns1 link del dev dummy1 and also found that the same issue was fixed in the bond driver in commit f51048c3e07b ("bonding: avoid NETDEV_CHANGEMTU event when unregistering slave"). Let's do similar thing for the team driver, with commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations") and commit 303a8487a657 ("net: s/__dev_set_mtu/__netif_set_mtu/") also applied. Reported-by: syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 Suggested-by: Ido Schimmel Reviewed-by: Jiri Pirko Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") Signed-off-by: Tetsuo Handa Signed-off-by: Ido Schimmel Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20260224125709.317574-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 54a7013aa13fc0ae7444ded36dee2ff47c74c741 Author: Hangbin Liu Date: Fri Oct 17 03:41:54 2025 +0000 team: use common function to compute the features [ Upstream commit 745cd46c2a47144dd656185b9be0a1e5e9b02d2d ] Use the new helper netdev_compute_master_upper_features() to compute the team device features. This helper performs both the feature computation and the netdev_change_features() call. Note that such change replace the lower layer traversing currently done using team->port_list with netdev_for_each_lower_dev(). Such change is safe as `port_list` contains exactly the same elements as `team->dev->adj_list.lower` and the helper is always invoked under the RTNL lock. With this change, the explicit netdev_change_features() in team_add_slave() can be safely removed, as team_port_add() already takes care of the notification via netdev_compute_master_upper_features(), and same thing for team_del_slave() This also fixes missing computations for MPLS, XFRM, and TSO/GSO partial features. Signed-off-by: Hangbin Liu Reviewed-by: Sabrina Dubroca Reviewed-by: Jiri Pirko Link: https://patch.msgid.link/20251017034155.61990-4-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: bb4c698633c0 ("team: avoid NETDEV_CHANGEMTU event when unregistering slave") Signed-off-by: Sasha Levin commit 26924d2fdec2c7243d9143734c576d7956bd15b5 Author: Hangbin Liu Date: Fri Oct 17 03:41:52 2025 +0000 net: add a common function to compute features for upper devices [ Upstream commit 28098defc79fe7d29e6bfe4eb6312991f6bdc3d3 ] Some high level software drivers need to compute features from lower devices. But each has their own implementations and may lost some feature compute. Let's use one common function to compute features for kinds of these devices. The new helper uses the current bond implementation as the reference one, as the latter already handles all the relevant aspects: netdev features, TSO limits and dst retention. Suggested-by: Paolo Abeni Signed-off-by: Hangbin Liu Reviewed-by: Sabrina Dubroca Reviewed-by: Jiri Pirko Link: https://patch.msgid.link/20251017034155.61990-2-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: bb4c698633c0 ("team: avoid NETDEV_CHANGEMTU event when unregistering slave") Signed-off-by: Sasha Levin commit fa3c2f8d9152344a478abb847081c1b5f84a94f5 Author: Dipayaan Roy Date: Tue Feb 24 04:38:36 2026 -0800 net: mana: Fix double destroy_workqueue on service rescan PCI path [ Upstream commit f975a0955276579e2176a134366ed586071c7c6a ] While testing corner cases in the driver, a use-after-free crash was found on the service rescan PCI path. When mana_serv_reset() calls mana_gd_suspend(), mana_gd_cleanup() destroys gc->service_wq. If the subsequent mana_gd_resume() fails with -ETIMEDOUT or -EPROTO, the code falls through to mana_serv_rescan() which triggers pci_stop_and_remove_bus_device(). This invokes the PCI .remove callback (mana_gd_remove), which calls mana_gd_cleanup() a second time, attempting to destroy the already- freed workqueue. Fix this by NULL-checking gc->service_wq in mana_gd_cleanup() and setting it to NULL after destruction. Call stack of issue for reference: [Sat Feb 21 18:53:48 2026] Call Trace: [Sat Feb 21 18:53:48 2026] [Sat Feb 21 18:53:48 2026] mana_gd_cleanup+0x33/0x70 [mana] [Sat Feb 21 18:53:48 2026] mana_gd_remove+0x3a/0xc0 [mana] [Sat Feb 21 18:53:48 2026] pci_device_remove+0x41/0xb0 [Sat Feb 21 18:53:48 2026] device_remove+0x46/0x70 [Sat Feb 21 18:53:48 2026] device_release_driver_internal+0x1e3/0x250 [Sat Feb 21 18:53:48 2026] device_release_driver+0x12/0x20 [Sat Feb 21 18:53:48 2026] pci_stop_bus_device+0x6a/0x90 [Sat Feb 21 18:53:48 2026] pci_stop_and_remove_bus_device+0x13/0x30 [Sat Feb 21 18:53:48 2026] mana_do_service+0x180/0x290 [mana] [Sat Feb 21 18:53:48 2026] mana_serv_func+0x24/0x50 [mana] [Sat Feb 21 18:53:48 2026] process_one_work+0x190/0x3d0 [Sat Feb 21 18:53:48 2026] worker_thread+0x16e/0x2e0 [Sat Feb 21 18:53:48 2026] kthread+0xf7/0x130 [Sat Feb 21 18:53:48 2026] ? __pfx_worker_thread+0x10/0x10 [Sat Feb 21 18:53:48 2026] ? __pfx_kthread+0x10/0x10 [Sat Feb 21 18:53:48 2026] ret_from_fork+0x269/0x350 [Sat Feb 21 18:53:48 2026] ? __pfx_kthread+0x10/0x10 [Sat Feb 21 18:53:48 2026] ret_from_fork_asm+0x1a/0x30 [Sat Feb 21 18:53:48 2026] Fixes: 505cc26bcae0 ("net: mana: Add support for auxiliary device servicing events") Reviewed-by: Haiyang Zhang Signed-off-by: Dipayaan Roy Reviewed-by: Simon Horman Link: https://patch.msgid.link/aZ2bzL64NagfyHpg@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f8a06d562638bc3b7b5c8382db0c965a526be7a9 Author: Felix Gu Date: Tue Feb 24 19:04:04 2026 +0800 dpll: zl3073x: Remove redundant cleanup in devm_dpll_init() [ Upstream commit 676c7af91fcd740d34e7cb788cbc58e3bcafde39 ] The devm_add_action_or_reset() function already executes the cleanup action on failure before returning an error, so the explicit goto error and subsequent zl3073x_dev_dpll_fini() call causes double cleanup. Fixes: ebb1031c5137 ("dpll: zl3073x: Refactor DPLL initialization") Reviewed-by: Ivan Vecera Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260224-dpll-v2-1-d7786414a830@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 900be42c53cd9247a7e5df4b53dc64ebe8a9fac3 Author: Simon Baatz Date: Tue Feb 24 09:20:12 2026 +0100 tcp: re-enable acceptance of FIN packets when RWIN is 0 [ Upstream commit 1e3bb184e94125bae7c1703472109a646d0f79d9 ] Commit 2bd99aef1b19 ("tcp: accept bare FIN packets under memory pressure") allowed accepting FIN packets in tcp_data_queue() even when the receive window was closed, to prevent ACK/FIN loops with broken clients. Such a FIN packet is in sequence, but because the FIN consumes a sequence number, it extends beyond the window. Before commit 9ca48d616ed7 ("tcp: do not accept packets beyond window"), tcp_sequence() only required the seq to be within the window. After that change, the entire packet (including the FIN) must fit within the window. As a result, such FIN packets are now dropped and the handling path is no longer reached. Be more lenient by not counting the sequence number consumed by the FIN when calling tcp_sequence(), restoring the previous behavior for cases where only the FIN extends beyond the window. Fixes: 9ca48d616ed7 ("tcp: do not accept packets beyond window") Signed-off-by: Simon Baatz Reviewed-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260224-fix_zero_wnd_fin-v2-1-a16677ea7cea@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d3e32e2f3262f1b25d77c085ace38e2cc4ad75cf Author: Jacob Moroni Date: Tue Feb 24 23:41:53 2026 +0000 RDMA/umem: Fix double dma_buf_unpin in failure path [ Upstream commit 104016eb671e19709721c1b0048dd912dc2e96be ] In ib_umem_dmabuf_get_pinned_with_dma_device(), the call to ib_umem_dmabuf_map_pages() can fail. If this occurs, the dmabuf is immediately unpinned but the umem_dmabuf->pinned flag is still set. Then, when ib_umem_release() is called, it calls ib_umem_dmabuf_revoke() which will call dma_buf_unpin() again. Fix this by removing the immediate unpin upon failure and just let the ib_umem_release/revoke path handle it. This also ensures the proper unmap-unpin unwind ordering if the dmabuf_map_pages call happened to fail due to dma_resv_wait_timeout (and therefore has a non-NULL umem_dmabuf->sgt). Fixes: 1e4df4a21c5a ("RDMA/umem: Allow pinned dmabuf umem usage") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260224234153.1207849-1-jmoroni@google.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9d5a97bc71ed5783687705c708454c4453aa91d1 Author: Gao Xiang Date: Tue Feb 24 18:31:25 2026 +0800 erofs: fix interlaced plain identification for encoded extents [ Upstream commit 4a2d046e4b13202a6301a993961f5b30ae4d7119 ] Only plain data whose start position and on-disk physical length are both aligned to the block size should be classified as interlaced plain extents. Otherwise, it must be treated as shifted plain extents. This issue was found by syzbot using a crafted compressed image containing plain extents with unaligned physical lengths, which can cause OOB read in z_erofs_transform_plain(). Reported-and-tested-by: syzbot+d988dc155e740d76a331@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/699d5714.050a0220.cdd3c.03e7.GAE@google.com Fixes: 1d191b4ca51d ("erofs: implement encoded extent metadata") Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit d2e7c898cc02dfe42443489a67a45ed616cb76e9 Author: Ziyi Guo Date: Sun Feb 22 05:06:33 2026 +0000 net: usb: pegasus: enable basic endpoint checking [ Upstream commit 3d7e6ce34f4fcc7083510c28b17a7c36462a25d4 ] pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors: - usb_rcvbulkpipe(dev, 1) for RX data - usb_sndbulkpipe(dev, 2) for TX data - usb_rcvintpipe(dev, 3) for status interrupts A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes. Add a pegasus_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion. Similar fix to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") - commit 9e7021d2aeae ("net: usb: catc: enable basic endpoint checking") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ziyi Guo Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260222050633.410165-1-n7l8m4@u.northwestern.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f3e4cceafad27c9363c33622732f86722846ec6f Author: Sebastian Andrzej Siewior Date: Fri Feb 20 19:38:58 2026 +0100 net: Drop the lock in skb_may_tx_timestamp() [ Upstream commit 983512f3a87fd8dc4c94dfa6b596b6e57df5aad7 ] skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared. Link: https://lore.kernel.org/all/20260205145104.iWinkXHv@linutronix.de Fixes: b245be1f4db1a ("net-timestamp: no-payload only sysctl") Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Willem de Bruijn Reviewed-by: Jason Xing Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260220183858.N4ERjFW6@linutronix.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9bc0bca26418a5b38b18bf35fc2b675bf0dfa400 Author: Jason Gunthorpe Date: Mon Feb 16 11:02:47 2026 -0400 RDMA/efa: Fix typo in efa_alloc_mr() [ Upstream commit f22c77ce49db0589103d96487dca56f5b2136362 ] The pattern is to check the entire driver request space, not just sizeof something unrelated. Fixes: 40909f664d27 ("RDMA/efa: Add EFA verbs implementation") Signed-off-by: Jason Gunthorpe Link: https://patch.msgid.link/1-v1-83e918d69e73+a9-rdma_udata_rc_jgg@nvidia.com Acked-by: Michael Margolin Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 2b96156c927cd83c109e2e3946e6111dce73231f Author: Kamal Heib Date: Fri Feb 20 17:21:26 2026 -0500 RDMA/ionic: Fix potential NULL pointer dereference in ionic_query_port [ Upstream commit fd80bd7105f88189f47d465ca8cb7d115570de30 ] The function ionic_query_port() calls ib_device_get_netdev() without checking the return value which could lead to NULL pointer dereference, Fix it by checking the return value and return -ENODEV if the 'ndev' is NULL. Fixes: 2075bbe8ef03 ("RDMA/ionic: Register device ops for miscellaneous functionality") Signed-off-by: Kamal Heib Link: https://patch.msgid.link/20260220222125.16973-2-kheib@redhat.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 3126a2f98beaec5a554a1fb31c46db1e8542665e Author: Jakub Kicinski Date: Thu Feb 19 11:50:21 2026 -0800 netconsole: avoid OOB reads, msg is not nul-terminated [ Upstream commit 82aec772fca2223bc5774bd9af486fd95766e578 ] msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 ("netconsole: convert to NBCON console infrastructure") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00) Fixes: c62c0a17f9b7 ("netconsole: Append kernel version to message") Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260219195021.2099699-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 21d341fe514fd07e345ed264c9eee21cb2061ca2 Author: Duoming Zhou Date: Thu Feb 19 20:46:37 2026 +0800 net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets [ Upstream commit bae8a5d2e759da2e0cba33ab2080deee96a09373 ] When the FarSync T-series card is being detached, the fst_card_info is deallocated in fst_remove_one(). However, the fst_tx_task or fst_int_task may still be running or pending, leading to use-after-free bugs when the already freed fst_card_info is accessed in fst_process_tx_work_q() or fst_process_int_work_q(). A typical race condition is depicted below: CPU 0 (cleanup) | CPU 1 (tasklet) | fst_start_xmit() fst_remove_one() | tasklet_schedule() unregister_hdlc_device()| | fst_process_tx_work_q() //handler kfree(card) //free | do_bottom_half_tx() | card-> //use The following KASAN trace was captured: ================================================================== BUG: KASAN: slab-use-after-free in do_bottom_half_tx+0xb88/0xd00 Read of size 4 at addr ffff88800aad101c by task ksoftirqd/3/32 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcb/0x5d0 ? do_bottom_half_tx+0xb88/0xd00 kasan_report+0xb8/0xf0 ? do_bottom_half_tx+0xb88/0xd00 do_bottom_half_tx+0xb88/0xd00 ? _raw_spin_lock_irqsave+0x85/0xe0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx___hrtimer_run_queues+0x10/0x10 fst_process_tx_work_q+0x67/0x90 tasklet_action_common+0x1fa/0x720 ? hrtimer_interrupt+0x31f/0x780 handle_softirqs+0x176/0x530 __irq_exit_rcu+0xab/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 41 on cpu 3 at 72.330843s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 __kasan_kmalloc+0x7f/0x90 fst_add_one+0x1a5/0x1cd0 local_pci_probe+0xdd/0x190 pci_device_probe+0x341/0x480 really_probe+0x1c6/0x6a0 __driver_probe_device+0x248/0x310 driver_probe_device+0x48/0x210 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x101/0x190 __device_attach+0x198/0x3a0 device_initial_probe+0x78/0xa0 pci_bus_add_device+0x81/0xc0 pci_bus_add_devices+0x7e/0x190 enable_slot+0x9b9/0x1130 acpiphp_check_bridge.part.0+0x2e1/0x460 acpiphp_hotplug_notify+0x36c/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... Freed by task 41 on cpu 1 at 75.138639s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x135/0x410 fst_remove_one+0x2ca/0x540 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0x364/0x530 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device+0xd/0x20 disable_slot+0x116/0x260 acpiphp_disable_and_eject_slot+0x4b/0x190 acpiphp_hotplug_notify+0x230/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... The buggy address belongs to the object at ffff88800aad1000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 28 bytes inside of freed 1024-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xaad0 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x100000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000003 ffffea00002ab401 00000000ffffffff 00000000ffffffff head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88800aad0f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800aad0f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800aad1000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88800aad1080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88800aad1100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Fix this by ensuring that both fst_tx_task and fst_int_task are properly canceled before the fst_card_info is released. Add tasklet_kill() in fst_remove_one() to synchronize with any pending or running tasklets. Since unregister_hdlc_device() stops data transmission and reception, and fst_disable_intr() prevents further interrupts, it is appropriate to place tasklet_kill() after these calls. The bugs were identified through static analysis. To reproduce the issue and validate the fix, a FarSync T-series card was simulated in QEMU and delays(e.g., mdelay()) were introduced within the tasklet handler to increase the likelihood of triggering the race condition. Fixes: 2f623aaf9f31 ("net: farsync: Fix kmemleak when rmmods farsync") Signed-off-by: Duoming Zhou Reviewed-by: Jijie Shao Link: https://patch.msgid.link/20260219124637.72578-1-duoming@zju.edu.cn Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e57d397bffaba8e459e8f6a1fcb77c94bc1a96a6 Author: Jiri Pirko Date: Tue Jan 27 10:38:39 2026 +0100 RDMA/core: Fix stale RoCE GIDs during netdev events at registration [ Upstream commit 9af0feae8016ba58ad7ff784a903404986b395b1 ] RoCE GID entries become stale when netdev properties change during the IB device registration window. This is reproducible with a udev rule that sets a MAC address when a VF netdev appears: ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth4", \ RUN+="/sbin/ip link set eth4 address 88:22:33:44:55:66" After VF creation, show_gids displays GIDs derived from the original random MAC rather than the configured one. The root cause is a race between netdev event processing and device registration: CPU 0 (driver) CPU 1 (udev/workqueue) ────────────── ────────────────────── ib_register_device() ib_cache_setup_one() gid_table_setup_one() _gid_table_setup_one() ← GID table allocated rdma_roce_rescan_device() ← GIDs populated with OLD MAC ip link set eth4 addr NEW_MAC NETDEV_CHANGEADDR queued netdevice_event_work_handler() ib_enum_all_roce_netdevs() ← Iterates DEVICE_REGISTERED ← Device NOT marked yet, SKIP! enable_device_and_get() xa_set_mark(DEVICE_REGISTERED) ← Too late, event was lost The netdev event handler uses ib_enum_all_roce_netdevs() which only iterates devices marked DEVICE_REGISTERED. However, this mark is set late in the registration process, after the GID cache is already populated. Events arriving in this window are silently dropped. Fix this by introducing a new xarray mark DEVICE_GID_UPDATES that is set immediately after the GID table is allocated and initialized. Use the new mark in ib_enum_all_roce_netdevs() function to iterate devices instead of DEVICE_REGISTERED. This is safe because: - After _gid_table_setup_one(), all required structures exist (port_data, immutable, cache.gid) - The GID table mutex serializes concurrent access between the initial rescan and event handlers - Event handlers correctly update stale GIDs even when racing with rescan - The mark is cleared in ib_cache_cleanup_one() before teardown This also fixes similar races for IP address events (inetaddr_event, inet6addr_event) which use the same enumeration path. Fixes: 0df91bb67334 ("RDMA/devices: Use xarray to store the client_data") Signed-off-by: Jiri Pirko Link: https://patch.msgid.link/20260127093839.126291-1-jiri@resnulli.us Reported-by: syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d8fc9f972fbdd16bb1271f86185d71d04b5671d2 Author: Tung Nguyen Date: Fri Feb 20 05:05:41 2026 +0000 tipc: fix duplicate publication key in tipc_service_insert_publ() [ Upstream commit 3aa677625c8fad39989496c51bcff3872c1f16f1 ] TIPC uses named table to store TIPC services represented by type and instance. Each time an application calls TIPC API bind() to bind a type/instance to a socket, an entry is created and inserted into the named table. It looks like this: named table: key1, entry1 (type, instance ...) key2, entry2 (type, instance ...) In the above table, each entry represents a route for sending data from one socket to the other. For all publications originated from the same node, the key is UNIQUE to identify each entry. It is calculated by this formula: key = socket portid + number of bindings + 1 (1) where: - socket portid: unique and calculated by using linux kernel function get_random_u32_below(). So, the value is randomized. - number of bindings: the number of times a type/instance pair is bound to a socket. This number is linearly increased, starting from 0. While the socket portid is unique and randomized by linux kernel, the linear increment of "number of bindings" in formula (1) makes "key" not unique anymore. For example: - Socket 1 is created with its associated port number 20062001. Type 1000, instance 1 is bound to socket 1: key1: 20062001 + 0 + 1 = 20062002 Then, bind() is called a second time on Socket 1 to by the same type 1000, instance 1: key2: 20062001 + 1 + 1 = 20062003 Named table: key1 (20062002), entry1 (1000, 1 ...) key2 (20062003), entry2 (1000, 1 ...) - Socket 2 is created with its associated port number 20062002. Type 1000, instance 1 is bound to socket 2: key3: 20062002 + 0 + 1 = 20062003 TIPC looks up the named table and finds out that key2 with the same value already exists and rejects the insertion into the named table. This leads to failure of bind() call from application on Socket 2 with error message EINVAL "Invalid argument". This commit fixes this issue by adding more port id checking to make sure that the key is unique to publications originated from the same port id and node. Fixes: 218527fe27ad ("tipc: replace name table service range array with rb tree") Signed-off-by: Tung Nguyen Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260220050541.237962-1-tung.quang.nguyen@est.tech Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9fc2e95fe54147a21280d01910ed653ae87f0fc7 Author: Ivan Vecera Date: Fri Feb 20 16:57:54 2026 +0100 dpll: zl3073x: fix REF_PHASE_OFFSET_COMP register width for some chip IDs [ Upstream commit 4cfe066a82cdf9e83e48b16000f55280efc98325 ] The REF_PHASE_OFFSET_COMP register is 48-bit wide on most zl3073x chip variants, but only 32-bit wide on chip IDs 0x0E30, 0x0E93..0x0E97 and 0x1F60. The driver unconditionally uses 48-bit read/write operations, which on 32-bit variants causes reading 2 bytes past the register boundary (corrupting the value) and writing 2 bytes into the adjacent register. Fix this by storing the chip ID in the device structure during probe and adding a helper to detect the affected variants. Use the correct register width for read/write operations and the matching sign extension bit (31 vs 47) when interpreting the phase compensation value. Fixes: 6287262f761e ("dpll: zl3073x: Add support to adjust phase") Signed-off-by: Ivan Vecera Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260220155755.448185-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b2acd29bd487806bc1ec96eb50651ed6be04d2e2 Author: Ivan Vecera Date: Thu Nov 13 08:41:03 2025 +0100 dpll: zl3073x: Cache all reference properties in zl3073x_ref [ Upstream commit 5bc02b190a3fb703bf8cadc4d778fc22cd4d1e78 ] Expand the zl3073x_ref structure to cache all reference-related hardware registers, including frequency components, embedded-sync settings and phase compensation. Previously, these registers were read on-demand from various functions in dpll.c leading to frequent mailbox operations. Modify zl3073x_ref_state_fetch() to read and populate all these new fields at once. Refactor all "getter" functions in dpll.c to read from this new cached state instead of performing direct register access. Remove the standalone zl3073x_dpll_input_ref_frequency_get() helper, as its functionality is now replaced by zl3073x_ref_freq_get() which operates on the cached state and add a corresponding zl3073x_dev_... wrapper. Introduce a new function, zl3073x_ref_state_set(), to handle writing changes back to the hardware. This function compares the provided state with the current cached state and writes *only* the modified register values to the device via a single mailbox sequence before updating the local cache. Refactor all dpll "setter" functions to modify a local copy of the ref state and then call zl3073x_ref_state_set() to commit the changes. As a cleanup, update callers in dpll.c that already have a struct zl3073x_ref * to use the direct helpers instead of the zl3073x_dev_... wrappers. This change centralizes all reference-related register I/O into ref.c, significantly reduces bus traffic, and simplifies the logic in dpll.c. Reviewed-by: Petr Oros Tested-by: Prathosh Satish Signed-off-by: Ivan Vecera Link: https://patch.msgid.link/20251113074105.141379-5-ivecera@redhat.com Signed-off-by: Jakub Kicinski Stable-dep-of: 4cfe066a82cd ("dpll: zl3073x: fix REF_PHASE_OFFSET_COMP register width for some chip IDs") Signed-off-by: Sasha Levin commit a4b086cc61e6bc43d4d158f1a799167dd10b507c Author: Ivan Vecera Date: Thu Nov 13 08:41:02 2025 +0100 dpll: zl3073x: Cache reference monitor status [ Upstream commit 5534a8202d7cf9b2e4557517745583c43662b6a8 ] Instead of reading the ZL_REG_REF_MON_STATUS register every time the reference status is needed, cache this value in the zl3073x_ref struct. This is achieved by: * Adding a mon_status field to struct zl3073x_ref * Introducing zl3073x_dev_ref_status_update() to read the status for all references into this new cache field * Calling this update function from the periodic work handler * Adding zl3073x_ref_is_status_ok() and zl3073x_dev_ref_is_status_ok() helpers to check the cached value * Refactoring all callers in dpll.c to use the new zl3073x_dev_ref_is_status_ok() helper, removing direct register reads This change consolidates all status register reads into a single periodic function and reduces I/O bus traffic in dpll callbacks. Reviewed-by: Petr Oros Tested-by: Prathosh Satish Signed-off-by: Ivan Vecera Link: https://patch.msgid.link/20251113074105.141379-4-ivecera@redhat.com Signed-off-by: Jakub Kicinski Stable-dep-of: 4cfe066a82cd ("dpll: zl3073x: fix REF_PHASE_OFFSET_COMP register width for some chip IDs") Signed-off-by: Sasha Levin commit b1e3edf688a88c1a3ac41657055d9c136a08cd25 Author: Jiayuan Chen Date: Thu Feb 19 09:42:51 2026 +0800 kcm: fix zero-frag skb in frag_list on partial sendmsg error [ Upstream commit ca220141fa8ebae09765a242076b2b77338106b0 ] Syzkaller reported a warning in kcm_write_msgs() when processing a message with a zero-fragment skb in the frag_list. When kcm_sendmsg() fills MAX_SKB_FRAGS fragments in the current skb, it allocates a new skb (tskb) and links it into the frag_list before copying data. If the copy subsequently fails (e.g. -EFAULT from user memory), tskb remains in the frag_list with zero fragments: head skb (msg being assembled, NOT yet in sk_write_queue) +-----------+ | frags[17] | (MAX_SKB_FRAGS, all filled with data) | frag_list-+--> tskb +-----------+ +----------+ | frags[0] | (empty! copy failed before filling) +----------+ For SOCK_SEQPACKET with partial data already copied, the error path saves this message via partial_message for later completion. For SOCK_SEQPACKET, sock_write_iter() automatically sets MSG_EOR, so a subsequent zero-length write(fd, NULL, 0) completes the message and queues it to sk_write_queue. kcm_write_msgs() then walks the frag_list and hits: WARN_ON(!skb_shinfo(skb)->nr_frags) TCP has a similar pattern where skbs are enqueued before data copy and cleaned up on failure via tcp_remove_empty_skb(). KCM was missing the equivalent cleanup. Fix this by tracking the predecessor skb (frag_prev) when allocating a new frag_list entry. On error, if the tail skb has zero frags, use frag_prev to unlink and free it in O(1) without walking the singly-linked frag_list. frag_prev is safe to dereference because the entire message chain is only held locally (or in kcm->seq_skb) and is not added to sk_write_queue until MSG_EOR, so the send path cannot free it underneath us. Also change the WARN_ON to WARN_ON_ONCE to avoid flooding the log if the condition is somehow hit repeatedly. There are currently no KCM selftests in the kernel tree; a simple reproducer is available at [1]. [1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa Reported-by: syzbot+52624bdfbf2746d37d70@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000269a1405a12fdc77@google.com/T/ Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260219014256.370092-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 854cd32bc74fe573353095e90958490e4e4d641b Author: Hyunwoo Kim Date: Fri Feb 20 18:40:36 2026 +0900 tls: Fix race condition in tls_sw_cancel_work_tx() [ Upstream commit 7bb09315f93dce6acc54bf59e5a95ba7365c2be4 ] This issue was discovered during a code audit. After cancel_delayed_work_sync() is called from tls_sk_proto_close(), tx_work_handler() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the tx_work_handler() worker may dereference a freed TLS object. The following is a simple race scenario: cpu0 cpu1 tls_sk_proto_close() tls_sw_cancel_work_tx() tls_write_space() tls_sw_write_space() if (!test_and_set_bit(BIT_TX_SCHEDULED, &tx_ctx->tx_bitmask)) set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask); cancel_delayed_work_sync(&ctx->tx_work.work); schedule_delayed_work(&tx_ctx->tx_work.work, 0); To prevent this race condition, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync(). Fixes: f87e62d45e51 ("net/tls: remove close callback sock unlock/lock around TX work flush") Signed-off-by: Hyunwoo Kim Reviewed-by: Simon Horman Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/aZgsFO6nfylfvLE7@v4bel Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5455a232edea6b946b99449f15ca771a8874a5a6 Author: Eric Dumazet Date: Fri Feb 20 22:26:05 2026 +0000 net: do not pass flow_id to set_rps_cpu() [ Upstream commit 8a8a9fac9efa6423fd74938b940cb7d731780718 ] Blamed commit made the assumption that the RPS table for each receive queue would have the same size, and that it would not change. Compute flow_id in set_rps_cpu(), do not assume we can use the value computed by get_rps_cpu(). Otherwise we risk out-of-bound access and/or crashes. Fixes: 48aa30443e52 ("net: Cache hash and flow_id to avoid recalculation") Signed-off-by: Eric Dumazet Cc: Krishna Kumar Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260220222605.3468081-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 96581749c7c14fbec32c35728520867929600041 Author: Luiz Augusto von Dentz Date: Fri Feb 13 13:33:33 2026 -0500 Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ [ Upstream commit 138d7eca445ef37a0333425d269ee59900ca1104 ] This adds a check for encryption key size upon receiving L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAP_CR_LE_BAD_KEY_SIZE. Link: https://lore.kernel.org/linux-bluetooth/5782243.rdbgypaU67@n9w6sw14/ Fixes: 27e2d4c8d28b ("Bluetooth: Add basic LE L2CAP connect request receiving support") Signed-off-by: Luiz Augusto von Dentz Tested-by: Christian Eggers Signed-off-by: Sasha Levin commit 3a954c75b1cda46e6123d38093c241faabb2319e Author: Luiz Augusto von Dentz Date: Tue Feb 17 13:29:43 2026 -0500 Bluetooth: L2CAP: Fix not checking output MTU is acceptable on L2CAP_ECRED_CONN_REQ [ Upstream commit a8d1d73c81d1e70d2aa49fdaf59d933bb783ffe5 ] Upon receiving L2CAP_ECRED_CONN_REQ the given MTU shall be checked against the suggested MTU of the listening socket as that is required by the likes of PTS L2CAP/ECFC/BV-27-C test which expects L2CAP_CR_LE_UNACCEPT_PARAMS if the MTU is lowers than socket omtu. In order to be able to set chan->omtu the code now allows setting setsockopt(BT_SNDMTU), but it is only allowed when connection has not been stablished since there is no procedure to reconfigure the output MTU. Link: https://github.com/bluez/bluez/issues/1895 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 69dd2e85f8e831aca210d8b0c12aa6cdbc91051b Author: Luiz Augusto von Dentz Date: Wed Feb 11 15:18:03 2026 -0500 Bluetooth: L2CAP: Fix response to L2CAP_ECRED_CONN_REQ [ Upstream commit 05761c2c2b5bfec85c47f60c903c461e9b56cf87 ] Similar to 03dba9cea72f ("Bluetooth: L2CAP: Fix not responding with L2CAP_CR_LE_ENCRYPTION") the result code L2CAP_CR_LE_ENCRYPTION shall be used when BT_SECURITY_MEDIUM is set since that means security mode 2 which mean it doesn't require authentication which results in qualification test L2CAP/ECFC/BV-32-C failing. Link: https://github.com/bluez/bluez/issues/1871 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 49065204b95b8b1546deac4e547c2577c33bb19a Author: Jinwang Li Date: Thu Feb 5 14:26:00 2026 +0800 Bluetooth: hci_qca: Cleanup on all setup failures [ Upstream commit 5c4e9a8b18457ad28b57069ef0f14661e3192b2e ] The setup process previously combined error handling and retry gating under one condition. As a result, the final failed attempt exited without performing cleanup. Update the failure path to always perform power and port cleanup on setup failure, and reopen the port only when retrying. Fixes: 9e80587aba4c ("Bluetooth: hci_qca: Enhance retry logic in qca_setup") Signed-off-by: Jinwang Li Reviewed-by: Bartosz Golaszewski Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit e981a9392800ce2c5bca196a6ab2c55e9370efaa Author: Luiz Augusto von Dentz Date: Thu Feb 5 15:11:34 2026 -0500 Bluetooth: L2CAP: Fix result of L2CAP_ECRED_CONN_RSP when MTU is too short [ Upstream commit c28d2bff70444a85b3b86aaf241ece9408c7858c ] Test L2CAP/ECFC/BV-26-C expect the response to L2CAP_ECRED_CONN_REQ with and MTU value < L2CAP_ECRED_MIN_MTU (64) to be L2CAP_CR_LE_INVALID_PARAMS rather than L2CAP_CR_LE_UNACCEPT_PARAMS. Also fix not including the correct number of CIDs in the response since the spec requires all CIDs being rejected to be included in the response. Link: https://github.com/bluez/bluez/issues/1868 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7010201831df08bd7f20e12b944299000db7bd41 Author: Luiz Augusto von Dentz Date: Tue Feb 3 15:16:16 2026 -0500 Bluetooth: L2CAP: Fix invalid response to L2CAP_ECRED_RECONF_REQ [ Upstream commit 7accb1c4321acb617faf934af59d928b0b047e2b ] This fixes responding with an invalid result caused by checking the wrong size of CID which should have been (cmd_len - sizeof(*req)) and on top of it the wrong result was use L2CAP_CR_LE_INVALID_PARAMS which is invalid/reserved for reconf when running test like L2CAP/ECFC/BI-03-C: > ACL Data RX: Handle 64 flags 0x02 dlen 14 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 6 MTU: 64 MPS: 64 Source CID: 64 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reserved (0x000c) Result: Reconfiguration failed - one or more Destination CIDs invalid (0x0003) Fiix L2CAP/ECFC/BI-04-C which expects L2CAP_RECONF_INVALID_MPS (0x0002) when more than one channel gets its MPS reduced: > ACL Data RX: Handle 64 flags 0x02 dlen 16 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 8 MTU: 264 MPS: 99 Source CID: 64 ! Source CID: 65 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration successful (0x0000) Result: Reconfiguration failed - reduction in size of MPS not allowed for more than one channel at a time (0x0002) Fix L2CAP/ECFC/BI-05-C when SCID is invalid (85 unconnected): > ACL Data RX: Handle 64 flags 0x02 dlen 14 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 6 MTU: 65 MPS: 64 ! Source CID: 85 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration successful (0x0000) Result: Reconfiguration failed - one or more Destination CIDs invalid (0x0003) Fix L2CAP/ECFC/BI-06-C when MPS < L2CAP_ECRED_MIN_MPS (64): > ACL Data RX: Handle 64 flags 0x02 dlen 14 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 6 MTU: 672 ! MPS: 63 Source CID: 64 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration failed - reduction in size of MPS not allowed for more than one channel at a time (0x0002) Result: Reconfiguration failed - other unacceptable parameters (0x0004) Fix L2CAP/ECFC/BI-07-C when MPS reduced for more than one channel: > ACL Data RX: Handle 64 flags 0x02 dlen 16 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 3 len 8 MTU: 84 ! MPS: 71 Source CID: 64 ! Source CID: 65 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration successful (0x0000) Result: Reconfiguration failed - reduction in size of MPS not allowed for more than one channel at a time (0x0002) Link: https://github.com/bluez/bluez/issues/1865 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 25c3e0de3b46727553e2e199d7908da3abee5fdd Author: Linus Torvalds Date: Mon Feb 23 11:18:48 2026 -0800 Remove WARN_ALL_UNSEEDED_RANDOM kernel config option [ Upstream commit 7dff99b354601dd01829e1511711846e04340a69 ] This config option goes way back - it used to be an internal debug option to random.c (at that point called DEBUG_RANDOM_BOOT), then was renamed and exposed as a config option as CONFIG_WARN_UNSEEDED_RANDOM, and then further renamed to the current CONFIG_WARN_ALL_UNSEEDED_RANDOM. It was all done with the best of intentions: the more limited rate-limited reports were reporting some cases, but if you wanted to see all the gory details, you'd enable this "ALL" option. However, it turns out - perhaps not surprisingly - that when people don't care about and fix the first rate-limited cases, they most certainly don't care about any others either, and so warning about all of them isn't actually helping anything. And the non-ratelimited reporting causes problems, where well-meaning people enable debug options, but the excessive flood of messages that nobody cares about will hide actual real information when things go wrong. I just got a kernel bug report (which had nothing to do with randomness) where two thirds of the the truncated dmesg was just variations of random: get_random_u32 called from __get_random_u32_below+0x10/0x70 with crng_init=0 and in the process early boot messages had been lost (in addition to making the messages that _hadn't_ been lost harder to read). The proper way to find these things for the hypothetical developer that cares - if such a person exists - is almost certainly with boot time tracing. That gives you the option to get call graphs etc too, which is likely a requirement for fixing any problems anyway. See Documentation/trace/boottime-trace.rst for that option. And if we for some reason do want to re-introduce actual printing of these things, it will need to have some uniqueness filtering rather than this "just print it all" model. Fixes: cc1e127bfa95 ("random: remove ratelimiting for in-kernel unseeded randomness") Acked-by: Jason Donenfeld Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 64ccb0aac41c5055780c2a58bbe2c1b362ceccde Author: Marek Szyprowski Date: Tue Feb 3 11:21:33 2026 +0100 wifi: brcmfmac: Fix potential kernel oops when probe fails [ Upstream commit 243307a0d1b0d01538e202c00454c28b21d4432e ] When probe of the sdio brcmfmac device fails for some reasons (i.e. missing firmware), the sdiodev->bus is set to error instead of NULL, thus the cleanup later in brcmf_sdio_remove() tries to free resources via invalid bus pointer. This happens because sdiodev->bus is set 2 times: first in brcmf_sdio_probe() and second time in brcmf_sdiod_probe(). Fix this by chaning the brcmf_sdio_probe() function to return the error code and set sdio->bus only there. Fixes: 0ff0843310b7 ("wifi: brcmfmac: Add optional lpo clock enable support") Signed-off-by: Marek Szyprowski Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260203102133.1478331-1-m.szyprowski@samsung.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 3c87b7e64735c0f6211e06b0febb468da7819ec6 Author: Johannes Berg Date: Mon Feb 9 19:12:20 2026 +0100 wifi: cfg80211: wext: fix IGTK key ID off-by-one [ Upstream commit c8d7f21ead727485ebf965e2b4d42d4a4f0840f6 ] The IGTK key ID must be 4 or 5, but the code checks against key ID + 1, so must check against 5/6 rather than 4/5. Fix that. Reported-by: Jouni Malinen Fixes: 08645126dd24 ("cfg80211: implement wext key handling") Link: https://patch.msgid.link/20260209181220.362205-2-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 3e14ba8b95c974e69994eaf8bc1503fb32cfff8c Author: Jiri Pirko Date: Mon Feb 9 16:38:05 2026 +0100 dma-mapping: avoid random addr value print out on error path [ Upstream commit 47322c469d4a63ac45b705ca83680671ff71c975 ] dma_addr is unitialized in dma_direct_map_phys() when swiotlb is forced and DMA_ATTR_MMIO is set which leads to random value print out in warning. Fix that by just returning DMA_MAPPING_ERROR. Fixes: e53d29f957b3 ("dma-mapping: convert dma_direct_*map_page to be phys_addr_t based") Signed-off-by: Jiri Pirko Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260209153809.250835-2-jiri@resnulli.us Signed-off-by: Sasha Levin commit ceae058eb707ddd0d68f0872f9d9f23b7c30c37b Author: Nicholas Carlini Date: Thu Feb 19 20:58:57 2026 +0900 ksmbd: fix signededness bug in smb_direct_prepare_negotiation() [ Upstream commit 6b4f875aac344cdd52a1f34cc70ed2f874a65757 ] smb_direct_prepare_negotiation() casts an unsigned __u32 value from sp->max_recv_size and req->preferred_send_size to a signed int before computing min_t(int, ...). A maliciously provided preferred_send_size of 0x80000000 will return as smaller than max_recv_size, and then be used to set the maximum allowed alowed receive size for the next message. By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow. This fix replaces min_t(int, ...) with min_t(u32) Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Signed-off-by: Nicholas Carlini Reviewed-by: Stefan Metzmacher Acked-by: Stefan Metzmacher Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 0315bec883c67fa1413c61e504a28dc5bd02eb37 Author: Ralf Lici Date: Wed Feb 18 21:08:26 2026 +0100 ovpn: tcp - fix packet extraction from stream [ Upstream commit d4f687fbbce45b5e88438e89b5e26c0c15847992 ] When processing TCP stream data in ovpn_tcp_recv, we receive large cloned skbs from __strp_rcv that may contain multiple coalesced packets. The current implementation has two bugs: 1. Header offset overflow: Using pskb_pull with large offsets on coalesced skbs causes skb->data - skb->head to exceed the u16 storage of skb->network_header. This causes skb_reset_network_header to fail on the inner decapsulated packet, resulting in packet drops. 2. Unaligned protocol headers: Extracting packets from arbitrary positions within the coalesced TCP stream provides no alignment guarantees for the packet data causing performance penalties on architectures without efficient unaligned access. Additionally, openvpn's 2-byte length prefix on TCP packets causes the subsequent 4-byte opcode and packet ID fields to be inherently misaligned. Fix both issues by allocating a new skb for each openvpn packet and using skb_copy_bits to extract only the packet content into the new buffer, skipping the 2-byte length prefix. Also, check the length before invoking the function that performs the allocation to avoid creating an invalid skb. If the packet has to be forwarded to userspace the 2-byte prefix can be pushed to the head safely, without misalignment. As a side effect, this approach also avoids the expensive linearization that pskb_pull triggers on cloned skbs with page fragments. In testing, this resulted in TCP throughput improvements of up to 74%. Fixes: 11851cbd60ea ("ovpn: implement TCP transport") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli Reviewed-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8178567c6a97cd4bf4126ad26f1ef580970625d4 Author: Pavan Chebbi Date: Thu Feb 19 10:53:12 2026 -0800 bnxt_en: Fix deleting of Ntuple filters [ Upstream commit c1bbd9900d65ac65b9fce9f129e3369a04871570 ] Ntuple filters can be deleted when the interface is down. The current code blindly sends the filter delete command to FW. When the interface is down, all the VNICs are deleted in the FW. When the VNIC is freed in the FW, all the associated filters are also freed. We need not send the free command explicitly. Sending such command will generate FW error in the dmesg. In order to fix this, we can safely return from bnxt_hwrm_cfa_ntuple_filter_free() when BNXT_STATE_OPEN is not true which confirms the VNICs have been deleted. Fixes: 8336a974f37d ("bnxt_en: Save user configured filters in a lookup list") Suggested-by: Michael Chan Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Link: https://patch.msgid.link/20260219185313.2682148-3-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 079986d6db1f8e3d50c55f400cf998ac9690d2c8 Author: Pavan Chebbi Date: Thu Feb 19 10:53:11 2026 -0800 bnxt_en: Fix RSS context delete logic [ Upstream commit e123d9302d223767bd910bfbcfe607bae909f8ac ] We need to free the corresponding RSS context VNIC in FW everytime an RSS context is deleted in driver. Commit 667ac333dbb7 added a check to delete the VNIC in FW only when netif_running() is true to help delete RSS contexts with interface down. Having that condition will make the driver leak VNICs in FW whenever close() happens with active RSS contexts. On the subsequent open(), as part of RSS context restoration, we will end up trying to create extra VNICs for which we did not make any reservation. FW can fail this request, thereby making us lose active RSS contexts. Suppose an RSS context is deleted already and we try to process a delete request again, then the HWRM functions will check for validity of the request and they simply return if the resource is already freed. So, even for delete-when-down cases, netif_running() check is not necessary. Remove the netif_running() condition check when deleting an RSS context. Reported-by: Jakub Kicinski Fixes: 667ac333dbb7 ("eth: bnxt: allow deleting RSS contexts when the device is down") Reviewed-by: Andy Gospodarek Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Link: https://patch.msgid.link/20260219185313.2682148-2-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f27030ac5bef47d997cfac05a3d188aa69f4df7f Author: Kuniyuki Iwashima Date: Thu Feb 19 17:31:31 2026 +0000 udplite: Fix null-ptr-deref in __udp_enqueue_schedule_skb(). [ Upstream commit 470c7ca2b4c3e3a51feeb952b7f97a775b5c49cd ] syzbot reported null-ptr-deref of udp_sk(sk)->udp_prod_queue. [0] Since the cited commit, udp_lib_init_sock() can fail, as can udp_init_sock() and udpv6_init_sock(). Let's handle the error in udplite_sk_init() and udplitev6_sk_init(). [0]: BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:82 [inline] BUG: KASAN: null-ptr-deref in atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline] BUG: KASAN: null-ptr-deref in __udp_enqueue_schedule_skb+0x151/0x1480 net/ipv4/udp.c:1719 Read of size 4 at addr 0000000000000008 by task syz.2.18/2944 CPU: 1 UID: 0 PID: 2944 Comm: syz.2.18 Not tainted syzkaller #0 PREEMPTLAZY Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 kasan_report+0xa2/0xe0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 mm/kasan/generic.c:200 instrument_atomic_read include/linux/instrumented.h:82 [inline] atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline] __udp_enqueue_schedule_skb+0x151/0x1480 net/ipv4/udp.c:1719 __udpv6_queue_rcv_skb net/ipv6/udp.c:795 [inline] udpv6_queue_rcv_one_skb+0xa2e/0x1ad0 net/ipv6/udp.c:906 udp6_unicast_rcv_skb+0x227/0x380 net/ipv6/udp.c:1064 ip6_protocol_deliver_rcu+0xe17/0x1540 net/ipv6/ip6_input.c:438 ip6_input_finish+0x191/0x350 net/ipv6/ip6_input.c:489 NF_HOOK+0x354/0x3f0 include/linux/netfilter.h:318 ip6_input+0x16c/0x2b0 net/ipv6/ip6_input.c:500 NF_HOOK+0x354/0x3f0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6149 [inline] __netif_receive_skb+0xd3/0x370 net/core/dev.c:6262 process_backlog+0x4d6/0x1160 net/core/dev.c:6614 __napi_poll+0xae/0x320 net/core/dev.c:7678 napi_poll net/core/dev.c:7741 [inline] net_rx_action+0x60d/0xdc0 net/core/dev.c:7893 handle_softirqs+0x209/0x8d0 kernel/softirq.c:622 do_softirq+0x52/0x90 kernel/softirq.c:523 __local_bh_enable_ip+0xe7/0x120 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x109c/0x2dc0 net/core/dev.c:4856 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline] ip6_finish_output+0x158/0x4e0 net/ipv6/ip6_output.c:219 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x342/0x580 net/ipv6/ip6_output.c:246 ip6_send_skb+0x1d7/0x3c0 net/ipv6/ip6_output.c:1984 udp_v6_send_skb+0x9a5/0x1770 net/ipv6/udp.c:1442 udp_v6_push_pending_frames+0xa2/0x140 net/ipv6/udp.c:1469 udpv6_sendmsg+0xfe0/0x2830 net/ipv6/udp.c:1759 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xe5/0x270 net/socket.c:742 __sys_sendto+0x3eb/0x580 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd2/0xf20 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f67b4d9c629 Code: ff 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 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f67b5c98028 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f67b5015fa0 RCX: 00007f67b4d9c629 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f67b4e32b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000040000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f67b5016038 R14: 00007f67b5015fa0 R15: 00007ffe3cb66dd8 Fixes: b650bf0977d3 ("udp: remove busylock and add per NUMA queues") Reported-by: syzbot Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260219173142.310741-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2d74412dfd3621552a394d55cc3dd26a7cbf608e Author: Linus Walleij Date: Thu Feb 19 12:38:50 2026 +0100 net: ethernet: xscale: Check for PTP support properly [ Upstream commit 594163ea88a03bdb412063af50fc7177ef3cbeae ] In ixp4xx_get_ts_info() ixp46x_ptp_find() is called unconditionally despite this feature only existing on ixp46x, leading to the following splat from tcpdump: root@OpenWrt:~# tcpdump -vv -X -i eth0 (...) Unable to handle kernel NULL pointer dereference at virtual address 00000238 when read (...) Call trace: ptp_clock_index from ixp46x_ptp_find+0x1c/0x38 ixp46x_ptp_find from ixp4xx_get_ts_info+0x4c/0x64 ixp4xx_get_ts_info from __ethtool_get_ts_info+0x90/0x108 __ethtool_get_ts_info from __dev_ethtool+0xa00/0x2648 __dev_ethtool from dev_ethtool+0x160/0x234 dev_ethtool from dev_ioctl+0x2cc/0x460 dev_ioctl from sock_ioctl+0x1ec/0x524 sock_ioctl from sys_ioctl+0x51c/0xa94 sys_ioctl from ret_fast_syscall+0x0/0x44 (...) Segmentation fault Check for ixp46x in ixp46x_ptp_find() before trying to set up PTP to avoid this. To avoid altering the returned error code from ixp4xx_hwtstamp_set() which before this patch was -EOPNOTSUPP, we return -EOPNOTSUPP from ixp4xx_hwtstamp_set() if ixp46x_ptp_find() fails no matter the error code. The helper function ixp46x_ptp_find() helper returns -ENODEV. Fixes: 9055a2f59162 ("ixp4xx_eth: make ptp support a platform driver") Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260219-ixp4xx-fix-ethernet-v3-1-f235ccc3cd46@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cb8f0a3857386b792c38b9f81f3d87832147201b Author: Dmitry Torokhov Date: Wed Feb 18 16:56:00 2026 -0800 net: phy: qcom: qca807x: normalize return value of gpio_get [ Upstream commit 2bb995e6155cb4f254574598cbd6fe1dcc99766a ] The GPIO get callback is expected to return 0 or 1 (or a negative error code). Ensure that the value returned by qca807x_gpio_get() is normalized to the [0, 1] range. Fixes: 86ef402d805d ("gpiolib: sanitize the return value of gpio_chip::get()") Signed-off-by: Dmitry Torokhov Reviewed-by: Bartosz Golaszewski Reviewed-by: Linus Walleij Link: https://patch.msgid.link/aZZeyr2ysqqk2GqA@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9605406cf28fa8350ac731c0a9b218da8a7c8785 Author: Ethan Tidmore Date: Thu Feb 19 16:10:01 2026 -0600 proc: Fix pointer error dereference [ Upstream commit f6a495484a27150fb85f943e1a7464da88c2a797 ] The function try_lookup_noperm() can return an error pointer. Add check for error pointer. Detected by Smatch: fs/proc/base.c:2148 proc_fill_cache() error: 'child' dereferencing possible ERR_PTR() Fixes: 1df98b8bbcca ("proc_fill_cache(): clean up, get rid of pointless find_inode_number() use") Signed-off-by: Ethan Tidmore Link: https://patch.msgid.link/20260219221001.1117135-1-ethantidmore06@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit f3970be26a308f35dd24ebb2f73ad5bd33745844 Author: Martin Pålsson Date: Wed Feb 18 05:28:22 2026 +0000 net: usb: lan78xx: scan all MDIO addresses on LAN7801 [ Upstream commit f1e2f0ce704e4a14e3f367d3b97d3dd2d8e183b7 ] The LAN7801 is designed exclusively for external PHYs (unlike the LAN7800/LAN7850 which have internal PHYs), but lan78xx_mdio_init() restricts PHY scanning to MDIO addresses 0-7 by setting phy_mask to ~(0xFF). This prevents discovery of external PHYs wired to addresses outside that range. One such case is the DP83TC814 100BASE-T1 PHY, which is typically configured at MDIO address 10 via PHYAD bootstrap pins and goes undetected with the current mask. Remove the restrictive phy_mask assignment for the LAN7801 so that the default mask of 0 applies, allowing all 32 MDIO addresses to be scanned during bus registration. Fixes: 02dc1f3d613d ("lan78xx: add LAN7801 MAC only support") Signed-off-by: Martin Pålsson Link: https://patch.msgid.link/0110019c6f388aff-98d99cf0-4425-4fff-b16b-dea5ad8fafe0-000000@eu-north-1.amazonses.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fc393af769af845d9985e2845e49553d8f015a64 Author: Ziyi Guo Date: Tue Feb 17 17:50:12 2026 +0000 net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode [ Upstream commit 64868f5ecadeb359a49bc4485bfa7c497047f13a ] kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls netif_stop_queue() and netif_wake_queue(). These are TX queue flow control functions unrelated to RX multicast configuration. The premature netif_wake_queue() can re-enable TX while tx_urb is still in-flight, leading to a double usb_submit_urb() on the same URB: kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); } kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done } kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active } This triggers the WARN in usb_submit_urb(): "URB submitted while active" This is a similar class of bug fixed in rtl8150 by - commit 958baf5eaee3 ("net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast"). Also kaweth_set_rx_mode() is already functionally broken, the real set_rx_mode action is performed by kaweth_async_set_rx_mode(), which in turn is not a no-op only at ndo_open() time. Suggested-by: Paolo Abeni Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ziyi Guo Link: https://patch.msgid.link/20260217175012.1234494-1-n7l8m4@u.northwestern.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 664e9df53226b4505a0894817ecad2c610ab11d8 Author: Hyunwoo Kim Date: Wed Feb 18 02:16:43 2026 +0900 espintcp: Fix race condition in espintcp_close() [ Upstream commit e1512c1db9e8794d8d130addd2615ec27231d994 ] This issue was discovered during a code audit. After cancel_work_sync() is called from espintcp_close(), espintcp_tx_work() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the espintcp_tx_work() worker may dereference a freed espintcp ctx or sk. The following is a simple race scenario: cpu0 cpu1 espintcp_close() cancel_work_sync(&ctx->work); espintcp_write_space() schedule_work(&ctx->work); To prevent this race condition, cancel_work_sync() is replaced with disable_work_sync(). Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Signed-off-by: Hyunwoo Kim Reviewed-by: Simon Horman Link: https://patch.msgid.link/aZSie7rEdh9Nu0eM@v4bel Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b640188b61e631ba5c82b232fb544411444205ee Author: Eric Dumazet Date: Wed Feb 18 14:13:37 2026 +0000 psp: use sk->sk_hash in psp_write_headers() [ Upstream commit f891007ab1c77436950d10e09eae54507f1865ff ] udp_flow_src_port() is indirectly using sk->sk_txhash as a base, because __tcp_transmit_skb() uses skb_set_hash_from_sk(). This is problematic because this field can change over the lifetime of a TCP flow, thanks to calls to sk_rethink_txhash(). Problem is that some NIC might (ab)use the PSP UDP source port in their RSS computation, and PSP packets for a given flow could jump from one queue to another. In order to avoid surprises, it is safer to let Protective Load Balancing (PLB) get its entropy from the IPv6 flowlabel, and change psp_write_headers() to use sk->sk_hash which does not change for the duration of the flow. We might add a sysctl to select the behavior, if there is a need for it. Fixes: fc724515741a ("psp: provide encapsulation helper for drivers") Signed-off-by: Eric Dumazet Reviewed-By: Daniel Zahka Link: https://patch.msgid.link/20260218141337.999945-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fe89b2f05b854847784f91127319172945c1fadd Author: Eric Dumazet Date: Tue Feb 17 16:12:05 2026 +0000 tcp: fix potential race in tcp_v6_syn_recv_sock() [ Upstream commit 858d2a4f67ff69e645a43487ef7ea7f28f06deae ] Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late. After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it. Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found. Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion. This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+937b5bbb6a815b3e5d0b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69949275.050a0220.2eeac1.0145.GAE@google.com/ Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260217161205.2079883-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 82c5acb68c6390b9b5c402cac484406ad9c3ba28 Author: Kuniyuki Iwashima Date: Tue Oct 14 22:42:07 2025 +0000 ipv6: Move ipv6_fl_list from ipv6_pinfo to inet_sock. [ Upstream commit 1c17f4373d4db1e1f0ebd3ddcd8e7a642927a826 ] In {tcp6,udp6,raw6}_sock, struct ipv6_pinfo is always placed at the beginning of a new cache line because 1. __alignof__(struct tcp_sock) is 64 due to ____cacheline_aligned of __cacheline_group_begin(tcp_sock_write_tx) 2. __alignof__(struct udp_sock) is 64 due to ____cacheline_aligned of struct numa_drop_counters 3. in raw6_sock, struct numa_drop_counters is placed before struct ipv6_pinfo . struct ipv6_pinfo is 136 bytes, but the last cache line is only used by ipv6_fl_list: $ pahole -C ipv6_pinfo vmlinux struct ipv6_pinfo { ... /* --- cacheline 2 boundary (128 bytes) --- */ struct ipv6_fl_socklist * ipv6_fl_list; /* 128 8 */ /* size: 136, cachelines: 3, members: 23 */ Let's move ipv6_fl_list from struct ipv6_pinfo to struct inet_sock to save a full cache line for {tcp6,udp6,raw6}_sock. Now, struct ipv6_pinfo is 128 bytes, and {tcp6,udp6,raw6}_sock have 64 bytes less, while {tcp,udp,raw}_sock retain the same size. Before: # grep -E "^(RAW|UDP[^L\-]|TCP)" /proc/slabinfo | awk '{print $1, "\t", $4}' RAWv6 1408 UDPv6 1472 TCPv6 2560 RAW 1152 UDP 1280 TCP 2368 After: # grep -E "^(RAW|UDP[^L\-]|TCP)" /proc/slabinfo | awk '{print $1, "\t", $4}' RAWv6 1344 UDPv6 1408 TCPv6 2496 RAW 1152 UDP 1280 TCP 2368 Also, ipv6_fl_list and inet_flags (SNDFLOW bit) are placed in the same cache line. $ pahole -C inet_sock vmlinux ... /* --- cacheline 11 boundary (704 bytes) was 56 bytes ago --- */ struct ipv6_pinfo * pinet6; /* 760 8 */ /* --- cacheline 12 boundary (768 bytes) --- */ struct ipv6_fl_socklist * ipv6_fl_list; /* 768 8 */ unsigned long inet_flags; /* 776 8 */ Doc churn is due to the insufficient Type column (only 1 space short). Suggested-by: Eric Dumazet Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20251014224210.2964778-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 858d2a4f67ff ("tcp: fix potential race in tcp_v6_syn_recv_sock()") Signed-off-by: Sasha Levin commit 59581778792cbaf8ad788f4a21dc663ce986050e Author: Tetsuo Handa Date: Fri Jan 30 19:42:47 2026 +0900 xfrm: always flush state and policy upon NETDEV_UNREGISTER event [ Upstream commit 4efa91a28576054aae0e6dad9cba8fed8293aef8 ] syzbot is reporting that "struct xfrm_state" refcount is leaking. unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 2 ref_tracker: netdev@ffff888052f24618 has 1/1 users at __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline] netdev_tracker_alloc include/linux/netdevice.h:4412 [inline] xfrm_dev_state_add+0x3a5/0x1080 net/xfrm/xfrm_device.c:316 xfrm_state_construct net/xfrm/xfrm_user.c:986 [inline] xfrm_add_sa+0x34ff/0x5fa0 net/xfrm/xfrm_user.c:1022 xfrm_user_rcv_msg+0x58e/0xc00 net/xfrm/xfrm_user.c:3507 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2550 xfrm_netlink_rcv+0x71/0x90 net/xfrm/xfrm_user.c:3529 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa5d/0xc30 net/socket.c:2592 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2646 __sys_sendmsg+0x16d/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f This is because commit d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") implemented xfrm_dev_unregister() as no-op despite xfrm_dev_state_add() from xfrm_state_construct() acquires a reference to "struct net_device". I guess that that commit expected that NETDEV_DOWN event is fired before NETDEV_UNREGISTER event fires, and also assumed that xfrm_dev_state_add() is called only if (dev->features & NETIF_F_HW_ESP) != 0. Sabrina Dubroca identified steps to reproduce the same symptoms as below. echo 0 > /sys/bus/netdevsim/new_device dev=$(ls -1 /sys/bus/netdevsim/devices/netdevsim0/net/) ip xfrm state add src 192.168.13.1 dst 192.168.13.2 proto esp \ spi 0x1000 mode tunnel aead 'rfc4106(gcm(aes))' $key 128 \ offload crypto dev $dev dir out ethtool -K $dev esp-hw-offload off echo 0 > /sys/bus/netdevsim/del_device Like these steps indicate, the NETIF_F_HW_ESP bit can be cleared after xfrm_dev_state_add() acquired a reference to "struct net_device". Also, xfrm_dev_state_add() does not check for the NETIF_F_HW_ESP bit when acquiring a reference to "struct net_device". Commit 03891f820c21 ("xfrm: handle NETDEV_UNREGISTER for xfrm device") re-introduced the NETDEV_UNREGISTER event to xfrm_dev_event(), but that commit for unknown reason chose to share xfrm_dev_down() between the NETDEV_DOWN event and the NETDEV_UNREGISTER event. I guess that that commit missed the behavior in the previous paragraph. Therefore, we need to re-introduce xfrm_dev_unregister() in order to release the reference to "struct net_device" by unconditionally flushing state and policy. Reported-by: syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") Cc: Sabrina Dubroca Signed-off-by: Tetsuo Handa Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit f726b3a57e00bb6249c67714c11ae8b4b31719a1 Author: Matt Johnston Date: Tue Jan 13 17:41:34 2026 +0800 ipmi: ipmb: initialise event handler read bytes [ Upstream commit 9f235ccecd03c436cb1683eac16b12f119e54aa9 ] IPMB doesn't use i2c reads, but the handler needs to set a value. Otherwise an i2c read will return an uninitialised value from the bus driver. Fixes: 63c4eb347164 ("ipmi:ipmb: Add initial support for IPMI over IPMB") Signed-off-by: Matt Johnston Message-ID: <20260113-ipmb-read-init-v1-1-a9cbce7b94e3@codeconstruct.com.au> Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 27e70f32aef0ab0e039d4900012e7fe9a599a0e9 Author: Leon Romanovsky Date: Tue Jan 27 14:49:23 2026 +0200 xfrm: skip templates check for packet offload tunnel mode [ Upstream commit 0a4524bc69882a4ddb235bb6b279597721bda197 ] In packet offload, hardware is responsible to check templates. The result of its operation is forwarded through secpath by relevant drivers. That secpath is actually removed in __xfrm_policy_check2(). In case packet is forwarded, this secpath is reset in RX, but pushed again to TX where policy is rechecked again against dummy secpath in xfrm_policy_ok(). Such situation causes to unexpected XfrmInTmplMismatch increase. As a solution, simply skip template mismatch check. Fixes: 600258d555f0 ("xfrm: delete intermediate secpath entry in packet offload mode") Signed-off-by: Leon Romanovsky Reviewed-by: Jianbo Liu Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit c7221e7bd8fc2ef38a0b27be580d9d202281306b Author: Jiayuan Chen Date: Tue Jan 27 19:38:44 2026 +0800 xfrm6: fix uninitialized saddr in xfrm6_get_saddr() [ Upstream commit 1799d8abeabc68ec05679292aaf6cba93b343c05 ] xfrm6_get_saddr() does not check the return value of ipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6_get_saddr() still returns 0 (success). This causes the caller xfrm_tmpl_resolve_one() to use the uninitialized address in xfrm_state_find(), triggering KMSAN warning: ===================================================== BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940 xfrm_state_find+0x2424/0xa940 xfrm_resolve_and_create_bundle+0x906/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 xfrm_lookup_route+0x63/0x2b0 ip_route_output_flow+0x1ce/0x270 udp_sendmsg+0x2ce1/0x3400 inet_sendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64_sys_sendto+0x130/0x200 x64_sys_call+0x332b/0x3e70 do_syscall_64+0xd3/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable tmp.i.i created at: xfrm_resolve_and_create_bundle+0x3e3/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 ===================================================== Fix by checking the return value of ipv6_dev_get_saddr() and propagating the error. Fixes: a1e59abf8249 ("[XFRM]: Fix wildcard as tunnel source") Reported-by: syzbot+e136d86d34b42399a8b1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68bf1024.a70a0220.7a912.02c2.GAE@google.com/T/ Signed-off-by: Jiayuan Chen Signed-off-by: Jiayuan Chen Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 5000ce7fcb31067566a1a1a2e5b5bbff93625242 Author: Ankit Soni Date: Thu Jan 22 15:30:38 2026 +0000 iommu/amd: serialize sequence allocation under concurrent TLB invalidations [ Upstream commit 9e249c48412828e807afddc21527eb734dc9bd3d ] With concurrent TLB invalidations, completion wait randomly gets timed out because cmd_sem_val was incremented outside the IOMMU spinlock, allowing CMD_COMPL_WAIT commands to be queued out of sequence and breaking the ordering assumption in wait_on_sem(). Move the cmd_sem_val increment under iommu->lock so completion sequence allocation is serialized with command queuing. And remove the unnecessary return. Fixes: d2a0cac10597 ("iommu/amd: move wait_on_sem() out of spinlock") Tested-by: Srikanth Aithal Reported-by: Srikanth Aithal Signed-off-by: Ankit Soni Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a133e3caf844a3f56b6eef89ddaa66115874f6bd Author: Maciej Grochowski Date: Thu Feb 13 14:53:17 2025 -0800 ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lut [ Upstream commit 186615f8855a0be4ee7d3fcd09a8ecc10e783b08 ] Number of MW LUTs depends on NTB configuration and can be set to zero, in such scenario rounddown_pow_of_two will cause undefined behaviour and should not be performed. This patch ensures that rounddown_pow_of_two is called on valid value. Signed-off-by: Maciej Grochowski Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 2346856b74823a2a78109002e479a3d02526a9ce Author: Maciej Grochowski Date: Thu Feb 13 14:53:18 2025 -0800 ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access [ Upstream commit c8ba7ad2cc1c7b90570aa347b8ebbe279f1eface ] Number of MW LUTs depends on NTB configuration and can be set to MAX_MWS, This patch protects against invalid index out of bounds access to mw_sizes When invalid access print message to user that configuration is not valid. Signed-off-by: Maciej Grochowski Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 495d9cb4ed711795a015e80b43eeb7998c630e00 Author: Tomas Melin Date: Thu Jan 22 13:53:45 2026 +0000 rtc: zynqmp: correct frequency value [ Upstream commit 2724fb4d429cbb724dcb6fa17953040918ebe3a2 ] Fix calibration value in case a clock reference is provided. The actual calibration value written into register is frequency - 1. Reviewed-by: Harini T Tested-by: Harini T Signed-off-by: Tomas Melin Acked-by: Michal Simek Link: https://patch.msgid.link/20260122-zynqmp-rtc-updates-v4-1-d4edb966b499@vaisala.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 630ace4d8286f8479eb6574d53699176f818c8c3 Author: Victor Zhao Date: Wed Feb 4 23:15:04 2026 +0800 drm/amdgpu: avoid sdma ring reset in sriov [ Upstream commit 5cc7bbd9f1b74d9fe2f7ac08d6ba0477e8d2d65f ] sdma ring reset is not supported in SRIOV. kfd driver does not check reset mask, and could queue sdma ring reset during unmap_queues_cpsch. Avoid the ring reset for sriov. Signed-off-by: Victor Zhao Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7a7e7bcefdd3e44c58ee17e81f36308ca7aecdb7 Author: Alex Hung Date: Wed Feb 4 22:05:16 2026 -0700 drm/amd/display: Remove conditional for shaper 3DLUT power-on [ Upstream commit 1b38a87b8f8020e8ef4563e7752a64182b5a39b9 ] [Why] Shaper programming has high chance to fail on first time after power-on or reboot. This can be verified by running IGT's kms_colorop. [How] Always power on the shaper and 3DLUT before programming by removing the debug flag of low power mode. Reviewed-by: Aurabindo Pillai Signed-off-by: Alex Hung Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 581ed1a5a957a219655397fbfc981f0a6d0eac4f Author: Arnd Bergmann Date: Mon Feb 16 11:54:21 2026 +0100 arm64: hugetlbpage: avoid unused-but-set-parameter warning (gcc-16) [ Upstream commit 729a2e8e9ac47099a967567389cc9d73ef4194ca ] gcc-16 warns about an instance that older compilers did not: arch/arm64/mm/hugetlbpage.c: In function 'huge_pte_clear': arch/arm64/mm/hugetlbpage.c:369:57: error: parameter 'addr' set but not used [-Werror=unused-but-set-parameter=] The issue here is that __pte_clear() does not actually use its second argument, but when CONFIG_ARM64_CONTPTE is enabled it still gets updated. Replace the macro with an inline function to let the compiler see the argument getting passed down. Suggested-by: Catalin Marinas Signed-off-by: Arnd Bergmann Reviewed-by: Dev Jain Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit dd6e15658ab5dedf1f611308d91d5b8b1101839d Author: Aaron Erhardt Date: Wed Feb 18 22:32:10 2026 +0100 ALSA: hda/hdmi: Add quirk for TUXEDO IBS14G6 [ Upstream commit d649c58bcad8fb9b749e3837136a201632fa109d ] Depending on the timing during boot, the BIOS might report wrong pin capabilities, which can lead to HDMI audio being disabled. Therefore, force HDMI audio connection on TUXEDO InfinityBook S 14 Gen6. Signed-off-by: Aaron Erhardt Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20260218213234.429686-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d70d2a8a491e872c47fdd6300580c87fa2fd2c0f Author: Vijendar Mukunda Date: Wed Feb 18 16:15:34 2026 +0530 ASoC: amd: amd_sdw: add machine driver quirk for Lenovo models [ Upstream commit 3acf517e1ae05ef66561b7a2782690387ce46e21 ] This patch adds a quirk to include the codec amplifier function for Lenovo models listed in the quirk table. Note: In these models, the RT722 codec amplifier is excluded, and an external amplifier is used instead. Signed-off-by: Vijendar Mukunda Link: https://patch.msgid.link/20260218104734.3641481-3-Vijendar.Mukunda@amd.com Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c19830db30a094dce400b0e7758e9ae51ac2e9e9 Author: Adarsh Das Date: Tue Feb 3 22:53:57 2026 +0530 btrfs: replace BUG() with error handling in __btrfs_balance() [ Upstream commit be6324a809dbda76d5fdb23720ad9b20e5c1905c ] We search with offset (u64)-1 which should never match exactly. Previously this was handled with BUG(). Now logs an error and return -EUCLEAN. Reviewed-by: Qu Wenruo Signed-off-by: Adarsh Das Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 6af16f1b8649df4c00d6ced924bdd8b72c885b6a Author: Takashi Iwai Date: Mon Feb 16 15:12:07 2026 +0100 ALSA: usb-audio: Add sanity check for OOB writes at silencing [ Upstream commit fba2105a157fffcf19825e4eea498346738c9948 ] At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076 Link: https://patch.msgid.link/20260216141209.1849200-4-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d6e933f29bc05d754e37ff9ed0087da542294c05 Author: decce6 Date: Tue Feb 10 07:26:00 2026 +0000 drm/radeon: Add HAINAN clock adjustment [ Upstream commit 908d318f23d6b5d625bea093c5fc056238cdb7ff ] This patch limits the clock speeds of the AMD Radeon R5 M420 GPU from 850/1000MHz (core/memory) to 800/950 MHz, making it work stably. This patch is for radeon. Signed-off-by: decce6 Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e341e18215030af2136836b78508e0d798916df7 Author: Fabian Godehardt Date: Wed Feb 11 08:26:16 2026 +0100 spi: spidev: fix lock inversion between spi_lock and buf_lock [ Upstream commit 40534d19ed2afb880ecf202dab26a8e7a5808d16 ] The spidev driver previously used two mutexes, spi_lock and buf_lock, but acquired them in different orders depending on the code path: write()/read(): buf_lock -> spi_lock ioctl(): spi_lock -> buf_lock This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks: WARNING: possible circular locking dependency detected spidev_ioctl() -> mutex_lock(&spidev->buf_lock) spidev_sync_write() -> mutex_lock(&spidev->spi_lock) *** DEADLOCK *** The issue is reproducible with a simple userspace program that performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from separate threads on the same spidev file descriptor. Fix this by simplifying the locking model and removing the lock inversion entirely. spidev_sync() no longer performs any locking, and all callers serialize access using spi_lock. buf_lock is removed since its functionality is fully covered by spi_lock, eliminating the possibility of lock ordering issues. This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour. Signed-off-by: Fabian Godehardt Link: https://patch.msgid.link/20260211072616.489522-1-fg@emlix.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 91e19be60e08b5fb300e4eef793d064df4b53609 Author: Clay King Date: Fri Jan 30 11:40:06 2026 -0500 drm/amd/display: bypass post csc for additional color spaces in dal [ Upstream commit 7d9ec9dc20ecdb1661f4538cd9112cd3d6a5f15a ] [Why] For RGB BT2020 full and limited color spaces, overlay adjustments were applied twice (once by MM and once by DAL). This results in incorrect colours and a noticeable difference between mpo and non-mpo cases. [How] Add RGB BT2020 full and limited color spaces to list that bypasses post csc adjustment. Reviewed-by: Aric Cyr Signed-off-by: Clay King Signed-off-by: Tom Chung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e3c0c83844791f9aecd16cd09eb849e3cf7ef884 Author: decce6 Date: Tue Feb 10 07:24:01 2026 +0000 drm/amdgpu: Add HAINAN clock adjustment [ Upstream commit 49fe2c57bdc0acff9d2551ae337270b6fd8119d9 ] This patch limits the clock speeds of the AMD Radeon R5 M420 GPU from 850/1000MHz (core/memory) to 800/950 MHz, making it work stably. This patch is for amdgpu. Signed-off-by: decce6 Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e949fd266cfa1dcca7caa3faa698578c4ffd26d6 Author: Takashi Iwai Date: Mon Feb 16 15:12:05 2026 +0100 ALSA: usb-audio: Update the number of packets properly at receiving [ Upstream commit cf044e44190234a41a788de1cdbb6c21f4a52e1e ] At receiving the packets from the implicit feedback source, we didn't update ctx->packets field but only the ctx->packet_size[] data. In exceptional cases, this might lead to unexpectedly superfluous data transfer (although this won't happen usually due to the nature of USB isochronous transfer). Fix it to update the field properly. Link: https://patch.msgid.link/20260216141209.1849200-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ef8b0cc691f1a68310a39397eb35fdee67fab05a Author: Erik Sanjaya Date: Tue Feb 17 17:21:12 2026 +0700 ALSA: hda/realtek: Fix headset mic on ASUS Zenbook 14 UX3405MA [ Upstream commit 91062e119b4eafde553c894ca072cd615a6dae2e ] The ASUS Zenbook 14 UX3405MA uses an ALC294 codec with CS35L41 amplifiers over SPI. The existing quirk for this model only configured the amplifiers, leaving the headset microphone on the combo jack non-functional. Introduce a new fixup that configures pin 0x19 as headset mic input and chains to ALC245_FIXUP_CS35L41_SPI_2 to preserve speaker functionality. Similar to the fix done for the UM3406HA in commit 018f659753fd ("ALSA: hda/realtek: Fix headset mic on ASUS Zenbook 14"). Signed-off-by: Erik Sanjaya Link: https://patch.msgid.link/20260217102112.20651-1-sirreidlos@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8c545bcb1dabda49de6bdcc805d3a78e9add999c Author: Ce Sun Date: Tue Feb 10 15:32:01 2026 +0800 drm/amdgpu: Adjust usleep_range in fence wait [ Upstream commit 3ee1c72606bd2842f0f377fd4b118362af0323ae ] Tune the sleep interval in the PSP fence wait loop from 10-100us to 60-100us.This adjustment results in an overall wait window of 1.2s (60us * 20000 iterations) to 2 seconds (100us * 20000 iterations), which guarantees that we can retrieve the correct fence value Signed-off-by: Ce Sun Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 89232d0db3ca9d20776f955f20dae3727e227a00 Author: Gangliang Xie Date: Mon Feb 9 17:32:00 2026 +0800 drm/amdgpu: return when ras table checksum is error [ Upstream commit 044f8d3b1fac6ac89c560f61415000e6bdab3a03 ] end the function flow when ras table checksum is error Signed-off-by: Gangliang Xie Reviewed-by: Tao Zhou Reviewed-by: Kent Russell Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit dea826897ea37e49321597486416b0bd9549d3d8 Author: Wayne Lin Date: Fri Jan 23 14:47:01 2026 +0800 drm/amd/display: Avoid updating surface with the same surface under MPO [ Upstream commit 1a38ded4bc8ac09fd029ec656b1e2c98cc0d238c ] [Why & How] Although it's dummy updates of surface update for committing stream updates, we should not have dummy_updates[j].surface all indicating to the same surface under multiple surfaces case. Otherwise, copy_surface_update_to_plane() in update_planes_and_stream_state() will update to the same surface only. Reviewed-by: Harry Wentland Signed-off-by: Wayne Lin Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a71819d2cc6f7d3a3ae7862385272057e708fc14 Author: Tom Chung Date: Tue Jan 20 18:10:31 2026 +0800 drm/amd/display: Fix system resume lag issue [ Upstream commit 64c94cd9be2e188ed07efeafa6a109bce638c967 ] [Why] System will try to apply idle power optimizations setting during system resume. But system power state is still in D3 state, and it will cause the idle power optimizations command not actually to be sent to DMUB and cause some platforms to go into IPS. [How] Set power state to D0 first before calling the dc_dmub_srv_apply_idle_power_optimizations(dm->dc, false) Reviewed-by: Nicholas Kazlauskas Signed-off-by: Tom Chung Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 16b65c8ca31600bcf61a50e0fe7d85c14b36bfc3 Author: Baojun Xu Date: Wed Feb 11 11:09:46 2026 +0800 ALSA: hda/tas2781: Ignore reset check for SPI device [ Upstream commit 908ef80e31e4d3bd953a0088fe57640cd9ae7b3e ] In the SPI driver probe, the device should be in the default state, so the device status check is not necessary. It should be forced to do the firmware download as I2C device. Signed-off-by: Baojun Xu Link: https://patch.msgid.link/20260211030946.2330-1-baojun.xu@ti.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 96c5ea9e7a8214be8fabf4690a878e1e936f9ae8 Author: Bjorn Andersson Date: Wed Feb 11 21:37:14 2026 -0600 regulator: core: Remove regulator supply_name length limit [ Upstream commit e243cdd87b911ce9968b62e4ab2b680dfadc4341 ] When creating the regulator object, associated with a consumer device, the supply_name is string formatted into a statically sized buffer on the stack, then strdup()'ed onto the heap. Not only is the dance on the stack unnecessary, but when the device's name is long we might not fit the constructed supply_name in the fixed 64 byte buffer on the stack. One such case can be seen on the Qualcomm Rb3Gen2 board, where we find a PCIe controller, with a PCIe switch, with a USB controller, with a USB hub, consuming a regulator. In this example the dev->kobj.name itself is 62 characters long. Drop the temporary buffer on the stack and kasprintf() the string directly on the heap, both to simplify the code, and to remove the length limitation. Signed-off-by: Bjorn Andersson Link: https://patch.msgid.link/20260211-regulator-supply-name-length-v1-1-3875541c1576@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0be2f54012b45f22c2495b789b3260a3df025a50 Author: Jack Yu Date: Tue Feb 10 15:43:35 2026 +0800 ASoC: rt721-sdca: Fix issue of fail to detect OMTP jack type [ Upstream commit 5578da7d957fbaf91f6c39ba2363c2d2e4273183 ] Add related HP-JD settings to fix issue of fail to detect OMTP jack type. Signed-off-by: Jack Yu Link: https://patch.msgid.link/20260210074335.2337830-1-jack.yu@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c57b6b4bc339a3cf7e3d0d8c542f048e3ff36190 Author: Carlos López Date: Thu Jan 22 12:41:31 2026 +0100 mshv: clear eventfd counter on irqfd shutdown [ Upstream commit 2b4246153e2184e3a3b4edc8cc35337d7a2455a6 ] While unhooking from the irqfd waitqueue, clear the internal eventfd counter by using eventfd_ctx_remove_wait_queue() instead of remove_wait_queue(), preventing potential spurious interrupts. This removes the need to store a pointer into the workqueue, as the eventfd already keeps track of it. This mimicks what other similar subsystems do on their equivalent paths with their irqfds (KVM, Xen, ACRN support, etc). Signed-off-by: Carlos López Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 8ee9aa80d4f1893a6699d46c403a1731548b544b Author: Lijo Lazar Date: Thu Jan 22 12:11:49 2026 +0530 drm/amdgpu: Skip vcn poison irq release on VF [ Upstream commit 8980be03b3f9a4b58197ef95d3b37efa41a25331 ] VF doesn't enable VCN poison irq in VCNv2.5. Skip releasing it and avoid call trace during deinitialization. [ 71.913601] [drm] clean up the vf2pf work item [ 71.915088] ------------[ cut here ]------------ [ 71.915092] WARNING: CPU: 3 PID: 1079 at /tmp/amd.aFkFvSQl/amd/amdgpu/amdgpu_irq.c:641 amdgpu_irq_put+0xc6/0xe0 [amdgpu] [ 71.915355] Modules linked in: amdgpu(OE-) amddrm_ttm_helper(OE) amdttm(OE) amddrm_buddy(OE) amdxcp(OE) amddrm_exec(OE) amd_sched(OE) amdkcl(OE) drm_suballoc_helper drm_display_helper cec rc_core i2c_algo_bit video wmi binfmt_misc nls_iso8859_1 intel_rapl_msr intel_rapl_common input_leds joydev serio_raw mac_hid qemu_fw_cfg sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua efi_pstore ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 hid_generic crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel usbhid 8139too sha256_ssse3 sha1_ssse3 hid psmouse bochs i2c_i801 ahci drm_vram_helper libahci i2c_smbus lpc_ich drm_ttm_helper 8139cp mii ttm aesni_intel crypto_simd cryptd [ 71.915484] CPU: 3 PID: 1079 Comm: rmmod Tainted: G OE 6.8.0-87-generic #88~22.04.1-Ubuntu [ 71.915489] Hardware name: Red Hat KVM/RHEL, BIOS 1.16.3-2.el9_5.1 04/01/2014 [ 71.915492] RIP: 0010:amdgpu_irq_put+0xc6/0xe0 [amdgpu] [ 71.915768] Code: 75 84 b8 ea ff ff ff eb d4 44 89 ea 48 89 de 4c 89 e7 e8 fd fc ff ff 5b 41 5c 41 5d 41 5e 5d 31 d2 31 f6 31 ff e9 55 30 3b c7 <0f> 0b eb d4 b8 fe ff ff ff eb a8 e9 b7 3b 8a 00 66 2e 0f 1f 84 00 [ 71.915771] RSP: 0018:ffffcf0800eafa30 EFLAGS: 00010246 [ 71.915775] RAX: 0000000000000000 RBX: ffff891bda4b0668 RCX: 0000000000000000 [ 71.915777] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 71.915779] RBP: ffffcf0800eafa50 R08: 0000000000000000 R09: 0000000000000000 [ 71.915781] R10: 0000000000000000 R11: 0000000000000000 R12: ffff891bda480000 [ 71.915782] R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000 [ 71.915792] FS: 000070cff87c4c40(0000) GS:ffff893abfb80000(0000) knlGS:0000000000000000 [ 71.915795] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 71.915797] CR2: 00005fa13073e478 CR3: 000000010d634006 CR4: 0000000000770ef0 [ 71.915800] PKRU: 55555554 [ 71.915802] Call Trace: [ 71.915805] [ 71.915809] vcn_v2_5_hw_fini+0x19e/0x1e0 [amdgpu] Signed-off-by: Lijo Lazar Reviewed-by: Mangesh Gadre Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit dce5da49f65c718ee5520cf033c664cfac4fd2cf Author: Alex Hung Date: Wed Jan 14 17:20:31 2026 -0700 drm/amd/display: Fix writeback on DCN 3.2+ [ Upstream commit 9ef84a307582a92ef055ef0bd3db10fd8ac75960 ] [WHAT] 1. Set no scaling for writeback as they are hardcoded in DCN3.2+. 2. Set no fast plane update for writeback commits. Reviewed-by: Harry Wentland Signed-off-by: Alex Hung Signed-off-by: Wayne Lin Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b7af28b96ddcef1be9bb173143f926534ca4ee94 Author: Thomas Weissschuh Date: Wed Jan 7 10:56:33 2026 +0100 ARM: 9467/1: mm: Don't use %pK through printk [ Upstream commit 012ea376a5948b025f260aa45d2a6ec5d96674ea ] Restricted pointers ("%pK") were never meant to be used through printk(). They can acquire sleeping locks in atomic contexts. Switch to %px over the more secure %p as this usage is a debugging aid, gated behind CONFIG_DEBUG_VIRTUAL and used by WARN(). Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/ Signed-off-by: Thomas Weißschuh Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit 88c624236ef0182db35840dc7298c24d50eb6de1 Author: Phil Sutter Date: Sat Feb 14 15:54:06 2026 +0100 include: uapi: netfilter_bridge.h: Cover for musl libc [ Upstream commit 4edd4ba71ce0df015303dba75ea9d20d1a217546 ] Musl defines its own struct ethhdr and thus defines __UAPI_DEF_ETHHDR to zero. To avoid struct redefinition errors, user space is therefore supposed to include netinet/if_ether.h before (or instead of) linux/if_ether.h. To relieve them from this burden, include the libc header here if not building for kernel space. Reported-by: Alyssa Ross Suggested-by: Florian Westphal Signed-off-by: Phil Sutter Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit dbf5c71218102f72dbbc5659829d94514bb2020a Author: Yauhen Kharuzhy Date: Thu Feb 12 00:22:42 2026 +0200 ACPI: x86: Force enabling of PWM2 on the Yogabook YB1-X90 [ Upstream commit a8c975302868c716afef0f50467bebbd069a35b8 ] The PWM2 on YB1-X90 tablets is used for keyboard backlight control but it is disabled in the ACPI DSDT table. Add it to the override_status_ids list to allow keyboard function control driver (drivers/platform/x86/lenovo/yogabook.c) to use it. Signed-off-by: Yauhen Kharuzhy Link: https://patch.msgid.link/20260211222242.4101162-1-jekhor@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 5c4e940075bd64eeaca33695dfc9b9f60bfa2748 Author: Kaushlendra Kumar Date: Wed Feb 11 08:23:15 2026 +0000 thermal: int340x: Fix sysfs group leak on DLVR registration failure [ Upstream commit 15176b818e048ccf6ef4b96db34eda7b7e98938a ] When DLVR sysfs group creation fails in proc_thermal_rfim_add(), the function returns immediately without cleaning up the FIVR group that may have been created earlier. Add proper error unwinding to remove the FIVR group before returning failure. Signed-off-by: Kaushlendra Kumar Acked-by: Srinivas Pandruvada Link: https://patch.msgid.link/LV3PR11MB876881B77D32A2854AD2908EF563A@LV3PR11MB8768.namprd11.prod.outlook.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c1a0f5f1e5e7e98c36a362ec3d1fcfd9932931ed Author: Ilya Dryomov Date: Fri Jul 4 16:30:50 2025 +0200 libceph: define and enforce CEPH_MAX_KEY_LEN [ Upstream commit ac431d597a9bdfc2ba6b314813f29a6ef2b4a3bf ] When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway. Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 5b75c7f24973cf9ec698edbc7e5dae6ef535ea65 Author: ethanwu Date: Thu Sep 25 18:42:06 2025 +0800 ceph: supply snapshot context in ceph_uninline_data() [ Upstream commit 305ff6b3a03c230d3c07b61457e961406d979693 ] The ceph_uninline_data function was missing proper snapshot context handling for its OSD write operations. Both CEPH_OSD_OP_CREATE and CEPH_OSD_OP_WRITE requests were passing NULL instead of the appropriate snapshot context, which could lead to unnecessary object clone. Reproducer: ../src/vstart.sh --new -x --localhost --bluestore // turn on cephfs inline data ./bin/ceph fs set a inline_data true --yes-i-really-really-mean-it // allow fs_a client to take snapshot ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' // mount cephfs with fuse, since kernel cephfs doesn't support inline write ceph-fuse --id fs_a -m 127.0.0.1:40318 --conf ceph.conf -d /mnt/mycephfs/ // bump snapshot seq mkdir /mnt/mycephfs/.snap/snap1 echo "foo" > /mnt/mycephfs/test // umount and mount it again using kernel cephfs client umount /mnt/mycephfs mount -t ceph fs_a@.a=/ /mnt/mycephfs/ -o conf=./ceph.conf echo "bar" >> /mnt/mycephfs/test ./bin/rados listsnaps -p cephfs.a.data $(printf "%x\n" $(stat -c %i /mnt/mycephfs/test)).00000000 will see this object does unnecessary clone 1000000000a.00000000 (seq:2): cloneid snaps size overlap 2 2 4 [] head - 8 but it's expected to see 10000000000.00000000 (seq:2): cloneid snaps size overlap head - 8 since there's no snapshot between these 2 writes clone happened because the first osd request CEPH_OSD_OP_CREATE doesn't pass snap context so object is created with snap seq 0, but later data writeback is equipped with snapshot context. snap.seq(1) > object snap seq(0), so osd does object clone. This fix properly acquiring the snapshot context before performing write operations. Signed-off-by: ethanwu Reviewed-by: Viacheslav Dubeyko Tested-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 57633b43a603fbfdeeff36276e538bd5a06c46fd Author: Konstantin Komarov Date: Mon Feb 9 16:07:32 2026 +0100 fs/ntfs3: avoid calling run_get_entry() when run == NULL in ntfs_read_run_nb_ra() [ Upstream commit c5226b96c08a010ebef5fdf4c90572bcd89e4299 ] When ntfs_read_run_nb_ra() is invoked with run == NULL the code later assumes run is valid and may call run_get_entry(NULL, ...), and also uses clen/idx without initializing them. Smatch reported uninitialized variable warnings and this can lead to undefined behaviour. This patch fixes it. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202512230646.v5hrYXL0-lkp@intel.com/ Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit b014372b62237521444ee51384549bdf48b79015 Author: Szymon Wilczek Date: Sat Dec 27 15:43:07 2025 +0100 ntfs3: fix circular locking dependency in run_unpack_ex [ Upstream commit 08ce2fee1b869ecbfbd94e0eb2630e52203a2e03 ] Syzbot reported a circular locking dependency between wnd->rw_lock (sbi->used.bitmap) and ni->file.run_lock. The deadlock scenario: 1. ntfs_extend_mft() takes ni->file.run_lock then wnd->rw_lock. 2. run_unpack_ex() takes wnd->rw_lock then tries to acquire ni->file.run_lock inside ntfs_refresh_zone(). This creates an AB-BA deadlock. Fix this by using down_read_trylock() instead of down_read() when acquiring run_lock in run_unpack_ex(). If the lock is contended, skip ntfs_refresh_zone() - the MFT zone will be refreshed on the next MFT operation. This breaks the circular dependency since we never block waiting for run_lock while holding wnd->rw_lock. Reported-by: syzbot+d27edf9f96ae85939222@syzkaller.appspotmail.com Tested-by: syzbot+d27edf9f96ae85939222@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d27edf9f96ae85939222 Signed-off-by: Szymon Wilczek Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit b67fb01429fff093ac5dfe4a2cb9822b86382374 Author: Konstantin Komarov Date: Fri Dec 12 14:27:48 2025 +0300 fs/ntfs3: drop preallocated clusters for sparse and compressed files [ Upstream commit 3a6aba7f3cf2b46816e08548c254d98de9c74eba ] Do not keep preallocated clusters for sparsed and compressed files. Preserving preallocation in these cases causes fsx failures when running with sparse files and preallocation enabled. Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 9779a6eaaabdf47aa57910d352b398ad742e6a5f Author: Jaehun Gou Date: Tue Dec 2 20:01:46 2025 +0900 fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST [ Upstream commit 06909b2549d631a47fcda249d34be26f7ca1711d ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an ATTR_LIST attribute indicates a zero data size while the driver allocates memory for it. When ntfs_load_attr_list() processes a resident ATTR_LIST with data_size set to zero, it still allocates memory because of al_aligned(0). This creates an inconsistent state where ni->attr_list.size is zero, but ni->attr_list.le is non-null. This causes ni_enum_attr_ex to incorrectly assume that no attribute list exists and enumerates only the primary MFT record. When it finds ATTR_LIST, the code reloads it and restarts the enumeration, repeating indefinitely. The mount operation never completes, hanging the kernel thread. This patch adds validation to ensure that data_size is non-zero before memory allocation. When a zero-sized ATTR_LIST is detected, the function returns -EINVAL, preventing a DoS vulnerability. Co-developed-by: Seunghun Han Signed-off-by: Seunghun Han Co-developed-by: Jihoon Kwon Signed-off-by: Jihoon Kwon Signed-off-by: Jaehun Gou Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit c0b43c45d45f59e7faad48675a50231a210c379b Author: Jaehun Gou Date: Tue Dec 2 20:01:09 2025 +0900 fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent metadata [ Upstream commit 4b90f16e4bb5607fb35e7802eb67874038da4640 ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an attribute header indicates an empty run list, while directory entries reference it as containing actual data. In NTFS, setting evcn=-1 with svcn=0 is a valid way to represent an empty run list, and run_unpack() correctly handles this by checking if evcn + 1 equals svcn and returning early without parsing any run data. However, this creates a problem when there is metadata inconsistency, where the attribute header claims to be empty (evcn=-1) but the caller expects to read actual data. When run_unpack() immediately returns success upon seeing this condition, it leaves the runs_tree uninitialized with run->runs as a NULL. The calling function attr_load_runs_range() assumes that a successful return means that the runs were loaded and sets clen to 0, expecting the next run_lookup_entry() call to succeed. Because runs_tree remains uninitialized, run_lookup_entry() continues to fail, and the loop increments vcn by zero (vcn += 0), leading to an infinite loop. This patch adds a retry counter to detect when run_lookup_entry() fails consecutively after attr_load_runs_vcn(). If the run is still not found on the second attempt, it indicates corrupted metadata and returns -EINVAL, preventing the Denial-of-Service (DoS) vulnerability. Co-developed-by: Seunghun Han Signed-off-by: Seunghun Han Co-developed-by: Jihoon Kwon Signed-off-by: Jihoon Kwon Signed-off-by: Jaehun Gou Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit b0ea441f44ce64fa514a415d4a9e6e2b06e7946c Author: Jaehun Gou Date: Tue Dec 2 19:59:59 2025 +0900 fs: ntfs3: check return value of indx_find to avoid infinite loop [ Upstream commit 1732053c8a6b360e2d5afb1b34fe9779398b072c ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed dentry in the ntfs3 filesystem can cause the kernel to hang during the lookup operations. By setting the HAS_SUB_NODE flag in an INDEX_ENTRY within a directory's INDEX_ALLOCATION block and manipulating the VCN pointer, an attacker can cause the indx_find() function to repeatedly read the same block, allocating 4 KB of memory each time. The kernel lacks VCN loop detection and depth limits, causing memory exhaustion and an OOM crash. This patch adds a return value check for fnd_push() to prevent a memory exhaustion vulnerability caused by infinite loops. When the index exceeds the size of the fnd->nodes array, fnd_push() returns -EINVAL. The indx_find() function checks this return value and stops processing, preventing further memory allocation. Co-developed-by: Seunghun Han Signed-off-by: Seunghun Han Co-developed-by: Jihoon Kwon Signed-off-by: Jihoon Kwon Signed-off-by: Jaehun Gou Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 843dc5c2151868a0b1570792f927281bea04220f Author: John Garry Date: Wed Jan 7 09:40:06 2026 +0000 MIPS: Loongson: Make cpumask_of_node() robust against NUMA_NO_NODE [ Upstream commit d55d3fe2d1470ac5b6e93efe7998b728013c9fc8 ] The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE - which is a valid index - so add a check for this. Signed-off-by: John Garry Reviewed-by: Huacai Chen Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 54302ec38da41d87a3fdd6d28e51f8883fd38d90 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:38 2026 +0100 iio: magnetometer: Remove IRQF_ONESHOT [ Upstream commit a54e9440925e6617c98669066b4753c4cdcea8a0 ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also disallows force-threading of the primary handler and the irq-core will warn about this. The force-threading functionality is required on PREEMPT_RT because the handler is using locks with can sleep on PREEMPT_RT. Remove IRQF_ONESHOT from irqflags. Tested-by: Geert Uytterhoeven Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Andy Shevchenko Reviewed-by: Nuno Sá Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit af51e8d99df7886cfc71f555a71e30051c1b8dd0 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:36 2026 +0100 iio: Use IRQF_NO_THREAD [ Upstream commit 04d390af97f2c28166f7ddfe1a6bda622e3a4766 ] The interrupt handler iio_trigger_generic_data_rdy_poll() will invoke other interrupt handler and this supposed to happen from within the hardirq. Use IRQF_NO_THREAD to forbid forced-threading. Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 12cb0a166dc4f7087e3e07a2efd707196f0408a8 Author: Ilpo Järvinen Date: Tue Jan 13 19:21:50 2026 +0200 mfd: intel-lpss: Add Intel Nova Lake-S PCI IDs [ Upstream commit cefd793fa17de708d043adab50e7f96f414b0f1d ] Add Intel Nova Lake-S LPSS PCI IDs. Signed-off-by: Ilpo Järvinen Acked-by: Andy Shevchenko Link: https://patch.msgid.link/20260113172151.48062-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit fcfa64c5358607a0767e2c32a52d6d6efe7dcb51 Author: Marcus Folkesson Date: Mon Nov 24 17:16:51 2025 +0100 Revert "mfd: da9052-spi: Change read-mask to write-mask" [ Upstream commit 12daa9c1954542bf98bb942fb2dadf19de79a44b ] This reverts commit 2e3378f6c79a1b3f7855ded1ef306ea4406352ed. Almost every register in this chip can be customized via OTP memory. Somehow the value for R19, which decide if the flag is set on read or write operation, seems to have been overwritten for the chip the original patch were written for. Revert the change to follow the default behavior. Signed-off-by: Marcus Folkesson Link: https://patch.msgid.link/20251124-da9052-revert-v1-1-fbeb2c894002@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 2a99af226fbbb7a950701604e6b31b3af3a79d98 Author: Xu Yang Date: Tue Jan 20 19:17:12 2026 +0800 phy: fsl-imx8mq-usb: disable bind/unbind platform driver feature [ Upstream commit 27ee0869d77b2cb404770ac49bdceae3aedf658b ] Disabling PHYs in runtime usually causes the client with external abort exception or similar issue due to lack of API to notify clients about PHY removal. This patch removes the possibility to unbind i.MX PHY drivers in runtime. Signed-off-by: Xu Yang Reviewed-by: Frank Li Link: https://patch.msgid.link/20260120111712.3159782-1-xu.yang_2@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c3be09c3c85bd42a1b0812df8986c249dfdebc7d Author: Aleksandar Gerasimovski Date: Tue Jan 6 15:06:43 2026 +0000 phy: mvebu-cp110-utmi: fix dr_mode property read from dts [ Upstream commit e2ce913452ab56b3330539cc443b97b7ea8c3a1a ] The problem with the current implementation is that it does not consider that the USB controller can have multiple PHY handles with different arguments count, as for example we have in our cn9131 based platform: "phys = <&cp0_comphy1 0>, <&cp0_utmi0>;". In such case calling "of_usb_get_dr_mode_by_phy" with -1 (no phy-cells) leads to not proper phy detection, taking the "marvell,cp110-utmi-phy" dts definition we can call the "of_usb_get_dr_mode_by_phy" with 0 (#phy-cells = <0>) and safely look for that phy. Signed-off-by: Aleksandar Gerasimovski Link: https://patch.msgid.link/20260106150643.922110-1-aleksandar.gerasimovski@belden.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c3beae1bed61d86510023f4a469fd89d8476e350 Author: Rafael J. Wysocki Date: Mon Dec 22 21:09:22 2025 +0100 watchdog: rzv2h_wdt: Discard pm_runtime_put() return value [ Upstream commit 2dea984a74265a67e3210f818416a83b87f70200 ] Failing device probe due to pm_runtime_put() returning an error is not particularly useful. Returning an error code from pm_runtime_put() merely means that it has not queued up a work item to check whether or not the device can be suspended and there are many perfectly valid situations in which that can happen, like after writing "on" to the devices' runtime PM "control" attribute in sysfs for one example. It also happens when the kernel is configured with CONFIG_PM unset. Accordingly, update rzt2h_wdt_wdtdcr_init() to simply discard the return value of pm_runtime_put() and return success to the caller after invoking that function. This will facilitate a planned change of the pm_runtime_put() return type to void in the future. Signed-off-by: Rafael J. Wysocki Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit d6014855a2cbaf2f284b97cb5a39b96f17214a2c Author: Oleksandr Suvorov Date: Sun Nov 23 22:24:33 2025 +0200 watchdog: imx7ulp_wdt: handle the nowayout option [ Upstream commit d303d37ef5cf86c8c3b2daefd2a7d7fd8ca1ec14 ] The module parameter `nowayout` indicates whether the watchdog should ever be allowed to stop, but the driver currently ignores this option. Pass the `nowayout` parameter to the watchdog core by setting the WDOG_NO_WAY_OUT flag accordingly. Signed-off-by: Oleksandr Suvorov Reviewed-by: Guenter Roeck Reviewed-by: Frank Li Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 17de6ad1c32bfd6a3933e51134a7714af72591b3 Author: Thomas Weißschuh Date: Wed Jan 7 15:29:50 2026 +0100 binder: don't use %pK through printk [ Upstream commit 56d21267663bad91e8b10121224ec46366a7937e ] In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh Acked-by: Carlos Llamas Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260107-restricted-pointers-binder-v1-1-181018bf3812@linutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5b3350e036670260002c80fb245e8faffbdf0e6f Author: René Rebe Date: Mon Nov 17 13:11:24 2025 +0100 fix it87_wdt early reboot by reporting running timer [ Upstream commit 88b2ab346436f799b99894a3e9518a3ffa344524 ] Some products, such as the Ugreen DXP4800 Plus NAS, ship with the it87 wdt enabled by the firmware and a broken BIOS option that does not allow to change the time or turn it off. As this makes installing Linux rather difficult, change the it87_wdt to report it running to the watchdog core. Signed-off-by: René Rebe Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 812e5d3bcc1eab4a512736fee9ebfef1c45cf31b Author: Moteen Shah Date: Mon Jan 12 13:48:29 2026 +0530 serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA termination is done [ Upstream commit a5fd8945a478ff9be14812693891d7c9b4185a50 ] Clear rx_running flag only after DMA teardown polling completes. In the previous implementation the flag was being cleared while hardware teardown was still in progress, creating a mismatch between software state (flag = 0, "ready") and hardware state (still terminating). Signed-off-by: Moteen Shah Link: https://patch.msgid.link/20260112081829.63049-3-m-shah@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cbe7f4bc2dc1596b0c05b3ce94ba56e683fbaa0a Author: Moteen Shah Date: Mon Jan 12 13:48:28 2026 +0530 serial: 8250: 8250_omap.c: Add support for handling UART error conditions [ Upstream commit 623b07b370e9963122d167e04fdc1dc713ebfbaf ] The DMA IRQ handler does not accounts for the overrun(OE) or any other errors being reported by the IP before triggering a DMA transaction which leads to the interrupts not being handled resulting into an IRQ storm. The way to handle OE is to: 1. Reset the RX FIFO. 2. Read the UART_RESUME register, which clears the internal flag Earlier, the driver issued DMA transations even in case of OE which shouldn't be done according to the OE handling mechanism mentioned above, as we are resetting the FIFO's, refer section: "12.1.6.4.8.1.3.6 Overrun During Receive" [0]. [0] https://www.ti.com/lit/pdf/spruiu1 Signed-off-by: Moteen Shah Link: https://patch.msgid.link/20260112081829.63049-2-m-shah@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit af48c1a0abe849e167fc754b6c260b6d8350b6fd Author: Diksha Kumari Date: Tue Jan 13 14:47:12 2026 +0530 staging: rtl8723bs: fix memory leak on failure path [ Upstream commit abe850d82c8cb72d28700673678724e779b1826e ] cfg80211_inform_bss_frame() may return NULL on failure. In that case, the allocated buffer 'buf' is not freed and the function returns early, leading to potential memory leak. Fix this by ensuring that 'buf' is freed on both success and failure paths. Signed-off-by: Diksha Kumari Reviewed-by: Mukesh Kumar Chaurasiya Link: https://patch.msgid.link/20260113091712.7071-1-dikshakdevgan@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f4fbf2d4750d12ac8525d2efac1016fa0d84d4ec Author: Mario Peter Date: Thu Jan 8 16:59:02 2026 +0000 usb: chipidea: udc: fix DMA and SG cleanup in _ep_nuke() [ Upstream commit cea2a1257a3b5ea3e769a445b34af13e6aa5a123 ] The ChipIdea UDC driver can encounter "not page aligned sg buffer" errors when a USB device is reconnected after being disconnected during an active transfer. This occurs because _ep_nuke() returns requests to the gadget layer without properly unmapping DMA buffers or cleaning up scatter-gather bounce buffers. Root cause: When a disconnect happens during a multi-segment DMA transfer, the request's num_mapped_sgs field and sgt.sgl pointer remain set with stale values. The request is returned to the gadget driver with status -ESHUTDOWN but still has active DMA state. If the gadget driver reuses this request on reconnect without reinitializing it, the stale DMA state causes _hardware_enqueue() to skip DMA mapping (seeing non-zero num_mapped_sgs) and attempt to use freed/invalid DMA addresses, leading to alignment errors and potential memory corruption. The normal completion path via _hardware_dequeue() properly calls usb_gadget_unmap_request_by_dev() and sglist_do_debounce() before returning the request. The _ep_nuke() path must do the same cleanup to ensure requests are returned in a clean, reusable state. Fix: Add DMA unmapping and bounce buffer cleanup to _ep_nuke() to mirror the cleanup sequence in _hardware_dequeue(): - Call usb_gadget_unmap_request_by_dev() if num_mapped_sgs is set - Call sglist_do_debounce() with copy=false if bounce buffer exists This ensures that when requests are returned due to endpoint shutdown, they don't retain stale DMA mappings. The 'false' parameter to sglist_do_debounce() prevents copying data back (appropriate for shutdown path where transfer was aborted). Signed-off-by: Mario Peter Reviewed-by: Xu Yang Acked-by: Peter Chen Link: https://patch.msgid.link/20260108165902.795354-1-mario.peter@leica-geosystems.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7a8ac86f5133c7efdd372adfdc01e7863b15055d Author: Sam Day Date: Thu Jan 8 08:30:20 2026 +1000 usb: gadget: f_fs: Fix ioctl error handling [ Upstream commit 8e4c1d06183c25022f6b0002a5cab84979ca6337 ] When ffs_epfile_ioctl handles FUNCTIONFS_DMABUF_* ioctls, it's currently falling through when copy_from_user fails. However, this fallthrough isn't being checked properly, so the handler continues executing further than it should. It then tries the secondary dispatch where it ultimately gives up and returns -ENOTTY. The end result is invalid ioctl invocations will yield a -ENOTTY rather than an -EFAULT. It's a common pattern elsewhere in the kernel code to directly return -EFAULT when copy_from_user fails. So we update ffs_epfile_ioctl to do the same and fix this issue. Signed-off-by: Sam Day Link: https://patch.msgid.link/20260108-ffs-dmabuf-ioctl-fix-v1-1-e51633891a81@samcday.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 09820593b5069bcd620a1c4043dd1a5cf200f007 Author: Sam Day Date: Thu Jan 8 08:30:21 2026 +1000 usb: gadget: f_fs: fix DMA-BUF OUT queues [ Upstream commit 0145e7acd29855dfba4a2f387d455b5d9a520f0e ] Currently, DMA_FROM_DEVICE is used when attaching DMABUFs to IN endpoints and DMA_TO_DEVICE for OUT endpoints. This is inverted from how it should be. The result is IOMMU read-only mappings placed on OUT queues, triggering arm-smmu write faults. Put differently, OUT endpoints flow data from host -> gadget, meaning the UDC peripheral needs to have write access to the buffer to fill it with the incoming data. This commit flips the directions and updates the implicit-sync helpers so IN endpoints act as readers and OUT endpoints as writers. Signed-off-by: Sam Day Tested-by: David Heidelberg # OnePlus 6T on sdm845-next-20251119 Link: https://patch.msgid.link/20260108-ffs-dmabuf-ioctl-fix-v1-2-e51633891a81@samcday.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2de2659c206bc349c70e77fc4c1c397833763383 Author: Derek J. Clark Date: Tue Jan 6 05:45:19 2026 +0000 iio: bmi270_i2c: Add MODULE_DEVICE_TABLE for BMI260/270 [ Upstream commit f69b5ac682dbc61e6aca806c22ce2ae74d598e45 ] Currently BMI260 & BMI270 devices do not automatically load this driver. To fix this, add missing MODULE_DEVICE_TABLE for the i2c, acpi, and of device tables so the driver will load when the hardware is detected. Tested on my OneXPlayer F1 Pro. Signed-off-by: Derek J. Clark Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit e86bc719b06185aa86468850c0740325a68b6987 Author: Cosmin Tanislav Date: Fri Dec 5 17:02:28 2025 +0200 pinctrl: renesas: rzt2h: Allow .get_direction() for IRQ function GPIOs [ Upstream commit 49b039a61a314c18074c15a7047705399e1240e6 ] Setting up an IRQ would normally be done in the .activate() and .deactivate() ops of the IRQ domain, but for hierarchical IRQ domains the .activate() and .deactivate() ops are overridden in the gpiochip_hierarchy_setup_domain_ops() function. As such, activating and deactivating need to be done in the .translate() and .free() ops of the IRQ domain. For RZ/T2H and RZ/N2H, interrupts go through the pin controller, into the ICU, which level-translates them and forwards them to the GIC. To use a GPIO as an interrupt it needs to be put into peripheral function mode 0, which will connect it to the IRQ lines of the ICU. The IRQ chip .child_to_parent_hwirq() callback is called as part of the IRQ fwspec parsing logic (as part of irq_create_of_mapping()) which happens before the IRQ is requested (as part of gpiochip_lock_as_irq()). gpiochip_lock_as_irq() calls gpiod_get_direction() if the .get_direction() callback is provided to ensure that the GPIO line is set up as input. In our case, IRQ function is separate from GPIO, and both cannot be true at the same time. Return GPIO_LINE_DIRECTION_IN even if pin is in IRQ function to allow this setup to work. Hold the spinlock to ensure atomicity between reading the PMC register (which determines whether the pin is in GPIO mode or not) and reading the function of the pin when it is not in GPIO mode. Signed-off-by: Cosmin Tanislav Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251205150234.2958140-3-cosmin-gabriel.tanislav.xa@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit d2975604bf1ba36ffc5a08fe8da97fd63b91c4f1 Author: Felix Gu Date: Fri Dec 26 18:22:43 2025 +0800 misc: ti_fpc202: fix a potential memory leak in probe function [ Upstream commit dad9f13d967b4e53e8eaf5f9c690f8e778ad9802 ] Use for_each_child_of_node_scoped() to simplify the code and ensure the device node reference is automatically released when the loop scope ends. Signed-off-by: Felix Gu Reviewed-by: Romain Gantois Link: https://patch.msgid.link/tencent_FA1AC670F5CF49873F88A44424F866994A08@qq.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b6cfbd47015839916a442023d4eb9e3c683df610 Author: Markus Perkins Date: Tue Dec 2 11:48:24 2025 +0100 misc: eeprom: Fix EWEN/EWDS/ERAL commands for 93xx56 and 93xx66 [ Upstream commit b54c82d6cbfc76647ba558e8e3647eb2b0ba0e2b ] commit 14374fbb3f06 ("misc: eeprom_93xx46: Add new 93c56 and 93c66 compatible strings") added support for 93xx56 and 93xx66 eeproms, but didn't take into account that the write enable/disable + erase all commands are hardcoded for the 6-bit address of the 93xx46. This commit fixes the command word generation by increasing the number of shifts as the address field grows, keeping the command intact. Also, the check for 8-bit or 16-bit mode is no longer required as this is already taken into account in the edev->addrlen field. Signed-off-by: Markus Perkins Link: https://patch.msgid.link/20251202104823.429869-3-markus@notsyncing.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 822019d7516b35311827e15542cb1c67a6ea0adf Author: Liang Jie Date: Tue Dec 9 18:02:17 2025 +0800 pinctrl: mediatek: make devm allocations safer and clearer in mtk_eint_do_init() [ Upstream commit 255b721c96046d4c57fa2268e4c72607868ce91f ] mtk_eint_do_init() allocates several pointer arrays which are then populated in a per-instance loop and freed on error. The arrays are currently allocated with devm_kmalloc(), so their entries are left uninitialised until the per-instance allocations succeed. On a failure in the middle of the loop, the error path iterates over the full nbase range and calls devm_kfree() on each element. For indices which were never initialised, the corresponding array entries contain stack garbage. If any of those happen to be non-zero, devm_kfree() will pass them to devres_destroy(), which will WARN because there is no matching devm_kmalloc() resource for such bogus pointers. Improve the robustness and readability by: - Using devm_kcalloc() for the pointer arrays so that all entries start as NULL, ensuring that only genuinely initialised elements may be freed and preventing spurious WARN_ON()s in the error path. - Switching the allocations to sizeof(*ptr) / sizeof(**ptr) forms, avoiding hard-coded element types and making the code more resilient to future type changes. - Dropping the redundant NULL checks before devm_kfree(), as devm_kfree() safely handles NULL pointers. The functional behaviour in the successful initialisation path remains unchanged, while the error handling becomes simpler and less error-prone. Reviewed-by: fanggeng Signed-off-by: Liang Jie Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 3842f93e6e29d5cc1dcb9e5bda70587b444bed69 Author: Tuo Li Date: Thu Dec 11 14:36:37 2025 +0800 misc: bcm_vk: Fix possible null-pointer dereferences in bcm_vk_read() [ Upstream commit ba75ecb97d3f4e95d59002c13afb6519205be6cb ] In the function bcm_vk_read(), the pointer entry is checked, indicating that it can be NULL. If entry is NULL and rc is set to -EMSGSIZE, the following code may cause null-pointer dereferences: struct vk_msg_blk tmp_msg = entry->to_h_msg[0]; set_msg_id(&tmp_msg, entry->usr_msg_id); tmp_msg.size = entry->to_h_blks - 1; To prevent these possible null-pointer dereferences, copy to_h_msg, usr_msg_id, and to_h_blks from iter into temporary variables, and return these temporary variables to the application instead of accessing them through a potentially NULL entry. Signed-off-by: Tuo Li Reviewed-by: Scott Branden Link: https://patch.msgid.link/20251211063637.3987937-1-islituo@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4e033a7215df38f541a4823a26505a09d404d9ea Author: Thomas Richard (TI.com) Date: Tue Dec 16 15:24:25 2025 +0100 phy: cadence-torrent: restore parent clock for refclk during resume [ Upstream commit 434e1a0ee145d0389b192252be4c993f86cf1134 ] While suspend and resume, parent clock config for refclk was getting lost. So save and restore it in suspend and resume operations. Reviewed-by: Neil Armstrong Signed-off-by: Thomas Richard (TI.com) Link: https://patch.msgid.link/20251216-phy-cadence-torrent-resume-restore-refclk-parent-v3-1-8a7ed84b47e3@bootlin.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4842c87399612b1c051d94a644407e1b186bef86 Author: Thomas Richard (TI.com) Date: Tue Dec 16 15:26:20 2025 +0100 phy: ti: phy-j721e-wiz: restore mux selection during resume [ Upstream commit 53f6240e88c9e8715e09fc19942f13450db4cb33 ] While suspend and resume mux selection was getting lost. So save and restore these values in suspend and resume operations. Signed-off-by: Thomas Richard (TI.com) Link: https://patch.msgid.link/20251216-phy-ti-phy-j721e-wiz-resume-restore-mux-sel-v1-1-771d564db966@bootlin.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a6e099cda247399a4dc524ce3efead887cbe5ca6 Author: Clément Le Goffic Date: Wed Dec 17 09:15:03 2025 +0100 dmaengine: stm32-mdma: initialize m2m_hw_period and ccr to fix warnings [ Upstream commit aaf3bc0265744adbc2d364964ef409cf118d193d ] m2m_hw_period is initialized only when chan_config->m2m_hw is true. This triggers a warning: ‘m2m_hw_period’ may be used uninitialized [-Wmaybe-uninitialized] Although m2m_hw_period is only used when chan_config->m2m_hw is true and ignored otherwise, initialize it unconditionally to 0. ccr is initialized by stm32_mdma_set_xfer_param() when the sg list is not empty. This triggers a warning: ‘ccr’ may be used uninitialized [-Wmaybe-uninitialized] Indeed, it could be used uninitialized if the sg list is empty. Initialize it to 0. Signed-off-by: Clément Le Goffic Reviewed-by: Clément Le Goffic Signed-off-by: Amelie Delaunay Link: https://patch.msgid.link/20251217-mdma_warnings_fix-v2-1-340200e0bb55@foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit bc25f81a3f6e478d815b545a855849dd81e8a233 Author: Chen-Yu Tsai Date: Sun Dec 21 16:04:48 2025 +0800 dmaengine: sun6i: Choose appropriate burst length under maxburst [ Upstream commit 7178c3586ab42693b28bb81014320a7783e5c435 ] maxburst, as provided by the client, specifies the largest amount of data that is allowed to be transferred in one burst. This limit is normally provided to avoid a data burst overflowing the target FIFO. It does not mean that the DMA engine can only do bursts in that size. Let the driver pick the largest supported burst length within the given limit. This lets the driver work correctly with some clients that give a large maxburst value. In particular, the 8250_dw driver will give a quarter of the UART's FIFO size as maxburst. On some systems the FIFO size is 256 bytes, giving a maxburst of 64 bytes, while the hardware only supports bursts of up to 16 bytes. Signed-off-by: Chen-Yu Tsai Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20251221080450.1813479-1-wens@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit af0b99b2214a10554adb5b868240d23af6e64e71 Author: Navaneeth K Date: Thu Nov 27 16:53:37 2025 +0000 most: core: fix resource leak in most_register_interface error paths [ Upstream commit 1f4c9d8a1021281750c6cda126d6f8a40cc24e71 ] The function most_register_interface() did not correctly release resources if it failed early (before registering the device). In these cases, it returned an error code immediately, leaking the memory allocated for the interface. Fix this by initializing the device early via device_initialize() and calling put_device() on all error paths. The most_register_interface() is expected to call put_device() on error which frees the resources allocated in the caller. The put_device() either calls release_mdev() or dim2_release(), depending on the caller. Switch to using device_add() instead of device_register() to handle the split initialization. Acked-by: Abdun Nihaal Signed-off-by: Navaneeth K Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20251127165337.19172-1-knavaneeth786@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f907623616f7f8aa22c8c80ad49e4e02fa2e5740 Author: Romain Gantois Date: Thu Nov 27 16:58:48 2025 +0100 fpga: of-fpga-region: Fail if any bridge is missing [ Upstream commit c141c8221bc5089de915d9f26044df892c343c7e ] When parsing the region bridge list from the "fpga-bridges" device tree property, the of-fpga-region driver will silently ignore bridges which fail to be obtained, for example due to a missing bridge driver or invalid phandle. This can lead to hardware issues if a region bridge stays coupled when partial programming is performed. Fail if any of the bridges specified in "fpga-bridges" cannot be obtained. Signed-off-by: Romain Gantois Link: https://lore.kernel.org/r/20251127-of-fpga-region-fail-if-bridges-not-found-v1-1-ca674f8d07eb@bootlin.com Reviewed-by: Xu Yilun Signed-off-by: Xu Yilun Signed-off-by: Sasha Levin commit 2433adbe30bfa8eb2314bf84c91de8e2fa6088a8 Author: Benson Leung Date: Mon Dec 8 17:48:48 2025 +0000 usb: typec: ucsi: psy: Fix voltage and current max for non-Fixed PDOs [ Upstream commit 6811e0a08bdce6b2767414caf17fda24c2e4e032 ] ucsi_psy_get_voltage_max and ucsi_psy_get_current_max are calculated using whichever pdo is in the last position of the src_pdos array, presuming it to be a fixed pdo, so the pdo_fixed_voltage or pdo_max_current helpers are used on that last pdo. However, non-Fixed PDOs such as Battery PDOs, Augmented PDOs (used for AVS and for PPS) may exist, and are always at the end of the array if they do. In the event one of these more advanced chargers are attached the helpers for fixed return mangled values. Here's an example case of a Google Pixel Flex Dual Port 67W USB-C Fast Charger with PPS support: POWER_SUPPLY_NAME=ucsi-source-psy-cros_ec_ucsi.4.auto2 POWER_SUPPLY_TYPE=USB POWER_SUPPLY_CHARGE_TYPE=Standard POWER_SUPPLY_USB_TYPE=C [PD] PD_PPS PD_DRP POWER_SUPPLY_ONLINE=1 POWER_SUPPLY_VOLTAGE_MIN=5000000 POWER_SUPPLY_VOLTAGE_MAX=13400000 POWER_SUPPLY_VOLTAGE_NOW=20000000 POWER_SUPPLY_CURRENT_MAX=5790000 POWER_SUPPLY_CURRENT_NOW=3250000 Voltage Max is reading as 13.4V, but that's an incorrect decode of the PPS APDO in the last position. Same goes for CURRENT_MAX. 5.79A is incorrect. Instead, enumerate through the src_pdos and filter just for Fixed PDOs for now, and find the one with the highest voltage and current respectively. After, from the same charger: POWER_SUPPLY_NAME=ucsi-source-psy-cros_ec_ucsi.4.auto2 POWER_SUPPLY_TYPE=USB POWER_SUPPLY_CHARGE_TYPE=Standard POWER_SUPPLY_USB_TYPE=C [PD] PD_PPS PD_DRP POWER_SUPPLY_ONLINE=1 POWER_SUPPLY_VOLTAGE_MIN=5000000 POWER_SUPPLY_VOLTAGE_MAX=20000000 POWER_SUPPLY_VOLTAGE_NOW=20000000 POWER_SUPPLY_CURRENT_MAX=4000000 POWER_SUPPLY_CURRENT_NOW=3250000 Signed-off-by: Benson Leung Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20251208174918.289394-3-bleung@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 006470339240cec20873c630375df73b7e739553 Author: Artem Shimko Date: Tue Nov 4 17:54:25 2025 +0300 serial: 8250_dw: handle clock enable errors in runtime_resume [ Upstream commit d31228143a489ba6ba797896a07541ce06828c09 ] Add error checking for clk_prepare_enable() calls in dw8250_runtime_resume(). Currently if either clock fails to enable, the function returns success while leaving clocks in inconsistent state. This change implements comprehensive error handling by checking the return values of both clk_prepare_enable() calls. If the second clock enable operation fails after the first clock has already been successfully enabled, the code now properly cleans up by disabling and unpreparing the first clock before returning. The error code is then propagated to the caller, ensuring that clock enable failures are properly reported rather than being silently ignored. Signed-off-by: Artem Shimko Link: https://patch.msgid.link/20251104145433.2316165-2-a.shimko.dev@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 31dcb6316e2502db7ed9d8d8af5cd95377df6399 Author: Liang Jie Date: Mon Dec 8 17:27:28 2025 +0800 staging: rtl8723bs: fix missing status update on sdio_alloc_irq() failure [ Upstream commit 618b4aec12faabc7579a6b0df046842d798a4c7c ] The return value of sdio_alloc_irq() was not stored in status. If sdio_alloc_irq() fails after rtw_drv_register_netdev() succeeds, status remains _SUCCESS and the error path skips resource cleanup, while rtw_drv_init() still returns success. Store the return value of sdio_alloc_irq() in status and reuse the existing error handling which relies on status. Reviewed-by: fanggeng Signed-off-by: Liang Jie Link: https://patch.msgid.link/20251208092730.262499-1-buaajxlj@163.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 487e455643c041148ab7e6820722c026fbc8380f Author: Maciej Strozek Date: Mon Dec 15 15:17:29 2025 +0000 soundwire: intel_auxdevice: add cs42l45 codec to wake_capable_list [ Upstream commit f87e5575a6bd1925cd55f500b61b661724372e5f ] Add cs42l45 to the wake_capable_list because it can generate jack events whilst the bus is stopped. Signed-off-by: Maciej Strozek Reviewed-by: Bard Liao Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20251215151729.3911077-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c7ed6e59a58c778eed223d8f5f2598667eb8074f Author: Peter Ujfalusi Date: Mon Dec 15 15:09:47 2025 +0200 soundwire: dmi-quirks: add mapping for Avell B.ON (OEM rebranded of NUC15) [ Upstream commit 59946373755d71dbd7614ba235e0093159f80b69 ] Avell B.ON is an OEM re-branded NUC15 'Bishop County' LAPBC510 and LAPBC710. Link: https://github.com/thesofproject/linux/issues/5529 Signed-off-by: Peter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Link: https://patch.msgid.link/20251215130947.31385-1-peter.ujfalusi@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit e7e5f19998a9f064963bc0c3a2aa98b2d1519444 Author: Amelie Delaunay Date: Fri Nov 21 14:36:56 2025 +0100 dmaengine: stm32-dma3: use module_platform_driver [ Upstream commit 0d41ed4ea496fabbb4dc21171e32d9a924c2a661 ] Without module_platform_driver(), stm32-dma3 doesn't have a module_exit procedure. Once stm32-dma3 module is inserted, it can't be removed, marked busy. Use module_platform_driver() instead of subsys_initcall() to register (insmod) and unregister (rmmod) stm32-dma3 driver. Reviewed-by: Eugen Hristev Signed-off-by: Amelie Delaunay Link: https://patch.msgid.link/20251121-dma3_improv-v2-1-76a207b13ea6@foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 59e7707492576bdbfa8c1dbe7d90791df31e4773 Author: Stefano Stabellini Date: Thu Jan 29 15:03:48 2026 -0800 9p/xen: protect xen_9pfs_front_free against concurrent calls [ Upstream commit ce8ded2e61f47747e31eeefb44dc24a2160a7e32 ] The xenwatch thread can race with other back-end change notifications and call xen_9pfs_front_free() twice, hitting the observed general protection fault due to a double-free. Guard the teardown path so only one caller can release the front-end state at a time, preventing the crash. This is a fix for the following double-free: [ 27.052347] Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 27.052357] CPU: 0 UID: 0 PID: 32 Comm: xenwatch Not tainted 6.18.0-02087-g51ab33fc0a8b-dirty #60 PREEMPT(none) [ 27.052363] RIP: e030:xen_9pfs_front_free+0x1d/0x150 [ 27.052368] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 41 55 41 54 55 48 89 fd 48 c7 c7 48 d0 92 85 53 e8 cb cb 05 00 48 8b 45 08 48 8b 55 00 <48> 3b 28 0f 85 f9 28 35 fe 48 3b 6a 08 0f 85 ef 28 35 fe 48 89 42 [ 27.052377] RSP: e02b:ffffc9004016fdd0 EFLAGS: 00010246 [ 27.052381] RAX: 6b6b6b6b6b6b6b6b RBX: ffff88800d66e400 RCX: 0000000000000000 [ 27.052385] RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000000 RDI: 0000000000000000 [ 27.052389] RBP: ffff88800a887040 R08: 0000000000000000 R09: 0000000000000000 [ 27.052393] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888009e46b68 [ 27.052397] R13: 0000000000000200 R14: 0000000000000000 R15: ffff88800a887040 [ 27.052404] FS: 0000000000000000(0000) GS:ffff88808ca57000(0000) knlGS:0000000000000000 [ 27.052408] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 27.052412] CR2: 00007f9714004360 CR3: 0000000004834000 CR4: 0000000000050660 [ 27.052418] Call Trace: [ 27.052420] [ 27.052422] xen_9pfs_front_changed+0x5d5/0x720 [ 27.052426] ? xenbus_otherend_changed+0x72/0x140 [ 27.052430] ? __pfx_xenwatch_thread+0x10/0x10 [ 27.052434] xenwatch_thread+0x94/0x1c0 [ 27.052438] ? __pfx_autoremove_wake_function+0x10/0x10 [ 27.052442] kthread+0xf8/0x240 [ 27.052445] ? __pfx_kthread+0x10/0x10 [ 27.052449] ? __pfx_kthread+0x10/0x10 [ 27.052452] ret_from_fork+0x16b/0x1a0 [ 27.052456] ? __pfx_kthread+0x10/0x10 [ 27.052459] ret_from_fork_asm+0x1a/0x30 [ 27.052463] [ 27.052465] Modules linked in: [ 27.052471] ---[ end trace 0000000000000000 ]--- Signed-off-by: Stefano Stabellini Message-ID: <20260129230348.2390470-1-stefano.stabellini@amd.com> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 80a27fb114f77153ac22cf4ef23def37bab2db3a Author: Daniel Palmer Date: Sat Dec 13 21:04:01 2025 +0900 m68k: nommu: fix memmove() with differently aligned src and dest for 68000 [ Upstream commit 590fe2f46c8698bb758f9002cb247ca10ce95569 ] 68000 has different alignment needs to 68020+. memcpy() checks if the destination is aligned and does a smaller copy to fix the alignment and then critically for 68000 it checks if the source is still unaligned and if it is reverts to smaller copies. memmove() does not currently do the second part and malfunctions if one of the pointers is aligned and the other isn't. This is apparently getting triggered by printk. If I put breakpoints into the new checks added by this commit the first hit looks like this: memmove (n=205, src=0x2f3971 , dest=0x2f3980 ) at arch/m68k/lib/memmove.c:82 Signed-off-by: Daniel Palmer Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit 479937252f44b184b4ce71e88b2e1da76db200c2 Author: Daniel Peng Date: Mon Nov 17 17:40:41 2025 +0800 HID: i2c-hid: Add FocalTech FT8112 [ Upstream commit 3d9586f1f90c9101b1abf5b0e9d70ca45f5f16db ] Information for touchscreen model HKO/RB116AS01-2 as below: - HID :FTSC1000 - slave address:0X38 - Interface:HID over I2C - Touch control lC:FT8112 - I2C ID: PNP0C50 Signed-off-by: Daniel Peng Acked-by: Jiri Kosina Reviewed-by: Douglas Anderson Link: https://patch.msgid.link/20251117094041.300083-2-Daniel_Peng@pegatron.corp-partner.google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 534dbb6422f9a71cc67ca3b5ff74169140021144 Author: Brian Masney Date: Fri Dec 5 14:46:28 2025 -0500 clk: microchip: core: correct return value on *_get_parent() [ Upstream commit 5df96d141cccb37f0c3112a22fc1112ea48e9246 ] roclk_get_parent() and sclk_get_parent() has the possibility of returning -EINVAL, however the framework expects this call to always succeed since the return value is unsigned. If there is no parent map defined, then the current value programmed in the hardware is used. Let's use that same value in the case where -EINVAL is currently returned. This index is only used by clk_core_get_parent_by_index(), and it validates that it doesn't overflow the number of available parents. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202512050233.R9hAWsJN-lkp@intel.com/ Signed-off-by: Brian Masney Reviewed-by: Claudiu Beznea Link: https://lore.kernel.org/r/20251205-clk-microchip-fixes-v3-2-a02190705e47@redhat.com Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit 8d35f60ff0dc420a4a4c0ac9449e92d7dac81216 Author: Biju Das Date: Thu Jan 8 12:34:27 2026 +0000 clk: renesas: rzg2l: Deassert reset on assert timeout [ Upstream commit 0b0201f259e1158a875c5fd01adf318ae5d32352 ] If the assert() fails due to timeout error, set the reset register bit back to deasserted state. This change is needed especially for handling assert error in suspend() callback that expect the device to be in operational state in case of failure. Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260108123433.104464-2-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit f990244e0f07e813735773107e6d7b82b30a7517 Author: Chuan Liu Date: Fri Sep 19 13:59:01 2025 +0800 clk: amlogic: remove potentially unsafe flags from S4 video clocks [ Upstream commit 4aca7e92023cac5018b4053bae324450f884c937 ] The video clocks enci, encp, vdac and hdmitx share the same clock source. Adding CLK_SET_RATE_PARENT to the mux may unintentionally change the shared parent clock, which could affect other video clocks. Signed-off-by: Chuan Liu Link: https://lore.kernel.org/r/20250919-add_video_clk-v6-3-fe223161fb3f@amlogic.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit 803e99ee0d6070df4f801db2df6ce1c5cea127eb Author: Otto Pflüger Date: Sat Jan 10 16:43:36 2026 +0100 mailbox: sprd: clear delivery flag before handling TX done [ Upstream commit c77661d60d4223bf2ff10d409beb0c3b2021183b ] If there are any pending messages in the mailbox queue, they are sent as soon as a TX done event arrives from the driver. This may trigger a new delivery interrupt while the previous one is still being handled. If the delivery status is cleared after this, the interrupt is lost. To prevent this from happening, clear the delivery status immediately after checking it and before any new messages are sent. Signed-off-by: Otto Pflüger Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit c6bc63adddc35fd14c7e91b29d5afbfcd190544a Author: Tzung-Bi Shih Date: Mon Jan 12 11:07:55 2026 +0000 remoteproc: mediatek: Break lock dependency to `prepare_lock` [ Upstream commit d935187cfb27fc4168f78f3959aef4eafaae76bb ] A potential circular locking dependency (ABBA deadlock) exists between `ec_dev->lock` and the clock framework's `prepare_lock`. The first order (A -> B) occurs when scp_ipi_send() is called while `ec_dev->lock` is held (e.g., within cros_ec_cmd_xfer()): 1. cros_ec_cmd_xfer() acquires `ec_dev->lock` and calls scp_ipi_send(). 2. scp_ipi_send() calls clk_prepare_enable(), which acquires `prepare_lock`. See #0 in the following example calling trace. (Lock Order: `ec_dev->lock` -> `prepare_lock`) The reverse order (B -> A) is more complex and has been observed (learned) by lockdep. It involves the clock prepare operation triggering power domain changes, which then propagates through sysfs and power supply uevents, eventually calling back into the ChromeOS EC driver and attempting to acquire `ec_dev->lock`: 1. Something calls clk_prepare(), which acquires `prepare_lock`. It then triggers genpd operations like genpd_runtime_resume(), which takes `&genpd->mlock`. 2. Power domain changes can trigger regulator changes; regulator changes can then trigger device link changes; device link changes can then trigger sysfs changes. Eventually, power_supply_uevent() is called. 3. This leads to calls like cros_usbpd_charger_get_prop(), which calls cros_ec_cmd_xfer_status(), which then attempts to acquire `ec_dev->lock`. See #1 ~ #6 in the following example calling trace. (Lock Order: `prepare_lock` -> `&genpd->mlock` -> ... -> `&ec_dev->lock`) Move the clk_prepare()/clk_unprepare() operations for `scp->clk` to the remoteproc prepare()/unprepare() callbacks. This ensures `prepare_lock` is only acquired in prepare()/unprepare() callbacks. Since `ec_dev->lock` is not involved in the callbacks, the dependency loop is broken. This means the clock is always "prepared" when the SCP is running. The prolonged "prepared time" for the clock should be acceptable as SCP is designed to be a very power efficient processor. The power consumption impact can be negligible. A simplified calling trace reported by lockdep: > -> #6 (&ec_dev->lock) > cros_ec_cmd_xfer > cros_ec_cmd_xfer_status > cros_usbpd_charger_get_port_status > cros_usbpd_charger_get_prop > power_supply_get_property > power_supply_show_property > power_supply_uevent > dev_uevent > uevent_show > dev_attr_show > sysfs_kf_seq_show > kernfs_seq_show > -> #5 (kn->active#2) > kernfs_drain > __kernfs_remove > kernfs_remove_by_name_ns > sysfs_remove_file_ns > device_del > __device_link_del > device_links_driver_bound > -> #4 (device_links_lock) > device_link_remove > _regulator_put > regulator_put > -> #3 (regulator_list_mutex) > regulator_lock_dependent > regulator_disable > scpsys_power_off > _genpd_power_off > genpd_power_off > -> #2 (&genpd->mlock/1) > genpd_add_subdomain > pm_genpd_add_subdomain > scpsys_add_subdomain > scpsys_probe > -> #1 (&genpd->mlock) > genpd_runtime_resume > __rpm_callback > rpm_callback > rpm_resume > __pm_runtime_resume > clk_core_prepare > clk_prepare > -> #0 (prepare_lock) > clk_prepare > scp_ipi_send > scp_send_ipi > mtk_rpmsg_send > rpmsg_send > cros_ec_pkt_xfer_rpmsg Signed-off-by: Tzung-Bi Shih Reviewed-by: Chen-Yu Tsai Tested-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20260112110755.2435899-1-tzungbi@kernel.org Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 780185148d85caed21229c589f9617386fdd1299 Author: Otto Pflüger Date: Sat Jan 10 16:43:38 2026 +0100 mailbox: sprd: mask interrupts that are not handled [ Upstream commit 75df94d05fc03fd9d861eaf79ce10fbb7a548bd8 ] To reduce the amount of spurious interrupts, disable the interrupts that are not handled in this driver. Signed-off-by: Otto Pflüger Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit a60671946d85fbc3c1b7ae2487291596a5c9e2b1 Author: Valentina Fernandez Date: Thu Dec 18 10:33:59 2025 +0000 mailbox: mchp-ipc-sbi: fix uninitialized symbol and other smatch warnings [ Upstream commit bc4d17e495cd3b02bcb2e10f575763a5ff31f80b ] Fix uninitialized symbol 'hartid' warning in mchp_ipc_cluster_aggr_isr() by introducing a 'found' flag to track whether the IRQ matches any online hart. If no match is found, return IRQ_NONE. Also fix other smatch warnings by removing dead code in mchp_ipc_startup() and by returning -ENODEV in dev_err_probe() if the Microchip SBI extension is not found. Fixes below smatch warnings: drivers/mailbox/mailbox-mchp-ipc-sbi.c:187 mchp_ipc_cluster_aggr_isr() error: uninitialized symbol 'hartid'. drivers/mailbox/mailbox-mchp-ipc-sbi.c:324 mchp_ipc_startup() warn: ignoring unreachable code. drivers/mailbox/mailbox-mchp-ipc-sbi.c:422 mchp_ipc_probe() warn: passing zero to 'dev_err_probe' Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202512171533.CDLdScMY-lkp@intel.com/ Signed-off-by: Valentina Fernandez Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit cf66aae883a5d340ea1207b1dd7553353025c776 Author: Jacky Bai Date: Tue Dec 16 16:00:54 2025 +0800 mailbox: imx: Skip the suspend flag for i.MX7ULP [ Upstream commit 673b570825ace0dcb2ac0c676080559d505c6f40 ] In current imx-mailbox driver, the MU IRQ is configured with 'IRQF_NO_SUSPEND' flag set. So during linux suspend/resume flow, the MU IRQ is always enabled. With commit 892cb524ae8a ("mailbox: imx: fix wakeup failure from freeze mode"), if the MU IRQ is triggered after the priv->suspended flag has been set, the system suspend will be aborted. On i.MX7ULP platform, certain drivers that depend on rpmsg may need to send rpmsg request and receive an acknowledgment from the remote core during the late_suspend stage. Early suspend abort is not expected, and the i.MX7ULP already has additional hardware and software to make sure the system can be wakeup from freeze mode correctly when MU IRQ is trigger. Skip the 'suspend' flag handling logic on i.MX7ULP to avoid the early abort when doing suspend. Signed-off-by: Jacky Bai Reviewed-by: Peng Fan Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 2f41bbab5e326ba775e0104d7640de86d2041bcd Author: Mark Brown Date: Fri Jan 16 14:07:40 2026 +0000 mailbox: pcc: Remove spurious IRQF_ONESHOT usage [ Upstream commit 673327028cd61db68a1e0c708be2e302c082adf9 ] The PCC code currently specifies IRQF_ONESHOT if the interrupt could potentially be shared but doesn't actually use request_threaded_irq() and the interrupt handler does not use IRQ_WAKE_THREAD so IRQF_ONESHOT is never relevant. Since commit aef30c8d569c ("genirq: Warn about using IRQF_ONESHOT without a threaded handler") specifying it has resulted in a WARN_ON(), fix this by removing IRQF_ONESHOT. Reported-by: Aishwarya TCV Signed-off-by: Mark Brown Reviewed-by: Sudeep Holla Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 95438699c92947155823dcd3918049a07f3cd867 Author: Valentina Fernandez Date: Thu Nov 13 13:49:22 2025 +0000 mailbox: mchp-ipc-sbi: fix out-of-bounds access in mchp_ipc_get_cluster_aggr_irq() [ Upstream commit f7c330a8c83c9b0332fd524097eaf3e69148164d ] The cluster_cfg array is dynamically allocated to hold per-CPU configuration structures, with its size based on the number of online CPUs. Previously, this array was indexed using hartid, which may be non-contiguous or exceed the bounds of the array, leading to out-of-bounds access. Switch to using cpuid as the index, as it is guaranteed to be within the valid range provided by for_each_online_cpu(). Signed-off-by: Valentina Fernandez Reviewed-by: Conor Dooley Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit dd6c4b46320929e5f1b8fdd4fc1a87fb8d90f6c4 Author: Iuliana Prodan Date: Thu Dec 4 14:28:23 2025 +0200 remoteproc: imx_dsp_rproc: Skip RP_MBOX_SUSPEND_SYSTEM when mailbox TX channel is uninitialized [ Upstream commit d62e0e92e589c53c4320ed5914af5fe103f5ce7e ] Firmwares that do not use mailbox communication (e.g., the hello_world sample) leave priv->tx_ch as NULL. The current suspend logic unconditionally sends RP_MBOX_SUSPEND_SYSTEM, which is invalid without an initialized TX channel. Detect the no_mailboxes case early and skip sending the suspend message. Instead, proceed directly to the runtime PM suspend path, which is the correct behavior for firmwares that cannot respond to mailbox requests. Signed-off-by: Iuliana Prodan Link: https://lore.kernel.org/r/20251204122825.756106-1-iuliana.prodan@oss.nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 359ca3038b77bf4b598fbff1c910111f9cfc0e05 Author: Colin Lord Date: Mon Feb 9 23:48:10 2026 -0800 tracing: Fix false sharing in hwlat get_sample() [ Upstream commit f743435f988cb0cf1f521035aee857851b25e06d ] The get_sample() function in the hwlat tracer assumes the caller holds hwlat_data.lock, but this is not actually happening. The result is unprotected data access to hwlat_data, and in per-cpu mode can result in false sharing which may show up as false positive latency events. The specific case of false sharing observed was primarily between hwlat_data.sample_width and hwlat_data.count. These are separated by just 8B and are therefore likely to share a cache line. When one thread modifies count, the cache line is in a modified state so when other threads read sample_width in the main latency detection loop, they fetch the modified cache line. On some systems, the fetch itself may be slow enough to count as a latency event, which could set up a self reinforcing cycle of latency events as each event increments count which then causes more latency events, continuing the cycle. The other result of the unprotected data access is that hwlat_data.count can end up with duplicate or missed values, which was observed on some systems in testing. Convert hwlat_data.count to atomic64_t so it can be safely modified without locking, and prevent false sharing by pulling sample_width into a local variable. One system this was tested on was a dual socket server with 32 CPUs on each numa node. With settings of 1us threshold, 1000us width, and 2000us window, this change reduced the number of latency events from 500 per second down to approximately 1 event per minute. Some machines tested did not exhibit measurable latency from the false sharing. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260210074810.6328-1-clord@mykolab.com Signed-off-by: Colin Lord Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit d451a01c5a1432145b2973600564bb0c4f3dda08 Author: Sergey Matyukevich Date: Sun Jan 25 21:09:56 2026 -0700 riscv: vector: init vector context with proper vlenb [ Upstream commit ef3ff40346db8476a9ef7269fc9d1837e7243c40 ] The vstate in thread_struct is zeroed when the vector context is initialized. That includes read-only register vlenb, which holds the vector register length in bytes. Zeroed state persists until mstatus.VS becomes 'dirty' and a context switch saves the actual hardware values. This can expose the zero vlenb value to the user-space in early debug scenarios, e.g. when ptrace attaches to a traced process early, before any vector instruction except the first one was executed. Fix this by specifying proper vlenb on vector context init. Signed-off-by: Sergey Matyukevich Reviewed-by: Andy Chiu Tested-by: Andy Chiu Link: https://patch.msgid.link/20251214163537.1054292-3-geomatsi@gmail.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 62b650c4c0ac02407d0c9bb560925dc0cc3d7365 Author: Keita Morisaki Date: Mon Feb 2 11:45:26 2026 +0900 scsi: ufs: mediatek: Fix page faults in ufs_mtk_clk_scale() trace event [ Upstream commit 9672ed3de7d772ceddd713c769c05e832fc69bae ] The ufs_mtk_clk_scale() trace event currently stores the address of the name string directly via __field(const char *, name). This pointer may become invalid after the module is unloaded, causing page faults when the trace buffer is subsequently accessed. This can occur because the MediaTek UFS driver can be configured as a loadable module (tristate in Kconfig), meaning the name string passed to the trace event may reside in module memory that becomes invalid after module unload. Fix this by using __string() and __assign_str() to copy the string contents into the ring buffer instead of storing the pointer. This ensures the trace data remains valid regardless of module state. This change increases the memory usage for each ftrace entry by a few bytes (clock names are typically 7-15 characters like "ufs_sel" or "ufs_sel_max_src") compared to storing an 8-byte pointer. Note that this change does not affect anything unless all of the following conditions are met: - CONFIG_SCSI_UFS_MEDIATEK is enabled - ftrace tracing is enabled - The ufs_mtk_clk_scale event is enabled in ftrace Signed-off-by: Keita Morisaki Reviewed-by: Peter Wang Link: https://patch.msgid.link/20260202024526.122515-1-keita.morisaki@tier4.jp Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 25c429dd117854b46cf515e28cb910c66742688e Author: Kommula Shiva Shankar Date: Fri Jan 2 12:27:03 2026 +0530 vhost: fix caching attributes of MMIO regions by setting them explicitly [ Upstream commit 5145b277309f3818e2db507f525d19ac3b910922 ] Explicitly set non-cached caching attributes for MMIO regions. Default write-back mode can cause CPU to cache device memory, causing invalid reads and unpredictable behavior. Invalid read and write issues were observed on ARM64 when mapping the notification area to userspace via mmap. Signed-off-by: Kommula Shiva Shankar Acked-by: Jason Wang Reviewed-by: Jason Gunthorpe Signed-off-by: Michael S. Tsirkin Message-Id: <20260102065703.656255-1-kshankar@marvell.com> Signed-off-by: Sasha Levin commit 59e14a18a7d5b71dc797caa685b5a2d5c76f3e8d Author: Arnd Bergmann Date: Tue Feb 3 17:33:15 2026 +0100 scsi: buslogic: Reduce stack usage [ Upstream commit e17f0d4cc006265dd92129db4bf9da3a2e4a4f66 ] Some randconfig builds run into excessive stack usage with gcc-14 or higher, which use __attribute__((cold)) where earlier versions did not do that: drivers/scsi/BusLogic.c: In function 'blogic_init': drivers/scsi/BusLogic.c:2398:1: error: the frame size of 1680 bytes is larger than 1536 bytes [-Werror=frame-larger-than=] The problem is that a lot of code gets inlined into blogic_init() here. Two functions stick out, but they are a bit different: - blogic_init_probeinfo_list() actually uses a few hundred bytes of kernel stack, which is a problem in combination with other functions that also do. Marking this one as noinline means that the stack slots get get reused between function calls - blogic_reportconfig() has a few large variables, but whenever it is not inlined into its caller, the compiler is actually smart enough to reuse stack slots for these automatically, so marking it as noinline saves most of the stack space by itself. The combination of both of these should avoid the problem entirely. Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260203163321.2598593-1-arnd@kernel.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 263fe43d875313e27e3bd6270c34de16e01b3570 Author: Longfang Liu Date: Thu Jan 22 10:02:03 2026 +0800 hisi_acc_vfio_pci: update status after RAS error [ Upstream commit 8be14dd48dfee0df91e511acceb4beeb2461a083 ] After a RAS error occurs on the accelerator device, the accelerator device will be reset. The live migration state will be abnormal after reset, and the original state needs to be restored during the reset process. Therefore, reset processing needs to be performed in a live migration scenario. Signed-off-by: Longfang Liu Link: https://lore.kernel.org/r/20260122020205.2884497-3-liulongfang@huawei.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 9443fe6d05d119f2224d1c3d1d8aa6e68ca89911 Author: Henry Tseng Date: Mon Dec 1 17:46:22 2025 +0800 ata: libata: avoid long timeouts on hot-unplugged SATA DAS [ Upstream commit 151cabd140322205e27dae5c4bbf261ede0056e3 ] When a SATA DAS enclosure is connected behind a Thunderbolt PCIe switch, hot-unplugging the whole enclosure causes pciehp to tear down the PCI hierarchy before the SCSI layer issues SYNCHRONIZE CACHE and START STOP UNIT for the disks. libata still queues these commands and the AHCI driver tries to access the HBA registers even though the PCI channel is already offline. This results in a series of timeouts and error recovery attempts, e.g.: [ 824.778346] pcieport 0000:00:07.0: pciehp: Slot(14): Link Down [ 891.612720] ata8.00: qc timeout after 5000 msecs (cmd 0xec) [ 902.876501] ata8.00: qc timeout after 10000 msecs (cmd 0xec) [ 934.107998] ata8.00: qc timeout after 30000 msecs (cmd 0xec) [ 936.206431] sd 7:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK ... [ 1006.298356] ata1.00: qc timeout after 5000 msecs (cmd 0xec) [ 1017.561926] ata1.00: qc timeout after 10000 msecs (cmd 0xec) [ 1048.791790] ata1.00: qc timeout after 30000 msecs (cmd 0xec) [ 1050.890035] sd 0:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK With this patch applied, the same hot-unplug looks like: [ 59.965496] pcieport 0000:00:07.0: pciehp: Slot(14): Link Down [ 60.002502] sd 7:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK ... [ 60.103050] sd 0:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK In this test setup with two disks, the hot-unplug sequence shrinks from about 226 seconds (~3.8 minutes) between the Link Down event and the last SYNCHRONIZE CACHE failure to under a second. Without this patch the total delay grows roughly with the number of disks, because each disk gets its own SYNCHRONIZE CACHE and qc timeout series. If the underlying PCI device is already gone, these commands cannot succeed anyway. Avoid issuing them by introducing ata_adapter_is_online(), which checks pci_channel_offline() for PCI-based hosts. It is used from ata_scsi_find_dev() to return NULL, causing the SCSI layer to fail new commands with DID_BAD_TARGET immediately, and from ata_qc_issue() to bail out before touching the HBA registers. Since such failures would otherwise trigger libata error handling, ata_adapter_is_online() is also consulted from ata_scsi_port_error_handler(). When the adapter is offline, libata skips ap->ops->error_handler(ap) and completes error handling using the existing path, rather than running a full EH sequence against a dead adapter. With this change, SYNCHRONIZE CACHE and START STOP UNIT commands issued during hot-unplug fail quickly once the PCI channel is offline, without qc timeout spam or long libata EH delays. Suggested-by: Damien Le Moal Signed-off-by: Henry Tseng Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit ba5a09630ebba20b6c71bd24ef99d0fc9159ff43 Author: Tiwei Bie Date: Tue Jan 6 08:12:27 2026 +0800 um: Preserve errno within signal handler [ Upstream commit f68b2d5a907b53eed99cf2efcaaae116df73c298 ] We rely on errno to determine whether a syscall has failed, so we need to ensure that accessing errno is async-signal-safe. Currently, we preserve the errno in sig_handler_common(), but it doesn't cover every possible case. Let's do it in hard_handler() instead, which is the signal handler we actually register. Signed-off-by: Tiwei Bie Link: https://patch.msgid.link/20260106001228.1531146-2-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 7b7516ac611cb67c4735d80bae3a9fe6a3ff98d5 Author: Longfang Liu Date: Thu Jan 22 10:02:05 2026 +0800 hisi_acc_vfio_pci: fix the queue parameter anomaly issue [ Upstream commit c3cbc276c2a33b04fc78a86cdb2ddce094cb3614 ] When the number of QPs initialized by the device, as read via vft, is zero, it indicates either an abnormal device configuration or an abnormal read result. Returning 0 directly in this case would allow the live migration operation to complete successfully, leading to incorrect parameter configuration after migration and preventing the service from recovering normal functionality. Therefore, in such situations, an error should be returned to roll back the live migration operation. Signed-off-by: Longfang Liu Link: https://lore.kernel.org/r/20260122020205.2884497-5-liulongfang@huawei.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 61ad70c6c90856e7109bd99452f6671e325db378 Author: Md Haris Iqbal Date: Wed Jan 7 17:15:16 2026 +0100 RDMA/rtrs-clt: For conn rejection use actual err number [ Upstream commit fc290630702b530c2969061e7ef0d869a5b6dc4f ] When the connection establishment request is rejected from the server side, then the actual error number sent back should be used. Signed-off-by: Md Haris Iqbal Link: https://patch.msgid.link/20260107161517.56357-10-haris.iqbal@ionos.com Reviewed-by: Grzegorz Prajsner Reviewed-by: Jack Wang Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d527695c1df09886a280e4efb1624aadd1738770 Author: Longfang Liu Date: Thu Jan 22 10:02:04 2026 +0800 hisi_acc_vfio_pci: resolve duplicate migration states [ Upstream commit 8c6ac1730a977234dff74cc1753b4a953f59be7b ] In special scenarios involving duplicate migrations, after the first migration is completed, if the original VF device is used again and then migrated to another destination, the state indicating data migration completion for the VF device is not reset. This results in the second migration to the destination being skipped without performing data migration. After the modification, it ensures that a complete data migration is performed after the subsequent migration. Signed-off-by: Longfang Liu Link: https://lore.kernel.org/r/20260122020205.2884497-4-liulongfang@huawei.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit e9cc097427e859099da29af3c663b4ae1d9f2f29 Author: Carl Lee Date: Thu Feb 5 19:11:39 2026 +0800 nfc: nxp-nci: remove interrupt trigger type [ Upstream commit 57be33f85e369ce9f69f61eaa34734e0d3bd47a7 ] For NXP NCI devices (e.g. PN7150), the interrupt is level-triggered and active high, not edge-triggered. Using IRQF_TRIGGER_RISING in the driver can cause interrupts to fail to trigger correctly. Remove IRQF_TRIGGER_RISING and rely on the IRQ trigger type configured via Device Tree. Signed-off-by: Carl Lee Link: https://patch.msgid.link/20260205-fc-nxp-nci-remove-interrupt-trigger-type-v2-1-79d2ed4a7e42@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 529eefdf984299c88b9ec63797c7aeefa94f4775 Author: Arnd Bergmann Date: Thu Feb 5 17:28:09 2026 +0100 myri10ge: avoid uninitialized variable use [ Upstream commit fd24173439c033ffb3c2a2628fcbc9cb65e62bdb ] While compile testing on less common architectures, I noticed that gcc-10 on s390 finds a bug that all other configurations seem to miss: drivers/net/ethernet/myricom/myri10ge/myri10ge.c: In function 'myri10ge_set_multicast_list': drivers/net/ethernet/myricom/myri10ge/myri10ge.c:391:25: error: 'cmd.data0' is used uninitialized in this function [-Werror=uninitialized] 391 | buf->data0 = htonl(data->data0); | ^~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:392:25: error: '*((void *)&cmd+4)' is used uninitialized in this function [-Werror=uninitialized] 392 | buf->data1 = htonl(data->data1); | ^~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c: In function 'myri10ge_allocate_rings': drivers/net/ethernet/myricom/myri10ge/myri10ge.c:392:13: error: 'cmd.data1' is used uninitialized in this function [-Werror=uninitialized] 392 | buf->data1 = htonl(data->data1); drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1939:22: note: 'cmd.data1' was declared here 1939 | struct myri10ge_cmd cmd; | ^~~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:393:13: error: 'cmd.data2' is used uninitialized in this function [-Werror=uninitialized] 393 | buf->data2 = htonl(data->data2); drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1939:22: note: 'cmd.data2' was declared here 1939 | struct myri10ge_cmd cmd; It would be nice to understand how to make other compilers catch this as well, but for the moment I'll just shut up the warning by fixing the undefined behavior in this driver. Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260205162935.2126442-1-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fb108754550f82a6d276e34f48be8e8b651cd877 Author: Ilpo Järvinen Date: Fri Jan 16 15:15:12 2026 +0200 PCI/bwctrl: Disable BW controller on Intel P45 using a quirk [ Upstream commit 46a9f70e93ef73860d1dbbec75ef840031f8f30a ] The commit 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller") was found to lead to a boot hang on a Intel P45 system. Testing without setting Link Bandwidth Management Interrupt Enable (LBMIE) and Link Autonomous Bandwidth Interrupt Enable (LABIE) (PCIe r7.0, sec 7.5.3.7) in bwctrl allowed system to come up. P45 is a very old chipset and supports only up to gen2 PCIe, so not having bwctrl does not seem a huge deficiency. Add no_bw_notif in struct pci_dev and quirk Intel P45 Root Port with it. Reported-by: Adam Stylinski Link: https://lore.kernel.org/linux-pci/aUCt1tHhm_-XIVvi@eggsbenedict/ Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Adam Stylinski Link: https://patch.msgid.link/20260116131513.2359-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit b8bd9fe67041cfa58d5cfd7884caa178d094612d Author: Johnny-CC Chang Date: Thu Nov 13 16:44:06 2025 +0800 PCI: Mark Nvidia GB10 to avoid bus reset [ Upstream commit c81a2ce6b6a844d1a57d2a69833a9d0f00403f00 ] After asserting Secondary Bus Reset to downstream devices via a GB10 Root Port, the link may not retrain correctly, e.g., the link may retrain with a lower lane count or config accesses to downstream devices may fail. Prevent use of Secondary Bus Reset for devices below GB10. Signed-off-by: Johnny-CC Chang [bhelgaas: drop pci_ids.h update (only used once), update commit log] Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251113084441.2124737-1-Johnny-CC.Chang@mediatek.com Signed-off-by: Sasha Levin commit 551f16cd696e5bf0b82eacb87a0c4db382df0ba8 Author: Krishna Chaitanya Chundru Date: Fri Jan 9 13:53:32 2026 +0530 PCI: Add ACS quirk for Qualcomm Hamoa & Glymur [ Upstream commit 44d2f70b1fd72c339c72983fcffa181beae3e113 ] The Qualcomm Hamoa & Glymur Root Ports don't advertise an ACS capability, but they do provide ACS-like features to disable peer transactions and validate bus numbers in requests. Add an ACS quirk for Hamoa & Glymur. Signed-off-by: Krishna Chaitanya Chundru Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260109-acs_quirk-v1-1-82adf95a89ae@oss.qualcomm.com Signed-off-by: Sasha Levin commit 8d3fc66a008bc914c38a5c4a377197dafb98c444 Author: Manivannan Sadhasivam Date: Fri Jan 2 21:04:47 2026 +0530 PCI: Enable ACS after configuring IOMMU for OF platforms [ Upstream commit c41e2fb67e26b04d919257875fa954aa5f6e392e ] Platform, ACPI, or IOMMU drivers call pci_request_acs(), which sets 'pci_acs_enable' to request that ACS be enabled for any devices enumerated in the future. OF platforms called pci_enable_acs() for the first device before of_iommu_configure() called pci_request_acs(), so ACS was never enabled for that device (typically a Root Port). Call pci_enable_acs() later, from pci_dma_configure(), after of_dma_configure() has had a chance to call pci_request_acs(). Here's the call path, showing the move of pci_enable_acs() from pci_acs_init() to pci_dma_configure(), where it always happens after pci_request_acs(): pci_device_add pci_init_capabilities pci_acs_init - pci_enable_acs - if (pci_acs_enable) <-- previous test - ... device_add bus_notify(BUS_NOTIFY_ADD_DEVICE) iommu_bus_notifier iommu_probe_device iommu_init_device dev->bus->dma_configure pci_dma_configure # pci_bus_type.dma_configure of_dma_configure of_iommu_configure pci_request_acs pci_acs_enable = 1 <-- set + pci_enable_acs + if (pci_acs_enable) <-- new test + ... bus_probe_device device_initial_probe ... really_probe dev->bus->dma_configure pci_dma_configure # pci_bus_type.dma_configure ... pci_enable_acs Note that we will now call pci_enable_acs() twice for every device, first from the iommu_probe_device() path and again from the really_probe() path. Presumably that's not an issue since we also call dev->bus->dma_configure() twice. For the ACPI platforms, pci_request_acs() is called during ACPI initialization time itself, independent of the IOMMU framework. Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Tested-by: Marek Szyprowski Tested-by: Naresh Kamboju Link: https://patch.msgid.link/20260102-pci_acs-v3-1-72280b94d288@oss.qualcomm.com Signed-off-by: Sasha Levin commit d60ed85b841910bafbb6aa4e6315a261fdfed2e6 Author: Keith Busch Date: Fri Jan 30 08:59:51 2026 -0800 PCI: Fix pci_slot_lock () device locking [ Upstream commit 1f5e57c622b4dc9b8e7d291d560138d92cfbe5bf ] Like pci_bus_lock(), pci_slot_lock() needs to lock the bridge device to prevent warnings like: pcieport 0000:e2:05.0: unlocked secondary bus reset via: pciehp_reset_slot+0x55/0xa0 Take and release the lock for the bridge providing the slot for the lock/trylock and unlock routines. Signed-off-by: Keith Busch Signed-off-by: Bjorn Helgaas Reviewed-by: Dan Williams Link: https://patch.msgid.link/20260130165953.751063-3-kbusch@meta.com Signed-off-by: Sasha Levin commit cad253d055e259682a97dd926649529aead7d3de Author: Lukas Wunner Date: Sun Jan 25 10:25:51 2026 +0100 PCI/AER: Clear stale errors on reporting agents upon probe [ Upstream commit e242d09b58e869f86071b7889acace4cff215935 ] Correctable and Uncorrectable Error Status Registers on reporting agents are cleared upon PCI device enumeration in pci_aer_init() to flush past events. They're cleared again when an error is handled by the AER driver. If an agent reports a new error after pci_aer_init() and before the AER driver has probed on the corresponding Root Port or Root Complex Event Collector, that error is not handled by the AER driver: It clears the Root Error Status Register on probe, but neglects to re-clear the Correctable and Uncorrectable Error Status Registers on reporting agents. The error will eventually be reported when another error occurs. Which is irritating because to an end user it appears as if the earlier error has just happened. Amend the AER driver to clear stale errors on reporting agents upon probe. Skip reporting agents which have not invoked pci_aer_init() yet to avoid using an uninitialized pdev->aer_cap. They're recognizable by the error bits in the Device Control register still being clear. Reporting agents may execute pci_aer_init() after the AER driver has probed, particularly when devices are hotplugged or removed/rescanned via sysfs. For this reason, it continues to be necessary that pci_aer_init() clears Correctable and Uncorrectable Error Status Registers. Reported-by: Lucas Van # off-list Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Tested-by: Lucas Van Reviewed-by: Kuppuswamy Sathyanarayanan Link: https://patch.msgid.link/3011c2ed30c11f858e35e29939add754adea7478.1769332702.git.lukas@wunner.de Signed-off-by: Sasha Levin commit a175a7614738294abeb0dbb104a3cb189f00dfe8 Author: Alex Williamson Date: Thu Jan 8 17:02:08 2026 -0700 PCI: Mark ASM1164 SATA controller to avoid bus reset [ Upstream commit beb2f81792a8a619e5122b6b24a374861309c54b ] User forums report issues when assigning ASM1164 SATA controllers to VMs, especially in configurations with multiple controllers. Logs show the device fails to retrain after bus reset. Reports suggest this is an issue across multiple platforms. The device indicates support for PM reset, therefore the device still has a viable function level reset mechanism. The reporting user confirms the device is well behaved in this use case with bus reset disabled. Reported-by: Patrick Bianchi Link: https://forum.proxmox.com/threads/problems-with-pcie-passthrough-with-two-identical-devices.149003/ Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260109000211.398300-1-alex.williamson@nvidia.com Signed-off-by: Sasha Levin commit 14eae5564053ac3973b9369dc674638f22f4765e Author: Håkon Bugge Date: Mon Feb 2 22:57:20 2026 -0700 net/rds: Clear reconnect pending bit [ Upstream commit b89fc7c2523b2b0750d91840f4e52521270d70ed ] When canceling the reconnect worker, care must be taken to reset the reconnect-pending bit. If the reconnect worker has not yet been scheduled before it is canceled, the reconnect-pending bit will stay on forever. Signed-off-by: Håkon Bugge Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260203055723.1085751-6-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a036d058f5ef0954aeb5ed51265db4b84f02268d Author: Arnd Bergmann Date: Tue Feb 3 17:34:00 2026 +0100 vmw_vsock: bypass false-positive Wnonnull warning with gcc-16 [ Upstream commit e25dbf561e03c0c5e36228e3b8b784392819ce85 ] The gcc-16.0.1 snapshot produces a false-positive warning that turns into a build failure with CONFIG_WERROR: In file included from arch/x86/include/asm/string.h:6, from net/vmw_vsock/vmci_transport.c:10: In function 'vmci_transport_packet_init', inlined from '__vmci_transport_send_control_pkt.constprop' at net/vmw_vsock/vmci_transport.c:198:2: arch/x86/include/asm/string_32.h:150:25: error: argument 2 null where non-null expected because argument 3 is nonzero [-Werror=nonnull] 150 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n) | ^~~~~~~~~~~~~~~~~~~~~~~~~ net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy' 164 | memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait)); | ^~~~~~ arch/x86/include/asm/string_32.h:150:25: note: in a call to built-in function '__builtin_memcpy' net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy' 164 | memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait)); | ^~~~~~ This seems relatively harmless, and it so far the only instance of this warning I have found. The __vmci_transport_send_control_pkt function is called either with wait=NULL or with one of the type values that pass 'wait' into memcpy() here, but not from the same caller. Replacing the memcpy with a struct assignment is otherwise the same but avoids the warning. Signed-off-by: Arnd Bergmann Reviewed-by: Bobby Eshleman Reviewed-by: Stefano Garzarella Reviewed-by: Bryan Tan Link: https://patch.msgid.link/20260203163406.2636463-1-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c55ba9760662effe2b604acb014b19883db54fe5 Author: Ethan Nelson-Moore Date: Mon Feb 2 17:39:09 2026 -0800 net: usb: sr9700: remove code to drive nonexistent multicast filter [ Upstream commit 9a9424c756feee9ee6e717405a9d6fa7bacdef08 ] Several registers referenced in this driver's source code do not actually exist (they are not writable and read as zero in my testing). They exist in this driver because it originated as a copy of the dm9601 driver. Notably, these include the multicast filter registers - this causes the driver to not support multicast packets correctly. Remove the multicast filter code and register definitions. Instead, set the chip to receive all multicast filter packets when any multicast addresses are in the list. Reviewed-by: Simon Horman (from v1) Signed-off-by: Ethan Nelson-Moore Link: https://patch.msgid.link/20260203013924.28582-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 90ecae0dece4da70921c012ff883904af67c6049 Author: David Woodhouse Date: Fri Jan 30 17:36:04 2026 +0000 ptp: ptp_vmclock: add 'VMCLOCK' to ACPI device match [ Upstream commit ed4d23ed469ca14d47670c0384f6ae6c4ff060a5 ] As we finalised the spec, we spotted that vmgenid actually says that the _HID is supposed to be hypervisor-specific. Although in the 13 years since the original vmgenid doc was published, nobody seems to have cared about using _HID to distinguish between implementations on different hypervisors, and we only ever use the _CID. For consistency, match the _CID of "VMCLOCK" too. Signed-off-by: David Woodhouse Signed-off-by: Babis Chalios Tested-by: Takahiro Itazuri Link: https://patch.msgid.link/20260130173704.12575-6-itazur@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5baf9dc03e84d6426819a99e02f2f6f03eb87954 Author: Joe Damato Date: Fri Jan 30 16:30:41 2026 -0800 bnxt_en: Allow ntuple filters for drops [ Upstream commit 61cef6454cfbb9fcdbe41401fb53895f86603081 ] It appears that in commit 7efd79c0e689 ("bnxt_en: Add drop action support for ntuple"), bnxt gained support for ntuple filters for packet drops. However, support for this does not seem to work in recent kernels or against net-next: % sudo ethtool -U eth0 flow-type udp4 src-ip 1.1.1.1 action -1 rmgr: Cannot insert RX class rule: Operation not supported Cannot insert classification rule The issue is that the existing code uses ethtool_get_flow_spec_ring_vf, which will return a non-zero value if the ring_cookie is set to RX_CLS_FLOW_DISC, which then causes bnxt_add_ntuple_cls_rule to return -EOPNOTSUPP because it thinks the user is trying to set an ntuple filter for a vf. Fix this by first checking that the ring_cookie is not RX_CLS_FLOW_DISC. After this patch, ntuple filters for drops can be added: % sudo ethtool -U eth0 flow-type udp4 src-ip 1.1.1.1 action -1 Added rule with ID 0 % ethtool -n eth0 44 RX rings available Total 1 rules Filter: 0 Rule Type: UDP over IPv4 Src IP addr: 1.1.1.1 mask: 0.0.0.0 Dest IP addr: 0.0.0.0 mask: 255.255.255.255 TOS: 0x0 mask: 0xff Src port: 0 mask: 0xffff Dest port: 0 mask: 0xffff Action: Drop Reviewed-by: Michael Chan Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260131003042.2570434-1-joe@dama.to Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 211958e721983f027cd94ad5e753d54e8da4f506 Author: Ziyi Guo Date: Fri Jan 23 17:56:11 2026 +0000 wifi: ath10k: fix lock protection in ath10k_wmi_event_peer_sta_ps_state_chg() [ Upstream commit 820ba7dd6859ef8b1eaf6014897e7aa4756fc65d ] ath10k_wmi_event_peer_sta_ps_state_chg() uses lockdep_assert_held() to assert that ar->data_lock should be held by the caller, but neither ath10k_wmi_10_2_op_rx() nor ath10k_wmi_10_4_op_rx() acquire this lock before calling this function. The field arsta->peer_ps_state is documented as protected by ar->data_lock in core.h, and other accessors (ath10k_peer_ps_state_disable, ath10k_dbg_sta_read_peer_ps_state) properly acquire this lock. Add spin_lock_bh()/spin_unlock_bh() around the peer_ps_state update, and remove the lockdep_assert_held() to be aligned with new locking, following the pattern used by other WMI event handlers in the driver. Signed-off-by: Ziyi Guo Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260123175611.767731-1-n7l8m4@u.northwestern.edu [removed excess blank line] Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 0e12a252ec4b80fa526544b8f03e60e1864a9bfe Author: Dian-Syuan Yang Date: Tue Jan 27 16:50:35 2026 +0800 wifi: rtw89: pci: restore LDO setting after device resume [ Upstream commit af1e82232b988f8fc6d635c60609765e49221a64 ] The LDO (Low Dropout Regulator) setting is missing after suspend/resume in some platforms, and it will cause card loss. Therefore, reconfigure this setting to avoid it. Signed-off-by: Dian-Syuan Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260127085036.44060-6-pkshih@realtek.com Signed-off-by: Sasha Levin commit 2f4de7738aded83b79219b11fcec7bcfa5f742ac Author: Marek Behún Date: Wed Jan 28 18:00:44 2026 +0100 net: sfp: add quirk for Lantech 8330-265D [ Upstream commit 86a8e8e0ddbc3d14c799536eb888180b84d002f3 ] Similar to Lantech 8330-262D-E, the Lantech 8330-265D also reports 2500MBd instead of 3125MBd. Also, all 8330-265D report normal RX_LOS in EEPROM, but some signal inverted RX_LOS. We therefore need to ignore RX_LOS on these modules. Signed-off-by: Marek Behún Link: https://patch.msgid.link/20260128170044.15576-1-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8052d0587fb14b85539c3a14a226586c0c3d6b4c Author: Geetha sowjanya Date: Tue Jan 27 18:21:47 2026 +0530 octeontx2-af: Workaround SQM/PSE stalls by disabling sticky [ Upstream commit 70e9a5760abfb6338d63994d4de6b0778ec795d6 ] NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated. work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21) These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations. Signed-off-by: Geetha sowjanya Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260127125147.1642-1-gakula@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ea3f3de49cb6902de4ff9a7948c1c03a9ed01ebc Author: Jacopo Scannella Date: Tue Jan 20 10:13:04 2026 +0100 Bluetooth: btusb: Add device ID for Realtek RTL8761BU [ Upstream commit cc6383d4f0cf6127c0552f94cae517a06ccc6b17 ] Add USB device ID 0x2c0a:0x8761 to the btusb driver fo the Realtek RTL8761BU Bluetooth adapter. Reference: https://www.startech.com/en-us/networking-io/av53c1-usb-bluetooth Signed-off-by: Jacopo Scannella Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c87634f7b51f2a4fc84b61a1b8f5e7e4b879bfe6 Author: Shell Chen Date: Wed Jan 14 15:03:35 2026 +1100 Bluetooth: btusb: Add new VID/PID for RTL8852CE [ Upstream commit d9f7c39c6b7548bd70519b241b6c2d1bcc658d4b ] Add VID:PID 13d3:3612 to the quirks_table. This ID pair is found in the Realtek RTL8852CE PCIe module in an ASUS TUF A14 2025 (FA401KM) laptop. Tested on aforementioned laptop. The device info from /sys/kernel/debug/usb/devices is listed as below. T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3612 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Shell Chen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit e1b2d0394c8bdfe433c043888387dc67224773be Author: Stefan Sørensen Date: Tue Dec 16 10:20:09 2025 +0100 Bluetooth: hci_conn: use mod_delayed_work for active mode timeout [ Upstream commit 49d0901e260739de2fcc90c0c29f9e31e39a2d9b ] hci_conn_enter_active_mode() uses queue_delayed_work() with the intention that the work will run after the given timeout. However, queue_delayed_work() does nothing if the work is already queued, so depending on the link policy we may end up putting the connection into idle mode every hdev->idle_timeout ms. Use mod_delayed_work() instead so the work is queued if not already queued, and the timeout is updated otherwise. Signed-off-by: Stefan Sørensen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 113eeb6e2f94e897b18ba4d81b8cd23aeb7a52e5 Author: Techie Ernie Date: Wed Dec 24 11:31:29 2025 +0800 Bluetooth: btusb: Add USB ID 0489:e112 for Realtek 8851BE [ Upstream commit e07094a51ad8faf98ea64320799ce550828e97cd ] Add USB ID 0489:e112 for the Realtek 8851BE Bluetooth adapter. Without this entry, the device is not handled correctly by btusb and Bluetooth fails to initialise. Adding the ID enables proper Realtek initialization for Bluetooth to work on various motherboards using this Bluetooth adapter. The device identifies as: Bus 001 Device XXX: ID 0489:e112 Foxconn / Hon Hai Bluetooth Radio Tested on Realtek 8851BE. Bluetooth works after this change is made. Signed-off-by: Techie Ernie Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a6cbc4f5a6fdba5bf609cf97cbed653a9100b73d Author: Stefan Sørensen Date: Tue Dec 16 10:20:10 2025 +0100 Bluetooth: hci_conn: Set link_policy on incoming ACL connections [ Upstream commit 4bb091013ab0f2edfed3f58bebe658a798cbcc4d ] The connection link policy is only set when establishing an outgoing ACL connection causing connection idle modes not to be available on incoming connections. Move the setting of the link policy to the creation of the connection so all ACL connection will use the link policy set on the HCI device. Signed-off-by: Stefan Sørensen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4a300678ab7ccdff080af3967a3120e3aee774a7 Author: Shuai Zhang Date: Wed Dec 3 11:37:12 2025 +0800 Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw [ Upstream commit fce1a9244a0f85683be8530e623bc729f24c5067 ] On QCS9075 and QCA8275 platforms, the BT_EN pin is always pulled up by hw and cannot be controlled by the host. As a result, in case of a firmware crash, the host cannot trigger a cold reset. Instead, the BT controller performs a warm restart on its own, without reloading the firmware. This leads to the controller remaining in IBS_WAKE state, while the host expects it to be in sleep mode. The mismatch causes HCI reset commands to time out. Additionally, the driver does not clear internal flags QCA_SSR_TRIGGERED and QCA_IBS_DISABLED, which blocks the reset sequence. If the SSR duration exceeds 2 seconds, the host may enter TX sleep mode due to tx_idle_timeout, further preventing recovery. Also, memcoredump_flag is not cleared, so only the first SSR generates a coredump. Tell the driver that the BT controller has undergone a proper restart sequence: - Clear QCA_SSR_TRIGGERED and QCA_IBS_DISABLED flags after SSR. - Add a 50ms delay to allow the controller to complete its warm reset. - Reset tx_idle_timer to prevent the host from entering TX sleep mode. - Clear memcoredump_flag to allow multiple coredump captures. Apply these steps only when HCI_QUIRK_NON_PERSISTENT_SETUP is not set, which indicates that BT_EN is defined in DTS and cannot be toggled. Refer to the comment in include/net/bluetooth/hci.h for details on HCI_QUIRK_NON_PERSISTENT_SETUP. Reviewed-by: Dmitry Baryshkov Signed-off-by: Shuai Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 2d6160de5ff477cace83685a466c2c5aa83d113b Author: Bluecross Date: Wed Dec 10 23:22:25 2025 +0300 Bluetooth: btusb: Add support for MediaTek7920 0489:e158 [ Upstream commit 2630bcc8343a9d2a38dc1793068e6754b3156811 ] Add support for MediaTek7920 0489:e158 /sys/kernel/debug/usb/devices reports for that device: T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=03 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e158 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Signed-off-by: Andrew Elatsev Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f7e05f08849f68358d1f8ff1cbc188f107674264 Author: Kuniyuki Iwashima Date: Tue Jan 27 04:35:24 2026 +0000 ipv4: fib: Annotate access to struct fib_alias.fa_state. [ Upstream commit 6e84fc395e90465f1418f582a9f7d53c87ab010e ] syzbot reported that struct fib_alias.fa_state can be modified locklessly by RCU readers. [0] Let's use READ_ONCE()/WRITE_ONCE() properly. [0]: BUG: KCSAN: data-race in fib_table_lookup / fib_table_lookup write to 0xffff88811b06a7fa of 1 bytes by task 4167 on cpu 0: fib_alias_accessed net/ipv4/fib_lookup.h:32 [inline] fib_table_lookup+0x361/0xd60 net/ipv4/fib_trie.c:1565 fib_lookup include/net/ip_fib.h:390 [inline] ip_route_output_key_hash_rcu+0x378/0x1380 net/ipv4/route.c:2814 ip_route_output_key_hash net/ipv4/route.c:2705 [inline] __ip_route_output_key include/net/route.h:169 [inline] ip_route_output_flow+0x65/0x110 net/ipv4/route.c:2932 udp_sendmsg+0x13c3/0x15d0 net/ipv4/udp.c:1450 inet_sendmsg+0xac/0xd0 net/ipv4/af_inet.c:859 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0x53a/0x600 net/socket.c:2592 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2646 __sys_sendmmsg+0x185/0x320 net/socket.c:2735 __do_sys_sendmmsg net/socket.c:2762 [inline] __se_sys_sendmmsg net/socket.c:2759 [inline] __x64_sys_sendmmsg+0x57/0x70 net/socket.c:2759 x64_sys_call+0x1e28/0x3000 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88811b06a7fa of 1 bytes by task 4168 on cpu 1: fib_alias_accessed net/ipv4/fib_lookup.h:31 [inline] fib_table_lookup+0x338/0xd60 net/ipv4/fib_trie.c:1565 fib_lookup include/net/ip_fib.h:390 [inline] ip_route_output_key_hash_rcu+0x378/0x1380 net/ipv4/route.c:2814 ip_route_output_key_hash net/ipv4/route.c:2705 [inline] __ip_route_output_key include/net/route.h:169 [inline] ip_route_output_flow+0x65/0x110 net/ipv4/route.c:2932 udp_sendmsg+0x13c3/0x15d0 net/ipv4/udp.c:1450 inet_sendmsg+0xac/0xd0 net/ipv4/af_inet.c:859 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0x53a/0x600 net/socket.c:2592 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2646 __sys_sendmmsg+0x185/0x320 net/socket.c:2735 __do_sys_sendmmsg net/socket.c:2762 [inline] __se_sys_sendmmsg net/socket.c:2759 [inline] __x64_sys_sendmmsg+0x57/0x70 net/socket.c:2759 x64_sys_call+0x1e28/0x3000 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 UID: 0 PID: 4168 Comm: syz.4.206 Not tainted syzkaller #0 PREEMPT(voluntary) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Reported-by: syzbot+d24f940f770afda885cf@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69783ead.050a0220.c9109.0013.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260127043528.514160-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ebeaa3b24ba568ff8505165f954dba15cc53e4b3 Author: Ping-Ke Shih Date: Fri Jan 23 09:39:56 2026 +0800 wifi: rtw89: pci: validate release report content before using for RTL8922DE [ Upstream commit 5f93d611b33a05bd03d6843c8efe8cb6a1992620 ] The commit 957eda596c76 ("wifi: rtw89: pci: validate sequence number of TX release report") does validation on existing chips, which somehow a release report of SKB becomes malformed. As no clear cause found, add rules ahead for RTL8922DE to avoid crash if it happens. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260123013957.16418-11-pkshih@realtek.com Signed-off-by: Sasha Levin commit 9e4da6e3907c79b4762c860c62811aa5b4c41b7b Author: Ziyi Guo Date: Sun Jan 25 19:30:05 2026 +0000 wifi: iwlegacy: add missing mutex protection in il3945_store_measurement() [ Upstream commit 4dd1dda65265ecbc9f43ffc08e333684cf715152 ] il3945_store_measurement() calls il3945_get_measurement() which internally calls il_send_cmd_sync() without holding il->mutex. However, il_send_cmd_sync() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. Other sysfs store functions in the same file properly acquire the mutex: - il3945_store_flags() acquires mutex at 3945-mac.c:3110 - il3945_store_filter_flags() acquires mutex at 3945-mac.c:3144 Add mutex_lock()/mutex_unlock() around the il3945_get_measurement() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260125193005.1090429-1-n7l8m4@u.northwestern.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 998e57caaa46910621997922ecfff4c1dbc54567 Author: Ziyi Guo Date: Sun Jan 25 19:40:39 2026 +0000 wifi: iwlegacy: add missing mutex protection in il4965_store_tx_power() [ Upstream commit e31fa691d0b1c07b6094a6cf0cce894192c462b3 ] il4965_store_tx_power() calls il_set_tx_power() without holding il->mutex. However, il_set_tx_power() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. All other callers of il_set_tx_power() properly acquire the mutex: - il_bg_scan_completed() acquires mutex at common.c:1683 - il_mac_config() acquires mutex at common.c:5006 - il3945_commit_rxon() and il4965_commit_rxon() are called via work queues that hold the mutex (like il4965_bg_alive_start) Add mutex_lock()/mutex_unlock() around the il_set_tx_power() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260125194039.1196488-1-n7l8m4@u.northwestern.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6b36e5c4741f1810b5abefd0d75e617bb6ddd082 Author: Jijie Shao Date: Fri Jan 23 17:47:55 2026 +0800 net: hns3: extend HCLGE_FD_AD_QID to 11 bits [ Upstream commit 878406d4d6ef85c37fab52074771cc916e532c16 ] Currently, HCLGE_FD_AD_QID has only 10 bits and supports a maximum of 1023 queues. However, there are actually scenarios where the queue_id exceeds 1023. This patch adds an additional bit to HCLGE_FD_AD_QID to ensure that queue_id greater than 1023 are supported. Signed-off-by: Jijie Shao Link: https://patch.msgid.link/20260123094756.3718516-2-shaojijie@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b76eab322b7d9020b202353763c00391efab18fd Author: Eric Dumazet Date: Thu Jan 22 17:22:47 2026 +0000 ipv4: igmp: annotate data-races around idev->mr_maxdelay [ Upstream commit e4faaf65a75f650ac4366ddff5dabb826029ca5a ] idev->mr_maxdelay is read and written locklessly, add READ_ONCE()/WRITE_ONCE() annotations. While we are at it, make this field an u32. Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20260122172247.2429403-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 00b36860495bace44eeaa73507c26cdfe14e29d7 Author: Eric Dumazet Date: Thu Jan 22 04:57:17 2026 +0000 gro: change the BUG_ON() in gro_pull_from_frag0() [ Upstream commit cbe41362be2c27e0237a94a404ae413cec9c2ad9 ] Replace the BUG_ON() which never fired with a DEBUG_NET_WARN_ON_ONCE() $ scripts/bloat-o-meter -t vmlinux.1 vmlinux.2 add/remove: 2/2 grow/shrink: 1/1 up/down: 370/-254 (116) Function old new delta gro_try_pull_from_frag0 - 196 +196 napi_gro_frags 771 929 +158 __pfx_gro_try_pull_from_frag0 - 16 +16 __pfx_gro_pull_from_frag0 16 - -16 dev_gro_receive 1514 1464 -50 gro_pull_from_frag0 188 - -188 Total: Before=22565899, After=22566015, chg +0.00% Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260122045720.1221017-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit afe908432e44381d4cc51add0f0b8bde778d132f Author: Ojaswin Mujoo Date: Fri Jan 23 11:55:35 2026 +0530 ext4: propagate flags to convert_initialized_extent() [ Upstream commit 3fffa44b6ebf65be92a562a5063303979385a1c9 ] Currently, ext4_zero_range passes EXT4_EX_NOCACHE flag to avoid caching extents however this is not respected by convert_initialized_extent(). Hence, modify it to accept flags from the caller and to pass the flags on to other extent manipulation functions it calls. This makes sure the NOCACHE flag is respected throughout the code path. Also, we no longer explicitly pass CONVERT_UNWRITTEN as the caller takes care of this. Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Signed-off-by: Ojaswin Mujoo Link: https://patch.msgid.link/07008fbb14db727fddcaf4c30e2346c49f6c8fe0.1769149131.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 899ef00963ce76f9fc421a7d02335fe4ead6389b Author: Gerd Rausch Date: Wed Jan 21 22:52:12 2026 -0700 net/rds: No shortcut out of RDS_CONN_ERROR [ Upstream commit ad22d24be635c6beab6a1fdd3f8b1f3c478d15da ] RDS connections carry a state "rds_conn_path::cp_state" and transitions from one state to another and are conditional upon an expected state: "rds_conn_path_transition." There is one exception to this conditionality, which is "RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop" regardless of what state the condition is currently in. But as soon as a connection enters state "RDS_CONN_ERROR", the connection handling code expects it to go through the shutdown-path. The RDS/TCP multipath changes added a shortcut out of "RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING" via "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change"). A subsequent "rds_tcp_reset_callbacks" can then transition the state to "RDS_CONN_RESETTING" with a shutdown-worker queued. That'll trip up "rds_conn_init_shutdown", which was never adjusted to handle "RDS_CONN_RESETTING" and subsequently drops the connection with the dreaded "DR_INV_CONN_STATE", which leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever. So we do two things here: a) Don't shortcut "RDS_CONN_ERROR", but take the longer path through the shutdown code. b) Add "RDS_CONN_RESETTING" to the expected states in "rds_conn_init_shutdown" so that we won't error out and get stuck, if we ever hit weird state transitions like this again." Signed-off-by: Gerd Rausch Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260122055213.83608-2-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4db148f74a99fa752770cbd1893f6ecf31209393 Author: Po-Hao Huang Date: Sat Jan 17 12:41:57 2026 +0800 wifi: rtw89: 8922a: add digital compensation for 2GHz [ Upstream commit 8da7e88682d58a7c2e2c2101e49d3c9c9ac481b0 ] This fixes transmit power too low under 2GHz connection. Previously we missed the settings of 2GHz, add the according calibrated tables. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260117044157.2392958-10-pkshih@realtek.com Signed-off-by: Sasha Levin commit 98a774e2c58dfaa008e487ac59b77116df8c4bad Author: Po-Hao Huang Date: Wed Jan 14 09:39:50 2026 +0800 wifi: rtw89: fix unable to receive probe responses under MLO connection [ Upstream commit 6f6d7a325fbde4f025ee1b1277f6f44727e21223 ] During MLO connections, A1 of the probe responses we received are in link address, these frames will then be dropped by mac80211 due to not matching the MLD address in ieee80211_scan_accept_presp(). Fix this by using MLD address to scan when not using random MAC address. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260114013950.19704-13-pkshih@realtek.com Signed-off-by: Sasha Levin commit 6944aaa804af27fb47e414f3fcabad9e832f67b4 Author: Greg Kroah-Hartman Date: Wed Jan 21 11:29:45 2026 +0100 driver core: faux: stop using static struct device [ Upstream commit 61b76d07d2b46a86ea91267d36449fc78f8a1f6e ] faux_bus_root should not have been a static struct device, but rather a dynamically created structure so that lockdep and other testing tools do not trip over it (as well as being the right thing overall to do.) Fix this up by making it properly dynamic. Reported-by: Gui-Dong Han Closes: https://lore.kernel.org/lkml/CALbr=LYKJsj6cbrDLA07qioKhWJcRj+gW8=bq5=4ZvpEe2c4Yg@mail.gmail.com/ Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/2026012145-lapping-countless-ef81@gregkh Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e1c24d4cd1610add4ca6e9af2b57325418aac737 Author: Nidhish A N Date: Sun Jan 11 19:39:14 2026 +0200 wifi: iwlwifi: mld: Fix primary link selection logic [ Upstream commit 7a749db26cab2334d5b356ac31e6f1147c7682da ] When assigning emlsr.primary with emlsr.selected_primary we are checking if BIT(mld_vif->emlsr.selected_links) are a part of vif->active_links. This is incorrect as emlsr.selected_links is a bitmap of possibly two selected links. Therefore, performing the BIT() operation on it does not yield any meaningful result and almost always leads to incorrect primary link selection. Additionally, we cannot rely on vif->active_links at this stage of the link switch flow because it contains both the removed links and also the newly added links. For example, if we had selected links in the past (0x11) and we now select links because of TTLM/debugfs (0x100), vif->active_links will now be (0x111) and primary link will be 0, while 0 is not even an active link. Thus, we create our own bitmap of final active links. Signed-off-by: Nidhish A N Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260111193638.38b2e14e3a20.Ie81a88dfff0c5d2becedabab8398702808f6b1bf@changeid Signed-off-by: Sasha Levin commit 83f0bb907cc81790b4948f58d92e788645a0da48 Author: Miri Korenblit Date: Sun Jan 11 19:39:12 2026 +0200 wifi: iwlwifi: mld: fix chandef start calculation [ Upstream commit d2fcdf36554316cc51f7928b777944738d06e332 ] A link pair in which both links are in 5 GHz can be used for EMLSR only if they are separated enough. To check this condition we calculate the start and the end of the chandefs of both links in the pair and do some checks. But the calculation of the start/end of the chandef is currently done by subtracting/adding half the bandwidth from/to the control channel's center frequency, when it should really be subtracted/added from/to the center frequency of the entire chandef. Fix the wrong calculation. Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260111193638.2138fdb99bd5.I4d2e5957b22482a57b1d6ca444e90fcf73bf2cab@changeid Signed-off-by: Sasha Levin commit 1d49a42717bdc8de77eabeb5b7d3e88d141ffea9 Author: Johannes Berg Date: Mon Nov 10 15:02:19 2025 +0200 wifi: iwlwifi: fix 22000 series SMEM parsing [ Upstream commit 58192b9ce09b0f0f86e2036683bd542130b91a98 ] If the firmware were to report three LMACs (which doesn't exist in hardware) then using "fwrt->smem_cfg.lmac[2]" is an overrun of the array. Reject such and use IWL_FW_CHECK instead of WARN_ON in this function. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20251110150012.16e8c2d70c26.Iadfcc1aedf43c5175b3f0757bea5aa232454f1ac@changeid Signed-off-by: Sasha Levin commit ece13ddb9791e4ff550d9b4e41a9a7512a6fe506 Author: Miri Korenblit Date: Mon Nov 10 15:02:15 2025 +0200 wifi: iwlwifi: mvm: check the validity of noa_len [ Upstream commit 1e3fb3c4a8e6c581d0f4533dba887fabf53d607d ] Validate iwl_probe_resp_data_notif::noa_attr::len_low since we are using its value to determine the noa_len, which is later used for the NoA attribute. Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20251110150012.99b663d9b424.I206fd54c990ca9e1160b9b94fa8be44e67bcc1b9@changeid Signed-off-by: Sasha Levin commit f181a659909f1f9fe5947a27906773136a9c4ef0 Author: Ilan Peer Date: Mon Nov 10 18:08:46 2025 +0200 wifi: iwlwifi: mld: Handle rate selection for NAN interface [ Upstream commit dbbeebece03050cd510073ce89fee83844e06b00 ] Frames transmitted over a NAN interface might not have channel information assigned to them. In such cases assign the lowest OFDM to the frame. Signed-off-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20251110180612.72046f98f878.Ib784931fffd0747acd9d7bb22eabbbec5282733e@changeid Signed-off-by: Sasha Levin commit 3d39d78b8d487024b6afd2bff6b82d3b009bf9c6 Author: Richard Zhu Date: Wed Oct 15 11:04:27 2025 +0800 PCI: imx6: Add CLKREQ# override to enable REFCLK for i.MX95 PCIe [ Upstream commit 27a064aba2da6bc58fc36a6b8e889187ae3bf89d ] The CLKREQ# is an open drain, active low signal that is driven low by the card to request reference clock. It's an optional signal added in PCIe CEM r4.0, sec 2. Thus, this signal wouldn't be driven low if it's not exposed on the slot. On the i.MX95 EVK board, REFCLK to the host and endpoint is gated by this CLKREQ# signal. So if the CLKREQ# signal is not driven by the endpoint, it will gate the REFCLK to host too, leading to operational failure. Hence, enable the REFCLK on this SoC by enabling the CLKREQ# override using imx95_pcie_clkreq_override() helper during probe. This override should only be cleared when the CLKREQ# signal is exposed on the slot. Signed-off-by: Richard Zhu [mani: reworded description] Signed-off-by: Manivannan Sadhasivam Tested-by: Alexander Stein Reviewed-by: Frank Li Link: https://patch.msgid.link/20251015030428.2980427-11-hongxing.zhu@nxp.com Signed-off-by: Sasha Levin commit 9650627d0757a36f33512dd86676569a48e34130 Author: Mingj Ye Date: Tue Jan 20 09:59:49 2026 +0800 net: usb: r8152: fix transmit queue timeout [ Upstream commit 833dcd75d54f0bf5aa0a0781ff57456b421fbb40 ] When the TX queue length reaches the threshold, the netdev watchdog immediately detects a TX queue timeout. This patch updates the trans_start timestamp of the transmit queue on every asynchronous USB URB submission along the transmit path, ensuring that the network watchdog accurately reflects ongoing transmission activity. Signed-off-by: Mingj Ye Reviewed-by: Hayes Wang Link: https://patch.msgid.link/20260120015949.84996-1-insyelu@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a729596086984e76cba5e8f7fe52e912c08a24ae Author: Brian Masney Date: Tue Jan 20 12:07:23 2026 -0500 openrisc: define arch-specific version of nop() [ Upstream commit 0dfffa5479d6260d04d021f69203b1926f73d889 ] When compiling a driver written for MIPS on OpenRISC that uses the nop() function, it fails due to the following error: drivers/watchdog/pic32-wdt.c: Assembler messages: drivers/watchdog/pic32-wdt.c:125: Error: unrecognized instruction `nop' The driver currently uses the generic version of nop() from include/asm-generic/barrier.h: #ifndef nop #define nop() asm volatile ("nop") #endif Let's fix this on OpenRISC by defining an architecture-specific version of nop(). This was tested by performing an allmodconfig openrisc cross compile on an aarch64 host. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202601180236.BVy480We-lkp@intel.com/ Signed-off-by: Brian Masney Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit 5e13d0a37666955b6cfddc0f73cb40ed645b8a05 Author: Florian Westphal Date: Mon Jan 19 12:30:42 2026 +0100 netfilter: xt_tcpmss: check remaining length before reading optlen [ Upstream commit 735ee8582da3d239eb0c7a53adca61b79fb228b3 ] Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload). Reported-by: sungzii Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 29f51913cb77c0ab779d85683d9c832685e630bf Author: Yuto Hamaguchi Date: Fri Dec 19 20:53:51 2025 +0900 netfilter: nf_conntrack: Add allow_clash to generic protocol handler [ Upstream commit 8a49fc8d8a3e83dc51ec05bcd4007bdea3c56eec ] The upstream commit, 71d8c47fc653711c41bc3282e5b0e605b3727956 ("netfilter: conntrack: introduce clash resolution on insertion race"), sets allow_clash=true in the UDP/UDPLITE protocol handler but does not set it in the generic protocol handler. As a result, packets composed of connectionless protocols at each layer, such as UDP over IP-in-IP, still drop packets due to conflicts during conntrack insertion. To resolve this, this patch sets allow_clash in the nf_conntrack_l4proto_generic. Signed-off-by: Yuto Hamaguchi Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 74431472d16eb54e9451b2060f74a3d35e8bdc8b Author: Zhang Yi Date: Mon Jan 5 09:45:16 2026 +0800 ext4: use reserved metadata blocks when splitting extent on endio [ Upstream commit 01942af95ab6c9d98e64ae01fdc243a03e4b973f ] When performing buffered writes, we may need to split and convert an unwritten extent into a written one during the end I/O process. However, we do not reserve space specifically for these metadata changes, we only reserve 2% of space or 4096 blocks. To address this, we use EXT4_GET_BLOCKS_PRE_IO to potentially split extents in advance and EXT4_GET_BLOCKS_METADATA_NOFAIL to utilize reserved space if necessary. These two approaches can reduce the likelihood of running out of space and losing data. However, these methods are merely best efforts, we could still run out of space, and there is not much difference between converting an extent during the writeback process and the end I/O process, it won't increase the risk of losing data if we postpone the conversion. Therefore, also use EXT4_GET_BLOCKS_METADATA_NOFAIL in ext4_convert_unwritten_extents_endio() to prepare for the buffered I/O iomap conversion, which may perform extent conversion during the end I/O process. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Reviewed-by: Ojaswin Mujoo Link: https://patch.msgid.link/20260105014522.1937690-2-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 3b3c11f944bd9ab3fcce7006430b4e00921976cb Author: Li Chen Date: Thu Dec 11 19:51:42 2025 +0800 ext4: mark group extend fast-commit ineligible [ Upstream commit 1f8dd813a1c771b13c303f73d876164bc9b327cc ] Fast commits only log operations that have dedicated replay support. EXT4_IOC_GROUP_EXTEND grows the filesystem to the end of the last block group and updates the same on-disk metadata without going through the fast commit tracking paths. In practice these operations are rare and usually followed by further updates, but mixing them into a fast commit makes the overall semantics harder to reason about and risks replay gaps if new call sites appear. Teach ext4 to mark the filesystem fast-commit ineligible when EXT4_IOC_GROUP_EXTEND grows the filesystem. This forces those transactions to fall back to a full commit, ensuring that the group extension changes are captured by the normal journal rather than partially encoded in fast commit TLVs. This change should not affect common workloads but makes online resize via GROUP_EXTEND safer and easier to reason about under fast commit. Testing: 1. prepare: dd if=/dev/zero of=/root/fc_resize.img bs=1M count=0 seek=256 mkfs.ext4 -O fast_commit -F /root/fc_resize.img mkdir -p /mnt/fc_resize && mount -t ext4 -o loop /root/fc_resize.img /mnt/fc_resize 2. Extended the filesystem to the end of the last block group using a helper that calls EXT4_IOC_GROUP_EXTEND on the mounted filesystem and checked fc_info: ./group_extend_helper /mnt/fc_resize cat /proc/fs/ext4/loop0/fc_info shows the "Resize" ineligible reason increased. 3. Fsynced a file on the resized filesystem and confirmed that the fast commit ineligible counter incremented for the resize transaction: touch /mnt/fc_resize/file /root/fsync_file /mnt/fc_resize/file sync cat /proc/fs/ext4/loop0/fc_info Signed-off-by: Li Chen Link: https://patch.msgid.link/20251211115146.897420-6-me@linux.beauty Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit bf5b609524497c195f801cd5707252384aed8149 Author: Baokun Li Date: Tue Dec 9 21:31:16 2025 +0800 ext4: move ext4_percpu_param_init() before ext4_mb_init() [ Upstream commit 270564513489d98b721a1e4a10017978d5213bff ] When running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the `DOUBLE_CHECK` macro defined, the following panic is triggered: ================================================================== EXT4-fs error (device vdc): ext4_validate_block_bitmap:423: comm mount: bg 0: bad block bitmap checksum BUG: unable to handle page fault for address: ff110000fa2cc000 PGD 3e01067 P4D 3e02067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none) RIP: 0010:percpu_counter_add_batch+0x13/0xa0 Call Trace: ext4_mark_group_bitmap_corrupted+0xcb/0xe0 ext4_validate_block_bitmap+0x2a1/0x2f0 ext4_read_block_bitmap+0x33/0x50 mb_group_bb_bitmap_alloc+0x33/0x80 ext4_mb_add_groupinfo+0x190/0x250 ext4_mb_init_backend+0x87/0x290 ext4_mb_init+0x456/0x640 __ext4_fill_super+0x1072/0x1680 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4f6/0x6b0 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/test With DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() reads and validates the block bitmap. When the validation fails, ext4_mark_group_bitmap_corrupted() attempts to update sbi->s_freeclusters_counter. However, this percpu_counter has not been initialized yet at this point, which leads to the panic described above. Fix this by moving the execution of ext4_percpu_param_init() to occur before ext4_mb_init(), ensuring the per-CPU counters are initialized before they are used. Signed-off-by: Baokun Li Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20251209133116.731350-1-libaokun@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 27a99fa3125278bac0225c0119d3776e12bb57e1 Author: Li Chen Date: Thu Dec 11 19:51:41 2025 +0800 ext4: mark group add fast-commit ineligible [ Upstream commit 89b4336fd5ec78f51f9d3a1d100f3ffa3228e604 ] Fast commits only log operations that have dedicated replay support. Online resize via EXT4_IOC_GROUP_ADD updates the superblock and group descriptor metadata without going through the fast commit tracking paths. In practice these operations are rare and usually followed by further updates, but mixing them into a fast commit makes the overall semantics harder to reason about and risks replay gaps if new call sites appear. Teach ext4 to mark the filesystem fast-commit ineligible when ext4_ioctl_group_add() adds new block groups. This forces those transactions to fall back to a full commit, ensuring that the filesystem geometry updates are captured by the normal journal rather than partially encoded in fast commit TLVs. This change should not affect common workloads but makes online resize via GROUP_ADD safer and easier to reason about under fast commit. Testing: 1. prepare: dd if=/dev/zero of=/root/fc_resize.img bs=1M count=0 seek=256 mkfs.ext4 -O fast_commit -F /root/fc_resize.img mkdir -p /mnt/fc_resize && mount -t ext4 -o loop /root/fc_resize.img /mnt/fc_resize 2. Ran a helper that issues EXT4_IOC_GROUP_ADD on the mounted filesystem and checked the resize ineligible reason: ./group_add_helper /mnt/fc_resize cat /proc/fs/ext4/loop0/fc_info shows "Resize": > 0. 3. Fsynced a file on the resized filesystem and verified that the fast commit stats report at least one ineligible commit: touch /mnt/fc_resize/file /root/fsync_file /mnt/fc_resize/file sync cat /proc/fs/ext4/loop0/fc_info shows fc stats ineligible > 0. Signed-off-by: Li Chen Link: https://patch.msgid.link/20251211115146.897420-5-me@linux.beauty Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit c315d742675a514c64dc186eb9aed9a09e2ec26e Author: Eric Dumazet Date: Thu Jan 15 09:41:40 2026 +0000 ipv6: exthdrs: annotate data-race over multiple sysctl [ Upstream commit 978b67d28358b0b4eacfa94453d1ad4e09b123ad ] Following four sysctls can change under us, add missing READ_ONCE(). - ipv6.sysctl.max_dst_opts_len - ipv6.sysctl.max_dst_opts_cnt - ipv6.sysctl.max_hbh_opts_len - ipv6.sysctl.max_hbh_opts_cnt Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260115094141.3124990-8-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 58e7c79cf0a3aae28ea60471661129fe9bd72808 Author: Eric Dumazet Date: Thu Jan 15 09:41:41 2026 +0000 ipv6: annotate data-races in net/ipv6/route.c [ Upstream commit f062e8e25102324364aada61b8283356235bc3c1 ] sysctls are read while their values can change, add READ_ONCE() annotations. Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260115094141.3124990-9-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7d4c7533b632cc500b64412522f4eaabedbc2eed Author: Eric Dumazet Date: Thu Jan 15 09:41:38 2026 +0000 ipv6: annotate data-races over sysctl.flowlabel_reflect [ Upstream commit 5ade47c974b46eb2a1279185962a0ffa15dc5450 ] Add missing READ_ONCE() when reading ipv6.sysctl.flowlabel_reflect, as its value can be changed under us. Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260115094141.3124990-6-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ccaff26fac79fbee2b7328f829d5cadbd54b3fe6 Author: Eric Dumazet Date: Thu Jan 15 09:41:37 2026 +0000 ipv6: annotate data-races in ip6_multipath_hash_{policy,fields}() [ Upstream commit 03e9d91dd64e2f5ea632df5d59568d91757efc4d ] Add missing READ_ONCE() when reading sysctl values. Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260115094141.3124990-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 08e7ae48e175cb88b9b14f0ea8e19c0756f305a8 Author: Miri Korenblit Date: Wed Jan 7 13:51:57 2026 +0200 wifi: cfg80211: allow only one NAN interface, also in multi radio [ Upstream commit e69fda4d07701373354e52b0321bd40311d743d0 ] According to Wi-Fi Aware (TM) 4.0 specification 2.8, A NAN device can have one NAN management interface. This applies also to multi radio devices. The current code allows a driver to support more than one NAN interface, if those are not in the same radio. Fix it. Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260107135129.fdaecec0fe8a.I246b5ba6e9da3ec1481ff197e47f6ce0793d7118@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 8362565a6905ae78baac4d1779294cd32fd948d0 Author: Baochen Qiang Date: Mon Jan 12 15:36:26 2026 +0800 wifi: ath12k: fix mac phy capability parsing [ Upstream commit b5151c9b6e3a347416a4b4b55fc00195526d8771 ] Currently ath12k_pull_mac_phy_cap_svc_ready_ext() assumes only one band supported in each phy, hence it skips 5 GHz band if 2 GHz band support is detected. This does not work for device which gets only one phy but has both bands supported, such as QCC2072. Change to check each band individually to fix this issue. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-6-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit e8ce435b9b1fffc0b95ca4581539713ae772ed4c Author: Baochen Qiang Date: Mon Jan 12 15:36:24 2026 +0800 wifi: ath12k: fix preferred hardware mode calculation [ Upstream commit 7f852de0003219c431a6f2ffd951fd82a4673660 ] For single pdev device like WCN7850/QCC2072, preferred_hw_mode is initialized to WMI_HOST_HW_MODE_SINGLE. Later when firmware sends supported modes to host, each mode is compared with the initial one and if the priority of the new mode is higher, update the parameter and store mode capability. For WCN7850, this does not result in issue, as one of the supported mode indeed has a higher priority. However the only available mode of QCC2072 at this stage is WMI_HOST_HW_MODE_SINGLE, which fails the comparison, hence mode capability is not stored. Subsequently driver initialization fails. Fix it by accepting a mode with the same priority. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-4-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5358df6e61c6f14426c5111da08617c84a0f0eb4 Author: Qian Zhang Date: Thu Jan 8 11:46:07 2026 +0800 wifi: ath11k: Fix failure to connect to a 6 GHz AP [ Upstream commit 0bc8c48de6f06c0cac52dde024ffda4433de6234 ] STA fails to connect to a 6 GHz AP with the following errors: ath11k_pci 0000:01:00.0: failed to handle chan list with power type 1 wlp1s0: deauthenticating from c8:a3:e8:dd:41:e3 by local choice (Reason: 3=DEAUTH_LEAVING) ath11k_reg_handle_chan_list() treats the update as redundant and returns -EINVAL. That causes the connection attempt to fail. Avoid unnecessary validation during association. Apply the regulatory redundant check only when the power type is IEEE80211_REG_UNSET_AP, which only occurs during core initialization. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Signed-off-by: Qian Zhang Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260108034607.812885-1-qian.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 0e76bc37f1922c8d1472ab2f32fba2ca65ca34c5 Author: Ross Vandegrift Date: Sat Jan 3 17:00:34 2026 -0800 wifi: ath11k: add pm quirk for Thinkpad Z13/Z16 Gen1 [ Upstream commit 4015b1972763d7d513172276e51439f37e622a92 ] Z16 Gen1 has the wakeup-from-suspend issues from [1] but was never added to the appropriate quirk list. I've tested this patch on top of 6.18.2, it fixes the issue for me on 21D4 Mark Pearson provided the other product IDs covering the second Z16 Gen1 and both Z13 Gen1 identifiers. They share the same firmware, and folks in the bugzilla report do indeed see the problem on Z13. [1] - https://bugzilla.kernel.org/show_bug.cgi?id=219196 Signed-off-by: Ross Vandegrift Reviewed-by: Baochen Qiang Tested-by: Mark Pearson Reviewed-by: Mark Pearson Link: https://patch.msgid.link/wj7o2kmb7g54stdjvxp2hjqrnutnq3jbf4s2uh4ctvmlxdq7tf@nbkj2ebakhrd Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 4b4784394099dbcf35765bd657c36c74c727a66e Author: Ping-Ke Shih Date: Sat Jan 10 10:20:15 2026 +0800 wifi: rtw89: disable EHT protocol by chip capabilities [ Upstream commit 7fd36ffedeedc97c44a10249a3f12d471bb2dc26 ] For certain chip models, EHT protocol is disabled, and driver must follow the capabilities. Otherwise, chips become unusable. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260110022019.2254969-5-pkshih@realtek.com Signed-off-by: Sasha Levin commit 4d510f668f0f78de897a5ea75f97f2c53d0c6db1 Author: Shawn Lin Date: Wed Dec 24 18:01:01 2025 +0800 PCI: dw-rockchip: Disable BAR 0 and BAR 1 for Root Port [ Upstream commit b5d712e5b87fc56ff838684afb1bae359eb8069f ] Some Rockchip PCIe Root Ports report bogus size of 1GiB for the BAR memories and they cause below resource allocation issue during probe. pci 0000:00:00.0: [1d87:3588] type 01 class 0x060400 PCIe Root Port pci 0000:00:00.0: BAR 0 [mem 0x00000000-0x3fffffff] pci 0000:00:00.0: BAR 1 [mem 0x00000000-0x3fffffff] pci 0000:00:00.0: ROM [mem 0x00000000-0x0000ffff pref] ... pci 0000:00:00.0: BAR 0 [mem 0x900000000-0x93fffffff]: assigned pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: can't assign; no space pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: failed to assign pci 0000:00:00.0: ROM [mem 0xf0200000-0xf020ffff pref]: assigned pci 0000:00:00.0: BAR 0 [mem 0x900000000-0x93fffffff]: releasing pci 0000:00:00.0: ROM [mem 0xf0200000-0xf020ffff pref]: releasing pci 0000:00:00.0: BAR 0 [mem 0x900000000-0x93fffffff]: assigned pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: can't assign; no space pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: failed to assign Since there is no use of the Root Port BAR memories, disable both of them. Signed-off-by: Shawn Lin [mani: reworded the description and comment] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/1766570461-138256-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Sasha Levin commit 717fc84f180d02f179a8843a9835e1309d8f1cf6 Author: Chin-Yen Lee Date: Sat Jan 10 10:20:13 2026 +0800 wifi: rtw89: wow: add reason codes for disassociation in WoWLAN mode [ Upstream commit 2fd8f953f25173d14981d8736b6f5bfcd757e51b ] Some APs disconnect clients by sending a Disassociation frame rather than a Deauthentication frame. Since these frames use different reason codes in WoWLAN mode, this commit adds support for handling Disassociation to prevent missed disconnection events. Signed-off-by: Chin-Yen Lee Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260110022019.2254969-3-pkshih@realtek.com Signed-off-by: Sasha Levin commit fa8301c29079a3bec996e531efc79d31ca76dbb5 Author: Ping-Ke Shih Date: Sat Jan 10 10:20:17 2026 +0800 wifi: rtw89: mac: correct page number for CSI response [ Upstream commit aa2a44d0d22d45d659b9f01638809b1735e46cff ] For beamforming procedure, hardware reserve memory page for CSI response. The unit of register is (value - 1), so add one accordingly as expected. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260110022019.2254969-7-pkshih@realtek.com Signed-off-by: Sasha Levin commit ef7fa19809b2d892d45da53f90ac698d13c367fd Author: Ping-Ke Shih Date: Sat Jan 10 10:20:12 2026 +0800 wifi: rtw89: pci: validate sequence number of TX release report [ Upstream commit 957eda596c7665f2966970fd1dcc35fe299b38e8 ] Hardware rarely reports abnormal sequence number in TX release report, which will access out-of-bounds of wd_ring->pages array, causing NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1085 Comm: irq/129-rtw89_p Tainted: G S U 6.1.145-17510-g2f3369c91536 #1 (HASH:69e8 1) Call Trace: rtw89_pci_release_tx+0x18f/0x300 [rtw89_pci (HASH:4c83 2)] rtw89_pci_napi_poll+0xc2/0x190 [rtw89_pci (HASH:4c83 2)] net_rx_action+0xfc/0x460 net/core/dev.c:6578 net/core/dev.c:6645 net/core/dev.c:6759 handle_softirqs+0xbe/0x290 kernel/softirq.c:601 ? rtw89_pci_interrupt_threadfn+0xc5/0x350 [rtw89_pci (HASH:4c83 2)] __local_bh_enable_ip+0xeb/0x120 kernel/softirq.c:499 kernel/softirq.c:423 rtw89_pci_interrupt_threadfn+0xf8/0x350 [rtw89_pci (HASH:4c83 2)] ? irq_thread+0xa7/0x340 kernel/irq/manage.c:0 irq_thread+0x177/0x340 kernel/irq/manage.c:1205 kernel/irq/manage.c:1314 ? thaw_kernel_threads+0xb0/0xb0 kernel/irq/manage.c:1202 ? irq_forced_thread_fn+0x80/0x80 kernel/irq/manage.c:1220 kthread+0xea/0x110 kernel/kthread.c:376 ? synchronize_irq+0x1a0/0x1a0 kernel/irq/manage.c:1287 ? kthread_associate_blkcg+0x80/0x80 kernel/kthread.c:331 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 To prevent crash, validate rpp_info.seq before using. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260110022019.2254969-2-pkshih@realtek.com Signed-off-by: Sasha Levin commit ffbcca93034f1e9133678b5e67f2e7d90a87378d Author: Zenm Chen Date: Mon Jan 12 08:43:58 2026 +0800 wifi: rtw89: Add support for MSI AX1800 Nano (GUAX18N) [ Upstream commit 3116f287b81fe777a00b93ab07ec3c270093b185 ] Add the ID 0db0:f0c8 to the table to support an additional RTL8832BU adapter: MSI AX1800 Nano (GUAX18N). Compile tested only. Link: https://github.com/morrownr/rtl8852bu-20250826/pull/2 Signed-off-by: Zenm Chen Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260112004358.5516-1-zenmchen@gmail.com Signed-off-by: Sasha Levin commit e15768e68820142077bbca402d8e902f64ade1b0 Author: Ankit Soni Date: Mon Dec 1 14:39:40 2025 +0000 iommu/amd: move wait_on_sem() out of spinlock [ Upstream commit d2a0cac10597068567d336e85fa3cbdbe8ca62bf ] With iommu.strict=1, the existing completion wait path can cause soft lockups under stressed environment, as wait_on_sem() busy-waits under the spinlock with interrupts disabled. Move the completion wait in iommu_completion_wait() out of the spinlock. wait_on_sem() only polls the hardware-updated cmd_sem and does not require iommu->lock, so holding the lock during the busy wait unnecessarily increases contention and extends the time with interrupts disabled. Signed-off-by: Ankit Soni Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 3308c7504e093b22e91a4468470309cee2e26b83 Author: Szymon Wilczek Date: Sun Dec 21 16:58:06 2025 +0100 wifi: libertas: fix WARNING in usb_tx_block [ Upstream commit d66676e6ca96bf8680f869a9bd6573b26c634622 ] The function usb_tx_block() submits cardp->tx_urb without ensuring that any previous transmission on this URB has completed. If a second call occurs while the URB is still active (e.g. during rapid firmware loading), usb_submit_urb() detects the active state and triggers a warning: 'URB submitted while active'. Fix this by enforcing serialization: call usb_kill_urb() before submitting the new request. This ensures the URB is idle and safe to reuse. Reported-by: syzbot+67969ab6a2551c27f71b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=67969ab6a2551c27f71b Signed-off-by: Szymon Wilczek Link: https://patch.msgid.link/20251221155806.23925-1-swilczek.lx@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 27272429732d9db5b5d4b0449ed08c982967d9ef Author: Wander Lairson Costa Date: Tue Jan 6 08:49:48 2026 -0300 rtla: Fix NULL pointer dereference in actions_parse [ Upstream commit a0890f9dbd24b302d327fe7dad9b9c5be0e278aa ] The actions_parse() function uses strtok() to tokenize the trigger string, but does not check if the returned token is NULL before passing it to strcmp(). If the trigger parameter is an empty string or contains only delimiter characters, strtok() returns NULL, causing strcmp() to dereference a NULL pointer and crash the program. This issue can be triggered by malformed user input or edge cases in trigger string parsing. Add a NULL check immediately after the strtok() call to validate that a token was successfully extracted before using it. If no token is found, the function now returns -1 to indicate a parsing error. Signed-off-by: Wander Lairson Costa Link: https://lore.kernel.org/r/20260106133655.249887-13-wander@redhat.com Signed-off-by: Tomas Glozar Signed-off-by: Sasha Levin commit 1260bee01493126cf9c872b6ca2af261173baa6d Author: Kuan-Chung Chen Date: Wed Dec 31 17:06:46 2025 +0800 wifi: rtw89: fix potential zero beacon interval in beacon tracking [ Upstream commit eb57be32f438c57c88d6ce756101c1dfbcc03bba ] During fuzz testing, it was discovered that bss_conf->beacon_int might be zero, which could result in a division by zero error in subsequent calculations. Set a default value of 100 TU if the interval is zero to ensure stability. Signed-off-by: Kuan-Chung Chen Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251231090647.56407-11-pkshih@realtek.com Signed-off-by: Sasha Levin commit fce7f6f63915472d8dd6e9af7b2e3124d124c547 Author: Slark Xiao Date: Mon Jan 5 10:26:46 2026 +0800 net: wwan: mhi: Add network support for Foxconn T99W760 [ Upstream commit 915a5f60ad947e8dd515d2cc77a96a14dffb3f15 ] T99W760 is designed based on Qualcomm SDX35 chip. It use similar architecture with SDX72/SDX75 chip. So we need to assign initial link id for this device to make sure network available. Signed-off-by: Slark Xiao Link: https://patch.msgid.link/20260105022646.10630-1-slark_xiao@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c7e5d819388e525196a340a0634e45d715d0272d Author: Alexander Grest Date: Mon Dec 8 13:28:57 2025 -0800 iommu/arm-smmu-v3: Improve CMDQ lock fairness and efficiency [ Upstream commit df180b1a4cc51011c5f8c52c7ec02ad2e42962de ] The SMMU CMDQ lock is highly contentious when there are multiple CPUs issuing commands and the queue is nearly full. The lock has the following states: - 0: Unlocked - >0: Shared lock held with count - INT_MIN+N: Exclusive lock held, where N is the # of shared waiters - INT_MIN: Exclusive lock held, no shared waiters When multiple CPUs are polling for space in the queue, they attempt to grab the exclusive lock to update the cons pointer from the hardware. If they fail to get the lock, they will spin until either the cons pointer is updated by another CPU. The current code allows the possibility of shared lock starvation if there is a constant stream of CPUs trying to grab the exclusive lock. This leads to severe latency issues and soft lockups. Consider the following scenario where CPU1's attempt to acquire the shared lock is starved by CPU2 and CPU0 contending for the exclusive lock. CPU0 (exclusive) | CPU1 (shared) | CPU2 (exclusive) | `cmdq->lock` -------------------------------------------------------------------------- trylock() //takes | | | 0 | shared_lock() | | INT_MIN | fetch_inc() | | INT_MIN | no return | | INT_MIN + 1 | spins // VAL >= 0 | | INT_MIN + 1 unlock() | spins... | | INT_MIN + 1 set_release(0) | spins... | | 0 see[NOTE] (done) | (sees 0) | trylock() // takes | 0 | *exits loop* | cmpxchg(0, INT_MIN) | 0 | | *cuts in* | INT_MIN | cmpxchg(0, 1) | | INT_MIN | fails // != 0 | | INT_MIN | spins // VAL >= 0 | | INT_MIN | *starved* | | INT_MIN [NOTE] The current code resets the exclusive lock to 0 regardless of the state of the lock. This causes two problems: 1. It opens the possibility of back-to-back exclusive locks and the downstream effect of starving shared lock. 2. The count of shared lock waiters are lost. To mitigate this, we release the exclusive lock by only clearing the sign bit while retaining the shared lock waiter count as a way to avoid starving the shared lock waiters. Also deleted cmpxchg loop while trying to acquire the shared lock as it is not needed. The waiters can see the positive lock count and proceed immediately after the exclusive lock is released. Exclusive lock is not starved in that submitters will try exclusive lock first when new spaces become available. Reviewed-by: Mostafa Saleh Reviewed-by: Nicolin Chen Signed-off-by: Alexander Grest Signed-off-by: Jacob Pan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 6cdb21e0c9fdee484feba14fc9e72e9d07daf9f3 Author: Ding Hui Date: Sat Dec 20 20:03:50 2025 +0800 dm: remove fake timeout to avoid leak request [ Upstream commit f3a9c95a15d2f4466acad5c68faeff79ca5e9f47 ] Since commit 15f73f5b3e59 ("blk-mq: move failure injection out of blk_mq_complete_request"), drivers are responsible for calling blk_should_fake_timeout() at appropriate code paths and opportunities. However, the dm driver does not implement its own timeout handler and relies on the timeout handling of its slave devices. If an io-timeout-fail error is injected to a dm device, the request will be leaked and never completed, causing tasks to hang indefinitely. Reproduce: 1. prepare dm which has iscsi slave device 2. inject io-timeout-fail to dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/fail_io_timeout/probability echo 10 >/sys/kernel/debug/fail_io_timeout/times 3. read/write dm 4. iscsiadm -m node -u Result: hang task like below [ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds. [ 862.244133] Tainted: G E 6.19.0-rc1+ #51 [ 862.244337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000 [ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi] [ 862.245264] Call Trace: [ 862.245587] [ 862.245814] __schedule+0x810/0x15c0 [ 862.246557] schedule+0x69/0x180 [ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120 [ 862.247688] elevator_change+0x16d/0x460 [ 862.247893] elevator_set_none+0x87/0xf0 [ 862.248798] blk_unregister_queue+0x12e/0x2a0 [ 862.248995] __del_gendisk+0x231/0x7e0 [ 862.250143] del_gendisk+0x12f/0x1d0 [ 862.250339] sd_remove+0x85/0x130 [sd_mod] [ 862.250650] device_release_driver_internal+0x36d/0x530 [ 862.250849] bus_remove_device+0x1dd/0x3f0 [ 862.251042] device_del+0x38a/0x930 [ 862.252095] __scsi_remove_device+0x293/0x360 [ 862.252291] scsi_remove_target+0x486/0x760 [ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi] [ 862.252886] process_one_work+0x633/0xe50 [ 862.253101] worker_thread+0x6df/0xf10 [ 862.253647] kthread+0x36d/0x720 [ 862.254533] ret_from_fork+0x2a6/0x470 [ 862.255852] ret_from_fork_asm+0x1a/0x30 [ 862.256037] Remove the blk_should_fake_timeout() check from dm, as dm has no native timeout handling and should not attempt to fake timeouts. Signed-off-by: Ding Hui Reviewed-by: Christoph Hellwig Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 8f220e851a00b29c94535710e416bcdb12e9c7ae Author: Daniel Gomez Date: Sat Dec 20 04:49:37 2025 +0100 dm: replace -EEXIST with -EBUSY [ Upstream commit b13ef361d47f09b7aecd18e0383ecc83ff61057e ] The -EEXIST error code is reserved by the module loading infrastructure to indicate that a module is already loaded. When a module's init function returns -EEXIST, userspace tools like kmod interpret this as "module already loaded" and treat the operation as successful, returning 0 to the user even though the module initialization actually failed. This follows the precedent set by commit 54416fd76770 ("netfilter: conntrack: helper: Replace -EEXIST by -EBUSY") which fixed the same issue in nf_conntrack_helper_register(). Affected modules: * dm_cache dm_clone dm_integrity dm_mirror dm_multipath dm_pcache * dm_vdo dm-ps-round-robin dm_historical_service_time dm_io_affinity * dm_queue_length dm_service_time dm_snapshot Signed-off-by: Daniel Gomez Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 6b20fde2f14b3e3649cf2072c1c19e53854cc44c Author: Zong-Zhe Yang Date: Mon Dec 29 11:09:25 2025 +0800 wifi: rtw89: regd: 6 GHz power type marks default when inactive [ Upstream commit 8c96752d99c0b094af68317a8c701b09bd0862d9 ] When inactive, 6 GHz power type has been assigned to the default one, but missed to mark the local control variable, dflt, true. Then, this might let some 6 GHz power info of disconnected APs keep being taken into account under certain cases. So, mark default when inactive. Signed-off-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251229030926.27004-12-pkshih@realtek.com Signed-off-by: Sasha Levin commit f85d790c3cb702547c80c1c5df17d729a9095ff0 Author: Bitterblue Smith Date: Wed Dec 24 01:26:45 2025 +0200 wifi: rtw88: Fix inadvertent sharing of struct ieee80211_supported_band data [ Upstream commit fcac0f23d4d20b11014a39f8e2527cdc12ec9c82 ] Internally wiphy writes to individual channels in this structure, so we must not share one static definition of channel list between multiple device instances, because that causes hard to debug breakage. For example, with two rtw88 driven devices in the system, channel information may get incoherent, preventing channel use. Copied from commit 0ae36391c804 ("wifi: rtw89: Fix inadverent sharing of struct ieee80211_supported_band data"). Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/e94ad653-2b6d-4284-a33c-8c694f88955b@gmail.com Signed-off-by: Sasha Levin commit ad9b80ee310ed734482a2e5da874b67f88ac0ef8 Author: Bitterblue Smith Date: Wed Dec 24 01:25:32 2025 +0200 wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band() [ Upstream commit 2ba12401cc1f2d970fa2e7d5b15abde3f5abd40d ] Simplify the code by using device managed memory allocations. This also fixes a memory leak in rtw_register_hw(). The supported bands were not freed in the error path. Copied from commit 145df52a8671 ("wifi: rtw89: Convert rtw89_core_set_supported_band to use devm_*"). Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/1aa7fdef-2d5b-4a31-a4e9-fac8257ed30d@gmail.com Signed-off-by: Sasha Levin commit 6552d7992860fc59b903fcbffef3054db43692f9 Author: Chih-Kang Chang Date: Tue Dec 23 11:06:51 2025 +0800 wifi: rtw89: mcc: reset probe counter when receiving beacon [ Upstream commit 1b40c1c7571fcf926095ed92f25bd87900bdc8ed ] For BE chips, needs to transmit QoS null data periodically to ensure the connection with AP in GC+STA mode. However, in environments with interference, the Qos null data might fail to transmit successfully. Therefore, when receive the beacon from AP will reset the QoS null data failure counter to avoid unnecessary disconnection. Signed-off-by: Chih-Kang Chang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251223030651.480633-13-pkshih@realtek.com Signed-off-by: Sasha Levin commit 5a7362a3b613205da10f8be91e84504f79543533 Author: Chih-Kang Chang Date: Tue Dec 23 11:06:50 2025 +0800 wifi: rtw89: setting TBTT AGG number when mac port initialization [ Upstream commit 5e5f83fba48381098b26a8b2513a6d5fc5c66ccb ] When initializing mac port, needs to set TBTT AGG number to trigger TBTT related interrupts. Otherwise, after sending join info H2C command with disconnection mode, firmware will clear TBTT AGG number. Without the setting from mac port initialization after that, this port will not be able to transmit beacons. Signed-off-by: Chih-Kang Chang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251223030651.480633-12-pkshih@realtek.com Signed-off-by: Sasha Levin commit efa0f7fa3a43802a75a215e0be6dd9e27732f7b1 Author: Zong-Zhe Yang Date: Tue Dec 23 11:06:44 2025 +0800 wifi: rtw89: ser: enable error IMR after recovering from L1 [ Upstream commit f4de946bdb379f543e3a599f8f048d741ad4a58e ] After recovering from L1, explicitly enable error IMR to ensure next L1 SER (system error recovery) can work normally. Signed-off-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251223030651.480633-6-pkshih@realtek.com Signed-off-by: Sasha Levin commit 232418bbe02612c657bdc242f29de38d9b4db733 Author: Jose Ignacio Tornos Martinez Date: Wed Nov 26 10:18:56 2025 +0100 wifi: rtw89: 8922a: set random mac if efuse contains zeroes [ Upstream commit 41be33d3efc120f6a2c02d12742655f2aa09e1b6 ] I have some rtl8922ae devices with no permanent mac stored in efuse. It could be properly saved and/or configured from user tools like NetworkManager, but it would be desirable to be able to initialize it somehow to get the device working by default. So, in the same way as with other devices, if the mac address read from efuse contains zeros, a random mac address is assigned to at least allow operation, and the user is warned about this in case any action needs to be considered. Signed-off-by: Jose Ignacio Tornos Martinez Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251126091905.217951-1-jtornosm@redhat.com Signed-off-by: Sasha Levin commit e1958f4d66a57d09f49321e2f5cdf52fd3b13eed Author: Hsiu-Ming Chang Date: Fri Dec 5 08:32:04 2025 +0800 wifi: rtw88: rtw8821cu: Add ID for Mercusys MU6H [ Upstream commit 77653c327e11c71c5363b18a53fbf2b92ed21da4 ] Add support for Mercusys MU6H AC650 High Gain Wireless Dual Band USB Adapter V1.30. It is based on RTL8811CU, usb device ID is 2c4e:0105. Signed-off-by: Hsiu-Ming Chang Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251205003245.5762-1-cges30901@gmail.com Signed-off-by: Sasha Levin commit 509becaee5680a39bde00c2c7d448dfeb39a8e05 Author: Bitterblue Smith Date: Sun Nov 30 16:50:31 2025 +0200 wifi: rtw88: 8822b: Avoid WARNING in rtw8822b_config_trx_mode() [ Upstream commit 44d1f624bbdd2d60319374ba85f7195a28d00c90 ] rtw8822b_set_antenna() can be called from userspace when the chip is powered off. In that case a WARNING is triggered in rtw8822b_config_trx_mode() because trying to read the RF registers when the chip is powered off returns an unexpected value. Call rtw8822b_config_trx_mode() in rtw8822b_set_antenna() only when the chip is powered on. ------------[ cut here ]------------ write RF mode table fail WARNING: CPU: 0 PID: 7183 at rtw8822b.c:824 rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b] CPU: 0 UID: 0 PID: 7183 Comm: iw Tainted: G W OE 6.17.5-arch1-1 #1 PREEMPT(full) 01c39fc421df2af799dd5e9180b572af860b40c1 Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: LENOVO 82KR/LNVNB161216, BIOS HBCN18WW 08/27/2021 RIP: 0010:rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b] Call Trace: rtw8822b_set_antenna+0x57/0x70 [rtw88_8822b 370206f42e5890d8d5f48eb358b759efa37c422b] rtw_ops_set_antenna+0x50/0x80 [rtw88_core 711c8fb4f686162be4625b1d0b8e8c6a5ac850fb] ieee80211_set_antenna+0x60/0x100 [mac80211 f1845d85d2ecacf3b71867635a050ece90486cf3] nl80211_set_wiphy+0x384/0xe00 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? netdev_run_todo+0x63/0x550 genl_family_rcv_msg_doit+0xfc/0x160 genl_rcv_msg+0x1aa/0x2b0 ? __pfx_nl80211_pre_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_nl80211_set_wiphy+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_nl80211_post_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x59/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x285/0x3c0 ? __alloc_skb+0xdb/0x1a0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x39f/0x3d0 ? import_iovec+0x2f/0x40 ___sys_sendmsg+0x99/0xe0 ? refill_obj_stock+0x12e/0x240 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x81/0x970 ? do_syscall_64+0x81/0x970 ? ksys_read+0x73/0xf0 ? do_syscall_64+0x81/0x970 ? count_memcg_events+0xc2/0x190 ? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]--- Link: https://github.com/lwfinger/rtw88/issues/366 Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/fb9a3444-9319-4aa2-8719-35a6308bf568@gmail.com Signed-off-by: Sasha Levin commit 3cf7a584327a61db4f6277ca13ad320af86dce06 Author: Roman Peshkichev Date: Tue Nov 25 23:09:37 2025 +0500 wifi: rtw88: fix DTIM period handling when conf->dtim_period is zero [ Upstream commit 9f68fdcdc9dbf21be2a48feced90ff7f77d07443 ] The function rtw_set_dtim_period() accepted an 'int' dtim_period parameter, while mac80211 provides dtim_period as 'u8' in struct ieee80211_bss_conf. In IBSS (ad-hoc) mode mac80211 may set dtim_period to 0. The driver unconditionally wrote (dtim_period - 1) to REG_DTIM_COUNTER_ROOT, which resulted in 0xFF when dtim_period was 0. This caused delays in broadcast/multicast traffic processing and issues with ad-hoc operation. Convert the function parameter to u8 to match ieee80211_bss_conf and avoid the underflow by writing 0 when dtim_period is 0. Link: https://github.com/lwfinger/rtw88/issues/406 Signed-off-by: Roman Peshkichev Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251125180937.22977-1-roman.peshkichev@gmail.com Signed-off-by: Sasha Levin commit cf0e2c83136133f1aab3082d092e046fbc79991f Author: Manivannan Sadhasivam Date: Thu Dec 18 17:34:52 2025 +0530 PCI: dwc: Skip PME_Turn_Off broadcast and L2/L3 transition during suspend if link is not up [ Upstream commit cfd2fdfd0a8da2e5bbfdc4009b9c4b8bf164c937 ] During system suspend, if the PCIe link is not up, then there is no need to broadcast PME_Turn_Off message and wait for L2/L3 transition. So skip them. Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Tested-by: Vincent Guittot Reviewed-by: Frank Li Reviewed-by: Shawn Lin Link: https://patch.msgid.link/20251218-pci-dwc-suspend-rework-v2-1-5a7778c6094a@oss.qualcomm.com Signed-off-by: Sasha Levin commit fe136426e30ca6debcf916fd6a141555ed9fde74 Author: Jori Koolstra Date: Tue Oct 28 13:22:12 2025 +0100 jfs: nlink overflow in jfs_rename [ Upstream commit 9218dc26fd922b09858ecd3666ed57dfd8098da8 ] If nlink is maximal for a directory (-1) and inside that directory you perform a rename for some child directory (not moving from the parent), then the nlink of the first directory is first incremented and later decremented. Normally this is fine, but when nlink = -1 this causes a wrap around to 0, and then drop_nlink issues a warning. After applying the patch syzbot no longer issues any warnings. I also ran some basic fs tests to look for any regressions. Signed-off-by: Jori Koolstra Reported-by: syzbot+9131ddfd7870623b719f@syzkaller.appspotmail.com Closes: https://syzbot.org/bug?extid=9131ddfd7870623b719f Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 974dac536e8c9ec2963a8201aabc66fa3212da2c Author: Haotian Zhang Date: Mon Dec 1 19:38:01 2025 +0800 jfs: Add missing set_freezable() for freezable kthread [ Upstream commit eb0cfcf265714b419cc3549895a00632e76732ae ] The jfsIOWait() thread calls try_to_freeze() but lacks set_freezable(), causing it to remain non-freezable by default. This prevents proper freezing during system suspend. Add set_freezable() to make the thread freezable as intended. Signed-off-by: Haotian Zhang Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 8e5297128563d62b4c3b587b2fd75228c4d917f5 Author: Lianqin Hu Date: Mon Feb 9 08:38:29 2026 +0000 ALSA: usb-audio: Add iface reset and delay quirk for AB13X USB Audio [ Upstream commit ac656d7d7c70f7c352c7652bc2bb0c1c8c2dde08 ] Setting up the interface when suspended/resumeing fail on this card. Adding a reset and delay quirk will eliminate this problem. usb 1-1: New USB device found, idVendor=001f, idProduct=0b21 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: AB13X USB Audio usb 1-1: Manufacturer: Generic usb 1-1: SerialNumber: 20210926172016 Signed-off-by: Lianqin Hu Link: https://patch.msgid.link/TYUPR06MB6217522D0DB6E2C9DF46B56ED265A@TYUPR06MB6217.apcprd06.prod.outlook.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e6645e625480cdf1079a4265f758d13b70721029 Author: Takashi Iwai Date: Mon Feb 9 13:12:11 2026 +0100 ALSA: mixer: oss: Add card disconnect checkpoints [ Upstream commit 084d5d44418148662365eced3e126ad1a81ee3e2 ] ALSA OSS mixer layer calls the kcontrol ops rather individually, and pending calls might be not always caught at disconnecting the device. For avoiding the potential UAF scenarios, add sanity checks of the card disconnection at each entry point of OSS mixer accesses. The rwsem is taken just before that check, hence the rest context should be covered by that properly. Link: https://patch.msgid.link/20260209121212.171430-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 572e4274251fb67f4bc55f2f958eb0bd5a7df2eb Author: Illia Barbashyn <04baril@gmail.com> Date: Sat Feb 7 23:19:37 2026 +0100 ALSA: hda/realtek - Enable mute LEDs on HP ENVY x360 15-es0xxx [ Upstream commit ac1ff574bbc09a6c90f4fe8f9e6b8d66c983064c ] The mute and mic-mute LEDs on HP ENVY x360 Convertible 15-es0xxx (PCI SSID 103c:88b3) do not work with the current driver. This model requires a combination of COEFBIT and GPIO fixups to correctly control the LEDs. Introduce a new fixup function alc245_fixup_hp_envy_x360_mute_led and add a quirk to apply it. Signed-off-by: Illia Barbashyn <04baril@gmail.com> Link: https://patch.msgid.link/20260207221955.24132-1-04baril@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2d8f056e9c68faee873cd40c9dd6bef13a2c4da9 Author: Ziyi Guo Date: Thu Feb 5 05:24:29 2026 +0000 ASoC: fsl: imx-rpmsg: use snd_soc_find_dai_with_mutex() in probe [ Upstream commit 84faa91585fa22a161763f2fe8f84a602a196c87 ] imx_rpmsg_probe() calls snd_soc_find_dai() without holding client_mutex. However, snd_soc_find_dai() has lockdep_assert_held(&client_mutex) indicating callers must hold this lock, as the function iterates over the global component list. All other callers of snd_soc_find_dai() either hold client_mutex via the snd_soc_bind_card() path or use the snd_soc_find_dai_with_mutex() wrapper. Use snd_soc_find_dai_with_mutex() instead to fix the missing lock protection. Signed-off-by: Ziyi Guo Reviewed-by: Frank Li Link: https://patch.msgid.link/20260205052429.4046903-1-n7l8m4@u.northwestern.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c3ac651a4f89bcb38a643e6ef7294615a9eb9740 Author: Praveen Talari Date: Wed Feb 4 21:58:52 2026 +0530 spi: geni-qcom: Fix abort sequence execution for serial engine errors [ Upstream commit 96e041647bb0f9d92f95df1d69cb7442d7408b79 ] The driver currently skips the abort sequence for target mode when serial engine errors occur. This leads to improper error recovery as the serial engine may remain in an undefined state without proper cleanup, potentially causing subsequent operations to fail or behave unpredictably. Fix this by ensuring the abort sequence and DMA reset always execute during error recovery, as both are required for proper serial engine error handling. Co-developed-by: Konrad Dybcio Signed-off-by: Konrad Dybcio Signed-off-by: Praveen Talari Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260204162854.1206323-3-praveen.talari@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 42068f7dd42b559c4eeae645e1455ff36518866a Author: Ranjani Sridharan Date: Wed Feb 4 10:18:32 2026 +0200 ASoC: SOF: Intel: hda: Fix NULL pointer dereference [ Upstream commit 16c589567a956d46a7c1363af3f64de3d420af20 ] If there's a mismatch between the DAI links in the machine driver and the topology, it is possible that the playback/capture widget is not set, especially in the case of loopback capture for echo reference where we use the dummy DAI link. Return the error when the widget is not set to avoid a null pointer dereference like below when the topology is broken. RIP: 0010:hda_dai_get_ops.isra.0+0x14/0xa0 [snd_sof_intel_hda_common] Signed-off-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Reviewed-by: Mateusz Redzynia Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260204081833.16630-10-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9da857e6b5fd87f79c0a4dac9e32d5a86616513e Author: Ziyi Guo Date: Fri Jan 30 18:26:51 2026 +0000 power: sequencing: fix missing state_lock in pwrseq_power_on() error path [ Upstream commit e1dccb485c2876ac1318f36ccc0155416c633a48 ] pwrseq_power_on() calls pwrseq_unit_disable() when the post_enable callback fails. However, this call is outside the scoped_guard(mutex, &pwrseq->state_lock) block that ends. pwrseq_unit_disable() has lockdep_assert_held(&pwrseq->state_lock), which will fail when called from this error path. Add the scoped_guard block to cover the post_enable callback and its error handling to ensure the lock is held when pwrseq_unit_disable() is called. Signed-off-by: Ziyi Guo Link: https://patch.msgid.link/20260130182651.1576579-1-n7l8m4@u.northwestern.edu Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit aba5b98c4108812082f96a27a5181f1a146616af Author: René Rebe Date: Sun Nov 23 13:13:30 2025 +0100 modpost: Amend ppc64 save/restfpr symnames for -Os build [ Upstream commit 3cd9763ce4ad999d015cf0734e6b968cead95077 ] Building a size optimized ppc64 kernel (-Os), gcc emits more FP save/restore symbols, that the linker generates on demand into the .sfpr section. Explicitly allow-list those in scripts/mod/modpost.c, too. They are needed for the amdgpu in-kernel floating point support. MODPOST Module.symvers ERROR: modpost: "_restfpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_26" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_27" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_25" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_28" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_29" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savefpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savefpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_15" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! WARNING: modpost: suppressed 56 unresolved symbol warnings because there were too many) Signed-off-by: René Rebe Link: https://patch.msgid.link/20251123.131330.407910684435629198.rene@exactco.de Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit cafea2adb3583df1dccbe13efaed28c2f925652d Author: Hsieh Hung-En Date: Sat Jan 31 00:00:17 2026 +0800 ASoC: es8328: Add error unwind in resume [ Upstream commit 8232e6079ae6f8d3a61d87973cb427385aa469b9 ] Handle failures in the resume path by unwinding previously enabled resources. If enabling regulators or syncing the regcache fails, disable regulators and unprepare the clock to avoid leaking resources and leaving the device in a partially resumed state. Signed-off-by: Hsieh Hung-En Link: https://patch.msgid.link/20260130160017.2630-6-hungen3108@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 460796f33df7dd976850a0e3a0a90e0dc941966b Author: Bastien Nocera Date: Sun Jan 25 13:12:02 2026 +0100 HID: logitech-hidpp: Add support for Logitech K980 [ Upstream commit af4fe07a9d963a72438ade96cf090e84b3399d0c ] Add support for the solar-charging Logitech K980 keyboard, over Bluetooth. Bolt traffic doesn't get routed through logitech-dj, so this code isn't triggered when Bolt is used. Signed-off-by: Bastien Nocera Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit c8cde3ddd12ad7d0e6b5a3e0ea3914a9a778adf4 Author: Felix Gu Date: Thu Jan 15 21:54:15 2026 +0800 hwmon: (nct7363) Fix a resource leak in nct7363_present_pwm_fanin [ Upstream commit 4923bbff0bcffe488b3aa76829c829bd15b02585 ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In nct7363_present_pwm_fanin, it does not release the reference, causing a resource leak. Signed-off-by: Felix Gu Link: https://lore.kernel.org/r/tencent_9717645269E4C07D3D131F52201E12E5E10A@qq.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 5e13b9b341ee74dff8cb1dd9e8eab359f01ea36f Author: Ji-Ze Hong (Peter Hong) Date: Tue Dec 23 13:10:40 2025 +0800 hwmon: (f71882fg) Add F81968 support [ Upstream commit e4a3d6f79c9933fece64368168c46d6cf5fc2e52 ] Add hardware monitoring support for the Fintek F81968 Super I/O chip. It is fully compatible with F81866. Several products share compatibility with the F81866. To better distinguish between them, ensure that the Product ID is displayed when the device is probed. Signed-off-by: Ji-Ze Hong (Peter Hong) Link: https://lore.kernel.org/r/20251223051040.10227-1-peter_hong@fintek.com.tw Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 3fa44a5e3bc771a96fe127ef9ff7a699c12815cb Author: Felix Gu Date: Thu Jan 15 21:51:48 2026 +0800 hwmon: (emc2305) Fix a resource leak in emc2305_of_parse_pwm_child [ Upstream commit 2954ce672b7623478c1cfeb69e6a6e4042a3656e ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In emc2305_of_parse_pwm_child, it does not release the reference, causing a resource leak. Signed-off-by: Felix Gu Link: https://lore.kernel.org/r/tencent_738BA80BBF28F3440301EEE6F9E470165105@qq.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit da684ff541a42238c62be9b0749b4158756ca420 Author: Anj Duvnjak Date: Tue Dec 23 09:09:42 2025 +1100 hwmon: (nct6683) Add customer ID for ASRock Z590 Taichi [ Upstream commit c0fa7879c9850bd4597740a79d4fac5ebfcf69cc ] Add support for customer ID 0x1621 found on ASRock Z590 Taichi boards using the Nuvoton NCT6686D embedded controller. This allows the driver to instantiate without requiring the force=1 module parameter. Tested on two separate ASRock Z590 Taichi boards, both with EC firmware version 1.0 build 01/25/21. Signed-off-by: Anj Duvnjak Link: https://lore.kernel.org/r/20251222220942.10762-1-avian@extremenerds.net Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit cabde1dddad3b358ea9905e6b6ef22684b1331ae Author: Denis Pauk Date: Wed Dec 31 17:53:14 2025 +0200 hwmon: (nct6775) Add ASUS Pro WS WRX90E-SAGE SE [ Upstream commit 246167b17c14e8a5142368ac6457e81622055e0a ] Boards Pro WS WRX90E-SAGE SE has got a nct6775 chip, but by default there's no use of it because of resource conflict with WMI method. Add the board to the WMI monitoring list. Link: https://bugzilla.kernel.org/show_bug.cgi?id=204807 Signed-off-by: Denis Pauk Tested-by: Marcus Link: https://lore.kernel.org/r/20251231155316.2048-1-pauk.denis@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 3f0aa5f0794a7a3badbd8e4480b86f623a545a1a Author: Armin Wolf Date: Sun Jan 4 01:06:10 2026 +0100 hwmon: (dell-smm) Add support for Dell OptiPlex 7080 [ Upstream commit 46c3e87a79179454f741f797c274dd25f5c6125e ] The Dell OptiPlex 7080 supports the legacy SMM interface for reading sensors and performing fan control. Whitelist this machine so that this driver loads automatically. Closes: https://github.com/Wer-Wolf/i8kutils/issues/16 Signed-off-by: Armin Wolf Acked-by: Pali Rohár Link: https://lore.kernel.org/r/20260104000654.6406-1-W_Armin@gmx.de Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit ff0827301718d1760d37f6eae8717654d11755db Author: Chen Ni Date: Fri Jan 30 17:19:04 2026 +0800 ASoC: codecs: max98390: Check return value of devm_gpiod_get_optional() in max98390_i2c_probe() [ Upstream commit a1d14d8364eac2611fe1391c73ff0e5b26064f0e ] The devm_gpiod_get_optional() function may return an error pointer (ERR_PTR) in case of a genuine failure during GPIO acquisition, not just NULL which indicates the legitimate absence of an optional GPIO. Add an IS_ERR() check after the function call to catch such errors and propagate them to the probe function, ensuring the driver fails to load safely rather than proceeding with an invalid pointer. Signed-off-by: Chen Ni Link: https://patch.msgid.link/20260130091904.3426149-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f752cc300fa039e71ed265641ce47914ae4e107a Author: Miquel Raynal (Schneider Electric) Date: Thu Jan 22 16:13:34 2026 +0100 spi: cadence-qspi: Try hard to disable the clocks [ Upstream commit 612227b392eed94a3398dc03334a84a699a82276 ] In the remove path, we should try hard to perform all steps as we simply cannot fail. The "no runtime PM" quirk must only alter the state of the RPM core, but the clocks should still be disabled if that is possible. Move the disable call outside of the RPM quirk. Tested-by: Wolfram Sang Signed-off-by: Miquel Raynal (Schneider Electric) Tested-by: Santhosh Kumar K Link: https://patch.msgid.link/20260122-schneider-6-19-rc1-qspi-v4-9-f9c21419a3e6@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cf2a37be899dc1b01f53bf1d0157330eaf3e3f55 Author: Jesse.Zhang Date: Wed Jan 28 11:35:57 2026 +0800 drm/amdgpu: validate user queue size constraints [ Upstream commit 8079b87c02e531cc91601f72ea8336dd2262fdf1 ] Add validation to ensure user queue sizes meet hardware requirements: - Size must be a power of two for efficient ring buffer wrapping - Size must be at least AMDGPU_GPU_PAGE_SIZE to prevent undersized allocations This prevents invalid configurations that could lead to GPU faults or unexpected behavior. Reviewed-by: Christian König Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 25c5065bb6766e71fe2cf28bd089b6f62ea8210b Author: Zhongwei Date: Tue Jan 13 15:51:42 2026 +0800 drm/amd/display: avoid dig reg access timeout on usb4 link training fail [ Upstream commit 15b1d7b77e9836ff4184093163174a1ef28bbdd7 ] [Why] When usb4 link training fails, the dpia sym clock will be disabled and SYMCLK source should be changed back to phy clock. In enable_streams, it is assumed that link training succeeded and will switch from refclk to phy clock. But phy clk here might not be on. Dig reg access timeout will occur. [How] When enable_stream is hit, check if link training failed for usb4. If it did, fall back to the ref clock to avoid reg access timeout. Reviewed-by: Wenjing Liu Signed-off-by: Zhongwei Signed-off-by: Aurabindo Pillai Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2d02b419ef8d14603ad4312763897e8d4fd51fab Author: Matthew Stewart Date: Fri Jan 9 13:32:42 2026 -0500 drm/amd/display: Fix GFX12 family constant checks [ Upstream commit bdad08670278829771626ea7b57c4db531e2544f ] Using >=, <= for checking the family is not always correct. Reviewed-by: Aurabindo Pillai Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 30ed220ddcb89e1f8aa2122252115c0a4cd7cb88 Author: Chin-Ting Kuo Date: Tue Jan 20 20:30:04 2026 +0800 spi: spi-mem: Protect dirmap_create() with spi_mem_access_start/end [ Upstream commit 53f826ff5e0e3ecb279862ca7cce1491b94bb017 ] spi_mem_dirmap_create() may reconfigure controller-wide settings, which can interfere with concurrent transfers to other devices sharing the same SPI controller but using different chip selects. Wrap the ->dirmap_create() callback with spi_mem_access_start() and spi_mem_access_end() to serialize access and prevent cross-CS interference during dirmap creation. This patch has been verified on a setup where a SPI TPM is connected to CS0 of a SPI controller, while a SPI NOR flash is connected to CS1 of the same controller. Without this patch, spi_mem_dirmap_create() for the SPI NOR flash interferes with ongoing SPI TPM data transfers, resulting in failure to create the TPM device. This was tested on an ASPEED AST2700 EVB. Signed-off-by: Chin-Ting Kuo Reviewed-by: Paul Menzel Link: https://patch.msgid.link/20260120123005.1392071-2-chin-ting_kuo@aspeedtech.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 588faab060c5498a421b71e9bd35eaefbb264687 Author: Chen Ni Date: Tue Jan 27 11:32:50 2026 +0800 ASoC: sunxi: sun50i-dmic: Add missing check for devm_regmap_init_mmio [ Upstream commit 74823db9ba2e13f3ec007b354759b3d8125e462c ] Add check for the return value of devm_regmap_init_mmio() and return the error if it fails in order to catch the error. Signed-off-by: Chen Ni Link: https://patch.msgid.link/20260127033250.2044608-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ffb5fde572e947ffc487f602e13f2a9e1fe1356b Author: Billy Tsai Date: Fri Jan 23 17:26:26 2026 +0800 gpio: aspeed-sgpio: Change the macro to support deferred probe [ Upstream commit e18533b023ec7a33488bcf33140ce69bbba2894f ] Use module_platform_driver() to replace module_platform_driver_probe(). The former utilizes platform_driver_register(), which allows the driver to defer probing when it doesn't acquire the necessary resources due to probe order. In contrast, the latter uses __platform_driver_probe(), which includes the comment "Note that this is incompatible with deferred probing." Since our SGPIO driver requires access to the clock resource, the former is more suitable. Reviewed-by: Linus Walleij Signed-off-by: Billy Tsai Link: https://lore.kernel.org/r/20260123-upstream_sgpio-v2-1-69cfd1631400@aspeedtech.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 62914b5c295528fd2c473339a9b0adc97729ce97 Author: Damien Dagorn Date: Fri Jan 23 18:14:52 2026 +0100 ALSA: hda/realtek: fix LG Gram Style 14 speakers [ Upstream commit cc051fbd7f40226cc407558bc97c5099513e8657 ] The LG Gram Style 14 (14Z90RS-G.AD77F, SSID 1854:0490) with Realtek ALC298 shows normal routing and volume changes, but internal speakers stay silent unless a userland HDA-verb workaround is applied. Add a dedicated quirk for the LG Gram Style 14 that programs the codec coefficient sequence used by the known workaround and enables the speaker amps only during playback. Tested-by: Damien Dagorn Signed-off-by: Damien Dagorn Link: https://lore.kernel.org/CAN59QMUhd4kHrkRoJA6VzEr2VKezN2yjHnANaQoZn2-Bnwe3bQ@mail.gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 06d929be11327e316d64d3538357f26c12562a3d Author: gongqi <550230171hxy@gmail.com> Date: Thu Jan 22 23:55:01 2026 +0800 ALSA: hda/conexant: Add headset mic fix for MECHREVO Wujie 15X Pro [ Upstream commit f2581ea2d9f30844c437e348a462027ea25c12e9 ] The headset microphone on the MECHREVO Wujie 15X Pro requires the CXT_FIXUP_HEADSET_MIC quirk to function properly. Add the PCI SSID (0x1d05:0x3012) to the quirk table. Signed-off-by: gongqi <550230171hxy@gmail.com> Link: https://patch.msgid.link/20260122155501.376199-5-550230171hxy@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a36e053b1680428481aabd7bccd072ad240a4878 Author: David Phillips Date: Fri Jan 23 12:56:09 2026 +0900 HID: elecom: Add support for ELECOM HUGE Plus M-HT1MRBK [ Upstream commit b8e5fdf0bd022cd5493a5987ef66f5a24f8352d8 ] New model in the ELECOM HUGE trackball line that has 8 buttons but the report descriptor specifies only 5. The HUGE Plus supports connecting via Bluetooth, 2.4GHz wireless USB dongle, and directly via a USB-C cable. Each connection type reports a different device id, 01AA for cable, 01AB for USB dongle, and 01AC for Bluetooth. This patch adds these device IDs and applies the fixups similar to the other ELECOM devices to get all 8 buttons working for all 3 connection types. For reference, the usbhid-dump output: 001:013:001:DESCRIPTOR 1769085639.598405 05 01 09 02 A1 01 85 01 09 01 A1 00 05 09 19 01 29 05 15 00 25 01 75 01 95 05 81 02 75 03 95 01 81 01 05 01 09 30 09 31 16 01 80 26 FF 7F 75 10 95 02 81 06 09 38 15 81 25 7F 75 08 95 01 81 06 05 0C 0A 38 02 15 81 25 7F 75 08 95 01 81 06 C0 C0 05 0C 09 01 A1 01 85 02 15 01 26 8C 02 19 01 2A 8C 02 75 10 95 01 81 00 C0 05 01 09 80 A1 01 85 03 09 82 09 81 09 83 15 00 25 01 19 01 29 03 75 01 95 03 81 02 95 05 81 01 C0 06 01 FF 09 00 A1 01 85 08 09 00 15 00 26 FF 00 75 08 95 07 81 02 C0 06 02 FF 09 02 A1 01 85 06 09 02 15 00 26 FF 00 75 08 95 07 B1 02 C0 Signed-off-by: David Phillips Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 37914cef17eee90fb0d083dadae68d1ae655425b Author: Ricardo Ribalda Date: Thu Nov 13 23:04:00 2025 +0200 media: uvcvideo: Create an ID namespace for streaming output terminals [ Upstream commit 3d9f32e02c2ed85338be627de672e2b81b88a836 ] Some devices, such as the Grandstream GUV3100 and the LSK Meeting Eye for Business & Home, exhibit entity ID collisions between units and streaming output terminals. The UVC specification requires unit and terminal IDs to be unique, and uses the ID to reference entities: - In control requests, to identify the target entity - In the UVC units and terminals descriptors' bSourceID field, to identify source entities - In the UVC input header descriptor's bTerminalLink, to identify the terminal associated with a streaming interface Entity ID collisions break accessing controls and make the graph description in the UVC descriptors ambiguous. However, collisions where one of the entities is a streaming output terminal and the other entity is not a streaming terminal are less severe. Streaming output terminals have no controls, and, as they are the final entity in pipelines, they are never referenced in descriptors as source entities. They are referenced by ID only from innput header descriptors, which by definition only reference streaming terminals. For these reasons, we can work around the collision by giving streaming output terminals their own ID namespace. Do so by setting bit UVC_TERM_OUTPUT (15) in the uvc_entity.id field, which is normally never set as the ID is a 8-bit value. This ID change doesn't affect the entity name in the media controller graph as the name isn't constructed from the ID, so there should not be any impact on the uAPI. Although this change handles some ID collisions automagically, keep printing an error in uvc_alloc_new_entity() when a camera has invalid descriptors. Hopefully this message will help vendors fix their invalid descriptors. This new method of handling ID collisions includes a revert of commit 758dbc756aad ("media: uvcvideo: Use heuristic to find stream entity") that attempted to fix the problem urgently due to regression reports. Suggested-by: Laurent Pinchart Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Tested-by: Lili Orosz Co-developed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Link: https://patch.msgid.link/20251113210400.28618-1-laurent.pinchart@ideasonboard.com Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 882974699753f49d5c943643230472b2a4b5ca15 Author: Thorsten Schmelzer Date: Fri Jan 23 09:57:05 2026 +0100 HID: multitouch: add eGalaxTouch EXC3188 support [ Upstream commit 8e4ac86b2ddd36fe501e20ecfcc080e536df1f48 ] Add support for the for the EXC3188 touchscreen from eGalaxy. Signed-off-by: Thorsten Schmelzer Signed-off-by: Michael Tretter Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 16790e7e2987d84e2ce6a1b2b5f3db25c2123d6a Author: Wang, Sung-huai Date: Tue Dec 30 11:01:38 2025 +0800 drm/amd/display: Revert "init dispclk from bootup clock for DCN315" [ Upstream commit a625dc4989a2affb8f06e7b418bf30e1474b99c1 ] [Why&How] This reverts commit 14bb17cc37e0. Due to the change, the display shows garbage on startup. We have an alternative solution for the original issue: d24203bb629f ("drm/amd/display: Re-check seamless boot can be enabled or not") Reviewed-by: Nicholas Kazlauskas Signed-off-by: Wang, Sung-huai Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 37282c9129fd64a0e81baca75f339b827430bbfa Author: Rui Wang Date: Mon Jan 5 12:11:42 2026 -0500 media: rkisp1: Fix filter mode register configuration [ Upstream commit 5a50f2b61104d0d351b59ec179f67abab7870453 ] The rkisp1_flt_config() function performs an initial direct write to RKISP1_CIF_ISP_FILT_MODE without including the RKISP1_CIF_ISP_FLT_ENA bit, which clears the filter enable bit in the hardware. The subsequent read/modify/write sequence then reads back the register with the enable bit already cleared and cannot restore it, resulting in the filter being inadvertently disabled. Remove the redundant direct write. The read/modify/write sequence alone correctly preserves the existing enable bit state while updating the DNR mode and filter configuration bits. Signed-off-by: Rui Wang Reviewed-by: Stefan Klug Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260105171142.147792-2-rui.wang@ideasonboard.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 7b4d0fab3ff2c00c6d34e1952c9df5129a826aee Author: Ludovic Desroches Date: Fri Oct 24 18:14:53 2025 +0200 drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release [ Upstream commit bc847787233277a337788568e90a6ee1557595eb ] The atmel_hlcdc_plane_atomic_duplicate_state() callback was copying the atmel_hlcdc_plane state structure without properly duplicating the drm_plane_state. In particular, state->commit remained set to the old state commit, which can lead to a use-after-free in the next drm_atomic_commit() call. Fix this by calling __drm_atomic_helper_duplicate_plane_state(), which correctly clones the base drm_plane_state (including the ->commit pointer). It has been seen when closing and re-opening the device node while another DRM client (e.g. fbdev) is still attached: ============================================================================= BUG kmalloc-64 (Not tainted): Poison overwritten ----------------------------------------------------------------------------- 0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6b FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6b Allocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0 pid=29 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_framebuffer_remove+0x4cc/0x5a8 drm_mode_rmfb_work_fn+0x6c/0x80 process_one_work+0x12c/0x2cc worker_thread+0x2a8/0x400 kthread+0xc0/0xdc ret_from_fork+0x14/0x28 Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0 pid=169 drm_atomic_helper_commit_hw_done+0x100/0x150 drm_atomic_helper_commit_tail+0x64/0x8c commit_tail+0x168/0x18c drm_atomic_helper_commit+0x138/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0 flags=0x200(workingset|zone=0) Object 0xc611b340 @offset=832 fp=0xc611b7c0 Signed-off-by: Ludovic Desroches Reviewed-by: Manikandan Muralidharan Link: https://patch.msgid.link/20251024-lcd_fixes_mainlining-v1-2-79b615130dc3@microchip.com Signed-off-by: Manikandan Muralidharan Signed-off-by: Sasha Levin commit f1f3e18596e2ed392ed1b5dc9f7618b11f326ed0 Author: Ludovic Desroches Date: Thu Nov 20 11:38:25 2025 +0100 drm/atmel-hlcdc: don't reject the commit if the src rect has fractional parts [ Upstream commit 06682206e2a1883354ed758c09efeb51f435adbd ] Don’t reject the commit when the source rectangle has fractional parts. This can occur due to scaling: drm_atomic_helper_check_plane_state() calls drm_rect_clip_scaled(), which may introduce fractional parts while computing the clipped source rectangle. This does not imply the commit is invalid, so we should accept it instead of discarding it. Signed-off-by: Ludovic Desroches Reviewed-by: Manikandan Muralidharan Link: https://patch.msgid.link/20251120-lcd_scaling_fix-v1-1-5ffc98557923@microchip.com Signed-off-by: Manikandan Muralidharan Signed-off-by: Sasha Levin commit 082271e364a3205598c2e4e6233a9f49ce7941cf Author: Ludovic Desroches Date: Fri Oct 24 18:14:52 2025 +0200 drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback [ Upstream commit f12352471061df83a36edf54bbb16284793284e4 ] After several commits, the slab memory increases. Some drm_crtc_commit objects are not freed. The atomic_destroy_state callback only put the framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function to put all the objects that are no longer needed. It has been seen after hours of usage of a graphics application or using kmemleak: unreferenced object 0xc63a6580 (size 64): comm "egt_basic", pid 171, jiffies 4294940784 hex dump (first 32 bytes): 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:. 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:. backtrace (crc c25aa925): kmemleak_alloc+0x34/0x3c __kmalloc_cache_noprof+0x150/0x1a4 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Signed-off-by: Ludovic Desroches Reviewed-by: Manikandan Muralidharan Link: https://patch.msgid.link/20251024-lcd_fixes_mainlining-v1-1-79b615130dc3@microchip.com Signed-off-by: Manikandan Muralidharan Signed-off-by: Sasha Levin commit 1e89f8a2e8b000ce3aa130155965a4df0c90e676 Author: Nicholas Kazlauskas Date: Tue Jan 6 11:11:19 2026 -0500 drm/amd/display: Ensure link output is disabled in backend reset for PLL_ON [ Upstream commit 4589712e0111352973131bad975023b25569287c ] [Why] We're missing the code to actually disable the link output when we have to leave the SYMCLK_ON but the TX remains OFF. [How] Port the code from DCN401 that detects SYMCLK_ON_TX_OFF and disable the link output when the backend is reset. Reviewed-by: Ovidiu (Ovi) Bunea Signed-off-by: Nicholas Kazlauskas Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5f0c5775d4eebdba21bcd93b0ba184b566d8406b Author: Ovidiu Bunea Date: Fri Jan 2 17:48:59 2026 -0500 drm/amd/display: Disable FEC when powering down encoders [ Upstream commit 8cee62904caf95e5698fa0f2d420f5f22b4dea15 ] [why & how] VBIOS DMCUB FW can enable FEC for capable eDPs, but S/W DC state is only updated for link0 when transitioning into OS with driver loaded. This causes issues when the eDP is immediately hidden and DIG0 is assigned to another link that does not support FEC. Driver will attempt to disable FEC but FEC enablement occurs based on the link state, which does not have fec_state updated since it is a different link. Thus, FEC disablement on DIG0 will get skipped and cause no light up. Reviewed-by: Karen Chen Signed-off-by: Ovidiu Bunea Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit bc8b167f031ad37eaf33cae724004424172a0cb8 Author: Peter Ujfalusi Date: Tue Jan 20 21:35:04 2026 +0200 PCI: Add Intel Nova Lake audio Device ID [ Upstream commit b190870e0e0cfb375c0d4da02761c32083f3644d ] Add Nova Lake (NVL) audio Device ID The ID will be used by HDA legacy, SOF audio stack and the driver to determine which audio stack should be used (intel-dsp-config). Signed-off-by: Peter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Liam Girdwood Reviewed-by: Ranjani Sridharan Acked-by: Bjorn Helgaas Acked-by: Takashi Iwai Link: https://patch.msgid.link/20260120193507.14019-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d5262b2ee0620257bb6b3ac3fec182da95871d43 Author: Bard Liao Date: Mon Jan 19 17:17:48 2026 +0800 ASoC: soc-acpi-intel-arl-match: change rt722 amp endpoint to aggregated [ Upstream commit 08c09899960118ffb01417242e659eb6cc067d6a ] rt722 is aggregated with rt1320 amp in arl_rt722_l0_rt1320_l2 and it is the only audio configuration in the ARL platform. Set .aggregated = 1 to represent the fact and avoid unexpected issue. Signed-off-by: Bard Liao Reviewed-by: Liam Girdwood Reviewed-by: Ranjani Sridharan Link: https://patch.msgid.link/20260119091749.1752088-2-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cfe928c39b48f92a16ec6dce75e307007e1a3e5a Author: Thomas Weißschuh Date: Thu Jan 15 08:35:45 2026 +0100 virt: vbox: uapi: Mark inner unions in packed structs as packed [ Upstream commit c25d01e1c4f2d43f47af87c00e223f5ca7c71792 ] The unpacked unions within a packed struct generates alignment warnings on clang for 32-bit ARM: ./usr/include/linux/vbox_vmmdev_types.h:239:4: error: field u within 'struct vmmdev_hgcm_function_parameter32' is less aligned than 'union (unnamed union at ./usr/include/linux/vbox_vmmdev_types.h:223:2)' and is usually due to 'struct vmmdev_hgcm_function_parameter32' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] 239 | } u; | ^ ./usr/include/linux/vbox_vmmdev_types.h:254:6: error: field u within 'struct vmmdev_hgcm_function_parameter64::(anonymous union)::(unnamed at ./usr/include/linux/vbox_vmmdev_types.h:249:3)' is less aligned than 'union (unnamed union at ./usr/include/linux/vbox_vmmdev_types.h:251:4)' and is usually due to 'struct vmmdev_hgcm_function_parameter64::(anonymous union)::(unnamed at ./usr/include/linux/vbox_vmmdev_types.h:249:3)' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] With the recent changes to compile-test the UAPI headers in more cases, these warning in combination with CONFIG_WERROR breaks the build. Fix the warnings. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512140314.DzDxpIVn-lkp@intel.com/ Reported-by: Nathan Chancellor Closes: https://lore.kernel.org/linux-kbuild/20260110-uapi-test-disable-headers-arm-clang-unaligned-access-v1-1-b7b0fa541daa@kernel.org/ Suggested-by: Arnd Bergmann Link: https://lore.kernel.org/linux-kbuild/29b2e736-d462-45b7-a0a9-85f8d8a3de56@app.fastmail.com/ Signed-off-by: Thomas Weißschuh Tested-by: Nicolas Schier Reviewed-by: Nicolas Schier Acked-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260115-kbuild-alignment-vbox-v1-2-076aed1623ff@linutronix.de Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit b856cf4a155002e2ea3b2abd2acb257b85ed865b Author: Thomas Weißschuh Date: Thu Jan 15 08:35:44 2026 +0100 hyper-v: Mark inner union in hv_kvp_exchg_msg_value as packed [ Upstream commit 1e5271393d777f6159d896943b4c44c4f3ecff52 ] The unpacked union within a packed struct generates alignment warnings on clang for 32-bit ARM: ./usr/include/linux/hyperv.h:361:2: error: field within 'struct hv_kvp_exchg_msg_value' is less aligned than 'union hv_kvp_exchg_msg_value::(anonymous at ./usr/include/linux/hyperv.h:361:2)' and is usually due to 'struct hv_kvp_exchg_msg_value' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] 361 | union { | ^ With the recent changes to compile-test the UAPI headers in more cases, this warning in combination with CONFIG_WERROR breaks the build. Fix the warning. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512140314.DzDxpIVn-lkp@intel.com/ Reported-by: Nathan Chancellor Closes: https://lore.kernel.org/linux-kbuild/20260110-uapi-test-disable-headers-arm-clang-unaligned-access-v1-1-b7b0fa541daa@kernel.org/ Suggested-by: Arnd Bergmann Link: https://lore.kernel.org/linux-kbuild/29b2e736-d462-45b7-a0a9-85f8d8a3de56@app.fastmail.com/ Signed-off-by: Thomas Weißschuh Acked-by: Wei Liu (Microsoft) Tested-by: Nicolas Schier Reviewed-by: Nicolas Schier Acked-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260115-kbuild-alignment-vbox-v1-1-076aed1623ff@linutronix.de Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 79f42487ed60d0d5ffce97c3bb98f80c3d17735a Author: Hugo Villeneuve Date: Mon Jan 12 10:43:18 2026 -0500 drm: renesas: rz-du: mipi_dsi: fix kernel panic when rebooting for some panels [ Upstream commit 64aa8b3a60a825134f7d866adf05c024bbe0c24c ] Since commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for RZ/G2L") we may get the following kernel panic, for some panels, when rebooting: systemd-shutdown[1]: Rebooting. Call trace: ... do_serror+0x28/0x68 el1h_64_error_handler+0x34/0x50 el1h_64_error+0x6c/0x70 rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P) mipi_dsi_device_transfer+0x44/0x58 mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4 ili9881c_unprepare+0x38/0x88 drm_panel_unprepare+0xbc/0x108 This happens for panels that need to send MIPI-DSI commands in their unprepare() callback. Since the MIPI-DSI interface is stopped at that point, rzg2l_mipi_dsi_host_transfer() triggers the kernel panic. Fix by moving rzg2l_mipi_dsi_stop() to new callback function rzg2l_mipi_dsi_atomic_post_disable(). With this change we now have the correct power-down/stop sequence: systemd-shutdown[1]: Rebooting. rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_disable(): entry ili9881c-dsi 10850000.dsi.0: ili9881c_unprepare(): entry rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_post_disable(): entry reboot: Restarting system Suggested-by: Biju Das Signed-off-by: Hugo Villeneuve Tested-by: Biju Das Link: https://patch.msgid.link/20260112154333.655352-1-hugo@hugovil.com Signed-off-by: Biju Das Signed-off-by: Sasha Levin commit cb8b9a1755fe9f38e4fb7f287486d7e7fab3dba4 Author: Xiao Kan <814091656@qq.com> Date: Wed Jan 14 08:22:26 2026 -0500 drm: Account property blob allocations to memcg [ Upstream commit 26b4309a3ab82a0697751cde52eb336c29c19035 ] DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory. Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM. Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits. Signed-off-by: Xiao Kan <814091656@qq.com> Signed-off-by: Xiao Kan Link: https://patch.msgid.link/tencent_D12AA2DEDE6F359E1AF59405242FB7A5FD05@qq.com Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 662ec0a17b50462963a0e01d73991324e3a90152 Author: Donet Tom Date: Mon Jan 12 19:36:56 2026 +0530 drm/amdkfd: Fix GART PTE for non-4K pagesize in svm_migrate_gart_map() [ Upstream commit 6c160001661b6c4e20f5c31909c722741e14c2d8 ] In svm_migrate_gart_map(), while migrating GART mapping, the number of bytes copied for the GART table only accounts for CPU pages. On non-4K systems, each CPU page can contain multiple GPU pages, and the GART requires one 8-byte PTE per GPU page. As a result, an incorrect size was passed to the DMA, causing only a partial update of the GART table. Fix this function to work correctly on non-4K page-size systems by accounting for the number of GPU pages per CPU page when calculating the number of bytes to be copied. Acked-by: Christian König Reviewed-by: Philip Yang Signed-off-by: Ritesh Harjani (IBM) Signed-off-by: Donet Tom Signed-off-by: Felix Kuehling Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit acfc84cfa70aca5b970faf152979bc97b9f8b0c0 Author: Donet Tom Date: Mon Jan 12 19:36:54 2026 +0530 drm/amdkfd: Relax size checking during queue buffer get [ Upstream commit 42ea9cf2f16b7131cb7302acb3dac510968f8bdc ] HW-supported EOP buffer sizes are 4K and 32K. On systems that do not use 4K pages, the minimum buffer object (BO) allocation size is PAGE_SIZE (for example, 64K). During queue buffer acquisition, the driver currently checks the allocated BO size against the supported EOP buffer size. Since the allocated BO is larger than the expected size, this check fails, preventing queue creation. Relax the strict size validation and allow PAGE_SIZE-sized BOs to be used. Only the required 4K region of the buffer will be used as the EOP buffer and avoids queue creation failures on non-4K page systems. Acked-by: Christian König Suggested-by: Philip Yang Signed-off-by: Donet Tom Signed-off-by: Felix Kuehling Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6eb9fc7d451ce53568102ac3a70ffa4d6f0b3aab Author: fenugrec Date: Sun Jan 11 16:36:40 2026 -0500 ALSA: usb-audio: presonus s18xx uses little-endian [ Upstream commit 3ce03297baff0ba116769044e4594fb324d4a551 ] Use __le32 types for USB control transfers Signed-off-by: fenugrec Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260111-preso_clean1-v2-1-44b4e5129a75@mail.com Signed-off-by: Sasha Levin commit 9745c2561e55f5a4d15942fa6b4f3430d079b072 Author: Bharat Dev Burman Date: Tue Jan 13 00:12:40 2026 +0530 ALSA: hda/realtek: add HP Victus 16-e0xxx mute LED quirk [ Upstream commit 72919c57a055f6d7b79d66731dc398e9b433f47c ] HP Victus 16-e0xxx with ALC245 codec does not handle the toggling of the mute LED. This patch adds a quirk entry for subsystem ID 0x88eb using a new ALC245_FIXUP_HP_MUTE_LED_V2_COEFBIT fixup, enabling correct mute LED behavior. Signed-off-by: Bharat Dev Burman Link: https://patch.msgid.link/20260112184253.33376-1-bharat.singh7924@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c626a9b6b7ff23426eedb740c05a98fe737b9207 Author: Sakari Ailus Date: Wed Jan 7 23:55:31 2026 +0200 media: ipu6: Always close firmware stream [ Upstream commit 2b08b7007e55bd1793a58478d3ecea4fd95849a5 ] Close the firmware stream even when disabling a stream on an upstream sub-device fails. This allows the firmware to release resources related to a stream that is stopped in any case. Suggested-by: Bingbu Cao Signed-off-by: Sakari Ailus Reviewed-by: Bingbu Cao Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit eb7cdb7ab50b0371ab885427ae59ccd0bd513de6 Author: Sakari Ailus Date: Thu Dec 18 00:05:38 2025 +0200 media: ipu6: Close firmware streams on streaming enable failure [ Upstream commit 5925a92cc70d10c7d3124923c36da09b9c1a6eeb ] When enabling streaming fails, the stream is stopped in firmware but not closed. Do this to release resources on firmware side. Signed-off-by: Sakari Ailus Reviewed-by: Bingbu Cao Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 5d5190cbc4bbe2020b2120b004c40017049003b1 Author: Sakari Ailus Date: Thu Nov 27 14:14:22 2025 +0200 media: ipu6: Ensure stream_mutex is acquired when dealing with node list [ Upstream commit 779bdaad2abf718fb8116839e818e58852874b4d ] The ipu6 isys driver maintains the list of video buffer queues related to a stream (in ipu6 context streams on the same CSI-2 virtual channel) and this list is modified through VIDIOC_STREAMON and VIDIOC_STREAMOFF IOCTLs. Ensure the common mutex is acquired when accessing the linked list, i.e. the isys device context's stream_mutex. Add a lockdep assert to ipu6_isys_get_buffer_list() and switch to guard() while at it as the error handling becomes more simple this way. Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e913d0d8e26cd648ee1d54a268fb07428dcd1e89 Author: Hans de Goede Date: Tue Dec 30 18:03:10 2025 +0100 media: mt9m114: Return -EPROBE_DEFER if no endpoint is found [ Upstream commit 437e1f6a960035166495a5117aacbc596115eeb6 ] With IPU# bridges, endpoints may only be created when the IPU bridge is initialized. This may happen after the sensor driver's first probe(). Reviewed-by: Laurent Pinchart Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 7bccb94dff567a573160a01be93fb94dca4b1be0 Author: Hans de Goede Date: Tue Dec 30 18:03:03 2025 +0100 media: mt9m114: Avoid a reset low spike during probe() [ Upstream commit 84359d0a5e3afce5e3e3b6562efadff690614d5b ] mt9m114_probe() requests the reset GPIO in output low state: sensor->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW); and then almost immediately afterwards calls mt9m114_power_on() which does: gpiod_set_value(sensor->reset, 1); fsleep(duration); gpiod_set_value(sensor->reset, 0); which means that if the reset pin was high before this code runs that it will very briefly be driven low because of passing GPIOD_OUT_LOW when requesting the GPIO only to be driven high again possibly directly after that. Such a very brief driving low of the reset pin may put the chip in a confused state. Request the GPIO in high (reset the chip) state instead to avoid this, turning the initial gpiod_set_value() in mt9m114_power_on() into a no-op. and the fsleep() ensures that it will stay high long enough to properly reset the chip. Reviewed-by: Laurent Pinchart Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b02bcb378efa8af07827f49b3afcc5e825318c55 Author: Sakari Ailus Date: Fri Nov 21 13:48:40 2025 +0200 media: v4l2-async: Fix error handling on steps after finding a match [ Upstream commit 7345d6d356336c448d6b9230ed8704f39679fd12 ] Once an async connection is found to be matching with an fwnode, a sub-device may be registered (in case it wasn't already), its bound operation is called, ancillary links are created, the async connection is added to the sub-device's list of connections and removed from the global waiting connection list. Further on, the sub-device's possible own notifier is searched for possible additional matches. Fix these specific issues: - If v4l2_async_match_notify() failed before the sub-notifier handling, the async connection was unbound and its entry removed from the sub-device's async connection list. The latter part was also done in v4l2_async_match_notify(). - The async connection's sd field was only set after creating ancillary links in v4l2_async_match_notify(). It was however dereferenced in v4l2_async_unbind_subdev_one(), which was called on error path of v4l2_async_match_notify() failure. Signed-off-by: Sakari Ailus Tested-by: "Yew, Chang Ching" Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2e9d6b58ab814b9e20875792baab5d6581629cbe Author: Vladimir Zapolskiy Date: Mon Oct 20 17:02:27 2025 +0300 media: qcom: camss: Do not enable cpas fast ahb clock for SM8550 VFE lite [ Upstream commit a89e490ba3551823511588b7b3828d67f8b82954 ] The clock is needed to stream images over a full VFE IP on SM8550 CAMSS, and it should not be enabled, when an image stream is routed over any of two lite VFE IPs on the SoC. Signed-off-by: Vladimir Zapolskiy Acked-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b7210170b10e2d17f7a4f6b9d39cc092442db860 Author: Haoxiang Li Date: Sat Jan 3 15:46:47 2026 +0800 media: cx25821: Fix a resource leak in cx25821_dev_setup() [ Upstream commit 68cd8ac994cac38a305200f638b30e13c690753b ] Add release_mem_region() if ioremap() fails to release the memory region obtained by cx25821_get_resources(). Signed-off-by: Haoxiang Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit d29f33b2cf98e4901cd5457d1ee34062e808df73 Author: Kees Cook Date: Thu Dec 11 19:00:35 2025 -0800 media: solo6x10: Check for out of bounds chip_id [ Upstream commit 0fdf6323c35a134f206dcad5babb4ff488552076 ] Clang with CONFIG_UBSAN_SHIFT=y noticed a condition where a signed type (literal "1" is an "int") could end up being shifted beyond 32 bits, so instrumentation was added (and due to the double is_tw286x() call seen via inlining), Clang decides the second one must now be undefined behavior and elides the rest of the function[1]. This is a known problem with Clang (that is still being worked on), but we can avoid the entire problem by actually checking the existing max chip ID, and now there is no runtime instrumentation added at all since everything is known to be within bounds. Additionally use an unsigned value for the shift to remove the instrumentation even without the explicit bounds checking. Link: https://github.com/ClangBuiltLinux/linux/issues/2144 [1] Suggested-by: Nathan Chancellor Signed-off-by: Kees Cook Signed-off-by: Hans Verkuil [hverkuil: fix checkpatch warning for is_tw286x] Signed-off-by: Sasha Levin commit 2011929f0e4cf6a0a34dd6205911b12276904453 Author: Szymon Wilczek Date: Sat Dec 20 19:24:19 2025 +0100 media: pvrusb2: fix URB leak in pvr2_send_request_ex [ Upstream commit a8333c8262aed2aedf608c18edd39cf5342680a7 ] When pvr2_send_request_ex() submits a write URB successfully but fails to submit the read URB (e.g. returns -ENOMEM), it returns immediately without waiting for the write URB to complete. Since the driver reuses the same URB structure, a subsequent call to pvr2_send_request_ex() attempts to submit the still-active write URB, triggering a 'URB submitted while active' warning in usb_submit_urb(). Fix this by ensuring the write URB is unlinked and waited upon if the read URB submission fails. Reported-by: syzbot+405dcd13121ff75a9e16@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=405dcd13121ff75a9e16 Signed-off-by: Szymon Wilczek Acked-by: Mike Isely Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit d484d11030aae8a3d199ab6117db2190df605b2a Author: Thorsten Schmelzer Date: Tue Nov 25 15:29:57 2025 +0100 media: adv7180: fix frame interval in progressive mode [ Upstream commit 90289b67c5c1d4c18784059b27460d292e16d208 ] The ADV7280-M may internally convert interlaced video input to progressive video. If this mode is enabled, the ADV7280-M delivers progressive video frames at the field rate of 50 fields per second (PAL) or 60 fields per second (NTSC). Fix the reported frame interval if progressive video is enabled. Signed-off-by: Thorsten Schmelzer Reviewed-by: Niklas Söderlund Signed-off-by: Michael Tretter Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2f5427d8726b22b807beec248d7d6bf88e291e0b Author: Tuo Li Date: Thu Dec 18 20:09:55 2025 +0800 drm/panel: Fix a possible null-pointer dereference in jdi_panel_dsi_remove() [ Upstream commit 95eed73b871111123a8b1d31cb1fce7e902e49ea ] In jdi_panel_dsi_remove(), jdi is explicitly checked, indicating that it may be NULL: if (!jdi) mipi_dsi_detach(dsi); However, when jdi is NULL, the function does not return and continues by calling jdi_panel_disable(): err = jdi_panel_disable(&jdi->base); Inside jdi_panel_disable(), jdi is dereferenced unconditionally, which can lead to a NULL-pointer dereference: struct jdi_panel *jdi = to_panel_jdi(panel); backlight_disable(jdi->backlight); To prevent such a potential NULL-pointer dereference, return early from jdi_panel_dsi_remove() when jdi is NULL. Signed-off-by: Tuo Li Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20251218120955.11185-1-islituo@gmail.com Signed-off-by: Sasha Levin commit 7c0feaa0026baaf2d3df757eb543b220c43b04eb Author: Ming Qian Date: Wed Dec 17 11:02:22 2025 +0800 media: amphion: Clear last_buffer_dequeued flag for DEC_CMD_START [ Upstream commit d85f3207d75df6d7a08be6526b15ff398668206c ] The V4L2_DEC_CMD_START command may be used to handle the dynamic source change, which will triggers an implicit decoder drain. The last_buffer_dequeued flag is set in the implicit decoder drain, so driver need to clear it to continue the following decoding flow. Signed-off-by: Ming Qian Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit efa59cc2142db0df3098043bc48efe14edbd5c90 Author: Waiman Long Date: Mon Jan 12 11:00:19 2026 -0500 cgroup/cpuset: Don't fail cpuset.cpus change in v2 [ Upstream commit 6e6f13f6d5095f3a432da421e78f4d7d51ef39c8 ] Commit fe8cd2736e75 ("cgroup/cpuset: Delay setting of CS_CPU_EXCLUSIVE until valid partition") introduced a new check to disallow the setting of a new cpuset.cpus.exclusive value that is a superset of a sibling's cpuset.cpus value so that there will at least be one CPU left in the sibling in case the cpuset becomes a valid partition root. This new check does have the side effect of failing a cpuset.cpus change that make it a subset of a sibling's cpuset.cpus.exclusive value. With v2, users are supposed to be allowed to set whatever value they want in cpuset.cpus without failure. To maintain this rule, the check is now restricted to only when cpuset.cpus.exclusive is being changed not when cpuset.cpus is changed. The cgroup-v2.rst doc file is also updated to reflect this change. Signed-off-by: Waiman Long Reviewed-by: Chen Ridong Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit b725955d651dfb8f4e68feadc7b9cde09537e57a Author: Miquel Raynal Date: Fri Jan 9 18:18:01 2026 +0100 spi: spi-mem: Limit octal DTR constraints to octal DTR situations [ Upstream commit 8618271887ca10ac5108fe7e1d82ba8f1b152cf9 ] In this helper, any operation with a single DTR cycle (like 1S-1S-8D) is considered requiring a duplicated command opcode. This is wrong as this constraint only applies to octal DTR operations (8D-8D-8D). Narrow the application of this constraint to the concerned bus interface. Note: none of the possible XD-XD-XD pattern, with X being one of {1, 2, 4} would benefit from this check either as there is only in octal DTR mode that a single clock edge would be enough to transmit the full opcode. Make sure the constraint of expecting two bytes for the command is applied to the relevant bus interface. Reviewed-by: Tudor Ambarus Signed-off-by: Miquel Raynal Link: https://patch.msgid.link/20260109-winbond-v6-17-rc1-oddr-v2-3-1fff6a2ddb80@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 677681a41fc974269daef40e400f2066258ef7f8 Author: Sebastian Krzyszkowiak Date: Mon Jan 5 04:02:10 2026 +0100 ASoC: wm8962: Don't report a microphone if it's shorted to ground on plug [ Upstream commit e590752119029d87ce46d725e11245a52d22e1fe ] This usually means that a TRS plug with no microphone pin has been plugged into a TRRS socket. Cases where a user is plugging in a microphone while pressing a button will be handled via incoming interrupt after the user releases the button, so the microphone will still be detected once it becomes usable. Signed-off-by: Sebastian Krzyszkowiak Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260105-wm8962-l5-fixes-v1-3-f4f4eeacf089@puri.sm Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 669220b2fca69fffc0861f84c185a119de0b2554 Author: Sebastian Krzyszkowiak Date: Mon Jan 5 04:02:08 2026 +0100 ASoC: wm8962: Add WM8962_ADC_MONOMIX to "3D Coefficients" mask [ Upstream commit 66c26346ae30c883eef70acf9cf9054dfdb4fb2f ] This bit is handled by a separate control. Signed-off-by: Sebastian Krzyszkowiak Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260105-wm8962-l5-fixes-v1-1-f4f4eeacf089@puri.sm Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a85e45fcff1ba74d53d26d541d60d2055c304d67 Author: Matthew Brost Date: Fri Jan 9 17:27:35 2026 -0800 drm/xe: Only toggle scheduling in TDR if GuC is running [ Upstream commit dd1ef5e2456558876244795bb22a4d90cb24f160 ] If the firmware is not running during TDR (e.g., when the driver is unloading), there's no need to toggle scheduling in the GuC. In such cases, skip this step. v4: - Bail on wait UC not running (Niranjana) Signed-off-by: Matthew Brost Reviewed-by: Niranjana Vishwanathapura Link: https://patch.msgid.link/20260110012739.2888434-4-matthew.brost@intel.com Signed-off-by: Sasha Levin commit dc3097ef16e7e3a50cf03713d04357c1d7b497ca Author: Dmytro Laktyushkin Date: Tue Dec 16 16:38:50 2025 -0500 drm/amd/display: only power down dig on phy endpoints [ Upstream commit 0839d8d24e6f1fc2587c4a976f44da9fa69ae3d0 ] This avoids any issues with dpia endpoints Reviewed-by: Charlene Liu Signed-off-by: Dmytro Laktyushkin Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2b9e44b3849fdd20cfd88ec51102a03e60f0af6b Author: YuBiao Wang Date: Wed Nov 12 15:16:27 2025 +0800 drm/amdgpu: Skip loading SDMA_RS64 in VF [ Upstream commit 39c21b81112321cbe1267b02c77ecd2161ce19aa ] VFs use the PF SDMA ucode and are unable to load SDMA_RS64. Signed-off-by: YuBiao Wang Signed-off-by: Victor Skvortsov Reviewed-by: Gavin Wan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 409d19050cde825e2de85ae9d050fd0d8a96af96 Author: Brian Howard Date: Tue Dec 2 21:35:47 2025 -0500 HID: multitouch: add quirks for Lenovo Yoga Book 9i [ Upstream commit 822bc5b3744b0b2c2c9678aa1d80b2cf04fdfabf ] The Lenovo Yoga Book 9i is a dual-screen laptop, with a single composite USB device providing both touch and tablet interfaces for both screens. All inputs report through a single device, differentiated solely by report numbers. As there is no way for udev to differentiate the inputs based on USB vendor/product ID or interface numbers, custom naming is required to match against for downstream configuration. A firmware bug also results in an erroneous InRange message report being received after the stylus leaves proximity, blocking later touch events. Add required quirks for Gen 8 to Gen 10 models, including a new quirk providing for custom input device naming and dropping erroneous InRange reports. Signed-off-by: Brian Howard Tested-by: Brian Howard Tested-by: Kris Fredrick Reported-by: Andrei Shumailov Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220386 Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 5ed818e9560f1e190ab2bc107b261e8d1574ae68 Author: Tomasz Pakuła Date: Sat Nov 29 19:46:14 2025 +0100 HID: pidff: Do not set out of range trigger button [ Upstream commit e01a029654f7fb67d7151365410aa22be4e63dbe ] Some games (mainly observed with Kylotonn's WRC Serises) set trigger button to a random value, or always the same one, out of range. I observed 307 and other values but, for example, my Moza R9 only exposes 128 buttons AND it's trigger button field is 8-bit. This causes errors to appear in dmesg. Only set the trigger button and trigger interval in the trigger button is in range of the field. Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 18750cac9b015cc2a96300b3942883400f1c3bee Author: Joey Bednar Date: Wed Nov 12 06:06:23 2025 +0000 HID: apple: Add "SONiX KN85 Keyboard" to the list of non-apple keyboards [ Upstream commit 7273acfd0aef106093a8ffa3b4973eb70e5a3799 ] The SoNiX KN85 keyboard identifies as the "Apple, Inc. Aluminium Keyboard" and is not recognized as a non-apple keyboard. Adding "SoNiX KN85 Keyboard" to the list of non-apple keyboards fixes the function keys. Signed-off-by: Joey Bednar Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit e9e477d3197f7d8955a042c0d7f53f78f13218ba Author: Srinivasan Shanmugam Date: Thu Dec 11 21:25:20 2025 +0530 drm/amdgpu: Refactor amdgpu_gem_va_ioctl for Handling Last Fence Update and Timeline Management v4 [ Upstream commit bd8150a1b3370a9f7761c5814202a3fe5a79f44f ] This commit simplifies the amdgpu_gem_va_ioctl function, key updates include: - Moved the logic for managing the last update fence directly into amdgpu_gem_va_update_vm. - Introduced checks for the timeline point to enable conditional replacement or addition of fences. v2: Addressed review comments from Christian. v3: Updated comments (Christian). v4: The previous version selected the fence too early and did not manage its reference correctly, which could lead to stale or freed fences being used. This resulted in refcount underflows and could crash when updating GPU timelines. The fence is now chosen only after the VA mapping work is completed, and its reference is taken safely. After exporting it to the VM timeline syncobj, the driver always drops its local fence reference, ensuring balanced refcounting and avoiding use-after-free on dma_fence. Crash signature: [ 205.828135] refcount_t: underflow; use-after-free. [ 205.832963] WARNING: CPU: 30 PID: 7274 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110 ... [ 206.074014] Call Trace: [ 206.076488] [ 206.078608] amdgpu_gem_va_ioctl+0x6ea/0x740 [amdgpu] [ 206.084040] ? __pfx_amdgpu_gem_va_ioctl+0x10/0x10 [amdgpu] [ 206.089994] drm_ioctl_kernel+0x86/0xe0 [drm] [ 206.094415] drm_ioctl+0x26e/0x520 [drm] [ 206.098424] ? __pfx_amdgpu_gem_va_ioctl+0x10/0x10 [amdgpu] [ 206.104402] amdgpu_drm_ioctl+0x4b/0x80 [amdgpu] [ 206.109387] __x64_sys_ioctl+0x96/0xe0 [ 206.113156] do_syscall_64+0x66/0x2d0 ... [ 206.553351] BUG: unable to handle page fault for address: ffffffffc0dfde90 ... [ 206.553378] RIP: 0010:dma_fence_signal_timestamp_locked+0x39/0xe0 ... [ 206.553405] Call Trace: [ 206.553409] [ 206.553415] ? __pfx_drm_sched_fence_free_rcu+0x10/0x10 [gpu_sched] [ 206.553424] dma_fence_signal+0x30/0x60 [ 206.553427] drm_sched_job_done.isra.0+0x123/0x150 [gpu_sched] [ 206.553434] dma_fence_signal_timestamp_locked+0x6e/0xe0 [ 206.553437] dma_fence_signal+0x30/0x60 [ 206.553441] amdgpu_fence_process+0xd8/0x150 [amdgpu] [ 206.553854] sdma_v4_0_process_trap_irq+0x97/0xb0 [amdgpu] [ 206.554353] edac_mce_amd(E) ee1004(E) [ 206.554270] amdgpu_irq_dispatch+0x150/0x230 [amdgpu] [ 206.554702] amdgpu_ih_process+0x6a/0x180 [amdgpu] [ 206.555101] amdgpu_irq_handler+0x23/0x60 [amdgpu] [ 206.555500] __handle_irq_event_percpu+0x4a/0x1c0 [ 206.555506] handle_irq_event+0x38/0x80 [ 206.555509] handle_edge_irq+0x92/0x1e0 [ 206.555513] __common_interrupt+0x3e/0xb0 [ 206.555519] common_interrupt+0x80/0xa0 [ 206.555525] [ 206.555527] ... [ 206.555650] RIP: 0010:dma_fence_signal_timestamp_locked+0x39/0xe0 ... [ 206.555667] Kernel panic - not syncing: Fatal exception in interrupt Link: https://patchwork.freedesktop.org/patch/654669/ Cc: Alex Deucher Cc: Christian König Suggested-by: Christian König Signed-off-by: Srinivasan Shanmugam Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 486b2909ac284185900c06f05ffc6eca895f38b8 Author: Dmytro Laktyushkin Date: Wed Dec 10 15:52:39 2025 -0500 drm/amd/display: Add signal type check for dcn401 get_phyd32clk_src [ Upstream commit c979d8db7b0f293111f2e83795ea353c8ed75de9 ] Trying to access link enc on a dpia link will cause a crash otherwise Reviewed-by: Charlene Liu Signed-off-by: Dmytro Laktyushkin Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f58458249d8687c16ab7b7399db6877b99c18551 Author: Alex Deucher Date: Fri Dec 12 11:46:48 2025 -0500 drm/amdgpu: avoid a warning in timedout job handler [ Upstream commit c8cf9ddc549fb93cb5a35f3fe23487b1e6707e74 ] Only set an error on the fence if the fence is not signalled. We can end up with a warning if the per queue reset path signals the fence and sets an error as part of the reset, but fails to recover. Reviewed-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c10fe9471f3aa352bb9d9329d0b25e28e0672243 Author: Charlene Liu Date: Wed Dec 10 17:01:17 2025 -0500 drm/amd/display: Fix dsc eDP issue [ Upstream commit 878a4b73c11111ff5f820730f59a7f8c6fd59374 ] [why] Need to add function hook check before use Reviewed-by: Mohit Bawa Signed-off-by: Charlene Liu Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0b1005d5ca9a92489e79bcd66ba3b0d1af5d4bd1 Author: Tim Huang Date: Thu Dec 12 10:46:47 2024 +0800 drm/amdgpu: add support for HDP IP version 6.1.1 [ Upstream commit e2fd14f579b841f54a9b7162fef15234d8c0627a ] This initializes HDP IP version 6.1.1. Reviewed-by: Mario Limonciello Signed-off-by: Tim Huang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 20e248df7341b2754e88bb6f4a1119e47b69f174 Author: Nicolas Dufresne Date: Fri Nov 28 14:16:16 2025 -0500 media: mediatek: vcodec: Don't try to decode 422/444 VP9 [ Upstream commit 3e92d7e4935084ecdbdc88880cc4688618ae1557 ] This is not supported by the hardware and trying to decode these leads to LAT timeout errors. Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b173ba3365ff0c6d2de0dc58fd19904ec02d31cf Author: Hans de Goede Date: Mon Jan 5 16:51:34 2026 +0100 drm/panel: edp: add BOE NV140WUM-T08 panel [ Upstream commit 349d4efadc1f831ebc0b872ba1e3a2b7dd58b72b ] Add powerseq timing info for the BOE NV140WUM-T08 panel used on Lenovo Thinkpad T14s gen 6 (Snapdragon X1 Elite) laptops. edid-decode (hex): 00 ff ff ff ff ff ff 00 09 e5 26 0c 00 00 00 00 0a 21 01 04 a5 1e 13 78 03 d6 62 99 5e 5a 8e 27 25 53 58 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 33 3f 80 dc 70 b0 3c 40 30 20 36 00 2e bc 10 00 00 1a 00 00 00 fd 00 28 3c 4c 4c 10 01 0a 20 20 20 20 20 20 00 00 00 fe 00 42 4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fe 00 4e 56 31 34 30 57 55 4d 2d 54 30 38 0a 00 fa Signed-off-by: Hans de Goede Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260105155134.83266-1-johannes.goede@oss.qualcomm.com Signed-off-by: Sasha Levin commit 5e702ee8c7f5d469d1252bcfa0eac3d46b3ee03e Author: Brandon Brnich Date: Tue Oct 21 15:46:18 2025 -0500 media: chips-media: wave5: Process ready frames when CMD_STOP sent to Encoder [ Upstream commit 5da0380de41439ed64ed9a5218850db38544e315 ] CMD_STOP being sent to encoder before last job is executed by device_run can lead to an occasional dropped frame. Ensure that remaining ready buffers are drained by making a call to v4l2_m2m_try_schedule. Signed-off-by: Brandon Brnich Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b607b5e2c62b68a96a9d80075087d4fee7d09fe8 Author: Brandon Brnich Date: Tue Oct 21 15:46:17 2025 -0500 media: chips-media: wave5: Fix conditional in start_streaming [ Upstream commit b4e26c6fc1b3c225caf80d4a95c6f9fcbe959e17 ] When STREAMON(CAP) is called after STREAMON(OUT), the driver was failing to switch states from VPU_INST_STATE_OPEN to VPU_INST_STATE_INIT_SEQ and VPU_INST_STATE_PIC_RUN because the capture queue streaming boolean had not yet been set to true. This led to a hang in the encoder since the state was stuck in VPU_INST_STATE_OPEN. During the second call to start_streaming, the sequence initialization and frame buffer allocation should occur. Signed-off-by: Brandon Brnich Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 98c62dacabbd0d8886904daf565d6836d5593402 Author: Hans Verkuil Date: Wed Apr 30 09:21:53 2025 +0200 media: omap3isp: set initial format [ Upstream commit 7575b8dfa91f82fcb34ffd5568ff415ac4685794 ] Initialize the v4l2_format to a default. Empty formats are not allowed in V4L2, so this fixes v4l2-compliance issues: fail: v4l2-test-formats.cpp(514): !pix.width || !pix.height test VIDIOC_G_FMT: FAIL Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Sasha Levin commit 7ab5e86088f292d99052849c79e7af8a0b247692 Author: Hans Verkuil Date: Tue Oct 7 17:09:18 2025 +0200 media: omap3isp: isppreview: always clamp in preview_try_format() [ Upstream commit 17e1e1641f74a89824d4de3aa38c78daa5686cc1 ] If prev->input != PREVIEW_INPUT_MEMORY the width and height weren't clamped. Just always clamp. This fixes a v4l2-compliance error: fail: v4l2-test-subdevs.cpp(171): fse.max_width == ~0U || fse.max_height == ~0U fail: v4l2-test-subdevs.cpp(270): ret && ret != ENOTTY test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: FAIL Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Sasha Levin commit dd1bdabe47bceaea251b34cbd9489010d0363328 Author: Hans Verkuil Date: Fri Oct 17 15:26:40 2025 +0200 media: omap3isp: isp_video_mbus_to_pix/pix_to_mbus fixes [ Upstream commit 44c03802a5191626996ee9db4bac090b164ca340 ] The isp_video_mbus_to_pix/pix_to_mbus functions did not take the last empty entry { 0, } of the formats array into account. As a result, isp_video_mbus_to_pix would accept code 0 and isp_video_pix_to_mbus would select code 0 if no match was found. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Sasha Levin commit 0290934d30abe7c88e18140fd5184c3f386b1e44 Author: Xiaolei Wang Date: Wed Dec 3 21:03:23 2025 +0800 drm/v3d: Set DMA segment size to avoid debug warnings [ Upstream commit 9eb018828b1b30dfba689c060735c50fc5b9f704 ] When using V3D rendering with CONFIG_DMA_API_DEBUG enabled, the kernel occasionally reports a segment size mismatch. This is because 'max_seg_size' is not set. The kernel defaults to 64K. setting 'max_seg_size' to the maximum will prevent 'debug_dma_map_sg()' from complaining about the over-mapping of the V3D segment length. DMA-API: v3d 1002000000.v3d: mapping sg segment longer than device claims to support [len=8290304] [max=65536] WARNING: CPU: 0 PID: 493 at kernel/dma/debug.c:1179 debug_dma_map_sg+0x330/0x388 CPU: 0 UID: 0 PID: 493 Comm: Xorg Not tainted 6.12.53-yocto-standard #1 Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_dma_map_sg+0x330/0x388 lr : debug_dma_map_sg+0x330/0x388 sp : ffff8000829a3ac0 x29: ffff8000829a3ac0 x28: 0000000000000001 x27: ffff8000813fe000 x26: ffffc1ffc0000000 x25: ffff00010fdeb760 x24: 0000000000000000 x23: ffff8000816a9bf0 x22: 0000000000000001 x21: 0000000000000002 x20: 0000000000000002 x19: ffff00010185e810 x18: ffffffffffffffff x17: 69766564206e6168 x16: 74207265676e6f6c x15: 20746e656d676573 x14: 20677320676e6970 x13: 5d34303334393134 x12: 0000000000000000 x11: 00000000000000c0 x10: 00000000000009c0 x9 : ffff8000800e0b7c x8 : ffff00010a315ca0 x7 : ffff8000816a5110 x6 : 0000000000000001 x5 : 000000000000002b x4 : 0000000000000002 x3 : 0000000000000008 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00010a315280 Call trace: debug_dma_map_sg+0x330/0x388 __dma_map_sg_attrs+0xc0/0x278 dma_map_sgtable+0x30/0x58 drm_gem_shmem_get_pages_sgt+0xb4/0x140 v3d_bo_create_finish+0x28/0x130 [v3d] v3d_create_bo_ioctl+0x54/0x180 [v3d] drm_ioctl_kernel+0xc8/0x140 drm_ioctl+0x2d4/0x4d8 Signed-off-by: Xiaolei Wang Link: https://patch.msgid.link/20251203130323.2247072-1-xiaolei.wang@windriver.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit bb09f4584aa2daac441eb53997f7092f4081b67d Author: Deepak Kumar Date: Thu Dec 18 11:48:28 2025 +0100 spi: stm32: fix Overrun issue at < 8bpw [ Upstream commit 1ac3be217c01d5df55ec5052f81e4f1708f46552 ] When SPI communication is suspended by hardware automatically, it could happen that few bits of next frame are already clocked out due to internal synchronization delay. To achieve a safe suspension, we need to ensure that each word must be at least 8 SPI clock cycles long. That's why, if bpw is less than 8 bits, we need to use midi to reach 8 SPI clock cycles at least. This will ensure that each word achieve safe suspension and prevent overrun condition. Signed-off-by: Deepak Kumar Signed-off-by: Alain Volmat Link: https://patch.msgid.link/20251218-stm32-spi-enhancements-v2-2-3b69901ca9fe@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit acd80343470e5f059d6de30d8f46d01b69bf3f03 Author: Jan Remmet Date: Tue Dec 16 08:39:35 2025 +0100 gpio: pca953x: Add support for TCAL6408 TCAL6416 [ Upstream commit a30a9cb9bca4296d25f253619883e7013b6be158 ] TCAL6408 and TCAL6416 supports latchable inputs and maskable interrupt. Tested on a TCAL6416, checked datasheets for the TCAL6408. They use the same programming model ad the NXP PCAL64xx, but support a lower supply power (1.08V to 3.6V) compared to PCAL (1.65V to 5.5V) Datasheet: https://www.ti.com/lit/ds/symlink/tcal6408.pdf Datasheet: https://www.ti.com/lit/ds/symlink/tcal6416.pdf Signed-off-by: Jan Remmet Link: https://lore.kernel.org/r/20251216-wip-jremmet-tcal6416rtw-v2-3-6516d98a9836@phytec.de Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit bbc6e7fc432c4bbafb7aa336e413c71a37b92eb9 Author: Hans Verkuil Date: Thu Jun 5 08:57:35 2025 +0200 media: dvb-core: dmxdevfilter must always flush bufs [ Upstream commit c4e620eccbef76aa5564ebb295e23d6540e27215 ] Currently the buffers are being filled until full, which works fine for the transport stream, but not when reading sections, those have to be returned to userspace immediately, otherwise dvbv5-scan will just wait forever. Add a 'flush' argument to dvb_vb2_fill_buffer to indicate whether the buffer must be flushed or wait until it is full. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f88cd8da2d28e1d2cfb9569e937455d410acc176 Author: Peter Ujfalusi Date: Wed Dec 17 16:39:43 2025 +0200 ASoC: SOF: ipc4: Support for sending payload along with LARGE_CONFIG_GET [ Upstream commit d96cb0b86d6e8bbbbfa425771606f6c1aebc318e ] There are message types when we would need to send a payload along with the LARGE_CONFIG_GET message to provide information to the firmware on what data is requested. Such cases are the ALSA Kcontrol related messages when the high level param_id tells only the type of the control, but the ID/index of the exact control is specified in the payload area. The caller must place the payload for TX before calling the set_get_data() and this payload will be sent alongside with the message to the firmware. The data area will be overwritten by the received data from firmware. Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 59b888198843ef6353b293b423c407ba8b625278 Author: Peichen Huang Date: Tue Nov 18 11:19:36 2025 +0800 drm/amd/display: Don't disable DPCD mst_en if sink connected [ Upstream commit 9aeb31b2456452257ad1ff7ec566f21bab1f3e8a ] [WHY] User may connect mst dock with multi monitors and do quick unplug and plug in one of the monitor. This operatioin may create CSN from dock to display driver. Then display driver would disable and then enable mst link and also disable/enable DPCD mst_en bit in dock RX. However, when mst_en bit being disabled, if dock has another CSN message to transmit then the message would be removed because of the disabling of mst_en. In this case, the message is missing and it ends up no display in the replugged monitor. [HOW] Don't disable mst_en bit when link still has sink connected. Reviewed-by: Wenjing Liu Signed-off-by: Peichen Huang Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7df6fe98b24de25010ed22e4f6f90bf869290248 Author: LinCheng Ku Date: Wed Dec 3 10:18:16 2025 +0800 drm/amd/display: Add USB-C DP Alt Mode lane limitation in DCN32 [ Upstream commit cea573a8e1ed83840a2173d153dd68e172849d44 ] [Why] USB-C DisplayPort Alt Mode with concurrent USB data needs lane count limitation to prevent incorrect 4-lane DP configuration when only 2 lanes are available due to hardware lane sharing between DP and USB3. [How] Query DMUB for Alt Mode status (is_dp_alt_disable, is_usb, is_dp4) in dcn32_link_encoder_get_max_link_cap() and cap DP to 2 lanes when USB is active on USB-C port. Added inline documentation explaining the USB-C lane sharing constraint. Reviewed-by: PeiChen Huang Signed-off-by: LinCheng Ku Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 08dca4c8099a41a9fa3be128a793387603f73a17 Author: Mark Brown Date: Thu Dec 4 19:13:35 2025 +0000 spi: cadence-quadspi: Parse DT for flashes with the rest of the DT parsing [ Upstream commit 9f0736a4e136a6eb61e0cf530ddc18ab6d816ba3 ] The recent refactoring of where runtime PM is enabled done in commit f1eb4e792bb1 ("spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance") made the fact that when we do a pm_runtime_disable() in the error paths of probe() we can trigger a runtime disable which in turn results in duplicate clock disables. This is particularly likely to happen when there is missing or broken DT description for the flashes attached to the controller. Early on in the probe function we do a pm_runtime_get_noresume() since the probe function leaves the device in a powered up state but in the error path we can't assume that PM is enabled so we also manually disable everything, including clocks. This means that when runtime PM is active both it and the probe function release the same reference to the main clock for the IP, triggering warnings from the clock subsystem: [ 8.693719] clk:75:7 already disabled [ 8.693791] WARNING: CPU: 1 PID: 185 at /usr/src/kernel/drivers/clk/clk.c:1188 clk_core_disable+0xa0/0xb ... [ 8.694261] clk_core_disable+0xa0/0xb4 (P) [ 8.694272] clk_disable+0x38/0x60 [ 8.694283] cqspi_probe+0x7c8/0xc5c [spi_cadence_quadspi] [ 8.694309] platform_probe+0x5c/0xa4 Dealing with this issue properly is complicated by the fact that we don't know if runtime PM is active so can't tell if it will disable the clocks or not. We can, however, sidestep the issue for the flash descriptions by moving their parsing to when we parse the controller properties which also save us doing a bunch of setup which can never be used so let's do that. Reported-by: Francesco Dolcini Closes: https://lore.kernel.org/r/20251201072844.GA6785@francesco-nb Signed-off-by: Mark Brown Link: https://patch.msgid.link/20251204-spi-cadence-qspi-runtime-pm-imbalance-v2-1-10af9115d531@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 00f77947972eddd056031bb1f4fa68db97a08f41 Author: Jonathan Marek Date: Thu Nov 20 16:12:00 2025 -0500 spi-geni-qcom: use xfer->bits_per_word for can_dma() [ Upstream commit fb2bbe3838728f572485706677590e4fc41eec5c ] mas->cur_bits_per_word may not reflect the value of xfer->bits_per_word when can_dma() is called. Use the right value instead. Signed-off-by: Jonathan Marek Link: https://patch.msgid.link/20251120211204.24078-3-jonathan@marek.ca Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 97872d00da3cf07b658c8001d5aae88e1d5dcfe4 Author: Jonathan Marek Date: Thu Nov 20 16:12:01 2025 -0500 spi-geni-qcom: initialize mode related registers to 0 [ Upstream commit 739062a9f1e9a77a9687c8fd30f8e5dd12ec70be ] setup_fifo_params assumes these will be zero, it won't write these registers if the initial mode is zero. Signed-off-by: Jonathan Marek Link: https://patch.msgid.link/20251120211204.24078-4-jonathan@marek.ca Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b3d6ca4f27d49cb0e8c1c507c44d6ac0583213e2 Author: Philip Yang Date: Wed Nov 19 16:32:45 2025 -0500 drm/amdkfd: Handle GPU reset and drain retry fault race [ Upstream commit 5b57c3c3f22336e8fd5edb7f0fef3c7823f8eac1 ] Only check and drain IH1 ring if CAM is not enabled. If GPU is under reset, don't access IH to drain retry fault. Signed-off-by: Philip Yang Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0bd968c04acfb60afc403fddc7d1ec518e9ffa83 Author: Val Packett Date: Sat Dec 6 14:37:28 2025 -0300 drm/panel-edp: Add AUO B140QAX01.H panel [ Upstream commit bcd752c706c357229185a330ab450b86236d9031 ] A 14-inch 2560x1600 60Hz matte touch panel, found on a Dell Latitude 7455 laptop (second-source with BOE NE14QDM), according to online sources it's also found on the Latitude 7440 and some ASUS models. Raw EDID dump: 00 ff ff ff ff ff ff 00 06 af a4 0b 00 00 00 00 00 20 01 04 a5 1e 13 78 03 ad f5 a8 54 47 9c 24 0e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 f0 68 00 a0 a0 40 2e 60 30 20 35 00 2d bc 10 00 00 1a f3 53 00 a0 a0 40 2e 60 30 20 35 00 2d bc 10 00 00 1a 00 00 00 fe 00 36 39 52 31 57 80 42 31 34 30 51 41 58 00 00 00 00 00 02 41 21 a8 00 01 00 00 1a 41 0a 20 20 00 a1 Don't have datasheet access, but the same timing as for other panels from the same manufacturer works fine. Signed-off-by: Val Packett [dianders: Moved to the right location in the table] Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20251206173739.2222940-1-val@packett.cool Signed-off-by: Sasha Levin commit 79c5cbeba6b0e678b8abb0b476e7cefbbd8001f3 Author: Dillon Varone Date: Tue Nov 18 20:58:23 2025 +0000 drm/amd/display: Guard FAMS2 configuration updates [ Upstream commit 7dedb906cdfec100061daf41f8e54266e975987d ] [WHY&HOW] If DMCUB is not initialized or FAMS2 is not supported, the interface should not be called. Reviewed-by: Sridevi Arvindekar Signed-off-by: Dillon Varone Signed-off-by: Roman Li Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7ad1f6f9476b541558fe2a036ec8fc5876b81e75 Author: Jing Zhou Date: Mon Nov 17 15:18:50 2025 +0800 drm/amd/display: Correct FIXED_VS Link Rate Toggle Condition [ Upstream commit 531fe6e0fee85a1bdb5b8223a706fff654ed0a61 ] [WHY&HOW] The condition is only perform toggle if FIXED_VS LTTPR reports no IEEE OUI. The literal "\x0,\x0,\x0" contains commas changes the bytes being compared to {0x00,0x2C,0X00}. The correct literal should be "\x00\x00\x00" without commas. Reviewed-by: Charlene Liu Reviewed-by: Wenjing Liu Signed-off-by: Jing Zhou Signed-off-by: Roman Li Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0b7f78caeffa51a1afa521c284e863ec3b5a36df Author: Asad Kamal Date: Fri Nov 21 00:46:23 2025 +0800 drm/amdgpu/ras: Move ras data alloc before bad page check [ Upstream commit bd68a1404b6fa2e7e9957b38ba22616faba43e75 ] In the rare event if eeprom has only invalid address entries, allocation is skipped, this causes following NULL pointer issue [ 547.103445] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ 547.118897] #PF: supervisor read access in kernel mode [ 547.130292] #PF: error_code(0x0000) - not-present page [ 547.141689] PGD 124757067 P4D 0 [ 547.148842] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 547.158504] CPU: 49 PID: 8167 Comm: cat Tainted: G OE 6.8.0-38-generic #38-Ubuntu [ 547.177998] Hardware name: Supermicro AS -8126GS-TNMR/H14DSG-OD, BIOS 1.7 09/12/2025 [ 547.195178] RIP: 0010:amdgpu_ras_sysfs_badpages_read+0x2f2/0x5d0 [amdgpu] [ 547.210375] Code: e8 63 78 82 c0 45 31 d2 45 3b 75 08 48 8b 45 a0 73 44 44 89 f1 48 8b 7d 88 48 89 ca 48 c1 e2 05 48 29 ca 49 8b 4d 00 48 01 d1 <48> 83 79 10 00 74 17 49 63 f2 48 8b 49 08 41 83 c2 01 48 8d 34 76 [ 547.252045] RSP: 0018:ffa0000067287ac0 EFLAGS: 00010246 [ 547.263636] RAX: ff11000167c28130 RBX: ff11000127600000 RCX: 0000000000000000 [ 547.279467] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ff11000125b1c800 [ 547.295298] RBP: ffa0000067287b50 R08: 0000000000000000 R09: 0000000000000000 [ 547.311129] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 547.326959] R13: ff11000217b1de00 R14: 0000000000000000 R15: 0000000000000092 [ 547.342790] FS: 0000746e59d14740(0000) GS:ff11017dfda80000(0000) knlGS:0000000000000000 [ 547.360744] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 547.373489] CR2: 0000000000000010 CR3: 000000019585e001 CR4: 0000000000f71ef0 [ 547.389321] PKRU: 55555554 [ 547.395316] Call Trace: [ 547.400737] [ 547.405386] ? show_regs+0x6d/0x80 [ 547.412929] ? __die+0x24/0x80 [ 547.419697] ? page_fault_oops+0x99/0x1b0 [ 547.428588] ? do_user_addr_fault+0x2ee/0x6b0 [ 547.438249] ? exc_page_fault+0x83/0x1b0 [ 547.446949] ? asm_exc_page_fault+0x27/0x30 [ 547.456225] ? amdgpu_ras_sysfs_badpages_read+0x2f2/0x5d0 [amdgpu] [ 547.470040] ? mas_wr_modify+0xcd/0x140 [ 547.478548] sysfs_kf_bin_read+0x63/0xb0 [ 547.487248] kernfs_file_read_iter+0xa1/0x190 [ 547.496909] kernfs_fop_read_iter+0x25/0x40 [ 547.506182] vfs_read+0x255/0x390 This also result in space left assigned to negative values. Moving data alloc call before bad page check resolves both the issue. Signed-off-by: Asad Kamal Suggested-by: Lijo Lazar Reviewed-by: Hawking Zhang Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a25cf4a927a7cac460a1d97d38f1e322de22160c Author: Tao Zhou Date: Wed Nov 19 15:21:43 2025 +0800 drm/amdgpu: fix the calculation of RAS bad page number [ Upstream commit f752e79d38857011f1293fcb6c810409c3b669ee ] __amdgpu_ras_restore_bad_pages is responsible for the maintenance of bad page number, drop the unnecessary bad page number update in the error handling path of add_bad_pages. Signed-off-by: Tao Zhou Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 276028fd9b60bbcc68796d1124b6b58298f4ca8a Author: Likun Gao Date: Fri Jul 12 11:07:40 2024 +0800 drm/amdgpu: fix NULL pointer issue buffer funcs [ Upstream commit 9877a865d62c9c3e0f4cc369dc9ca9f7f24f5ee9 ] If SDMA block not enabled, buffer_funcs will not initialize, fix the null pointer issue if buffer_funcs not initialized. Signed-off-by: Likun Gao Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 31a1fb32f5ebd5ca226c2b70dc510a9c0293238d Author: Lizhi Hou Date: Thu Dec 4 10:16:03 2025 -0800 accel/amdxdna: Fix tail-pointer polling in mailbox_get_msg() [ Upstream commit cd77d5a4aaf8c5c1d819f47cf814bf7d4920b0a2 ] In mailbox_get_msg(), mailbox_reg_read_non_zero() is called to poll for a non-zero tail pointer. This assumed that a zero value indicates an error. However, certain corner cases legitimately produce a zero tail pointer. To handle these cases, remove mailbox_reg_read_non_zero(). The zero tail pointer will be treated as a valid rewind event. Reviewed-by: Maciej Falkowski Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251204181603.793824-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 6ca4647a74155de016d37b28fea9b4d0d944d1d2 Author: Alexey Klimov Date: Wed Dec 3 07:45:55 2025 +0000 gpu/panel-edp: add AUO panel entry for B140HAN06.4 [ Upstream commit 2976aeb0de77da599ad37691963efbdcb07435ce ] Add an eDP panel entry for AUO B140HAN06.4 that is also used in some variants of Lenovo Flex 5G with Qcom SC8180 SoC. The raw edid of the panel is: 00 ff ff ff ff ff ff 00 06 af 3d 64 00 00 00 00 2b 1d 01 04 a5 1f 11 78 03 b8 1a a6 54 4a 9b 26 0e 52 55 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 14 37 80 b8 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 10 2c 80 b8 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 42 31 34 30 48 41 4e 30 36 2e 34 20 0a 00 eb I do not have access to the datasheet and but it is tested on above mentioned laptop for a few weeks and seems to work just fine with timing info of similar panels. Cc: Bjorn Andersson Cc: Vinod Koul Signed-off-by: Alexey Klimov Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20251203074555.690613-1-alexey.klimov@linaro.org Signed-off-by: Sasha Levin commit d380351cbefe0df281efd0465ef81b50214b4f36 Author: Balasubramani Vivekanandan Date: Fri Nov 21 15:38:23 2025 +0530 drm/xe/xe3_lpg: Apply Wa_16028005424 [ Upstream commit 9d94c1cf6ef938abd4b849b66f8eab11e3c537ef ] Applied Wa_16028005424 to Graphics version from 30.00 to 30.05 Reviewed-by: Matt Roper Signed-off-by: Balasubramani Vivekanandan Link: https://patch.msgid.link/20251121100822.20076-2-balasubramani.vivekanandan@intel.com Signed-off-by: Matt Roper Signed-off-by: Sasha Levin commit 49355c85b4cd92c457cf25bb78ecb11d1a49a7cb Author: Boris Brezillon Date: Fri Nov 28 09:48:35 2025 +0100 drm/panthor: Always wait after sending a command to an AS [ Upstream commit d2c6fde56d451ca48a5e03428535ce3dbc8fc910 ] There's currently no situation where we want to issue a command to an AS and not wait for this command to complete. The wait is either explicitly done (LOCK, UNLOCK) or it's missing (UPDATE). So let's turn write_cmd() into as_send_cmd_and_wait() that has the wait after a command is sent. v2: - New patch v3: - Collect R-b v4: - No changes Reviewed-by: Steven Price Link: https://patch.msgid.link/20251128084841.3804658-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 4d2ccdea18b564e3f73e3e543854acea64e6277d Author: Suraj Kandpal Date: Wed Nov 19 15:16:50 2025 +0530 drm/display/dp_mst: Add protection against 0 vcpi [ Upstream commit 342ccffd9f77fc29fe1c05fd145e4d842bd2feaa ] When releasing a timeslot there is a slight chance we may end up with the wrong payload mask due to overflow if the delayed_destroy_work ends up coming into play after a DP 2.1 monitor gets disconnected which causes vcpi to become 0 then we try to make the payload = ~BIT(vcpi - 1) which is a negative shift. VCPI id should never really be 0 hence skip changing the payload mask if VCPI is 0. Otherwise it leads to <7> [515.287237] xe 0000:03:00.0: [drm:drm_dp_mst_get_port_malloc [drm_display_helper]] port ffff888126ce9000 (3) <4> [515.287267] -----------[ cut here ]----------- <3> [515.287268] UBSAN: shift-out-of-bounds in ../drivers/gpu/drm/display/drm_dp_mst_topology.c:4575:36 <3> [515.287271] shift exponent -1 is negative <4> [515.287275] CPU: 7 UID: 0 PID: 3108 Comm: kworker/u64:33 Tainted: G S U 6.17.0-rc6-lgci-xe-xe-3795-3e79699fa1b216e92+ #1 PREEMPT(voluntary) <4> [515.287279] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER <4> [515.287279] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 1645 03/15/2024 <4> [515.287281] Workqueue: drm_dp_mst_wq drm_dp_delayed_destroy_work [drm_display_helper] <4> [515.287303] Call Trace: <4> [515.287304] <4> [515.287306] dump_stack_lvl+0xc1/0xf0 <4> [515.287313] dump_stack+0x10/0x20 <4> [515.287316] __ubsan_handle_shift_out_of_bounds+0x133/0x2e0 <4> [515.287324] ? drm_atomic_get_private_obj_state+0x186/0x1d0 <4> [515.287333] drm_dp_atomic_release_time_slots.cold+0x17/0x3d [drm_display_helper] <4> [515.287355] mst_connector_atomic_check+0x159/0x180 [xe] <4> [515.287546] drm_atomic_helper_check_modeset+0x4d9/0xfa0 <4> [515.287550] ? __ww_mutex_lock.constprop.0+0x6f/0x1a60 <4> [515.287562] intel_atomic_check+0x119/0x2b80 [xe] <4> [515.287740] ? find_held_lock+0x31/0x90 <4> [515.287747] ? lock_release+0xce/0x2a0 <4> [515.287754] drm_atomic_check_only+0x6a2/0xb40 <4> [515.287758] ? drm_atomic_add_affected_connectors+0x12b/0x140 <4> [515.287765] drm_atomic_commit+0x6e/0xf0 <4> [515.287766] ? _pfx__drm_printfn_info+0x10/0x10 <4> [515.287774] drm_client_modeset_commit_atomic+0x25c/0x2b0 <4> [515.287794] drm_client_modeset_commit_locked+0x60/0x1b0 <4> [515.287795] ? mutex_lock_nested+0x1b/0x30 <4> [515.287801] drm_client_modeset_commit+0x26/0x50 <4> [515.287804] __drm_fb_helper_restore_fbdev_mode_unlocked+0xdc/0x110 <4> [515.287810] drm_fb_helper_hotplug_event+0x120/0x140 <4> [515.287814] drm_fbdev_client_hotplug+0x28/0xd0 <4> [515.287819] drm_client_hotplug+0x6c/0xf0 <4> [515.287824] drm_client_dev_hotplug+0x9e/0xd0 <4> [515.287829] drm_kms_helper_hotplug_event+0x1a/0x30 <4> [515.287834] drm_dp_delayed_destroy_work+0x3df/0x410 [drm_display_helper] <4> [515.287861] process_one_work+0x22b/0x6f0 <4> [515.287874] worker_thread+0x1e8/0x3d0 <4> [515.287879] ? __pfx_worker_thread+0x10/0x10 <4> [515.287882] kthread+0x11c/0x250 <4> [515.287886] ? __pfx_kthread+0x10/0x10 <4> [515.287890] ret_from_fork+0x2d7/0x310 <4> [515.287894] ? __pfx_kthread+0x10/0x10 <4> [515.287897] ret_from_fork_asm+0x1a/0x30 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6303 Signed-off-by: Suraj Kandpal Reviewed-by: Imre Deak Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20251119094650.799135-1-suraj.kandpal@intel.com Signed-off-by: Sasha Levin commit 86017c455e0a587cd2ef429299625c9547b0e1b0 Author: Himal Prasad Ghimiray Date: Tue Nov 25 13:26:28 2025 +0530 drm/xe/vm: Skip ufence association for CPU address mirror VMA during MAP [ Upstream commit 7f08cc5b3cc3bf6416f8b55bff906f67ed75637d ] The MAP operation for a CPU address mirror VMA does not require ufence association because such mappings are not GPU-synchronized and do not participate in GPU job completion signaling. Remove the unnecessary ufence addition for this case to avoid -EBUSY failure in check_ufence of unbind ops. Cc: Matthew Brost Cc: Thomas Hellström Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20251125075628.1182481-6-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray Signed-off-by: Sasha Levin commit e72721081bd1a6c058a37772443b96547f71f5d0 Author: Matthew Brost Date: Fri Nov 21 17:25:02 2025 -0800 drm/xe: Covert return of -EBUSY to -ENOMEM in VM bind IOCTL [ Upstream commit 6028f59620927aee2e15a424004012ae05c50684 ] xe_vma_userptr_pin_pages can return -EBUSY but -EBUSY has special meaning in VM bind IOCTLs that user fence is pending that is attached to the VMA. Convert -EBUSY to -ENOMEM in this case as -EBUSY in practice means we are low or out of memory. Signed-off-by: Matthew Brost Reviewed-by: Tejas Upadhyay Link: https://patch.msgid.link/20251122012502.382587-2-matthew.brost@intel.com Signed-off-by: Sasha Levin commit 2583ab12055dddb05c57e19db7be9bc2db83d45a Author: Matt Roper Date: Tue Nov 18 08:44:01 2025 -0800 drm/xe/ggtt: Use scope-based runtime pm [ Upstream commit 8a579f4b2476fd1df07e2bca9fedc82a39a56a65 ] Switch the GGTT code to scope-based runtime PM for consistency with other parts of the driver. Reviewed-by: Gustavo Sousa Link: https://patch.msgid.link/20251118164338.3572146-51-matthew.d.roper@intel.com Signed-off-by: Matt Roper Signed-off-by: Sasha Levin commit 3db57975e98803b6bbf04bc6c21a84980ed934a3 Author: Helge Deller Date: Tue Jan 27 17:58:55 2026 +0100 parisc: Prevent interrupts during reboot [ Upstream commit 35ac5a728c878594f2ea6c43b57652a16be3c968 ] Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 707a77b9c6fd52e21a4cffb129c4491a3d936f8d Author: Borislav Petkov (AMD) Date: Mon Jan 12 12:37:49 2026 +0100 x86/sev: Use kfree_sensitive() when freeing a SNP message descriptor [ Upstream commit af05e558988ed004a20fc4de7d0f80cfbba663f0 ] Use the proper helper instead of an open-coded variant. Closes: https://lore.kernel.org/r/202512202235.WHPQkLZu-lkp@intel.com Reported-by: kernel test robot Reported-by: Julia Lawall Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tom Lendacky Link: https://patch.msgid.link/20260112114147.GBaWTd-8HSy_Xp4S3X@fat_crate.local Signed-off-by: Sasha Levin commit 45395efdf6a6553f6d357bca486c6db364a1f67a Author: Peng Fan Date: Wed Jan 14 06:12:41 2026 +0800 soc: imx8m: Fix error handling for clk_prepare_enable() [ Upstream commit f6ef3d9ff81240e9bcc030f2da132eb0f8a761d7 ] imx8m_soc_prepare() directly returns the result of clk_prepare_enable(), which skips proper cleanup if the clock enable fails. Check the return value of clk_prepare_enable() and release resources if failure. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202601111406.ZVV3YaiU-lkp@intel.com/ Signed-off-by: Peng Fan Reviewed-by: Marco Felsch Reviewed-by: Daniel Baluta Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 45677538270882c6d25e99fc0bf84f8fb993812d Author: Diogo Ivo Date: Thu Dec 4 21:27:21 2025 +0000 arm64: tegra: smaug: Add usb-role-switch support [ Upstream commit dfa93788dd8b2f9c59adf45ecf592082b1847b7b ] The USB2 port on Smaug is configured for OTG operation but lacked the required 'usb-role-switch' property, leading to a failed probe and a non-functioning USB port. Add the property along with setting the default role to host. Signed-off-by: Diogo Ivo Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 6e1486257a2e85f1082ec3da27c7d997d95766ca Author: Qiuxu Zhuo Date: Mon Nov 24 14:54:56 2025 +0800 EDAC/igen6: Add two Intel Amston Lake SoCs support [ Upstream commit 41ca2155d62b0b0d217f59e1bce18362d0c2446f ] Intel Amston Lake SoCs with IBECC (In-Band ECC) capability share the same IBECC registers as Alder Lake-N SoCs. Add two new compute die IDs for Amston Lake SoC products to enable EDAC support. Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Tested-by: Jianfeng Gao Link: https://patch.msgid.link/20251124065457.3630949-2-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 3a72bf74f50a6c0944a3506f11f2091f054153aa Author: Lili Li Date: Mon Nov 24 21:15:37 2025 +0800 EDAC/igen6: Add more Intel Panther Lake-H SoCs support [ Upstream commit 4c36e6106997b6ad8f4a279b4bdbca3ed6f53c6c ] Add more Intel Panther Lake-H SoC compute die IDs for EDAC support. Signed-off-by: Lili Li Signed-off-by: Tony Luck Reviewed-by: Qiuxu Zhuo Link: https://patch.msgid.link/20251124131537.3633983-1-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 3983ef126e439900bbf419724a9759863c146660 Author: Tomas Melin Date: Tue Nov 25 09:53:54 2025 +0200 Revert "arm64: zynqmp: Add an OP-TEE node to the device tree" [ Upstream commit c197179990124f991fca220d97fac56779a02c6d ] This reverts commit 06d22ed6b6635b17551f386b50bb5aaff9b75fbe. OP-TEE logic in U-Boot automatically injects a reserved-memory node along with optee firmware node to kernel device tree. The injection logic is dependent on that there is no manually defined optee node. Having the node in zynqmp.dtsi effectively breaks OP-TEE's insertion of the reserved-memory node, causing memory access violations during runtime. Signed-off-by: Tomas Melin Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/20251125-revert-zynqmp-optee-v1-1-d2ce4c0fcaf6@vaisala.com Signed-off-by: Sasha Levin commit 919785992a371b2684de94e72058a6de495a9efc Author: Haoxiang Li Date: Wed Dec 10 11:16:56 2025 +0800 firmware: arm_ffa: Unmap Rx/Tx buffers on init failure [ Upstream commit 9fda364cb78c8b9e1abe4029f877300c94655742 ] ffa_init() maps the Rx/Tx buffers via ffa_rxtx_map() but on the partition setup failure path it never unmaps them. Add the missing ffa_rxtx_unmap() call in the error path so that the Rx/Tx buffers are properly released before freeing the backing pages. Signed-off-by: Haoxiang Li Message-Id: <20251210031656.56194-1-lihaoxiang@isrc.iscas.ac.cn> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 2c99326dc1c79b7ce3c8dd92929b5ce724ff70eb Author: Ruipeng Qi Date: Tue Feb 3 10:03:58 2026 +0800 pstore: ram_core: fix incorrect success return when vmap() fails [ Upstream commit 05363abc7625cf18c96e67f50673cd07f11da5e9 ] In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures. Signed-off-by: Ruipeng Qi Link: https://patch.msgid.link/20260203020358.3315299-1-ruipengqi3@gmail.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit db702ef6d91451f65e78539c33a702cbf520ce15 Author: Joel Fernandes Date: Mon Jan 26 10:59:00 2026 +0100 sched/debug: Fix updating of ppos on server write ops [ Upstream commit 6080fb211672aec6ce8f2f5a2e0b4eae736f2027 ] Updating "ppos" on error conditions does not make much sense. The pattern is to return the error code directly without modifying the position, or modify the position on success and return the number of bytes written. Since on success, the return value of apply is 0, there is no point in modifying ppos either. Fix it by removing all this and just returning error code or number of bytes written on success. Signed-off-by: Joel Fernandes Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Juri Lelli Reviewed-by: Andrea Righi Acked-by: Tejun Heo Tested-by: Christian Loehle Link: https://patch.msgid.link/20260126100050.3854740-3-arighi@nvidia.com Signed-off-by: Sasha Levin commit c075eb0d220daf9ab263948c7cc1aa8f6011f953 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:29 2026 +0100 char: tpm: cr50: Remove IRQF_ONESHOT [ Upstream commit 1affd29ffbd50125a5492c6be1dbb1f04be18d4f ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. Remove IRQF_ONESHOT from irqflags. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Jarkko Sakkinen Link: https://patch.msgid.link/20260128095540.863589-10-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 4fa6bfa6dc2de6a18bd544b250406718817d1458 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:24 2026 +0100 mailbox: bcm-ferxrm-mailbox: Use default primary handler [ Upstream commit 03843d95a4a4e0ba22ad4fcda65ccf21822b104c ] request_threaded_irq() is invoked with a primary and a secondary handler and no flags are passed. The primary handler is the same as irq_default_primary_handler() so there is no need to have an identical copy. The lack of the IRQF_ONESHOT flag can be dangerous because the interrupt source is not masked while the threaded handler is active. This means, especially on LEVEL typed interrupt lines, the interrupt can fire again before the threaded handler had a chance to run. Use the default primary interrupt handler by specifying NULL and set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-5-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit aaaa758294fb159280ec3c1b1a688e1b3c72f96a Author: Chenghai Huang Date: Sat Jan 17 18:18:03 2026 +0800 crypto: hisilicon/qm - move the barrier before writing to the mailbox register [ Upstream commit ebf35d8f9368816c930f5d70783a72716fab5e19 ] Before sending the data via the mailbox to the hardware, to ensure that the data accessed by the hardware is the most up-to-date, a write barrier should be added before writing to the mailbox register. The current memory barrier is placed after writing to the register, the barrier order should be modified to be before writing to the register. Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a048eb4e37ea7f84aecd7592a0bb63ed315ae877 Author: Ihor Solodrai Date: Wed Jan 28 13:12:55 2026 -0800 bpftool: Fix dependencies for static build [ Upstream commit 08a7491843224f8b96518fbe70d9e48163046054 ] When building selftests/bpf with EXTRA_LDFLAGS=-static the follwoing error happens: LINK /ws/linux/tools/testing/selftests/bpf/tools/build/bpftool/bootstrap/bpftool /usr/bin/x86_64-linux-gnu-ld.bfd: /usr/lib/gcc/x86_64-linux-gnu/15/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-dso_dlfcn.o): in function `dlfcn_globallookup': [...] /usr/bin/x86_64-linux-gnu-ld.bfd: /usr/lib/gcc/x86_64-linux-gnu/15/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_oneshot_expand_block': (.text+0xc64): undefined reference to `uncompress' /usr/bin/x86_64-linux-gnu-ld.bfd: /usr/lib/gcc/x86_64-linux-gnu/15/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_oneshot_compress_block': (.text+0xce4): undefined reference to `compress' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:252: /ws/linux/tools/testing/selftests/bpf/tools/build/bpftool/bootstrap/bpftool] Error 1 make: *** [Makefile:327: /ws/linux/tools/testing/selftests/bpf/tools/sbin/bpftool] Error 2 make: *** Waiting for unfinished jobs.... This is caused by wrong order of dependencies in the Makefile. Fix it. Signed-off-by: Ihor Solodrai Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260128211255.376933-1-ihor.solodrai@linux.dev Signed-off-by: Sasha Levin commit aee8db5f048616990dbdefcc25689ade0a2620ec Author: Haoxiang Li Date: Sun Jan 25 22:44:52 2026 +0800 PCI/MSI: Unmap MSI-X region on error [ Upstream commit 1a8d4c6ecb4c81261bcdf13556abd4a958eca202 ] msix_capability_init() fails to unmap the MSI-X region if msix_setup_interrupts() fails. Add the missing iounmap() for that error path. [ tglx: Massaged change log ] Signed-off-by: Haoxiang Li Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260125144452.2103812-1-lihaoxiang@isrc.iscas.ac.cn Signed-off-by: Sasha Levin commit 716f777b6c9b7dab64f7c76d5d3ccdcea6074ba9 Author: Bartosz Golaszewski Date: Fri Jan 16 12:17:23 2026 +0100 clocksource/drivers/timer-integrator-ap: Add missing Kconfig dependency on OF [ Upstream commit 2246464821e2820572e6feefca2029f17629cc50 ] This driver accesses the of_aliases global variable declared in linux/of.h and defined in drivers/base/of.c. It requires OF support or will cause a link failure. Add the missing Kconfig dependency. Closes: https://lore.kernel.org/oe-kbuild-all/202601152233.og6LdeUo-lkp@intel.com/ Signed-off-by: Bartosz Golaszewski Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260116111723.10585-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Sasha Levin commit bc59d5f3afe41fec5d673c27c703b761ae578d28 Author: Niklas Söderlund Date: Tue Dec 2 23:13:41 2025 +0100 clocksource/drivers/sh_tmu: Always leave device running after probe [ Upstream commit b1278972b08e480990e2789bdc6a7c918bc349be ] The TMU device can be used as both a clocksource and a clockevent provider. The driver tries to be smart and power itself on and off, as well as enabling and disabling its clock when it's not in operation. This behavior is slightly altered if the TMU is used as an early platform device in which case the device is left powered on after probe, but the clock is still enabled and disabled at runtime. This has worked for a long time, but recent improvements in PREEMPT_RT and PROVE_LOCKING have highlighted an issue. As the TMU registers itself as a clockevent provider, clockevents_register_device(), it needs to use raw spinlocks internally as this is the context of which the clockevent framework interacts with the TMU driver. However in the context of holding a raw spinlock the TMU driver can't really manage its power state or clock with calls to pm_runtime_*() and clk_*() as these calls end up in other platform drivers using regular spinlocks to control power and clocks. This mix of spinlock contexts trips a lockdep warning. ============================= [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90 For non-PREEMPT_RT builds this is not really an issue, but for PREEMPT_RT builds where normal spinlocks can sleep this might be an issue. Be cautious and always leave the power and clock running after probe. Signed-off-by: Niklas Söderlund Signed-off-by: Daniel Lezcano Tested-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251202221341.1856773-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Sasha Levin commit 1088d3cb5b5ba90c639964b4e50e9eafb83e95b1 Author: Jiri Olsa Date: Mon Jan 12 13:11:56 2026 +0100 arm64/ftrace,bpf: Fix partial regs after bpf_prog_run [ Upstream commit 276f3b6daf6024ae2742afd161e7418a5584a660 ] Mahe reported issue with bpf_override_return helper not working when executed from kprobe.multi bpf program on arm. The problem is that on arm we use alternate storage for pt_regs object that is passed to bpf_prog_run and if any register is changed (which is the case of bpf_override_return) it's not propagated back to actual pt_regs object. Fixing this by introducing and calling ftrace_partial_regs_update function to propagate the values of changed registers (ip and stack). Reported-by: Mahe Tardy Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Reviewed-by: Steven Rostedt (Google) Acked-by: Will Deacon Link: https://lore.kernel.org/bpf/20260112121157.854473-1-jolsa@kernel.org Signed-off-by: Sasha Levin commit e1886b473131b82b4c17abd0d186f03f0d64e4d1 Author: Namhyung Kim Date: Mon Jan 12 08:51:57 2026 -0800 perf/core: Fix slow perf_event_task_exit() with LBR callstacks [ Upstream commit 4960626f956d63dce57f099016c2ecbe637a8229 ] I got a report that a task is stuck in perf_event_exit_task() waiting for global_ctx_data_rwsem. On large systems with lots threads, it'd have performance issues when it grabs the lock to iterate all threads in the system to allocate the context data. And it'd block task exit path which is problematic especially under memory pressure. perf_event_open perf_event_alloc attach_perf_ctx_data attach_global_ctx_data percpu_down_write (global_ctx_data_rwsem) for_each_process_thread alloc_task_ctx_data do_exit perf_event_exit_task percpu_down_read (global_ctx_data_rwsem) It should not hold the global_ctx_data_rwsem on the exit path. Let's skip allocation for exiting tasks and free the data carefully. Reported-by: Rosalie Fang Suggested-by: Peter Zijlstra Signed-off-by: Namhyung Kim Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260112165157.1919624-1-namhyung@kernel.org Signed-off-by: Sasha Levin commit df02c3ff3be4bf998812c8c8e79d10db1329d535 Author: Anton Protopopov Date: Wed Jan 14 16:25:43 2026 +0000 bpf: Properly mark live registers for indirect jumps [ Upstream commit d1aab1ca576c90192ba961094d51b0be6355a4d6 ] For a `gotox rX` instruction the rX register should be marked as used in the compute_insn_live_regs() function. Fix this. Signed-off-by: Anton Protopopov Link: https://lore.kernel.org/r/20260114162544.83253-2-a.s.protopopov@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit aae391a79f2a13f3fd907e6295a2da7c15d7661d Author: Imran Khan Date: Tue Jan 13 22:37:27 2026 +0800 genirq/cpuhotplug: Notify about affinity changes breaking the affinity mask [ Upstream commit dd9f6d30c64001ca4dde973ac04d8d155e856743 ] During CPU offlining the interrupts affined to that CPU are moved to other online CPUs, which might break the original affinity mask if the outgoing CPU was the last online CPU in that mask. This change is not propagated to irq_desc::affinity_notify(), which leaves users of the affinity notifier mechanism with stale information. Avoid this by scheduling affinity change notification work for interrupts that were affined to the CPU being offlined, if the new target CPU is not part of the original affinity mask. Since irq_set_affinity_locked() uses the same logic to schedule affinity change notification work, split out this logic into a dedicated function and use that at both places. [ tglx: Removed the EXPORT(), removed the !SMP stub, moved the prototype, added a lockdep assert instead of a comment, fixed up coding style and name space. Polished and clarified the change log ] Signed-off-by: Imran Khan Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260113143727.1041265-1-imran.f.khan@oracle.com Signed-off-by: Sasha Levin commit 4c122e8ae14950cf6b59d208fc5160f7c601e746 Author: Alexei Starovoitov Date: Mon Jan 12 12:13:57 2026 -0800 bpf: Recognize special arithmetic shift in the verifier [ Upstream commit bffacdb80b93b7b5e96b26fad64cc490a6c7d6c7 ] cilium bpf_wiregard.bpf.c when compiled with -O1 fails to load with the following verifier log: 192: (79) r2 = *(u64 *)(r10 -304) ; R2=pkt(r=40) R10=fp0 fp-304=pkt(r=40) ... 227: (85) call bpf_skb_store_bytes#9 ; R0=scalar() 228: (bc) w2 = w0 ; R0=scalar() R2=scalar(smin=0,smax=umax=0xffffffff,var_off=(0x0; 0xffffffff)) 229: (c4) w2 s>>= 31 ; R2=scalar(smin=0,smax=umax=0xffffffff,smin32=-1,smax32=0,var_off=(0x0; 0xffffffff)) 230: (54) w2 &= -134 ; R2=scalar(smin=0,smax=umax=umax32=0xffffff7a,smax32=0x7fffff7a,var_off=(0x0; 0xffffff7a)) ... 232: (66) if w2 s> 0xffffffff goto pc+125 ; R2=scalar(smin=umin=umin32=0x80000000,smax=umax=umax32=0xffffff7a,smax32=-134,var_off=(0x80000000; 0x7fffff7a)) ... 238: (79) r4 = *(u64 *)(r10 -304) ; R4=scalar() R10=fp0 fp-304=scalar() 239: (56) if w2 != 0xffffff78 goto pc+210 ; R2=0xffffff78 // -136 ... 258: (71) r1 = *(u8 *)(r4 +0) R4 invalid mem access 'scalar' The error might confuse most bpf authors, since fp-304 slot had 'pkt' pointer at insn 192 and became 'scalar' at 238. That happened because bpf_skb_store_bytes() clears all packet pointers including those in the stack. On the first glance it might look like a bug in the source code, since ctx->data pointer should have been reloaded after the call to bpf_skb_store_bytes(). The relevant part of cilium source code looks like this: // bpf/lib/nodeport.h int dsr_set_ipip6() { if (ctx_adjust_hroom(...)) return DROP_INVALID; // -134 if (ctx_store_bytes(...)) return DROP_WRITE_ERROR; // -141 return 0; } bool dsr_fail_needs_reply(int code) { if (code == DROP_FRAG_NEEDED) // -136 return true; return false; } tail_nodeport_ipv6_dsr() { ret = dsr_set_ipip6(...); if (!IS_ERR(ret)) { ... } else { if (dsr_fail_needs_reply(ret)) return dsr_reply_icmp6(...); } } The code doesn't have arithmetic shift by 31 and it reloads ctx->data every time it needs to access it. So it's not a bug in the source code. The reason is DAGCombiner::foldSelectCCToShiftAnd() LLVM transformation: // If this is a select where the false operand is zero and the compare is a // check of the sign bit, see if we can perform the "gzip trick": // select_cc setlt X, 0, A, 0 -> and (sra X, size(X)-1), A // select_cc setgt X, 0, A, 0 -> and (not (sra X, size(X)-1)), A The conditional branch in dsr_set_ipip6() and its return values are optimized into BPF_ARSH plus BPF_AND: 227: (85) call bpf_skb_store_bytes#9 228: (bc) w2 = w0 229: (c4) w2 s>>= 31 ; R2=scalar(smin=0,smax=umax=0xffffffff,smin32=-1,smax32=0,var_off=(0x0; 0xffffffff)) 230: (54) w2 &= -134 ; R2=scalar(smin=0,smax=umax=umax32=0xffffff7a,smax32=0x7fffff7a,var_off=(0x0; 0xffffff7a)) after insn 230 the register w2 can only be 0 or -134, but the verifier approximates it, since there is no way to represent two scalars in bpf_reg_state. After fallthough at insn 232 the w2 can only be -134, hence the branch at insn 239: (56) if w2 != -136 goto pc+210 should be always taken, and trapping insn 258 should never execute. LLVM generated correct code, but the verifier follows impossible path and rejects valid program. To fix this issue recognize this special LLVM optimization and fork the verifier state. So after insn 229: (c4) w2 s>>= 31 the verifier has two states to explore: one with w2 = 0 and another with w2 = 0xffffffff which makes the verifier accept bpf_wiregard.c A similar pattern exists were OR operation is used in place of the AND operation, the verifier detects that pattern as well by forking the state before the OR operation with a scalar in range [-1,0]. Note there are 20+ such patterns in bpf_wiregard.o compiled with -O1 and -O2, but they're rarely seen in other production bpf programs, so push_stack() approach is not a concern. Reported-by: Hao Sun Signed-off-by: Alexei Starovoitov Co-developed-by: Puranjay Mohan Signed-off-by: Puranjay Mohan Link: https://lore.kernel.org/r/20260112201424.816836-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit c1357b496286dba5381d16016ba792ae564786c9 Author: Sami Tolvanen Date: Sat Jan 10 08:25:51 2026 +0000 bpf: net_sched: Use the correct destructor kfunc type [ Upstream commit c99d97b46631c4bea0c14b7581b7a59214601e63 ] With CONFIG_CFI enabled, the kernel strictly enforces that indirect function calls use a function pointer type that matches the target function. As bpf_kfree_skb() signature differs from the btf_dtor_kfunc_t pointer type used for the destructor calls in bpf_obj_free_fields(), add a stub function with the correct type to fix the type mismatch. Signed-off-by: Sami Tolvanen Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20260110082548.113748-8-samitolvanen@google.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 50d6fd69388cc7b05dce72f09080674dcede4ac9 Author: Sami Tolvanen Date: Sat Jan 10 08:25:50 2026 +0000 bpf: crypto: Use the correct destructor kfunc type [ Upstream commit b40a5d724f29fc2eed23ff353808a9aae616b48a ] With CONFIG_CFI enabled, the kernel strictly enforces that indirect function calls use a function pointer type that matches the target function. I ran into the following type mismatch when running BPF self-tests: CFI failure at bpf_obj_free_fields+0x190/0x238 (target: bpf_crypto_ctx_release+0x0/0x94; expected type: 0xa488ebfc) Internal error: Oops - CFI: 00000000f2008228 [#1] SMP ... As bpf_crypto_ctx_release() is also used in BPF programs and using a void pointer as the argument would make the verifier unhappy, add a simple stub function with the correct type and register it as the destructor kfunc instead. Signed-off-by: Sami Tolvanen Acked-by: Yonghong Song Tested-by: Viktor Malik Link: https://lore.kernel.org/r/20260110082548.113748-7-samitolvanen@google.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit c67bbeb87aea0c50d4730431a59919bc78b8e9d5 Author: Sami Tolvanen Date: Mon Nov 17 20:38:07 2025 +0000 gendwarfksyms: Fix build on 32-bit hosts [ Upstream commit ddc54f912a551f6eb0bbcfc3880f45fe27a252cb ] We have interchangeably used unsigned long for some of the types defined in elfutils, assuming they're always 64-bit. This obviously fails when building gendwarfksyms on 32-bit hosts. Fix the types. Reported-by: Michal Suchánek Closes: https://lore.kernel.org/linux-modules/aRcxzPxtJblVSh1y@kitsune.suse.cz/ Tested-by: Michal Suchánek Signed-off-by: Sami Tolvanen Signed-off-by: Sasha Levin commit cf9e5b8b9e3126538983ae394bd487850d7216d2 Author: Martin Schiller Date: Mon Nov 24 08:48:45 2025 +0100 perf/x86/intel: Add Airmont NP [ Upstream commit a08340fd291671c54d379d285b2325490ce90ddd ] The Intel / MaxLinear Airmont NP (aka Lightning Mountain) supports the same architectual and non-architecural events as Airmont. Signed-off-by: Martin Schiller Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20251124074846.9653-3-ms@dev.tdt.de Signed-off-by: Sasha Levin commit 40497751c3f9bf03141f5e228aa5df31c8e692c7 Author: Martin Schiller Date: Mon Nov 24 08:48:46 2025 +0100 perf/x86/cstate: Add Airmont NP [ Upstream commit 3006911f284d769b0f66c12b39da130325ef1440 ] From the perspective of Intel cstate residency counters, the Airmont NP (aka Lightning Mountain) is identical to the Airmont. Signed-off-by: Martin Schiller Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20251124074846.9653-4-ms@dev.tdt.de Signed-off-by: Sasha Levin commit 89571b4a886f665413e1f748f6ef992e6a3c9931 Author: Martin Schiller Date: Mon Nov 24 08:48:44 2025 +0100 perf/x86/msr: Add Airmont NP [ Upstream commit 63dbadcafc1f4d1da796a8e2c0aea1e561f79ece ] Like Airmont, the Airmont NP (aka Intel / MaxLinear Lightning Mountain) supports SMI_COUNT MSR. Signed-off-by: Martin Schiller Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20251124074846.9653-2-ms@dev.tdt.de Signed-off-by: Sasha Levin commit 501c84f42b89dba339a82838ef64e9ad95f7e203 Author: Nick Hu Date: Tue Dec 2 14:07:40 2025 +0800 irqchip/riscv-imsic: Add a CPU pm notifier to restore the IMSIC on exit [ Upstream commit f48b4bd0915bf61ac12b8c65c7939ebd03bc8abf ] The IMSIC might be reset when the system enters a low power state, but on exit nothing restores the registers, which prevents interrupt delivery. Solve this by registering a CPU power management notifier, which restores the IMSIC on exit. Signed-off-by: Nick Hu Signed-off-by: Thomas Gleixner Reviewed-by: Yong-Xuan Wang Reviewed-by: Cyan Yang Reviewed-by: Anup Patel Reviewed-by: Nutty Liu Link: https://patch.msgid.link/20251202-preserve-aplic-imsic-v3-1-1844fbf1fe92@sifive.com Signed-off-by: Sasha Levin commit bad352600722fedfce7123769ae64c9266f51b08 Author: Cupertino Miranda Date: Tue Dec 2 18:02:19 2025 +0000 bpf: verifier improvement in 32bit shift sign extension pattern [ Upstream commit d18dec4b8990048ce75f0ece32bb96b3fbd3f422 ] This patch improves the verifier to correctly compute bounds for sign extension compiler pattern composed of left shift by 32bits followed by a sign right shift by 32bits. Pattern in the verifier was limitted to positive value bounds and would reset bound computation for negative values. New code allows both positive and negative values for sign extension without compromising bound computation and verifier to pass. This change is required by GCC which generate such pattern, and was detected in the context of systemd, as described in the following GCC bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119731 Three new tests were added in verifier_subreg.c. Signed-off-by: Cupertino Miranda Signed-off-by: Andrew Pinski Acked-by: Eduard Zingerman Cc: David Faust Cc: Jose Marchesi Cc: Elena Zannoni Link: https://lore.kernel.org/r/20251202180220.11128-2-cupertino.miranda@oracle.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit c6a27aa6585260fc6bdf83f48806e99ea0946c22 Author: Sam James Date: Wed Feb 4 13:40:29 2026 +0000 sparc: don't reference obsolete termio struct for TC* constants [ Upstream commit be0bccffcde3308150d2a90e55fc10e249098909 ] Similar in nature to commit ab107276607a ("powerpc: Fix struct termio related ioctl macros"). glibc-2.42 drops the legacy termio struct, but the ioctls.h header still defines some TC* constants in terms of termio (via sizeof). Hardcode the values instead. This fixes building Python for example, which falls over like: ./Modules/termios.c:1119:16: error: invalid application of 'sizeof' to incomplete type 'struct termio' Link: https://bugs.gentoo.org/961769 Link: https://bugs.gentoo.org/962600 Signed-off-by: Sam James Reviewed-by: Andreas Larsson Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit 6560e1d1fa324f22ec369e2257e986754255e5ea Author: Andreas Larsson Date: Mon Jan 19 15:47:52 2026 +0100 sparc: Synchronize user stack on fork and clone [ Upstream commit e38eba3b77878ada327a572a41596a3b0b44e522 ] Flush all uncommitted user windows before calling the generic syscall handlers for clone, fork, and vfork. Prior to entering the arch common handlers sparc_{clone|fork|vfork}, the arch-specific syscall wrappers for these syscalls will attempt to flush all windows (including user windows). In the window overflow trap handlers on both SPARC{32|64}, if the window can't be stored (i.e due to MMU related faults) the routine backups the user window and increments a thread counter (wsaved). By adding a synchronization point after the flush attempt, when fault handling is enabled, any uncommitted user windows will be flushed. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=31394 Closes: https://lore.kernel.org/sparclinux/fe5cc47167430007560501aabb28ba154985b661.camel@physik.fu-berlin.de/ Signed-off-by: Andreas Larsson Signed-off-by: Ludwig Rydberg Tested-by: John Paul Adrian Glaubitz Link: https://lore.kernel.org/r/20260119144753.27945-2-ludwig.rydberg@gaisler.com Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit f15b4e9286c7fa1417be8519e28352006f3ee549 Author: Luke Wang Date: Wed Feb 4 11:40:02 2026 +0800 block: decouple secure erase size limit from discard size limit [ Upstream commit ee81212f74a57c5d2b56cf504f40d528dac6faaf ] Secure erase should use max_secure_erase_sectors instead of being limited by max_discard_sectors. Separate the handling of REQ_OP_SECURE_ERASE from REQ_OP_DISCARD to allow each operation to use its own size limit. Signed-off-by: Luke Wang Reviewed-by: Ulf Hansson Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ea53119b1dff2b8b81cf09c6e3cfee374ea2870e Author: Yu Kuai Date: Tue Feb 3 16:19:43 2026 +0800 blk-mq-sched: unify elevators checking for async requests [ Upstream commit 1db61b0afdd7e8aa9289c423fdff002603b520b5 ] bfq and mq-deadline consider sync writes as async requests and only reserve tags for sync reads by async_depth, however, kyber doesn't consider sync writes as async requests for now. Consider the case there are lots of dirty pages, and user use fsync to flush dirty pages. In this case sched_tags can be exhausted by sync writes and sync reads can stuck waiting for tag. Hence let kyber follow what mq-deadline and bfq did, and unify async requests checking for all elevators. Signed-off-by: Yu Kuai Reviewed-by: Nilay Shroff Reviewed-by: Hannes Reinecke Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 40932ac2433e824c91fb7232bbcd929c7c93cfd7 Author: Yu Kuai Date: Mon Feb 2 16:05:22 2026 +0800 blk-mq-debugfs: add missing debugfs_mutex in blk_mq_debugfs_register_hctxs() [ Upstream commit 9d20fd6ce1ba9733cd5ac96fcab32faa9fc404dd ] In blk_mq_update_nr_hw_queues(), debugfs_mutex is not held while creating debugfs entries for hctxs. Hence add debugfs_mutex there, it's safe because queue is not frozen. Signed-off-by: Yu Kuai Reviewed-by: Nilay Shroff Reviewed-by: Ming Lei Reviewed-by: Hannes Reinecke Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d39d675a430308cda49c89e8d64bd80ba350b4c1 Author: Jason Andryuk Date: Wed Nov 19 17:47:29 2025 -0500 xenbus: Use .freeze/.thaw to handle xenbus devices [ Upstream commit e08dd1ee49838750a514e83c0aa60cd12ba6ecbb ] The goal is to fix s2idle and S3 for Xen PV devices. A domain resuming from s3 or s2idle disconnects its PV devices during resume. The backends are not expecting this and do not reconnect. b3e96c0c7562 ("xen: use freeze/restore/thaw PM events for suspend/ resume/chkpt") changed xen_suspend()/do_suspend() from PMSG_SUSPEND/PMSG_RESUME to PMSG_FREEZE/PMSG_THAW/PMSG_RESTORE, but the suspend/resume callbacks remained. .freeze/restore are used with hiberation where Linux restarts in a new place in the future. .suspend/resume are useful for runtime power management for the duration of a boot. The current behavior of the callbacks works for an xl save/restore or live migration where the domain is restored/migrated to a new location and connecting to a not-already-connected backend. Change xenbus_pm_ops to use .freeze/thaw/restore and drop the .suspend/resume hook. This matches the use in drivers/xen/manage.c for save/restore and live migration. With .suspend/resume empty, PV devices are left connected during s2idle and s3, so PV devices are not changed and work after resume. Signed-off-by: Jason Andryuk Acked-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20251119224731.61497-2-jason.andryuk@amd.com> Signed-off-by: Sasha Levin commit 11d591f1d70e7895e4c1fa91da422ddce14f35b4 Author: Ata İlhan Köktürk Date: Thu Jan 29 17:48:56 2026 +0300 ACPI: battery: fix incorrect charging status when current is zero [ Upstream commit bb1256e0ddc7e9e406164319769b9f8d8389f056 ] On some laptops, such as the Huawei Matebook series, the embedded controller continues to report "Charging" status even when the charge threshold is reached and no current is being drawn. This incorrect reporting prevents the system from switching to battery power profiles, leading to significantly higher power (e.g., 18W instead of 7W during browsing) and missed remaining battery time estimation. Validate the "Charging" state by checking if rate_now is zero. If the hardware reports charging but the current is zero, report "Not Charging" to user space. Signed-off-by: Ata İlhan Köktürk [ rjw: Whitespace fix, braces added to an inner if (), new comment rewrite ] [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260129144856.43058-1-atailhan2006@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit baeecf1ac9e8e2ef17bd0cf8366d6967564d373e Author: Jakob Riemenschneider Date: Tue Jan 27 21:01:21 2026 +0100 ACPI: x86: s2idle: Invoke Microsoft _DSM Function 9 (Turn On Display) [ Upstream commit 229ecbaac6b31f89c554b77eb407377a5eade7d4 ] Windows 11, version 22H2 introduced a new function index (Function 9) to the Microsoft LPS0 _DSM, titled "Turn On Display Notification". According to Microsoft documentation, this function signals to the system firmware that the OS intends to turn on the display when exiting Modern Standby. This allows the firmware to release Power Limits (PLx) earlier. Crucially, this patch fixes a functional issue observed on the Lenovo Yoga Slim 7i Aura (15ILL9), where system fans and keyboard backlights fail to resume after suspend. Investigation linked shows the EC on this device turns off these components during sleep but requires the Function 9 notification to wake them up again. This patch defines the new function index (ACPI_MS_TURN_ON_DISPLAY) and invokes it in acpi_s2idle_restore_early_lps0(). The execution order is updated to match the logic of an "intent" signal: 1. LPS0 Exit (Function 6) 2. Turn On Display Intent (Function 9) 3. Modern Standby Exit (Function 8) 4. Screen On (Function 4) Invoking Function 9 before the Modern Standby Exit ensures the firmware has time to restore power rails and functionality (like fans) before the software fully exits the sleep state. Link: https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-firmware-notifications#turn-on-display-notification-function-9 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220505 Suggested-by: Antheas Kapenekakis Signed-off-by: Jakob Riemenschneider Link: https://patch.msgid.link/20260127200121.1292216-1-riemenschneiderjakob@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit da0ce17c9d5c8a66dbdd68cb5188c2352a0e0b70 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:34 2026 +0100 perf/cxlpmu: Replace IRQF_ONESHOT with IRQF_NO_THREAD [ Upstream commit ab26d9c85554c4ff1d95ca8341522880ed9219d6 ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also disallows force-threading of the primary handler and the irq-core will warn about this. The intention here was probably not allowing forced-threading. Replace IRQF_ONESHOT with IRQF_NO_THREAD. Reviewed-by: Jonathan Cameron Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 8e6ea0b484fa1f47408192736fd4a97f1849d5b1 Author: Thomas Richter Date: Fri Jan 23 10:14:12 2026 +0100 s390/perf: Disable register readout on sampling events [ Upstream commit b2c04fc1239062b39ddfdd8731ee1a10810dfb74 ] Running commands # ./perf record -IR0,R1 -a sleep 1 extracts and displays register value of general purpose register r1 and r0. However the value displayed of any register is random and does not reflect the register value recorded at the time of the sample interrupt. The sampling device driver on s390 creates a very large buffer for the hardware to store the samples. Only when that large buffer gets full an interrupt is generated and many hundreds of sample entries are processed and copied to the kernel ring buffer and eventually get copied to the perf tool. It is during the copy to the kernel ring buffer that each sample is processed (on s390) and at that time the register values are extracted. This is not the original goal, the register values should be read when the samples are created not when the samples are copied to the kernel ring buffer. Prevent this event from being installed in the first place and return -EOPNOTSUPP. This is already the case for PERF_SAMPLE_REGS_USER. Signed-off-by: Thomas Richter Reviewed-by: Jan Polensky Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit f5b48df92c1cf9411700bb36c35918058fb7e1b6 Author: Konrad Dybcio Date: Tue Jan 13 16:25:35 2026 +0100 cpufreq: dt-platdev: Block the driver from probing on more QC platforms [ Upstream commit 7b781899072c5701ef9538c365757ee9ab9c00bd ] Add a number of QC platforms to the blocklist, they all use either the qcom-cpufreq-hw driver. Signed-off-by: Konrad Dybcio Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit e8d10ef5988ea412a51f63b3466e335be4c8f3b7 Author: Alexandre Courbot Date: Fri Nov 28 11:11:39 2025 +0900 rust: cpufreq: always inline functions using build_assert with arguments [ Upstream commit 8c8b12a55614ea05953e8d695e700e6e1322a05d ] `build_assert` relies on the compiler to optimize out its error path. Functions using it with its arguments must thus always be inlined, otherwise the error path of `build_assert` might not be optimized out, triggering a build error. Signed-off-by: Alexandre Courbot Reviewed-by: Daniel Almeida Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 24783dd06de870d646c25207bae186f78195f912 Author: Heinz Mauelshagen Date: Wed Jan 14 18:52:21 2026 +0100 md raid: fix hang when stopping arrays with metadata through dm-raid [ Upstream commit cefcb9297fbdb6d94b61787b4f8d84f55b741470 ] When using device-mapper's dm-raid target, stopping a RAID array can cause the system to hang under specific conditions. This occurs when: - A dm-raid managed device tree is suspended from top to bottom (the top-level RAID device is suspended first, followed by its underlying metadata and data devices) - The top-level RAID device is then removed Removing the top-level device triggers a hang in the following sequence: the dm-raid destructor calls md_stop(), which tries to flush the write-intent bitmap by writing to the metadata sub-devices. However, these devices are already suspended, making them unable to complete the write-intent operations and causing an indefinite block. Fix: - Prevent bitmap flushing when md_stop() is called from dm-raid destructor context and avoid a quiescing/unquescing cycle which could also cause I/O - Still allow write-intent bitmap flushing when called from dm-raid suspend context This ensures that RAID array teardown can complete successfully even when the underlying devices are in a suspended state. This second patch uses md_is_rdwr() to distinguish between suspend and destructor paths as elaborated on above. Link: https://lore.kernel.org/linux-raid/CAM23VxqYrwkhKEBeQrZeZwQudbiNey2_8B_SEOLqug=pXxaFrA@mail.gmail.com Signed-off-by: Heinz Mauelshagen Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 721599e837d3f4c0e6cc14da059612c017b6d3ec Author: Jiasheng Jiang Date: Sat Jan 17 14:59:03 2026 +0000 md-cluster: fix NULL pointer dereference in process_metadata_update [ Upstream commit f150e753cb8dd756085f46e86f2c35ce472e0a3c ] The function process_metadata_update() blindly dereferences the 'thread' pointer (acquired via rcu_dereference_protected) within the wait_event() macro. While the code comment states "daemon thread must exist", there is a valid race condition window during the MD array startup sequence (md_run): 1. bitmap_load() is called, which invokes md_cluster_ops->join(). 2. join() starts the "cluster_recv" thread (recv_daemon). 3. At this point, recv_daemon is active and processing messages. 4. However, mddev->thread (the main MD thread) is not initialized until later in md_run(). If a METADATA_UPDATED message is received from a remote node during this specific window, process_metadata_update() will be called while mddev->thread is still NULL, leading to a kernel panic. To fix this, we must validate the 'thread' pointer. If it is NULL, we release the held lock (no_new_dev_lockres) and return early, safely ignoring the update request as the array is not yet fully ready to process it. Link: https://lore.kernel.org/linux-raid/20260117145903.28921-1-jiashengjiangcool@gmail.com Signed-off-by: Jiasheng Jiang Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 03e42b5f7ad4c2c3db8bd384bab7990d5d53c90f Author: Magnus Lindholm Date: Fri Jan 2 18:30:43 2026 +0100 alpha: fix user-space corruption during memory compaction [ Upstream commit dd5712f3379cfe760267cdd28ff957d9ab4e51c7 ] Alpha systems can suffer sporadic user-space crashes and heap corruption when memory compaction is enabled. Symptoms include SIGSEGV, glibc allocator failures (e.g. "unaligned tcache chunk"), and compiler internal errors. The failures disappear when compaction is disabled or when using global TLB invalidation. The root cause is insufficient TLB shootdown during page migration. Alpha relies on ASN-based MM context rollover for instruction cache coherency, but this alone is not sufficient to prevent stale data or instruction translations from surviving migration. Fix this by introducing a migration-specific helper that combines: - MM context invalidation (ASN rollover), - immediate per-CPU TLB invalidation (TBI), - synchronous cross-CPU shootdown when required. The helper is used only by migration/compaction paths to avoid changing global TLB semantics. Additionally, update flush_tlb_other(), pte_clear(), to use READ_ONCE()/WRITE_ONCE() for correct SMP memory ordering. This fixes observed crashes on both UP and SMP Alpha systems. Reviewed-by: Ivan Kokshaysky Tested-by: Matoro Mahri Tested-by: Michael Cree Signed-off-by: Magnus Lindholm Link: https://lore.kernel.org/r/20260102173603.18247-2-linmag7@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin commit bfc1a95012c4dc6aa4f0f4d6945f84123a16f35e Author: Jens Axboe Date: Tue Jan 20 09:53:43 2026 -0700 io_uring/timeout: annotate data race in io_flush_timeouts() [ Upstream commit 42b12cb5fd4554679bac06bbdd05dc8b643bcc42 ] syzbot correctly reports this as a KCSAN race, as ctx->cached_cq_tail should be read under ->uring_lock. This isn't immediately feasible in io_flush_timeouts(), but as long as we read a stable value, that should be good enough. If two io-wq threads compete on this value, then they will both end up calling io_flush_timeouts() and at least one of them will see the correct value. Reported-by: syzbot+6c48db7d94402407301e@syzkaller.appspotmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 790a984e34f3aea01ba66f191408180e2f8e3e43 Author: Daniel Tang Date: Wed Jan 14 21:01:52 2026 -0500 powercap: intel_rapl: Add PL4 support for Ice Lake [ Upstream commit 54b3cd55a515c7c0fcfa0c1f0b10d62c11d64bcc ] Microsoft Surface Pro 7 firmware throttles the processor upon boot/resume. Userspace needs to be able to restore the correct value. Link: https://github.com/linux-surface/linux-surface/issues/706 Signed-off-by: Daniel Tang Link: https://patch.msgid.link/6088605.ChMirdbgyp@daniel-desktop3 Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 2a9bf565d6fe4752fbae57ece2c1a79641594d5a Author: Armin Wolf Date: Wed Jan 14 13:25:33 2026 +0100 ACPICA: Abort AML bytecode execution when executing AML_FATAL_OP [ Upstream commit 026ad376a6a48538b576f3589331daa94daae6f0 ] The ACPI specification states that when executing AML_FATAL_OP, the OS should log the fatal error event and shutdown in a timely fashion. Windows complies with this requirement by immediatly entering a Bso_d, effectively aborting the execution of the AML bytecode in question. ACPICA however might continue with the AML bytecode execution should acpi_os_signal() simply return AE_OK. This will cause issues because ACPI BIOS implementations might assume that the Fatal() operator does not return. Fix this by aborting the AML bytecode execution in such a case by returning AE_ERROR. Also turn struct acpi_signal_fatal_info into a local variable because of its small size (12 bytes) and to ensure that acpi_os_signal() always receives valid information about the fatal ACPI BIOS error. Link: https://github.com/acpica/acpica/commit/d516c7758ba6 Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3325491.5fSG56mABF@rafael.j.wysocki Signed-off-by: Sasha Levin commit 62dfb8ac00a5ceb1bd619336adc110b21a17fea0 Author: Ai Chao Date: Tue Jan 13 15:27:19 2026 +0800 ACPI: resource: Add JWIPC JVC9100 to irq1_level_low_skip_override[] [ Upstream commit ba6ded26dffe511b862a98a25955955e7154bfa8 ] Like the JWIPC JVC9100 has its serial IRQ (10 and 11) described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh which breaks the serial. irq 10, level, active-low, shared, skip-override irq 11, level, active-low, shared, skip-override Add the JVC9100 to the irq1_level_low_skip_override[] quirk table to fix this. Signed-off-by: Ai Chao Link: https://patch.msgid.link/20260113072719.4154485-1-aichao@kylinos.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 29f60d3d06818d40118a30d663231f027ae87a05 Author: Tuo Li Date: Mon Jan 12 00:32:14 2026 +0800 ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4() [ Upstream commit f132e089fe89cadc2098991f0a3cb05c3f824ac6 ] In acpi_processor_errata_piix4(), the pointer dev is first assigned an IDE device and then reassigned an ISA device: dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB, ...); dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB_0, ...); If the first lookup succeeds but the second fails, dev becomes NULL. This leads to a potential null-pointer dereference when dev_dbg() is called: if (errata.piix4.bmisx) dev_dbg(&dev->dev, ...); To prevent this, use two temporary pointers and retrieve each device independently, avoiding overwriting dev with a possible NULL value. Signed-off-by: Tuo Li [ rjw: Subject adjustment, added an empty code line ] Link: https://patch.msgid.link/20260111163214.202262-1-islituo@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 25b290624b0e3d2f0f90238709ee0b6009b9fde8 Author: Mauro Carvalho Chehab Date: Thu Jan 8 12:35:04 2026 +0100 EFI/CPER: don't go past the ARM processor CPER record buffer [ Upstream commit eae21beecb95a3b69ee5c38a659f774e171d730e ] There's a logic inside GHES/CPER to detect if the section_length is too small, but it doesn't detect if it is too big. Currently, if the firmware receives an ARM processor CPER record stating that a section length is big, kernel will blindly trust section_length, producing a very long dump. For instance, a 67 bytes record with ERR_INFO_NUM set 46198 and section length set to 854918320 would dump a lot of data going a way past the firmware memory-mapped area. Fix it by adding a logic to prevent it to go past the buffer if ERR_INFO_NUM is too big, making it report instead: [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 [Hardware Error]: event severity: recoverable [Hardware Error]: Error 0, type: recoverable [Hardware Error]: section_type: ARM processor error [Hardware Error]: MIDR: 0xff304b2f8476870a [Hardware Error]: section length: 854918320, CPER size: 67 [Hardware Error]: section length is too big [Hardware Error]: firmware-generated error record is incorrect [Hardware Error]: ERR_INFO_NUM is 46198 Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Ard Biesheuvel Reviewed-by: Hanjun Guo [ rjw: Subject and changelog tweaks ] Link: https://patch.msgid.link/41cd9f6b3ace3cdff7a5e864890849e4b1c58b63.1767871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 136093ba4161e0080088abff48273f6830a47766 Author: Mauro Carvalho Chehab Date: Thu Jan 8 12:35:03 2026 +0100 APEI/GHES: ARM processor Error: don't go past allocated memory [ Upstream commit 87880af2d24e62a84ed19943dbdd524f097172f2 ] If the BIOS generates a very small ARM Processor Error, or an incomplete one, the current logic will fail to deferrence err->section_length and ctx_info->size Add checks to avoid that. With such changes, such GHESv2 records won't cause OOPSes like this: [ 1.492129] Internal error: Oops: 0000000096000005 [#1] SMP [ 1.495449] Modules linked in: [ 1.495820] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.18.0-rc1-00017-gabadcc3553dd-dirty #18 PREEMPT [ 1.496125] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 [ 1.496433] Workqueue: kacpi_notify acpi_os_execute_deferred [ 1.496967] pstate: 814000c5 (Nzcv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1.497199] pc : log_arm_hw_error+0x5c/0x200 [ 1.497380] lr : ghes_handle_arm_hw_error+0x94/0x220 0xffff8000811c5324 is in log_arm_hw_error (../drivers/ras/ras.c:75). 70 err_info = (struct cper_arm_err_info *)(err + 1); 71 ctx_info = (struct cper_arm_ctx_info *)(err_info + err->err_info_num); 72 ctx_err = (u8 *)ctx_info; 73 74 for (n = 0; n < err->context_info_num; n++) { 75 sz = sizeof(struct cper_arm_ctx_info) + ctx_info->size; 76 ctx_info = (struct cper_arm_ctx_info *)((long)ctx_info + sz); 77 ctx_len += sz; 78 } 79 and similar ones while trying to access section_length on an error dump with too small size. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Ard Biesheuvel Reviewed-by: Hanjun Guo [ rjw: Subject tweaks ] Link: https://patch.msgid.link/7fd9f38413be05ee2d7cfdb0dc31ea2274cf1a54.1767871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6f5d41984ad896736c23e2fff7c80e15c1319132 Author: Mauro Carvalho Chehab Date: Thu Jan 8 12:35:05 2026 +0100 APEI/GHES: ensure that won't go past CPER allocated record [ Upstream commit fa2408a24f8f0db14d9cfc613ef162dc267d7ad4 ] The logic at ghes_new() prevents allocating too large records, by checking if they're bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB). Yet, the allocation is done with the actual number of pages from the CPER bios table location, which can be smaller. Yet, a bad firmware could send data with a different size, which might be bigger than the allocated memory, causing an OOPS: Unable to handle kernel paging request at virtual address fff00000f9b40000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 52-bit VAs, pgdp=000000008ba16000 [fff00000f9b40000] pgd=180000013ffff403, p4d=180000013fffe403, pud=180000013f85b403, pmd=180000013f68d403, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-gda407d200220 #34 PREEMPT Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 Workqueue: kacpi_notify acpi_os_execute_deferred pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : hex_dump_to_buffer+0x30c/0x4a0 lr : hex_dump_to_buffer+0x328/0x4a0 sp : ffff800080e13880 x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083 x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004 x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083 x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010 x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008 x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020 x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000 x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008 Call trace: hex_dump_to_buffer+0x30c/0x4a0 (P) print_hex_dump+0xac/0x170 cper_estatus_print_section+0x90c/0x968 cper_estatus_print+0xf0/0x158 __ghes_print_estatus+0xa0/0x148 ghes_proc+0x1bc/0x220 ghes_notify_hed+0x5c/0xb8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x80 acpi_hed_notify+0x28/0x40 acpi_ev_notify_dispatch+0x50/0x80 acpi_os_execute_deferred+0x24/0x48 process_one_work+0x15c/0x3b0 worker_thread+0x2d0/0x400 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44) ---[ end trace 0000000000000000 ]--- Prevent that by taking the actual allocated are into account when checking for CPER length. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Ard Biesheuvel Reviewed-by: Hanjun Guo [ rjw: Subject tweaks ] Link: https://patch.msgid.link/4e70310a816577fabf37d94ed36cde4ad62b1e0a.1767871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit a8419f5f2c5f2d80848ddabb2b95cf0da84a5f91 Author: Mauro Carvalho Chehab Date: Thu Jan 8 12:35:06 2026 +0100 EFI/CPER: don't dump the entire memory region [ Upstream commit 55cc6fe5716f678f06bcb95140882dfa684464ec ] The current logic at cper_print_fw_err() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory. The end result can be: - the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region. Fix it by checking if the section length is too small before doing a hex dump. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Ard Biesheuvel Reviewed-by: Hanjun Guo [ rjw: Subject tweaks ] Link: https://patch.msgid.link/1752b5ba63a3e2f148ddee813b36c996cc617e86.1767871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 142c444a395f4d26055c8a4473e228bb86283f1e Author: Al Viro Date: Wed Nov 19 16:15:04 2025 -0500 ntfs: ->d_compare() must not block [ Upstream commit ca2a04e84af79596e5cd9cfe697d5122ec39c8ce ] ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX. Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 6d61077981cfd4e609207e244a7f5c0813c2f37f Author: Hou Wenlong Date: Sat Jan 10 12:00:08 2026 +0800 x86/xen/pvh: Enable PAE mode for 32-bit guest only when CONFIG_X86_PAE is set [ Upstream commit db9aded979b491a24871e1621cd4e8822dbca859 ] The PVH entry is available for 32-bit KVM guests, and 32-bit KVM guests do not depend on CONFIG_X86_PAE. However, mk_early_pgtbl_32() builds different pagetables depending on whether CONFIG_X86_PAE is set. Therefore, enabling PAE mode for 32-bit KVM guests without CONFIG_X86_PAE being set would result in a boot failure during CR3 loading. Signed-off-by: Hou Wenlong Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: Signed-off-by: Sasha Levin commit c94ede3c436dfbd9cedd9cb69f604f6fc901b6a2 Author: Md Haris Iqbal Date: Fri Dec 5 13:47:33 2025 +0100 rnbd-srv: Zero the rsp buffer before using it [ Upstream commit 69d26698e4fd44935510553809007151b2fe4db5 ] Before using the data buffer to send back the response message, zero it completely. This prevents any stray bytes to be picked up by the client side when there the message is exchanged between different protocol versions. Signed-off-by: Md Haris Iqbal Signed-off-by: Jack Wang Signed-off-by: Grzegorz Prajsner Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit fd51d47fcacec3ca027eb65d8c44853d3b6cea95 Author: Jinqian Yang Date: Sat Dec 27 17:24:48 2025 +0800 arm64: Add support for TSV110 Spectre-BHB mitigation [ Upstream commit e3baa5d4b361276efeb87b20d8beced451a7dbd5 ] The TSV110 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of TSV110 to the list for software mitigation. Signed-off-by: Jinqian Yang Reviewed-by: Zenghui Yu Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit f4ac7292b635fbd368619f08c2f6e4cce66689e9 Author: Robin Murphy Date: Mon Nov 24 16:39:54 2025 +0000 perf/arm-cmn: Support CMN-600AE [ Upstream commit 12a94953c37e834c3eabb839ce057094946fe67a ] The functional safety features of CMN-600AE have little to no impact on the PMU relative to the base CMN-600 design, so for simplicity we can reasonably just treat it as the same thing. The only obvious difference is that the revision numbers aren't aligned, so we may hide some aliases for events which do actually exist, but those can still be specified via the underlying "type,eventid" format so it's not too big a deal. Signed-off-by: Robin Murphy Reviewed-by: Ilkka Koskinen Tested-by: Michal Simek Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 8c7fdc39e38a1194756e919c5f162fe54c9b054c Author: Heiko Carstens Date: Fri Dec 12 16:47:07 2025 +0100 s390/purgatory: Add -Wno-default-const-init-unsafe to KBUILD_CFLAGS [ Upstream commit b4780fe4ddf04b51127a33d705f4a2e224df00fa ] Add -Wno-default-const-init-unsafe to purgatory KBUILD_CFLAGS, similar to scripts/Makefile.extrawarn, since clang generates warnings for the dummy variable in typecheck(): CC arch/s390/purgatory/purgatory.o arch/s390/include/asm/ptrace.h:221:9: warning: default initialization of an object of type 'typeof (regs->psw)' (aka 'const psw_t') leaves the object uninitialized [-Wdefault-const-init-var-unsafe] 221 | return psw_bits(regs->psw).pstate; | ^ arch/s390/include/asm/ptrace.h:98:2: note: expanded from macro 'psw_bits' 98 | typecheck(psw_t, __psw); \ | ^ include/linux/typecheck.h:11:12: note: expanded from macro 'typecheck' 11 | typeof(x) __dummy2; \ | ^ Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit c7671c46dab46c540743e57a5c6f7628acfefc6d Author: Kaushlendra Kumar Date: Mon Dec 1 17:47:45 2025 +0530 tools/power cpupower: Reset errno before strtoull() [ Upstream commit f9bd3762cf1bd0c2465f2e6121b340883471d1bf ] cpuidle_state_get_one_value() never cleared errno before calling strtoull(), so a prior ERANGE caused every cpuidle counter read to return zero. Reset errno to 0 before the conversion so each sysfs read is evaluated independently. Link: https://lore.kernel.org/r/20251201121745.3776703-1-kaushlendra.kumar@intel.com Signed-off-by: Kaushlendra Kumar Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit f699251d5a2d946f59759d26d58a8e956e8fe8e1 Author: Heiko Carstens Date: Fri Dec 12 16:43:58 2025 +0100 s390/boot: Add -Wno-default-const-init-unsafe to KBUILD_CFLAGS [ Upstream commit 5ba35a6c13fff0929c34aba6b7602dacbe68686c ] Add -Wno-default-const-init-unsafe to boot KBUILD_CFLAGS, similar to scripts/Makefile.extrawarn, since clang generates warnings for the dummy variable in typecheck(): CC arch/s390/boot/version.o arch/s390/include/asm/ptrace.h:221:9: warning: default initialization of an object of type 'typeof (regs->psw)' (aka 'const psw_t') leaves the object uninitialized [-Wdefault-const-init-var-unsafe] 221 | return psw_bits(regs->psw).pstate; | ^ arch/s390/include/asm/ptrace.h:98:2: note: expanded from macro 'psw_bits' 98 | typecheck(psw_t, __psw); \ | ^ include/linux/typecheck.h:11:12: note: expanded from macro 'typecheck' 11 | typeof(x) __dummy2; \ | ^ Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit f0729486c9076e3beb410dbdae98450981581e60 Author: Kaushlendra Kumar Date: Wed Nov 26 14:46:13 2025 +0530 tools/cpupower: Fix inverted APERF capability check [ Upstream commit 24858a84163c8d04827166b3bcaed80612bb62fc ] The capability check was inverted, causing the function to return error when APERF support is available and proceed when it is not. Negate the condition to return error only when APERF capability is absent. Link: https://lore.kernel.org/r/20251126091613.567480-1-kaushlendra.kumar@intel.com Signed-off-by: Kaushlendra Kumar Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 6287eefaf21ec805d42f941bd368018cf397a7f5 Author: Henrique Carvalho Date: Mon Jan 19 14:54:44 2026 -0300 smb: client: prevent races in ->query_interfaces() [ Upstream commit c3c06e42e1527716c54f3ad2ced6a034b5f3a489 ] It was possible for two query interface works to be concurrently trying to update the interfaces. Prevent this by checking and updating iface_last_update under iface_lock. Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 2e121c53b581e40397ae08090a7af4ed10781fbc Author: Andreas Gruenbacher Date: Thu Feb 5 15:52:57 2026 +0100 gfs2: fiemap page fault fix [ Upstream commit e411d74cc5ba290f85d0dd5e4d1df8f1d6d975d2 ] In gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault. Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary. Fixes xfstest generic/742. Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 327de5b59801b15d9f4c519154f9a646c13b96f4 Author: Henrique Carvalho Date: Mon Jan 19 14:54:45 2026 -0300 smb: client: add proper locking around ses->iface_last_update [ Upstream commit e97dcac3dc0bd37e4b56aaa6874b572a3a461102 ] There is a missing ses->iface_lock in cifs_setup_session, around ses->iface_last_update. Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Sasha Levin commit be0d85bc660afe93ebe12ecea7f3d7af375d8a6c Author: Shyam Prasad N Date: Sat Jan 31 14:03:04 2026 +0530 netfs: when subreq is marked for retry, do not check if it faced an error [ Upstream commit 82e8885bd7633a36ee9050e6d7f348a4155eed5f ] The *_subreq_terminated functions today only process the NEED_RETRY flag when the subreq was successful or failed with EAGAIN error. However, there could be other retriable errors for network filesystems. Avoid this by processing the NEED_RETRY irrespective of the error code faced by the subreq. If it was specifically marked for retry, the error code must not matter. Acked-by: David Howells Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 66c3be4ac35d5aefa500372f8fba5f40c7221a9b Author: jinbaohong Date: Wed Jan 28 07:06:40 2026 +0000 btrfs: handle user interrupt properly in btrfs_trim_fs() [ Upstream commit bfb670b9183b0e4ba660aff2e396ec1cc01d0761 ] When a fatal signal is pending or the process is freezing, btrfs_trim_block_group() and btrfs_trim_free_extents() return -ERESTARTSYS. Currently this is treated as a regular error: the loops continue to the next iteration and count it as a block group or device failure. Instead, break out of the loops immediately and return -ERESTARTSYS to userspace without counting it as a failure. Also skip the device loop entirely if the block group loop was interrupted. Reviewed-by: Qu Wenruo Signed-off-by: Robbie Ko Signed-off-by: jinbaohong Reviewed-by: Filipe Manana Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 4d49275175fdbcdad35b2d8ad964e065b93f91e7 Author: Qu Wenruo Date: Sat Nov 1 10:22:16 2025 +1030 btrfs: fallback to buffered IO if the data profile has duplication [ Upstream commit 7c2830f00c3e086292c1ee9f27b61efaf8e76c9a ] [BACKGROUND] Inspired by a recent kernel bug report, which is related to direct IO buffer modification during writeback, that leads to contents mismatch of different RAID1 mirrors. [CAUSE AND PROBLEMS] The root cause is exactly the same explained in commit 968f19c5b1b7 ("btrfs: always fallback to buffered write if the inode requires checksum"), that we can not trust direct IO buffer which can be modified halfway during writeback. Unlike data checksum verification, if this happened on inodes without data checksum but has the data has extra mirrors, it will lead to stealth data mismatch on different mirrors. This will be way harder to detect without data checksum. Furthermore for RAID56, we can even have data without checksum and data with checksum mixed inside the same full stripe. In that case if the direct IO buffer got changed halfway for the nodatasum part, the data with checksum immediately lost its ability to recover, e.g.: " " = Good old data or parity calculated using good old data "X" = Data modified during writeback 0 32K 64K Data 1 | | Has csum Data 2 |XXXXXXXXXXXXXXXX | No csum Parity | | In above case, the parity is calculated using data 1 (has csum, from page cache, won't change during writeback), and old data 2 (has no csum, direct IO write). After parity is calculated, but before submission to the storage, direct IO buffer of data 2 is modified, causing the range [0, 32K) of data 2 has a different content. Now all data is submitted to the storage, and the fs got fully synced. Then the device of data 1 is lost, has to be rebuilt from data 2 and parity. But since the data 2 has some modified data, and the parity is calculated using old data, the recovered data is no the same for data 1, causing data checksum mismatch. [FIX] Fix the problem by checking the data allocation profile. If our data allocation profile is either RAID0 or SINGLE, we can allow true zero-copy direct IO and the end user is fully responsible for any race. However this is not going to fix all situations, as it's still possible to race with balance where the fs got a new data profile after the data allocation profile check. But this fix should still greatly reduce the window of the original bug. Link: https://bugzilla.kernel.org/show_bug.cgi?id=99171 Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 082083c9fbd99422a0370fe2102144a231c9f5d6 Author: Ezrak1e Date: Tue Jan 20 10:35:06 2026 -0500 dlm: validate length in dlm_search_rsb_tree [ Upstream commit 080e5563f878c64e697b89e7439d730d0daad882 ] The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow. Signed-off-by: Ezrak1e Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 31fefc18096cdc5549cfa54964d90e0b3229aedc Author: Jori Koolstra Date: Mon Dec 8 16:39:47 2025 +0100 minix: Add required sanity checking to minix_check_superblock() [ Upstream commit 8c97a6ddc95690a938ded44b4e3202f03f15078c ] The fs/minix implementation of the minix filesystem does not currently support any other value for s_log_zone_size than 0. This is also the only value supported in util-linux; see mkfs.minix.c line 511. In addition, this patch adds some sanity checking for the other minix superblock fields, and moves the minix_blocks_needed() checks for the zmap and imap also to minix_check_super_block(). This also closes a related syzbot bug report. Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20251208153947.108343-1-jkoolstra@xs4all.nl Reviewed-by: Jan Kara Reported-by: syzbot+5ad0824204c7bf9b67f2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5ad0824204c7bf9b67f2 Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 75903591f869a463d034638361743695fe613eb9 Author: Alexander Aring Date: Tue Jan 20 10:35:05 2026 -0500 dlm: fix recovery pending middle conversion [ Upstream commit 1416bd508c78bdfdb9ae0b4511369e5581f348ea ] During a workload involving conversions between lock modes PR and CW, lock recovery can create a "conversion deadlock" state between locks that have been recovered. When this occurs, kernel warning messages are logged, e.g. "dlm: WARN: pending deadlock 1e node 0 2 1bf21" "dlm: receive_rcom_lock_args 2e middle convert gr 3 rq 2 remote 2 1e" After this occurs, the deadlocked conversions both appear on the convert queue of the resource being locked, and the conversion requests do not complete. Outside of recovery, conversions that would produce a deadlock are resolved immediately, and return -EDEADLK. The locks are not placed on the convert queue in the deadlocked state. To fix this problem, an lkb under conversion between PR/CW is rebuilt during recovery on a new master's granted queue, with the currently granted mode, rather than being rebuilt on the new master's convert queue, with the currently granted mode and the newly requested mode. The in-progress convert is then resent to the new master after recovery, so the conversion deadlock will be processed outside of the recovery context and handled as described above. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 0e5806ef45f25cc8220b5945db8f6b9168809dd8 Author: Adrian Hunter Date: Tue Jan 13 09:26:42 2026 +0200 i3c: mipi-i3c-hci: Reset RING_OPERATION1 fields during init [ Upstream commit 78f63ae4a82db173f93adca462e63d11ba06b126 ] The MIPI I3C HCI specification does not define reset values for RING_OPERATION1 fields, and some controllers (e.g., Intel) do not clear them during a software reset. Ensure the ring pointers are explicitly set to zero during bus initialization to avoid inconsistent state. Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260113072702.16268-2-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit a2198bf95a4aedf2d6614d715592a94ebcc0063d Author: Adrian Hunter Date: Tue Jan 6 18:44:07 2026 +0200 i3c: mipi-i3c-hci: Stop reading Extended Capabilities if capability ID is 0 [ Upstream commit 0818e4aa8fdeeed5973e0a8faeddc9da599fc897 ] Extended Capability ID value 0 is special. It signifies the end of the list. Stop reading Extended Capabilities if capability ID is 0. Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260106164416.67074-3-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 98ddff8a90f82a45a3bf9cc02923c24c20dc75e4 Author: Frank Li Date: Mon Dec 15 15:08:51 2025 -0500 i3c: master: svc: Initialize 'dev' to NULL in svc_i3c_master_ibi_isr() [ Upstream commit 3c9ffb4db787428a5851d5865823ab23842d5103 ] Initialize the 'dev' pointer to NULL in svc_i3c_master_ibi_isr() and add a NULL check in the error path. Reported-by: kernel test robot Closes: https://lore.kernel.org/r/202512131016.YCKIsDXM-lkp@intel.com/ Signed-off-by: Frank Li Link: https://patch.msgid.link/20251215200852.3079073-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 67407d6abc9520a8a4661285b3ed294eb73ff6e7 Author: Tetsuo Handa Date: Tue Jan 6 18:39:33 2026 +0900 hfsplus: pretend special inodes as regular files [ Upstream commit ed8889ca21b6ab37bc1435c4009ce37a79acb9e6 ] Since commit af153bb63a33 ("vfs: catch invalid modes in may_open()") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for special inodes. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Signed-off-by: Tetsuo Handa Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/d0a07b1b-8b73-4002-8e29-e2bd56871262@I-love.SAKURA.ne.jp Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit a2e8c144299c31d3972295ed80d4cb908daf4f6f Author: Jeffrey Bencteux Date: Sat Dec 27 09:39:24 2025 +0100 audit: add missing syscalls to read class [ Upstream commit bcb90a2834c7393c26df9609b889a3097b7700cd ] The "at" variant of getxattr() and listxattr() are missing from the audit read class. Calling getxattrat() or listxattrat() on a file to read its extended attributes will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds missing syscalls to the audit read class. Signed-off-by: Jeffrey Bencteux Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit c6f2c554dd8bd9c08f39f54ac61200d5812bec6c Author: Clint George Date: Mon Dec 15 14:20:22 2025 +0530 kselftest/kublk: include message in _Static_assert for C11 compatibility [ Upstream commit 3e6ad272bb8b3199bad952e7b077102af2d8df03 ] Add descriptive message in the _Static_assert to comply with the C11 standard requirement to prevent compiler from throwing out error. The compiler throws an error when _Static_assert is used without a message as that is a C23 extension. [] Testing: The diff between before and after of running the kselftest test of the module shows no regression on system with x86 architecture [] Error log: ~/Desktop/kernel-dev/linux-v1/tools/testing/selftests/ublk$ make LLVM=1 W=1 CC kublk In file included from kublk.c:6: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extension [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <= 7); | ^ | , "" 1 error generated. In file included from null.c:3: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extension [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <= 7); | ^ | , "" 1 error generated. In file included from file_backed.c:3: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extension [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <= 7); | ^ | , "" 1 error generated. In file included from common.c:3: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extension [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <= 7); | ^ | , "" 1 error generated. In file included from stripe.c:3: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extension [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <= 7); | ^ | , "" 1 error generated. In file included from fault_inject.c:11: ./kublk.h:220:43: error: '_Static_assert' with no message is a C23 extension [-Werror,-Wc23-extensions] 220 | _Static_assert(UBLK_MAX_QUEUES_SHIFT <= 7); | ^ | , "" 1 error generated. make: *** [../lib.mk:225: ~/Desktop/kernel-dev/linux-v1/tools/testing/selftests/ublk/kublk] Error 1 Link: https://lore.kernel.org/r/20251215085022.7642-1-clintbgeorge@gmail.com Signed-off-by: Clint George Reviewed-by: Ming Lei Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 42c32d7571ccd8ef32351cac506f00b0fae99fd2 Author: Deepakkumar Karn Date: Thu Dec 11 18:42:11 2025 +0530 fs/buffer: add alert in try_to_free_buffers() for folios without buffers [ Upstream commit b68f91ef3b3fe82ad78c417de71b675699a8467c ] try_to_free_buffers() can be called on folios with no buffers attached when filemap_release_folio() is invoked on a folio belonging to a mapping with AS_RELEASE_ALWAYS set but no release_folio operation defined. In such cases, folio_needs_release() returns true because of the AS_RELEASE_ALWAYS flag, but the folio has no private buffer data. This causes try_to_free_buffers() to call drop_buffers() on a folio with no buffers, leading to a null pointer dereference. Adding a check in try_to_free_buffers() to return early if the folio has no buffers attached, with WARN_ON_ONCE() to alert about the misconfiguration. This provides defensive hardening. Signed-off-by: Deepakkumar Karn Link: https://patch.msgid.link/20251211131211.308021-1-dkarn@redhat.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 956b1d8051cfa391ab5dbf199a7e603dd3713ffa Author: Viacheslav Dubeyko Date: Sat Dec 6 19:58:22 2025 -0800 hfsplus: fix volume corruption issue for generic/498 [ Upstream commit 9a8c4ad44721da4c48e1ff240ac76286c82837fe ] The xfstests' test-case generic/498 leaves HFS+ volume in corrupted state: sudo ./check generic/498 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc1+ #18 SMP PREEMPT_DYNAMIC Thu Dec 4 12:24:45 PST 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/498 _check_generic_filesystem: filesystem on /dev/loop51 is inconsistent (see XFSTESTS-2/xfstests-dev/results//generic/498.full for details) Ran: generic/498 Failures: generic/498 Failed 1 of 1 tests sudo fsck.hfsplus -d /dev/loop51 ** /dev/loop51 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. Executing fsck_hfs (version 540.1-Linux). ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. Invalid leaf record count (It should be 16 instead of 2) ** Checking multi-linked files. CheckHardLinks: found 1 pre-Leopard file inodes. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. Verify Status: VIStat = 0x0000, ABTStat = 0x0000 EBTStat = 0x0000 CBTStat = 0x8000 CatStat = 0x00000000 ** Repairing volume. ** Rechecking volume. ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. CheckHardLinks: found 1 pre-Leopard file inodes. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled was repaired successfully. The generic/498 test executes such steps on final phase: mkdir $SCRATCH_MNT/A mkdir $SCRATCH_MNT/B mkdir $SCRATCH_MNT/A/C touch $SCRATCH_MNT/B/foo $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/B/foo ln $SCRATCH_MNT/B/foo $SCRATCH_MNT/A/C/foo $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/A "Simulate a power failure and mount the filesystem to check that what we explicitly fsync'ed exists." _flakey_drop_and_remount The FSCK tool complains about "Invalid leaf record count". HFS+ b-tree header contains leaf_count field is updated by hfs_brec_insert() and hfs_brec_remove(). The hfs_brec_insert() is involved into hard link creation process. However, modified in-core leaf_count field is stored into HFS+ b-tree header by hfs_btree_write() method. But, unfortunately, hfs_btree_write() hasn't been called by hfsplus_cat_write_inode() and hfsplus_file_fsync() stores not fully consistent state of the Catalog File's b-tree. This patch adds calling hfs_btree_write() method in the hfsplus_cat_write_inode() with the goal of storing consistent state of Catalog File's b-tree. Finally, it makes FSCK tool happy. sudo ./check generic/498 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc1+ #22 SMP PREEMPT_DYNAMIC Sat Dec 6 17:01:31 PST 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/498 33s ... 31s Ran: generic/498 Passed all 1 tests Signed-off-by: Viacheslav Dubeyko cc: John Paul Adrian Glaubitz cc: Yangtao Li cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/20251207035821.3863657-1-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 4fed776ca86378da7dd743a7b648e20b025ba8ef Author: Jeffrey Bencteux Date: Mon Nov 24 20:49:30 2025 +0100 audit: add fchmodat2() to change attributes class [ Upstream commit 4f493a6079b588cf1f04ce5ed6cdad45ab0d53dc ] fchmodat2(), introduced in version 6.6 is currently not in the change attribute class of audit. Calling fchmodat2() to change a file attribute in the same fashion than chmod() or fchmodat() will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds fchmodat2() to the change attributes class. Signed-off-by: Jeffrey Bencteux Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 54694417d4384d7b03ffe33990f9d28216a3f16c Author: Viacheslav Dubeyko Date: Thu Dec 4 16:00:55 2025 -0800 hfsplus: fix volume corruption issue for generic/480 [ Upstream commit bea4429eb30190c59b5ac7c8ff6c90176c7c110f ] The xfstests' test-case generic/480 leaves HFS+ volume in corrupted state: sudo ./check generic/480 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.17.0-rc1+ #4 SMP PREEMPT_DYNAMIC Wed Oct 1 15:02:44 PDT 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/480 _check_generic_filesystem: filesystem on /dev/loop51 is inconsistent (see XFSTESTS-2/xfstests-dev/results//generic/480.full for details) Ran: generic/480 Failures: generic/480 Failed 1 of 1 tests sudo fsck.hfsplus -d /dev/loop51 ** /dev/loop51 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. Executing fsck_hfs (version 540.1-Linux). ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. CheckHardLinks: found 1 pre-Leopard file inodes. Incorrect number of file hard links ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. invalid VHB nextCatalogID Volume header needs minor repair (2, 0) Verify Status: VIStat = 0x8000, ABTStat = 0x0000 EBTStat = 0x0000 CBTStat = 0x0000 CatStat = 0x00000002 ** Repairing volume. Incorrect flags for file hard link (id = 19) (It should be 0x22 instead of 0x2) Incorrect flags for file inode (id = 18) (It should be 0x22 instead of 0x2) first link ID=0 is < 16 for fileinode=18 Error getting first link ID for inode = 18 (result=2) Invalid first link in hard link chain (id = 18) (It should be 19 instead of 0) Indirect node 18 needs link count adjustment (It should be 1 instead of 2) ** Rechecking volume. ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled was repaired successfully. The generic/480 test executes such steps on final phase: "Now remove of the links of our file and create a new file with the same name and in the same parent directory, and finally fsync this new file." unlink $SCRATCH_MNT/testdir/bar touch $SCRATCH_MNT/testdir/bar $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir/bar "Simulate a power failure and mount the filesystem to check that replaying the fsync log/journal succeeds, that is the mount operation does not fail." _flakey_drop_and_remount The key issue in HFS+ logic is that hfsplus_link(), hfsplus_unlink(), hfsplus_rmdir(), hfsplus_symlink(), and hfsplus_mknod() methods don't call hfsplus_cat_write_inode() for the case of modified inode objects. As a result, even if hfsplus_file_fsync() is trying to flush the dirty Catalog File, but because of not calling hfsplus_cat_write_inode() not all modified inodes save the new state into Catalog File's records. Finally, simulation of power failure results in inconsistent state of Catalog File and FSCK tool reports about volume corruption. This patch adds calling of hfsplus_cat_write_inode() method for modified inodes in hfsplus_link(), hfsplus_unlink(), hfsplus_rmdir(), hfsplus_symlink(), and hfsplus_mknod() methods. Also, it adds debug output in several methods. sudo ./check generic/480 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc1+ #18 SMP PREEMPT_DYNAMIC Thu Dec 4 12:24:45 PST 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/480 16s ... 16s Ran: generic/480 Passed all 1 tests Signed-off-by: Viacheslav Dubeyko cc: John Paul Adrian Glaubitz cc: Yangtao Li cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/20251205000054.3670326-1-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit f13680f62934865ca7c83601d04f84b7b25b17ea Author: Bhavik Sachdev Date: Sat Nov 29 14:41:20 2025 +0530 statmount: permission check should return EPERM [ Upstream commit fccbe38a5d06dbe44bcd89196fe1d2c2272a1f4a ] Currently, statmount() returns ENOENT when caller is not CAP_SYS_ADMIN in the user namespace owner of target mount namespace. This should be EPERM instead. Suggested-by: Miklos Szeredi Signed-off-by: Bhavik Sachdev Link: https://patch.msgid.link/20251129091455.757724-2-b.sachdev1904@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit f987cbd82eb4c2a6c4e8f7b90e1fe65a526bd760 Author: Anthony Pighin (Nokia) Date: Tue Nov 25 17:35:19 2025 +0000 rtc: interface: Alarm race handling should not discard preceding error [ Upstream commit 81be22cd4ace020045cc6d31255c6f7c071eb7c0 ] Commit 795cda8338ea ("rtc: interface: Fix long-standing race when setting alarm") should not discard any errors from the preceding validations. Prior to that commit, if the alarm feature was disabled, or the set_alarm failed, a meaningful error code would be returned to the caller for further action. After, more often than not, the __rtc_read_time will cause a success return code instead, misleading the caller. An example of this is when timer_enqueue is called for a rtc-abx080x device. Since that driver does not clear the alarm feature bit, but instead relies on the set_alarm operation to return invalid, the discard of the return code causes very different behaviour; i.e. hwclock: select() to /dev/rtc0 to wait for clock tick timed out Fixes: 795cda8338ea ("rtc: interface: Fix long-standing race when setting alarm") Signed-off-by: Anthony Pighin (Nokia) Reviewed-by: Esben Haabendal Tested-by: Nick Bowler Link: https://patch.msgid.link/BN0PR08MB6951415A751F236375A2945683D1A@BN0PR08MB6951.namprd08.prod.outlook.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit e1105da952143a212e13e5d8a2e11be974525c47 Author: Thomas Richter Date: Mon Feb 9 16:32:56 2026 +0100 perf test: Fix test case perftool-testsuite_report for s390 [ Upstream commit 3d012b8614ee020666f3dd15af9f65dc487e3f5f ] Test case perftool-testsuite_report fails on s390 for some time now. Root cause is a time out which is too tight for large s390 machines. The time out value addr2line_timeout_ms is per default set to 1 second. This is the maximum time the function read_addr2line_record() waits for a reply from the forked off tool addr2line, which is started as a child in interactive mode. It reads stdin (an address in hexadecimal) and replies on stdout with function name, file name and line number. This might take more than one second. However one second is not always enough and the reply from addr2line tool is not received. Function read_addr2line_record() fails and emits a warning, which is not expected by the test case. It fails. Output before: # perf test -F 133 -- [ PASS ] -- perf_report :: setup :: prepare the perf.data file ================== [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.087 MB \ /tmp/perftool-testsuite_report.FHz/perf_report/perf.data.1 \ (207 samples) ] ================== -- [ PASS ] -- perf_report :: setup :: prepare the perf.data.1 file ## [ PASS ] ## perf_report :: setup SUMMARY -- [ SKIP ] -- perf_report :: test_basic :: help message :: testcase skipped Line did not match any pattern: "cmd__addr2line /usr/lib/debug/lib/modules/ 6.19.0-20260205.rc8.git366.9845cf73f7db.300.fc43.s390x+next/ vmlinux: could not read first record" Line did not match any pattern: "cmd__addr2line /usr/lib/debug/lib/modules/ 6.19.0-20260205.rc8.git366.9845cf73f7db.300.fc43.s390x+next/ vmlinux: could not read first record" -- [ FAIL ] -- perf_report :: test_basic :: basic execution (output regexp parsing) .... 133: perftool-testsuite_report : FAILED! Output after: # ./perf test -F 133 -- [ PASS ] -- perf_report :: setup :: prepare the perf.data file ================== [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.087 MB \ /tmp/perftool-testsuite_report.Mlp/perf_report/perf.data.1 (188 samples) ] ================== -- [ PASS ] -- perf_report :: setup :: prepare the perf.data.1 file ## [ PASS ] ## perf_report :: setup SUMMARY -- [ SKIP ] -- perf_report :: test_basic :: help message :: testcase skipped -- [ PASS ] -- perf_report :: test_basic :: basic execution -- [ PASS ] -- perf_report :: test_basic :: number of samples -- [ PASS ] -- perf_report :: test_basic :: header -- [ PASS ] -- perf_report :: test_basic :: header timestamp -- [ PASS ] -- perf_report :: test_basic :: show CPU utilization -- [ PASS ] -- perf_report :: test_basic :: pid -- [ PASS ] -- perf_report :: test_basic :: non-existing symbol -- [ PASS ] -- perf_report :: test_basic :: symbol filter -- [ PASS ] -- perf_report :: test_basic :: latency header -- [ PASS ] -- perf_report :: test_basic :: default report for latency profile -- [ PASS ] -- perf_report :: test_basic :: latency report for latency profile -- [ PASS ] -- perf_report :: test_basic :: parallelism histogram ## [ PASS ] ## perf_report :: test_basic SUMMARY 133: perftool-testsuite_report : Ok # Fixes: 257046a36750a6db ("perf srcline: Fallback between addr2line implementations") Reviewed-by: Jan Polensky Signed-off-by: Thomas Richter Cc: Alexander Gordeev Cc: Heiko Carstens Cc: Ian Rogers Cc: linux-s390@vger.kernel.org Cc: Namhyung Kim Cc: Sumanth Korikkar Cc: Vasily Gorbik Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 68ab096e361dd023058229094034e709cb8dbb50 Author: Ian Rogers Date: Mon Feb 2 22:09:18 2026 -0800 libperf build: Always place libperf includes first [ Upstream commit 8c5b40678c63be6b85f1c2dc8c8b89d632faf988 ] When building tools/perf the CFLAGS can contain a directory for the installed headers. As the headers may be being installed while building libperf.a this can cause headers to be partially installed and found in the include path while building an object file for libperf.a. The installed header may reference other installed headers that are missing given the partial nature of the install and then the build fails with a missing header file. Avoid this by ensuring the libperf source headers are always first in the CFLAGS. Fixes: 3143504918105156 ("libperf: Make libperf.a part of the perf build") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b0ae7a8272bfc3f7d69bcc4ab7602cfe84fb6e87 Author: Ian Rogers Date: Fri Jan 30 15:35:39 2026 -0800 perf build: Remove NO_LIBCAP that controls nothing [ Upstream commit 169343cc8ff2bd59758760d867bd26adae866a2b ] Using libcap was removed in commit e25ebda78e230283 ("perf cap: Tidy up and improve capability testing") and improve capability testing"), however, some build documentation and a use of the NO_LIBCAP=1 were lingering. Remove these left over bits. Fixes: e25ebda78e230283 ("perf cap: Tidy up and improve capability testing") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7f686fb319e686d1520ee576a07dfa807620d934 Author: Sandipan Das Date: Thu Jan 22 13:39:46 2026 +0530 perf vendor events amd: Fix Zen 5 MAB allocation events [ Upstream commit 76b2cf07a6d2a836108f9c2486d76599f7adf6e8 ] The unit masks for PMCx041 vary across different generations of Zen processors. Fix the Zen 5 events based on PMCx041 as they incorrectly use the same unit masks as that of Zen 4. Fixes: 45c072f2537ab07b ("perf vendor events amd: Add Zen 5 core events") Reported-by: Suyash Mahar Reviewed-by: Ian Rogers Signed-off-by: Sandipan Das Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ananth Narayan Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Sandipan Das Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 13458b3b3df7a6cef8ff2ebc1f5d63fc4e81c07c Author: Arnaldo Carvalho de Melo Date: Mon Jan 26 17:25:00 2026 -0300 perf annotate: Fix BUILD_NONDISTRO=1 missing args->ms conversions to pointer [ Upstream commit dda5f926a1006c735b00ed5c27291fce64236656 ] Fix a few missing conversions to pointer in the usage of 'struct annotate_args' 'ms' member in symbol__disassemble_bpf_libbfd(). Fixes: 00419892bac28bf1 ("perf annotate: Fix args leak of map_symbol") Reviewed-by: Ian Rogers Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 8943b2c49bd8c386e9f6ff01559bf461d2890421 Author: Leo Yan Date: Thu Jan 8 09:43:24 2026 +0000 tools headers: Go back to include asm-generic/unistd.h for arm64 [ Upstream commit 096b86ce08332fbcb0ec6ff6714c44899ec03970 ] The header unistd.h is included under Arm64's uAPI folder (see tools/arch/arm64/include/uapi/asm/), but it does not include its dependent header unistd_64.h. The intention is for unistd_64.h to be generated dynamically using scripts/Makefile.asm-headers. However, this dynamic approach causes problems because the header is not available early enough, even though it is widely included throughout tools. Using the perf build as an example: 1) Feature detection: Perf first runs feature tests. The BPF feature program test-bpf.c includes unistd.h. Since unistd_64.h has not been generated yet, the program fails to build, and the BPF feature ends up being disabled. 2) libperf build: The libperf Makefile later generates unistd_64.h on the fly, so libperf itself builds successfully. 3) Final perf build: Although the perf binary can build successfully using the generated header, we never get a chance to build BPF skeleton programs, because BPF support was already disabled earlier. Restore to include asm-generic/unistd.h for fixing the issue. This aligns with most architectures (x86 is a special case that keeps unistd_32.h/unistd_64.h for its particular syscall numbers) and ensures the header is available from the start. Fixes: 22f72088ffe69a37 ("tools headers: Update the syscall table with the kernel sources") Reviewed-by: James Clark Signed-off-by: Leo Yan Cc: Adrian Hunter Cc: Arnd Bergmann Cc: Ian Rogers Cc: Jiri Olsa Cc: Namhyung Kim Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 0abe77dcaca79cefd5bd3f124e16520d37184b61 Author: Suchit Karunakaran Date: Thu Jan 22 22:47:04 2026 +0530 perf annotate: Fix memcpy size in arch__grow_instructions() [ Upstream commit f0d98c78f8bf73ce2a9b7793f66cda240fa9ab10 ] The memcpy() in arch__grow_instructions() is copying the wrong number of bytes when growing from a non-allocated table. It should copy arch->nr_instructions * sizeof(struct ins) bytes, not just arch->nr_instructions bytes. This bug causes data corruption as only a partial copy of the instruction table is made, leading to garbage data in most entries and potential crashes Fixes: 2a1ff812c40be982 ("perf annotate: Introduce alternative method of keeping instructions table") Reviewed-by: Ian Rogers Signed-off-by: Suchit Karunakaran Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 59a7c3c9c3128a4e2d8c85185a4c8ea4ff5c1300 Author: Ian Rogers Date: Thu Jan 22 09:53:37 2026 -0800 perf tests sched: Avoid error in cleanup on loaded machines [ Upstream commit c5e47e4d00fbc15f2390bb6ed8d9c21836363291 ] The stop_noploops function will kill the noploop processes that are running for 10 seconds. On a loaded machine they may have already terminated meaning the kill will return an error of no such process. This doesn't matter and so ignore the error to avoid the test terminating in the cleanup. Fixes: 0e22c5ca44e68798 ("perf test: Add sched latency and script shell tests") Signed-off-by: Ian Rogers Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ddbf249d9923eecf324b9a4fcbbd210ac491fc28 Author: Ian Rogers Date: Thu Jan 22 13:35:07 2026 -0800 perf maps: Fix reference count leak in maps__find_ams() [ Upstream commit 6fdd2676db55b503c52dd3f1359b5c57f774ab75 ] ams and so ams->ms.map is an in argument, however, it is also overwritten. As a map is reference counted, ensure a map__put() is done before overwriting it. Fixes: 42fd623b58dbcc48 ("perf maps: Get map before returning in maps__find") Reviewed-by: James Clark Signed-off-by: Ian Rogers Cc: Aditya Bodkhe Cc: Adrian Hunter Cc: Albert Ou Cc: Alexander Shishkin Cc: Alexandre Ghiti Cc: Athira Rajeev Cc: Bill Wendling Cc: Dr. David Alan Gilbert Cc: Guo Ren Cc: Howard Chu Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: John Garry Cc: Julia Lawall Cc: Justin Stitt Cc: Krzysztof Łopatowski Cc: Leo Yan Cc: Namhyung Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Peter Zijlstra Cc: Sergei Trofimovich Cc: Shimin Guo Cc: Suchit Karunakaran Cc: Thomas Falcon Cc: Tianyou Li Cc: Will Deacon Cc: Zecheng Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 77c08fedf3f46243b8277ec30f8d7b56004b7dfb Author: Ian Rogers Date: Thu Jan 22 13:35:06 2026 -0800 perf annotate: Fix args leak of map_symbol [ Upstream commit 00419892bac28bf148450d762bbff990a6bd5494 ] map_symbol__exit() needs calling on an annotate_args.ms, however, rather than introduce proper reference count handling to symbol__annotate() just switch to passing the map_symbol pointer parameter around, making the puts the caller's responsibility. Fix a number of cases to ensure the map in a map_symbol has a reference count increment and add the then necessary map_symbol_exits. Fixes: 56e144fe98260a0f ("perf mem_info: Add and use map_symbol__exit and addr_map_symbol__exit") Reviewed-by: James Clark Signed-off-by: Ian Rogers Cc: Aditya Bodkhe Cc: Adrian Hunter Cc: Albert Ou Cc: Alexander Shishkin Cc: Alexandre Ghiti Cc: Athira Rajeev Cc: Bill Wendling Cc: Dr. David Alan Gilbert Cc: Guo Ren Cc: Howard Chu Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: John Garry Cc: Julia Lawall Cc: Justin Stitt Cc: Krzysztof Łopatowski Cc: Leo Yan Cc: linux-arm-kernel@lists.infradead.org Cc: linux-csky@vger.kernel.org Cc: linux-riscv@lists.infradead.org Cc: Namhyung Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Peter Zijlstra Cc: Sergei Trofimovich Cc: Shimin Guo Cc: Suchit Karunakaran Cc: Thomas Falcon Cc: Tianyou Li Cc: Will Deacon Cc: Zecheng Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit a7819ced00b9b0fbed5186587c2500facf5a2cbf Author: James Clark Date: Mon Jan 19 10:18:35 2026 +0000 perf cs-etm: Fix decoding for sparse CPU maps [ Upstream commit a70493e2bb0878885aa7a8178162550270693eb1 ] The ETM decoder incorrectly assumed that auxtrace queue indices were equivalent to CPU number. This assumption is used for inserting records into the queue, and for fetching queues when given a CPU number. This assumption held when Perf always opened a dummy event on every CPU, even if the user provided a subset of CPUs on the commandline, resulting in the indices aligning. For example: # event : name = cs_etm//u, , id = { 2451, 2452 }, type = 11 (cs_etm), size = 136, config = 0x4010, { sample_period, samp> # event : name = dummy:u, , id = { 2453, 2454, 2455, 2456 }, type = 1 (PERF_TYPE_SOFTWARE), size = 136, config = 0x9 (PER> 0 0 0x200 [0xd0]: PERF_RECORD_ID_INDEX nr: 6 ... id: 2451 idx: 2 cpu: 2 tid: -1 ... id: 2452 idx: 3 cpu: 3 tid: -1 ... id: 2453 idx: 0 cpu: 0 tid: -1 ... id: 2454 idx: 1 cpu: 1 tid: -1 ... id: 2455 idx: 2 cpu: 2 tid: -1 ... id: 2456 idx: 3 cpu: 3 tid: -1 Since commit 811082e4b668 ("perf parse-events: Support user CPUs mixed with threads/processes") the dummy event no longer behaves in this way, making the ETM event indices start from 0 on the first CPU recorded regardless of its ID: # event : name = cs_etm//u, , id = { 771, 772 }, type = 11 (cs_etm), size = 144, config = 0x4010, { sample_period, sample> # event : name = dummy:u, , id = { 773, 774 }, type = 1 (PERF_TYPE_SOFTWARE), size = 144, config = 0x9 (PERF_COUNT_SW_DUM> 0 0 0x200 [0x90]: PERF_RECORD_ID_INDEX nr: 4 ... id: 771 idx: 0 cpu: 2 tid: -1 ... id: 772 idx: 1 cpu: 3 tid: -1 ... id: 773 idx: 0 cpu: 2 tid: -1 ... id: 774 idx: 1 cpu: 3 tid: -1 This causes the following segfault when decoding: $ perf record -e cs_etm//u -C 2,3 -- true $ perf report perf: Segmentation fault -------- backtrace -------- #0 0xaaaabf9fd020 in ui__signal_backtrace setup.c:110 #1 0xffffab5c7930 in __kernel_rt_sigreturn [vdso][930] #2 0xaaaabfb68d30 in cs_etm_decoder__reset cs-etm-decoder.c:85 #3 0xaaaabfb65930 in cs_etm__get_data_block cs-etm.c:2032 #4 0xaaaabfb666fc in cs_etm__run_per_cpu_timeless_decoder cs-etm.c:2551 #5 0xaaaabfb6692c in (cs_etm__process_timeless_queues cs-etm.c:2612 #6 0xaaaabfb63390 in cs_etm__flush_events cs-etm.c:921 #7 0xaaaabfb324c0 in auxtrace__flush_events auxtrace.c:2915 #8 0xaaaabfaac378 in __perf_session__process_events session.c:2285 #9 0xaaaabfaacc9c in perf_session__process_events session.c:2442 #10 0xaaaabf8d3d90 in __cmd_report builtin-report.c:1085 #11 0xaaaabf8d6944 in cmd_report builtin-report.c:1866 #12 0xaaaabf95ebfc in run_builtin perf.c:351 #13 0xaaaabf95eeb0 in handle_internal_command perf.c:404 #14 0xaaaabf95f068 in run_argv perf.c:451 #15 0xaaaabf95f390 in main perf.c:558 #16 0xffffaab97400 in __libc_start_call_main libc_start_call_main.h:74 #17 0xffffaab974d8 in __libc_start_main@@GLIBC_2.34 libc-start.c:128 #18 0xaaaabf8aa8f0 in _start perf[7a8f0] Fix it by inserting into the queues based on CPU number, rather than using the index. Fixes: 811082e4b668db96 ("perf parse-events: Support user CPUs mixed with threads/processes") Signed-off-by: James Clark Tested-by: Leo Yan Cc: Adrian Hunter Cc: Alexander Shishkin Cc: coresight@lists.linaro.org Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: John Garry Cc: Mark Rutland Cc: Mike Leach Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Suzuki Poulouse Cc: Thomas Falcon Cc: Will Deacon Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 8d0cf138d1831378bc3c40e3b6e28625ba79b1e4 Author: Namhyung Kim Date: Tue Jan 13 15:37:57 2026 -0800 perf tools: Get debug info of DSO properly [ Upstream commit 069e603d8248dac98b1ef2909e2f1c4169b9da11 ] The dso__debuginfo() just used the path name to open the file but it may be outdated. It should check build-ID and use the file in the build-ID cache if available rather than just using the path name. Let's factor out dso__get_filename() to avoid code duplicate. Fixes: 53a61a6ca279165d ("perf annotate: Add dso__debuginfo() helper") Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Cc: Adrian Hunter Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 82b1f2b0e7abf7ca78844425cb64652447ce2363 Author: Ian Rogers Date: Fri Jan 16 21:28:27 2026 -0800 perf symbol-elf: Fix leak of ELF files with GNU debugdata [ Upstream commit 92d65d9c31621befe0a5f7c0bd43bd217613c6b6 ] The processing of DSO_BINARY_TYPE__GNU_DEBUGDATA in symsrc__init happens with an open ELF file but the error path only closes the associate fd. Fix the goto so that the ELF file is also ended and memory released. Fixes: b10f74308e130527 ("perf symbol: Support .gnu_debugdata for symbols") Signed-off-by: Ian Rogers Cc: Aditya Bodkhe Cc: Adrian Hunter Cc: Albert Ou Cc: Alexandre Ghiti Cc: Andi Kleen Cc: Athira Rajeev Cc: Chun-Tse Shao Cc: Dmitriy Vyukov Cc: Dr. David Alan Gilbert Cc: Guo Ren Cc: Haibo Xu Cc: Howard Chu Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: John Garry Cc: Krzysztof Łopatowski Cc: Leo Yan Cc: Mark Wielaard Cc: Namhyung Kim Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Peter Zijlstra Cc: Sergei Trofimovich Cc: Shimin Guo Cc: Stephen Brennan Cc: Thomas Falcon Cc: Will Deacon Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 055b4bce85bfccc23f6710da71c690bc7a09fc0a Author: Randy Dunlap Date: Wed Jan 7 20:54:32 2026 -0800 rtc: max31335: use correct CONFIG symbol in IS_REACHABLE() [ Upstream commit d5aca9a17f6de884febc56018f92d743b8ea1298 ] IS_REACHABLE() is meant to be used with full symbol names from a kernel .config file, not the shortened symbols used in Kconfig files, so change HWMON to CONFIG_HWMON in 3 places. Fixes: dedaf03b99d6 ("rtc: max31335: add driver support") Signed-off-by: Randy Dunlap Acked-by: Nuno Sá Link: https://patch.msgid.link/20260108045432.2705691-1-rdunlap@infradead.org Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 46a2044778937a0378701f03002473d1ade248de Author: Sri Jayaramappa Date: Tue Dec 2 16:36:32 2025 -0500 libsubcmd: Fix null intersection case in exclude_cmds() [ Upstream commit b6ee9b6e206b288921c14c906eebf4b32fe0c0d8 ] When there is no exclusion occurring from the cmds list - for example - cmds contains ["read-vdso32"] and excludes contains ["archive"] - the main loop completes with ci == cj == 0. In the original code the loop processing the remaining elements in the list was conditional: if (ci != cj) { ...} So we end up in the assertion loop since ci < cmds->cnt and we incorrectly try to assert the list elements to be NULL and fail with the following error help.c:104: exclude_cmds: Assertion `cmds->names[ci] == NULL' failed. Fix this by moving the if (ci != cj) check inside of a broader loop. If ci != cj, left shift the list elements, as before, and then unconditionally advance the ci and cj indicies which also covers the ci == cj case. Fixes: 1fdf938168c4d26f ("perf tools: Fix use-after-free in help_unknown_cmd()") Reviewed-by: Guilherme Amadio Signed-off-by: Sri Jayaramappa Tested-by: Guilherme Amadio Tested-by: Ian Rogers Cc: Joshua Hunt Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20251202213632.2873731-1-sjayaram@akamai.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 68a9c15032e8fee1e8bc22df72b79bfbb0fbcc50 Author: Ian Rogers Date: Sat Jan 10 20:13:36 2026 -0800 perf callchain: Fix srcline printing with inlines [ Upstream commit abec464767b5d26f0612250d511c18f420826ca1 ] sample__fprintf_callchain() was using map__fprintf_srcline() which won't report inline line numbers. Fix by using the srcline from the callchain and falling back to the map variant. Fixes: 25da4fab5f66e659 ("perf evsel: Move fprintf methods to separate source file") Reviewed-by: James Clark Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Howard Chu Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephen Brennan Cc: Tony Jones Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 27c53054d593c716b2516f61dd4b185d7977cab2 Author: Ian Rogers Date: Sat Jan 10 20:13:32 2026 -0800 perf unwind-libdw: Fix invalid reference counts [ Upstream commit f815fc0c66e777c727689666cfb46b8d461c2f99 ] The addition of addr_location__exit() causes use-after put on the maps and map references in the unwind info. Add the gets and then add the map_symbol__exit() calls. Fixes: 0dd5041c9a0eaf8c ("perf addr_location: Add init/exit/copy functions") Reviewed-by: James Clark Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Howard Chu Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephen Brennan Cc: Tony Jones Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 62f730d55aac33ef2d3e8e38c21be1c20eb29224 Author: Nicolas Schier Date: Thu Jan 8 12:29:10 2026 +0100 perf build: Raise minimum shellcheck version to 0.7.2 [ Upstream commit 383f8e26e2c483e25453f8c3d0839877708ac701 ] Raise the minimum shellcheck version for perf builds to 0.7.2, so that systems with shellcheck versions below 0.7.2 will automatically skip the shell script checking, even if NO_SHELLCHECK is unset. Since commit 241f21be7d0fdf3c ("perf test perftool_testsuite: Use absolute paths"), shellcheck versions before 0.7.2 break the perf build with several SC1090 [2] warnings due to its too strict dynamic source handling [1], e.g.: In tests/shell/base_probe/test_line_semantics.sh line 20: . "$DIR_PATH/../common/init.sh" ^---------------------------^ SC1090: Can't follow non-constant source. Use a directive to specify location. Fixes: 241f21be7d0fdf3c ("perf test perftool_testsuite: Use absolute paths") Signed-off-by: Nicolas Schier Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: Jakub Brnak Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Michael Petlan Cc: Nicolas Schier Cc: Peter Zijlstra Cc: Philipp Hahn Cc: Veronika Molnarova Link: https://github.com/koalaman/shellcheck/issues/1998 # [1] Link: https://www.shellcheck.net/wiki/SC1090 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 3b14096e0c9f59906589c6e8f7dbcd9594bbdf67 Author: Thomas Richter Date: Wed Jan 7 14:32:16 2026 +0100 perf test stat tests: Fix for virtualized machines [ Upstream commit e272628902c1c96731e2d9f62a7fc77767686eb0 ] On s390 'perf test's 'perf stat tests', subtest test_hybrid fails for z/VM systems. The root cause is this statement: $(perf stat -a -- sleep 0.1 2>&1 |\ grep -E "/cpu-cycles/[uH]*| cpu-cycles[:uH]* -c) The 'perf stat' output on a s390 z/VM system is # perf stat -a -- sleep 0.1 2>&1 Performance counter stats for 'system wide': 56 context-switches # 46.3 cs/sec cs_per_second 1,210.41 msec cpu-clock # 11.9 CPUs CPUs_utilized 12 cpu-migrations # 9.9 migrations/sec ... 81 page-faults # 66.9 faults/sec ... 0.100891009 seconds time elapsed The grep command does not match any single line and exits with error code 1. As the bash script is executed with 'set -e', it aborts with the first error code being non-zero. Fix this and use 'wc -l' to count matching lines instead of 'grep ... -c'. Output before: # perf test 102 102: perf stat tests : FAILED! # Output after: # perf test 102 102: perf stat tests : Ok # Fixes: bb6e7cb11d97ce19 ("perf tools: Add fallback for exclude_guest") Reviewed-by: Ian Rogers Reviewed-by: James Clark Signed-off-by: Thomas Richter Cc: Alexander Gordeev Cc: Heiko Carstens Cc: Jan Polensky Cc: linux-s390@vger.kernel.org Cc: Namhyung Kim Cc: Sumanth Korikkar Cc: Vasily Gorbik Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b7621a279de3d3db5304ea75ebe85963eb0783a9 Author: Ian Rogers Date: Tue Nov 11 13:22:04 2025 -0800 perf test stat: Update test expectations and events [ Upstream commit a48cd551d7436be3b1bd65c63a6d00163f7e7706 ] test_stat_record_report and test_stat_record_script used default output which triggers a bug when sending metrics. As this isn't relevant to the test switch to using named software events. Update the match in test_hybrid as the cycles event is now cpu-cycles to workaround potential ARM issues. Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Stable-dep-of: e272628902c1 ("perf test stat tests: Fix for virtualized machines") Signed-off-by: Sasha Levin commit da178b6387238bc4dde70fc6a549c813b47e7418 Author: Alexandre Frade Date: Sat Feb 28 17:54:42 2026 +0000 Linux 6.18.15-xanmod1 Signed-off-by: Alexandre Frade commit c346740d2878998fe5e3acc693cbc9a4de4499ba Merge: 10328d796c54 df0dc1b06fb6 Author: Alexandre Frade Date: Sat Feb 28 17:52:43 2026 +0000 Merge tag 'v6.18.15' into 6.18 This is the 6.18.15 stable release commit df0dc1b06fb6b6461f9838694bf84079eca7562a Author: Greg Kroah-Hartman Date: Fri Feb 27 16:05:10 2026 -0500 Linux 6.18.15 Signed-off-by: Greg Kroah-Hartman commit c1f305ac054f2358cf8fa086d15293a680900b7f Author: Pablo Neira Ayuso Date: Wed Jan 21 01:08:44 2026 +0100 netfilter: nf_tables: add .abort_skip_removal flag for set types commit f175b46d9134f708358b5404730c6dfa200fbf3c upstream. The pipapo set backend is the only user of the .abort interface so far. To speed up pipapo abort path, removals are skipped. The follow up patch updates the rbtree to use to build an array of ordered elements, then use binary search. This needs a new .abort interface but, unlike pipapo, it also need to undo/remove elements. Add a flag and use it from the pipapo set backend. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Cc: "Kris Karas (Bug Reporting)" Cc: Genes Lists Cc: Philip Müller Signed-off-by: Greg Kroah-Hartman commit 10328d796c549e06674ae8ad42a55c6be90cccaf Author: Alexandre Frade Date: Fri Feb 27 12:52:29 2026 +0000 Linux 6.18.14-xanmod1 Signed-off-by: Alexandre Frade commit b08c1bc8e691a2d215a433eb2be4cfaa7af1e716 Author: Alexandre Frade Date: Fri Feb 27 12:49:29 2026 +0000 XANMOD: .gitlab-ci: Add x64v1 build job Signed-off-by: Alexandre Frade commit 4f4158992d8c335f5c9691a92175cabdde577320 Author: Oleksandr Natalenko Date: Mon Oct 13 08:33:45 2025 +0200 tcp_bbr: v3: update TCP 'bbr' congestion control module to BBRv3 [v6.18.14+] Original patchset Link: https://github.com/google/bbr/tree/v3 Signed-off-by: Oleksandr Natalenko Signed-off-by: Alexandre Frade commit 445c11863e41eef337df3b9e438eafa5eb3b0c9e Merge: 69f71f819654 2ad6657a787f Author: Alexandre Frade Date: Fri Feb 27 12:43:57 2026 +0000 Merge tag 'v6.18.14' into 6.18 This is the 6.18.14 stable release commit 69f71f819654109490e177dae831d60b7b607139 Author: Alexandre Frade Date: Fri Feb 27 12:41:15 2026 +0000 Revert "tcp_bbr: v3: update TCP 'bbr' congestion control module to BBRv3" This reverts commit eb57a72edc8f2b2a40d81d7b0f63eeef8ecdccc3. commit 2ad6657a787fe8caf39b6d050e0238650e2d81fe Author: Greg Kroah-Hartman Date: Thu Feb 26 14:59:47 2026 -0800 Linux 6.18.14 Link: https://lore.kernel.org/r/20260225012348.915798704@linuxfoundation.org Tested-by: Shung-Hsi Yu Tested-by: Salvatore Bonaccorso Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Jeffrin Jose T Link: https://lore.kernel.org/r/20260225151847.709818960@linuxfoundation.org Tested-by: Peter Schneider Tested-by: Jeffrin Jose T Tested-by: Brett A C Sheffield Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Luna Jernberg Tested-by: Justin M. Forbes Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit bcf08144a20af5c52b52ed149cfcb02d1a2b88e8 Author: Damien Le Moal Date: Fri Feb 20 12:09:12 2026 +0900 ata: libata-core: fix cancellation of a port deferred qc work commit 55db009926634b20955bd8abbee921adbc8d2cb4 upstream. cancel_work_sync() is a sleeping function so it cannot be called with the spin lock of a port being held. Move the call to this function in ata_port_detach() after EH completes, with the port lock released, together with other work cancellation calls. Fixes: 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") Signed-off-by: Damien Le Moal Reviewed-by: Hannes Reinecke Reviewed-by: Igor Pylypiv Signed-off-by: Greg Kroah-Hartman commit 33abac5b5a5303ba2c66d89e063a806033be07fc Author: Damien Le Moal Date: Fri Feb 20 13:43:00 2026 +0900 ata: libata-eh: correctly handle deferred qc timeouts commit eddb98ad9364b4e778768785d46cfab04ce52100 upstream. A deferred qc may timeout while waiting for the device queue to drain to be submitted. In such case, since the qc is not active, ata_scsi_cmd_error_handler() ends up calling scsi_eh_finish_cmd(), which frees the qc. But as the port deferred_qc field still references this finished/freed qc, the deferred qc work may eventually attempt to call ata_qc_issue() against this invalid qc, leading to errors such as reported by UBSAN (syzbot run): UBSAN: shift-out-of-bounds in drivers/ata/libata-core.c:5166:24 shift exponent 4210818301 is too large for 64-bit type 'long long unsigned int' ... Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x279/0x2a0 lib/ubsan.c:494 ata_qc_issue.cold+0x38/0x9f drivers/ata/libata-core.c:5166 ata_scsi_deferred_qc_work+0x154/0x1f0 drivers/ata/libata-scsi.c:1679 process_one_work+0x9d7/0x1920 kernel/workqueue.c:3275 process_scheduled_works kernel/workqueue.c:3358 [inline] worker_thread+0x5da/0xe40 kernel/workqueue.c:3439 kthread+0x370/0x450 kernel/kthread.c:467 ret_from_fork+0x754/0xd80 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fix this by checking if the qc of a timed out SCSI command is a deferred one, and in such case, clear the port deferred_qc field and finish the SCSI command with DID_TIME_OUT. Reported-by: syzbot+1f77b8ca15336fff21ff@syzkaller.appspotmail.com Fixes: 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") Signed-off-by: Damien Le Moal Reviewed-by: Hannes Reinecke Reviewed-by: Igor Pylypiv Signed-off-by: Greg Kroah-Hartman commit a488528a7182b62d55b0c9a67358f04d089500e0 Author: Ivan Lipski Date: Tue Jan 13 17:29:59 2026 -0500 drm/amd/display: Add an hdmi_hpd_debounce_delay_ms module commit 6a681cd9034587fe3550868bacfbd639d1c6891f upstream. [Why&How] Right now, the HDMI HPD filter is enabled by default at 1500ms. We want to disable it by default, as most modern displays with HDMI do not require it for DPMS mode. The HPD can instead be enabled as a driver parameter with a custom delay value in ms (up to 5000ms). Fixes: c918e75e1ed9 ("drm/amd/display: Add an HPD filter for HDMI") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4859 Signed-off-by: Ivan Lipski Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit a86c53332a81f37c6964f071be7b18e5bbff9a6b Author: Huacai Chen Date: Tue Feb 3 14:29:01 2026 +0800 net: stmmac: dwmac-loongson: Set clk_csr_i to 100-150MHz commit e1aa5ef892fb4fa9014a25e87b64b97347919d37 upstream. Current clk_csr_i setting of Loongson STMMAC (including LS7A1000/2000 and LS2K1000/2000/3000) are copy & paste from other drivers. In fact, Loongson STMMAC use 125MHz clocks and need 62 freq division to within 2.5MHz, meeting most PHY MDC requirement. So fix by setting clk_csr_i to 100-150MHz, otherwise some PHYs may link fail. Cc: stable@vger.kernel.org Fixes: 30bba69d7db40e7 ("stmmac: pci: Add dwmac support for Loongson") Signed-off-by: Hongliang Wang Signed-off-by: Huacai Chen Link: https://patch.msgid.link/20260203062901.2158236-1-chenhuacai@loongson.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ff763ac9771303310484d7b6c31575610b24715d Author: Ivan Lipski Date: Fri Jan 16 10:03:54 2026 -0500 drm/amd/display: Clear HDMI HPD pending work only if it is enabled commit 17b2c526fd8026d8e0f4c0e7f94fc517e3901589 upstream. [Why&How] On amdgpu_dm_connector_destroy(), the driver attempts to cancel pending HDMI HPD work without checking if the HDMI HPD is enabled. Added a check that it is enabled before clearing it. Fixes: 6a681cd90345 ("drm/amd/display: Add an hdmi_hpd_debounce_delay_ms module") Signed-off-by: Ivan Lipski Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 5566ebcf41ae1b4bf67f857f8c46f4c413d97ad0 Author: Martin KaFai Lau Date: Wed Nov 12 15:23:31 2025 -0800 selftests/bpf: Test bpf_skb_check_mtu(BPF_MTU_CHK_SEGS) when transport_header is not set commit 6cc73f35406cae1f053e984e8de40e6dc9681446 upstream. Add a test to check that bpf_skb_check_mtu(BPF_MTU_CHK_SEGS) is rejected (-EINVAL) if skb->transport_header is not set. The test needs to lower the MTU of the loopback device. Thus, take this opportunity to run the test in a netns by adding "ns_" to the test name. The "serial_" prefix can then be removed. Signed-off-by: Martin KaFai Lau Link: https://lore.kernel.org/r/20251112232331.1566074-2-martin.lau@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 73c2a1255f0fd318644c9d8022c7c023a2de1a36 Author: Joanne Koong Date: Thu Dec 4 13:51:14 2025 -0800 io_uring/rsrc: clean up buffer cloning arg validation commit b8201b50e403815f941d1c6581a27fdbfe7d0fd4 upstream. Get rid of some redundant checks and move the src arg validation to before the buffer table allocation, which simplifies error handling. Signed-off-by: Joanne Koong Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b20266f1880b100a0479a0e4b4f987542b8175f8 Author: Jan Kiszka Date: Mon Feb 16 17:24:56 2026 +0100 Drivers: hv: vmbus: Use kthread for vmbus interrupts on PREEMPT_RT commit f8e6343b7a89c7c649db5a9e309ba7aa20401813 upstream. Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V with related guest support enabled: [ 1.127941] hv_vmbus: registering driver hyperv_drm [ 1.132518] ============================= [ 1.132519] [ BUG: Invalid wait context ] [ 1.132521] 6.19.0-rc8+ #9 Not tainted [ 1.132524] ----------------------------- [ 1.132525] swapper/0/0 is trying to lock: [ 1.132526] ffff8b9381bb3c90 (&channel->sched_lock){....}-{3:3}, at: vmbus_chan_sched+0xc4/0x2b0 [ 1.132543] other info that might help us debug this: [ 1.132544] context-{2:2} [ 1.132545] 1 lock held by swapper/0/0: [ 1.132547] #0: ffffffffa010c4c0 (rcu_read_lock){....}-{1:3}, at: vmbus_chan_sched+0x31/0x2b0 [ 1.132557] stack backtrace: [ 1.132560] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-rc8+ #9 PREEMPT_{RT,(lazy)} [ 1.132565] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/25/2025 [ 1.132567] Call Trace: [ 1.132570] [ 1.132573] dump_stack_lvl+0x6e/0xa0 [ 1.132581] __lock_acquire+0xee0/0x21b0 [ 1.132592] lock_acquire+0xd5/0x2d0 [ 1.132598] ? vmbus_chan_sched+0xc4/0x2b0 [ 1.132606] ? lock_acquire+0xd5/0x2d0 [ 1.132613] ? vmbus_chan_sched+0x31/0x2b0 [ 1.132619] rt_spin_lock+0x3f/0x1f0 [ 1.132623] ? vmbus_chan_sched+0xc4/0x2b0 [ 1.132629] ? vmbus_chan_sched+0x31/0x2b0 [ 1.132634] vmbus_chan_sched+0xc4/0x2b0 [ 1.132641] vmbus_isr+0x2c/0x150 [ 1.132648] __sysvec_hyperv_callback+0x5f/0xa0 [ 1.132654] sysvec_hyperv_callback+0x88/0xb0 [ 1.132658] [ 1.132659] [ 1.132660] asm_sysvec_hyperv_callback+0x1a/0x20 As code paths that handle vmbus IRQs use sleepy locks under PREEMPT_RT, the vmbus_isr execution needs to be moved into thread context. Open- coding this allows to skip the IPI that irq_work would additionally bring and which we do not need, being an IRQ, never an NMI. This affects both x86 and arm64, therefore hook into the common driver logic. Signed-off-by: Jan Kiszka Reviewed-by: Florian Bezdeka Tested-by: Florian Bezdeka Reviewed-by: Michael Kelley Tested-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit 4949e32387fe315b59ad5f422c9fc52836fbdd1e Author: Jeongjun Park Date: Mon Jan 19 17:25:52 2026 +0900 drm/exynos: vidi: fix to avoid directly dereferencing user pointer commit d4c98c077c7fb2dfdece7d605e694b5ea2665085 upstream. In vidi_connection_ioctl(), vidi->edid(user pointer) is directly dereferenced in the kernel. This allows arbitrary kernel memory access from the user space, so instead of directly accessing the user pointer in the kernel, we should modify it to copy edid to kernel memory using copy_from_user() and use it. Cc: Signed-off-by: Jeongjun Park Signed-off-by: Inki Dae Signed-off-by: Greg Kroah-Hartman commit b5fc86d753dd4c281a943b92f0eef02d31af03d7 Author: Jeongjun Park Date: Mon Jan 19 17:25:51 2026 +0900 drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl() commit d3968a0d85b211e197f2f4f06268a7031079e0d0 upstream. vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to obtain a struct vidi_context pointer. However, drm_dev->dev is the exynos-drm master device, and the driver_data contained therein is not the vidi component device, but a completely different device. This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more. To resolve this issue, we need to store/delete the vidi device pointer in exynos_drm_private->vidi_dev during bind/unbind, and then read this exynos_drm_private->vidi_dev within ioctl() to obtain the correct struct vidi_context pointer. Cc: Signed-off-by: Jeongjun Park Signed-off-by: Inki Dae Signed-off-by: Greg Kroah-Hartman commit 5c8e29b5208b823c8d5730e7a7aff0218593666c Author: Lewis Mason Date: Tue Feb 10 23:13:37 2026 +0000 ALSA: hda/realtek: Add quirk for Samsung Galaxy Book3 Pro 360 (NP965QFG) commit 3a6b7dc431aab90744e973254604855e654294ae upstream. The Samsung Galaxy Book3 Pro 360 NP965QFG (subsystem ID 0x144d:0xc1cb) uses the same Realtek ALC298 codec and amplifier configuration as the NP960QFG (0x144d:0xc1ca). Apply the same ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS fixup to enable the internal speakers. Cc: stable@vger.kernel.org Signed-off-by: Lewis Mason Link: https://patch.msgid.link/20260210231337.7265-1-lewis@ocuru.co.uk Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 356a6afadb44a490de26758e303925dd8a388fb9 Author: Takashi Iwai Date: Tue Feb 17 11:44:11 2026 +0100 ALSA: hda/conexant: Fix headphone jack handling on Acer Swift SF314 commit 7bc0df86c2384bc1e2012a2c946f82305054da64 upstream. Acer Swift SF314 (SSID 1025:136d) needs a bit of tweaks of the pin configurations for NID 0x16 and 0x19 to make the headphone / headset jack working. NID 0x17 can remain as is for the working speaker, and the built-in mic is supported via SOF. Cc: Link: https://bugzilla.kernel.org/show_bug.cgi?id=221086 Link: https://patch.msgid.link/20260217104414.62911-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6cadda9d1921dc72a408080416cdbf582ca3ccef Author: Eric Naim Date: Tue Feb 10 17:34:02 2026 +0800 ALSA: hda/realtek: Add quirk for Gigabyte G5 KF5 (2023) commit 405d59fdd2038a65790eaad8c1013d37a2af6561 upstream. Fixes microphone detection when a headset is connected to the audio jack using the ALC256. Cc: stable@vger.kernel.org Signed-off-by: Eric Naim Link: https://patch.msgid.link/20260210093403.21514-1-dnaim@cachyos.org Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 84dbf4feaa937a71d53f894e0a950c7af4176f44 Author: Shengjiu Wang Date: Thu Feb 12 10:18:29 2026 +0800 ASoC: dt-bindings: asahi-kasei,ak5558: Fix the supply names commit 80ca113671a005430207d351cb403c1637106212 upstream. In the original txt format binding document ak4458.txt, the supply names are 'AVDD-supply', 'DVDD-supply', and they are also used in driver. But in the commit converting to yaml format, they are changed to 'avdd-supply', 'dvdd-supply'. After search all the dts file, these names 'AVDD-supply', 'DVDD-supply', 'avdd-supply', 'dvdd-supply' are not used in any dts file. So it is safe to fix the yaml binding document. Fixes: 829d78e3ea32 ("ASoC: dt-bindings: ak5558: Convert to dtschema") Cc: stable@vger.kernel.org Signed-off-by: Shengjiu Wang Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260212021829.3244736-4-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1c1148cbebad2bef4609515e126dc1322d9d2168 Author: Shengjiu Wang Date: Thu Feb 12 10:18:28 2026 +0800 ASoC: dt-bindings: asahi-kasei,ak4458: Fix the supply names commit e570a5ca307f6d7a6acd080fc219db2ce3c0737b upstream. In the original txt format binding document ak4458.txt, the supply names are 'AVDD-supply', 'DVDD-supply', and they are also used in driver. But in the commit converting to yaml format, they are changed to 'avdd-supply', 'dvdd-supply'. After search all the dts file, these names 'AVDD-supply', 'DVDD-supply', 'avdd-supply', 'dvdd-supply' are not used in any dts file. So it is safe to fix this yaml binding document. Fixes: 009e83b591dd ("ASoC: dt-bindings: ak4458: Convert to dtschema") Cc: stable@vger.kernel.org Signed-off-by: Shengjiu Wang Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260212021829.3244736-3-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8562d921e4eeb8ee4f042533f5de880732b42b74 Author: Shengjiu Wang Date: Thu Feb 12 10:18:27 2026 +0800 ASoC: dt-bindings: asahi-kasei,ak4458: set unevaluatedProperties:false commit 50a634f1d795721ce68583c78ba493f1d7aa8bc2 upstream. When including the dai-common.yaml, and allow '#sound-dai-cells' and "sound-name-prefix' to be used, should use unevaluatedProperties:false according to writing-bindings.rst. Fixes: 8d7de4a014f5 ("ASoC: dt-bindings: asahi-kasei,ak4458: Reference common DAI properties") Cc: stable@vger.kernel.org Signed-off-by: Shengjiu Wang Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260212021829.3244736-2-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a16695e3ac32df044cd1842f072425cac319fca0 Author: Vikram Sharma Date: Fri Nov 7 21:55:20 2025 +0530 dt-bindings: media: qcom,qcs8300-camss: Add missing power supplies commit 555e882051a3a7ecc2bcee2b2047822249dcd074 upstream. Add missing vdda-phy-supply and vdda-pll-supply in the (monaco)qcs8300 camss binding. While enabling imx412 sensor for qcs8300 we see a need to add these supplies which were missing in initial submission. Fixes: 634a2958fae30 ("media: dt-bindings: Add qcom,qcs8300-camss compatible") Cc: stable@vger.kernel.org Co-developed-by: Nihal Kumar Gupta Signed-off-by: Nihal Kumar Gupta Signed-off-by: Vikram Sharma Reviewed-by: Krzysztof Kozlowski Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 05072d352ed1088d5188c00cd38da217aa85a81b Author: Abel Vesa Date: Wed Dec 24 12:53:27 2025 +0200 dt-bindings: phy: qcom-edp: Add missing clock for X Elite commit 6b99eeacf6abb1ff2d6463c84e490343f39cf11a upstream. On X Elite platform, the eDP PHY uses one more clock called ref. The current X Elite devices supported upstream work fine without this clock, because the boot firmware leaves this clock enabled. But we should not rely on that. Also, even though this change breaks the ABI, it is needed in order to make the driver disables this clock along with the other ones, for a proper bring-down of the entire PHY. So attach the this ref clock to the PHY. Cc: stable@vger.kernel.org # v6.10 Fixes: 5d5607861350 ("dt-bindings: phy: qcom-edp: Add X1E80100 PHY compatibles") Reviewed-by: Krzysztof Kozlowski Reviewed-by: Bjorn Andersson Signed-off-by: Abel Vesa Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-missing-refclk-v5-1-3f45d349b5ac@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit c20f925214249bb4fc04f7e197bea142a6438af6 Author: Daniel Hodges Date: Fri Feb 6 15:41:46 2026 -0500 SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path commit dd2fdc3504592d85e549c523b054898a036a6afe upstream. Commit 5940d1cf9f42 ("SUNRPC: Rebalance a kref in auth_gss.c") added a kref_get(&gss_auth->kref) call to balance the gss_put_auth() done in gss_release_msg(), but forgot to add a corresponding kref_put() on the error path when kstrdup_const() fails. If service_name is non-NULL and kstrdup_const() fails, the function jumps to err_put_pipe_version which calls put_pipe_version() and kfree(gss_msg), but never releases the gss_auth reference. This leads to a kref leak where the gss_auth structure is never freed. Add a forward declaration for gss_free_callback() and call kref_put() in the err_put_pipe_version error path to properly release the reference taken earlier. Fixes: 5940d1cf9f42 ("SUNRPC: Rebalance a kref in auth_gss.c") Cc: stable@vger.kernel.org Signed-off-by: Daniel Hodges Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit d79b9097a6a2b91471b40755f1225364be5d85ff Author: Chuck Lever Date: Fri Dec 26 10:15:32 2025 -0500 SUNRPC: auth_gss: fix memory leaks in XDR decoding error paths commit 3e6397b056335cc56ef0e9da36c95946a19f5118 upstream. The gssx_dec_ctx(), gssx_dec_status(), and gssx_dec_name() functions allocate memory via gssx_dec_buffer(), which calls kmemdup(). When a subsequent decode operation fails, these functions return immediately without freeing previously allocated buffers, causing memory leaks. The leak in gssx_dec_ctx() is particularly relevant because the caller (gssp_accept_sec_context_upcall) initializes several buffer length fields to non-zero values, resulting in memory allocation: struct gssx_ctx rctxh = { .exported_context_token.len = GSSX_max_output_handle_sz, .mech.len = GSS_OID_MAX_LEN, .src_name.display_name.len = GSSX_max_princ_sz, .targ_name.display_name.len = GSSX_max_princ_sz }; If, for example, gssx_dec_name() succeeds for src_name but fails for targ_name, the memory allocated for exported_context_token, mech, and src_name.display_name remains unreferenced and cannot be reclaimed. Add error handling with goto-based cleanup to free any previously allocated buffers before returning an error. Reported-by: Xingjing Deng Closes: https://lore.kernel.org/linux-nfs/CAK+ZN9qttsFDu6h1FoqGadXjMx1QXqPMoYQ=6O9RY4SxVTvKng@mail.gmail.com/ Fixes: 1d658336b05f ("SUNRPC: Add RPC based upcall mechanism for RPCGSS auth") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 888cd7e40adb2ef4af1b4d3b6e2e83ad409ae8c2 Author: Damien Le Moal Date: Wed Dec 17 16:40:48 2025 +0900 ata: libata-scsi: avoid Non-NCQ command starvation commit 0ea84089dbf62a92dc7889c79e6b18fc89260808 upstream. When a non-NCQ command is issued while NCQ commands are being executed, ata_scsi_qc_issue() indicates to the SCSI layer that the command issuing should be deferred by returning SCSI_MLQUEUE_XXX_BUSY. This command deferring is correct and as mandated by the ACS specifications since NCQ and non-NCQ commands cannot be mixed. However, in the case of a host adapter using multiple submission queues, when the target device is under a constant load of NCQ commands, there are no guarantees that requeueing the non-NCQ command will be executed later and it may be deferred again repeatedly as other submission queues can constantly issue NCQ commands from different CPUs ahead of the non-NCQ command. This can lead to very long delays for the execution of non-NCQ commands, and even complete starvation for these commands in the worst case scenario. Since the block layer and the SCSI layer do not distinguish between queueable (NCQ) and non queueable (non-NCQ) commands, libata-scsi SAT implementation must ensure forward progress for non-NCQ commands in the presence of NCQ command traffic. This is similar to what SAS HBAs with a hardware/firmware based SAT implementation do. Implement such forward progress guarantee by limiting requeueing of non-NCQ commands from ata_scsi_qc_issue(): when a non-NCQ command is received and NCQ commands are in-flight, do not force a requeue of the non-NCQ command by returning SCSI_MLQUEUE_XXX_BUSY and instead return 0 to indicate that the command was accepted but hold on to the qc using the new deferred_qc field of struct ata_port. This deferred qc will be issued using the work item deferred_qc_work running the function ata_scsi_deferred_qc_work() once all in-flight commands complete, which is checked with the port qc_defer() callback return value indicating that no further delay is necessary. This check is done using the helper function ata_scsi_schedule_deferred_qc() which is called from ata_scsi_qc_complete(). This thus excludes this mechanism from all internal non-NCQ commands issued by ATA EH. When a port deferred_qc is non NULL, that is, the port has a command waiting for the device queue to drain, the issuing of all incoming commands (both NCQ and non-NCQ) is deferred using the regular busy mechanism. This simplifies the code and also avoids potential denial of service problems if a user issues too many non-NCQ commands. Finally, whenever ata EH is scheduled, regardless of the reason, a deferred qc is always requeued so that it can be retried once EH completes. This is done by calling the function ata_scsi_requeue_deferred_qc() from ata_eh_set_pending(). This avoids the need for any special processing for the deferred qc in case of NCQ error, link or device reset, or device timeout. Reported-by: Xingui Yang Reported-by: Igor Pylypiv Fixes: bdb01301f3ea ("scsi: Add host and host template flag 'host_tagset'") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Niklas Cassel Reviewed-by: Martin K. Petersen Reviewed-by: John Garry Tested-by: Igor Pylypiv Tested-by: Xingui Yang Signed-off-by: Greg Kroah-Hartman commit 410336fc82ac9e1a294af56b9ede0e0e0910ba61 Author: Damien Le Moal Date: Wed Dec 17 14:05:25 2025 +0900 ata: libata-scsi: refactor ata_scsi_translate() commit bb3a8154b1a1dc2c86d037482c0a2cf9186829ed upstream. Factor out of ata_scsi_translate() the code handling queued command deferral using the port qc_defer callback and issuing the queued command with ata_qc_issue() into the new function ata_scsi_qc_issue(), and simplify the goto used in ata_scsi_translate(). While at it, also add a lockdep annotation to check that the port lock is held when ata_scsi_translate() is called. No functional changes. Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Niklas Cassel Reviewed-by: Martin K. Petersen Reviewed-by: John Garry Reviewed-by: Igor Pylypiv Signed-off-by: Greg Kroah-Hartman commit 62a16b2e3ce9b7fc92898d957316573e3f847ab7 Author: Linus Walleij Date: Tue Feb 3 11:23:01 2026 +0100 ata: pata_ftide010: Fix some DMA timings commit ff4a46c278ac6a4b3f39be1492a4568b6dcc6105 upstream. The FTIDE010 has been missing some timing settings since its inception, since the upstream OpenWrt patch was missing these. The community has since come up with the appropriate timings. Fixes: be4e456ed3a5 ("ata: Add driver for Faraday Technology FTIDE010") Cc: stable@vger.kernel.org Signed-off-by: Linus Walleij Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 3be216fd6f89e653c6b76a309d07646d2baa1d40 Author: Jan Kara Date: Wed Jan 14 19:28:19 2026 +0100 ext4: use optimized mballoc scanning regardless of inode format commit 3574c322b1d0eb32dbd76b469cb08f9a67641599 upstream. Currently we don't used mballoc optimized scanning (using max free extent order and avg free extent order group lists) for inodes with indirect block based format. This is confusing for users and I don't see a good reason for that. Even with indirect block based inode format we can spend big amount of time searching for free blocks for large filesystems with fragmented free space. To add to the confusion before commit 077d0c2c78df ("ext4: make mb_optimize_scan performance mount option work with extents") optimized scanning was applied *only* to indirect block based inodes so that commit appears as a performance regression to some users. Just use optimized scanning whenever it is enabled by mount options. Reviewed-by: Baokun Li Reviewed-by: Zhang Yi Signed-off-by: Jan Kara Cc: stable@kernel.org Link: https://patch.msgid.link/20260114182836.14120-4-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 34c803edc0b3365a42efcf9815acab63b4cf54e0 Author: Jan Kara Date: Wed Jan 14 19:28:18 2026 +0100 ext4: always allocate blocks only from groups inode can use commit 4865c768b563deff1b6a6384e74a62f143427b42 upstream. For filesystems with more than 2^32 blocks inodes using indirect block based format cannot use blocks beyond the 32-bit limit. ext4_mb_scan_groups_linear() takes care to not select these unsupported groups for such inodes however other functions selecting groups for allocation don't. So far this is harmless because the other selection functions are used only with mb_optimize_scan and this is currently disabled for inodes with indirect blocks however in the following patch we want to enable mb_optimize_scan regardless of inode format. Reviewed-by: Baokun Li Reviewed-by: Zhang Yi Signed-off-by: Jan Kara Acked-by: Pedro Falcato Cc: stable@kernel.org Link: https://patch.msgid.link/20260114182836.14120-3-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 3924aea2c33df3864929c1acd178bfc29d8f005f Author: Brian Foster Date: Tue Jan 13 12:19:05 2026 -0500 ext4: fix dirtyclusters double decrement on fs shutdown commit 94a8cea54cd935c54fa2fba70354757c0fc245e3 upstream. fstests test generic/388 occasionally reproduces a warning in ext4_put_super() associated with the dirty clusters count: WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4] Tracing the failure shows that the warning fires due to an s_dirtyclusters_counter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4_mb_mark_diskspace_used() and the caller ext4_mb_new_blocks(). First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4_handle_dirty_metadata() call(s) made from ext4_mb_mark_context(). The changed value is non-zero at this point, so ext4_mb_mark_diskspace_used() does not exit after the error bubbles up from ext4_mb_mark_context(). Instead, the former decrements both cluster counters and returns the error up to ext4_mb_new_blocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency. To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4_mb_new_blocks() is responsible for acquiring cluster reservation (via ext4_claim_free_clusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure. Fixes: 0087d9fb3f29 ("ext4: Fix s_dirty_blocks_counter if block allocation failed with nodelalloc") Signed-off-by: Brian Foster Reviewed-by: Baokun Li Link: https://patch.msgid.link/20260113171905.118284-1-bfoster@redhat.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 29a07d691d282faf38c33d4b61839b89399110f9 Author: Yongjian Sun Date: Tue Jan 6 17:08:20 2026 +0800 ext4: fix e4b bitmap inconsistency reports commit bdc56a9c46b2a99c12313122b9352b619a2e719e upstream. A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads. Ext4 reported multiple e4b bitmap check failures like: ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks Analysis and experimentation confirmed that the issue is caused by a race condition between page migration and bitmap modification. Although this timing window is extremely narrow, it is still hit in practice: folio_lock ext4_mb_load_buddy __migrate_folio check ref count folio_mc_copy __filemap_get_folio folio_try_get(folio) ...... mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock The root cause of this issue is that the fast path of load_buddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. We observed that the folio migration process acquires the folio lock. Therefore, we can determine whether to take the fast path in load_buddy by checking the lock status. If the folio is locked, we opt for the slow path (which acquires the lock) to close this concurrency window. Additionally, this change addresses the following issues: When the DOUBLE_CHECK macro is enabled to inspect bitmap-related issues, the following error may be triggered: corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc Analysis reveals that this is a false positive. There is a specific race window where the bitmap and the group descriptor become momentarily inconsistent, leading to this error report: ext4_mb_load_buddy ext4_mb_load_buddy __filemap_get_folio(create|lock) folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio(no lock) ...... mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits(e4b->bd_bitmap) folio_unlock The original logic assumed that since mb_cmp_bitmaps is called when the bitmap is newly loaded from disk, the folio lock would be sufficient to prevent concurrent access. However, this overlooks a specific race condition: if another process attempts to load buddy and finds the folio is already in an uptodate state, it will immediately begin using it without holding folio lock. Signed-off-by: Yongjian Sun Reviewed-by: Zhang Yi Reviewed-by: Baokun Li Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260106090820.836242-1-sunyongjian@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 12615ab4bfb69678e5d961b28bb70040299e51b1 Author: Zilin Guan Date: Thu Dec 25 08:48:00 2025 +0000 ext4: fix memory leak in ext4_ext_shift_extents() commit ca81109d4a8f192dc1cbad4a1ee25246363c2833 upstream. In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4_find_extent(), leading to a memory leak. Fix this by jumping to the out label to ensure the path is properly released. Fixes: a18ed359bdddc ("ext4: always check ext4_ext_find_extent result") Signed-off-by: Zilin Guan Reviewed-by: Zhang Yi Reviewed-by: Baokun Li Link: https://patch.msgid.link/20251225084800.905701-1-zilin@seu.edu.cn Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 808f3191498f300174523c54cab101e18795ae4e Author: Zhang Yi Date: Sat Nov 29 18:32:39 2025 +0800 ext4: drop extent cache when splitting extent fails commit 79b592e8f1b435796cbc2722190368e3e8ffd7a1 upstream. When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. So drop all of the remaining potentially stale extents if the splitting fails. Signed-off-by: Zhang Yi Reviewed-by: Baokun Li Cc: stable@kernel.org Reviewed-by: Ojaswin Mujoo Message-ID: <20251129103247.686136-8-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit c2ee51d684adca7645e4aa74adca13f6750390bc Author: Zhang Yi Date: Sat Nov 29 18:32:38 2025 +0800 ext4: drop extent cache after doing PARTIAL_VALID1 zeroout commit 6d882ea3b0931b43530d44149b79fcd4ffc13030 upstream. When splitting an unwritten extent in the middle and converting it to initialized in ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_DATA_VALID2 flags set, it could leave a stale unwritten extent. Assume we have an unwritten file and buffered write in the middle of it without dioread_nolock enabled, it will allocate blocks as written extent. 0 A B N [UUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_PARTIAL_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and leave the entire extent as unwritten. 0 A B N [UUUUUUUUUUUU] on-disk extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDDZZ] Z: zeroed data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and leave an written extent from A to N. 0 A B N [UUWWWWWWWWWW] on-disk extent W: written extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDDZZ] Finally ext4_map_create_blocks() only insert extent A to B to the extent status tree, and leave an stale unwritten extent in the status tree. 0 A B N [UUWWWWWWWWWW] on-disk extent W: written extent [UUWWWWWWWWUU] extent status tree [--DDDDDDDDZZ] Fix this issue by always cached extent status entry after zeroing out the second part. Signed-off-by: Zhang Yi Reviewed-by: Baokun Li Cc: stable@kernel.org Reviewed-by: Ojaswin Mujoo Message-ID: <20251129103247.686136-7-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 5b1f4290453314e11cd8e15c7baa8a9b76c19b23 Author: Zhang Yi Date: Sat Nov 29 18:32:37 2025 +0800 ext4: don't cache extent during splitting extent commit 8b4b19a2f96348d70bfa306ef7d4a13b0bcbea79 upstream. Caching extents during the splitting process is risky, as it may result in stale extents remaining in the status tree. Moreover, in most cases, the corresponding extent block entries are likely already cached before the split happens, making caching here not particularly useful. Assume we have an unwritten extent, and then DIO writes the first half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, when ext4_split_extent_at() splits this extent, it truncates the existing extent and then inserts a new one. During this process, this extent status entry may be shrunk, and calls to ext4_find_extent() and ext4_cache_extents() may occur, which could potentially insert the truncated range as a hole into the extent status tree. After the split is completed, this hole is not replaced with the correct status. [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: hole Then, the outer calling functions will not correct this remaining hole extent either. Finally, if we perform a delayed buffer write on this latter part, it will re-insert the delayed extent and cause an error in space accounting. In adition, if the unwritten extent cache is not shrunk during the splitting, ext4_cache_extents() also conflicts with existing extents when caching extents. In the future, we will add checks when caching extents, which will trigger a warning. Therefore, Do not cache extents that are being split. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li Cc: stable@kernel.org Message-ID: <20251129103247.686136-6-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit d67c8ecf3d8fda9b8ef80e6f665d84b6d6ac9d88 Author: Zhang Yi Date: Sat Nov 29 18:32:34 2025 +0800 ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1 commit 1bf6974822d1dba86cf11b5f05498581cf3488a2 upstream. When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle. 0 A B N [UUUUUUUUUUUU] U: unwritten extent [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written. 0 A B N [WWWWWWWWWWWW] W: written extent [SSDDDDDDDDZZ] Z: zeroed, S: stale data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A. 0 A B N [WW|WWWWWWWWWW] [SS|DDDDDDDDZZ] Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, don't convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4_split_extent() will pass the EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the second time, allowing it to properly handle the split. If the split is successful, it will keep extent from 0 to A as unwritten. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li Cc: stable@kernel.org Message-ID: <20251129103247.686136-3-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit f86ddca5e4197aabcb8561e3dd4460e705ed35f3 Author: Zhang Yi Date: Sat Nov 29 18:32:33 2025 +0800 ext4: subdivide EXT4_EXT_DATA_VALID1 commit 22784ca541c0f01c5ebad14e8228298dc0a390ed upstream. When splitting an extent, if the EXT4_GET_BLOCKS_CONVERT flag is set and it is necessary to split the target extent in the middle, ext4_split_extent() first handles splitting the latter half of the extent and passes the EXT4_EXT_DATA_VALID1 flag. This flag implies that all blocks before the split point contain valid data; however, this assumption is incorrect. Therefore, subdivid EXT4_EXT_DATA_VALID1 into EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_DATA_PARTIAL_VALID1, which indicate that the first half of the extent is either entirely valid or only partially valid, respectively. These two flags cannot be set simultaneously. This patch does not use EXT4_EXT_DATA_PARTIAL_VALID1, it only replaces EXT4_EXT_DATA_VALID1 with EXT4_EXT_DATA_ENTIRE_VALID1 at the location where it is set, no logical changes. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li Cc: stable@kernel.org Message-ID: <20251129103247.686136-2-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 561834f6d6f52b8a1791331e94b2aac753491d2a Author: Yao Zi Date: Thu Feb 5 15:56:44 2026 +0000 MIPS: Work around LLVM bug when gp is used as global register variable commit 30bfc2d6a1132a89a5f1c3b96c59cf3e4d076ea3 upstream. On MIPS, __current_thread_info is defined as global register variable locating in $gp, and is simply assigned with new address during kernel relocation. This however is broken with LLVM, which always restores $gp if it finds $gp is clobbered in any form, including when intentionally through a global register variable. This is against GCC's documentation[1], which requires a callee-saved register used as global register variable not to be restored if it's clobbered. As a result, $gp will continue to point to the unrelocated kernel after the epilog of relocate_kernel(), leading to an early crash in init_idle, [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY [ 0.000000] Tainted: [W]=WARN [ 0.000000] Hardware name: loongson,loongson64v-4core-virtio [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240 [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001 [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002 [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80 [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80 [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90 [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90 [ 0.000000] Hi : 0000000000000000 [ 0.000000] Lo : 0000000000000000 [ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270 [ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270 [ 0.000000] Status: 540000e2 KX SX UX KERNEL EXL [ 0.000000] Cause : 00000008 (ExcCode 02) [ 0.000000] BadVA : 0000000000000000 [ 0.000000] PrId : 00006305 (ICT Loongson-3) [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000) [ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528 [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000 [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258 [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98 [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [] init_idle+0x130/0x270 [ 0.000000] [] sched_init+0x5c8/0x6c0 [ 0.000000] [] start_kernel+0x27c/0x7a8 This bug has been reported to LLVM[2] and affects version from (at least) 18 to 21. Let's work around this by using inline assembly to assign $gp before a fix is widely available. Cc: stable@vger.kernel.org Link: https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Global-Register-Variables.html # [1] Link: https://github.com/llvm/llvm-project/issues/176546 # [2] Signed-off-by: Yao Zi Acked-by: Nathan Chancellor Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit fc086c0ce3db0eefbbeb66a5b1e626296336e33a Author: Thomas Richard (TI) Date: Fri Jan 30 11:05:45 2026 +0100 usb: cdns3: fix role switching during resume commit 87e4b043b98a1d269be0b812f383881abee0ca45 upstream. If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference. The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped. So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usb_hcd_is_primary_hcd+0x0/0x1c lr : cdns_host_resume+0x24/0x5c ... Call trace: usb_hcd_is_primary_hcd+0x0/0x1c (P) cdns_resume+0x6c/0xbc cdns3_controller_resume.isra.0+0xe8/0x17c cdns3_plat_resume+0x18/0x24 platform_pm_resume+0x2c/0x68 dpm_run_callback+0x90/0x248 device_resume+0x100/0x24c dpm_resume+0x190/0x2ec dpm_resume_end+0x18/0x34 suspend_devices_and_enter+0x2b0/0xa44 pm_suspend+0x16c/0x5fc state_store+0x80/0xec kobj_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x130/0x1dc vfs_write+0x240/0x370 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0x108 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]--- Cc: stable Fixes: 2cf2581cd229 ("usb: cdns3: add power lost support for system resume") Signed-off-by: Thomas Richard (TI) Acked-by: Peter Chen Link: https://patch.msgid.link/20260130-usb-cdns3-fix-role-switching-during-resume-v1-1-44c456852b52@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 557f65399133f5be3ad3215f9dbd6caba6b243ca Author: Mario Kleiner Date: Fri Feb 6 23:38:28 2026 +0100 drm/amd/display: Use same max plane scaling limits for all 64 bpp formats [ Upstream commit f0157ce46cf0e5e2257e19d590c9b16036ce26d4 ] The plane scaling hw seems to have the same min/max plane scaling limits for all 16 bpc / 64 bpp interleaved pixel color formats. Therefore add cases to amdgpu_dm_plane_get_min_max_dc_plane_scaling() for all the 16 bpc fixed-point / unorm formats to use the same .fp16 up/downscaling factor limits as used by the fp16 floating point formats. So far, 16 bpc unorm formats were not handled, and the default: path returned max/min factors for 32 bpp argb8888 formats, which were wrong and bigger than what many DCE / DCN hw generations could handle. The result sometimes was misscaling of framebuffers with DRM_FORMAT_XRGB16161616, DRM_FORMAT_ARGB16161616, DRM_FORMAT_XBGR16161616, DRM_FORMAT_ABGR16161616, leading to very wrong looking display, as tested on Polaris11 / DCE-11.2. So far this went unnoticed, because only few userspace clients used such 16 bpc unorm framebuffers, and those didn't use hw plane scaling, so they did not experience this issue. With upcoming Mesa 26 exposing 16 bpc unorm formats under both OpenGL and Vulkan under Wayland, and the upcoming GNOME 50 Mutter Wayland compositor allowing for direct scanout of these formats, the scaling hw will be used on these formats if possible for HiDPI display scaling, so it is important to use the correct hw scaling limits to avoid wrong display. Tested on AMD Polaris 11 / DCE 11.2 with upcoming Mesa 26 and GNOME 50 on HiDPI displays with scaling enabled. The mutter Wayland compositor now correctly falls back to scaling via desktop compositing instead of direct scanout, thereby avoiding wrong image display. For unscaled mode, it correctly uses direct scanout. Fixes: 580204038f5b ("drm/amd/display: Enable support for 16 bpc fixed-point framebuffers.") Signed-off-by: Mario Kleiner Tested-by: Mario Kleiner Cc: Alex Deucher Cc: Harry Wentland Cc: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9fbb4f14462f0830516694dc7ea7be5d70e6ca3b Author: Detlev Casanova Date: Wed Feb 18 15:18:34 2026 -0500 ASoC: rockchip: i2s-tdm: Use param rate if not provided by set_sysclk [ Upstream commit 0783052534f547f8f201dd4554b1df9f1f8615b5 ] Drivers will not always call set_sysclk() for all clocks, especially when default mclk-fs can be used. When that is the case, use the clock rate set in the params multiplied by the default mclk-fs. Fixes: 5323186e2e8d ("ASoC: rockchip: i2s_tdm: Re-add the set_sysclk callback") Signed-off-by: Detlev Casanova Reported-by: Luca Ceresoli Link: https://patch.msgid.link/20260218201834.924358-1-detlev.casanova@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7e92f716a55bf5fcd96d9763fe6b55bb560e7fc0 Author: Ethan Tidmore Date: Wed Feb 18 13:09:03 2026 -0600 x86/hyperv: Fix error pointer dereference [ Upstream commit 705d01c8d78121ee1634bfc602ac4b0ad1438fab ] The function idle_thread_get() can return an error pointer and is not checked for it. Add check for error pointer. Detected by Smatch: arch/x86/hyperv/hv_vtl.c:126 hv_vtl_bringup_vcpu() error: 'idle' dereferencing possible ERR_PTR() Fixes: 2b4b90e053a29 ("x86/hyperv: Use per cpu initial stack for vtl context") Signed-off-by: Ethan Tidmore Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit d7cf2314dd5e8661c05d076cd627eea9a7f76616 Author: Filipe Manana Date: Wed Feb 4 17:15:53 2026 +0000 btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not found [ Upstream commit ecb7c2484cfc83a93658907580035a8adf1e0a92 ] If btrfs_search_slot_for_read() returns 1, it means we did not find any key greater than or equals to the key we asked for, meaning we have reached the end of the tree and therefore the path is not valid. If this happens we need to break out of the loop and stop, instead of continuing and accessing an invalid path. Fixes: 5223cc60b40a ("btrfs: drop the path before adding qgroup items when enabling qgroups") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 6ca11deb6c94423d1feb4184dfedf72a59b4c053 Author: Filipe Manana Date: Tue Feb 3 18:03:35 2026 +0000 btrfs: use the correct type to initialize block reserve for delayed refs [ Upstream commit 2155d0c0a761a56ce7ede83a26eb23ea0f935260 ] When initializing the delayed refs block reserve for a transaction handle we are passing a type of BTRFS_BLOCK_RSV_DELOPS, which is meant for delayed items and not for delayed refs. The correct type for delayed refs is BTRFS_BLOCK_RSV_DELREFS. On release of any excess space reserved in a local delayed refs reserve, we also should transfer that excess space to the global block reserve (it it's full, we return to the space info for general availability). By initializing a transaction's local delayed refs block reserve with a type of BTRFS_BLOCK_RSV_DELOPS, we were also causing any excess space released from the delayed block reserve (fs_info->delayed_block_rsv, used for delayed inodes and items) to be transferred to the global block reserve instead of the global delayed refs block reserve. This was an unintentional change in commit 28270e25c69a ("btrfs: always reserve space for delayed refs when starting transaction"), but it's not particularly serious as things tend to cancel out each other most of the time and it's relatively rare to be anywhere near exhaustion of the global reserve. Fix this by initializing a transaction's local delayed refs reserve with a type of BTRFS_BLOCK_RSV_DELREFS and making btrfs_block_rsv_release() attempt to transfer unused space from such a reserve into the global block reserve, just as we did before that commit for when the block reserve is a delayed refs rsv. Reported-by: Alex Lyakas Link: https://lore.kernel.org/linux-btrfs/CAOcd+r0FHG5LWzTSu=LknwSoqxfw+C00gFAW7fuX71+Z5AfEew@mail.gmail.com/ Fixes: 28270e25c69a ("btrfs: always reserve space for delayed refs when starting transaction") Reviewed-by: Alex Lyakas Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 55d02a533a8aef4d395fc8a0d000adb72b6bfaf8 Author: Jiasheng Jiang Date: Wed Jan 14 01:13:38 2026 +0000 btrfs: reset block group size class when it becomes empty [ Upstream commit 5870ec7c8fe57a8b2c65005e5da5efc054faa3e6 ] Block group size classes are managed consistently everywhere. Currently, btrfs_use_block_group_size_class() sets a block group's size class to specialize it for a specific allocation size. However, this size class remains "stale" even if the block group becomes completely empty (both used and reserved bytes reach zero). This happens in two scenarios: 1. When space reservations are freed (e.g., due to errors or transaction aborts) via btrfs_free_reserved_bytes(). 2. When the last extent in a block group is freed via btrfs_update_block_group(). While size classes are advisory, a stale size class can cause find_free_extent to unnecessarily skip candidate block groups during initial search loops. This undermines the purpose of size classes to reduce fragmentation by keeping block groups restricted to a specific size class when they could be reused for any size. Fix this by resetting the size class to BTRFS_BG_SZ_NONE whenever a block group's used and reserved counts both reach zero. This ensures that empty block groups are fully available for any allocation size in the next cycle. Fixes: 52bb7a2166af ("btrfs: introduce size class to block group allocator") Reviewed-by: Boris Burkov Signed-off-by: Jiasheng Jiang Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 74fcfce2a5eeef97e42cbf4cc693afac42e4fba6 Author: Filipe Manana Date: Mon Oct 20 12:47:26 2025 +0100 btrfs: reduce block group critical section in btrfs_free_reserved_bytes() [ Upstream commit 8b6fa164ab59f9e3f24e627fe09a0234783e7a8b ] There's no need to update the space_info fields (bytes_reserved, max_extent_size, bytes_readonly, bytes_zone_unusable) while holding the block group's spinlock. So move those updates to happen after we unlock the block group (and while holding the space_info locked of course), so that all we do under the block group's critical section is to update the block group itself. Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: 5870ec7c8fe5 ("btrfs: reset block group size class when it becomes empty") Signed-off-by: Sasha Levin commit 38944f3c500614ef9c0ff35f3f86693557e5ddb9 Author: Filipe Manana Date: Mon Oct 13 13:57:09 2025 +0100 btrfs: remove fs_info argument from btrfs_try_granting_tickets() [ Upstream commit e3df6408b13a75cf73e543e53453f28261874c6f ] We don't need it since we can grab fs_info from the given space_info. So remove the fs_info argument. Reviewed-by: Qu Wenruo Reviewed-by: Johannes Thumshirn Reviewed-by: Anand Jain Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: 5870ec7c8fe5 ("btrfs: reset block group size class when it becomes empty") Signed-off-by: Sasha Levin commit 9b18bf59977f5c5bc3b11b210520f62500a7adf3 Author: Kiryl Shutsemau (Meta) Date: Tue Feb 17 10:49:56 2026 +0000 efi: Fix reservation of unaccepted memory table [ Upstream commit 0862438c90487e79822d5647f854977d50381505 ] The reserve_unaccepted() function incorrectly calculates the size of the memblock reservation for the unaccepted memory table. It aligns the size of the table, but fails to account for cases where the table's starting physical address (efi.unaccepted) is not page-aligned. If the table starts at an offset within a page and its end crosses into a subsequent page that the aligned size does not cover, the end of the table will not be reserved. This can lead to the table being overwritten or inaccessible, causing a kernel panic in accept_memory(). This issue was observed when starting Intel TDX VMs with specific memory sizes (e.g., > 64GB). Fix this by calculating the end address first (including the unaligned start) and then aligning it up, ensuring the entire range is covered by the reservation. Fixes: 8dbe33956d96 ("efi/unaccepted: Make sure unaccepted table is mapped") Reported-by: Moritz Sanft Signed-off-by: Kiryl Shutsemau (Meta) Reviewed-by: Tom Lendacky Acked-by: Mike Rapoport (Microsoft) Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 7098d3743105f7d522c5bb6c9763e30028039b26 Author: Dmitry Torokhov Date: Tue Feb 17 14:11:49 2026 -0800 gpio: amd-fch: ionly return allowed values from amd_fch_gpio_get() [ Upstream commit fbd03587ba732c612b8a569d1cf5bed72bd3a27c ] As of 86ef402d805d ("gpiolib: sanitize the return value of gpio_chip::get()") gpiolib requires drivers implementing GPIOs to only return 0, 1 or negative error for the get() callbacks. Ensure that amd-fch complies with this requirement. Fixes: 86ef402d805d ("gpiolib: sanitize the return value of gpio_chip::get()") Reported-and-tested-by: Tj Signed-off-by: Dmitry Torokhov Link: https://patch.msgid.link/aZTlwnvHt2Gho4yN@google.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 778f326af79f5028aa67938f6d9c2c79fcf94418 Author: Raag Jadav Date: Thu Feb 12 11:26:22 2026 +0530 drm/xe/bo: Redirect faults to dummy page for wedged device [ Upstream commit 4e83a8d58e1c721a89b3ffe15f549007080272e2 ] As per uapi documentation[1], the prerequisite for wedged device is to redirected page faults to a dummy page. Follow it. [1] Documentation/gpu/drm-uapi.rst v2: Add uapi reference and fixes tag (Matthew Brost) Fixes: 7bc00751f877 ("drm/xe: Use device wedged event") Signed-off-by: Raag Jadav Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260212055622.2054991-1-raag.jadav@intel.com Signed-off-by: Matt Roper (cherry picked from commit c020fff70d757612933711dd3cc3751d7d782d3c) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit ed945276a76e9054a45ac75653cae466ad440f17 Author: Shuicheng Lin Date: Mon Feb 2 18:18:54 2026 +0000 drm/xe: Make xe_modparam.force_vram_bar_size signed [ Upstream commit 1acec6ef0511b92e7974cc5a8768bfd3a659feaf ] vram_bar_size is registered as an int module parameter and is documented to accept negative values to disable BAR resizing. Store it as an int in xe_modparam as well, so negative values work as intended and the module_param type matches. Fixes: 80742a1aa26e ("drm/xe: Allow to drop vram resizing") Reviewed-by: Michal Wajdeczko Signed-off-by: Shuicheng Lin Link: https://patch.msgid.link/20260202181853.1095736-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper (cherry picked from commit 25c9aa4dcb5ef2ad9f354d19f8f1eeb690d1c161) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 940b8daa52906e94924c4878484e3ad6a33874e6 Author: Matt Roper Date: Thu Feb 5 14:05:09 2026 -0800 drm/xe/xe2_hpg: Fix handling of Wa_14019988906 & Wa_14019877138 [ Upstream commit bc6387a2e0c1562faa56ce2a98cef50cab809e08 ] The PSS_CHICKEN register has been part of the RCS engine's LRC since it was first introduced in Xe_LP. That means that any workarounds that adjust its value (such as Wa_14019988906 and Wa_14019877138) need to be implemented in the lrc_was[] table so that they become part of the default LRC from which all subsequent LRCs are copied. Although these workarounds were implemented correctly on most platforms, they were incorrectly placed on the engine_was[] table for Xe2_HPG. Move the workarounds to the proper lrc_was[] table and switch the 'xe_rtp_match_first_render_or_compute' rule to specifically match the RCS since that's the engine whose LRC manages the register. Bspec: 65182 Fixes: 7f3ee7d88058 ("drm/xe/xe2hpg: Add initial GT workarounds") Reviewed-by: Shekhar Chauhan Link: https://patch.msgid.link/20260205220508.51905-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper (cherry picked from commit e04c609eedf4d6748ac0bcada4de1275b034fed6) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit ef074e9bee05559ee9d601c8287025ffcaed640d Author: Shuicheng Lin Date: Fri Jan 30 16:56:22 2026 +0000 drm/xe/mmio: Avoid double-adjust in 64-bit reads [ Upstream commit 4a9b4e1fa52a6aaa1adbb7f759048df14afed54c ] xe_mmio_read64_2x32() was adjusting register addresses and then calling xe_mmio_read32(), which applies the adjustment again. This may shift accesses twice if adj_offset < adj_limit. There is no issue currently, as for media gt, adj_offset > adj_limit, so the 2nd adjust will be a no-op. But it may not work in future. To fix it, replace the adjusted-address comparison with a direct sanity check that ensures the MMIO address adjustment cutoff never falls within the 8-byte range of a 64-bit register. And let xe_mmio_read32() handle address translation. v2: rewrite the sanity check in a more natural way. (Matt) v3: Add Fixes tag. (Jani) Fixes: 07431945d8ae ("drm/xe: Avoid 64-bit register reads") Reviewed-by: Matt Roper Cc: Jani Nikula Cc: Rodrigo Vivi Signed-off-by: Shuicheng Lin Link: https://patch.msgid.link/20260130165621.471408-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper (cherry picked from commit a30f999681126b128a43137793ac84b6a5b7443f) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 5ba475d1f3419365892aab6645cfaad0d3b52c3f Author: Michal Wajdeczko Date: Tue Feb 3 20:37:45 2026 +0100 drm/xe/configfs: Fix 'parameter name omitted' errors [ Upstream commit 2a673fb4d787ce6672862cb693112378bff86abb ] On some configs and old compilers we can get following build errors: ../drivers/gpu/drm/xe/xe_configfs.h: In function 'xe_configfs_get_ctx_restore_mid_bb': ../drivers/gpu/drm/xe/xe_configfs.h:40:76: error: parameter name omitted static inline u32 xe_configfs_get_ctx_restore_mid_bb(struct pci_dev *pdev, enum xe_engine_class, ^~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/xe_configfs.h: In function 'xe_configfs_get_ctx_restore_post_bb': ../drivers/gpu/drm/xe/xe_configfs.h:42:77: error: parameter name omitted static inline u32 xe_configfs_get_ctx_restore_post_bb(struct pci_dev *pdev, enum xe_engine_class, ^~~~~~~~~~~~~~~~~~~~ when trying to define our configfs stub functions. Fix that. Fixes: 7a4756b2fd04 ("drm/xe/lrc: Allow to add user commands mid context switch") Signed-off-by: Michal Wajdeczko Cc: Rodrigo Vivi Reviewed-by: Rodrigo Vivi Reviewed-by: Shuicheng Lin Link: https://patch.msgid.link/20260203193745.576-1-michal.wajdeczko@intel.com (cherry picked from commit f59cde8a2452b392115d2af8f1143a94725f4827) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 0c42190a2f2690da43b42ebc9571ff9fd5381870 Author: Alexander Egorenkov Date: Mon Feb 16 07:29:16 2026 +0100 s390/kexec: Make KEXEC_SIG available when CONFIG_MODULES=n [ Upstream commit dd3411959b57df6e05a3ccbac67b0a836871c0c4 ] The commit c8424e776b09 ("MODSIGN: Export module signature definitions") replaced the dependency of KEXEC_SIG on SYSTEM_DATA_VERIFICATION with the dependency on MODULE_SIG_FORMAT. This change disables KEXEC_SIG in s390 kernels built with MODULES=n if nothing else selects MODULE_SIG_FORMAT. Furthermore, the signature verification in s390 kexec does not require MODULE_SIG_FORMAT because it requires only the struct module_signature and, therefore, does not depend on code in kernel/module_signature.c. But making ARCH_SUPPORTS_KEXEC_SIG depend on SYSTEM_DATA_VERIFICATION is also incorrect because it makes KEXEC_SIG available on s390 only if some other arbitrary option (for instance a file system or device driver) selects it directly or indirectly. To properly make KEXEC_SIG available for s390 kernels built with MODULES=y as well as MODULES=n _and_ also not depend on arbitrary options selecting SYSTEM_DATA_VERIFICATION, set ARCH_SUPPORTS_KEXEC_SIG=y for s390 and select SYSTEM_DATA_VERIFICATION when KEXEC_SIG=y. Fixes: c8424e776b09 ("MODSIGN: Export module signature definitions") Suggested-by: Heiko Carstens Signed-off-by: Alexander Egorenkov Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 0f93a80eb3fd596ddc5730d05e0e8c88e1aa2891 Author: Felix Gu Date: Thu Feb 12 20:41:40 2026 +0800 spi: wpcm-fiu: Fix potential NULL pointer dereference in wpcm_fiu_probe() [ Upstream commit 888a0a802c467bbe34a42167bdf9d7331333440a ] platform_get_resource_byname() can return NULL, which would cause a crash when passed the pointer to resource_size(). Move the fiu->memory_size assignment after the error check for devm_ioremap_resource() to prevent the potential NULL pointer dereference. Fixes: 9838c182471e ("spi: wpcm-fiu: Add direct map support") Signed-off-by: Felix Gu Reviewed-by: J. Neuschäfer Link: https://patch.msgid.link/20260212-wpcm-v1-1-5b7c4f526aac@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 263e28add4f4472cfa95150d218955d1945aa413 Author: Srinivasan Shanmugam Date: Fri Feb 6 20:49:23 2026 +0530 drm/amd/display: Fix out-of-bounds stream encoder index v3 [ Upstream commit abde491143e4e12eecc41337910aace4e8d59603 ] eng_id can be negative and that stream_enc_regs[] can be indexed out of bounds. eng_id is used directly as an index into stream_enc_regs[], which has only 5 entries. When eng_id is 5 (ENGINE_ID_DIGF) or negative, this can access memory past the end of the array. Add a bounds check using ARRAY_SIZE() before using eng_id as an index. The unsigned cast also rejects negative values. This avoids out-of-bounds access. Fixes the below smatch error: dcn*_resource.c: stream_encoder_create() may index stream_enc_regs[eng_id] out of bounds (size 5). drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn351/dcn351_resource.c 1246 static struct stream_encoder *dcn35_stream_encoder_create( 1247 enum engine_id eng_id, 1248 struct dc_context *ctx) 1249 { ... 1255 1256 /* Mapping of VPG, AFMT, DME register blocks to DIO block instance */ 1257 if (eng_id <= ENGINE_ID_DIGF) { ENGINE_ID_DIGF is 5. should <= be dc_bios, 1283 eng_id, vpg, afmt, --> 1284 &stream_enc_regs[eng_id], ^^^^^^^^^^^^^^^^^^^^^^^ This stream_enc_regs[] array has 5 elements so we are one element beyond the end of the array. ... 1287 return &enc1->base; 1288 } v2: use explicit bounds check as suggested by Roman/Dan; avoid unsigned int cast v3: The compiler already knows how to compare the two values, so the cast (int) is not needed. (Roman) Fixes: 2728e9c7c842 ("drm/amd/display: add DC changes for DCN351") Reported-by: Dan Carpenter Cc: Harry Wentland Cc: Mario Limonciello Cc: Alex Hung Cc: Aurabindo Pillai Cc: ChiaHsuan Chung Cc: Roman Li Signed-off-by: Srinivasan Shanmugam Reviewed-by: Roman Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8eb62f5adc12b124004a7d6c0eafcb541ed569dd Author: Timur Kristóf Date: Sun Jan 18 15:57:41 2026 +0100 drm/amd/display: Reject cursor plane on DCE when scaled differently than primary [ Upstream commit 41af6215cdbcecd12920f211239479027904abf3 ] Currently DCE doesn't support the overlay cursor, so the dm_crtc_get_cursor_mode() function returns DM_CURSOR_NATIVE_MODE unconditionally. The outcome is that it doesn't check for the conditions that would necessitate the overlay cursor, meaning that it doesn't reject cases where the native cursor mode isn't supported on DCE. Remove the early return from dm_crtc_get_cursor_mode() for DCE and instead let it perform the necessary checks and return DM_CURSOR_OVERLAY_MODE. Add a later check that rejects when DM_CURSOR_OVERLAY_MODE would be used with DCE. Fixes: 1b04dcca4fb1 ("drm/amd/display: Introduce overlay cursor mode") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4600 Suggested-by: Leo Li Signed-off-by: Timur Kristóf Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2b36c0c1bcbbe15f6cfa9652084b3124c835a150 Author: Srinivasan Shanmugam Date: Fri Feb 6 21:18:11 2026 +0530 drm/amdkfd: Fix watch_id bounds checking in debug address watch v2 [ Upstream commit 5a19302cab5cec7ae7f1a60c619951e6c17d8742 ] The address watch clear code receives watch_id as an unsigned value (u32), but some helper functions were using a signed int and checked bits by shifting with watch_id. If a very large watch_id is passed from userspace, it can be converted to a negative value. This can cause invalid shifts and may access memory outside the watch_points array. drm/amdkfd: Fix watch_id bounds checking in debug address watch v2 Fix this by checking that watch_id is within MAX_WATCH_ADDRESSES before using it. Also use BIT(watch_id) to test and clear bits safely. This keeps the behavior unchanged for valid watch IDs and avoids undefined behavior for invalid ones. Fixes the below: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_debug.c:448 kfd_dbg_trap_clear_dev_address_watch() error: buffer overflow 'pdd->watch_points' 4 <= u32max user_rl='0-3,2147483648-u32max' uncapped drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_debug.c 433 int kfd_dbg_trap_clear_dev_address_watch(struct kfd_process_device *pdd, 434 uint32_t watch_id) 435 { 436 int r; 437 438 if (!kfd_dbg_owns_dev_watch_id(pdd, watch_id)) kfd_dbg_owns_dev_watch_id() doesn't check for negative values so if watch_id is larger than INT_MAX it leads to a buffer overflow. (Negative shifts are undefined). 439 return -EINVAL; 440 441 if (!pdd->dev->kfd->shared_resources.enable_mes) { 442 r = debug_lock_and_unmap(pdd->dev->dqm); 443 if (r) 444 return r; 445 } 446 447 amdgpu_gfx_off_ctrl(pdd->dev->adev, false); --> 448 pdd->watch_points[watch_id] = pdd->dev->kfd2kgd->clear_address_watch( 449 pdd->dev->adev, 450 watch_id); v2: (as per, Jonathan Kim) - Add early watch_id >= MAX_WATCH_ADDRESSES validation in the set path to match the clear path. - Drop the redundant bounds check in kfd_dbg_owns_dev_watch_id(). Fixes: e0f85f4690d0 ("drm/amdkfd: add debug set and clear address watch points operation") Reported-by: Dan Carpenter Cc: Jonathan Kim Cc: Felix Kuehling Cc: Alex Deucher Cc: Christian König Signed-off-by: Srinivasan Shanmugam Reviewed-by: Jonathan Kim Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 96f42087b05801263b1f4c1129f525c0bbcfa3eb Author: Kai-Heng Feng Date: Tue Feb 10 22:20:57 2026 +0800 PCI: Validate window resource type in pbus_select_window_for_type() [ Upstream commit e5f72cb9cea599dc9f5a9b80a33560a1d06f01cc ] After ebe091ad81e1 ("PCI: Use pbus_select_window_for_type() during IO window sizing") and ae88d0b9c57f ("PCI: Use pbus_select_window_for_type() during mem window sizing"), many bridge windows can't get resources assigned: pci 0006:05:00.0: bridge window [??? 0x00001000-0x00001fff flags 0x20080000]: can't assign; no space pci 0006:05:00.0: bridge window [??? 0x00001000-0x00001fff flags 0x20080000]: failed to assign Those commits replace find_bus_resource_of_type() with pbus_select_window_for_type(), and the latter lacks resource type validation. Add the resource type validation back to pbus_select_window_for_type() to match the original behavior. Fixes: 74afce3dfcba ("PCI: Add bridge window selection functions") Link: https://bugzilla.kernel.org/show_bug.cgi?id=221072 Signed-off-by: Kai-Heng Feng Signed-off-by: Bjorn Helgaas Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/20260210142058.82701-1-kaihengf@nvidia.com Signed-off-by: Sasha Levin commit e37630e34e246f3f538da1e34bb1482191f6bb8d Author: Alexandre Ferrieux Date: Wed Feb 11 11:27:32 2026 +0100 ASoC: codecs: aw88261: Fix erroneous bitmask logic in Awinic init [ Upstream commit b82fa9b0c26eeb2fde6017f7de2c3c544484efef ] The aw88261_dev_reg_update() function sets the Awinic registers in a rather nonuniform way: - most registers get directly overwritten from the firmware blob - but a handful of them need more delicate logic to preserve some bits from their current value, according to a register- specific mask For the latter, the logic is basically NEW = (OLD & MASK) | (VAL & ~MASK) However, the ~MASK value is hand-computed, and in the specific case of the SYSCTRL register, in a buggy way. This patch restores the proper ~MASK value. Fixes: 028a2ae25691 ("ASoC: codecs: Add aw88261 amplifier driver") Signed-off-by: Alexandre Ferrieux Link: https://patch.msgid.link/20260211-aw88261-fwname-v1-1-e24e833a019d@fairphone.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 63680351142e87e0f123482333d15d03c8db6b61 Author: Kaushlendra Kumar Date: Fri Jan 9 08:55:49 2026 +0530 drm/i915/acpi: free _DSM package when no connectors [ Upstream commit 57b85fd53fccfdf14ce7b36d919c31aa752255f8 ] acpi_evaluate_dsm_typed() returns an ACPI package in pkg. When pkg->package.count == 0, we returned without freeing pkg, leaking memory. Free pkg before returning on the empty case. Signed-off-by: Kaushlendra Kumar Fixes: 337d7a1621c7 ("drm/i915: Fix invalid access to ACPI _DSM objects") Reviewed-by: Jani Nikula Link: https://patch.msgid.link/20260109032549.1826303-1-kaushlendra.kumar@intel.com Signed-off-by: Jani Nikula (cherry picked from commit c0a27a0ca8a34e96d08bb05a2c5d5ccf63fb8dc0) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit 9a2a5da002775376498e8814df4a87cd629a3a0c Author: Ziyi Guo Date: Tue Feb 10 18:57:14 2026 +0000 ASoC: fsl_xcvr: Revert fix missing lock in fsl_xcvr_mode_put() [ Upstream commit 9f16d96e1222391a6b996a1b676bec14fb91e3b2 ] This reverts commit f51424872760 ("ASoC: fsl_xcvr: fix missing lock in fsl_xcvr_mode_put()"). The original patch attempted to acquire the card->controls_rwsem lock in fsl_xcvr_mode_put(). However, this function is called from the upper ALSA core function snd_ctl_elem_write(), which already holds the write lock on controls_rwsem for the whole put operation. So there is no need to simply hold the lock for fsl_xcvr_activate_ctl() again. Acquiring the read lock while holding the write lock in the same thread results in a deadlock and a hung task, as reported by Alexander Stein. Fixes: f51424872760 ("ASoC: fsl_xcvr: fix missing lock in fsl_xcvr_mode_put()") Reported-by: Alexander Stein Closes: https://lore.kernel.org/linux-sound/5056506.GXAFRqVoOG@steina-w/ Signed-off-by: Ziyi Guo Link: https://patch.msgid.link/20260210185714.556385-1-n7l8m4@u.northwestern.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a62afa5a595ec4a5bbb63a1d9efd6470b8ca39f2 Author: Li RongQing Date: Thu Feb 5 04:40:10 2026 -0500 mshv: fix SRCU protection in irqfd resampler ack handler [ Upstream commit 2e7577cd5ddc1f86d1b6c48caf3cfa87dbb14e34 ] Replace hlist_for_each_entry_rcu() with hlist_for_each_entry_srcu() in mshv_irqfd_resampler_ack() to correctly handle SRCU-protected linked list traversal. The function uses SRCU (sleepable RCU) synchronization via partition->pt_irq_srcu, but was incorrectly using the RCU variant for list iteration. This could lead to race conditions when the list is modified concurrently. Also add srcu_read_lock_held() assertion as required by hlist_for_each_entry_srcu() to ensure we're in the proper read-side critical section. Fixes: 621191d709b14 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs") Signed-off-by: Li RongQing Reviewed-by: Anirudh Rayabharam (Microsoft) Acked-by: Stanislav Kinsburskii Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit ca2eff3617860c9081c80b6df179fce1d3a4e25b Author: Alex Deucher Date: Tue Feb 3 11:53:51 2026 -0500 drm/amdgpu/sdma6: enable queue resets unconditionally [ Upstream commit 56423871e9eef1dd069bddef895207fa5ce275fe ] There is no firmware version dependency. This also enables sdma queue resets on all SDMA 6.x based chips. Fixes: 59fd50b8663b ("drm/amdgpu: Add sysfs interface for sdma reset mask") Cc: Jesse Zhang Reviewed-by: Jesse.Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5211aa12e46fc3266c7e8aaf6b2c58c88f87acc4 Author: Alex Deucher Date: Tue Feb 3 11:52:46 2026 -0500 drm/amdgpu/sdma5.2: enable queue resets unconditionally [ Upstream commit 314d30ad50622fc0d70da71509f9dff21545be14 ] There is no firmware version dependency. This also enables sdma queue resets on all SDMA 5.2.x based chips. Fixes: 59fd50b8663b ("drm/amdgpu: Add sysfs interface for sdma reset mask") Cc: Jesse Zhang Reviewed-by: Jesse.Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0d8ba96c792fc4b5339b00e0d7e18fde5c56dedf Author: Alex Deucher Date: Tue Feb 3 11:51:45 2026 -0500 drm/amdgpu/sdma5: enable queue resets unconditionally [ Upstream commit 46a2cb7d24f21132e970cab52359210c3f5ea3c6 ] There is no firmware version dependency. Fixes: 59fd50b8663b ("drm/amdgpu: Add sysfs interface for sdma reset mask") Cc: Jesse Zhang Reviewed-by: Jesse.Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3759040d6d7c1f8f4144bd52357d3220b3972684 Author: Alex Deucher Date: Tue Oct 14 17:01:05 2025 -0400 drm/amdgpu: move reset debug disable handling [ Upstream commit ad0a48e531a3137cec16bb5f8f60c8cc8de06b01 ] Move everything to the supported resets masks rather than having an explicit misc checks for this. Reviewed-by: Jesse Zhang Signed-off-by: Alex Deucher Stable-dep-of: 46a2cb7d24f2 ("drm/amdgpu/sdma5: enable queue resets unconditionally") Signed-off-by: Sasha Levin commit 2fef8c2ac67e7c1b0409d23653300b134c63e54c Author: Zilin Guan Date: Thu Jan 29 08:35:15 2026 +0000 drm/amdgpu: Fix memory leak in amdgpu_ras_init() [ Upstream commit ee41e5b63c8210525c936ee637a2c8d185ce873c ] When amdgpu_nbio_ras_sw_init() fails in amdgpu_ras_init(), the function returns directly without freeing the allocated con structure, leading to a memory leak. Fix this by jumping to the release_con label to properly clean up the allocated memory before returning the error code. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: fdc94d3a8c88 ("drm/amdgpu: Rework pcie_bif ras sw_init") Reviewed-by: Tao Zhou Signed-off-by: Zilin Guan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9ae85b0c1909b6c6bfd2636b04cdaf7f520bf2b5 Author: Zilin Guan Date: Thu Jan 29 09:05:42 2026 +0000 drm/amdgpu: Use kvfree instead of kfree in amdgpu_gmc_get_nps_memranges() [ Upstream commit 0c44d61945c4a80775292d96460aa2f22e62f86c ] amdgpu_discovery_get_nps_info() internally allocates memory for ranges using kvcalloc(), which may use vmalloc() for large allocation. Using kfree() to release vmalloc memory will lead to a memory corruption. Use kvfree() to safely handle both kmalloc and vmalloc allocations. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: b194d21b9bcc ("drm/amdgpu: Use NPS ranges from discovery table") Reviewed-by: Lijo Lazar Signed-off-by: Zilin Guan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d1370ef2ecf7d4df25e3e1e430cd191b1e7f8596 Author: Zilin Guan Date: Thu Jan 29 09:25:32 2026 +0000 drm/amdgpu: Fix memory leak in amdgpu_acpi_enumerate_xcc() [ Upstream commit c9be63d565789b56ca7b0197e2cb78a3671f95a8 ] In amdgpu_acpi_enumerate_xcc(), if amdgpu_acpi_dev_init() returns -ENOMEM, the function returns directly without releasing the allocated xcc_info, resulting in a memory leak. Fix this by ensuring that xcc_info is properly freed in the error paths. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 4d5275ab0b18 ("drm/amdgpu: Add parsing of acpi xcc objects") Reviewed-by: Lijo Lazar Signed-off-by: Zilin Guan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit aebd195e93052e33e38cd083133909d63c89735a Author: John Johansen Date: Mon Feb 2 04:12:02 2026 -0800 apparmor: fix aa_label to return state from compount and component match [ Upstream commit 9058798652c8bc0584ed1fb0766a1015046c06e8 ] aa-label_match is not correctly returning the state in all cases. The only reason this didn't cause a error is that all callers currently ignore the return value. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202602020631.wXgZosyU-lkp@intel.com/ Fixes: a4c9efa4dbad6 ("apparmor: make label_match return a consistent value") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 1d2b2b58fde9059a488bc25399e6c3d74e9b5548 Author: Georgia Garcia Date: Thu Jan 29 15:58:45 2026 -0300 apparmor: fix invalid deref of rawdata when export_binary is unset [ Upstream commit df9ac55abd18628bd8cff687ea043660532a3654 ] If the export_binary parameter is disabled on runtime, profiles that were loaded before that will still have their rawdata stored in apparmorfs, with a symbolic link to the rawdata on the policy directory. When one of those profiles are replaced, the rawdata is set to NULL, but when trying to resolve the symbolic links to rawdata for that profile, it will try to dereference profile->rawdata->name when profile->rawdata is now NULL causing an oops. Fix it by checking if rawdata is set. [ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088 [ 168.657420] #PF: supervisor read access in kernel mode [ 168.660619] #PF: error_code(0x0000) - not-present page [ 168.663613] PGD 0 P4D 0 [ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI [ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary) [ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330 [ 168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8 [ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282 [ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158 [ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80 [ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000 [ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80 [ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0 [ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000 [ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0 [ 168.701696] Call Trace: [ 168.702325] [ 168.702995] rawdata_get_link_data+0x1c/0x30 [ 168.704145] vfs_readlink+0xd4/0x160 [ 168.705152] do_readlinkat+0x114/0x180 [ 168.706214] __x64_sys_readlink+0x1e/0x30 [ 168.708653] x64_sys_call+0x1d77/0x26b0 [ 168.709525] do_syscall_64+0x81/0x500 [ 168.710348] ? do_statx+0x72/0xb0 [ 168.711109] ? putname+0x3e/0x80 [ 168.711845] ? __x64_sys_statx+0xb7/0x100 [ 168.712711] ? x64_sys_call+0x10fc/0x26b0 [ 168.713577] ? do_syscall_64+0xbf/0x500 [ 168.714412] ? do_user_addr_fault+0x1d2/0x8d0 [ 168.715404] ? irqentry_exit+0xb2/0x740 [ 168.716359] ? exc_page_fault+0x90/0x1b0 [ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 1180b4c757aab ("apparmor: fix dangling symlinks to policy rawdata after replacement") Signed-off-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 80c334acc6d0bee8605a358a33e69b4aea1ffb92 Author: Zhengmian Hu Date: Mon Jan 19 19:03:07 2026 -0500 apparmor: avoid per-cpu hold underflow in aa_get_buffer [ Upstream commit 640cf2f09575c9dc344b3f7be2498d31e3923ead ] When aa_get_buffer() pulls from the per-cpu list it unconditionally decrements cache->hold. If hold reaches 0 while count is still non-zero, the unsigned decrement wraps to UINT_MAX. This keeps hold non-zero for a very long time, so aa_put_buffer() never returns buffers to the global list, which can starve other CPUs and force repeated kmalloc(aa_g_path_max) allocations. Guard the decrement so hold never underflows. Fixes: ea9bae12d028 ("apparmor: cache buffers on percpu list if there is lock contention") Signed-off-by: Zhengmian Hu Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 4610d536ff097adf470b3e52bb1eba96068bd501 Author: John Johansen Date: Thu Nov 13 23:59:38 2025 -0800 apparmor: make label_match return a consistent value [ Upstream commit a4c9efa4dbad6dacad6e8b274e30e814c8353097 ] compound match is inconsistent in returning a state or an integer error this is problemati if the error is ever used as a state in the state machine Fixes: f1bd904175e81 ("apparmor: add the base fns() for domain labels") Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 9ef25645775b4375c455d3b44ce90c22dfe4a2c8 Author: John Johansen Date: Fri Nov 14 00:14:36 2025 -0800 apparmor: remove apply_modes_to_perms from label_match [ Upstream commit b2e27be2948f2f8c38421cd554b5fc9383215648 ] The modes shouldn't be applied at the point of label match, it just results in them being applied multiple times. Instead they should be applied after which is already being done by all callers so it can just be dropped from label_match. Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Stable-dep-of: a4c9efa4dbad ("apparmor: make label_match return a consistent value") Signed-off-by: Sasha Levin commit 9bf1fa150775b0c6b794e4b6a2c0395e13777999 Author: John Johansen Date: Sun Nov 9 14:16:54 2025 -0800 apparmor: fix rlimit for posix cpu timers [ Upstream commit 6ca56813f4a589f536adceb42882855d91fb1125 ] Posix cpu timers requires an additional step beyond setting the rlimit. Refactor the code so its clear when what code is setting the limit and conditionally update the posix cpu timers when appropriate. Fixes: baa73d9e478ff ("posix-timers: Make them configurable") Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit b2a8011ae8749215f3939881239b454728a2d88b Author: John Johansen Date: Sat Sep 13 02:22:21 2025 -0700 apparmor: move check for aa_null file to cover all cases [ Upstream commit 4a134723f9f1ad2f3621566259db673350d19cb1 ] files with a dentry pointing aa_null.dentry where already rejected as part of file_inheritance. Unfortunately the check in common_file_perm() is insufficient to cover all cases causing unnecessary audit messages without the original files context. Eg. [ 442.886474] audit: type=1400 audit(1704822661.616:329): apparmor="DENIED" operation="file_inherit" class="file" namespace="root//lxd-juju-98527a-0_" profile="snap.lxd.activate" name="/apparmor/.null" pid=9525 comm="snap-exec" Further examples of this are in the logs of https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2120439 https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1952084 https://bugs.launchpad.net/snapd/+bug/2049099 These messages have no value and should not be sent to the logs. AppArmor was already filtering the out in some cases but the original patch did not catch all cases. Fix this by push the existing check down into two functions that should cover all cases. Link: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2122743 Fixes: 192ca6b55a86 ("apparmor: revalidate files during exec") Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 7757757908e0326fe73a91b650b0b5b872cfc593 Author: Ryan Lee Date: Wed Jan 7 11:47:02 2026 -0800 apparmor: account for in_atomic removal in common_file_perm [ Upstream commit 9b829c0aa96e9385b1e9a308d3eb054b95fbeda2 ] If we are not in an atomic context in common_file_perm, then we don't have to use the atomic versions, resulting in improved performance outside of atomic contexts. Signed-off-by: Ryan Lee Signed-off-by: John Johansen Stable-dep-of: 4a134723f9f1 ("apparmor: move check for aa_null file to cover all cases") Signed-off-by: Sasha Levin commit f3cb5e58a65d53cdb9456d19dc69af82f89a0d7a Author: John Johansen Date: Sat Jan 17 23:40:03 2026 -0800 apparmor: drop in_atomic flag in common_mmap, and common_file_perm [ Upstream commit c3f27ccdb2dce3f0f2814574d06017f46c11fa29 ] with the previous changes to mmap the in_atomic flag is now always false, so drop it. Suggested-by: Tyler Hicks Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Stable-dep-of: 4a134723f9f1 ("apparmor: move check for aa_null file to cover all cases") Signed-off-by: Sasha Levin commit 1eadeb462ec365eba0219086326e64cbf9021fcd Author: Ryan Lee Date: Wed Jan 7 11:48:54 2026 -0800 apparmor: fix boolean argument in apparmor_mmap_file [ Upstream commit 48d5268e911abcf7674ec33c9b0b3e952be1175e ] The previous value of GFP_ATOMIC is an int and not a bool, potentially resulting in UB when being assigned to a bool. In addition, the mmap hook is called outside of locks (i.e. in a non-atomic context), so we can pass a fixed constant value of false instead to common_mmap. Signed-off-by: Ryan Lee Signed-off-by: John Johansen Stable-dep-of: 4a134723f9f1 ("apparmor: move check for aa_null file to cover all cases") Signed-off-by: Sasha Levin commit ac8f179e5c9eecd0160dce9f1c8a0236fab81d76 Author: Ryan Lee Date: Tue Jan 13 09:35:57 2026 -0800 apparmor: return -ENOMEM in unpack_perms_table upon alloc failure [ Upstream commit 74b7105e53e80a4072bd3e1a50be7aa15e3f0a01 ] In policy_unpack.c:unpack_perms_table, the perms struct is allocated via kcalloc, with the position being reset if the allocation fails. However, the error path results in -EPROTO being retured instead of -ENOMEM. Fix this to return the correct error code. Reported-by: Zygmunt Krynicki Fixes: fd1b2b95a2117 ("apparmor: add the ability for policy to specify a permission table") Reviewed-by: Tyler Hicks Signed-off-by: Ryan Lee Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit e027999049c493fb728ead5a90db76942181a935 Author: Helge Deller Date: Wed Nov 26 21:15:04 2025 +0100 apparmor: Fix & Optimize table creation from possibly unaligned memory [ Upstream commit 6fc367bfd4c8886e6b1742aabbd1c0bdc310db3a ] Source blob may come from userspace and might be unaligned. Try to optize the copying process by avoiding unaligned memory accesses. - Added Fixes tag - Added "Fix &" to description as this doesn't just optimize but fixes a potential unaligned memory access Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Signed-off-by: Helge Deller [jj: remove duplicate word "convert" in comment trigger checkpatch warning] Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 23f112bd6144e815153462e12d313ac3e7027168 Author: Helge Deller Date: Tue Nov 25 16:11:07 2025 +0100 AppArmor: Allow apparmor to handle unaligned dfa tables [ Upstream commit 64802f731214a51dfe3c6c27636b3ddafd003eb0 ] The dfa tables can originate from kernel or userspace and 8-byte alignment isn't always guaranteed and as such may trigger unaligned memory accesses on various architectures. Resulting in the following [   73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720 [   74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common [   74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE [   74.536543] Call Trace: [   74.568561] [<0000000000434c24>] dump_stack+0x8/0x18 [   74.633757] [<0000000000476438>] __warn+0xd8/0x100 [   74.696664] [<00000000004296d4>] warn_slowpath_fmt+0x34/0x74 [   74.771006] [<00000000008db28c>] aa_dfa_unpack+0x6cc/0x720 [   74.843062] [<00000000008e643c>] unpack_pdb+0xbc/0x7e0 [   74.910545] [<00000000008e7740>] unpack_profile+0xbe0/0x1300 [   74.984888] [<00000000008e82e0>] aa_unpack+0xe0/0x6a0 [   75.051226] [<00000000008e3ec4>] aa_replace_profiles+0x64/0x1160 [   75.130144] [<00000000008d4d90>] policy_update+0xf0/0x280 [   75.201057] [<00000000008d4fc8>] profile_replace+0xa8/0x100 [   75.274258] [<0000000000766bd0>] vfs_write+0x90/0x420 [   75.340594] [<00000000007670cc>] ksys_write+0x4c/0xe0 [   75.406932] [<0000000000767174>] sys_write+0x14/0x40 [   75.472126] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [   75.548802] ---[ end trace 0000000000000000 ]--- [   75.609503] dfa blob stream 0xfff0000008926b96 not aligned. [   75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720 Work around it by using the get_unaligned_xx() helpers. Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Reported-by: John Paul Adrian Glaubitz Closes: https://github.com/sparclinux/issues/issues/30 Signed-off-by: Helge Deller Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit ccb66a3c6c8f51b3ed1bc003b70bb9ff99e8d835 Author: John Johansen Date: Mon Nov 24 15:07:42 2025 -0800 apparmor: fix NULL sock in aa_sock_file_perm [ Upstream commit 00b67657535dfea56e84d11492f5c0f61d0af297 ] Deal with the potential that sock and sock-sk can be NULL during socket setup or teardown. This could lead to an oops. The fix for NULL pointer dereference in __unix_needs_revalidation shows this is at least possible for af_unix sockets. While the fix for af_unix sockets applies for newer mediation this is still the fall back path for older af_unix mediation and other sockets, so ensure it is covered. Fixes: 56974a6fcfef6 ("apparmor: add base infastructure for socket mediation") Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit fea017a7f6abe179decf575a2d8464c74edb3964 Author: System Administrator Date: Thu Oct 9 16:35:00 2025 +0000 apparmor: fix NULL pointer dereference in __unix_needs_revalidation [ Upstream commit e2938ad00b21340c0362562dfedd7cfec0554d67 ] When receiving file descriptors via SCM_RIGHTS, both the socket pointer and the socket's sk pointer can be NULL during socket setup or teardown, causing NULL pointer dereferences in __unix_needs_revalidation(). This is a regression in AppArmor 5.0.0 (kernel 6.17+) where the new __unix_needs_revalidation() function was added without proper NULL checks. The crash manifests as: BUG: kernel NULL pointer dereference, address: 0x0000000000000018 RIP: aa_file_perm+0xb7/0x3b0 (or +0xbe/0x3b0, +0xc0/0x3e0) Call Trace: apparmor_file_receive+0x42/0x80 security_file_receive+0x2e/0x50 receive_fd+0x1d/0xf0 scm_detach_fds+0xad/0x1c0 The function dereferences sock->sk->sk_family without checking if either sock or sock->sk is NULL first. Add NULL checks for both sock and sock->sk before accessing sk_family. Fixes: 88fec3526e841 ("apparmor: make sure unix socket labeling is correctly updated.") Reported-by: Jamin Mc Closes: https://bugzilla.proxmox.com/show_bug.cgi?id=7083 Closes: https://gitlab.com/apparmor/apparmor/-/issues/568 Signed-off-by: Fabian Grünbichler Signed-off-by: System Administrator Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit d80311e398ebe49395233ed10431ae8ccf2ef9ed Author: Cosmin Ratiu Date: Wed Feb 18 09:29:04 2026 +0200 net/mlx5e: Use unsigned for mlx5e_get_max_num_channels [ Upstream commit 57a94d4b22b0c6cc5d601e6b6238d78fb923d991 ] The max number of channels is always an unsigned int, use the correct type to fix compilation errors done with strict type checking, e.g.: error: call to ‘__compiletime_assert_1110’ declared with attribute error: min(mlx5e_get_devlink_param_num_doorbells(mdev), mlx5e_get_max_num_channels(mdev)) signedness error Fixes: 74a8dadac17e ("net/mlx5e: Preparations for supporting larger number of channels") Signed-off-by: Cosmin Ratiu Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260218072904.1764634-7-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4329514c61abefe4961541b128c549b017bab5ad Author: Cosmin Ratiu Date: Wed Feb 18 09:29:03 2026 +0200 net/mlx5e: Fix deadlocks between devlink and netdev instance locks [ Upstream commit 83ac0304a2d77519dae1e54c9713cbe1aedf19c9 ] In the mentioned "Fixes" commit, various work tasks triggering devlink health reporter recovery were switched to use netdev_trylock to protect against concurrent tear down of the channels being recovered. But this had the side effect of introducing potential deadlocks because of incorrect lock ordering. The correct lock order is described by the init flow: probe_one -> mlx5_init_one (acquires devlink lock) -> mlx5_init_one_devl_locked -> mlx5_register_device -> mlx5_rescan_drivers_locked -...-> mlx5e_probe -> _mlx5e_probe -> register_netdev (acquires rtnl lock) -> register_netdevice (acquires netdev lock) => devlink lock -> rtnl lock -> netdev lock. But in the current recovery flow, the order is wrong: mlx5e_tx_err_cqe_work (acquires netdev lock) -> mlx5e_reporter_tx_err_cqe -> mlx5e_health_report -> devlink_health_report (acquires devlink lock => boom!) -> devlink_health_reporter_recover -> mlx5e_tx_reporter_recover -> mlx5e_tx_reporter_recover_from_ctx -> mlx5e_tx_reporter_err_cqe_recover The same pattern exists in: mlx5e_reporter_rx_timeout mlx5e_reporter_tx_ptpsq_unhealthy mlx5e_reporter_tx_timeout Fix these by moving the netdev_trylock calls from the work handlers lower in the call stack, in the respective recovery functions, where they are actually necessary. Fixes: 8f7b00307bf1 ("net/mlx5e: Convert mlx5 netdevs to instance locking") Signed-off-by: Cosmin Ratiu Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260218072904.1764634-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 54522509cb9aade1de14da2423c95d197200d46b Author: Gal Pressman Date: Wed Feb 18 09:29:01 2026 +0200 net/mlx5: Fix misidentification of write combining CQE during poll loop [ Upstream commit d451994ebc7d4392610bd4b2ab339b255deb4143 ] The write combining completion poll loop uses usleep_range() which can sleep much longer than requested due to scheduler latency. Under load, we witnessed a 20ms+ delay until the process was rescheduled, causing the jiffies based timeout to expire while the thread is sleeping. The original do-while loop structure (poll, sleep, check timeout) would exit without a final poll when waking after timeout, missing a CQE that arrived during sleep. Instead of the open-coded while loop, use the kernel's poll_timeout_us() which always performs an additional check after the sleep expiration, and is less error-prone. Note: poll_timeout_us() doesn't accept a sleep range, by passing 10 sleep_us the sleep range effectively changes from 2-10 to 3-10 usecs. Fixes: d98995b4bf98 ("net/mlx5: Reimplement write combining test") Signed-off-by: Gal Pressman Reviewed-by: Jianbo Liu Signed-off-by: Tariq Toukan Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260218072904.1764634-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b13e896fc47e0ab1381269b54e68975e92166b9a Author: Shay Drory Date: Wed Feb 18 09:28:59 2026 +0200 net/mlx5: Fix multiport device check over light SFs [ Upstream commit 47bf2e813817159f4d195be83a9b5a640ee6baec ] Driver is using num_vhca_ports capability to distinguish between multiport master device and multiport slave device. num_vhca_ports is a capability the driver sets according to the MAX num_vhca_ports capability reported by FW. On the other hand, light SFs doesn't set the above capbility. This leads to wrong results whenever light SFs is checking whether he is a multiport master or slave. Therefore, use the MAX capability to distinguish between master and slave devices. Fixes: e71383fb9cd1 ("net/mlx5: Light probe local SFs") Signed-off-by: Shay Drory Reviewed-by: Moshe Shemesh Signed-off-by: Tariq Toukan Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260218072904.1764634-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fef13c403be3fb685cb06419e6b3623106aab5ba Author: Hangbin Liu Date: Wed Feb 18 06:09:19 2026 +0000 bonding: alb: fix UAF in rlb_arp_recv during bond up/down [ Upstream commit e6834a4c474697df23ab9948fd3577b26bf48656 ] The ALB RX path may access rx_hashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlb_deinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN. However, the root cause is that rlb_arp_recv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag. [ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding] [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfx_arp_process+0x10/0x10 [ 214.343775] ? sched_balance_find_src_group+0x98/0x630 [ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ? arp_rcv+0x307/0x690 [ 214.360311] ? __pfx_arp_rcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 214.380743] ? lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ? process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ? __pfx_net_rx_action+0x10/0x10 [ 214.408193] ? lock_acquire.part.0+0xbd/0x260 [ 214.413058] ? sched_clock_cpu+0x6c/0x540 [ 214.417540] ? mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ? __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlb_arp_recv() can race with rlb_deinitialize() and dereference a freed rx_hashtbl entry. Fix this by setting recv_probe to NULL and then calling synchronize_net() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rx_hashtbl after it is freed in bond_alb_deinitialize(). Reported-by: Liang Li Fixes: 3aba891dde38 ("bonding: move processing of recv handlers into handle_frame()") Reviewed-by: Nikolay Aleksandrov Acked-by: Jay Vosburgh Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20260218060919.101574-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 02baf80d1e333fc8aa68d6ce6cecc3ec216ed5c0 Author: Vikas Gupta Date: Wed Feb 18 10:57:55 2026 +0530 bnge: fix reserving resources from FW [ Upstream commit 604530085b2ef484843c723a105b6fd3218b4710 ] HWRM_FUNC_CFG is used to reserve resources, whereas HWRM_FUNC_QCFG is intended for querying resource information from the firmware. Since __bnge_hwrm_reserve_pf_rings() reserves resources for a specific PF, the command type should be HWRM_FUNC_CFG. Fixes: 627c67f038d2 ("bng_en: Add resource management support") Signed-off-by: Vikas Gupta Reviewed-by: Bhargava Chenna Marreddy Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260218052755.4097468-1-vikas.gupta@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f5a1f13c9e0fdd7e63a79df585dbb3fa2f306596 Author: Dimitri Daskalakis Date: Tue Feb 17 19:06:20 2026 -0800 eth: fbnic: Advertise supported XDP features. [ Upstream commit e977fcb3a318b53b47f23b44ac237fceb1b731fe ] Drivers are supposed to advertise the XDP features they support. This was missed while adding XDP support. Before: $ ynl --family netdev --dump dev-get ... {'ifindex': 3, 'xdp-features': set(), 'xdp-rx-metadata-features': set(), 'xsk-features': set()}, ... After: $ ynl --family netdev --dump dev-get ... {'ifindex': 3, 'xdp-features': {'basic', 'rx-sg'}, 'xdp-rx-metadata-features': set(), 'xsk-features': set()}, ... Fixes: 168deb7b31b2 ("eth: fbnic: Add support for XDP_TX action") Signed-off-by: Jakub Kicinski Signed-off-by: Dimitri Daskalakis Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260218030620.3329608-1-dimitri.daskalakis1@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 72726d22786bb5b4860e2a5acf0d5824b5744e8d Author: Hariprasad Kelam Date: Mon Feb 16 14:33:38 2026 +0530 octeontx2-af: Fix default entries mcam entry action [ Upstream commit 45be47bf5d7db0f762a93e9c0ede6cb3c91edf3b ] As per design, AF should update the default MCAM action only when mcam_index is -1. A bug in the previous patch caused default entries to be changed even when the request was not for them. Fixes: 570ba37898ec ("octeontx2-af: Update RSS algorithm index") Signed-off-by: Hariprasad Kelam Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260216090338.1318976-1-hkelam@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9be9100774b51b3f88424a4a708181c817e3b46b Author: Eric Dumazet Date: Mon Feb 16 14:28:30 2026 +0000 ipv6: icmp: remove obsolete code in icmpv6_xrlim_allow() [ Upstream commit 0201eedb69b24a6be9b7c1716287a89c4dde2320 ] Following part was needed before the blamed commit, because inet_getpeer_v6() second argument was the prefix. /* Give more bandwidth to wider prefixes. */ if (rt->rt6i_dst.plen < 128) tmo >>= ((128 - rt->rt6i_dst.plen)>>5); Now inet_getpeer_v6() retrieves hosts, we need to remove @tmo adjustement or wider prefixes likes /24 allow 8x more ICMP to be sent for a given ratelimit. As we had this issue for a while, this patch changes net.ipv6.icmp.ratelimit default value from 1000ms to 100ms to avoid potential regressions. Also add a READ_ONCE() when reading net->ipv6.sysctl.icmpv6_time. Fixes: fd0273d7939f ("ipv6: Remove external dependency on rt6i_dst and rt6i_src") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Cc: Martin KaFai Lau Link: https://patch.msgid.link/20260216142832.3834174-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 66036be40f7f72a3dbed1c70614e5b8d17a40ed2 Author: Eric Dumazet Date: Mon Feb 16 14:28:29 2026 +0000 inet: move icmp_global_{credit,stamp} to a separate cache line [ Upstream commit 87b08913a9ae82082e276d237ece08fc8ee24380 ] icmp_global_credit was meant to be changed ~1000 times per second, but if an admin sets net.ipv4.icmp_msgs_per_sec to a very high value, icmp_global_credit changes can inflict false sharing to surrounding fields that are read mostly. Move icmp_global_credit and icmp_global_stamp to a separate cacheline aligned group. Fixes: b056b4cd9178 ("icmp: move icmp_global.credit and icmp_global.stamp to per netns storage") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260216142832.3834174-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2c7384dbfd6a4cfc2f31c82301aa75f31d7e9c56 Author: Eric Dumazet Date: Mon Feb 16 14:28:28 2026 +0000 icmp: prevent possible overflow in icmp_global_allow() [ Upstream commit 034bbd806298e9ba4197dd1587b0348ee30996ea ] Following expression can overflow if sysctl_icmp_msgs_per_sec is big enough. sysctl_icmp_msgs_per_sec * delta / HZ; Fixes: 4cdf507d5452 ("icmp: add a global rate limitation") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260216142832.3834174-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d7eaa006c0444a5d4671be7efe6dbb33ef8b515e Author: Dimitri Daskalakis Date: Sat Feb 14 09:19:49 2026 -0800 eth: fbnic: Add validation for MTU changes [ Upstream commit ccd8e87748ad083047d6c8544c5809b7f96cc8df ] Increasing the MTU beyond the HDS threshold causes the hardware to fragment packets across multiple buffers. If a single-buffer XDP program is attached, the driver will drop all multi-frag frames. While we can't prevent a remote sender from sending non-TCP packets larger than the MTU, this will prevent users from inadvertently breaking new TCP streams. Traditionally, drivers supported XDP with MTU less than 4Kb (packet per page). Fbnic currently prevents attaching XDP when MTU is too high. But it does not prevent increasing MTU after XDP is attached. Fixes: 1b0a3950dbd4 ("eth: fbnic: Add XDP pass, drop, abort support") Signed-off-by: Jakub Kicinski Signed-off-by: Dimitri Daskalakis Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d34f7a8aa9a25b7e64e0e46e444697c0f702374d Author: Eric Dumazet Date: Fri Feb 13 14:25:57 2026 +0000 macvlan: observe an RCU grace period in macvlan_common_newlink() error path [ Upstream commit e3f000f0dee1bfab52e2e61ca6a3835d9e187e35 ] valis reported that a race condition still happens after my prior patch. macvlan_common_newlink() might have made @dev visible before detecting an error, and its caller will directly call free_netdev(dev). We must respect an RCU period, either in macvlan or the core networking stack. After adding a temporary mdelay(1000) in macvlan_forward_source_one() to open the race window, valis repro was: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source (ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 &) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56 data bytes RTNETLINK answers: Invalid argument BUG: KASAN: slab-use-after-free in macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) Read of size 8 at addr ffff888016bb89c0 by task e/175 CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) kasan_report (mm/kasan/report.c:597) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) ? tasklet_init (kernel/softirq.c:983) macvlan_handle_frame (drivers/net/macvlan.c:501) Allocated by task 169: kasan_save_stack (mm/kasan/common.c:58) kasan_save_track (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) __kasan_kmalloc (mm/kasan/common.c:419) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5657 mm/slub.c:7140) alloc_netdev_mqs (net/core/dev.c:12012) rtnl_create_link (net/core/rtnetlink.c:3648) rtnl_newlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlink_rcv_msg (net/core/rtnetlink.c:6958) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131) Freed by task 169: kasan_save_stack (mm/kasan/common.c:58) kasan_save_track (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) kasan_save_free_info (mm/kasan/generic.c:587) __kasan_slab_free (mm/kasan/common.c:287) kfree (mm/slub.c:6674 mm/slub.c:6882) rtnl_newlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlink_rcv_msg (net/core/rtnetlink.c:6958) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131) Fixes: f8db6475a836 ("macvlan: fix error recovery in macvlan_common_newlink()") Signed-off-by: Eric Dumazet Reported-by: valis Link: https://patch.msgid.link/20260213142557.3059043-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2a06576b611e26cd0284ab138331bcd85785ea04 Author: Jakub Kicinski Date: Fri Feb 13 19:51:59 2026 -0800 selftests: tc_actions: don't dump 2MB of \0 to stdout [ Upstream commit 32b70e62034aa72f8414ad4e9122cce7ad418c48 ] Since we started running selftests in NIPA we have been seeing tc_actions.sh generate a soft lockup warning on ~20% of the runs. On the pre-netdev foundation setup it was actually a missed irq splat from the console. Now it's either that or a lockup. I initially suspected a socket locking issue since the test is exercising local loopback with act_mirred. After hours of staring at this I noticed in strace that ncat when -o $file is specified _both_ saves the output to the file and still prints it to stdout. Because the file being sent is constructed with: dd conv=sparse status=none if=/dev/zero bs=1M count=2 of=$mirred ^^^^^^^^^ the data printed is all \0. Most terminals don't display nul characters (and neither does vng output capture save them). But QEMU's serial console still has to poke them thru which is very slow and causes the lockup (if the file is >600kB). Replace the '-o $file' with '> $file'. This speeds the test up from 2m20s to 18s on debug kernels, and prevents the warnings. Fixes: ca22da2fbd69 ("act_mirred: use the backlog for nested calls to mirred ingress") Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260214035159.2119699-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d96b0d661ef0434b644ed48901e916bd9fe5f64a Author: Eric Dumazet Date: Mon Feb 16 10:01:49 2026 +0000 ping: annotate data-races in ping_lookup() [ Upstream commit ad5dfde2a5733aaf652ea3e40c8c5e071e935901 ] isk->inet_num, isk->inet_rcv_saddr and sk->sk_bound_dev_if are read locklessly in ping_lookup(). Add READ_ONCE()/WRITE_ONCE() annotations. The race on isk->inet_rcv_saddr is probably coming from IPv6 support, but does not deserve a specific backport. Fixes: dbca1596bbb0 ("ping: convert to RCU lookups, get rid of rwlock") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260216100149.3319315-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4e34deebfb880111e318db0cbb81b36e57335521 Author: Arnd Bergmann Date: Mon Feb 16 11:54:54 2026 +0100 net: psp: select CONFIG_SKB_EXTENSIONS [ Upstream commit 6e980df452169f82674f2e650079c1fe0aee343d ] psp now uses skb extensions, failing to build when that is disabled: In file included from include/net/psp.h:7, from net/psp/psp_sock.c:9: include/net/psp/functions.h: In function '__psp_skb_coalesce_diff': include/net/psp/functions.h:60:13: error: implicit declaration of function 'skb_ext_find'; did you mean 'skb_ext_copy'? [-Wimplicit-function-declaration] 60 | a = skb_ext_find(one, SKB_EXT_PSP); | ^~~~~~~~~~~~ | skb_ext_copy include/net/psp/functions.h:60:31: error: 'SKB_EXT_PSP' undeclared (first use in this function) 60 | a = skb_ext_find(one, SKB_EXT_PSP); | ^~~~~~~~~~~ include/net/psp/functions.h:60:31: note: each undeclared identifier is reported only once for each function it appears in include/net/psp/functions.h: In function '__psp_sk_rx_policy_check': include/net/psp/functions.h:94:53: error: 'SKB_EXT_PSP' undeclared (first use in this function) 94 | struct psp_skb_ext *pse = skb_ext_find(skb, SKB_EXT_PSP); | ^~~~~~~~~~~ net/psp/psp_sock.c: In function 'psp_sock_recv_queue_check': net/psp/psp_sock.c:164:41: error: 'SKB_EXT_PSP' undeclared (first use in this function) 164 | pse = skb_ext_find(skb, SKB_EXT_PSP); | ^~~~~~~~~~~ Select the Kconfig symbol as we do from its other users. Fixes: 6b46ca260e22 ("net: psp: add socket security association code") Signed-off-by: Arnd Bergmann Reviewed-by: Simon Horman Reviewed-by: Daniel Zahka Link: https://patch.msgid.link/20260216105500.2382181-1-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5c939ebbd72f4e3ae6d1426afa243c1ffa5877f8 Author: Jakub Kicinski Date: Tue Feb 17 11:41:50 2026 -0800 bpftool: Fix truncated netlink dumps [ Upstream commit 3b39d73cc3379360a33eb583b17f21fe55e1288e ] Netlink requires that the recv buffer used during dumps is at least min(PAGE_SIZE, 8k) (see the man page). Otherwise the messages will get truncated. Make sure bpftool follows this requirement, avoid missing information on systems with large pages. Acked-by: Quentin Monnet Fixes: 7084566a236f ("tools/bpftool: Remove libbpf_internal.h usage in bpftool") Signed-off-by: Jakub Kicinski Link: https://lore.kernel.org/r/20260217194150.734701-1-kuba@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 71b5fc8e8e17eace1304cec7d080e56a6c2d507d Author: Eric Dumazet Date: Mon Feb 16 10:22:02 2026 +0000 ipv6: fix a race in ip6_sock_set_v6only() [ Upstream commit 452a3eee22c57a5786ae6db5c97f3b0ec13bb3b7 ] It is unlikely that this function will be ever called with isk->inet_num being not zero. Perform the check on isk->inet_num inside the locked section for complete safety. Fixes: 9b115749acb24 ("ipv6: add ip6_sock_set_v6only") Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Reviewed-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260216102202.3343588-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dbd0af8083dd201f07c49110b2ee93710abdff28 Author: Inseo An Date: Tue Feb 17 21:14:40 2026 +0900 netfilter: nf_tables: fix use-after-free in nf_tables_addchain() [ Upstream commit 71e99ee20fc3f662555118cf1159443250647533 ] nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed. Fixes: 91c7b38dc9f0 ("netfilter: nf_tables: use new transaction infrastructure to handle chain") Signed-off-by: Inseo An Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 50422613185d505201167e8bdd2f2700790d5db6 Author: Pablo Neira Ayuso Date: Tue Feb 17 12:56:39 2026 +0100 net: remove WARN_ON_ONCE when accessing forward path array [ Upstream commit 008e7a7c293b30bc43e4368dac6ea3808b75a572 ] Although unlikely, recent support for IPIP tunnels increases chances of reaching this WARN_ON_ONCE if userspace manages to build a sufficiently long forward path. Remove it. Fixes: ddb94eafab8b ("net: resolve forwarding path from virtual netdevice and HW destination address") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit bae53b3baf2ff2f45f9205c438818fc055601a54 Author: Julian Anastasov Date: Sat Feb 14 16:58:50 2026 +0200 ipvs: do not keep dest_dst if dev is going down [ Upstream commit 8fde939b0206afc1d5846217a01a16b9bc8c7896 ] There is race between the netdev notifier ip_vs_dst_event() and the code that caches dst with dev that is going down. As the FIB can be notified for the closed device after our handler finishes, it is possible valid route to be returned and cached resuling in a leaked dev reference until the dest is not removed. To prevent new dest_dst to be attached to dest just after the handler dropped the old one, add a netif_running() check to make sure the notifier handler is not currently running for device that is closing. Fixes: 7a4f0761fce3 ("IPVS: init and cleanup restructuring") Signed-off-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 9a6b2ba7367f473b9827e78bbefadb1556083ff7 Author: Florian Westphal Date: Wed Feb 11 12:53:09 2026 +0100 netfilter: nf_conntrack_h323: don't pass uninitialised l3num value [ Upstream commit a6d28eb8efe96b3e35c92efdf1bfacb0cccf541f ] Mihail Milev reports: Error: UNINIT (CWE-457): net/netfilter/nf_conntrack_h323_main.c:1189:2: var_decl: Declaring variable "tuple" without initializer. net/netfilter/nf_conntrack_h323_main.c:1197:2: uninit_use_in_call: Using uninitialized value "tuple.src.l3num" when calling "__nf_ct_expect_find". net/netfilter/nf_conntrack_expect.c:142:2: read_value: Reading value "tuple->src.l3num" when calling "nf_ct_expect_dst_hash". 1195| tuple.dst.protonum = IPPROTO_TCP; 1196| 1197|-> exp = __nf_ct_expect_find(net, nf_ct_zone(ct), &tuple); 1198| if (exp && exp->master == ct) 1199| return exp; Switch this to a C99 initialiser and set the l3num value. Fixes: f587de0e2feb ("[NETFILTER]: nf_conntrack/nf_nat: add H.323 helper port") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 96815220626b291d3497c4c051062228a1fccca3 Author: Aleksei Oladko Date: Fri Feb 13 13:19:06 2026 +0000 selftests: forwarding: vxlan_bridge_1d_ipv6: fix test failure with br_netfilter enabled [ Upstream commit ce9f6aec0fb780dafc1dfc5f47c688422aff464a ] The test generates VXLAN traffic using mausezahn, where the encapsulated inner IPv6 packet has an incorrect payload length set in the IPv6 header. After VXLAN decapsulation, such packets do not pass sanity checks in br_netfilter and are dropped, which causes the test to fail. Fix this by setting the correct IPv6 payload length for the encapsulated packet generated by mausezahn, so that the packet is accepted by br_netfilter. tools/testing/selftests/net/forwarding/vxlan_bridge_1d_ipv6.sh lines 698-706 )"00:03:"$( : Payload length )"3a:"$( : Next header )"04:"$( : Hop limit )"$saddr:"$( : IP saddr )"$daddr:"$( : IP daddr )"80:"$( : ICMPv6.type )"00:"$( : ICMPv6.code )"00:"$( : ICMPv6.checksum ) Data after IPv6 header: • 80: — 1 byte (ICMPv6 type) • 00: — 1 byte (ICMPv6 code) • 00: — 1 byte (ICMPv6 checksum, truncated) Total: 3 bytes → 00:03 is correct. The old value 00:08 did not match the actual payload size. Fixes: b07e9957f220 ("selftests: forwarding: Add VxLAN tests with a VLAN-unaware bridge for IPv6") Signed-off-by: Aleksei Oladko Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260213131907.43351-3-aleksey.oladko@virtuozzo.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a6187e1d47f35f6e0b7cc0c0bca5b8f46dcadfb1 Author: Aleksei Oladko Date: Fri Feb 13 13:19:05 2026 +0000 selftests: forwarding: vxlan_bridge_1d: fix test failure with br_netfilter enabled [ Upstream commit 02cb2e6bacbb08ebf6acb61be816efd11e1f4a21 ] The test generates VXLAN traffic using mausezahn, where the encapsulated inner IPv4 packet contains a zero IP header checksum. After VXLAN decapsulation, such packets do not pass sanity checks in br_netfilter and are dropped, which causes the test to fail. Fix this by calculating and setting a valid IPv4 header checksum for the encapsulated packet generated by mausezahn, so that the packet is accepted by br_netfilter. Fixed by using the payload_template_calc_checksum() / payload_template_expand_checksum() helpers that are only available in v6.3 and newer kernels. Fixes: a0b61f3d8ebf ("selftests: forwarding: vxlan_bridge_1d: Add an ECN decap test") Signed-off-by: Aleksei Oladko Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260213131907.43351-2-aleksey.oladko@virtuozzo.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit fae260fc84e1eae8f590c7907e53e8768df2d986 Author: Nikolay Aleksandrov Date: Fri Feb 13 09:00:30 2026 +0200 net: bridge: mcast: always update mdb_n_entries for vlan contexts [ Upstream commit 8b769e311a86bb9d15c5658ad283b86fc8f080a2 ] syzbot triggered a warning[1] about the number of mdb entries in a context. It turned out that there are multiple ways to trigger that warning today (some got added during the years), the root cause of the problem is that the increase is done conditionally, and over the years these different conditions increased so there were new ways to trigger the warning, that is to do a decrease which wasn't paired with a previous increase. For example one way to trigger it is with flush: $ ip l add br0 up type bridge vlan_filtering 1 mcast_snooping 1 $ ip l add dumdum up master br0 type dummy $ bridge mdb add dev br0 port dumdum grp 239.0.0.1 permanent vid 1 $ ip link set dev br0 down $ ip link set dev br0 type bridge mcast_vlan_snooping 1 ^^^^ this will enable snooping, but will not update mdb_n_entries because in __br_multicast_enable_port_ctx() we check !netif_running $ bridge mdb flush dev br0 ^^^ this will trigger the warning because it will delete the pg which we added above, which will try to decrease mdb_n_entries Fix the problem by removing the conditional increase and always keep the count up-to-date while the vlan exists. In order to do that we have to first initialize it on port-vlan context creation, and then always increase or decrease the value regardless of mcast options. To keep the current behaviour we have to enforce the mdb limit only if the context is port's or if the port-vlan's mcast snooping is enabled. [1] ------------[ cut here ]------------ n == 0 WARNING: net/bridge/br_multicast.c:718 at br_multicast_port_ngroups_dec_one net/bridge/br_multicast.c:718 [inline], CPU#0: syz.4.4607/22043 WARNING: net/bridge/br_multicast.c:718 at br_multicast_port_ngroups_dec net/bridge/br_multicast.c:771 [inline], CPU#0: syz.4.4607/22043 WARNING: net/bridge/br_multicast.c:718 at br_multicast_del_pg+0x1bbe/0x1e20 net/bridge/br_multicast.c:825, CPU#0: syz.4.4607/22043 Modules linked in: CPU: 0 UID: 0 PID: 22043 Comm: syz.4.4607 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:br_multicast_port_ngroups_dec_one net/bridge/br_multicast.c:718 [inline] RIP: 0010:br_multicast_port_ngroups_dec net/bridge/br_multicast.c:771 [inline] RIP: 0010:br_multicast_del_pg+0x1bbe/0x1e20 net/bridge/br_multicast.c:825 Code: 41 5f 5d e9 04 7a 48 f7 e8 3f 73 5c f7 90 0f 0b 90 e9 cf fd ff ff e8 31 73 5c f7 90 0f 0b 90 e9 16 fd ff ff e8 23 73 5c f7 90 <0f> 0b 90 e9 60 fd ff ff e8 15 73 5c f7 eb 05 e8 0e 73 5c f7 48 8b RSP: 0018:ffffc9000c207220 EFLAGS: 00010293 RAX: ffffffff8a68042d RBX: ffff88807c6f1800 RCX: ffff888066e90000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff888066e90000 R09: 000000000000000c R10: 000000000000000c R11: 0000000000000000 R12: ffff8880303ef800 R13: dffffc0000000000 R14: ffff888050eb11c4 R15: 1ffff1100a1d6238 FS: 00007fa45921b6c0(0000) GS:ffff8881256f5000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa4591f9ff8 CR3: 0000000081df2000 CR4: 00000000003526f0 Call Trace: br_mdb_flush_pgs net/bridge/br_mdb.c:1525 [inline] br_mdb_flush net/bridge/br_mdb.c:1544 [inline] br_mdb_del_bulk+0x5e2/0xb20 net/bridge/br_mdb.c:1561 rtnl_mdb_del+0x48a/0x640 net/core/rtnetlink.c:-1 rtnetlink_rcv_msg+0x77e/0xbe0 net/core/rtnetlink.c:6967 netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2646 __sys_sendmsg net/socket.c:2678 [inline] __do_sys_sendmsg net/socket.c:2683 [inline] __se_sys_sendmsg net/socket.c:2681 [inline] __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa45839aeb9 Code: ff 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 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fa45921b028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fa458615fa0 RCX: 00007fa45839aeb9 RDX: 0000000000000000 RSI: 00002000000000c0 RDI: 0000000000000004 RBP: 00007fa458408c1f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa458616038 R14: 00007fa458615fa0 R15: 00007fff0b59fae8 Fixes: b57e8d870d52 ("net: bridge: Maintain number of MDB entries in net_bridge_mcast_port") Reported-by: syzbot+d5d1b7343531d17bd3c5@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/aYrWbRp83MQR1ife@debil/T/#t Reviewed-by: Ido Schimmel Signed-off-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260213070031.1400003-2-nikolay@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 024355273593735c5f0a8c2faf5dfdcd758c4908 Author: Allison Henderson Date: Thu Feb 12 20:54:09 2026 -0700 net/rds: rds_sendmsg should not discard payload_len [ Upstream commit da29e453dcb3aa7cabead7915f5f945d0add3a52 ] Commit 3db6e0d172c9 ("rds: use RCU to synchronize work-enqueue with connection teardown") modifies rds_sendmsg to avoid enqueueing work while a tear down is in progress. However, it also changed the return value of rds_sendmsg to that of rds_send_xmit instead of the payload_len. This means the user may incorrectly receive errno values when it should have simply received a payload of 0 while the peer attempts a reconnections. So this patch corrects the teardown handling code to only use the out error path in that case, thus restoring the original payload_len return value. Fixes: 3db6e0d172c9 ("rds: use RCU to synchronize work-enqueue with connection teardown") Reviewed-by: Simon Horman Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260213035409.1963391-1-achender@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 654780dee9eae419e1648ea58462c4efe54518fa Author: Ziyi Guo Date: Thu Feb 12 22:40:40 2026 +0000 xen-netback: reject zero-queue configuration from guest [ Upstream commit 6d1dc8014334c7fb25719999bca84d811e60a559 ] A malicious or buggy Xen guest can write "0" to the xenbus key "multi-queue-num-queues". The connect() function in the backend only validates the upper bound (requested_num_queues > xenvif_max_queues) but not zero, allowing requested_num_queues=0 to reach vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers WARN_ON_ONCE(!size) in __vmalloc_node_range(). On systems with panic_on_warn=1, this allows a guest-to-host denial of service. The Xen network interface specification requires the queue count to be "greater than zero". Add a zero check to match the validation already present in xen-blkback, which has included this guard since its multi-queue support was added. Fixes: 8d3d53b3e433 ("xen-netback: Add support for multiple queues") Signed-off-by: Ziyi Guo Reviewed-by: Juergen Gross Link: https://patch.msgid.link/20260212224040.86674-1-n7l8m4@u.northwestern.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 36c28b028efba0f42218d41fed12c47ce217c1f1 Author: Ziyi Guo Date: Thu Feb 12 21:41:54 2026 +0000 net: usb: catc: enable basic endpoint checking [ Upstream commit 9e7021d2aeae57c323a6f722ed7915686cdcc123 ] catc_probe() fills three URBs with hardcoded endpoint pipes without verifying the endpoint descriptors: - usb_sndbulkpipe(usbdev, 1) and usb_rcvbulkpipe(usbdev, 1) for TX/RX - usb_rcvintpipe(usbdev, 2) for interrupt status A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes. Add a catc_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls after usb_set_interface() to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time. Similar to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") which fixed the issue in rtl8150. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Simon Horman Signed-off-by: Ziyi Guo Link: https://patch.msgid.link/20260212214154.3609844-1-n7l8m4@u.northwestern.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f998b2c4bec487063a586695159f9a1856e81c56 Author: Antonio Quartulli Date: Thu Feb 12 22:31:19 2026 +0100 ovpn: tcp - don't deref NULL sk_socket member after tcp_close() [ Upstream commit 94560267d6c41b1ff3fafbab726e3f8a55a6af34 ] When deleting a peer in case of keepalive expiration, the peer is removed from the OpenVPN hashtable and is temporary inserted in a "release list" for further processing. This happens in: ovpn_peer_keepalive_work() unlock_ovpn(release_list) This processing includes detaching from the socket being used to talk to this peer, by restoring its original proto and socket ops/callbacks. In case of TCP it may happen that, while the peer is sitting in the release list, userspace decides to close the socket. This will result in a concurrent execution of: tcp_close(sk) __tcp_close(sk) sock_orphan(sk) sk_set_socket(sk, NULL) The last function call will set sk->sk_socket to NULL. When the releasing routine is resumed, ovpn_tcp_socket_detach() will attempt to dereference sk->sk_socket to restore its original ops member. This operation will crash due to sk->sk_socket being NULL. Fix this race condition by testing-and-accessing sk->sk_socket atomically under sk->sk_callback_lock. Link: https://lore.kernel.org/netdev/176996279620.3109699.15382994681575380467@eldamar.lan/ Link: https://github.com/OpenVPN/ovpn-net-next/issues/29 Signed-off-by: Antonio Quartulli Fixes: 11851cbd60ea ("ovpn: implement TCP transport") Link: https://patch.msgid.link/20260212213130.11497-1-antonio@openvpn.net Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c55ba7501f97dd3ea80bcf233ba5035e534007f7 Author: Bobby Eshleman Date: Wed Feb 11 17:00:43 2026 -0800 eth: fbnic: set DMA_HINT_L4 for all flows [ Upstream commit 0f30a31b55c4179fc55613a75ef41d496687d465 ] fbnic always advertises ETHTOOL_TCP_DATA_SPLIT_ENABLED via ethtool .get_ringparam. To enable proper splitting for all flow types, even for IP/Ethernet flows, this patch sets DMA_HINT_L4 unconditionally for all RSS and NFC flow steering rules. According to the spec, L4 falls back to L3 if no valid L4 is found, and L3 falls back to L2 if no L3 is found. This makes sure that the correct header boundary is used regardless of traffic type. This is important for zero-copy use cases where we must ensure that all ZC packets are split correctly. Fixes: 2b30fc01a6c7 ("eth: fbnic: Add support for HDS configuration") Signed-off-by: Bobby Eshleman Link: https://patch.msgid.link/20260211-fbnic-tcp-hds-fixes-v1-3-55d050e6f606@meta.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit aa090d2346def2d4d45a9dfc687031bd0606d154 Author: Bobby Eshleman Date: Wed Feb 11 17:00:42 2026 -0800 eth: fbnic: increase FBNIC_HDR_BYTES_MIN from 128 to 256 bytes [ Upstream commit bd254115f38db3c046332bb62e8719e0dc7c2b53 ] Increase FBNIC_HDR_BYTES_MIN from 128 to 256 bytes. The previous minimum was too small to guarantee that very long L2+L3+L4 headers always fit within the header buffer. When EN_HDR_SPLIT is disabled and a packet exceeds MAX_HEADER_BYTES, splitting occurs at that byte offset instead of the header boundary, resulting in some of the header landing in the payload page. The increased minimum ensures headers always fit with the MAX_HEADER_BYTES cut off and land in the header page. Fixes: 2b30fc01a6c7 ("eth: fbnic: Add support for HDS configuration") Signed-off-by: Bobby Eshleman Acked-by: Mohsin Bashir Link: https://patch.msgid.link/20260211-fbnic-tcp-hds-fixes-v1-2-55d050e6f606@meta.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9f441ef914527fd94228e496c843af8e56ca278b Author: Bobby Eshleman Date: Wed Feb 11 17:00:41 2026 -0800 eth: fbnic: set FBNIC_QUEUE_RDE_CTL0_EN_HDR_SPLIT on RDE_CTL0 [ Upstream commit bbeb3bfbffe0279fa47c041658b037fb38a93965 ] Fix EN_HDR_SPLIT configuration by writing the field to RDE_CTL0 instead of RDE_CTL1. Because drop mode configuration and header splitting enablement both use RDE_CTL0, we consolidate these configurations into the single function fbnic_config_drop_mode. Fixes: 2b30fc01a6c7 ("eth: fbnic: Add support for HDS configuration") Signed-off-by: Bobby Eshleman Acked-by: Mohsin Bashir Link: https://patch.msgid.link/20260211-fbnic-tcp-hds-fixes-v1-1-55d050e6f606@meta.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9f9600daaa49ead8367396867c9009e367439947 Author: Mohsin Bashir Date: Thu Nov 13 15:26:10 2025 -0800 eth: fbnic: Configure RDE settings for pause frame [ Upstream commit 0135333914d63181f823bd340ae96737c8a820ca ] fbnic supports pause frames. When pause frames are enabled presumably user expects lossless operation from the NIC. Make sure we configure RDE (Rx DMA Engine) to DROP_NEVER mode to avoid discards due to delays in fetching Rx descriptors from the host. While at it enable DROP_NEVER when NIC only has a single queue configured. In this case the NIC acts as a FIFO so there's no risk of head-of-line blocking other queues by making RDE wait. If pause is disabled this just moves the packet loss from the DMA engine to the Rx buffer. Remove redundant call to fbnic_config_drop_mode_rcq(), introduced by commit 0cb4c0a13723 ("eth: fbnic: Implement Rx queue alloc/start/stop/free"). This call does not add value as fbnic_enable_rcq(), which is called immediately afterward, already handles this. Although we do not support autoneg at this time, preserve tx_pause in .mac_link_up instead of fbnic_phylink_get_pauseparam() Signed-off-by: Mohsin Bashir Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20251113232610.1151712-1-mohsin.bashr@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: bbeb3bfbffe0 ("eth: fbnic: set FBNIC_QUEUE_RDE_CTL0_EN_HDR_SPLIT on RDE_CTL0") Signed-off-by: Sasha Levin commit ca2a44b31c4d4de006430f3da18df2f8edd51733 Author: Anton Protopopov Date: Fri Feb 13 21:29:49 2026 +0000 bpf: Add a map/btf from a fd array more consistently [ Upstream commit b0b1a8583d8e797114e613139e3e3318a1704690 ] The add_fd_from_fd_array() function takes a file descriptor as a parameter and tries to add either map or btf to the corresponding list of used objects. As was reported by Dan Carpenter, since the commit c81e4322acf0 ("bpf: Fix a potential use-after-free of BTF object"), the fdget() is called twice on the file descriptor, and thus userspace, potentially, can replace the file pointed to by the file descriptor in between the two calls. On practice, this shouldn't break anything on the kernel side, but for consistency fix the code such that only one fdget() is executed. Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/aY689z7gHNv8rgVO@stanley.mountain/ Fixes: ccd2d799ed44 ("bpf: Fix a potential use-after-free of BTF object") Signed-off-by: Anton Protopopov Link: https://lore.kernel.org/r/20260213212949.759321-1-a.s.protopopov@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit eac65c272f3b49021a843cba5107d63627395e0e Author: Anton Protopopov Date: Mon Feb 9 13:29:04 2026 +0000 bpf: Fix a potential use-after-free of BTF object [ Upstream commit ccd2d799ed4467c07f5ee18c2f5c59bcc990822c ] Refcounting in the check_pseudo_btf_id() function is incorrect: the __check_pseudo_btf_id() function might get called with a zero refcounted btf. Fix this, and patch related code accordingly. v3: rephrase a comment (AI) v2: fix a refcount leak introduced in v1 (AI) Reported-by: syzbot+5a0f1995634f7c1dadbf@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5a0f1995634f7c1dadbf Fixes: 76145f725532 ("bpf: Refactor check_pseudo_btf_id") Signed-off-by: Anton Protopopov Link: https://lore.kernel.org/r/20260209132904.63908-1-a.s.protopopov@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 068708543a851d947dd173d6894b94338cec1860 Author: Amery Hung Date: Mon Feb 9 15:01:34 2026 -0800 libbpf: Fix invalid write loop logic in bpf_linker__add_buf() [ Upstream commit 04999b99e81eaa7b6223ec1c03af3bcb4ac57aaa ] Fix bpf_linker__add_buf()'s logic of copying data from memory buffer into memfd. In the event of short write not writing entire buf_sz bytes into memfd file, we'll append bytes from the beginning of buf *again* (corrupting ELF file contents) instead of correctly appending the rest of not-yet-read buf contents. Closes: https://github.com/libbpf/libbpf/issues/945 Fixes: 6d5e5e5d7ce1 ("libbpf: Extend linker API to support in-memory ELF files") Signed-off-by: Amery Hung Signed-off-by: Andrii Nakryiko Acked-by: Jiri Olsa Link: https://lore.kernel.org/bpf/20260209230134.3530521-1-ameryhung@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 223cfef4812bdfa5ac5c1aa761cdba03cfe2c9cd Author: Chengfeng Ye Date: Wed Feb 11 19:13:29 2026 +0000 fbnic: close fw_log race between users and teardown [ Upstream commit ee5492fd88cfc079c19fbeac78e9e53b7f6c04f3 ] Fixes a theoretical race on fw_log between the teardown path and fw_log write functions. fw_log is written inside fbnic_fw_log_write() and can be reached from the mailbox handler fbnic_fw_msix_intr(), but fw_log is freed before IRQ/MBX teardown during cleanup, resulting in a potential data race of dereferencing a freed/null variable. Possible Interleaving Scenario: CPU0: fbnic_fw_msix_intr() // Entry fbnic_fw_log_write() if (fbnic_fw_log_ready()) // true ... preempt ... CPU1: fbnic_remove() // Entry fbnic_fw_log_free() vfree(log->data_start); log->data_start = NULL; CPU0: continues, walks log->entries or writes to log->data_start The initialization also has an incorrect order problem, as the fw_log is currently allocated after MBX setup during initialization. Fix the problems by adjusting the synchronization order to put initialization in place before the mailbox is enabled, and not cleared until after the mailbox has been disabled. Fixes: ecc53b1b46c89 ("eth: fbnic: Enable firmware logging") Signed-off-by: Chengfeng Ye Link: https://patch.msgid.link/20260211191329.530886-1-dg573847474@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 37954733984f647790cf7e615244ab19b39773d9 Author: Daniel Machon Date: Thu Feb 12 12:02:30 2026 +0100 net: sparx5/lan969x: fix PTP clock max_adj value [ Upstream commit a49d2a2c37a6252c41cbdd505f9d1c58d5a3817a ] The max_adj field in ptp_clock_info tells userspace how much the PHC clock frequency can be adjusted. ptp4l reads this and will never request a correction larger than max_adj. On both sparx5 and lan969x the clock offset may never converge because the servo needs a frequency correction larger than the current max_adj of 200000 (200 ppm) allows. The servo rails at the max and the offset stays in the tens of microseconds. The hardware has no inherent max adjustment limit; frequency correction is done by writing a 64-bit clock period increment to CLK_PER_CFG, and the register has plenty of range. The 200000 value was just an overly conservative software limit. The max_adj is shared between sparx5 and lan969x, and the increased value is safe for both. Fix this by increasing max_adj to 10000000 (10000 ppm), giving the servo sufficient headroom. Fixes: 0933bd04047c ("net: sparx5: Add support for ptp clocks") Signed-off-by: Daniel Machon Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260212-sparx5-ptp-max-adj-v2-v1-1-06b200e50ce3@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 03b5051e02f5a3772eee57493ad697d4b505b0c2 Author: Kuniyuki Iwashima Date: Wed Feb 11 17:50:21 2026 +0000 ipv6: Fix out-of-bound access in fib6_add_rt2node(). [ Upstream commit 8244f959e2c125c849e569f5b23ed49804cce695 ] syzbot reported out-of-bound read in fib6_add_rt2node(). [0] When IPv6 route is created with RTA_NH_ID, struct fib6_info does not have the trailing struct fib6_nh. The cited commit started to check !iter->fib6_nh->fib_nh_gw_family to ensure that rt6_qualify_for_ecmp() will return false for iter. If iter->nh is not NULL, rt6_qualify_for_ecmp() returns false anyway. Let's check iter->nh before reading iter->fib6_nh and avoid OOB read. [0]: BUG: KASAN: slab-out-of-bounds in fib6_add_rt2node+0x349c/0x3500 net/ipv6/ip6_fib.c:1142 Read of size 1 at addr ffff8880384ba6de by task syz.0.18/5500 CPU: 0 UID: 0 PID: 5500 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) 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+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xba/0x230 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 fib6_add_rt2node+0x349c/0x3500 net/ipv6/ip6_fib.c:1142 fib6_add_rt2node_nh net/ipv6/ip6_fib.c:1363 [inline] fib6_add+0x910/0x18c0 net/ipv6/ip6_fib.c:1531 __ip6_ins_rt net/ipv6/route.c:1351 [inline] ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3957 inet6_rtm_newroute+0x268/0x19e0 net/ipv6/route.c:5660 rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2646 __sys_sendmsg net/socket.c:2678 [inline] __do_sys_sendmsg net/socket.c:2683 [inline] __se_sys_sendmsg net/socket.c:2681 [inline] __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f9316b9aeb9 Code: ff 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 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd8809b678 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f9316e15fa0 RCX: 00007f9316b9aeb9 RDX: 0000000000000000 RSI: 0000200000004380 RDI: 0000000000000003 RBP: 00007f9316c08c1f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f9316e15fac R14: 00007f9316e15fa0 R15: 00007f9316e15fa0 Allocated by task 5499: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5657 [inline] __kmalloc_noprof+0x40c/0x7e0 mm/slub.c:5669 kmalloc_noprof include/linux/slab.h:961 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] fib6_info_alloc+0x30/0xf0 net/ipv6/ip6_fib.c:155 ip6_route_info_create+0x142/0x860 net/ipv6/route.c:3820 ip6_route_add+0x49/0x1b0 net/ipv6/route.c:3949 inet6_rtm_newroute+0x268/0x19e0 net/ipv6/route.c:5660 rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2646 __sys_sendmsg net/socket.c:2678 [inline] __do_sys_sendmsg net/socket.c:2683 [inline] __se_sys_sendmsg net/socket.c:2681 [inline] __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: bbf4a17ad9ff ("ipv6: Fix ECMP sibling count mismatch when clearing RTF_ADDRCONF") Reported-by: syzbot+707d6a5da1ab9e0c6f9d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/698cbfba.050a0220.2eeac1.009d.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Fernando Fernandez Mancera Reviewed-by: Shigeru Yoshida Link: https://patch.msgid.link/20260211175133.3657034-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d1410317337c91a9017d25fda15c4dfd71d3f79b Author: Pin-yen Lin Date: Mon Feb 9 16:59:36 2026 -0800 selftests: netconsole: Increase port listening timeout [ Upstream commit a68a9bd086c2822d0c629443bd16ad1317afe501 ] wait_for_port() can wait up to 2 seconds with the sleep and the polling in wait_local_port_listen() combined. So, in netcons_basic.sh, the socat process could die before the test writes to the netconsole. Increase the timeout to 3 seconds to make netcons_basic.sh pass consistently. Fixes: 3dc6c76391cb ("selftests: net: Add IPv6 support to netconsole basic tests") Signed-off-by: Pin-yen Lin Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260210005939.3230550-1-treapking@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a0070e9635fd5b2dcf616aa063395c8dae13e4e5 Author: Andre Carvalho Date: Sat Nov 29 12:24:19 2025 +0000 selftests: netconsole: remove log noise due to socat exit [ Upstream commit e3b8cbf40c6e60a7a935bd8980884d5741a7a77b ] This removes some noise that can be distracting while looking at selftests by redirecting socat stderr to /dev/null. Before this commit, netcons_basic would output: Running with target mode: basic (ipv6) 2025/11/29 12:08:03 socat[259] W exiting on signal 15 2025/11/29 12:08:03 socat[271] W exiting on signal 15 basic : ipv6 : Test passed Running with target mode: basic (ipv4) 2025/11/29 12:08:05 socat[329] W exiting on signal 15 2025/11/29 12:08:05 socat[322] W exiting on signal 15 basic : ipv4 : Test passed Running with target mode: extended (ipv6) 2025/11/29 12:08:08 socat[386] W exiting on signal 15 2025/11/29 12:08:08 socat[386] W exiting on signal 15 2025/11/29 12:08:08 socat[380] W exiting on signal 15 extended : ipv6 : Test passed Running with target mode: extended (ipv4) 2025/11/29 12:08:10 socat[440] W exiting on signal 15 2025/11/29 12:08:10 socat[435] W exiting on signal 15 2025/11/29 12:08:10 socat[435] W exiting on signal 15 extended : ipv4 : Test passed After these changes, output looks like: Running with target mode: basic (ipv6) basic : ipv6 : Test passed Running with target mode: basic (ipv4) basic : ipv4 : Test passed Running with target mode: extended (ipv6) extended : ipv6 : Test passed Running with target mode: extended (ipv4) extended : ipv4 : Test passed Signed-off-by: Andre Carvalho Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251129-netcons-socat-noise-v1-1-605a0cea8fca@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: a68a9bd086c2 ("selftests: netconsole: Increase port listening timeout") Signed-off-by: Sasha Levin commit 51c32ae7fae14552d79f7139614b77c1bbd57a48 Author: Ziyi Guo Date: Sun Feb 8 22:56:02 2026 +0000 net: mscc: ocelot: add missing lock protection in ocelot_port_xmit_inj() [ Upstream commit 026f6513c5880c2c89e38ad66bbec2868f978605 ] ocelot_port_xmit_inj() calls ocelot_can_inject() and ocelot_port_inject_frame() without holding the injection group lock. Both functions contain lockdep_assert_held() for the injection lock, and the correct caller felix_port_deferred_xmit() properly acquires the lock using ocelot_lock_inj_grp() before calling these functions. Add ocelot_lock_inj_grp()/ocelot_unlock_inj_grp() around the register injection path to fix the missing lock protection. The FDMA path is not affected as it uses its own locking mechanism. Fixes: c5e12ac3beb0 ("net: mscc: ocelot: serialize access to the injection/extraction groups") Signed-off-by: Ziyi Guo Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260208225602.1339325-4-n7l8m4@u.northwestern.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2a90d6b837003fba29395c8d1fe85c71a00555c4 Author: Ziyi Guo Date: Sun Feb 8 22:56:01 2026 +0000 net: mscc: ocelot: split xmit into FDMA and register injection paths [ Upstream commit 47f79b20e7fb885aa1623b759a68e8e27401ec4d ] Split ocelot_port_xmit() into two separate functions: - ocelot_port_xmit_fdma(): handles the FDMA injection path - ocelot_port_xmit_inj(): handles the register-based injection path The top-level ocelot_port_xmit() now dispatches to the appropriate function based on the ocelot_fdma_enabled static key. This is a pure refactor with no behavioral change. Separating the two code paths makes each one simpler and prepares for adding proper locking to the register injection path without affecting the FDMA path. Signed-off-by: Ziyi Guo Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260208225602.1339325-3-n7l8m4@u.northwestern.edu Signed-off-by: Jakub Kicinski Stable-dep-of: 026f6513c588 ("net: mscc: ocelot: add missing lock protection in ocelot_port_xmit_inj()") Signed-off-by: Sasha Levin commit 6eb26695a4b206bc41caf01680c38d407c75c7fd Author: Ziyi Guo Date: Sun Feb 8 22:56:00 2026 +0000 net: mscc: ocelot: extract ocelot_xmit_timestamp() helper [ Upstream commit 29372f07f7969a2f0490793226ecf6c8c6bde0fa ] Extract the PTP timestamp handling logic from ocelot_port_xmit() into a separate ocelot_xmit_timestamp() helper function. This is a pure refactor with no behavioral change. The helper returns false if the skb was consumed (freed) due to a timestamp request failure, and true if the caller should continue with frame injection. The rew_op value is returned via pointer. This prepares for splitting ocelot_port_xmit() into separate FDMA and register injection paths in a subsequent patch. Signed-off-by: Ziyi Guo Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260208225602.1339325-2-n7l8m4@u.northwestern.edu Signed-off-by: Jakub Kicinski Stable-dep-of: 026f6513c588 ("net: mscc: ocelot: add missing lock protection in ocelot_port_xmit_inj()") Signed-off-by: Sasha Levin commit fa79b29cc926cdedd44f11621b6db735cff303c8 Author: Daniel Machon Date: Tue Feb 10 14:44:01 2026 +0100 net: sparx5/lan969x: fix DWRR cost max to match hardware register width [ Upstream commit 6c28aa8dfdf24f554d4c5d4ff7d723a95360d94a ] DWRR (Deficit Weighted Round Robin) scheduling distributes bandwidth across traffic classes based on per-queue cost values, where lower cost means higher bandwidth share. The SPX5_DWRR_COST_MAX constant is 63 (6 bits) but the hardware register field HSCH_DWRR_ENTRY_DWRR_COST is GENMASK(24, 20), only 5 bits wide (max 31). This causes sparx5_weight_to_hw_cost() to compute cost values that silently overflow via FIELD_PREP, resulting in incorrect scheduling weights. Set SPX5_DWRR_COST_MAX to 31 to match the hardware register width. Fixes: 211225428d65 ("net: microchip: sparx5: add support for offloading ets qdisc") Signed-off-by: Daniel Machon Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260210-sparx5-fix-dwrr-cost-max-v1-1-58fbdbc25652@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b1f23df09e7dbf4c86b6908dff7efb8cb2b7d609 Author: Jie Zhang Date: Mon Feb 9 17:50:32 2026 -0500 net: stmmac: fix oops when split header is enabled [ Upstream commit babab1b42ed68877ef669a08384becf281ad2582 ] For GMAC4, when split header is enabled, in some rare cases, the hardware does not fill buf2 of the first descriptor with payload. Thus we cannot assume buf2 is always fully filled if it is not the last descriptor. Otherwise, the length of buf2 of the second descriptor will be calculated wrong and cause an oops: Unable to handle kernel paging request at virtual address ffff00019246bfc0 ... x2 : 0000000000000040 x1 : ffff00019246bfc0 x0 : ffff00009246c000 Call trace: dcache_inval_poc+0x28/0x58 (P) dma_direct_sync_single_for_cpu+0x38/0x6c __dma_sync_single_for_cpu+0x34/0x6c stmmac_napi_poll_rx+0x8f0/0xb60 __napi_poll.constprop.0+0x30/0x144 net_rx_action+0x160/0x274 handle_softirqs+0x1b8/0x1fc ... To fix this, the PL bit-field in RDES3 register is used for all descriptors, whether it is the last descriptor or not. Fixes: ec222003bd94 ("net: stmmac: Prepare to add Split Header support") Reviewed-by: Jacob Keller Signed-off-by: Jie Zhang Link: https://patch.msgid.link/20260209225037.589130-1-jie.zhang@analog.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9e9f1263e210d810f0bcc4d507a0be390a5dc0d1 Author: Russell King (Oracle) Date: Tue Oct 21 08:26:49 2025 +0100 net: stmmac: replace has_xxxx with core_type [ Upstream commit 26ab9830beabda863766be4a79dc590c7645f4d9 ] Replace the has_gmac, has_gmac4 and has_xgmac ints, of which only one can be set when matching a core to its driver backend, with an enumerated type carrying the DWMAC core type. Tested-by: Maxime Chevallier Signed-off-by: Russell King (Oracle) Acked-by: Chen-Yu Tsai Reviewed-by: Maxime Chevallier Tested-by: Mohd Ayaan Anwar Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/E1vB6ld-0000000BIPy-2Qi4@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Stable-dep-of: babab1b42ed6 ("net: stmmac: fix oops when split header is enabled") Signed-off-by: Sasha Levin commit ee231568d57dc1afa4781527f9eeaefc37b2bab1 Author: Russell King (Oracle) Date: Thu Oct 16 15:36:46 2025 +0100 net: stmmac: remove broken PCS code [ Upstream commit 813882ae22756bcf9645d405e045c60e5aab0a93 ] Changing the netif_carrier_*() state behind phylink's back has always been prohibited because it messes up with phylinks state tracking, and means that phylink no longer guarantees to call the mac_link_down() and mac_link_up() methods at the appropriate times. This was later documented in the sfp-phylink network driver conversion guide. stmmac was converted to phylink in 2019, but nothing was done with the "PCS" code. Since then, apart from the updates as part of phylink development, nothing has happened with stmmac to improve its use of phylink, or even to address this point. A couple of years ago, a has_integrated_pcs boolean was added by Bart, which later became the STMMAC_FLAG_HAS_INTEGRATED_PCS flag, to avoid manipulating the netif_carrier_*() state. This flag is mis-named, because whenever the stmmac is synthesized for its native SGMII, TBI or RTBI interfaces, it has an "integrated PCS". This boolean/flag actually means "ignore the status from the integrated PCS". Discussing with Bart, the reasons for this are lost to the winds of time (which is why we should always document the reasons in the commit message.) RGMII also has in-band status, and the dwmac cores and stmmac code supports this but with one bug that saves the day. When dwmac cores are synthesised for RGMII only, they do not contain an integrated PCS, and so priv->dma_cap.pcs is clear, which prevents (incorrectly) the "RGMII PCS" being used, meaning we don't read the in-band status. However, a core synthesised for RGMII and also SGMII, TBI or RTBI will have this capability bit set, thus making these code paths reachable. The Jetson Xavier NX uses RGMII mode to talk to its PHY, and removing the incorrect check for priv->dma_cap.pcs reveals the theortical issue with netif_carrier_*() manipulation is real: dwc-eth-dwmac 2490000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 dwc-eth-dwmac 2490000.ethernet eth0: PHY [stmmac-0:00] driver [RTL8211F Gigabit Ethernet] (irq=141) dwc-eth-dwmac 2490000.ethernet eth0: No Safety Features support found dwc-eth-dwmac 2490000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported dwc-eth-dwmac 2490000.ethernet eth0: registered PTP clock dwc-eth-dwmac 2490000.ethernet eth0: configuring for phy/rgmii-id link mode 8021q: adding VLAN 0 to HW filter on device eth0 dwc-eth-dwmac 2490000.ethernet eth0: Adding VLAN ID 0 is not supported Link is Up - 1000/Full Link is Down Link is Up - 1000/Full This looks good until one realises that the phylink "Link" status messages are missing, even when the RJ45 cable is reconnected. Nothing one can do results in the interface working. The interrupt handler (which prints those "Link is" messages) always wins over phylink's resolve worker, meaning phylink never calls the mac_link_up() nor mac_link_down() methods. eth0 also sees no traffic received, and is unable to obtain a DHCP address: 3: eth0: mtu 1500 qdisc mq state UP group defa ult qlen 1000 link/ether e6:d3:6a:e6:92:de brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 27686 149 0 0 0 0 With the STMMAC_FLAG_HAS_INTEGRATED_PCS flag set, which disables the netif_carrier_*() manipulation then stmmac works normally: dwc-eth-dwmac 2490000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 dwc-eth-dwmac 2490000.ethernet eth0: PHY [stmmac-0:00] driver [RTL8211F Gigabit Ethernet] (irq=141) dwc-eth-dwmac 2490000.ethernet eth0: No Safety Features support found dwc-eth-dwmac 2490000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported dwc-eth-dwmac 2490000.ethernet eth0: registered PTP clock dwc-eth-dwmac 2490000.ethernet eth0: configuring for phy/rgmii-id link mode 8021q: adding VLAN 0 to HW filter on device eth0 dwc-eth-dwmac 2490000.ethernet eth0: Adding VLAN ID 0 is not supported Link is Up - 1000/Full dwc-eth-dwmac 2490000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx and packets can be transferred. This clearly shows that when priv->hw->pcs is set, but STMMAC_FLAG_HAS_INTEGRATED_PCS is clear, the driver reliably fails. Discovering whether a platform falls into this is impossible as parsing all the dtsi and dts files to find out which use the stmmac driver, whether any of them use RGMII or SGMII and also depends whether an external interface is being used. The kernel likely doesn't contain all dts files either. The only driver that sets this flag uses the qcom,sa8775p-ethqos compatible, and uses SGMII or 2500BASE-X. but these are saved from this problem by the incorrect check for priv->dma_cap.pcs. So, we have to assume that for every other platform that uses SGMII with stmmac is using an external PCS. Moreover, ethtool output can be incorrect. With the full-duplex link negotiated, ethtool reports: Speed: 1000Mb/s Duplex: Half because with dwmac4, the full-duplex bit is in bit 16 of the status, priv->xstats.pcs_duplex becomes BIT(16) for full duplex, but the ethtool ksettings duplex member is u8 - so becomes zero. Moreover, the supported, advertised and link partner modes are all "not reported". Finally, ksettings_set() won't be able to set the advertisement on a PHY if this PCS code is activated, which is incorrect when SGMII is used with a PHY. Thus, remove: 1. the incorrect netif_carrier_*() manipulation. 2. the broken ethtool ksettings code. Given that all uses of STMMAC_FLAG_HAS_INTEGRATED_PCS are now gone, remove the flag from stmmac.h and dwmac-qcom-ethqos.c. Reviewed-by: Andrew Lunn Signed-off-by: Russell King (Oracle) Tested-by: Maxime Chevallier Tested-by: Lad Prabhakar Link: https://patch.msgid.link/E1v9P5y-0000000AolC-1QWH@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Stable-dep-of: babab1b42ed6 ("net: stmmac: fix oops when split header is enabled") Signed-off-by: Sasha Levin commit 87b7321ddc7d0ec93ef674bc2e9e1da78f9bf5b0 Author: Yue Haibing Date: Wed Feb 11 10:21:46 2026 +0800 selftests: net: lib: Fix jq parsing error [ Upstream commit 10ec0fc0ccc525abc807b0ca8ad5a26a0bd56361 ] The testcase failed as below: $./vlan_bridge_binding.sh ... + adf_ip_link_set_up d1 + local name=d1 + shift + ip_link_is_up d1 + ip_link_has_flag d1 UP + local name=d1 + shift + local flag=UP + shift ++ ip -j link show d1 ++ jq --arg flag UP 'any(.[].flags.[]; . == $flag)' jq: error: syntax error, unexpected '[', expecting FORMAT or QQSTRING_START (Unix shell quoting issues?) at , line 1: any(.[].flags.[]; . == $flag) jq: 1 compile error Remove the extra dot (.) after flags array to fix this. Fixes: 4baa1d3a5080 ("selftests: net: lib: Add ip_link_has_flag()") Signed-off-by: Yue Haibing Reviewed-by: Petr Machata Link: https://patch.msgid.link/20260211022146.190948-1-yuehaibing@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dfd9571c31ef1c94085beb08083a72e98173645f Author: Ido Schimmel Date: Mon Feb 9 14:53:53 2026 +0100 selftests: mlxsw: tc_restrictions: Fix test failure with new iproute2 [ Upstream commit a2646773a005b59fd1dc7ff3ba15df84889ca5d2 ] As explained in [1], iproute2 started rejecting tc-police burst sizes that result in an overflow. This can happen when the burst size is high enough and the rate is low enough. A couple of test cases specify such configurations, resulting in iproute2 errors and test failure. Fix by reducing the burst size so that the test will pass with both new and old iproute2 versions. [1] https://lore.kernel.org/netdev/20250916215731.3431465-1-jay.vosburgh@canonical.com/ Fixes: cb12d1763267 ("selftests: mlxsw: tc_restrictions: Test tc-police restrictions") Signed-off-by: Ido Schimmel Signed-off-by: Petr Machata Reviewed-by: Simon Horman Link: https://patch.msgid.link/88b00c6e85188aa6a065dc240206119b328c46e1.1770643998.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f4edf0c7d21695d3615493a76299e88c6ce0e8a6 Author: Ralf Lici Date: Fri Jan 30 18:32:50 2026 +0100 ovpn: fix VPN TX bytes counting [ Upstream commit b660b13d4c6379ca6360f24aaef8c5807fefd237 ] In ovpn_net_xmit, after GSO segmentation and segment processing, the first segment on the list is used to increment VPN TX statistics, which fails to account for any subsequent segments in the chain. Fix this by accumulating the length of every segment that successfully passes skb_share_check into a tx_bytes variable. This ensures the peer statistics accurately reflect the total data volume sent, regardless of whether the original packet was segmented. Fixes: 04ca14955f9a ("ovpn: store tunnel and transport statistics") Signed-off-by: Ralf Lici Reviewed-by: Sabrina Dubroca Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit 3e4fbcb4e078915367ba5576cd70d76dbc970f95 Author: Ralf Lici Date: Fri Jan 30 18:32:49 2026 +0100 ovpn: fix possible use-after-free in ovpn_net_xmit [ Upstream commit a5ec7baa44ea3a1d6aa0ca31c0ad82edf9affe41 ] When building the skb_list in ovpn_net_xmit, skb_share_check will free the original skb if it is shared. The current implementation continues to use the stale skb pointer for subsequent operations: - peer lookup, - skb_dst_drop (even though all segments produced by skb_gso_segment will have a dst attached), - ovpn_peer_stats_increment_tx. Fix this by moving the peer lookup and skb_dst_drop before segmentation so that the original skb is still valid when used. Return early if all segments fail skb_share_check and the list ends up empty. Also switch ovpn_peer_stats_increment_tx to use skb_list.next; the next patch fixes the stats logic. Fixes: 08857b5ec5d9 ("ovpn: implement basic TX path (UDP)") Signed-off-by: Ralf Lici Reviewed-by: Sabrina Dubroca Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit 6f076ba274e29e2ec1848ab8b86ce463613ad789 Author: Ralf Lici Date: Fri Jan 30 18:32:48 2026 +0100 ovpn: set sk_user_data before overriding callbacks [ Upstream commit 93686c472eb7b09a51b97a096449e7092fefcd1f ] During initialization, we override socket callbacks and set sk_user_data to an ovpn_socket instance. Currently, these two operations are decoupled: callbacks are overridden before sk_user_data is set. While existing callbacks perform safety checks for NULL or non-ovpn sk_user_data, this condition causes a "half-formed" state where valid packets arriving during attachment trigger error logs (e.g., "invoked on non ovpn socket"). Set sk_user_data before overriding the callbacks so that it can be accessed safely from them. Since we already check that the socket has no sk_user_data before setting it, this remains safe even if an interrupt accesses the socket after sk_user_data is set but before the callbacks are overridden. This also requires initializing all protocol-specific fields (such as tcp_tx_work and peer links) before calling ovpn_socket_attach, ensuring the ovpn_socket is fully formed before it becomes visible to any callback. Fixes: f6226ae7a0cd ("ovpn: introduce the ovpn_socket object") Signed-off-by: Ralf Lici Reviewed-by: Sabrina Dubroca Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit 63ae78336f40bcd9a44952a7c6bafb9c88a8effd Author: Aboorva Devarajan Date: Tue Feb 17 00:20:02 2026 +0530 cpuidle: Skip governor when only one idle state is available [ Upstream commit e5c9ffc6ae1bcdb1062527d611043681ac301aca ] On certain platforms (PowerNV systems without a power-mgt DT node), cpuidle may register only a single idle state. In cases where that single state is a polling state (state 0), the ladder governor may incorrectly treat state 1 as the first usable state and pass an out-of-bounds index. This can lead to a NULL enter callback being invoked, ultimately resulting in a system crash. [ 13.342636] cpuidle-powernv : Only Snooze is available [ 13.351854] Faulting instruction address: 0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668 Fix this by adding a bail-out in cpuidle_select() that returns state 0 directly when state_count <= 1, bypassing the governor and keeping the tick running. Fixes: dc2251bf98c6 ("cpuidle: Eliminate the CPUIDLE_DRIVER_STATE_START symbol") Signed-off-by: Aboorva Devarajan Reviewed-by: Christian Loehle Link: https://patch.msgid.link/20260216185005.1131593-2-aboorvad@linux.ibm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b800728a8aef66f1b89591d784ef20031648a794 Author: Zhai Can Date: Sun Feb 15 00:14:52 2026 +0800 ACPI: PM: Add unused power resource quirk for THUNDEROBOT ZERO [ Upstream commit cd7ef20ba8c6e936dba133b4136537a8ada22976 ] On the THUNDEROBOT ZERO laptop, the second NVMe slot and the discrete NVIDIA GPU are both controlled by power-resource PXP. Due to the SSDT table bug (lack of reference), PXP will be shut dow as an "unused" power resource during initialization, making the NVMe slot #2 + NVIDIA both inaccessible. This issue was introduced by commit a1224f34d72a ("ACPI: PM: Check states of power resources during initialization"). Here are test results on the three consecutive commits: (bad again!) a1224f34d72a ACPI: PM: Check states of power resources during initialization (good) bc2836859643 ACPI: PM: Do not turn off power resources in unknown state (bad) 519d81956ee2 Linux 5.15-rc6 On commit bc2836859643 ("ACPI: PM: Do not turn off power resources in unknown state") this was not an issue because the power resource state left UNKNOWN thus being ignored. See also commit 9b04d99788cf ("ACPI: PM: Do not turn of unused power resources on the Toshiba Click Mini") which is another almost identical case to this one. Fixes: a1224f34d72a ("ACPI: PM: Check states of power resources during initialization") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221087 Signed-off-by: Zhai Can Link: https://patch.msgid.link/20260214161452.2849346-1-bczhc0@126.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 43fcc84cd9710c2bc5a9abe6379a6d93e06344b4 Author: zhouwenhao Date: Mon Feb 2 21:28:46 2026 +0800 objpool: fix the overestimation of object pooling metadata size [ Upstream commit 5ed4b6b37c647d168ae31035b3f61b705997e043 ] objpool uses struct objpool_head to store metadata information, and its cpu_slots member points to an array of pointers that store the addresses of the percpu ring arrays. However, the memory size allocated during the initialization of cpu_slots is nr_cpu_ids * sizeof(struct objpool_slot). On a 64-bit machine, the size of struct objpool_slot is 16 bytes, which is twice the size of the actual pointer required, and the extra memory is never be used, resulting in a waste of memory. Therefore, the memory size required for cpu_slots needs to be corrected. Link: https://lkml.kernel.org/r/20260202132846.68257-1-zhouwenhao7600@gmail.com Fixes: b4edb8d2d464 ("lib: objpool added: ring-array based lockless MPMC") Signed-off-by: zhouwenhao Reviewed-by: Andrew Morton Cc: "Masami Hiramatsu (Google)" Cc: Matt Wu Cc: wuqiang.matt Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit f6bc23794fa050a278815c079a0c5520f66abc9b Author: Aristeu Rozanski Date: Mon Feb 2 09:38:05 2026 -0500 selftests/memfd: use IPC semaphore instead of SIGSTOP/SIGCONT [ Upstream commit b24335521de92fd2ee22460072b75367ca8860b0 ] selftests/memfd: use IPC semaphore instead of SIGSTOP/SIGCONT In order to synchronize new processes to test inheritance of memfd_noexec sysctl, memfd_test sets up the sysctl with a value before creating the new process. The new process then sends itself a SIGSTOP in order to wait for the parent to flip the sysctl value and send a SIGCONT signal. This would work as intended if it wasn't the fact that the new process is being created with CLONE_NEWPID, which creates a new PID namespace and the new process has PID 1 in this namespace. There're restrictions on sending signals to PID 1 and, although it's relaxed for other than root PID namespace, it's biting us here. In this specific case the SIGSTOP sent by the new process is ignored (no error to kill() is returned) and it never stops its execution. This is usually not noticiable as the parent usually manages to set the new sysctl value before the child has a chance to run and the test succeeds. But if you run the test in a loop, it eventually reproduces: while [ 1 ]; do ./memfd_test >log 2>&1 || break; done; cat log So this patch replaces the SIGSTOP/SIGCONT synchronization with IPC semaphore. Link: https://lkml.kernel.org/r/a7776389-b3d6-4b18-b438-0b0e3ed1fd3b@work Fixes: 6469b66e3f5a ("selftests: improve vm.memfd_noexec sysctl tests") Signed-off-by: Aristeu Rozanski Cc: Aleksa Sarai Cc: Shuah Khan Cc: liuye Cc: Lorenzo Stoakes Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit f056c340b73962ebaffe93997b582bdf16dc6270 Author: Josh Poimboeuf Date: Tue Feb 10 13:45:22 2026 -0800 kbuild: Add objtool to top-level clean target [ Upstream commit 68b4fe32d73789dea23e356f468de67c8367ef8f ] Objtool is an integral part of the build, make sure it gets cleaned by "make clean" and "make mrproper". Fixes: 442f04c34a1a ("objtool: Add tool to perform compile-time stack metadata validation") Reported-by: Jens Remus Closes: https://lore.kernel.org/15f2af3b-be33-46fc-b972-6b8e7e0aa52e@linux.ibm.com Signed-off-by: Josh Poimboeuf Tested-by: Jens Remus Link: https://patch.msgid.link/968faf2ed30fa8b3519f79f01a1ecfe7929553e5.1770759919.git.jpoimboe@kernel.org [nathan: use Closes: instead of Link: per checkpatch.pl] Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit ba16fb47e8975c4aa190e27cf18d1c1453be7e16 Author: Kuppuswamy Sathyanarayanan Date: Wed Feb 11 14:34:01 2026 -0800 powercap: intel_rapl_tpmi: Remove FW_BUG from invalid version check [ Upstream commit c7d54dafa042cf379859dba265fe5afef6fa8770 ] On partitioned systems, multiple TPMI instances may exist per package, but RAPL registers are only valid on one instance since RAPL has package-scope control. Other instances return invalid versions during domain parsing, which is expected behavior on such systems. Currently this generates a firmware bug warning: intel_rapl_tpmi: [Firmware Bug]: Invalid version Remove the FW_BUG tag, downgrade to pr_debug(), and update the message to clarify that invalid versions are expected on partitioned systems where only one instance can be valid. Fixes: 9eef7f9da928 ("powercap: intel_rapl: Introduce RAPL TPMI interface driver") Reported-by: Zhang Rui Signed-off-by: Kuppuswamy Sathyanarayanan Reviewed-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260211223401.1575776-1-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 02978747e90722651fb887116f55fd5710e59067 Author: Sean V Kelley Date: Wed Feb 11 21:22:54 2026 +0000 ACPI: CPPC: Fix remaining for_each_possible_cpu() to use online CPUs [ Upstream commit 56eb0c0ed345da7815274aa821a8546a073d7e97 ] per_cpu(cpc_desc_ptr, cpu) object is initialized for only the online CPUs via acpi_soft_cpu_online() --> __acpi_processor_start() --> acpi_cppc_processor_probe(). However, send_pcc_cmd() and acpi_get_psd_map() still iterate over all possible CPUs. In acpi_get_psd_map(), encountering an offline CPU returns -EFAULT, causing cppc_cpufreq initialization to fail. This breaks systems booted with "nosmt" or "nosmt=force". Fix by using for_each_online_cpu() in both functions. Fixes: 80b8286aeec0 ("ACPI / CPPC: support for batching CPPC requests") Signed-off-by: Sean V Kelley Link: https://patch.msgid.link/20260211212254.30190-1-skelley@nvidia.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 78942172d5bff4d4afed8674abc09cc560ce44a0 Author: Jiasheng Jiang Date: Sat Jan 17 16:50:24 2026 +0000 fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot [ Upstream commit b2bc7c44ed1779fc9eaab9a186db0f0d01439622 ] In the 'DeleteIndexEntryRoot' case of the 'do_action' function, the entry size ('esize') is retrieved from the log record without adequate bounds checking. Specifically, the code calculates the end of the entry ('e2') using: e2 = Add2Ptr(e1, esize); It then calculates the size for memmove using 'PtrOffset(e2, ...)', which subtracts the end pointer from the buffer limit. If 'esize' is maliciously large, 'e2' exceeds the used buffer size. This results in a negative offset which, when cast to size_t for memmove, interprets as a massive unsigned integer, leading to a heap buffer overflow. This commit adds a check to ensure that the entry size ('esize') strictly fits within the remaining used space of the index header before performing memory operations. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Signed-off-by: Jiasheng Jiang Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 4bf3bafb8e0635ed93e3cd4156dcbcc0fb960cb4 Author: Edward Adam Davis Date: Sun Dec 28 11:53:25 2025 +0800 fs/ntfs3: prevent infinite loops caused by the next valid being the same [ Upstream commit 27b75ca4e51e3e4554dc85dbf1a0246c66106fd3 ] When processing valid within the range [valid : pos), if valid cannot be retrieved correctly, for example, if the retrieved valid value is always the same, this can trigger a potential infinite loop, similar to the hung problem reported by syzbot [1]. Adding a check for the valid value within the loop body, and terminating the loop and returning -EINVAL if the value is the same as the current value, can prevent this. [1] INFO: task syz.4.21:6056 blocked for more than 143 seconds. Call Trace: rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244 inode_lock include/linux/fs.h:1027 [inline] ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284 Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Reported-by: syzbot+bcf9e1868c1a0c7e04f1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bcf9e1868c1a0c7e04f1 Signed-off-by: Edward Adam Davis Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 5a30cc03bde169ad558695b26da6ea7e55f6194a Author: Bartlomiej Kubik Date: Wed Nov 26 23:02:51 2025 +0100 fs/ntfs3: Initialize new folios before use [ Upstream commit f223ebffa185cc8da934333c5a31ff2d4f992dc9 ] KMSAN reports an uninitialized value in longest_match_std(), invoked from ntfs_compress_write(). When new folios are allocated without being marked uptodate and ni_read_frame() is skipped because the caller expects the frame to be completely overwritten, some reserved folios may remain only partially filled, leaving the rest memory uninitialized. Fixes: 584f60ba22f7 ("ntfs3: Convert ntfs_get_frame_pages() to use a folio") Tested-by: syzbot+08d8956768c96a2c52cf@syzkaller.appspotmail.com Reported-by: syzbot+08d8956768c96a2c52cf@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=08d8956768c96a2c52cf Signed-off-by: Bartlomiej Kubik Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 5e573e7783641c0c10734f1468889f14d495d7ab Author: Jens Axboe Date: Mon Feb 16 14:16:27 2026 -0700 io_uring/cancel: de-unionize file and user_data in struct io_cancel_data [ Upstream commit 22dbb0987bd1e0ec3b1e4ad20756a98f99aa4a08 ] By having them share the same space in struct io_cancel_data, it ends up disallowing IORING_ASYNC_CANCEL_FD|IORING_ASYNC_CANCEL_USERDATA from working. Eg you cannot match on both a file and user_data for cancelation purposes. This obviously isn't a common use case as nobody has reported this, but it does result in -ENOENT potentially being returned when trying to match on both, rather than actually doing what the API says it would. Fixes: 4bf94615b888 ("io_uring: allow IORING_OP_ASYNC_CANCEL with 'fd' key") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a9d157a9bd38e00d3cba8ff51f1b197acb4bcbc2 Author: Pavel Begunkov Date: Sun Feb 15 22:06:52 2026 +0000 io_uring: delay sqarray static branch disablement [ Upstream commit 56112578c71213a10c995a56835bddb5e9ab1ed0 ] io_key_has_sqarray static branch can be easily switched on/off by the user every time patching the kernel. That can be very disruptive as it might require heavy synchronisation across all CPUs. Use deferred static keys, which can rate-limit it by deferring, batching and potentially effectively eliminating dec+inc pairs. Fixes: 9b296c625ac1d ("io_uring: static_key for !IORING_SETUP_NO_SQARRAY") Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c76647799272272f681bf87a9cc13c93f9eb7792 Author: Christoph Böhmwalder Date: Thu Feb 5 18:39:29 2026 +0100 drbd: always set BLK_FEAT_STABLE_WRITES [ Upstream commit 2ebc8d600fb907fa6b1e7095c0b6d84fc47e91ea ] DRBD requires stable pages because it may read the same bio data multiple times for local disk I/O and network transmission, and in some cases for calculating checksums. The BLK_FEAT_STABLE_WRITES flag is set when the device is first created, but blk_set_stacking_limits() clears it whenever a backing device is attached. In some cases the flag may be inherited from the backing device, but we want it to be enabled at all times. Unconditionally re-enable BLK_FEAT_STABLE_WRITES in drbd_reconsider_queue_parameters() after the queue parameter negotiations. Also, document why we want this flag enabled in the first place. Fixes: 1a02f3a73f8c ("block: move the stable_writes flag to queue_limits") Signed-off-by: Christoph Böhmwalder Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit bda244871179543dd3be7d093236cb33b2fb1765 Author: Jared Kangas Date: Tue Jan 13 11:46:50 2026 -0800 dmaengine: fsl-edma: don't explicitly disable clocks in .remove() [ Upstream commit 666c53e94c1d0bf0bdf14c49505ece9ddbe725bc ] The clocks in fsl_edma_engine::muxclk are allocated and enabled with devm_clk_get_enabled(), which automatically cleans these resources up, but these clocks are also manually disabled in fsl_edma_remove(). This causes warnings on driver removal for each clock: edma_module already disabled WARNING: CPU: 0 PID: 418 at drivers/clk/clk.c:1200 clk_core_disable+0x198/0x1c8 [...] Call trace: clk_core_disable+0x198/0x1c8 (P) clk_disable+0x34/0x58 fsl_edma_remove+0x74/0xe8 [fsl_edma] [...] ---[ end trace 0000000000000000 ]--- edma_module already unprepared WARNING: CPU: 0 PID: 418 at drivers/clk/clk.c:1059 clk_core_unprepare+0x1f8/0x220 [...] Call trace: clk_core_unprepare+0x1f8/0x220 (P) clk_unprepare+0x34/0x58 fsl_edma_remove+0x7c/0xe8 [fsl_edma] [...] ---[ end trace 0000000000000000 ]--- Fix these warnings by removing the unnecessary fsl_disable_clocks() call in fsl_edma_remove(). Fixes: a9903de3aa16 ("dmaengine: fsl-edma: refactor using devm_clk_get_enabled") Signed-off-by: Jared Kangas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260113-fsl-edma-clock-removal-v1-1-2025b49e7bcc@redhat.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 0832e88bc69f7ee2440b15d3d7d87070c26e31bb Author: Barnabás Czémán Date: Fri Jan 16 08:07:36 2026 +0100 backlight: qcom-wled: Change PM8950 WLED configurations [ Upstream commit 83333aa97441ba7ce32b91e8a007c72d316a1c67 ] PMI8950 WLED needs same configurations as PMI8994 WLED. Fixes: 10258bf4534b ("backlight: qcom-wled: Add PMI8950 compatible") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20260116-pmi8950-wled-v3-4-e6c93de84079@mainlining.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 54540e574092dc85b31b99a18020fbee6b8043e4 Author: Barnabás Czémán Date: Fri Jan 16 08:07:34 2026 +0100 backlight: qcom-wled: Support ovp values for PMI8994 [ Upstream commit f29f972a6e7e3f187ea4d89b98a76c1981ca4d53 ] WLED4 found in PMI8994 supports different ovp values. Fixes: 6fc632d3e3e0 ("video: backlight: qcom-wled: Add PMI8994 compatible") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20260116-pmi8950-wled-v3-2-e6c93de84079@mainlining.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 784936cad37baf0e5dcfec337ac1cfac80498ae3 Author: Haotian Zhang Date: Fri Jan 9 01:51:33 2026 +0800 leds: qcom-lpg: Check the return value of regmap_bulk_write() [ Upstream commit f42033b5ce8c79c5db645916c9a72ee3e10cecfa ] The lpg_lut_store() function currently ignores the return value of regmap_bulk_write() and always returns 0. This can cause hardware write failures to go undetected, leading the caller to believe LUT programming succeeded when it may have failed. Check the return value of regmap_bulk_write() in lpg_lut_store and return the error to the caller on failure. Fixes: 24e2d05d1b68 ("leds: Add driver for Qualcomm LPG") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20260108175133.638-1-vulab@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 4f45047e3bf0a9837fec148b6b3b9b6f1ae14133 Author: Duje Mihanović Date: Wed Dec 17 19:14:23 2025 +0100 leds: expresswire: Fix chip state breakage [ Upstream commit f4b830a5371914239756b0599e5dc9d4c328e387 ] It is possible to put the KTD2801 chip in an unknown/undefined state by changing the brightness very rapidly (for example, with a brightness slider). When this happens, the brightness is stuck on max and cannot be changed until the chip is power cycled. Fix this by disabling interrupts while talking to the chip. While at it, make expresswire_power_off() use fsleep() and also unexport some functions meant to be internal. Fixes: 1368d06dd2c9 ("leds: Introduce ExpressWire library") Tested-by: Karel Balej Signed-off-by: Duje Mihanović Link: https://patch.msgid.link/20251217-expresswire-fix-v2-1-4a02b10acd96@dujemihanovic.xyz Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 3c7d637bfc3dfbd6471c68bd767f7eb8b5b09eba Author: Jiayu Du Date: Sun Dec 28 23:49:47 2025 +0800 pinctrl: canaan: k230: Fix NULL pointer dereference when parsing devicetree [ Upstream commit d8c128fb6c2277d95f3f6a4ce28b82c8370031f6 ] When probing the k230 pinctrl driver, the kernel triggers a NULL pointer dereference. The crash trace showed: [ 0.732084] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000068 [ 0.740737] ... [ 0.776296] epc : k230_pinctrl_probe+0x1be/0x4fc In k230_pinctrl_parse_functions(), we attempt to retrieve the device pointer via info->pctl_dev->dev, but info->pctl_dev is only initialized after k230_pinctrl_parse_dt() completes. At the time of DT parsing, info->pctl_dev is still NULL, leading to the invalid dereference of info->pctl_dev->dev. Use the already available device pointer from platform_device instead of accessing through uninitialized pctl_dev. Fixes: d94a32ac688f ("pinctrl: canaan: k230: Fix order of DT parse and pinctrl register") Signed-off-by: Jiayu Du Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit e2e367e56bacb93ce5ac73f0b3297d5c83d38dd4 Author: Wei Li Date: Tue Jan 20 08:07:35 2026 +0000 pinctrl: single: fix refcount leak in pcs_add_gpio_func() [ Upstream commit 353353309b0f7afa407df29e455f9d15b5acc296 ] of_parse_phandle_with_args() returns a device_node pointer with refcount incremented in gpiospec.np. The loop iterates through all phandles but never releases the reference, causing a refcount leak on each iteration. Add of_node_put() calls to release the reference after extracting the needed arguments and on the error path when devm_kzalloc() fails. This bug was detected by our static analysis tool and verified by my code review. Fixes: a1a277eb76b3 ("pinctrl: single: create new gpio function range") Signed-off-by: Wei Li Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fc356d8c3042f3fe9863b6e66be431f7b52c370e Author: Felix Gu Date: Wed Jan 28 02:23:12 2026 +0800 pinctrl: meson: amlogic-a4: Fix device node reference leak in bank helpers [ Upstream commit e56aa18eba32fb68ac5e19e44670010095bb189c ] of_parse_phandle_with_fixed_args() increments the reference count of the returned device node, so it must be explicitly released using of_node_put() after use. Fix the reference leak in aml_bank_pins() and aml_bank_number() by adding the missing of_node_put() calls. Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs") Signed-off-by: Felix Gu Reviewed-by: Xianwei Zhao Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit a851ed0ff9015f855afb0c0728fc39142a719788 Author: Luca Weiss Date: Wed Jan 28 12:22:28 2026 +0100 pinctrl: qcom: sm8250-lpass-lpi: Fix i2s2_data_groups definition [ Upstream commit eabf273c8466af3f033473c2d2267a6ea7946d57 ] The i2s2_data function is available on both gpio12 and gpio13. Fix the groups definition. Fixes: 6e261d1090d6 ("pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver") Signed-off-by: Luca Weiss Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 7446125afb6d9d4f15fd3b6c6e7e7cf0ca91557c Author: Luca Boccassi Date: Tue Jan 27 22:51:37 2026 +0000 pidfs: return -EREMOTE when PIDFD_GET_INFO is called on another ns [ Upstream commit ab89060fbc92edd6e852bf0f533f29140afabe0e ] Currently it is not possible to distinguish between the case where a process has already exited and the case where a process is in a different namespace, as both return -ESRCH. glibc's pidfd_getpid() procfs-based implementation returns -EREMOTE in the latter, so that distinguishing the two is possible, as the fdinfo in procfs will list '0' as the PID in that case: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/pidfd_getpid.c;h=860829cf07da2267484299ccb02861822c0d07b4;hb=HEAD#l121 Change the error code so that the kernel also returns -EREMOTE in that case. Fixes: 7477d7dce48a ("pidfs: allow to retrieve exit information") Signed-off-by: Luca Boccassi Link: https://patch.msgid.link/20260127225209.2293342-1-luca.boccassi@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 21aff1255d7284eaa019c503c2c1a611096ce38c Author: Randy Dunlap Date: Sun Dec 28 11:04:43 2025 -0800 mips: LOONGSON32: drop a dangling Kconfig symbol [ Upstream commit d463fc5ca1ace0b2e8bb764df04fc12ecd6f8e2b ] CPU_HAS_LOAD_STORE_LR is not used anywhere in the kernel sources, so drop it. Fixes: 85c4354076ca ("MIPS: loongson32: Switch to generic core") Signed-off-by: Randy Dunlap Reviewed-by: Keguang Zhang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 517d9f2b963089b3d64c23accf7920d77f5a30c8 Author: Harshit Mogalapalli Date: Tue Jan 27 22:49:49 2026 -0800 iio: sca3000: Fix a resource leak in sca3000_probe() [ Upstream commit 62b44ebc1f2c71db3ca2d4737c52e433f6f03038 ] spi->irq from request_threaded_irq() not released when iio_device_register() fails. Add an return value check and jump to a common error handler when iio_device_register() fails. Fixes: 9a4936dc89a3 ("staging:iio:accel:sca3000 Tidy up probe order to avoid a race.") Signed-off-by: Harshit Mogalapalli Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 8ae999c410e2bb1a4a2c1cc80e9ff672b8c1fd81 Author: Qing Wang Date: Wed Jan 28 14:24:04 2026 +0100 ovl: Fix uninit-value in ovl_fill_real [ Upstream commit 1992330d90dd766fcf1730fd7bf2d6af65370ac4 ] Syzbot reported a KMSAN uninit-value issue in ovl_fill_real. This iusse's call chain is: __do_sys_getdents64() -> iterate_dir() ... -> ext4_readdir() -> fscrypt_fname_alloc_buffer() // alloc -> fscrypt_fname_disk_to_usr // write without tail '\0' -> dir_emit() -> ovl_fill_real() // read by strcmp() The string is used to store the decrypted directory entry name for an encrypted inode. As shown in the call chain, fscrypt_fname_disk_to_usr() write it without null-terminate. However, ovl_fill_real() uses strcmp() to compare the name against "..", which assumes a null-terminated string and may trigger a KMSAN uninit-value warning when the buffer tail contains uninit data. Reported-by: syzbot+d130f98b2c265fae5297@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d130f98b2c265fae5297 Fixes: 4edb83bb1041 ("ovl: constant d_ino for non-merge dirs") Signed-off-by: Qing Wang Signed-off-by: Amir Goldstein Link: https://patch.msgid.link/20260128132406.23768-2-amir73il@gmail.com Acked-by: Miklos Szeredi Reviewed-by: Eric Biggers Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit a5f1f8ebc6e2a351a138fd7e9609e7c1ef8966c6 Author: Felix Gu Date: Tue Jan 27 01:30:07 2026 +0800 pinctrl: equilibrium: Fix device node reference leak in pinbank_init() [ Upstream commit c0b4a4feeb43305a754893d8d9c6b2b5a52d45ac ] When calling of_parse_phandle_with_fixed_args(), the caller is responsible to call of_node_put() to release the reference of device node. In pinbank_init(), the reference of the node obtained from the "gpio-ranges" property is never released, resulting in a reference count leak. Add the missing of_node_put() call to fix the leak. Fixes: 1948d5c51dba ("pinctrl: Add pinmux & GPIO controller driver for a new SoC") Signed-off-by: Felix Gu Acked-by: Andy Shevchenko Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 18a3ebff869c9fdf75cb64b996bb2e35d10befbe Author: Jose Javier Rodriguez Barbarin Date: Fri Jan 16 12:21:41 2026 +0100 mcb: fix incorrect sanity check [ Upstream commit bc2e4bc952e26dd93b978588219044bd8b24237b ] __mcb_register_driver() makes some sanity checks over mcb_driver to check if .probe and .remove callbacks are set. However, since commit 3bd13ae04ccc ("gpio: menz127: simplify error path and remove remove()") removed the .remove callback from menz127-gpio.c, not all mcb device drivers implement .remove callback. Remove .remove check to ensure all mcb device drivers can be loaded. Signed-off-by: Jose Javier Rodriguez Barbarin Fixes: 3bd13ae04ccc ("gpio: menz127: simplify error path and remove remove()") [ jth: added statement about menz127-gpio.c ] Signed-off-by: Johannes Thumshirn Link: https://patch.msgid.link/16fb55bd59d9c1d2ce2443f41d4dec2048f9a8ec.1768562302.git.jth@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ab08bb8363b4610534e3ad4030a187c232fba7b1 Author: Randy Dunlap Date: Fri Jan 16 17:08:45 2026 +0000 nvmem: an8855: drop an unused Kconfig symbol [ Upstream commit 4796eaafd6a170db012395a40385d2baf4f4d118 ] MFD_AIROHA_AN8855 is referenced here but never defined, so drop it from the Kconfig file. Fixes: e2258cfd9b98 ("nvmem: an8855: Add support for Airoha AN8855 Switch EFUSE") Signed-off-by: Randy Dunlap Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260116170846.733558-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0c930fcadb2fe772ca9461f491eab5d24244c207 Author: Justin Chen Date: Tue Jan 20 12:07:54 2026 -0800 usb: bdc: fix sleep during atomic [ Upstream commit f1195ca3b4bbd001d3f1264dce91f83dec7777f5 ] bdc_run() can be ran during atomic context leading to a sleep during atomic warning. Fix this by replacing read_poll_timeout() with read_poll_timeout_atomic(). Fixes: 75ae051efc9b ("usb: gadget: bdc: use readl_poll_timeout() to simplify code") Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260120200754.2488765-1-justin.chen@broadcom.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9b8c7a25809ef3440d9f5042359641b9575ec801 Author: Svyatoslav Ryhel Date: Thu Jan 22 17:34:25 2026 +0200 drivers: iio: mpu3050: use dev_err_probe for regulator request [ Upstream commit b010880b9936da14f8035585ab57577aa05be23a ] Regulator requesting may result in deferred probing error which will abort driver probing. To avoid this just use dev_err_probe which handles deferred probing. Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") Signed-off-by: Svyatoslav Ryhel Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit bedc5b06493cc7c592e7833a8952531a9d58667f Author: Robert Marko Date: Mon Jan 12 17:14:52 2026 +0100 mfd: simple-mfd-i2c: Add Delta TN48M CPLD support [ Upstream commit 8f34c1a64c5394d2b51d3fba197947dc4b0b48a0 ] Delta TN48M switches have a Lattice CPLD that serves multiple purposes including being a GPIO expander. So, lets use the simple I2C MFD driver to provide the MFD core. Also add a virtual symbol which pulls in the simple-mfd-i2c driver and provide a common symbol on which the subdevice drivers can depend on. Fixes: b3dcb5de6209 ("gpio: Add Delta TN48M CPLD GPIO driver") Signed-off-by: Robert Marko Link: https://lore.kernel.org/20220131133049.77780-2-robert.marko@sartura.hr Link: https://lore.kernel.org/linux-gpio/20260112064950.3837737-1-rdunlap@infradead.org/ Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260112-mfd-tn48m-v11-1-00c798d8cd2a@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 5a4923726a165593d7601834a6fb2a10ab47b85d Author: Haotian Zhang Date: Sun Dec 14 22:58:03 2025 +0800 mfd: arizona: Fix regulator resource leak on wm5102_clear_write_sequencer() failure [ Upstream commit 4feb753ba6e5e5bbaba868b841a2db41c21e56fa ] The wm5102_clear_write_sequencer() helper may return an error and just return, bypassing the cleanup sequence and causing regulators to remain enabled, leading to a resource leak. Change the direct return to jump to the err_reset label to properly free the resources. Fixes: 1c1c6bba57f5 ("mfd: wm5102: Ensure we always boot the device fully") Signed-off-by: Haotian Zhang Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20251214145804.2037-1-vulab@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 8e7d8aca8811a078ce1e9d8340eb45afc87f4f3a Author: Greg Kroah-Hartman Date: Wed Jan 21 15:49:31 2026 +0100 Revert "mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms" [ Upstream commit ff112f1ecd10b72004eac05bae395e1c65f0c63c ] This reverts commit aced969e9bf3701dc75cfca57c78c031b7875b9d. It was determined that this was not the correct "fix", so should be reverted. Fixes: aced969e9bf3 ("mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms") Cc: Matthew Schwartz Cc: Ulf Hansson Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 38a07194bbcddb18d77dad40ba9978d994c0b74c Author: Yicong Yang Date: Wed Jan 21 18:15:42 2026 +0800 coresight: tmc-etr: Fix race condition between sysfs and perf mode [ Upstream commit e6e43e82c79c97917cbe356c07e8a6f3f982ab53 ] When trying to run perf and sysfs mode simultaneously, the WARN_ON() in tmc_etr_enable_hw() is triggered sometimes: WARNING: CPU: 42 PID: 3911571 at drivers/hwtracing/coresight/coresight-tmc-etr.c:1060 tmc_etr_enable_hw+0xc0/0xd8 [coresight_tmc] [..snip..] Call trace: tmc_etr_enable_hw+0xc0/0xd8 [coresight_tmc] (P) tmc_enable_etr_sink+0x11c/0x250 [coresight_tmc] (L) tmc_enable_etr_sink+0x11c/0x250 [coresight_tmc] coresight_enable_path+0x1c8/0x218 [coresight] coresight_enable_sysfs+0xa4/0x228 [coresight] enable_source_store+0x58/0xa8 [coresight] dev_attr_store+0x20/0x40 sysfs_kf_write+0x4c/0x68 kernfs_fop_write_iter+0x120/0x1b8 vfs_write+0x2c8/0x388 ksys_write+0x74/0x108 __arm64_sys_write+0x24/0x38 el0_svc_common.constprop.0+0x64/0x148 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x1ac/0x1b0 ---[ end trace 0000000000000000 ]--- Since the enablement of sysfs mode is separeted into two critical regions, one for sysfs buffer allocation and another for hardware enablement, it's possible to race with the perf mode. Fix this by double check whether the perf mode's been used before enabling the hardware in sysfs mode. mode: [sysfs mode] [perf mode] tmc_etr_get_sysfs_buffer() spin_lock(&drvdata->spinlock) [sysfs buffer allocation] spin_unlock(&drvdata->spinlock) spin_lock(&drvdata->spinlock) tmc_etr_enable_hw() drvdata->etr_buf = etr_perf->etr_buf spin_unlock(&drvdata->spinlock) spin_lock(&drvdata->spinlock) tmc_etr_enable_hw() WARN_ON(drvdata->etr_buf) // WARN sicne etr_buf initialized at the perf side spin_unlock(&drvdata->spinlock) With this fix, we retain the check for CS_MODE_PERF in get_etr_sysfs_buf. This ensures we verify whether the perf mode's already running before we actually allocate the buffer. Then we can save the time of allocating/freeing the sysfs buffer if race with the perf mode. Fixes: 296b01fd106e ("coresight: Refactor out buffer allocation function for ETR") Signed-off-by: Yicong Yang Signed-off-by: Junhao He Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260121101543.2017014-3-wangyushan12@huawei.com Signed-off-by: Sasha Levin commit dd8b9ba3d9701832cfb5dcefd8b43250df28dbc2 Author: Thomas Richard Date: Wed Jan 14 17:50:23 2026 +0100 phy: freescale: imx8qm-hsio: fix NULL pointer dereference [ Upstream commit 4dd5d4c0361af0a3fd24f45c815996abf4429770 ] During the probe the refclk_pad pointer is set to NULL if the 'fsl,refclk-pad-mode' property is not defined in the devicetree node. But in imx_hsio_configure_clk_pad() this pointer is unconditionally used which could result in a NULL pointer dereference. So check the pointer before to use it. Fixes: 82c56b6dd24f ("phy: freescale: imx8qm-hsio: Add i.MX8QM HSIO PHY driver support") Signed-off-by: Thomas Richard Reviewed-by: Richard Zhu Link: https://patch.msgid.link/20260114-phy-fsl-imx8qm-hsio-fix-null-pointer-dereference-v1-1-730e941be464@bootlin.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 1bec5f283dd5ece89d87e29e89b959cdf2a8f768 Author: Antonio Borneo Date: Thu Jan 8 16:24:27 2026 +0100 coresight: etm3x: Fix cpulocked warning on cpuhp [ Upstream commit 1feb0377b9b816f89a04fc381eb19fc6bac9f4a4 ] When changes [1] and [2] have been applied to the driver etm4x, the same modifications have been also collapsed in [3] and applied in one shot to the driver etm3x. While doing this, the driver etm3x has not been aligned to etm4x on the use of non cpuslocked version of cpuhp callback setup APIs. The current code triggers two run-time warnings when the kernel is compiled with CONFIG_PROVE_LOCKING=y. Use non cpuslocked version of cpuhp callback setup APIs in driver etm3x, aligning it to the driver etm4x. [1] commit 2d1a8bfb61ec ("coresight: etm4x: Fix etm4_count race by moving cpuhp callbacks to init") [2] commit 22a550a306ad ("coresight: etm4x: Allow etm4x to be built as a module") [3] commit 97fe626ce64c ("coresight: etm3x: Allow etm3x to be built as a module") Fixes: 97fe626ce64c ("coresight: etm3x: Allow etm3x to be built as a module") Signed-off-by: Antonio Borneo Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260108152427.357379-1-antonio.borneo@foss.st.com Signed-off-by: Sasha Levin commit 8665e18a707ca85d146a4d180a8f13804f6f242e Author: Kery Qi Date: Mon Jan 12 01:29:15 2026 +0800 watchdog: starfive-wdt: Fix PM reference leak in probe error path [ Upstream commit 3f2d8d79cceb05a8b8dd200fa81c0dffc59ec46f ] The PM reference count is not expected to be incremented on return in functions starfive_wdt_probe. However, pm_runtime_get_sync will increment pm usage counter even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: db728ea9c7be ("drivers: watchdog: Add StarFive Watchdog driver") Signed-off-by: Kery Qi Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit a75046f2efadca2553a206a899645091d72bb141 Author: Petre Rodan Date: Wed Jan 14 18:55:34 2026 +0200 iio: pressure: mprls0025pa: fix pressure calculation [ Upstream commit d63403d4e31ae537fefc5c0ee9d90f29b4fc532b ] A sign change is needed for proper calculation of the pressure. This is a minor fix since it only affects users that might have custom silicon from Honeywell that has honeywell,pmin-pascal != 0. Also due to the fact that raw pressure values can not be lower than output_min (400k-3.3M) there is no need to calculate a decimal for the offset. Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") Signed-off-by: Petre Rodan Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b61512ff73d28978d26d56b756a51eaa99d3eaad Author: Petre Rodan Date: Wed Jan 14 18:55:33 2026 +0200 iio: pressure: mprls0025pa: fix scan_type struct [ Upstream commit 8a228e036926f7e57421d750c3724e63f11b808a ] Fix the scan_type sign and realbits assignment. The pressure is a 24bit unsigned int between output_min and output_max. transfer function A: 10% to 90% of 2^24 transfer function B: 2.5% to 22.5% of 2^24 transfer function C: 20% to 80% of 2^24 [MPR_FUNCTION_A] = { .output_min = 1677722, .output_max = 15099494 } [MPR_FUNCTION_B] = { .output_min = 419430, .output_max = 3774874 } [MPR_FUNCTION_C] = { .output_min = 3355443, .output_max = 13421773 } Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") Signed-off-by: Petre Rodan Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 0beeade4823bccc19ff906bb538cca8ce086143f Author: Petre Rodan Date: Wed Jan 14 18:55:32 2026 +0200 iio: pressure: mprls0025pa: fix interrupt flag [ Upstream commit fff3f1a7d805684e4701a70bfaeba39622b59dbc ] Interrupt falling/rising flags should only be defined in the device tree. Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") Signed-off-by: Petre Rodan Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 285af88d5da16032c751117c31e7f03b4f53ed7a Author: Petre Rodan Date: Wed Jan 14 18:55:31 2026 +0200 iio: pressure: mprls0025pa: fix SPI CS delay violation [ Upstream commit 583fa86ca581595b1f534a8de6d49ba8b3bf7196 ] Based on the sensor datasheet in chapter 7.6 SPI timing, Table 20, during the SPI transfer there is a minimum time interval requirement between the CS being asserted and the first clock edge (tHDSS). This minimum interval of 2.5us is being violated if two consecutive SPI transfers are queued up. Fixes: a0858f0cd28e ("iio: pressure: mprls0025pa add SPI driver") Datasheet: https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/micropressure-mpr-series/documents/sps-siot-mpr-series-datasheet-32332628-ciid-172626.pdf?download=false Signed-off-by: Petre Rodan Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 664ffdf34c01810085e4d85508b361c3fdd2ab40 Author: Petre Rodan Date: Wed Jan 14 18:55:30 2026 +0200 iio: pressure: mprls0025pa: fix spi_transfer struct initialisation [ Upstream commit 1e0ac56c92e26115cbc8cfc639843725cb3a7d6a ] Make sure that the spi_transfer struct is zeroed out before use. Fixes: a0858f0cd28e ("iio: pressure: mprls0025pa add SPI driver") Signed-off-by: Petre Rodan Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 37fb15537cc052b75daed684b951a3d9016bec1c Author: Matthew Schwartz Date: Sun Jan 4 22:02:36 2026 -0800 mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms [ Upstream commit aced969e9bf3701dc75cfca57c78c031b7875b9d ] The existing 1ms delay in sd_power_on is insufficient and causes resume errors around 4% of the time. Increasing the delay to 5ms resolves this issue after testing 300 s2idle cycles. Fixes: 1f311c94aabd ("mmc: rtsx: add 74 Clocks in power on flow") Signed-off-by: Matthew Schwartz Link: https://patch.msgid.link/20260105060236.400366-3-matthew.schwartz@linux.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9c97fcfb7a62dea893104a046d544da8ac23370b Author: Zilin Guan Date: Tue Dec 30 03:45:46 2025 +0000 gpib: Fix memory leak in ni_usb_init() [ Upstream commit b89921eed8cf2d97250bac4be38dbcfbf048b586 ] In ni_usb_init(), if ni_usb_setup_init() fails, the function returns -EFAULT without freeing the allocated writes buffer, leading to a memory leak. Additionally, ni_usb_setup_init() returns 0 on failure, which causes ni_usb_init() to return -EFAULT, an inappropriate error code for this situation. Fix the leak by freeing writes in the error path. Modify ni_usb_setup_init() to return -EINVAL on failure and propagate this error code in ni_usb_init(). Fixes: 4e127de14fa7 ("staging: gpib: Add National Instruments USB GPIB driver") Suggested-by: Greg KH Suggested-by: Dave Penkler Co-developed-by: Jianhao Xu Signed-off-by: Jianhao Xu Signed-off-by: Zilin Guan Link: https://patch.msgid.link/20251230034546.929452-1-zilin@seu.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b30ba62cafd8bd705dacbcc5f6072f8e0dde9af2 Author: Dan Carpenter Date: Fri Nov 28 10:17:57 2025 +0300 gpib: Fix error code in ni_usb_write_registers() [ Upstream commit 484e62252212c5b5fc62eaee5e4977143cb159c6 ] If ni_usb_receive_bulk_msg() succeeds but without reading 16 bytes, then the error code needs to be set. The current code returns success. Fixes: 4e127de14fa7 ("staging: gpib: Add National Instruments USB GPIB driver") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/aSlMpbE4IrQuBGFS@stanley.mountain Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5ca0f7b3718377bf635be83b289d3fa7d6b7b91b Author: Dan Carpenter Date: Fri Nov 28 10:17:49 2025 +0300 gpib: Fix error code in ibonline() [ Upstream commit 96118565d24e7691e423d73be224b3a3fffc4680 ] This accidentally returns 1 on error, but it should return negative error codes. Fixes: 9dde4559e939 ("staging: gpib: Add GPIB common core driver") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/aSlMnaT1M104NJb2@stanley.mountain Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 12679ed78c09b0c30321cafe0ad24e59f3f4a6bb Author: Randy Dunlap Date: Sat Jan 10 15:26:43 2026 -0800 serial: SH_SCI: improve "DMA support" prompt [ Upstream commit 93bb95a11238d66a4c9aa6eabf9774b073a5895c ] Having a prompt of "DMA support" suddenly appear during a "make oldconfig" can be confusing. Add a little helpful text to the prompt message. Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.") Signed-off-by: Randy Dunlap Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260110232643.3533351-5-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3f8b835a63341163da0400befb3c6e8f6d4085da Author: Randy Dunlap Date: Sat Jan 10 15:26:40 2026 -0800 serial: imx: change SERIAL_IMX_CONSOLE to bool [ Upstream commit 79527d86ba91c2d9354832d19fd12b3baa66bd10 ] SERIAL_IMX_CONSOLE is a build option for the imx driver (SERIAL_IMX). It does not build a separate console driver file, so it can't be built as a module since it isn't built at all. Change the Kconfig symbol from tristate to bool and update the help text accordingly. Fixes: 0db4f9b91c86 ("tty: serial: imx: enable imx serial console port as module") Signed-off-by: Randy Dunlap Link: https://patch.msgid.link/20260110232643.3533351-2-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 06162d85f830582da6e9e5fcf9c9504d6da9ae0b Author: Chaitanya Mishra Date: Thu Jan 8 20:42:54 2026 +0530 staging: greybus: lights: avoid NULL deref [ Upstream commit efcffd9a6ad8d190651498d5eda53bfc7cf683a7 ] gb_lights_light_config() stores channel_count before allocating the channels array. If kcalloc() fails, gb_lights_release() iterates the non-zero count and dereferences light->channels, which is NULL. Allocate channels first and only then publish channels_count so the cleanup path can't walk a NULL pointer. Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") Link: https://lore.kernel.org/all/20260108103700.15384-1-chaitanyamishra.ai@gmail.com/ Reviewed-by: Rui Miguel Silva Signed-off-by: Chaitanya Mishra Link: https://patch.msgid.link/20260108151254.81553-1-chaitanyamishra.ai@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c7f7b55ce2ad858b015c45cd1797cf23139a516e Author: Randy Dunlap Date: Sun Dec 28 11:06:03 2025 -0800 usb: typec: ucsi: drop an unused Kconfig symbol [ Upstream commit c5177144b561dd4037a6a225d444b3604afbfbf2 ] EXTCON_TCSS_CROS_EC isn't used anywhere else in the kernel tree, so drop it from this Kconfig file. (unless it should be EXTCON_USBC_CROS_EC ?) Fixes: f1a2241778d9 ("usb: typec: ucsi: Implement ChromeOS UCSI driver") Signed-off-by: Randy Dunlap Reviewed-by: Abhishek Pandit-Subedi Reviewed-by: Benson Leung Link: https://patch.msgid.link/20251228190604.2484082-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b244fbf3ff829d23972821f829b9b8b8a9f16849 Author: Randy Dunlap Date: Sat Dec 27 23:10:29 2025 -0800 iio: test: drop dangling symbol in gain-time-scale helpers [ Upstream commit d63d868b312478523670b76007dcc5eaedc3ee07 ] The code for this never went upstream. It was replaced by other code, so this should be dropped. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216748 Fixes: cf996f039679 ("iio: test: test gain-time-scale helpers") Signed-off-by: Randy Dunlap Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit ac00f8a0cb157f5f8d6ed8099524c31fdb94ca2d Author: Arnd Bergmann Date: Tue Dec 23 22:50:01 2025 +0100 soundwire: intel_ace2x: add SND_HDA_CORE dependency [ Upstream commit dc3a6a942e9ee3f18560bfcb16c06bb94f37fabf ] The ace2x driver can optionally use the HDA infrastructure, but can still build without that. However, with SND_HDA_CORE=m and SND_HDA_ALIGNED_MMIO=y, it fails to link as built-in: aarch64-linux-ld: drivers/soundwire/intel_ace2x.o: in function `intel_shim_wake': intel_ace2x.c:(.text+0x2518): undefined reference to `snd_hdac_aligned_read' aarch64-linux-ld: intel_ace2x.c:(.text+0x25d4): undefined reference to `snd_hdac_aligned_read' aarch64-linux-ld: intel_ace2x.c:(.text+0x268c): undefined reference to `snd_hdac_aligned_write' Add a Kconfig dependency that forces the soundwire driver to be a loadable module if necessary. Fixes: 79e7123c078d ("soundwire: intel_ace2x: fix wakeup handling") Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20251223215014.534756-1-arnd@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 621a8bf292ede41df2f8f09d4198f4ab628267d7 Author: Alper Ak Date: Sat Dec 27 02:02:48 2025 +0300 char: misc: Use IS_ERR() for filp_open() return value [ Upstream commit e849ada70c6b1ee22e9f4f5c0e38231dcee53f04 ] filp_open() never returns NULL, it returns either a valid pointer or an error pointer. Using IS_ERR_OR_NULL() is unnecessary. Additionally, if filp were NULL, PTR_ERR(NULL) would return 0, leading to a misleading error message. Fixes: 74d8361be344 ("char: misc: add test cases") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202506132058.thWZHlrb-lkp@intel.com/ Signed-off-by: Alper Ak Acked-by: Thadeu Lima de Souza Cascardo Link: https://patch.msgid.link/20251226230248.113073-1-alperyasinak1@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 05ce13d78226bf4100151cbd47029dba0653a9a1 Author: Cristian Ciocaltea Date: Sun Dec 21 12:36:23 2025 +0200 phy: rockchip: samsung-hdptx: Pre-compute HDMI PLL config for 461.10125 MHz output [ Upstream commit f2daf0c67a1767ff6536aa3e96599afb42ca42e7 ] Attempting to make use of a 1080p@120Hz display mode with 10 bpc RGB on my Acer XV275K P3 monitor results in a blank image. A similar behavior has been reported on Philips 279M1RV. The faulty modeline is created by drm_gtf_mode_complex() based on the following EDID entry from the Standard Timings block: GTF: 1920x1080 119.999987 Hz 16:9 138.840 kHz 368.759000 MHz It's worth noting the computed pixel clock ends up being slightly higher at 368.881000 MHz. Nevertheless, this seems to work consistently fine with 8 bpc RGB. After switching to 10 bpc, the TMDS character rate expected for the mode increases to 461.101250 MHz, as per drm_hdmi_compute_mode_clock(). Since there is no entry for this rate in the ropll_tmds_cfg table, the necessary HDMI PLL configuration parameters are calculated dynamically by rk_hdptx_phy_clk_pll_calc(). However, the resulting output rate is not quite a perfect match, i.e. 461.100000 MHz. That proved to be the actual root cause of the problem. Add a new entry to the TMDS configuration table and provide the necessary frequency division coefficients for the PHY PLL to generate the expected 461.101250 MHz output. Fixes: 9d0ec51d7c22 ("phy: rockchip: samsung-hdptx: Add high color depth management") Tested-by: Derek Foreman Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20251221-phy-hdptx-pll-fix-v2-1-ae4abf7f75a1@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ccc29a067399e911e1f0e8cc68def95d0f7164b0 Author: Nuno Sá Date: Tue Nov 4 16:22:26 2025 +0000 dma: dma-axi-dmac: fix HW scatter-gather not looking at the queue [ Upstream commit bbcbafb99df41a1d81403eb4f5bb443b38228b57 ] For HW scatter gather transfers we still need to look for the queue. The HW is capable of queueing 3 concurrent transfers and if we try more than that we'll get the submit queue full and should return. Otherwise, if we go ahead and program the new transfer, we end up discarding it. Fixes: e97dc7435972 ("dmaengine: axi-dmac: Add support for scatter-gather transfers") Signed-off-by: Nuno Sá base-commit: 398035178503bf662281bbffb4bebce1460a4bc5 change-id: 20251104-axi-dmac-fixes-and-improvs-e3ad512a329c Acked-by: Michael Hennerich Link: https://patch.msgid.link/20251104-axi-dmac-fixes-and-improvs-v1-2-3e6fd9328f72@analog.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit dd1e96fd9f60a9f20757ceaa6bffd0d7fdcef858 Author: Nuno Sá Date: Tue Nov 4 16:22:25 2025 +0000 dma: dma-axi-dmac: fix SW cyclic transfers [ Upstream commit 9bd257181fd5c996d922e9991500ad27987cfbf4 ] If 'hw_cyclic' is false we should still be able to do cyclic transfers in "software". That was not working for the case where 'desc->num_sgs' is 1 because 'chan->next_desc' is never set with the current desc which means that the cyclic transfer only runs once and in the next SOT interrupt we do nothing since vchan_next_desc() will return NULL. Fix it by setting 'chan->next_desc' as soon as we get a new desc via vchan_next_desc(). Fixes: 0e3b67b348b8 ("dmaengine: Add support for the Analog Devices AXI-DMAC DMA controller") Signed-off-by: Nuno Sá base-commit: 398035178503bf662281bbffb4bebce1460a4bc5 change-id: 20251104-axi-dmac-fixes-and-improvs-e3ad512a329c Acked-by: Michael Hennerich Link: https://patch.msgid.link/20251104-axi-dmac-fixes-and-improvs-v1-1-3e6fd9328f72@analog.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b0ce68420da60030b12258e663420b4c6199b6de Author: AngeloGioacchino Del Regno Date: Thu Nov 13 13:22:26 2025 +0100 dmaengine: mediatek: uart-apdma: Fix above 4G addressing TX/RX [ Upstream commit 58ab9d7b6651d21e1cff1777529f2d3dd0b4e851 ] The VFF_4G_SUPPORT register is named differently in datasheets, and its name is "VFF_ADDR2"; was this named correctly from the beginning it would've been clearer that there was a mistake in the programming sequence. This register is supposed to hold the high bits to support the DMA addressing above 4G (so, more than 32 bits) and not a bit to "enable" the support for VFF 4G. Fix the name of this register, and also fix its usage by writing the upper 32 bits of the dma_addr_t on it when the SoC supports such feature. Fixes: 9135408c3ace ("dmaengine: mediatek: Add MediaTek UART APDMA support") Signed-off-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20251113122229.23998-6-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 2f0d9a5d552c671b36db4f149d7df22705fd3cfe Author: Nicolas Frattaroli Date: Mon Nov 24 12:07:02 2025 +0100 interconnect: mediatek: Aggregate bandwidth with saturating add [ Upstream commit 6ffd02b82243d9907b5f5d2c7a2fc6a62669eece ] By using a regular non-overflow-checking add, the MediaTek icc-emi driver will happy wrap at U32_MAX + 1 to 0. As it's common for the interconnect core to fill in INT_MAX values, this is not a hypothetical situation, but something that actually happens in regular use. This would be pretty disasterous if anything used this driver. Replace the addition with an overflow-checked addition from overflow.h, and saturate to U32_MAX if an overflow is detected. Fixes: b45293799f75 ("interconnect: mediatek: Add MediaTek MT8183/8195 EMI Interconnect driver") Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Frattaroli Link: https://lore.kernel.org/r/20251124-mt8196-dvfsrc-v2-13-d9c1334db9f3@collabora.com Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit 86e6547ac6c4d1f3dcc896f7d0bc13f140f40038 Author: Nicolas Frattaroli Date: Mon Nov 24 12:07:01 2025 +0100 interconnect: mediatek: Don't hijack parent device [ Upstream commit 510f8214440c553e81774c5822437ccf154e9e38 ] If the intention is that users of the interconnect declare their relationship to the child icc_emi node of the dvfsrc controller, then this code never worked. That's because it uses the parent dvfsrc device as the device it passes to the interconnect core framework, which means all the OF parsing is broken. Use the actual device instead, and pass the dvfsrc parent into the dvfsrc calls. Fixes: b45293799f75 ("interconnect: mediatek: Add MediaTek MT8183/8195 EMI Interconnect driver") Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Frattaroli Link: https://lore.kernel.org/r/20251124-mt8196-dvfsrc-v2-12-d9c1334db9f3@collabora.com Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit 52e4ac51e3fa7bff9515173aab4aeb41bdd7eae6 Author: Krzysztof Kozlowski Date: Wed Dec 24 12:42:12 2025 +0100 clk: zynqmp: pll: Fix zynqmp_clk_divider_determine_rate kerneldoc [ Upstream commit 750e0e0a1652530618d2c07697618e705bc5061b ] After renaming round_rate->determine, kerneldoc does not match anymore, causing W=1 warnings: pll.c:102 function parameter 'req' not described in 'zynqmp_pll_determine_rate' pll.c:102 expecting prototype for zynqmp_pll_round_rate(). Prototype was for zynqmp_pll_determine_rate() instead Fixes: 193650c7a873 ("clk: zynqmp: pll: convert from round_rate() to determine_rate()") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Brian Masney Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit d53b019a60031dbd89c9dc5431f06fb2193da7e1 Author: Krzysztof Kozlowski Date: Wed Dec 24 12:42:11 2025 +0100 clk: zynqmp: divider: Fix zynqmp_clk_divider_determine_rate kerneldoc [ Upstream commit 1b8773864904c7a25e45f1b12ab505bdb7e06568 ] After renaming round_rate->determine, kerneldoc does not match anymore, causing W=1 warnings: Warning: drivers/clk/zynqmp/divider.c:122 function parameter 'req' not described in 'zynqmp_clk_divider_determine_rate' Warning: drivers/clk/zynqmp/divider.c:122 expecting prototype for zynqmp_clk_divider_round_rate(). Prototype was for zynqmp_clk_divider_determine_rate() instead Fixes: 0f9cf96a01fd ("clk: zynqmp: divider: convert from round_rate() to determine_rate()") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Brian Masney Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 71e5335fcec0807e04f00c26789afef14b198148 Author: Haotian Zhang Date: Sun Nov 23 23:43:15 2025 +0800 clk: mediatek: Fix error handling in runtime PM setup [ Upstream commit aa2ad19210a6a444111bce55e8b69579f29318fb ] devm_pm_runtime_enable() can fail due to memory allocation. The current code ignores its return value, and when pm_runtime_resume_and_get() fails, it returns directly without unmapping the shared_io region. Add error handling for devm_pm_runtime_enable(). Reorder cleanup labels to properly unmap shared_io on pm_runtime_resume_and_get() failure. Fixes: 2f7b1d8b5505 ("clk: mediatek: Do a runtime PM get on controllers during probe") Signed-off-by: Haotian Zhang Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6e5379c3b54578d8194ea9de06ab5b0978af97bc Author: Nicolas Frattaroli Date: Mon Dec 15 11:24:02 2025 +0100 clk: mediatek: Add mfg_eb as parent to mt8196 mfgpll clocks [ Upstream commit 19024c9980c331908de0680283d572b80308654e ] All the MFGPLL require MFG_EB to be on for any operation on them, and they only tick when MFG_EB is on as well, therefore making this a parent-child relationship. This dependency wasn't clear during the initial upstreaming of these clock controllers, as it only made itself known when I could observe the effects of the clock by bringing up a different piece of hardware. Add a new PLL_PARENT_EN flag to mediatek's clk-pll.h, and check for it when initialising the pll to then translate it into the actual CLK_OPS_PARENT_ENABLE flag. Then add the mfg_eb parent to the mfgpll clocks, and set the new PLL_PARENT_EN flag. Fixes: 03dc02f8c7dc ("clk: mediatek: Add MT8196 mfg clock support") Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Frattaroli Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 1debd9ba7eb18af8fb63dc93517c6bbcab0e31ee Author: Sjoerd Simons Date: Tue Dec 23 12:05:17 2025 +0100 clk: mediatek: Drop __initconst from gates [ Upstream commit 871afb43e41ad4e8246438de495a939cd0f8113c ] Since commit 8ceff24a754a ("clk: mediatek: clk-gate: Refactor mtk_clk_register_gate to use mtk_gate struct") the mtk_gate structs are no longer just used for initialization/registration, but also at runtime. So drop __initconst annotations. Fixes: 8ceff24a754a ("clk: mediatek: clk-gate: Refactor mtk_clk_register_gate to use mtk_gate struct") Signed-off-by: Sjoerd Simons Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Laura Nao Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 053490ddace34432e457df932a8f97b849861a49 Author: Brian Masney Date: Thu Jan 8 16:16:41 2026 -0500 clk: zynqmp: divider: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 30a807808c69a1907001ffb79289237a2ee97cfa ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 0f9cf96a01fd ("clk: zynqmp: divider: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit df502559b124935f5589087fd7eacbf27ac1c136 Author: Brian Masney Date: Thu Jan 8 16:16:40 2026 -0500 clk: x86: cgu: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit bb1b0e63dbbd7150324cb4d6aef7854dbe26a617 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: f7a6bed91a19 ("clk: x86: cgu: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit ccab4798a64fdec9de055d8f38b735e8e7c2a8b3 Author: Brian Masney Date: Thu Jan 8 16:16:39 2026 -0500 clk: versaclock3: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 56c1cfb488cc17944c200edad96191a70a3783ba ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 9e3372b2ebac ("clk: versaclock3: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit c632744ff0af41461f04e7b2ce81e6afd06d4de3 Author: Brian Masney Date: Thu Jan 8 16:16:38 2026 -0500 clk: stm32: stm32-core: convert from divider_round_rate_parent() to divider_determine_rate() [ Upstream commit 2532795a6d6bb9791d713ffa9d9433f293b45b14 ] The divider_round_rate_parent() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: cd1cb38836c0 ("clk: stm32: stm32-core: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 29781f258a9f1acad589c7caf0a6e3bc605787a0 Author: Brian Masney Date: Thu Jan 8 16:16:37 2026 -0500 clk: stm32: stm32-core: convert from divider_ro_round_rate() to divider_ro_determine_rate() [ Upstream commit 6587c9dacc89ad7014bf601fe851955429f13230 ] The divider_ro_round_rate() function is now deprecated, so let's migrate to divider_ro_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: cd1cb38836c0 ("clk: stm32: stm32-core: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 141fd6e372781f7c49aadd0c0de2980cdb4f9ea7 Author: Brian Masney Date: Thu Jan 8 16:16:36 2026 -0500 clk: sprd: div: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit f78fb9422980ceeb340fa3a2e370ae8845798ec7 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: deb4740a5ff8 ("clk: sprd: div: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit aab1749732515185028449bc8bb1d5d92eba3fb8 Author: Brian Masney Date: Thu Jan 8 16:16:35 2026 -0500 clk: sophgo: sg2042-clkgen: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 77b04dc19693510ce8ed1c6eda5f5b833e208816 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Note that this commit also removes a debugging message that's not really needed. Fixes: 9a3b6993613d ("clk: sophgo: sg2042-clkgen: convert from round_rate() to determine_rate()") Tested-by: Chen Wang Reviewed-by: Chen Wang Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 73fbacf47588607acbe3c9a8375237f2e2a2569a Author: Brian Masney Date: Thu Jan 8 16:16:31 2026 -0500 clk: nxp: lpc32xx: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit af943663ccc266e6346e5645b13c0fca71d24395 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 0879768df240 ("clk: nxp: lpc32xx: convert from round_rate() to determine_rate()") Tested-by: Vladimir Zapolskiy Reviewed-by: Vladimir Zapolskiy Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 7f487ccf58b02960fa437a37c1588fcfe527f3b9 Author: Brian Masney Date: Thu Jan 8 16:16:30 2026 -0500 clk: nuvoton: ma35d1-divider: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 9329d784ca9aad03b12508128797d40fd1f2e0c1 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 215f8aa095a1 ("clk: nuvoton: ma35d1-divider: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 199625f9734ff3fffc76765d91da50dcdee79246 Author: Brian Masney Date: Thu Jan 8 16:16:29 2026 -0500 clk: milbeaut: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 865e63b038c446d38593ddbcc362ebb62e6ff007 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 7b45988fcf78 ("clk: milbeaut: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit c05f9dfa6959ddecb179bc84ffe578d6ce0248ce Author: Brian Masney Date: Thu Jan 8 16:16:27 2026 -0500 clk: loongson1: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 11d3c676e7e0f00e3398199f85e47a0e22369866 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: bb40a2ef4fc9 ("clk: loongson1: convert from round_rate() to determine_rate()") Reviewed-by: Keguang Zhang Tested-by: Keguang Zhang # on LS1B & LS1C Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 0a5c1dff51150f2e8511e548cbda4c911aa354a8 Author: Brian Masney Date: Thu Jan 8 16:16:26 2026 -0500 clk: hisilicon: clkdivider-hi6220: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit e3a5249c140a1ded55937ba04247d530a85f0edc ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 619a6210f398 ("clk: hisilicon: clkdivider-hi6220: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit aa1ed67e584265ff8aa8bc43cdeb1075d6a76d0f Author: Brian Masney Date: Thu Jan 8 16:16:25 2026 -0500 clk: bm1880: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 463b97bef0c9fb02b743d6b9f0d698cae81a1d9f ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 64613d7fb42f ("clk: bm1880: convert from round_rate() to determine_rate()") Acked-by: Manivannan Sadhasivam Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit d4274c2df180e45d385ff53b9729cc6a41fc2ec8 Author: Brian Masney Date: Thu Jan 8 16:16:23 2026 -0500 clk: actions: owl-divider: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 3ff3360440fa8cc7ef5a4da628d3b770b46a4f73 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Additionally, owl_divider_helper_round_rate() is no longer used, so let's drop that from the header file as well. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 1b04e12a8bcc ("clk: actions: owl-divider: convert from round_rate() to determine_rate()") Acked-by: Manivannan Sadhasivam Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit bfcc7cc9c36caeac92afc0437166d2d048ee021b Author: Brian Masney Date: Thu Jan 8 16:16:22 2026 -0500 clk: actions: owl-composite: convert from owl_divider_helper_round_rate() to divider_determine_rate() [ Upstream commit d0b7c5bf6c5520c35fecff34da83d390405d3eaf ] owl_divider_helper_round_rate() is just a wrapper for divider_round_rate(), which is deprecated. Let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Acked-by: Manivannan Sadhasivam Signed-off-by: Brian Masney Stable-dep-of: 3ff3360440fa ("clk: actions: owl-divider: convert from divider_round_rate() to divider_determine_rate()") Signed-off-by: Sasha Levin commit aed53da569fb96eec09b4817b1953bcc2e467eea Author: Dmitry Baryshkov Date: Sat Jan 17 05:54:47 2026 +0200 clk: qcom: gfx3d: add parent to parent request map [ Upstream commit 2583cb925ca1ce450aa5d74a05a67448db970193 ] After commit d228ece36345 ("clk: divider: remove round_rate() in favor of determine_rate()") determining GFX3D clock rate crashes, because the passed parent map doesn't provide the expected best_parent_hw clock (with the roundd_rate path before the offending commit the best_parent_hw was ignored). Set the field in parent_req in addition to setting it in the req, fixing the crash. clk_hw_round_rate (drivers/clk/clk.c:1764) (P) clk_divider_bestdiv (drivers/clk/clk-divider.c:336) divider_determine_rate (drivers/clk/clk-divider.c:358) clk_alpha_pll_postdiv_determine_rate (drivers/clk/qcom/clk-alpha-pll.c:1275) clk_core_determine_round_nolock (drivers/clk/clk.c:1606) clk_core_round_rate_nolock (drivers/clk/clk.c:1701) __clk_determine_rate (drivers/clk/clk.c:1741) clk_gfx3d_determine_rate (drivers/clk/qcom/clk-rcg2.c:1268) clk_core_determine_round_nolock (drivers/clk/clk.c:1606) clk_core_round_rate_nolock (drivers/clk/clk.c:1701) clk_core_round_rate_nolock (drivers/clk/clk.c:1710) clk_round_rate (drivers/clk/clk.c:1804) dev_pm_opp_set_rate (drivers/opp/core.c:1440 (discriminator 1)) msm_devfreq_target (drivers/gpu/drm/msm/msm_gpu_devfreq.c:51) devfreq_set_target (drivers/devfreq/devfreq.c:360) devfreq_update_target (drivers/devfreq/devfreq.c:426) devfreq_monitor (drivers/devfreq/devfreq.c:458) process_one_work (arch/arm64/include/asm/jump_label.h:36 include/trace/events/workqueue.h:110 kernel/workqueue.c:3284) worker_thread (kernel/workqueue.c:3356 (discriminator 2) kernel/workqueue.c:3443 (discriminator 2)) kthread (kernel/kthread.c:467) ret_from_fork (arch/arm64/kernel/entry.S:861) Fixes: 55213e1acec9 ("clk: qcom: Add gfx3d ping-pong PLL frequency switching") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Reviewed-by: Brian Masney Link: https://lore.kernel.org/r/20260117-db820-fix-gfx3d-v1-1-0f8894d71d63@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e5001c92fc8662900e499bfc8548ead05b74b512 Author: David Heidelberg Date: Sat Jan 17 19:18:28 2026 +0100 clk: qcom: dispcc-sm7150: Fix dispcc_mdss_pclk1_clk_src [ Upstream commit fab13d738c9bd645965464b881335f580d38a54e ] Set CLK_OPS_PARENT_ENABLE to ensure the parent gets prepared and enabled when switching to it. Fixes: e3c13e0caa8c ("clk: qcom: dispcc-sm7150: Fix dispcc_mdss_pclk0_clk_src") Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20260117-sm7150-dispcc-fix-v1-1-2f39966bcad2@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit aeb606d885ef6a4902400edf8cb0ef4b8a754410 Author: Petr Hodina Date: Wed Jan 7 12:44:43 2026 +0100 clk: qcom: dispcc-sdm845: Enable parents for pixel clocks [ Upstream commit a1d63493634e98360140027fef49d82b1ff0a267 ] Add CLK_OPS_PARENT_ENABLE to MDSS pixel clock sources to ensure parent clocks are enabled during clock operations, preventing potential stability issues during display configuration. Fixes: 81351776c9fb ("clk: qcom: Add display clock controller driver for SDM845") Signed-off-by: Petr Hodina Reviewed-by: Dmitry Baryshkov Reviewed-by: David Heidelberg Link: https://lore.kernel.org/r/20260107-stability-discussion-v2-1-ef7717b435ff@protonmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2a01a346d20ed1c27ab424e0b93cff8e850bfcda Author: Brian Masney Date: Thu Jan 8 16:16:34 2026 -0500 clk: qcom: regmap-divider: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit d8300e6e078a3a44ac0c75c6d8ba46d78ab94035 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: b6f90511c165 ("clk: qcom: regmap-divider: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260108-clk-divider-round-rate-v1-16-535a3ed73bf3@redhat.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 22d691c02ad5c8bb3df265720d4b1de05bd262ac Author: Brian Masney Date: Thu Jan 8 16:16:33 2026 -0500 clk: qcom: regmap-divider: convert from divider_ro_round_rate() to divider_ro_determine_rate() [ Upstream commit 349f02c0f5d4ee147c582b89cadd553bd534028a ] The divider_ro_round_rate() function is now deprecated, so let's migrate to divider_ro_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: b6f90511c165 ("clk: qcom: regmap-divider: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260108-clk-divider-round-rate-v1-15-535a3ed73bf3@redhat.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cdab39223d57edb4e89e7c35ff2661b8a388049c Author: Geert Uytterhoeven Date: Mon Dec 1 10:42:26 2025 +0100 clk: Move clk_{save,restore}_context() to COMMON_CLK section [ Upstream commit f47c1b77d0a2a9c0d49ec14302e74f933398d1a3 ] The clk_save_context() and clk_restore_context() helpers are only implemented by the Common Clock Framework. They are not available when using legacy clock frameworks. Dummy implementations are provided, but only if no clock support is available at all. Hence when CONFIG_HAVE_CLK=y, but CONFIG_COMMON_CLK is not enabled: m68k-linux-gnu-ld: drivers/net/phy/air_en8811h.o: in function `en8811h_resume': air_en8811h.c:(.text+0x83e): undefined reference to `clk_restore_context' m68k-linux-gnu-ld: drivers/net/phy/air_en8811h.o: in function `en8811h_suspend': air_en8811h.c:(.text+0x856): undefined reference to `clk_save_context' Fix this by moving forward declarations and dummy implementions from the HAVE_CLK to the COMMON_CLK section. Fixes: 8b95d1ce3300c411 ("clk: Add functions to save/restore clock context en-masse") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202511301553.eaEz1nEW-lkp@intel.com/ Signed-off-by: Geert Uytterhoeven Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 4fdbb1e3ffa3607d6b68a40e95712daa6e396fc8 Author: Vladimir Zapolskiy Date: Tue Jan 13 17:11:40 2026 +0200 Input: adp5589 - remove a leftover header file [ Upstream commit f8a6e5eac701369afb5d69aba875dc5fec93003d ] In commit 3bdbd0858df6 ("Input: adp5589: remove the driver") the last user of include/linux/input/adp5589.h was removed along with the whole driver, thus the header file can be also removed. Signed-off-by: Vladimir Zapolskiy Reviewed-by: Laurent Pinchart Reviewed-by: Nuno Sá Fixes: 3bdbd0858df6 ("Input: adp5589: remove the driver") Link: https://patch.msgid.link/20260113151140.3843753-1-vz@mleia.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 8ed504f525f1b7347e2067db98bf9068091b7ca3 Author: Brian Masney Date: Fri Dec 5 14:46:27 2025 -0500 clk: microchip: core: remove duplicate determine_rate on pic32_sclk_ops [ Upstream commit d93faac66dc04650d924f8f9584216d14f48fb14 ] pic32_sclk_ops previously had a sclk_round_rate() member, and this was recently converted over to sclk_determine_rate() with the help of a Coccinelle semantic patch. pic32_sclk_ops now has two conflicting determine_rate ops members. Prior to the conversion, pic32_sclk_ops already had a determine_rate member that points to __clk_mux_determine_rate(). When both the round_rate() and determine_rate() ops are defined, the clk core only uses the determine_rate() op. Let's go ahead and drop the recently converted sclk_determine_rate() to match the previous functionality prior to the conversion. Fixes: e9f039c08cdc ("clk: microchip: core: convert from round_rate() to determine_rate()") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202511222115.uvHrP95A-lkp@intel.com/ Signed-off-by: Brian Masney Reviewed-by: Claudiu Beznea Link: https://lore.kernel.org/r/20251205-clk-microchip-fixes-v3-1-a02190705e47@redhat.com Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit 0533f1cdb382d9c9ea0f92dffbaeb42cf006f01f Author: Miaoqian Lin Date: Tue Aug 5 07:03:58 2025 +0400 clk: rockchip: Fix error pointer check after rockchip_clk_register_gate_link() [ Upstream commit a8d722f03923b1c6166d39482c6df8f017e185d9 ] Replace NULL check with IS_ERR_OR_NULL() check after calling rockchip_clk_register_gate_link() since this function returns error pointers (ERR_PTR). Fixes: c62fa612cfa6 ("clk: rockchip: implement linked gate clock support") Signed-off-by: Miaoqian Lin Link: https://patch.msgid.link/20250805030358.3665878-1-linmq006@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 0b45cddb7385553c3d2285c2a62eda46d200230f Author: Brian Masney Date: Thu Jan 8 16:16:32 2026 -0500 clk: qcom: alpha-pll: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit e1f08613e113f02a3ec18c9a7964de97f940acbf ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 0e56e3369b60 ("clk: qcom: alpha-pll: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260108-clk-divider-round-rate-v1-14-535a3ed73bf3@redhat.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 87fa98532b45bed3b5ba2d822357a294c8fabc36 Author: George Moussalem Date: Fri Nov 28 15:03:19 2025 +0400 clk: qcom: gcc-ipq5018: flag sleep clock as critical [ Upstream commit 04c4dc1f541135708d90a9b4632af51136f93ac3 ] The sleep clock never be disabled. To avoid the kernel trying to disable it and keep it always on, flag it as critical. Fixes: e3fdbef1bab8 ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018") Signed-off-by: George Moussalem Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251128-ipq5018-sleep-clk-fix-v1-1-6f4b75ec336c@outlook.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b88e84b154b97318bd79fb20b4b87cce049db822 Author: Barnabás Czémán Date: Mon Nov 17 18:58:48 2025 +0100 clk: qcom: gcc-msm8917: Remove ALWAYS_ON flag from cpp_gdsc [ Upstream commit e4eb42f290aecac0ba355b1f8d7243be6de11f32 ] cpp_gdsc should not be always on, ALWAYS_ON flag was set accidentally. Fixes: 33cc27a47d3a ("clk: qcom: Add global clock controller driver for MSM8917") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251117-fix-gdsc-cpp-msm8917-msm8953-v1-2-db33adcff28a@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9dbd33356e3d95c704ebc6dd26f1bf58bd15d68d Author: Barnabás Czémán Date: Mon Nov 17 18:58:47 2025 +0100 clk: qcom: gcc-msm8953: Remove ALWAYS_ON flag from cpp_gdsc [ Upstream commit 5f613e7034187179a9d088ff5fd02b1089d0cf20 ] cpp_gdsc should not be always on, ALWAYS_ON flag was set accidentally. Fixes: 9bb6cfc3c77e ("clk: qcom: Add Global Clock Controller driver for MSM8953") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251117-fix-gdsc-cpp-msm8917-msm8953-v1-1-db33adcff28a@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a9d771adb49a18687abb8798004d08c382452c65 Author: Jagadeesh Kona Date: Thu Nov 27 23:27:43 2025 +0530 clk: qcom: gcc-glymur: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit d5639a6d72810023d257c935cb763aea1ada1abc ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: efe504300a17 ("clk: qcom: gcc: Add support for Global Clock Controller") Signed-off-by: Jagadeesh Kona Reviewed-by: Imran Shaik Reviewed-by: Taniya Das Reviewed-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-8-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8d7df9126dad4d1a952febb1bc3ca1fd19962e55 Author: Jagadeesh Kona Date: Thu Nov 27 23:27:42 2025 +0530 clk: qcom: gcc-qdu1000: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit 947c4b326c1f4dc64aed42170b39c2cf551ba8ca ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: baa316580013 ("clk: qcom: gcc-qdu1000: Update the SDCC clock RCG ops") Signed-off-by: Jagadeesh Kona Reviewed-by: Imran Shaik Reviewed-by: Taniya Das Reviewed-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-7-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 357bdc307c5a1463fc1ef218864c3527c9a406d4 Author: Jagadeesh Kona Date: Thu Nov 27 23:27:41 2025 +0530 clk: qcom: gcc-x1e80100: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit a468047c4e1c56783204a3ac551b843b4277c8fc ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: 161b7c401f4b ("clk: qcom: Add Global Clock controller (GCC) driver for X1E80100") Signed-off-by: Jagadeesh Kona Reviewed-by: Imran Shaik Reviewed-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-6-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 16a21335eff9c80846308d369ccd100d5438413c Author: Jagadeesh Kona Date: Thu Nov 27 23:27:40 2025 +0530 clk: qcom: gcc-milos: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit 08da8d7dabb161cea14c6d3ad9b5037aaf6d4b7e ] Use shared_floor_ops for the SDCC RCGs to avoid any overclocking issues in SDCC usecases. Fixes: 88174d5d9422 ("clk: qcom: Add Global Clock controller (GCC) driver for Milos") Reviewed-by: Taniya Das Reviewed-by: Imran Shaik Reviewed-by: Dmitry Baryshkov Reviewed-by: Vladimir Zapolskiy Signed-off-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-5-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 76d5437ca4d0be2b06b45dcb04709c38c7e120cb Author: Jagadeesh Kona Date: Thu Nov 27 23:27:39 2025 +0530 clk: qcom: gcc-sdx75: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit 4b057462bb61a6571608ba393e6e018c9da9c9c3 ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: 108cdc09b2de ("clk: qcom: Add GCC driver support for SDX75") Reviewed-by: Taniya Das Reviewed-by: Imran Shaik Reviewed-by: Dmitry Baryshkov Reviewed-by: Vladimir Zapolskiy Signed-off-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-4-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 37babf26bfb574cce17c216849b386db9322f297 Author: Jagadeesh Kona Date: Thu Nov 27 23:27:38 2025 +0530 clk: qcom: gcc-sm4450: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit 458e8a082186335380a9ab83003a385aec9bb254 ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: c32c4ef98bac ("clk: qcom: Add GCC driver support for SM4450") Reviewed-by: Taniya Das Reviewed-by: Imran Shaik Reviewed-by: Dmitry Baryshkov Reviewed-by: Vladimir Zapolskiy Signed-off-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-3-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7873e2a407a03ec068fddc103ca7d7a1ac8f4f98 Author: Jagadeesh Kona Date: Thu Nov 27 23:27:37 2025 +0530 clk: qcom: gcc-sm8750: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit a7231d4aa084e485394f9214ec9bcb2d1f65dde9 ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: 3267c774f3ff ("clk: qcom: Add support for GCC on SM8750") Reviewed-by: Taniya Das Reviewed-by: Imran Shaik Reviewed-by: Dmitry Baryshkov Reviewed-by: Vladimir Zapolskiy Signed-off-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-2-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 527508eb5712d997827a016c0929c96013b20da0 Author: Jagadeesh Kona Date: Thu Nov 27 23:27:36 2025 +0530 clk: qcom: gcc-sm8450: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit 89428516f99572a9c37ebbb7859595881e7025a0 ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: a27ac3806b0a ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs") Reviewed-by: Taniya Das Reviewed-by: Imran Shaik Reviewed-by: Dmitry Baryshkov Reviewed-by: Vladimir Zapolskiy Signed-off-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-1-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1bc262014a14ace3228d990617760e1265b0ac3e Author: Martin Blumenstingl Date: Mon Jan 5 21:47:09 2026 +0100 clk: meson: g12a: Limit the HDMI PLL OD to /4 [ Upstream commit 7aa6c24697ef5db1402dd38743914493cd5b356d ] GXBB has the HDMI PLL OD in the HHI_HDMI_PLL_CNTL2 register while for G12A/G12B/SM1 the OD has moved to HHI_HDMI_PLL_CNTL0. At first glance the rest of the OD setup seems identical. However, looking at the downstream kernel sources as well as testing shows that G12A/G12B/SM1 only supports three OD values: - register value 0 means: divide by 1 - register value 1 means: divide by 2 - register value 2 means: divide by 4 Downstream sources are also only using OD register values 0, 1 and 2 for G12A/G12B/SM1 (while for GXBB the downstream kernel sources are also using value 3 which means: divide by 8). Add clk_div_table and have it replace the CLK_DIVIDER_POWER_OF_TWO flag to make the kernel's view of this register match with how the hardware actually works. Fixes: 085a4ea93d54 ("clk: meson: g12a: add peripheral clock controller") Signed-off-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20260105204710.447779-3-martin.blumenstingl@googlemail.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit e82d721b05e070b5044a1c307088829a802a2ab3 Author: Martin Blumenstingl Date: Mon Jan 5 21:47:08 2026 +0100 clk: meson: gxbb: Limit the HDMI PLL OD to /4 on GXL/GXM SoCs [ Upstream commit 5b1a43950fd3162af0ce52b13c14a2d29b179d4f ] GXBB has the HDMI PLL OD in the HHI_HDMI_PLL_CNTL2 register while for GXL/GXM the OD has moved to HHI_HDMI_PLL_CNTL3. At first glance the rest of the OD setup seems identical. However, looking at the downstream kernel sources as well as testing shows that GXL only supports three OD values: - register value 0 means: divide by 1 - register value 1 means: divide by 2 - register value 2 means: divide by 4 Using register value 3 (which on GXBB means: divide by 8) still divides by 4 as verified using meson-clk-measure. Downstream sources are also only using OD register values 0, 1 and 2 for GXL (while for GXBB the downstream kernel sources are also using value 3). Add clk_div_table and have it replace the CLK_DIVIDER_POWER_OF_TWO flag to make the kernel's view of this register match with how the hardware actually works. Fixes: 69d92293274b ("clk: meson: add the gxl hdmi pll") Signed-off-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20260105204710.447779-2-martin.blumenstingl@googlemail.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit f7b0686119fd25868dc954da4c54b15626199d6a Author: Taniya Das Date: Mon Jan 5 16:09:50 2026 +0530 clk: qcom: rcg2: compute 2d using duty fraction directly [ Upstream commit d6205a1878dd4cc9664c4b4829b68a29c0426efc ] The duty-cycle calculation in clk_rcg2_set_duty_cycle() currently derives an intermediate percentage `duty_per = (num * 100) / den` and then computes: d = DIV_ROUND_CLOSEST(n * duty_per * 2, 100); This introduces integer truncation at the percentage step (division by `den`) and a redundant scaling by 100, which can reduce precision for large `den` and skew the final rounding. Compute `2d` directly from the duty fraction to preserve precision and avoid the unnecessary scaling: d = DIV_ROUND_CLOSEST(n * duty->num * 2, duty->den); This keeps the intended formula `d ≈ n * 2 * (num/den)` while performing a single, final rounded division, improving accuracy especially for small duty cycles or large denominators. It also removes the unused `duty_per` variable, simplifying the code. There is no functional changes beyond improved numerical accuracy. Fixes: 7f891faf596ed ("clk: qcom: clk-rcg2: Add support for duty-cycle for RCG") Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/20260105-duty_cycle_precision-v2-1-d1d466a6330a@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit aa14e7603835397665bf7fb38a02da1fa8dc5fa6 Author: Vladimir Zapolskiy Date: Mon Nov 24 23:20:12 2025 +0200 clk: qcom: gcc-sm8650: Use floor ops for SDCC RCGs [ Upstream commit 8c4415fd17cd5979c31a4bf303acc702e9726033 ] In line with commit a27ac3806b0a ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs") done to fix issues with overclocked SD cards on SM8450 powered boards set floor clock operations for SDCC RCGs on SM8650. This change fixes initialization of some SD cards, where the problem is manifested by the SDHC driver: mmc0: Card appears overclocked; req 50000000 Hz, actual 100000000 Hz mmc0: error -110 whilst initialising SD card Fixes: c58225b7e3d7 ("clk: qcom: add the SM8650 Global Clock Controller driver, part 1") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Neil Armstrong Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20251124212012.3660189-3-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b714c1d0bb437e46b1bb82fea5d0a138bbfe6f98 Author: Vladimir Zapolskiy Date: Mon Nov 24 23:20:11 2025 +0200 clk: qcom: gcc-sm8550: Use floor ops for SDCC RCGs [ Upstream commit 1c06e3956054fb5a0930f07b02726b1774b6c700 ] In line with commit a27ac3806b0a ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs") done to fix issues with overclocked SD cards on SM8450 powered boards set floor clock operations for SDCC RCGs on SM8550. This change fixes initialization of some SD cards, where the problem is manifested by the SDHC driver: mmc0: Card appears overclocked; req 50000000 Hz, actual 100000000 Hz mmc0: error -110 whilst initialising SD card Fixes: 955f2ea3b9e9 ("clk: qcom: Add GCC driver for SM8550") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Neil Armstrong Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20251124212012.3660189-2-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e9ed7237b8249227943c5d15240b36bdcad26602 Author: Inochi Amaoto Date: Fri Dec 19 09:28:17 2025 +0800 clk: spacemit: Respect Kconfig setting when building modules [ Upstream commit 5ec8cbbc54c82c0bdae4dbf0e5aecf9817bde2b9 ] Currently, the SPACEMIT_CCU entry is only a switch for enabling entry SPACEMIT_K1_CCU. It does not guide the build for common clock codes even if it is a tristate entry. This makes this entry useless. Change the Makefile to add a separate build for common clock logic, so the SPACEMIT_CCU entry takes effect, also add necessary MODULE_LICENSE()/MODULE_DESCRIPTION()/EXPORT_SYMBOL() for the module build. Fixes: 1b72c59db0ad ("clk: spacemit: Add clock support for SpacemiT K1 SoC") Signed-off-by: Inochi Amaoto Reviewed-by: Yixun Lan Link: https://lore.kernel.org/r/20251219012819.440972-2-inochiama@gmail.com Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit 19eb98a970c908d9b45a3558bcebef546d3ec24a Author: Yao Zi Date: Thu Nov 20 13:14:11 2025 +0000 clk: thead: th1520-ap: Poll for PLL lock and wait for stability [ Upstream commit 892abfbed71e8e0fc5d6ccee1e975904805c6327 ] All PLLs found on TH1520 SoC take 21250ns at maximum to lock, and their lock status is indicated by register PLL_STS (offset 0x80 inside AP clock controller). We should poll the register to ensure the PLL actually locks after enabling it. Furthermore, a 30us delay is added after enabling the PLL, after which the PLL could be considered stable as stated by vendor clock code. Fixes: 56a48c1833aa ("clk: thead: add support for enabling/disabling PLLs") Reviewed-by: Drew Fustini Signed-off-by: Yao Zi Signed-off-by: Drew Fustini Signed-off-by: Sasha Levin commit 3d4202ee6494c0d576cdc104b12e0834ca8136a8 Author: Felix Gu Date: Tue Feb 3 20:14:58 2026 +0800 fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe() [ Upstream commit ce4e25198a6aaaaf36248edf8daf3d744ec8e309 ] In au1200fb_drv_probe(), when platform_get_irq fails(), it directly returns from the function with an error code, which causes a memory leak. Replace it with a goto label to ensure proper cleanup. Fixes: 4e88761f5f8c ("fbdev: au1200fb: Fix missing IRQ check in au1200fb_drv_probe") Signed-off-by: Felix Gu Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit e76a2f1d40ea91b656ff069a8faa303daa6c2add Author: Felix Gu Date: Sat Jan 31 20:48:33 2026 +0800 fbdev: of_display_timing: Fix device node reference leak in of_get_display_timings() [ Upstream commit c39ee2d264f98efa14aa46c9942114cb03c7baa6 ] Use for_each_child_of_node_scoped instead of for_each_child_of_node to ensure automatic of_node_put on early exit paths, preventing device node reference leak. Fixes: cc3f414cf2e4 ("video: add of helper for display timings/videomode") Signed-off-by: Felix Gu Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 2cafad617431f02393383c9faff17747da7d6f01 Author: Sudeep Holla Date: Thu Oct 16 20:08:15 2025 +0100 Revert "mailbox/pcc: support mailbox management of the shared buffer" [ Upstream commit f82c3e62b6b8c31d8c56415bf38658f306fda4cb ] This reverts commit 5378bdf6a611a32500fccf13d14156f219bb0c85. Commit 5378bdf6a611 ("mailbox/pcc: support mailbox management of the shared buffer") attempted to introduce generic helpers for managing the PCC shared memory, but it largely duplicates functionality already provided by the mailbox core and leaves gaps: 1. TX preparation: The mailbox framework already supports this via ->tx_prepare callback for mailbox clients. The patch adds pcc_write_to_buffer() and expects clients to toggle pchan->chan.manage_writes, but no drivers set manage_writes, so pcc_write_to_buffer() has no users. 2. RX handling: Data reception is already delivered through mbox_chan_received_data() and client ->rx_callback. The patch adds an optional pchan->chan.rx_alloc, which again has no users and duplicates the existing path. 3. Completion handling: While adding last_tx_done is directionally useful, the implementation only covers Type 3/4 and fails to handle the absence of a command_complete register, so it is incomplete for other types. Given the duplication and incomplete coverage, revert this change. Any new requirements should be addressed in focused follow-ups rather than bundling multiple behavioral changes together. Fixes: 5378bdf6a611 ("mailbox/pcc: support mailbox management of the shared buffer") Signed-off-by: Sudeep Holla Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 9a10843740d777707de3e8faca02752dde297127 Author: Shengjiu Wang Date: Thu Dec 18 15:17:50 2025 +0800 remoteproc: imx_dsp_rproc: Only reset carveout memory at RPROC_OFFLINE state [ Upstream commit b490ddf27be28e64a39c08ae643d7b22561beaf6 ] Do not reset memory at suspend and resume stage, because some memory is used to save the software state for resume, if it is cleared, the resume operation can fail. Fixes: c4c432dfb00f ("remoteproc: imx_dsp_rproc: Add support of recovery and coredump process") Signed-off-by: Shengjiu Wang Reviewed-by: Daniel Baluta Reviewed-by: Iuliana Prodan Link: https://lore.kernel.org/r/20251218071750.2692132-1-shengjiu.wang@nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit ca8f2551772d120d3b37b2d933db0aba09542f71 Author: Steven Rostedt Date: Mon Jan 26 13:00:37 2026 -0500 tracing: Remove duplicate ENABLE_EVENT_STR and DISABLE_EVENT_STR macros [ Upstream commit 9df0e49c5b9b8d051529be9994e4f92f2d20be6f ] The macros ENABLE_EVENT_STR and DISABLE_EVENT_STR were added to trace.h so that more than one file can have access to them, but was never removed from their original location. Remove the duplicates. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Tom Zanussi Link: https://patch.msgid.link/20260126130037.4ba201f9@gandalf.local.home Fixes: d0bad49bb0a09 ("tracing: Add enable_hist/disable_hist triggers") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 335dfe4bc6368e70e8c15419375cf609c4f85558 Author: Miaoqian Lin Date: Thu Dec 11 14:00:58 2025 +0400 tracing: Properly process error handling in event_hist_trigger_parse() [ Upstream commit 0550069cc25f513ce1f109c88f7c1f01d63297db ] Memory allocated with trigger_data_alloc() requires trigger_data_free() for proper cleanup. Replace kfree() with trigger_data_free() to fix this. Found via static analysis and code review. This isn't a real bug due to the current code basically being an open coded version of trigger_data_free() without the synchronization. The synchronization isn't needed as this is the error path of creation and there's nothing to synchronize against yet. Replace the kfree() to be consistent with the allocation. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Tom Zanussi Link: https://patch.msgid.link/20251211100058.2381268-1-linmq006@gmail.com Fixes: e1f187d09e11 ("tracing: Have existing event_command.parse() implementations use helpers") Signed-off-by: Miaoqian Lin Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 47d3fed638664a72b2b84f02b8ef85d7fe75c048 Author: Sagi Grimberg Date: Sat Dec 27 12:46:29 2025 +0200 fs/nfs: Fix readdir slow-start regression [ Upstream commit 42e7c876b182da65723700f6bc507a8aecb10d3b ] Commit 580f236737d1 ("NFS: Adjust the amount of readahead performed by NFS readdir") reduces the amount of readahead names caching done by the client. The downside of this approach is READDIR now may suffer from a slow-start issue, where initially it will fetch names that fit in a single page, then in 2, 4, 8 until the maximum supported transfer size (usually 1M). This patch tries to take a balanced approach between mitigating the slow-start issue still maintaining some efficiency gains. Fixes: 580f236737d1 ("NFS: Adjust the amount of readahead performed by NFS readdir") Signed-off-by: Sagi Grimberg Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit e568088337e5a66b7e959153e0c9b6e68d98b85c Author: Li Chen Date: Tue Feb 3 10:13:51 2026 +0800 nvdimm: virtio_pmem: serialize flush requests [ Upstream commit a9ba6733c7f1096c4506bf4e34a546e07242df74 ] Under heavy concurrent flush traffic, virtio-pmem can overflow its request virtqueue (req_vq): virtqueue_add_sgs() starts returning -ENOSPC and the driver logs "no free slots in the virtqueue". Shortly after that the device enters VIRTIO_CONFIG_S_NEEDS_RESET and flush requests fail with "virtio pmem device needs a reset". Serialize virtio_pmem_flush() with a per-device mutex so only one flush request is in-flight at a time. This prevents req_vq descriptor overflow under high concurrency. Reproducer (guest with virtio-pmem): - mkfs.ext4 -F /dev/pmem0 - mount -t ext4 -o dax,noatime /dev/pmem0 /mnt/bench - fio: ioengine=io_uring rw=randwrite bs=4k iodepth=64 numjobs=64 direct=1 fsync=1 runtime=30s time_based=1 - dmesg: "no free slots in the virtqueue" "virtio pmem device needs a reset" Fixes: 6e84200c0a29 ("virtio-pmem: Add virtio pmem driver") Signed-off-by: Li Chen Acked-by: Pankaj Gupta Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20260203021353.121091-1-me@linux.beauty Signed-off-by: Ira Weiny Signed-off-by: Sasha Levin commit 25ab5e97d3c5f3ed594b4a65d1cc99dc24756681 Author: Colin Ian King Date: Thu Jan 29 15:53:32 2026 +0000 scsi: csiostor: Fix dereference of null pointer rn [ Upstream commit 1982257570b84dc33753d536dd969fd357a014e9 ] The error exit path when rn is NULL ends up deferencing the null pointer rn via the use of the macro CSIO_INC_STATS. Fix this by adding a new error return path label after the use of the macro to avoid the deference. Fixes: a3667aaed569 ("[SCSI] csiostor: Chelsio FCoE offload driver") Signed-off-by: Colin Ian King Link: https://patch.msgid.link/20260129155332.196338-1-colin.i.king@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 77794465365bf1893e06faf684559eeee4adc305 Author: Arnd Bergmann Date: Mon Feb 2 10:50:18 2026 +0100 scsi: ufs: host: mediatek: Require CONFIG_PM [ Upstream commit bbb8d98fb4536594cb104fd630ea0f7dce3771d6 ] The added print statement from a recent fix causes the driver to fail building when CONFIG_PM is disabled: drivers/ufs/host/ufs-mediatek.c: In function 'ufs_mtk_resume': drivers/ufs/host/ufs-mediatek.c:1890:40: error: 'struct dev_pm_info' has no member named 'request' 1890 | hba->dev->power.request, It seems unlikely that the driver can work at all without CONFIG_PM, so just add a dependency and remove the existing ifdef checks, rather than adding another ifdef. Fixes: 15ef3f5aa822 ("scsi: ufs: host: mediatek: Enhance recovery on resume failure") Signed-off-by: Arnd Bergmann Reviewed-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20260202095052.1232703-1-arnd@kernel.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e5579ebaadc7b699868dad0f591a7bf83cd647e1 Author: Zilin Guan Date: Sat Jan 31 09:36:41 2026 +0000 scsi: smartpqi: Fix memory leak in pqi_report_phys_luns() [ Upstream commit 41b37312bd9722af77ec7817ccf22d7a4880c289 ] pqi_report_phys_luns() fails to release the rpl_list buffer when encountering an unsupported data format or when the allocation for rpl_16byte_wwid_list fails. These early returns bypass the cleanup logic, leading to memory leaks. Consolidate the error handling by adding an out_free_rpl_list label and use goto statements to ensure rpl_list is consistently freed on failure. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 28ca6d876c5a ("scsi: smartpqi: Add extended report physical LUNs") Signed-off-by: Zilin Guan Tested-by: Don Brace Acked-by: Don Brace Link: https://patch.msgid.link/20260131093641.1008117-1-zilin@seu.edu.cn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 48cb99e745614fe112996d48cc49580a01865135 Author: Olga Kornievskaia Date: Mon Jan 26 14:15:39 2026 -0500 pNFS: fix a missing wake up while waiting on NFS_LAYOUT_DRAIN [ Upstream commit 5248d8474e594d156bee1ed10339cc16e207a28b ] It is possible to have a task get stuck on waiting on the NFS_LAYOUT_DRAIN in the following scenario 1. cpu a: waiter test NFS_LAYOUT_DRAIN (1) and plh_outstanding (1) 2. cpu b: atomic_dec_and_test() -> clear bit -> wake up 3. cpu c: sets NFS_LAYOUT_DRAIN again 4. cpu a: calls wait_on_bit() sleeps forever. To expand on this we have say 2 outstanding pnfs write IO that get ESTALE which causes both to call pnfs_destroy_layout() and set the NFS_LAYOUT_DRAIN bit but the 1st one doesn't call the pnfs_put_layout_hdr() yet (as that would prevent the 2nd ESTALE write from trying to call pnfs_destroy_layout()). If the 1st ESTALE write is the one that initially sets the NFS_LAYOUT_DRAIN so that new IO on this file initiates new LAYOUTGET. Another new write would find NFS_LAYOUT_DRAIN set and phl_outstanding>0 (step 1) and would wait_on_bit(). LAYOUTGET completes doing step 2. Now, the 2nd of ESTALE writes is calling pnfs_destory_layout() and set the NFS_LAYOUT_DRAIN bit (step 3). Finally, the waiting write wakes up to check the bit and goes back to sleep. The problem revolves around the fact that if NFS_LAYOUT_INVALID_STID was already set, it should not do the work of pnfs_mark_layout_stateid_invalid(), thus NFS_LAYOUT_DRAIN will not be set more than once for an invalid layout. Suggested-by: Trond Myklebust Fixes: 880265c77ac4 ("pNFS: Avoid a live lock condition in pnfs_update_layout()") Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 7bc44485182c2f4bb27ce070da1e1c0a2437ba8d Author: Yi Liu Date: Thu Jan 29 17:49:00 2026 +0800 RDMA/uverbs: Add __GFP_NOWARN to ib_uverbs_unmarshall_recv() kmalloc [ Upstream commit 58b604dfc7bb753f91bc0ccd3fa705e14e6edfb4 ] Since wqe_size in ib_uverbs_unmarshall_recv() is user-provided and already validated, but can still be large, add __GFP_NOWARN to suppress memory allocation warnings for large sizes, consistent with the similar fix in ib_uverbs_post_send(). Fixes: 67cdb40ca444 ("[IB] uverbs: Implement more commands") Signed-off-by: Yi Liu Link: https://patch.msgid.link/20260129094900.3517706-1-liuy22@mails.tsinghua.edu.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f354f16e96989bd93c0f7ccb33b2c96851a94ea2 Author: Val Packett Date: Tue Jan 20 20:57:58 2026 -0300 power: supply: qcom_battmgr: Recognize "LiP" as lithium-polymer [ Upstream commit c655f45480637aee326b5bd96488d35ab90db2b0 ] On the Dell Latitude 7455, the firmware uses "LiP" with a lowercase 'i' for the battery chemistry type, but only all-uppercase "LIP" was being recognized. Add the CamelCase variant to the check to fix the "Unknown battery technology" warning. Fixes: 202ac22b8e2e ("power: supply: qcom_battmgr: Add lithium-polymer entry") Signed-off-by: Val Packett Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20260120235831.479038-1-val@packett.cool Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 47abfc207ab02cf1297257e282e8048da63f0d08 Author: Waqar Hameed Date: Fri Jan 23 11:24:20 2026 +0100 power: supply: pm8916_lbc: Fix use-after-free for extcon in IRQ handler [ Upstream commit 23067259919663580c6f81801847cfc7bd54fd1f ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `extcon` handle, means that the `extcon` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `extcon` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `extcon_set_state_sync()` with a freed `extcon` handle. Which usually crashes the system or otherwise silently corrupts the memory... Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `extcon` handle. Fixes: f8d7a3d21160 ("power: supply: Add driver for pm8916 lbc") Signed-off-by: Waqar Hameed Reviewed-by: Nikita Travkin Link: https://patch.msgid.link/e2a4cd2fcd42b6cd97d856c17c097289a2aed393.1769163273.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit ac092258d0d6beac09dccc2a4f4ac9f3a474fb49 Author: Weili Qian Date: Thu Jan 22 10:02:02 2026 +0800 hisi_acc_vfio_pci: fix VF reset timeout issue [ Upstream commit a22099ed7936f8e8dabbdbadd97d56047797116b ] If device error occurs during live migration, qemu will reset the VF. At this time, VF reset and device reset are performed simultaneously. The VF reset will timeout. Therefore, the QM_RESETTING flag is used to ensure that VF reset and device reset are performed serially. Fixes: b0eed085903e ("hisi_acc_vfio_pci: Add support for VFIO live migration") Signed-off-by: Weili Qian Link: https://lore.kernel.org/r/20260122020205.2884497-2-liulongfang@huawei.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 980aa1f8d0dd1291682b588cad7ec8e34d2c462a Author: Miquel Raynal Date: Fri Jan 9 18:18:02 2026 +0100 mtd: spinand: Fix kernel doc [ Upstream commit a57b1f07d2d35843a7ada30c8cf9a215c0931868 ] The @data buffer is 5 bytes, not 4, it has been extended for the need of devices with an extra ID bytes. Fixes: 34a956739d29 ("mtd: spinand: Add support for 5-byte IDs") Reviewed-by: Tudor Ambarus Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 39b74ec0869f58b843ecb5c5a19b1b87cd995b6f Author: Weigang He Date: Fri Jan 23 05:26:08 2026 +0000 mtd: parsers: ofpart: fix OF node refcount leak in parse_fixed_partitions() [ Upstream commit 7cce81df7d26d44123bd7620715c8349d96793d7 ] of_get_child_by_name() returns a node pointer with refcount incremented, which must be released with of_node_put() when done. However, in parse_fixed_partitions(), when dedicated is true (i.e., a "partitions" subnode was found), the ofpart_node obtained from of_get_child_by_name() is never released on any code path. Add of_node_put(ofpart_node) calls on all exit paths when dedicated is true to fix the reference count leak. This bug was detected by our static analysis tool. Fixes: 562b4e91d3b2 ("mtd: parsers: ofpart: fix parsing subpartitions") Signed-off-by: Weigang He Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit eacca141258750059e92c9485e3ed288b0d21c91 Author: Yuxiong Wang Date: Thu Jan 29 14:45:52 2026 +0800 cxl: Fix premature commit_end increment on decoder commit failure [ Upstream commit 7b6f9d9b1ea05c9c22570126547c780e8c6c3f62 ] In cxl_decoder_commit(), commit_end is incremented before verifying whether the commit succeeded, and the CXL_DECODER_F_ENABLE bit in cxld->flags is only set after a successful commit. As a result, if the commit fails, commit_end has been incremented and cxld->reset() has no effect since the flag is not set, so commit_end remains incorrectly incremented. The inconsistency between commit_end and CXL_DECODER_F_ENABLE causes failure during subsequent either commit or reset operations. Fix this by incrementing commit_end only after confirming the commit succeeded. Also, remove the ineffective cxld->reset() call. According to CXL Spec r4.0 8.2.4.20.12 Committing Decoder Programming, since cxld_await_commit() has cleared the decoder commit bit on failure, no additional reset is required. [dj: Fixed commit log 80 char wrapping. ] [dj: Fix "Fixes" tag to correct hash length. ] [dj: Change spec to r4.0. ] Fixes: 176baefb2eb5 ("cxl/hdm: Commit decoder state to hardware") Signed-off-by: Yuxiong Wang Acked-by: Huang Ying Reviewed-by: Dave Jiang Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260129064552.31180-1-yuxiong.wang@linux.alibaba.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit cc66fc9b5cf7f44a9c34cd0cc42fc3182880c393 Author: Chuck Lever Date: Tue Jan 27 19:53:59 2026 -0500 RDMA/core: add rdma_rw_max_sge() helper for SQ sizing [ Upstream commit afcae7d7b8a278a6c29e064f99e5bafd4ac1fb37 ] svc_rdma_accept() computes sc_sq_depth as the sum of rq_depth and the number of rdma_rw contexts (ctxts). This value is used to allocate the Send CQ and to initialize the sc_sq_avail credit pool. However, when the device uses memory registration for RDMA operations, rdma_rw_init_qp() inflates the QP's max_send_wr by a factor of three per context to account for REG and INV work requests. The Send CQ and credit pool remain sized for only one work request per context, causing Send Queue exhaustion under heavy NFS WRITE workloads. Introduce rdma_rw_max_sge() to compute the actual number of Send Queue entries required for a given number of rdma_rw contexts. Upper layer protocols call this helper before creating a Queue Pair so that their Send CQs and credit accounting match the QP's true capacity. Update svc_rdma_accept() to use rdma_rw_max_sge() when computing sc_sq_depth, ensuring the credit pool reflects the work requests that rdma_rw_init_qp() will reserve. Reviewed-by: Christoph Hellwig Fixes: 00bd1439f464 ("RDMA/rw: Support threshold for registration vs scattering to local pages") Signed-off-by: Chuck Lever Link: https://patch.msgid.link/20260128005400.25147-5-cel@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 5ae9da022ee3c97e6469eabcddce9271501ddbad Author: Li Zhijian Date: Tue Jan 20 15:44:37 2026 +0800 RDMA/rxe: Fix race condition in QP timer handlers [ Upstream commit 87bf646921430e303176edc4eb07c30160361b73 ] I encontered the following warning: WARNING: drivers/infiniband/sw/rxe/rxe_task.c:249 at rxe_sched_task+0x1c8/0x238 [rdma_rxe], CPU#0: swapper/0/0 ... libsha1 [last unloaded: ip6_udp_tunnel] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G C 6.19.0-rc5-64k-v8+ #37 PREEMPT Tainted: [C]=CRAP Hardware name: Raspberry Pi 4 Model B Rev 1.2 Call trace: rxe_sched_task+0x1c8/0x238 [rdma_rxe] (P) retransmit_timer+0x130/0x188 [rdma_rxe] call_timer_fn+0x68/0x4d0 __run_timers+0x630/0x888 ... WARNING: drivers/infiniband/sw/rxe/rxe_task.c:38 at rxe_sched_task+0x1c0/0x238 [rdma_rxe], CPU#0: swapper/0/0 ... WARNING: drivers/infiniband/sw/rxe/rxe_task.c:111 at do_work+0x488/0x5c8 [rdma_rxe], CPU#3: kworker/u17:4/93400 ... refcount_t: underflow; use-after-free. WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x138/0x1a0, CPU#3: kworker/u17:4/93400 The issue is caused by a race condition between retransmit_timer() and rxe_destroy_qp, leading to the Queue Pair's (QP) reference count dropping to zero during timer handler execution. It seems this warning is harmless because rxe_qp_do_cleanup() will flush all pending timers and requests. Example of flow causing the issue: CPU0 CPU1 retransmit_timer() { spin_lock_irqsave rxe_destroy_qp() __rxe_cleanup() __rxe_put() // qp->ref_count decrease to 0 rxe_qp_do_cleanup() { if (qp->valid) { rxe_sched_task() { WARN_ON(rxe_read(task->qp) <= 0); } } spin_unlock_irqrestore } spin_lock_irqsave qp->valid = 0 spin_unlock_irqrestore } Ensure the QP's reference count is maintained and its validity is checked within the timer callbacks by adding calls to rxe_get(qp) and corresponding rxe_put(qp) after use. Signed-off-by: Li Zhijian Fixes: d94671632572 ("RDMA/rxe: Rewrite rxe_task.c") Link: https://patch.msgid.link/20260120074437.623018-1-lizhijian@fujitsu.com Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit b2bc649c18fbe8a7fd38d17266da3dcbfbcc44d2 Author: Zilin Guan Date: Mon Jan 26 07:48:01 2026 +0000 RDMA/mlx5: Fix memory leak in GET_DATA_DIRECT_SYSFS_PATH handler [ Upstream commit 9b9d253908478f504297ac283c514e5953ddafa6 ] The UVERBS_HANDLER(MLX5_IB_METHOD_GET_DATA_DIRECT_SYSFS_PATH) function allocates memory for the device path using kobject_get_path(). If the length of the device path exceeds the output buffer length, the function returns -ENOSPC but does not free the allocated memory, resulting in a memory leak. Add a kfree() call to the error path to ensure the allocated memory is properly freed. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: ec7ad6530909 ("RDMA/mlx5: Introduce GET_DATA_DIRECT_SYSFS_PATH ioctl") Signed-off-by: Zilin Guan Link: https://patch.msgid.link/20260126074801.627898-1-zilin@seu.edu.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit bf4454da8b1e712714628c0a0d6e7845bb40790a Author: Yi Liu Date: Thu Jan 22 22:29:00 2026 +0800 RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send [ Upstream commit 1956f0a74ccf5dc9c3ef717f2985c3ed3400aab0 ] ib_uverbs_post_send() uses cmd.wqe_size from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr). Fixes: c3bea3d2dc53 ("RDMA/uverbs: Use the iterator for ib_uverbs_unmarshall_recv()") Signed-off-by: Yi Liu Link: https://patch.msgid.link/20260122142900.2356276-2-liuy22@mails.tsinghua.edu.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 409c2c5508f3d30627bea576f8676de523cb906e Author: Li Zhijian Date: Fri Jan 16 11:27:53 2026 +0800 RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE [ Upstream commit 12985e5915a0b8354796efadaaeb201eed115377 ] The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/ Fixes: 592627ccbdff ("RDMA/rxe: Replace rxe_map and rxe_phys_buf by xarray") Signed-off-by: Li Zhijian Link: https://patch.msgid.link/20260116032753.2574363-1-lizhijian@fujitsu.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 02f720109fed51ab433dfbd4e82d8dc95afaa3ba Author: Cheatham, Benjamin Date: Fri Jan 9 07:57:38 2026 -0600 cxl/core: Fix cxl_dport debugfs EINJ entries [ Upstream commit 4ed7952b9e87cf731ebc8251874416e60eb15230 ] Protocol error injection is only valid for CXL 2.0+ root ports and CXL 1.1 memory-mapped downstream ports as per the ACPI v6.5 spec (Table 8-31). The core code currently creates an 'einj_inject' file in CXL debugfs for all CXL 1.1 downstream ports and all PCI CXL 2.0+ downstream ports. This results in debugfs EINJ files that won't work due to platform/spec restrictions. Fix by limiting 'einj_inject' file creation to only CXL 1.1 dports and CXL 2.0+ root ports. Update the comment above the check to more accurately represent the requirements expected by the EINJ module and ACPI spec. Fixes: 8039804cfa73 ("cxl/core: Add CXL EINJ debugfs files") Signed-off-by: Ben Cheatham Reviewed-by: Jonathan Cameron Reviewed-by: Alison Schofield Reviewed-by: Dave Jiang Link: https://patch.msgid.link/6e9fb657-8264-4028-92e2-5428e2695bf1@amd.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 055cd68b8ebbd42aa425a594ccddd55e4c3d61d5 Author: Mike Snitzer Date: Wed Jan 7 11:08:57 2026 -0500 NFS/localio: remove -EAGAIN handling in nfs_local_doio() [ Upstream commit e72a73957613653f50375db1f3a3fbb907a9c40b ] Handling -EAGAIN in nfs_local_doio() was introduced with commit 0978e5b85fc08 (nfs_do_local_{read,write} were made to have negative checks for correspoding iter method) but commit e43e9a3a3d66 since eliminated the possibility for this -EAGAIN early return. So remove nfs_local_doio()'s -EAGAIN handling that calls nfs_localio_disable_client() -- while it should never happen from nfs_do_local_{read,write} this particular -EAGAIN handling is now "dead" and so it has become a liability. Fixes: e43e9a3a3d66 ("nfs/localio: refactor iocb initialization") Signed-off-by: Mike Snitzer Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 1d6933f32b29710b97592c44563fe7e37434995b Author: Mike Snitzer Date: Wed Jan 7 11:08:56 2026 -0500 NFS/localio: use GFP_NOIO and non-memreclaim workqueue in nfs_local_commit [ Upstream commit 9bb0060f7860aa4561c5b21163dd45ceb66946a9 ] nfslocaliod_workqueue is a non-memreclaim workqueue (it isn't initialized with WQ_MEM_RECLAIM), see commit b9f5dd57f4a5 ("nfs/localio: use dedicated workqueues for filesystem read and write"). Use nfslocaliod_workqueue for LOCALIO's SYNC work. Also, set PF_LOCAL_THROTTLE | PF_MEMALLOC_NOIO in nfs_local_fsync_work. Fixes: b9f5dd57f4a5 ("nfs/localio: use dedicated workqueues for filesystem read and write") Signed-off-by: Mike Snitzer Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit ae26a4cf2baf0a44c538dc093504d1994b02dade Author: Mike Snitzer Date: Wed Jan 7 11:08:55 2026 -0500 NFS/localio: prevent direct reclaim recursion into NFS via nfs_writepages [ Upstream commit 67435d2d8a33a75f9647724952cb1b18279d2e95 ] LOCALIO is an NFS loopback mount optimization that avoids using the network for READ, WRITE and COMMIT if the NFS client and server are determined to be on the same system. But because LOCALIO is still fundamentally "just NFS loopback mount" it is susceptible to recursion deadlock via direct reclaim, e.g.: NFS LOCALIO down to XFS and then back into NFS via nfs_writepages. Fix LOCALIO's potential for direct reclaim deadlock by ensuring that all its page cache allocations are done from GFP_NOFS context. Thanks to Ben Coddington for pointing out commit ad22c7a043c2 ("xfs: prevent stack overflows from page cache allocation"). Reported-by: John Cagle Tested-by: Allen Lu Suggested-by: Benjamin Coddington Fixes: 70ba381e1a43 ("nfs: add LOCALIO support") Signed-off-by: Mike Snitzer Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit c627769730e98c4dbff0d5f5d194f467d79df326 Author: Trond Myklebust Date: Sat Jan 3 12:14:59 2026 -0500 NFS/localio: Handle short writes by retrying [ Upstream commit 615762059d284b863f9163b53679d95b3dcdd495 ] The current code for handling short writes in localio just truncates the I/O and then sets an error. While that is close to how the ordinary NFS code behaves, it does mean there is a chance the data that got written is lost because it isn't persisted. To fix this, change localio so that the upper layers can direct the behaviour to persist any unstable data by rewriting it, and then continuing writing until an ENOSPC is hit. Fixes: 70ba381e1a43 ("nfs: add LOCALIO support") Signed-off-by: Trond Myklebust Reviewed-by: Mike Snitzer Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit ec121ad626c319085f6d40a52cd04e99b4554926 Author: Zilin Guan Date: Thu Jan 22 13:09:50 2026 +0000 mtd: parsers: Fix memory leak in mtd_parser_tplink_safeloader_parse() [ Upstream commit 980ce2b02dd06a4fdf5fee38b2e14becf9cf7b8b ] The function mtd_parser_tplink_safeloader_parse() allocates buf via mtd_parser_tplink_safeloader_read_table(). If the allocation for parts[idx].name fails inside the loop, the code jumps to the err_free label without freeing buf, leading to a memory leak. Fix this by freeing the temporary buffer buf in the err_free label. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 00a3588084be ("mtd: parsers: add TP-Link SafeLoader partitions table parser") Signed-off-by: Zilin Guan Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit eb0e8003d9a036c498f1a84e22d061d5eaf75f6d Author: Mario Limonciello (AMD) Date: Thu Jan 15 22:11:32 2026 -0600 crypto: ccp - Send PSP_CMD_TEE_RING_DESTROY when PSP_CMD_TEE_RING_INIT fails [ Upstream commit 7b85137caf110a09a4a18f00f730de4709f9afc8 ] The hibernate resume sequence involves loading a resume kernel that is just used for loading the hibernate image before shifting back to the existing kernel. During that hibernate resume sequence the resume kernel may have loaded the ccp driver. If this happens the resume kernel will also have called PSP_CMD_TEE_RING_INIT but it will never have called PSP_CMD_TEE_RING_DESTROY. This is problematic because the existing kernel needs to re-initialize the ring. One could argue that the existing kernel should call destroy as part of restore() but there is no guarantee that the resume kernel did or didn't load the ccp driver. There is also no callback opportunity for the resume kernel to destroy before handing back control to the existing kernel. Similar problems could potentially exist with the use of kdump and crash handling. I actually reproduced this issue like this: 1) rmmod ccp 2) hibernate the system 3) resume the system 4) modprobe ccp The resume kernel will have loaded ccp but never destroyed and then when I try to modprobe it fails. Because of these possible cases add a flow that checks the error code from the PSP_CMD_TEE_RING_INIT call and tries to call PSP_CMD_TEE_RING_DESTROY if it failed. If this succeeds then call PSP_CMD_TEE_RING_INIT again. Fixes: f892a21f51162 ("crypto: ccp - use generic power management") Reported-by: Lars Francke Closes: https://lore.kernel.org/platform-driver-x86/CAD-Ua_gfJnQSo8ucS_7ZwzuhoBRJ14zXP7s8b-zX3ZcxcyWePw@mail.gmail.com/ Tested-by: Yijun Shen Signed-off-by: Mario Limonciello (AMD) Reviewed-by: Shyam Sundar S K Acked-by: Tom Lendacky Link: https://patch.msgid.link/20260116041132.153674-6-superm1@kernel.org Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit eb5263f3f8e483caa8956404607eec1c514cadef Author: Mario Limonciello (AMD) Date: Thu Jan 15 22:11:31 2026 -0600 crypto: ccp - Factor out ring destroy handling to a helper [ Upstream commit d95f87a65bce5f2f2a02ca6094ca4841d4073df3 ] The ring destroy command needs to be used in multiple places. Split out the code to a helper. Tested-by: Yijun Shen Signed-off-by: Mario Limonciello (AMD) Acked-by: Tom Lendacky Reviewed-by: Shyam Sundar S K Link: https://patch.msgid.link/20260116041132.153674-5-superm1@kernel.org Signed-off-by: Ilpo Järvinen Stable-dep-of: 7b85137caf11 ("crypto: ccp - Send PSP_CMD_TEE_RING_DESTROY when PSP_CMD_TEE_RING_INIT fails") Signed-off-by: Sasha Levin commit 10eef0f932387b8595eff9c32e2d5b6f83856f38 Author: Mario Limonciello (AMD) Date: Thu Jan 15 22:11:30 2026 -0600 crypto: ccp - Add an S4 restore flow [ Upstream commit 0ba2035026d0ab6c7c7e65ad8b418dc73d5700d9 ] The system will have lost power during S4. The ring used for TEE communications needs to be initialized before use. Fixes: f892a21f51162 ("crypto: ccp - use generic power management") Reported-by: Lars Francke Closes: https://lore.kernel.org/platform-driver-x86/CAD-Ua_gfJnQSo8ucS_7ZwzuhoBRJ14zXP7s8b-zX3ZcxcyWePw@mail.gmail.com/ Tested-by: Yijun Shen Signed-off-by: Mario Limonciello (AMD) Reviewed-by: Shyam Sundar S K Reviewed-by: Tom Lendacky Link: https://patch.msgid.link/20260116041132.153674-4-superm1@kernel.org Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit b3010ff068fadea7816615cd71f95ded4d86d463 Author: Mario Limonciello (AMD) Date: Thu Jan 15 22:11:29 2026 -0600 crypto: ccp - Declare PSP dead if PSP_CMD_TEE_RING_INIT fails [ Upstream commit 5e599d7871bf852e94e8aa08b99724635f2cbf96 ] tee_init_ring() only declares PSP dead if the command times out. If there is any other failure it is still considered fatal though. Set psp_dead for other failures as well. Fixes: 949a0c8dd3c2 ("crypto: ccp - Move direct access to some PSP registers out of TEE") Tested-by: Yijun Shen Signed-off-by: Mario Limonciello (AMD) Acked-by: Tom Lendacky Reviewed-by: Shyam Sundar S K Link: https://patch.msgid.link/20260116041132.153674-3-superm1@kernel.org Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 7c28e2789697797d5cc6cd25a30d164b539b5e2f Author: Shyam Sundar S K Date: Thu Jan 15 22:11:28 2026 -0600 platform/x86/amd/pmf: Prevent TEE errors after hibernate [ Upstream commit 48d229c7047128dd52eaf863881bb3e62b5896e5 ] After resuming from hibernate, TEE commands can time out and cause PSP disables. Fix this by reinitializing the Trusted Application (TA) and cancelling the pb workqueue in the hibernate callbacks to avoid these errors. ccp 0000:c4:00.2: tee: command 0x5 timed out, disabling PSP amd-pmf AMDI0107:00: TEE enact cmd failed. err: ffff000e, ret:0 amd-pmf AMDI0107:00: TEE enact cmd failed. err: ffff000e, ret:0 amd-pmf AMDI0107:00: TEE enact cmd failed. err: ffff000e, ret:0 Fixes: ae82cef7d9c5 ("platform/x86/amd/pmf: Add support for PMF-TA interaction") Reported-by: Lars Francke Closes: https://lore.kernel.org/platform-driver-x86/CAD-Ua_gfJnQSo8ucS_7ZwzuhoBRJ14zXP7s8b-zX3ZcxcyWePw@mail.gmail.com/ Tested-by: Yijun Shen Co-developed-by: Patil Rajesh Reddy Signed-off-by: Patil Rajesh Reddy Signed-off-by: Shyam Sundar S K [ML: Add more tags] Signed-off-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260116041132.153674-2-superm1@kernel.org Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 8269e0ee89bd8ae61c3195ad912746edc0dc18cc Author: Anthony Pighin (Nokia) Date: Fri Jan 16 15:31:26 2026 +0000 vfio/pci: Lock upstream bridge for vfio_pci_core_disable() [ Upstream commit 962ae6892d8bd208b2d1e2b358f07551ddc8d32f ] The commit 7e89efc6e9e4 ("Lock upstream bridge for pci_reset_function()") added locking of the upstream bridge to the reset function. To catch paths that are not properly locked, the commit 920f6468924f ("Warn on missing cfg_access_lock during secondary bus reset") added a warning if the PCI configuration space was not locked during a secondary bus reset request. When a VFIO PCI device is released from userspace ownership, an attempt to reset the PCI device function may be made. If so, and the upstream bridge is not locked, the release request results in a warning: pcieport 0000:00:00.0: unlocked secondary bus reset via: pci_reset_bus_function+0x188/0x1b8 Add missing upstream bridge locking to vfio_pci_core_disable(). Fixes: 7e89efc6e9e4 ("PCI: Lock upstream bridge for pci_reset_function()") Signed-off-by: Anthony Pighin Link: https://lore.kernel.org/r/BN0PR08MB695171D3AB759C65B6438B5D838DA@BN0PR08MB6951.namprd08.prod.outlook.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 721bd22bcf45a63ebd9bd0f478ef721b45cc5383 Author: Alexander Usyskin Date: Thu Jan 15 07:22:37 2026 +0200 mtd: intel-dg: Fix accessing regions before setting nregions [ Upstream commit 779c59274d03cc5c07237a2c845dfb71cff77705 ] The regions array is counted by nregions, but it's set only after accessing it: [] UBSAN: array-index-out-of-bounds in drivers/mtd/devices/mtd_intel_dg.c:750:15 [] index 0 is out of range for type ' [*]' Fix it by also fixing an undesired behavior: the loop silently ignores ENOMEM and continues setting the other entries. CC: Gustavo A. R. Silva CC: Raag Jadav Reported-by: Jani Partanen Closes: https://lore.kernel.org/all/caca6c67-4f1d-49f1-948f-e63b6b937b29@sotapeli.fi Fixes: ceb5ab3cb646 ("mtd: add driver for intel graphics non-volatile memory device") Signed-off-by: Lucas De Marchi Signed-off-by: Alexander Usyskin Reviewed-by: Raag Jadav Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 4d02e3870c88fa8a4fd10d5be2d1d3e765e65419 Author: Alok Tiwari Date: Fri Dec 19 03:09:30 2025 -0800 mtd: rawnand: cadence: Fix return type of CDMA send-and-wait helper [ Upstream commit 6d8226cbbf124bb5613b532216b74c886a4361b7 ] cadence_nand_cdma_send_and_wait() propagates negative errno values from cadence_nand_cdma_send(), returns -ETIMEDOUT on failure and -EIO when the CDMA engine reports a command failure. However, it is declared as u32, causing error codes to wrap. Change the return type to int to correctly propagate errors. Fixes: ec4ba01e894d ("mtd: rawnand: Add new Cadence NAND driver to MTD subsystem") Signed-off-by: Alok Tiwari Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 9b0927c9b91b4aaa759596416232e1b48c3b7a98 Author: Or Har-Toov Date: Thu Jan 15 14:26:45 2026 +0200 IB/mlx5: Fix port speed query for representors [ Upstream commit 18ea78e2ae83d1d86a72d21d9511927e57e2c0e1 ] When querying speed information for a representor in switchdev mode, the code previously used the first device in the eswitch, which may not match the device that actually owns the representor. In setups such as multi-port eswitch or LAG, this led to incorrect port attributes being reported. Fix this by retrieving the correct core device from the representor's eswitch before querying its port attributes. Fixes: 27f9e0ccb6da ("net/mlx5: Lag, Add single RDMA device in multiport mode") Signed-off-by: Or Har-Toov Reviewed-by: Mark Bloch Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260115-port-speed-query-fix-v2-1-3bde6a3c78e7@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6d838873da9cb97551d42316967cc82bf8f8031b Author: Chiara Meiohas Date: Tue Jan 13 15:37:10 2026 +0200 RDMA/mlx5: Fix UMR hang in LAG error state unload [ Upstream commit ebc2164a4cd4314503f1a0c8e7aaf76d7e5fa211 ] During firmware reset in LAG mode, a race condition causes the driver to hang indefinitely while waiting for UMR completion during device unload. See [1]. In LAG mode the bond device is only registered on the master, so it never sees sys_error events from the slave. During firmware reset this causes UMR waits to hang forever on unload as the slave is dead but the master hasn't entered error state yet, so UMR posts succeed but completions never arrive. Fix this by adding a sys_error notifier that gets registered before MLX5_IB_STAGE_IB_REG and stays alive until after ib_unregister_device(). This ensures error events reach the bond device throughout teardown. [1] Call Trace: __schedule+0x2bd/0x760 schedule+0x37/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.isra.6+0x2b5/0x4a0 __mlx5_ib_dereg_mr+0x606/0x870 [mlx5_ib] ? __xa_erase+0x4a/0xa0 ? _cond_resched+0x15/0x30 ? wait_for_completion+0x31/0x100 ib_dereg_mr_user+0x48/0xc0 [ib_core] ? rdmacg_uncharge_hierarchy+0xa0/0x100 destroy_hw_idr_uobject+0x20/0x50 [ib_uverbs] uverbs_destroy_uobject+0x37/0x150 [ib_uverbs] __uverbs_cleanup_ufile+0xda/0x140 [ib_uverbs] uverbs_destroy_ufile_hw+0x3a/0xf0 [ib_uverbs] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs] remove_client_context+0x8b/0xd0 [ib_core] disable_device+0x8c/0x130 [ib_core] __ib_unregister_device+0x10d/0x180 [ib_core] ib_unregister_device+0x21/0x30 [ib_core] __mlx5_ib_remove+0x1e4/0x1f0 [mlx5_ib] auxiliary_bus_remove+0x1e/0x30 device_release_driver_internal+0x103/0x1f0 bus_remove_device+0xf7/0x170 device_del+0x181/0x410 mlx5_rescan_drivers_locked.part.10+0xa9/0x1d0 [mlx5_core] mlx5_disable_lag+0x253/0x260 [mlx5_core] mlx5_lag_disable_change+0x89/0xc0 [mlx5_core] mlx5_eswitch_disable+0x67/0xa0 [mlx5_core] mlx5_unload+0x15/0xd0 [mlx5_core] mlx5_unload_one+0x71/0xc0 [mlx5_core] mlx5_sync_reset_reload_work+0x83/0x100 [mlx5_core] process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x22/0x40 Fixes: ede132a5cf55 ("RDMA/mlx5: Move events notifier registration to be after device registration") Signed-off-by: Chiara Meiohas Signed-off-by: Maher Sanalla Reviewed-by: Mark Bloch Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260113-umr-hand-lag-fix-v1-1-3dc476e00cd9@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 71b23ada25b337135fd36089bca44748095428b9 Author: Malaya Kumar Rout Date: Thu Jan 15 15:33:33 2026 +0530 tools/power/x86/intel-speed-select: Fix file descriptor leak in isolate_cpus() [ Upstream commit 56c17ee151c6e1a73d77e15b82a8e2130cd8dd16 ] The file descriptor opened in isolate_cpus() when (!level) is true was not being closed before returning, causing a file descriptor leak in both the error path and the success path. When write() fails at line 950, the function returns at line 953 without closing the file descriptor. Similarly, on success, the function returns at line 956 without closing the file descriptor. Add close(fd) calls before both return statements to fix the resource leak. This follows the same pattern used elsewhere in the same function where file descriptors are properly closed before returning (see lines 1005 and 1027). Fixes: 997074df658e ("tools/power/x86/intel-speed-select: Use cgroup v2 isolation") Signed-off-by: Malaya Kumar Rout Signed-off-by: Srinivas Pandruvada Signed-off-by: Sasha Levin commit d9aefb386fdc430a23a7d94d4f2fe2d52ffe75eb Author: Krishna Chomal Date: Tue Jan 13 23:56:03 2026 +0530 platform/x86: hp-wmi: fix platform profile values for Omen 16-wf1xxx [ Upstream commit 8ca7515d3c76a8b629f703ff8301a75f503bcc50 ] HP Omen 16-wf1xxx (board ID 8C78) currently sends the incorrect Victus-specific thermal profile values via WMI, leading to a logical inconsistency when switching between platform profiles. The driver currently uses Victus S values: 0x00 => Balanced / Low-Power 0x01 => Performance However, Omen Gaming Hub logs / EC register inspection on Windows shows that this board is intended to use: 0x30 => Balanced / Low-Power 0x31 => Performance This patch corrects the thermal profile command values to match the values observed from Omen Gaming Hub logs. The performance benchmarks and peak power draw (from both CPU and GPU) show no observable change with this correction (suggesting that the firmware is currently tolerant of the incorrect values). However sending the correct values prevents potential regressions after future firmware updates. Refactor victus_s_thermal_profile_boards from a list of strings to a dmi_system_id table and move the lookup to module init. The new struct thermal_profile_params is used to store board-specific WMI parameters, allowing the driver to cache these values in a static pointer. This avoids repeated DMI string comparisons and allows marking of DMI table as __initconst. Testing on HP Omen 16-wf1xxx (board 8C78) confirmed WMI codes 0x30/0x31 are now sent, resolving the logical inconsistency and ensuring the value visible in EC registers match the Windows state for this profile. Fixes: fb146a38cb11 ("platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support") Signed-off-by: Krishna Chomal Link: https://patch.msgid.link/20260113182604.115211-2-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit eb715133e0ae12514bba4d2d5ce1dee774476056 Author: Jacob Moroni Date: Mon Jan 12 02:00:06 2026 +0000 RDMA/iwcm: Fix workqueue list corruption by removing work_list [ Upstream commit 7874eeacfa42177565c01d5198726671acf7adf2 ] The commit e1168f0 ("RDMA/iwcm: Simplify cm_event_handler()") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] Fixes: e1168f09b331 ("RDMA/iwcm: Simplify cm_event_handler()") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260112020006.1352438-1-jmoroni@google.com Reviewed-by: Bart Van Assche Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 5c07aef09a121a4cd622a71eb0753a9e135c84a8 Author: Jiasheng Jiang Date: Mon Jan 12 01:54:12 2026 +0000 RDMA/rxe: Fix double free in rxe_srq_from_init [ Upstream commit 0beefd0e15d962f497aad750b2d5e9c3570b66d1 ] In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user. Fixes: aae0484e15f0 ("IB/rxe: avoid srq memory leak") Signed-off-by: Jiasheng Jiang Link: https://patch.msgid.link/20260112015412.29458-1-jiashengjiangcool@gmail.com Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 33e396029002bc4f2d888e07555edb807c1fadfd Author: Roman Penyaev Date: Wed Jan 7 17:15:08 2026 +0100 RDMA/rtrs-srv: fix SG mapping [ Upstream commit 83835f7c07b523c7ca2a5ad0a511670b5810539e ] This fixes the following error on the server side: RTRS server session allocation failed: -EINVAL caused by the caller of the `ib_dma_map_sg()`, which does not expect less mapped entries, than requested, which is in the order of things and can be easily reproduced on the machine with enabled IOMMU. The fix is to treat any positive number of mapped sg entries as a successful mapping and cache DMA addresses by traversing modified SG table. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Signed-off-by: Roman Penyaev Signed-off-by: Jack Wang Signed-off-by: Grzegorz Prajsner Link: https://patch.msgid.link/20260107161517.56357-2-haris.iqbal@ionos.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit c0def811ad8d642dca9b6d31a198cc39f5f90837 Author: Waqar Hameed Date: Sat Dec 20 23:46:24 2025 +0100 power: supply: wm97xx: Fix NULL pointer dereference in power_supply_changed() [ Upstream commit 39fe0eac6d755ef215026518985fcf8de9360e9e ] In `probe()`, `request_irq()` is called before allocating/registering a `power_supply` handle. If an interrupt is fired between the call to `request_irq()` and `power_supply_register()`, the `power_supply` handle will be used uninitialized in `power_supply_changed()` in `wm97xx_bat_update()` (triggered from the interrupt handler). This will lead to a `NULL` pointer dereference since Fix this racy `NULL` pointer dereference by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Since the IRQ is the last thing requests in the `probe()` now, remove the error path for freeing it. Instead add one for unregistering the `power_supply` handle when IRQ request fails. Fixes: 7c87942aef52 ("wm97xx_battery: Use irq to detect charger state") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/97b55f0479a932eea7213844bf66f28a974e27a2.1766270196.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 64327c46f25513cfe63feb1b1e171ca73faded36 Author: Haotian Zhang Date: Thu Dec 4 16:34:36 2025 +0800 power: supply: bq27xxx: fix wrong errno when bus ops are unsupported [ Upstream commit 688364a11647dc09ba1e4429313e0008066ec790 ] bq27xxx_write(), bq27xxx_read_block(), and bq27xxx_write_block() return -EPERM when the bus callback pointer is NULL. A NULL callback indicates the operation is not supported by the bus/driver, not that permission is denied. Return -EOPNOTSUPP instead of -EPERM when di->bus.write/ read_bulk/write_bulk is NULL. Fixes: 14073f6614f6 ("power: supply: bq27xxx: Add bulk transfer bus methods") Signed-off-by: Haotian Zhang Reviewed-by: Matt Ranostay Link: https://patch.msgid.link/20251204083436.1367-1-vulab@iscas.ac.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit a465a149922283d095253155102d3e17037b5c4d Author: Alexander Koskovich Date: Sun Dec 14 19:16:18 2025 +0000 power: reset: nvmem-reboot-mode: respect cell size for nvmem_cell_write [ Upstream commit 36b05629226413836cfbb3fbe6689cd188bca156 ] Some platforms expose reboot mode cells that are smaller than an unsigned int, in which cases lead to write failures. Read the cell first to determine actual size and only write the number of bytes the cell can hold. Fixes: 7a78a7f7695b ("power: reset: nvmem-reboot-mode: use NVMEM as reboot mode write interface") Signed-off-by: Alexander Koskovich Link: https://patch.msgid.link/20251214191529.2470580-1-akoskovich@pm.me Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 861dda7a9074c0ff67788928165ae39d7f647491 Author: Waqar Hameed Date: Sat Dec 20 23:36:02 2025 +0100 power: supply: sbs-battery: Fix use-after-free in power_supply_changed() [ Upstream commit 8d59cf3887fbabacef53bfba473e33e8a8d9d07b ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Keep the old behavior of just printing a warning in case of any failures during the IRQ request and finishing the probe successfully. Fixes: d2cec82c2880 ("power: sbs-battery: Request threaded irq and fix dev callback cookie") Signed-off-by: Waqar Hameed Reviewed-by: Phil Reid Link: https://patch.msgid.link/0ef896e002495e615157b482d18a437af19ddcd0.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 64e15155095f39f4dec9b4659da1238ef8fc54d4 Author: Waqar Hameed Date: Sat Dec 20 23:36:02 2025 +0100 power: supply: rt9455: Fix use-after-free in power_supply_changed() [ Upstream commit e2febe375e5ea5afed92f4cd9711bde8f24ee6d2 ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: e86d69dd786e ("power_supply: Add support for Richtek RT9455 battery charger") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/1567d831e04c3e2fcb9e18dd36b7bcba4634581a.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 08e674e9862a2db46fb234eb7c5442455ece0131 Author: Waqar Hameed Date: Sat Dec 20 23:36:01 2025 +0100 power: supply: pm8916_lbc: Fix use-after-free in power_supply_changed() [ Upstream commit b7508129978ae1e2ed9b0410396abc05def9c4eb ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: f8d7a3d21160 ("power: supply: Add driver for pm8916 lbc") Signed-off-by: Waqar Hameed Reviewed-by: Nikita Travkin Link: https://patch.msgid.link/64d8dd3675a4e59fa32c3e0ef451f12d1f7ed18f.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit a8b7117ae3a791c6a328674d05a06cd45d8241bd Author: Waqar Hameed Date: Sat Dec 20 23:36:01 2025 +0100 power: supply: pm8916_bms_vm: Fix use-after-free in power_supply_changed() [ Upstream commit 62914959b35e9a1e29cc0f64cb8cfc5075a5366f ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 098bce1838e0 ("power: supply: Add pm8916 VM-BMS support") Signed-off-by: Waqar Hameed Reviewed-by: Nikita Travkin Link: https://patch.msgid.link/2749c09ff81fcac87ae48147e216135450d8c067.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 8c89aade8335e26a6a7dcda18992d15f51943927 Author: Waqar Hameed Date: Sat Dec 20 23:36:00 2025 +0100 power: supply: goldfish: Fix use-after-free in power_supply_changed() [ Upstream commit b2ce982e2e0c888dc55c888ad0e20ea04daf2e6b ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 84d7b7687489 ("power: Add battery driver for goldfish emulator") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/500a606bb6fb6f2bb8d797e19a00cea9dd7b03c1.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 2841bbb5a35c4449c0a0458e8e476b2a62f95147 Author: Waqar Hameed Date: Sat Dec 20 23:36:00 2025 +0100 power: supply: cpcap-battery: Fix use-after-free in power_supply_changed() [ Upstream commit 642f33e34b969eedec334738fd5df95d2dc42742 ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 874b2adbed12 ("power: supply: cpcap-battery: Add a battery driver") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/81db58d610c9a51a68184f856cd431a934cccee2.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 03d1e4ee4e6aa6d2966e883e4ca0e5be73bf1b7c Author: Waqar Hameed Date: Sat Dec 20 23:35:59 2025 +0100 power: supply: bq25980: Fix use-after-free in power_supply_changed() [ Upstream commit 5f0b1cb41906e86b64bf69f5ededb83b0d757c27 ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 5069185fc18e ("power: supply: bq25980: Add support for the BQ259xx family") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/8763035cadb959e14787b3837f2d3db61f6e1c34.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 4b6fb0b6124f558131e502e3ffd03e6583b3ace6 Author: Waqar Hameed Date: Sat Dec 20 23:35:59 2025 +0100 power: supply: bq256xx: Fix use-after-free in power_supply_changed() [ Upstream commit 8005843369723d9c8975b7c4202d1b85d6125302 ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 32e4978bb920 ("power: supply: bq256xx: Introduce the BQ256XX charger driver") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/39da6da8cc060fa0382ca859f65071e791cb6119.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit f27eb76def5c07e4d7cc468b40741f19dafc83ce Author: Waqar Hameed Date: Sat Dec 20 23:35:59 2025 +0100 power: supply: act8945a: Fix use-after-free in power_supply_changed() [ Upstream commit 3291c51d4684d048dd2eb91b5b65fcfdaf72141f ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: a09209acd6a8 ("power: supply: act8945a_charger: Add status change update support") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/bcf3a23b5187df0bba54a8c8fe09f8b8a0031dee.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 709db4b476e254579d9c48ec34d397a41ca0c407 Author: Waqar Hameed Date: Sat Dec 20 23:35:58 2025 +0100 power: supply: ab8500: Fix use-after-free in power_supply_changed() [ Upstream commit c4af8a98bb52825a5331ae1d0604c0ea6956ba4b ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Commit 1c1f13a006ed ("power: supply: ab8500: Move to componentized binding") introduced this issue during a refactorization. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 1c1f13a006ed ("power: supply: ab8500: Move to componentized binding") Signed-off-by: Waqar Hameed Reviewed-by: Linus Walleij Link: https://patch.msgid.link/ccf83a09942cb8dda3dff70b2682f2c2e9cb97f2.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 9b82bdb9e7c93e05dacb2d33a19a006d9b9f74c6 Author: Dan Williams Date: Mon Dec 15 16:56:11 2025 -0800 cxl/mem: Fix devm_cxl_memdev_edac_release() confusion [ Upstream commit 10016118b6fade907143a32a7aeaa777063dc79c ] A device release method is only for undoing allocations on the path to preparing the device for device_add(). In contrast, devm allocations are post device_add(), are acquired during / after ->probe() and are released synchronous with ->remove(). So, a "devm" helper in a "release" method is a clear anti-pattern. Move this devm release action where it belongs, an action created at edac object creation time. Otherwise, this leaks resources until cxl_memdev_release() time which may be long after these xarray and error record caches have gone idle. Note, this also fixes up the type of @cxlmd->err_rec_array which needlessly dropped type-safety. Fixes: 0b5ccb0de1e2 ("cxl/edac: Support for finding memory operation attributes from the current boot") Cc: Dave Jiang Cc: Jonathan Cameron Cc: Shiju Jose Cc: Alison Schofield Reviewed-by: Alison Schofield Reviewed-by: Ben Cheatham Reviewed-by: Dave Jiang Reviewed-by: Jonathan Cameron Tested-by: Shiju Jose Reviewed-by: Shiju Jose Tested-by: Alejandro Lucero Link: https://patch.msgid.link/20251216005616.3090129-2-dan.j.williams@intel.com Signed-off-by: Dan Williams Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 51c89a5247bf5a48505693c8d6cc6f5da357252b Author: Maher Sanalla Date: Sun Jan 4 15:51:35 2026 +0200 RDMA/mlx5: Fix ucaps init error flow [ Upstream commit 6dc78c53de99e4ed9868d4f0fc6da6e46f52fe4d ] In mlx5_ib_stage_caps_init(), if mlx5_ib_init_ucaps() fails after mlx5_ib_init_var_table() succeeds, the VAR bitmap is leaked since the function returns without cleanup. Thus, cleanup the var table bitmap in case of error of initializing ucaps before exiting, preventing the leak above. Fixes: cf7174e8982f ("RDMA/mlx5: Create UCAP char devices for supported device capabilities") Signed-off-by: Maher Sanalla Reviewed-by: Yishai Hadas Link: https://patch.msgid.link/20260104-ib-core-misc-v1-3-00367f77f3a8@nvidia.com Reviewed-by: Kalesh AP Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8bf968d68ea6c43c78db708f92fa76ba4a15cadd Author: Chengchang Tang Date: Sun Jan 4 14:40:57 2026 +0800 RDMA/hns: Notify ULP of remaining soft-WCs during reset [ Upstream commit 0789f929900d85b80b343c5f04f8b9444e991384 ] During a reset, software-generated WCs cannot be reported via interrupts. This may cause the ULP to miss some WCs. To avoid this, add check in the CQ arm process: if a hardware reset has occurred and there are still unreported soft-WCs, notify the ULP to handle the remaining WCs, thereby preventing any loss of completions. Fixes: 626903e9355b ("RDMA/hns: Add support for reporting wc as software mode") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20260104064057.1582216-5-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 4994b9be17ff742113973f7966080f98c251e1a5 Author: Junxian Huang Date: Sun Jan 4 14:40:56 2026 +0800 RDMA/hns: Fix RoCEv1 failure due to DSCP [ Upstream commit 84bd5d60f0a2b9c763c5e6d0b3d8f4f61f6c5470 ] DSCP is not supported in RoCEv1, but get_dscp() is still called. If get_dscp() returns an error, it'll eventually cause create_ah to fail even when using RoCEv1. Correct the return value and avoid calling get_dscp() when using RoCEv1. Fixes: ee20cc17e9d8 ("RDMA/hns: Support DSCP") Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20260104064057.1582216-4-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 0cbec8b49270f3f0600b8e3ef5e8f0d233dcea27 Author: Chengchang Tang Date: Sun Jan 4 14:40:54 2026 +0800 RDMA/hns: Fix WQ_MEM_RECLAIM warning [ Upstream commit c0a26bbd3f99b7b03f072e3409aff4e6ec8af6f6 ] When sunrpc is used, if a reset triggered, our wq may lead the following trace: workqueue: WQ_MEM_RECLAIM xprtiod:xprt_rdma_connect_worker [rpcrdma] is flushing !WQ_MEM_RECLAIM hns_roce_irq_workq:flush_work_handle [hns_roce_hw_v2] WARNING: CPU: 0 PID: 8250 at kernel/workqueue.c:2644 check_flush_dependency+0xe0/0x144 Call trace: check_flush_dependency+0xe0/0x144 start_flush_work.constprop.0+0x1d0/0x2f0 __flush_work.isra.0+0x40/0xb0 flush_work+0x14/0x30 hns_roce_v2_destroy_qp+0xac/0x1e0 [hns_roce_hw_v2] ib_destroy_qp_user+0x9c/0x2b4 rdma_destroy_qp+0x34/0xb0 rpcrdma_ep_destroy+0x28/0xcc [rpcrdma] rpcrdma_ep_put+0x74/0xb4 [rpcrdma] rpcrdma_xprt_disconnect+0x1d8/0x260 [rpcrdma] xprt_rdma_connect_worker+0xc0/0x120 [rpcrdma] process_one_work+0x1cc/0x4d0 worker_thread+0x154/0x414 kthread+0x104/0x144 ret_from_fork+0x10/0x18 Since QP destruction frees memory, this wq should have the WQ_MEM_RECLAIM. Fixes: ffd541d45726 ("RDMA/hns: Add the workqueue framework for flush cqe handler") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20260104064057.1582216-2-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 38e2c5ad6f1170941e2cb19eddece4462ffb9e97 Author: Etienne AUJAMES Date: Wed Dec 31 14:07:45 2025 +0100 IB/cache: update gid cache on client reregister event [ Upstream commit ddd6c8c873e912cb1ead79def54de5e24ff71c80 ] Some HCAs (e.g: ConnectX4) do not trigger a IB_EVENT_GID_CHANGE on subnet prefix update from SM (PortInfo). Since the commit d58c23c92548 ("IB/core: Only update PKEY and GID caches on respective events"), the GID cache is updated exclusively on IB_EVENT_GID_CHANGE. If this event is not emitted, the subnet prefix in the IPoIB interface’s hardware address remains set to its default value (0xfe80000000000000). Then rdma_bind_addr() failed because it relies on hardware address to find the port GID (subnet_prefix + port GUID). This patch fixes this issue by updating the GID cache on IB_EVENT_CLIENT_REREGISTER event (emitted on PortInfo::ClientReregister=1). Fixes: d58c23c92548 ("IB/core: Only update PKEY and GID caches on respective events") Signed-off-by: Etienne AUJAMES Link: https://patch.msgid.link/aVUfsO58QIDn5bGX@eaujamesFR0130 Reviewed-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d273d9cedd78db56905b852a06e746bb5ff1dc55 Author: Honggang LI Date: Wed Dec 24 10:38:19 2025 +0800 RDMA/rtrs: server: remove dead code [ Upstream commit a3572bdc3a028ca47f77d7166ac95b719cf77d50 ] As rkey had been initialized to zero, the WARN_ON_ONCE should never been triggered. Remove it. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Signed-off-by: Honggang LI Link: https://patch.msgid.link/20251224023819.138846-1-honggangli@163.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 365996a2b14d07caa9e33d367b67ea26c09d89b4 Author: Kuniyuki Iwashima Date: Sat Feb 7 23:22:34 2026 +0000 af_unix: Fix memleak of newsk in unix_stream_connect(). [ Upstream commit 6884028cd7f275f8bcb854a347265cb1fb0e4bea ] When prepare_peercred() fails in unix_stream_connect(), unix_release_sock() is not called for newsk, and the memory is leaked. Let's move prepare_peercred() before unix_create1(). Fixes: fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid") Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260207232236.2557549-1-kuniyu@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 08b10c468962cd46091c5ac825473ab7c9de5b3c Author: Hariprasad Kelam Date: Fri Feb 6 23:56:45 2026 +0530 octeontx2-pf: Unregister devlink on probe failure [ Upstream commit 943f3b8bfbf297cf74392b50a7108ce1fe4cbd8c ] When probe fails after devlink registration, the missing devlink unregister call causing a memory leak. Fixes: 2da489432747 ("octeontx2-pf: devlink params support to set mcam entry count") Signed-off-by: Hariprasad Kelam Link: https://patch.msgid.link/20260206182645.4032737-1-hkelam@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8abc12ce2573efcefaf3ee39b195ccc4a5265b45 Author: Michael Dege Date: Fri Feb 6 14:41:53 2026 +0100 net: renesas: rswitch: fix forwarding offload statemachine [ Upstream commit e9a5073a98d940837cbb95e71eed1f28f48e7b30 ] A change of the port state of one port, caused the state of another port to change. This behvior was unintended. Fixes: b7502b1043de ("net: renesas: rswitch: add offloading for L2 switching") Signed-off-by: Michael Dege Link: https://patch.msgid.link/20260206-fix-offloading-statemachine-v3-1-07bfba07d03e@renesas.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1d4f8092bd7851a12a769422113db532f70da1ab Author: Eric Joyner Date: Fri Feb 6 14:46:51 2026 -0800 ionic: Rate limit unknown xcvr type messages [ Upstream commit cdb1634de3bf197c0d86487d1fb84c128a79cc7c ] Running ethtool repeatedly with a transceiver unknown to the driver or firmware will cause the driver to spam the kernel logs with "unknown xcvr type" messages which can distract from real issues; and this isn't interesting information outside of debugging. Fix this by rate limiting the output so that there are still notifications but not so many that they flood the log. Using dev_dbg_once() would reduce the number of messages further, but this would miss the case where a different unknown transceiver type is plugged in, and its status is requested. Fixes: 4d03e00a2140 ("ionic: Add initial ethtool support") Signed-off-by: Eric Joyner Reviewed-by: Brett Creeley Link: https://patch.msgid.link/20260206224651.1491-1-eric.joyner@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a16bea45d758e97002e8ccd3395458e846e18bd1 Author: Vimlesh Kumar Date: Fri Feb 6 11:15:08 2026 +0000 octeon_ep_vf: ensure dbell BADDR updation [ Upstream commit 484e834d53cffa91c311631271f83130cf6e9e7c ] Make sure the OUT DBELL base address reflects the latest values written to it. Fix: Add a wait until the OUT DBELL base address register is updated with the DMA ring descriptor address, and modify the setup_oq function to properly handle failures. Fixes: 2c0c32c72be29 ("octeon_ep_vf: add hardware configuration APIs") Signed-off-by: Sathesh Edara Signed-off-by: Shinas Rasheed Signed-off-by: Vimlesh Kumar Link: https://patch.msgid.link/20260206111510.1045092-4-vimleshk@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 13a61502c1c83b11d1355de9bf39626d7fe74201 Author: Vimlesh Kumar Date: Fri Feb 6 11:15:07 2026 +0000 octeon_ep: ensure dbell BADDR updation [ Upstream commit ce8fe3fc4f99efd872120301c0f72f2e90ab9769 ] Make sure the OUT DBELL base address reflects the latest values written to it. Fix: Add a wait until the OUT DBELL base address register is updated with the DMA ring descriptor address, and modify the setup_oq function to properly handle failures. Fixes: 0807dc76f3bf5 ("octeon_ep: support Octeon CN10K devices") Signed-off-by: Sathesh Edara Signed-off-by: Shinas Rasheed Signed-off-by: Vimlesh Kumar Link: https://patch.msgid.link/20260206111510.1045092-3-vimleshk@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1b8e3c8b74436bdb7503ec9a76ab16574433a031 Author: Vimlesh Kumar Date: Fri Feb 6 11:15:06 2026 +0000 octeon_ep: disable per ring interrupts [ Upstream commit 73e6ffa37cebee152c07c5f2b8bc70fd2899ea6e ] Disable the MSI-X per ring interrupt for every PF ring when PF netdev goes down. Fixes: 1f2c2d0cee023 ("octeon_ep: add hardware configuration APIs") Signed-off-by: Sathesh Edara Signed-off-by: Shinas Rasheed Signed-off-by: Vimlesh Kumar Link: https://patch.msgid.link/20260206111510.1045092-2-vimleshk@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c8c197aaa56b25a2d54f3aa07e27e228d6c08546 Author: Jiayuan Chen Date: Fri Feb 6 15:44:44 2026 +0800 serial: caif: fix use-after-free in caif_serial ldisc_close() [ Upstream commit 308e7e4d0a846359685f40aade023aee7b27284c ] There is a use-after-free bug in caif_serial where handle_tx() may access ser->tty after the tty has been freed. The race condition occurs between ldisc_close() and packet transmission: CPU 0 (close) CPU 1 (xmit) ------------- ------------ ldisc_close() tty_kref_put(ser->tty) [tty may be freed here] <-- race window --> caif_xmit() handle_tx() tty = ser->tty // dangling ptr tty->ops->write() // UAF! schedule_work() ser_release() unregister_netdevice() The root cause is that tty_kref_put() is called in ldisc_close() while the network device is still active and can receive packets. Since ser and tty have a 1:1 binding relationship with consistent lifecycles (ser is allocated in ldisc_open and freed in ser_release via unregister_netdevice, and each ser binds exactly one tty), we can safely defer the tty reference release to ser_release() where the network device is unregistered. Fix this by moving tty_kref_put() from ldisc_close() to ser_release(), after unregister_netdevice(). This ensures the tty reference is held as long as the network device exists, preventing the UAF. Note: We save ser->tty before unregister_netdevice() because ser is embedded in netdev's private data and will be freed along with netdev (needs_free_netdev = true). How to reproduce: Add mdelay(500) at the beginning of ldisc_close() to widen the race window, then run the reproducer program [1]. Note: There is a separate deadloop issue in handle_tx() when using PORT_UNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper serial backend). This deadloop exists even without this patch, and is likely caused by inconsistency between uart_write_room() and uart_write() in serial core. It has been addressed in a separate patch [2]. KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in handle_tx+0x5d1/0x620 Read of size 1 at addr ffff8881131e1490 by task caif_uaf_trigge/9929 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xd0/0x630 kasan_report+0xe4/0x120 handle_tx+0x5d1/0x620 dev_hard_start_xmit+0x9d/0x6c0 __dev_queue_xmit+0x6e2/0x4410 packet_xmit+0x243/0x360 packet_sendmsg+0x26cf/0x5500 __sys_sendto+0x4a3/0x520 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0xc9/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f615df2c0d7 Allocated by task 9930: Freed by task 64: Last potentially related work creation: The buggy address belongs to the object at ffff8881131e1000 which belongs to the cache kmalloc-cg-2k of size 2048 The buggy address is located 1168 bytes inside of freed 2048-byte region [ffff8881131e1000, ffff8881131e1800) The buggy address belongs to the physical page: page_owner tracks the page as allocated page last free pid 9778 tgid 9778 stack trace: Memory state around the buggy address: ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u Reported-by: syzbot+827272712bd6d12c79a4@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000a4a7550611e234f5@google.com/T/ Fixes: 56e0ef527b18 ("drivers/net: caif: fix wrong rtnl_is_locked() usage") Reviewed-by: Greg Kroah-Hartman Signed-off-by: Jiayuan Chen Reviewed-by: Jijie Shao Link: https://patch.msgid.link/20260206074450.154267-1-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1c9ef28f643cce34a6a6c36c8f4d6d60a60db7e1 Author: Jiayuan Chen Date: Fri Feb 6 13:02:19 2026 +0800 xfrm: fix ip_rt_bug race in icmp_route_lookup reverse path [ Upstream commit 81b84de32bb27ae1ae2eb9acf0420e9d0d14bf00 ] icmp_route_lookup() performs multiple route lookups to find a suitable route for sending ICMP error messages, with special handling for XFRM (IPsec) policies. The lookup sequence is: 1. First, lookup output route for ICMP reply (dst = original src) 2. Pass through xfrm_lookup() for policy check 3. If blocked (-EPERM) or dst is not local, enter "reverse path" 4. In reverse path, call xfrm_decode_session_reverse() to get fl4_dec which reverses the original packet's flow (saddr<->daddr swapped) 5. If fl4_dec.saddr is local (we are the original destination), use __ip_route_output_key() for output route lookup 6. If fl4_dec.saddr is NOT local (we are a forwarding node), use ip_route_input() to simulate the reverse packet's input path 7. Finally, pass rt2 through xfrm_lookup() with XFRM_LOOKUP_ICMP flag The bug occurs in step 6: ip_route_input() is called with fl4_dec.daddr (original packet's source) as destination. If this address becomes local between the initial check and ip_route_input() call (e.g., due to concurrent "ip addr add"), ip_route_input() returns a LOCAL route with dst.output set to ip_rt_bug. This route is then used for ICMP output, causing dst_output() to call ip_rt_bug(), triggering a WARN_ON: ------------[ cut here ]------------ WARNING: net/ipv4/route.c:1275 at ip_rt_bug+0x21/0x30, CPU#1 Call Trace: ip_push_pending_frames+0x202/0x240 icmp_push_reply+0x30d/0x430 __icmp_send+0x1149/0x24f0 ip_options_compile+0xa2/0xd0 ip_rcv_finish_core+0x829/0x1950 ip_rcv+0x2d7/0x420 __netif_receive_skb_one_core+0x185/0x1f0 netif_receive_skb+0x90/0x450 tun_get_user+0x3413/0x3fb0 tun_chr_write_iter+0xe4/0x220 ... Fix this by checking rt2->rt_type after ip_route_input(). If it's RTN_LOCAL, the route cannot be used for output, so treat it as an error. The reproducer requires kernel modification to widen the race window, making it unsuitable as a selftest. It is available at: https://gist.github.com/mrpre/eae853b72ac6a750f5d45d64ddac1e81 Reported-by: syzbot+e738404dcd14b620923c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000b1060905eada8881@google.com/T/ Closes: https://lore.kernel.org/r/20260128090523.356953-1-jiayuan.chen@linux.dev Fixes: 8b7817f3a959 ("[IPSEC]: Add ICMP host relookup support") Signed-off-by: Jiayuan Chen Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260206050220.59642-1-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d8c851cd3245281779792c31117ba90db7527401 Author: René Rebe Date: Thu Feb 5 17:09:59 2026 +0100 net: sunhme: Fix sbus regression [ Upstream commit 8c5d17834ec104d0abd1bda52fbc04e647fab274 ] Commit cc216e4b44ce ("net: sunhme: Switch SBUS to devres") changed explicit sized of_ioremap with BMAC_REG_SIZEs to devm_platform_ioremap_resource mapping all the resource. However, this does not work on my Sun Ultra 2 with SBUS HMEs: hme f0072f38: error -EBUSY: can't request region for resource [mem 0x1ffe8c07000-0x1ffe8c0701f] hme f0072f38: Cannot map TCVR registers. hme f0072f38: probe with driver hme failed with error -16 hme f007ab44: error -EBUSY: can't request region for resource [mem 0x1ff28c07000-0x1ff28c0701f] hme f007ab44: Cannot map TCVR registers. hme f007ab44: probe with driver hme failed with error -16 Turns out the open-firmware resources overlap, at least on this machines and PROM version: hexdump /proc/device-tree/sbus@1f,0/SUNW,hme@2,8c00000/reg: 00 00 00 02 08 c0 00 00 00 00 01 08 00 00 00 02 08 c0 20 00 00 00 20 00 00 00 00 02 08 c0 40 00 00 00 20 00 00 00 00 02 08 c0 60 00 00 00 20 00 00 00 00 02 08 c0 70 00 00 00 00 20 And the driver previously explicitly mapped way smaller mmio regions: /proc/iomem: 1ff28c00000-1ff28c00107 : HME Global Regs 1ff28c02000-1ff28c02033 : HME TX Regs 1ff28c04000-1ff28c0401f : HME RX Regs 1ff28c06000-1ff28c0635f : HME BIGMAC Regs 1ff28c07000-1ff28c0701f : HME Tranceiver Regs Quirk this specific issue by truncating the previous resource to not overlap into the TCVR registers. Fixes: cc216e4b44ce ("net: sunhme: Switch SBUS to devres") Signed-off-by: René Rebe Reviewed-by: Sean Anderson Link: https://patch.msgid.link/20260205.170959.89574674688839340.rene@exactco.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 69d3f9ee5489e6e8b66defcfa226e91d82393297 Author: Jiayuan Chen Date: Thu Feb 5 17:54:51 2026 +0800 net: atm: fix crash due to unvalidated vcc pointer in sigd_send() [ Upstream commit ae88a5d2f29b69819dc7b04086734439d074a643 ] Reproducer available at [1]. The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd_enq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values. Fix this by introducing find_get_vcc() which validates the pointer by searching through vcc_hash (similar to how sigd_close() iterates over all VCCs), and acquires a reference via sock_hold() if found. Since struct atm_vcc embeds struct sock as its first member, they share the same lifetime. Therefore using sock_hold/sock_put is sufficient to keep the vcc alive while it is being used. Note that there may be a race with sigd_close() which could mark the vcc with various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns. However, sock_hold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety. [1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+1f22cb1769f249df9fa0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69039850.a70a0220.5b2ed.005d.GAE@google.com/T/ Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260205095501.131890-1-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 03462247e3b655501ff8ea2c5c298a0ae08032a0 Author: Stefan Metzmacher Date: Thu Feb 5 17:14:14 2026 +0100 smb: client: correct value for smbd_max_fragmented_recv_size [ Upstream commit 4a93d1ee2d0206970b6eb13fbffe07938cd95948 ] When we download a file without rdma offload or get a large directly enumeration from the server, the server might want to send up to smbd_max_fragmented_recv_size bytes, but if it is too large all our recv buffers might already be moved to the recv_io.reassembly.list and we're no longer able to grant recv credits. The maximum fragmented upper-layer payload receive size supported Assume max_payload_per_credit is smbd_max_receive_size - 24 = 1340 The maximum number would be smbd_receive_credit_max * max_payload_per_credit 1340 * 255 = 341700 (0x536C4) The minimum value from the spec is 131072 (0x20000) For now we use the logic we used in ksmbd before: (1364 * 255) / 2 = 173910 (0x2A756) Fixes: 03bee01d6215 ("CIFS: SMBD: Add SMB Direct protocol initial values and constants") Cc: Steve French Cc: Tom Talpey Cc: Long Li Cc: Namjae Jeon Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 4f9ae386861e280b7631ca252f798d25575627ee Author: Jinliang Zheng Date: Wed Jan 28 16:30:07 2026 +0800 procfs: fix missing RCU protection when reading real_parent in do_task_stat() [ Upstream commit 76149d53502cf17ef3ae454ff384551236fba867 ] When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent. Link: https://lkml.kernel.org/r/20260128083007.3173016-1-alexjlzheng@tencent.com Fixes: 06fffb1267c9 ("do_task_stat: don't take rcu_read_lock()") Signed-off-by: Jinliang Zheng Acked-by: Oleg Nesterov Cc: David Hildenbrand Cc: Ingo Molnar Cc: Lorenzo Stoakes Cc: Mateusz Guzik Cc: ruippan Cc: Usama Arif Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit fdbccddb7e7822016601829f95de4008e193f7bc Author: Jian Shen Date: Thu Feb 5 20:17:19 2026 +0800 net: hns3: fix double free issue for tx spare buffer [ Upstream commit 6d2f142b1e4b203387a92519d9d2e34752a79dbb ] In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure is created for rollback. However, the tx_spare pointer in the original ring handle is incorrectly left pointing to the old backup memory. Later, if memory allocation fails in hns3_init_all_ring() during the setup, the error path attempts to free all newly allocated rings. Since tx_spare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory. The root cause is that the tx_spare field was not cleared after its value was saved in tmp_rings, leaving a dangling pointer. Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new `tx_spare` fails. This ensures the error cleanup path only frees genuinely newly allocated buffers. Fixes: 907676b130711 ("net: hns3: use tx bounce buffer for small packets") Signed-off-by: Jian Shen Signed-off-by: Jijie Shao Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260205121719.3285730-1-shaojijie@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9a4d6c37cb1280d96ebbb043ec7ef9ce7eecc0dd Author: Ivan Vecera Date: Thu Feb 5 19:10:55 2026 +0100 dpll: zl3073x: Fix output pin phase adjustment sign [ Upstream commit 5d41f95f5d0bd9db02f3f16a649d0631f71e9fdb ] The output pin phase adjustment functions incorrectly negate the phase compensation value. Per the ZL3073x datasheet, the output phase compensation register is simply a signed two's complement integer where: - Positive values move the phase later in time - Negative values move the phase earlier in time No negation is required. The erroneous negation caused phase adjustments to be applied in the wrong direction. Note that input pin phase adjustment correctly uses negation because the hardware has an inverted convention for input references (positive moves phase earlier, negative moves phase later). Fixes: 6287262f761e ("dpll: zl3073x: Add support to adjust phase") Signed-off-by: Ivan Vecera Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260205181055.129768-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 072cec234a877e6292acda8a80425b13fee2c7d1 Author: Ivan Vecera Date: Thu Nov 13 08:41:04 2025 +0100 dpll: zl3073x: Cache all output properties in zl3073x_out [ Upstream commit 5fb9b0d411f81ec46833ea8e43c0263515060c64 ] Expand the zl3073x_out structure to cache all output-related hardware registers, including divisors, widths, embedded-sync parameters and phase compensation. Modify zl3073x_out_state_fetch() to read and populate all these new fields at once, including zero-divisor checks. Refactor all dpll "getter" functions in dpll.c to read from this new cached state instead of performing direct register access. Introduce a new function, zl3073x_out_state_set(), to handle writing changes back to the hardware. This function compares the provided state with the current cached state and writes *only* the modified register values via a single mailbox sequence before updating the local cache. Refactor all dpll "setter" functions to modify a local copy of the output state and then call zl3073x_out_state_set() to commit the changes. This change centralizes all output-related register I/O into out.c, significantly reduces bus traffic, and simplifies the logic in dpll.c. Reviewed-by: Petr Oros Tested-by: Prathosh Satish Signed-off-by: Ivan Vecera Link: https://patch.msgid.link/20251113074105.141379-6-ivecera@redhat.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5d41f95f5d0b ("dpll: zl3073x: Fix output pin phase adjustment sign") Signed-off-by: Sasha Levin commit 9116bb0e0c9f89e72fb6c22dc2fcec23b244fa86 Author: Ivan Vecera Date: Thu Nov 13 08:41:01 2025 +0100 dpll: zl3073x: Split ref, out, and synth logic from core [ Upstream commit 607f2c00c61faa3b437dbb0d38287e7a9d398a52 ] Refactor the zl3073x driver by splitting the logic for input references, outputs and synthesizers out of the monolithic core.[ch] files. Move the logic for each functional block into its own dedicated files: ref.[ch], out.[ch] and synth.[ch]. Specifically: - Move state structures (zl3073x_ref, zl3073x_out, zl3073x_synth) from core.h into their respective new headers - Move state-fetching functions (..._state_fetch) from core.c to their new .c files - Move the zl3073x_ref_freq_factorize helper from core.c to ref.c - Introduce a new helper layer to decouple the core device logic from the state-parsing logic: 1. Move the original inline helpers (e.g., zl3073x_ref_is_enabled) to the new headers (ref.h, etc.) and make them operate on a const struct ... * pointer. 2. Create new zl3073x_dev_... prefixed functions in core.h (e.g., zl3073x_dev_ref_is_enabled) and Implement these _dev_ functions to fetch state using a new ..._state_get() helper and then call the non-prefixed helper. 3. Update all driver-internal callers (in dpll.c, prop.c, etc.) to use the new zl3073x_dev_... functions. Reviewed-by: Petr Oros Tested-by: Prathosh Satish Signed-off-by: Ivan Vecera Link: https://patch.msgid.link/20251113074105.141379-3-ivecera@redhat.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5d41f95f5d0b ("dpll: zl3073x: Fix output pin phase adjustment sign") Signed-off-by: Sasha Levin commit 84b8990f5771d0591de7365ddbec17b1fafb97c7 Author: Ivan Vecera Date: Thu Nov 13 08:41:00 2025 +0100 dpll: zl3073x: Store raw register values instead of parsed state [ Upstream commit 58fb88d30b0250f928e1afa0eaa4547770d86229 ] The zl3073x_ref, zl3073x_out and zl3073x_synth structures previously stored state that was parsed from register reads. This included values like boolean 'enabled' flags, synthesizer selections, and pre-calculated frequencies. This commit refactors the state management to store the raw register values directly in these structures. The various inline helper functions are updated to parse these raw values on-demand using FIELD_GET. Reviewed-by: Petr Oros Tested-by: Prathosh Satish Signed-off-by: Ivan Vecera Link: https://patch.msgid.link/20251113074105.141379-2-ivecera@redhat.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5d41f95f5d0b ("dpll: zl3073x: Fix output pin phase adjustment sign") Signed-off-by: Sasha Levin commit 40bcd1fa0e23c31e9c2ab910e54d93d8d0fabc1b Author: Ivan Vecera Date: Wed Oct 29 16:32:07 2025 +0100 dpll: zl3073x: Specify phase adjustment granularity for pins [ Upstream commit 055a01b29fd643e33b9b1e88e24bbe1afe6fc6d9 ] Output pins phase adjustment values in the device are expressed in half synth clock cycles. Use this number of cycles as output pins' phase adjust granularity and simplify both get/set callbacks. Reviewed-by: Michal Schmidt Reviewed-by: Petr Oros Tested-by: Prathosh Satish Signed-off-by: Ivan Vecera Reviewed-by: Arkadiusz Kubalewski Link: https://patch.msgid.link/20251029153207.178448-3-ivecera@redhat.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5d41f95f5d0b ("dpll: zl3073x: Fix output pin phase adjustment sign") Signed-off-by: Sasha Levin commit f399e8af187a86a7feb16de879474e854bb6bc89 Author: Ivan Vecera Date: Wed Oct 29 16:32:06 2025 +0100 dpll: add phase-adjust-gran pin attribute [ Upstream commit 30176bf7c871681df506f3165ffe76ec462db991 ] Phase-adjust values are currently limited by a min-max range. Some hardware requires, for certain pin types, that values be multiples of a specific granularity, as in the zl3073x driver. Add a `phase-adjust-gran` pin attribute and an appropriate field in dpll_pin_properties. If set by the driver, use its value to validate user-provided phase-adjust values. Reviewed-by: Michal Schmidt Reviewed-by: Petr Oros Tested-by: Prathosh Satish Signed-off-by: Ivan Vecera Reviewed-by: Jiri Pirko Reviewed-by: Arkadiusz Kubalewski Link: https://patch.msgid.link/20251029153207.178448-2-ivecera@redhat.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5d41f95f5d0b ("dpll: zl3073x: Fix output pin phase adjustment sign") Signed-off-by: Sasha Levin commit 782368c13f5a331e4a7261261061b79cb41ffafe Author: Nicolas Cavallari Date: Mon Jan 19 17:08:33 2026 +0100 PCI: Add ACS quirk for Pericom PI7C9X2G404 switches [12d8:b404] [ Upstream commit 5907a90551e9f7968781f3a6ab8684458959beb3 ] 12d8:b404 is apparently another PCI ID for Pericom PI7C9X2G404 (as identified by the chip silkscreen and lspci). It is also affected by the PI7C9X2G errata (e.g. a network card attached to it fails under load when P2P Redirect Request is enabled), so apply the same quirk to this PCI ID too. PCI bridge [0604]: Pericom Semiconductor PI7C9X2G404 EV/SV PCIe2 4-Port/4-Lane Packet Switch [12d8:b404] (rev 01) Fixes: acd61ffb2f16 ("PCI: Add ACS quirk for Pericom PI7C9X2G switches") Closes: https://lore.kernel.org/all/a1d926f0-4cb5-4877-a4df-617902648d80@green-communications.fr/ Signed-off-by: Nicolas Cavallari Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260119160915.26456-1-nicolas.cavallari@green-communications.fr Signed-off-by: Sasha Levin commit 12b1681793e9b7552495290785a3570c539f409d Author: Pablo Neira Ayuso Date: Fri Feb 6 13:33:46 2026 +0100 netfilter: nft_set_rbtree: validate open interval overlap [ Upstream commit 648946966a08e4cb1a71619e3d1b12bd7642de7b ] Open intervals do not have an end element, in particular an open interval at the end of the set is hard to validate because of it is lacking the end element, and interval validation relies on such end element to perform the checks. This patch adds a new flag field to struct nft_set_elem, this is not an issue because this is a temporary object that is allocated in the stack from the insert/deactivate path. This flag field is used to specify that this is the last element in this add/delete command. The last flag is used, in combination with the start element cookie, to check if there is a partial overlap, eg. Already exists: 255.255.255.0-255.255.255.254 Add interval: 255.255.255.0-255.255.255.255 ~~~~~~~~~~~~~ start element overlap Basically, the idea is to check for an existing end element in the set if there is an overlap with an existing start element. However, the last open interval can come in any position in the add command, the corner case can get a bit more complicated: Already exists: 255.255.255.0-255.255.255.254 Add intervals: 255.255.255.0-255.255.255.255,255.255.255.0-255.255.255.254 ~~~~~~~~~~~~~ start element overlap To catch this overlap, annotate that the new start element is a possible overlap, then report the overlap if the next element is another start element that confirms that previous element in an open interval at the end of the set. For deletions, do not update the start cookie when deleting an open interval, otherwise this can trigger spurious EEXIST when adding new elements. Unfortunately, there is no NFT_SET_ELEM_INTERVAL_OPEN flag which would make easier to detect open interval overlaps. Fixes: 7c84d41416d8 ("netfilter: nft_set_rbtree: Detect partial overlaps on insertion") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 90cbb8561aee03dbbe866ee3c6df7031b0299500 Author: Pablo Neira Ayuso Date: Fri Feb 6 13:33:45 2026 +0100 netfilter: nft_set_rbtree: validate element belonging to interval [ Upstream commit 782f2688128eca6d05a48be1c247f68d86afc168 ] The existing partial overlap detection does not check if the elements belong to the interval, eg. add element inet x y { 1.1.1.1-2.2.2.2, 4.4.4.4-5.5.5.5 } add element inet x y { 1.1.1.1-5.5.5.5 } => this should fail: ENOENT Similar situation occurs with deletions: add element inet x y { 1.1.1.1-2.2.2.2, 4.4.4.4-5.5.5.5} delete element inet x y { 1.1.1.1-5.5.5.5 } => this should fail: ENOENT This currently works via mitigation by nft in userspace, which is performing the overlap detection before sending the elements to the kernel. This requires a previous netlink dump of the set content which slows down incremental updates on interval sets, because a netlink set content dump is needed. This patch extends the existing overlap detection to track the most recent start element that already exists. The pointer to the existing start element is stored as a cookie (no pointer dereference is ever possible). If the end element is added and it already exists, then check that the existing end element is adjacent to the already existing start element. Similar logic applies to element deactivation. This patch also annotates the timestamp to identify if start cookie comes from an older batch, in such case reset it. Otherwise, a failing create element command leaves the start cookie in place, resulting in bogus error reporting. There is still a few more corner cases of overlap detection related to the open interval that are addressed in follow up patches. This is address an early design mistake where an interval is expressed as two elements, using the NFT_SET_ELEM_INTERVAL_END flag, instead of the more recent NFTA_SET_ELEM_KEY_END attribute that pipapo already uses. Fixes: 7c84d41416d8 ("netfilter: nft_set_rbtree: Detect partial overlaps on insertion") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 3c40cc71cec7a3a26826e87551151bafdfe14f31 Author: Florian Westphal Date: Wed Jan 28 15:06:21 2026 +0100 netfilter: nft_set_rbtree: don't gc elements on insert [ Upstream commit 35f83a75529a829b0939708b003652f7b4f3df9a ] During insertion we can queue up expired elements for garbage collection. In case of later abort, the commit hook will never be called. Packet path and 'get' requests will find free'd elements in the binary search blob: nft_set_ext_key include/net/netfilter/nf_tables.h:800 [inline] nft_array_get_cmp+0x1f6/0x2a0 net/netfilter/nft_set_rbtree.c:133 __inline_bsearch include/linux/bsearch.h:15 [inline] bsearch+0x50/0xc0 lib/bsearch.c:33 nft_rbtree_get+0x16b/0x400 net/netfilter/nft_set_rbtree.c:169 nft_setelem_get net/netfilter/nf_tables_api.c:6495 [inline] nft_get_set_elem+0x420/0xaa0 net/netfilter/nf_tables_api.c:6543 nf_tables_getsetelem+0x448/0x5e0 net/netfilter/nf_tables_api.c:6632 nfnetlink_rcv_msg+0x8ae/0x12c0 net/netfilter/nfnetlink.c:290 Also, when we insert an element that triggers -EEXIST, and that insertion happens to also zap a timed-out entry, we end up with same issue: Neither commit nor abort hook is called. Fix this by removing gc api usage during insertion. The blamed commit also removes concurrency of the rbtree with the packet path, so we can now safely rb_erase() the element and move it to a new expired list that can be reaped in the commit hook before building the next blob iteration. This also avoids the need to rebuild the blob in the abort path: Expired elements seen during insertion attempts are kept around until a transaction passes. Reported-by: syzbot+d417922a3e7935517ef6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d417922a3e7935517ef6 Fixes: 7e43e0a1141d ("netfilter: nft_set_rbtree: translate rbtree to array for binary search") Signed-off-by: Florian Westphal Stable-dep-of: 782f2688128e ("netfilter: nft_set_rbtree: validate element belonging to interval") Signed-off-by: Sasha Levin commit 89a3f393ab0d964d38a7c4d8d9cb018f33b20e42 Author: Pablo Neira Ayuso Date: Wed Jan 21 01:08:47 2026 +0100 netfilter: nft_set_rbtree: remove seqcount_rwlock_t [ Upstream commit 5599fa810b503eafc2bd8cd15bd45f35fc8ff6b9 ] After the conversion to binary search array, this is not required anymore. Remove it. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Stable-dep-of: 782f2688128e ("netfilter: nft_set_rbtree: validate element belonging to interval") Signed-off-by: Sasha Levin commit e4ea5be0b35fd2f772bb289e235e3836320957bd Author: Pablo Neira Ayuso Date: Wed Jan 21 01:08:46 2026 +0100 netfilter: nft_set_rbtree: use binary search array in get command [ Upstream commit 2aa34191f06fc5af4f70241518a8554370d86054 ] Rework .get interface to use the binary search array, this needs a specific lookup function to match on end intervals (<=). Packet path lookup is slight different because match is on lesser value, not equal (ie. <). After this patch, seqcount can be removed in a follow up patch. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Stable-dep-of: 782f2688128e ("netfilter: nft_set_rbtree: validate element belonging to interval") Signed-off-by: Sasha Levin commit 36ed9b6e39611234ef85c16e3cfd1bb24b306c07 Author: Pablo Neira Ayuso Date: Wed Jan 21 01:08:45 2026 +0100 netfilter: nft_set_rbtree: translate rbtree to array for binary search [ Upstream commit 7e43e0a1141deec651a60109dab3690854107298 ] The rbtree can temporarily store overlapping inactive elements during the transaction processing, leading to false negative lookups. To address this issue, this patch adds a .commit function that walks the the rbtree to build a array of intervals of ordered elements. This conversion compacts the two singleton elements that represent the start and the end of the interval into a single interval object for space efficient. Binary search is O(log n), similar to rbtree lookup time, therefore, performance number should be similar, and there is an implementation available under lib/bsearch.c and include/linux/bsearch.h that is used for this purpose. This slightly increases memory consumption for this new array that stores pointers to the start and the end of the interval. With this patch: # time nft -f 100k-intervals-set.nft real 0m4.218s user 0m3.544s sys 0m0.400s Without this patch: # time nft -f 100k-intervals-set.nft real 0m3.920s user 0m3.547s sys 0m0.276s With this patch, with IPv4 intervals: baseline rbtree (match on first field only): 15254954pps Without this patch: baseline rbtree (match on first field only): 10256119pps This provides a ~50% improvement in matching intervals from packet path. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Stable-dep-of: 782f2688128e ("netfilter: nft_set_rbtree: validate element belonging to interval") Signed-off-by: Sasha Levin commit dad14d22dff1a191612acb98facceb303d0524a2 Author: Pablo Neira Ayuso Date: Fri Feb 6 13:33:44 2026 +0100 netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets [ Upstream commit 4780ec142cbb24b794129d3080eee5cac2943ffc ] Userspace provides an optimized representation in case intervals are adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous set checks on start elements for this reason. However, it is possible to add intervals that overlap to this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end A B start end A C Restore the check on overlapping start elements to report an overlap. Fixes: c9e6978e2725 ("netfilter: nft_set_rbtree: Switch to node list walk for overlap detection") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 40a7afde2f5369ad63fe801edbf4b44d51b17b8d Author: Pablo Neira Ayuso Date: Fri Feb 6 13:33:43 2026 +0100 netfilter: nft_set_rbtree: fix bogus EEXIST with NLM_F_CREATE with null interval [ Upstream commit 7f9203f41aae8eea74fba6a3370da41332eabcda ] Userspace adds a non-matching null element to the kernel for historical reasons. This null element is added when the set is populated with elements. Inclusion of this element is conditional, therefore, userspace needs to dump the set content to check for its presence. If the NLM_F_CREATE flag is turned on, this becomes an issue because kernel bogusly reports EEXIST. Add special case to ignore NLM_F_CREATE in this case, therefore, re-adding the nul-element never fails. Fixes: c016c7e45ddf ("netfilter: nf_tables: honor NLM_F_EXCL flag in set element insertion") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 735ad034f1dcbce15ac25c931898c0e093bd9dc9 Author: Anders Grahn Date: Tue Feb 3 14:48:30 2026 +0100 netfilter: nft_counter: fix reset of counters on 32bit archs [ Upstream commit 1e13f27e0675552161ab1778be9a23a636dde8a7 ] nft_counter_reset() calls u64_stats_add() with a negative value to reset the counter. This will work on 64bit archs, hence the negative value added will wrap as a 64bit value which then can wrap the stat counter as well. On 32bit archs, the added negative value will wrap as a 32bit value and _not_ wrapping the stat counter properly. In most cases, this would just lead to a very large 32bit value being added to the stat counter. Fix by introducing u64_stats_sub(). Fixes: 4a1d3acd6ea8 ("netfilter: nft_counter: Use u64_stats_t for statistic.") Signed-off-by: Anders Grahn Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 6f2d238faff01e3209032f983b0fef4bf648e13e Author: Florian Westphal Date: Tue Jan 27 20:13:45 2026 +0100 netfilter: nft_set_hash: fix get operation on big endian [ Upstream commit 2f635adbe2642d398a0be3ab245accd2987be0c3 ] tests/shell/testcases/packetpath/set_match_nomatch_hash_fast fails on big endian with: Error: Could not process rule: No such file or directory reset element ip test s { 244.147.90.126 } ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Fatal: Cannot fetch element "244.147.90.126" ... because the wrong bucket is searched, jhash() and jhash1_word are not interchangeable on big endian. Fixes: 3b02b0adc242 ("netfilter: nft_set_hash: fix lookups with fixed size hash on big endian") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 23901aa6b8a2f294c4b774436b4691f3ff863a8f Author: Florian Westphal Date: Thu Nov 20 17:17:06 2025 +0100 netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation [ Upstream commit 207b3ebacb6113acaaec0d171d5307032c690004 ] Ulrich reports a regression with nfqueue: If an application did not set the 'F_GSO' capability flag and a gso packet with an unconfirmed nf_conn entry is received all packets are now dropped instead of queued, because the check happens after skb_gso_segment(). In that case, we did have exclusive ownership of the skb and its associated conntrack entry. The elevated use count is due to skb_clone happening via skb_gso_segment(). Move the check so that its peformed vs. the aggregated packet. Then, annotate the individual segments except the first one so we can do a 2nd check at reinject time. For the normal case, where userspace does in-order reinjects, this avoids packet drops: first reinjected segment continues traversal and confirms entry, remaining segments observe the confirmed entry. While at it, simplify nf_ct_drop_unconfirmed(): We only care about unconfirmed entries with a refcnt > 1, there is no need to special-case dying entries. This only happens with UDP. With TCP, the only unconfirmed packet will be the TCP SYN, those aren't aggregated by GRO. Next patch adds a udpgro test case to cover this scenario. Reported-by: Ulrich Weber Fixes: 7d8dc1c7be8d ("netfilter: nf_queue: drop packets with cloned unconfirmed conntracks") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 870e3e63da8e88daffe9d692a025c711658018a8 Author: Scott Mitchell Date: Fri Jan 23 14:09:30 2026 -0800 netfilter: nfnetlink_queue: optimize verdict lookup with hash table [ Upstream commit e19079adcd26a25d7d3e586b1837493361fdf8b6 ] The current implementation uses a linear list to find queued packets by ID when processing verdicts from userspace. With large queue depths and out-of-order verdicting, this O(n) lookup becomes a significant bottleneck, causing userspace verdict processing to dominate CPU time. Replace the linear search with a hash table for O(1) average-case packet lookup by ID. A global rhashtable spanning all network namespaces attributes hash bucket memory to kernel but is subject to fixed upper bound. Signed-off-by: Scott Mitchell Signed-off-by: Florian Westphal Stable-dep-of: 207b3ebacb61 ("netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation") Signed-off-by: Sasha Levin commit 276820278e9717cc7d4bb32381892dd3ddf418d4 Author: Votokina Victoria Date: Tue Feb 3 14:31:57 2026 +0300 nfc: hci: shdlc: Stop timers and work before freeing context [ Upstream commit c9efde1e537baed7648a94022b43836a348a074f ] llc_shdlc_deinit() purges SHDLC skb queues and frees the llc_shdlc structure while its timers and state machine work may still be active. Timer callbacks can schedule sm_work, and sm_work accesses SHDLC state and the skb queues. If teardown happens in parallel with a queued/running work item, it can lead to UAF and other shutdown races. Stop all SHDLC timers and cancel sm_work synchronously before purging the queues and freeing the context. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 4a61cd6687fc ("NFC: Add an shdlc llc module to llc core") Signed-off-by: Votokina Victoria Link: https://patch.msgid.link/20260203113158.2008723-1-Victoria.Votokina@kaspersky.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 531c1aec81bfe19d00af13da5531fbb8209e4bd2 Author: Eric Dumazet Date: Tue Feb 3 19:25:09 2026 +0000 inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP [ Upstream commit c89477ad79446867394360b29bb801010fc3ff22 ] Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src="192.168.2.1", dst="8.8.8.8", proto=255)/Raw("TEST") pkt = IP(src="192.168.1.1", dst="192.168.2.1")/ICMP(type=3, code=4, nexthopmtu=576)/inner "man 7 raw" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yizhou Zhao Link: https://lore.kernel.org/netdev/20251109134600.292125-1-zhaoyz24@mails.tsinghua.edu.cn/ Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260203192509.682208-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 67b75bb0ec55a31e88dd28939406e311b5fbe7f3 Author: Thomas Bogendoerfer Date: Tue Feb 3 15:11:52 2026 +0100 bonding: only set speed/duplex to unknown, if getting speed failed [ Upstream commit 48dec8d88af96039a4a17b8c2f148f2a4066e195 ] bond_update_speed_duplex() first set speed/duplex to unknown and then asks slave driver for current speed/duplex. Since getting speed/duplex might take longer there is a race, where this false state is visible by /proc/net/bonding. With commit 691b2bf14946 ("bonding: update port speed when getting bond speed") this race gets more visible, if user space is calling ethtool on a regular base. Fix this by only setting speed/duplex to unknown, if link speed is really unknown/unusable. Fixes: 98f41f694f46 ("bonding:update speed/duplex for NETDEV_CHANGE") Signed-off-by: Thomas Bogendoerfer Acked-by: Jay Vosburgh Reviewed-by: Nikolay Aleksandrov Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260203141153.51581-1-tbogendoerfer@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9c3398e5b3a914b74276d44ab54c49123b89c61a Author: Anshumali Gaur Date: Tue Feb 3 10:37:01 2026 +0530 octeontx2-af: Fix PF driver crash with kexec kernel booting [ Upstream commit 2d2d574309e3ae84ee794869a5da8b4c38753a94 ] During a kexec reboot the hardware is not power-cycled, so AF state from the old kernel can persist into the new kernel. When AF and PF drivers are built as modules, the PF driver may probe before AF reinitializes the hardware. The PF driver treats the RVUM block revision as an indication that AF initialization is complete. If this value is left uncleared at shutdown, PF may incorrectly assume AF is ready and access stale hardware state, leading to a crash. Clear the RVUM block revision during AF shutdown to avoid PF mis-detecting AF readiness after kexec. Fixes: 54494aa5d1e6 ("octeontx2-af: Add Marvell OcteonTX2 RVU AF driver") Signed-off-by: Anshumali Gaur Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260203050701.2616685-1-agaur@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1fff00261c7883baafe98541481a3732d652d9fc Author: Paolo Abeni Date: Tue Feb 3 19:41:18 2026 +0100 mptcp: fix receive space timestamp initialization [ Upstream commit 70274765fef555af92a1532d5bd5450c691fca9d ] MPTCP initialize the receive buffer stamp in mptcp_rcv_space_init(), using the provided subflow stamp. Such helper is invoked in several places; for passive sockets, space init happened at clone time. In such scenario, MPTCP ends-up accesses the subflow stamp before its initialization, leading to quite randomic timing for the first receive buffer auto-tune event, as the timestamp for newly created subflow is not refreshed there. Fix the issue moving the stamp initialization out of the mentioned helper, at the data transfer start, and always using a fresh timestamp. Fixes: 013e3179dbd2 ("mptcp: fix rcv space initialization") Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260203-net-next-mptcp-misc-feat-6-20-v1-2-31ec8bfc56d1@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fb7bf00b04a6b48859f52035d4e745848c2b4c79 Author: Paolo Abeni Date: Tue Feb 3 19:41:17 2026 +0100 mptcp: do not account for OoO in mptcp_rcvbuf_grow() [ Upstream commit 6b329393502e5857662b851a13f947209c588587 ] MPTCP-level OoOs are physiological when multiple subflows are active concurrently and will not cause retransmissions nor are caused by drops. Accounting for them in mptcp_rcvbuf_grow() causes the rcvbuf slowly drifting towards tcp_rmem[2]. Remove such accounting. Note that subflows will still account for TCP-level OoO when the MPTCP-level rcvbuf is propagated. This also closes a subtle and very unlikely race condition with rcvspace init; active sockets with user-space holding the msk-level socket lock, could complete such initialization in the receive callback, after that the first OoO data reaches the rcvbuf and potentially triggering a divide by zero Oops. Fixes: e118cdc34dd1 ("mptcp: rcvbuf auto-tuning improvement") Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260203-net-next-mptcp-misc-feat-6-20-v1-1-31ec8bfc56d1@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 10a66a44e3691c2c9257e272ac6f14db60168044 Author: Tuo Li Date: Mon Jan 5 15:14:38 2026 +0800 of: unittest: fix possible null-pointer dereferences in of_unittest_property_copy() [ Upstream commit d289cb7fcefe41a54d8f9c6d0e0947f5f82b15c6 ] This function first duplicates p1 and p2 into new, and then checks whether the duplication succeeds. However, if the duplication fails (e.g., kzalloc() returns NULL in __of_prop_dup()), new will be NULL but is still dereferenced in __of_prop_free(). To ensure that the unit test continues to run even when duplication fails, add a NULL check before calling __of_prop_free(). Fixes: 1c5e3d9bf33b ("of: Add a helper to free property struct") Signed-off-by: Tuo Li Link: https://patch.msgid.link/20260105071438.156186-1-islituo@gmail.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit b8856aba0fb03cd5a1da7930054cc0b049de2bea Author: Chia-Yu Chang Date: Sat Jan 31 23:25:06 2026 +0100 tcp: accecn: handle unexpected AccECN negotiation feedback [ Upstream commit c5ff6b83715919767f181f13e992b5055812a194 ] According to Sections 3.1.2 and 3.1.3 of AccECN spec (RFC9768). In Section 3.1.2, it says an AccECN implementation has no need to recognize or support the Server response labelled 'Nonce' or ECN-nonce feedback more generally, as RFC 3540 has been reclassified as Historic. AccECN is compatible with alternative ECN feedback integrity approaches to the nonce. The SYN/ACK labelled 'Nonce' with (AE,CWR,ECE) = (1,0,1) is reserved for future use. A TCP Client (A) that receives such a SYN/ACK follows the procedure for forward compatibility given in Section 3.1.3. Then in Section 3.1.3, it says if a TCP Client has sent a SYN requesting AccECN feedback with (AE,CWR,ECE) = (1,1,1) then receives a SYN/ACK with the currently reserved combination (AE,CWR,ECE) = (1,0,1) but it does not have logic specific to such a combination, the Client MUST enable AccECN mode as if the SYN/ACK onfirmed that the Server supported AccECN and as if it fed back that the IP-ECN field on the SYN had arrived unchanged. Fixes: 3cae34274c79 ("tcp: accecn: AccECN negotiation"). Signed-off-by: Chia-Yu Chang Acked-by: Paolo Abeni Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260131222515.8485-7-chia-yu.chang@nokia-bell-labs.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2ff45b29f37ed8e9d33cc4ac722a72ad0a9c6af4 Author: Chia-Yu Chang Date: Sat Jan 31 23:25:05 2026 +0100 tcp: disable RFC3168 fallback identifier for CC modules [ Upstream commit e68c28f22f46ecfdec3656ae785dd8ccbb4d557d ] When AccECN is not successfully negociated for a TCP flow, it defaults fallback to classic ECN (RFC3168). However, L4S service will fallback to non-ECN. This patch enables congestion control module to control whether it should not fallback to classic ECN after unsuccessful AccECN negotiation. A new CA module flag (TCP_CONG_NO_FALLBACK_RFC3168) identifies this behavior expected by the CA. Signed-off-by: Chia-Yu Chang Acked-by: Paolo Abeni Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260131222515.8485-6-chia-yu.chang@nokia-bell-labs.com Signed-off-by: Paolo Abeni Stable-dep-of: c5ff6b837159 ("tcp: accecn: handle unexpected AccECN negotiation feedback") Signed-off-by: Sasha Levin commit 69484fd350be4cd98708d42544e01149bca24f0b Author: Chia-Yu Chang Date: Sat Jan 31 23:25:04 2026 +0100 tcp: ECT_1_NEGOTIATION and NEEDS_ACCECN identifiers [ Upstream commit 100f946b8d44b64bc0b8a8c30d283105031c0a77 ] Two flags for congestion control (CC) module are added in this patch related to AccECN negotiation. First, a new flag (TCP_CONG_NEEDS_ACCECN) defines that the CC expects to negotiate AccECN functionality using the ECE, CWR and AE flags in the TCP header. Second, during ECN negotiation, ECT(0) in the IP header is used. This patch enables CC to control whether ECT(0) or ECT(1) should be used on a per-segment basis. A new flag (TCP_CONG_ECT_1_NEGOTIATION) defines the expected ECT value in the IP header by the CA when not-yet initialized for the connection. The detailed AccECN negotiaotn can be found in IETF RFC9768. Co-developed-by: Olivier Tilmans Signed-off-by: Olivier Tilmans Signed-off-by: Ilpo Järvinen Signed-off-by: Chia-Yu Chang Acked-by: Paolo Abeni Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260131222515.8485-5-chia-yu.chang@nokia-bell-labs.com Signed-off-by: Paolo Abeni Stable-dep-of: c5ff6b837159 ("tcp: accecn: handle unexpected AccECN negotiation feedback") Signed-off-by: Sasha Levin commit 817780cb3f555228e93d6fee2a776c717b751757 Author: Arnd Bergmann Date: Mon Feb 2 21:43:45 2026 +0100 jfs: avoid -Wtautological-constant-out-of-range-compare warning [ Upstream commit 7833570dae833028337bb53b7f389825b910c100 ] A recent change for the range check started triggering a clang warning: fs/jfs/jfs_dtree.c:2906:31: error: result of comparison of constant 128 with expression of type 's8' (aka 'signed char') is always false [-Werror,-Wtautological-constant-out-of-range-compare] 2906 | if (stbl[i] < 0 || stbl[i] >= DTPAGEMAXSLOT) { | ~~~~~~~ ^ ~~~~~~~~~~~~~ fs/jfs/jfs_dtree.c:3111:30: error: result of comparison of constant 128 with expression of type 's8' (aka 'signed char') is always false [-Werror,-Wtautological-constant-out-of-range-compare] 3111 | if (stbl[0] < 0 || stbl[0] >= DTPAGEMAXSLOT) { | ~~~~~~~ ^ ~~~~~~~~~~~~~ Both the old and the new check were useless, but the previous version apparently did not lead to the warning. Remove the extraneous range check for simplicity. Fixes: cafc6679824a ("jfs: replace hardcoded magic number with DTPAGEMAXSLOT constant") Signed-off-by: Arnd Bergmann Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit b4374b0bed103fc37be64a8f9a344f8c93eb5599 Author: Ondrej Mosnacek Date: Thu Jan 22 15:07:45 2026 +0100 ucount: check for CAP_SYS_RESOURCE using ns_capable_noaudit() [ Upstream commit 0895a000e4fff9e950a7894210db45973e485c35 ] The user.* sysctls implement the ctl_table_root::permissions hook and they override the file access mode based on the CAP_SYS_RESOURCE capability (at most rwx if capable, at most r-- if not). The capability is being checked unconditionally, so if an LSM denies the capability, an audit record may be logged even when access is in fact granted. Given the logic in the set_permissions() function in kernel/ucount.c and the unfortunate way the permission checking is implemented, it doesn't seem viable to avoid false positive denials by deferring the capability check. Thus, do the same as in net_ctl_permissions() (net/sysctl_net.c) - switch from ns_capable() to ns_capable_noaudit(), so that the check never logs an audit record. Link: https://lkml.kernel.org/r/20260122140745.239428-1-omosnace@redhat.com Fixes: dbec28460a89 ("userns: Add per user namespace sysctls.") Signed-off-by: Ondrej Mosnacek Reviewed-by: Paul Moore Acked-by: Serge Hallyn Cc: Eric Biederman Cc: Alexey Gladkov Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8fd58e0a0f04059b293a2673a6ffcda2b615160f Author: Ondrej Mosnacek Date: Thu Jan 22 15:13:03 2026 +0100 ipc: don't audit capability check in ipc_permissions() [ Upstream commit 071588136007482d70fd2667b827036bc60b1f8f ] The IPC sysctls implement the ctl_table_root::permissions hook and they override the file access mode based on the CAP_CHECKPOINT_RESTORE capability, which is being checked regardless of whether any access is actually denied or not, so if an LSM denies the capability, an audit record may be logged even when access is in fact granted. It wouldn't be viable to restructure the sysctl permission logic to only check the capability when the access would be actually denied if it's not granted. Thus, do the same as in net_ctl_permissions() (net/sysctl_net.c) - switch from ns_capable() to ns_capable_noaudit(), so that the check never emits an audit record. Fixes: 0889f44e2810 ("ipc: Check permissions for checkpoint_restart sysctls at open time") Signed-off-by: Ondrej Mosnacek Acked-by: Alexey Gladkov Acked-by: Serge Hallyn Signed-off-by: Serge Hallyn Stable-dep-of: 8924336531e2 ("ipc: don't audit capability check in ipc_permissions()") Signed-off-by: Sasha Levin commit f5efb397c8f937873130f903569ec366d1e5d173 Author: Kevin Brodsky Date: Thu Jan 22 17:02:19 2026 +0000 selftests/mm: fix usage of FORCE_READ() in cow tests [ Upstream commit bce1dabd310e87fefe0645fec9ba98b84d37e418 ] Commit 5bbc2b785e63 ("selftests/mm: fix FORCE_READ to read input value correctly") modified FORCE_READ() to take a value instead of a pointer. It also changed most of the call sites accordingly, but missed many of them in cow.c. In those cases, we ended up with the pointer itself being read, not the memory it points to. No failure occurred as a result, so it looks like the tests work just fine without faulting in. However, the huge_zeropage tests explicitly check that pages are populated, so those became skipped. Convert all the remaining FORCE_READ() to fault in the mapped page, as was originally intended. This allows the huge_zeropage tests to run again (3 tests in total). Link: https://lkml.kernel.org/r/20260122170224.4056513-5-kevin.brodsky@arm.com Fixes: 5bbc2b785e63 ("selftests/mm: fix FORCE_READ to read input value correctly") Signed-off-by: Kevin Brodsky Acked-by: SeongJae Park Reviewed-by: wang lian Acked-by: David Hildenbrand (Red Hat) Reviewed-by: Dev Jain Cc: Jason Gunthorpe Cc: John Hubbard Cc: Lorenzo Stoakes Cc: Mark Brown Cc: Paolo Abeni Cc: Ryan Roberts Cc: Shuah Khan Cc: Usama Anjum Cc: Yunsheng Lin Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 4a0d8d372915261c344fea63e4eb1e6b41650ac0 Author: Håkon Bugge Date: Thu Jan 29 18:52:33 2026 +0100 PCI/ACPI: Restrict program_hpx_type2() to AER bits [ Upstream commit 9abf79c8d7b40db0e5a34aa8c744ea60ff9a3fcf ] Previously program_hpx_type2() applied PCIe settings unconditionally, which could incorrectly change bits like Extended Tag Field Enable and Enable Relaxed Ordering. When _HPX was added to ACPI r3.0, the intent of the PCIe Setting Record (Type 2) in sec 6.2.7.3 was to configure AER registers when the OS does not own the AER Capability: The PCI Express setting record contains ... [the AER] Uncorrectable Error Mask, Uncorrectable Error Severity, Correctable Error Mask ... to be used when configuring registers in the Advanced Error Reporting Extended Capability Structure ... OSPM [1] will only evaluate _HPX with Setting Record – Type 2 if OSPM is not controlling the PCI Express Advanced Error Reporting capability. ACPI r3.0b, sec 6.2.7.3, added more AER registers, including registers in the PCIe Capability with AER-related bits, and the restriction that the OS use this only when it owns PCIe native hotplug: ... when configuring PCI Express registers in the Advanced Error Reporting Extended Capability Structure *or PCI Express Capability Structure* ... An OS that has assumed ownership of native hot plug but does not ... have ownership of the AER register set must use ... the Type 2 record to program the AER registers ... However, since the Type 2 record also includes register bits that have functions other than AER, the OS must ignore values ... that are not applicable. Restrict program_hpx_type2() to only the intended purpose: - Apply settings only when OS owns PCIe native hotplug but not AER, - Only touch the AER-related bits (Error Reporting Enables) in Device Control - Don't touch Link Control at all, since nothing there seems AER-related, but log _HPX settings for debugging purposes Note that Read Completion Boundary is now configured elsewhere, since it is unrelated to _HPX. [1] Operating System-directed configuration and Power Management Fixes: 40abb96c51bb ("[PATCH] pciehp: Fix programming hotplug parameters") Signed-off-by: Håkon Bugge Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260129175237.727059-3-haakon.bugge@oracle.com Signed-off-by: Sasha Levin commit dbe723b480e4731faf181ae5b650a2dcdcbc4179 Author: Håkon Bugge Date: Thu Jan 29 18:52:32 2026 +0100 PCI: Initialize RCB from pci_configure_device() [ Upstream commit 1a6845aaa6de81f95959b380b45de8f10d6a8502 ] Commit e42010d8207f ("PCI: Set Read Completion Boundary to 128 iff Root Port supports it (_HPX)") worked around a bogus _HPX type 2 record, which caused program_hpx_type2() to set the RCB in an endpoint even though the Root Port did not have the RCB bit set. e42010d8207f fixed that by setting the RCB in the endpoint only when it was set in the Root Port. In retrospect, program_hpx_type2() is intended for AER-related settings, and the RCB should be configured elsewhere so it doesn't depend on the presence or contents of an _HPX record. Explicitly program the RCB from pci_configure_device() so it matches the Root Port's RCB. The Root Port may not be visible to virtualized guests; in that case, leave RCB alone. Fixes: e42010d8207f ("PCI: Set Read Completion Boundary to 128 iff Root Port supports it (_HPX)") Signed-off-by: Håkon Bugge Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260129175237.727059-2-haakon.bugge@oracle.com Signed-off-by: Sasha Levin commit da289440f04c93048d82d293b180f1cacdfee2d9 Author: Aaradhana Sahu Date: Tue Jan 27 09:04:00 2026 +0530 wifi: ath12k: clear stale link mapping of ahvif->links_map [ Upstream commit 2c1ba9c2adf0fda96eaaebd8799268a7506a8fc9 ] When an arvif is initialized in non-AP STA mode but MLO connection preparation fails before the arvif is created (arvif->is_created remains false), the error path attempts to delete all links. However, link deletion only executes when arvif->is_created is true. As a result, ahvif retains a stale entry of arvif that is initialized but not created. When a new arvif is initialized with the same link id, this stale mapping triggers the following WARN_ON. WARNING: drivers/net/wireless/ath/ath12k/mac.c:4271 at ath12k_mac_op_change_vif_links+0x140/0x180 [ath12k], CPU#3: wpa_supplicant/275 Call trace: ath12k_mac_op_change_vif_links+0x140/0x180 [ath12k] (P) drv_change_vif_links+0xbc/0x1a4 [mac80211] ieee80211_vif_update_links+0x54c/0x6a0 [mac80211] ieee80211_vif_set_links+0x40/0x70 [mac80211] ieee80211_prep_connection+0x84/0x450 [mac80211] ieee80211_mgd_auth+0x200/0x480 [mac80211] ieee80211_auth+0x14/0x20 [mac80211] cfg80211_mlme_auth+0x90/0xf0 [cfg80211] nl80211_authenticate+0x32c/0x380 [cfg80211] genl_family_rcv_msg_doit+0xc8/0x134 Fix this issue by unassigning the link vif and clearing ahvif->links_map if arvif is only initialized but not created. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Fixes: 81e4be30544e ("wifi: ath12k: handle link removal in change_vif_links()") Signed-off-by: Aaradhana Sahu Reviewed-by: Vasanthakumar Thiagarajan Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260127033400.1721220-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 474e93f4a5aa5e990aeaeaf1cc2bcdd6a3997b88 Author: Aaradhana Sahu Date: Fri Jan 23 12:42:51 2026 +0530 wifi: ath12k: Fix index decrement when array_len is zero [ Upstream commit e4763898bb1325dbb3792961b6d607b5c6452d64 ] Currently, print_array_to_buf_index() decrements index unconditionally. This may lead to invalid buffer access when array_len is zero. Fix this by decrementing index only when array_len is non-zero. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: adf6df963c03 ("wifi: ath12k: Add support to parse requested stats_type") Signed-off-by: Aaradhana Sahu Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260123071253.2202644-2-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 0e0ca8dbfef901babb8c9c52ba114a9fda87e7e6 Author: Miaoqing Pan Date: Wed Jan 21 17:50:54 2026 +0800 wifi: ath11k: add usecase firmware handling based on device compatible [ Upstream commit c386a2b1068910538e87ef1cf2fc938ebf7e218f ] For M.2 WLAN chips, there is no suitable DTS node to specify the firmware-name property. In addition, assigning firmware for the M.2 PCIe interface causes chips that do not use usecase specific firmware to fail. Therefore, abandoning the approach of specifying firmware in DTS. As an alternative, propose a static lookup table mapping device compatible to firmware names. Currently, only WCN6855 HW2.1 requires this. However, support for the firmware-name property is retained to keep the ABI backwards compatible. For details on usecase specific firmware, see: https://lore.kernel.org/all/20250522013444.1301330-3-miaoqing.pan@oss.qualcomm.com/. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Fixes: edbbc647c4f3 ("wifi: ath11k: support usercase-specific firmware overrides") Signed-off-by: Miaoqing Pan Reviewed-by: Vasanthakumar Thiagarajan Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260121095055.3683957-2-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 134bd7f7e42f856b5cf99bc51d5391b14243b630 Author: Ziyi Guo Date: Fri Jan 23 04:58:22 2026 +0000 wifi: ath10k: sdio: add missing lock protection in ath10k_sdio_fw_crashed_dump() [ Upstream commit e55ac348089e579fc224569c7bd90340bf2439f9 ] ath10k_sdio_fw_crashed_dump() calls ath10k_coredump_new() which requires ar->dump_mutex to be held, as indicated by lockdep_assert_held() in that function. However, the SDIO implementation does not acquire this lock, unlike the PCI and SNOC implementations which properly hold the mutex. Additionally, ar->stats.fw_crash_counter is documented as protected by ar->data_lock in core.h, but the SDIO implementation modifies it without holding this spinlock. Add the missing mutex_lock()/mutex_unlock() around the coredump operations, and add spin_lock_bh()/spin_unlock_bh() around the fw_crash_counter increment, following the pattern used in ath10k_pci_fw_dump_work() and ath10k_snoc_fw_crashed_dump(). Fixes: 3c45f21af84e ("ath10k: sdio: add firmware coredump support") Signed-off-by: Ziyi Guo Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260123045822.2221549-1-n7l8m4@u.northwestern.edu Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 8fb1dc29637806a4ff4daba69ba170ebb53e5f99 Author: Sergey Shtylyov Date: Tue Jan 27 23:39:42 2026 +0300 PCI: Check parent for NULL in of_pci_bus_release_domain_nr() [ Upstream commit f7245901de8978d829f80b3d8e36ed9a8fd18049 ] of_pci_bus_find_domain_nr() allows its parent parameter to be NULL but of_pci_bus_release_domain_nr() (that undoes its effect) doesn't -- that means it's going to blow up while calling of_get_pci_domain_nr() if the parent parameter indeed happens to be NULL. Add the missing NULL check. Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: c14f7ccc9f5d ("PCI: Assign PCI domain IDs by ida_alloc()") Signed-off-by: Sergey Shtylyov Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260127203944.28588-1-s.shtylyov@auroraos.dev Signed-off-by: Sasha Levin commit adc2deacdd8198689c89c9b7f20a6e17806b3243 Author: Eric Dumazet Date: Tue Jan 27 12:38:27 2026 +0000 tcp: tcp_tx_timestamp() must look at the rtx queue [ Upstream commit 838eb9687691d29915797a885b861fd09353386e ] tcp_tx_timestamp() is only called at the end of tcp_sendmsg_locked() before the final tcp_push(). By the time it is called, it is possible all the copied data has been sent already (transmit queue is empty). If this is the case, use the last skb in the rtx queue. Fixes: 75c119afe14f ("tcp: implement rb-tree based retransmit queue") Signed-off-by: Eric Dumazet Reviewed-by: Jason Xing Link: https://patch.msgid.link/20260127123828.4098577-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2a9370693b1ceed745edd831a691d6faa7aeb2dd Author: Ilpo Järvinen Date: Fri Dec 19 19:40:18 2025 +0200 PCI: Remove old_size limit from bridge window sizing [ Upstream commit f909e3ee3ed1a44202f09ac7e637a0f9ec372225 ] calculate_memsize() applies lower bound to the resource size before aligning the resource size making it impossible to shrink bridge window resources. I've not found any justification for this lower bound and nothing indicated it was to work around some HW issue. Prior to the commit 3baeae36039a ("PCI: Use pci_release_resource() instead of release_resource()"), releasing a bridge window during BAR resize resulted in clearing start and end address of the resource. Clearing addresses destroys the resource size as a side-effect, therefore nullifying the effect of the old size lower bound. After the commit 3baeae36039a ("PCI: Use pci_release_resource() instead of release_resource()"), BAR resize uses the aligned old size, which results in exceeding what fits into the parent window in some cases: xe 0030:03:00.0: [drm] Attempting to resize bar from 256MiB -> 16384MiB xe 0030:03:00.0: BAR 0 [mem 0x620c000000000-0x620c000ffffff 64bit]: releasing xe 0030:03:00.0: BAR 2 [mem 0x6200000000000-0x620000fffffff 64bit pref]: releasing pci 0030:02:01.0: bridge window [mem 0x6200000000000-0x620001fffffff 64bit pref]: releasing pci 0030:01:00.0: bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref]: releasing pci 0030:00:00.0: bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref]: was not released (still contains assigned resources) pci 0030:00:00.0: Assigned bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref] to [bus 01-04] free space at [mem 0x6200400000000-0x62007ffffffff 64bit pref] pci 0030:00:00.0: Assigned bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref] to [bus 01-04] cannot fit 0x4000000000 required for 0030:01:00.0 bridging to [bus 02-04] The old size of 0x6200000000000-0x6203fbff0ffff resource was used as the lower bound which results in 0x4000000000 size request due to alignment. That exceeds what can fit into the parent window. Since the lower bound never even was enforced fully because the resource addresses were cleared when the bridge window is released, remove the old_size lower bound entirely and trust the calculated bridge window size is enough. This same problem may occur on io window side but seems less likely to cause issues due to general difference in alignment. Removing the lower bound may have other unforeseen consequences in case of io window so it's better to leave it as -next material if no problem is reported related to io window sizing (BAR resize shouldn't touch io windows anyway). Fixes: 3baeae36039a ("PCI: Use pci_release_resource() instead of release_resource()") Reported-by: Simon Richter Link: https://lore.kernel.org/r/f9a8c975-f5d3-4dd2-988e-4371a1433a60@hogyros.de/ Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251219174036.16738-6-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit b855d994862190772dc09d47a1a12e82f3ad3a9e Author: Ilpo Järvinen Date: Fri Dec 19 19:40:16 2025 +0200 PCI: Stop over-estimating bridge window size [ Upstream commit 3958bf16e2fe1b1c95467e58694102122c951a31 ] New way to calculate the bridge window head alignment produces tight-fit, that is, it does not leave any gaps between the resources. Similarly, relaxed tail alignment does not leave extra tail room. Start to use bridge window calculation that does not over-estimate the size of the required window. pbus_upstream_space_available() can be removed. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Malte Schröder Link: https://patch.msgid.link/20251219174036.16738-4-ilpo.jarvinen@linux.intel.com Stable-dep-of: f909e3ee3ed1 ("PCI: Remove old_size limit from bridge window sizing") Signed-off-by: Sasha Levin commit d5de3e34dcb5a2de5e8947b303be0a560cbdb770 Author: Ilpo Järvinen Date: Fri Dec 19 19:40:15 2025 +0200 PCI: Rewrite bridge window head alignment function [ Upstream commit bc75c8e5071120e919beb39e69f0979cccfdf219 ] The calculation of bridge window head alignment is done by calculate_mem_align() [*]. With the default bridge window alignment, it is used for both head and tail alignment. The selected head alignment does not always result in tight-fitting resources (gap at d4f00000-d4ffffff): d4800000-dbffffff : PCI Bus 0000:06 d4800000-d48fffff : PCI Bus 0000:07 d4800000-d4803fff : 0000:07:00.0 d4800000-d4803fff : nvme d4900000-d49fffff : PCI Bus 0000:0a d4900000-d490ffff : 0000:0a:00.0 d4900000-d490ffff : r8169 d4910000-d4913fff : 0000:0a:00.0 d4a00000-d4cfffff : PCI Bus 0000:0b d4a00000-d4bfffff : 0000:0b:00.0 d4a00000-d4bfffff : 0000:0b:00.0 d4c00000-d4c07fff : 0000:0b:00.0 d4d00000-d4dfffff : PCI Bus 0000:15 d4d00000-d4d07fff : 0000:15:00.0 d4d00000-d4d07fff : xhci-hcd d4e00000-d4efffff : PCI Bus 0000:16 d4e00000-d4e7ffff : 0000:16:00.0 d4e80000-d4e803ff : 0000:16:00.0 d4e80000-d4e803ff : ahci d5000000-dbffffff : PCI Bus 0000:0c This has not caused problems (for years) with the default bridge window tail alignment that grossly over-estimates the required tail alignment leaving more tail room than necessary. With the introduction of relaxed tail alignment that leaves no extra tail room whatsoever, any gaps will immediately turn into assignment failures. Introduce head alignment calculation that ensures no gaps are left and apply the new approach when using relaxed alignment. We may want to consider using it for the normal alignment eventually, but as the first step, solve only the problem with the relaxed tail alignment. ([*] I don't understand the algorithm in calculate_mem_align().) Link: https://git.kernel.org/history/history/c/5d0a8965aea9 ("[PATCH] 2.5.14: New PCI allocation code (alpha, arm, parisc) [2/2]") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220775 Reported-by: Malte Schröder Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Malte Schröder Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251219174036.16738-3-ilpo.jarvinen@linux.intel.com Stable-dep-of: f909e3ee3ed1 ("PCI: Remove old_size limit from bridge window sizing") Signed-off-by: Sasha Levin commit 17866f8a0822d414cb02e621cf003a7d04396ef8 Author: Zhiyu Zhang Date: Thu Jan 1 19:11:48 2026 +0800 fat: avoid parent link count underflow in rmdir [ Upstream commit 8cafcb881364af5ef3a8b9fed4db254054033d8a ] Corrupted FAT images can leave a directory inode with an incorrect i_nlink (e.g. 2 even though subdirectories exist). rmdir then unconditionally calls drop_nlink(dir) and can drive i_nlink to 0, triggering the WARN_ON in drop_nlink(). Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error. Link: https://lkml.kernel.org/r/20260101111148.1437-1-zhiyuzhang999@gmail.com Fixes: 9a53c3a783c2 ("[PATCH] r/o bind mounts: unlink: monitor i_nlink") Signed-off-by: Zhiyu Zhang Reported-by: Zhiyu Zhang Closes: https://lore.kernel.org/linux-fsdevel/aVN06OKsKxZe6-Kv@casper.infradead.org/T/#t Tested-by: Zhiyu Zhang Acked-by: OGAWA Hirofumi Cc: Al Viro Cc: Christian Brauner Cc: Jan Kara Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit a77e945c528f012ac593e25ef320c45502ee7316 Author: Alice Ryhl Date: Wed Jan 7 08:28:46 2026 +0000 rust: task: restrict Task::group_leader() to current [ Upstream commit 105ddfb2d2b3acec7a7d9695463df48733d91e6c ] The Task::group_leader() method currently allows you to access the group_leader() of any task, for example one you hold a refcount to. But this is not safe in general since the group leader could change when a task exits. See for example commit a15f37a40145c ("kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths"). All existing users of Task::group_leader() call this method on current, which is guaranteed running, so there's not an actual issue in Rust code today. But to prevent code in the future from making this mistake, restrict Task::group_leader() so that it can only be called on current. There are some other cases where accessing task->group_leader is okay. For example it can be safe if you hold tasklist_lock or rcu_read_lock(). However, only supporting current->group_leader is sufficient for all in-tree Rust users of group_leader right now. Safe Rust functionality for accessing it under rcu or while holding tasklist_lock may be added in the future if required by any future Rust module. This patch is a bugfix in that it prevents users of this API from writing incorrect code. It doesn't change behavior of correct code. Link: https://lkml.kernel.org/r/20260107-task-group-leader-v2-1-8fbf816f2a2f@google.com Signed-off-by: Alice Ryhl Fixes: 313c4281bc9d ("rust: add basic `Task`") Reported-by: Oleg Nesterov Closes: https://lore.kernel.org/all/aTLnV-5jlgfk1aRK@redhat.com/ Reviewed-by: Boqun Feng Reviewed-by: Gary Guo Cc: Andreas Hindborg Cc: Benno Lossin Cc: "Björn Roy Baron" Cc: Björn Roy Baron Cc: Christian Brauner Cc: Danilo Krummrich Cc: FUJITA Tomonori Cc: Miguel Ojeda Cc: Panagiotis Foliadis Cc: Shankari Anand Cc: Trevor Gross Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit bd1d06eaad53d576bee297f361645b1f4ca7e92c Author: Chaitanya Mishra Date: Sat Dec 27 14:52:29 2025 +0530 lib/kstrtox: fix kstrtobool() docstring to mention enabled/disabled [ Upstream commit 1921044eebf1d6861a6de1a76e3f63729a45e712 ] Commit ae5b3500856f ("kstrtox: add support for enabled and disabled in kstrtobool()") added support for 'e'/'E' (enabled) and 'd'/'D' (disabled) inputs, but did not update the docstring accordingly. Update the docstring to include 'Ee' (for true) and 'Dd' (for false) in the list of accepted first characters. Link: https://lkml.kernel.org/r/20251227092229.57330-1-chaitanyamishra.ai@gmail.com Fixes: ae5b3500856f ("kstrtox: add support for enabled and disabled in kstrtobool()") Signed-off-by: Chaitanya Mishra Cc: Mario Limonciello Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit d75ec4504a4340b033b15cad0303988b3089dd93 Author: Anthony Iliopoulos Date: Mon Dec 22 14:30:04 2025 -0500 nfsd: never defer requests during idmap lookup [ Upstream commit f9c206cdc4266caad6a9a7f46341420a10f03ccb ] During v4 request compound arg decoding, some ops (e.g. SETATTR) can trigger idmap lookup upcalls. When those upcall responses get delayed beyond the allowed time limit, cache_check() will mark the request for deferral and cause it to be dropped. This prevents nfs4svc_encode_compoundres from being executed, and thus the session slot flag NFSD4_SLOT_INUSE never gets cleared. Subsequent client requests will fail with NFSERR_JUKEBOX, given that the slot will be marked as in-use, making the SEQUENCE op fail. Fix this by making sure that the RQ_USEDEFERRAL flag is always clear during nfs4svc_decode_compoundargs(), since no v4 request should ever be deferred. Fixes: 2f425878b6a7 ("nfsd: don't use the deferral service, return NFS4ERR_DELAY") Signed-off-by: Anthony Iliopoulos Reviewed-by: NeilBrown Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit b29094276ab222ba7397c90ba0cedece7233c333 Author: Chuck Lever Date: Mon Dec 22 09:44:29 2025 -0500 xdrgen: Remove inclusion of nlm4.h header [ Upstream commit eb1f3b55ac6202a013daf14ed508066947cdafa8 ] The client-side source code template mistakenly includes the nlm4.h header file, which is specific to the NLM protocol and should not be present in the generic template that generates client stubs for all XDR-based protocols. Fixes: 903a7d37d9ea ("xdrgen: Update the files included in client-side source code") Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit b633683dc0d4c6b733108f017ffb81b8581f4035 Author: Chuck Lever Date: Sat Dec 20 10:41:09 2025 -0500 xdrgen: Initialize data pointer for zero-length items [ Upstream commit 27b0fcae8f535fb882b1876227a935dcfdf576aa ] The xdrgen decoders for strings and opaque data had an optimization that skipped calling xdr_inline_decode() when the item length was zero. This left the data pointer uninitialized, which could lead to unpredictable behavior when callers access it. Remove the zero-length check and always call xdr_inline_decode(). When passed a length of zero, xdr_inline_decode() returns the current buffer position, which is valid and matches the behavior of hand-coded XDR decoders throughout the kernel. Fixes: 4b132aacb076 ("tools: Add xdrgen") Reviewed-by: Jeff Layton Reviewed-by: NeilBrown Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 59d23891cdba5c8bd61b98309f1231caf7d2a41d Author: Chuck Lever Date: Tue Dec 9 19:28:50 2025 -0500 NFS: NFSERR_INVAL is not defined by NFSv2 [ Upstream commit 0ac903d1bfdce8ff40657c2b7d996947b72b6645 ] A documenting comment in include/uapi/linux/nfs.h claims incorrectly that NFSv2 defines NFSERR_INVAL. There is no such definition in either RFC 1094 or https://pubs.opengroup.org/onlinepubs/9629799/chap7.htm NFS3ERR_INVAL is introduced in RFC 1813. NFSD returns NFSERR_INVAL for PROC_GETACL, which has no specification (yet). However, nfsd_map_status() maps nfserr_symlink and nfserr_wrong_type to nfserr_inval, which does not align with RFC 1094. This logic was introduced only recently by commit 438f81e0e92a ("nfsd: move error choice for incorrect object types to version-specific code."). Given that we have no INVAL or SERVERFAULT status in NFSv2, probably the only choice is NFSERR_IO. Fixes: 438f81e0e92a ("nfsd: move error choice for incorrect object types to version-specific code.") Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 59409c5958b20ae07f59d5d1e8c48e5a389b99a8 Author: Chuck Lever Date: Mon Dec 8 11:15:32 2025 -0500 xdrgen: Fix struct prefix for typedef types in program wrappers [ Upstream commit bf0fe9ad3d597d8e1378dc9953ca96dfc3addb2b ] The program templates for decoder/argument.j2 and encoder/result.j2 unconditionally add 'struct' prefix to all types. This is incorrect when an RPC protocol specification lists a typedef'd basic type or an enum as a procedure argument or result (e.g., NFSv2's fhandle or stat), resulting in compiler errors when building generated C code. Fixes: 4b132aacb076 ("tools: Add xdrgen") Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 1bd726fa8f5cf64568b4e49595e6c518eb64cd85 Author: Mikulas Patocka Date: Mon Jan 26 15:36:22 2026 +0100 dm: use bio_clone_blkg_association [ Upstream commit 2df8b310bcfe76827fd71092f58a2493ee6590b0 ] The origin bio carries blk-cgroup information which could be set from foreground(task_css(css) - wbc->wb->blkcg_css), so the blkcg won't control buffer io since commit ca522482e3eaf ("dm: pass NULL bdev to bio_alloc_clone"). The synchronous io is still under control by blkcg, because 'bio->bi_blkg' is set by io submitting task which has been added into 'cgroup.procs'. Fix it by using bio_clone_blkg_association when submitting a cloned bio. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220985 Fixes: ca522482e3eaf ("dm: pass NULL bdev to bio_alloc_clone") Reported-by: Zhihao Cheng Signed-off-by: Mikulas Patocka Tested-by: Zhihao Cheng Signed-off-by: Sasha Levin commit d2138abc8f0a7fce4101b7229b43b06811ed083d Author: Lu Baolu Date: Thu Jan 22 09:48:55 2026 +0800 iommu/vt-d: Clear Present bit before tearing down context entry [ Upstream commit c1e4f1dccbe9d7656d1c6872ebeadb5992d0aaa2 ] When tearing down a context entry, the current implementation zeros the entire 128-bit entry using multiple 64-bit writes. This creates a window where the hardware can fetch a "torn" entry — where some fields are already zeroed while the 'Present' bit is still set — leading to unpredictable behavior or spurious faults. While x86 provides strong write ordering, the compiler may reorder writes to the two 64-bit halves of the context entry. Even without compiler reordering, the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Align with the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake: 1. Clear only the 'Present' (P) bit of the context entry first to signal the transition of ownership from hardware to software. 2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU. 3. Perform the required cache and context-cache invalidation to ensure hardware no longer has cached references to the entry. 4. Fully zero out the entry only after the invalidation is complete. Also, add a dma_wmb() to context_set_present() to ensure the entry is fully initialized before the 'Present' bit becomes visible. Fixes: ba39592764ed2 ("Intel IOMMU: Intel IOMMU driver") Reported-by: Dmytro Maluka Closes: https://lore.kernel.org/all/aTG7gc7I5wExai3S@google.com/ Signed-off-by: Lu Baolu Reviewed-by: Dmytro Maluka Reviewed-by: Samiullah Khawaja Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260120061816.2132558-3-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 821807c167b7b48a41b95b6607c6b9f97600f7d9 Author: Lu Baolu Date: Thu Jan 22 09:48:54 2026 +0800 iommu/vt-d: Clear Present bit before tearing down PASID entry [ Upstream commit 75ed00055c059dedc47b5daaaa2f8a7a019138ff ] The Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64 bytes). When tearing down an entry, the current implementation zeros the entire 64-byte structure immediately using multiple 64-bit writes. Since the IOMMU hardware may fetch these 64 bytes using multiple internal transactions (e.g., four 128-bit bursts), updating or zeroing the entire entry while it is active (P=1) risks a "torn" read. If a hardware fetch occurs simultaneously with the CPU zeroing the entry, the hardware could observe an inconsistent state, leading to unpredictable behavior or spurious faults. Follow the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake: 1. Clear only the 'Present' (P) bit of the PASID entry. 2. Use a dma_wmb() to ensure the cleared bit is visible to hardware before proceeding. 3. Execute the required invalidation sequence (PASID cache, IOTLB, and Device-TLB flush) to ensure the hardware has released all cached references. 4. Only after the flushes are complete, zero out the remaining fields of the PASID entry. Also, add a dma_wmb() in pasid_set_present() to ensure that all other fields of the PASID entry are visible to the hardware before the Present bit is set. Fixes: 0bbeb01a4faf ("iommu/vt-d: Manage scalalble mode PASID tables") Signed-off-by: Lu Baolu Reviewed-by: Dmytro Maluka Reviewed-by: Samiullah Khawaja Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260120061816.2132558-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 36244dfd3853f7bf89d03b8e90d56b23ce7fbc16 Author: Dmytro Maluka Date: Thu Jan 22 09:48:52 2026 +0800 iommu/vt-d: Flush cache for PASID table before using it [ Upstream commit 22d169bdd2849fe6bd18c2643742e1c02be6451c ] When writing the address of a freshly allocated zero-initialized PASID table to a PASID directory entry, do that after the CPU cache flush for this PASID table, not before it, to avoid the time window when this PASID table may be already used by non-coherent IOMMU hardware while its contents in RAM is still some random old data, not zero-initialized. Fixes: 194b3348bdbb ("iommu/vt-d: Fix PASID directory pointer coherency") Signed-off-by: Dmytro Maluka Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20251221123508.37495-1-dmaluka@chromium.org Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 53336a811485ae3b5cf8b8610e00ed289a810624 Author: Zilin Guan Date: Fri Jan 16 13:08:34 2026 +0000 wifi: rtw89: debug: Fix memory leak in __print_txpwr_map() [ Upstream commit 6070a44051b1c35714fa130de7726cfe91ca5559 ] In __print_txpwr_map(), memory is allocated to bufp via vzalloc(). If max_valid_addr is 0, the function returns -EOPNOTSUPP immediately without freeing bufp, leading to a memory leak. Since the validation of max_valid_addr does not depend on the allocated memory, fix this by moving the vzalloc() call after the check. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 036042e15770 ("wifi: rtw89: debug: txpwr table supports Wi-Fi 7 chips") Suggested-by: Zong-Zhe Yang Signed-off-by: Zilin Guan Reviewed-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260116130834.1413924-1-zilin@seu.edu.cn Signed-off-by: Sasha Levin commit e53224783442874d80852c478a6ac7a2f2b2ca7e Author: Jörg Wedekind Date: Mon Jan 19 15:31:10 2026 +0100 PCI: Mark 3ware-9650SA Root Port Extended Tags as broken [ Upstream commit 959ac08a2c2811305be8c2779779e8b0932e5a99 ] Per PCIe r7.0, sec 2.2.6.2.1 and 7.5.3.4, a Requester may not use 8-bit Tags unless its Extended Tag Field Enable is set, but all Receivers/Completers must handle 8-bit Tags correctly regardless of their Extended Tag Field Enable. Some devices do not handle 8-bit Tags as Completers, so add a quirk for them. If we find such a device, we disable Extended Tags for the entire hierarchy to make peer-to-peer DMA possible. The 3ware 9650SA seems to have issues with handling 8-bit tags. Mark it as broken. This fixes PCI Parity Errors like : 3w-9xxx: scsi0: ERROR: (0x06:0x000C): PCI Parity Error: clearing. 3w-9xxx: scsi0: ERROR: (0x06:0x000D): PCI Abort: clearing. 3w-9xxx: scsi0: ERROR: (0x06:0x000E): Controller Queue Error: clearing. 3w-9xxx: scsi0: ERROR: (0x06:0x0010): Microcontroller Error: clearing. Fixes: 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=202425 Signed-off-by: Jörg Wedekind Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260119143114.21948-1-joerg@wedekind.de Signed-off-by: Sasha Levin commit feef0143ec5e98a48334316f0067a445199b310d Author: Petr Mladek Date: Fri Nov 28 14:59:19 2025 +0100 kallsyms/ftrace: set module buildid in ftrace_mod_address_lookup() [ Upstream commit e8a1e7eaa19d0b757b06a2f913e3eeb4b1c002c6 ] __sprint_symbol() might access an invalid pointer when kallsyms_lookup_buildid() returns a symbol found by ftrace_mod_address_lookup(). The ftrace lookup function must set both @modname and @modbuildid the same way as module_address_lookup(). Link: https://lkml.kernel.org/r/20251128135920.217303-7-pmladek@suse.com Fixes: 9294523e3768 ("module: add printk formats to add module build ID to stacktraces") Signed-off-by: Petr Mladek Reviewed-by: Aaron Tomlin Acked-by: Steven Rostedt (Google) Cc: Alexei Starovoitov Cc: Daniel Borkman Cc: Daniel Gomez Cc: John Fastabend Cc: Kees Cook Cc: Luis Chamberalin Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Petr Pavlu Cc: Sami Tolvanen Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 7f4827b247500f2d1e29c6e707651593f80d7bd8 Author: Petr Mladek Date: Fri Nov 28 14:59:16 2025 +0100 module: add helper function for reading module_buildid() [ Upstream commit acfdbb4ab2910ff6f03becb569c23ac7b2223913 ] Add a helper function for reading the optional "build_id" member of struct module. It is going to be used also in ftrace_mod_address_lookup(). Use "#ifdef" instead of "#if IS_ENABLED()" to match the declaration of the optional field in struct module. Link: https://lkml.kernel.org/r/20251128135920.217303-4-pmladek@suse.com Signed-off-by: Petr Mladek Reviewed-by: Daniel Gomez Reviewed-by: Petr Pavlu Cc: Aaron Tomlin Cc: Alexei Starovoitov Cc: Daniel Borkman Cc: John Fastabend Cc: Kees Cook Cc: Luis Chamberalin Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Sami Tolvanen Cc: Steven Rostedt (Google) Signed-off-by: Andrew Morton Stable-dep-of: e8a1e7eaa19d ("kallsyms/ftrace: set module buildid in ftrace_mod_address_lookup()") Signed-off-by: Sasha Levin commit 34de49d09775a4c8d5a6e14ed9005c850f4934fe Author: Petr Mladek Date: Fri Nov 28 14:59:18 2025 +0100 kallsyms/bpf: rename __bpf_address_lookup() to bpf_address_lookup() [ Upstream commit cd6735896d0343942cf3dafb48ce32eb79341990 ] bpf_address_lookup() has been used only in kallsyms_lookup_buildid(). It was supposed to set @modname and @modbuildid when the symbol was in a module. But it always just cleared @modname because BPF symbols were never in a module. And it did not clear @modbuildid because the pointer was not passed. The wrapper is no longer needed. Both @modname and @modbuildid are now always initialized to NULL in kallsyms_lookup_buildid(). Remove the wrapper and rename __bpf_address_lookup() to bpf_address_lookup() because this variant is used everywhere. [akpm@linux-foundation.org: fix loongarch] Link: https://lkml.kernel.org/r/20251128135920.217303-6-pmladek@suse.com Fixes: 9294523e3768 ("module: add printk formats to add module build ID to stacktraces") Signed-off-by: Petr Mladek Acked-by: Alexei Starovoitov Cc: Aaron Tomlin Cc: Daniel Borkman Cc: Daniel Gomez Cc: John Fastabend Cc: Kees Cook Cc: Luis Chamberalin Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Petr Pavlu Cc: Sami Tolvanen Cc: Steven Rostedt (Google) Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 536ffc371b52ecd00f78658895e35e0775df9b81 Author: Fernando Fernandez Mancera Date: Mon Jan 19 21:35:46 2026 +0100 netfilter: nf_conncount: fix tracking of connections from localhost [ Upstream commit de8a70cefcb26cdceaafdc5ac144712681419c29 ] Since commit be102eb6a0e7 ("netfilter: nf_conncount: rework API to use sk_buff directly"), we skip the adding and trigger a GC when the ct is confirmed. For connections originated from local to local it doesn't work because the connection is confirmed on POSTROUTING, therefore tracking on the INPUT hook is always skipped. In order to fix this, we check whether skb input ifindex is set to loopback ifindex. If it is then we fallback on a GC plus track operation skipping the optimization. This fallback is necessary to avoid duplicated tracking of a packet train e.g 10 UDP datagrams sent on a burst when initiating the connection. Tested with xt_connlimit/nft_connlimit and OVS limit and with a HTTP server and iperf3 on UDP mode. Fixes: be102eb6a0e7 ("netfilter: nf_conncount: rework API to use sk_buff directly") Reported-by: Michal Slabihoudek Closes: https://lore.kernel.org/netfilter/6989BD9F-8C24-4397-9AD7-4613B28BF0DB@gooddata.com/ Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit a0cdcacc0d414c6cf536db389bf4aa33f8a36f6f Author: Florian Westphal Date: Fri Aug 19 16:16:07 2022 +0200 netfilter: nft_compat: add more restrictions on netlink attributes [ Upstream commit cda26c645946b08f070f20c166d4736767e4a805 ] As far as I can see nothing bad can happen when NFTA_TARGET/MATCH_NAME are too large because this calls x_tables helpers which check for the length, but it seems better to already reject it during netlink parsing. Rest of the changes avoid silent u8/u16 truncations. For _TYPE, its expected to be only 1 or 0. In x_tables world, this variable is set by kernel, for IPT_SO_GET_REVISION_TARGET its 1, for all others its set to 0. As older versions of nf_tables permitted any value except 1 to mean 'match', keep this as-is but sanitize the value for consistency. Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables") Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 6e5fa7add3e76da068a478d905be64be8fa4e80a Author: Fernando Fernandez Mancera Date: Wed Dec 17 15:46:41 2025 +0100 netfilter: nf_conncount: increase the connection clean up limit to 64 [ Upstream commit 21d033e472735ecec677f1ae46d6740b5e47a4f3 ] After the optimization to only perform one GC per jiffy, a new problem was introduced. If more than 8 new connections are tracked per jiffy the list won't be cleaned up fast enough possibly reaching the limit wrongly. In order to prevent this issue, only skip the GC if it was already triggered during the same jiffy and the increment is lower than the clean up limit. In addition, increase the clean up limit to 64 connections to avoid triggering GC too often and do more effective GCs. This has been tested using a HTTP server and several performance tools while having nft_connlimit/xt_connlimit or OVS limit configured. Output of slowhttptest + OVS limit at 52000 connections: slow HTTP test status on 340th second: initializing: 0 pending: 432 connected: 51998 error: 0 closed: 0 service available: YES Fixes: d265929930e2 ("netfilter: nf_conncount: reduce unnecessary GC") Reported-by: Aleksandra Rukomoinikova Closes: https://lore.kernel.org/netfilter/b2064e7b-0776-4e14-adb6-c68080987471@k2.cloud/ Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit ab455baa7420f8c416ec69b8d5ccda3fc9763994 Author: Fernando Fernandez Mancera Date: Fri Nov 21 01:14:31 2025 +0100 netfilter: nf_conncount: make nf_conncount_gc_list() to disable BH [ Upstream commit c0362b5748282e22fa1592a8d3474f726ad964c2 ] For convenience when performing GC over the connection list, make nf_conncount_gc_list() to disable BH. This unifies the behavior with nf_conncount_add() and nf_conncount_count(). Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 21d033e47273 ("netfilter: nf_conncount: increase the connection clean up limit to 64") Signed-off-by: Sasha Levin commit 0d7ccd3d16ad0f352b56b32d88167afceeeebb59 Author: Florian Westphal Date: Fri Nov 28 12:26:54 2025 +0100 netfilter: nf_tables: reset table validation state on abort [ Upstream commit 6f93616a7323d646d18db9c09f147e453b40fdd7 ] If a transaction fails the final validation in the commit hook, the table validation state is changed to NFT_VALIDATE_DO and a replay of the batch is performed. Every rule insert will then do a graph validation. This is much slower, but provides better error reporting to the user because we can point at the rule that introduces the validation issue. Without this reset the affected table(s) remain in full validation mode, i.e. on next transaction we start with slow-mode. This makes the next transaction after a failed incremental update very slow: # time iptables-restore < /tmp/ruleset real 0m0.496s [..] # time iptables -A CALLEE -j CALLER iptables v1.8.11 (nf_tables): RULE_APPEND failed (Too many links): rule in chain CALLEE real 0m0.022s [..] # time iptables-restore < /tmp/ruleset real 1m22.355s [..] After this patch, 2nd iptables-restore is back to ~0.5s. Fixes: 9a32e9850686 ("netfilter: nf_tables: don't write table validation state without mutex") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit f1f9aea3729765e456ebdede35170ab906e52d44 Author: Li Chen Date: Tue Jan 6 20:06:21 2026 +0800 ext4: fast commit: make s_fc_lock reclaim-safe [ Upstream commit 491f2927ae097e2d405afe0b3fe841931ab8aad2 ] s_fc_lock can be acquired from inode eviction and thus is reclaim unsafe. Since the fast commit path holds s_fc_lock while writing the commit log, allocations under the lock can enter reclaim and invert the lock order with fs_reclaim. Add ext4_fc_lock()/ext4_fc_unlock() helpers which acquire s_fc_lock under memalloc_nofs_save()/restore() context and use them everywhere so allocations under the lock cannot recurse into filesystem reclaim. Fixes: 6593714d67ba ("ext4: hold s_fc_lock while during fast commit") Signed-off-by: Li Chen Reviewed-by: Baokun Li Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260106120621.440126-1-me@linux.beauty Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 59f10fa502ee7859d3c9b3b31ddf40ccde99810f Author: Miri Korenblit Date: Wed Jan 7 14:04:51 2026 +0200 wifi: cfg80211: stop NAN and P2P in cfg80211_leave [ Upstream commit e1696c8bd0056bc1a5f7766f58ac333adc203e8a ] Seems that there is an assumption that this function should be called only for netdev interfaces, but it can also be called in suspend, or from nl80211_netlink_notify (indirectly). Note that the documentation of NL80211_ATTR_SOCKET_OWNER explicitly says that NAN interfaces would be destroyed as well in the nl80211_netlink_notify case. Fix this by also stopping P2P and NAN. Fixes: cb3b7d87652a ("cfg80211: add start / stop NAN commands") Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260107140430.dab142cbef0b.I290cc47836d56dd7e35012ce06bec36c6da688cd@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6ff2ebfef75fbc57d937d8fbe738b967edf2d331 Author: Matt Johnston Date: Tue Jan 13 17:01:16 2026 +0800 mctp i2c: initialise event handler read bytes [ Upstream commit 2a14e91b6d76639dac70ea170f4384c1ee3cb48d ] Set a 0xff value for i2c reads of an mctp-i2c device. Otherwise reads will return "val" from the i2c bus driver. For i2c-aspeed and i2c-npcm7xx that is a stack uninitialised u8. Tested with "i2ctransfer -y 1 r10@0x34" where 0x34 is a mctp-i2c instance, now it returns all 0xff. Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver") Signed-off-by: Matt Johnston Link: https://patch.msgid.link/20260113-mctp-read-fix-v1-1-70c4b59c741c@codeconstruct.com.au Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c1116859a7f462233b500bb95e0c85fd6210b08a Author: Jian Zhang Date: Thu Jan 8 18:18:29 2026 +0800 net: mctp-i2c: fix duplicate reception of old data [ Upstream commit ae4744e173fadd092c43eda4ca92dcb74645225a ] The MCTP I2C slave callback did not handle I2C_SLAVE_READ_REQUESTED events. As a result, i2c read event will trigger repeated reception of old data, reset rx_pos when a read request is received. Signed-off-by: Jian Zhang Link: https://patch.msgid.link/20260108101829.1140448-1-zhangjian.3032@bytedance.com Signed-off-by: Jakub Kicinski Stable-dep-of: 2a14e91b6d76 ("mctp i2c: initialise event handler read bytes") Signed-off-by: Sasha Levin commit 02bb1500f1479750e6557c8044f6a2d7e9d30c12 Author: Abhishek Bapat Date: Thu Jan 15 21:31:03 2026 +0000 quota: fix livelock between quotactl and freeze_super [ Upstream commit 77449e453dfc006ad738dec55374c4cbc056fd39 ] When a filesystem is frozen, quotactl_block() enters a retry loop waiting for the filesystem to thaw. It acquires s_umount, checks the freeze state, drops s_umount and uses sb_start_write() - sb_end_write() pair to wait for the unfreeze. However, this retry loop can trigger a livelock issue, specifically on kernels with preemption disabled. The mechanism is as follows: 1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write(). 2. sb_wait_write() calls percpu_down_write(), which initiates synchronize_rcu(). 3. Simultaneously, quotactl_block() spins in its retry loop, immediately executing the sb_start_write() - sb_end_write() pair. 4. Because the kernel is non-preemptible and the loop contains no scheduling points, quotactl_block() never yields the CPU. This prevents that CPU from reaching an RCU quiescent state. 5. synchronize_rcu() in the freezer thread waits indefinitely for the quotactl_block() CPU to report a quiescent state. 6. quotactl_block() spins indefinitely waiting for the freezer to advance, which it cannot do as it is blocked on the RCU sync. This results in a hang of the freezer process and 100% CPU usage by the quota process. While this can occur intermittently on multi-core systems, it is reliably reproducing on a node with the following script, running both the freezer and the quota toggle on the same CPU: # mkfs.ext4 -O quota /dev/sda 2g && mkdir a_mount # mount /dev/sda -o quota,usrquota,grpquota a_mount # taskset -c 3 bash -c "while true; do xfs_freeze -f a_mount; \ xfs_freeze -u a_mount; done" & # taskset -c 3 bash -c "while true; do quotaon a_mount; \ quotaoff a_mount; done" & Adding cond_resched() to the retry loop fixes the issue. It acts as an RCU quiescent state, allowing synchronize_rcu() in percpu_down_write() to complete. Fixes: 576215cffdef ("fs: Drop wait_unfrozen wait queue") Signed-off-by: Abhishek Bapat Link: https://patch.msgid.link/20260115213103.1089129-1-abhishekbapat@google.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 7379837c3f9efa576dc2d716ebfaa3a113b3112f Author: Baochen Qiang Date: Mon Nov 3 10:44:49 2025 +0800 wifi: ath12k: do WoW offloads only on primary link [ Upstream commit e62102ac9b773bdb08475aa9ca24dea61ae98708 ] In case of multi-link connection, WCN7850 firmware crashes due to WoW offloads enabled on both primary and secondary links. Change to do it only on primary link to fix it. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Fixes: 32f7b19668bd ("wifi: ath12k: support MLO as well if single_chip_mlo_support flag is set") Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20251103-ath12-primary-link-wow-v1-1-3cf523dc09f0@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5a0b892ac90d03038f0463d938992a47c7dfacd2 Author: Rosen Penev Date: Fri Aug 1 17:04:32 2025 -0700 wifi: ath9k: add OF dependency to AHB [ Upstream commit 125e7b31f041cc0a4ede1e42bef69915f0a63a35 ] The conversion to OF missed adding a Kconfig dependency. Fixes: 2fa490c0d759 ("wifi: ath9k: ahb: replace id_table with of") Signed-off-by: Rosen Penev Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20250802000432.3079550-1-rosenp@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit a44220e4eba357f62a3a95ac7c22eadd77568e1c Author: Alistair Popple Date: Mon Jan 12 11:54:40 2026 +1100 PCI/P2PDMA: Reset page reference count when page mapping fails [ Upstream commit 83014d82a1100abc89f7712ad67c3e5accaddc43 ] When mapping a p2pdma page the page reference count is initialised to 1 prior to calling vm_insert_page(). This is to avoid vm_insert_page() warning if the page refcount is zero. Prior to setting the page count there is a check to ensure the page is currently free (ie. has a zero reference count). However vm_insert_page() can fail. In this case the pages are freed back to the genalloc pool, but that does not reset the page refcount. So a future allocation of the same page will see the elevated page refcount from the previous set_page_count() call triggering the VM_WARN_ON_ONCE_PAGE checking that the page is free. Fix this by resetting the page refcount to zero using set_page_count(). Note that put_page() is not used because that would result in freeing the page twice due to implicitly calling p2pdma_folio_free(). Fixes: b7e282378773 ("mm/mm_init: move p2pdma page refcount initialisation to p2pdma") Signed-off-by: Alistair Popple Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Acked-by: Balbir Singh Link: https://patch.msgid.link/20260112005440.998543-1-apopple@nvidia.com Signed-off-by: Sasha Levin commit 5b1f6531d4a12ecdfae5f73fab3fef1b6dbda1c4 Author: Aadityarangan Shridhar Iyengar Date: Sun Jan 11 22:06:50 2026 +0530 PCI/PTM: Fix pcie_ptm_create_debugfs() memory leak [ Upstream commit 62171369cf17794ddd88f602c2c84d008ecafcff ] In pcie_ptm_create_debugfs(), if devm_kasprintf() fails after successfully allocating ptm_debugfs with kzalloc(), the function returns without freeing the allocated memory, resulting in a memory leak. Free ptm_debugfs before returning in the devm_kasprintf() error path and in pcie_ptm_destroy_debugfs(). Fixes: 132833405e61 ("PCI: Add debugfs support for exposing PTM context") Signed-off-by: Aadityarangan Shridhar Iyengar [bhelgaas: squash additional fix from Mani: https://lore.kernel.org/r/pdp4xc4d5ee3e547mmdro5riui3mclduqdl7j6iclfbozo2a4c@7m3qdm6yrhuv] Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260111163650.33168-1-adiyenga@cisco.com Signed-off-by: Sasha Levin commit aeddfb00bb83c50a8bdfa5139f8c2c87e8d85049 Author: Mikulas Patocka Date: Thu Jan 8 20:56:20 2026 +0100 dm: use READ_ONCE in dm_blk_report_zones [ Upstream commit e9f5a55b70ae6187ab64ef2d1232ae2738e31d1f ] The functon dm_blk_report_zones reads md->zone_revalidate_map, however it may change while the function is running. Use READ_ONCE. Signed-off-by: Mikulas Patocka Fixes: 37f53a2c60d0 ("dm: fix dm_blk_report_zones") Reviewed-by: Benjamin Marzinski Signed-off-by: Sasha Levin commit 7a3385e97af2b6f485fef11e82d8c29adee4be93 Author: Mikulas Patocka Date: Thu Jan 8 20:55:08 2026 +0100 dm: fix unlocked test for dm_suspended_md [ Upstream commit 24c405fdbe215c45e57bba672cc42859038491ee ] The function dm_blk_report_zones tests if the device is suspended with the "dm_suspended_md" call. However, this function is called without holding any locks, so the device may be suspended just after it. Move the call to dm_suspended_md after dm_get_live_table, so that the device can't be suspended after the suspended state was tested. Signed-off-by: Mikulas Patocka Fixes: 37f53a2c60d0 ("dm: fix dm_blk_report_zones") Reviewed-by: Benjamin Marzinski Signed-off-by: Sasha Levin commit 5d0a2a2ce94b5af78e8b9bbb41a1ac67d04379c4 Author: Uwe Kleine-König Date: Tue Dec 2 16:13:49 2025 +0100 PCI/portdrv: Fix potential resource leak [ Upstream commit 01464a3fdf91c041a381d93a1b6fefbdb819a46f ] pcie_port_probe_service() unconditionally calls get_device() (unless it fails). So drop that reference also unconditionally as it's fine for a PCIe driver to not have a remove callback. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Uwe Kleine-König Signed-off-by: Bjorn Helgaas Reviewed-by: Ilpo Järvinen Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/e1c68c3b3f1af8427e98ca5e2c79f8bf0ebe2ce4.1764688034.git.u.kleine-koenig@baylibre.com Signed-off-by: Sasha Levin commit 1af76378577e030fe5fb26000da4442161d907f8 Author: Inochi Amaoto Date: Fri Jan 9 12:07:53 2026 +0800 PCI: sophgo: Disable L0s and L1 on Sophgo 2044 PCIe Root Ports [ Upstream commit 613f3255a35a95f52575dd8c60b7ac9d711639ce ] Sophgo 2044 Root Ports advertise L0 and L1 capabilities without supporting them. Since commit f3ac2ff14834 ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms") force enabled ASPM on all device tree platforms, the issue became evident and the SG2044 Root Port started breaking. Hence, disable the L0s and L1 capabilities in the LINKCAP register for the SG2044 Root Ports, so that these states won't get enabled. Fixes: 467d9c0348d6 ("PCI: dwc: Add Sophgo SG2044 PCIe controller driver in Root Complex mode") Signed-off-by: Inochi Amaoto [mani: reworded description and corrected fixes tag] Signed-off-by: Manivannan Sadhasivam Tested-by: Han Gao Link: https://patch.msgid.link/20260109040756.731169-1-inochiama@gmail.com Signed-off-by: Sasha Levin commit ef42c53b7a2848ca15e46b134a332a06ae00a511 Author: Håkon Bugge Date: Wed Nov 12 10:54:40 2025 +0100 PCI: Do not attempt to set ExtTag for VFs [ Upstream commit 73711730a1128d91ebca1a6994ceeb18f36cb0cd ] The bit for enabling extended tags is Reserved and Preserved (RsvdP) for VFs, according to PCIe r7.0 section 7.5.3.4 table 7.21. Hence, bail out early from pci_configure_extended_tags() if the device is a VF. Otherwise, we may see incorrect log messages such as: kernel: pci 0000:af:00.2: enabling Extended Tags (af:00.2 is a VF) Fixes: 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported") Signed-off-by: Håkon Bugge Signed-off-by: Bjorn Helgaas Reviewed-by: Zhu Yanjun Link: https://patch.msgid.link/20251112095442.1913258-1-haakon.bugge@oracle.com Signed-off-by: Sasha Levin commit 1938bf90c1dd01b8a9979d4262ba0173b86a50bc Author: Shuai Xue Date: Wed Dec 10 21:29:07 2025 +0800 Documentation: tracing: Add PCI tracepoint documentation [ Upstream commit 8236fc613d44e59f6736d6c3e9efffaf26ab7f00 ] The PCI tracing system provides tracepoints to monitor critical hardware events that can impact system performance and reliability. Add documentation about it. Signed-off-by: Shuai Xue [bhelgaas: squash fixes: https://lore.kernel.org/r/20260108013956.14351-2-bagasdotme@gmail.com https://lore.kernel.org/r/20260108013956.14351-3-bagasdotme@gmail.com] Signed-off-by: Bjorn Helgaas Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/20251210132907.58799-4-xueshuai@linux.alibaba.com Signed-off-by: Sasha Levin commit eb9aa9f8010465d927864f5a35bdc5604b0ff51a Author: Hou Tao Date: Sat Dec 20 12:04:35 2025 +0800 PCI/P2PDMA: Fix p2pmem_alloc_mmap() warning condition [ Upstream commit cb500023a75246f60b79af9f7321d6e75330c5b5 ] Commit b7e282378773 has already changed the initial page refcount of p2pdma page from one to zero, however, in p2pmem_alloc_mmap() it uses "VM_WARN_ON_ONCE_PAGE(!page_ref_count(page))" to assert the initial page refcount should not be zero and the following will be reported when CONFIG_DEBUG_VM is enabled: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x380400000 flags: 0x20000000002000(reserved|node=0|zone=4) raw: 0020000000002000 ff1100015e3ab440 0000000000000000 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: VM_WARN_ON_ONCE_PAGE(!page_ref_count(page)) ------------[ cut here ]------------ WARNING: CPU: 5 PID: 449 at drivers/pci/p2pdma.c:240 p2pmem_alloc_mmap+0x83a/0xa60 Fix by using "page_ref_count(page)" as the assertion condition. Fixes: b7e282378773 ("mm/mm_init: move p2pdma page refcount initialisation to p2pdma") Signed-off-by: Hou Tao Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Reviewed-by: Alistair Popple Link: https://patch.msgid.link/20251220040446.274991-3-houtao@huaweicloud.com Signed-off-by: Sasha Levin commit e19cce88ec4c4877f4ff2469099b9cf23cc3e93e Author: Hou Tao Date: Sat Dec 20 12:04:34 2025 +0800 PCI/P2PDMA: Release per-CPU pgmap ref when vm_insert_page() fails [ Upstream commit 6220694c52a5a04102b48109e4f24e958b559bd3 ] When vm_insert_page() fails in p2pmem_alloc_mmap(), p2pmem_alloc_mmap() doesn't invoke percpu_ref_put() to free the per-CPU ref of pgmap acquired after gen_pool_alloc_owner(), and memunmap_pages() will hang forever when trying to remove the PCI device. Fix it by adding the missed percpu_ref_put(). Fixes: 7e9c7ef83d78 ("PCI/P2PDMA: Allow userspace VMA allocations through sysfs") Signed-off-by: Hou Tao Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Reviewed-by: Alistair Popple Link: https://patch.msgid.link/20251220040446.274991-2-houtao@huaweicloud.com Signed-off-by: Sasha Levin commit 2108e783a7cf2410f2cb4399aaf0f8fd47baa11c Author: Huang Chenming Date: Tue Dec 9 08:27:33 2025 +0530 wifi: cfg80211: Fix use_for flag update on BSS refresh [ Upstream commit 4073ea516106e5f98ed0476f89cdede8baa98d37 ] Userspace may fail to connect to certain BSS that were initially marked as unusable due to regulatory restrictions (use_for = 0, e.g., 6 GHz power type mismatch). Even after these restrictions are removed and the BSS becomes usable, connection attempts still fail. The issue occurs in cfg80211_update_known_bss() where the use_for flag is updated using bitwise AND (&=) instead of direct assignment. Once a BSS is marked with use_for = 0, the AND operation masks out any subsequent non-zero values, permanently keeping the flag at 0. This causes __cfg80211_get_bss(), invoked by nl80211_assoc_bss(), to fail the check "(bss->pub.use_for & use_for) != use_for", thereby blocking association. Replace the bitwise AND operation with direct assignment so the use_for flag accurately reflects the current BSS state. Fixes: d02a12b8e4bb ("wifi: cfg80211: add BSS usage reporting") Signed-off-by: Huang Chenming Link: https://patch.msgid.link/20251209025733.2098456-1-chenming.huang@oss.qualcomm.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d072c2c82322e9734f22aa8d2562ac321eec90f4 Author: Brian Norris Date: Fri Oct 3 15:40:09 2025 -0700 PCI/PM: Avoid redundant delays on D3hot->D3cold [ Upstream commit 4d982084507d663df160546c4c48066a8887ed89 ] When transitioning to D3cold, __pci_set_power_state() first transitions to D3hot. If the device was already in D3hot, this adds excess work: (a) read/modify/write PMCSR; and (b) excess delay (pci_dev_d3_sleep()). For (b), we already performed the necessary delay on the previous D3hot entry; this was extra noticeable when evaluating runtime PM transition latency. Check whether we're already in the target state before continuing. Note that __pci_set_power_state() already does this same check for other state transitions, but D3cold is special because __pci_set_power_state() converts it to D3hot for the purposes of PMCSR. This seems to be an oversight in commit 0aacdc957401 ("PCI/PM: Clean up pci_set_low_power_state()"). Fixes: 0aacdc957401 ("PCI/PM: Clean up pci_set_low_power_state()") Signed-off-by: Brian Norris Signed-off-by: Brian Norris [bhelgaas: reverse test to match other "dev->current_state == state" cases] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251003154008.1.I7a21c240b30062c66471329567a96dceb6274358@changeid Signed-off-by: Sasha Levin commit ed0ef3d0c92d8acf737f5b9f1f0d18235039ca08 Author: Baruch Siach Date: Mon Nov 3 09:28:30 2025 +0200 Documentation: PCI: endpoint: Fix ntb/vntb copy & paste errors [ Upstream commit ad0c6da5be901f5c181490f683d22b416059bccb ] Fix copy & paste errors by changing the references from 'ntb' to 'vntb'. Fixes: 4ac8c8e52cd9 ("Documentation: PCI: Add specification for the PCI vNTB function device") Signed-off-by: Baruch Siach [mani: squashed the patches and fixed more errors] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/b51c2a69ffdbfa2c359f5cf33f3ad2acc3db87e4.1762154911.git.baruch@tkos.co.il Signed-off-by: Sasha Levin commit 004288f3b24ebb30cdfd8b379ff796829ac0bff1 Author: Haotian Zhang Date: Fri Dec 19 10:16:15 2025 +0800 PCI: xilinx: Fix INTx IRQ domain leak in error paths [ Upstream commit f42b3c053b1554d66af6fe45bb1ef357464c0456 ] In xilinx_pcie_init_irq_domain(), if xilinx_allocate_msi_domains() fails after pcie->leg_domain has been successfully created via irq_domain_create_linear(), the function returns directly without cleaning up the allocated IRQ domain, resulting in a resource leak. In xilinx_free_msi_domains(), pcie->leg_domain is also neglected. Add irq_domain_remove() call in the error path to properly release the IRQ domain before returning the error. Also rename xilinx_free_msi_domains() to xilinx_free_irq_domains() and add the release of pcie->leg_domain to it. Fixes: 313b64c3ae52 ("PCI: xilinx: Convert to MSI domains") Suggested-by: Manivannan Sadhasivam Signed-off-by: Haotian Zhang Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251219021615.965-1-vulab@iscas.ac.cn Signed-off-by: Sasha Levin commit 4e8e7080b5579ccfe779733cae5415a3aa6e3cf7 Author: Haotian Zhang Date: Wed Nov 19 10:33:08 2025 +0800 PCI: mediatek: Fix IRQ domain leak when MSI allocation fails [ Upstream commit 7f0cdcddf8bef1c8c18f9be6708073fd3790a20f ] In mtk_pcie_init_irq_domain(), if mtk_pcie_allocate_msi_domains() fails after port->irq_domain has been successfully created via irq_domain_create_linear(), the function returns directly without cleaning up the allocated IRQ domain, resulting in a resource leak. Add irq_domain_remove() call in the error path to properly release the INTx IRQ domain before returning the error. Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") Signed-off-by: Haotian Zhang Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251119023308.476-1-vulab@iscas.ac.cn Signed-off-by: Sasha Levin commit d1878562a41fda13e486aaf95dd2dac5d43633d4 Author: Carl Lee Date: Tue Feb 10 15:26:34 2026 +0800 hwmon: (pmbus/mpq8785) fix VOUT_MODE mismatch during identification [ Upstream commit 9e33c1dba22431bea9b2bf48adf56859e52fc7ec ] When MPQ8785 reports VOUT_MODE as VID mode, mpq8785_identify() configures the driver for direct mode. The subsequent pmbus_identify_common() check then fails due to a mismatch between the reported mode and the configured mode, causing device initialization to fail. Override the reported VOUT_MODE to direct mode to keep the driver configuration consistent with the reported mode and allow successful device initialization. This does not change how voltages are interpreted, but avoids a false identification failure caused by mismatched mode handling. Fixes: f20b4a931130c ("hwmon: Add driver for MPS MPQ8785 Synchronous Step-Down Converter") Signed-off-by: Carl Lee Link: https://lore.kernel.org/r/20260210-dt-bindings-hwmon-pmbus-mpq8785-add-mpq8786-support-v3-1-84636ccfe76f@amd.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 14a38784e09aebc21207dc32fffa05247fc3dd64 Author: Guenter Roeck Date: Sat Feb 7 08:12:25 2026 -0800 Revert "hwmon: (ibmpex) fix use-after-free in high/low store" [ Upstream commit 8bde3e395a85017f12af2b0ba5c3684f5af9c006 ] This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d. Jean Delvare points out that the patch does not completely fix the reported problem, that it in fact introduces a (new) race condition, and that it may actually not be needed in the first place. Various AI reviews agree. Specific and relevant AI feedback: " This reordering sets the driver data to NULL before removing the sensor attributes in the loop below. ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but does not check if it is NULL before dereferencing it to access data->sensors[]. If a userspace process reads a sensor file (like temp1_input) while this delete function is running, could it race with the dev_set_drvdata(..., NULL) call here and crash in ibmpex_show_sensor()? Would it be safer to keep the original order where device_remove_file() is called before clearing the driver data? device_remove_file() should wait for any active sysfs callbacks to complete, which might already prevent the use-after-free this patch intends to fix. " Revert the offending patch. If it can be shown that the originally reported alleged race condition does indeed exist, it can always be re-introduced with a complete fix. Reported-by: Jean Delvare Closes: https://lore.kernel.org/linux-hwmon/20260121095342.73e723cb@endymion/ Cc: Jean Delvare Cc: Junrui Luo Fixes: 6946c726c3f4 ("hwmon: (ibmpex) fix use-after-free in high/low store") Reviewed-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 98c6a053b6d38db889a669c8da9ee629cdb8bd38 Author: Francesco Lavra Date: Mon Feb 9 10:50:01 2026 +0100 spi: tools: Add include folder to .gitignore [ Upstream commit 5af56f30c4fcbade4a92f94dadfea517d1db9703 ] The Makefile for the SPI tools creates an include/linux/spi folder and some symlinks inside it. After running `make -C spi/tools`, this folder shows up as untracked in the git status. Add the above folder to the .gitignore file. Fixes: f325b73dc4db ("spi: tools: move to tools buildsystem") Signed-off-by: Francesco Lavra Link: https://patch.msgid.link/20260209095001.556495-1-flavra@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 81190b2e9d04bfa2cdade33c797aa228db251ec5 Author: Charles Keepax Date: Wed Feb 4 12:59:39 2026 +0000 ASoC: SDCA: Handle volatile controls correctly [ Upstream commit 9fad74b79e5ff353fe156c4b685cceffa5afdb1d ] There are very few volatile controls in SDCA that are exported as ALSA controls, typically Detected Mode is the only common one. However, the current code does not resume the device when these ALSA controls are accessed, which will result in the read/write failing. Add a new wrapper specifically for volatile controls that will do the required pm_runtime operations before accessing the register. Fixes: c3ca24e3fcb6 ("ASoC: SDCA: Create ALSA controls from DisCo") Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260204125944.1134011-3-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 97b513d04e116123a085856022756b5ac8ba251a Author: Charles Keepax Date: Mon Oct 20 16:55:02 2025 +0100 ASoC: SDCA: Force some SDCA Controls to be volatile [ Upstream commit c7b6c6b60594fd1efe35c61bc6a2176b25263ccc ] Whilst SDCA does specify an Access Mode for each Control, there is not a 1-to-1 mapping between that and ASoC's internal representation. Some registers require being treated as volatile from the hosts perspective even in their Access Mode is Read-Write. Add an explicit list of SDCA controls that should be forced volatile. Reviewed-by: Bard Liao Signed-off-by: Charles Keepax Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20251020155512.353774-10-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Stable-dep-of: 9fad74b79e5f ("ASoC: SDCA: Handle volatile controls correctly") Signed-off-by: Sasha Levin commit 32606d55ffc1a1572dc65429cd0288aed067c896 Author: Charles Keepax Date: Wed Feb 4 12:59:38 2026 +0000 ASoC: SDCA: Remove outdated todo comment [ Upstream commit b27b57f85fe3f0eca479556ac55bc9cbd1a5685a ] Support for -cn- properties has already been added, however the TODO comment noting this feature was required was not removed. Remove the now redundant comment. Fixes: 50a479527ef01 ("ASoC: SDCA: Add support for -cn- value properties") Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260204125944.1134011-2-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 59be162822e56feaa100b122ba655fd9a550ecf9 Author: Lizhi Hou Date: Tue Feb 3 10:40:37 2026 -0800 accel/amdxdna: Fix incorrect error code returned for failed chain command [ Upstream commit 750817a7c41de083ca5d73052e97bb7b67d7c394 ] The driver currently returns an incorrect error code when a chain command fails. In this case, ERT_CMD_STATE_ERROR is expected to be reported for failed chain commands. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Reviewed-by: Mario Limonciello (AMD) Reviewed-by: Maciej Falkowski Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260203184037.2751889-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit feb4bcfd405282de60aba321f13a1272b30c5af4 Author: Ryan Lin Date: Fri Jan 30 13:34:56 2026 +0800 HID: intel-ish-hid: fix NULL-ptr-deref in ishtp_bus_remove_all_clients [ Upstream commit 56f7db581ee73af53cd512e00a6261a025bf1d58 ] During a warm reset flow, the cl->device pointer may be NULL if the reset occurs while clients are still being enumerated. Accessing cl->device->reference_count without a NULL check leads to a kernel panic. This issue was identified during multi-unit warm reboot stress clycles. Add a defensive NULL check for cl->device to ensure stability under such intensive testing conditions. KASAN: null-ptr-deref in range [0000000000000000-0000000000000007] Workqueue: ish_fw_update_wq fw_reset_work_fn Call Trace: ishtp_bus_remove_all_clients+0xbe/0x130 [intel_ishtp] ishtp_reset_handler+0x85/0x1a0 [intel_ishtp] fw_reset_work_fn+0x8a/0xc0 [intel_ish_ipc] Fixes: 3703f53b99e4a ("HID: intel_ish-hid: ISH Transport layer") Signed-off-by: Ryan Lin Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 5a68d2c99c859e6e8e36fa4e32749abf6d1fb66a Author: Zishun Yi Date: Fri Jan 30 01:10:22 2026 +0800 accel/amdxdna: Fix memory leak in amdxdna_ubuf_map [ Upstream commit 84dd57fb0359500092f1101409ca32091731490d ] The amdxdna_ubuf_map() function allocates memory for sg and internal sg table structures, but it fails to free them if subsequent operations (sg_alloc_table_from_pages or dma_map_sgtable) fail. Fixes: bd72d4acda10 ("accel/amdxdna: Support user space allocated buffer") Signed-off-by: Zishun Yi Reviewed-by: Lizhi Hou Reviewed-by: Min Ma Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260129171022.68578-1-zishun.yi.dev@gmail.com Signed-off-by: Sasha Levin commit b79d31dce49b50c79620389b3639280802a86960 Author: Lizhi Hou Date: Thu Jan 29 16:32:55 2026 -0800 accel/amdxdna: Stop job scheduling across aie2_release_resource() [ Upstream commit f1370241fe8045702bc9d0812b996791f0500f1b ] Running jobs on a hardware context while it is in the process of releasing resources can lead to use-after-free and crashes. Fix this by stopping job scheduling before calling aie2_release_resource() and restarting it after the release completes. Additionally, aie2_sched_job_run() now checks whether the hardware context is still active. Fixes: 4fd6ca90fc7f ("accel/amdxdna: Refactor hardware context destroy routine") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260130003255.2083255-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit f6b4c1d98a7b8040d4d02e89425b3942016a2c2c Author: Lizhi Hou Date: Tue Jan 27 16:23:56 2026 -0800 accel/amdxdna: Hold mm structure across iommu_sva_unbind_device() [ Upstream commit a9162439ad792afcddc04718408ec1380b7a5f63 ] Some tests trigger a crash in iommu_sva_unbind_device() due to accessing iommu_mm after the associated mm structure has been freed. Fix this by taking an explicit reference to the mm structure after successfully binding the device, and releasing it only after the device is unbound. This ensures the mm remains valid for the entire SVA bind/unbind lifetime. Fixes: be462c97b7df ("accel/amdxdna: Add hardware context") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260128002356.1858122-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit e6ff5e9e390055d440e4505521bfd42ae4fc3ce3 Author: Tzung-Bi Shih Date: Fri Jan 30 04:03:35 2026 +0000 platform/chrome: cros_ec_lightbar: Fix response size initialization [ Upstream commit ec0dd36dbf8b0b209e63d0cd795451fa2203c736 ] Commit 1e7913ff5f9f ("platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command") meant to set smaller values for both request and response sizes. However, it incorrectly assigned the response size to the `result` field instead of `insize`. Fix it. Reported-by: Gwendal Grignou Closes: https://lore.kernel.org/chrome-platform/CAMHSBOVrrYaB=1nEqZk09VkczCrj=6B-P8Fe29TpPdSDgT2CCQ@mail.gmail.com Fixes: 1e7913ff5f9f ("platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command") Link: https://lore.kernel.org/r/20260130040335.361997-1-tzungbi@kernel.org Reviewed-by: Gwendal Grignou Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit 52b71d02539783826a337244f019dc5f55cfaa46 Author: Sheetal Date: Fri Jan 23 15:23:43 2026 +0530 ASoC: tegra: Add AHUB writeable_reg for RX holes [ Upstream commit 0ba6286a71581aaf8413a55b9bd90ea3463fd23b ] Add writeable_reg callbacks for Tegra210/186 AHUB RX registers so the flat cache only treats valid RX locations as writable, avoiding holes in the register map. Fixes: 16e1bcc2caf4 ("ASoC: tegra: Add Tegra210 based AHUB driver") Signed-off-by: Sheetal Reviewed-by: Jon Hunter Tested-by: Jon Hunter Link: https://patch.msgid.link/20260123095346.1258556-2-sheetal@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a3ce2b030809f1f7fc7f63d6c9198282cf655738 Author: Harry Yoo Date: Fri Jan 23 07:52:40 2026 +0100 mm/slab: fix false lockdep warning in __kfree_rcu_sheaf() [ Upstream commit f8b4cd2dad097e4ea5aed3511f42b9eb771e7b19 ] kvfree_call_rcu() can be called while holding a raw_spinlock_t. Since __kfree_rcu_sheaf() may acquire a spinlock_t (which becomes a sleeping lock on PREEMPT_RT) and violate lock nesting rules, kvfree_call_rcu() bypasses the sheaves layer entirely on PREEMPT_RT. However, lockdep still complains about acquiring spinlock_t while holding raw_spinlock_t, even on !PREEMPT_RT where spinlock_t is a spinning lock. This causes a false lockdep warning [1]: ============================= [ BUG: Invalid wait context ] 6.19.0-rc6-next-20260120 #21508 Not tainted ----------------------------- migration/1/23 is trying to lock: ffff8afd01054e98 (&barn->lock){..-.}-{3:3}, at: barn_get_empty_sheaf+0x1d/0xb0 other info that might help us debug this: context-{5:5} 3 locks held by migration/1/23: #0: ffff8afd01fd89a8 (&p->pi_lock){-.-.}-{2:2}, at: __balance_push_cpu_stop+0x3f/0x200 #1: ffffffff9f15c5c8 (rcu_read_lock){....}-{1:3}, at: cpuset_cpus_allowed_fallback+0x27/0x250 #2: ffff8afd1f470be0 ((local_lock_t *)&pcs->lock){+.+.}-{3:3}, at: __kfree_rcu_sheaf+0x52/0x3d0 stack backtrace: CPU: 1 UID: 0 PID: 23 Comm: migration/1 Not tainted 6.19.0-rc6-next-20260120 #21508 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Stopper: __balance_push_cpu_stop+0x0/0x200 <- balance_push+0x118/0x170 Call Trace: __dump_stack+0x22/0x30 dump_stack_lvl+0x60/0x80 dump_stack+0x19/0x24 __lock_acquire+0xd3a/0x28e0 ? __lock_acquire+0x5a9/0x28e0 ? __lock_acquire+0x5a9/0x28e0 ? barn_get_empty_sheaf+0x1d/0xb0 lock_acquire+0xc3/0x270 ? barn_get_empty_sheaf+0x1d/0xb0 ? __kfree_rcu_sheaf+0x52/0x3d0 _raw_spin_lock_irqsave+0x47/0x70 ? barn_get_empty_sheaf+0x1d/0xb0 barn_get_empty_sheaf+0x1d/0xb0 ? __kfree_rcu_sheaf+0x52/0x3d0 __kfree_rcu_sheaf+0x19f/0x3d0 kvfree_call_rcu+0xaf/0x390 set_cpus_allowed_force+0xc8/0xf0 [...] This wasn't triggered until sheaves were enabled for all slab caches, since kfree_rcu() wasn't being called with a raw spinlock held for caches with sheaves (vma, maple node). As suggested by Vlastimil Babka, fix this by using a lockdep map with LD_WAIT_CONFIG wait type to tell lockdep that acquiring spinlock_t is valid in this case, as those spinlocks won't be used on PREEMPT_RT. Note that kfree_rcu_sheaf_map should be acquired using _try() variant, otherwise the acquisition of the lockdep map itself will trigger an invalid wait context warning. Reported-by: Paul E. McKenney Closes: https://lore.kernel.org/linux-mm/c858b9af-2510-448b-9ab3-058f7b80dd42@paulmck-laptop [1] Fixes: ec66e0d59952 ("slab: add sheaf support for batching kfree_rcu() operations") Suggested-by: Vlastimil Babka Signed-off-by: Harry Yoo Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin commit aa27ad4e20e0aa2e7c038fe303fbc99e156a4327 Author: Shuicheng Lin Date: Fri Jan 9 21:10:42 2026 +0000 drm/xe: Unregister drm device on probe error [ Upstream commit 96c2c72b817d70e8d110e78b0162e044a0c41f9f ] Call drm_dev_unregister() when xe_device_probe() fails after successful drm_dev_register(). This ensures the DRM device is promptly unregistered before returning an error, avoiding leaving it registered on the failure path. Otherwise, there is warn message if xe_device_probe() is called again: " [ 207.322365] [drm:drm_minor_register] [ 207.322381] debugfs: '128' already exists in 'dri' [ 207.322432] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:01.0/0000:03:00.0/drm/renderD128' [ 207.322435] CPU: 5 UID: 0 PID: 10261 Comm: modprobe Tainted: G B W 6.19.0-rc2-lgci-xe-kernel+ #223 PREEMPT(voluntary) [ 207.322439] Tainted: [B]=BAD_PAGE, [W]=WARN [ 207.322440] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023 [ 207.322441] Call Trace: [ 207.322442] [ 207.322443] dump_stack_lvl+0xa0/0xc0 [ 207.322446] dump_stack+0x10/0x20 [ 207.322448] sysfs_warn_dup+0xd5/0x110 [ 207.322451] sysfs_create_dir_ns+0x1f6/0x280 [ 207.322453] ? __pfx_sysfs_create_dir_ns+0x10/0x10 [ 207.322455] ? lock_acquire+0x1a4/0x2e0 [ 207.322458] ? __kasan_check_read+0x11/0x20 [ 207.322461] kobject_add_internal+0x28d/0x8e0 [ 207.322464] kobject_add+0x11f/0x1f0 [ 207.322465] ? lock_acquire+0x1a4/0x2e0 [ 207.322467] ? __pfx_kobject_add+0x10/0x10 [ 207.322469] ? __kasan_check_write+0x14/0x20 [ 207.322471] ? kobject_put+0x62/0x4a0 [ 207.322473] ? get_device_parent.isra.0+0x1bb/0x4c0 [ 207.322475] ? kobject_put+0x62/0x4a0 [ 207.322477] device_add+0x2d7/0x1500 [ 207.322479] ? __pfx_device_add+0x10/0x10 [ 207.322481] ? drm_debugfs_add_file+0xfa/0x170 [ 207.322483] ? drm_debugfs_add_files+0x82/0xd0 [ 207.322485] ? drm_debugfs_add_files+0x82/0xd0 [ 207.322487] drm_minor_register+0x10a/0x2d0 [ 207.322489] drm_dev_register+0x143/0x860 [ 207.322491] ? xe_configfs_get_psmi_enabled+0x12/0x90 [xe] [ 207.322667] xe_device_probe+0x185b/0x2c40 [xe] [ 207.322812] ? __pfx___drm_dev_dbg+0x10/0x10 [ 207.322815] ? add_dr+0x180/0x220 [ 207.322818] ? __pfx___drmm_mutex_release+0x10/0x10 [ 207.322821] ? __pfx_xe_device_probe+0x10/0x10 [xe] [ 207.322966] ? xe_pm_init_early+0x33a/0x410 [xe] [ 207.323136] xe_pci_probe+0x936/0x1250 [xe] [ 207.323298] ? lock_acquire+0x1a4/0x2e0 [ 207.323302] ? __pfx_xe_pci_probe+0x10/0x10 [xe] [ 207.323464] local_pci_probe+0xe6/0x1a0 [ 207.323468] pci_device_probe+0x523/0x840 [ 207.323470] ? __pfx_pci_device_probe+0x10/0x10 [ 207.323473] ? sysfs_do_create_link_sd.isra.0+0x8c/0x110 [ 207.323476] ? sysfs_create_link+0x48/0xc0 [ 207.323479] really_probe+0x1fd/0x8a0 ... " Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Shuicheng Lin Reviewed-by: Jonathan Cavitt Link: https://patch.msgid.link/20260109211041.2446012-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper (cherry picked from commit 60bfb8baf8f0d5b0d521744dfd01c880ce1a23f3) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit c287399b66c003012a41b7c374dd8b5a0ac14f56 Author: Vinay Belgaumkar Date: Fri Jan 23 16:59:17 2026 -0800 drm/xe/ptl: Disable DCC on PTL [ Upstream commit 801a6e61f5fbab2c0dd76c8360f45b625b49e410 ] On PTL, the recommendation is to disable DCC(Duty Cycle Control) as it may cause some regressions due to added latencies. Upcoming GuC releases will disable DCC on PTL as well, but we need to force it in KMD so that this behavior is propagated to older kernels. v2: Update commit message (Rodrigo) v3: Rebase v4: Fix typo: s/propagted/propagated Fixes: 5cdb71d3b0db ("drm/xe/ptl: Add GuC FW definition for PTL") Cc: Daniele Ceraolo Spurio Cc: Rodrigo Vivi Signed-off-by: Vinay Belgaumkar Link: https://patch.msgid.link/20260124005917.398522-1-vinay.belgaumkar@intel.com Reviewed-by: Rodrigo Vivi Signed-off-by: Rodrigo Vivi (cherry picked from commit 40ee63f5df2d5c6471b583df800aac89dc0502a4) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit ede7b0f33c5a67d34be1389784716338db760015 Author: Roberto Sassu Date: Tue Jan 20 15:53:41 2026 +0100 evm: Use ordered xattrs list to calculate HMAC in evm_init_hmac() [ Upstream commit 0496fc9cdc384f67be4413b1c6156eb64fccd5c4 ] Commit 8e5d9f916a96 ("smack: deduplicate xattr setting in smack_inode_init_security()") introduced xattr_dupval() to simplify setting the xattrs to be provided by the SMACK LSM on inode creation, in the smack_inode_init_security(). Unfortunately, moving lsm_get_xattr_slot() caused the SMACK64TRANSMUTE xattr be added in the array of new xattrs before SMACK64. This causes the HMAC of xattrs calculated by evm_init_hmac() for new files to diverge from the one calculated by both evm_calc_hmac_or_hash() and evmctl. evm_init_hmac() calculates the HMAC of the xattrs of new files based on the order LSMs provide them, while evm_calc_hmac_or_hash() and evmctl calculate the HMAC based on an ordered xattrs list. Fix the issue by making evm_init_hmac() calculate the HMAC of new files based on the ordered xattrs list too. Fixes: 8e5d9f916a96 ("smack: deduplicate xattr setting in smack_inode_init_security()") Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 5332491be2ca19b85e9f9c548c539f354f34fa32 Author: Ricardo Ribalda Date: Wed Jan 14 10:32:13 2026 +0000 media: uvcvideo: Fix allocation for small frame sizes [ Upstream commit 40d3ac25c11310bfaa50ed7614846ef75cb69a1e ] If a frame has size of less or equal than one packet size uvc_alloc_urb_buffers() is unable to allocate memory for it due to a off-by-one error. Fix the off-by-one-error and now that we are at it, make sure that stream->urb_size has always a valid value when we return from the function, even when an error happens. Fixes: efdc8a9585ce ("V4L/DVB (10295): uvcvideo: Retry URB buffers allocation when the system is low on memory.") Reported-by: Itay Chamiel Closes: https://lore.kernel.org/linux-media/CANiDSCsSoZf2LsCCoWAUbCg6tJT-ypXR1B85aa6rAdMVYr2iBQ@mail.gmail.com/T/#t Co-developed-by: Itay Chamiel Signed-off-by: Itay Chamiel Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Tested-by: Itay Chamiel Link: https://patch.msgid.link/20260114-uvc-alloc-urb-v1-1-cedf3fb66711@chromium.org Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 16dd68310f5011db4f12a7fb94fb2990cf149ba4 Author: Gokul Praveen Date: Wed Jan 21 11:41:34 2026 +0530 pwm: tiehrpwm: Enable pwmchip's parent device before setting configuration [ Upstream commit 75e7ed52ac7c1da90f304dcda2906636404df921 ] The period and duty cycle configurations on J7200 and J784S4 SoCs does not get reflected after setting them using sysfs nodes. This is because at the end of ehrpwm_pwm_config function, the put_sync function is called which resets the hardware. Hold the PWM controller out of low-power mode during .apply() to make sure it accepts the writes to its registers. This renders the calls to pm_runtime_get_sync() and pm_runtime_put_sync() in ehrpwm_pwm_config() into no-ops, so these can be dropped. Fixes: 5f027d9b83db ("pwm: tiehrpwm: Implement .apply() callback") Signed-off-by: Gokul Praveen Suggested-by: Uwe Kleine-König Link: https://patch.msgid.link/20260121061134.15466-1-g-praveen@ti.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit 39c24b19a61114f1a5118ad2290fb5056b264bf4 Author: Andy Shevchenko Date: Tue Jan 20 14:12:30 2026 +0100 platform/chrome: cros_typec_switch: Don't touch struct fwnode_handle::dev [ Upstream commit e1adf48853bc715f4deea074932aa1c44eb7abea ] The 'dev' field in struct fwnode is special and related to device links, There no driver should use it for printing messages. Fix incorrect use of private field. Fixes: affc804c44c8 ("platform/chrome: cros_typec_switch: Add switch driver") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20260120131413.1697891-2-andriy.shevchenko@linux.intel.com Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit b7e2bd20e7c8b301210e984d7f387dac303eef42 Author: Nathan Chancellor Date: Tue Jan 13 17:00:31 2026 -0700 drm/msm/dp: Avoid division by zero in msm_dp_ctrl_config_msa() [ Upstream commit f185076da44c774241a16a82a7773ece3c1c607b ] An (admittedly problematic) optimization change in LLVM 20 [1] turns known division by zero into the equivalent of __builtin_unreachable(), which invokes undefined behavior if it is encountered in a control flow graph, destroying code generation. When compile testing for x86_64, objtool flags an instance of this optimization triggering in msm_dp_ctrl_config_msa(), inlined into msm_dp_ctrl_on_stream(): drivers/gpu/drm/msm/msm.o: warning: objtool: msm_dp_ctrl_on_stream(): unexpected end of section .text.msm_dp_ctrl_on_stream The zero division happens if the else branch in the first if statement in msm_dp_ctrl_config_msa() is taken because pixel_div is initialized to zero and it is not possible for LLVM to eliminate the else branch since rate is still not known after inlining into msm_dp_ctrl_on_stream(). Transform the if statements into a switch statement with a default case with the existing error print and an early return to avoid the invalid division. Add a comment to note this helps the compiler, even though the case is known to be unreachable. With this, pixel_dev's default zero initialization can be dropped, as it is dead with this change. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Link: https://github.com/llvm/llvm-project/commit/37932643abab699e8bb1def08b7eb4eae7ff1448 [1] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202601081959.9UVJEOfP-lkp@intel.com/ Suggested-by: Konrad Dybcio Signed-off-by: Nathan Chancellor Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/698355/ Link: https://lore.kernel.org/r/20260113-drm-msm-dp_ctrl-avoid-zero-div-v2-1-f1aa67bf6e8e@kernel.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit e60e16d406b2310a05353649078f9b3e4031d33d Author: Dmitry Baryshkov Date: Mon Jan 19 14:16:39 2026 +0200 drm/msm/dpu: program correct register for UBWC config on DPU 8.x+ [ Upstream commit 5dcec3fc1311c277369a4bdf8b292781e5cc91fd ] Since DPU 8.0 there is a separate register for the second rectangle, which needs to be programmed with the UBWC config if multirect is being used. Write pipe's UBWC configuration to the correct register. Fixes: 100d7ef6995d ("drm/msm/dpu: add support for SM8450") Tested-by: Val Packett # x1e80100-dell-latitude-7455 Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/699277/ Link: https://lore.kernel.org/r/20260119-msm-ubwc-fixes-v4-3-0987acc0427f@oss.qualcomm.com Signed-off-by: Sasha Levin commit d791b31e7da1646ecf65df395df2f2ac61304f92 Author: Dmitry Baryshkov Date: Mon Jan 19 14:16:38 2026 +0200 drm/msm/dpu: offset HBB values written to DPU by -13 [ Upstream commit 7ead14d4b9742b5ed244f35b999f0fe26dc23586 ] As in all other places, the Highest Bank Bit value should be programmed into the hardware with the offset of -13. Correct the value written into the register to prevent unpredictable results. Fixes: 227d4ce0b09e ("drm/msm: Offset MDSS HBB value by 13") Tested-by: Val Packett # x1e80100-dell-latitude-7455 Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/699276/ Link: https://lore.kernel.org/r/20260119-msm-ubwc-fixes-v4-2-0987acc0427f@oss.qualcomm.com Signed-off-by: Sasha Levin commit b573177b314e08d6f3002f07a3a4403bf253f848 Author: Dmitry Baryshkov Date: Mon Jan 19 14:16:37 2026 +0200 drm/msm/mdss: correct HBB programmed on UBWC 5.x and 6.x devices [ Upstream commit e6177c7a2401b87b016728b75992926971d871fc ] As in the previous generations, on UBWC 5.x and 6.x devices the Highest Bank Bit value should be programmed into the hardware with the offset of -13. Correct the value written into the register to prevent unpredictable results. Fixes: 227d4ce0b09e ("drm/msm: Offset MDSS HBB value by 13") Tested-by: Val Packett # x1e80100-dell-latitude-7455 Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/699274/ Link: https://lore.kernel.org/r/20260119-msm-ubwc-fixes-v4-1-0987acc0427f@oss.qualcomm.com Signed-off-by: Sasha Levin commit 7672af88d30724222573f5f4bded99195650fc11 Author: Cristian Ciocaltea Date: Thu Jan 15 18:24:43 2026 +0200 drm/rockchip: dw_hdmi_qp: Fix RK3576 HPD interrupt handling [ Upstream commit 5f7be8afc40c5ccf1be0410514703e50a49532c0 ] The threaded interrupt handler on RK3576 checks HPD IRQ status before deciding to continue with interrupt clearing and unmasking. This is not only redundant, since a similar verification has been already performed by the hard IRQ handler before masking the interrupt, but is also error prone, because it might happen that hardware clears the status register right after the masking operation completes, and before the threaded handler reads its value. The consequence is that HPD IRQ gets never unmasked, which breaks hotplug detection until reloading the driver or rebooting the system. Drop the unnecessary verification of the HPD interrupt status from the threaded interrupt handler. Fixes: 36439120efbd ("drm/rockchip: dw_hdmi_qp: Add basic RK3576 HDMI output support") Signed-off-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260115-dw-hdmi-qp-hpd-v1-1-e59c166eaa65@collabora.com Signed-off-by: Sasha Levin commit fb328aa95c34c14f5e358392afbae5a9dbe211ee Author: Baihan Li Date: Wed Dec 10 10:37:59 2025 +0800 drm/hisilicon/hibmc: Adding reset colorbar cfg in dp init. [ Upstream commit 6dad7fa8581e96321ec8a6a4f8160762466f539a ] Add colorbar disable operation before reset chontroller, to make sure colorbar status is clear in the DP init, so if rmmod the driver and the previous colorbar configuration will not affect the next time insmod the driver. Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq feature") Signed-off-by: Baihan Li Signed-off-by: Yongbang Shi Reviewed-by: Dmitry Baryshkov Reviewed-by: Tao Tian Link: https://patch.msgid.link/20251210023759.3944834-5-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 0922d282f7d305603938a69fa724523579a0c846 Author: Baihan Li Date: Wed Dec 10 10:37:58 2025 +0800 drm/hisilicon/hibmc: fix no showing problem with loading hibmc manually [ Upstream commit 0607052a6aee1e3d218a99fae70ba9f14b3b47ed ] When using command rmmod and insmod, there is no showing in second time insmoding. Because DP controller won't send HPD signals, if connection doesn't change or controller isn't reset. So add reset before unreset in hibmc_dp_hw_init(). And also need to move the HDCP cfg after DP controller de-resets, so that HDCP configuration takes effect. Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq feature") Signed-off-by: Baihan Li Signed-off-by: Yongbang Shi Reviewed-by: Dmitry Baryshkov Reviewed-by: Tao Tian Link: https://patch.msgid.link/20251210023759.3944834-4-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 84359ed3c53f0a44c56c71bb90498e8db72acf92 Author: Baihan Li Date: Wed Dec 10 10:37:57 2025 +0800 drm/hisilicon/hibmc: add dp mode valid check [ Upstream commit 607805abfb747b98f43aa57d6d9ba4caed4d106f ] If DP is connected, check the DP BW in mode_valid_ctx() to ensure that DP's link rate supports high-resolution data transmission. Fixes: 0ab6ea261c1f ("drm/hisilicon/hibmc: add dp module in hibmc") Signed-off-by: Baihan Li Signed-off-by: Yongbang Shi Reviewed-by: Dmitry Baryshkov Reviewed-by: Tao Tian Link: https://patch.msgid.link/20251210023759.3944834-3-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit bc950899ef118979277300a7a3e2922f92aac80c Author: Baihan Li Date: Wed Dec 10 10:37:56 2025 +0800 drm/hisilicon/hibmc: fix dp probabilistical detect errors after HPD irq [ Upstream commit 3906e7a3b26d683868704fe262db443207f392fe ] The issue is that drm_connector_helper_detect_from_ddc() returns wrong status when plugging or unplugging the monitor, which may cause the link failed err.[0] Use HPD pin status in DP's detect_ctx() for real physical monitor in/out, and implement a complete DP detection including read DPCD, check if it's a branch device and its sink count for different situations. [0]: hibme-drm 0000:83:00.0: [drm] *ERROR* channel equalization failed 5 times hibme-drm 0000:83:00.0: [drm] *ERROR* channel equalization failed 5 times hibme-drm 0000:83:00.0: [drm] *ERROR* dp link training failed, ret: -16 hibmc-drm 0000:83:00.0: [drm] *ERROR* hibme dp mode set failed: -16 Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq feature") Signed-off-by: Baihan Li Signed-off-by: Yongbang Shi Reviewed-by: Tao Tian Link: https://patch.msgid.link/20251210023759.3944834-2-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 840581b30cdeb21c04235999cde8763f8341460d Author: Michał Grzelak Date: Mon Dec 8 11:27:14 2025 +0100 drm/buddy: release free_trees array on buddy mm teardown [ Upstream commit 7d0507772406e129329983b8b807e5b499bd74fd ] During initialization of DRM buddy memory manager at drm_buddy_init, mm->free_trees array is allocated for both clear and dirty RB trees. During cleanup happening at drm_buddy_fini it is never freed, leading to following memory leaks observed on xe module load & unload cycles: kmemleak_alloc+0x4a/0x90 __kmalloc_cache_noprof+0x488/0x800 drm_buddy_init+0xc2/0x330 [drm_buddy] __xe_ttm_vram_mgr_init+0xc3/0x190 [xe] xe_ttm_stolen_mgr_init+0xf5/0x9d0 [xe] xe_device_probe+0x326/0x9e0 [xe] xe_pci_probe+0x39a/0x610 [xe] local_pci_probe+0x47/0xb0 pci_device_probe+0xf3/0x260 really_probe+0xf1/0x3c0 __driver_probe_device+0x8c/0x180 driver_probe_device+0x24/0xd0 __driver_attach+0x10f/0x220 bus_for_each_dev+0x7f/0xe0 driver_attach+0x1e/0x30 bus_add_driver+0x151/0x290 Deallocate array for free trees when cleaning up buddy memory manager in the same way as if going through out_free_tree label. Fixes: d4cd665c98c1 ("drm/buddy: Separate clear and dirty free block trees") Signed-off-by: Michał Grzelak Reviewed-by: Lucas De Marchi Reviewed-by: Matthew Auld Signed-off-by: Arunpravin Paneer Selvam Link: https://patch.msgid.link/20251208102714.4008260-2-michal.grzelak@intel.com Signed-off-by: Sasha Levin commit f83b92c5768647034b074abe798f07e0524d1dc0 Author: Dmitry Baryshkov Date: Fri Nov 21 18:13:03 2025 +0200 drm/msm/a2xx: fix pixel shader start on A225 [ Upstream commit 6a7b0a670ba4d283285d76d45233cbecc5af5e40 ] A225 has a different PixelShader start address, write correct address while initializing GPU. Fixes: 21af872cd8c6 ("drm/msm/adreno: add a2xx") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/689906/ Message-ID: <20251121-a225-v1-1-a1bab651d186@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 21cf7527de1d174c22fdca8eedf5e8c0d7206a04 Author: David Heidelberg Date: Fri Jan 9 18:57:07 2026 +0100 media: ccs: Accommodate C-PHY into the calculation [ Upstream commit 3085977e734dab74adebb1dda195befce25addff ] We need to set correct mode for PLL to calculate correct frequency. Signalling mode is known at this point, so use it for that. Fixes: 47b6eaf36eba ("media: ccs-pll: Differentiate between CSI-2 D-PHY and C-PHY") Reviewed-by: Mehdi Djait Signed-off-by: David Heidelberg [Sakari Ailus: Drop extra newline.] Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 5fab6e1405e18ff48c56bfbd145c6daf12a7f5cd Author: Lizhi Hou Date: Tue Jan 13 09:36:24 2026 -0800 accel/amdxdna: Fix notifier_wq flushing warning [ Upstream commit b36178488d479e9a53bbef2b01280378b5586e60 ] Create notifier_wq with WQ_MEM_RECLAIM flag to fix the possible warning. workqueue: WQ_MEM_RECLAIM amdxdna_js:drm_sched_free_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM notifier_wq:0x0 Fixes: e486147c912f ("accel/amdxdna: Add BO import and export") Reviewed-by: Mario Limonciello (AMD) Reviewed-by: Maciej Falkowski Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260113173624.256053-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit c0727bcbf09b472afb8a7c924419428b477cce81 Author: Brian Masney Date: Thu Jan 8 16:16:42 2026 -0500 drm/msm/dsi_phy_14nm: convert from divider_round_rate() to divider_determine_rate() [ Upstream commit 1d232f793d4dbffd329ad48b52954d4c8ca24db5 ] The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: cc41f29a6b04 ("drm/msm/dsi_phy_14nm: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney Reviewed-by: Konrad Dybcio Reviewed-by: Abel Vesa Patchwork: https://patchwork.freedesktop.org/patch/697613/ Link: https://lore.kernel.org/r/20260108-clk-divider-round-rate-v1-24-535a3ed73bf3@redhat.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 2b46bb9f88cd79039f66a696a3bac201ceebb87b Author: Dmitry Baryshkov Date: Sun Dec 28 06:02:28 2025 +0200 drm/msm/dpu: fix CMD panels on DPU 1.x - 3.x [ Upstream commit 59ca3d11f5311d9167015fe4f431701614ae0048 ] DPU units before 4.x don't have a separate CTL_START IRQ to mark the begin of the data transfer. In such a case, wait for the frame transfer to complete rather than trying to wait for the CTL_START interrupt (and obviously hitting the timeout). Fixes: 050770cbbd26 ("drm/msm/dpu: Fix timeout issues on command mode panels") Reported-by: Alexey Minnekhanov Closes: https://lore.kernel.org/r/8e1d33ff-d902-4ae9-9162-e00d17a5e6d1@postmarketos.org Patchwork: https://patchwork.freedesktop.org/patch/696490/ Link: https://lore.kernel.org/r/20251228-mdp5-drop-dpu3-v4-2-7497c3d39179@oss.qualcomm.com Tested-by: Alexey Minnekhanov Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 2f803e86ba4f4b0177ade51a473785f4c94f734b Author: Dmitry Baryshkov Date: Fri Nov 14 05:43:28 2025 +0200 drm/msm/disp: set num_planes to 1 for interleaved YUV formats [ Upstream commit 6421e1c5075b7e1536a8fcbe6b4086db07103048 ] Interleaved YUV formats use only one plane for all pixel data. Specify num_planes = 1 for those formats. This was left unnoticed since _dpu_format_populate_plane_sizes_linear() overrides layout->num_planes. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Reviewed-by: Jessica Zhang Patchwork: https://patchwork.freedesktop.org/patch/688162/ Link: https://lore.kernel.org/r/20251114-dpu-formats-v3-1-cae312379d49@oss.qualcomm.com Tested-by: Luca Weiss # qcm6490-fairphone-fp5 Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 35301ca2a83d17aac2f3e8e35c696f0da2a13111 Author: Haotian Zhang Date: Mon Nov 17 16:28:08 2025 +0800 HID: playstation: Add missing check for input_ff_create_memless [ Upstream commit e6807641ac94e832988655a1c0e60ccc806b76dc ] The ps_gamepad_create() function calls input_ff_create_memless() without verifying its return value, which can lead to incorrect behavior or potential crashes when FF effects are triggered. Add a check for the return value of input_ff_create_memless(). Fixes: 51151098d7ab ("HID: playstation: add DualSense classic rumble support.") Signed-off-by: Haotian Zhang Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit b6a83ad13d253f9319920313a0fbad637fab9aef Author: André Draszik Date: Fri Jan 9 08:38:39 2026 +0000 regulator: core: move supply check earlier in set_machine_constraints() [ Upstream commit 86a8eeb0e913f4b6a55dabba5122098d4e805e55 ] Since commit 98e48cd9283d ("regulator: core: resolve supply for boot-on/always-on regulators"), set_machine_constraints() can return -EPROBE_DEFER very late, after it has done a lot of work and configuration of the regulator. This means that configuration will happen multiple times for no benefit in that case. Furthermore, this can lead to timing-dependent voltage glitches as mentioned e.g. in commit 8a866d527ac0 ("regulator: core: Resolve supply name earlier to prevent double-init"). We can know that it's going to fail very early, in particular before going through the complete regulator configuration by moving some code around a little. Do so to avoid re-configuring the regulator multiple times, also avoiding the voltage glitches if we can. Fixes: 98e48cd9283d ("regulator: core: resolve supply for boot-on/always-on regulators") Signed-off-by: André Draszik Link: https://patch.msgid.link/20260109-regulators-defer-v2-3-1a25dc968e60@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a6b7308f35cdf1d17a135303c17f8309f4b5d9e3 Author: Jani Nikula Date: Wed Jan 7 18:02:26 2026 +0200 mei: late_bind: fix struct intel_lb_component_ops kernel-doc [ Upstream commit 936cae9254e55a39aeaa0c156a764d22f319338b ] Fix kernel-doc warnings on struct intel_lb_component_ops: Warning: include/drm/intel/intel_lb_mei_interface.h:55 Incorrect use of kernel-doc format: * push_payload - Sends a payload to the authentication firmware And a bunch more. There isn't really support for documenting function pointer struct members in kernel-doc, but at least reference the member properly. Fixes: 741eeabb7c78 ("mei: late_bind: add late binding component driver") Cc: Alexander Usyskin Reviewed-by: Nitin Gote Link: https://patch.msgid.link/20260107160226.2381388-1-jani.nikula@intel.com Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 4ef745e4d0d6356394b97456bb4de3550830fc4e Author: Mani Chandana Ballary Kuntumalla Date: Tue Nov 25 16:26:20 2025 +0530 drm/msm/dp: Update msm_dp_controller IDs for sa8775p [ Upstream commit 1338e8ae4084e55c0359a79e617b2ae183d01579 ] The Qualcomm SA8775P platform comes with 2 DisplayPort controllers for each mdss. Update controller id for DPTX0 and DPTX1 of mdss1. Fixes: dcb380d19e58 ("drm/msm/dp: Add DisplayPort controller for SA8775P") Signed-off-by: Mani Chandana Ballary Kuntumalla Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/690234/ Link: https://lore.kernel.org/r/20251125105622.1755651-2-quic_mkuntuma@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit acfd1dce074f8af3b334c8a446e558143047ea11 Author: Dmitry Baryshkov Date: Tue Dec 30 09:17:57 2025 +0200 drm/msm/dpu: fix WD timer handling on DPU 8.x [ Upstream commit 794b0e68caba49b950b42ec32e364028c2facf57 ] Since DPU 8.x Watchdog timer settings were moved from the TOP to the INTF block. Support programming the timer in the INTF block. Fixes tag points to the commit which removed register access to those registers on DPU 8.x+ (and which also should have added proper support for WD timer on those devices). Fixes: 43e3293fc614 ("drm/msm/dpu: add support for MDP_TOP blackhole") Reviewed-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/696586/ Link: https://lore.kernel.org/r/20251230-intf-fix-wd-v6-2-98203d150611@oss.qualcomm.com Signed-off-by: Sasha Levin commit 822d9b24de402dd91b2bfccf3a3f658a60ba991e Author: Teguh Sobirin Date: Tue Dec 30 09:17:56 2025 +0200 drm/msm/dpu: Set vsync source irrespective of mdp top support [ Upstream commit 1ad9880f059c9b0943e53714f9a59924cb035bbb ] Since DPU 5.x the vsync source TE setup is split between MDP TOP and INTF blocks. Currently all code to setup vsync_source is only executed if MDP TOP implements the setup_vsync_source() callback. However on DPU >= 8.x this callback is not implemented, making DPU driver skip all vsync setup. Move the INTF part out of this condition, letting DPU driver to setup TE vsync selection on all new DPU devices. Signed-off-by: Teguh Sobirin Fixes: 2f69e5458447 ("drm/msm/dpu: skip watchdog timer programming through TOP on >= SM8450") [DB: restored top->ops.setup_vsync_source call] Reviewed-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/696584/ Link: https://lore.kernel.org/r/20251230-intf-fix-wd-v6-1-98203d150611@oss.qualcomm.com Signed-off-by: Sasha Levin commit dc567a611b1694a685c5d1c548c186c518154347 Author: Mahadevan P Date: Thu Jan 1 10:34:38 2026 +0530 drm/msm/disp/dpu: add merge3d support for sc7280 [ Upstream commit 2892de3f4f985fa779c330468e2f341fdb762ccd ] On SC7280 targets, display modes with a width greater than the max_mixer_width (2400) are rejected during mode validation when merge3d is disabled. This limitation exists because, without a 3D merge block, two layer mixers cannot be combined(non-DSC interface), preventing large layers from being split across mixers. As a result, higher resolution modes cannot be supported. Enable merge3d support on SC7280 to allow combining streams from two layer mixers into a single non-DSC interface. This capability removes the width restriction and enables buffer sizes beyond the 2400-pixel limit. Fixes: 591e34a091d1 ("drm/msm/disp/dpu1: add support for display for SC7280 target") Signed-off-by: Mahadevan P Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/696713/ Link: https://lore.kernel.org/r/20260101-4k-v2-1-712ae3c1f816@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 8db8fadf1364f582315054f01831e551b7416f85 Author: Srinivasan Shanmugam Date: Thu Dec 18 15:25:25 2025 +0530 drm/amdgpu: Use explicit VCN instance 0 in SR-IOV init [ Upstream commit af26fa751c2eef66916acbf0d3c3e9159da56186 ] vcn_v2_0_start_sriov() declares a local variable "i" initialized to zero and uses it only as the instance index in SOC15_REG_OFFSET(UVD, i, ...). The value is never changed and all other fields are taken from adev->vcn.inst[0], so this path only ever programs VCN instance 0. This triggered a Smatch: warn: iterator 'i' not incremented Replace the dummy iterator with an explicit instance index of 0 in SOC15_REG_OFFSET() calls. Fixes: dd26858a9cd8 ("drm/amdgpu: implement initialization part on VCN2.0 for SRIOV") Reported by: Dan Carpenter Cc: darlington Opara Cc: Jinage Zhao Cc: Monk Liu Cc: Emily Deng Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Emily Deng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 30c6faf9170595e75958421c7ef693139c73ae28 Author: Srinivasan Shanmugam Date: Wed Dec 17 15:21:57 2025 +0530 drm/amdkfd: Fix signal_eviction_fence() bool return value [ Upstream commit 31dc58adda9874420ab8fa5a2f9c43377745753a ] signal_eviction_fence() is declared to return bool, but returns -EINVAL when no eviction fence is present. This makes the "no fence" or "the NULL-fence" path evaluate to true and triggers a Smatch warning. v2: Return true instead to explicitly indicate that there is no eviction fence to signal and that eviction is already complete. This matches the existing caller logic where a NULL fence means "nothing to do" and allows restore handling to proceed normally. (Christian) Fixes the below: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:2099 signal_eviction_fence() warn: '(-22)' is not bool drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c 2090 static bool signal_eviction_fence(struct kfd_process *p) ^^^^ 2091 { 2092 struct dma_fence *ef; 2093 bool ret; 2094 2095 rcu_read_lock(); 2096 ef = dma_fence_get_rcu_safe(&p->ef); 2097 rcu_read_unlock(); 2098 if (!ef) --> 2099 return -EINVAL; This should be either true or false. Probably true because presumably it has been tested? 2100 2101 ret = dma_fence_check_and_signal(ef); 2102 dma_fence_put(ef); 2103 2104 return ret; 2105 } Fixes: 37865e02e6cc ("drm/amdkfd: Fix eviction fence handling") Reported by: Dan Carpenter Cc: Philip Yang Cc: Gang BA Cc: Felix Kuehling Signed-off-by: Srinivasan Shanmugam Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 083351c6886e320252af1c1bd8602ab7b10b17f3 Author: Mario Limonciello (AMD) Date: Sun Dec 14 19:12:19 2025 -0600 drm/amd: Drop "amdgpu kernel modesetting enabled" message [ Upstream commit 8644084a74a4573278d6f454c6638ccd5965f4e2 ] The behavior for amdgpu was changed with commit e00e5c223878 ("drm/amdgpu: adjust drm_firmware_drivers_only() handling") to potentially allow loading even if nomodeset was set, so the message is no longer accurate. Just drop it to avoid confusion. Fixes: e00e5c223878 ("drm/amdgpu: adjust drm_firmware_drivers_only() handling") Signed-off-by: Mario Limonciello (AMD) Reviewed-by: Aurabindo Pillai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1de71556cbd6e1d0d26fb86b9b3bb8caa0df8495 Author: Zilin Guan Date: Tue Nov 11 14:57:06 2025 +0000 media: chips-media: wave5: Fix memory leak on codec_info allocation failure [ Upstream commit a519e21e32398459ba357e67b541402f7295ee1b ] In wave5_vpu_open_enc() and wave5_vpu_open_dec(), a vpu instance is allocated via kzalloc(). If the subsequent allocation for inst->codec_info fails, the functions return -ENOMEM without freeing the previously allocated instance, causing a memory leak. Fix this by calling kfree() on the instance in this error path to ensure it is properly released. Fixes: 9707a6254a8a6 ("media: chips-media: wave5: Add the v4l2 layer") Signed-off-by: Zilin Guan Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 77dc0140ea592b13003acd460c9d77df39d83d1c Author: Cristian Ciocaltea Date: Wed Dec 31 22:04:15 2025 +0200 ASoC: nau8821: Fixup nau8821_enable_jack_detect() [ Upstream commit 70237853edf0a69773a7370eb74ea2a44dfe3050 ] The nau8821_enable_jack_detect() function was supposed to allow enabling or disabling jack events reporting. However, once enabled, any subsequent invocation would fail and the following splat is shown: [ 3136.996771] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0131 01/30/2024 [ 3136.996773] Workqueue: events_unbound deferred_probe_work_func [ 3136.996780] Call Trace: [ 3136.996782] [ 3136.996787] dump_stack_lvl+0x6e/0xa0 [ 3136.996796] __setup_irq.cold+0x9c/0xce [ 3136.996803] ? __pfx_irq_default_primary_handler+0x10/0x10 [ 3136.996812] ? __pfx_nau8821_interrupt+0x10/0x10 [snd_soc_nau8821] [ 3136.996825] request_threaded_irq+0xd9/0x160 [ 3136.996853] devm_request_threaded_irq+0x71/0xd0 [ 3136.996859] ? __pfx_nau8821_interrupt+0x10/0x10 [snd_soc_nau8821] [ 3136.996882] nau8821_enable_jack_detect+0xa5/0xc0 [snd_soc_nau8821] [ 3136.996901] acp5x_8821_init+0x8d/0xa0 [snd_soc_acp5x_mach] [ 3136.996917] snd_soc_link_init+0x25/0x50 [snd_soc_core] [ 3136.996958] snd_soc_bind_card+0x615/0xd00 [snd_soc_core] [ 3136.997026] snd_soc_register_card+0x1b2/0x1c0 [snd_soc_core] [ 3136.997064] devm_snd_soc_register_card+0x47/0x90 [snd_soc_core] [ 3136.997108] acp5x_probe+0x72/0xb0 [snd_soc_acp5x_mach] [...] [ 3136.997508] nau8821 i2c-NVTN2020:00: Cannot request irq 58 (-16) Introduce jdet_active flag to driver data structure and use it to provide one-time initialization of the jack detection work queue and related interrupt line. Note this is also a prerequisite for additional fixes around module unloading and suspend handling. Fixes: aab1ad11d69f ("ASoC: nau8821: new driver") Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20251231-nau8821-cleanup-v1-1-6b0b76cbbb64@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5a247a84de0ba44edbbd6be851c8a6b2aa60ff85 Author: Konstantin Andreev Date: Tue Sep 30 15:31:53 2025 +0300 smack: /smack/doi: accept previously used values [ Upstream commit 33d589ed60ae433b483761987b85e0d24e54584e ] Writing to /smack/doi a value that has ever been written there in the past disables networking for non-ambient labels. E.g. # cat /smack/doi 3 # netlabelctl -p cipso list Configured CIPSO mappings (1) DOI value : 3 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (3) domain: "_" (IPv4) protocol: UNLABELED domain: DEFAULT (IPv4) protocol: CIPSO, DOI = 3 domain: DEFAULT (IPv6) protocol: UNLABELED # cat /smack/ambient _ # cat /proc/$$/attr/smack/current _ # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.964 ms # echo foo >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.956 ms unknown option 86 # echo 4 >/smack/doi # echo 3 >/smack/doi !> [ 214.050395] smk_cipso_doi:691 cipso add rc = -17 # echo 3 >/smack/doi !> [ 249.402261] smk_cipso_doi:678 remove rc = -2 !> [ 249.402261] smk_cipso_doi:691 cipso add rc = -17 # ping -c1 10.1.95.12 !!> ping: 10.1.95.12: Address family for hostname not supported # echo _ >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.617 ms This happens because Smack keeps decommissioned DOIs, fails to re-add them, and consequently refuses to add the “default” domain map: # netlabelctl -p cipso list Configured CIPSO mappings (2) DOI value : 3 mapping type : PASS_THROUGH DOI value : 4 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (2) domain: "_" (IPv4) protocol: UNLABELED !> (no ipv4 map for default domain here) domain: DEFAULT (IPv6) protocol: UNLABELED Fix by clearing decommissioned DOI definitions and serializing concurrent DOI updates with a new lock. Also: - allow /smack/doi to live unconfigured, since adding a map (netlbl_cfg_cipsov4_map_add) may fail. CIPSO_V4_DOI_UNKNOWN(0) indicates the unconfigured DOI - add new DOI before removing the old default map, so the old map remains if the add fails (2008-02-04, Casey Schaufler) Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit cb59ae56199526612643f119e3c880a78e202d4e Author: Konstantin Andreev Date: Tue Sep 30 15:16:02 2025 +0300 smack: /smack/doi must be > 0 [ Upstream commit 19c013e1551bf51e1493da1270841d60e4fd3f15 ] /smack/doi allows writing and keeping negative doi values. Correct values are 0 < doi <= (max 32-bit positive integer) (2008-02-04, Casey Schaufler) Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit da3be3289ecfadc831db49aac9e2b07a25b146b5 Author: Ketil Johnsen Date: Fri Dec 19 10:35:44 2025 +0100 drm/panthor: Evict groups before VM termination [ Upstream commit 565ed40b5fc1242f7538a016fce5a85f802d4fb5 ] Ensure all related groups are evicted and suspended before VM destruction takes place. This fixes an issue where panthor_vm_destroy() destroys and unmaps the heap context while there are still on slot groups using this. The FW will do a write out to the heap context when a CSG (group) is suspended, so a premature unmap of the heap context will cause a GPU page fault. This page fault is quite harmless, and do not affect the continued operation of the GPU. Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block") Reviewed-by: Boris Brezillon Signed-off-by: Ketil Johnsen Reviewed-by: Liviu Dudau Reviewed-by: Steven Price Link: https://patch.msgid.link/20251219093546.1227697-1-ketil.johnsen@arm.com Co-developed-by: Boris Brezillon Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 956cc8a74f410264d6c8783092929d0fcfcedc1d Author: Simon Trimmer Date: Tue Dec 16 14:22:04 2025 +0000 ASoC: SDCA: Allow sample width wild cards in set_usage() [ Upstream commit 87783532d34050e2bff6749a4fe9860e624a0540 ] The SDCA spec allows the sample rate and width to be wild cards, but the current implementation of set_usage() only checked for a wild card of the sample rate. Fixes: 4ed357f72a0e ("ASoC: SDCA: Add hw_params() helper function") Signed-off-by: Simon Trimmer Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20251216142204.183958-1-simont@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fa3b263c4de3edb8d3fa34e88ec70d348de02c52 Author: Takashi Iwai Date: Tue Dec 16 15:06:30 2025 +0100 ALSA: vmaster: Relax __free() variable declarations [ Upstream commit 3b7c7bda39e1e48f926fb3d280a5f5d20a939857 ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Fixes: fb9e197f3f27 ("ALSA: vmaster: Use automatic cleanup of kfree()") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-9-tiwai@suse.de Signed-off-by: Sasha Levin commit ed9acd01e907fa0d6d5224b03be2a188c5949d92 Author: Takashi Iwai Date: Tue Dec 16 15:06:25 2025 +0100 ALSA: pcm: Relax __free() variable declarations [ Upstream commit f3d233daf011abbad2f6ebd0e545b42d2f378a4f ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Fixes: ae9213984864 ("ALSA: pcm: Use automatic cleanup of kfree()") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-4-tiwai@suse.de Signed-off-by: Sasha Levin commit 082aba8e3aab961fc4d26a14dbfa397a23eb3978 Author: David Heidelberg Date: Sun Dec 14 15:51:21 2025 +0100 drm/panel: sw43408: Remove manual invocation of unprepare at remove [ Upstream commit cbc1e99a9e0a6c8b22ddcbb40ca37457066f9493 ] The drm_panel_remove should take care of disable/unprepare. Remove the manual call from the sw43408_remove function. Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver") Reviewed-by: Dmitry Baryshkov Signed-off-by: David Heidelberg Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20251214-pixel-3-v7-5-b1c0cf6f224d@ixit.cz Signed-off-by: Sasha Levin commit 5b295f0133935e1693ecb7b3afeb6e2d88e8c77a Author: Lizhi Hou Date: Wed Dec 10 20:51:25 2025 -0800 accel/amdxdna: Fix race where send ring appears full due to delayed head update [ Upstream commit 343f5683cfa443000904c88ce2e23656375fc51c ] The firmware sends a response and interrupts the driver before advancing the mailbox send ring head pointer. As a result, the driver may observe the response and attempt to send a new request before the firmware has updated the head pointer. In this window, the send ring still appears full, causing the driver to incorrectly fail the send operation. This race can be triggered more easily in a multithreaded environment, leading to unexpected and spurious "send ring full" failures. To address this, poll the send ring head pointer for up to 100us before returning a full-ring condition. This allows the firmware time to update the head pointer. Fixes: b87f920b9344 ("accel/amdxdna: Support hardware mailbox") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20251211045125.1724604-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 0b0d8ed13d292f7de564b71f83c17c327a07ee32 Author: Boris Brezillon Date: Mon Dec 8 11:08:29 2025 +0100 drm/panthor: Fix panthor_gpu_coherency_set() [ Upstream commit 9beb8dca9e749e9983e70b22e9823e6fcd519f91 ] GPU_COHERENCY_PROTOCOL takes one of GPU_COHERENCY_xx not BIT(GPU_COHERENCY_xx). v3: - New commit v4: - Add Steve's R-b v5: - No changes v6: - No changes v7: - No changes v8: - No changes Cc: Akash Goel Fixes: dd7db8d911a1 ("drm/panthor: Explicitly set the coherency mode") Reported-by: Steven Price Reviewed-by: Steven Price Link: https://patch.msgid.link/20251208100841.730527-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit d8d97352bf5d5995e24670c176846795b93dbfe7 Author: Lai Jiangshan Date: Mon Dec 8 21:25:18 2025 +0800 workqueue: Process rescuer work items one-by-one using a cursor [ Upstream commit e5a30c303b07a4d6083e0f7f051b53add6d93c5d ] Previously, the rescuer scanned for all matching work items at once and processed them within a single rescuer thread, which could cause one blocking work item to stall all others. Make the rescuer process work items one-by-one instead of slurping all matches in a single pass. Break the rescuer loop after finding and processing the first matching work item, then restart the search to pick up the next. This gives normal worker threads a chance to process other items which gives them the opportunity to be processed instead of waiting on the rescuer's queue and prevents a blocking work item from stalling the rest once memory pressure is relieved. Introduce a dummy cursor work item to avoid potentially O(N^2) rescans of the work list. The marker records the resume position for the next scan, eliminating redundant traversals. Also introduce RESCUER_BATCH to control the maximum number of work items the rescuer processes in each turn, and move on to other PWQs when the limit is reached. Cc: ying chen Reported-by: ying chen Fixes: e22bee782b3b ("workqueue: implement concurrency managed dynamic worker pool") Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 5ec7110f5ed405c437a8cc58538ae0322362f33f Author: Lai Jiangshan Date: Fri Nov 21 22:57:15 2025 +0800 workqueue: Only assign rescuer work when really needed [ Upstream commit 7b05c90b3302cf3d830dfa6f8961376bcaf43b94 ] If the pwq does not need rescue (normal workers have been created or become available), the rescuer can immediately move on to other stalled pwqs. Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo Stable-dep-of: e5a30c303b07 ("workqueue: Process rescuer work items one-by-one using a cursor") Signed-off-by: Sasha Levin commit 932c36b81325bcabbb90865697c64584202f6858 Author: Lai Jiangshan Date: Fri Nov 21 22:57:14 2025 +0800 workqueue: Factor out assign_rescuer_work() [ Upstream commit 99ed6f62a46e91dc796b785618d646eeded1b230 ] Move the code to assign work to rescuer and assign_rescuer_work(). Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo Stable-dep-of: e5a30c303b07 ("workqueue: Process rescuer work items one-by-one using a cursor") Signed-off-by: Sasha Levin commit 8c66adcae91b3898be43fa0c830278543d7c7ba5 Author: Boris Brezillon Date: Fri Nov 28 10:48:38 2025 +0100 drm/panthor: Make sure we resume the tick when new jobs are submitted [ Upstream commit 99820b4b7e50d9651f01d2d55b6b9ba92dcc5b99 ] If the group is already assigned a slot but was idle before this job submission, we need to make sure the priority rotation happens in the future. Extract the existing logic living in group_schedule_locked() and call this new sched_resume_tick() helper from the "group is assigned a slot" path. v2: - Add R-b v3: - Re-use queue_mask to clear the bit - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251128094839.3856402-8-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit d2f485242e3116d3c2da7e02462df7a0eb4a62ae Author: Boris Brezillon Date: Fri Nov 28 10:48:37 2025 +0100 drm/panthor: Fix the logic that decides when to stop ticking [ Upstream commit 61d9a43d70dc3e1709ecd14a34f6d5f01e21dfc9 ] When we have multiple active groups with the same priority, we need to keep ticking for the priority rotation to take place. If we don't do that, we might starve slots with lower priorities. It's annoying to deal with that in tick_ctx_update_resched_target(), so let's add a ::stop_tick field to the tick context which is initialized to true, and downgraded to false as soon as we detect something that requires to tick to happen. This way we can complement the current logic with extra conditions if needed. v2: - Add R-b v3: - Drop panthor_sched_tick_ctx::min_priority (no longer relevant) - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251128094839.3856402-7-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit ef100b8e257b62905c9af20f1df83017613b1713 Author: Boris Brezillon Date: Fri Nov 28 10:48:36 2025 +0100 drm/panthor: Fix immediate ticking on a disabled tick [ Upstream commit 4356d21994f4ff5c87305b874939b359f16f6677 ] We have a few paths where we schedule the tick work immediately without changing the resched_target. If the tick was stopped, this would lead to a remaining_jiffies that's always > 0, and it wouldn't force a full tick in that case. Add extra checks to cover that case properly. v2: - Fix typo - Simplify the code as suggested by Steve v3: - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251128094839.3856402-6-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 73f2614637f642f96d2c82dde83250a3986f396d Author: Boris Brezillon Date: Fri Nov 28 10:48:35 2025 +0100 drm/panthor: Fix the group priority rotation logic [ Upstream commit 55429c51d5db3db24c2ad561944c6a0ca922d476 ] When rotating group priorities, we want the group with the highest priority to go back to the end of the queue, and all other active groups to get their priority bumped, otherwise some groups will never get a chance to run with the highest priority. This implies moving the rotation itself to tick_work(), and only dealing with old group ordering in tick_ctx_insert_old_group(). v2: - Add R-b - Fix the commit message v3: - Drop the full_tick argument in tick_ctx_init() - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251128094839.3856402-5-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 693a04f41a54b27cef92e775f9bff0499f595001 Author: Boris Brezillon Date: Fri Nov 28 10:48:34 2025 +0100 drm/panthor: Fix the full_tick check [ Upstream commit a3c2d0b40b108bd45d44f6c1dfa33c39d577adcd ] We have a full tick when the remaining time to the next tick is zero, not the other way around. Declare a full_tick variable so we don't get that test wrong in other places. v2: - Add R-b v3: - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251128094839.3856402-4-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 57753f2c64c033a21a7400b3a2192db1cd6c890e Author: Boris Brezillon Date: Fri Nov 28 09:48:37 2025 +0100 drm/panthor: Recover from panthor_gpu_flush_caches() failures [ Upstream commit 3c0a60195b37af83bbbaf223cd3a78945bace49e ] We have seen a few cases where the whole memory subsystem is blocked and flush operations never complete. When that happens, we want to: - schedule a reset, so we can recover from this situation - in the reset path, we need to reset the pending_reqs so we can send new commands after the reset - if more panthor_gpu_flush_caches() operations are queued after the timeout, we skip them and return -EIO directly to avoid needless waits (the memory block won't miraculously work again) Note that we drop the WARN_ON()s because these hangs can be triggered with buggy GPU jobs created by the UMD, and there's no way we can prevent it. We do keep the error messages though. v2: - New patch v3: - Collect R-b - Explicitly mention the fact we dropped the WARN_ON()s in the commit message v4: - No changes Fixes: 5cd894e258c4 ("drm/panthor: Add the GPU logical block") Reviewed-by: Steven Price Link: https://patch.msgid.link/20251128084841.3804658-4-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit da9c1afd9991e591b987e3ecc5fe237357ce25a7 Author: Junhui Liu Date: Sat Jan 17 18:06:22 2026 +0800 reset: canaan: k230: drop OF dependency and enable by default [ Upstream commit c7a5e01e229d21e0560d78bd645b4f7398667ce4 ] The driver doesn't use any symbols depending on CONFIG_OF, so drop the dependency. Also, enable it by default when ARCH_CANAAN is selected. Fixes: 360a7a647759 ("reset: canaan: add reset driver for Kendryte K230") Signed-off-by: Junhui Liu Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit 3c0dd95dd520822ef45c6d9235fe24ca3ffd6e6c Author: Konrad Dybcio Date: Mon Dec 29 21:47:41 2025 +0100 arm64: dts: qcom: sm6115: Add CX_MEM/DBGC GPU regions [ Upstream commit 78c13dac18cf0e6f6cbc6ea85d4f967e6cca9562 ] Describe the GPU register regions, with the former existing but not being used much if at all on this silicon, and the latter containing various debugging levers generally related to dumping the state of the IP upon a crash. Fixes: 11750af256f8 ("arm64: dts: qcom: sm6115: Add GPU nodes") Reported-by: Krzysztof Kozlowski Closes: https://lore.kernel.org/linux-arm-msm/8a64f70b-8034-45e7-86a3-0015cf357132@oss.qualcomm.com/T/#m404f1425c36b61467760f058b696b8910340a063 Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Akhil P Oommen Link: https://lore.kernel.org/r/20251229-topic-6115_2290_gpu_dbgc-v1-3-4a24d196389c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 58c0b917fdca3a6052d61bd1df140ea6e8a22763 Author: Konrad Dybcio Date: Mon Dec 29 21:47:40 2025 +0100 arm64: dts: qcom: agatti: Add CX_MEM/DBGC GPU regions [ Upstream commit 0fdcc948929a6d673bd0f90631dd6e42090c3dbd ] Describe the GPU register regions, with the former existing but not being used much if at all on this silicon, and the latter containing various debugging levers generally related to dumping the state of the IP upon a crash. Fixes: 4faeef52c8e6 ("arm64: dts: qcom: qcm2290: Add GPU nodes") Reported-by: Krzysztof Kozlowski Closes: https://lore.kernel.org/linux-arm-msm/8a64f70b-8034-45e7-86a3-0015cf357132@oss.qualcomm.com/T/#m404f1425c36b61467760f058b696b8910340a063 Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Akhil P Oommen Link: https://lore.kernel.org/r/20251229-topic-6115_2290_gpu_dbgc-v1-2-4a24d196389c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 222e45e64bbca35147676a70b0ce750ab38d77e1 Author: Viken Dadhaniya Date: Tue Nov 11 22:33:50 2025 +0530 arm64: dts: qcom: talos: Drop opp-shared from QUP OPP table [ Upstream commit dda4bdd325326dd67ae4401f4f3d35b9cf781e3f ] QUP devices are currently marked with opp-shared in their OPP table, causing the kernel to treat them as part of a shared OPP domain. This leads to the qcom_geni_serial driver failing to probe with error -EBUSY (-16). Remove the opp-shared property to ensure the OPP framework treats the QUP OPP table as device-specific, allowing the serial driver to probe successfully Fixes: f6746dc9e379 ("arm64: dts: qcom: qcs615: Add QUPv3 configuration") Signed-off-by: Viken Dadhaniya Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251111170350.525832-1-viken.dadhaniya@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 37082c9b418d41c2fd01f2e88b3348046ad370fb Author: Jonathan Marek Date: Thu Nov 27 16:29:42 2025 -0500 arm64: dts: qcom: x1e: bus is 40-bits (fix 64GB models) [ Upstream commit b38dd256e11a4c8bd5a893e11fc42d493939c907 ] Unlike the phone SoCs this was copied from, x1e has a 40-bit physical bus. The upper address space is used to support more than 32GB of memory. This fixes issues when DMA buffers are allocated outside the 36-bit range. Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts") Signed-off-by: Jonathan Marek Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251127212943.24480-1-jonathan@marek.ca Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 06557d72ea40ccc1e72257249e8412b257042b93 Author: Dmitry Baryshkov Date: Tue Jan 6 03:01:18 2026 +0200 arm64: dts: qcom: sdm845-db845c: specify power for WiFi CH1 [ Upstream commit c303e89f7f17c29981d09f8beaaf60937ae8b1f2 ] Specify power supply for the second chain / antenna output of the onboard WiFi chip. Fixes: 3f72e2d3e682 ("arm64: dts: qcom: Add Dragonboard 845c") Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260106-wcn3990-pwrctl-v2-8-0386204328be@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 39974be66f8173cd7fe11b59081bdf3683cd4566 Author: Dmitry Baryshkov Date: Tue Jan 6 03:01:17 2026 +0200 arm64: dts: qcom: sdm845-db845c: drop CS from SPIO0 [ Upstream commit 8bfb696ccdc5bcfad7a45b84c2c8a36757070e19 ] On SDM845 SPI uses hardware-provided chip select, while specifying cs-gpio makes the driver request GPIO pin, which on DB845c conflicts with the normal host controllers pinctrl entry. Drop the cs-gpios property to restore SPI functionality. Fixes: cb29e7106d4e ("arm64: dts: qcom: db845c: Add support for MCP2517FD") Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260106-wcn3990-pwrctl-v2-7-0386204328be@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2d7ea0516f2beced16bf51aefc8c8aa214294df9 Author: Dmitry Baryshkov Date: Tue Jan 6 03:01:16 2026 +0200 arm64: dts: qcom: qrb4210-rb2: Fix UART3 wakeup IRQ storm [ Upstream commit c5dc4812f6bf397b82290c540085e9ec98b47b30 ] Follow commit 9c92d36b0b1e ("arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm") and apply the similar fix to the RB2 platform. Having RX / TX pins as pull up and wakup interrupt as high-level triggered generates an interrupt storm when trying to suspend the device. Avoid the storm by using the falling edge trigger (as all other platforms do). Fixes: cab60b166575 ("arm64: dts: qcom: qrb4210-rb2: Enable bluetooth") Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260106-wcn3990-pwrctl-v2-6-0386204328be@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 33bc5e10165d5239e469bcfa6efee0f13c0f7a36 Author: Jerome Brunet Date: Wed Jan 14 18:08:53 2026 +0100 arm64: dts: amlogic: g12: assign the MMC A signal clock [ Upstream commit 3c941feaa363f1573a501452391ddf513394c84b ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. Assign the clock to make sure it is properly configured Fixes: 8a6b3ca2d361 ("arm64: dts: meson: g12a: add SDIO controller") Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-mmc-clocks-followup-v1-6-a999fafbe0aa@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 844317f9b007587055b44c541a87ad9f49df55c4 Author: Jerome Brunet Date: Wed Jan 14 18:08:52 2026 +0100 arm64: dts: amlogic: g12: assign the MMC B and C signal clocks [ Upstream commit be2ff5fdb0e83e32d4ec4e68a69875cec0d14621 ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. Assign the clocks to make sure they are properly configured Fixes: 4759fd87b928 ("arm64: dts: meson: g12a: add mmc nodes") Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-mmc-clocks-followup-v1-5-a999fafbe0aa@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 0709a0901956c3465d63046f6a9cb80a105aa5ef Author: Jerome Brunet Date: Wed Jan 14 18:08:51 2026 +0100 arm64: dts: amlogic: gx: assign the MMC signal clocks [ Upstream commit 406706559046eebc09a31e8ae5e78620bfd746fe ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. Assign the clocks to make sure they are properly configured Fixes: 50662499f911 ("ARM64: dts: meson-gx: Use correct mmc clock source 0") Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-mmc-clocks-followup-v1-4-a999fafbe0aa@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit c9bb634897e337b0d4502b2430624fa9e789b6ed Author: Jerome Brunet Date: Wed Jan 14 18:08:50 2026 +0100 arm64: dts: amlogic: axg: assign the MMC signal clocks [ Upstream commit 13d3fe2318ef6e46d6fcfe13bc373827fdf2aeac ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. Assign the clocks to make sure they are properly configured Fixes: 221cf34bac54 ("ARM64: dts: meson-axg: enable the eMMC controller") Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-mmc-clocks-followup-v1-3-a999fafbe0aa@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit f6e54c1ea7b84f8fcb32a4205bb421d32c769bcd Author: Jerome Brunet Date: Wed Jan 14 18:08:48 2026 +0100 arm64: dts: amlogic: c3: assign the MMC signal clocks [ Upstream commit 69330fd2368371c4eb47d60ace6bca09763d24a0 ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. Assign the clocks to make sure they are properly configured Fixes: 520b792e8317 ("arm64: dts: amlogic: add some device nodes for C3") Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-mmc-clocks-followup-v1-1-a999fafbe0aa@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 6cc29c7148550fdca590ae3b731734fe138307fc Author: Haotian Zhang Date: Mon Nov 24 18:48:05 2025 +0800 hwspinlock: omap: Handle devm_pm_runtime_enable() errors [ Upstream commit 3bd4edd67b034f8e1f61c86e0eb098de6179e3f2 ] Although unlikely, devm_pm_runtime_enable() can fail due to memory allocations. Without proper error handling, the subsequent pm_runtime_resume_and_get() call may operate on incorrectly initialized runtime PM state. Add error handling to check the return value of devm_pm_runtime_enable() and return on failure. Fixes: 25f7d74d4514 ("hwspinlock: omap: Use devm_pm_runtime_enable() helper") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20251124104805.135-1-vulab@iscas.ac.cn Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit eeb84c4f43372eeadc360a6bf7cacd13ff23037e Author: Dmitry Baryshkov Date: Sat Jan 10 21:37:53 2026 +0200 soc: qcom: ubwc: add missing include [ Upstream commit ccef4b2703ff5b0de0b1bda30a0de3026d52eb19 ] The header has a function which calls pr_err(). Don't require users of the header to include and include it here. Fixes: 87cfc79dcd60 ("drm/msm/a6xx: Resolve the meaning of UBWC_MODE") Signed-off-by: Dmitry Baryshkov Reviewed-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20260110-iris-ubwc-v1-1-dd70494dcd7b@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6906a9889898934770e3386190e631c847359879 Author: Abhash Kumar Jha Date: Mon Jan 12 14:21:13 2026 +0530 arm64: dts: ti: k3-j784s4-j742s2-main-common.dtsi: Refactor watchdog instances for j784s4 [ Upstream commit 61acc4428a7f52e0a13e226ba76f2ce2ca66c065 ] Each A72 core has one watchdog instance associated with it. Since j742s2 has 4 A72 cores, the common file should not define 8 watchdog instances. Refactor the last 4 extra watchdogs from the common file to j784s4 specific file, as j784s4 has 8 A72 cores and thus hardware description requires 8 watchdog instances. Fixes: 9cc161a4509c ("arm64: dts: ti: Refactor J784s4 SoC files to a common file") Signed-off-by: Abhash Kumar Jha Reviewed-by: Udit Kumar Link: https://patch.msgid.link/20260112085113.3476193-3-a-kumar2@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 8273989e774abdf6504094b52b33d6852ad73c10 Author: Abhash Kumar Jha Date: Mon Jan 12 14:21:12 2026 +0530 arm64: dts: ti: k3-j784s4-main.dtsi: Move c71_3 node to appropriate order [ Upstream commit 24c9d5fb8bbf5e8c9e6fc2beffeb80ac2da83de4 ] The device tree nodes should be ordered by unit addresses in ascending order. Correct the order by moving the c71_3 DSP node at the end as it has a higher unit address. Signed-off-by: Abhash Kumar Jha Reviewed-by: Udit Kumar Link: https://patch.msgid.link/20260112085113.3476193-2-a-kumar2@ti.com Signed-off-by: Nishanth Menon Stable-dep-of: 61acc4428a7f ("arm64: dts: ti: k3-j784s4-j742s2-main-common.dtsi: Refactor watchdog instances for j784s4") Signed-off-by: Sasha Levin commit 1f71dfc03471bf489f973fac134042c137964016 Author: Jerome Brunet Date: Wed Jan 14 11:43:12 2026 +0100 arm64: dts: amlogic: s4: fix mmc clock assignment [ Upstream commit 3a115d42922cffc91b303992eadf220111d66c31 ] MMC A and C are mis-represented as having their "clkin0" input connected to xtal while it is actually connected to the MMC clock, probably in an attempt to provide 24MHz to the device on this input. Fix this and assign the clock to 24MHz to actually provide the required rate. Fixes: 3ab9d54b5d84 ("arm64: dts: amlogic: enable some device nodes for S4") Tested-by: Nick Xie Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-s4-mmc-fixup-v3-2-a4d3e136b3f2@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 5a5ec520e74012637f141879fe21d4c371371063 Author: Jerome Brunet Date: Wed Jan 14 11:43:11 2026 +0100 arm64: dts: amlogic: s4: assign mmc b clock to 24MHz [ Upstream commit 86124a8becb43eed3103f2459399daee8af2c99d ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. This assumption did hold true until but it now, but it is apparently not the case with s4. The clock has been reported to provide 1GHz instead. This is most likely due to how the bootloader is using the MMC clock on this platform. Regardless of why the MMC clock rate is 1GHz, if the MMC driver expects 24MHz, the clock should be properly assigned, so assign it. Reported-by: Nick Xie Closes: https://lore.kernel.org/linux-amlogic/20260113011931.40424-1-nick@khadas.com/ Fixes: 3ab9d54b5d84 ("arm64: dts: amlogic: enable some device nodes for S4") Tested-by: Nick Xie Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-s4-mmc-fixup-v3-1-a4d3e136b3f2@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 85cf4f7c2cf22fed8763927e909be6bd25cd3fb6 Author: AngeloGioacchino Del Regno Date: Fri Jan 9 12:47:41 2026 +0100 arm64: dts: mediatek: mt8183-jacuzzi-pico6: Fix typo in pinmux node [ Upstream commit b1fc81a986c9b8089db31e21a372cc8b6514e900 ] Rename "piins-bt-wakeup" to "pins-bt-wakeup" to fix a dtbs_check warning happening due to this typo. Fixes: 055ef10ccdd4 ("arm64: dts: mt8183: Add jacuzzi pico/pico6 board") Reviewed-by: Chen-Yu Tsai Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 6666c9d544323a49f862f5de55c68c5ff40cd91b Author: Vladimir Zapolskiy Date: Mon Dec 29 00:49:07 2025 +0200 arm: dts: lpc32xx: add clocks property to Motor Control PWM device tree node [ Upstream commit 71630e581a0e34c03757f5c1706f57c853b92555 ] Motor Control PWM depends on its own supply clock, the clock gate control is present in TIMCLK_CTRL1 register. Fixes: b7d41c937ed7 ("ARM: LPC32xx: Add the motor PWM to base dts file") Signed-off-by: Vladimir Zapolskiy Signed-off-by: Sasha Levin commit bcab50ed6e73cf6307da13386a16cfa8723bb28e Author: Lad Prabhakar Date: Tue Jan 6 13:13:19 2026 +0000 arm64: dts: renesas: rzt2h-n2h-evk-common: Use GPIO for SD0 write protect [ Upstream commit a1b1ee0348f889ec262482e16e9ff670617db7b0 ] Switch SD0 write-protect detection to a GPIO on the RZ/T2H and RZ/N2H EVKs. Both boards use a full-size SD card slot on the SD0 channel with a dedicated WP pin. The RZ/T2H and RZ/N2H SoCs use of_data_rcar_gen3, which sets MMC_CAP2_NO_WRITE_PROTECT and causes the core to ignore the WP signal unless a wp-gpios property is provided. Describe the WP pin as a GPIO to allow the MMC core to evaluate the write-protect status correctly. Fixes: d065453e5ee0 ("arm64: dts: renesas: rzt2h-rzn2h-evk: Enable SD card slot") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260106131319.643084-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 6e6561231c6cfc32c5631aeecc0928ff2b14265c Author: Narayana Murty N Date: Wed Dec 10 08:25:59 2025 -0600 powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event handling [ Upstream commit 815a8d2feb5615ae7f0b5befd206af0b0160614c ] The recent commit 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") restructured the EEH driver to improve synchronization with the PCI hotplug layer. However, it inadvertently moved pci_lock_rescan_remove() outside its intended scope in eeh_handle_normal_event(), leading to broken PCI error reporting and improper EEH event triggering. Specifically, eeh_handle_normal_event() acquired pci_lock_rescan_remove() before calling eeh_pe_bus_get(), but eeh_pe_bus_get() itself attempts to acquire the same lock internally, causing nested locking and disrupting normal EEH event handling paths. This patch adds a boolean parameter do_lock to _eeh_pe_bus_get(), with two public wrappers: eeh_pe_bus_get() with locking enabled. eeh_pe_bus_get_nolock() that skips locking. Callers that already hold pci_lock_rescan_remove() now use eeh_pe_bus_get_nolock() to avoid recursive lock acquisition. Additionally, pci_lock_rescan_remove() calls are restored to the correct position—after eeh_pe_bus_get() and immediately before iterating affected PEs and devices. This ensures EEH-triggered PCI removes occur under proper bus rescan locking without recursive lock contention. The eeh_pe_loc_get() function has been split into two functions: eeh_pe_loc_get(struct eeh_pe *pe) which retrieves the loc for given PE. eeh_pe_loc_get_bus(struct pci_bus *bus) which retrieves the location code for given bus. This resolves lockdep warnings such as: [ 84.964298] [ T928] ============================================ [ 84.964304] [ T928] WARNING: possible recursive locking detected [ 84.964311] [ T928] 6.18.0-rc3 #51 Not tainted [ 84.964315] [ T928] -------------------------------------------- [ 84.964320] [ T928] eehd/928 is trying to acquire lock: [ 84.964324] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964342] [ T928] but task is already holding lock: [ 84.964347] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964357] [ T928] other info that might help us debug this: [ 84.964363] [ T928] Possible unsafe locking scenario: [ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] [ T928] lock(pci_rescan_remove_lock); [ 84.964378] [ T928] lock(pci_rescan_remove_lock); [ 84.964383] [ T928] *** DEADLOCK *** [ 84.964388] [ T928] May be due to missing lock nesting notation [ 84.964393] [ T928] 1 lock held by eehd/928: [ 84.964397] [ T928] #0: c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964408] [ T928] stack backtrace: [ 84.964414] [ T928] CPU: 2 UID: 0 PID: 928 Comm: eehd Not tainted 6.18.0-rc3 #51 VOLUNTARY [ 84.964417] [ T928] Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_022) hv:phyp pSeries [ 84.964419] [ T928] Call Trace: [ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130 (unreliable) [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440 [ 84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] __mutex_lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pci_lock_rescan_remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh_pe_bus_get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c000000000050434] eeh_handle_normal_event+0x64/0xa60 [ 84.964446] [ T928] [c0000011a7157f30] [c000000000051de8] eeh_event_handler+0xf8/0x190 [ 84.964450] [ T928] [c0000011a7157f90] [c0000000002747ac] kthread+0x16c/0x180 [ 84.964453] [ T928] [c0000011a7157fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Fixes: 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") Signed-off-by: Narayana Murty N Reviewed-by: Sourabh Jain Reviewed-by: Mahesh Salgaonkar Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20251210142559.8874-1-nnmlinux@linux.ibm.com Signed-off-by: Sasha Levin commit 0f6498077faa9cd89bb787bcc57063494a6f0601 Author: Zilin Guan Date: Sun Dec 28 16:26:36 2025 +0000 soc: mediatek: svs: Fix memory leak in svs_enable_debug_write() [ Upstream commit 6259094ee806fb813ca95894c65fb80e2ec98bf1 ] In svs_enable_debug_write(), the buf allocated by memdup_user_nul() is leaked if kstrtoint() fails. Fix this by using __free(kfree) to automatically free buf, eliminating the need for explicit kfree() calls and preventing leaks. Fixes: 13f1bbcfb582 ("soc: mediatek: SVS: add debug commands") Co-developed-by: Jianhao Xu Signed-off-by: Jianhao Xu Signed-off-by: Zilin Guan [Angelo: Added missing cleanup.h inclusion] Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 3eeda22d52ff9defd3018726d92c85e55bed4988 Author: Haotian Zhang Date: Tue Dec 16 09:39:32 2025 +0800 soc: qcom: cmd-db: Use devm_memremap() to fix memory leak in cmd_db_dev_probe [ Upstream commit 0da7824734d8d83e6a844dd0207f071cb0c50cf4 ] If cmd_db_magic_matches() fails after memremap() succeeds, the function returns -EINVAL without unmapping the memory region, causing a potential resource leak. Switch to devm_memremap to automatically manage the map resource. Fixes: 312416d9171a ("drivers: qcom: add command DB driver") Suggested-by: Dmitry Baryshkov Signed-off-by: Haotian Zhang Link: https://lore.kernel.org/r/20251216013933.773-1-vulab@iscas.ac.cn Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1b39dbd7761d51f4f5d08c414583ee924bd8c29b Author: Christophe Leroy Date: Wed Dec 24 12:20:49 2025 +0100 powerpc/uaccess: Move barrier_nospec() out of allow_read_{from/write}_user() [ Upstream commit 5fbc09eb0b4f4b1a4b33abebacbeee0d29f195e9 ] Commit 74e19ef0ff80 ("uaccess: Add speculation barrier to copy_from_user()") added a redundant barrier_nospec() in copy_from_user(), because powerpc is already calling barrier_nospec() in allow_read_from_user() and allow_read_write_user(). But on other architectures that call to barrier_nospec() was missing. So change powerpc instead of reverting the above commit and having to fix other architectures one by one. This is now possible because barrier_nospec() has also been added in copy_from_user_iter(). Move barrier_nospec() out of allow_read_from_user() and allow_read_write_user(). This will also allow reuse of those functions when implementing masked user access which doesn't require barrier_nospec(). Don't add it back in raw_copy_from_user() as it is already called by copy_from_user() and copy_from_user_iter(). Fixes: 74e19ef0ff80 ("uaccess: Add speculation barrier to copy_from_user()") Signed-off-by: Christophe Leroy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/f29612105c5fcbc8ceb7303808ddc1a781f0f6b5.1766574657.git.chleroy@kernel.org Signed-off-by: Sasha Levin commit 3ce94bf05945c8896bdd28c02ad407afe1de4143 Author: Chen-Yu Tsai Date: Thu Dec 25 18:36:14 2025 +0800 ARM: dts: allwinner: sun5i-a13-utoo-p66: delete "power-gpios" property [ Upstream commit 0b2761eb1287bd9f62367cccf6626eb3107cef6f ] The P66's device tree includes the reference design dtsi files, which defines a node and properties for the touchpanel in the common design. The P66 dts file then overrides all the properties to match its own design, but as the touchpanel model is different, a different schema is matched. This other schema uses a different name for the GPIO. The original submission added the correct GPIO property, but did not delete the one inherited from the reference design, causing validation errors. Explicitly delete the incorrect GPIO property. Fixes: 2a53aff27236 ("ARM: dts: sun5i: Enable touchscreen on Utoo P66") Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20251225103616.3203473-4-wens@kernel.org Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit db09ba1f9e70405ed9be59c15303cde6213174ab Author: Vladimir Zapolskiy Date: Fri Dec 26 02:39:23 2025 +0200 arm64: dts: qcom: msm8994-octagon: Fix Analog Devices vendor prefix of AD7147 [ Upstream commit 7db5fbe508deedec6c183d5056cf3c504c027f40 ] Trivial change, Analog Devices vendor prefix is "adi", but there is a valid "ad" vendor prefix of another company, this may explain why the issue hasn't been discovered by the automatic tests. A problem of not described compatible value is out of this change scope. Fixes: c636eeb751f6 ("arm64: dts: qcom: msm8994-octagon: Add AD7147 and APDS9930 sensors") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20251226003923.3341904-1-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9bbee82bacb9032af0d2826a7e97d4febe6789d4 Author: Geert Uytterhoeven Date: Tue Nov 25 17:52:06 2025 +0100 arm64: dts: renesas: r9a09g047e57-smarc: Remove duplicate SW_LCD_EN [ Upstream commit 44cfd102ce28e749a07bb0f1668cf932077b1175 ] SW_LCD_EN is defined twice. Fixes: 9e95446b0cf93a91 ("arm64: dts: renesas: r9a09g047e57-smarc: Add gpio keys") Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/1f93558c62f4461f50935644ec831a7d2cb52630.1764089463.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 480374c75c675a10097fbd6d2102697de6e753d7 Author: Abel Vesa Date: Mon Nov 3 18:51:40 2025 +0200 arm64: dts: qcom: x1e80100: Fix USB combo PHYs SS1 and SS2 ref clocks [ Upstream commit 3af51501e2b8c87564b5cda43b0e5c316cf54717 ] It seems the USB combo SS1 and SS2 ref clocks have another gate, unlike the SS0. These gates are part of the TCSR clock controller. At least on Dell XPS 13 (9345), if the ref clock provided by the TCSR clock controller for SS1 PHY is disabled on the clk_disable_unused late initcall, the PHY fails to initialize. It doesn't happen on the SS0 PHY and the SS2 is not used on this device. This doesn't seem to be a problem on CRD though. It might be that the RPMh has a vote for it from some other consumer and does not actually disable it when ther kernel drops its vote. Either way, these TCSR provided clocks seem to be the correct ones for the SS1 and SS2, so use them instead. Fixes: 4af46b7bd66f ("arm64: dts: qcom: x1e80100: Add USB nodes") Signed-off-by: Abel Vesa Reviewed-by: Neil Armstrong Reviewed-by: Taniya Das Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251103-dts-qcom-x1e80100-fix-combo-ref-clks-v1-1-f395ec3cb7e8@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 02d580c9affa52d2f2e097b9b67ca778a4c34468 Author: Casey Connolly Date: Tue Nov 18 15:52:27 2025 +0100 arm64: dts: qcom: sdm845-oneplus: Mark l14a regulator as boot-on [ Upstream commit ad33ee060be46794a03d033894c9db3a9d6c1a0f ] This regulator is used only for the display, which is enabled by the bootloader and left on for continuous splash. Mark it as such. Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices") Signed-off-by: Casey Connolly Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251118-dts-oneplus-regulators-v2-3-3e67cea1e4e7@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7f4d96e1221807774c3b9419864a293f6c7119eb Author: Casey Connolly Date: Tue Nov 18 15:52:26 2025 +0100 arm64: dts: qcom: sdm845-oneplus: Don't keep panel regulator always on [ Upstream commit 45d1f42d3e84b5880cf9fab1eb24a7818320eeb7 ] The panel regulator doesn't need to be always on, so remove this property. Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices") Signed-off-by: Casey Connolly Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251118-dts-oneplus-regulators-v2-2-3e67cea1e4e7@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f5b047a2327185a92111defb13e4328277def39e Author: Casey Connolly Date: Tue Nov 18 15:52:25 2025 +0100 arm64: dts: qcom: sdm845-oneplus: Don't mark ts supply boot-on [ Upstream commit c9b98b9dad9749bf2eb7336a6fca31a6af1039d7 ] The touchscreen isn't enabled by bootloader and doesn't need to be enabled at boot, only when the driver probes, thus remove the regulator-boot-on property. Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices") Signed-off-by: Casey Connolly Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251118-dts-oneplus-regulators-v2-1-3e67cea1e4e7@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 75a3a27e4f825888d3f3a6120518f2587a34eaeb Author: Dmitry Baryshkov Date: Thu Dec 11 03:27:45 2025 +0200 arm64: dts: qcom: sdm630: fix gpu_speed_bin size [ Upstream commit e814796dfcae8905682ac3ac2dd57f512a9f6726 ] Historically sdm630.dtsi has used 1 byte length for the gpu_speed_bin cell, although it spans two bytes (offset 5, size 7 bits). It was being accepted by the kernel because before the commit 7a06ef751077 ("nvmem: core: fix bit offsets of more than one byte") the kernel didn't have length check. After this commit nvmem core rejects QFPROM on sdm630 / sdm660, making GPU and USB unusable on those platforms. Set the size of the gpu_speed_bin cell to 2 bytes, fixing the parsing error. While we are at it, update the length to 8 bits as pointed out by Alexey Minnekhanov. Fixes: b190fb010664 ("arm64: dts: qcom: sdm630: Add sdm630 dts file") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Alexey Minnekhanov Link: https://lore.kernel.org/r/20251211-sdm630-fix-gpu-v2-1-92f0e736dba0@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 97ca54da16f401aec2bb82d6ac82d39b92d1178d Author: Haotian Zhang Date: Wed Dec 17 12:13:38 2025 +0800 clk: qcom: Return correct error code in qcom_cc_probe_by_index() [ Upstream commit 1e07ebe744fb522983bd52a4a6148601675330c7 ] When devm_platform_ioremap_resource() fails, it returns various error codes. Returning a hardcoded -ENOMEM masks the actual failure reason. Use PTR_ERR() to propagate the actual error code returned by devm_platform_ioremap_resource() instead of -ENOMEM. Fixes: 75e0a1e30191 ("clk: qcom: define probe by index API as common API") Signed-off-by: Haotian Zhang Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251217041338.2432-1-vulab@iscas.ac.cn Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 911a473e29c322e4894af1321bacf249dca207c6 Author: Alexander Stein Date: Tue Dec 9 11:53:13 2025 +0100 arm64: dts: tqma8mpql-mba8mp-ras314: Fix HDMI CEC pad control settings [ Upstream commit 53a5c1d98d1155ece4c9446c0fea55e17d08774a ] As per datasheet of the HDMI protection IC the CEC_IC pin has been configured as open-drain. Fixes: ddabb3ce3f90 ("arm64: dts: freescale: add TQMa8MPQL on MBa8MP-RAS314") Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 5a76398d0e03bc5287793320482ecdd7a3bfb686 Author: Alexander Stein Date: Tue Dec 9 11:53:09 2025 +0100 arm64: dts: tqma8mpql-mba8mpxl: Fix HDMI CEC pad control settings [ Upstream commit 8401527abb5e3a00c867b6597b8e1b29c80c9824 ] As per datasheet of the HDMI protection IC the CEC_IC pin has been configured as open-drain. Fixes: 418d1d840e42 ("arm64: dts: freescale: add initial device tree for TQMa8MPQL with i.MX8MP") Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 9fd645784128257fdd558225ddf3056b1a84ff47 Author: Sudeep Holla Date: Thu Dec 18 14:20:01 2025 +0000 firmware: arm_ffa: Correct 32-bit response handling in NOTIFICATION_INFO_GET [ Upstream commit be4d4543f78074fbebd530ba5109d39a2a34e668 ] The FF-A specification allows NOTIFICATION_INFO_GET to return either a 64-bit (FFA_FN64_SUCCESS) or a 32-bit (FFA_SUCCESS) response, depending on whether the firmware chooses the SMC64 or SMC32 calling convention. The driver previously detected the response format by checking ret.a0, but still interpreted the returned ID lists (x3..x17 or w3..w7) as if they always followed the 64-bit SMC64 layout. In the SMC32 case, the upper 32 bits of each argument register are undefined by the calling convention, meaning the driver could read stale or garbage values when parsing notification IDs. This resulted in incorrectly decoded partition/VCPU IDs whenever the FF-A firmware used an SMC32 return path. Fix the issue by: - Introducing logic to map list indices to the correct u16 offsets, depending on whether the response width matches the kernel word size or is a 32-bit response on a 64-bit kernel. - Ensuring that the packed ID list is parsed using the proper layout, avoiding reads from undefined upper halves in the SMC32 case. With this change, NOTIFICATION_INFO_GET now correctly interprets ID list entries regardless of the response width, aligning the driver with the FF-A specification. Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Reported-by: Sourav Mohapatra Message-Id: <20251218142001.2457111-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit f64f4ec804b3e485174d9803d2c732453995eafb Author: Dan Carpenter Date: Tue Dec 9 17:37:04 2025 +0300 EDAC/i5400: Fix snprintf() limit calculation in calculate_dimm_size() [ Upstream commit 72f12683611344853ab030fe7d19b23970ed2bd8 ] The snprintf() can't really overflow because we're writing a max of 42 bytes to a PAGE_SIZE buffer. But my static checker complains because the limit calculation doesn't take the first 11 space characters that we wrote into the buffer into consideration. Fix this for the sake of correctness even though it doesn't affect runtime. Also delete an earlier "space -= n;" which was not used. Fixes: 68d086f89b80 ("i5400_edac: improve debug messages to better represent the filled memory") Signed-off-by: Dan Carpenter Signed-off-by: Tony Luck Reviewed-by: Qiuxu Zhuo Link: https://patch.msgid.link/ccd06b91748e7ed8e33eeb2ff1e7b98700879304.1765290801.git.dan.carpenter@linaro.org Signed-off-by: Sasha Levin commit 3efb54e1201b86bbfb2c5333cfa02221d5e1e010 Author: Dan Carpenter Date: Tue Dec 9 17:36:59 2025 +0300 EDAC/i5000: Fix snprintf() size calculation in calculate_dimm_size() [ Upstream commit 7b5c7e83ac405ff9ecbdd92b37a477f4288f8814 ] The snprintf() can't really overflow because we're writing a max of 42 bytes to a PAGE_SIZE buffer. But the limit calculation doesn't take the first 11 bytes that we wrote into consideration so the limit is not correct. Just fix it for correctness even though it doesn't affect runtime. Fixes: 64e1fdaf55d6 ("i5000_edac: Fix the logic that retrieves memory information") Signed-off-by: Dan Carpenter Signed-off-by: Tony Luck Reviewed-by: Qiuxu Zhuo Link: https://patch.msgid.link/07cd652c51e77aad5a8350e1a7cd9407e5bbe373.1765290801.git.dan.carpenter@linaro.org Signed-off-by: Sasha Levin commit d32e8339e1fda98dec1a948b2c0025440dcf61ef Author: Jorge Ramirez-Ortiz Date: Tue Dec 9 08:45:37 2025 +0100 soc: qcom: smem: handle ENOMEM error during probe [ Upstream commit 0fe01a7955f4fef97e7cc6d14bfc5931c660402b ] Fail the driver probe if the region can't be mapped Signed-off-by: Jorge Ramirez-Ortiz Fixes: 20bb6c9de1b7 ("soc: qcom: smem: map only partitions used by local HOST") Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20251209074610.3751781-1-jorge.ramirez@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4f73486ca822305c1cf5b8ebc0b53a6ab3801a81 Author: Sai Ritvik Tanksalkar Date: Sun Feb 1 13:22:40 2026 +0000 pstore/ram: fix buffer overflow in persistent_ram_save_old() [ Upstream commit 5669645c052f235726a85f443769b6fc02f66762 ] persistent_ram_save_old() can be called multiple times for the same persistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_prz for PSTORE_TYPE_DMESG records). Currently, the function only allocates prz->old_log when it is NULL, but it unconditionally updates prz->old_log_size to the current buffer size and then performs memcpy_fromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_size The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms >= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1) 9. ramoops_get_next_prz() → persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y > X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms >= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied. Fixes: 201e4aca5aa1 ("pstore/ram: Should update old dmesg buffer before reading") Signed-off-by: Sai Ritvik Tanksalkar Link: https://patch.msgid.link/20260201132240.2948732-1-stanksal@purdue.edu Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 119702b7167764c5f246dff7873fa748add73cb3 Author: Larysa Zaremba Date: Tue Feb 3 16:50:58 2026 +0100 selftests/xsk: fix number of Tx frags in invalid packet [ Upstream commit 88af9fefed412e4bea9a1a771cbe6fe347fa3507 ] The issue occurs in TOO_MANY_FRAGS test case when xdp_zc_max_segs is set to an odd number. TOO_MANY_FRAGS test case contains an invalid packet consisting of (xdp_zc_max_segs) frags. Every frag, even the last one has XDP_PKT_CONTD flag set. This packet is expected to be dropped. After that, there is a valid linear packet, which is expected to be received back. Once (xdp_zc_max_segs) is an odd number, the last packet cannot be received, if packet forwarding between Rx and Tx interfaces relies on the ethernet header, e.g. checks for ETH_P_LOOPBACK. Packet is malformed, if all traffic is looped. Turns out, sending function processes multiple invalid frags as if they were in 2-frag packets. So once the invalid mbuf packet contains an odd number of those, the valid packet after gets paired with the previous invalid descriptor, and hence does not get an ethernet header generated, so it is either dropped or malformed. Make invalid packets in verbatim mode always have only a single frag. For such packets, number of frags is otherwise meaningless, as descriptor flags are pre-configured in verbatim mode and packet data is not generated for invalid descriptors. Fixes: 697604492b64 ("selftests/xsk: add invalid descriptor test for multi-buffer") Reviewed-by: Aleksandr Loktionov Signed-off-by: Larysa Zaremba Link: https://lore.kernel.org/r/20260203155103.2305816-3-larysa.zaremba@intel.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit b2b172a9871325fe9e26dbef5aeda757b02c1c06 Author: Larysa Zaremba Date: Tue Feb 3 16:50:57 2026 +0100 selftests/xsk: properly handle batch ending in the middle of a packet [ Upstream commit 42e41b2a0afa04ca49ee2725aadf90ccb058ed28 ] Referenced commit reduced the scope of the variable pkt, so now it has to be reinitialized via pkt_stream_get_next_rx_pkt(), which also increments some counters. When the packet is interrupted by the batch ending, pkt stream therefore proceeds to the next packet, while xsk ring still contains the previous one, this results in a pkt_nb mismatch. Decrement the affected counters when packet is interrupted. Fixes: 8913e653e9b8 ("selftests/xsk: Iterate over all the sockets in the receive pkts function") Reviewed-by: Aleksandr Loktionov Signed-off-by: Larysa Zaremba Link: https://lore.kernel.org/r/20260203155103.2305816-2-larysa.zaremba@intel.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 8b1a095541c138003effc7905bea323fce9e5bd4 Author: Bastien Curutchet (eBPF Foundation) Date: Fri Oct 31 09:04:37 2025 +0100 selftests/bpf: test_xsk: Split xskxceiver [ Upstream commit 3ab77f35a75eb236956c1e8ba8494ef18a75eae0 ] AF_XDP features are tested by the test_xsk.sh script but not by the test_progs framework. The tests used by the script are defined in xksxceiver.c which can't be integrated in the test_progs framework as is. Extract these test definitions from xskxceiver{.c/.h} to put them in new test_xsk{.c/.h} files. Keep the main() function and its unshared dependencies in xksxceiver to avoid impacting the test_xsk.sh script which is often used to test real hardware. Move ksft_test_result_*() calls to xskxceiver.c to keep the kselftest's report valid Reviewed-by: Maciej Fijalkowski Signed-off-by: Bastien Curutchet (eBPF Foundation) Link: https://lore.kernel.org/r/20251031-xsk-v7-1-39fe486593a3@bootlin.com Signed-off-by: Alexei Starovoitov Stable-dep-of: 42e41b2a0afa ("selftests/xsk: properly handle batch ending in the middle of a packet") Signed-off-by: Sasha Levin commit dcf416eb88eafe1e3c0f920a14bdffd10bc4d259 Author: Lianjie Wang Date: Fri Jan 30 06:50:16 2026 +0900 hwrng: core - use RCU and work_struct to fix race condition [ Upstream commit cc2f39d6ac48e6e3cb2d6240bc0d6df839dd0828 ] Currently, hwrng_fill is not cleared until the hwrng_fillfn() thread exits. Since hwrng_unregister() reads hwrng_fill outside the rng_mutex lock, a concurrent hwrng_unregister() may call kthread_stop() again on the same task. Additionally, if hwrng_unregister() is called immediately after hwrng_register(), the stopped thread may have never been executed. Thus, hwrng_fill remains dirty even after hwrng_unregister() returns. In this case, subsequent calls to hwrng_register() will fail to start new threads, and hwrng_unregister() will call kthread_stop() on the same freed task. In both cases, a use-after-free occurs: refcount_t: addition on 0; use-after-free. WARNING: ... at lib/refcount.c:25 refcount_warn_saturate+0xec/0x1c0 Call Trace: kthread_stop+0x181/0x360 hwrng_unregister+0x288/0x380 virtrng_remove+0xe3/0x200 This patch fixes the race by protecting the global hwrng_fill pointer inside the rng_mutex lock, so that hwrng_fillfn() thread is stopped only once, and calls to kthread_run() and kthread_stop() are serialized with the lock held. To avoid deadlock in hwrng_fillfn() while being stopped with the lock held, we convert current_rng to RCU, so that get_current_rng() can read current_rng without holding the lock. To remove the lock from put_rng(), we also delay the actual cleanup into a work_struct. Since get_current_rng() no longer returns ERR_PTR values, the IS_ERR() checks are removed from its callers. With hwrng_fill protected by the rng_mutex lock, hwrng_fillfn() can no longer clear hwrng_fill itself. Therefore, if hwrng_fillfn() returns directly after current_rng is dropped, kthread_stop() would be called on a freed task_struct later. To fix this, hwrng_fillfn() calls schedule() now to keep the task alive until being stopped. The kthread_stop() call is also moved from hwrng_unregister() to drop_current_rng(), ensuring kthread_stop() is called on all possible paths where current_rng becomes NULL, so that the thread would not wait forever. Fixes: be4000bc4644 ("hwrng: create filler thread") Suggested-by: Herbert Xu Signed-off-by: Lianjie Wang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9095671fa24044500d21f9f108b942894cc0cc42 Author: Jonathan McDowell Date: Tue Sep 23 14:33:05 2025 +0100 hwrng: core - Allow runtime disabling of the HW RNG [ Upstream commit e74b96d77da9eb5ee1b603c937c2adab5134a04b ] The HW RNG core allows for manual selection of which RNG device to use, but does not allow for no device to be enabled. It may be desirable to do this on systems with only a single suitable hardware RNG, where we need exclusive access to other functionality on this device. In particular when performing TPM firmware upgrades this lets us ensure the kernel does not try to access the device. Before: root@debian-qemu-efi:~# grep "" /sys/devices/virtual/misc/hw_random/rng_* /sys/devices/virtual/misc/hw_random/rng_available:tpm-rng-0 /sys/devices/virtual/misc/hw_random/rng_current:tpm-rng-0 /sys/devices/virtual/misc/hw_random/rng_quality:1024 /sys/devices/virtual/misc/hw_random/rng_selected:0 After: root@debian-qemu-efi:~# grep "" /sys/devices/virtual/misc/hw_random/rng_* /sys/devices/virtual/misc/hw_random/rng_available:tpm-rng-0 none /sys/devices/virtual/misc/hw_random/rng_current:tpm-rng-0 /sys/devices/virtual/misc/hw_random/rng_quality:1024 /sys/devices/virtual/misc/hw_random/rng_selected:0 root@debian-qemu-efi:~# echo none > /sys/devices/virtual/misc/hw_random/rng_current root@debian-qemu-efi:~# grep "" /sys/devices/virtual/misc/hw_random/rng_* /sys/devices/virtual/misc/hw_random/rng_available:tpm-rng-0 none /sys/devices/virtual/misc/hw_random/rng_current:none grep: /sys/devices/virtual/misc/hw_random/rng_quality: No such device /sys/devices/virtual/misc/hw_random/rng_selected:1 (Observe using bpftrace no calls to TPM being made) root@debian-qemu-efi:~# echo "" > /sys/devices/virtual/misc/hw_random/rng_current root@debian-qemu-efi:~# grep "" /sys/devices/virtual/misc/hw_random/rng_* /sys/devices/virtual/misc/hw_random/rng_available:tpm-rng-0 none /sys/devices/virtual/misc/hw_random/rng_current:tpm-rng-0 /sys/devices/virtual/misc/hw_random/rng_quality:1024 /sys/devices/virtual/misc/hw_random/rng_selected:0 (Observe using bpftrace that calls to the TPM resume) Signed-off-by: Jonathan McDowell Signed-off-by: Herbert Xu Stable-dep-of: cc2f39d6ac48 ("hwrng: core - use RCU and work_struct to fix race condition") Signed-off-by: Sasha Levin commit 4869d0e4e48a5301b267d359b2561c4080791a55 Author: Zilin Guan Date: Thu Jan 29 15:10:16 2026 +0000 crypto: starfive - Fix memory leak in starfive_aes_aead_do_one_req() [ Upstream commit ccb679fdae2e62ed92fd9acb25ed809c0226fcc6 ] The starfive_aes_aead_do_one_req() function allocates rctx->adata with kzalloc() but fails to free it if sg_copy_to_buffer() or starfive_aes_hw_init() fails, which lead to memory leaks. Since rctx->adata is unconditionally freed after the write_adata operations, ensure consistent cleanup by freeing the allocation in these earlier error paths as well. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 7467147ef9bf ("crypto: starfive - Use dma for aes requests") Signed-off-by: Zilin Guan Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7752d36343862323bbeea4ce3adf0ec2ed86e122 Author: KP Singh Date: Thu Feb 5 08:07:55 2026 +0100 bpf: Require frozen map for calculating map hash [ Upstream commit a2c86aa621c22f2a7e26c654f936d65cfff0aa91 ] Currently, bpf_map_get_info_by_fd calculates and caches the hash of the map regardless of the map's frozen state. This leads to a TOCTOU bug where userspace can call BPF_OBJ_GET_INFO_BY_FD to cache the hash and then modify the map contents before freezing. Therefore, a trusted loader can be tricked into verifying the stale hash while loading the modified contents. Fix this by returning -EPERM if the map is not frozen when the hash is requested. This ensures the hash is only generated for the final, immutable state of the map. Fixes: ea2e6467ac36 ("bpf: Return hashes of maps in BPF_OBJ_GET_INFO_BY_FD") Reported-by: Toshi Piazza Signed-off-by: KP Singh Acked-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260205070755.695776-1-kpsingh@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5835a077c6f5c565d525eaca9fac01572b97a9b9 Author: KP Singh Date: Thu Feb 5 07:38:07 2026 +0100 bpf: Limit bpf program signature size [ Upstream commit ea1535e28bb3773fc0b3cbd1f3842b808016990c ] Practical BPF signatures are significantly smaller than KMALLOC_MAX_CACHE_SIZE Allowing larger sizes opens the door for abuse by passing excessive size values and forcing the kernel into expensive allocation paths (via kmalloc_large or vmalloc). Fixes: 349271568303 ("bpf: Implement signature verification for BPF programs") Reported-by: Chris Mason Signed-off-by: KP Singh Acked-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260205063807.690823-1-kpsingh@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 45acb60fe59abdec804758fe2dceb18dc4378a74 Author: Titouan Ameline de Cadeville Date: Tue Feb 3 18:59:50 2026 +0100 fs/tests: exec: drop duplicate bprm_stack_limits test vectors [ Upstream commit 46a03ea50b5f380bdb99178b8f90b39c6ba1f528 ] Remove duplicate entries from the bprm_stack_limits KUnit test vector table. The duplicates do not add coverage and only increase test size. Signed-off-by: Titouan Ameline de Cadeville Fixes: 60371f43e56b ("exec: Add KUnit test for bprm_stack_limits()") Link: https://patch.msgid.link/20260203175950.43710-1-titouan.ameline@gmail.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 52aeb1e07ec223caf212f036817976c98d2aa250 Author: Chen Jinghuang Date: Thu Jan 22 01:25:33 2026 +0000 sched/rt: Skip currently executing CPU in rto_next_cpu() [ Upstream commit 94894c9c477e53bcea052e075c53f89df3d2a33e ] CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed). However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts. The trigging scenario is as follows: cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios. Fixes: 4bdced5c9a29 ("sched/rt: Simplify the IPI based RT balancing logic") Suggested-by: Steven Rostedt (Google) Suggested-by: K Prateek Nayak Signed-off-by: Chen Jinghuang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Steven Rostedt (Google) Reviewed-by: Valentin Schneider Link: https://patch.msgid.link/20260122012533.673768-1-chenjinghuang2@huawei.com Signed-off-by: Sasha Levin commit 909131ad0a0065ecf457e544e035ea0086099fab Author: Joel Fernandes Date: Mon Jan 26 10:58:59 2026 +0100 sched/deadline: Clear the defer params [ Upstream commit 3cb3b27693bf30defb16aa096158a3b24583b8d2 ] The defer params were not cleared in __dl_clear_params. Clear them. Without this is some of my test cases are flaking and the DL timer is not starting correctly AFAICS. Fixes: a110a81c52a9 ("sched/deadline: Deferrable dl server") Signed-off-by: Joel Fernandes Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Andrea Righi Acked-by: Juri Lelli Tested-by: Christian Loehle Link: https://patch.msgid.link/20260126100050.3854740-2-arighi@nvidia.com Signed-off-by: Sasha Levin commit 83550d2311559beb40bb3ceb8c13826209ad8bab Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:40 2026 +0100 media: pci: mg4b: Use IRQF_NO_THREAD [ Upstream commit ef92b98f5f6758a049898b53aa30476010db04fa ] The interrupt handler iio_trigger_generic_data_rdy_poll() will invoke other interrupt handlers and this supposed to happen from hard interrupt context. Use IRQF_NO_THREAD to forbid forced-threading. Fixes: 0ab13674a9bd1 ("media: pci: mgb4: Added Digiteq Automotive MGB4 driver") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-21-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 352f1bbbd711a766439cfc170a6d9e11f504c813 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:35 2026 +0100 mfd: wm8350-core: Use IRQF_ONESHOT [ Upstream commit 553b4999cbe231b5011cb8db05a3092dec168aca ] Using a threaded interrupt without a dedicated primary handler mandates the IRQF_ONESHOT flag to mask the interrupt source while the threaded handler is active. Otherwise the interrupt can fire again before the threaded handler had a chance to run. Mark explained that this should not happen with this hardware since it is a slow irqchip which is behind an I2C/ SPI bus but the IRQ-core will refuse to accept such a handler. Set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Fixes: 1c6c69525b40e ("genirq: Reject bogus threaded irq requests") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Charles Keepax Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260128095540.863589-16-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 7b0c5dec6a01ab9dc053a499f8b16ed976413a43 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:32 2026 +0100 rtc: amlogic-a4: Remove IRQF_ONESHOT [ Upstream commit 18d28446231390e4ea3634fb16200865df2c6506 ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. Remove IRQF_ONESHOT from irqflags. Fixes: c89ac9182ee29 ("rtc: support for the Amlogic on-chip RTC") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Xianwei Zhao Link: https://patch.msgid.link/20260128095540.863589-13-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 5248f7f5b3407e0d93462cfb63810d44a1b12562 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:31 2026 +0100 usb: typec: fusb302: Remove IRQF_ONESHOT [ Upstream commit a7fb84ea70aae9a92a842932206e70ed1b3c7007 ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. Remove IRQF_ONESHOT from irqflags. Fixes: 309b6341d5570 ("usb: typec: fusb302: Revert incorrect threaded irq fix") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Acked-by: Greg Kroah-Hartman Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260128095540.863589-12-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 66839f7c2bd66689ad508e13b0c73a4aa3340e48 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:30 2026 +0100 EDAC/altera: Remove IRQF_ONESHOT [ Upstream commit 5c858d6c66304b4c7579582ec5235f02d43578ea ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. Remove IRQF_ONESHOT from irqflags. Fixes: a29d64a45eed1 ("EDAC, altera: Add IRQ Flags to disable IRQ while handling") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-11-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 909dfc310ee53df6c8f3f09a6a3e532073cbe53b Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:27 2026 +0100 scsi: efct: Use IRQF_ONESHOT and default primary handler [ Upstream commit bd81f07e9a27c341cd7e72be95eb0b7cf3910926 ] There is no added value in efct_intr_msix() compared to irq_default_primary_handler(). Using a threaded interrupt without a dedicated primary handler mandates the IRQF_ONESHOT flag to mask the interrupt source while the threaded handler is active. Otherwise the interrupt can fire again before the threaded handler had a chance to run. Use the default primary interrupt handler by specifying NULL and set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Fixes: 4df84e8466242 ("scsi: elx: efct: Driver initialization routines") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-8-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit f5e5bbf56ecf6434ae065219754f70fc21d2d169 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:26 2026 +0100 Bluetooth: btintel_pcie: Use IRQF_ONESHOT and default primary handler [ Upstream commit 28abed6569c87eab9071ab56c64433c2f0d9ce51 ] There is no added value in btintel_pcie_msix_isr() compared to irq_default_primary_handler(). Using a threaded interrupt without a dedicated primary handler mandates the IRQF_ONESHOT flag to mask the interrupt source while the threaded handler is active. Otherwise the interrupt can fire again before the threaded handler had a chance to run. Use the default primary interrupt handler by specifying NULL and set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Fixes: c2b636b3f788d ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-7-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 680b652b2d08779965aa5d27b575bee112b3a3a8 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:23 2026 +0100 iommu/amd: Use core's primary handler and set IRQF_ONESHOT [ Upstream commit 5bfcdccb4d18d3909b7f87942be67fd6bdc00c1d ] request_threaded_irq() is invoked with a primary and a secondary handler and no flags are passed. The primary handler is the same as irq_default_primary_handler() so there is no need to have an identical copy. The lack of the IRQF_ONESHOT can be dangerous because the interrupt source is not masked while the threaded handler is active. This means, especially on LEVEL typed interrupt lines, the interrupt can fire again before the threaded handler had a chance to run. Use the default primary interrupt handler by specifying NULL and set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Fixes: 72fe00f01f9a3 ("x86/amd-iommu: Use threaded interupt handler") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-4-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 91b6a550472a976223310538adee5fd7193ff87f Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:22 2026 +0100 platform/x86: int0002: Remove IRQF_ONESHOT from request_irq() [ Upstream commit f6bc712877f24dc89bdfd7bdbf1a32f3b9960b34 ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt cannot fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. The flag was added to match the flag on the shared handler which uses a threaded handler and therefore IRQF_ONESHOT. This is no longer needed because devm_request_irq() now passes IRQF_COND_ONESHOT for this case. Revert adding IRQF_ONESHOT to irqflags. Fixes: 8f812373d1958 ("platform/x86: intel: int0002_vgpio: Pass IRQF_ONESHOT to request_irq()") Reported-by: Borah, Chaitanya Kumar Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Hans de Goede Acked-by: Ilpo Järvinen Link: https://patch.msgid.link/20260128095540.863589-3-bigeasy@linutronix.de Closes: https://lore.kernel.org/all/555f1c56-0f74-41bf-8bd2-6217e0aab0c6@intel.com Signed-off-by: Sasha Levin commit 0c1876a365447d84c03c4acec605440b30b7944b Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:21 2026 +0100 genirq: Set IRQF_COND_ONESHOT in devm_request_irq(). [ Upstream commit 943b052ded21feb84f293d40b06af3181cd0d0d7 ] The flag IRQF_COND_ONESHOT was already force-added to request_irq() because the ACPI SCI interrupt handler is using the IRQF_ONESHOT flag which breaks all shared handlers. devm_request_irq() needs the same change since some users, such as int0002_vgpio, are using this function instead. Add IRQF_COND_ONESHOT to the flags passed to devm_request_irq(). Fixes: c37927a203fa2 ("genirq: Set IRQF_COND_ONESHOT in request_irq()") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-2-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit d7b87adeb0eb539b9b824b101bb14fb01e41240b Author: Paul Chaignon Date: Sat Jan 31 17:08:37 2026 +0100 bpf: Fix bpf_xdp_store_bytes proto for read-only arg [ Upstream commit 6557f1565d779851c4db9c488c49c05a47a6e72f ] While making some maps in Cilium read-only from the BPF side, we noticed that the bpf_xdp_store_bytes proto is incorrect. In particular, the verifier was throwing the following error: ; ret = ctx_store_bytes(ctx, l3_off + offsetof(struct iphdr, saddr), &nat->address, 4, 0); 635: (79) r1 = *(u64 *)(r10 -144) ; R1=ctx() R10=fp0 fp-144=ctx() 636: (b4) w2 = 26 ; R2=26 637: (b4) w4 = 4 ; R4=4 638: (b4) w5 = 0 ; R5=0 639: (85) call bpf_xdp_store_bytes#190 write into map forbidden, value_size=6 off=0 size=4 nat comes from a BPF_F_RDONLY_PROG map, so R3 is a PTR_TO_MAP_VALUE. The verifier checks the helper's memory access to R3 in check_mem_size_reg, as it reaches ARG_CONST_SIZE argument. The third argument has expected type ARG_PTR_TO_UNINIT_MEM, which includes the MEM_WRITE flag. The verifier thus checks for a BPF_WRITE access on R3. Given R3 points to a read-only map, the check fails. Conversely, ARG_PTR_TO_UNINIT_MEM can also lead to the helper reading from uninitialized memory. This patch simply fixes the expected argument type to match that of bpf_skb_store_bytes. Fixes: 3f364222d032 ("net: xdp: introduce bpf_xdp_pointer utility routine") Signed-off-by: Paul Chaignon Link: https://lore.kernel.org/r/9fa3c9f72d806e82541071c4df88b8cba28ad6a9.1769875479.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit d7decb572b55d2af33e59e9858fcee5d9ae69175 Author: Jianpeng Chang Date: Tue Jan 20 09:55:24 2026 +0800 crypto: caam - fix netdev memory leak in dpaa2_caam_probe [ Upstream commit 7d43252b3060b0ba4a192dce5dba85a3f39ffe39 ] When commit 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2") converted embedded net_device to dynamically allocated pointers, it added cleanup in dpaa2_dpseci_disable() but missed adding cleanup in dpaa2_dpseci_free() for error paths. This causes memory leaks when dpaa2_dpseci_dpio_setup() fails during probe due to DPIO devices not being ready yet. The kernel's deferred probe mechanism handles the retry successfully, but the netdevs allocated during the failed probe attempt are never freed, resulting in kmemleak reports showing multiple leaked netdev-related allocations all traced back to dpaa2_caam_probe(). Fix this by preserving the CPU mask of allocated netdevs during setup and using it for cleanup in dpaa2_dpseci_free(). This approach ensures that only the CPUs that actually had netdevs allocated will be cleaned up, avoiding potential issues with CPU hotplug scenarios. Fixes: 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2") Signed-off-by: Jianpeng Chang Reviewed-by: Breno Leitao Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d0bac6618e810c02def90966aadcf9eb78b18116 Author: Weili Qian Date: Sat Jan 17 15:18:21 2026 +0800 crypto: hisilicon/trng - support tfms sharing the device [ Upstream commit 3d3135057ff567d5c09fff4c9ef6391a684e8042 ] Since the number of devices is limited, and the number of tfms may exceed the number of devices, to ensure that tfms can be successfully allocated, support tfms sharing the same device. Fixes: e4d9d10ef4be ("crypto: hisilicon/trng - add support for PRNG") Signed-off-by: Weili Qian Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 94fdeeaeb7cef9cf99b46b10f148ca9ae195b9e7 Author: Jiri Olsa Date: Mon Jan 26 22:18:34 2026 +0100 selftests/bpf: Fix kprobe multi stacktrace_ips test [ Upstream commit 0207f94971e72a13380e28022c86da147e8e090f ] We now include the attached function in the stack trace, fixing the test accordingly. Fixes: c9e208fa93cd ("selftests/bpf: Add stacktrace ips test for kprobe_multi/kretprobe_multi") Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260126211837.472802-4-jolsa@kernel.org Signed-off-by: Sasha Levin commit 42a155c738b9a18c9b2fec23f29236fefd5009e1 Author: Jiri Olsa Date: Mon Jan 26 22:18:33 2026 +0100 x86/fgraph,bpf: Switch kprobe_multi program stack unwind to hw_regs path [ Upstream commit aea251799998aa1b78eacdfb308f18ea114ea5b3 ] Mahe reported missing function from stack trace on top of kprobe multi program. The missing function is the very first one in the stacktrace, the one that the bpf program is attached to. # bpftrace -e 'kprobe:__x64_sys_newuname* { print(kstack)}' Attaching 1 probe... do_syscall_64+134 entry_SYSCALL_64_after_hwframe+118 ('*' is used for kprobe_multi attachment) The reason is that the previous change (the Fixes commit) fixed stack unwind for tracepoint, but removed attached function address from the stack trace on top of kprobe multi programs, which I also overlooked in the related test (check following patch). The tracepoint and kprobe_multi have different stack setup, but use same unwind path. I think it's better to keep the previous change, which fixed tracepoint unwind and instead change the kprobe multi unwind as explained below. The bpf program stack unwind calls perf_callchain_kernel for kernel portion and it follows two unwind paths based on X86_EFLAGS_FIXED bit in pt_regs.flags. When the bit set we unwind from stack represented by pt_regs argument, otherwise we unwind currently executed stack up to 'first_frame' boundary. The 'first_frame' value is taken from regs.rsp value, but ftrace_caller and ftrace_regs_caller (ftrace trampoline) functions set the regs.rsp to the previous stack frame, so we skip the attached function entry. If we switch kprobe_multi unwind to use the X86_EFLAGS_FIXED bit, we set the start of the unwind to the attached function address. As another benefit we also cut extra unwind cycles needed to reach the 'first_frame' boundary. The speedup can be measured with trigger bench for kprobe_multi program and stacktrace support. - trigger bench with stacktrace on current code: kprobe-multi : 0.810 ± 0.001M/s kretprobe-multi: 0.808 ± 0.001M/s - and with the fix: kprobe-multi : 1.264 ± 0.001M/s kretprobe-multi: 1.401 ± 0.002M/s With the fix, the entry probe stacktrace: # bpftrace -e 'kprobe:__x64_sys_newuname* { print(kstack)}' Attaching 1 probe... __x64_sys_newuname+9 do_syscall_64+134 entry_SYSCALL_64_after_hwframe+118 The return probe skips the attached function, because it's no longer on the stack at the point of the unwind and this way is the same how standard kretprobe works. # bpftrace -e 'kretprobe:__x64_sys_newuname* { print(kstack)}' Attaching 1 probe... do_syscall_64+134 entry_SYSCALL_64_after_hwframe+118 Fixes: 6d08340d1e35 ("Revert "perf/x86: Always store regs->ip in perf_callchain_kernel()"") Reported-by: Mahe Tardy Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Acked-by: Steven Rostedt (Google) Link: https://lore.kernel.org/bpf/20260126211837.472802-3-jolsa@kernel.org Signed-off-by: Sasha Levin commit 9e10486f79936ff8f16b79e48c52e506d62b68d2 Author: Jiri Olsa Date: Mon Jan 26 22:18:32 2026 +0100 x86/fgraph: Fix return_to_handler regs.rsp value [ Upstream commit 8bc11700e0d23d4fdb7d8d5a73b2e95de427cabc ] The previous change (Fixes commit) messed up the rsp register value, which is wrong because it's already adjusted with FRAME_SIZE, we need the original rsp value. This change does not affect fprobe current kernel unwind, the !perf_hw_regs path perf_callchain_kernel: if (perf_hw_regs(regs)) { if (perf_callchain_store(entry, regs->ip)) return; unwind_start(&state, current, regs, NULL); } else { unwind_start(&state, current, NULL, (void *)regs->sp); } which uses pt_regs.sp as first_frame boundary (FRAME_SIZE shift makes no difference, unwind stil stops at the right frame). This change fixes the other path when we want to unwind directly from pt_regs sp/fp/ip state, which is coming in following change. Fixes: 20a0bc10272f ("x86/fgraph,bpf: Fix stack ORC unwind from kprobe_multi return probe") Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Reviewed-by: Steven Rostedt (Google) Link: https://lore.kernel.org/bpf/20260126211837.472802-2-jolsa@kernel.org Signed-off-by: Sasha Levin commit 243d642ff5809811208fa1707b7ab8a6ab4b1d68 Author: Aleksander Jan Bajkowski Date: Sun Jan 11 14:20:32 2026 +0100 crypto: inside-secure/eip93 - unregister only available algorithm [ Upstream commit 0ceeadc7b53a041d89d5843f6bf0ccb7c98b0b4f ] EIP93 has an options register. This register indicates which crypto algorithms are implemented in silicon. Supported algorithms are registered on this basis. Unregister algorithms on the same basis. Currently, all algorithms are unregistered, even those not supported by HW. This results in panic on platforms that don't have all options implemented in silicon. Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support") Signed-off-by: Aleksander Jan Bajkowski Acked-by: Antoine Tenart Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9a3ace9b010ffd8c422c97844ae152f7c53d6b18 Author: Ella Ma Date: Fri Jan 9 16:17:24 2026 +0100 crypto: ccp - Fix a crash due to incorrect cleanup usage of kfree [ Upstream commit d5abcc33ee76bc26d58b39dc1a097e43a99dd438 ] Annotating a local pointer variable, which will be assigned with the kmalloc-family functions, with the `__cleanup(kfree)` attribute will make the address of the local variable, rather than the address returned by kmalloc, passed to kfree directly and lead to a crash due to invalid deallocation of stack address. According to other places in the repo, the correct usage should be `__free(kfree)`. The code coincidentally compiled because the parameter type `void *` of kfree is compatible with the desired type `struct { ... } **`. Fixes: a71475582ada ("crypto: ccp - reduce stack usage in ccp_run_aes_gcm_cmd") Signed-off-by: Ella Ma Acked-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4ecbcfb71a50c401c5eeaa41d72c9edf9af08518 Author: Luis Gerhorst Date: Tue Jan 27 12:59:11 2026 +0100 bpf: Fix verifier_bug_if to account for BPF_CALL [ Upstream commit cd3b6a3d49f8061d0c4c7e4226783051fe592ae7 ] The BPF verifier assumes `insn_aux->nospec_result` is only set for direct memory writes (e.g., `*(u32*)(r1+off) = r2`). However, the assertion fails to account for helper calls (e.g., `bpf_skb_load_bytes_relative`) that perform writes to stack memory. Make the check more precise to resolve this. The problem is that `BPF_CALL` instructions have `BPF_CLASS(insn->code) == BPF_JMP`, which triggers the warning check: - Helpers like `bpf_skb_load_bytes_relative` write to stack memory - `check_helper_call()` loops through `meta.access_size`, calling `check_mem_access(..., BPF_WRITE)` - `check_stack_write()` sets `insn_aux->nospec_result = 1` - Since `BPF_CALL` is encoded as `BPF_JMP | BPF_CALL`, the warning fires Execution flow: ``` 1. Drop capabilities → Enable Spectre mitigation 2. Load BPF program └─> do_check() ├─> check_cond_jmp_op() → Marks dead branch as speculative │ └─> push_stack(..., speculative=true) ├─> pop_stack() → state->speculative = 1 ├─> check_helper_call() → Processes helper in dead branch │ └─> check_mem_access(..., BPF_WRITE) │ └─> insn_aux->nospec_result = 1 └─> Checks: state->speculative && insn_aux->nospec_result └─> BPF_CLASS(insn->code) == BPF_JMP → WARNING ``` To fix the assert, it would be nice to be able to reuse bpf_insn_successors() here, but bpf_insn_successors()->cnt is not exactly what we want as it may also be 1 for BPF_JA. Instead, we could check opcode_info.can_jump, but then we would have to share the table between the functions. This would mean moving the table out of the function and adding bpf_opcode_info(). As the verifier_bug_if() only runs for insns with nospec_result set, the impact on verification time would likely still be negligible. However, I assume sharing bpf_opcode_info() between liveness.c and verifier.c will not be worth it. It seems as only adjust_jmp_off() could also be simplified using it, and there imm/off is touched. Thus it is maybe better to rely on exact opcode/class matching there. Therefore, to avoid this sharing only for a verifier_bug_if(), just check the opcode. This should now cover all opcodes for which can_jump in bpf_insn_successors() is true. Parts of the description and example are taken from the bug report. Fixes: dadb59104c64 ("bpf: Fix aux usage after do_check_insn()") Signed-off-by: Luis Gerhorst Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Reported-by: Dongliang Mu Closes: https://lore.kernel.org/bpf/7678017d-b760-4053-a2d8-a6879b0dbeeb@hust.edu.cn/ Link: https://lore.kernel.org/r/20260127115912.3026761-2-luis.gerhorst@fau.de Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 4e0772cded109c238411f2fac36ac39302758b81 Author: Guillaume Gonnet Date: Tue Jan 27 17:02:00 2026 +0100 bpf: Fix tcx/netkit detach permissions when prog fd isn't given [ Upstream commit ae23bc81ddf7c17b663c4ed1b21e35527b0a7131 ] This commit fixes a security issue where BPF_PROG_DETACH on tcx or netkit devices could be executed by any user when no program fd was provided, bypassing permission checks. The fix adds a capability check for CAP_NET_ADMIN or CAP_SYS_ADMIN in this case. Fixes: e420bed02507 ("bpf: Add fd-based tcx multi-prog infra with link support") Signed-off-by: Guillaume Gonnet Link: https://lore.kernel.org/r/20260127160200.10395-1-ggonnet.linux@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 4b8d1424b32c4e01b8d6f48d748f550dc230a254 Author: Jiayuan Chen Date: Sat Jan 24 19:32:44 2026 +0800 bpf, sockmap: Fix FIONREAD for sockmap [ Upstream commit 929e30f9312514902133c45e51c79088421ab084 ] A socket using sockmap has its own independent receive queue: ingress_msg. This queue may contain data from its own protocol stack or from other sockets. Therefore, for sockmap, relying solely on copied_seq and rcv_nxt to calculate FIONREAD is not enough. This patch adds a new msg_tot_len field in the psock structure to record the data length in ingress_msg. Additionally, we implement new ioctl interfaces for TCP and UDP to intercept FIONREAD operations. Note that we intentionally do not include sk_receive_queue data in the FIONREAD result. Data in sk_receive_queue has not yet been processed by the BPF verdict program, and may be redirected to other sockets or dropped. Including it would create semantic ambiguity since this data may never be readable by the user. Unix and VSOCK sockets have similar issues, but fixing them is outside the scope of this patch as it would require more intrusive changes. Previous work by John Fastabend made some efforts towards FIONREAD support: commit e5c6de5fa025 ("bpf, sockmap: Incorrectly handling copied_seq") Although the current patch is based on the previous work by John Fastabend, it is acceptable for our Fixes tag to point to the same commit. FD1:read() -- FD1->copied_seq++ | [read data] | [enqueue data] v [sockmap] -> ingress to self -> ingress_msg queue FD1 native stack ------> ^ -- FD1->rcv_nxt++ -> redirect to other | [enqueue data] | | | ingress to FD1 v ^ ... | [sockmap] FD2 native stack Fixes: 04919bed948dc ("tcp: Introduce tcp_read_skb()") Signed-off-by: Jiayuan Chen Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/r/20260124113314.113584-3-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit f274a4540226e1d5d7664d32263f04d742d643ae Author: Jiayuan Chen Date: Sat Jan 24 19:32:43 2026 +0800 bpf, sockmap: Fix incorrect copied_seq calculation [ Upstream commit b40cc5adaa80e1471095a62d78233b611d7a558c ] A socket using sockmap has its own independent receive queue: ingress_msg. This queue may contain data from its own protocol stack or from other sockets. The issue is that when reading from ingress_msg, we update tp->copied_seq by default. However, if the data is not from its own protocol stack, tcp->rcv_nxt is not increased. Later, if we convert this socket to a native socket, reading from this socket may fail because copied_seq might be significantly larger than rcv_nxt. This fix also addresses the syzkaller-reported bug referenced in the Closes tag. This patch marks the skmsg objects in ingress_msg. When reading, we update copied_seq only if the data is from its own protocol stack. FD1:read() -- FD1->copied_seq++ | [read data] | [enqueue data] v [sockmap] -> ingress to self -> ingress_msg queue FD1 native stack ------> ^ -- FD1->rcv_nxt++ -> redirect to other | [enqueue data] | | | ingress to FD1 v ^ ... | [sockmap] FD2 native stack Closes: https://syzkaller.appspot.com/bug?extid=06dbd397158ec0ea4983 Fixes: 04919bed948dc ("tcp: Introduce tcp_read_skb()") Reviewed-by: Jakub Sitnicki Reviewed-by: John Fastabend Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260124113314.113584-2-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 3ed835f6aa1888fbeee3811bc7e75c970e578eb1 Author: Kumar Kartikeya Dwivedi Date: Thu Jan 22 03:59:11 2026 -0800 rqspinlock: Fix TAS fallback lock entry creation [ Upstream commit 82f3b142c99cf44c7b1e70b7720169c646b9760f ] The TAS fallback can be invoked directly when queued spin locks are disabled, and through the slow path when paravirt is enabled for queued spin locks. In the latter case, the res_spin_lock macro will attempt the fast path and already hold the entry when entering the slow path. This will lead to creation of extraneous entries that are not released, which may cause false positives for deadlock detection. Fix this by always preceding invocation of the TAS fallback in every case with the grabbing of the held lock entry, and add a comment to make note of this. Fixes: c9102a68c070 ("rqspinlock: Add a test-and-set fallback") Reported-by: Amery Hung Signed-off-by: Kumar Kartikeya Dwivedi Tested-by: Amery Hung Link: https://lore.kernel.org/r/20260122115911.3668985-1-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 6abdd33a088db9bca9fd79ab6ebe5e5c17fb68b1 Author: Aleksander Jan Bajkowski Date: Mon Jan 5 21:41:49 2026 +0100 hwrng: airoha - set rng quality to 900 [ Upstream commit c0008a29a006091d7f9d288620c2456afa23ff27 ] Airoha uses RAW mode to collect noise from the TRNG. These appear to be unprocessed oscillations from the tero loop. For this reason, they do not have a perfect distribution and entropy. Simple noise compression reduces its size by 9%, so setting the quality to 900 seems reasonable. The same value is used by the downstream driver. Compare the size before and after compression: $ ls -l random_airoha* -rw-r--r-- 1 aleksander aleksander 76546048 Jan 3 23:43 random_airoha -rw-rw-r-- 1 aleksander aleksander 69783562 Jan 5 20:23 random_airoha.zip FIPS test results: $ cat random_airoha | rngtest -c 10000 rngtest 2.6 Copyright (c) 2004 by Henrique de Moraes Holschuh This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. rngtest: starting FIPS tests... rngtest: bits received from input: 200000032 rngtest: FIPS 140-2 successes: 0 rngtest: FIPS 140-2 failures: 10000 rngtest: FIPS 140-2(2001-10-10) Monobit: 9957 rngtest: FIPS 140-2(2001-10-10) Poker: 10000 rngtest: FIPS 140-2(2001-10-10) Runs: 10000 rngtest: FIPS 140-2(2001-10-10) Long run: 4249 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 rngtest: input channel speed: (min=953.674; avg=27698.935; max=19073.486)Mibits/s rngtest: FIPS tests speed: (min=59.791; avg=298.028; max=328.853)Mibits/s rngtest: Program run time: 647638 microseconds In general, these data look like real noise, but with lower entropy than expected. Fixes: e53ca8efcc5e ("hwrng: airoha - add support for Airoha EN7581 TRNG") Suggested-by: Benjamin Larsson Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 46825599fad19684091ea630080b259eede510ee Author: Tycho Andersen (AMD) Date: Mon Jan 5 10:22:18 2026 -0700 crypto: ccp - narrow scope of snp_range_list [ Upstream commit dc8ccab15081efc4f2c5a9fc7b209cd641d29177 ] snp_range_list is only used in __sev_snp_init_locked() in the SNP_INIT_EX case, move the declaration there and add a __free() cleanup helper for it instead of waiting until shutdown. Fixes: 1ca5614b84ee ("crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP") Reviewed-by: Alexey Kardashevskiy Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e6a4b3d22221183a173e88e3df07c756e83140e4 Author: Tom Lendacky Date: Mon Jan 5 10:22:17 2026 -0700 crypto: ccp - Fix a case where SNP_SHUTDOWN is missed [ Upstream commit 551120148b67e04527b405c5ec33a31593846ba4 ] If page reclaim fails in sev_ioctl_do_snp_platform_status() and SNP was moved from UNINIT to INIT for the function, SNP is not moved back to UNINIT state. Additionally, SNP is not required to be initialized in order to execute the SNP_PLATFORM_STATUS command, so don't attempt to move to INIT state and let SNP_PLATFORM_STATUS report the status as is. Fixes: ceac7fb89e8d ("crypto: ccp - Ensure implicit SEV/SNP init and shutdown in ioctls") Signed-off-by: Tom Lendacky Reviewed-by: Tycho Andersen (AMD) Reviewed-by: Alexey Kardashevskiy Signed-off-by: Tycho Andersen (AMD) Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7530c3595d1e23bc5938cbd44b7e8f33457fc71f Author: Aleksander Jan Bajkowski Date: Tue Dec 30 22:17:17 2025 +0100 crypto: inside-secure/eip93 - fix kernel panic in driver detach [ Upstream commit b6e32ba6d32503440a3e3e16c8d0521cbb7e0c5d ] During driver detach, the same hash algorithm is unregistered multiple times due to a wrong iterator. Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support") Signed-off-by: Aleksander Jan Bajkowski Reviewed-by: Antoine Tenart Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 1bbb1356f6be500f9cda5380be26e7b1370a146b Author: Thomas Gleixner Date: Mon Jan 19 11:38:34 2026 +0100 hrtimer: Fix trace oddity [ Upstream commit 5d6446f409da00e5a389125ddb5ce09f5bc404c9 ] It turns out that __run_hrtimer() will trace like: -0 [032] d.h2. 20705.474563: hrtimer_cancel: hrtimer=0xff2db8f77f8226e8 -0 [032] d.h1. 20705.474563: hrtimer_expire_entry: hrtimer=0xff2db8f77f8226e8 now=20699452001850 function=tick_nohz_handler/0x0 Which is a bit nonsensical, the timer doesn't get canceled on expiration. The cause is the use of the incorrect debug helper. Fixes: c6a2a1770245 ("hrtimer: Add tracepoint for hrtimers") Reported-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260121143208.219595606@infradead.org Signed-off-by: Sasha Levin commit c77581cdebada8a6eec9723274b16c93abbb8b34 Author: Kery Qi Date: Wed Jan 21 17:41:16 2026 +0800 selftests/bpf: Fix resource leak in serial_test_wq on attach failure [ Upstream commit a32ae2658471dd87a2f7a438388ed7d9a5767212 ] When wq__attach() fails, serial_test_wq() returns early without calling wq__destroy(), leaking the skeleton resources allocated by wq__open_and_load(). This causes ASAN leak reports in selftests runs. Fix this by jumping to a common clean_up label that calls wq__destroy() on all exit paths after successful open_and_load. Note that the early return after wq__open_and_load() failure is correct and doesn't need fixing, since that function returns NULL on failure (after internally cleaning up any partial allocations). Fixes: 8290dba51910 ("selftests/bpf: wq: add bpf_wq_start() checks") Signed-off-by: Kery Qi Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20260121094114.1801-3-qikeyu2017@gmail.com Signed-off-by: Sasha Levin commit fdfe75161f6e8c41a7d3023fbb815b537107b806 Author: Zesen Liu Date: Tue Jan 20 16:28:46 2026 +0800 bpf: Fix memory access flags in helper prototypes [ Upstream commit 802eef5afb1865bc5536a5302c068ba2215a1f72 ] After commit 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking"), the verifier started relying on the access type flags in helper function prototypes to perform memory access optimizations. Currently, several helper functions utilizing ARG_PTR_TO_MEM lack the corresponding MEM_RDONLY or MEM_WRITE flags. This omission causes the verifier to incorrectly assume that the buffer contents are unchanged across the helper call. Consequently, the verifier may optimize away subsequent reads based on this wrong assumption, leading to correctness issues. For bpf_get_stack_proto_raw_tp, the original MEM_RDONLY was incorrect since the helper writes to the buffer. Change it to ARG_PTR_TO_UNINIT_MEM which correctly indicates write access to potentially uninitialized memory. Similar issues were recently addressed for specific helpers in commit ac44dcc788b9 ("bpf: Fix verifier assumptions of bpf_d_path's output buffer") and commit 2eb7648558a7 ("bpf: Specify access type of bpf_sysctl_get_name args"). Fix these prototypes by adding the correct memory access flags. Fixes: 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking") Co-developed-by: Shuran Liu Signed-off-by: Shuran Liu Co-developed-by: Peili Gao Signed-off-by: Peili Gao Co-developed-by: Haoran Ni Signed-off-by: Haoran Ni Signed-off-by: Zesen Liu Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260120-helper_proto-v3-1-27b0180b4e77@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 92a8cb1806adefb263cf096eab6705705cf7eee1 Author: Puranjay Mohan Date: Thu Jan 15 07:11:40 2026 -0800 bpf: Preserve id of register in sync_linked_regs() [ Upstream commit af9e89d8dd39530c8bd14c33ddf6b502df1071b6 ] sync_linked_regs() copies the id of known_reg to reg when propagating bounds of known_reg to reg using the off of known_reg, but when known_reg was linked to reg like: known_reg = reg ; both known_reg and reg get same id known_reg += 4 ; known_reg gets off = 4, and its id gets BPF_ADD_CONST now when a call to sync_linked_regs() happens, let's say with the following: if known_reg >= 10 goto pc+2 known_reg's new bounds are propagated to reg but now reg gets BPF_ADD_CONST from the copy. This means if another link to reg is created like: another_reg = reg ; another_reg should get the id of reg but assign_scalar_id_before_mov() sees BPF_ADD_CONST on reg and assigns a new id to it. As reg has a new id now, known_reg's link to reg is broken. If we find new bounds for known_reg, they will not be propagated to reg. This can be seen in the selftest added in the next commit: 0: (85) call bpf_get_prandom_u32#7 ; R0=scalar() 1: (57) r0 &= 255 ; R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) 2: (bf) r1 = r0 ; R0=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) R1=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) 3: (07) r1 += 4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=4,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff)) 4: (a5) if r1 < 0xa goto pc+4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=10,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff)) 5: (bf) r2 = r0 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) R2=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) 6: (a5) if r1 < 0xe goto pc+2 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=14,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff)) 7: (35) if r0 >= 0xa goto pc+1 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=9,var_off=(0x0; 0xf)) 8: (37) r0 /= 0 div by zero When 4 is verified, r1's bounds are propagated to r0 but r0 also gets BPF_ADD_CONST (bug). When 5 is verified, r0 gets a new id (2) and its link with r1 is broken. After 6 we know r1 has bounds [14, 259] and therefore r0 should have bounds [10, 255], therefore the branch at 7 is always taken. But because r0's id was changed to 2, r1's new bounds are not propagated to r0. The verifier still thinks r0 has bounds [6, 255] before 7 and execution can reach div by zero. Fix this by preserving id in sync_linked_regs() like off and subreg_def. Fixes: 98d7ca374ba4 ("bpf: Track delta between "linked" registers.") Signed-off-by: Puranjay Mohan Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260115151143.1344724-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 33d3290333e8eeb09b49bb14852b83c0aa84618c Author: Chenghai Huang Date: Fri Dec 19 11:36:19 2025 +0800 crypto: hisilicon/sgl - fix inconsistent map/unmap direction issue [ Upstream commit 4154f7d3b1c133b909d20c44ecb8277e8482aa6b ] Ensure that the direction for dma_map_sg and dma_unmap_sg is consistent. Fixes: 2566de3e06a3 ("crypto: hisilicon - Use fine grained DMA mapping direction") Signed-off-by: Chenghai Huang Reviewed-by: Zenghui Yu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 740e710a6f2724a906442dbfec25abba64cfe9bf Author: Qi Tao Date: Thu Dec 18 21:44:52 2025 +0800 crypto: hisilicon/sec2 - support skcipher/aead fallback for hardware queue unavailable [ Upstream commit e7507439628052363500d717caffb5c2241854dc ] When all hardware queues are busy and no shareable queue, new processes fail to apply for queues. To avoid affecting tasks, support fallback mechanism when hardware queues are unavailable. Fixes: c16a70c1f253 ("crypto: hisilicon/sec - add new algorithm mode for AEAD") Signed-off-by: Qi Tao Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9f35acf698017824ff391bd20fc09ab1c821bdab Author: Weili Qian Date: Thu Dec 18 21:44:51 2025 +0800 crypto: hisilicon/hpre - support the hpre algorithm fallback [ Upstream commit 6aff4d977e2d582c5d6ff6afd5646c1a459490fa ] When all hardware queues are busy and no shareable queue, new processes fail to apply for queues. To avoid affecting tasks, support fallback mechanism when hardware queues are unavailable. HPRE driver supports DH algorithm, limited to prime numbers up to 4K. It supports prime numbers larger than 4K via fallback mechanism. Fixes: 05e7b906aa7c ("crypto: hisilicon/hpre - add 'ECDH' algorithm") Signed-off-by: Weili Qian Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c990abb136b74547c222bfb78f8978179c009aa2 Author: Chenghai Huang Date: Thu Dec 18 21:44:47 2025 +0800 crypto: hisilicon - consolidate qp creation and start in hisi_qm_alloc_qps_node [ Upstream commit 72f3bbebff15e87171271d643ee2672fb8e92031 ] Consolidate the creation and start of qp into the function hisi_qm_alloc_qps_node. This change eliminates the need for each module to perform these steps in two separate phases (creation and start). Signed-off-by: Chenghai Huang Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Stable-dep-of: 6aff4d977e2d ("crypto: hisilicon/hpre - support the hpre algorithm fallback") Signed-off-by: Sasha Levin commit cc7a36b6ac8f4403c85319a7990868a76335494f Author: Chenghai Huang Date: Thu Dec 18 21:44:50 2025 +0800 crypto: hisilicon/zip - support fallback for zip [ Upstream commit 73398f85a430cfebc2ff06ab836d6d9eb1484c79 ] When the hardware queue resource busy(no shareable queue) or memery alloc fail in initialization of acomp_alg, use soft algorithm to complete the work. Fixes: 1a9e6f59caee ("crypto: hisilicon/zip - remove zlib and gzip") Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3acd2479c770e89b1d9f56161171d64169433b5c Author: Chenghai Huang Date: Thu Dec 18 21:44:46 2025 +0800 crypto: hisilicon/qm - centralize the sending locks of each module into qm [ Upstream commit 8cd9b608ee8dea78cac3f373bd5e3b3de2755d46 ] When a single queue used by multiple tfms, the protection of shared resources by individual module driver programs is no longer sufficient. The hisi_qp_send needs to be ensured by the lock in qp. Fixes: 5fdb4b345cfb ("crypto: hisilicon - add a lock for the qp send operation") Signed-off-by: Chenghai Huang Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 23fcfd8c0d1fdd59bd724447f3950ff3defa7da6 Author: Chenghai Huang Date: Thu Dec 18 21:44:45 2025 +0800 crypto: hisilicon/qm - enhance the configuration of req_type in queue attributes [ Upstream commit 21452eaa06edb5f6038720e643aed0bbfffad9c3 ] Originally, when a queue was requested, it could only be configured with the default algorithm type of 0. Now, when multiple tfms use the same queue, the queue must be selected based on its attributes to meet the requirements of tfm tasks. So the algorithm type attribute of queue need to be distinguished. Just like a queue used for compression in ZIP cannot be used for decompression tasks. Fixes: 3f1ec97aacf1 ("crypto: hisilicon/qm - Put device finding logic into QM") Signed-off-by: Chenghai Huang Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2b8b12e3f869d1a8cd4ecde537e2d26deb9df04a Author: lizhi Date: Thu Dec 18 21:44:44 2025 +0800 crypto: hisilicon/hpre: extend tag field to 64 bits for better performance [ Upstream commit 3a1984758197f7fd4c557dd98090e8e0cf9f498e ] This commit expands the tag field in hpre_sqe structure from 16-bit to 64-bit. The change enables storing request addresses directly in the tag field, allowing callback functions to access request messages without the previous indirection mechanism. By eliminating the need for lookup tables, this modification reduces lock contention and associated overhead, leading to improved efficiency and simplified code. Fixes: c8b4b477079d ("crypto: hisilicon - add HiSilicon HPRE accelerator") Signed-off-by: lizhi Signed-off-by: Weili Qian Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 139e24de706eddc3e59888183a3cd601576c1621 Author: Chenghai Huang Date: Thu Dec 18 21:44:43 2025 +0800 crypto: hisilicon/sec - move backlog management to qp and store sqe in qp for callback [ Upstream commit 08eb67d23e5172a5d1e60f1f0acccee569fe10ba ] When multiple tfm use a same qp, the backlog data should be managed centrally by the qp, rather than in the qp_ctx of each req. Additionally, since SEC_BD_TYPE1 and SEC_BD_TYPE2 cannot use the tag of the sqe to carry the virtual address of the req, the sent sqe is stored in the qp. This allows the callback function to get the req address. To handle the differences between hardware types, the callback functions are split into two separate implementations. Fixes: f0ae287c5045 ("crypto: hisilicon/sec2 - implement full backlog mode for sec") Signed-off-by: Chenghai Huang Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 1f269645bb4c8d9b0911b75fc6972f8b61d6b75e Author: Chenghai Huang Date: Thu Dec 18 21:44:42 2025 +0800 crypto: hisilicon/zip - adjust the way to obtain the req in the callback function [ Upstream commit 19c2475ce1984cf675ebfbbeaa5509b2fb1887d6 ] In the shared queue design, multiple tfms use same qp, and one qp need to corresponds to multiple qp_ctx. So use tag to obtain the req virtual address. Build a one-to-one relationship between tfm and qp_ctx. finaly remove the old get_tag operation. Fixes: 2bcf36348ce5 ("crypto: hisilicon/zip - initialize operations about 'sqe' in 'acomp_alg.init'") Signed-off-by: Chenghai Huang Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c6eb4991a17762a0ffa09511ec9a761b15407f2f Author: Thomas Fourier Date: Thu Dec 18 11:12:57 2025 +0100 crypto: octeontx - fix dma_free_coherent() size [ Upstream commit 624a6760bf8464965c17c8df10b40b557eaa3002 ] The size of the buffer in alloc_command_queues() is curr->size + OTX_CPT_NEXT_CHUNK_PTR_SIZE, so used that length for dma_free_coherent(). Fixes: 10b4f09491bf ("crypto: marvell - add the Virtual Function driver for CPT") Signed-off-by: Thomas Fourier Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2bdeabe2b6478660ae15d8701a9311d9a1850a03 Author: Thomas Fourier Date: Thu Dec 18 10:56:45 2025 +0100 crypto: cavium - fix dma_free_coherent() size [ Upstream commit 941676c30ba5b40a01bed92448f457ce62fd1f07 ] The size of the buffer in alloc_command_queues() is curr->size + CPT_NEXT_CHUNK_PTR_SIZE, so used that length for dma_free_coherent(). Fixes: c694b233295b ("crypto: cavium - Add the Virtual Function driver for CPT") Signed-off-by: Thomas Fourier Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9029e8db69fb30f7d19b5d0917547c7872389520 Author: Gabriele Monaco Date: Mon Jan 12 15:04:13 2026 +0100 sched: Fix build for modules using set_tsk_need_resched() [ Upstream commit 8d737320166bd145af70a3133a9964b00ca81cba ] Commit adcc3bfa8806 ("sched: Adapt sched tracepoints for RV task model") added a tracepoint to the need_resched action that can be triggered also by set_tsk_need_resched. This function was previously accessible from out-of-tree modules but it's no longer available because the __trace_set_need_resched() symbol is not exported (together with the tracepoint itself, which was exported in a separate patch) and building such modules fails. Export __trace_set_need_resched to modules to fix those build issues. Fixes: adcc3bfa8806 ("sched: Adapt sched tracepoints for RV task model") Signed-off-by: Gabriele Monaco Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Phil Auld Link: https://patch.msgid.link/20260112140413.362202-1-gmonaco@redhat.com Signed-off-by: Sasha Levin commit 8ed7f3c03d0426b786e7941df36d1b5b2b7b9d24 Author: Thomas Gleixner Date: Tue Jan 13 17:47:37 2026 +0100 time/sched_clock: Use ACCESS_PRIVATE() to evaluate hrtimer::function [ Upstream commit 3db5306b0bd562ac0fe7eddad26c60ebb6f5fdd4 ] This dereference of sched_clock_timer::function was missed when the hrtimer callback function pointer was marked private. Fixes: 04257da0c99c ("hrtimers: Make callback function pointer private") Reported-by: kernel test robot Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/875x95jw7q.ffs@tglx Closes: https://lore.kernel.org/oe-kbuild-all/202601131713.KsxhXQ0M-lkp@intel.com/ Signed-off-by: Sasha Levin commit 9b94124cb9c239ab369b85a3a9a660a5f331557a Author: Thomas Weißschuh Date: Tue Dec 23 07:59:17 2025 +0100 ARM: VDSO: Patch out __vdso_clock_getres() if unavailable [ Upstream commit b9fecf0dddfc55cd7d02b0011494da3c613f7cde ] The vDSO code hides symbols which are non-functional. __vdso_clock_getres() was not added to this list when it got introduced. Fixes: 052e76a31b4a ("ARM: 8931/1: Add clock_getres entry point") Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-6-97ea7a06a543@linutronix.de Signed-off-by: Sasha Levin commit 26cbfd67fdb5e11f74f1e44fecc11505717e6a93 Author: Gabriele Monaco Date: Fri Dec 5 14:16:16 2025 +0100 sched: Export hidden tracepoints to modules [ Upstream commit 6c125b85f3c87b4bf7dba91af6f27d9600b9dba0 ] The tracepoints sched_entry, sched_exit and sched_set_need_resched are not exported to tracefs as trace events, this allows only kernel code to access them. Helper modules like [1] can be used to still have the tracepoints available to ftrace for debugging purposes, but they do rely on the tracepoints being exported. Export the 3 not exported tracepoints. Note that sched_set_state is already exported as the macro is called from modules. [1] - https://github.com/qais-yousef/sched_tp.git Fixes: adcc3bfa8806 ("sched: Adapt sched tracepoints for RV task model") Signed-off-by: Gabriele Monaco Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Phil Auld Link: https://patch.msgid.link/20251205131621.135513-9-gmonaco@redhat.com Signed-off-by: Sasha Levin commit c3cfe342d1209562f4e2d1bab6414035fe337f91 Author: Varun R Mallya Date: Wed Jan 7 05:05:27 2026 +0530 libbpf: Fix OOB read in btf_dump_get_bitfield_value [ Upstream commit 5714ca8cba5ed736f3733663c446cbee63a10a64 ] When dumping bitfield data, btf_dump_get_bitfield_value() reads data based on the underlying type's size (t->size). However, it does not verify that the provided data buffer (data_sz) is large enough to contain these bytes. If btf_dump__dump_type_data() is called with a buffer smaller than the type's size, this leads to an out-of-bounds read. This was confirmed by AddressSanitizer in the linked issue. Fix this by ensuring we do not read past the provided data_sz limit. Fixes: a1d3cc3c5eca ("libbpf: Avoid use of __int128 in typed dump display") Reported-by: Harrison Green Suggested-by: Alan Maguire Signed-off-by: Varun R Mallya Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260106233527.163487-1-varunrmallya@gmail.com Closes: https://github.com/libbpf/libbpf/issues/928 Signed-off-by: Sasha Levin commit c2a90d855bea5a3666d29846d9b0da869a91f9bb Author: Puranjay Mohan Date: Wed Dec 31 14:10:50 2025 -0800 selftests/bpf: veristat: fix printing order in output_stats() [ Upstream commit c286e7e9d1f1f3d90ad11c37e896f582b02d19c4 ] The order of the variables in the printf() doesn't match the text and therefore veristat prints something like this: Done. Processed 24 files, 0 programs. Skipped 62 files, 0 programs. When it should print: Done. Processed 24 files, 62 programs. Skipped 0 files, 0 programs. Fix the order of variables in the printf() call. Fixes: 518fee8bfaf2 ("selftests/bpf: make veristat skip non-BPF and failing-to-open BPF objects") Tested-by: Eduard Zingerman Signed-off-by: Puranjay Mohan Link: https://lore.kernel.org/r/20251231221052.759396-1-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 36abc0b2df605f51e19490d759f823faf8ce5852 Author: Giovanni Cabiddu Date: Thu Nov 20 16:30:46 2025 +0000 crypto: qat - fix warning on adf_pfvf_pf_proto.c [ Upstream commit 994689b8f91b02fdb5f64cba2412cde5ef3084b5 ] Building the QAT driver with -Wmaybe-uninitialized triggers warnings in qat_common/adf_pfvf_pf_proto.c. Specifically, the variables blk_type, blk_byte, and byte_max may be used uninitialized in handle_blkmsg_req(): make M=drivers/crypto/intel/qat W=1 C=2 "KCFLAGS=-Werror" \ KBUILD_CFLAGS_KERNEL=-Wmaybe-uninitialized \ CFLAGS_MODULE=-Wmaybe-uninitialized ... warning: ‘byte_max’ may be used uninitialized [-Wmaybe-uninitialized] warning: ‘blk_type’ may be used uninitialized [-Wmaybe-uninitialized] warning: ‘blk_byte’ may be used uninitialized [-Wmaybe-uninitialized] Although the caller of handle_blkmsg_req() always provides a req.type that is handled by the switch, the compiler cannot guarantee this. Add a default case to the switch statement to handle an invalid req.type. Fixes: 673184a2a58f ("crypto: qat - introduce support for PFVF block messages") Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 1838a7507e1339cf10b356791d75260151492259 Author: Sandipan Das Date: Fri Dec 5 16:16:46 2025 -0800 perf/x86/core: Do not set bit width for unavailable counters [ Upstream commit b456a6ba5756b6fb7e651775343e713bd08418e7 ] Not all x86 processors have fixed counters. It may also be the case that a processor has only fixed counters and no general-purpose counters. Set the bit widths corresponding to each counter type only if such counters are available. Fixes: b3d9468a8bd2 ("perf, x86: Expose perf capability to other modules") Signed-off-by: Sandipan Das Co-developed-by: Dapeng Mi Signed-off-by: Dapeng Mi Signed-off-by: Mingwei Zhang Signed-off-by: Sean Christopherson Signed-off-by: Peter Zijlstra (Intel) Tested-by: Xudong Hao Link: https://patch.msgid.link/20251206001720.468579-11-seanjc@google.com Signed-off-by: Sasha Levin commit 7e4c643aa3b22ec685cd7889f5506d2b015ed80f Author: Andrew Cooper Date: Wed Nov 26 13:03:52 2025 +0000 x86/cpu/amd: Correct the microcode table for Zenbleed [ Upstream commit fb7bfa31b8e8569f154f2fe0ea6c2f03c0f087aa ] The good revisions are tied to exact steppings, meaning it's not valid to match on model number alone, let alone a range. This is probably only a latent issue. From public microcode archives, the following CPUs exist 17-30-00, 17-60-00, 17-70-00 and would be captured by the model ranges. They're likely pre-production steppings, and likely didn't get Zenbleed microcode, but it's still incorrect to compare them to a different steppings revision. Either way, convert the logic to use x86_match_min_microcode_rev(), which is the preferred mechanism. Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix") Signed-off-by: Andrew Cooper Signed-off-by: Ingo Molnar Cc: Borislav Petkov Cc: Mario Limonciello Cc: x86@kernel.org Link: https://patch.msgid.link/20251126130352.880424-1-andrew.cooper3@citrix.com Signed-off-by: Sasha Levin commit 445d35742d8636225d01e26f90fb49fa0327d8c1 Author: Jens Axboe Date: Thu Feb 5 08:38:20 2026 -0700 io_uring/kbuf: fix memory leak if io_buffer_add_list fails [ Upstream commit 442ae406603a94f1a263654494f425302ceb0445 ] io_register_pbuf_ring() ignores the return value of io_buffer_add_list(), which can fail if xa_store() returns an error (e.g., -ENOMEM). When this happens, the function returns 0 (success) to the caller, but the io_buffer_list structure is neither added to the xarray nor freed. In practice this requires failure injection to hit, hence not a real issue. But it should get fixed up none the less. Fixes: c7fb19428d67 ("io_uring: add support for ring mapped supplied buffers") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6715560527e343a387e4a0d2e6c401748e89fa55 Author: Salah Triki Date: Fri Jan 30 21:47:59 2026 +0100 s390/cio: Fix device lifecycle handling in css_alloc_subchannel() [ Upstream commit f65c75b0b9b5a390bc3beadcde0a6fbc3ad118f7 ] `css_alloc_subchannel()` calls `device_initialize()` before setting up the DMA masks. If `dma_set_coherent_mask()` or `dma_set_mask()` fails, the error path frees the subchannel structure directly, bypassing the device model reference counting. Once `device_initialize()` has been called, the embedded struct device must be released via `put_device()`, allowing the release callback to free the container structure. Fix the error path by dropping the initial device reference with `put_device()` instead of calling `kfree()` directly. This ensures correct device lifetime handling and avoids potential use-after-free or double-free issues. Fixes: e5dcf0025d7af ("s390/css: move subchannel lock allocation") Signed-off-by: Salah Triki Reviewed-by: Vineeth Vijayan Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit af5b0854fba03ce47c09ada29d535a9f702bd2ab Author: Gui-Dong Han Date: Tue Feb 3 11:19:43 2026 +0800 PM: sleep: wakeirq: harden dev_pm_clear_wake_irq() against races [ Upstream commit 5c9ecd8e6437cd55a38ea4f1e1d19cee8e226cb8 ] dev_pm_clear_wake_irq() currently uses a dangerous pattern where dev->power.wakeirq is read and checked for NULL outside the lock. If two callers invoke this function concurrently, both might see a valid pointer and proceed. This could result in a double-free when the second caller acquires the lock and tries to release the same object. Address this by removing the lockless check of dev->power.wakeirq. Instead, acquire dev->power.lock immediately to ensure the check and the subsequent operations are atomic. If dev->power.wakeirq is NULL under the lock, simply unlock and return. This guarantees that concurrent calls cannot race to free the same object. Based on a quick scan of current users, I did not find an actual bug as drivers seem to rely on their own synchronization. However, since asynchronous usage patterns exist (e.g., in drivers/net/wireless/ti/wlcore), I believe a race is theoretically possible if the API is used less carefully in the future. This change hardens the API to be robust against such cases. Fixes: 4990d4fe327b ("PM / Wakeirq: Add automated device wake IRQ handling") Signed-off-by: Gui-Dong Han Link: https://patch.msgid.link/20260203031943.1924-1-hanguidong02@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 630f3eca39624670ed020909192efc06977423ec Author: Yaxiong Tian Date: Tue Feb 3 10:48:52 2026 +0800 cpufreq: intel_pstate: Enable asym capacity only when CPU SMT is not possible [ Upstream commit 1fedbb589448bee9f20bb2ed9c850d1d2cf9963c ] According to the description in the intel_pstate.rst documentation, Capacity-Aware Scheduling and Energy-Aware Scheduling are only supported on a hybrid processor without SMT. Previously, the system used sched_smt_active() for judgment, which is not a strict condition because users can switch it on or off via /sys at any time. This could lead to incorrect driver settings in certain scenarios. For example, on a CPU that supports SMT, a user can disable SMT via the nosmt parameter to enable asym capacity, and then re-enable SMT via /sys. In such cases, some settings in the driver would no longer be correct. To address this issue, replace sched_smt_active() with cpu_smt_possible(), and only enable asym capacity when CPU SMT is not possible. Fixes: 929ebc93ccaa ("cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems") Signed-off-by: Yaxiong Tian [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260203024852.301066-1-tianyaxiong@kylinos.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 5cbf75e0f07f6597e524924665fb4bc727e7aa1a Author: Leo Yan Date: Tue Feb 3 14:40:43 2026 +0000 perf: arm_spe: Properly set hw.state on failures [ Upstream commit 283182c1c239f6873d1a50e9e710c1a699f2256b ] When arm_spe_pmu_next_off() fails to calculate a valid limit, it returns zero to indicate that tracing should not start. However, the caller arm_spe_perf_aux_output_begin() does not propagate this failure by updating hwc->state, cause the error to be silently ignored by upper layers. Because hwc->state remains zero after a failure, arm_spe_pmu_start() continues to programs filter registers unnecessarily. The driver still reports success to the perf core, so the core assumes the SPE event was enabled and proceeds to enable other events. This breaks event group semantics: SPE is already stopped while other events in the same group are enabled. Fix this by updating arm_spe_perf_aux_output_begin() to return a status code indicating success (0) or failure (-EIO). Both the interrupt handler and arm_spe_pmu_start() check the return value and call arm_spe_pmu_stop() to set PERF_HES_STOPPED in hwc->state. In the interrupt handler, the period (e.g., period_left) needs to be updated, so PERF_EF_UPDATE is passed to arm_spe_pmu_stop(). When the error occurs during event start, the trace unit is not yet enabled, so a flag '0' is used to drain buffer and update state only. Fixes: d5d9696b0380 ("drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension") Signed-off-by: Leo Yan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit c787a235deb33be6eda40beee8f561da5fd8cb8c Author: Breno Leitao Date: Mon Feb 2 10:32:51 2026 -0800 arm64/gcs: Fix error handling in arch_set_shadow_stack_status() [ Upstream commit 53c998527ffa60f9deda8974a11ad39790684159 ] alloc_gcs() returns an error-encoded pointer on failure, which comes from do_mmap(), not NULL. The current NULL check fails to detect errors, which could lead to using an invalid GCS address. Use IS_ERR_VALUE() to properly detect errors, consistent with the check in gcs_alloc_thread_stack(). Fixes: b57180c75c7e ("arm64/gcs: Implement shadow stack prctl() interface") Reviewed-by: Mark Brown Signed-off-by: Breno Leitao Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 1141301a7195416d6947bc557b0cc46dec95899a Author: Samuel Wu Date: Fri Jan 23 17:21:29 2026 -0800 PM: wakeup: Handle empty list in wakeup_sources_walk_start() [ Upstream commit 75ce02f4bc9a8b8350b6b1b01872467b0cc960cc ] In the case of an empty wakeup_sources list, wakeup_sources_walk_start() will return an invalid but non-NULL address. This also affects wrappers of the aforementioned function, like for_each_wakeup_source(). Update wakeup_sources_walk_start() to return NULL in case of an empty list. Fixes: b4941adb24c0 ("PM: wakeup: Add routine to help fetch wakeup source object.") Signed-off-by: Samuel Wu [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260124012133.2451708-2-wusamuel@google.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 80d58a8915d7d4fcf4343c02522602c85ef916fa Author: Xiao Ni Date: Tue Jan 27 15:39:27 2026 +0800 md: fix return value of mddev_trylock [ Upstream commit 05c8de4f09b08e97c6ecb190dcec0e68b167cb03 ] A return value of 0 is treaded as successful lock acquisition. In fact, a return value of 1 means getting the lock successfully. Link: https://lore.kernel.org/linux-raid/20260127073951.17248-1-xni@redhat.com Fixes: 9e59d609763f ("md: call del_gendisk in control path") Reported-by: Bart Van Assche Closes: https://lore.kernel.org/linux-raid/20250611073108.25463-1-xni@redhat.com/T/#mfa369ef5faa4aa58e13e6d9fdb88aecd862b8f2f Signed-off-by: Xiao Ni Reviewed-by: Bart Van Assche Reviewed-by: Li Nan Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit ec10e3dc93994b87adf7c759a4639fe34013989a Author: Zilin Guan Date: Mon Jan 26 07:15:33 2026 +0000 md/raid1: fix memory leak in raid1_run() [ Upstream commit 6abc7d5dcf0ee0f85e16e41c87fbd06231f28753 ] raid1_run() calls setup_conf() which registers a thread via md_register_thread(). If raid1_set_limits() fails, the previously registered thread is not unregistered, resulting in a memory leak of the md_thread structure and the thread resource itself. Add md_unregister_thread() to the error path to properly cleanup the thread, which aligns with the error handling logic of other paths in this function. Compile tested only. Issue found using a prototype static analysis tool and code review. Link: https://lore.kernel.org/linux-raid/20260126071533.606263-1-zilin@seu.edu.cn Fixes: 97894f7d3c29 ("md/raid1: use the atomic queue limit update APIs") Signed-off-by: Zilin Guan Reviewed-by: Li Nan Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 02455f658db8e32cc4ae9adb9c2ff6d1b80bb0b0 Author: Roger Pau Monne Date: Wed Jan 28 12:05:08 2026 +0100 Partial revert "x86/xen: fix balloon target initialization for PVH dom0" [ Upstream commit 0949c646d64697428ff6257d52efa5093566868d ] This partially reverts commit 87af633689ce16ddb166c80f32b120e50b1295de so the current memory target for PV guests is still fetched from start_info->nr_pages, which matches exactly what the toolstack sets the initial memory target to. Using get_num_physpages() is possible on PV also, but needs adjusting to take into account the ISA hole and the PFN at 0 not considered usable memory despite being populated, and hence would need extra adjustments. Instead of carrying those extra adjustments switch back to the previous code. That leaves Linux with a difference in how current memory target is obtained for HVM vs PV, but that's better than adding extra logic just for PV. However if switching to start_info->nr_pages for PV domains we need to differentiate between released pages (freed back to the hypervisor) as opposed to pages in the physmap which are not populated to start with. Introduce a new xen_unpopulated_pages to account for papges that have never been populated, and hence in the PV case don't need subtracting. Fixes: 87af633689ce ("x86/xen: fix balloon target initialization for PVH dom0") Reported-by: James Dingwall Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260128110510.46425-2-roger.pau@citrix.com> Signed-off-by: Sasha Levin commit f75a5555e0049e7857eae25b60aee98b80e287ec Author: Govindarajulu Varadarajan Date: Fri Jan 30 10:14:12 2026 -0700 ublk: Validate SQE128 flag before accessing the cmd [ Upstream commit da7e4b75e50c087d2031a92f6646eb90f7045a67 ] ublk_ctrl_cmd_dump() accesses (header *)sqe->cmd before IO_URING_F_SQE128 flag check. This could cause out of boundary memory access. Move the SQE128 flag check earlier in ublk_ctrl_uring_cmd() to return -EINVAL immediately if the flag is not set. Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Signed-off-by: Govindarajulu Varadarajan Reviewed-by: Caleb Sander Mateos Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9b03dda1453e8e8c580e10d90de0179d489deb6c Author: Caleb Sander Mateos Date: Wed Jan 28 13:56:34 2026 -0700 ublk: restore auto buf unregister refcount optimization [ Upstream commit ad5f2e2908c9b79a86529281a48e94d644d43dc7 ] Commit 1ceeedb59749 ("ublk: optimize UBLK_IO_UNREGISTER_IO_BUF on daemon task") optimized ublk request buffer unregistration to use a non-atomic reference count decrement when performed on the ublk_io's daemon task. The optimization applied to auto buffer unregistration, which happens as part of handling UBLK_IO_COMMIT_AND_FETCH_REQ on the daemon task. However, commit b749965edda8 ("ublk: remove ublk_commit_and_fetch()") reordered the ublk_sub_req_ref() for the completed request before the io_buffer_unregister_bvec() call. As a result, task_registered_buffers is already 0 when io_buffer_unregister_bvec() calls ublk_io_release() and the non-atomic refcount optimization doesn't apply. Move the io_buffer_unregister_bvec() call back to before ublk_need_complete_req() to restore the reference counting optimization. Signed-off-by: Caleb Sander Mateos Fixes: b749965edda8 ("ublk: remove ublk_commit_and_fetch()") Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8344d5da9df74fdbef676214d0c482fc822a01ca Author: Felix Gu Date: Sat Jan 24 03:06:40 2026 +0800 thermal/of: Fix reference leak in thermal_of_cm_lookup() [ Upstream commit a1fe789a96fe47733c133134fd264cb7ca832395 ] In thermal_of_cm_lookup(), tr_np is obtained via of_parse_phandle(), but never released. Use the __free(device_node) cleanup attribute to automatically release the node and fix the leak. Fixes: 423de5b5bc5b ("thermal/of: Fix cdev lookup in thermal_of_should_bind()") Signed-off-by: Felix Gu Reviewed-by: Lukasz Luba [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260124-thermal_of-v1-1-54d3416948cf@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 769a8a732e825a8e2ce7270cb211bdbf7f87eb4f Author: Christoph Hellwig Date: Mon Jan 26 06:53:38 2026 +0100 iomap: fix submission side handling of completion side errors [ Upstream commit 4ad357e39b2ecd5da7bcc7e840ee24d179593cd5 ] The "if (dio->error)" in iomap_dio_bio_iter exists to stop submitting more bios when a completion already return an error. Commit cfe057f7db1f ("iomap_dio_actor(): fix iov_iter bugs") made it revert the iov by "copied", which is very wrong given that we've already consumed that range and submitted a bio for it. Fixes: cfe057f7db1f ("iomap_dio_actor(): fix iov_iter bugs") Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Reviewed-by: Darrick J. Wong Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 67bbf2527c1d0e48d0b92b6851c4e7c0810dd2db Author: Felix Gu Date: Wed Jan 21 23:32:06 2026 +0800 cpufreq: scmi: Fix device_node reference leak in scmi_cpu_domain_id() [ Upstream commit 0b7fbf9333fa4699a53145bad8ce74ea986caa13 ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In scmi_cpu_domain_id(), it does not release the reference. Fixes: e336baa4193e ("cpufreq: scmi: Prepare to move OF parsing of domain-id to cpufreq") Signed-off-by: Felix Gu Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 27feb209c2d7bf86d652ff9f5a66c078f30ad71a Author: Aleks Todorov Date: Fri Jan 23 14:03:44 2026 +0000 OPP: Return correct value in dev_pm_opp_get_level [ Upstream commit 0b7277e02dabba2a9921a7f4761ae6e627e7297a ] Commit 073d3d2ca7d4 ("OPP: Level zero is valid") modified the documentation for this function to indicate that errors should return a non-zero value to avoid colliding with the OPP level zero, however forgot to actually update the return. No in-tree kernel code depends on the error value being 0. Fixes: 073d3d2ca7d4 ("OPP: Level zero is valid") Signed-off-by: Aleks Todorov Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 095417d6b669c2dec39a5842ccb94df915f97f54 Author: Yu Kuai Date: Sat Jan 24 02:26:23 2026 +0800 md/md-llbitmap: fix percpu_ref not resurrected on suspend timeout [ Upstream commit d119bd2e1643cc023210ff3c6f0657e4f914e71d ] When llbitmap_suspend_timeout() times out waiting for percpu_ref to become zero, it returns -ETIMEDOUT without resurrecting the percpu_ref. The caller (md_llbitmap_daemon_fn) then continues to the next page without calling llbitmap_resume(), leaving the percpu_ref in a killed state permanently. Fix this by resurrecting the percpu_ref before returning the error, ensuring the page control structure remains usable for subsequent operations. Link: https://lore.kernel.org/linux-raid/20260123182623.3718551-3-yukuai@fnnas.com Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Signed-off-by: Yu Kuai Reviewed-by: Li Nan Signed-off-by: Sasha Levin commit 870b9f15867b0e70f3459ef3974b043e8b229690 Author: Yu Kuai Date: Sat Jan 24 02:26:22 2026 +0800 md/raid5: fix IO hang with degraded array with llbitmap [ Upstream commit cd1635d844d26471c56c0a432abdee12fc9ad735 ] When llbitmap bit state is still unwritten, any new write should force rcw, as bitmap_ops->blocks_synced() is checked in handle_stripe_dirtying(). However, later the same check is missing in need_this_block(), causing stripe to deadloop during handling because handle_stripe() will decide to go to handle_stripe_fill(), meanwhile need_this_block() always return 0 and nothing is handled. Link: https://lore.kernel.org/linux-raid/20260123182623.3718551-2-yukuai@fnnas.com Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Signed-off-by: Yu Kuai Reviewed-by: Li Nan Signed-off-by: Sasha Levin commit 5bf494167291e762fe9ffce50c9dc5095fa84089 Author: Li Nan Date: Mon Jan 5 19:02:58 2026 +0800 md/raid10: fix any_working flag handling in raid10_sync_request [ Upstream commit 99582edb3f62e8ee6c34512021368f53f9b091f2 ] In raid10_sync_request(), 'any_working' indicates if any IO will be submitted. When there's only one In_sync disk with badblocks, 'any_working' might be set to 1 but no IO is submitted. Fix it by setting 'any_working' after badblock checks. Link: https://lore.kernel.org/linux-raid/20260105110300.1442509-11-linan666@huaweicloud.com Fixes: e875ecea266a ("md/raid10 record bad blocks as needed during recovery.") Signed-off-by: Li Nan Reviewed-by: Yu Kuai Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 32c046a506ea9270c06d09195c0b400cf1285261 Author: Yu Kuai Date: Thu Jan 15 01:12:29 2026 +0800 md/raid5: fix raid5_run() to return error when log_init() fails [ Upstream commit 2d9f7150ac197ce79c9c917a004d4cf0b26ad7e0 ] Since commit f63f17350e53 ("md/raid5: use the atomic queue limit update APIs"), the abort path in raid5_run() returns 'ret' instead of -EIO. However, if log_init() fails, 'ret' is still 0 from the previous successful call, causing raid5_run() to return success despite the failure. Fix this by capturing the return value from log_init(). Link: https://lore.kernel.org/linux-raid/20260114171241.3043364-2-yukuai@fnnas.com Fixes: f63f17350e53 ("md/raid5: use the atomic queue limit update APIs") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202601130531.LGfcZsa4-lkp@intel.com/ Signed-off-by: Yu Kuai Reviewed-by: Li Nan Reviewed-by: Xiao Ni Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 649ddf7e5aa64ef53e039fb9daea51f0b6460b02 Author: Rafael J. Wysocki Date: Tue Jan 20 16:23:41 2026 +0100 thermal: intel: x86_pkg_temp_thermal: Handle invalid temperature [ Upstream commit 9635c586a559ba0e45b2bfbff79c937ddbaf1a62 ] After commit be0a3600aa1e ("thermal: sysfs: Rework the handling of trip point updates"), THERMAL_TEMP_INVALID can be passed to sys_set_trip_temp() and it is treated as a regular temperature value there, so the sysfs write fails even though it is expected to succeed and disable the given trip point. Address this by making sys_set_trip_temp() clear its temp variable when it is equal to THERMAL_TEMP_INVALID. Fixes: be0a3600aa1e ("thermal: sysfs: Rework the handling of trip point updates") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2815400.mvXUDI8C0e@rafael.j.wysocki Signed-off-by: Sasha Levin commit 9d589661f21fa841cb1c08110f41d9e104c5f7cd Author: Rafael J. Wysocki Date: Tue Jan 20 16:26:14 2026 +0100 cpuidle: governors: menu: Always check timers with tick stopped [ Upstream commit 80606f4eb8d7484ab7f7d6f0fd30d71e6fbcf328 ] After commit 5484e31bbbff ("cpuidle: menu: Skip tick_nohz_get_sleep_length() call in some cases"), if the return value of get_typical_interval() multiplied by NSEC_PER_USEC is not greater than RESIDENCY_THRESHOLD_NS, the menu governor will skip computing the time till the closest timer. If that happens when the tick has been stopped already, the selected idle state may be too deep due to the subsequent check comparing predicted_ns with TICK_NSEC and causing its value to be replaced with the expected time till the closest timer, which is KTIME_MAX in that case. That will cause the deepest enabled idle state to be selected, but the time till the closest timer very well may be shorter than the target residency of that state, in which case a shallower state should be used. Address this by making menu_select() always compute the time till the closest timer when the tick has been stopped. Also move the predicted_ns check mentioned above into the branch in which the time till the closest timer is determined because it only needs to be done in that case. Fixes: 5484e31bbbff ("cpuidle: menu: Skip tick_nohz_get_sleep_length() call in some cases") Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle Link: https://patch.msgid.link/5959091.DvuYhMxLoT@rafael.j.wysocki Signed-off-by: Sasha Levin commit d733106e7c652d5fc3d497e9ee74456476b905d3 Author: Jens Axboe Date: Wed Jan 21 11:48:56 2026 -0700 io_uring/sync: validate passed in offset [ Upstream commit 649dd18f559891bdafc5532d737c7dfb56060a6d ] Check if the passed in offset is negative once cast to sync->off. This ensures that -EINVAL is returned for that case, like it would be for sync_file_range(2). Fixes: c992fe2925d7 ("io_uring: add fsync support") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1d126db2f263f2ce3968203ecb06faf1ea8a5007 Author: Jens Axboe Date: Wed Jan 21 11:21:32 2026 -0700 io_uring/eventfd: remove unused ctx->evfd_last_cq_tail member [ Upstream commit 07f3c3a1cd56c2048a92dad0c11f15e4ac3888c1 ] A previous commit got rid of any use of this member, but forgot to remove it. Kill it. Fixes: f4bb2f65bb81 ("io_uring/eventfd: move ctx->evfd_last_cq_tail into io_ev_fd") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b24595b86920911d2b04f862422b896a0620e9ad Author: Alexey Simakov Date: Wed Jan 14 13:20:17 2026 +0100 ACPICA: Fix NULL pointer dereference in acpi_ev_address_space_dispatch() [ Upstream commit f851e03bce968ff9b3faad1b616062e1244fd38d ] Cover a missed execution path with a new check. Fixes: 0acf24ad7e10 ("ACPICA: Add support for PCC Opregion special context data") Link: https://github.com/acpica/acpica/commit/f421dd9dd897 Signed-off-by: Alexey Simakov Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3030574.e9J7NaK4W3@rafael.j.wysocki Signed-off-by: Sasha Levin commit c1c266e2c1f10a115adaf898652e56b9f007a915 Author: Caleb Sander Mateos Date: Mon Jan 5 14:05:40 2026 -0700 io_uring: use release-acquire ordering for IORING_SETUP_R_DISABLED [ Upstream commit 7a8737e1132ff07ca225aa7a4008f87319b5b1ca ] io_uring_enter(), __io_msg_ring_data(), and io_msg_send_fd() read ctx->flags and ctx->submitter_task without holding the ctx's uring_lock. This means they may race with the assignment to ctx->submitter_task and the clearing of IORING_SETUP_R_DISABLED from ctx->flags in io_register_enable_rings(). Ensure the correct ordering of the ctx->flags and ctx->submitter_task memory accesses by storing to ctx->flags using release ordering and loading it using acquire ordering. Signed-off-by: Caleb Sander Mateos Fixes: 4add705e4eeb ("io_uring: remove io_register_submitter") Reviewed-by: Joanne Koong Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cb45bcc9709306b0cc2e0184233ca0578fdfbc7e Author: Teddy Astie Date: Tue Jan 6 17:36:50 2026 +0000 xen/virtio: Don't use grant-dma-ops when running as Dom0 [ Upstream commit dc8ea8714311e549ee93a2b0bdd5487d20bfadbf ] Dom0 inherit devices from the machine and is usually in PV mode. If we are running in a virtual that has virtio devices, these devices would be considered as using grants with Dom0 as backend, while being the said Dom0 itself, while we want to use these devices like regular PCI devices. Fix this by preventing grant-dma-ops from being used when running as Dom0 (initial domain). We still keep the device-tree logic as-is. Signed-off-by: Teddy Astie Fixes: 61367688f1fb0 ("xen/virtio: enable grant based virtio on x86") Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <6698564dd2270a9f7377b78ebfb20cb425cabbe8.1767720955.git.teddy.astie@vates.tech> Signed-off-by: Sasha Levin commit 68f38f648e4b5bed2aeadd2f711e25302e6490f8 Author: Rafael J. Wysocki Date: Tue Dec 23 18:09:11 2025 +0800 ACPI: processor: Update cpuidle driver check in __acpi_processor_start() [ Upstream commit 0089ce1c056aee547115bdc25c223f8f88c08498 ] Commit 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration") moved the ACPI idle driver registration to acpi_processor_driver_init() and acpi_processor_power_init() does not register an idle driver any more. Accordingly, the cpuidle driver check in __acpi_processor_start() needs to be updated to avoid calling acpi_processor_power_init() without a cpuidle driver, in which case the registration of the cpuidle device in that function would lead to a NULL pointer dereference in __cpuidle_register_device(). Fixes: 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration") Signed-off-by: Rafael J. Wysocki Reviewed-by: Mario Limonciello (AMD) Tested-by: Borislav Petkov (AMD) Link: https://patch.msgid.link/20251223100914.2407069-4-lihuisong@huawei.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 7cce69596cecc64d0548c3bbf11ef5b67a135100 Author: Florian-Ewald Mueller Date: Fri Dec 5 13:47:32 2025 +0100 rnbd-srv: Fix server side setting of bi_size for special IOs [ Upstream commit 4ac9690d4b9456ca1d5276d86547fa2e7cd47684 ] On rnbd-srv, the bi_size of the bio is set during the bio_add_page function, to which datalen is passed. But for special IOs like DISCARD and WRITE_ZEROES, datalen is 0, since there is no data to write. For these special IOs, use the bi_size of the rnbd_msg_io. Fixes: f6f84be089c9 ("block/rnbd-srv: Add sanity check and remove redundant assignment") Signed-off-by: Florian-Ewald Mueller Signed-off-by: Md Haris Iqbal Signed-off-by: Grzegorz Prajsner Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cbdb9f3adf5428ff702193122973288cc80a66be Author: Shyam Prasad N Date: Sat Jan 31 14:03:05 2026 +0530 netfs: avoid double increment of retry_count in subreq [ Upstream commit a5ca32d031bbba5160e1f555aabb75a3f40f918d ] This change fixes the instance of double incrementing of retry_count. The increment of this count already happens when netfs_reissue_write gets called. Incrementing this value before is not necessary. Fixes: 4acb665cf4f3 ("netfs: Work around recursion by abandoning retry if nothing read") Acked-by: David Howells Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Sasha Levin commit e66dcf7bb9c4df5582c82bc3582725abcbfbea73 Author: Paulo Alcantara Date: Thu Feb 5 13:19:52 2026 -0300 smb: client: fix potential UAF and double free in smb2_open_file() [ Upstream commit ebbbc4bfad4cb355d17c671223d0814ee3ef4eda ] Zero out @err_iov and @err_buftype before retrying SMB2_open() to prevent an UAF bug if @data != NULL, otherwise a double free. Fixes: e3a43633023e ("smb/client: fix memory leak in smb2_open_file()") Reported-by: David Howells Closes: https://lore.kernel.org/r/2892312.1770306653@warthog.procyon.org.uk Signed-off-by: Paulo Alcantara (Red Hat) Reviewed-by: David Howells Reviewed-by: ChenXiaoSong Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 5de1aa0bf3a5db0b3cbf61959da5ac61250833ed Author: Gao Xiang Date: Tue Feb 3 16:25:36 2026 +0800 erofs: fix inline data read failure for ztailpacking pclusters [ Upstream commit c134a40f86efb8d6b5a949ef70e06d5752209be5 ] Compressed folios for ztailpacking pclusters must be valid before adding these pclusters to I/O chains. Otherwise, z_erofs_decompress_pcluster() may assume they are already valid and then trigger a NULL pointer dereference. It is somewhat hard to reproduce because the inline data is in the same block as the tail of the compressed indexes, which are usually read just before. However, it may still happen if a fatal signal arrives while read_mapping_folio() is running, as shown below: erofs: (device dm-1): z_erofs_pcluster_begin: failed to get inline data -4 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 ... pc : z_erofs_decompress_queue+0x4c8/0xa14 lr : z_erofs_decompress_queue+0x160/0xa14 sp : ffffffc08b3eb3a0 x29: ffffffc08b3eb570 x28: ffffffc08b3eb418 x27: 0000000000001000 x26: ffffff8086ebdbb8 x25: ffffff8086ebdbb8 x24: 0000000000000001 x23: 0000000000000008 x22: 00000000fffffffb x21: dead000000000700 x20: 00000000000015e7 x19: ffffff808babb400 x18: ffffffc089edc098 x17: 00000000c006287d x16: 00000000c006287d x15: 0000000000000004 x14: ffffff80ba8f8000 x13: 0000000000000004 x12: 00000006589a77c9 x11: 0000000000000015 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : ffffffffffffffe0 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: z_erofs_decompress_queue+0x4c8/0xa14 z_erofs_runqueue+0x908/0x97c z_erofs_read_folio+0x128/0x228 filemap_read_folio+0x68/0x128 filemap_get_pages+0x44c/0x8b4 filemap_read+0x12c/0x5b8 generic_file_read_iter+0x4c/0x15c do_iter_readv_writev+0x188/0x1e0 vfs_iter_read+0xac/0x1a4 backing_file_read_iter+0x170/0x34c ovl_read_iter+0xf0/0x140 vfs_read+0x28c/0x344 ksys_read+0x80/0xf0 __arm64_sys_read+0x24/0x34 invoke_syscall+0x60/0x114 el0_svc_common+0x88/0xe4 do_el0_svc+0x24/0x30 el0_svc+0x40/0xa8 el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1bc/0x1c0 Fix this by reading the inline data before allocating and adding the pclusters to the I/O chains. Fixes: cecf864d3d76 ("erofs: support inline data decompression") Reported-by: Zhiguo Niu Reviewed-and-tested-by: Zhiguo Niu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 7d4eadee7042d27fcea659fcdd738f463a7d2e70 Author: Boris Burkov Date: Thu Jan 29 16:11:21 2026 -0800 btrfs: fix EEXIST abort due to non-consecutive gaps in chunk allocation [ Upstream commit b14c5e04bd0f722ed631845599d52d03fcae1bc1 ] I have been observing a number of systems aborting at insert_dev_extents() in btrfs_create_pending_block_groups(). The following is a sample stack trace of such an abort coming from forced chunk allocation (typically behind CONFIG_BTRFS_EXPERIMENTAL) but this can theoretically happen to any DUP chunk allocation. [81.801] ------------[ cut here ]------------ [81.801] BTRFS: Transaction aborted (error -17) [81.801] WARNING: fs/btrfs/block-group.c:2876 at btrfs_create_pending_block_groups+0x721/0x770 [btrfs], CPU#1: bash/319 [81.802] Modules linked in: virtio_net btrfs xor zstd_compress raid6_pq null_blk [81.803] CPU: 1 UID: 0 PID: 319 Comm: bash Kdump: loaded Not tainted 6.19.0-rc6+ #319 NONE [81.803] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 [81.804] RIP: 0010:btrfs_create_pending_block_groups+0x723/0x770 [btrfs] [81.806] RSP: 0018:ffffa36241a6bce8 EFLAGS: 00010282 [81.806] RAX: 000000000000000d RBX: ffff8e699921e400 RCX: 0000000000000000 [81.807] RDX: 0000000002040001 RSI: 00000000ffffffef RDI: ffffffffc0608bf0 [81.807] RBP: 00000000ffffffef R08: ffff8e69830f6000 R09: 0000000000000007 [81.808] R10: ffff8e699921e5e8 R11: 0000000000000000 R12: ffff8e6999228000 [81.808] R13: ffff8e6984d82000 R14: ffff8e69966a69c0 R15: ffff8e69aa47b000 [81.809] FS: 00007fec6bdd9740(0000) GS:ffff8e6b1b379000(0000) knlGS:0000000000000000 [81.809] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [81.810] CR2: 00005604833670f0 CR3: 0000000116679000 CR4: 00000000000006f0 [81.810] Call Trace: [81.810] [81.810] __btrfs_end_transaction+0x3e/0x2b0 [btrfs] [81.811] btrfs_force_chunk_alloc_store+0xcd/0x140 [btrfs] [81.811] kernfs_fop_write_iter+0x15f/0x240 [81.812] vfs_write+0x264/0x500 [81.812] ksys_write+0x6c/0xe0 [81.812] do_syscall_64+0x66/0x770 [81.812] entry_SYSCALL_64_after_hwframe+0x76/0x7e [81.813] RIP: 0033:0x7fec6be66197 [81.814] RSP: 002b:00007fffb159dd30 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 [81.815] RAX: ffffffffffffffda RBX: 00007fec6bdd9740 RCX: 00007fec6be66197 [81.815] RDX: 0000000000000002 RSI: 0000560483374f80 RDI: 0000000000000001 [81.816] RBP: 0000560483374f80 R08: 0000000000000000 R09: 0000000000000000 [81.816] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000002 [81.817] R13: 00007fec6bfb85c0 R14: 00007fec6bfb5ee0 R15: 00005604833729c0 [81.817] [81.817] irq event stamp: 20039 [81.818] hardirqs last enabled at (20047): [] __up_console_sem+0x52/0x60 [81.818] hardirqs last disabled at (20056): [] __up_console_sem+0x37/0x60 [81.819] softirqs last enabled at (19470): [] __irq_exit_rcu+0x96/0xc0 [81.819] softirqs last disabled at (19463): [] __irq_exit_rcu+0x96/0xc0 [81.820] ---[ end trace 0000000000000000 ]--- [81.820] BTRFS: error (device dm-7 state A) in btrfs_create_pending_block_groups:2876: errno=-17 Object already exists Inspecting these aborts with drgn, I observed a pattern of overlapping chunk_maps. Note how stripe 1 of the first chunk overlaps in physical address with stripe 0 of the second chunk. Physical Start Physical End Length Logical Type Stripe ---------------------------------------------------------------------------------------------------- 0x0000000102500000 0x0000000142500000 1.0G 0x0000000641d00000 META|DUP 0/2 0x0000000142500000 0x0000000182500000 1.0G 0x0000000641d00000 META|DUP 1/2 0x0000000142500000 0x0000000182500000 1.0G 0x0000000601d00000 META|DUP 0/2 0x0000000182500000 0x00000001c2500000 1.0G 0x0000000601d00000 META|DUP 1/2 Now how could this possibly happen? All chunk allocation is protected by the chunk_mutex so racing allocations should see a consistent view of the CHUNK_ALLOCATED bit in the chunk allocation extent-io-tree (device->alloc_state as set by chunk_map_device_set_bits()) The tree itself is protected by a spin lock, and clearing/setting the bits is always protected by fs_info->mapping_tree_lock, so no race is apparent. It turns out that there is a subtle bug in the logic regarding chunk allocations that have happened in the current transaction, known as "pending extents". The chunk allocation as defined in find_free_dev_extent() is a loop which searches the commit root of the dev_root and looks for gaps between DEV_EXTENT items. For those gaps, it then checks alloc_state bitmap for any pending extents and adjusts the hole that it finds accordingly. However, the logic in that adjustment assumes that the first pending extent is the only one in that range. e.g., given a layout with two non-consecutive pending extents in a hole passed to dev_extent_hole_check() via *hole_start and *hole_size: |----pending A----| real hole |----pending B----| | candidate hole | *hole_start *hole_start + *hole_size the code incorrectly returns a "hole" from the end of pending extent A until the passed in hole end, failing to account for pending B. However, it is not entirely obvious that it is actually possible to produce such a layout. I was able to reproduce it, but with some contortions: I continued to use the force chunk allocation sysfs file and I introduced a long delay (10 seconds) into the start of the cleaner thread. I also prevented the unused bgs cleaning logic from ever deleting metadata bgs. These help make it easier to deterministically produce the condition but shouldn't really matter if you imagine the conditions happening by race/luck. Allocations/frees can happen concurrently with the cleaner thread preparing to process an unused extent and both create some used chunks with an unused chunk interleaved, all during one transaction. Then btrfs_delete_unused_bgs() sees the unused one and clears it, leaving a range with several pending chunk allocations and a gap in the middle. The basic idea is that the unused_bgs cleanup work happens on a worker so if we allocate 3 block groups in one transaction, then the cleaner work kicked off by the previous transaction comes through and deletes the middle one of the 3, then the commit root shows no dev extents and we have the bad pattern in the extent-io-tree. One final consideration is that the code happens to loop to the next hole if there are no more extents at all, so we need one more dev extent way past the area we are working in. Something like the following demonstrates the technique: # push the BG frontier out to 20G fallocate -l 20G $mnt/foo # allocate one more that will prevent the "no more dev extents" luck fallocate -l 1G $mnt/sticky # sync sync # clear out the allocation area rm $mnt/foo sync _cleaner # let everything quiesce sleep 20 sync # dev tree should have one bg 20G out and the rest at the beginning.. # sort of like an empty FS but with a random sticky chunk. # kick off the cleaner in the background, remember it will sleep 10s # before doing interesting work _cleaner & sleep 3 # create 3 trivial block groups, all empty, all immediately marked as unused. echo 1 > "$(_btrfs_sysfs_space_info $dev metadata)/force_chunk_alloc" echo 1 > "$(_btrfs_sysfs_space_info $dev data)/force_chunk_alloc" echo 1 > "$(_btrfs_sysfs_space_info $dev metadata)/force_chunk_alloc" # let the cleaner thread definitely finish, it will remove the data bg sleep 10 # this allocation sees the non-consecutive pending metadata chunks with # data chunk gap of 1G and allocates a 2G extent in that hole. ENOSPC! echo 1 > "$(_btrfs_sysfs_space_info $dev metadata)/force_chunk_alloc" As for the fix, it is not that obvious. I could not see a trivial way to do it even by adding backup loops into find_free_dev_extent(), so I opted to change the semantics of dev_extent_hole_check() to not stop looping until it finds a sufficiently big hole. For clarity, this also required changing the helper function contains_pending_extent() into two new helpers which find the first pending extent and the first suitable hole in a range. I attempted to clean up the documentation and range calculations to be as consistent and clear as possible for the future. I also looked at the zoned case and concluded that the loop there is different and not to be unified with this one. As far as I can tell, the zoned check will only further constrain the hole so looping back to find more holes is acceptable. Though given that zoned really only appends, I find it highly unlikely that it is susceptible to this bug. Fixes: 1b9845081633 ("Btrfs: fix find_free_dev_extent() malfunction in case device tree has hole") Reported-by: Dimitrios Apostolou Closes: https://lore.kernel.org/linux-btrfs/q7760374-q1p4-029o-5149-26p28421s468@tzk.arg/ Reviewed-by: Qu Wenruo Signed-off-by: Boris Burkov Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 80e1fda9c084dcf54819a12bc7682ec0afd2d8f4 Author: Boris Burkov Date: Mon Dec 22 16:15:44 2025 -0800 btrfs: fix block_group_tree dirty_list corruption [ Upstream commit 3a1f4264daed4b419c325a7fe35e756cada3cf82 ] When the incompat flag EXTENT_TREE_V2 is set, we unconditionally add the block group tree to the switch_commits list before calling switch_commit_roots, as we do for the tree root and the chunk root. However, the block group tree uses normal root dirty tracking and in any transaction that does an allocation and dirties a block group, the block group root will already be linked to a list by the dirty_list field and this use of list_add_tail() is invalid and corrupts the prev/next members of block_group_root->dirty_list. This is apparent on a subsequent list_del on the prev if we enable CONFIG_DEBUG_LIST: [32.1571] ------------[ cut here ]------------ [32.1572] list_del corruption. next->prev should beffff958890202538, but was ffff9588992bd538. (next=ffff958890201538) [32.1575] WARNING: lib/list_debug.c:65 at 0x0, CPU#3: sync/607 [32.1583] CPU: 3 UID: 0 PID: 607 Comm: sync Not tainted 6.18.0 #24PREEMPT(none) [32.1585] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS1.17.0-4.fc41 04/01/2014 [32.1587] RIP: 0010:__list_del_entry_valid_or_report+0x108/0x120 [32.1593] RSP: 0018:ffffaa288287fdd0 EFLAGS: 00010202 [32.1594] RAX: 0000000000000001 RBX: ffff95889326e800 RCX:ffff958890201538 [32.1596] RDX: ffff9588992bd538 RSI: ffff958890202538 RDI:ffffffff82a41e00 [32.1597] RBP: ffff958890202538 R08: ffffffff828fc1e8 R09:00000000ffffefff [32.1599] R10: ffffffff8288c200 R11: ffffffff828e4200 R12:ffff958890201538 [32.1601] R13: ffff95889326e958 R14: ffff958895c24000 R15:ffff958890202538 [32.1603] FS: 00007f0c28eb5740(0000) GS:ffff958af2bd2000(0000)knlGS:0000000000000000 [32.1605] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [32.1607] CR2: 00007f0c28e8a3cc CR3: 0000000109942005 CR4:0000000000370ef0 [32.1609] Call Trace: [32.1610] [32.1611] switch_commit_roots+0x82/0x1d0 [btrfs] [32.1615] btrfs_commit_transaction+0x968/0x1550 [btrfs] [32.1618] ? btrfs_attach_transaction_barrier+0x23/0x60 [btrfs] [32.1621] __iterate_supers+0xe8/0x190 [32.1622] ? __pfx_sync_fs_one_sb+0x10/0x10 [32.1623] ksys_sync+0x63/0xb0 [32.1624] __do_sys_sync+0xe/0x20 [32.1625] do_syscall_64+0x73/0x450 [32.1626] entry_SYSCALL_64_after_hwframe+0x76/0x7e [32.1627] RIP: 0033:0x7f0c28d05d2b [32.1632] RSP: 002b:00007ffc9d988048 EFLAGS: 00000246 ORIG_RAX:00000000000000a2 [32.1634] RAX: ffffffffffffffda RBX: 00007ffc9d988228 RCX:00007f0c28d05d2b [32.1636] RDX: 00007f0c28e02301 RSI: 00007ffc9d989b21 RDI:00007f0c28dba90d [32.1637] RBP: 0000000000000001 R08: 0000000000000001 R09:0000000000000000 [32.1639] R10: 0000000000000000 R11: 0000000000000246 R12:000055b96572cb80 [32.1641] R13: 000055b96572b19f R14: 00007f0c28dfa434 R15:000055b96572b034 [32.1643] [32.1644] irq event stamp: 0 [32.1644] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [32.1646] hardirqs last disabled at (0): []copy_process+0xb37/0x2260 [32.1648] softirqs last enabled at (0): []copy_process+0xb37/0x2260 [32.1650] softirqs last disabled at (0): [<0000000000000000>] 0x0 [32.1652] ---[ end trace 0000000000000000 ]--- Furthermore, this list corruption eventually (when we happen to add a new block group) results in getting the switch_commits and dirty_cowonly_roots lists mixed up and attempting to call update_root on the tree root which can't be found in the tree root, resulting in a transaction abort: [87.8269] BTRFS critical (device nvme1n1): unable to find root key (1 0 0) in tree 1 [87.8272] ------------[ cut here ]------------ [87.8274] BTRFS: Transaction aborted (error -117) [87.8275] WARNING: fs/btrfs/root-tree.c:153 at 0x0, CPU#4: sync/703 [87.8285] CPU: 4 UID: 0 PID: 703 Comm: sync Not tainted 6.18.0 #25 PREEMPT(none) [87.8287] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-4.fc41 04/01/2014 [87.8289] RIP: 0010:btrfs_update_root+0x296/0x790 [btrfs] [87.8295] RSP: 0018:ffffa58d035dfd60 EFLAGS: 00010282 [87.8297] RAX: ffff9a59126ddb68 RBX: ffff9a59126dc000 RCX: 0000000000000000 [87.8299] RDX: 0000000000000000 RSI: 00000000ffffff8b RDI: ffffffffc0b28270 [87.8301] RBP: ffff9a5904aec000 R08: 0000000000000000 R09: 00000000ffffefff [87.8303] R10: ffffffff9ac8c200 R11: ffffffff9ace4200 R12: 0000000000000001 [87.8305] R13: ffff9a59041740e8 R14: ffff9a5904aec1f7 R15: ffff9a590fdefaf0 [87.8307] FS: 00007f54cde6b740(0000) GS:ffff9a5b5a81c000(0000) knlGS:0000000000000000 [87.8309] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [87.8310] CR2: 00007f54cde403cc CR3: 0000000112902004 CR4: 0000000000370ef0 [87.8312] Call Trace: [87.8313] [87.8314] ? _raw_spin_unlock+0x23/0x40 [87.8315] commit_cowonly_roots+0x1ad/0x250 [btrfs] [87.8317] ? btrfs_commit_transaction+0x79b/0x1560 [btrfs] [87.8320] btrfs_commit_transaction+0x8aa/0x1560 [btrfs] [87.8322] ? btrfs_attach_transaction_barrier+0x23/0x60 [btrfs] [87.8325] __iterate_supers+0xf1/0x170 [87.8326] ? __pfx_sync_fs_one_sb+0x10/0x10 [87.8327] ksys_sync+0x63/0xb0 [87.8328] __do_sys_sync+0xe/0x20 [87.8329] do_syscall_64+0x73/0x450 [87.8330] entry_SYSCALL_64_after_hwframe+0x76/0x7e [87.8331] RIP: 0033:0x7f54cdd05d2b [87.8336] RSP: 002b:00007fff1b58ff78 EFLAGS: 00000246 ORIG_RAX: 00000000000000a2 [87.8338] RAX: ffffffffffffffda RBX: 00007fff1b590158 RCX: 00007f54cdd05d2b [87.8340] RDX: 00007f54cde02301 RSI: 00007fff1b592b66 RDI: 00007f54cddba90d [87.8342] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [87.8344] R10: 0000000000000000 R11: 0000000000000246 R12: 000055e07ca96b80 [87.8346] R13: 000055e07ca9519f R14: 00007f54cddfa434 R15: 000055e07ca95034 [87.8348] [87.8348] irq event stamp: 0 [87.8349] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [87.8351] hardirqs last disabled at (0): [] copy_process+0xb37/0x21e0 [87.8353] softirqs last enabled at (0): [] copy_process+0xb37/0x21e0 [87.8355] softirqs last disabled at (0): [<0000000000000000>] 0x0 [87.8357] ---[ end trace 0000000000000000 ]--- [87.8358] BTRFS: error (device nvme1n1 state A) in btrfs_update_root:153: errno=-117 Filesystem corrupted [87.8360] BTRFS info (device nvme1n1 state EA): forced readonly [87.8362] BTRFS warning (device nvme1n1 state EA): Skipping commit of aborted transaction. [87.8364] BTRFS: error (device nvme1n1 state EA) in cleanup_transaction:2037: errno=-117 Filesystem corrupted Since the block group tree was pulled out of the extent tree and uses normal root dirty tracking, remove the offending extra list_add. This fixes the list corruption and the resulting fs corruption. Fixes: 14033b08a029 ("btrfs: don't save block group root into super block") Reviewed-by: Filipe Manana Signed-off-by: Boris Burkov Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 00ea0370ba7bc669f03ae498246768cafa1ec800 Author: Filipe Manana Date: Tue Jan 20 19:35:23 2026 +0000 btrfs: qgroup: return correct error when deleting qgroup relation item [ Upstream commit 51b1fcf71c88c3c89e7dcf07869c5de837b1f428 ] If we fail to delete the second qgroup relation item, we end up returning success or -ENOENT in case the first item does not exist, instead of returning the error from the second item deletion. Fixes: 73798c465b66 ("btrfs: qgroup: Try our best to delete qgroup relations") Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f957ddc4d8eb951ca03acee1c5bcdea1a73cb449 Author: Johannes Thumshirn Date: Thu Dec 4 13:42:23 2025 +0100 btrfs: zoned: don't zone append to conventional zone [ Upstream commit b39b26e017c7889181cb84032e22bef72e81cf29 ] In case of a zoned RAID, it can happen that a data write is targeting a sequential write required zone and a conventional zone. In this case the bio will be marked as REQ_OP_ZONE_APPEND but for the conventional zone, this needs to be REQ_OP_WRITE. The setting of REQ_OP_ZONE_APPEND is deferred to the last possible time in btrfs_submit_dev_bio(), but the decision if we can use zone append is cached in btrfs_bio. CC: Naohiro Aota Fixes: e9b9b911e03c ("btrfs: add raid stripe tree to features enabled with debug config") Reviewed-by: Christoph Hellwig Reviewed-by: Naohiro Aota Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 9643b3baa46b6731efe7e851143a97df54135778 Author: Qu Wenruo Date: Fri Oct 24 15:08:34 2025 +1030 btrfs: introduce btrfs_bio::async_csum [ Upstream commit dd57c78aec398717a2fa6488d87b1a6cd43c7d0d ] [ENHANCEMENT] Btrfs currently calculates data checksums then submits the bio. But after commit 968f19c5b1b7 ("btrfs: always fallback to buffered write if the inode requires checksum"), any writes with data checksum will fallback to buffered IO, meaning the content will not change during writeback. This means we're safe to calculate the data checksum and submit the bio in parallel, and only need the following new behavior: - Wait the csum generation to finish before calling btrfs_bio::end_io() Or this can lead to use-after-free for the csum generation worker. - Save the current bi_iter for csum_one_bio() As the submission part can advance btrfs_bio::bio.bi_iter, if not saved csum_one_bio() may got an empty bi_iter and do not generate any checksum. Unfortunately this means we have to increase the size of btrfs_bio for 16 bytes, but this is still acceptable. As usual, such new feature is hidden behind the experimental flag. [THEORETIC ANALYZE] Consider the following theoretic hardware performance, which should be more or less close to modern mainstream hardware: Memory bandwidth: 50GiB/s CRC32C bandwidth: 45GiB/s SSD bandwidth: 8GiB/s Then write bandwidth with data checksum before the patch is: 1 / ( 1 / 50 + 1 / 45 + 1 / 8) = 5.98 GiB/s After the patch, the bandwidth is: 1 / ( 1 / 50 + max( 1 / 45 + 1 / 8)) = 6.90 GiB/s The difference is 15.32% improvement. [REAL WORLD BENCHMARK] I'm using a Zen5 (HX 370) as the host, the VM has 4GiB memory, 10 vCPUs, the storage is backed by a PCIe gen3 x4 NVMe. The test is a direct IO write, with 1MiB block size, write 7GiB data into a btrfs mount with data checksum. Thus the direct write will fallback to buffered one: Vanilla Datasum: 1619.97 GiB/s Patched Datasum: 1792.26 GiB/s Diff +10.6 % In my case, the bottleneck is the storage, thus the improvement is not reaching the theoretic one, but still some observable improvement. Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Stable-dep-of: b39b26e017c7 ("btrfs: zoned: don't zone append to conventional zone") Signed-off-by: Sasha Levin commit 0981c6b984a163f2232acfbf8e26b75146032511 Author: Qu Wenruo Date: Thu Oct 23 15:19:16 2025 +1030 btrfs: make sure all btrfs_bio::end_io are called in task context [ Upstream commit 4591c3ef751d861d7dd95ff4d2aadb1b5e95854e ] [BACKGROUND] Btrfs has a lot of different bi_end_io functions, to handle different raid profiles. But they introduced a lot of different contexts for btrfs_bio::end_io() calls: - Simple read bios Run in task context, backed by either endio_meta_workers or endio_workers. - Simple write bios Run in IRQ context. - RAID56 write or rebuild bios Run in task context, backed by rmw_workers. - Mirrored write bios Run in irq context. This is inconsistent, and contributes to the number of workqueues used in btrfs. [ENHANCEMENT] Make all the above bios call their btrfs_bio::end_io() in task context, backed by either endio_meta_workers for metadata, or endio_workers for data. For simple write bios, merge the handling into simple_end_io_work(). For mirrored write bios, it will be a little more complex, since both the original or the cloned bios can run the final btrfs_bio::end_io(). Here we make sure the cloned bios are using btrfs_bioset, to reuse the end_io_work, and run both original and cloned work inside the workqueue. Add extra ASSERT()s to make sure btrfs_bio_end_io() is running in task context. This not only unifies the context for btrfs_bio::end_io() functions, but also opens a new door for further btrfs_bio::end_io() related cleanups. Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: b39b26e017c7 ("btrfs: zoned: don't zone append to conventional zone") Signed-off-by: Sasha Levin commit 4663160aa2d8472e9194367d02f75e26573809e9 Author: Qu Wenruo Date: Wed Oct 29 08:35:33 2025 +1030 btrfs: remove btrfs_bio::fs_info by extracting it from btrfs_bio::inode [ Upstream commit 81cea6cd7041ebd42281e0517f856d88527d3326 ] Currently there is only one caller which doesn't populate btrfs_bio::inode, and that's scrub. The idea is scrub doesn't want any automatic csum verification nor read-repair, as everything will be handled by scrub itself. However that behavior is really no different than metadata inode, thus we can reuse btree_inode as btrfs_bio::inode for scrub. The only exception is in btrfs_submit_chunk() where if a bbio is from scrub or data reloc inode, we set rst_search_commit_root to true. This means we still need a way to distinguish scrub from metadata, but that can be done by a new flag inside btrfs_bio. Now btrfs_bio::inode is a mandatory parameter, we can extract fs_info from that inode thus can remove btrfs_bio::fs_info to save 8 bytes from btrfs_bio structure. Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: b39b26e017c7 ("btrfs: zoned: don't zone append to conventional zone") Signed-off-by: Sasha Levin commit 8f7f0e1728685416b0ef7a8872399a843f06fcf0 Author: Qu Wenruo Date: Tue Oct 28 10:06:36 2025 +1030 btrfs: headers cleanup to remove unnecessary local includes [ Upstream commit c5667f9c8eb90293dfa4e52c65eb89fe39f5652d ] [BUG] When I tried to remove btrfs_bio::fs_info and use btrfs_bio::inode to grab the fs_info, the header "btrfs_inode.h" is needed to access the full btrfs_inode structure. Then btrfs will fail to compile. [CAUSE] There is a recursive including chain: "bio.h" -> "btrfs_inode.h" -> "extent_map.h" -> "compression.h" -> "bio.h" That recursive including is causing problems for btrfs. [ENHANCEMENT] To reduce the risk of recursive including: - Remove unnecessary local includes from btrfs headers Either the included header is pulled in by other headers, or is completely unnecessary. - Remove btrfs local includes if the header only requires a pointer In that case let the implementing C file to pull the required header. This is especially important for headers like "btrfs_inode.h" which pulls in a lot of other btrfs headers, thus it's a mine field of recursive including. - Remove unnecessary temporary structure definition Either if we have included the header defining the structure, or completely unused. Now including "btrfs_inode.h" inside "bio.h" is completely fine, although "btrfs_inode.h" still includes "extent_map.h", but that header only includes "fs.h", no more chain back to "bio.h". Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: b39b26e017c7 ("btrfs: zoned: don't zone append to conventional zone") Signed-off-by: Sasha Levin commit e49abde0ffc382a967b24f326d1614ac3bb06a94 Author: Gao Xiang Date: Fri Jan 30 15:54:22 2026 +0800 erofs: handle end of filesystem properly for file-backed mounts [ Upstream commit bc804a8d7e865ef47fb7edcaf5e77d18bf444ebc ] I/O requests beyond the end of the filesystem should be zeroed out, similar to loopback devices and that is what we expect. Fixes: ce63cb62d794 ("erofs: support unencoded inodes for fileio") Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 728ba4346177481426c03a70316db0195fc68696 Author: Gao Xiang Date: Thu Nov 27 16:07:56 2025 +0800 erofs: get rid of raw bi_end_io() usage [ Upstream commit 80d0c27a0a4af8e0678d7412781482e6f73c22c7 ] These BIOs are actually harmless in practice, as they are all pseudo BIOs and do not use advanced features like chaining. Using the BIO interface is a more friendly and unified approach for both bdev and and file-backed I/Os (compared to awkward bvec interfaces). Let's use bio_endio() instead. Reviewed-by: Christoph Hellwig Reviewed-by: Ming Lei Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Stable-dep-of: bc804a8d7e86 ("erofs: handle end of filesystem properly for file-backed mounts") Signed-off-by: Sasha Levin commit ec15eb67fe9df87981b4829b901ec254273ca483 Author: Alper Ak Date: Fri Dec 26 15:09:27 2025 +0300 tpm: st33zp24: Fix missing cleanup on get_burstcount() error [ Upstream commit 3e91b44c93ad2871f89fc2a98c5e4fe6ca5db3d9 ] get_burstcount() can return -EBUSY on timeout. When this happens, st33zp24_send() returns directly without releasing the locality acquired earlier. Use goto out_err to ensure proper cleanup when get_burstcount() fails. Fixes: bf38b8710892 ("tpm/tpm_i2c_stm_st33: Split tpm_i2c_tpm_st33 in 2 layers (core + phy)") Signed-off-by: Alper Ak Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 1a22048c1117cdfac185ba450aba67ed6b65dc87 Author: Alper Ak Date: Fri Dec 26 13:23:38 2025 +0300 tpm: tpm_i2c_infineon: Fix locality leak on get_burstcount() failure [ Upstream commit bbd6e97c836cbeb9606d7b7e5dcf8a1d89525713 ] get_burstcount() can return -EBUSY on timeout. When this happens, the function returns directly without releasing the locality that was acquired at the beginning of tpm_tis_i2c_send(). Use goto out_err to ensure proper cleanup when get_burstcount() fails. Fixes: aad628c1d91a ("char/tpm: Add new driver for Infineon I2C TIS TPM") Signed-off-by: Alper Ak Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 8e71414e252c1cb235911008a98fd47927d3a55c Author: Zilin Guan Date: Mon Jan 26 08:11:21 2026 +0000 i3c: dw: Fix memory leak in dw_i3c_master_i2c_xfers() [ Upstream commit 2537089413514caaa9a5fdeeac3a34d45100f747 ] The dw_i3c_master_i2c_xfers() function allocates memory for the xfer structure using dw_i3c_master_alloc_xfer(). If pm_runtime_resume_and_get() fails, the function returns without freeing the allocated xfer, resulting in a memory leak. Add a dw_i3c_master_free_xfer() call to the error path to ensure the allocated memory is properly freed. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 62fe9d06f570 ("i3c: dw: Add power management support") Signed-off-by: Zilin Guan Reviewed-by: Frank Li Link: https://patch.msgid.link/20260126081121.644099-1-zilin@seu.edu.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 53f4761ab032de49136805c934a1bf9fa4ec0fd8 Author: Fredrik Markstrom Date: Fri Jan 16 15:29:42 2026 +0100 i3c: dw: Initialize spinlock to avoid upsetting lockdep [ Upstream commit b58eaa4761ab02fc38c39d674a6bcdd55e00f388 ] The devs_lock spinlock introduced when adding support for ibi:s was never initialized. Fixes: e389b1d72a624 ("i3c: dw: Add support for in-band interrupts") Suggested-by: Jani Nurminen Signed-off-by: Fredrik Markstrom Reviewed-by: Ivar Holmqvist Link: https://patch.msgid.link/20260116-i3c_dw_initialize_spinlock-v3-1-cf707b6ed75f@est.tech Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 6d76febba07c40bcf358f63216d36ea68cf1c215 Author: Deepanshu Kartikey Date: Fri Jan 30 14:51:34 2026 +0530 gfs2: Fix use-after-free in iomap inline data write path [ Upstream commit faddeb848305e79db89ee0479bb0e33380656321 ] The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().] Reported-by: syzbot+ea1cd4aa4d1e98458a55@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ea1cd4aa4d1e98458a55 Fixes: d0a22a4b03b8 ("gfs2: Fix iomap write page reclaim deadlock") Signed-off-by: Deepanshu Kartikey Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 1d47922b98046b8070a77347fb883a6523792803 Author: Andreas Gruenbacher Date: Sun Dec 14 16:47:34 2025 +0000 gfs2: Fix slab-use-after-free in qd_put [ Upstream commit 22150a7d401d9e9169b9b68e05bed95f7f49bf69 ] Commit a475c5dd16e5 ("gfs2: Free quota data objects synchronously") started freeing quota data objects during filesystem shutdown instead of putting them back onto the LRU list, but it failed to remove these objects from the LRU list, causing LRU list corruption. This caused use-after-free when the shrinker (gfs2_qd_shrink_scan) tried to access already-freed objects on the LRU list. Fix this by removing qd objects from the LRU list before freeing them in qd_put(). Initial fix from Deepanshu Kartikey . Fixes: a475c5dd16e5 ("gfs2: Free quota data objects synchronously") Reported-by: syzbot+046b605f01802054bff0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=046b605f01802054bff0 Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 5480341dc884f163b854451e8f1670b2eb7012ae Author: Andreas Gruenbacher Date: Tue Dec 9 22:59:12 2025 +0000 gfs2: Retries missing in gfs2_{rename,exchange} [ Upstream commit 11d763f0b0afc2cf5f92f4adae5dbbbbef712f8f ] Fix a bug in gfs2's asynchronous glock handling for rename and exchange operations. The original async implementation from commit ad26967b9afa ("gfs2: Use async glocks for rename") mentioned that retries were needed but never implemented them, causing operations to fail with -ESTALE instead of retrying on timeout. Also makes the waiting interruptible. In addition, the timeouts used were too high for situations in which timing out is a rare but expected scenario. Switch to shorter timeouts with randomization and exponentional backoff. Fixes: ad26967b9afa ("gfs2: Use async glocks for rename") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 7378340f2e220b428472ef6b82943fbdc966bedb Author: Adrian Hunter Date: Tue Jan 13 09:26:44 2026 +0200 i3c: master: Update hot-join flag only on success [ Upstream commit f0775157b9f9a28ae3eabc8d05b0bc52e8056c80 ] To prevent inconsistent state when an error occurs, ensure the hot-join flag is updated only when enabling or disabling hot-join succeeds. Fixes: 317bacf960a48 ("i3c: master: add enable(disable) hot join in sys entry") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260113072702.16268-4-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 5c328675d2a8adc8f9e69fbe0c3989ea96edb92c Author: Ben Dooks Date: Thu Jan 8 11:58:56 2026 +0000 fs: add for 'init_fs' [ Upstream commit 589cff4975afe1a4eaaa1d961652f50b1628d78d ] The init_fs symbol is defined in but was not included in fs/fs_struct.c so fix by adding the include. Fixes the following sparse warning: fs/fs_struct.c:150:18: warning: symbol 'init_fs' was not declared. Should it be static? Fixes: 3e93cd671813e ("Take fs_struct handling to new file") Signed-off-by: Ben Dooks Link: https://patch.msgid.link/20260108115856.238027-1-ben.dooks@codethink.co.uk Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 44e9f5aedfb4cafd09b356e10d4617c1a1860225 Author: Amir Goldstein Date: Fri Jan 9 22:15:36 2026 +0100 fs: move initializing f_mode before file_ref_init() [ Upstream commit 1219e0feaefc9697f738b223540e8e8906291cb3 ] The comment above file_ref_init() says: "We're SLAB_TYPESAFE_BY_RCU so initialize f_ref last." but file_set_fsnotify_mode() was added after file_ref_init(). Move it right after setting f_mode, where it makes more sense. Fixes: 711f9b8fbe4f4 ("fsnotify: disable pre-content and permission events by default") Signed-off-by: Amir Goldstein Link: https://patch.msgid.link/20260109211536.3565697-1-amir73il@gmail.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit c2ed725668f23fb1ad1f0f883c45b42c641321bf Author: Breno Leitao Date: Wed Jan 7 06:06:36 2026 -0800 device_cgroup: remove branch hint after code refactor [ Upstream commit 6784f274722559c0cdaaa418bc8b7b1d61c314f9 ] commit 4ef4ac360101 ("device_cgroup: avoid access to ->i_rdev in the common case in devcgroup_inode_permission()") reordered the checks in devcgroup_inode_permission() to check the inode mode before checking i_rdev, for better cache behavior. However, the likely() annotation on the i_rdev check was not updated to reflect the new code flow. Originally, when i_rdev was checked first, likely(!inode->i_rdev) made sense because most inodes were(?) regular files/directories, thus i_rdev == 0. After the reorder, by the time we reach the i_rdev check, we have already confirmed the inode IS a block or character device. Block and character special files are precisely defined by having a device number (i_rdev), so !inode->i_rdev is now the rare edge case, not the common case. Branch profiling confirmed this is 100% mispredicted: correct incorrect % Function File Line ------- --------- - -------- ---- ---- 0 2631904 100 devcgroup_inode_permission device_cgroup.h 24 Remove likely() to avoid giving the wrong hint to the CPU. Fixes: 4ef4ac360101 ("device_cgroup: avoid access to ->i_rdev in the common case in devcgroup_inode_permission()") Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260107-likely_device-v1-1-0c55f83a7e47@debian.org Reviewed-by: Mateusz Guzik Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 49c201c09b473f6c126be2836569ed3ce899bea8 Author: Billy Tsai Date: Mon Jan 12 14:07:22 2026 +0800 i3c: Move device name assignment after i3c_bus_init [ Upstream commit 3502cea99c7ceb331458cbd34ef6792c83144687 ] Move device name initialization to occur after i3c_bus_init() so that i3cbus->id is guaranteed to be assigned before it is used. Fixes: 9d4f219807d5 ("i3c: fix refcount inconsistency in i3c_master_register") Signed-off-by: Billy Tsai Reviewed-by: Frank Li Link: https://patch.msgid.link/20260112-upstream_i3c_fix-v1-1-cbbf2cb71809@aspeedtech.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit d0200c70e3175522fba2f2e8b725bc197a764964 Author: Xiaochen Shen Date: Wed Dec 17 11:04:53 2025 +0800 selftests/resctrl: Fix a division by zero error on Hygon [ Upstream commit 671ef08d9455f5754d1fc96f5a14e357d6b80936 ] Change to adjust effective L3 cache size with SNC enabled change introduced the snc_nodes_per_l3_cache() function to detect the Intel Sub-NUMA Clustering (SNC) feature by comparing #CPUs in node0 with #CPUs sharing LLC with CPU0. The function was designed to return: (1) >1: SNC mode is enabled. (2) 1: SNC mode is not enabled or not supported. However, on certain Hygon CPUs, #CPUs sharing LLC with CPU0 is actually less than #CPUs in node0. This results in snc_nodes_per_l3_cache() returning 0 (calculated as cache_cpus / node_cpus). This leads to a division by zero error in get_cache_size(): *cache_size /= snc_nodes_per_l3_cache(); Causing the resctrl selftest to fail with: "Floating point exception (core dumped)" Fix the issue by ensuring snc_nodes_per_l3_cache() returns 1 when SNC mode is not supported on the platform. Updated commit log to fix commit has issues: Shuah Khan Link: https://lore.kernel.org/r/20251217030456.3834956-2-shenxiaochen@open-hieco.net Fixes: a1cd99e700ec ("selftests/resctrl: Adjust effective L3 cache size with SNC enabled") Signed-off-by: Xiaochen Shen Reviewed-by: Reinette Chatre Reviewed-by: Fenghua Yu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 28397957c75b913214d0d1a681f432b749696569 Author: Ben Dooks Date: Fri Jan 9 13:39:38 2026 +0000 audit: move the compat_xxx_class[] extern declarations to audit_arch.h [ Upstream commit 76489955c6d4a065ca69dc88faf7a50a59b66f35 ] The comapt_xxx_class symbols aren't declared in anything that lib/comapt_audit.c is including (arm64 build) which is causing the following sparse warnings: lib/compat_audit.c:7:10: warning: symbol 'compat_dir_class' was not declared. Should it be static? lib/compat_audit.c:12:10: warning: symbol 'compat_read_class' was not declared. Should it be static? lib/compat_audit.c:17:10: warning: symbol 'compat_write_class' was not declared. Should it be static? lib/compat_audit.c:22:10: warning: symbol 'compat_chattr_class' was not declared. Should it be static? lib/compat_audit.c:27:10: warning: symbol 'compat_signal_class' was not declared. Should it be static? Trying to fix this by chaning compat_audit.c to inclde does not work on arm64 due to compile errors with the extra includes that changing this header makes. The simpler thing would be just to move the definitons of these symbols out of into which is included. Fixes: 4b58841149dca ("audit: Add generic compat syscall support") Signed-off-by: Ben Dooks [PM: rewrite subject line, fixed line length in description] Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 4a4a6e12c9c829be3f74b7206fa8640fc4e1c566 Author: Yao Kai Date: Thu Jan 1 11:34:10 2026 -0500 rcu: Fix rcu_read_unlock() deadloop due to softirq [ Upstream commit d41e37f26b3157b3f1d10223863519a943aa239b ] Commit 5f5fa7ea89dc ("rcu: Don't use negative nesting depth in __rcu_read_unlock()") removes the recursion-protection code from __rcu_read_unlock(). Therefore, we could invoke the deadloop in raise_softirq_irqoff() with ftrace enabled as follows: WARNING: CPU: 0 PID: 0 at kernel/trace/trace.c:3021 __ftrace_trace_stack.constprop.0+0x172/0x180 Modules linked in: my_irq_work(O) CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.18.0-rc7-dirty #23 PREEMPT(full) Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:__ftrace_trace_stack.constprop.0+0x172/0x180 RSP: 0018:ffffc900000034a8 EFLAGS: 00010002 RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000000000 RDX: 0000000000000003 RSI: ffffffff826d7b87 RDI: ffffffff826e9329 RBP: 0000000000090009 R08: 0000000000000005 R09: ffffffff82afbc4c R10: 0000000000000008 R11: 0000000000011d7a R12: 0000000000000000 R13: ffff888003874100 R14: 0000000000000003 R15: ffff8880038c1054 FS: 0000000000000000(0000) GS:ffff8880fa8ea000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055b31fa7f540 CR3: 00000000078f4005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 unwind_next_frame+0x203/0x9b0 __unwind_start+0x15d/0x1c0 arch_stack_walk+0x62/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 unwind_next_frame+0x203/0x9b0 __unwind_start+0x15d/0x1c0 arch_stack_walk+0x62/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 unwind_next_frame+0x203/0x9b0 __unwind_start+0x15d/0x1c0 arch_stack_walk+0x62/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 __is_insn_slot_addr+0x54/0x70 kernel_text_address+0x48/0xc0 __kernel_text_address+0xd/0x40 unwind_get_return_address+0x1e/0x40 arch_stack_walk+0x9c/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 __raise_softirq_irqoff+0x61/0x80 __flush_smp_call_function_queue+0x115/0x420 __sysvec_call_function_single+0x17/0xb0 sysvec_call_function_single+0x8c/0xc0 Commit b41642c87716 ("rcu: Fix rcu_read_unlock() deadloop due to IRQ work") fixed the infinite loop in rcu_read_unlock_special() for IRQ work by setting a flag before calling irq_work_queue_on(). We fix this issue by setting the same flag before calling raise_softirq_irqoff() and rename the flag to defer_qs_pending for more common. Fixes: 5f5fa7ea89dc ("rcu: Don't use negative nesting depth in __rcu_read_unlock()") Reported-by: Tengda Wu Signed-off-by: Yao Kai Reviewed-by: Joel Fernandes Tested-by: Paul E. McKenney Signed-off-by: Joel Fernandes Signed-off-by: Boqun Feng Signed-off-by: Sasha Levin commit 2e6ff6a6fc69cc17ed10c9cb6242935d52acd52d Author: Shardul Bankar Date: Tue Dec 30 02:19:38 2025 +0530 hfsplus: return error when node already exists in hfs_bnode_create [ Upstream commit d8a73cc46c8462a969a7516131feb3096f4c49d3 ] When hfs_bnode_create() finds that a node is already hashed (which should not happen in normal operation), it currently returns the existing node without incrementing its reference count. This causes a reference count inconsistency that leads to a kernel panic when the node is later freed in hfs_bnode_put(): kernel BUG at fs/hfsplus/bnode.c:676! BUG_ON(!atomic_read(&node->refcnt)) This scenario can occur when hfs_bmap_alloc() attempts to allocate a node that is already in use (e.g., when node 0's bitmap bit is incorrectly unset), or due to filesystem corruption. Returning an existing node from a create path is not normal operation. Fix this by returning ERR_PTR(-EEXIST) instead of the node when it's already hashed. This properly signals the error condition to callers, which already check for IS_ERR() return values. Reported-by: syzbot+1c8ff72d0cd8a50dfeaa@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=1c8ff72d0cd8a50dfeaa Link: https://lore.kernel.org/all/784415834694f39902088fa8946850fc1779a318.camel@ibm.com/ Fixes: 634725a92938 ("[PATCH] hfs: cleanup HFS+ prints") Signed-off-by: Shardul Bankar Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20251229204938.1907089-1-shardul.b@mpiricsoftware.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 91f08ec6a97b28694a679be7489d2c96a2034b1b Author: Thomas Fourier Date: Tue Dec 16 18:47:13 2025 +0100 auxdisplay: arm-charlcd: fix release_mem_region() size [ Upstream commit b5c23a4d291d2ac1dfdd574a68a3a68c8da3069e ] It seems like, after the request_mem_region(), the corresponding release_mem_region() must take the same size. This was done in (now removed due to previous refactoring) charlcd_remove() but not in the error path in charlcd_probe(). Fixes: ce8962455e90 ("ARM: 6214/2: driver for the character LCD found in ARM refdesigns") Signed-off-by: Thomas Fourier Reviewed-by: Geert Uytterhoeven Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 205955f29c26330b1dc7fdeadd5bb97c38e26f56 Author: YunJe Shin Date: Tue Feb 3 19:06:21 2026 +0900 RDMA/umad: Reject negative data_len in ib_umad_write commit 5551b02fdbfd85a325bb857f3a8f9c9f33397ed2 upstream. ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list(). Add an explicit check to reject negative data_len before creating the send buffer. KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80 Fixes: 2be8e3ee8efd ("IB/umad: Add P_Key index support") Signed-off-by: YunJe Shin Link: https://patch.msgid.link/20260203100628.1215408-1-ioerts@kookmin.ac.kr Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 714c99e1dc8f85f446e05be02ba83972e981a817 Author: YunJe Shin Date: Wed Feb 4 18:24:57 2026 +0900 RDMA/siw: Fix potential NULL pointer dereference in header processing commit 14ab3da122bd18920ad57428f6cf4fade8385142 upstream. If siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(), qp->rx_fpdu can be NULL. The error path in siw_tcp_rx_data() dereferences qp->rx_fpdu->more_ddp_segs without checking, which may lead to a NULL pointer deref. Only check more_ddp_segs when rx_fpdu is present. KASAN splat: [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7] [ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50 Fixes: 8b6a361b8c48 ("rdma/siw: receive path") Signed-off-by: YunJe Shin Link: https://patch.msgid.link/20260204092546.489842-1-ioerts@kookmin.ac.kr Acked-by: Bernard Metzler Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman