linux-kernel - RE: [PATCH v2] 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 for Android: free password hash cracker in your pocket

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

Message-ID:
 <MRWPR09MB8022136D1D3BBA74D3945E648F84A@MRWPR09MB8022.eurprd09.prod.outlook.com>
Date: Wed, 7 Jan 2026 21:27:19 +0000
From: Pnina Feder <PNINA.FEDER@...ileye.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: "pmladek@...e.com" <pmladek@...e.com>, "senozhatsky@...omium.org"
	<senozhatsky@...omium.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, kernel test robot <lkp@...el.com>, Vladimir
 Kondratiev <Vladimir.Kondratiev@...ileye.com>
Subject: RE: [PATCH v2] panic: add panic_force_cpu= parameter to redirect
 panic to a specific CPU

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@...el.com>
> > Closes: 
> > https://lore.kernel.org/oe-kbuild-all/202601041820.6M8cIq2e-lkp@intel.
> > com/
> > Signed-off-by: Pnina Feder <pnina.feder@...ileye.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