commit 59351365ac271b5e0eb180f211c531476a36221f Author: Lorenzo Stoakes (ARM) Date: Tue Sep 8 21:55:02 2026 +0100 scripts/mksysmap: fix escape of '$' in the __pi_ pattern Commit b18b047002b7 ("kbuild: change scripts/mksysmap into sed script") converted scripts/mksysmap from a shell script to a sed script. However an error was made - escaping of '$' required \\ escaping in shell but only \ in a sed script. This was mostly corrected in commit 7a6c355b55c0 ("scripts/mksysmap: Fix escape chars '$'"), but this fix missed arm64 PIE namespace local symbols like __pi_$x and __pi_$d which appear in System.map and /proc/kallsyms: $ grep __pi_\\$ /proc/kallsyms | sort -u 0000000000000000 d __pi_$d 0000000000000000 t __pi_$x Fix the escaping properly. Fixes: b18b047002b7 ("kbuild: change scripts/mksysmap into sed script") Assisted-by: LLM Signed-off-by: Lorenzo Stoakes (ARM) Reviewed-by: Nathan Chancellor Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260908-build-speedup-v1-2-5dc1ac01672d@kernel.org Signed-off-by: Nicolas Schier commit 281b61d408d4c39544583e393c6707af0ef5ee50 Author: Lorenzo Stoakes (ARM) Date: Tue Sep 8 21:55:01 2026 +0100 scripts/mksysmap: drop the MODULE_INFO() symbols from kallsyms Commit 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") keeps .modinfo symbols out of System.map and kallsyms, which assumes unique IDs have a format like '__UNIQUE_ID_modinfo123'. However, commit afb026b6d35c ("compiler: Tweak __UNIQUE_ID() naming"), sent in the same cycle, changes this to '__UNIQUE_ID_modinfo_123'. As a result this regexp has never matched and every kernel since v6.18 has carried one kallsyms entries for every MODULE_INFO() declaration in the kernel whether the modules are compiled or not. That's 5,810 entries for an x86 defconfig build and 15,200 for arm64. On x86 defconfig that is 113 KiB of kallsyms tables and 32 KiB of bzImage, and every lookup walks past them. Fix the pattern. Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") Assisted-by: LLM Signed-off-by: Lorenzo Stoakes (ARM) Reviewed-by: Nicolas Schier Reviewed-by: Nathan Chancellor Link: https://patch.msgid.link/20260908-build-speedup-v1-1-5dc1ac01672d@kernel.org Signed-off-by: Nicolas Schier commit 7e645147dfba67edb3ed3090a1ed1d89df77fc27 Author: Karl Mehltretter Date: Wed Sep 9 08:29:17 2026 +0200 tracing: Fix ring_buffer_read_page_size() kernel-doc ring_buffer_read_page_size() takes a parameter named rpage, but its kernel-doc describes page. As a result, kernel-doc reports rpage as undescribed and page as an excess parameter description. Rename the documentation entry to match the function. Link: https://patch.msgid.link/20260909062917.89482-1-kmehltretter@gmail.com Fixes: dae8dda341d2 ("tracing: Fix subbuf resize races with trace_pipe_raw readers") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Vincent Donnefort Signed-off-by: Steven Rostedt commit c5dcb3aadc18d7b82ba64790721b005d18193d35 Author: Andrea Parri Date: Thu Sep 10 16:34:42 2026 +0200 hrtimer: Use hard expiry when updating timers on the same base Rearming a queued timer with nonzero slack can leave the timerqueue out of order. remove_and_enqueue_same_base() checks the new soft expiry against its neighbours' hard expiries, then stores the new hard expiry in the node without requeueing it. For example, with A at 10 and B at 20, rearming A at 11 with slack 30 passes the neighbour check but leaves A's hard expiry of 41 before B's 20. The same function also caches the soft expiry in base->expires_next when updating or inserting the first timer, giving next-event selection an earlier deadline than the queue head's hard expiry. Set the timer expiry before handling the queue. Use its stored hard expiry for the in-place ordering check and both updates to base->expires_next. The early update is safe because remove_and_enqueue_same_base() runs with base->cpu_base->lock held. The lock keeps the queue stable while hrtimer_can_update_in_place() checks the new expiry against both neighbours. If the check fails, timerqueue_linked_del() removes the node without comparing expiry values before it is reinserted. Fixes: eddffab8282e3 ("hrtimer: Keep track of first expiring timer per clock base") Fixes: 343f2f4dc5425 ("hrtimer: Try to modify timers in place") Signed-off-by: Andrea Parri Signed-off-by: Thomas Gleixner Assisted-by: LLM Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260910143442.2018-1-parri.andrea@gmail.com commit 27600805e62f800bacf990354632eae4e487d34c Author: Yazen Ghannam Date: Thu Sep 3 10:43:25 2026 -0500 x86/amd_node: Fix PCI device reference counting in amd_smn_init() The local "root" pointer is a temporary variable used during the device search. Therefore, refcount related to the search iterators should be cleaned up after the search is complete. Use the __free() cleanup macro to ensure the refcount is decremented when the temporary pointer goes out of scope. Additionally, increment the refcount when caching a root pointer. This ensures the in-use refcount is separate from the temporary search refcounting. Finally, drop the redundant "root = NULL" before the second search loop. The pci_get_class() iterator always decrements the refcount of its "from" argument, so the first loop can only fall through with "root" already NULL. Fixes: 0a4b61d9c2e4 ("x86/amd_node: Fix AMD root device caching") Closes: https://sashiko.dev/#/patchset/20260806160159.230453-1-jason.andryuk%40amd.com Reported-by: Sashiko Assisted-by: LLM Signed-off-by: Yazen Ghannam Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Mario Limonciello (AMD) Cc: Link: https://patch.msgid.link/20260903154325.74343-1-yazen.ghannam@amd.com commit 5a5d26f2cfe13467166219f6bf58099326912ddb Author: Soheil Hassas Yeganeh Date: Mon Aug 31 14:48:44 2026 +0000 x86/cfi: Fix FineIBT hash offset in cfi_get_func_hash() The switch of the FineIBT preamble from "subl $hash, %r10d" to the shorter "subl $hash, %eax" moved the hash immediate from offset 7 to offset 5 of the preamble. fineibt_preamble_hash was updated to match, but the open-coded offset in cfi_get_func_hash() was missed and it still reads the hash at offset 7. cfi_get_func_hash() is used by the BPF JIT to give a struct_ops trampoline the CFI hash of the stub function it stands in for. With FineIBT the trampoline now gets the upper half of the real hash followed by the first two bytes of the next instruction, so the first indirect call from the kernel into a struct_ops program, tcp_init_congestion_control() calling ->init() of a BPF congestion control for example, fails the FineIBT check and the kernel dies with a CFI failure. Move the FineIBT preamble template and its offset defines above cfi_get_func_hash() and use fineibt_preamble_hash there, so every reader of the preamble shares one definition of its layout. The CFI_FINEIBT arm is only built with CONFIG_FINEIBT, the only configuration in which cfi_mode can take that value. cfi_get_func_arity() does not need the same treatment: the __bhi_args call whose displacement it reads still ends at the function address. Fixes: 85a2d4a890dc ("x86,ibt: Use UDB instead of 0xEA") Assisted-by: LLM Signed-off-by: Soheil Hassas Yeganeh Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org # 6.18+ Link: https://patch.msgid.link/20260831-b4-x86-cfi-fineibt-func-hash-v1-1-6ffc0af5c4ec@gmail.com commit 6d760f8b41aed74de4402440e4db663d261478bd Author: Vishnu Razdan Date: Mon Aug 24 23:58:00 2026 -0700 hwmon: (pmbus) Clear generic status alarms with CLEAR_FAULTS Some hwmon alarms fall back to STATUS_WORD summary bits when no individual limit alarm is available. On PMBus 1.2 and newer devices, pmbus_get_boolean() acknowledges these alarms with the same byte-data write used for detailed status registers. For example, PB_STATUS_INPUT is 0x2000, so it is truncated to zero when passed to _pmbus_write_byte_data(). The resulting write cannot acknowledge the input alarm. PMBus 1.3 Part II, sections 10.2.4 and 10.2.5, excludes ordinary STATUS_BYTE and STATUS_WORD summary bits from individual clearing. Their summary bits clear when the underlying status bits clear, so changing this to a word-data write would not fix the generic input alarm either. Use the existing page CLEAR_FAULTS path for generic STATUS_WORD alarms, including devices whose status accessor uses STATUS_BYTE. Keep individual byte writes for detailed status registers on PMBus 1.2 and newer devices. As with the existing older-device fallback, CLEAR_FAULTS can clear other latched status; an active condition can reassert its status. Fixes: 35f165f08950 ("hwmon: (pmbus) Clear pmbus fault/warning bits after read") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Vishnu Razdan Link: https://patch.msgid.link/20260824-vrazdan-pmbus-status-word-b4-v1-1-2606ecd0c029@openai.com Signed-off-by: Guenter Roeck commit f4c3e38111fd84c2c7ae5785755f4a4d476e1cba Author: Miguel Ojeda Date: Tue Sep 8 19:05:39 2026 +0200 rust: allow `unknown_lints` in generated bindings for Rust < 1.88 Starting with bindgen 0.73.2 [1], `#[allow(unnecessary_transmutes)]` are used, even when `--rust-target 1.85` is passed. However, the lint was introduced in Rust 1.88.0. Thus building with older Rust versions warns like: error: unknown lint: `unnecessary_transmutes` --> rust/uapi/uapi_generated.rs:26294:13 | 26294 | #[allow(unnecessary_transmutes)] | ^^^^^^^^^^^^^^^^^^^^^^ | = note: `-D unknown-lints` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unknown_lints)]` Thus allow `unknown_lints` in the generated bindings -- only when building with older Rust versions. I have asked upstream if this is intentional [1], i.e. if we are supposed to always allow unknown lints in case `bindgen` uses such attributes, or whether it is an oversight. [ Emilio said it wasn't intentional -- we will work around it for now on the kernel side. - Miguel ] Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Cc: Emilio Cobos Álvarez Link: https://github.com/rust-lang/rust-bindgen/pull/3455#issuecomment-5588526559 [1] Assisted-by: LLM Link: https://patch.msgid.link/20260908170539.345207-1-ojeda@kernel.org [ Removed the `cfg` for `allow(unnecessary_transmutes)` as suggested by Gary. - Miguel ] Signed-off-by: Miguel Ojeda commit f97802dd98b27e45c04293f9926f07642578b23f Author: Karl Mehltretter Date: Sat Sep 5 10:03:44 2026 +0200 drm/logicvc: Drop the select of the nonexistent CONFIG_DRM_KMS_DMA_HELPER CONFIG_DRM_KMS_CMA_HELPER was removed by commit 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option"). When commit 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") later renamed the select in this Kconfig to CONFIG_DRM_KMS_DMA_HELPER, no symbol of that name existed, and git log -S finds no Kconfig file that has defined one since. The select is silently ignored. The driver already selects CONFIG_DRM_GEM_DMA_HELPER, which is what it needs. Remove the dead line. Fixes: 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260905080344.34077-1-kmehltretter@gmail.com commit fedf002d7d08bee36693aacd1ade2ba39351ea91 Author: Karl Mehltretter Date: Sat Sep 5 10:04:26 2026 +0200 drm/adp: Drop the select of the nonexistent CONFIG_DRM_KMS_DMA_HELPER There is no Kconfig symbol CONFIG_DRM_KMS_DMA_HELPER. The former CONFIG_DRM_KMS_CMA_HELPER was removed by commit 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option") before this driver was added, so the select does nothing. The driver already selects CONFIG_DRM_GEM_DMA_HELPER, which is what it needs. Remove the dead line. Fixes: 332122eba628 ("drm: adp: Add Apple Display Pipe driver") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260905080426.34224-1-kmehltretter@gmail.com commit e0554c6276da957b6e72849520c70a97404cd1ae Merge: c51fe228121e e89e88ad41d9 Author: Paolo Abeni Date: Tue Sep 8 12:35:23 2026 +0200 Merge branch 'net-ethernet-cortina-fix-rx-budget-accounting' Linus Walleij says: ==================== net: ethernet: cortina: Fix RX budget accounting Finish RX updates before releasing NAPI ownership, report actual NAPI work, charge dropped frames to the poll budget, and drive free-queue refills from consumed RX descriptors. Track RX drop state across descriptor chains so discarded frames are counted exactly once. Tested on the D-Link DIR-685. Hi Sashiko, yes there are more latent issues I will get to them, but my LLM thinks those are on the top of the list. Assisted-by: LLM Signed-off-by: Linus Walleij ==================== Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-0-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni commit e89e88ad41d9f31c829c2af39c48313e8e48d5b0 Author: Linus Walleij Date: Thu Sep 3 23:45:33 2026 +0200 net: ethernet: cortina: Count RX descriptors for freeq refill The software free queue provides one buffer fragment for every descriptor moved to an RX queue. The refill heuristic instead advances by NAPI work, which counts frames. A fragmented or discarded frame can consume several queue entries while adding only one to the refill count. Count the RX descriptors as they are consumed and report that separately from NAPI work. Use the descriptor count to drive free queue refills. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Assisted-by: LLM Reviewed-by: Joe Damato Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-5-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni commit 6520198c430c81bcc367f0dd5e32f2fb740b9d51 Author: Linus Walleij Date: Thu Sep 3 23:45:32 2026 +0200 net: ethernet: cortina: Count RX drops once per frame The absence of a partial skb means either that the driver is not assembling a frame or that the current frame was already dropped. Consequently, repeated descriptor errors can increment rx_dropped more than once, while an orphaned descriptor chain can reach EOF without being counted at all. Track the dropping state across NAPI polls. Clear it at frame boundaries and route mapping failures and orphaned continuations through the common drop path so each discarded frame is counted exactly once. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Reported-by: Joe Damato Closes: https://lore.kernel.org/netdev/apdK5aMmvYssz35F@devvm20253.cco0.facebook.com/ Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-4-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni commit b856c552f556bc0341c1dbe0bf88e630fd1dc4b7 Author: Linus Walleij Date: Thu Sep 3 23:45:31 2026 +0200 net: ethernet: cortina: Count dropped frames as NAPI work The RX loop only consumes budget when it successfully delivers a frame. Error paths keep consuming descriptors without reducing the budget, so a stream of bad frames can process the entire receive ring in one poll. Move the budget accounting to a common end-of-frame path. This counts each completed frame as NAPI work whether it was delivered or dropped, matching the behavior of the vendor driver. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-3-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni commit baa26841cb9a2cdc7e0e99d6854a4e3359bf7393 Author: Linus Walleij Date: Thu Sep 3 23:45:30 2026 +0200 net: ethernet: cortina: Finish RX updates before NAPI completion napi_complete_done() releases ownership of the NAPI instance, but the Gemini poll keeps the RX statistics writer section open and updates the free queue after calling it. A new poll can therefore start while the old writer is still active. Finish the statistics and free queue updates before releasing ownership. Only re-enable RX interrupts when napi_complete_done() reports successful completion. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Suggested-by: Joe Damato Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-2-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni commit a0de06d0da78a3db53de65dfd7452cc6d111f703 Author: Linus Walleij Date: Thu Sep 3 23:45:29 2026 +0200 net: ethernet: cortina: Fix budget accounting The gmac_rx() function returns the remaining NAPI budget, but its caller treats the return value as the number of packets received. An idle poll therefore reports a full budget and remains scheduled. Return the number of received packets instead. Preserve the existing free queue refill accounting by adding that count directly; continuing to subtract it from the budget would invert the refill behavior. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Link: https://lore.kernel.org/r/20260509-gemini-ethernet-fixes-v1-4-6c5d20ddc35b@kernel.org Link: https://lore.kernel.org/r/20260512131456.189452-1-pabeni@redhat.com Assisted-by: LLM Reviewed-by: Joe Damato Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-1-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni commit 2b6c0e25a3d713c4032e45f212bdd9e14c50f8a0 Author: Aleksei Sviridkin Date: Thu Sep 3 12:36:52 2026 +0000 net: macb: reject an unknown link speed in the taprio setup speed is a u32, so SPEED_UNKNOWN arrives as 0xffffffff and passes the "speed <= 0" check, which only ever catches zero. That is what an autonegotiating link reports while it is down: the limit derived from the speed collapses to a nanosecond at most and the first entry fails with a misleading "exceeds hardware limit". Zero stays covered, it is what an interface that was never opened reports, and enst_max_hw_interval() divides by it. Say which case it was in the error. Fixes: 89934dbf169e ("net: macb: Add TAPRIO traffic scheduling support") Assisted-by: LLM Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260903123652.23900-3-f@lex.la Signed-off-by: Paolo Abeni commit 0523d5c52a450590bf5992bd6925394f3cc403e8 Author: Aleksei Sviridkin Date: Thu Sep 3 12:36:51 2026 +0000 net: macb: zero the link settings taprio reads back macb_taprio_setup_replace() calls phylink_ethtool_ksettings_get() with an uninitialised kset, and kset is not only an out-parameter. On a fixed link, or an in-band link with no PHY, phylink writes speed and duplex only if kset->base.rate_matching already reads RATE_MATCH_NONE, a field it never writes itself; in PHY mode before the PHY is attached it writes port and supported and nothing more. Either way the speed read back afterwards can be stack garbage. The ethtool core zeroes the structure on every path into the op, which is why its callers never see this; taprio is the only in-kernel caller passing its own variable. Fixes: 89934dbf169e ("net: macb: Add TAPRIO traffic scheduling support") Assisted-by: LLM Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260903123652.23900-2-f@lex.la Signed-off-by: Paolo Abeni commit 9868f5c077dfe0b606331f2e782484f91a5789a5 Author: Dinh Nguyen Date: Wed Jun 17 11:43:03 2026 -0500 EDAC/altera: Use parent device for devres in altr_portb_setup() Anchor the devres group and the devm-managed IRQ requests in altr_portb_setup() to the actual parent device (device->edac->dev) instead of the embedded struct device inside the copied per-port altr_edac_device_dev. This keeps devres_open_group(), devm_request_irq(), devres_remove_group() and devres_release_group() all referring to the same long-lived device so the group and the resources allocated inside it are torn down together. Fixes: 911049845d70 ("EDAC, altera: Add Arria10 SD-MMC EDAC support") Closes: https://sashiko.dev/#/patchset/20260503212558.2811480-1-dbgh9129%40gmail.com Assisted-by: LLM Signed-off-by: Dinh Nguyen Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260617164303.585555-1-dinguyen@kernel.org commit d7808b37da0a619cf1fa541c2384e783fecc2480 Author: Karl Mehltretter Date: Sat Sep 5 17:20:58 2026 +0200 virtio_input: stop callbacks before unregistering input device virtinput_remove() unregisters the input device before resetting the virtio device. virtinput_recv_events() drops vi->lock around input_event(), so clearing vi->ready does not stop a callback that passed the entry check. It can still use vi->idev, requeue buffers and kick the queue. Reset first, as virtinput_freeze() already does. With the preceding core change, reset waits for callbacks before input_unregister_device() can free vi->idev. Recheck vi->ready after taking the lock again: keep draining completed events so an input packet is not truncated, but stop requeueing buffers and kicking the queue. With evdev attached, input_unregister_handle() currently waits for an RCU grace period, which also waits out IRQ callbacks. This masks the lifetime bug on PCI and MMIO, but does not protect sleepable callbacks on other transports. Fixes: 271c865161c5 ("Add virtio-input driver.") Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Michael S. Tsirkin Message-ID: <20260905152059.89560-3-kmehltretter@gmail.com> commit 93fa09455fb1a9624b73d42ac1f83771f4818e80 Author: Andrew Stellman Date: Fri Sep 4 10:13:18 2026 -0400 virtio-pci: return IRQ_HANDLED after non-zero ISR vp_interrupt() reads the ISR before dispatching config-change and vring handling. Reading the ISR also clears it, so once the read returns non-zero the interrupt was from this device and has already been consumed. Currently vp_interrupt() returns the result of vp_vring_interrupt(). For a config-change interrupt with no vring work, that can return IRQ_NONE even though the ISR was non-zero and the interrupt was handled. Call vp_vring_interrupt() for any queue work, but once the ISR is non-zero return IRQ_HANDLED. Tested with QEMU virtio-blk-pci forced to INTx using vectors=0 and pci=nomsi. On an idle device, 200 config-change interrupts were generated using QMP block_resize. Before this change, irq_handler_exit reported ret=unhandled and /proc/irq/11/spurious increased from 0 to 200 unhandled interrupts. After this change, irq_handler_exit reported ret=handled and the unhandled count remained at 0. The issue was found during an LLM-assisted Quality Playbook review. Fixes: 77cf524654a8 ("virtio_pci: split up vp_interrupt") Suggested-by: Michael S. Tsirkin Assisted-by: LLM Signed-off-by: Andrew Stellman Message-ID: <20260904141318.30278-1-astellman@stellman-greene.com> Signed-off-by: Michael S. Tsirkin commit adbd8a08208dc64bb1381f51b4f11ffdce1343fa Author: Daasaradhi Mannava Date: Sat Sep 5 15:49:00 2026 +0000 MAINTAINERS: Drop the nonexistent vsi-iommu.h file entry Commit 917ace84b770 ("iommu: Add verisilicon IOMMU driver") added the VERISILICON IOMMU DRIVER section, including a file entry for include/linux/vsi-iommu.h. That header is not present in the tree and no file includes it; the driver in drivers/iommu/vsi-iommu.c is self-contained. scripts/get_maintainer.pl --self-test=patterns reports the pattern as matching no file. Drop the stale entry so the section only lists files that exist. Assisted-by: LLM Signed-off-by: Daasaradhi Mannava Reviewed-by: Benjamin Gaignard Signed-off-by: Joerg Roedel commit 2ac74c6db40adaa29c50cbb281ae9a6f63de18e1 Author: John Hubbard Date: Sun Sep 6 14:58:22 2026 -0700 rust: allow `clippy::as_underscore` in the generated bindings A CLIPPY=1 build emitted about 15000 `as _` conversion warnings, all of them in bindgen's generated output and none in hand-written code. [ The lint messages look like: error: using `as _` conversion --> rust/bindings/bindings_generated.rs:18947:9 | 18947 | self._bitfield_1.get_const::<0usize, 16u8>() as u32 as _ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^- | | | help: consider giving the type explicitly: `u32` | = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.98.0/index.html#as_underscore = note: `-D clippy::as-underscore` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::as_underscore)]` - Miguel ] bindgen 0.73 returns each bitfield read through a trailing `as _`, and 0.72 returns it through a transmute, which the lint ignores. The bindings and uapi crates allow `clippy::all` over the generated code. That group does not cover `clippy::as_underscore`, a restriction lint. Allow `clippy::as_underscore` by name in the bindings and uapi crates. Assisted-by: LLM Signed-off-by: John Hubbard Link: https://patch.msgid.link/20260906215822.1201022-1-jhubbard@nvidia.com Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). [ Removed CI sentence. - Miguel ] Signed-off-by: Miguel Ojeda commit b26a7a80e6bbf8dd17dacb127d12435d79375cf2 Author: Roman Prucha Date: Thu Sep 3 23:14:44 2026 +0200 ALSA: ctxfi: Fix CA20K2 S/PDIF passthrough dao_rsc_init() encodes the DAIO configuration as conf = (desc->msr & 0x7) | (desc->passthru << 3); S/PDIF passthrough uses msr=1 and passthru=1, resulting in conf=9. daio_mgr_dao_init() masks conf with 0xf, but handles only values 1, 2, 4 and 8 when programming ATXCTL_NUC. As a result, conf=9 falls through to the default case and leaves NUC at its previous setting. On a Creative X-Fi Titanium HD SB1270 (CA20K2), this breaks AC3 IEC61937 passthrough when snd_ctxfi runs with reference_rate=48000,multiple=2. The receiver detects a non-audio stream but cannot decode the AC3 payload. With the unmodified driver, multiple=1 makes the same stream work. Handle conf=9 through the same NUC=0 path as conf=1. The change was runtime tested on the SB1270 with multiple=2 using IEC958 stereo PCM, pre-encoded AC3 IEC61937 passthrough and ALSA A52 live 5.1 encoding. Fixes: 26a9630c72eb ("ALSA: ctxfi: cthw20k2: fix mask on conf to allow 4 bits") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Roman Prucha Link: https://patch.msgid.link/20260903-ctxfi-spdif-conf9-fix-v1-1-5e4e3e1f801c@gmail.com Signed-off-by: Takashi Iwai commit 97f8cb91a8c5658fe2ae6f5c2ff6e95474a5eb2f Author: Miguel Ojeda Date: Wed Aug 26 16:56:42 2026 +0200 drm/panic: clean new `clippy::needless_range_loop` lint for Rust 1.100.0 Starting with Rust 1.100.0 (expected 2026-11-12), Clippy warns: warning: the loop variable `i` is only used to index `self.decimals` --> drivers/gpu/drm/drm_panic_qr.rs:410:18 | 410 | for i in 0..len { | ^^^^^^ | note: for this index operation --> drivers/gpu/drm/drm_panic_qr.rs:411:13 | 411 | self.decimals[i] = (chunk % 10) as u8; | ^^^^^^^^^^^^^^^^ = help: for further information visit https://rust-lang.github.io/rust-clippy/main/index.html#needless_range_loop = note: `-W clippy::needless-range-loop` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::needless_range_loop)]` help: consider using an iterator | 410 - for i in 0..len { 410 + for in self.decimals.iter_mut().take(len) { | The lint did not trigger here before because it could not handle arrays behind a field access such as `self.decimals` -- Clippy was improved to catch those cases [1][2]. Thus clean the warning by iterating over a slice rather than using `take()` so that an out-of-range `len` still triggers the same bounds check as the indexed loop. Cc: stable@vger.kernel.org # Needed in 6.18.y and later. Link: https://github.com/rust-lang/rust-clippy/issues/16631 [1] Link: https://github.com/rust-lang/rust-clippy/pull/16634 [2] Assisted-by: LLM Reviewed-by: Alexandre Courbot Reviewed-by: Jocelyn Falempe Link: https://patch.msgid.link/20260826145642.43807-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda commit a77644d009dece1104b6fcc6e322b0e4503db0d6 Author: Karl Mehltretter Date: Fri Aug 28 19:41:31 2026 +0200 arm64: mm: Fix the lockless page-table walk in show_pte() show_pte() walks page tables locklessly and can run with interrupts enabled. A concurrent teardown can free a table page while it is being walked. It can also clear a parent entry after show_pte() checked it; the regular pXd_offset() helpers then reread the cleared entry and can derive a bogus lower-level pointer and fault again. Use the lockless offset helpers with the saved parent entries, as gup_fast() does, and pass the saved PMD to pte_offset_map(). For task page tables, arm64 selects MMU_GATHER_RCU_TABLE_FREE. Disable local interrupts around the walk to hold off RCU-deferred table frees and block the tlb_remove_table_sync_one() IPI until the walk is finished. Place the IRQ guard after the header print. This does not make the output a consistent snapshot, but prevents the task page-table walk from dereferencing a released table page or deriving a pointer from a different parent value. Fixes: 1d18c47c735e ("arm64: MMU fault handling and page table management") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Will Deacon commit d806d5a85dcbe2a0f181b2f0f9f61ddfbefa1818 Author: Karl Mehltretter Date: Wed Sep 2 20:28:14 2026 +0200 smb: client: pin DFS superblock in iterator callback tcon_super_cb() stores a raw superblock pointer, but __cifs_get_super() takes its active reference only after iterate_supers_type() has dropped s_umount and its passive reference. Concurrent DFS automount expiry can therefore free the superblock before cifs_sb_active() uses it. A deterministic KASAN test reproduces the race as: BUG: KASAN: slab-use-after-free in cifs_sb_active+0x77/0x80 The same test passes with this change applied. Take the active reference in the callback while iterate_supers_type() still holds s_umount shared. cifs_put_tcp_super() remains the matching release. Fixes: bacd704a95ad ("cifs: handle prefix paths in reconnect") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Paulo Alcantara commit cacf35832292997018837e484283f95a9301ebf5 Author: Qu Wenruo Date: Thu Aug 20 18:28:48 2026 +0930 btrfs: do not force reloc root creation during qgroup_account_snapshot() [BUG] When running btrfs/252 with quota enabled through MKFS_OPTIONS="-O quota", it has a high chance to trigger the following kernel warning and flips the fs RO: BTRFS info (device dm-2): relocating block group 30408704 flags metadata|dup ------------[ cut here ]------------ WARNING: fs/btrfs/extent-tree.c:879 at lookup_inline_extent_backref+0x74b/0x960 [btrfs], CPU#4: btrfs/2173 CPU: 4 UID: 0 PID: 2173 Comm: btrfs Not tainted 7.2.0-rc6-custom+ #457 PREEMPT(full) 3adc6528fb66f7a55fe1095385818e742f200aab Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:lookup_inline_extent_backref+0x74b/0x960 [btrfs] Call Trace: insert_inline_extent_backref+0x7c/0x160 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_inc_extent_ref+0xa9/0x270 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_run_delayed_refs+0x4af/0x11c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_run_delayed_refs+0x9d/0xf0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshot+0x39d/0xf00 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshots+0x9b/0xc0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_commit_transaction+0x280/0xeb0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] prepare_to_relocate+0x147/0x200 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] relocate_block_group+0x6b/0x5e0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_block_group+0x92c/0x2380 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_balance+0xa2c/0x19c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_ioctl+0x2839/0x2d30 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- BTRFS info (device dm-2): leaf 4593991680 gen 233 total ptrs 175 free space 5953 owner 2 BTRFS info (device dm-2): refs 3 lock_owner 2173 current 2173 item 0 key (166772736 METADATA_ITEM 1) itemoff 16250 itemsize 33 extent refs 1 gen 222 flags 2 ref#0: tree block backref root 266 [ Skip the tree dump ] item 174 key (263225344 METADATA_ITEM 0) itemoff 10328 itemsize 33 extent refs 1 gen 162 flags 258 ref#0: tree block backref root 267 BTRFS error (device dm-2): extent item not found for insert, bytenr 179847168 num_bytes 16384 parent 4594335744 root_objectid 273 owner 0 offset 0 BTRFS error (device dm-2): failed to run delayed ref for logical 179847168 num_bytes 16384 type 182 action 1 ref_mod 1: -117 [CAUSE] The above error is showing that there is a tree reference to a metadata extent that is no longer there. With "ref_verify" mount option (requires CONFIG_BTRFS_DEBUG), there is some extra debug output: BTRFS error (device dm-2): dumping block entry [180961280 16384], num_refs 0, metadata 1, from disk 0 BTRFS error (device dm-2): root entry 256, num_refs 18446744073709551615 BTRFS error (device dm-2): root entry 273, num_refs 18446744073709551615 BTRFS error (device dm-2): Ref action 3, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 1 btrfs_force_cow_block+0x129/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_insert_empty_items+0x3a/0x70 [btrfs] insert_with_overflow+0x53/0x130 [btrfs] btrfs_insert_dir_item+0x125/0x290 [btrfs] btrfs_add_link+0xaa/0x410 [btrfs] btrfs_rename+0x5ea/0xcd0 [btrfs] btrfs_rename2+0x28/0x60 [btrfs] vfs_rename+0x5b2/0xe10 filename_renameat2+0x244/0x430 __x64_sys_rename+0x48/0x70 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 BTRFS error (device dm-2): Ref action 2, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 18446744073709551615 btrfs_force_cow_block+0x327/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_lookup_file_extent+0x4d/0x70 [btrfs] btrfs_drop_extents+0x151/0xf00 [btrfs] insert_reserved_file_extent+0xfe/0x3e0 [btrfs] btrfs_finish_one_ordered+0x549/0xc40 [btrfs] btrfs_work_helper+0xde/0x350 [btrfs] process_one_work+0x198/0x380 worker_thread+0x1c8/0x330 kthread+0xee/0x120 ret_from_fork+0x28f/0x310 ret_from_fork_asm+0x11/0x20 BTRFS error (device dm-2): Ref action 1, root 273, ref_root 0, parent 4594335744, owner 0, offset 0, num_refs 1 __btrfs_mod_ref+0x1c5/0x2d0 [btrfs] btrfs_copy_root+0x262/0x390 [btrfs] create_reloc_root+0xb9/0x370 [btrfs] btrfs_init_reloc_root+0xb0/0x1b0 [btrfs] record_root_in_trans+0xa6/0xd0 [btrfs] create_pending_snapshot+0x383/0xf00 [btrfs] create_pending_snapshots+0x9b/0xc0 [btrfs] btrfs_commit_transaction+0x280/0xeb0 [btrfs] prepare_to_relocate+0x147/0x200 [btrfs] relocate_block_group+0x6b/0x5e0 [btrfs] btrfs_relocate_block_group+0x92c/0x2380 [btrfs] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs] btrfs_balance+0xa2c/0x19c0 [btrfs] btrfs_ioctl+0x2839/0x2d30 [btrfs] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 The above shows the direct cause, Ref action 3 is the oldest operation, which shows the tree block is created by COW. Then ref action 2 shows it's COWed away, by a metadata update, meaning the tree block is already released, should not be referred any more. Then the final one, is trying to create a reloc tree for subvolume 273, and that reloc root creation is referring to the already dropped tree block. The root cause is that, during qgroup_account_snapshot(), we are calling record_root_in_trans() with "force = true". So if the root has no reloc root, we will create one, but at that timing it's already too late. Normally reloc root should be created before the commit and current roots diverge, to avoid the same problem we are hitting. But during relocation initialization, we are committing the current running transaction, with a new reloc_control attached halfway. And if qgroup is enabled, the record_root_in_trans() with "force = true" calls will force reloc root creation even if we do not and should not create reloc root at that timing. [FIX] Do not force reloc root creation during record_root_in_trans() with "force = true" cases, which is only called by qgroup_account_snapshot(). If we're really under relocation, the reloc root should be created way early, before the commit and current root diverge. If the root has no reloc tree yet, it means we're still initializing the reloc, and do not need a reloc root. So skipping the reloc tree creation in qgroup_account_snapshot() should be safe. Link: https://bugzilla.suse.com/show_bug.cgi?id=1275740 Fixes: 4d31778aa2fa ("btrfs: qgroup: Fix root item corruption when multiple same source snapshots are created with quota enabled") Assisted-by: LLM (initial analysis, but incorrect conclusion with too many burnt tokens) Tested-by: Disha Goel Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba commit 2519439b4b5f6ee95879b1a44fc373127291b1e4 Author: Linus Walleij Date: Wed Sep 2 09:55:59 2026 +0200 ASoC: ux500: Program the MSP FIFO watermarks The DMA engine is configured for four-element bursts, but the MSP driver never programs the FIFO watermark register and instead depends on its previous or reset value. The DB8500 DMA request protocol requires the peripheral watermark to match the DMA packet size. Program four-element receive and transmit watermarks when configuring the first direction, before enabling MSP DMA requests. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-9-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit dc1a1b1e22066f01bb86a9b11ee998d4dc72db66 Author: Linus Walleij Date: Wed Sep 2 09:55:58 2026 +0200 ASoC: ux500: Allow repeated MSP prepare calls ALSA can call the DAI prepare callback again after an XRUN without first shutting down the stream. The MSP open helper rejects the second call with -EBUSY because the direction remains configured. Track successful playback and capture configurations at the DAI layer. Make repeated prepare calls no-ops and only close directions which were successfully prepared. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-8-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit 7b819677b503667422b0b7bdb21853e0066f8606 Author: Linus Walleij Date: Wed Sep 2 09:55:57 2026 +0200 ASoC: ux500: Remove obsolete PRCMU QoS calls The DB8500 PRCMU QoS interface consists of unconditional inline stubs, so the MSP calls and cached constraint state have no effect. Device power and clocks are already represented by the regulator, power-domain and common-clock frameworks. Remove the dead calls and their private state instead of pretending to change the APE operating point. Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-7-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit 4fb67925f33ad789e9e00903a73306ed40f7ae32 Author: Linus Walleij Date: Wed Sep 2 09:55:56 2026 +0200 ASoC: ux500: Request the MSP MMIO resource A bare devm_ioremap() neither reserves the register range nor preserves the platform resource error. This permits another driver to claim the same range and reports every mapping failure as an allocation failure. Use the managed platform resource helper, retaining the resolved resource only to derive the DMA register address. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-6-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit 66ec63e7a90bedc56aa050fbe437964008c3d584 Author: Linus Walleij Date: Wed Sep 2 09:55:55 2026 +0200 ASoC: ux500: Deassert the MSP reset during probe The devicetree has described each MSP reset line since the PRCC reset controller was added, but the driver never acquires or deasserts it. The block can consequently remain inaccessible when firmware has left it in reset. Acquire the reset exclusively and keep it deasserted for the lifetime of the bound device. Fixes: 95f04048325c ("ARM: dts: ux500: Add reset lines to IP blocks") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-5-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit 9ccbacf5a0120964fc1ffacb8151e3347bee9287 Author: Linus Walleij Date: Wed Sep 2 09:55:54 2026 +0200 ASoC: ux500: Validate MSP DAI configuration Installing channel constraints from hw_params is too late to affect the parameters being committed. The driver consequently accepts channel counts which disagree with the I2S or TDM setup. It also silently truncates out-of-range slot masks and accepts inverted bit clock formats which prepare then rejects. Validate the selected channel count directly, reject invalid masks before changing cached TDM state, and implement all four standard clock and frame inversion combinations. Use the requested format in validation diagnostics. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-4-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit 94c18cea657c48680e4ee20b635b6c01f3eb352e Author: Linus Walleij Date: Wed Sep 2 09:55:53 2026 +0200 ASoC: ux500: Correct MSP frame and bit clock setup FRPER plus one is the number of bit clocks in a frame. It must follow the configured slot count and width. The legacy rate-dependent constants produce malformed frames; notably, a 16-slot, 16-bit frame is programmed as 278 rather than 256 clocks. Derive the frame period from the TDM geometry and use the real functional clock rate. Validate that the requested bit clock has an exact, representable divider, program SCKDIV as divider minus one, and report the resulting bit clock using that same divisor. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-3-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit 3415421a2b0bc4e32bb5a9df24ed7863512d47a7 Author: Linus Walleij Date: Wed Sep 2 09:55:52 2026 +0200 ASoC: ux500: Propagate MSP setup errors The prepare callback continues with a partly initialized configuration when format setup fails. Probe likewise tests the allocated pointer instead of the return value, so an MMIO resource or mapping failure can be ignored after allocation succeeds. Return configuration failures from prepare and test the MSP initialization result directly. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-2-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit c37ba8fe00f264eee2fd18b0bff7c5f188136c51 Author: Linus Walleij Date: Wed Sep 2 09:55:51 2026 +0200 ASoC: ux500: Fix MSP stream lifecycle handling The trigger stop path drops the direction busy flag even though ALSA still owns the stream until shutdown. A later trigger cannot reliably restart it, shutdown may leave the block configured, and a second stream may overwrite shared duplex configuration. Keep configured and running directions as separate state. Program shared settings only for the first direction, require a compatible configuration for the other half of a duplex stream, and enable the frame generator only while a provider stream is running. Also fix the RX-disable direction test and preserve the other direction multichannel setup. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-1-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit 312fd3f3a85b89aa0d4fb5417043d640daa3732c Author: Dmitry Torokhov Date: Sun Aug 30 04:15:10 2026 -0700 platform/x86: x86-android-tablets: use shared battery swnode group on Yoga Tab 2 The WM5102 codec software node lenovo_yoga_tab2_830_1050_wm5102 is registered automatically when attached to the codec device via device_add_software_node() in lenovo_yoga_tab2_830_1050_init_codec(). Including it in lenovo_yoga_tab2_830_1050_swnodes is therefore redundant, leaving generic_lipo_hv_4v35_battery_node as the only node needing registration. Switch lenovo_yoga_tab2_830_1050_info and lenovo_yoga_tab2_1380_info to use the shared generic_lipo_hv_4v35_battery_swnodes group directly and drop the custom lenovo_yoga_tab2_830_1050_swnodes array. Assisted-by: LLM Signed-off-by: Dmitry Torokhov Tested-by: Hans de Goede # Yoga tab 2 1380, yt3 Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260830-x86-android-lenovo-swnode-v1-6-066a91acb4ba@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit 74884436a53df0bbaf6d92d2922f643a4581b247 Author: Dmitry Torokhov Date: Sun Aug 30 04:15:09 2026 -0700 platform/x86: x86-android-tablets: drop redundant swnode group on YT3 The WM5102 codec software node lenovo_yt3_wm5102 is assigned to the board info swnode pointer in lenovo_yt3_spi_devs. When spi_new_device() instantiates the SPI device, device_add_software_node() automatically registers the software node. Therefore, explicitly registering lenovo_yt3_swnodes via software_node_register_node_group() and listing it in .swnode_group is redundant. Drop the unused node group and registration. Assisted-by: LLM Signed-off-by: Dmitry Torokhov Tested-by: Hans de Goede # Yoga tab 2 1380, yt3 Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260830-x86-android-lenovo-swnode-v1-5-066a91acb4ba@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit 7872c625cd83a0247821cedd6c6f63938d4bddbc Author: Dmitry Torokhov Date: Sun Aug 30 04:15:08 2026 -0700 platform/x86: x86-android-tablets: add Crystal Cove GPIO swnode support The crystalcove_gpiochip_node was created when gpiolib supported matching a software node name against the GPIO chip label. Later, gpiolib replaced name matching with firmware node identity mapping, and support for dynamically attaching software nodes to ACPI GPIO chips as secondary firmware nodes was added for Baytrail and Cherryview, but Crystal Cove ("INT33FD:00") was omitted. Consequently, lookups on the unattached Crystal Cove software node fail. Add support for attaching crystalcove_gpiochip_node to the INT33FD:00 ACPI device as a secondary firmware node, and enable it on Lenovo Yoga Tab 2 models. Fixes: 611fd6cfe139 ("gpio: swnode: remove deprecated lookup mechanism") Assisted-by: LLM Signed-off-by: Dmitry Torokhov Tested-by: Hans de Goede # Yoga tab 2 1380, yt3 Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260830-x86-android-lenovo-swnode-v1-4-066a91acb4ba@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit aab060ec969c3859b81f80f3444fd5a2edfc3cf5 Author: Dmitry Torokhov Date: Sun Aug 30 04:15:07 2026 -0700 platform/x86: x86-android-tablets: pass node group to gpio_secondary_fwnode_init() Currently gpio_secondary_fwnode_init() uses a file-scope static gpiochip_node_group variable initialized in probe. Pass the node group directly to gpio_secondary_fwnode_init() as an argument instead of using a global variable. This allows reusing the helper for additional GPIO controllers in subsequent patches. Assisted-by: LLM Signed-off-by: Dmitry Torokhov Tested-by: Hans de Goede # Yoga tab 2 1380, yt3 Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260830-x86-android-lenovo-swnode-v1-3-066a91acb4ba@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit 144113b0a70fa18033a747ee5db6803308f7688c Author: Dmitry Torokhov Date: Sun Aug 30 04:15:06 2026 -0700 platform/x86: x86-android-tablets: hold device reference for secondary fwnode teardown In gpio_secondary_fwnode_init(), acpi_bus_find_device_by_name() returns a device reference, but the local dev variable is declared with __free(put_device), dropping the reference at the end of each iteration. Meanwhile, devm_add_action_or_reset() saves the dev pointer for gpio_secondary_unset() without incrementing its reference count, which could lead to a use-after-free during driver teardown if the device is released in the interim. Acquire an explicit device reference with get_device() when registering the devres action, and drop it with put_device() inside gpio_secondary_unset(). Fixes: 1448c2d2ca5c ("platform/x86: x86-android-tablets: enable fwnode matching of GPIO chips") Assisted-by: LLM Signed-off-by: Dmitry Torokhov Tested-by: Hans de Goede # Yoga tab 2 1380, yt3 Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260830-x86-android-lenovo-swnode-v1-2-066a91acb4ba@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit 355b6558dd7be049aff4f0d438b0128f91a982eb Author: Dmitry Torokhov Date: Sun Aug 30 04:15:05 2026 -0700 platform/x86: x86-android-tablets: fix Arizona GPIO swnode references The standalone arizona_gpiochip_node was created when gpiolib supported matching a software node name against the GPIO chip label ("arizona"). Later, gpiolib replaced name matching with firmware node identity mapping (and eventually dropped the fallback mechanism), causing GPIO lookups on unattached software nodes to fail. In gpio-arizona, the GPIO chip inherits the firmware node of the parent codec device. Fix the lookups by pointing the GPIO property entries directly to the codec device software node (which is attached to the parent device) and dropping the obsolete arizona_gpiochip_node. Fixes: 611fd6cfe139 ("gpio: swnode: remove deprecated lookup mechanism") Assisted-by: LLM Signed-off-by: Dmitry Torokhov Tested-by: Hans de Goede # Yoga tab 2 1380, yt3 Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260830-x86-android-lenovo-swnode-v1-1-066a91acb4ba@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit 7a4ce92d150b9e7ecf1a710a34d8cdeb590d3751 Author: Tianchu Chen Date: Mon Aug 31 15:13:36 2026 +0000 ASoC: sprd: validate compress buffer sizes against fixed allocations sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but sprd_platform_compr_copy() derives all copy lengths from the user controlled runtime->fragment_size and the write() count, never comparing them against the physical buffer sizes. The compress core only checks fragment_size * fragments for an u32 overflow in snd_compress_check_input(), so a local user can configure a logical buffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the fixed allocations. A fragment_size larger than the 32K IRAM data area makes the stage 0 copy_from_user() overflow past the IRAM allocation, and a buffer_size larger than the 2M DDR buffer makes the wrapping copy at the end of sprd_platform_compr_copy() write fully user controlled data past the buffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP state reaches the copy callback directly. Reject parameters that do not fit into the fixed buffers in set_params(), and fix the advertised max fragment size: 128K never fitted into the 32K IRAM buffer. The caps values may have been carried over from the qdsp6 driver, which allocates its buffers according to the advertised maxima, unlike this driver. With 32K as max fragment size the advertised limits are self-consistent: 32K * 64 = 2M equals the DDR buffer size. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: cce1396936ef ("ASoC: sprd: Add Spreadtrum audio compress offload support") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/4386bc53631b052c1866a91061715b009d98b04f@linux.dev Signed-off-by: Mark Brown commit 711178754287db3fd0f7accff3c2a7575f8873b7 Author: Linus Walleij Date: Mon Aug 31 22:29:11 2026 +0200 ASoC: ab8500: Skip missing DMIC GPIOs on AB8505 GPIO27, GPIO29 and GPIO31 provide the digital microphone clock outputs on AB8500, but these GPIOs do not exist on AB8505. The shared codec driver nevertheless accesses their direction register while setting up every AB8505 codec. Identify the parent MFD device and leave the nonexistent GPIOs untouched on AB8505. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-6-f85024e717e3@kernel.org Signed-off-by: Mark Brown commit ec75e653b70ce26ea68187c2069722baa80efadb Author: Linus Walleij Date: Mon Aug 31 22:29:10 2026 +0200 ASoC: ab8500: Remove the nonfunctional sidetone apply control After the coefficient controls were removed, writing "Apply FIR" programs 128 zero coefficients and reports that the sidetone filter is configured. The associated ANC configuration DAPM pins are also now unreachable dead infrastructure. Remove the misleading status/apply control, its private state, and the obsolete configuration-only DAPM pins. Keep the direct sidetone reset and remaining hardware controls. Fixes: e366ce8b22ec ("ASoC: codecs: ab8500: Remove suspicious code") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-5-f85024e717e3@kernel.org Signed-off-by: Mark Brown commit 85cef7e2004ef5c1a715feaddb55d3f3d27bac0a Author: Linus Walleij Date: Mon Aug 31 22:29:09 2026 +0200 ASoC: ab8500: Validate and program TDM slots correctly The interface clock ratio is selected from the slot count alone, ffs() and fls() produce one-based hardware slot numbers, eight-channel mode does not program any mappings, and all register errors are ignored. Invalid masks can also leave a partially programmed interface. Validate the complete configuration first, derive the supported BCLK ratio from slots times slot width, use zero-based slot indices, program deterministic eight-channel maps, and propagate register failures. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-4-f85024e717e3@kernel.org Signed-off-by: Mark Brown commit f98785adf004db6b1c9f4cea9dadae7b800db72f Author: Linus Walleij Date: Mon Aug 31 22:29:08 2026 +0200 ASoC: ab8500: Correct digital interface format setup The codec programs I2S as an undelayed left-aligned format, although the hardware manual defines delayed left-aligned as I2S compatible. It also enables the master generator when the codec is a clock consumer, changes registers before the complete format has been validated, and discards register I/O errors. Build all three interface register values before writing them, use the required one-bit I2S delay, only run the master generator for a provider configuration, and propagate write failures. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-3-f85024e717e3@kernel.org Signed-off-by: Mark Brown commit 103fe1a37f040ef6ac9ed1cf33be786149d2bb15 Author: Linus Walleij Date: Mon Aug 31 22:29:07 2026 +0200 ASoC: ab8500: Repair the DAPM capture graph The capture stream routes point away from the stream widget. Digital microphone mux routes are unconditional and bypass their enable bits, and several widgets independently own shared AD path enable bits. The dummy ADC and DAC widgets hide the resulting power graph errors. Connect each real AIF widget to the stream and main supply, use the mux item names on digital microphone routes, and model shared AD enables as supplies. Also make the ANC DAPM switch writable. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-2-f85024e717e3@kernel.org Signed-off-by: Mark Brown commit 8e839bca7793a0b03c005f4b2b0825464290d425 Author: Linus Walleij Date: Mon Aug 31 22:29:06 2026 +0200 ASoC: ab8500: Reset the audio block before configuring it ResetAudn is active low, but the codec probe only deasserts it. It also clears Clk32kOut2Dis despite claiming to disable that output, and writes codec registers before releasing reset. Pulse ResetAudn before the first audio-bank access and leave the unused 32 kHz output disabled. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-1-f85024e717e3@kernel.org Signed-off-by: Mark Brown commit 3f4b7d1a49c5c826f3be9b684313eea5b83ac232 Author: Etienne Perot Date: Fri Aug 28 21:52:52 2026 +0000 selftests/cgroup: test clone3() into a previously killed cgroup Once cgroup.kill had been written to a cgroup, a stale kill_seq snapshot (taken in cgroup_css_set_fork() before the target cgroup was resolved) caused every child subsequently cloned into that cgroup with clone3(CLONE_INTO_CGROUP) to be SIGKILLed on the spot. Add a regression test: create a cgroup, kill it while it is empty, then clone a child into it and check that the child runs and exits cleanly. On a kernel without the fix, the test fails: not ok 4 test_cgkill_clone_into_killed The test is skipped on kernels without clone3() or without CLONE_INTO_CGROUP. Cc: Shakeel Butt Assisted-by: LLM Signed-off-by: Etienne Perot Signed-off-by: Tejun Heo commit 8e359920216689b3b79e0fe8961a77fe312a511f Author: Etienne Perot Date: Fri Aug 28 21:52:51 2026 +0000 cgroup: fix spurious SIGKILL of CLONE_INTO_CGROUP children Since commit b69bb476dee9 ("cgroup: fix race between fork and cgroup.kill"), the fork path snapshots the kill_seq of the child's future cgroup into kargs->kill_seq, and cgroup_post_fork() SIGKILLs the child if that cgroup's kill_seq has changed in the meantime, to catch forks racing with a cgroup.kill sweep. For CLONE_INTO_CGROUP, however, the snapshot in cgroup_css_set_fork() is taken before the target cgroup has been resolved: kargs->cgrp is always NULL at this point (it is only set at the end of the function). So the "if (kargs->cgrp)" branch is dead code and the snapshot always records the kill_seq of the parent's cgroup. cgroup_post_fork() then compares it with the kill_seq of the target cgroup, so the child gets SIGKILLed whenever the two cgroups have been killed a different number of times. As a result, once cgroup.kill has been written to a cgroup, every child subsequently cloned into it with clone3(CLONE_INTO_CGROUP) is killed on the spot, for as long as the cgroup exists: kill_seq is not exposed to userspace and never resets. Re-snapshot kill_seq from the target cgroup once it has been resolved, and drop the dead branch at the early snapshot site. This does not reopen the race fixed by b69bb476dee9. For CLONE_INTO_CGROUP, everything from the snapshot to the check in cgroup_post_fork() runs with cgroup_mutex held, and kill_seq is only ever incremented under cgroup_mutex. tj: Updated the comment above kill_seq to reflect the new serialization rules as suggested by Shakeel Butt. Fixes: b69bb476dee9 ("cgroup: fix race between fork and cgroup.kill") Cc: stable@vger.kernel.org Cc: Shakeel Butt Assisted-by: LLM Signed-off-by: Etienne Perot Signed-off-by: Tejun Heo commit 5eab74874d11160725c42ab676ba97a797a362eb Author: Ivan Immanuel Shaji Date: Tue Aug 25 12:52:50 2026 -0400 ring-buffer: Stop remote reader update when page swap fails The remote swap_reader_page callback can return -EBUSY when the writer moves the head before the remote catches it, particularly during an event storm on a small buffer. __rb_get_reader_page_from_remote() currently warns about that failure but continues with the unchanged reader ID and rearranges the local page list as though the swap succeeded. Handle the callback failure as a recoverable error. Report it with pr_warn_ratelimited() and return NULL. Callers already handle a NULL reader page as a failed attempt. This avoids splicing the same page as both the previous and new reader without flooding the log under contention. Cc: stable@vger.kernel.org Fixes: 2e67fabd8b77 ("ring-buffer: Introduce ring-buffer remotes") Link: https://patch.msgid.link/20260825-kernel-patch-1-v2-2-bb3461807a32@gmail.com Assisted-by: LLM sparse Signed-off-by: Ivan Immanuel Shaji Signed-off-by: Steven Rostedt commit e0d3aed7b12cf37b74c7cc5265073d0263b49cde Author: Ivan Immanuel Shaji Date: Tue Aug 25 12:52:49 2026 -0400 tracing: Fix retry exhaustion in simple ring buffer reader swap simple_ring_buffer_swap_reader_page() starts with retry set to 8 and post-decrements it only after a failed link replacement. On the final attempt, a successful replacement leaves retry at zero, while a failed replacement leaves it at -1. The current !retry test reverses both outcomes. It returns an error after a successful final replacement, leaving the link update complete but the reader bookkeeping unfinished. After a failed final replacement, it falls through and updates the head and reader pointers as though the replacement succeeded, which can corrupt the ring. Treat only a negative counter as exhaustion and return the documented -EBUSY error. Cc: stable@vger.kernel.org Fixes: 34e5b958bdad ("tracing: Introduce simple_ring_buffer") Link: https://patch.msgid.link/20260825-kernel-patch-1-v2-1-bb3461807a32@gmail.com Assisted-by: LLM sparse Reviewed-by: Vincent Donnefort Signed-off-by: Ivan Immanuel Shaji Signed-off-by: Steven Rostedt commit 5febf432df1cfa5b25d99b54c32103fafbdd0eb9 Author: Miguel Ojeda Date: Sun Aug 16 15:32:33 2026 +0200 kbuild: rust: keep Rust objects out of Clang LTO with inline helpers Under `CONFIG_LTO_CLANG` + `CONFIG_RUST_INLINE_HELPERS`, one may hit `objtool` errors such as: vmlinux.o: error: objtool: _R..._3Gsp4boot+0xd6a: can't find jump dest instruction at .text._R..._3Gsp4boot+0x1dfd The reason is that in such builds, the Clang invocation that compiles the combined Rust plus helpers bitcode emits LLVM bitcode (again) -- the final code generation happens in the linker's LTO step, which the `-mllvm` trap options passed to Clang do not reach. This, in turn, means that unreachable traps are missing, and the impossible paths do not merely fallthrough to the next symbol, but past the end of their own section, since LTO builds place each function in its own section. Thus filter `CC_FLAGS_LTO` out of the Clang invocation, so that it always emits machine code directly, with the traps in place. Assisted-by: LLM Cc: Gary Guo Cc: Boqun Feng Cc: Alice Ryhl Cc: Matthew Maurer Cc: Josh Poimboeuf Cc: Peter Zijlstra Cc: stable@vger.kernel.org Fixes: 3a2486cc1da5 ("kbuild: rust: provide an option to inline C helpers into Rust") Acked-by: Gary Guo Link: https://patch.msgid.link/20260816133233.197500-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda commit 0bff7711c19ba05ff3b686554c5a2d503c3e9797 Author: Miguel Ojeda Date: Sun Aug 16 15:32:32 2026 +0200 kbuild: rust: preserve unreachable traps with inline helpers When `CONFIG_RUST_INLINE_HELPERS` is enabled, it is possible to hit `objtool` warnings like: vmlinux.o: warning: objtool: _R..._4cmdq12CommandToGsp4init() falls through to next function _R..._4core5array4iter8IntoIterRShKj3_EEEBa_() `rustc` normally emits traps for unreachable paths. However, under `CONFIG_RUST_INLINE_HELPERS=y`, `rustc` emits LLVM bitcode and Clang performs final code generation after the helper bitcode is linked, but Clang does not trap unreachable IR by default. In turn, this means `objtool` follows compiler-generated impossible Rust `enum` paths through alignment padding into the next function, resulting in fallthrough warnings. Thus pass the LLVM `trap-unreachable` option to the final Clang invocation and suppress traps immediately after `noreturn` calls, which `objtool` already recognizes as dead ends. The combination of both flags makes it match `rustc`'s behavior. Rust 1.85.0 (the minimum supported one) supports LLVM >= 18, and both flags are available in LLVM 18. Assisted-by: LLM Cc: Gary Guo Cc: Boqun Feng Cc: Alice Ryhl Cc: Matthew Maurer Cc: Josh Poimboeuf Cc: Peter Zijlstra Cc: stable@vger.kernel.org Fixes: 3a2486cc1da5 ("kbuild: rust: provide an option to inline C helpers into Rust") Acked-by: Gary Guo Link: https://patch.msgid.link/20260816133233.197500-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda commit 6dd5d93f6c48a461157c73b9e2ce7f6d19d57f5a Author: Guopeng Zhang Date: Tue Aug 11 16:30:27 2026 +0800 cgroup/cpuset: Remove obsolete PFA_SPREAD_SLAB task flag Commit 16a1d968358a ("mm/slab: remove mm/slab.c and slab_def.h") removed the SLAB allocator, the only allocator that implemented cpuset slab spreading. Commit 61a182ab61a6 ("cgroup/cpuset: Remove cpuset_do_slab_mem_spread()") then removed the last task_spread_slab() caller. Commit 3ab67a9ce82f ("cgroup/cpuset: Mark memory_spread_slab as obsolete") marked the legacy control obsolete. cpuset still updates PFA_SPREAD_SLAB when tasks attach to a legacy cpuset and walks all tasks in a cpuset when memory_spread_slab changes. Remove the unused task flag and its helpers, and make spread task updates depend only on memory_spread_page. Keep the memory_spread_slab control and CS_SPREAD_SLAB state so legacy users retain the existing write, readback and inheritance behavior. Update the comments and documentation to describe only page-cache spreading as functional. Assisted-by: LLM Signed-off-by: Guopeng Zhang Reviewed-by: Waiman Long Signed-off-by: Tejun Heo commit 5d3ae80ecddeb82b492a2cf31ac3e44412b426f4 Author: Qing Luo Date: Fri Aug 7 14:43:14 2026 +0800 sctp: auth: propagate HMAC calculation errors to callers sctp_auth_calculate_hmac() can fail when building the association secret under memory pressure, but its void return silently leaves the HMAC digest zeroed. On the receive path, sctp_sf_authenticate() compares this zeroed digest against the peer-supplied one using crypto_memneq(), potentially accepting an all-zero HMAC from the peer if the allocation failed. On the send path, sctp_packet_pack() transmits a packet with a zeroed HMAC that the peer would reject. Improve error handling by making sctp_auth_calculate_hmac() return int: - sctp_sf_authenticate() returns SCTP_IERROR_NOMEM instead of accepting a zero HMAC. - sctp_packet_pack() drops the packet on failure instead of transmitting a zeroed HMAC. Update the declaration in auth.h accordingly. Assisted-by: LLM Signed-off-by: Qing Luo Acked-by: Xin Long Link: https://patch.msgid.link/20260807064314.500742-1-l1138897701@163.com Signed-off-by: Paolo Abeni commit 26d3a59e0241c3ef9f66ae1ae990f9326acbc059 Author: Guopeng Zhang Date: Mon Aug 10 17:55:59 2026 +0800 cgroup/cpuset: Use WRITE_ONCE() for shared prs_err updates cpuset_partition_show() reads cs->prs_err without cpuset_mutex using READ_ONCE(). The field is documented as not lock protected, but several updates to live cpusets still use plain stores. Convert the remaining prs_err stores on live cpusets to WRITE_ONCE(). Fixes: 0c7f293efc87 ("cgroup/cpuset: Add cpuset.cpus.exclusive.effective for v2") Assisted-by: LLM Signed-off-by: Guopeng Zhang Reviewed-by: Waiman Long Signed-off-by: Tejun Heo commit 46db3c8a1be96a354758b44b1d4fbb4b70d09a20 Author: Jeff Layton Date: Fri Jul 17 07:08:58 2026 -0400 nfsd: export NFSv4 callback op stats via netlink Add a proc4cb-ops nested attribute to the server-stats netlink dump, reusing the existing server-proc-entry (op/count) layout. The dump gains a callback section that emits one entry per callback opcode (OP_CB_GETATTR..OP_CB_OFFLOAD) from the per-netns callback counters, paged across messages like the other per-operation sections. This lets nfsstat report NFSv4 backchannel operation counts over netlink, including CB_GETATTR which corresponds to the procfs wdeleg_getattr line. Assisted-by: LLM Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260717-exportd-netlink-v7-6-b7ce17b83b60@kernel.org Signed-off-by: Chuck Lever commit 1e5f641dfa9998ca4a36018a6de9876eaff3db00 Author: Jeff Layton Date: Fri Jul 17 07:08:57 2026 -0400 nfsd: count NFSv4 callback operations per netns The NFS server tracks per-operation call counts for the forward channel (proc4ops) but keeps no statistics for the NFSv4 backchannel (callback) operations it sends to clients. Add a per-netns array of percpu counters for callback operations, indexed by RFC 8881 callback opcode (OP_CB_GETATTR..OP_CB_OFFLOAD), and bump the relevant counter in nfsd4_run_cb(), which is hit exactly once per callback that is actually queued. CB_GETATTR is sent when a GETATTR conflicts with an outstanding write delegation, which is roughly what the dedicated wdeleg_getattr counter tracked. The two are not identical: the old counter incremented on every such conflict, whereas the CB_GETATTR counter only counts callbacks that are actually queued, so concurrent conflicts that coalesce onto an already in-flight CB_GETATTR are now counted once rather than once per conflict. Report the procfs "wdeleg_getattr" line from the CB_GETATTR counter and drop the now-redundant NFSD_STATS_WDELEG_GETATTR counter, its helper, and its increment site. Assisted-by: LLM Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260717-exportd-netlink-v7-5-b7ce17b83b60@kernel.org Signed-off-by: Chuck Lever commit 5e4c283cb32f5d66618ffa9b5403ea09a60f2b61 Author: Jeff Layton Date: Fri Jul 17 07:08:56 2026 -0400 sunrpc: remove unused svc_version vs_count field Now that svc_seq_show() and the nfsd netlink stats handler both use the per-netns svc_stat vs_count arrays, the global per-version vs_count percpu counters are no longer read by anything. Remove the vs_count field from struct svc_version and all the associated DEFINE_PER_CPU_ALIGNED arrays and initializers across nfsd, lockd, and the NFS client callback service. Assisted-by: LLM Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260717-exportd-netlink-v7-4-b7ce17b83b60@kernel.org Signed-off-by: Chuck Lever commit 36ed32f46e2aa35084fa0e6edecc3f0a6178489f Author: Jeff Layton Date: Fri Jul 17 07:08:55 2026 -0400 nfsd: implement server-stats-get netlink handler Implement nfsd_nl_server_stats_get_dumpit() which exposes the NFS server statistics currently available via /proc/net/rpc/nfsd through the nfsd generic netlink family. The handler uses a dump operation to stream statistics across one or more netlink messages. The reply is divided into sections that are emitted in order: - scalar stats (reply cache, filehandle, IO, network, RPC), emitted once in the first message, then - per-version procedure counts (proc2/3/4-ops) and the NFSv4 per-operation counts (proc4ops-ops), using the per-netns vs_count arrays. cb->args[0] tracks the current section and cb->args[1] the entry index within it, so a section that does not fit in the current message is closed and resumed in the next one. This matters because the first dump message is allocated at NLMSG_GOODSIZE (a single page on most architectures) regardless of the client's receive buffer; packing every counter into one message would overflow it and fail the dump with -EMSGSIZE. Userspace merges the attributes from every message. This allows nfsstat to retrieve server statistics via netlink with a procfs fallback for older kernels. Assisted-by: LLM Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260717-exportd-netlink-v7-3-b7ce17b83b60@kernel.org Signed-off-by: Chuck Lever commit c1cd8442174afafbbd61799203145eae80b2163c Author: Jeff Layton Date: Fri Jul 17 07:08:54 2026 -0400 sunrpc: use per-net counts in svc_seq_show() Update svc_seq_show() to read from the per-netns statp->vs_count[] arrays instead of the global svc_version->vs_count[]. The only caller is nfsd, which always allocates vs_count via svc_stat_alloc_counts() in nfsd_net_init(), so the per-netns arrays are always available. This makes /proc/net/rpc/nfsd report per-network-namespace procedure call counts. Assisted-by: LLM Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260717-exportd-netlink-v7-2-b7ce17b83b60@kernel.org Signed-off-by: Chuck Lever commit f1775ed34ed3ecf1289588574b892aa9584e6ef3 Author: Jeff Layton Date: Fri Jul 17 07:08:53 2026 -0400 sunrpc: add per-netns per-procedure call counts to svc_stat The existing per-procedure call counts live in global svc_version->vs_count[] arrays which are not network-namespace-aware. Add per-netns equivalents in struct svc_stat so the upcoming netlink stats interface can return namespace-scoped statistics. Add a vs_count pointer array to struct svc_stat, along with svc_stat_alloc_counts() and svc_stat_free_counts() helpers to manage per-version percpu call count arrays. Increment the per-net counter alongside the global one in svc_generic_init_request(). Call the alloc/free helpers from nfsd_net_init() and nfsd_net_exit(). Assisted-by: LLM Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260717-exportd-netlink-v7-1-b7ce17b83b60@kernel.org Signed-off-by: Chuck Lever commit db4b9eefc8ee0bcaeee4d5e6a7313905f6a2fe7c Author: Johannes Thumshirn Date: Thu Jul 23 17:54:28 2026 +0200 btrfs: zoned: don't clobber the extent buffer when zeroing it out On a zoned filesystem a freed-but-still-dirty tree block is written out as zeros (EXTENT_BUFFER_ZONED_ZEROOUT) only to keep the zone write pointer advancing. btree_csum_one_bio() implemented this by memzeroing the extent buffer's own folios before submission. That destroys the in-memory buffer while it may still be referenced. In particular btrfs_free_tree_block() can run on it afterwards and reads the header to add a delayed reference; once the header has been zeroed it frees bytenr 0 and corrupts the extent tree (the btrfs_header_bytenr(buf) != 0 ASSERT in btrfs_free_tree_block(), or an "unable to find ref" abort). It is flaky and reproduces under fsstress, e.g. generic/461 and generic/013. Write the zeros to disk from the shared zero page instead and leave the extent buffer content untouched, so any later reference - including the delayed reference from btrfs_free_tree_block() - still sees a valid header. end_bbio_meta_write() now clears writeback on the buffer's own folios, as the bio no longer carries them. Fixes: aa6313e6ff2b ("btrfs: zoned: don't clear dirty flag of extent buffer") Assisted-by: LLM (debugging, commit message) Reviewed-by: Boris Burkov Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba commit 3cbcc099b4d42667ea8c6b10d28f6060c104048c Author: Johannes Thumshirn Date: Thu Jul 23 17:54:26 2026 +0200 btrfs: zoned: drop stranded dirty metadata on transaction abort On a zoned filesystem a freed tree block is not cleared but kept dirty and flagged EXTENT_BUFFER_ZONED_ZEROOUT, so a later writeback zeroes it out and advances the zone write pointer. A transaction abort turns the filesystem read-only before that writeback runs, so these buffers stay dirty and stranded ahead of the write pointer where btree_writepages() can no longer write them. They survive to the final iput() of the btree inode at unmount, which submits the write after the endio workqueues are gone, hanging unmount in folio_wait_writeback(). Clear the dirty state of such buffers when cleaning up the aborted transaction, where the buffer tree still references all of them. Assisted-by: LLM (debugging, commit message) Reviewed-by: Boris Burkov Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba commit ecc05eda9a346848ae01a6c8bfa3f0bec133bd8b Author: Johannes Thumshirn Date: Thu Jul 23 17:54:25 2026 +0200 btrfs: zoned: flush active metadata block group at btree_writepages() start btree_writepages() writes the btree inode's dirty metadata in ascending logical address order. On a zoned filesystem only one metadata and one system block group is active for writing at a time, and check_bg_is_active() (via btrfs_check_meta_write_pointer()) pivots the active block group as writeback moves from one block group to the next. If the active block group sits at a higher logical address than another block group that also holds dirty metadata, the ascending walk reaches the lower one first and, to write it, has to finish the active block group and activate the lower one. It cannot finish a block group that still has unsent IO, and during WB_SYNC_ALL && !for_sync (commit) writeback it deliberately refuses to wait for that IO under fs_info->zoned_meta_io_lock, as that can deadlock. The pivot thus cannot issue the submission itself either, so it gives up: btrfs_check_meta_write_pointer() returns -EAGAIN, which btrfs_write_and_wait_transaction() treats as fatal and aborts the transaction, forcing the filesystem read-only. This happens intermittently under metadata-heavy relocation (e.g. fstests btrfs/187). Flush the active metadata and system block groups at the start of btree_writepages(), under the fs_info->zoned_meta_io_lock it already holds, so they have no unsent IO left and the later pivot can finish them and make forward progress. Fixes: 13bb483d32ab ("btrfs: zoned: activate metadata block group on write time") Assisted-by: LLM (debugging, commit message) Reviewed-by: Boris Burkov Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba commit 5376c9db45368eb210b4d71104ac00a59dc8b6e0 Author: Boris Burkov Date: Tue Jul 14 17:21:02 2026 -0700 btrfs: write-protect folios during data writeback commit 095be159f3eb ("btrfs: unify folio dirty flag clearing") replaced the folio_clear_dirty_for_io() call in extent_write_cache_pages() with a plain folio_test_dirty() check. Besides clearing the dirty flag, folio_clear_dirty_for_io() also calls folio_mkclean(), which write-protects the shared mmap PTEs mapping the folio. Note that we still do call folio_clear_dirty_for_io() later in submit_one_sector() when we clear dirty on the last sector of the folio (the only sector for non-subpage cases). But we lost this early call in extent_write_cache_pages(). Without the extra write-protection, a process with the file mmap-ed can modify a sector while it is being used by writeback in a way that expects a stable folio (checksumming, compressing, copying, etc...) without faulting, which manifests as a handful of concrete bugs. 1. For large folios or subpage sectorsize, it is possible to submit a bio which does not cover the whole folio. When this happens, we will have a bio in flight for a folio that we have *not* called folio_clear_dirty_for_io() on. If a task with an existing mmap-ed PTE writes (without faulting..) in this window, it can result in corruptions. If the write arrives while the checksumming or writing itself is underway, this can result in an invalid checksum and later corruption reports on read. If the write arrives after checksumming/writing is done but before the last sector dirty is cleared, then the write is present in page cache but doesn't affect the dirty tracking and will be lost when the folio is fully finished being submitted and the dirty bit is cleared. This results in losing the write even if fsync() is called. 2. For zoned submissions which are done in batch separate from the main extent_writepage() loop, we also risk csum violations for those submissions. Zoned writes are clamped to max_zone_append_size and are not aligned with folios, so a submission can span two folios. The first folio being processed in extent_write_cache_pages() will call extent_write_locked_range() which will submit the partial range of the next folio, while the rest of that folio could still be dirty. So clearing dirty on the submitted sectors doesn't call folio_clear_dirty_for_io() and we have the same issue. Since extent_write_cache_pages() skips these batch submitted folios (they are already marked for writeback from submission by the preceding folio), we must add the extra write protection in lock_delalloc_folios(). 3. For inline extents this will subtly risk losing writes that happen after/while we copy the inline extent but before we clear dirty on the folio. 4. For folios spanning EOF, mmap could tamper with the zeroed bytes past EOF and cause them to be persisted where future faults would improperly see them instead of zeros. 5. Finally, for compressed extents, we risk modifying the folios while we work on compressing them which will result in corrupted compressed data. Specifically, in run_delalloc_compressed() we queue up work to do compress_file_range() in BTRFS_COMPRESSION_CHUNK_SIZE (512K) chunks which will call btrfs_folio_clamp_clear_dirty() on the range. For non-subpage, this will always clear the whole folio, safely. For subpage, we risk a partial clear here as well. In particular, imagine a 2M folio broken up into 512K chunks of work which might start compression work on one chunk before all the chunks compress_file_range() workers have gotten far enough to finish clearing all the dirty bitmaps of the folio and getting to folio_clear_dirty_for_io(). Large folios on the edges of submission ranges are similarly at risk to be only partly cleared. This particular gap was introduced by a second patch in the same series: commit a4ef54dbb576 ("btrfs: make extent_range_clear_dirty_for_io() to handle sector size < page size cases") We cannot simply restore the call to folio_clear_dirty_for_io() because that also drops the dirty flag off the folio which violates invariants introduced for large folios by commit 334509ce9d07 ("btrfs: use dirty flag to check if an ordered extent needs to be truncated") and results in failing to invalidate clean folios past i_size, resulting in deadlocks. Therefore, to fix it, leave the existing semantics w.r.t. the folio's dirty flag (to preserve the correct invalidate behavior) but ensure that the other aspect of folio_clear_dirty_for_io(), folio_mkclean(), is run on the folio when we lock it for writeback. Finally, to help prevent similar regressions in the future, add a debug warning that triggers at the known corruption sites if we have failed to write protect the folio. Assisted-by: LLM (debug, reproduce, research fix, review patch) Fixes: 095be159f3eb ("btrfs: unify folio dirty flag clearing") Fixes: a4ef54dbb576 ("btrfs: make extent_range_clear_dirty_for_io() to handle sector size < page size cases") Reviewed-by: Qu Wenruo Signed-off-by: Boris Burkov Signed-off-by: David Sterba commit 2a8d68338ee77e200895f2697c56fd00094767f7 Author: Jeff Layton Date: Tue Aug 4 12:13:44 2026 -0400 checkpatch.pl: adapt to new Assisted-by: format There is a new format for the 'Assisted-by:' tag. Change checkpatch.pl to just check that it has a value rather than testing for a specific format. Assisted-by: LLM Signed-off-by: Jeff Layton Signed-off-by: Jonathan Corbet Message-ID: <20260804-checkpatch-v1-1-27f29c79a46f@kernel.org> commit ae2567b11c3df43861d05f856bdb3434b3961aa1 Author: Boris Burkov Date: Thu Jul 30 09:38:02 2026 -0700 btrfs: flush the fixup workers during close_ctree Reintroducing the COW fixup worker brought back the unmount race fixed by commit 41fd1e94066a ("btrfs: wait for fixup workers before stopping cleaner kthread during umount") without bringing back the fix. A fixup work item queued by the final writeback pass can still be in flight when close_ctree() stops the cleaner kthread and frees the fs roots. While destroy_workqueue() drains the queue, that happens after the cleaner thread was freed, so btrfs_add_delayed_iput() called from the fixup worker is no longer safe (not to mention that we are already in BTRFS_FS_STATE_NO_DELAYED_IPUT when it runs). Therefore we need to bring back explicitly flushing the fixup workqueue as in Filipe's original fix. The first flush will catch all the fixup writeback queued during the final sync before umount, but some of that might hit memory allocation errors and stay fixup in the blocks/folio, leading any subsequent writeback triggered *inside* umount (e.g. reclaim workers shutting down) to hit it and queue again. To fix that, and the possibility of any really long-lived pinned folios getting marked, deny queueing new fixup during umount. That allows us to flush twice (once before doing a real writeback pass to get the actual data, second time to clean up any rather unlikely stragglers right before declaring BTRFS_FS_STATE_NO_DELAYED_IPUT) and be certain nothing got re-queued. Reproduced by injecting a one-shot 30s sleep at the head of btrfs_writepage_fixup_worker() on a KASAN kernel, running the normal reproducing read dio workload before unmount and then observing: BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x35/0x50 Read of size 1 at addr ffff88810b4b08f8 by task kworker/u32:5/219 Workqueue: btrfs-fixup btrfs_writepage_fixup_worker [btrfs] Call Trace: _raw_spin_lock_irqsave+0x35/0x50 try_to_wake_up+0xc0/0x18c0 btrfs_writepage_fixup_worker+0x7f3/0xf20 [btrfs] ... Fixes: 4be9c7da6860 ("btrfs: trigger cow fixup via dirty_folio()") Assisted-by: LLM (reproduction, analysis) Reviewed-by: Qu Wenruo Signed-off-by: Boris Burkov Signed-off-by: David Sterba commit 0ef349734a93227b45f65fc50a3311d1cc5f03e9 Author: Qu Wenruo Date: Fri Jul 31 10:14:49 2026 +0930 btrfs: initialize inode mapping flags for cached inodes [BUG] When running generic/795 with 8K block size, 4K page size, the test always fails, triggering some ASSERT()s related to folio size: 795 (241074): drop_caches: 3 assertion failed: IS_ALIGNED(start, blocksize) && IS_ALIGNED(end + 1, blocksize), in extent_io.c:1404 (blocksize=8192 root=262 ino=258 start=16826368 end=16830463 mapping min order=0) ------------[ cut here ]------------ kernel BUG at extent_io.c:1404! Oops: invalid opcode: 0000 [#1] SMP CPU: 8 UID: 0 PID: 241105 Comm: fsstress Tainted: G OE 7.2.0-rc5-custom+ #442 PREEMPT(full) f4bfb352566f3949f29c233ce6f735050a03b245 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:assert_folio_range.cold+0x3d/0x3f [btrfs] Call Trace: btrfs_read_folio+0x9e/0x170 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] prepare_one_folio.constprop.0+0x104/0x2a0 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] btrfs_buffered_write+0x285/0xa50 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] btrfs_do_write_iter+0x1aa/0x210 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] iter_file_splice_write+0x31a/0x540 direct_splice_actor+0x53/0x170 splice_direct_to_actor+0xe9/0x240 do_splice_direct+0x76/0xb0 vfs_copy_file_range+0x1fd/0x630 __x64_sys_copy_file_range+0xf9/0x220 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- The ASSERT() itself is added by a later patch. The crash is triggered with that new debug patch, and without this fix. [CAUSE] In the above case, the start 16826368 is properly 8K aligned, but the end (16830463 + 1) is not 8K aligned. Furthermore the mapping's minimal folio order is 0, not the expected 1 for 8K block size with 4K page size. So this means some inodes do not have btrfs_set_inode_mapping_order() called on it. The missing btrfs_set_inode_mapping_order() call happens for cached inodes, through the following events: - btrfs_create_new_inode() called for inode X Which properly sets minimal folio order for the VFS inode. - btrfs_update_inode() called for inode X Which calls btrfs_delayed_update_inode() to create a delayed_node into root->delayed_nodes xarray. - Drop cache/memory pressure, evicting in-memory inode X Which evicted the inode X, but delayed_node is still in root->delayed_nodes for future reuse. - btrfs_iget() for inode X called again btrfs_iget() |- btrfs_iget_locked() | |- iget5_locked_rcu() | Which creates a new vfs_inode for btrfs, whose mapping still | has the minimal order as 0. | |- btrfs_read_locked_inode() |- btrfs_fill_inode() | |- btrfs_get_delayed_node() | Which found out the previous node, and use that delayed | node to initialize the new inode. | |- filled = true; |- if (filled) goto cache_index; Which skips the btrfs_update_inode_mapping_flags() and btrfs_set_inode_mapping_order() calls. So the inode still has minimal folio order set as 0, not the required 1. Thus later page cache read will get a folio whose size is smaller than block size, as the mapping has its minimal folio order set as 0 not 1, then trigger the ASSERT(). [FIX] Move the btrfs_update_inode_mapping_flags() and btrfs_set_inode_mapping_order() calls under cache_index label, so that the mapping flags and minimal folio order is always set no matter if we have a cached inode. Assisted-by: LLM (analysis) Fixes: ecde48a1a6b3 ("btrfs: expose per-inode stable writes flag") Fixes: cc38d178ff33 ("btrfs: enable large data folio support under CONFIG_BTRFS_EXPERIMENTAL") Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba commit 0680cbbf39ca61c70be16141b5259f822e7cdb3b Author: Boris Burkov Date: Mon Jul 27 15:23:30 2026 -0700 btrfs: trigger cow fixup via dirty_folio() The problem scenario: If we have a folio mmapped shared and then somebody does a dio read with that folio as the read destination, then it is possible that the dio will see a dirty destination page when it starts (and thus skip dirtying and just GUP pin it) but then while it is doing the read, btrfs finishes writing it back and by the endio, the folio is clean. In that case, the dio read must re-dirty the folio with aops->dirty_folio(): btrfs_check_read_bio() |- __iomap_dio_bio_end_io() from btrfs_bio_end_io() |- bio_check_pages_dirty() |- bio_dirty_fn() |- bio_release_pages(bio, true) |- __bio_release_pages(bio, mark_dirty == true) |- folio_lock() |- folio_mark_dirty() |- aops->dirty_folio() |- folio_unlock() A data block normally moves through writeback as follows: TASK folio_lock write clean -> dirty bit + delalloc folio_unlock WRITEBACK for-each-dirty-folio: folio_lock run_delalloc delalloc consumed -> dirty bit + OE submission dirty bit consumed -> writeback bit + OE folio_unlock ENDIO endio OE bytes accounted OE finish writeback -> clean; destroy OE Three critical invariants that this path maintains are: I1. Any dirty block is covered by delalloc xor an ordered extent I2. Any dirty block covered by an OE will be submitted into that OE I3. Any dirty block already submitted into an OE will not be submitted again into the same OE. These ensure that the block will be written exactly once. It is clear that not reserving delalloc for the re-dirty case violates I1. This situation, even without bs < folio_size, has long required btrfs to fixup such dirty pages during writeback with an asynchronous worker that is allowed to do this expensive work and writeback does not proceed for a folio while it is doing this work. Commit 247e743cbe6e ("Btrfs: Use async helpers to deal with pages that have been improperly dirtied") introduced the COW fixup to catch exactly this class at writeback, way back in 2008. Since then, there have been many advances to prevent most of the causes of such re-dirtying and we thought we could get away with removing the annoying cow-fixup in the hope of simplifying writeback for large folio support. Commit b2a9f217ad3f ("btrfs: remove the COW fixup mechanism") Commit 4927b141877c ("btrfs: remove folio ordered flag and subpage bitmap") Since it turns out this assumption was incorrect, as evidenced by the report and attendant reproducers, we must reintroduce the fixup concept. This is of course critically further complicated by bs < folio_size. In that case, rather than just a folio dirty bit, we have a bitmap for the dirty blocks in the folio. And the (also broken) invariant is: I4. folio dirty IFF at least one block bitmap dirty. The original report of a stall on a misinterpreted empty bitmap is exactly evidence of a violation of I4. It is exactly because of bs < folio_size we don't want to simply revert the removal patches. The original fixup was not properly bs < folio_size aware, which motivated removal in the first place. So we wish to build a bs < folio_size aware fixup. One other important detail from the old design, any normal write that happens after a re-dirty but before a fixup is racing with the cow fixup to do the delalloc reservation, therefore it must cancel the fixup state. If it arrives after the reservation exists, it will be a normal dirty overwrite. This critically informs the design in a pretty clear way. fixup requiring re-dirty has folio granularity, while cancellation has delalloc (block) granularity so while we only ever produce fixup in chunks of folios, we must be able to clear it in blocks. Therefore we must track the blocks needing fixup at block granularity. The obvious way to do this is with a new bitmap in btrfs_folio_state, but it is desirable to avoid that if possible. Unfortunately, I don't think it is possible and the reason is subtle and leans on a sort of extreme reproducer, but I think can be explained relatively succinctly. Consider a folio whose two halves will land in different ordered extents (can be accomplished with tricks using nodatasum) and a dio read is running with it as the shared mmap destination. 1. The front half: a. folio comes clean on a normal write b. dio read completes into the folio marking it fixup. c. a write comes for the previous folio for a range extending into this folio, this is a cancellation of the fixup which reserves space. d. writeback runs on the range *not* overlapping the folio. This half remains dirty but is now covered by an OE and is awaiting writeback running on its range to be submitted and finish the OE. 2. The back half: a. the folio is part of an OE that gets far enough along to clear writeback. b. dio read completes into the folio marking it fixup. After this, the folio's front half is dirty in the "normal" sense, it needs to be submitted to the OE waiting for it. It's a cancelled fixup. Meanwhile, the second half is a true fresh fixup. So at this point if we run writeback on this folio, we genuinely can't know what to do without block level information. If we submit it, we submit unreserved dirty from the back half. If we don't, we will never finish the OE waiting for it. So it's either a corruption or a deadlock. Thus, the full high level design picture: - btrfs_data_dirty_folio(): For out of band non-reserving dirties, mark still-clean blocks inside EOF dirty and set their fixup bits (the event carries no range, so every clean block is suspect). Already-dirty blocks are covered or pending and are left alone. - Writeback: skip fixup blocks and enqueue work for them - writepage_fixup(): for each fixup block do the fixup reservation in a worker, after which the blocks can be written back normally. - Typical reserving write paths cancel fixup state for the ranges they cover with btrfs_folio_cancel_fixup() Link: https://lore.kernel.org/linux-btrfs/20260721191152.101118-1-borntraeger@linux.ibm.com/ Assisted-by: LLM Reviewed-by: Qu Wenruo Signed-off-by: Boris Burkov Signed-off-by: David Sterba commit b8228f59dc58aea06dc024efd8f64c2d048c4578 Author: Jay Vadayath Date: Fri Jul 17 11:40:19 2026 -0700 udf: bound lengthAllocDescs from unallocated space entry udf_read_inode() copies the on-disk lengthAllocDescs field of a USE (unallocSpaceEntry) inode into iinfo->i_lenAlloc without checking that it fits in the i_data buffer that is subsequently allocated for the inode. udf_count_free_table(), called from udf_statfs(), then walks the allocation descriptor array up to i_lenAlloc bytes, so a crafted UDF image with lengthAllocDescs larger than (blocksize - sizeof(struct unallocSpaceEntry)) causes udf_get_fileshortad() to read past the end of the kmalloc'd i_data buffer. KASAN report from mounting a crafted UDF image and calling statfs() from an unprivileged process: BUG: KASAN: slab-out-of-bounds in udf_get_fileshortad+0x126/0x130 Read of size 4 at addr ffff8880042137d8 by task poc/65 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x610 kasan_report+0xce/0x100 udf_get_fileshortad+0x126/0x130 udf_current_aext+0x3c4/0xa10 udf_next_aext+0x241/0x440 udf_statfs+0xb7d/0x11c0 statfs_by_dentry+0x117/0x1e0 user_statfs+0xac/0x130 __do_sys_statfs+0x80/0xe0 do_syscall_64+0x102/0x5a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reject USE inodes whose lengthAllocDescs would place descriptors past the end of the i_data buffer, mirroring the checks the rest of the UDF code performs on descriptor lengths. This bug was discovered by Artiphishell's vTriage pipeline, which generated a userspace reproducer that reliably triggers the KASAN report on an unpatched kernel. The fix below was drafted with the Claude coding assistant; a userspace reproducer (and the crafted UDF image) is available on request. Assisted-by: LLM Signed-off-by: Jay Vadayath Link: https://patch.msgid.link/20260717184021.13476-1-jay@artiphishell.com Signed-off-by: Jan Kara commit 6c732471740bc2ac9b0946134f9f551dc75f4369 Author: David Lee Date: Wed Jul 1 11:44:28 2026 +0000 fhandle: reject detached mounts in capable_wrt_mount() The recent fhandle RCU fix moved the mount namespace capability check into capable_wrt_mount(), so a non-NULL mnt_namespace survives the ns_capable() dereference. The helper still assumes the later READ_ONCE(mount->mnt_ns) must be non-NULL because may_decode_fh() checked is_mounted() first. That assumption is not stable. A detached mount from open_tree(..., OPEN_TREE_CLONE) can be dissolved on fput while open_by_handle_at() is between those checks, and umount_tree() can clear mount->mnt_ns. If the helper observes NULL, it dereferences mnt_ns->user_ns and panics. Return false when the RCU read observes a detached mount. This keeps the relaxed permission path conservative: a mount no longer attached to a namespace cannot authorize open_by_handle_at() access. Fixes: 620c266f3949 ("fhandle: relax open_by_handle_at() permission checks") Cc: stable@vger.kernel.org Signed-off-by: David Lee Assisted-by: LLM Link: https://patch.msgid.link/20260701114438.24431-1-david.lee@trailofbits.com Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner (Amutable) commit a380b9693c7a005806a7bf901f4a2be8b4395249 Author: Jori Koolstra Date: Tue Jun 30 12:54:00 2026 +0200 ntfs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in ntfs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-32-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 0ddd31b242644973514966d26fe07313aa7e83c8 Author: Jori Koolstra Date: Tue Jun 30 12:53:59 2026 +0200 xfs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in xfs_vn_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-31-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 2a58d0e0f070c05955dc21f49962ae449c272b0c Author: Jori Koolstra Date: Tue Jun 30 12:53:58 2026 +0200 ubifs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in ubifs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-30-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 0b83c6b36075cc6d157a073a31738a945c0f629f Author: Jori Koolstra Date: Tue Jun 30 12:53:57 2026 +0200 nfs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in nfs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-29-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 384de989eba9ff12925fcc8d0bbf316a0c272a8b Author: Jori Koolstra Date: Tue Jun 30 12:53:56 2026 +0200 ufs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in ufs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-28-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 30638fe73a3aad4e5545e2c843f20bcfa2be9272 Author: Jori Koolstra Date: Tue Jun 30 12:53:55 2026 +0200 udf: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in udf_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-27-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) commit 0ffe991d6ccc6787f68c5ddecc4c13eb4bd0fe4a Author: Jori Koolstra Date: Tue Jun 30 12:53:54 2026 +0200 ramfs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in ramfs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-26-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) commit 2eab03836e641cd47b8691b25664f8195ae74538 Author: Jori Koolstra Date: Tue Jun 30 12:53:53 2026 +0200 orangefs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in orangefs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-25-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 38d8af9d314da7952f6876a2f5e07fa79bb1c459 Author: Jori Koolstra Date: Tue Jun 30 12:53:52 2026 +0200 omfs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in omfs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-24-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 8f1b4d14e9fc0110b4a22c7dfbc9d3dde6cb60df Author: Jori Koolstra Date: Tue Jun 30 12:53:51 2026 +0200 ocfs2: dlmfs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in dlmfs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-23-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) commit 6caf971bc5e59276679d8fec5d791ab4ff0db702 Author: Jori Koolstra Date: Tue Jun 30 12:53:50 2026 +0200 ocfs2: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in ocfs2_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-22-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) commit bcf69800f9a5599b85b2fc6c3eecfe75bd185597 Author: Jori Koolstra Date: Tue Jun 30 12:53:49 2026 +0200 ntfs3: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in ntfs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-21-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 428475b82a4da0dbd5c0091718e059ff85b322a7 Author: Jori Koolstra Date: Tue Jun 30 12:53:48 2026 +0200 nilfs2: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in nilfs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-20-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 1ab6211652b42f1a06ddd2beb55cd346cb353268 Author: Jori Koolstra Date: Tue Jun 30 12:53:47 2026 +0200 minix: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in minix_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-19-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) commit 557a11939f2838996082763e5ae8c959bfe94128 Author: Jori Koolstra Date: Tue Jun 30 12:53:46 2026 +0200 jfs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in jfs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-18-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 950c8f79547c9331f56dfb7fe06f70ee861e49bc Author: Jori Koolstra Date: Tue Jun 30 12:53:45 2026 +0200 jffs2: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in jffs2_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-17-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 73c6af95575933388ecd2149816dfaa0185a5f59 Author: Jori Koolstra Date: Tue Jun 30 12:53:44 2026 +0200 hugetlbfs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in hugetlbfs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-16-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 9c8ef28c0ccac3749ac4669309b6af26099098c3 Author: Jori Koolstra Date: Tue Jun 30 12:53:43 2026 +0200 hpfs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in hpfs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-15-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit b27e20b4475af6f0d839badec9648b5587c8dffd Author: Jori Koolstra Date: Tue Jun 30 12:53:42 2026 +0200 hfsplus: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in hfsplus_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-14-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit b93efaa9aa9020349615f0791bf873997bd2e65d Author: Jori Koolstra Date: Tue Jun 30 12:53:41 2026 +0200 hfs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in hfs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-13-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 3d4e1570fff50c19d7b75584813589769c58642d Author: Jori Koolstra Date: Tue Jun 30 12:53:40 2026 +0200 gfs2: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in gfs2_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-12-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit e88c34c35bc18f1c9a74233b8b77e6cbd6ee7167 Author: Jori Koolstra Date: Tue Jun 30 12:53:39 2026 +0200 f2fs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in f2fs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-11-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit dc5419ffdb80a16b782da8ab208df2da7bd15691 Author: Jori Koolstra Date: Tue Jun 30 12:53:38 2026 +0200 ext4: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in ext4_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-10-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) commit 3a48f5f81af24fbf2fb5c540cb0cd1826445408a Author: Jori Koolstra Date: Tue Jun 30 12:53:37 2026 +0200 ext2: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in ext2_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-9-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) commit 5c39d53bf5c3967b1b64ea310ddd1d42a8cc365e Author: Jori Koolstra Date: Tue Jun 30 12:53:36 2026 +0200 ceph: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in ceph_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-8-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit e6e3cc72f46aa328a806603f1ed56c99c9faa654 Author: Jori Koolstra Date: Tue Jun 30 12:53:35 2026 +0200 btrfs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in btrfs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-7-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 2c04cc9c4958cf016a5993c6990ddff59d737ec0 Author: Jori Koolstra Date: Tue Jun 30 12:53:34 2026 +0200 autofs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in autofs_dir_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-6-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit b16f5529c63735ee29e9982c37b26b18d48f0696 Author: Jori Koolstra Date: Tue Jun 30 12:53:33 2026 +0200 afs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in afs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-5-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit c8ba66ee6028e7f45b9b2161276e1f76bd304c93 Author: Jori Koolstra Date: Tue Jun 30 12:53:32 2026 +0200 affs: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in affs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-4-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 015a1f57507932b6bbc0a1453e4962fda441f9ff Author: Jori Koolstra Date: Tue Jun 30 12:53:31 2026 +0200 9p: drop redundant S_IFDIR from mkdir vfs_mkdir() now sets the S_IFDIR type bit in the mode it passes to ->mkdir(), so OR-ing S_IFDIR into the mode again in v9fs_vfs_mkdir() is redundant. Drop it. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-3-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Signed-off-by: Christian Brauner (Amutable) commit 2f3a7a488cf289d0af85a3ba62c1393c52d7b83d Author: Jori Koolstra Date: Tue Jun 30 12:53:30 2026 +0200 vfs: pass S_IFDIR mode to vfs_prepare_mode() There is a comment in vfs_prepare_mode() that says: Note that it's currently valid for @type to be 0 if a directory is created. Filesystems raise that flag individually and we need to check whether each filesystem can deal with receiving S_IFDIR from the vfs before we enforce a non-zero type. It is safe to do this clean-up except that three filesystems (fuse, cifs, and coda) forward the mkdir @mode unchanged to something outside the kernel. Mask S_IFDIR back out in coda_mkdir(), fuse_mkdir() and cifs_mkdir() so that what is sent outside the kernel is unchanged. Their maintainers can drop the mask once they have confirmed it is safe. Assisted-by: LLM Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260630105400.68459-2-jkoolstra@xs4all.nl Reviewed-by: NeilBrown Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable)