From: Baoquan He <bhe@redhat.com>
To: Pnina Feder <pnina.feder@mobileye.com>
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,
vkondra@mobileye.com
Subject: Re: [PATCH v4] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU
Date: Thu, 8 Jan 2026 11:11:50 +0800 [thread overview]
Message-ID: <aV8gdniyP3hfkp1u@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20260107215659.3619730-1-pnina.feder@mobileye.com>
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
>
next prev parent reply other threads:[~2026-01-08 3:12 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-01 12:32 [PATCH] panic/kexec: Allow forcing panic execution on a specific CPU Pnina Feder
2026-01-03 18:29 ` Andrew Morton
2026-01-04 10:44 ` kernel test robot
2026-01-04 20:42 ` [PATCH v2] panic: add panic_force_cpu= parameter to redirect panic to " Pnina Feder
2026-01-05 23:34 ` Andrew Morton
2026-01-07 21:27 ` Pnina Feder
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-07 23:10 ` Andrew Morton
2026-01-08 11:49 ` Pnina Feder
2026-01-08 3:11 ` Baoquan He [this message]
2026-01-08 7:49 ` Peter Zijlstra
2026-01-08 12:02 ` Pnina Feder
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
2026-01-12 7:49 ` Peter Zijlstra
2026-01-14 21:57 ` Pnina Feder
2026-01-09 1:18 ` kernel test robot
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-11 17:13 ` Steven Rostedt
2026-01-09 22:19 ` kernel test robot
2026-01-09 22:41 ` Andrew Morton
2026-01-11 10:09 ` Pnina Feder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aV8gdniyP3hfkp1u@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=pnina.feder@mobileye.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=tglx@linutronix.de \
--cc=vkondra@mobileye.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox