GGreg Kroah-Hartmanrust: block: fix srctree/ links
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
rust: alloc: fix rusttest by providing Cmalloc::aligned_layout too [ Upstream commit 0f580d5d3d9d9cd0953695cd32e43aac3a946338 ] Commit fde578c86281 ("rust: alloc: replace aligned_size() with Kmalloc::aligned_layout()") provides a public aligned_layout function in Kamlloc, but not in Cmalloc, and thus uses of it will trigger an error in rusttest. Such a user appeared in the following commit 22ab0641b939 ("rust: drm: ensure kmalloc() compatible Layout"): error[E0599]: no function or associated item named aligned_layout found for struct alloc::allocator_test::Cmalloc in the current scope --> rust/kernel/drm/device.rs:100:31 | 100 | let layout = Kmalloc::aligned_layout(Layout::new::<Self>()); | ^^^^^^^^^^^^^^ function or associated item not found in Cmalloc | ::: rust/kernel/alloc/allocator_test.rs:19:1 | 19 | pub struct Cmalloc; | ------------------ function or associated item aligned_layout not found for this struct Thus add an equivalent one for Cmalloc. Fixes: fde578c86281 ("rust: alloc: replace aligned_size() with Kmalloc::aligned_layout()") Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250816204215.2719559-1-ojeda@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> | 9 个月前 | |
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 个月前 | |
rust: init: allow dead_code warnings for Rust >= 1.89.0 Starting with Rust 1.89.0 (expected 2025-08-07), the Rust compiler may warn: error: trait MustNotImplDrop is never used --> rust/kernel/init/macros.rs:927:15 | 927 | trait MustNotImplDrop {} | ^^^^^^^^^^^^^^^ | ::: rust/kernel/sync/arc.rs:133:1 | 133 | #[pin_data] | ----------- in this procedural macro expansion | = note: -D dead-code implied by -D warnings = help: to override -D warnings add #[allow(dead_code)] = note: this error originates in the macro $crate::__pin_data which comes from the expansion of the attribute macro pin_data (in Nightly builds, run with -Z macro-backtrace for more info) Thus allow it to clean it up. This does not happen in mainline nor 6.15.y, because there the macro was moved out of the kernel crate, and dead_code warnings are not emitted if the macro is foreign to the crate. Thus this patch is directly sent to stable and intended for 6.12.y only. Similarly, it is not needed in previous LTSs, because there the Rust version is pinned. Acked-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 11 个月前 | |
rust: start using the #[expect(...)] attribute commit 1f9ed172545687e5c04c77490a45896be6d2e459 upstream. In Rust, it is possible to allow particular warnings (diagnostics, lints) locally, making the compiler ignore instances of a given warning within a given function, module, block, etc. It is similar to #pragma GCC diagnostic push + ignored + pop in C: #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wunused-function" static void f(void) {} #pragma GCC diagnostic pop But way less verbose: #[allow(dead_code)] fn f() {} By that virtue, it makes it possible to comfortably enable more diagnostics by default (i.e. outside W= levels) that may have some false positives but that are otherwise quite useful to keep enabled to catch potential mistakes. The #[expect(...)] attribute [1] takes this further, and makes the compiler warn if the diagnostic was _not_ produced. For instance, the following will ensure that, when f() is called somewhere, we will have to remove the attribute: #[expect(dead_code)] fn f() {} If we do not, we get a warning from the compiler: warning: this lint expectation is unfulfilled --> x.rs:3:10 | 3 | #[expect(dead_code)] | ^^^^^^^^^ | = note: #[warn(unfulfilled_lint_expectations)] on by default This means that expects do not get forgotten when they are not needed. See the next commit for more details, nuances on its usage and documentation on the feature. The attribute requires the lint_reasons [2] unstable feature, but it is becoming stable in 1.81.0 (to be released on 2024-09-05) and it has already been useful to clean things up in this patch series, finding cases where the allows should not have been there. Thus, enable lint_reasons and convert some of our allows to expects where possible. This feature was also an example of the ongoing collaboration between Rust and the kernel -- we tested it in the kernel early on and found an issue that was quickly resolved [3]. Cc: Fridtjof Stoldt <xfrednet@gmail.com> Cc: Urgau <urgau@numericable.fr> Link: https://rust-lang.github.io/rfcs/2383-lint-reasons.html#expect-lint-attribute [1] Link: https://github.com/rust-lang/rust/issues/54503 [2] Link: https://github.com/rust-lang/rust/issues/114557 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-18-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: use custom FFI integer types commit d072acda4862f095ec9056979b654cc06a22cc68 upstream. Currently FFI integer types are defined in libcore. This commit creates the ffi crate and asks bindgen to use that crate for FFI integer types instead of core::ffi. This commit is preparatory and no type changes are made in this commit yet. Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240913213041.395655-4-gary@garyguo.net [ Added rustdoc, rusttest and KUnit tests support. Rebased on top of rust-next (e.g. migrated more core::ffi cases). Reworded crate docs slightly and formatted. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: use custom FFI integer types commit d072acda4862f095ec9056979b654cc06a22cc68 upstream. Currently FFI integer types are defined in libcore. This commit creates the ffi crate and asks bindgen to use that crate for FFI integer types instead of core::ffi. This commit is preparatory and no type changes are made in this commit yet. Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240913213041.395655-4-gary@garyguo.net [ Added rustdoc, rusttest and KUnit tests support. Rebased on top of rust-next (e.g. migrated more core::ffi cases). Reworded crate docs slightly and formatted. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: alloc: update module comment of alloc.rs commit 8ae740c3917ff92108df17236b3cf1b9a74bd359 upstream. Before we remove Rust's alloc crate, rewrite the module comment in alloc.rs to avoid a rustdoc warning. Besides that, the module comment in alloc.rs isn't correct anymore, we're no longer extending Rust's alloc crate. 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-28-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: block: introduce kernel::block::mq module Add initial abstractions for working with blk-mq. This patch is a maintained, refactored subset of code originally published by Wedson Almeida Filho <wedsonaf@gmail.com> [1]. [1] https://github.com/wedsonaf/linux/tree/f2cfd2fe0e2ca4e90994f96afe268bbd4382a891/rust/kernel/blk/mq.rs Cc: Wedson Almeida Filho <wedsonaf@gmail.com> Signed-off-by: Andreas Hindborg <a.hindborg@samsung.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20240611114551.228679-2-nmi@metaspace.dk Signed-off-by: Jens Axboe <axboe@kernel.dk> | 2 年前 | |
rust: upgrade to Rust 1.68.2 This is the first upgrade to the Rust toolchain since the initial Rust merge, from 1.62.0 to 1.68.2 (i.e. the latest). # Context The kernel currently supports only a single Rust version [1] (rather than a minimum) given our usage of some "unstable" Rust features [2] which do not promise backwards compatibility. The goal is to reach a point where we can declare a minimum version for the toolchain. For instance, by waiting for some of the features to be stabilized. Therefore, the first minimum Rust version that the kernel will support is "in the future". # Upgrade policy Given we will eventually need to reach that minimum version, it would be ideal to upgrade the compiler from time to time to be as close as possible to that goal and find any issues sooner. In the extreme, we could upgrade as soon as a new Rust release is out. Of course, upgrading so often is in stark contrast to what one normally would need for GCC and LLVM, especially given the release schedule: 6 weeks for Rust vs. half a year for LLVM and a year for GCC. Having said that, there is no particular advantage to updating slowly either: kernel developers in "stable" distributions are unlikely to be able to use their distribution-provided Rust toolchain for the kernel anyway [3]. Instead, by routinely upgrading to the latest instead, kernel developers using Linux distributions that track the latest Rust release may be able to use those rather than Rust-provided ones, especially if their package manager allows to pin / hold back / downgrade the version for some days during windows where the version may not match. For instance, Arch, Fedora, Gentoo and openSUSE all provide and track the latest version of Rust as they get released every 6 weeks. Then, when the minimum version is reached, we will stop upgrading and decide how wide the window of support will be. For instance, a year of Rust versions. We will probably want to start small, and then widen it over time, just like the kernel did originally for LLVM, see commit 3519c4d6e08e ("Documentation: add minimum clang/llvm version"). # Unstable features stabilized This upgrade allows us to remove the following unstable features since they were stabilized: - feature(explicit_generic_args_with_impl_trait) (1.63). - feature(core_ffi_c) (1.64). - feature(generic_associated_types) (1.65). - feature(const_ptr_offset_from) (1.65, *). - feature(bench_black_box) (1.66, *). - feature(pin_macro) (1.68). The ones marked with * apply only to our old rust branch, not mainline yet, i.e. only for code that we may potentially upstream. With this patch applied, the only unstable feature allowed to be used outside the kernel crate is new_uninit, though other code to be upstreamed may increase the list. Please see [2] for details. # Other required changes Since 1.63, rustdoc triggers the broken_intra_doc_links lint for links pointing to exported (#[macro_export]) macro_rules. An issue was opened upstream [4], but it turns out it is intended behavior. For the moment, just add an explicit reference for each link. Later we can revisit this if rustdoc removes the compatibility measure. Nevertheless, this was helpful to discover a link that was pointing to the wrong place unintentionally. Since that one was actually wrong, it is fixed in a previous commit independently. Another change was the addition of cfg(no_rc) and cfg(no_sync) in upstream [5], thus remove our original changes for that. Similarly, upstream now tests that it compiles successfully with #[cfg(not(no_global_oom_handling))] [6], which allow us to get rid of some changes, such as an #[allow(dead_code)]. In addition, remove another #[allow(dead_code)] due to new uses within the standard library. Finally, add try_extend_trusted and move the code in spec_extend.rs since upstream moved it for the infallible version. # alloc upgrade and reviewing There are a large amount of changes, but the vast majority of them are due to our alloc fork being upgraded at once. There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream. Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream. Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions. To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch: # Get the difference with respect to the old version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > old.patch git -C linux restore rust/alloc # Apply this patch. git -C linux am rust-upgrade.patch # Get the difference with respect to the new version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > new.patch git -C linux restore rust/alloc Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended. Link: https://rust-for-linux.com/rust-version-policy [1] Link: https://github.com/Rust-for-Linux/linux/issues/2 [2] Link: https://lore.kernel.org/rust-for-linux/CANiq72mT3bVDKdHgaea-6WiZazd8Mvurqmqegbe5JZxVyLR8Yg@mail.gmail.com/ [3] Link: https://github.com/rust-lang/rust/issues/106142 [4] Link: https://github.com/rust-lang/rust/pull/89891 [5] Link: https://github.com/rust-lang/rust/pull/98652 [6] Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-By: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Tested-by: Ariel Miculas <amiculas@cisco.com> Tested-by: David Gow <davidgow@google.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20230418214347.324156-4-ojeda@kernel.org [ Removed feature(core_ffi_c) from uapi ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> | 3 年前 | |
rust: device: change the from_raw() function The function Device::from_raw() increments a refcount by a call to bindings::get_device(ptr). This can be confused because usually from_raw() functions don't increment a refcount. Hence, rename Device::from_raw() to avoid confuion with other "from_raw" semantics. The new name of function should be "get_device" to be consistent with the function get_device() already exist in .c files. This function body also changed, because the into() will convert the &'a Device into ARef<Device> and also call inc_ref from the AlwaysRefCounted trait implemented for Device. Signed-off-by: Guilherme Giacomo Simoes <trintaeoitogc@gmail.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Closes: https://github.com/Rust-for-Linux/linux/issues/1088 Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20241001205603.106278-1-trintaeoitogc@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: error: add missing newline to pr_warn! calls [ Upstream commit 6f5c36f56d475732981dcf624e0ac0cc7c8984c8 ] Added missing newline at the end of pr_warn! usage so the log is not missed. Fixes: 6551a7fe0acb ("rust: error: Add Error::from_errno{_unchecked}()") Reported-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1139 Signed-off-by: Alban Kurti <kurti@invicto.ai> Link: https://lore.kernel.org/r/20250206-printing_fix-v3-2-a85273b501ae@invicto.ai [ Replaced Closes with Link since it fixes part of the issue. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> | 1 年前 | |
rust: firmware: Use ffi::c_char type in FwFunc commit 53bd97801632c940767f4c8407c2cbdeb56b40e7 upstream. The FwFunc struct contains an function with a char pointer argument, for which a *const u8 pointer was used. This is not really the "proper" type for this, so use a *const kernel::ffi::c_char pointer instead. This has no real functionality changes, since now kernel::ffi::c_char (which bindgen uses for char) is now a type alias to u8 anyways, but before commit 1bae8729e50a ("rust: map long to isize and char to u8") the concrete type of kernel::ffi::c_char depended on the architecture (However all supported architectures at the time mapped to i8). This caused problems on the v6.13 tag when building for 32 bit arm (with my patches), since back then *const i8 was used in the function argument and the function that bindgen generated used *const core::ffi::c_char which Rust mapped to *const u8 on 32 bit arm. The stable v6.13.y branch does not have this issue since commit 1bae8729e50a ("rust: map long to isize and char to u8") was backported. This caused the following build error: `` error[E0308]: mismatched types --> rust/kernel/firmware.rs:20:4 | 20 | Self(bindings::request_firmware) | ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected fn pointer, found fn item | | | arguments to this function are incorrect | = note: expected fn pointer unsafe extern "C" fn(_, *const i8, _) -> _ found fn item unsafe extern "C" fn(_, *const u8, _) -> _ {request_firmware} note: tuple struct defined here --> rust/kernel/firmware.rs:14:8 | 14 | struct FwFunc( | ^^^^^^ error[E0308]: mismatched types --> rust/kernel/firmware.rs:24:14 | 24 | Self(bindings::firmware_request_nowarn) | ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected fn pointer, found fn item | | | arguments to this function are incorrect | = note: expected fn pointer unsafe extern "C" fn(_, *const i8, _) -> _ found fn item unsafe extern "C" fn(_, *const u8, _) -> _ {firmware_request_nowarn} note: tuple struct defined here --> rust/kernel/firmware.rs:14:8 | 14 | struct FwFunc( | ^^^^^^ error[E0308]: mismatched types --> rust/kernel/firmware.rs:64:45 | 64 | let ret = unsafe { func.0(pfw as _, name.as_char_ptr(), dev.as_raw()) }; | ------ ^^^^^^^^^^^^^^^^^^ expected *const i8, found *const u8 | | | arguments to this function are incorrect | = note: expected raw pointer *const i8 found raw pointer *const u8 error: aborting due to 3 previous errors `` Fixes: de6582833db0 ("rust: add firmware abstractions") Cc: stable@vger.kernel.org Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Christian Schrefl <chrisi.schrefl@gmail.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250413-rust_arm_fix_fw_abstaction-v3-1-8dd7c0bbcd47@gmail.com [ Add firmware prefix to commit subject. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: init: add missing newline to pr_info! calls [ Upstream commit 6933c1067fe6df8ddb34dd68bdb2aa172cbd08c8 ] Several pr_info! calls in rust/kernel/init.rs (both in code examples and macro documentation) were missing a newline, causing logs to run together. This commit updates these calls to include a trailing newline, improving readability and consistency with the C side. Fixes: 6841d45a3030 ("rust: init: add stack_pin_init! macro") Fixes: 7f8977a7fe6d ("rust: init: add {pin_}chain functions to {Pin}Init<T, E>") Fixes: d0fdc3961270 ("rust: init: add PinnedDrop trait and macros") Fixes: 4af84c6a85c6 ("rust: init: update expanded macro explanation") Reported-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1139 Signed-off-by: Alban Kurti <kurti@invicto.ai> Link: https://lore.kernel.org/r/20250206-printing_fix-v3-3-a85273b501ae@invicto.ai [ Replaced Closes with Link since it fixes part of the issue. Added one more Fixes tag (still same set of stable kernels). - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> | 1 年前 | |
rust: start using the #[expect(...)] attribute commit 1f9ed172545687e5c04c77490a45896be6d2e459 upstream. In Rust, it is possible to allow particular warnings (diagnostics, lints) locally, making the compiler ignore instances of a given warning within a given function, module, block, etc. It is similar to #pragma GCC diagnostic push + ignored + pop in C: #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wunused-function" static void f(void) {} #pragma GCC diagnostic pop But way less verbose: #[allow(dead_code)] fn f() {} By that virtue, it makes it possible to comfortably enable more diagnostics by default (i.e. outside W= levels) that may have some false positives but that are otherwise quite useful to keep enabled to catch potential mistakes. The #[expect(...)] attribute [1] takes this further, and makes the compiler warn if the diagnostic was _not_ produced. For instance, the following will ensure that, when f() is called somewhere, we will have to remove the attribute: #[expect(dead_code)] fn f() {} If we do not, we get a warning from the compiler: warning: this lint expectation is unfulfilled --> x.rs:3:10 | 3 | #[expect(dead_code)] | ^^^^^^^^^ | = note: #[warn(unfulfilled_lint_expectations)] on by default This means that expects do not get forgotten when they are not needed. See the next commit for more details, nuances on its usage and documentation on the feature. The attribute requires the lint_reasons [2] unstable feature, but it is becoming stable in 1.81.0 (to be released on 2024-09-05) and it has already been useful to clean things up in this patch series, finding cases where the allows should not have been there. Thus, enable lint_reasons and convert some of our allows to expects where possible. This feature was also an example of the ongoing collaboration between Rust and the kernel -- we tested it in the kernel early on and found an issue that was quickly resolved [3]. Cc: Fridtjof Stoldt <xfrednet@gmail.com> Cc: Urgau <urgau@numericable.fr> Link: https://rust-lang.github.io/rfcs/2383-lint-reasons.html#expect-lint-attribute [1] Link: https://github.com/rust-lang/rust/issues/54503 [2] Link: https://github.com/rust-lang/rust/issues/114557 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-18-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: kunit: use C-string literals to clean warning Starting with upstream Rust commit a5e3a3f9b6bd ("move manual_c_str_literals to complexity"), to be released in Rust 1.83.0 [1], Clippy now warns on manual_c_str_literals by default, e.g.: error: manually constructing a nul-terminated string --> rust/kernel/kunit.rs:21:13 | 21 | b"\x013%pA\0".as_ptr() as _, | ^^^^^^^^^^^^^ help: use a c"" literal: c"\x013%pA" | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#manual_c_str_literals = note: -D clippy::manual-c-str-literals implied by -D warnings = help: to override -D warnings add #[allow(clippy::manual_c_str_literals)] Apply the suggestion to clean up the warnings. Link: https://github.com/rust-lang/rust-clippy/pull/13263 [1] Reviewed-by: Trevor Gross <tmgross@umich.edu> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20240927164414.560906-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> | 1 年前 | |
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> | 11 个月前 | |
rust: allow Rust 1.87.0's clippy::ptr_eq lint commit a39f3087092716f2bd531d6fdc20403c3dc2a879 upstream. Starting with Rust 1.87.0 (expected 2025-05-15) [1], Clippy may expand the ptr_eq lint, e.g.: error: use core::ptr::eq when comparing raw pointers --> rust/kernel/list.rs:438:12 | 438 | if self.first == item { | ^^^^^^^^^^^^^^^^^^ help: try: core::ptr::eq(self.first, item) | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_eq = note: -D clippy::ptr-eq implied by -D warnings = help: to override -D warnings add #[allow(clippy::ptr_eq)] It is expected that a PR to relax the lint will be backported [2] by the time Rust 1.87.0 releases, since the lint was considered too eager (at least by default) [3]. Thus allow the lint temporarily just in case. 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-clippy/pull/14339 [1] Link: https://github.com/rust-lang/rust-clippy/pull/14526 [2] Link: https://github.com/rust-lang/rust-clippy/issues/14525 [3] Link: https://lore.kernel.org/r/20250502140237.1659624-3-ojeda@kernel.org [ Converted to allows since backport was confirmed. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: core abstractions for network PHY drivers This patch adds abstractions to implement network PHY drivers; the driver registration and bindings for some of callback functions in struct phy_driver and many genphy_ functions. This feature is enabled with CONFIG_RUST_PHYLIB_ABSTRACTIONS=y. This patch enables unstable const_maybe_uninit_zeroed feature for kernel crate to enable unsafe code to handle a constant value with uninitialized data. With the feature, the abstractions can initialize a phy_driver structure with zero easily; instead of initializing all the members by hand. It's supposed to be stable in the not so distant future. Link: https://github.com/rust-lang/rust/pull/116218 Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 2 年前 | |
rust: add abstraction for struct page Adds a new struct called Page that wraps a pointer to struct page. This struct is assumed to hold ownership over the page, so that Rust code can allocate and manage pages directly. The page type has various methods for reading and writing into the page. These methods will temporarily map the page to allow the operation. All of these methods use a helper that takes an offset and length, performs bounds checks, and returns a pointer to the given offset in the page. This patch only adds support for pages of order zero, as that is all Rust Binder needs. However, it is written to make it easy to add support for higher-order pages in the future. To do that, you would add a const generic parameter to Page that specifies the order. Most of the methods do not need to be adjusted, as the logic for dealing with mapping multiple pages at once can be isolated to just the with_pointer_into_page method. Rust Binder needs to manage pages directly as that is how transactions are delivered: Each process has an mmap'd region for incoming transactions. When an incoming transaction arrives, the Binder driver will choose a region in the mmap, allocate and map the relevant pages manually, and copy the incoming transaction directly into the page. This architecture allows the driver to copy transactions directly from the address space of one process to another, without an intermediate copy to a kernel buffer. This code is based on Wedson's page abstractions from the old rust branch, but it has been modified by Alice by removing the incomplete support for higher-order pages, by introducing the with_* helpers to consolidate the bounds checking logic into a single place, and various other changes. Co-developed-by: Wedson Almeida Filho <wedsonaf@gmail.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240528-alice-mm-v7-4-78222c31b8f4@google.com [ Fixed typos and added a few intra-doc links. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> | 1 年前 | |
rust: alloc: add Vec to prelude commit 3145dc91c3c0ad945f06354385a6eb89d22becdb upstream. Now that we removed VecExt and the corresponding includes in prelude.rs, add the new kernel Vec type instead. 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-22-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: fix signature of rust_fmt_argument [ Upstream commit 901b3290bd4dc35e613d13abd03c129e754dd3dd ] Without this change, the rest of this series will emit the following error message: error[E0308]: if and else have incompatible types --> <linux>/rust/kernel/print.rs:22:22 | 21 | #[export] | --------- expected because of this 22 | unsafe extern "C" fn rust_fmt_argument( | ^^^^^^^^^^^^^^^^^ expected u8, found i8 | = note: expected fn item unsafe extern "C" fn(*mut u8, *mut u8, *mut c_void) -> *mut u8 {bindings::rust_fmt_argument} found fn item unsafe extern "C" fn(*mut i8, *mut i8, *const c_void) -> *mut i8 {print::rust_fmt_argument} The error may be different depending on the architecture. To fix this, change the void pointer argument to use a const pointer, and change the imports to use crate::ffi instead of core::ffi for integer types. Fixes: 787983da7718 ("vsprintf: add new %pA format specifier") Reviewed-by: Tamir Duberstein <tamird@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20250303-export-macro-v3-1-41fbad85a27f@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> | 1 年前 | |
rust: treewide: switch to our kernel Box type commit 8373147ce4961665c5700016b1c76299e962d077 upstream. Now that we got the kernel Box type in place, convert all existing Box users to make use of it. 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-13-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: sizes: add commonly used constants Add rust equivalent to include/linux/sizes.h, makes code more readable. Only SZ_*K that QT2025 PHY driver uses are added. Make generated constants accessible with a proper type. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Trevor Gross <tmgross@umich.edu> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 1 年前 | |
rust: static_assert: add static_assert! macro Add the static_assert! macro, which is a compile-time assert, similar to the C11 _Static_assert and C++11 static_assert declarations [1,2]. Do so in a new module, called static_assert. For instance: static_assert!(42 > 24); static_assert!(core::mem::size_of::<u8>() == 1); const X: &[u8] = b"bar"; static_assert!(X[1] == b'a'); const fn f(x: i32) -> i32 { x + 2 } static_assert!(f(40) == 42); Link: https://en.cppreference.com/w/c/language/_Static_assert [1] Link: https://en.cppreference.com/w/cpp/language/static_assert [2] Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org> | 3 年前 | |
rust: start using the #[expect(...)] attribute commit 1f9ed172545687e5c04c77490a45896be6d2e459 upstream. In Rust, it is possible to allow particular warnings (diagnostics, lints) locally, making the compiler ignore instances of a given warning within a given function, module, block, etc. It is similar to #pragma GCC diagnostic push + ignored + pop in C: #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wunused-function" static void f(void) {} #pragma GCC diagnostic pop But way less verbose: #[allow(dead_code)] fn f() {} By that virtue, it makes it possible to comfortably enable more diagnostics by default (i.e. outside W= levels) that may have some false positives but that are otherwise quite useful to keep enabled to catch potential mistakes. The #[expect(...)] attribute [1] takes this further, and makes the compiler warn if the diagnostic was _not_ produced. For instance, the following will ensure that, when f() is called somewhere, we will have to remove the attribute: #[expect(dead_code)] fn f() {} If we do not, we get a warning from the compiler: warning: this lint expectation is unfulfilled --> x.rs:3:10 | 3 | #[expect(dead_code)] | ^^^^^^^^^ | = note: #[warn(unfulfilled_lint_expectations)] on by default This means that expects do not get forgotten when they are not needed. See the next commit for more details, nuances on its usage and documentation on the feature. The attribute requires the lint_reasons [2] unstable feature, but it is becoming stable in 1.81.0 (to be released on 2024-09-05) and it has already been useful to clean things up in this patch series, finding cases where the allows should not have been there. Thus, enable lint_reasons and convert some of our allows to expects where possible. This feature was also an example of the ongoing collaboration between Rust and the kernel -- we tested it in the kernel early on and found an issue that was quickly resolved [3]. Cc: Fridtjof Stoldt <xfrednet@gmail.com> Cc: Urgau <urgau@numericable.fr> Link: https://rust-lang.github.io/rfcs/2383-lint-reasons.html#expect-lint-attribute [1] Link: https://github.com/rust-lang/rust/issues/54503 [2] Link: https://github.com/rust-lang/rust/issues/114557 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-18-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: clean Rust 1.88.0's clippy::uninlined_format_args lint commit 211dcf77856db64c73e0c3b9ce0c624ec855daca upstream. Starting with Rust 1.88.0 (expected 2025-06-26) [1], rustc may move back the uninlined_format_args to style from pedantic (it was there waiting for rust-analyzer suppotr), and thus we will start to see lints like: warning: variables can be used directly in the format! string --> rust/macros/kunit.rs:105:37 | 105 | let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args help: change this to | 105 - let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test); 105 + let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{test}"); There is even a case that is a pure removal: warning: variables can be used directly in the format! string --> rust/macros/module.rs:51:13 | 51 | format!("{field}={content}\0", field = field, content = content) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args help: change this to | 51 - format!("{field}={content}\0", field = field, content = content) 51 + format!("{field}={content}\0") The lints all seem like nice cleanups, thus just apply them. We may want to disable allow-mixed-uninlined-format-args in the future. 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-clippy/pull/14160 [1] Acked-by: Benno Lossin <lossin@kernel.org> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250502140237.1659624-6-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: lockdep: Remove support for dynamically allocated LockClassKeys commit 966944f3711665db13e214fef6d02982c49bb972 upstream. Currently, dynamically allocated LockCLassKeys can be used from the Rust side without having them registered. This is a soundness issue, so remove them. Fixes: 6ea5aa08857a ("rust: sync: introduce LockClassKey") Suggested-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Mitchell Levy <levymitchell0@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250307232717.1759087-11-boqun.feng@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: use custom FFI integer types commit d072acda4862f095ec9056979b654cc06a22cc68 upstream. Currently FFI integer types are defined in libcore. This commit creates the ffi crate and asks bindgen to use that crate for FFI integer types instead of core::ffi. This commit is preparatory and no type changes are made in this commit yet. Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240913213041.395655-4-gary@garyguo.net [ Added rustdoc, rusttest and KUnit tests support. Rebased on top of rust-next (e.g. migrated more core::ffi cases). Reworded crate docs slightly and formatted. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: use custom FFI integer types commit d072acda4862f095ec9056979b654cc06a22cc68 upstream. Currently FFI integer types are defined in libcore. This commit creates the ffi crate and asks bindgen to use that crate for FFI integer types instead of core::ffi. This commit is preparatory and no type changes are made in this commit yet. Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240913213041.395655-4-gary@garyguo.net [ Added rustdoc, rusttest and KUnit tests support. Rebased on top of rust-next (e.g. migrated more core::ffi cases). Reworded crate docs slightly and formatted. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: use custom FFI integer types commit d072acda4862f095ec9056979b654cc06a22cc68 upstream. Currently FFI integer types are defined in libcore. This commit creates the ffi crate and asks bindgen to use that crate for FFI integer types instead of core::ffi. This commit is preparatory and no type changes are made in this commit yet. Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240913213041.395655-4-gary@garyguo.net [ Added rustdoc, rusttest and KUnit tests support. Rebased on top of rust-next (e.g. migrated more core::ffi cases). Reworded crate docs slightly and formatted. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
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 年前 | |
rust: treewide: switch to our kernel Box type commit 8373147ce4961665c5700016b1c76299e962d077 upstream. Now that we got the kernel Box type in place, convert all existing Box users to make use of it. 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-13-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 |