RE: [PATCH v2] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU

Pnina Feder
2026-01-07T21:27:23Z

Hi Andrew,

> > Some platforms require panic handling to execute on a specific CPU for
> > crash dump to work reliably. This can be due to firmware limitations,
> > interrupt routing constraints, or platform-specific requirements where
> > only a single CPU is able to safely enter the crash kernel.
> >
> > Add support for redirecting panic execution to a designated CPU via a
> > kernel command-line parameter.
>
> Let's tell changelog readers what that command line parameter is called.

Will add "panic_force_cpu=" to the changelog in v4.

> > When the parameter is provided, the CPU that initially triggers panic
> > forwards the panic context to the target CPU, which then proceeds with
> > the normal panic and kexec flow.
> >
> > If the specified CPU is invalid, offline, or a panic is already in
> > progress on another CPU, the redirection is skipped and panic
> > continues on the current CPU.
>
> Well I like it. Others may not ;)

Thanks! Petr raised concerns about smp_call_function_single() safety -
I've switched to smp_call_function_single_async() in v4.

> > Changes since v1:
> > - Replace Kconfig option with a kernel command-line parameter
> > - Fix clang format warning reported by kernel test robot
> >
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes:
> > https://lore.kernel.org/oe-kbuild-all/202601041820.6M8cIq2e-lkp@intel.
> > com/
> > Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
> > ---
> > kernel/panic.c | 93
> > ++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Please update Documentation/admin-guide/kernel-parameters.txt?

Done in v4.

> > +__printf(1, 0)
> > +static bool panic_force_target_cpu(const char *fmt, va_list args) {
> > + static char panic_redirect_msg[1024];
>
> It's sad to chew 1k of everyone's RAM for this.
> smp_call_function_single() is synchronous, yes? Can we reduce that message a lot and use automatic storage?
>
> Or perhaps kmalloc the storage if the user provided the panic_force_cpu kernel parameter?

I'm now reusing vpanic()'s existing static buf[1024] - passing it as a
parameter to panic_force_target_cpu(). This avoids any additional memory
allocation.

> > + int cpu = raw_smp_processor_id();
> > + int target_cpu = panic_force_cpu;
> > +
> > + /* Feature not enabled via boot parameter */
> > + if (target_cpu < 0)
> > + return true;
> > +
> > + /* Already on target CPU - proceed normally */
> > + if (cpu == target_cpu)
> > + return true;
> > +
> > + /* Target CPU is offline, can't redirect */
> > + if (!cpu_online(target_cpu)) {
> > + pr_warn("panic: target CPU %d is offline, proceeding on CPU %d.\n"
>
> "panic: <lowercase>..."
>
> > + "Crash kernel console output may be unavailable.\n", target_cpu, cpu);
> > + return true;
> > + }
> > +
> > + /* Another panic already in progress */
> > + if (panic_in_progress()) {
> > + pr_warn("panic: Another panic in progress on CPU %d, cannot redirect to CPU %d.\n"
>
> "panic: <uppercase>..."
>
> boy, was that a nit!
>

I've removed the verbose warning messages per Petr's feedback -
the redirection will silently fall back to local panic,
matching vpanic()'s behavior.

Thanks for the review!

Pnina