linux.git/rust/kernel/print.rs, branch v6.6.131

rust: print: use explicit link in documentation

2024-02-16T18:10:43+00:00

commit a53d8cdd5a0aec75ae32badc2d8995c59ea6e3f0 upstream.

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 
Reviewed-by: Vincenzo Palazzo 
Reviewed-by: Finn Behrens 
Reviewed-by: Martin Rodriguez Reboredo 
Link: https://lore.kernel.org/r/20231005210556.466856-3-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: kernel: Mark rust_fmt_argument as extern "C"

2023-04-06T21:11:04+00:00

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: stable@vger.kernel.org
Fixes: 247b365dc8dc ("rust: add `kernel` crate")
Signed-off-by: David Gow 
Reviewed-by: Gary Guo 
Reviewed-by: Björn Roy Baron 
Reviewed-by: Vincenzo Palazzo 
[Applied `rustfmt`]
Signed-off-by: Miguel Ojeda

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

2023-01-15T23:54:35+00:00

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 
Reported-by: Domen Puncer Kugler 
Link: https://github.com/Rust-for-Linux/linux/issues/479
Signed-off-by: Miguel Ojeda 
Reviewed-by: Boqun Feng 
Reviewed-by: Gary Guo 
Reviewed-by: Björn Roy Baron 
Reviewed-by: Vincenzo Palazzo

rust: print: add `pr_cont!` macro

2022-12-01T19:12:44+00:00

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 
Signed-off-by: Adam Bratschi-Kaye 
Co-developed-by: Wedson Almeida Filho 
Signed-off-by: Wedson Almeida Filho 
Co-developed-by: Gary Guo 
Signed-off-by: Gary Guo 
Reviewed-by: Wei Liu 
Reviewed-by: Sergio González Collado 
Signed-off-by: Miguel Ojeda

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

2022-12-01T19:12:14+00:00

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 
Signed-off-by: Adam Bratschi-Kaye 
Co-developed-by: Wedson Almeida Filho 
Signed-off-by: Wedson Almeida Filho 
Co-developed-by: Gary Guo 
Signed-off-by: Gary Guo 
Reviewed-by: Boqun Feng 
Reviewed-by: Wei Liu 
Reviewed-by: Sergio Gonzalez Collado 
Signed-off-by: Miguel Ojeda

rust: add `kernel` crate

2022-09-28T06:58:24+00:00

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