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 a1e244a9f1 ("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>
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>
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: 282f8b547d ("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/
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
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>
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: 1da177e4c3 ("Linux-2.6.12-rc2")
Fixes: 08de61beab ("[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>
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 a13366c632
("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>
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>
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>
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: 3a2dfbe8ac ("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>
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: 563d5ca93e ("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>
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: acf568ee85 ("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>
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: e1e551bc56 ("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>
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>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEExQ4tCsdmOu34XfMFgNDMCsbYFmMFAmnTnbsACgkQgNDMCsbY
FmOynRAAwd60nzHWU8vJUwWwr5ARjT1Ox75VaNvV7e0kyBc7Ld28s5N2RB5fTR8O
WF8W7fXVanqk4dMEZS2GbJaub1gjTjfnk+VkZMBxXixGq5KJFBqNdrRwTAGF+pxu
Cmo2gBaFrRWMsHgZa7rV26vKT7pSyl8ZCgseX7FQ+molo/ycHImmiv9gJZJ3tj88
GoPpcDV7PHHa9k6B/FO5H7M3eoe596h4g2AqnCD7bW/nZAUkvO5HPAfqdLi6lyRf
ekcHBgLPYghx4EyC8N0WF8KSC2i7gyyl8HmiTGNZhuQbIE8mKpBVeYZVef6ebt8s
UM31wJMnmyDB4JaPfOhzmhjvneX2Vep5hxTO12tx/oiiOFs4k3EOOaw7X/MuNYtR
DKNJF/WWXpJLxj/LZPghx9o1IsXiblJdFQ+eTbDCcoHNUi7kzyJwazAX7Gku8sKK
YmjYQLimaEiw7OkDGa+425t8R5ax0O+FUD650hRHfaNKd/6xe89XnDwu9sFDzlHs
3CGSerb7ustg8rsvRIxwVpXc+ceBILp7mUc93mCT8GbeZwwE4veEIke3qGZARFmX
ExUC7NewHLCslPnw69oFoUUFDNKrULLwv7YoRqLoyJk4V2wTUm08vuCJ1nvsWmfP
RhTLgVv7/xowuSYWtOa4/myq9qZOB+sLlMgcGoiao5MS6KUqpu8=
=RyEu
-----END PGP SIGNATURE-----
Merge tag 'icc-7.1-rc1' of 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
...
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
-----BEGIN PGP SIGNATURE-----
iQJKBAABCgA0FiEEsSpuqBtbWtRe4rLGnM3fLN7rz1MFAmnP3dUWHGN3MDAuY2hv
aUBzYW1zdW5nLmNvbQAKCRCczd8s3uvPUz3ED/9DlV+zFijpckuSEu5BB05OmS35
ru8cOru50LG8yJMvemTiyHS1IOVD0dlWLJgm9nTrNVTwP5vILCNGPql0wVsS8KwW
kHmiLV3o4tT9kE+Kh9XuHwHuPhR6roxowfBwMWDQvse6TSAwojpXyRdcPvhOooxu
JILf8YkyAN1EdiE/UITvidGbAbBq0Yxbxv+KAaV62M2FX1d7gt2e18RpZ33ieALS
Ur0JzIsN7CKH26xwDcBjXu20UV47HiO7+/C4jANOwkkHjq2C8UWQfn+sN3XN3qZU
zejRoUf7r28aRl1yF5NuiyprudzjNbn0qvTvm9PDf5mucbAcIlrPCPe0mVJd1vlO
XqzR4MRV70EzcpLJMmXwe9eMtxA/vy/xaw7AaWc5FE8KZjMfSzChz+oLeW2e977d
1WUlCot2b6sr6tR3vTpDJLLXu065SfBCqhTgKgxO6XN+sA9WmB6IaueB2XNhyOWU
nbHZ/+XaNjd5lgI4e0eViKXutG8NoUdXQOE/VkfCGAnm8u26ljk0N6du2ejQYt+U
9IrpMMDBgpfsXaAR0qQzFW7kdv1iVIY4i5MexNAa8c4SP4mx0YGVV8/DbAp1C13u
L4daUWXA1uIigjt0tH7EN45pIaAfAj2dZhGjlTkQqBR94QmPQnx8egStZDAgSKGS
9R/kPmnTdlhe/fAPeA==
=0O4y
-----END PGP SIGNATURE-----
Merge tag 'extcon-next-for-7.1' of 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
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>
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>
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>
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>
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>
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>
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>
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>
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>
Currently, we need to go through raw pointers and then re-create the
`NonNull` from the result of offsetting the raw pointer.
`feature(non_null_convenience)` [1] has been stabilized in Rust
1.80.0 [2], which is older than our new minimum Rust version
(Rust 1.85.0).
Thus, now that we bump the Rust minimum version, simplify using
`NonNull::add()` and clean the TODO note.
Link: https://github.com/rust-lang/rust/issues/117691 [1]
Link: https://github.com/rust-lang/rust/pull/124498 [2]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260405235309.418950-15-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Now that the Rust minimum version is 1.85.0, there is no need to enable
certain features that are stable.
Thus clean them up.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260405235309.418950-13-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Back in Rust 1.82.0, I cleaned the `rustdoc::unescaped_backticks` lint in
upstream Rust and added tests so that hopefully it would not regress [1].
Thus we can remove it from our side given the Rust minimum version bump.
Link: https://github.com/rust-lang/rust/pull/128307 [1]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260405235309.418950-12-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
With the Rust version bump in place, the `RUSTC_HAS_COERCE_POINTEE`
Kconfig (automatic) option is always true.
Thus remove the option and simplify the code.
In particular, this includes removing our use of the predecessor unstable
features we used with Rust < 1.84.0 (`coerce_unsized`, `dispatch_from_dyn`
and `unsize`).
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260405235309.418950-11-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
With the Rust version bump in place, the `RUSTC_HAS_SLICE_AS_FLATTENED`
Kconfig (automatic) option is always true.
Thus remove the option and simplify the code.
In particular, this includes removing the `slice` module which contained
the temporary slice helpers, i.e. the `AsFlattened` extension trait and
its `impl`s.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260405235309.418950-10-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
With the Rust version bump in place, several Kconfig conditions based on
`RUSTC_VERSION` are always true.
Thus simplify them.
The minimum supported major LLVM version by our new Rust minimum version
is now LLVM 18, instead of LLVM 16. However, there are no possible
cleanups for `RUSTC_LLVM_VERSION`.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260405235309.418950-9-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
`clippy::incompatible_msrv` is not buying us much, and we discussed
allowing it several times in the past.
For instance, there was recently another patch sent to `allow` it where
needed [1]. While that particular case would not be needed after the
minimum version bump to 1.85.0, it is simpler to just allow it to prevent
future instances.
[ In addition, the lint fired without taking into account the features
that have been enabled in a crate [2]. While this was improved in Rust
1.90.0 [3], it would still fire in a case like this patch. ]
Thus do so, and remove the last instance of locally allowing it we have
in the tree (except the one in the vendored `proc_macro2` crate).
Note that we still keep the `msrv` config option in `clippy.toml` since
that affects other lints as well.
Link: https://lore.kernel.org/rust-for-linux/20260404212831.78971-4-jhubbard@nvidia.com/ [1]
Link: https://github.com/rust-lang/rust-clippy/issues/14425 [2]
Link: https://github.com/rust-lang/rust-clippy/pull/14433 [3]
Link: https://patch.msgid.link/20260405235309.418950-8-ojeda@kernel.org
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Following the Rust compiler bump, we can now update Clippy's MSRV we
set in the configuration, which will improve the diagnostics it generates.
Thus do so and clean a few of the `allow`s that are not needed anymore.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260405235309.418950-7-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
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's release happened on 2025-08-09 [4], 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.
pin-init was left as-is since the patches come from upstream. And the
vendored crates are unmodified, since we do not want to change those.
Note that the minimum LLVM major version for Rust 1.85.0 is LLVM 18 (the
Rust upstream binaries use LLVM 19.1.7), thus e.g. `RUSTC_LLVM_VERSION`
tests can also be updated, but there are no suitable ones to simplify.
Ubuntu 25.10 also has a recent enough Rust toolchain [5], and they also
provide versioned packages with a Rust 1.85.1 toolchain even back to
Ubuntu 22.04 LTS [6].
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://www.debian.org/releases/trixie/ [4]
Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=rustc [5]
Link: https://launchpad.net/ubuntu/+source/rustc-1.85 [6]
Acked-by: Tamir Duberstein <tamird@kernel.org>
Acked-by: Benno Lossin <lossin@kernel.org>
Acked-by: Gary Guo <gary@garyguo.net>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260405235309.418950-6-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
These were likely copied from the `bindings` and `uapi` crates, but are
unneeded since there are no `cfg(test)`s in the bindings.
In addition, the issue that triggered the addition in those crates
originally is also fixed in `bindgen` (please see the previous commit).
Thus remove them.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260405235309.418950-5-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The issue that required `allow`s for `cfg(test)` code generated by
`bindgen` for layout testing was fixed back in `bindgen` 0.60.0 [1],
so it could have been removed even before the version bump, but it does
not hurt.
Thus remove it now.
Link: https://github.com/rust-lang/rust-bindgen/pull/2203 [1]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260405235309.418950-4-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
There is a workaround that has not been needed, even already after commit
08ab786556 ("rust: bindgen: upgrade to 0.65.1"), but it does not hurt.
Thus remove it.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260405235309.418950-3-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
