print: use new #[export] macro for rust_fmt_argument

This moves the rust_fmt_argument function over to use the new #[export]
macro, which will verify at compile-time that the function signature
matc

print: use new #[export] macro for rust_fmt_argument

This moves the rust_fmt_argument function over to use the new #[export]
macro, which will verify at compile-time that the function signature
matches what is in the header file.

Reviewed-by: Andreas Hindborg <[email protected]>
Reviewed-by: Tamir Duberstein <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Acked-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Removed period as requested by Andy. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: fix signature of rust_fmt_argument

Without this change, the rest of this series will emit the following
error message:

error[E0308]: `if` and `else` have incompatible types
--> <linux>/rust

rust: fix signature of rust_fmt_argument

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 <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Acked-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: cleanup unnecessary casts

With `long` mapped to `isize`, `size_t`/`__kernel_size_t` mapped to
`usize` and `char` mapped to `u8`, many of the existing casts are no
longer necessary.

Signed-off

rust: cleanup unnecessary casts

With `long` mapped to `isize`, `size_t`/`__kernel_size_t` mapped to
`usize` and `char` mapped to `u8`, many of the existing casts are no
longer necessary.

Signed-off-by: Gary Guo <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Moved `uaccess` changes to the previous commit, since they were
irrefutable patterns that Rust >= 1.82.0 warns about. Removed a
couple casts that now use `c""` literals. Rebased on top of
`rust-next`. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

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

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 <[email protected]>
Cc: Urgau <[email protected]>
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 <[email protected]>
Reviewed-by: Trevor Gross <[email protected]>
Tested-by: Gary Guo <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: enable Clippy's `check-private-items`

In Rust 1.76.0, Clippy added the `check-private-items` lint configuration
option. When turned on (the default is off), it makes several lints
check privat

rust: enable Clippy's `check-private-items`

In Rust 1.76.0, Clippy added the `check-private-items` lint configuration
option. When turned on (the default is off), it makes several lints
check private items as well.

In our case, it affects two lints we have enabled [1]:
`missing_safety_doc` and `unnecessary_safety_doc`.

It also seems to affect the new `too_long_first_doc_paragraph` lint [2],
even though the documentation does not mention it.

Thus allow the few instances remaining we currently hit and enable
the lint.

Link: https://doc.rust-lang.org/nightly/clippy/lint_configuration.html#check-private-items [1]
Link: https://rust-lang.github.io/rust-clippy/master/index.html#/too_long_first_doc_paragraph [2]
Reviewed-by: Trevor Gross <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Tested-by: Gary Guo <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: enable `clippy::undocumented_unsafe_blocks` lint

Checking that we are not missing any `// SAFETY` comments in our `unsafe`
blocks is something we have wanted to do for a long time, as well as

rust: enable `clippy::undocumented_unsafe_blocks` lint

Checking that we are not missing any `// SAFETY` comments in our `unsafe`
blocks is something we have wanted to do for a long time, as well as
cleaning up the remaining cases that were not documented [1].

Back when Rust for Linux started, this was something that could have
been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0,
Clippy implemented the `undocumented_unsafe_blocks` lint [2].

Even though the lint has a few false positives, e.g. in some cases where
attributes appear between the comment and the `unsafe` block [3], there
are workarounds and the lint seems quite usable already.

Thus enable the lint now.

We still have a few cases to clean up, so just allow those for the moment
by writing a `TODO` comment -- some of those may be good candidates for
new contributors.

Link: https://github.com/Rust-for-Linux/linux/issues/351 [1]
Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2]
Link: https://github.com/rust-lang/rust-clippy/issues/13189 [3]
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Trevor Gross <[email protected]>
Tested-by: Gary Guo <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: kernel: use docs.kernel.org links in code documentation

Use links to docs.kernel.org instead of www.kernel.org/doc/html/latest
in the code documentation. The links are shorter and cleaner.

Li

rust: kernel: use docs.kernel.org links in code documentation

Use links to docs.kernel.org instead of www.kernel.org/doc/html/latest
in the code documentation. The links are shorter and cleaner.

