From 1f9ed172545687e5c04c77490a45896be6d2e459 Mon Sep 17 00:00:00 2001 From: Miguel Ojeda Date: Wed, 4 Sep 2024 22:43:45 +0200 Subject: rust: start using the `#[expect(...)]` attribute 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 `expect`s 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 `allow`s should not have been there. Thus, enable `lint_reasons` and convert some of our `allow`s to `expect`s 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 Cc: Urgau 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 Reviewed-by: Trevor Gross Tested-by: Gary Guo Reviewed-by: Gary Guo Link: https://lore.kernel.org/r/20240904204347.168520-18-ojeda@kernel.org Signed-off-by: Miguel Ojeda --- rust/kernel/lib.rs | 1 + 1 file changed, 1 insertion(+) (limited to 'rust/kernel/lib.rs') diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs index b5f4b3ce6b48..f329638fc5e0 100644 --- a/rust/kernel/lib.rs +++ b/rust/kernel/lib.rs @@ -14,6 +14,7 @@ #![no_std] #![feature(coerce_unsized)] #![feature(dispatch_from_dyn)] +#![feature(lint_reasons)] #![feature(new_uninit)] #![feature(receiver_trait)] #![feature(unsize)] -- cgit v1.2.3 From c95bbb59a9b22f9b838b15d28319185c1c884329 Mon Sep 17 00:00:00 2001 From: Gary Guo Date: Sun, 15 Sep 2024 14:26:31 +0100 Subject: rust: enable arbitrary_self_types and remove `Receiver` The term "receiver" means that a type can be used as the type of `self`, and thus enables method call syntax `foo.bar()` instead of `Foo::bar(foo)`. Stable Rust as of today (1.81) enables a limited selection of types (primitives and types in std, e.g. `Box` and `Arc`) to be used as receivers, while custom types cannot. We want the kernel `Arc` type to have the same functionality as the Rust std `Arc`, so we use the `Receiver` trait (gated behind `receiver_trait` unstable feature) to gain the functionality. The `arbitrary_self_types` RFC [1] (tracking issue [2]) is accepted and it will allow all types that implement a new `Receiver` trait (different from today's unstable trait) to be used as receivers. This trait will be automatically implemented for all `Deref` types, which include our `Arc` type, so we no longer have to opt-in to be used as receiver. To prepare us for the change, remove the `Receiver` implementation and the associated feature. To still allow `Arc` and others to be used as method receivers, turn on `arbitrary_self_types` feature instead. This feature gate is introduced in 1.23.0. It used to enable both `Deref` types and raw pointer types to be used as receivers, but the latter is now split into a different feature gate in Rust 1.83 nightly. We do not need receivers on raw pointers so this change would not affect us and usage of `arbitrary_self_types` feature would work for all Rust versions that we support (>=1.78). Cc: Adrian Taylor Link: https://github.com/rust-lang/rfcs/pull/3519 [1] Link: https://github.com/rust-lang/rust/issues/44874 [2] Signed-off-by: Gary Guo Reviewed-by: Benno Lossin Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20240915132734.1653004-1-gary@garyguo.net Signed-off-by: Miguel Ojeda --- rust/kernel/lib.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'rust/kernel/lib.rs') diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs index f329638fc5e0..3e4bd6e57bee 100644 --- a/rust/kernel/lib.rs +++ b/rust/kernel/lib.rs @@ -12,11 +12,11 @@ //! do so first instead of bypassing this crate. #![no_std] +#![feature(arbitrary_self_types)] #![feature(coerce_unsized)] #![feature(dispatch_from_dyn)] #![feature(lint_reasons)] #![feature(new_uninit)] -#![feature(receiver_trait)] #![feature(unsize)] // Ensure conditional compilation based on the kernel configuration works; -- cgit v1.2.3 From ce1c54fdff7c4556b08f5b875a331d8952e8b6b7 Mon Sep 17 00:00:00 2001 From: Aliet Exposito Garcia Date: Wed, 18 Sep 2024 18:51:14 -0400 Subject: rust: kernel: move `FromBytes` and `AsBytes` traits to a new `transmute` module Refactor the `FromBytes` and `AsBytes` traits from `types.rs` into a new `transmute.rs` module: - Add `rust/kernel/transmute.rs` with the definitions of `FromBytes` and `AsBytes`. - Remove the same trait definitions from `rust/kernel/types.rs`. - Update `rust/kernel/uaccess.rs` to import `AsBytes` and `FromBytes` from `transmute.rs`. The traits and their implementations remain unchanged. Suggested-by: Benno Lossin Link: https://github.com/Rust-for-Linux/linux/issues/1117 Signed-off-by: Aliet Exposito Garcia Reviewed-by: Fiona Behrens Reviewed-by: Benno Lossin Link: https://lore.kernel.org/r/20240918225115.2309224-2-aliet.exposito@gmail.com [ Rebased on top of the lints series and slightly reworded. - Miguel ] Signed-off-by: Miguel Ojeda --- rust/kernel/lib.rs | 1 + 1 file changed, 1 insertion(+) (limited to 'rust/kernel/lib.rs') diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs index 3e4bd6e57bee..dc37aef6a008 100644 --- a/rust/kernel/lib.rs +++ b/rust/kernel/lib.rs @@ -54,6 +54,7 @@ pub mod str; pub mod sync; pub mod task; pub mod time; +pub mod transmute; pub mod types; pub mod uaccess; pub mod workqueue; -- cgit v1.2.3 From e8c6ccdbcaaf31f26c0fffd4073edd0b0147cdc6 Mon Sep 17 00:00:00 2001 From: Danilo Krummrich Date: Fri, 4 Oct 2024 17:41:17 +0200 Subject: rust: alloc: remove extension of std's `Box` Now that all existing `Box` users were moved to the kernel `Box` type, remove the `BoxExt` extension and all other related extensions. Reviewed-by: Alice Ryhl Reviewed-by: Benno Lossin Reviewed-by: Gary Guo Signed-off-by: Danilo Krummrich Link: https://lore.kernel.org/r/20241004154149.93856-14-dakr@kernel.org Signed-off-by: Miguel Ojeda --- rust/kernel/lib.rs | 1 - 1 file changed, 1 deletion(-) (limited to 'rust/kernel/lib.rs') diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs index dc37aef6a008..34e9151db58d 100644 --- a/rust/kernel/lib.rs +++ b/rust/kernel/lib.rs @@ -16,7 +16,6 @@ #![feature(coerce_unsized)] #![feature(dispatch_from_dyn)] #![feature(lint_reasons)] -#![feature(new_uninit)] #![feature(unsize)] // Ensure conditional compilation based on the kernel configuration works; -- cgit v1.2.3 From 2aac4cd7dae3d7bb0e0ddec2561b2ee4cbe6c8f6 Mon Sep 17 00:00:00 2001 From: Danilo Krummrich Date: Fri, 4 Oct 2024 17:41:20 +0200 Subject: rust: alloc: implement kernel `Vec` type `Vec` provides a contiguous growable array type with contents allocated with the kernel's allocators (e.g. `Kmalloc`, `Vmalloc` or `KVmalloc`). In contrast to Rust's stdlib `Vec` type, the kernel `Vec` type considers the kernel's GFP flags for all appropriate functions, always reports allocation failures through `Result<_, AllocError>` and remains independent from unstable features. [ This patch starts using a new unstable feature, `inline_const`, but it was stabilized in Rust 1.79.0, i.e. the next version after the minimum one, thus it will not be an issue. - Miguel ] Reviewed-by: Benno Lossin Reviewed-by: Gary Guo Signed-off-by: Danilo Krummrich Link: https://lore.kernel.org/r/20241004154149.93856-17-dakr@kernel.org [ Cleaned `rustdoc` unescaped backtick warning, added a couple more backticks elsewhere, fixed typos, sorted `feature`s, rewrapped documentation lines. - Miguel ] Signed-off-by: Miguel Ojeda --- rust/kernel/lib.rs | 1 + 1 file changed, 1 insertion(+) (limited to 'rust/kernel/lib.rs') diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs index 34e9151db58d..620de74d128f 100644 --- a/rust/kernel/lib.rs +++ b/rust/kernel/lib.rs @@ -15,6 +15,7 @@ #![feature(arbitrary_self_types)] #![feature(coerce_unsized)] #![feature(dispatch_from_dyn)] +#![feature(inline_const)] #![feature(lint_reasons)] #![feature(unsize)] -- cgit v1.2.3 From 8b55dc8610acf816a66373be53ca6e3bbe2d313a Mon Sep 17 00:00:00 2001 From: Yutaro Ohno Date: Mon, 21 Oct 2024 11:58:47 +0900 Subject: rust: kernel: fix THIS_MODULE header path in ThisModule doc comment The doc comment for `ThisModule` incorrectly states the C header file for `THIS_MODULE` as `include/linux/export.h`, while the correct path is `include/linux/init.h`. This is because `THIS_MODULE` was moved in commit 5b20755b7780 ("init: move THIS_MODULE from to "). Update the doc comment for `ThisModule` to reflect the correct header file path for `THIS_MODULE`. Fixes: 5b20755b7780 ("init: move THIS_MODULE from to ") Signed-off-by: Yutaro Ohno Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/ZxXDZwxWgoEiIYkj@ohnotp Signed-off-by: Miguel Ojeda --- rust/kernel/lib.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'rust/kernel/lib.rs') diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs index 620de74d128f..b62451f64f6e 100644 --- a/rust/kernel/lib.rs +++ b/rust/kernel/lib.rs @@ -85,7 +85,7 @@ pub trait Module: Sized + Sync + Send { /// Equivalent to `THIS_MODULE` in the C API. /// -/// C header: [`include/linux/export.h`](srctree/include/linux/export.h) +/// C header: [`include/linux/init.h`](srctree/include/linux/init.h) pub struct ThisModule(*mut bindings::module); // SAFETY: `THIS_MODULE` may be used from all threads within a module. -- cgit v1.2.3 From d072acda4862f095ec9056979b654cc06a22cc68 Mon Sep 17 00:00:00 2001 From: Gary Guo Date: Fri, 13 Sep 2024 22:29:23 +0100 Subject: rust: use custom FFI integer types 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 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 --- rust/kernel/lib.rs | 2 ++ 1 file changed, 2 insertions(+) (limited to 'rust/kernel/lib.rs') diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs index b62451f64f6e..bf8d7f841f94 100644 --- a/rust/kernel/lib.rs +++ b/rust/kernel/lib.rs @@ -27,6 +27,8 @@ compile_error!("Missing kernel configuration for conditional compilation"); // Allow proc-macros to refer to `::kernel` inside the `kernel` crate (this crate). extern crate self as kernel; +pub use ffi; + pub mod alloc; #[cfg(CONFIG_BLOCK)] pub mod block; -- cgit v1.2.3