kernel/linux.git/rust, branch v6.12.80

rust: pin-init: internal: init: document load-bearing fact of field accessors

2026-04-02T11:09:50+00:00

commit 580cc37b1de4fcd9997c48d7080e744533f09f36 upstream. The functions `[Pin]Init::__[pinned_]init` and `ptr::write` called from the `init!` macro require the passed pointer to be aligned. This fact is ensured by the creation of field accessors to previously initialized fields. Since we missed this very important fact from the beginning [1], document it in the code. Link: https://rust-for-linux.zulipchat.com/#narrow/channel/561532-pin-init/topic/initialized.20field.20accessor.20detection/with/576210658 [1] Fixes: 90e53c5e70a6 ("rust: add pin-init API core") Cc: # 6.6.y, 6.12.y: 42415d163e5d: rust: pin-init: add references to previously initialized fields Cc: # 6.6.y, 6.12.y, 6.18.y, 6.19.y Signed-off-by: Benno Lossin Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260302140424.4097655-2-lossin@kernel.org [ Updated Cc: stable@ tags as discussed. - Miguel ] Signed-off-by: Miguel Ojeda [ Moved changes to the declarative macro, because 6.19.y and earlier do not have `syn`. Also duplicated the comment for all field accessor creations. - Benno ] Signed-off-by: Benno Lossin Signed-off-by: Greg Kroah-Hartman

rust: pin-init: add references to previously initialized fields

2026-04-02T11:09:50+00:00

commit 42415d163e5df6db799c7de6262d707e402c2c7e upstream. After initializing a field in an initializer macro, create a variable holding a reference that points at that field. The type is either `Pin<&mut T>` or `&mut T` depending on the field's structural pinning kind. [ Applied fixes to devres and rust_driver_pci sample - Benno] Reviewed-by: Danilo Krummrich Signed-off-by: Benno Lossin [ Removed the devres changes, because devres is not present in 6.12.y and earlier. Also adjusted paths in the macro to account for the fact that pin-init is part of the kernel crate in 6.12.y and earlier. - Benno ] Signed-off-by: Benno Lossin Signed-off-by: Greg Kroah-Hartman

rust: kunit: fix warning when !CONFIG_PRINTK

2026-03-13T16:20:40+00:00

