deepin/v6.12.53-rebased

GGreg Kroah-Hartmanrust: block: fix srctree/ links

e005b52b创建于 2025年10月12日历史提交

文件	最后提交记录	最后更新时间
bindings	rust: clean Rust 1.88.0's unnecessary_transmutes lint commit 7129ea6e242b00938532537da41ddf5fa3e21471 upstream. Starting with Rust 1.88.0 (expected 2025-06-26) [1][2], rustc may introduce a new lint that catches unnecessary transmutes, e.g.: error: unnecessary transmute --> rust/uapi/uapi_generated.rs:23242:18 | 23242 | unsafe { ::core::mem::transmute(self._bitfield_1.get(0usize, 1u8) as u8) } | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: replace this with: (self._bitfield_1.get(0usize, 1u8) as u8 == 1) | = note: -D unnecessary-transmutes implied by -D warnings = help: to override -D warnings add #[allow(unnecessary_transmutes)] There are a lot of them (at least 300), but luckily they are all in bindgen-generated code. Thus clean all up by allowing it there. Since unknown lints trigger a lint itself in older compilers, do it conditionally so that we can keep the unknown_lints lint enabled. 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/136083 [1] Link: https://github.com/rust-lang/rust/issues/136067 [2] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250502140237.1659624-4-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	1 年前
helpers	rust: alloc: implement KVmalloc allocator commit 8362c2608ba1be635ffa22a256dfcfe51c6238cc upstream. Implement Allocator for KVmalloc, an Allocator that tries to allocate memory with kmalloc first and, on failure, falls back to vmalloc. All memory allocations made with KVmalloc end up in kvrealloc_noprof(); all frees in kvfree(). Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-10-dakr@kernel.org [ Reworded typo. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	1 年前
kernel	rust: block: fix srctree/ links 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 <daniel.almeida@collabora.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	8 个月前
macros	rust: use #[used(compiler)] to fix build and modpost with Rust >= 1.89.0 commit 7498159226772d66f150dd406be462d75964a366 upstream. Starting with Rust 1.89.0 (expected 2025-08-07), the Rust compiler fails to build the rusttest target due to undefined references such as: kernel...-cgu.0:(.text....+0x116): undefined reference to rust_helper_kunit_get_current_test' Moreover, tooling like modpost gets confused: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/nova/nova.o ERROR: modpost: missing MODULE_LICENSE() in drivers/gpu/nova-core/nova_core.o The reason behind both issues is that the Rust compiler will now [1] treat #[used] as #[used(linker)] instead of #[used(compiler)] for our targets. This means that the retain section flag (R, SHF_GNU_RETAIN) will be used and that they will be marked as unique too, with different IDs. In turn, that means we end up with undefined references that did not get discarded in rusttest and that multiple .modinfo sections are generated, which confuse tooling like modpost because they only expect one. Thus start using #[used(compiler)] to keep the previous behavior and to be explicit about what we want. Sadly, it is an unstable feature (used_with_arg) [2] -- we will talk to upstream Rust about it. The good news is that it has been available for a long time (Rust >= 1.60) [3]. The changes should also be fine for previous Rust versions, since they behave the same way as before [4]. Alternatively, we could use #[no_mangle] or #[export_name = ...] since those still behave like #[used(compiler)]`, but of course it is not really what we want to express, and it requires other changes to avoid symbol conflicts. Cc: David Wood <david@davidtw.co> Cc: Wesley Wiser <wwiser@gmail.com> 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/140872 [1] Link: https://github.com/rust-lang/rust/issues/93798 [2] Link: https://github.com/rust-lang/rust/pull/91504 [3] Link: https://godbolt.org/z/sxzWTMfzW [4] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Link: https://lore.kernel.org/r/20250712160103.1244945-3-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	10 个月前
uapi	rust: clean Rust 1.88.0's unnecessary_transmutes lint commit 7129ea6e242b00938532537da41ddf5fa3e21471 upstream. Starting with Rust 1.88.0 (expected 2025-06-26) [1][2], rustc may introduce a new lint that catches unnecessary transmutes, e.g.: error: unnecessary transmute --> rust/uapi/uapi_generated.rs:23242:18 | 23242 | unsafe { ::core::mem::transmute(self._bitfield_1.get(0usize, 1u8) as u8) } | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: replace this with: (self._bitfield_1.get(0usize, 1u8) as u8 == 1) | = note: -D unnecessary-transmutes implied by -D warnings = help: to override -D warnings add #[allow(unnecessary_transmutes)] There are a lot of them (at least 300), but luckily they are all in bindgen-generated code. Thus clean all up by allowing it there. Since unknown lints trigger a lint itself in older compilers, do it conditionally so that we can keep the unknown_lints lint enabled. 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/136083 [1] Link: https://github.com/rust-lang/rust/issues/136067 [2] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250502140237.1659624-4-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	1 年前
.gitignore	rust: support running Rust documentation tests as KUnit ones Rust has documentation tests: these are typically examples of usage of any item (e.g. function, struct, module...). They are very convenient because they are just written alongside the documentation. For instance: /// Sums two numbers. /// /// /// assert_eq!(mymod::f(10, 20), 30); /// pub fn f(a: i32, b: i32) -> i32 { a + b } In userspace, the tests are collected and run via rustdoc. Using the tool as-is would be useful already, since it allows to compile-test most tests (thus enforcing they are kept in sync with the code they document) and run those that do not depend on in-kernel APIs. However, by transforming the tests into a KUnit test suite, they can also be run inside the kernel. Moreover, the tests get to be compiled as other Rust kernel objects instead of targeting userspace. On top of that, the integration with KUnit means the Rust support gets to reuse the existing testing facilities. For instance, the kernel log would look like: KTAP version 1 1..1 KTAP version 1 # Subtest: rust_doctests_kernel 1..59 # rust_doctest_kernel_build_assert_rs_0.location: rust/kernel/build_assert.rs:13 ok 1 rust_doctest_kernel_build_assert_rs_0 # rust_doctest_kernel_build_assert_rs_1.location: rust/kernel/build_assert.rs:56 ok 2 rust_doctest_kernel_build_assert_rs_1 # rust_doctest_kernel_init_rs_0.location: rust/kernel/init.rs:122 ok 3 rust_doctest_kernel_init_rs_0 ... # rust_doctest_kernel_types_rs_2.location: rust/kernel/types.rs:150 ok 59 rust_doctest_kernel_types_rs_2 # rust_doctests_kernel: pass:59 fail:0 skip:0 total:59 # Totals: pass:59 fail:0 skip:0 total:59 ok 1 rust_doctests_kernel Therefore, add support for running Rust documentation tests in KUnit. Some other notes about the current implementation and support follow. The transformation is performed by a couple scripts written as Rust hostprogs. Tests using the ? operator are also supported as usual, e.g.: /// /// # use kernel::{spawn_work_item, workqueue}; /// spawn_work_item!(workqueue::system(), || pr_info!("x"))?; /// # Ok::<(), Error>(()) /// The tests are also compiled with Clippy under CLIPPY=1, just like normal code, thus also benefitting from extra linting. The names of the tests are currently automatically generated. This allows to reduce the burden for documentation writers, while keeping them fairly stable for bisection. This is an improvement over the rustdoc-generated names, which include the line number; but ideally we would like to get rustdoc to provide the Rust item path and a number (for multiple examples in a single documented Rust item). In order for developers to easily see from which original line a failed doctests came from, a KTAP diagnostic line is printed to the log, containing the location (file and line) of the original test (i.e. instead of the location in the generated Rust file): # rust_doctest_kernel_types_rs_2.location: rust/kernel/types.rs:150 This line follows the syntax for declaring test metadata in the proposed KTAP v2 spec [1], which may be used for the proposed KUnit test attributes API [2]. Thus hopefully this will make migration easier later on (suggested by David [3]). The original line in that test attribute is figured out by providing an anchor (suggested by Boqun [4]). The original file is found by walking the filesystem, checking directory prefixes to reduce the amount of combinations to check, and it is only done once per file. Ambiguities are detected and reported. A notable difference from KUnit C tests is that the Rust tests appear to assert using the usual assert! and assert_eq! macros from the Rust standard library (core). We provide a custom version that forwards the call to KUnit instead. Importantly, these macros do not require passing context, unlike the KUnit C ones (i.e. struct kunit *). This makes them easier to use, and readers of the documentation do not need to care about which testing framework is used. In addition, it may allow us to test third-party code more easily in the future. However, a current limitation is that KUnit does not support assertions in other tasks. Thus we presently simply print an error to the kernel log if an assertion actually failed. This should be revisited to properly fail the test, perhaps saving the context somewhere else, or letting KUnit handle it. Link: https://lore.kernel.org/lkml/20230420205734.1288498-1-rmoar@google.com/ [1] Link: https://lore.kernel.org/linux-kselftest/20230707210947.1208717-1-rmoar@google.com/ [2] Link: https://lore.kernel.org/rust-for-linux/CABVgOSkOLO-8v6kdAGpmYnZUb+LKOX0CtYCo-Bge7r_2YTuXDQ@mail.gmail.com/ [3] Link: https://lore.kernel.org/rust-for-linux/ZIps86MbJF%2FiGIzd@boqun-archlinux/ [4] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>	2 年前
Makefile	rust: workaround rustdoc target modifiers bug commit abbf9a44944171ca99c150adad9361a2f517d3b6 upstream. Starting with Rust 1.88.0 (released 2025-06-26), rustdoc complains about a target modifier mismatch in configurations where -Zfixed-x18 is passed: error: mixing -Zfixed-x18 will cause an ABI mismatch in crate rust_out | = help: the -Zfixed-x18 flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely = note: unset -Zfixed-x18 in this crate is incompatible with -Zfixed-x18= in dependency core = help: set -Zfixed-x18= in this crate or unset -Zfixed-x18 in core = help: if you are sure this will not cause problems, you may use -Cunsafe-allow-abi-mismatch=fixed-x18 to silence this error The reason is that rustdoc was not passing the target modifiers when configuring the session options, and thus it would report a mismatch that did not exist as soon as a target modifier is used in a dependency. We did not notice it in the kernel until now because -Zfixed-x18 has been a target modifier only since 1.88.0 (and it is the only one we use so far). The issue has been reported upstream [1] and a fix has been submitted [2], including a test similar to the kernel case. [ This is now fixed upstream (thanks Guillaume for the quick review), so it will be fixed in Rust 1.90.0 (expected 2025-09-18). - Miguel ] Meanwhile, conditionally pass -Cunsafe-allow-abi-mismatch=fixed-x18 to workaround the issue on our side. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Reported-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Closes: https://lore.kernel.org/rust-for-linux/36cdc798-524f-4910-8b77-d7b9fac08d77@oss.qualcomm.com/ Link: https://github.com/rust-lang/rust/issues/144521 [1] Link: https://github.com/rust-lang/rust/pull/144523 [2] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250727092317.2930617-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	9 个月前
bindgen_parameters	rust: map __kernel_size_t and friends also to usize/isize commit 2fd6f55c048d0c863ffbc8590b1bd2edb5ff13e5 upstream. Currently bindgen has special logic to recognise size_t and ssize_t and map them to Rust usize and isize. Similarly, ptrdiff_t is mapped to isize. However this falls short for __kernel_size_t, __kernel_ssize_t and __kernel_ptrdiff_t. To ensure that they are mapped to usize/isize rather than 32/64 integers depending on platform, blocklist them in bindgen parameters and manually provide their definition. Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Link: https://lore.kernel.org/r/20240913213041.395655-3-gary@garyguo.net [ Formatted comment. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	1 年前
build_error.rs	rust: add build_error crate The build_error crate provides a function build_error which will panic at compile-time if executed in const context and, by default, will cause a build error if not executed at compile time and the optimizer does not optimise away the call. The CONFIG_RUST_BUILD_ASSERT_ALLOW kernel option allows to relax the default build failure and convert it to a runtime check. If the runtime check fails, panic! will be called. Its functionality will be exposed to users as a couple macros in the kernel crate in the following patch, thus some documentation here refers to them for simplicity. Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Wei Liu <wei.liu@kernel.org> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>	3 年前
compiler_builtins.rs	rust: add intrinsics to fix -Os builds Alice reported [1] that an arm64 build failed with: ld.lld: error: undefined symbol: __extendsfdf2 >>> referenced by core.a6f5fc5794e7b7b3-cgu.0 >>> rust/core.o:(<f32>::midpoint) in archive vmlinux.a >>> referenced by core.a6f5fc5794e7b7b3-cgu.0 >>> rust/core.o:(<f32>::midpoint) in archive vmlinux.a ld.lld: error: undefined symbol: __truncdfsf2 >>> referenced by core.a6f5fc5794e7b7b3-cgu.0 >>> rust/core.o:(<f32>::midpoint) in archive vmlinux.a Rust 1.80.0 or later together with CONFIG_CC_OPTIMIZE_FOR_SIZE=y is what triggers it. In addition, x86_64 builds also fail the same way. Similarly, compiling with Rust 1.82.0 (currently in nightly) makes another one appear, possibly due to the LLVM 19 upgrade there: ld.lld: error: undefined symbol: __eqdf2 >>> referenced by core.20495ea57a9f069d-cgu.0 >>> rust/core.o:(<f64>::next_up) in archive vmlinux.a >>> referenced by core.20495ea57a9f069d-cgu.0 >>> rust/core.o:(<f64>::next_down) in archive vmlinux.a Gary adds [1]: > Usually the fix on rustc side is to mark those functions as #[inline] > > All of {midpoint,next_up,next_down} are indeed unstable functions not > marked as inline... Fix all those by adding those intrinsics to our usual workaround. [ Trevor quickly submitted a fix to upstream Rust [2] that has already been merged, to be released in Rust 1.82.0 (2024-10-17). - Miguel ] Cc: Gary Guo <gary@garyguo.net> Reported-by: Alice Ryhl <aliceryhl@google.com> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/x/topic/x/near/455637364 [1] Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://github.com/rust-lang/rust/pull/128749 [2] Link: https://lore.kernel.org/r/20240806150619.192882-1-ojeda@kernel.org [ Shortened Zulip link. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>	1 年前
exports.c	kbuild: rust: remove the alloc crate and GlobalAlloc commit 392e34b6bc22077ef63abf62387ea3e9f39418c1 upstream. Now that we have our own Allocator, Box and Vec types we can remove Rust's alloc crate and the new_uninit unstable feature. Also remove Kmalloc's GlobalAlloc implementation -- we can't remove this in a separate patch, since the alloc crate requires a #[global_allocator] to set, that implements GlobalAlloc. Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-29-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	1 年前
ffi.rs	rust: map long to isize and char to u8 commit 1bae8729e50a900f41e9a1c17ae81113e4cf62b8 upstream. The following FFI types are replaced compared to core::ffi: 1. char type is now always mapped to u8, since kernel uses -funsigned-char on the C code. core::ffi maps it to platform default ABI, which can be either signed or unsigned. 2. long is now always mapped to isize. It's very common in the kernel to use long to represent a pointer-sized integer, and in fact intptr_t is a typedef of long in the kernel. Enforce this mapping rather than mapping to i32/i64 depending on platform can save us a lot of unnecessary casts. Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240913213041.395655-5-gary@garyguo.net [ Moved uaccess changes from the next commit, since they were irrefutable patterns that Rust >= 1.82.0 warns about. Reworded slightly and reformatted a few documentation comments. Rebased on top of rust-next. Added the removal of two casts to avoid Clippy warnings. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	1 年前