rust/kernel/print.rs | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
The safety comments in `rust_fmt_argument` and `call_printk` were
previously marked as TODO.
This patch adds the missing safety documentation explaining why
dereferencing the pointers and calling the C `_printk` function
is safe in these contexts. It clarifies the contract between
`lib/vsprintf.c` and the Rust implementation regarding the `%pA`
format specifier.
Signed-off-by: Muchamad Coirul Anwar <muchamadcoirulanwar@gmail.com>
---
rust/kernel/print.rs | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/rust/kernel/print.rs b/rust/kernel/print.rs
index 6fd84389a858..3e6ff8f42d95 100644
--- a/rust/kernel/print.rs
+++ b/rust/kernel/print.rs
@@ -29,7 +29,11 @@
use fmt::Write;
// SAFETY: The C contract guarantees that `buf` is valid if it's less than `end`.
let mut w = unsafe { RawFormatter::from_ptrs(buf.cast(), end.cast()) };
- // SAFETY: TODO.
+ // SAFETY: The C implementation of `vsprintf` (in `lib/vsprintf.c`) specifically
+ // calls this function ONLY when processing the `%pA` format specifier.
+ // On the Rust side (`call_printk`), we guarantee that `%pA` is always paired
+ // with a valid pointer to `fmt::Arguments`.
+ // Therefore, dereferencing `ptr` here is safe.
let _ = w.write_fmt(unsafe { *ptr.cast::<fmt::Arguments<'_>>() });
w.pos().cast()
}
@@ -109,7 +113,9 @@ pub unsafe fn call_printk(
) {
// `_printk` does not seem to fail in any path.
#[cfg(CONFIG_PRINTK)]
- // SAFETY: TODO.
+ // SAFETY: The format string is constructed to use `%pA`, which corresponds to the
+ // pointer to `fmt::Arguments` passed as the third argument.
+ // Since `args` is a valid reference, casting it to a pointer is safe.
unsafe {
bindings::_printk(
format_string.as_ptr(),
--
2.50.0
On Thu, Feb 05, 2026 at 11:21:32AM +0700, Muchamad Coirul Anwar wrote:
> The safety comments in `rust_fmt_argument` and `call_printk` were
> previously marked as TODO.
>
> This patch adds the missing safety documentation explaining why
> dereferencing the pointers and calling the C `_printk` function
> is safe in these contexts. It clarifies the contract between
> `lib/vsprintf.c` and the Rust implementation regarding the `%pA`
> format specifier.
>
> Signed-off-by: Muchamad Coirul Anwar <muchamadcoirulanwar@gmail.com>
> ---
> rust/kernel/print.rs | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/rust/kernel/print.rs b/rust/kernel/print.rs
> index 6fd84389a858..3e6ff8f42d95 100644
> --- a/rust/kernel/print.rs
> +++ b/rust/kernel/print.rs
> @@ -29,7 +29,11 @@
> use fmt::Write;
> // SAFETY: The C contract guarantees that `buf` is valid if it's less than `end`.
> let mut w = unsafe { RawFormatter::from_ptrs(buf.cast(), end.cast()) };
> - // SAFETY: TODO.
> + // SAFETY: The C implementation of `vsprintf` (in `lib/vsprintf.c`) specifically
> + // calls this function ONLY when processing the `%pA` format specifier.
> + // On the Rust side (`call_printk`), we guarantee that `%pA` is always paired
> + // with a valid pointer to `fmt::Arguments`.
> + // Therefore, dereferencing `ptr` here is safe.
There are multiple places that %pA is passed. For example, there is also
seq_file.rs and probably more.
Perhaps remove the reference to call_printk here?
// SAFETY: The C implementation of `vsprintf` (in `lib/vsprintf.c`) specifically
// calls this function ONLY when processing the `%pA` format specifier.
// On the Rust side, we always pair `%pA` with a valid pointer to
// `fmt::Arguments`.
> let _ = w.write_fmt(unsafe { *ptr.cast::<fmt::Arguments<'_>>() });
> w.pos().cast()
> }
> @@ -109,7 +113,9 @@ pub unsafe fn call_printk(
> ) {
> // `_printk` does not seem to fail in any path.
> #[cfg(CONFIG_PRINTK)]
> - // SAFETY: TODO.
> + // SAFETY: The format string is constructed to use `%pA`, which corresponds to the
> + // pointer to `fmt::Arguments` passed as the third argument.
> + // Since `args` is a valid reference, casting it to a pointer is safe.
> unsafe {
> bindings::_printk(
> format_string.as_ptr(),
> --
> 2.50.0
>
© 2016 - 2026 Red Hat, Inc.