| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <aV8gdniyP3hfkp1u@MiWiFi-R3L-srv>
Date: Thu, 8 Jan 2026 11:11:50 +0800
From: Baoquan He <bhe@...hat.com>
To: Pnina Feder <pnina.feder@...ileye.com>
Cc: akpm@...ux-foundation.org, pmladek@...e.com,
linux-kernel@...r.kernel.org, lkp@...el.com, mgorman@...e.de,
mingo@...hat.com, peterz@...radead.org, rostedt@...dmis.org,
senozhatsky@...omium.org, tglx@...utronix.de, vkondra@...ileye.com
Subject: Re: [PATCH v4] panic: add panic_force_cpu= parameter to redirect
panic to a specific CPU
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@...ileye.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
>
Powered by blists - more mailing lists