Link: https://github.com/Rust-for-Linux/linux/issues/1101
Signed-off-by: Michael Vetter <[email protected]>
[ Reworded slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: kernel: remove redundant imports

Rust's `unused_imports` lint covers both unused and redundant imports.
In the upcoming 1.78.0, the lint detects more cases of redundant imports
[1], e.g.:

rust: kernel: remove redundant imports

Rust's `unused_imports` lint covers both unused and redundant imports.
In the upcoming 1.78.0, the lint detects more cases of redundant imports
[1], e.g.:

error: the item `bindings` is imported redundantly
--> rust/kernel/print.rs:38:9
|
38 | use crate::bindings;
| ^^^^^^^^^^^^^^^ the item `bindings` is already defined by prelude

Most cases are `use crate::bindings`, plus a few other items like `Box`.
Thus clean them up.

Note that, in the `bindings` case, the message "defined by prelude"
above means the extern prelude, i.e. the `--extern` flags we pass.

Link: https://github.com/rust-lang/rust/pull/117772 [1]
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: support `srctree`-relative links

Some of our links use relative paths in order to point to files in the
source tree, e.g.:

//! C header: [`include/linux/printk.h`](../../../../include/lin

rust: support `srctree`-relative links

Some of our links use relative paths in order to point to files in the
source tree, e.g.:

//! C header: [`include/linux/printk.h`](../../../../include/linux/printk.h)
/// [`struct mutex`]: ../../../../include/linux/mutex.h

These are problematic because they are hard to maintain and do not support
`O=` builds.

Instead, provide support for `srctree`-relative links, e.g.:

//! C header: [`include/linux/printk.h`](srctree/include/linux/printk.h)
/// [`struct mutex`]: srctree/include/linux/mutex.h

The links are fixed after `rustdoc` generation to be based on the absolute
path to the source tree.

Essentially, this is the automatic version of Tomonori's fix [1],
suggested by Gary [2].

Suggested-by: Gary Guo <[email protected]>
Reported-by: FUJITA Tomonori <[email protected]>
Closes: https://lore.kernel.org/r/[email protected] [1]
Fixes: 48fadf440075 ("docs: Move rustdoc output, cross-reference it")
Link: https://lore.kernel.org/rust-for-linux/20231026154525.6d14b495@eugeo/ [2]
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: print: use explicit link in documentation

The future `rustdoc` in the Rust 1.73.0 upgrade requires an explicit
link for `pr_info!`:

error: unresolved link to `pr_info`
--> rust/ker

rust: print: use explicit link in documentation

The future `rustdoc` in the Rust 1.73.0 upgrade requires an explicit
link for `pr_info!`:

error: unresolved link to `pr_info`
--> rust/kernel/print.rs:395:63
|
395 | /// Use only when continuing a previous `pr_*!` macro (e.g. [`pr_info!`]).
| ^^^^^^^^ no item named `pr_info` in scope
|
= note: `macro_rules` named `pr_info` exists in this crate, but it is not in scope at this link's location
= note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings`

Thus do so to avoid a broken link while upgrading.

Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Vincenzo Palazzo <[email protected]>
Reviewed-by: Finn Behrens <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: kernel: Mark rust_fmt_argument as extern "C"

The rust_fmt_argument function is called from printk() to handle the %pA
format specifier.

Since it's called from C, we should mark it extern "C"

rust: kernel: Mark rust_fmt_argument as extern "C"

The rust_fmt_argument function is called from printk() to handle the %pA
format specifier.

Since it's called from C, we should mark it extern "C" to make sure it's
ABI compatible.

Cc: [email protected]
Fixes: 247b365dc8dc ("rust: add `kernel` crate")
Signed-off-by: David Gow <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Reviewed-by: Björn Roy Baron <[email protected]>
Reviewed-by: Vincenzo Palazzo <[email protected]>
[Applied `rustfmt`]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: print: avoid evaluating arguments in `pr_*` macros in `unsafe` blocks

At the moment it is possible to perform unsafe operations in
the arguments of `pr_*` macros since they are evaluated insid

rust: print: avoid evaluating arguments in `pr_*` macros in `unsafe` blocks

At the moment it is possible to perform unsafe operations in
the arguments of `pr_*` macros since they are evaluated inside
an `unsafe` block:

let x = &10u32 as *const u32;
pr_info!("{}", *x);

In other words, this is a soundness issue.

Fix it so that it requires an explicit `unsafe` block.

Reported-by: Wedson Almeida Filho <[email protected]>
Reported-by: Domen Puncer Kugler <[email protected]>
Link: https://github.com/Rust-for-Linux/linux/issues/479
Signed-off-by: Miguel Ojeda <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Reviewed-by: Björn Roy Baron <[email protected]>
Reviewed-by: Vincenzo Palazzo <[email protected]>

show more ...

rust: print: add `pr_cont!` macro

This level is a bit different from the rest since it does not
pass the module name to the `_printk()` call.

Thus add a new parameter to the general `print_macro!`

rust: print: add `pr_cont!` macro

This level is a bit different from the rest since it does not
pass the module name to the `_printk()` call.

Thus add a new parameter to the general `print_macro!` to
handle it differently.

Co-developed-by: Adam Bratschi-Kaye <[email protected]>
Signed-off-by: Adam Bratschi-Kaye <[email protected]>
Co-developed-by: Wedson Almeida Filho <[email protected]>
Signed-off-by: Wedson Almeida Filho <[email protected]>
Co-developed-by: Gary Guo <[email protected]>
Signed-off-by: Gary Guo <[email protected]>
Reviewed-by: Wei Liu <[email protected]>
Reviewed-by: Sergio González Collado <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: print: add more `pr_*!` levels

Currently, only `pr_info!` (for the minimal sample) and
`pr_emerg!` (for the panic handler) are there.

Add the other levels as new macros, i.e. `pr_alert!`, `pr

rust: print: add more `pr_*!` levels

Currently, only `pr_info!` (for the minimal sample) and
`pr_emerg!` (for the panic handler) are there.

Add the other levels as new macros, i.e. `pr_alert!`, `pr_crit!`,
`pr_err!`, `pr_warn!`, `pr_notice!` and `pr_debug!`.

Co-developed-by: Adam Bratschi-Kaye <[email protected]>
Signed-off-by: Adam Bratschi-Kaye <[email protected]>
Co-developed-by: Wedson Almeida Filho <[email protected]>
Signed-off-by: Wedson Almeida Filho <[email protected]>
Co-developed-by: Gary Guo <[email protected]>
Signed-off-by: Gary Guo <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Reviewed-by: Wei Liu <[email protected]>
Reviewed-by: Sergio Gonzalez Collado <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: add `kernel` crate

The `kernel` crate currently includes all the abstractions that wrap
kernel features written in C.

These abstractions call the C side of the kernel via the generated
bindin

rust: add `kernel` crate

The `kernel` crate currently includes all the abstractions that wrap
kernel features written in C.

These abstractions call the C side of the kernel via the generated
bindings with the `bindgen` tool. Modules developed in Rust should
never call the bindings themselves.

In the future, as the abstractions grow in number, we may need
to split this crate into several, possibly following a similar
subdivision in subsystems as the kernel itself and/or moving
the code to the actual subsystems.

Reviewed-by: Greg Kroah-Hartman <[email protected]>
Co-developed-by: Alex Gaynor <[email protected]>
Signed-off-by: Alex Gaynor <[email protected]>
Co-developed-by: Geoffrey Thomas <[email protected]>
Signed-off-by: Geoffrey Thomas <[email protected]>
Co-developed-by: Finn Behrens <[email protected]>
Signed-off-by: Finn Behrens <[email protected]>
Co-developed-by: Adam Bratschi-Kaye <[email protected]>
Signed-off-by: Adam Bratschi-Kaye <[email protected]>
Co-developed-by: Sven Van Asbroeck <[email protected]>
Signed-off-by: Sven Van Asbroeck <[email protected]>
Co-developed-by: Gary Guo <[email protected]>
Signed-off-by: Gary Guo <[email protected]>
Co-developed-by: Boris-Chengbiao Zhou <[email protected]>
Signed-off-by: Boris-Chengbiao Zhou <[email protected]>
Co-developed-by: Boqun Feng <[email protected]>
Signed-off-by: Boqun Feng <[email protected]>
Co-developed-by: Fox Chen <[email protected]>
Signed-off-by: Fox Chen <[email protected]>
Co-developed-by: Viktor Garske <[email protected]>
Signed-off-by: Viktor Garske <[email protected]>
Co-developed-by: Dariusz Sosnowski <[email protected]>
Signed-off-by: Dariusz Sosnowski <[email protected]>
Co-developed-by: Léo Lanteri Thauvin <[email protected]>
Signed-off-by: Léo Lanteri Thauvin <[email protected]>
Co-developed-by: Niklas Mohrin <[email protected]>
Signed-off-by: Niklas Mohrin <[email protected]>
Co-developed-by: Milan Landaverde <[email protected]>
Signed-off-by: Milan Landaverde <[email protected]>
Co-developed-by: Morgan Bartlett <[email protected]>
Signed-off-by: Morgan Bartlett <[email protected]>
Co-developed-by: Maciej Falkowski <[email protected]>
Signed-off-by: Maciej Falkowski <[email protected]>
Co-developed-by: Nándor István Krácser <[email protected]>
Signed-off-by: Nándor István Krácser <[email protected]>
Co-developed-by: David Gow <[email protected]>
Signed-off-by: David Gow <[email protected]>
Co-developed-by: John Baublitz <[email protected]>
Signed-off-by: John Baublitz <[email protected]>
Co-developed-by: Björn Roy Baron <[email protected]>
Signed-off-by: Björn Roy Baron <[email protected]>
Signed-off-by: Wedson Almeida Filho <[email protected]>
Co-developed-by: Miguel Ojeda <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...