From nobody Wed Jan 7 22:50:57 2026 Received: from esa4.hc555-34.eu.iphmx.com (esa4.hc555-34.eu.iphmx.com [207.54.77.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC8B924677A for ; Sun, 4 Jan 2026 20:43:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=207.54.77.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767559414; cv=none; b=K+3DjluEomN1NvhaxRGOPBhyzP6B7MDcaxvM9s7++ARTLWP2Dv2Md6lZKbMhPNVJtTmHpTHm6tq21GHfnyUtEIwICnPUe0qR4s2jpFq6B0Oe6Pbbzjzqm9uj0pBcpg67V0tsphqz1XVoEwYfRSVyFge/1eTBb2ug1dyUgJNkUCw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767559414; c=relaxed/simple; bh=fAmEArHBociz3QTxo2x8Md3QgfgEOQJqvRHm5vwW+BU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GISJdV4OOHKNnwiSccdWY9I1Y6gB6lwDrYqcmi6Vx6JqFubg59Nd7pPtFoe4imHh8d+B7Iyn+d+ItzI8wVzk7rVhsKjom+P+jezWBoefYyGnm6js/w3edb+xiJ7Sc5g2LqJRdeCayzi9qlPDvFdwzjTcX97zC0YsjtNwAagKFe4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mobileye.com; spf=pass smtp.mailfrom=mobileye.com; dkim=fail (0-bit key) header.d=mobileye.com header.i=@mobileye.com header.b=BSN6lgAo reason="key not found in DNS"; arc=none smtp.client-ip=207.54.77.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mobileye.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mobileye.com Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=mobileye.com header.i=@mobileye.com header.b="BSN6lgAo" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mobileye.com; i=@mobileye.com; q=dns/txt; s=MoEyIP; t=1767559408; x=1799095408; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=fAmEArHBociz3QTxo2x8Md3QgfgEOQJqvRHm5vwW+BU=; b=BSN6lgAoU/E01ha4kSucm3xocd0bjYWFFD5GL4kIurI+Obui/jTbFdMi QDotVPh0Ov0hoBS+omAcxISVTCPFe9Nncy64NFpdSl5mEDStlKqIv8tBc YCigW7LskAepxeG00G9Az7J9bEaRv052n9P7xhuXm/o0pQ15XOmPYn0xf +9oB1C610nwKfhBGXGKnQz6lmMLpdci7HV8g+7IGuxCd7c5TU+ahdKQ5V JTczNaj1vPbZW4AdtPRiheeSrM3geQg7UUFfWoQJWGhrQFj/+XRe/Yaa1 OnEHOYlb+kHPMjLEaikOmeYgmCRw0VTQcSKqDWjP+kiax6Hcwc0plpmMV Q==; X-CSE-ConnectionGUID: U1DKLQw9Q8y5L/eo6Iql4g== X-CSE-MsgGUID: JQZeqfGkTr+2QebZNwXnAg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from unknown (HELO ces04_data.me-crop.lan) ([146.255.191.134]) by esa4.hc555-34.eu.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jan 2026 22:42:17 +0200 X-CSE-ConnectionGUID: R8V6cqD6TRScueECO7CCZw== X-CSE-MsgGUID: VDojn+4HS9yWA4/JP9/sLA== Received: from unknown (HELO epgd034.me-corp.lan) ([10.154.54.2]) by ces04_data.me-crop.lan with SMTP; 04 Jan 2026 22:43:50 +0200 Received: by epgd034.me-corp.lan (sSMTP sendmail emulation); Sun, 04 Jan 2026 22:42:17 +0200 From: Pnina Feder To: akpm@linux-foundation.org Cc: pmladek@suse.com, senozhatsky@chromium.org, linux-kernel@vger.kernel.org, Pnina Feder , kernel test robot Subject: [PATCH v2] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU Date: Sun, 4 Jan 2026 22:42:10 +0200 Message-ID: <20260104204210.2418049-1-pnina.feder@mobileye.com> In-Reply-To: <20260101123237.277411-1-pnina.feder@mobileye.com> References: <20260101123237.277411-1-pnina.feder@mobileye.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 v1: - Replace Kconfig option with a kernel command-line parameter - Fix clang format warning reported by kernel test robot Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202601041820.6M8cIq2e-lkp@int= el.com/ Signed-off-by: Pnina Feder --- kernel/panic.c | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) diff --git a/kernel/panic.c b/kernel/panic.c index 0d52210a9e2b..fb48d14d2b44 100644 --- a/kernel/panic.c +++ b/kernel/panic.c @@ -300,6 +300,92 @@ void __weak crash_smp_send_stop(void) =20 atomic_t panic_cpu =3D ATOMIC_INIT(PANIC_CPU_INVALID); =20 +#ifdef CONFIG_SMP +/* CPU to redirect panic to, -1 means feature is disabled */ +static int panic_force_cpu =3D -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 =3D 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 ker= nel + * @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=3D 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 =3D raw_smp_processor_id(); + int target_cpu =3D panic_force_cpu; + + /* Feature not enabled via boot parameter */ + if (target_cpu < 0) + return true; + + /* Already on target CPU - proceed normally */ + if (cpu =3D=3D 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 console output may be unavailable.\n", target_cpu, cpu); + return true; + } + + /* Another panic already in progress */ + if (panic_in_progress()) { + pr_warn("panic: Another panic in progress on CPU %d, cannot redirect to = CPU %d.\n" + "Crash kernel console output may be unavailable.\n", + 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); + + smp_call_function_single(target_cpu, do_panic_on_target_cpu, panic_redire= ct_msg, false); + + 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(); =20 + /* + * Redirect panic to target CPU if configured via panic_force_cpu=3D. + * 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 --=20 2.43.0