summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-04rust: sync: Use safe synchronize_rcu() abstraction in pollPhilipp Stanner
We now have a safe wrapper for the foreign function synchronize_rcu(). Use it in poll.rs. Signed-off-by: Philipp Stanner <phasta@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Onur Özkan <work@onurozkan.dev> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Boqun Feng <boqun@kernel.org> Link: https://patch.msgid.link/20260624150704.1504001-5-phasta@kernel.org
2026-08-04rust: revocable: Use safe synchronize_rcu() abstractionPhilipp Stanner
We now have a safe wrapper for the foreign function synchronize_rcu(). Use it in revocable.rs. Signed-off-by: Philipp Stanner <phasta@kernel.org> Reviewed-by: Onur Özkan <work@onurozkan.dev> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Boqun Feng <boqun@kernel.org> Link: https://patch.msgid.link/20260624150704.1504001-4-phasta@kernel.org
2026-08-04rust: sync: Add abstraction for synchronize_rcu()Philipp Stanner
synchronize_rcu() is a frequently used C function which is always safe to be called. Add a safe abstraction for synchronize_rcu(). Signed-off-by: Philipp Stanner <phasta@kernel.org> Reviewed-by: Onur Özkan <work@onurozkan.dev> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> [boqun: Fix rustdoc reported by kernel test robot <lkp@intel.com>] Signed-off-by: Boqun Feng <boqun@kernel.org> Link: https://patch.msgid.link/20260624150704.1504001-3-phasta@kernel.org
2026-08-04spi: Add support for StarFive JHB100 SFCMark Brown
Changhuang Liang <changhuang.liang@starfivetech.com> says: This serial add support for the StarFive JHB100 SoC SPI Flash Controller (SFC), which is based on the Synopsys DesignWare SSI version 2.00a but with some customizations and it also add enhanced SPI for DesignWare SPI controllers. I picked up some patches from series [1]. This series depends on the series [2]: [1] https://lore.kernel.org/all/20221212180732.79167-1-sudip.mukherjee@sifive.com/ [2] https://lore.kernel.org/all/20260521012932.24163-1-changhuang.liang@starfivetech.com/ v1: https://lore.kernel.org/all/20260709055204.138168-1-changhuang.liang@starfivetech.com/ Link: https://patch.msgid.link/20260803124044.156998-1-changhuang.liang@starfivetech.com
2026-08-04spi: dw: Add support for StarFive JHB100 SoC SFCChanghuang Liang
Add support for the StarFive JHB100 SoC SPI Flash Controller (SFC), which is based on the Synopsys DesignWare SSI version 2.00a but with some customizations. The JHB100 SFC controller has the following special features: 1. Separate registers for instruction and address (DW_SPI_JHB100_INST and DW_SPI_JHB100_ADDR) instead of using the common data register. 2. A filter interrupt mask register (DW_SPI_JHB100_FILTER_IMR), which is default masked to disable filter interrupts as they are not used. 3. Requires a system controller phandle "starfive,sfc-filter-syscon" to configure 3-byte/4-byte address mode switching per chip select. 4. Different Set CS and Enable Controller Timing. A new quirk flag DW_SPI_QUIRK_JHB100 is introduced to handle these differences in the enhanced SPI memory operation path. The controller uses the HSSI initialization path (DW_HSSI_ID) and shares the same interrupt masking logic. Limit the JHB100 SFC address to 3-byte or 4-byte length. Additionally, the platform_suspend() and platform_resume() callbacks are introduced to handle platform-private suspend/resume procedures. Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> Link: https://patch.msgid.link/20260803124044.156998-12-changhuang.liang@starfivetech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-04spi: dt-bindings: snps,dw-apb-ssi: Add starfive,jhb100-sfcChanghuang Liang
Add a new compatible string "starfive,jhb100-sfc" for the StarFive JHB100 SPI Flash Controller, it based on the Synopsys DesignWare SSI version 2.00a but with minor modifications. Due to these minor modifications, it only supports access for flash memory and requires a system controller register to configure the address mode filter for SPI NOR flash devices. The starfive,sfc-filter-syscon property is required to provide a phandle to the system controller that manages switching between 3-byte and 4-byte addressing modes, essential for supporting SPI NOR flash devices with different address width requirements. Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260803124044.156998-11-changhuang.liang@starfivetech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-04spi: dw: detect enhanced spi modeSudip Mukherjee
All the SSI controllers supporting enhanced spi modes might not support all the three dual or quad or octal modes. Detect the modes that are supported and finally enable the DW_SPI_CAP_EMODE capability which will start using all the enhanced spi functions that has been added. Signed-off-by: Sudip Mukherjee <sudip.mukherjee@sifive.com> Co-developed-by: Changhuang Liang <changhuang.liang@starfivetech.com> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> Link: https://patch.msgid.link/20260803124044.156998-10-changhuang.liang@starfivetech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-04spi: dw: use irq handler for enhanced spiSudip Mukherjee
Introduce the interrupt handler for enhanced spi to read or write based on the generated irq. Also, use the xfer_completion from spi_controller to wait for a timeout or completion from irq handler. In enhanced mode we need to calculate RXFTLR based on the length of data we are expecting to receive or the fifo length. Signed-off-by: Sudip Mukherjee <sudip.mukherjee@sifive.com> Co-developed-by: Changhuang Liang <changhuang.liang@starfivetech.com> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> Link: https://patch.msgid.link/20260803124044.156998-9-changhuang.liang@starfivetech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-04spi: dw: send cmd and addr to start the spi transferSudip Mukherjee
In enhanced spi mode, read or write will start by sending the cmd and address (if present). Signed-off-by: Sudip Mukherjee <sudip.mukherjee@sifive.com> Co-developed-by: Changhuang Liang <changhuang.liang@starfivetech.com> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> Link: https://patch.msgid.link/20260803124044.156998-8-changhuang.liang@starfivetech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-04spi: dw: Introduce enhanced single/dual/quad/octal spiSudip Mukherjee
If the spi transfer is using enhanced single/dual/quad/octal spi mode, then we need to update the SPI_CTRLR0 register. The SPI_CTRLR0 register will be updated in dw_spi_update_config() via the values in dw_spi_enh_cfg. Signed-off-by: Sudip Mukherjee <sudip.mukherjee@sifive.com> Co-developed-by: Changhuang Liang <changhuang.liang@starfivetech.com> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> Link: https://patch.msgid.link/20260803124044.156998-7-changhuang.liang@starfivetech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-04spi: dw: update NDF while using enhanced spi modeSudip Mukherjee
If the transfer of Transmit only mode is using enhanced SPI then NDF needs to be updated with the number of data frames. If the Transmit FIFO goes empty in-between, DWC_ssi masks the serial clock and wait for rest of the data until the programmed amount of frames are transferred successfully. In receive mode, the number of data frames received is equal to this register value plus 1. In transmit mode, the number of data frames is equal this register value. Signed-off-by: Sudip Mukherjee <sudip.mukherjee@sifive.com> Co-developed-by: Changhuang Liang <changhuang.liang@starfivetech.com> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> Link: https://patch.msgid.link/20260803124044.156998-6-changhuang.liang@starfivetech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-04spi: dw: adjust size of mem_opSudip Mukherjee
In enhanced mode adjust the size of the data that can be sent or received as this will then be used to set the NDF. Signed-off-by: Sudip Mukherjee <sudip.mukherjee@sifive.com> Co-developed-by: Changhuang Liang <changhuang.liang@starfivetech.com> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> Link: https://patch.msgid.link/20260803124044.156998-5-changhuang.liang@starfivetech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-04spi: dw: add check for support of enhanced spiSudip Mukherjee
Before doing the mem op, spi controller will be queried about the buswidths it supports. Add the single/dual/quad/octal if the controller has the DW_SPI_CAP_EMODE capability. The DW_SPI_CAP_EMODE capability will be enabled in a later patch. Signed-off-by: Sudip Mukherjee <sudip.mukherjee@sifive.com> Co-developed-by: Changhuang Liang <changhuang.liang@starfivetech.com> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> Link: https://patch.msgid.link/20260803124044.156998-4-changhuang.liang@starfivetech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-04spi: dw: update SPI_CTRLR0 registerSudip Mukherjee
If the SPI transfer is being done in enhanced mode then SPI_CTRLR0 register needs to be updated to mention the instruction length, address length, address and instruction transfer format, wait cycles. And, we also need to enable clock stretching. Signed-off-by: Sudip Mukherjee <sudip.mukherjee@sifive.com> Co-developed-by: Changhuang Liang <changhuang.liang@starfivetech.com> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> Link: https://patch.msgid.link/20260803124044.156998-3-changhuang.liang@starfivetech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-04spi: dw: Introduce spi_frf and STD_SPISudip Mukherjee
The DW APB SSI controllers of v4.x and newer and DW AHB SSI controllers supports enhanced SPI modes which can be defined from SPI_FRF of DW_SPI_CTRLR0 register. Without enhanced mode, these controllers will work in the standard spi mode. Signed-off-by: Sudip Mukherjee <sudip.mukherjee@sifive.com> Co-developed-by: Changhuang Liang <changhuang.liang@starfivetech.com> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> Link: https://patch.msgid.link/20260803124044.156998-2-changhuang.liang@starfivetech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-04dt-bindings: mmc: sunxi: add compatible string for Allwinner A733 MMC0/1/2Jerome Brunet
The A733 MMC0/1/2 controllers are compatible with the D1 ones. Add an A733-specific compatible string, with the D1 as fallback. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-04dt-bindings: mmc: Document fixed-layout NVMEM provider supportLoic Poulain
Allow an eMMC hardware partition node to describe an NVMEM layout so the partition can be exposed as an NVMEM provider. This lets a partition (e.g. an eMMC boot partition) store device-specific information such as a WiFi MAC address or a Bluetooth BD address and reference it through NVMEM cells. Accept "fixed-layout" as the partition node compatible, in addition to "fixed-partitions", so the layout can be described directly on the partition node. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-04mmc: sdhci: unmap the bounce buffer before device releaseMyeonghun Pak
sdhci_allocate_bounce_buffer() allocates its buffer with devm_kmalloc() but maps it with dma_map_single(). The buffer is therefore released by devres without the streaming DMA mapping being unmapped. Register a managed action after dma_map_single() succeeds so the mapping is removed before devres releases the buffer. The action is registered only for buffers allocated and mapped by the SDHCI core, leaving buffers provided by host drivers under their existing ownership. Fixes: bd9b902798ab ("mmc: sdhci: Implement an SDHCI-specific bounce buffer") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-04mmc: sdhci: make tuning_err a signed intHaibo Chen
Coverity report INTEGER_OVERFLOW for host->tuning_err. The tuning_err field in struct sdhci_host is used to store an error code for re-tuning, but it was declared as unsigned int. Several call sites store negative error codes into it and later compare against negative values: - sdhci.c, sdhci-of-dwcmshc.c and sdhci-pci-gli.c assign it the return value of __sdhci_execute_tuning()/__sdhci_execute_tuning_9750(), both of which return a signed int (possibly a negative errno); - sdhci-of-esdhc.c assigns host->tuning_err = -EAGAIN and later does "ret = host->tuning_err; if (ret == -EAGAIN ...)"; - sdhci-of-dwcmshc.c prints it with the %d (signed) conversion. Storing a negative errno in an unsigned int and reading it back as a signed int only happens to work because of two's-complement, same-width integer conversions. It is misleading and triggers sign-conversion warnings. All users treat the value either as a signed error code or as a boolean (zero / non-zero), so changing the type to a signed int is safe and makes the intent explicit. Fixes: 7d8bb1f46e13 ("mmc: sdhci: add tuning error codes") Assisted-by: Cline:claude-sonnet [read_file, search_files, git] Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-04ALSA: hda/core: Log stream DMA errors on interruptArun Raghavan
The stream descriptor status register reports FIFO and descriptor errors, but these are currently cleared silently along with the rest of the interrupt status. Log them, rate-limited, so DMA problems are visible instead of only manifesting as audible glitches. Observed on some AMD GPU HDMI audio controllers under specific low power circumstances. Signed-off-by: Arun Raghavan <arunr@valvesoftware.com> Cc: Arun Raghavan <arun@arunraghavan.net> Link: https://patch.msgid.link/20260803-master-v1-1-9bcedb736978@valvesoftware.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-08-04drm/omap: dsi: Do not copy isr tableAndreas Kemnade
To be able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table. Fixes: 4ae2ddddf44cd ("OMAP: DSS2: DSI: Add ISR support") Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://patch.msgid.link/20260702-dsi-uaf-v2-1-dbb4aa0f0b8e@kemnade.info Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-08-04net/openvswitch: check Ethernet header length in key_extract()Cen Zhang (Microsoft)
When a packet arrives on an ARPHRD_NONE device (e.g. TUN), ovs_flow_key_extract() trusts the user-provided skb->protocol field: if it is ETH_P_TEB, the packet is classified as MAC_PROTO_ETHERNET and key_extract() is called without ensuring the skb has ETH_HLEN (14) bytes of linear data. key_extract() unconditionally pulls 2 * ETH_ALEN bytes for MAC addresses and parse_ethertype() pulls 2 more, either of which triggers a kernel BUG in __skb_pull() when the linear area is too small. kernel BUG at include/linux/skbuff.h:2848! RIP: 0010:key_extract+0xa7e/0xd90 net/openvswitch/flow.c:933 ovs_flow_key_extract+0x419/0xa70 ovs_vport_receive+0x222/0x390 netdev_frame_hook+0x3e0/0x630 tun_get_user+0x2d0c/0x38e0 Fixed by calling check_header() in key_extract() before accessing the Ethernet header. Fixes: 217ac77a3c25 ("openvswitch: allow L3 netdev ports") Reported-by: AutonomousCodeSecurity@microsoft.com Reviewed-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com> Reviewed-by: Ilya Maximets <i.maximets@ovn.org> Link: https://patch.msgid.link/20260730222006.118652-1-blbllhy@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-04mm/slab, kfence, memcg: completely remove obj_ext for kfence objectsVlastimil Babka (SUSE)
We have already disabled memory allocation profiling for objects allocated for KFENCE to avoid complexity. KFENCE allocations are rare and there can be only CONFIG_KFENCE_NUM_OBJECTS (default to 255) outstanding ones at any time, so they are among noise in the profiling stats. For the same reasons, we can stop memcg_kmem accounting of kfence objects as their memory usage will be negligible wrt any practical memcg limits. This allows us simplifying the code and getting rid of is_kfence_address() checks in various places, including slab_obj_ext()'s usage of obj_to_index(). Instead we rely on the fact that slab_obj_exts() will now always return 0 for a kfence object's fake slab, which makes those places unreachable. All we need to do to keep this assumption valid is not to allocate obj_exts for kfence objects, so the checks need to guard alloc_slab_obj_exts() where necessary. Suggested-by: Harry Yoo <harry@kernel.org> Link: https://patch.msgid.link/20260727-b4-objext_split-v3-13-c29ef0f1f257@kernel.org Reviewed-by: Hao Li <hao.li@linux.dev> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-08-04futex: Avoid private hash use-after-free on final putFelix Hoffmann
futex_private_hash_put() drops the reference to fph before evaluating fph->mm for wake_up_var(). futex_ref_put() enables preemption again before returning. If that put drops the final reference and the task is preempted, another task can pivot to the replacement hash and free the old hash after an RCU grace period. The first task then reads fph->mm from the freed allocation when it resumes. KASAN reports a slab-use-after-free in futex_private_hash_put(), with the read at offset 24 in a freed kmalloc-512 allocation. The allocation and free stacks point to futex_hash_allocate() and the RCU free path, respectively. Load the mm pointer while the fph reference is still held and pass the saved value to wake_up_var(). wake_up_var() uses the pointer as a waitqueue key and does not dereference the mm through it. Fixes: bd54df5ea7ca ("futex: Allow to resize the private local hash") Signed-off-by: Felix Hoffmann <f3lix.dev@gmx.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260731155024.1150011-1-f3lix.dev@gmx.de
2026-08-04riscv/runtime-const: Disable linker relaxation for RUNTIME_MAGICFangrui Song
Commit ee10b1028129 ("riscv/runtime-const: Replace open-coded placeholder with RUNTIME_MAGIC") switched the lui + addi[w] placeholder from hand-encoded immediates to %hi()/%lo() of RUNTIME_MAGIC. GNU Assembler folds %hi()/%lo() of an absolute expression at assembly time. LLVM's integrated assembler since 21.1 defers it to the linker instead, which range checks it: on riscv64 R_RISCV_HI20 must fit a signed 20-bit field, and RUNTIME_MAGIC (0x89ABCDEF) is a positive 64-bit value rather than a sign-extended 32-bit one, so it does not: ld.lld: error: relocation R_RISCV_HI20 out of range: 563901 is not in [-524288, 524287] The sequence is patched at runtime and its instruction offsets are recorded via ".long 1b - .", so the linker must not touch it in the first place. Add ".option norelax", as is already done for ALTERNATIVE() and static keys; the integrated assembler then resolves %hi()/%lo() itself and emits no relocation, restoring the exact encoding the open-coded placeholder produced. Fixes: ee10b1028129 ("riscv/runtime-const: Replace open-coded placeholder with RUNTIME_MAGIC") Closes: https://github.com/ClangBuiltLinux/linux/issues/2179 Reported-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Fangrui Song <i@maskray.me> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260802174342.597092-1-i@maskray.me
2026-08-04mm/slab: stop allocating objcg pointers when unnecessaryVlastimil Babka (SUSE)
Start using the slab_needs_objcg() helper to calculate slabobj_ext size. Caches that we know to never need objcg pointers (currently KMALLOC_NORMAL caches) will thus stop wasting memory on them when memory allocation profiling is enabled. For things to work properly, we need to also add slab_needs_objcg() checks to mem_cgroup_from_obj_slab() and memcg_slab_free_hook(), because when obj_exts array exists for a slab only due to mem_alloc profiling, we would otherwise attempt to access a non-existing objcg pointer in that slab. In slab_obj_ext_[set_]objcg() add debug warnings if called on a slab where slab_needs_objcg() is false. Reviewed-by: Hao Li <hao.li@linux.dev> Link: https://patch.msgid.link/20260727-b4-objext_split-v3-12-c29ef0f1f257@kernel.org Reviewed-by: Harry Yoo <harry@kernel.org> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-08-04mm/slab: add cache_ and slab_needs_objcg() helpersVlastimil Babka (SUSE)
Slabs of some caches never need the objcg part of struct slabobj_ext. Introduce helpers to query this for a cache or a slab. Introduce SLAB_MAY_ACCOUNT flag that is currently only internal and all caches have it set except: - KMALLOC_NORMAL caches, as long as KMALLOC_RECLAIM caches are separate - KMALLOC_NO_OBJ_EXT caches, if they exist For named caches we currently can't derive SLAB_MAY_ACCOUNT from SLAB_ACCOUNT because some caches might be created without SLAB_ACCOUNT and then used both with and without __GFP_ACCOUNT concurrently, allocating obj_ext arrays on demand. So just add the SLAB_MAY_ACCOUNT to all kmem caches, unless kmem accounting is disabled. This can be improved later by finding out all caches used with __GFP_ACCOUNT, creating them with the SLAB_MAY_ACCOUNT flag explicitly, and then ignoring __GFP_ACCOUNT for all other caches (possibly with a warning). To make the evaluation of slab_needs_objcg() faster in the allocation and free fast paths, add a obj_exts_needs_objcg flag into slab itself. This optimization is only available on 64bit architectures where free bits are available for the flag. Reviewed-by: Hao Li <hao.li@linux.dev> Link: https://patch.msgid.link/20260727-b4-objext_split-v3-11-c29ef0f1f257@kernel.org Reviewed-by: Harry Yoo <harry@kernel.org> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-08-04mm/slab: stop exporting kvfree_rcu_barrier[_on_cache]()Vlastimil Babka (SUSE)
No module code calls these functions directly. Seems it was always the case. Remove the exports. Acked-by: Paul E. McKenney <paulmck@kernel.org> Reviewed-by: Harry Yoo <harry@kernel.org> Link: https://patch.msgid.link/20260730-unexport-barriers-v1-1-852f6641abe9@kernel.org Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-08-04slub_kunit: extend the test for kfree_rcu_nolock()Harry Yoo (Oracle)
When slub_kunit is not built-in, call kfree_rcu() and kfree_rcu_nolock() to test kfree_rcu_nolock() in slub_kunit. Rename the test case as the test covers more _nolock() APIs. Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Signed-off-by: Harry Yoo (Oracle) <harry@kernel.org> Link: https://patch.msgid.link/20260729-kfree_rcu_nolock-v5-8-a28cdcda9673@kernel.org Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-08-04mm/slab: introduce kfree_rcu_nolock()Harry Yoo (Oracle)
Currently, k[v]free_rcu() cannot be called in unknown context since it could lead to a deadlock when called in the middle of k[v]free_rcu(). Make users' lives easier by introducing kfree_rcu_nolock() variant, now that kfree_rcu_sheaf() is available on PREEMPT_RT and __kfree_rcu_sheaf() handles unknown context. When sheaves path fails, kfree_rcu_nolock() falls back to defer_kfree_rcu() that uses an irq work to free the object via kvfree_call_rcu(). In most cases, the sheaves path is expected to succeed and therefore it's unnecessary to introduce additional complexity to the existing kvfree_rcu batching by teaching it how to handle unknown context. Since defer_kfree_rcu() can be called on caches without sheaves, move deferred_work_barrier() and rcu_barrier() outside the branch in kvfree_rcu_barrier_on_cache(). Now that deferred kvfree_rcu objects are submitted to kvfree_call_rcu() after deferred_work_barrier() and may end up in RCU sheaves, deferred_work_barrier() must be invoked before flush_rcu_sheaves_on_cache(). Since the RCU sheaf path has not been used on !KVFREE_RCU_BATCHED kernels, always fall back when kvfree_rcu() is not batched, for consistency. kvfree_rcu_barrier{,_on_cache()}() on !KVFREE_RCU_BATCHED are moved to mm/slab_common.c to invoke deferred_work_barrier() before rcu_barrier(). Signed-off-by: Harry Yoo (Oracle) <harry@kernel.org> Link: https://patch.msgid.link/20260729-kfree_rcu_nolock-v5-7-a28cdcda9673@kernel.org Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-08-04mm/slab: introduce struct kvfree_rcu_head for kvfree_rcu batchingHarry Yoo (Oracle)
rcu_head is overkill for kvfree_rcu() because the callback function is always either kfree(), vfree(), or free_large_kmalloc(), and thus there is no need for a function pointer. kvfree_rcu batching reuses the field to store the start address of an object, however, this is not strictly needed because we can calculate the start address in the slowpath. For the purpose of kvfree_rcu batching, it is sufficient to implement a linked list using a single pointer. Introduce a new struct called kvfree_rcu_head (the name was suggested by Vlastimil Babka), which is similar to rcu_head but is only a single pointer to build a linked list, without a function pointer, when CONFIG_KVFREE_RCU_BATCHED=y. When kvfree_rcu is not batched, kvfree_rcu_head is the same size as rcu_head. Note that shrinking struct kvfree_rcu_head on CONFIG_KVFREE_RCU_BATCHED=n kernels would inevitably require additional complexity and also some sort of batching (which defeats the purpose of the config option) because it cannot fall back to call_rcu(). For now there are no user-visible changes to the API. k[v]free_rcu() simply casts rcu_head to kvfree_rcu_head. While this does not affect the API, it allows kfree_rcu_nolock() to reuse kvfree_rcu batching as a fallback when trylock or sheaf allocation fails. Stop storing the object pointer in rcu_head.func and instead calculate the object's start address in kvfree_rcu_list(). Factor out the existing logic to calculate the start address from kvfree_rcu_cb() to kvmalloc_obj_start_addr(). To avoid losing the KASAN tag, calculate the offset and subtract it from the address of the kvfree_rcu_head. Signed-off-by: Harry Yoo (Oracle) <harry@kernel.org> Link: https://patch.msgid.link/20260729-kfree_rcu_nolock-v5-6-a28cdcda9673@kernel.org Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-08-04arm64: dts: sophgo: add initial Milk-V Duo S board supportJoshua Milas
Adds initial arm64 support for the Milk-V Duo S board [1] making it possible to boot Linux to the command line. Link: https://milkv.io/duo-s [1] Signed-off-by: Joshua Milas <josh.milas@gmail.com> Link: https://milkv.io/duo-s [1] Link: https://patch.msgid.link/20260615120324.1527881-2-josh.milas@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> # Trim empty line Signed-off-by: Chen Wang <chen.wang@linux.dev>
2026-08-04riscv: dts: sophgo: Add Milk-V Duo 256M board supportChen-Yu Yeh
The Milk-V Duo 256M is a small form factor development board based on the Sophgo SG2002 SoC. This patch adds basic device tree support for the board, including: - UART console - SD/MMC controller - USB host - Onboard blue status LED (connected to PWR_GPIO[2] / porte 2) Tested on actual Milk-V Duo 256M hardware, verified boot to shell and heartbeat LED functionality. Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com> Link: https://patch.msgid.link/20260725175346.139173-4-chenyou910331@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <chen.wang@linux.dev>
2026-08-04riscv: dts: sophgo: cv180x: Add PWR_GPIO controllerChen-Yu Yeh
The CV180x/CV181x family has an additional DesignWare APB GPIO controller (PWR_GPIO) located in the always-on power domain at 0x5021000. Add the node so that boards can reference GPIOs in this bank, such as status LEDs. Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com> Link: https://patch.msgid.link/20260725175346.139173-3-chenyou910331@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <chen.wang@linux.dev>
2026-08-04dt-bindings: soc: sophgo: add Milk-V Duo 256M boardChen-Yu Yeh
Add compatible string for the Milk-V Duo 256M board. Signed-off-by: Chen-Yu Yeh <chenyou910331@gmail.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260725175346.139173-2-chenyou910331@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <chen.wang@linux.dev>
2026-08-04riscv64: dts: sophgo: add initial Milk-V Duo S board supportJoshua Milas
This adds initial riscv support for the Milk-V Duo S board [1] making it possible to boot Linux to the command line. Link: https://milkv.io/duo-s [1] Signed-off-by: Joshua Milas <josh.milas@gmail.com> Link: https://milkv.io/duo-s [1] Link: https://patch.msgid.link/20260615120324.1527881-4-josh.milas@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> # Trim empty line Signed-off-by: Chen Wang <chen.wang@linux.dev>
2026-08-04riscv64: dts: sophgo: add SG2000 dtsiJoshua Milas
Adds sg2000.dtsi on the RISCV side. Signed-off-by: Joshua Milas <josh.milas@gmail.com> Tested-by: Gui-Dong Han <hanguidong02@gmail.com> Reviewed-by: Gui-Dong Han <hanguidong02@gmail.com> Link: https://patch.msgid.link/20260615120324.1527881-3-josh.milas@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <chen.wang@linux.dev>
2026-08-04riscv: dts: sophgo: cv180x: Allow the DMA multiplexer to set channel number ↵Inochi Amaoto
for DMA controller Change the DMA controller compatible to the sophgo,cv1800b-axi-dma, which supports setting DMA channel number in DMA phandle args. This dts change does not break backward compatibility as a fallback compatiable string is added. Fixes: 514951a81a5e ("riscv: dts: sophgo: cv18xx: add DMA controller") Reported-by: Anton D. Stavinskii <stavinsky@gmail.com> Closes: https://github.com/sophgo/linux/issues/9 Tested-by: Anton D. Stavinskii <stavinsky@gmail.com> Link: https://patch.msgid.link/20260511063818.463877-3-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <chen.wang@linux.dev>
2026-08-04ata: use named initializers for acpi_device_idPawel Zalewski (The Capable Hub)
Use a named initializer for the acpi_device_id fields which makes the code more readable and consistent with how lists are initialized in the rest of the kernel code base. Also drop explicitly setting fields to 0 where it is redundant. While we are at it - unify the list terminator to have a single space between the brackets and no trailing comma. Signed-off-by: Pawel Zalewski (The Capable Hub) <pzalewski@thegoodpenguin.co.uk> Reviewed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2026-08-04packet: synchronize pressure clearing with ring reconfigurationZihan Xi
packet_set_ring() updates the RX ring state under sk_receive_queue.lock, but used to publish the tpacket receive mode through po->prot_hook.func after releasing that lock. packet_poll() and packet_recvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage. Move the existing receive hook assignment into the same sk_receive_queue.lock section as the ring state update. Keep the assignment otherwise unchanged, including on TX ring reconfiguration, to avoid adding behavior changes that are not required for the fix. Serialize packet_recvmsg() pressure clearing with the same queue lock only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear and the socket has moved away from tpacket_rcv, packet_set_ring() has already detached the socket and waited for synchronize_net(), so no new packet input can set the flag again. packet_poll() already holds sk_receive_queue.lock, so it uses the new unlocked helper directly. Fixes: 2ccdbaa6d55b ("packet: rollover lock contention avoidance") Cc: stable@vger.kernel.org Reported-by: Vega <vega@nebusec.ai> Assisted-by: Codex:gpt-5.4 Signed-off-by: Zihan Xi <zihanx@nebusec.ai> Link: https://patch.msgid.link/f90b5688311fa278d1361ea8c6be0bf25967d591.1785247446.git.zihanx@nebusec.ai Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-04fpga: dfl: fix spelling in sysfs-platform-dfl-port ABI documentationAyananta Paul
Correct the spelling of "responding" which was incorrectly written as "respoding" in the Document/ABI/testing/sysfs-platform-dfl-port ABI testing file. Issue identified using: `codespell -D - -S "*.bin,*.o,*.a,*.so,*.ko,*.gz,*.png,*.jpg" Documentation/` Signed-off-by: Ayananta Paul <ayanantapaul@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Xu Yilun <yilun.xu@intel.com> Link: https://lore.kernel.org/r/20260727152634.5983-1-ayanantapaul@gmail.com Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
2026-08-04fpga: altera-cvp: Avoid out-of-bounds read in trailing byte writeDaisuke Matsuda
The trailing byte path in altera_cvp_send_block() dereferences a u32 pointer even when only 1-3 bytes remain in the input buffer. If the buffer ends at a page or scatterlist boundary, this can read past the valid image data and fault. Copy the remaining bytes into a zero-initialized u32 before writing the final word so only valid bytes are read from the input buffer. Fixes: 34d1dc17ce97 ("fpga manager: Add Altera CvP driver") Cc: stable@vger.kernel.org Signed-off-by: Daisuke Matsuda <matsuda@preferred.jp> Reviewed-by: Xu Yilun <yilun.xu@intel.com> Link: https://lore.kernel.org/r/20260723081912.74082-1-dskmtsd@gmail.com Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
2026-08-04Merge branch 'bpf-invalidate-rcu-pointers-after-final-spin-unlock'Kumar Kartikeya Dwivedi
Ning Ding says: ==================== bpf: Invalidate RCU pointers after final spin unlock In a sleepable BPF program, a spin lock can provide the only RCU protection for a kptr. The final spin unlock ends that protection, but the verifier leaves the pointer valid. Another CPU can then free the object before the pointer is used. A capability-limited runtime PoC triggered a KASAN-confirmed task_struct use-after-free. Patch 1 invalidates RCU-protected pointers only when an unlock leaves the final RCU-protected context. Patch 2 adds a negative sleepable test and positive controls for non-sleepable and explicit-RCU contexts. Testing used fresh QEMU/KVM guests with KASAN enabled. The patched focused test passed all three expected outcomes. The full task_kfunc test passed all 39 subtests, and the selected RCU, refcount, and spin-lock group had no failures. --- v2: - Rebase onto bpf-next commit 60781269e26c. - Target bpf-next and split the fix from its selftests, as requested. - Add positive controls for RCU contexts that remain valid after unlock. v1: https://lore.kernel.org/r/20260802231248.2781334-1-dingning04@gmail.com ==================== Link: https://patch.msgid.link/20260803112615.3362122-1-dingning04@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-08-04selftests/bpf: Test RCU pointer invalidation after spin unlockNing Ding
The verifier previously accepted a task kptr after the final spin unlock ended its RCU protection in a sleepable program. The pointer could then be used after the task was freed. Add a negative test for that case. Add positive controls showing that the pointer remains valid in a non-sleepable program and while an explicit RCU read-side section is still active. Assisted-by: Codex:gpt-5.6-sol Assisted-by: ChatGPT:GPT-5.6-Pro Signed-off-by: Ning Ding <dingning04@gmail.com> Link: https://lore.kernel.org/bpf/20260803112615.3362122-3-dingning04@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-08-04bpf: Invalidate RCU pointers after final spin unlockNing Ding
In a sleepable BPF program, a spin lock can provide the only RCU protection for a kptr. The final bpf_spin_unlock() ends that protection, but the verifier leaves the pointer valid. Another CPU can then free the object before the pointer is used. A capability-limited runtime PoC triggered a task_struct use-after-free in __bpf_get_task_stack(). Record whether the program is in an RCU-protected context before releasing the lock. Invalidate RCU-protected pointers only when the unlock leaves the final such context. This preserves valid pointers in non-sleepable programs and inside an explicit RCU read-side section. Fixes: 5861d1e8dbc4 ("bpf: Allow bpf_spin_{lock,unlock} in sleepable progs") Assisted-by: Codex:gpt-5.6-sol Assisted-by: ChatGPT:GPT-5.6-Pro Signed-off-by: Ning Ding <dingning04@gmail.com> Link: https://lore.kernel.org/bpf/20260803112615.3362122-2-dingning04@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-08-04Merge tag 'aspeed-7.2-driver-fixes-0' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux into arm/fixes aspeed: First batch of driver fixes for 7.2 This time it's a single fix for a kfifo overrun, caused by the the lpc-snoop driver implementation behaving as multiple consumers. * tag 'aspeed-7.2-driver-fixes-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux: soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-08-04usb: xhci: use BIT_ULL for CRCR bits to fix incorrect 64bit maskLachlan Hodges
xhci is unusable on some systems after driver switched to BIT() macro. Upper 32bits of 64bit CRCR command register are unintentionally cleared. Seen on a raspberry pi 4B compiled for arm32. The main symptoms were the following log message: [ 0.549897] raspberrypi-firmware soc:firmware: Attached to firmware from 2021-02-25T12:11:39 [ 0.626859] xhci_hcd 0000:01:00.0: xHCI Host Controller [ 0.626889] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1 [ 0.812619] xhci_hcd 0000:01:00.0: hcc params 0x002841eb hci version 0x100 quirks 0x0000200000000890 [ 0.813188] xhci_hcd 0000:01:00.0: xHCI Host Controller [ 0.813203] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 2 [ 0.813219] xhci_hcd 0000:01:00.0: Host supports USB 3.0 SuperSpeed [ 0.813602] hub 1-0:1.0: USB hub found [ 0.814052] hub 2-0:1.0: USB hub found [ 0.952714] xhci_hcd 0000:01:00.0: ERROR mismatched command completion event Additionally running lsusb just hangs. Running the same kernel compiled for aarch64 worked fine. Bisected to the commit in the Fixes line. Additionally a USB device plugged in to the USB3.0 (or 2.0) did not enumerate. Once this patch is applied the USB device enumerates properly. The CRCR register is 64 bits wide - commit abe93f27cdd7 ("xhci: use BIT macro") changed the flag definitions from (1 << n), a signed int, to BIT(n), an unsigned long. Within xhci_set_cmd_ring_deq(), the following operation is performed on the CRCR register: ... crcr &= ~CMD_RING_PTR_MASK; crcr |= deq_dma; crcr &= ~CMD_RING_CYCLE; crcr |= xhci->cmd_ring->cycle_state; ... Previously, ~CMD_RING_CYCLE was ~(int)1, a negative signed value (0xFFFFFFFE with the sign bit set). Widening a negative signed int to u64 sign-extends it to 0xFFFFFFFFFFFFFFFE, correctly clearing only bit 0 and preserving the 64-bit pointer written two lines above. After the change when running on 32 bit kernels, ~CMD_RING_CYCLE is ~(unsigned long)1UL. On a 32-bit host this is an unsigned 32-bit value (0xFFFFFFFE, no sign bit). Widening an unsigned value to u64 zero-extends it instead (0x00000000FFFFFFFE), so the subsequent AND silently clears bits 63:32 of crcr, truncating the command ring pointer that was just written before the value reaches hardware. To fix, similar to how CMD_RING_PTR_MASK is defined, make sure we use the BIT_ULL variant when defining the CRCR bits. [Mathias: use BIT_ULL() for ERST_EHB and EP_CTX_CYCLE_MASK as suggested by Michal Pecio, also include raspberry case in commit message] Fixes: abe93f27cdd7 ("xhci: use BIT macro") Cc: stable <stable@kernel.org> Assisted-by: Claude:claude-sonnet-5 cc: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260804083639.2148950-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-04dm-stats: fix a crash if allocation of per-cpu data failsMikulas Patocka
If "dm_kvzalloc(percpu_alloc_size, cpu_to_node(cpu))" fails, the code jumps to the "out" label and calls dm_stat_free. dm_stat_free does "for_each_possible_cpu(cpu) { dm_kvfree(s->stat_percpu[cpu][0].histogram, s->histogram_alloc_size);", which crashes with NULL pointer dereference if s->stat_percpu[cpu] is NULL. This commit fixes the bug by testing s->stat_percpu[cpu] for NULL before using it. Reported-by: Junzhe Yu <junzheyu1@gmail.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: fd2ed4d25270 ("dm: add statistics support") Cc: stable@vger.kernel.org
2026-08-04dm array: reject an array block whose value size is not the caller'sBryam Vargas
array_block_check() can only compare the header against itself, so a block with value_size 4 and max_entries 1018 is internally consistent and passes. dm-cache keeps two arrays -- mappings at 8 bytes and hints at 4 -- and the roots for both live in the superblock. Point the mappings root at a hint block and __load_mappings() walks it through an info whose value size is 8, so element_at() strides 8 bytes over 4-byte entries and reaches offset 8160 of a 4096-byte block. get_ablock() and __shadow_ablock() are the two places that hold the block and the caller at once. Reject there when the two value sizes disagree. Arrays only ever read their own blocks, so this fires on crafted metadata only. Fixes: 6513c29f44f2 ("dm persistent data: add transactional array") Suggested-by: Ming-Hung Tsai <mtsai@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Reviewed-by: Ming-Hung Tsai <mtsai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-08-04dm array: validate array block headers on readBryam Vargas
array_block_check() validates blocknr and csum and nothing else, while node_check(), next to it, has bounded the structural fields since both were written. dm_array_cursor_next() takes its loop bound from the on-disk nr_entries and element_at() is unguarded pointer arithmetic, so a count larger than the block holds keeps the cursor in one block while the index grows past it and the read walks off the dm-bufio buffer -- dm_cache_load_mappings() drives it once per cache block at activation. Check the header against itself: reject a zero value_size, require max_entries to equal calc_max_entries() for that value_size and block size, and require nr_entries to fit. Equality rather than an upper bound, since a count below the real capacity trips BUG_ON() in fill_ablock() and trim_ablock(). Metadata dm-array writes satisfies all three. Fixes: 6513c29f44f2 ("dm persistent data: add transactional array") Suggested-by: Ming-Hung Tsai <mtsai@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Reviewed-by: Ming-Hung Tsai <mtsai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-08 18:43:38 +0000