[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260108074857.GD272712@noisy.programming.kicks-ass.net>
Date: Thu, 8 Jan 2026 08:48:57 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Pnina Feder <pnina.feder@...ileye.com>
Cc: akpm@...ux-foundation.org, pmladek@...e.com, bhe@...hat.com,
linux-kernel@...r.kernel.org, lkp@...el.com, mgorman@...e.de,
mingo@...hat.com, rostedt@...dmis.org, senozhatsky@...omium.org,
tglx@...utronix.de, vkondra@...ileye.com
Subject: Re: [PATCH v4] panic: add panic_force_cpu= parameter to redirect
panic to a specific CPU
On Wed, Jan 07, 2026 at 11:56:59PM +0200, Pnina Feder wrote:
> 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 the panic_force_cpu= kernel command-line parameter to redirect panic
> execution to a designated CPU. When the parameter is provided, the CPU
> that initially triggers panic forwards the panic context to the target
> CPU via IPI, 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.
This seems exceedingly fragile to me. Who is saying the target CPU is
even responsive? At the very least this should be an arch callback such
that it can use NMIs where available.
Also, if this is a 'requirement' for kexec or the like, this shouldn't
be a command line argument, but something that's set-up by kexec itself
for functional reasons.
> + panic_force_cpu=
> + [KNL,SMP] Force panic handling to execute on a specific CPU.
> + Format: <cpu number>
> + Some platforms require panic handling to occur on a
> + specific CPU for the crash kernel to function correctly.
> + This can be due to firmware limitations, interrupt routing
> + constraints, or platform-specific requirements where only
> + a particular CPU can safely enter the crash kernel.
> + When set, panic() will redirect execution to the specified
> + CPU before proceeding with the normal panic and kexec flow.
> + If the target CPU is offline or unavailable, panic proceeds
> + on the current CPU.
It this stays; it should have a warning that it makes the panic less reliable.
Powered by blists - more mailing lists