summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorLines
2026-04-07selftests: net: add tests for PPPQingfang Deng-0/+181
Add ping and iperf3 tests for ppp_async.c and pppoe.c. Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev> Link: https://patch.msgid.link/20260403034908.30017-1-qingfang.deng@linux.dev Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-07Merge branch 'intel-sst' of https://github.com/spandruvada/linux-kernel into ↵Ilpo Järvinen-17/+24
review-ilpo-next
2026-04-07firmware: arm_ffa: Use the correct buffer size during RXTX_MAPSebastian Ene-1/+1
Don't use the discovered buffer size from an FFA_FEATURES call directly since we can run on a system that has the PAGE_SIZE larger than the returned size which makes the alloc_pages_exact for the buffer to be rounded up. Fixes: 61824feae5c0 ("firmware: arm_ffa: Fetch the Rx/Tx buffer size using ffa_features()") Signed-off-by: Sebastian Ene <sebastianene@google.com> Link: https://patch.msgid.link/20260402113939.930221-1-sebastianene@google.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-04-07platform/x86: asus-wireless: Convert ACPI driver to a platform oneRafael J. Wysocki-18/+21
In all cases in which a struct acpi_driver is used for binding a driver to an ACPI device object, a corresponding platform device is created by the ACPI core and that device is regarded as a proper representation of underlying hardware. Accordingly, a struct platform_driver should be used by driver code to bind to that device. There are multiple reasons why drivers should not bind directly to ACPI device objects [1]. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the Asus wireless ACPI driver to a platform one. After this change, the subordinate input and LED devices will be registered under the platform device used for driver binding instead of its ACPI companion. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Link: https://lore.kernel.org/all/2396510.ElGaqSPkdT@rafael.j.wysocki/ [1] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Denis Benato <denis.benato@linux.dev> Link: https://patch.msgid.link/13959361.uLZWGnKmhe@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-04-07platform/x86: asus-wireless: Register ACPI notify handler directlyRafael J. Wysocki-4/+16
To facilitate subsequent conversion of the driver to a platform one, make it install an ACPI notify handler directly instead of using a .notify() callback in struct acpi_driver. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Denis Benato <denis.benato@linux.dev> Link: https://patch.msgid.link/1949745.tdWV9SEqCh@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-04-07platform/x86: asus-laptop: Convert ACPI driver to a platform oneRafael J. Wysocki-17/+18
In all cases in which a struct acpi_driver is used for binding a driver to an ACPI device object, a corresponding platform device is created by the ACPI core and that device is regarded as a proper representation of underlying hardware. Accordingly, a struct platform_driver should be used by driver code to bind to that device. There are multiple reasons why drivers should not bind directly to ACPI device objects [1]. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the Asus laptop ACPI driver to a platform one. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Link: https://lore.kernel.org/all/2396510.ElGaqSPkdT@rafael.j.wysocki/ [1] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Denis Benato <denis.benato@linux.dev> Link: https://patch.msgid.link/2402539.ElGaqSPkdT@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-04-07platform/x86: asus-laptop: Register ACPI notify handler directlyRafael J. Wysocki-3/+8
To facilitate subsequent conversion of the driver to a platform one, make it install an ACPI notify handler directly instead of using a .notify() callback in struct acpi_driver. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Denis Benato <denis.benato@linux.dev> Link: https://patch.msgid.link/5082508.31r3eYUQgx@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-04-07ntfs: remove redundant out-of-bound checksHyunchul Lee-42/+0
Remove redundant out-of-bounds validations. Since ntfs_attr_find and ntfs_external_attr_find now validate the attribute value offsets and lengths against the bounds of the MFT record block, performing subsequent bounds checking in caller functions like ntfs_attr_lookup is no longer necessary. Signed-off-by: Hyunchul Lee <hyc.lee@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
2026-04-07ntfs: add bound checking to ntfs_external_attr_findHyunchul Lee-14/+69
Add bound validation in ntfs_external_attr_find to prevent out-of-bounds memory accesses. This ensures that the attribute record's length, name offset, and both resident and non-resident value offsets strictly fall within the safe boundaries of the MFT record. Signed-off-by: Hyunchul Lee <hyc.lee@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
2026-04-07ntfs: add bound checking to ntfs_attr_findHyunchul Lee-12/+72
Add bound validations in ntfs_attr_find to ensure attribute value offsets and lengths are safe to access. It verifies that resident attributes meet type-specific minimum length requirements and check the mapping_pairs_offset boundaries for non-resident attributes. Signed-off-by: Hyunchul Lee <hyc.lee@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
2026-04-07pinctrl: mcp23s08: Disable all pin interrupts during probeFrancesco Lavra-0/+9
A chip being probed may have the interrupt-on-change feature enabled on some of its pins, for example after a reboot. This can cause the chip to generate interrupts for pins that don't have a registered nested handler, which leads to a kernel crash such as below: [ 7.928897] Unable to handle kernel read from unreadable memory at virtual address 00000000000000ac [ 7.932314] Mem abort info: [ 7.935081] ESR = 0x0000000096000004 [ 7.938808] EC = 0x25: DABT (current EL), IL = 32 bits [ 7.944094] SET = 0, FnV = 0 [ 7.947127] EA = 0, S1PTW = 0 [ 7.950247] FSC = 0x04: level 0 translation fault [ 7.955101] Data abort info: [ 7.957961] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 7.963421] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 7.968447] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 7.973734] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000089b7000 [ 7.980148] [00000000000000ac] pgd=0000000000000000, p4d=0000000000000000 [ 7.986913] Internal error: Oops: 0000000096000004 [#1] SMP [ 7.992545] Modules linked in: [ 8.073678] CPU: 0 UID: 0 PID: 81 Comm: irq/18-4-0025 Not tainted 7.0.0-rc6-gd2b5a1f931c8-dirty #199 [ 8.073689] Hardware name: Khadas VIM3 (DT) [ 8.073692] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 8.094639] pc : _raw_spin_lock_irq+0x40/0x80 [ 8.098970] lr : handle_nested_irq+0x2c/0x168 [ 8.098979] sp : ffff800082b2bd20 [ 8.106599] x29: ffff800082b2bd20 x28: ffff800080107920 x27: ffff800080104d88 [ 8.106611] x26: ffff000003298080 x25: 0000000000000001 x24: 000000000000ff00 [ 8.113707] x23: 0000000000000001 x22: 0000000000000000 x21: 000000000000000e [ 8.120850] x20: 0000000000000000 x19: 00000000000000ac x18: 0000000000000000 [ 8.135046] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 8.135062] x14: ffff800081567ea8 x13: ffffffffffffffff x12: 0000000000000000 [ 8.135070] x11: 00000000000000c0 x10: 0000000000000b60 x9 : ffff800080109e0c [ 8.135078] x8 : 1fffe0000069dbc1 x7 : 0000000000000001 x6 : ffff0000034ede00 [ 8.135086] x5 : 0000000000000000 x4 : ffff0000034ede08 x3 : 0000000000000001 [ 8.163460] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 00000000000000ac [ 8.170560] Call trace: [ 8.180094] _raw_spin_lock_irq+0x40/0x80 (P) [ 8.184443] mcp23s08_irq+0x248/0x358 [ 8.184462] irq_thread_fn+0x34/0xb8 [ 8.184470] irq_thread+0x1a4/0x310 [ 8.195093] kthread+0x13c/0x150 [ 8.198309] ret_from_fork+0x10/0x20 [ 8.201850] Code: d65f03c0 d2800002 52800023 f9800011 (885ffc01) [ 8.207931] ---[ end trace 0000000000000000 ]--- This issue has always been present, but has been latent until commit "f9f4fda15e72" ("pinctrl: mcp23s08: init reg_defaults from HW at probe and switch cache type"), which correctly removed reg_defaults from the regmap and as a side effect changed the behavior of the interrupt handler so that the real value of the MCP_GPINTEN register is now being read from the chip instead of using a bogus 0 default value; a non-zero value for this register can trigger the invocation of a nested handler which may not exist (yet). Fix this issue by disabling all pin interrupts during initialization. Fixes: f9f4fda15e72 ("pinctrl: mcp23s08: init reg_defaults from HW at probe and switch cache type") Signed-off-by: Francesco Lavra <flavra@baylibre.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-04-07pinctrl: sophgo: pinctrl-sg2044: Fix wrong module descriptionInochi Amaoto-1/+1
Fix the SoC model in module description string, it should be sg2044 instead of sg2002. Fixes: 614a54cb5ac3 ("pinctrl: sophgo: add support for SG2044 SoC") Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-04-07pinctrl: sophgo: pinctrl-sg2042: Fix wrong module descriptionInochi Amaoto-1/+1
Fix the SoC model in module description string, it should be sg2042 instead of sg2002. Fixes: 1e67465d3b74 ("pinctrl: sophgo: add support for SG2042 SoC") Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-04-07fs: attr: fix comment formatting and spelling issuesChelsy Ratnawat-3/+3
Fix minor comment issues in fs/attr.c reported by checkpatch: - Wrap long comment lines to comply with the 75-character limit - Correct spelling of “overriden” to “overridden” No functional changes. Signed-off-by: Chelsy Ratnawat <chelsyratnawat2001@gmail.com> Link: https://patch.msgid.link/20260403092709.83458-1-chelsyratnawat2001@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-04-07lib/tests/slub_kunit: add a test case for {kmalloc,kfree}_nolockHarry Yoo (Oracle)-0/+92
Testing invocation of {kmalloc,kfree}_nolock() during kmalloc() or kfree() is tricky, and it is even harder to ensure that slowpaths are properly tested. Lack of such testing has led to late discovery of the bug fixed by commit a1e244a9f177 ("mm/slab: use prandom if !allow_spin"). Add a slub_kunit test that allocates and frees objects in a tight loop while a perf event triggers interrupts (NMI or hardirq depending on the arch) on the same task, invoking {kmalloc,kfree}_nolock() from the overflow handler. Acked-by: David Rientjes <rientjes@google.com> Signed-off-by: Harry Yoo (Oracle) <harry@kernel.org> Link: https://patch.msgid.link/20260406090907.11710-3-harry@kernel.org Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-04-07MAINTAINERS: add lib/tests/slub_kunit.c to SLAB ALLOCATOR sectionHarry Yoo (Oracle)-0/+1
The slub_kunit module has been maintained by SLAB ALLOCATOR folks, but is missing in the MAINTAINERS file. Add the missing entry. Acked-by: David Rientjes <rientjes@google.com> Signed-off-by: Harry Yoo (Oracle) <harry@kernel.org> Acked-by: SeongJae Park <sj@kernel.org> Link: https://patch.msgid.link/20260406090907.11710-2-harry@kernel.org Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-04-07irqchip/irq-pic32-evic: Add __maybe_unused for board_bind_eic_interrupt in ↵Brian Masney-1/+1
COMPILE_TEST There are a few ifdefs in this driver so that it can be compiled on all architectures when COMPILE_TEST is set. board_bind_eic_interrupt is defined in arch/mips/ for normal usage, however when this driver is compiled with COMPILE_TEST on other architectures, it is defined as a static variable inside this driver. This causes the following warning: drivers/irqchip/irq-pic32-evic.c:54:15: warning: variable 'board_bind_eic_interrupt' set but not used [-Wunused-but-set-global] 54 | static void (*board_bind_eic_interrupt)(int irq, int regset); | ^ Annotate the static variable with __maybe_unused to avoid having to put even more ifdefs into this driver. Fixes: 282f8b547d51d ("irqchip/irq-pic32-evic: Define board_bind_eic_interrupt for !MIPS builds") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260403-irq-pic32-evic-unused-v1-1-447cdc0675ec@redhat.com Closes: https://lore.kernel.org/oe-kbuild-all/202603300715.4HuMMAFb-lkp@intel.com/
2026-04-07irqchip/renesas-rzv2h: Kill icu_err stringGeert Uytterhoeven-6/+3
Replace the string variable icu_err by its expanded value where needed, to improve readability. This reduces generated code size by 16 bytes. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/c7472bec20dea2c4d63e390e8e293b7d7003ef39.1775205874.git.geert+renesas@glider.be
2026-04-07irqchip/renesas-rzv2h: Kill swint_names[]Geert Uytterhoeven-10/+4
The array swint_names[] just contains expansions of "int-ca55-%u". Replace it by formatting the strings where needed, to improve readability. Despite the two error messages can no longer be shared with the ICU error cases, this reduces generated code size by 56 bytes. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/aceab3fbc307ef428dfd62d8d846b68704dea012.1775205874.git.geert+renesas@glider.be
2026-04-07irqchip/renesas-rzv2h: Kill swint_idx[]Geert Uytterhoeven-3/+2
The array swint_idx[] just contains an identity mapping. Replace it by using the index directly, to simplify the code. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/0f32ba2a4701311710d02ff4fa2fd472b56745c4.1775205874.git.geert+renesas@glider.be
2026-04-07slub: use N_NORMAL_MEMORY in can_free_to_pcs to handle remote freesHao Li-2/+3
Memory hotplug now keeps N_NORMAL_MEMORY up to date correctly, so make can_free_to_pcs() use it. As a result, when freeing objects on memoryless nodes, or on nodes that have memory but only in ZONE_MOVABLE, the objects can be freed to the sheaf instead of going through the slow path. Signed-off-by: Hao Li <hao.li@linux.dev> Acked-by: Harry Yoo (Oracle) <harry@kernel.org> Acked-by: David Rientjes <rientjes@google.com> Link: https://patch.msgid.link/20260403073958.8722-1-hao.li@linux.dev Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-04-07net: af_key: zero aligned sockaddr tail in PF_KEY exportsZhengchuan Liang-18/+34
PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, `pfkey_sockaddr_fill()` initializes only the first 28 bytes of `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized. Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain `skb_put()`: - `SADB_ACQUIRE` - `SADB_X_NAT_T_NEW_MAPPING` - `SADB_X_MIGRATE` Fix those paths by clearing only the aligned sockaddr tail after `pfkey_sockaddr_fill()`. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 08de61beab8a ("[PFKEYV2]: Extension for dynamic update of endpoint address(es)") Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Co-developed-by: Yuan Tan <yuantan098@gmail.com> Signed-off-by: Yuan Tan <yuantan098@gmail.com> Suggested-by: Xin Liu <bird@lzu.edu.cn> Tested-by: Xiao Liu <lx24@stu.ynu.edu.cn> Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2026-04-07xfrm: Drop support for HMAC-RIPEMD-160Eric Biggers-26/+2
Drop support for HMAC-RIPEMD-160 from IPsec to reduce the UAPI surface and simplify future maintenance. It's almost certainly unused. RIPEMD-160 received some attention in the early 2000s when SHA-* weren't quite as well established. But it never received much adoption outside of certain niches such as Bitcoin. It's actually unclear that Linux + IPsec + HMAC-RIPEMD-160 has *ever* been used, even historically. When support for it was added in 2003, it was done so in a "cleanup" commit without any justification [1]. It didn't actually work until someone happened to fix it 5 years later [2]. That person didn't use or test it either [3]. Finally, also note that "hmac(rmd160)" is by far the slowest of the algorithms in aalg_list[]. Of course, today IPsec is usually used with an AEAD, such as AES-GCM. But even for IPsec users still using a dedicated auth algorithm, they almost certainly aren't using, and shouldn't use, HMAC-RIPEMD-160. Thus, let's just drop support for it. Note: no kconfig update is needed, since CRYPTO_RMD160 wasn't actually being selected anyway. References: [1] linux-history commit d462985fc1941a47 ("[IPSEC]: Clean up key manager algorithm handling.") [2] linux commit a13366c632132bb9 ("xfrm: xfrm_algo: correct usage of RIPEMD-160") [3] https://lore.kernel.org/all/1212340578-15574-1-git-send-email-rueegsegger@swiss-it.ch Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2026-04-07Merge patch series "rust: bump minimum Rust and `bindgen` versions"Miguel Ojeda-451/+88
As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's Rust versions as our minimum supported version. Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it still uses to this day [3] (i.e. no update to Rust 1.85.1). Debian Trixie was released with `bindgen` 0.71.1, which it also still uses to this day [4]. Debian Trixie's release happened on 2025-08-09 [5], which means that a fair amount of time has passed since its release for kernel developers to upgrade. Thus bump the minimum to the new versions, i.e. - Rust: 1.78.0 -> 1.85.0 - bindgen: 0.65.1 -> 0.71.1 There are a few main parts to the series, in this order: - A few cleanups that can be performed before the bumps. - The Rust bump (and its cleanups). - The `bindgen` bump (and its cleanups). - Documentation updates. - The `cfi_encoding` patch, added here, which needs the bump. - The per-version flags support and a Clippy cleanup on top. Link: https://lwn.net/Articles/1050174/ [1] Link: https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2] Link: https://packages.debian.org/trixie/rustc [3] Link: https://packages.debian.org/trixie/bindgen [4] Link: https://www.debian.org/releases/trixie/ [5] Link: https://patch.msgid.link/20260405235309.418950-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07xfrm_user: fix info leak in build_report()Greg Kroah-Hartman-0/+1
struct xfrm_user_report is a __u8 proto field followed by a struct xfrm_selector which means there is three "empty" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables. Cc: stable <stable@kernel.org> Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Simon Horman <horms@kernel.org> Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2026-04-07xfrm_user: fix info leak in build_mapping()Greg Kroah-Hartman-0/+1
struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables. Fixes: 3a2dfbe8acb1 ("xfrm: Notify changes in UDP encapsulation via netlink") Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Simon Horman <horms@kernel.org> Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2026-04-07xfrm: fix refcount leak in xfrm_migrate_policy_findKotlyarov Mihail-3/+0
syzkaller reported a memory leak in xfrm_policy_alloc: BUG: memory leak unreferenced object 0xffff888114d79000 (size 1024): comm "syz.1.17", pid 931 ... xfrm_policy_alloc+0xb3/0x4b0 net/xfrm/xfrm_policy.c:432 The root cause is a double call to xfrm_pol_hold_rcu() in xfrm_migrate_policy_find(). The lookup function already returns a policy with held reference, making the second call redundant. Remove the redundant xfrm_pol_hold_rcu() call to fix the refcount imbalance and prevent the memory leak. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 563d5ca93e88 ("xfrm: switch migrate to xfrm_policy_lookup_bytype") Signed-off-by: Kotlyarov Mihail <mihailkotlyarow@gmail.com> Reviewed-by: Florian Westphal <fw@strlen.de> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2026-04-07xfrm: hold dev ref until after transport_finish NF_HOOKQi Tang-6/+22
After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set. Suggested-by: Florian Westphal <fw@strlen.de> Fixes: acf568ee859f ("xfrm: Reinject transport-mode packets through tasklet") Cc: stable@vger.kernel.org Signed-off-by: Qi Tang <tpluszz77@gmail.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2026-04-07xfrm: Wait for RCU readers during policy netns exitSteffen Klassert-0/+2
xfrm_policy_fini() frees the policy_bydst hash tables after flushing the policy work items and deleting all policies, but it does not wait for concurrent RCU readers to leave their read-side critical sections first. The policy_bydst tables are published via rcu_assign_pointer() and are looked up through rcu_dereference_check(), so netns teardown must also wait for an RCU grace period before freeing the table memory. Fix this by adding synchronize_rcu() before freeing the policy hash tables. Fixes: e1e551bc5630 ("xfrm: policy: prepare policy_bydst hash for rcu lookups") Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Reviewed-by: Florian Westphal <fw@strlen.de>
2026-04-07Merge tag 'icc-7.1-rc1' of ↵Greg Kroah-Hartman-461/+4014
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/djakov/icc into char-misc-next Georgi writes: This pull request contains the interconnect changes for the 7.1-rc1 merge window. They are listed below: - New driver for Mahua SoC - New driver for Eliza SoC - Enable QoS support for QCS8300 and QCS615 SoCs - Add L3 cache scaling compatibles for SM8550 and Eliza SoCs - Fix multiple issues in the msm8974 driver - Fix kfree mismatch - Misc cleanups - Add maintainer entry for the interconnect KUnit tests Signed-off-by: Georgi Djakov <djakov@kernel.org> * tag 'icc-7.1-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/djakov/icc: (22 commits) MAINTAINERS: Add interconnect kunit test entry interconnect: debugfs: fix devm_kstrdup and kfree mismatch interconnect: qcom: msm8974: expand DEFINE_QNODE macros interconnect: qcom: msm8974: switch to the main icc-rpm driver interconnect: qcom: let platforms declare their bugginess interconnect: qcom: define OCMEM bus resource interconnect: qcom: icc-rpm: allow overwriting get_bw callback interconnect: qcom: drop unused is_on flag dt-bindings: interconnect: qcom,msm8974: use qcom,rpm-common dt-bindings: interconnect: qcom,msm8974: drop bus clocks interconnect: qcom: qcs615: enable QoS configuration dt-bindings: interconnect: qcom,qcs615-rpmh: add clocks property to enable QoS interconnect: qcom: Add Eliza interconnect provider driver dt-bindings: interconnect: document the RPMh Network-On-Chip interconnect in Eliza SoC dt-bindings: interconnect: OSM L3: Add Eliza EPSS L3 compatible interconnect: qcom: De-acronymize SoC names dt-bindings: interconnect: qcom,glymur-rpmh: De-acronymize SoC name dt-bindings: interconnect: OSM L3: Document sm8550 OSM L3 compatible interconnect: qcom: qcs8300: enable QoS configuration dt-bindings: interconnect: qcom,qcs8300-rpmh: add clocks property to enable QoS ...
2026-04-07Merge tag 'extcon-next-for-7.1' of ↵Greg Kroah-Hartman-17/+75
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-next Chanwoo writes: Update extcon next for v7.1 Detailed description for this pull request: - Fix sysfs duplicate filename issue on extcon core : Adjust ida_free timing after device_unregister to prevent duplicate filename error when re-allocating id - Update NXP PTN5150 extcon driver and dt-binding document : Handle pending IRQ events during system resume : Allow "connector" node to present in devicetree : Add Type-C orientation switch support to correctly set orientation of multiplexer according to CC status : Support USB role switch via connector fwnode - Replace use of system_wq with system_percpu_wq on int3496 driver - Make typec-power-opmode optional on usbc-tusb320 driver : Prevent probe error when usb-c connector is configured in the DT without "typec-power-opmode" property * tag 'extcon-next-for-7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon: extcon: usbc-tusb320: Make typec-power-opmode optional extcon: ptn5150: Support USB role switch via connector fwnode extcon: ptn5150: Add Type-C orientation switch support dt-bindings: extcon: ptn5150: Allow "connector" node to present extcon: Fixed sysfs duplicate filename issue extcon: int3496: replace use of system_wq with system_percpu_wq extcon: ptn5150: handle pending IRQ events during system resume
2026-04-07rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0Miguel Ojeda-1/+7
The Clippy `precedence` lint was extended in Rust 1.85.0 to include bitmasking and shift operations [1]. However, because it generated many hits, in Rust 1.86.0 it was split into a new `precedence_bits` lint which is not enabled by default [2]. In other words, only Rust 1.85 has a different behavior. For instance, it reports: warning: operator precedence can trip the unwary --> drivers/gpu/nova-core/fb/hal/ga100.rs:16:5 | 16 | / u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08()) << FLUSH_SYSMEM_ADDR_SHIFT 17 | | | u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40()) 18 | | << FLUSH_SYSMEM_ADDR_SHIFT_HI | |_________________________________________^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence = note: `-W clippy::precedence` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::precedence)]` help: consider parenthesizing your expression | 16 ~ (u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08()) << FLUSH_SYSMEM_ADDR_SHIFT) | (u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40()) 17 + << FLUSH_SYSMEM_ADDR_SHIFT_HI) | While so far we try our best to keep all versions Clippy-clean, the minimum (which is now Rust 1.85.0 after the bump) and the latest stable are the most important ones; and this may be considered a "false positive" with respect to the behavior in other versions. Thus allow this lint for this version using the per-version flags mechanism introduced in the previous commit. Link: https://github.com/rust-lang/rust-clippy/issues/14097 [1] Link: https://github.com/rust-lang/rust-clippy/pull/14115 [2] Link: https://lore.kernel.org/rust-for-linux/DFVDKMMA7KPC.2DN0951H3H55Y@kernel.org/ Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-34-ojeda@kernel.org [ Added paragraph from commit message to comment. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: kbuild: support global per-version flagsMiguel Ojeda-1/+9
Sometimes it is useful to gate global Rust flags per compiler version. For instance, we may want to disable a lint that has false positives in a single version [1]. We already had helpers like `rustc-min-version` for that, which we use elsewhere, but we cannot currently use them for `rust_common_flags`, which contains the global flags for all Rust code (kernel and host), because `rustc-min-version` depends on `CONFIG_RUSTC_VERSION`, which does not exist when `rust_common_flags` is defined. Thus, to support that, introduce `rust_common_flags_per_version`, defined after the `include/config/auto.conf` inclusion (where `CONFIG_RUSTC_VERSION` becomes available), and append it to `rust_common_flags`, `KBUILD_HOSTRUSTFLAGS` and `KBUILD_RUSTFLAGS`. In addition, move the expansion of `HOSTRUSTFLAGS` to the same place, so that users can also override per-version flags [2]. Link: https://lore.kernel.org/rust-for-linux/CANiq72mWdFU11GcCZRchzhy0Gi1QZShvZtyRkHV2O+WA2uTdVQ@mail.gmail.com/ [1] Link: https://lore.kernel.org/rust-for-linux/CANiq72mTaA2tjhkLKf0-2hrrrt9rxWPgy6SfNSbponbGOegQvA@mail.gmail.com/ [2] Link: https://patch.msgid.link/20260307170929.153892-1-ojeda@kernel.org Link: https://patch.msgid.link/20260405235309.418950-33-ojeda@kernel.org Reviewed-by: Tamir Duberstein <tamird@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: declare cfi_encoding for lru_statusAlice Ryhl-45/+10
By default bindgen will convert 'enum lru_status' into a typedef for an integer. For the most part, an integer of the same size as the enum results in the correct ABI, but in the specific case of CFI, that is not the case. The CFI encoding is supposed to be the same as a struct called 'lru_status' rather than the name of the underlying native integer type. To fix this, tell bindgen to generate a newtype and set the CFI type explicitly. Note that we need to set the CFI attribute explicitly as bindgen is using repr(transparent), which is otherwise identical to the inner type for ABI purposes. This allows us to remove the page range helper C function in Binder without risking a CFI failure when list_lru_walk calls the provided function pointer. The --with-attribute-custom-enum argument requires bindgen v0.71 or greater. [ In particular, the feature was added in 0.71.0 [1][2]. In addition, `feature(cfi_encoding)` has been available since Rust 1.71.0 [3]. Link: https://github.com/rust-lang/rust-bindgen/issues/2520 [1] Link: https://github.com/rust-lang/rust-bindgen/pull/2866 [2] Link: https://github.com/rust-lang/rust/pull/105452 [3] - Miguel ] My testing procedure was to add this to the android17-6.18 branch and verify that rust_shrink_free_page is successfully called without crash, and verify that it does in fact crash when the cfi_encoding is set to other values. Note that I couldn't test this on android16-6.12 as that branch uses a bindgen version that is too old. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260223-cfi-lru-status-v2-1-89c6448a63a4@google.com [ Rebased on top of the minimum Rust version bump series which provide the required `bindgen` version. - Miguel ] Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-32-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: general-information: use real exampleMiguel Ojeda-2/+2
Currently the example in the documentation shows a version-based name for the Kconfig example: RUSTC_VERSION_MIN_107900 The reason behind it was to possibly avoid repetition in case several features used the same minimum. However, we ended up preferring to give them a descriptive name for each feature added even if that could lead to some repetition. In practice, the repetition has not happened so far, and even if it does at some point, it is not a big deal. Thus replace the example in the documentation with one of our current examples (after removing previous ones from the bump), to show how they actually look like, and in case someone `grep`s for it. In addition, it has the advantage that it shows the `RUSTC_HAS_*` pattern we follow in `init/Kconfig`, similar to the C side. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-31-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: general-information: simplify Kconfig exampleMiguel Ojeda-1/+1
There is no need to use `def_bool y if <expr>` -- one can simply write `def_bool <expr>`. In fact, the simpler form is how we actually use them in practice in `init/Kconfig`. Thus simplify the example. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-30-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: remove GDB/Binutils mentionMiguel Ojeda-9/+0
The versions provided nowadays by even a distribution like Debian Stable (and Debian Old Stable) are newer than those mentioned [1]. Thus remove the workaround. Note that the minimum binutils version in the kernel is still 2.30, so one could argue part of the note is still relevant, but it is unlikely a kernel developer using such an old binutils is enabling Rust on a modern kernel, especially when using distribution toolchains, e.g. the Rust minimum version is not satisfied by Debian Old Stable. So we are at the point where keeping the docs short and relevant for essentially everyone is probably the better trade-off. Link: https://packages.debian.org/search?suite=all&searchon=names&keywords=binutils [1] Link: https://lore.kernel.org/all/CANiq72mCpc9=2TN_zC4NeDMpFQtPXAFvyiP+gRApg2vzspPWmw@mail.gmail.com/ Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-29-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: remove Nix "unstable channel" noteMiguel Ojeda-2/+2
Nix does not need the "unstable channel" note, since its packages are recent enough even in the stable channel [1][2]. Thus remove it to simplify the documentation. Link: https://search.nixos.org/packages?channel=25.11&query=rust [1] Link: https://search.nixos.org/packages?channel=25.11&query=bindgen [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-28-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: remove Gentoo "testing" noteMiguel Ojeda-2/+2
Gentoo does not need the "testing" note, since its packages are recent enough even in the stable branch [1][2]. Thus remove it to simplify the documentation. Link: https://packages.gentoo.org/packages/dev-lang/rust [1] Link: https://packages.gentoo.org/packages/dev-util/bindgen [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-27-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: add Ubuntu 26.04 LTS and remove subsection titleMiguel Ojeda-4/+1
Ubuntu 26.04 LTS (Resolute Raccoon) is scheduled to be released in a few weeks [1], and it has a recent enough Rust toolchain, just like Ubuntu 25.10 has [2][3]. We could update the title and the paragraph, but to simplify and to make it more consistent with the other distributions' sections, let's instead just remove that title. It will also reduce the differences later on to keep it updated. Eventually, when we remove the remaining subsection for older LTSs, Ubuntu should be a small section like the other distributions. Thus remove the title and add the mention of Ubuntu 26.04 LTS. Link: https://documentation.ubuntu.com/release-notes/26.04/schedule/#resolute-raccoon-schedule [1] Link: https://packages.ubuntu.com/search?keywords=rustc&searchon=names&exact=1&suite=all&section=all [2] Link: https://packages.ubuntu.com/search?keywords=bindgen&searchon=names&exact=1&suite=all&section=all [3] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-26-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: update minimum Ubuntu versionMiguel Ojeda-1/+1
Ubuntu 25.04 is out of support [1], and Ubuntu 25.10 is the latest supported one. Moreover, Ubuntu 25.10 is the first that provides a recent enough Rust given the minimum bump -- they provide 1.85.1 [2]. Thus update it. Link: https://ubuntu.com/about/release-cycle [1] Link: https://packages.ubuntu.com/search?keywords=rustc&searchon=names&exact=1&suite=all&section=all [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-25-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: update Ubuntu versioned packagesMiguel Ojeda-14/+14
Now that the minimum supported Rust version is bumped, bump the versioned Rust packages [1][2][3][4] to that version for Ubuntu in the Quick Start guide. In addition, add "may" to the `RUST_LIB_SRC` line since it does not look like it is needed from a quick test in a Ubuntu 24.04 LTS container. Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=rustc [1] Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=bindgen [2] Link: https://launchpad.net/ubuntu/+source/rustc-1.85 [3] Link: https://launchpad.net/ubuntu/+source/rust-bindgen-0.71 [4] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-24-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: openSUSE provides `rust-src` package nowadaysMiguel Ojeda-1/+1
Both openSUSE Tumbleweed and Slowroll provide the `rust-src` package nowadays [1]. Thus remove the version-specific one from the Quick Start guide. Link: https://software.opensuse.org/package/rust-src?search_term=rust-src [1] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-23-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: kbuild: remove "dummy parameter" workaround for `bindgen` < 0.71.1Miguel Ojeda-13/+2
Until the version bump of `bindgen`, we needed to pass a dummy parameter to avoid failing the `--version` call. Thus remove it. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-22-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: kbuild: update `bindgen --rust-target` version and replace commentMiguel Ojeda-14/+2
As the comment in the `Makefile` explains, previously, we needed to limit ourselves to the list of Rust versions known by `bindgen` for its `--rust-target` option [1]. In other words, we needed to consult the versions known by the minimum version of `bindgen` that we supported. Now that we bumped the minimum version of `bindgen`, that limitation does not apply anymore since `bindgen` 0.71.0 [2]. Thus replace the comment and simply write our minimum supported Rust version there, which is much simpler. See commit 7a5f93ea5862 ("rust: kbuild: set `bindgen`'s Rust target version") for more details. Link: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/rust.20version.20on.20generated.20bindings/near/484087179 [1] Link: https://github.com/rust-lang/rust-bindgen/pull/2993 [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-21-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: rust_is_available: remove warning for `bindgen` < 0.69.5 && libclang ↵Miguel Ojeda-51/+1
>= 19.1 It is not possible anymore to fall into the issue that this warning was alerting about given the `bindgen` version bump. Thus simplify by removing the machinery behind it, including tests. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-20-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: rust_is_available: remove warning for `bindgen` 0.66.[01]Miguel Ojeda-38/+3
It is not possible anymore to fall into the issue that this warning was alerting about given the `bindgen` version bump. Thus simplify by removing the machinery behind it, including tests. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-19-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie)Miguel Ojeda-2/+2
As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's `bindgen` versions as our minimum supported version. Debian Trixie was released with `bindgen` 0.71.1, which it still uses to this day [2]. Debian Trixie's release happened on 2025-08-09 [3], which means that a fair amount of time has passed since its release for kernel developers to upgrade. Thus bump the minimum to the new version. Then, in later commits, clean up most of the workarounds and other bits that this upgrade of the minimum allows us. Ubuntu 25.10 also has a recent enough `bindgen` [4] (even the already unsupported Ubuntu 25.04 had it), and they also provide versioned packages with `bindgen` 0.71.1 back to Ubuntu 24.04 LTS [5]. Link: https://lwn.net/Articles/1050174/ [1] Link: https://packages.debian.org/trixie/bindgen [2] Link: https://www.debian.org/releases/trixie/ [3] Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=bindgen [4] Link: https://launchpad.net/ubuntu/+source/rust-bindgen-0.71 [5] Acked-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-18-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: block: update `const_refs_to_static` MSRV TODO commentMiguel Ojeda-3/+1
`feature(const_refs_to_static)` was stabilized in Rust 1.83.0 [1]. Thus update the comment to reflect that. Link: https://github.com/rust-lang/rust/pull/129759 [1] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-17-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: macros: simplify code using `feature(extract_if)`Miguel Ojeda-4/+8
`feature(extract_if)` [1] was stabilized in Rust 1.87.0 [2], and the last significant change happened in Rust 1.85.0 [3] when the range parameter was added. That is, with our new minimum version, we can start using the feature. Thus simplify the code using the feature and remove the TODO comment. Suggested-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/rust-for-linux/DHHVSX66206Y.3E7I9QUNTCJ8I@garyguo.net/ Link: https://github.com/rust-lang/rust/issues/43244 [1] Link: https://github.com/rust-lang/rust/pull/137109 [2] Link: https://github.com/rust-lang/rust/pull/133265 [3] Link: https://patch.msgid.link/20260405235309.418950-16-ojeda@kernel.org Reviewed-by: Tamir Duberstein <tamird@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
generated by cgit v1.2.3 (git 2.46.0) at 2026-07-19 19:04:41 +0000