linux-kernel - RE: [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <MRWPR09MB80226D4647723C15D4FEC0608F85A@MRWPR09MB8022.eurprd09.prod.outlook.com>
Date: Thu, 8 Jan 2026 20:09:33 +0000
From: Pnina Feder <PNINA.FEDER@...ileye.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"pmladek@...e.com" <pmladek@...e.com>, "bhe@...hat.com" <bhe@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"lkp@...el.com" <lkp@...el.com>, "mgorman@...e.de" <mgorman@...e.de>,
	"mingo@...hat.com" <mingo@...hat.com>, "rostedt@...dmis.org"
	<rostedt@...dmis.org>, "senozhatsky@...omium.org" <senozhatsky@...omium.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>, Vladimir Kondratiev
	<Vladimir.Kondratiev@...ileye.com>
Subject: RE: [PATCH v4] panic: add panic_force_cpu= parameter to redirect
 panic to a specific CPU

Hi Peter,

Thanks for the review.

> > 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.

You're right that this adds a dependency on the target CPU being responsive. However, for platforms where the crash kernel must run on a specific CPU, this is our best-effort solution.
I've taken your advice and made the IPI delivery an overridable __weak function (panic_smp_redirect_cpu),
so architectures with NMI support can provide a more reliable implementation.

> 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.

Since the redirection needs to happen before other CPUs are stopped, would a sysctl be preferable? The user could set it when loading the crash kernel.

> > +	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.

Agreed, I'll add a warning to the documentation in v5.

Thanks,
Pnina