From: Petr Mladek <pmladek@suse.com>
To: Bradley Morgan <include@grrlz.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Jinchao Wang <wangjinchao600@gmail.com>,
Feng Tang <feng.tang@linux.alibaba.com>,
Rio <rioo.tsukatsukii@gmail.com>,
Pnina Feder <pnina.feder@mobileye.com>,
Petr Pavlu <petr.pavlu@suse.com>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
linux-kernel@vger.kernel.org, Sashiko <sashiko-bot@kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH v6 6/6] panic: kill the "buffer unavailable" redirect fallback
Date: Tue, 25 Aug 2026 11:49:15 +0200 [thread overview]
Message-ID: <ao1lG5wumJJ6FO2T@pathway.suse.cz> (raw)
In-Reply-To: <20260818163806.17460-7-include@grrlz.net>
On Tue 2026-08-18 16:38:06, Bradley Morgan wrote:
> The redirect buffer is a disgusting terrible hack. panic_force_buf is
> kmalloc'ed in a late_initcall, the return value is not even checked,
It is not checked intentionally. kmalloc() prints a debug message
on its own when it is not able to allocate the memory.
And it returns NULL in this case. It is enough in this case.
Please, remove this sentence from the commit message.
> and until then the redirect delivers this as the panic message:
> Redirected panic (buffer unavailable)
>
> The whole point of the redirect is to hand the panic message to the
> target CPU, so the crash kernel boots knowing it panicked and not why.
> And that window is the entire boot, from the early_param to the
> late_initcall, which is exactly when you most want the message. A
> failed kmalloc just keeps it broken forever, silently.
>
> Make it a static 1KB buffer and kill the initcall. The cost is 1KB of
> .bss in SMP crash dump builds, and it is only ever touched when
> panic_force_cpu= is set anyway.
>
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -413,20 +403,12 @@ static bool panic_try_force_cpu(const char *fmt, va_list args)
> return old_cpu != this_cpu;
>
> /*
> - * Use dynamically allocated buffer if available, otherwise
> - * fall back to static message for early boot panics or allocation failure.
> + * Do not consume args, the caller reuses them if we fail.
> */
> - if (panic_force_buf) {
> - va_list ap;
> -
> - /* Do not consume args, the caller reuses it if we fail */
> - va_copy(ap, args);
> - vsnprintf(panic_force_buf, PANIC_MSG_BUFSZ, fmt, ap);
> - va_end(ap);
> - msg = panic_force_buf;
> - } else {
> - msg = "Redirected panic (buffer unavailable)";
> - }
> + va_copy(ap, args);
> + vsnprintf(panic_force_buf, PANIC_MSG_BUFSZ, fmt, ap);
> + va_end(ap);
> + msg = panic_force_buf;
Nit: The "msg" variable is no longer needed. It will always be set to
panic_force_buf. The later code could use:
panic_smp_redirect_cpu(panic_force_cpu, (void *)panic_force_buf)
Otherwise, the change looks good from my POV.
Best Regards,
Petr
next prev parent reply other threads:[~2026-08-25 9:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 16:38 [PATCH v6 0/6] panic: fix panic_force_cpu= redirect races and NMI bypass Bradley Morgan
2026-08-18 16:38 ` [PATCH v6 1/6] panic: fix redirect CPU race in panic_try_force_cpu() Bradley Morgan
2026-08-25 8:27 ` Petr Mladek
2026-08-18 16:38 ` [PATCH v6 2/6] panic: flatten nmi_panic control flow Bradley Morgan
2026-08-18 16:38 ` [PATCH v6 3/6] panic: fix va_list reuse in panic_try_force_cpu() Bradley Morgan
2026-08-18 16:38 ` [PATCH v6 4/6] panic: restore variable arguments to nmi_panic() Bradley Morgan
2026-08-25 9:11 ` Petr Mladek
2026-08-18 16:38 ` [PATCH v6 5/6] panic: allow force_cpu redirect from an NMI Bradley Morgan
2026-08-25 9:28 ` Petr Mladek
2026-08-18 16:38 ` [PATCH v6 6/6] panic: kill the "buffer unavailable" redirect fallback Bradley Morgan
2026-08-25 9:49 ` Petr Mladek [this message]
2026-08-18 18:41 ` [PATCH v6 0/6] panic: fix panic_force_cpu= redirect races and NMI bypass Andrew Morton
2026-08-18 18:45 ` Bradley Morgan
2026-08-25 9:55 ` Petr Mladek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ao1lG5wumJJ6FO2T@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=feng.tang@linux.alibaba.com \
--cc=include@grrlz.net \
--cc=linux-kernel@vger.kernel.org \
--cc=petr.pavlu@suse.com \
--cc=pnina.feder@mobileye.com \
--cc=rioo.tsukatsukii@gmail.com \
--cc=sashiko-bot@kernel.org \
--cc=senozhatsky@chromium.org \
--cc=stable@vger.kernel.org \
--cc=wangjinchao600@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox