Re: [PATCH v7 4/6] panic: restore variable arguments to nmi_panic()

[Petr Mladek <pmladek@suse.com>]

On Wed 2026-09-16 18:29:55, Bradley Morgan wrote:
> nmi_panic() used to accept variable arguments until commit
> ebc41f20d77f ("panic: change nmi_panic from macro to function")
> flattened it to a final message string. vpanic() did not exist back
> then, so the function had to format through panic("%s", msg).
> 
> Bring the variable arguments back and format with vpanic() directly.
> The next patch makes nmi_panic() try the panic_force_cpu= redirect
> before claiming panic_cpu, which needs the arguments twice: once to
> format the message for the redirected CPU and once for vpanic() when
> no redirect happens. Passing a final string would lose that.

The reasoning is not correct. It would be perfectly fine to pass
the final string.

I would write something like:

<paste>
Bring the variable arguments back and format with vpanic() directly.
The next patch makes nmi_panic() try the panic_force_cpu= redirect before
claiming panic_cpu. panic_try_force_cpu() needs to print the message but
it is used also by panic() which accepts variable argument list.
The string could be formatted only when a CPU gets assigned to process
the redirection.  Otherwise, there might be a race when writing to
the `panic_force_buf`.
</paste>

> No current caller passes a string with format specifiers. The closest
> one is hpwdt_pretimeout(), which builds panic_msg with hex_byte_pack()
> and has only two variants, both plain strings. But the new __printf()
> annotation on nmi_panic() would warn with -Wformat-security there
> because the buffer is passed directly as the format argument, so
> switch it to nmi_panic(regs, "%s", panic_msg).
> 
> Suggested-by: Petr Mladek <pmladek@suse.com>
> Signed-off-by: Bradley Morgan <brads@mainlining.org>

With the updated commit message:

Reviewed-by: Petr Mladek <pmladek@suse.com>

Best Regards,
Petr