* Re: [PATCH v3] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-05 8:18 ` [PATCH v3] " Pnina Feder
@ 2026-01-05 16:50 ` Petr Mladek
2026-01-07 21:27 ` Pnina Feder
2026-01-07 21:56 ` [PATCH v4] " Pnina Feder
2026-01-08 20:36 ` [PATCH v5] " Pnina Feder
2 siblings, 1 reply; 29+ messages in thread
From: Petr Mladek @ 2026-01-05 16:50 UTC (permalink / raw)
To: Pnina Feder
Cc: akpm, senozhatsky, linux-kernel, kernel test robot,
Thomas Gleixner, Peter Zijlstra, Ingo Molnar, Steven Rostedt,
Mel Gorman, Baoquan He
Adding more people into Cc. I doubt that smp_call_function_single()
is reliable in panic().
On Mon 2026-01-05 10:18:08, 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 support for redirecting panic execution to a designated CPU via a
> kernel command-line parameter. 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.
>
> Changes since v2:
> - Make panic redirection warnings generic and platform-agnostic
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202601041820.6M8cIq2e-lkp@intel.com/
> Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
> ---
> kernel/panic.c | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 93 insertions(+)
>
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 0d52210a9e2b..6239bcdc2463 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -300,6 +300,92 @@ void __weak crash_smp_send_stop(void)
>
> atomic_t panic_cpu = ATOMIC_INIT(PANIC_CPU_INVALID);
>
> +#ifdef CONFIG_SMP
> +/* CPU to redirect panic to, -1 means feature is disabled */
> +static int panic_force_cpu = -1;
> +
> +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;
> + pr_info("panic_force_cpu: panic will execute on CPU %d\n", 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(1, 0)
> +static bool panic_force_target_cpu(const char *fmt, va_list args)
> +{
> + static char panic_redirect_msg[1024];
> + 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"
> + "Crash kernel interrupts 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"
IMHO, this message does not add much value and should be omitted.
vpanic() does not print any message when panic_try_start() fails.
> + "Crash kernel interrupts may be unavailable.\n",
I am confused by this message.
> + atomic_read(&panic_cpu), target_cpu);
> + return true;
> + }
> +
> + pr_info("panic: Redirecting from CPU %d to CPU %d for crash kernel\n",
> + cpu, target_cpu);
> +
> + vsnprintf(panic_redirect_msg, sizeof(panic_redirect_msg), fmt, args);
The "redirect" in "panic_redirect_msg" is confusing. It has nothing
to do with redirection. It is just a buffer for the formatted panic
message. I would call it "buf" or "panic_msg".
> + smp_call_function_single(target_cpu, do_panic_on_target_cpu, panic_redirect_msg, false);
I doubt that this is safe and reliable in panic() context.
For a start, panic() might be called in NMI and this function takes csd_lock().
panic() code should avoid locks. Or is should use trylock and
handle a failure gracefully.
BTW: The commit message says that this is needed for crash-dump
to work reliably. So, it does not make sense to do this
when crash-dump is not configured.
Maybe, crash-dump should get fixed instead?
What are the exact problems with the crash-dump, please?
> +
> + return false;
> +}
> +#else
> +__printf(1, 0)
> +static inline bool panic_force_target_cpu(const char *fmt, va_list args)
> +{
> + return true;
> +}
> +#endif /* CONFIG_SMP */
> +
> bool panic_try_start(void)
> {
> int old_cpu, this_cpu;
> @@ -451,6 +537,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(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
Best Regards,
Petr
^ permalink raw reply [flat|nested] 29+ messages in thread* RE: [PATCH v3] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-05 16:50 ` Petr Mladek
@ 2026-01-07 21:27 ` Pnina Feder
0 siblings, 0 replies; 29+ messages in thread
From: Pnina Feder @ 2026-01-07 21:27 UTC (permalink / raw)
To: Petr Mladek
Cc: akpm@linux-foundation.org, senozhatsky@chromium.org,
linux-kernel@vger.kernel.org, kernel test robot, Thomas Gleixner,
Peter Zijlstra, Ingo Molnar, Steven Rostedt, Mel Gorman,
Baoquan He, Vladimir Kondratiev
Hi Petr,
> Adding more people into Cc. I doubt that smp_call_function_single() is reliable in panic().
You're right. I've switched to smp_call_function_single_async() which
uses trylock semantics and won't block if the CSD is busy.
> On Mon 2026-01-05 10:18:08, 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 support for redirecting panic execution to a designated CPU via a
> > kernel command-line parameter. 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.
> >
> > Changes since v2:
> > - Make panic redirection warnings generic and platform-agnostic
> >
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes:
> > https://lore.kernel.org/oe-kbuild-all/202601041820.6M8cIq2e-lkp@intel.
> > com/
> > Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
> > ---
> > kernel/panic.c | 93
> > ++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 93 insertions(+)
> >
> > diff --git a/kernel/panic.c b/kernel/panic.c index
> > 0d52210a9e2b..6239bcdc2463 100644
> > --- a/kernel/panic.c
> > +++ b/kernel/panic.c
> > @@ -300,6 +300,92 @@ void __weak crash_smp_send_stop(void)
> >
> > atomic_t panic_cpu = ATOMIC_INIT(PANIC_CPU_INVALID);
> >
> > +#ifdef CONFIG_SMP
> > +/* CPU to redirect panic to, -1 means feature is disabled */ static
> > +int panic_force_cpu = -1;
> > +
> > +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;
> > + pr_info("panic_force_cpu: panic will execute on CPU %d\n", 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(1, 0)
> > +static bool panic_force_target_cpu(const char *fmt, va_list args) {
> > + static char panic_redirect_msg[1024];
> > + 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"
> > + "Crash kernel interrupts 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"
>
> IMHO, this message does not add much value and should be omitted.
> vpanic() does not print any message when panic_try_start() fails.
Agreed, removed in v4.
> > + "Crash kernel interrupts may be unavailable.\n",
>
> I am confused by this message.
Removed along with other verbose warnings.
> > + atomic_read(&panic_cpu), target_cpu);
> > + return true;
> > + }
> > +
> > + pr_info("panic: Redirecting from CPU %d to CPU %d for crash kernel\n",
> > + cpu, target_cpu);
> > +
> > + vsnprintf(panic_redirect_msg, sizeof(panic_redirect_msg), fmt,
> > +args);
>
> The "redirect" in "panic_redirect_msg" is confusing. It has nothing to do with redirection. It is just a buffer for the formatted panic message. I would call it "buf" or "panic_msg".
I'm now reusing vpanic()'s existing static buf[1024], passing it as a
parameter. This also addresses Andrew's concern about the extra 1k
memory allocation.
> > + smp_call_function_single(target_cpu, do_panic_on_target_cpu,
> > +panic_redirect_msg, false);
>
> I doubt that this is safe and reliable in panic() context.
> For a start, panic() might be called in NMI and this function takes csd_lock().
>
> panic() code should avoid locks. Or is should use trylock and handle a failure gracefully.
Changed to smp_call_function_single_async() which returns error instead
of blocking if the CSD is busy. On failure, panic continues locally.
> BTW: The commit message says that this is needed for crash-dump
> to work reliably. So, it does not make sense to do this
> when crash-dump is not configured.
Good point. I've added CONFIG_CRASH_DUMP to the #ifdef in v4.
> Maybe, crash-dump should get fixed instead?
> What are the exact problems with the crash-dump, please?
On some platforms, the interrupt controller configuration for the crash
kernel depends on which CPU executes the panic path. By the time the
crash kernel starts, all secondary CPUs have already been stopped via
smp_send_stop(), so it's too late to fix the routing at that point.
Thanks for the review!
Pnina
^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-05 8:18 ` [PATCH v3] " Pnina Feder
2026-01-05 16:50 ` Petr Mladek
@ 2026-01-07 21:56 ` Pnina Feder
2026-01-07 23:10 ` Andrew Morton
` (3 more replies)
2026-01-08 20:36 ` [PATCH v5] " Pnina Feder
2 siblings, 4 replies; 29+ messages in thread
From: Pnina Feder @ 2026-01-07 21:56 UTC (permalink / raw)
To: akpm
Cc: pmladek, bhe, linux-kernel, lkp, mgorman, mingo, peterz,
pnina.feder, rostedt, senozhatsky, tglx, vkondra
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
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-07 21:56 ` [PATCH v4] " Pnina Feder
@ 2026-01-07 23:10 ` Andrew Morton
2026-01-08 11:49 ` Pnina Feder
2026-01-08 3:11 ` Baoquan He
` (2 subsequent siblings)
3 siblings, 1 reply; 29+ messages in thread
From: Andrew Morton @ 2026-01-07 23:10 UTC (permalink / raw)
To: Pnina Feder
Cc: pmladek, bhe, linux-kernel, lkp, mgorman, mingo, peterz, rostedt,
senozhatsky, tglx, vkondra
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)
^ permalink raw reply [flat|nested] 29+ messages in thread* RE: [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-07 23:10 ` Andrew Morton
@ 2026-01-08 11:49 ` Pnina Feder
0 siblings, 0 replies; 29+ messages in thread
From: Pnina Feder @ 2026-01-08 11:49 UTC (permalink / raw)
To: Andrew Morton
Cc: pmladek@suse.com, bhe@redhat.com, linux-kernel@vger.kernel.org,
lkp@intel.com, mgorman@suse.de, mingo@redhat.com,
peterz@infradead.org, rostedt@goodmis.org,
senozhatsky@chromium.org, tglx@linutronix.de, Vladimir Kondratiev
> 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.
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-07 21:56 ` [PATCH v4] " Pnina Feder
2026-01-07 23:10 ` Andrew Morton
@ 2026-01-08 3:11 ` Baoquan He
2026-01-08 7:49 ` Peter Zijlstra
2026-01-08 12:02 ` Pnina Feder
2026-01-08 7:48 ` Peter Zijlstra
2026-01-09 1:18 ` kernel test robot
3 siblings, 2 replies; 29+ messages in thread
From: Baoquan He @ 2026-01-08 3:11 UTC (permalink / raw)
To: Pnina Feder
Cc: akpm, pmladek, linux-kernel, lkp, mgorman, mingo, peterz, rostedt,
senozhatsky, tglx, vkondra
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
>
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-08 3:11 ` Baoquan He
@ 2026-01-08 7:49 ` Peter Zijlstra
2026-01-08 12:02 ` Pnina Feder
1 sibling, 0 replies; 29+ messages in thread
From: Peter Zijlstra @ 2026-01-08 7:49 UTC (permalink / raw)
To: Baoquan He
Cc: Pnina Feder, akpm, pmladek, linux-kernel, lkp, mgorman, mingo,
rostedt, senozhatsky, tglx, vkondra
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-08 3:11 ` Baoquan He
2026-01-08 7:49 ` Peter Zijlstra
@ 2026-01-08 12:02 ` Pnina Feder
1 sibling, 0 replies; 29+ messages in thread
From: Pnina Feder @ 2026-01-08 12:02 UTC (permalink / raw)
To: Baoquan He
Cc: akpm@linux-foundation.org, pmladek@suse.com,
linux-kernel@vger.kernel.org, lkp@intel.com, mgorman@suse.de,
mingo@redhat.com, peterz@infradead.org, rostedt@goodmis.org,
senozhatsky@chromium.org, tglx@linutronix.de, Vladimir Kondratiev
> > 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?
This is for a custom SoC based on RISC-V, where the console/UART interrupt is routed exclusively to cluster 0 (CPU 0). Due to this hardware design, only CPU 0 can reliably handle console output during the crash kernel entry, making it necessary to redirect panic handling to that specific CPU.
> > 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, in that case crash dumping will fail. However, this is consistent with the existing behavior-if the original panicking CPU cannot function well enough to enter the crash kernel, the dump would fail anyway. This feature simply provides an additional option to attempt redirection to a known-good CPU when it is online and available. If the target CPU is offline or unreachable, we fall back to the regular flow and proceed with the crash on the current CPU, so we're not making the situation any worse.
> > 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
> >
Thanks,
Pnina
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-07 21:56 ` [PATCH v4] " Pnina Feder
2026-01-07 23:10 ` Andrew Morton
2026-01-08 3:11 ` Baoquan He
@ 2026-01-08 7:48 ` Peter Zijlstra
2026-01-08 16:36 ` Steven Rostedt
2026-01-08 20:09 ` Pnina Feder
2026-01-09 1:18 ` kernel test robot
3 siblings, 2 replies; 29+ messages in thread
From: Peter Zijlstra @ 2026-01-08 7:48 UTC (permalink / raw)
To: Pnina Feder
Cc: akpm, pmladek, bhe, linux-kernel, lkp, mgorman, mingo, rostedt,
senozhatsky, tglx, vkondra
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-08 7:48 ` Peter Zijlstra
@ 2026-01-08 16:36 ` Steven Rostedt
2026-01-08 20:14 ` Pnina Feder
2026-01-08 20:09 ` Pnina Feder
1 sibling, 1 reply; 29+ messages in thread
From: Steven Rostedt @ 2026-01-08 16:36 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Pnina Feder, akpm, pmladek, bhe, linux-kernel, lkp, mgorman,
mingo, senozhatsky, tglx, vkondra
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
^ permalink raw reply [flat|nested] 29+ messages in thread* RE: [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-08 16:36 ` Steven Rostedt
@ 2026-01-08 20:14 ` Pnina Feder
0 siblings, 0 replies; 29+ messages in thread
From: Pnina Feder @ 2026-01-08 20:14 UTC (permalink / raw)
To: Steven Rostedt, Peter Zijlstra
Cc: akpm@linux-foundation.org, pmladek@suse.com, bhe@redhat.com,
linux-kernel@vger.kernel.org, lkp@intel.com, mgorman@suse.de,
mingo@redhat.com, senozhatsky@chromium.org, tglx@linutronix.de,
Vladimir Kondratiev
Hi Steve,
> 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
I have added your suggestion to the documentation on v5.
Thanks,
Pnina
^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-08 7:48 ` Peter Zijlstra
2026-01-08 16:36 ` Steven Rostedt
@ 2026-01-08 20:09 ` Pnina Feder
2026-01-12 7:49 ` Peter Zijlstra
1 sibling, 1 reply; 29+ messages in thread
From: Pnina Feder @ 2026-01-08 20:09 UTC (permalink / raw)
To: Peter Zijlstra
Cc: akpm@linux-foundation.org, pmladek@suse.com, bhe@redhat.com,
linux-kernel@vger.kernel.org, lkp@intel.com, mgorman@suse.de,
mingo@redhat.com, rostedt@goodmis.org, senozhatsky@chromium.org,
tglx@linutronix.de, Vladimir Kondratiev
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-08 20:09 ` Pnina Feder
@ 2026-01-12 7:49 ` Peter Zijlstra
2026-01-14 21:57 ` Pnina Feder
0 siblings, 1 reply; 29+ messages in thread
From: Peter Zijlstra @ 2026-01-12 7:49 UTC (permalink / raw)
To: Pnina Feder
Cc: akpm@linux-foundation.org, pmladek@suse.com, bhe@redhat.com,
linux-kernel@vger.kernel.org, lkp@intel.com, mgorman@suse.de,
mingo@redhat.com, rostedt@goodmis.org, senozhatsky@chromium.org,
tglx@linutronix.de, Vladimir Kondratiev
On Thu, Jan 08, 2026 at 08:09:33PM +0000, Pnina Feder wrote:
> > 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.
I was more thinking about platform setup, it would set this on boot, and
equally dis-allow hot-unplug of the magical CPU.
^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-12 7:49 ` Peter Zijlstra
@ 2026-01-14 21:57 ` Pnina Feder
0 siblings, 0 replies; 29+ messages in thread
From: Pnina Feder @ 2026-01-14 21:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: akpm@linux-foundation.org, pmladek@suse.com, bhe@redhat.com,
linux-kernel@vger.kernel.org, lkp@intel.com, mgorman@suse.de,
mingo@redhat.com, rostedt@goodmis.org, senozhatsky@chromium.org,
tglx@linutronix.de, Vladimir Kondratiev
Hi,
> > > 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.
>
> I was more thinking about platform setup, it would set this on boot, and equally dis-allow hot-unplug of the magical CPU.
Thanks for the suggestion.
I was thinking of this as a fixed platform requirement that is known at boot and needs to apply from the start of the panic path. Handling it via platform setup would likely involve additional CPU hotplug and lifecycle handling, which seemed unnecessary for this case. A boot-time parameter felt like a simple and explicit way to express that constraint.
Please let me know if this sounds reasonable.
Thanks,
Pnina
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-07 21:56 ` [PATCH v4] " Pnina Feder
` (2 preceding siblings ...)
2026-01-08 7:48 ` Peter Zijlstra
@ 2026-01-09 1:18 ` kernel test robot
3 siblings, 0 replies; 29+ messages in thread
From: kernel test robot @ 2026-01-09 1:18 UTC (permalink / raw)
To: Pnina Feder, akpm
Cc: llvm, oe-kbuild-all, pmladek, bhe, linux-kernel, lkp, mgorman,
mingo, peterz, pnina.feder, rostedt, senozhatsky, tglx, vkondra
Hi Pnina,
kernel test robot noticed the following build warnings:
[auto build test WARNING on akpm-mm/mm-everything]
[also build test WARNING on linus/master v6.19-rc4 next-20260108]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Pnina-Feder/panic-add-panic_force_cpu-parameter-to-redirect-panic-to-a-specific-CPU/20260108-055823
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link: https://lore.kernel.org/r/20260107215659.3619730-1-pnina.feder%40mobileye.com
patch subject: [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260109/202601090229.rC0GNQqG-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260109/202601090229.rC0GNQqG-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601090229.rC0GNQqG-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> Warning: kernel/panic.c:344 function parameter 'buf' not described in 'panic_force_target_cpu'
>> Warning: kernel/panic.c:344 function parameter 'buf_size' not described in 'panic_force_target_cpu'
>> Warning: kernel/panic.c:344 function parameter 'buf' not described in 'panic_force_target_cpu'
>> Warning: kernel/panic.c:344 function parameter 'buf_size' not described in 'panic_force_target_cpu'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH v5] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-05 8:18 ` [PATCH v3] " Pnina Feder
2026-01-05 16:50 ` Petr Mladek
2026-01-07 21:56 ` [PATCH v4] " Pnina Feder
@ 2026-01-08 20:36 ` Pnina Feder
2026-01-08 21:00 ` Steven Rostedt
2026-01-09 22:19 ` kernel test robot
2 siblings, 2 replies; 29+ messages in thread
From: Pnina Feder @ 2026-01-08 20:36 UTC (permalink / raw)
To: akpm
Cc: pmladek, bhe, linux-kernel, lkp, mgorman, mingo, peterz,
pnina.feder, rostedt, senozhatsky, tglx, vkondra
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.
The IPI delivery is implemented as a weak function (panic_smp_redirect_cpu)
so architectures with NMI support can override it for more reliable delivery.
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 v4:
- Make IPI delivery an overridable weak function (panic_smp_redirect_cpu)
so architectures can use NMI where available
- Add declaration on include/linux/smp.h alongside other panic SMP functions
- Add warning to documentation about reduced reliability
- Address review comments from Andrew Morton (remove unnecessary cast,
add missing kernel-doc parameters)
Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
---
.../admin-guide/kernel-parameters.txt | 15 +++
include/linux/smp.h | 1 +
kernel/panic.c | 122 ++++++++++++++++++
3 files changed, 138 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index a8d0afde7f85..6d6f2880302f 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4753,6 +4753,21 @@ 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.
+ This option should only be used for systems with the above
+ constraints as it might cause the panic operation to be less reliable.
+
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/include/linux/smp.h b/include/linux/smp.h
index 91d0ecf3b8d3..1ebd88026119 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -62,6 +62,7 @@ int smp_call_function_single_async(int cpu, call_single_data_t *csd);
void __noreturn panic_smp_self_stop(void);
void __noreturn nmi_panic_self_stop(struct pt_regs *regs);
void crash_smp_send_stop(void);
+int panic_smp_redirect_cpu(int target_cpu, void *msg);
/*
* Call a function on all processors
diff --git a/kernel/panic.c b/kernel/panic.c
index 0d52210a9e2b..f03eb60ae8ac 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -300,6 +300,121 @@ 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 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", info);
+}
+
+/**
+ * panic_smp_redirect_cpu - Redirect panic to target CPU
+ * @target_cpu: CPU that should handle the panic
+ * @msg: formatted panic message
+ *
+ * Default implementation uses IPI. Architectures with NMI support
+ * can override this for more reliable delivery.
+ *
+ * Return: 0 on success, negative errno on failure
+ */
+int __weak panic_smp_redirect_cpu(int target_cpu, void *msg)
+{
+ static call_single_data_t panic_csd;
+
+ panic_csd.func = do_panic_on_target_cpu;
+ panic_csd.info = msg;
+
+ return smp_call_function_single_async(target_cpu, &panic_csd);
+}
+
+/**
+ * panic_force_target_cpu - Redirect panic to a specific CPU for crash kernel
+ * @buf: buffer to format the panic message into
+ * @buf_size: size of the buffer
+ * @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);
+
+ if (panic_smp_redirect_cpu(target_cpu, buf) != 0)
+ return true;
+
+ /* IPI/NMI sent, this CPU should stop */
+ 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 +566,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
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: [PATCH v5] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-08 20:36 ` [PATCH v5] " Pnina Feder
@ 2026-01-08 21:00 ` Steven Rostedt
2026-01-11 10:05 ` Pnina Feder
2026-01-09 22:19 ` kernel test robot
1 sibling, 1 reply; 29+ messages in thread
From: Steven Rostedt @ 2026-01-08 21:00 UTC (permalink / raw)
To: Pnina Feder
Cc: akpm, pmladek, bhe, linux-kernel, lkp, mgorman, mingo, peterz,
senozhatsky, tglx, vkondra
On Thu, 8 Jan 2026 22:36:12 +0200
Pnina Feder <pnina.feder@mobileye.com> wrote:
First, new versions of a patch or patch set should *always* be a new thread
and not a reply to the old version. That makes it much harder on
maintainers to see a new series.
> 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 v4:
> - Make IPI delivery an overridable weak function (panic_smp_redirect_cpu)
> so architectures can use NMI where available
> - Add declaration on include/linux/smp.h alongside other panic SMP functions
> - Add warning to documentation about reduced reliability
> - Address review comments from Andrew Morton (remove unnecessary cast,
> add missing kernel-doc parameters)
>
> Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
> ---
The "Changes since" line should always be below the '---' otherwise it gets
pulled into the git log and the maintainer needs to manually delete it
(which is annoying).
Also, it is helpful to add a link to the previous version.
> Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
> ---
Changes since v4: https://lore.kernel.org/all/20260107215659.3619730-1-pnina.feder@mobileye.com/
- Make IPI delivery an overridable weak function (panic_smp_redirect_cpu)
so architectures can use NMI where available
- Add declaration on include/linux/smp.h alongside other panic SMP functions
- Add warning to documentation about reduced reliability
- Address review comments from Andrew Morton (remove unnecessary cast,
add missing kernel-doc parameters)
This provides the continuity between versions without having to be replies
of older versions.
-- Steve
^ permalink raw reply [flat|nested] 29+ messages in thread* RE: [PATCH v5] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-08 21:00 ` Steven Rostedt
@ 2026-01-11 10:05 ` Pnina Feder
2026-01-11 17:13 ` Steven Rostedt
0 siblings, 1 reply; 29+ messages in thread
From: Pnina Feder @ 2026-01-11 10:05 UTC (permalink / raw)
To: Steven Rostedt
Cc: akpm@linux-foundation.org, pmladek@suse.com, bhe@redhat.com,
linux-kernel@vger.kernel.org, lkp@intel.com, mgorman@suse.de,
mingo@redhat.com, peterz@infradead.org, senozhatsky@chromium.org,
tglx@linutronix.de, Vladimir Kondratiev
Hi Steve,
Thanks for the guidance, will do.
Pnina
> On Thu, 8 Jan 2026 22:36:12 +0200
> Pnina Feder <pnina.feder@mobileye.com> wrote:
>
> First, new versions of a patch or patch set should *always* be a new thread and not a reply to the old version. That makes it much harder on maintainers to see a new series.
>
> > 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 v4:
> > - Make IPI delivery an overridable weak function (panic_smp_redirect_cpu)
> > so architectures can use NMI where available
> > - Add declaration on include/linux/smp.h alongside other panic SMP
> > functions
> > - Add warning to documentation about reduced reliability
> > - Address review comments from Andrew Morton (remove unnecessary cast,
> > add missing kernel-doc parameters)
> >
> > Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
> > ---
>
> The "Changes since" line should always be below the '---' otherwise it gets pulled into the git log and the maintainer needs to manually delete it (which is annoying).
>
> Also, it is helpful to add a link to the previous version.
>
> > Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
> > ---
> Changes since v4: Suspicious Link - Removed
> - Make IPI delivery an overridable weak function (panic_smp_redirect_cpu)
> so architectures can use NMI where available
> - Add declaration on include/linux/smp.h alongside other panic SMP functions
> - Add warning to documentation about reduced reliability
> - Address review comments from Andrew Morton (remove unnecessary cast,
> add missing kernel-doc parameters)
>
> This provides the continuity between versions without having to be replies of older versions.
>
> -- Steve
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v5] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-11 10:05 ` Pnina Feder
@ 2026-01-11 17:13 ` Steven Rostedt
0 siblings, 0 replies; 29+ messages in thread
From: Steven Rostedt @ 2026-01-11 17:13 UTC (permalink / raw)
To: Pnina Feder
Cc: akpm@linux-foundation.org, pmladek@suse.com, bhe@redhat.com,
linux-kernel@vger.kernel.org, lkp@intel.com, mgorman@suse.de,
mingo@redhat.com, peterz@infradead.org, senozhatsky@chromium.org,
tglx@linutronix.de, Vladimir Kondratiev
On Sun, 11 Jan 2026 10:05:05 +0000
Pnina Feder <PNINA.FEDER@mobileye.com> wrote:
> Hi Steve,
>
> Thanks for the guidance, will do.
>
> > >
> > > Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
> > > ---
> >
> > The "Changes since" line should always be below the '---' otherwise it gets pulled into the git log and the maintainer needs to manually delete it (which is annoying).
> >
> > Also, it is helpful to add a link to the previous version.
> >
> > > Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
> > > ---
> > Changes since v4: Suspicious Link - Removed
Of course it seems that your email server removes active links to old
versions which defeats the purpose :-p
-- Steve
> > - Make IPI delivery an overridable weak function (panic_smp_redirect_cpu)
> > so architectures can use NMI where available
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v5] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-08 20:36 ` [PATCH v5] " Pnina Feder
2026-01-08 21:00 ` Steven Rostedt
@ 2026-01-09 22:19 ` kernel test robot
2026-01-09 22:41 ` Andrew Morton
1 sibling, 1 reply; 29+ messages in thread
From: kernel test robot @ 2026-01-09 22:19 UTC (permalink / raw)
To: Pnina Feder, akpm
Cc: oe-kbuild-all, pmladek, bhe, linux-kernel, lkp, mgorman, mingo,
peterz, pnina.feder, rostedt, senozhatsky, tglx, vkondra
Hi Pnina,
kernel test robot noticed the following build warnings:
[auto build test WARNING on akpm-mm/mm-everything]
[also build test WARNING on linus/master v6.19-rc4 next-20260109]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Pnina-Feder/panic-add-panic_force_cpu-parameter-to-redirect-panic-to-a-specific-CPU/20260109-043725
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link: https://lore.kernel.org/r/20260108203612.955769-1-pnina.feder%40mobileye.com
patch subject: [PATCH v5] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20260109/202601092335.DbBERt3l-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260109/202601092335.DbBERt3l-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601092335.DbBERt3l-lkp@intel.com/
All warnings (new ones prefixed by >>):
kernel/panic.c: In function 'do_panic_on_target_cpu':
>> kernel/panic.c:327:17: warning: format '%s' expects argument of type 'char *', but argument 2 has type 'void *' [-Wformat=]
327 | panic("%s", info);
| ~^ ~~~~
| | |
| | void *
| char *
| %p
vim +327 kernel/panic.c
324
325 static void do_panic_on_target_cpu(void *info)
326 {
> 327 panic("%s", info);
328 }
329
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [PATCH v5] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-09 22:19 ` kernel test robot
@ 2026-01-09 22:41 ` Andrew Morton
2026-01-11 10:09 ` Pnina Feder
0 siblings, 1 reply; 29+ messages in thread
From: Andrew Morton @ 2026-01-09 22:41 UTC (permalink / raw)
To: kernel test robot
Cc: Pnina Feder, oe-kbuild-all, pmladek, bhe, linux-kernel, mgorman,
mingo, peterz, rostedt, senozhatsky, tglx, vkondra
On Fri, 9 Jan 2026 23:19:34 +0100 kernel test robot <lkp@intel.com> wrote:
> kernel/panic.c: In function 'do_panic_on_target_cpu':
> >> kernel/panic.c:327:17: warning: format '%s' expects argument of type 'char *', but argument 2 has type 'void *' [-Wformat=]
> 327 | panic("%s", info);
> | ~^ ~~~~
Thanks. That's what you get for listening to akpm ;)
Stupid compiler.
^ permalink raw reply [flat|nested] 29+ messages in thread* RE: [PATCH v5] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
2026-01-09 22:41 ` Andrew Morton
@ 2026-01-11 10:09 ` Pnina Feder
0 siblings, 0 replies; 29+ messages in thread
From: Pnina Feder @ 2026-01-11 10:09 UTC (permalink / raw)
To: Andrew Morton
Cc: oe-kbuild-all@lists.linux.dev, pmladek@suse.com, bhe@redhat.com,
linux-kernel@vger.kernel.org, mgorman@suse.de, mingo@redhat.com,
peterz@infradead.org, rostedt@goodmis.org,
senozhatsky@chromium.org, tglx@linutronix.de, Vladimir Kondratiev
> On Fri, 9 Jan 2026 23:19:34 +0100 kernel test robot <lkp@intel.com> wrote:
>
> > kernel/panic.c: In function 'do_panic_on_target_cpu':
> > >> kernel/panic.c:327:17: warning: format '%s' expects argument of type 'char *', but argument 2 has type 'void *' [-Wformat=]
> > 327 | panic("%s", info);
> > | ~^ ~~~~
>
> Thanks. That's what you get for listening to akpm ;)
>
> Stupid compiler.
I'll add the cast back in v6 :)
Pnina
^ permalink raw reply [flat|nested] 29+ messages in thread