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:
 <MRWPR09MB8022AC9E976367CC04A28C688F85A@MRWPR09MB8022.eurprd09.prod.outlook.com>
Date: Thu, 8 Jan 2026 11:49:46 +0000
From: Pnina Feder <PNINA.FEDER@...ileye.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: "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>, "peterz@...radead.org"
	<peterz@...radead.org>, "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

> On Wed,  7 Jan 2026 23:56:59 +0200 Pnina Feder <pnina.feder@...ileye.com> > 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.
> > 
> > Changes since v3:
> >  - Dump original CPU's stack before redirecting to preserve debug info
> >  - Add Documentation/admin-guide/kernel-parameters.txt entry
> >  - Use smp_call_function_single_async() to avoid blocking in 
> > csd_lock()
> >  - Add CONFIG_CRASH_DUMP dependency
> >  - Reuse vpanic()'s static buffer instead of separate allocation
> >  - Remove verbose warning messages
> 
> Looking nice to my eye.

Thanks!

> > +#if defined(CONFIG_SMP) && defined(CONFIG_CRASH_DUMP)
> 
> Congrats on caring about uniprocessor ;)
> 
> > +/* CPU to redirect panic to, or -1 if disabled */ static int 
> > +panic_force_cpu = -1; static call_single_data_t panic_csd;
> > +
> > +static int __init panic_force_cpu_setup(char *str) {
> > +	int cpu;
> > +
> > +	if (!str)
> > +		return -EINVAL;
> > +
> > +	if (kstrtoint(str, 0, &cpu) || cpu < 0) {
> > +		pr_warn("panic_force_cpu: invalid value '%s'\n", str);
> > +		return -EINVAL;
> > +	}
> > +
> > +	panic_force_cpu = cpu;
> > +	return 0;
> > +}
> > +early_param("panic_force_cpu", panic_force_cpu_setup);
> > +
> > +static void do_panic_on_target_cpu(void *info) {
> > +	panic("%s", (char *)info);
> 
> Probably the (char *) cast isn't needed?

You're right, removed.

> > +}
> > +
> > +/**
> > + * panic_force_target_cpu - Redirect panic to a specific CPU for 
> > +crash kernel
> > + * @fmt: panic message format string
> > + * @args: arguments for format string
> 
> `make htmldocs' is going to get upset about missing docs for `buf' and `buf_size'?

Fixed.

Will send v5 with these fixes.

Thanks,
Pnina