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

Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
---
 .../admin-guide/kernel-parameters.txt         |  13 +++
 kernel/panic.c                                | 104 ++++++++++++++++++
 2 files changed, 117 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index a8d0afde7f85..561ce09a6ae1 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4753,6 +4753,19 @@ Kernel parameters
 	panic_on_warn=1	panic() instead of WARN().  Useful to cause kdump
 			on a WARN().
 
+	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.
+
 	panic_print=	Bitmask for printing system info when panic happens.
 			User can chose combination of the following bits:
 			bit 0: print all tasks info
diff --git a/kernel/panic.c b/kernel/panic.c
index 0d52210a9e2b..414ef60d2306 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -300,6 +300,103 @@ void __weak crash_smp_send_stop(void)
 
 atomic_t panic_cpu = ATOMIC_INIT(PANIC_CPU_INVALID);
 
+#if defined(CONFIG_SMP) && defined(CONFIG_CRASH_DUMP)
+/* 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);
+}
+
+/**
+ * panic_force_target_cpu - Redirect panic to a specific CPU for crash kernel
+ * @fmt: panic message format string
+ * @args: arguments for format string
+ *
+ * Some platforms require panic handling to occur on a specific CPU
+ * for the crash kernel to function correctly. This function redirects
+ * panic handling to the CPU specified via the panic_redirect_cpu= boot parameter.
+ *
+ * Returns true if panic should proceed on current CPU.
+ * Returns false (never returns) if panic was redirected.
+ */
+__printf(3, 0)
+static bool panic_force_target_cpu(char *buf, int buf_size, const char *fmt, va_list args)
+{
+	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))
+		return true;
+
+	/* Another panic already in progress */
+	if (panic_in_progress())
+		return true;
+
+	vsnprintf(buf, buf_size, fmt, args);
+
+	console_verbose();
+	bust_spinlocks(1);
+
+	pr_emerg("panic: Redirecting from CPU %d to CPU %d for crash kernel\n",
+		cpu, target_cpu);
+
+	/* Dump original CPU's stack before redirecting */
+	if (test_taint(TAINT_DIE) || oops_in_progress > 1) {
+		panic_this_cpu_backtrace_printed = true;
+	} else if (IS_ENABLED(CONFIG_DEBUG_BUGVERBOSE)) {
+		dump_stack();
+		panic_this_cpu_backtrace_printed = true;
+	}
+
+	printk_legacy_allow_panic_sync();
+	console_flush_on_panic(CONSOLE_FLUSH_PENDING);
+
+	panic_csd.func = do_panic_on_target_cpu;
+	panic_csd.info = buf;
+
+	/* Use smp_call_function_single_async() to avoid blocking in csd_lock(). */
+	if (smp_call_function_single_async(target_cpu, &panic_csd) != 0)
+		return true;
+
+	return false;
+}
+#else
+__printf(3, 0)
+static inline bool panic_force_target_cpu(char *buf, int buf_size, const char *fmt, va_list args)
+{
+	return true;
+}
+#endif /* CONFIG_SMP && CONFIG CRASH_DUMP */
+
 bool panic_try_start(void)
 {
 	int old_cpu, this_cpu;
@@ -451,6 +548,13 @@ void vpanic(const char *fmt, va_list args)
 	local_irq_disable();
 	preempt_disable_notrace();
 
+	/*
+	 * Redirect panic to target CPU if configured via panic_force_cpu=.
+	 * Returns false and never returns if panic was redirected.
+	 */
+	if (!panic_force_target_cpu(buf, sizeof(buf), fmt, args))
+		panic_smp_self_stop();
+
 	/*
 	 * It's possible to come here directly from a panic-assertion and
 	 * not have preempt disabled. Some functions called from here want
-- 
2.43.0

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.

On Thu, 8 Jan 2026 08:48:57 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> > +	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. It should probably end with:

              This option should only be used for systems with the above
              constraints as it will cause the panic operation to be less
              reliable.

-- Steve

On 01/07/26 at 11:56pm, 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,

Thanks for fixing this. Could you kindly reveal which platform this
issue is from?

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

What if both the original CPU and specified CPU are not able to function
well on panic jumping? The crash dumping will fail in this case?

> 
> 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
> 
> Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
> ---
>  .../admin-guide/kernel-parameters.txt         |  13 +++
>  kernel/panic.c                                | 104 ++++++++++++++++++
>  2 files changed, 117 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index a8d0afde7f85..561ce09a6ae1 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4753,6 +4753,19 @@ Kernel parameters
>  	panic_on_warn=1	panic() instead of WARN().  Useful to cause kdump
>  			on a WARN().
>  
> +	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.
> +
>  	panic_print=	Bitmask for printing system info when panic happens.
>  			User can chose combination of the following bits:
>  			bit 0: print all tasks info
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 0d52210a9e2b..414ef60d2306 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -300,6 +300,103 @@ void __weak crash_smp_send_stop(void)
>  
>  atomic_t panic_cpu = ATOMIC_INIT(PANIC_CPU_INVALID);
>  
> +#if defined(CONFIG_SMP) && defined(CONFIG_CRASH_DUMP)
> +/* 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);
> +}
> +
> +/**
> + * panic_force_target_cpu - Redirect panic to a specific CPU for crash kernel
> + * @fmt: panic message format string
> + * @args: arguments for format string
> + *
> + * Some platforms require panic handling to occur on a specific CPU
> + * for the crash kernel to function correctly. This function redirects
> + * panic handling to the CPU specified via the panic_redirect_cpu= boot parameter.
> + *
> + * Returns true if panic should proceed on current CPU.
> + * Returns false (never returns) if panic was redirected.
> + */
> +__printf(3, 0)
> +static bool panic_force_target_cpu(char *buf, int buf_size, const char *fmt, va_list args)
> +{
> +	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))
> +		return true;
> +
> +	/* Another panic already in progress */
> +	if (panic_in_progress())
> +		return true;
> +
> +	vsnprintf(buf, buf_size, fmt, args);
> +
> +	console_verbose();
> +	bust_spinlocks(1);
> +
> +	pr_emerg("panic: Redirecting from CPU %d to CPU %d for crash kernel\n",
> +		cpu, target_cpu);
> +
> +	/* Dump original CPU's stack before redirecting */
> +	if (test_taint(TAINT_DIE) || oops_in_progress > 1) {
> +		panic_this_cpu_backtrace_printed = true;
> +	} else if (IS_ENABLED(CONFIG_DEBUG_BUGVERBOSE)) {
> +		dump_stack();
> +		panic_this_cpu_backtrace_printed = true;
> +	}
> +
> +	printk_legacy_allow_panic_sync();
> +	console_flush_on_panic(CONSOLE_FLUSH_PENDING);
> +
> +	panic_csd.func = do_panic_on_target_cpu;
> +	panic_csd.info = buf;
> +
> +	/* Use smp_call_function_single_async() to avoid blocking in csd_lock(). */
> +	if (smp_call_function_single_async(target_cpu, &panic_csd) != 0)
> +		return true;
> +
> +	return false;
> +}
> +#else
> +__printf(3, 0)
> +static inline bool panic_force_target_cpu(char *buf, int buf_size, const char *fmt, va_list args)
> +{
> +	return true;
> +}
> +#endif /* CONFIG_SMP && CONFIG CRASH_DUMP */
> +
>  bool panic_try_start(void)
>  {
>  	int old_cpu, this_cpu;
> @@ -451,6 +548,13 @@ void vpanic(const char *fmt, va_list args)
>  	local_irq_disable();
>  	preempt_disable_notrace();
>  
> +	/*
> +	 * Redirect panic to target CPU if configured via panic_force_cpu=.
> +	 * Returns false and never returns if panic was redirected.
> +	 */
> +	if (!panic_force_target_cpu(buf, sizeof(buf), fmt, args))
> +		panic_smp_self_stop();
> +
>  	/*
>  	 * It's possible to come here directly from a panic-assertion and
>  	 * not have preempt disabled. Some functions called from here want
> -- 
> 2.43.0
>

On Thu, Jan 08, 2026 at 11:11:50AM +0800, Baoquan He wrote:
> On 01/07/26 at 11:56pm, 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,
> 
> Thanks for fixing this. Could you kindly reveal which platform this
> issue is from?
> 
> > 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.
> 
> What if both the original CPU and specified CPU are not able to function
> well on panic jumping? The crash dumping will fail in this case?

Yes.

On Wed,  7 Jan 2026 23:56:59 +0200 Pnina Feder <pnina.feder@mobileye.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.

> +#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?

> +}
> +
> +/**
> + * 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'?

> + * Some platforms require panic handling to occur on a specific CPU
> + * for the crash kernel to function correctly. This function redirects
> + * panic handling to the CPU specified via the panic_redirect_cpu= boot parameter.
> + *
> + * Returns true if panic should proceed on current CPU.
> + * Returns false (never returns) if panic was redirected.
> + */
> +__printf(3, 0)
> +static bool panic_force_target_cpu(char *buf, int buf_size, const char *fmt, va_list args)