Re: [PATCH v4 2/4] rust: print: document safety of _printk FFI calls

On Wed, Jul 29, 2026 at 7:53=E2=80=AFPM cianM167 <[email protected]>=
 wrote:
>
> From: Cian McGuire <[email protected]>
>
> Two calls in this file had their SAFETY comments left as "TODO.": the
> cast back to `fmt::Arguments` in `rust_fmt_argument`, and the call to
> `bindings::_printk` in `call_printk`.
>
> `rust_fmt_argument` is only reachable through the `%pA` format
> specifier. Every in-tree Rust caller that uses `%pA` -- `call_printk`,
> `device::printk`, `kunit::printk`, and `seq_file::call_printf` -- invokes
> it synchronously with a pointer derived from its own live
> `fmt::Arguments`, as one call in a `switch` dispatch in
> `lib/vsprintf.c`'s pointer formatter that returns its result immediately;
> there is no deferred use or storage of the pointer on the C side. So the
> `fmt::Arguments` value stays alive on the caller's stack for the whole
> time `rust_fmt_argument` is running with `ptr` pointing at it.
>
> The `_printk` call itself is justified by this function's `# Safety`
> section, which this patch also tightens: `format_string` must be one of
> the non-continuation `format_strings` statics, not
> `format_strings::CONT`. `call_printk` always supplies two extra
> arguments -- `module_name` for `%s` and `args` for `%pA` -- which only
> matches the `"%s: %pA"` shape shared by every non-continuation string;
> `CONT`'s format string is `"%pA"` only, so passing it here would make
> `_printk` consume `module_name`'s pointer for `%pA` instead, and
> `rust_fmt_argument` would then reinterpret that `*const c_char` as a
> `*const fmt::Arguments` and dereference it. No caller does this today --
> `call_printk` is only reached from `print_macro!`'s non-continuation arm;
> the continuation arm calls the separate, safe `call_printk_cont`, which
> hardcodes `CONT` together with the single argument it expects -- but the
> previous, broader contract permitted it. With `format_string` guaranteed
> non-`CONT`, and `module_name` guaranteed null-terminated by both of its
> possible origins (`kernel::__LOG_PREFIX` and the one generated by the
> `module!` proc macro), the specifiers always match the supplied
> arguments.
>
> Suggested-by: Miguel Ojeda <[email protected]>
> Link: https://github.com/Rust-for-Linux/linux/issues/351
> Signed-off-by: Cian McGuire <[email protected]>

Thanks for the patch!

A few notes:

  - It seems the "From:" in the email (not the Git commit) changed in
v4. Not a big deal, but I am not sure if it is intended.

  - Is there a reason you are sending only 2/4 in the new versions?

    If the patches are independent (and especially if they also target
different subsystems), then it may be best to send them separately.
Otherwise, if you are sending a series, then please re-send the entire
series.

    (Some developers do send sometimes a single update to a long
series in the form of a patch or a diff, but even that is typically
done replying to the original series.)

    For this case, I would suggest resending them separately.

  - Just in case: was the commit, or its message and/or changelog
assisted by an LLM? Please see:

      https://docs.kernel.org/process/generated-content.html
      https://docs.kernel.org/process/coding-assistants.html

Cheers,
Miguel