[ Upstream commit 7dd34dfc8dfa92a7244242098110388367996ac3 ] If `CONFIG_PRINTK` is not set, then the following warnings are issued during build: warning: unused variable: `args` --> ../rust/kernel/kunit.rs:16:12 | 16 | pub fn err(args: fmt::Arguments<'_>) { | ^^^^ help: if this is intentional, prefix it with an underscore: `_args` | = note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default warning: unused variable: `args` --> ../rust/kernel/kunit.rs:32:13 | 32 | pub fn info(args: fmt::Arguments<'_>) { | ^^^^ help: if this is intentional, prefix it with an underscore: `_args` Fix this by adding a no-op assignment using `args` when `CONFIG_PRINTK` is not set. Fixes: a66d733da801 ("rust: support running Rust documentation tests as KUnit ones") Signed-off-by: Alexandre Courbot Reviewed-by: Alice Ryhl Reviewed-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin

rust: kbuild: pass `-Zunstable-options` for Rust 1.95.0

2026-03-04T12:21:54+00:00

[ Upstream commit 0a9be83e57de0d0ca8ca4ec610bc344f17a8e5e7 ] Custom target specifications are unstable, but starting with Rust 1.95.0, `rustc` requires to explicitly pass `-Zunstable-options` to use them [1]: error: error loading target specification: custom targets are unstable and require `-Zunstable-options` | = help: run `rustc --print target-list` for a list of built-in targets David (Rust compiler team lead), writes: "We're destabilising custom targets to allow us to move forward with build-std without accidentally exposing functionality that we'd like to revisit prior to committing to. I'll start a thread on Zulip to discuss with the RfL team how we can come up with an alternative for them." Thus pass it. Cc: David Wood Cc: Wesley Wiser Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/151534 [1] Reviewed-by: Gary Guo Tested-by: Gary Guo Link: https://patch.msgid.link/20260206204535.39431-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin

rust: rbtree: fix documentation typo in CursorMut peek_next method

2026-02-06T15:55:44+00:00

commit 45f6aed8a835ee2bdd0a5d5ee626a91fe285014f upstream. The peek_next method's doc comment incorrectly stated it accesses the "previous" node when it actually accesses the next node. Fix the documentation to accurately reflect the method's behavior. Fixes: 98c14e40e07a ("rust: rbtree: add cursor") Reviewed-by: Alice Ryhl Signed-off-by: Hang Shu Reported-by: Miguel Ojeda Closes: https://github.com/Rust-for-Linux/linux/issues/1205 Cc: stable@vger.kernel.org Reviewed-by: Gary Guo Link: https://patch.msgid.link/20251107093921.3379954-1-m18080292938@163.com [ Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

rust: kbuild: workaround `rustdoc` doctests modifier bug

2025-11-24T09:36:07+00:00

[ Upstream commit fad472efab0a805dd939f017c5b8669a786a4bcf ] The `rustdoc` modifiers bug [1] was fixed in Rust 1.90.0 [2], for which we added a workaround in commit abbf9a449441 ("rust: workaround `rustdoc` target modifiers bug"). However, `rustdoc`'s doctest generation still has a similar issue [3], being fixed at [4], which does not affect us because we apply the workaround to both, and now, starting with Rust 1.91.0 (released 2025-10-30), `-Zsanitizer` is a target modifier too [5], which means we fail with: RUSTDOC TK rust/kernel/lib.rs error: mixing `-Zsanitizer` will cause an ABI mismatch in crate `kernel` --> rust/kernel/lib.rs:3:1 | 3 | //! The `kernel` crate. | ^ | = help: the `-Zsanitizer` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely = note: unset `-Zsanitizer` in this crate is incompatible with `-Zsanitizer=kernel-address` in dependency `core` = help: set `-Zsanitizer=kernel-address` in this crate or unset `-Zsanitizer` in `core` = help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=sanitizer` to silence this error A simple way around is to add the sanitizer to the list in the existing workaround (especially if we had not started to pass the sanitizer flags in the previous commit, since in that case that would not be necessary). However, that still applies the workaround in more cases than necessary. Instead, only modify the doctests flags to ignore the check for sanitizers, so that it is more local (and thus the compiler keeps checking it for us in the normal `rustdoc` calls). Since the previous commit already treated the `rustdoc` calls as kernel objects, this should allow us in the future to easily remove this workaround when the time comes. By the way, the `-Cunsafe-allow-abi-mismatch` flag overwrites previous ones rather than appending, so it needs to be all done in the same flag. Moreover, unknown modifiers are rejected, and thus we have to gate based on the version too. Finally, `-Zsanitizer-cfi-normalize-integers` is not affected (in Rust 1.91.0), so it is not needed in the workaround for the moment. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/issues/144521 [1] Link: https://github.com/rust-lang/rust/pull/144523 [2] Link: https://github.com/rust-lang/rust/issues/146465 [3] Link: https://github.com/rust-lang/rust/pull/148068 [4] Link: https://github.com/rust-lang/rust/pull/138736 [5] Reviewed-by: Alice Ryhl Tested-by: Justin M. Forbes Link: https://patch.msgid.link/20251102212853.1505384-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda [ added --remap-path-prefix comments missing in stable branch ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

rust: kbuild: treat `build_error` and `rustdoc` as kernel objects

2025-11-24T09:36:07+00:00

[ Upstream commit 16c43a56b79e2c3220b043236369a129d508c65a ] Even if normally `build_error` isn't a kernel object, it should still be treated as such so that we pass the same flags. Similarly, `rustdoc` targets are never kernel objects, but we need to treat them as such. Otherwise, starting with Rust 1.91.0 (released 2025-10-30), `rustc` will complain about missing sanitizer flags since `-Zsanitizer` is a target modifier too [1]: error: mixing `-Zsanitizer` will cause an ABI mismatch in crate `build_error` --> rust/build_error.rs:3:1 | 3 | //! Build-time error. | ^ | = help: the `-Zsanitizer` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely = note: unset `-Zsanitizer` in this crate is incompatible with `-Zsanitizer=kernel-address` in dependency `core` = help: set `-Zsanitizer=kernel-address` in this crate or unset `-Zsanitizer` in `core` = help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=sanitizer` to silence this error Thus explicitly mark them as kernel objects. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/138736 [1] Reviewed-by: Alice Ryhl Tested-by: Justin M. Forbes Link: https://patch.msgid.link/20251102212853.1505384-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda [ Adjust context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

rust: Add -fno-isolate-erroneous-paths-dereference to bindgen_skip_c_flags

2025-11-24T09:35:49+00:00

[ Upstream commit fe4b3a34e9a9654d98d274218dac0270779db0ae ] It's used to work around an objtool issue since commit abb2a5572264 ("LoongArch: Add cflag -fno-isolate-erroneous-paths-dereference"), but it's then passed to bindgen and cause an error because Clang does not have this option. Fixes: abb2a5572264 ("LoongArch: Add cflag -fno-isolate-erroneous-paths-dereference") Acked-by: Miguel Ojeda Tested-by: Mingcong Bai Signed-off-by: Xi Ruoyao Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin

mm/ksm: fix flag-dropping behavior in ksm_madvise

2025-10-23T14:20:47+00:00

commit f04aad36a07cc17b7a5d5b9a2d386ce6fae63e93 upstream. syzkaller discovered the following crash: (kernel BUG) [ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460 [ 44.617726] Call Trace: [ 44.617926] [ 44.619284] userfaultfd_release+0xef/0x1b0 [ 44.620976] __fput+0x3f9/0xb60 [ 44.621240] fput_close_sync+0x110/0x210 [ 44.622222] __x64_sys_close+0x8f/0x120 [ 44.622530] do_syscall_64+0x5b/0x2f0 [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227 Kernel panics because it detects UFFD inconsistency during userfaultfd_release_all(). Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags. The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags. Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VM_MERGEABLE assignment. VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value. Fix it by changing `VM_MERGEABLE` constant to unsigned long, using the BIT() macro. Note: other VM_* flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_* flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s. Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place: [ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067 but the root-cause (flag-drop) remains the same. [akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel] Link: https://lore.kernel.org/oe-kbuild-all/202510030449.VfSaAjvd-lkp@intel.com/ Link: https://lkml.kernel.org/r/20251001090353.57523-2-acsjakub@amazon.de Fixes: 7677f7fd8be7 ("userfaultfd: add minor fault registration mode") Signed-off-by: Jakub Acs Signed-off-by: Miguel Ojeda Acked-by: David Hildenbrand Acked-by: SeongJae Park Tested-by: Alice Ryhl Tested-by: Miguel Ojeda Cc: Xu Xin Cc: Chengming Zhou Cc: Peter Xu Cc: Axel Rasmussen Cc: Signed-off-by: Andrew Morton [acsjakub@amazon.de: adjust context in bindgings_helper.h] Signed-off-by: Jakub Acs Signed-off-by: Greg Kroah-Hartman

rust: block: fix `srctree/` links

2025-10-12T10:57:16+00:00

commit 208d7f788e84e80992d7b1c82ff17b620eb1371e upstream. This `srctree/` link pointed to a file with an underscore, but the header used a dash instead. Thus fix it. This cleans a future warning that will check our `srctree/` links. Cc: stable@vger.kernel.org Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module") Reviewed-by: Daniel Almeida Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman