From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 A527F253340 for ; Mon, 5 Jan 2026 23:34:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767656045; cv=none; b=URzxPKJ5D/WiGtYzDsP8NKA8Wn7y4xtASPbkEb3KKL9fJiJaxliPltL1oMVlJWrQeJRCZ0A2mw7+hiHSe3tOYVAeO7iT1GIHxoBRDAeYk0XonuN2M+LvnNni2Rsr5IxciDeUppdgEaq7aInmnq8t7nQ4Vp0dvg5tF0+/U+qcutQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767656045; c=relaxed/simple; bh=uVXuqeUjmptwqL/aXtuiM0r5VxAN0V9+DNzybrDkxgk=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=qz8t0ddTs1Uu/ZjBJp11t/lHwEFd/SQP7eFW4EBIeX23pohG8wuJc6BgADgoHNLzQD5GHEJhopGYJ6sH6lauEdouLDrGoeN/gDps7G7TdXnF1BREw2hdHxjwY/24bblSdUwxS8EsiyDzDp9dcVtwkeLmRtXFAszrj4jH0E8KYZA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=fX3W3WEE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="fX3W3WEE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB15FC116D0; Mon, 5 Jan 2026 23:34:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1767656045; bh=uVXuqeUjmptwqL/aXtuiM0r5VxAN0V9+DNzybrDkxgk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fX3W3WEEgNgekqp1Wo0tsouJxeaqP3FwnF3ZZi4ywU0lLqzxNUa6QEYuJVWPo0xOF IzrzdWSuI7l73bEsRpltydPc9t7tWPitCbBYveCnFJXvTJZ44iBxfQU0MLWf74KSLn 3W7fE9Liki3LQ+wJGevkV7h8SjFAi1WAfHEdM7qI= Date: Mon, 5 Jan 2026 15:34:04 -0800 From: Andrew Morton To: Pnina Feder Cc: pmladek@suse.com, senozhatsky@chromium.org, linux-kernel@vger.kernel.org, kernel test robot Subject: Re: [PATCH v2] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU Message-Id: <20260105153404.b519bc1c9b5efeb201c844d2@linux-foundation.org> In-Reply-To: <20260104204210.2418049-1-pnina.feder@mobileye.com> References: <20260101123237.277411-1-pnina.feder@mobileye.com> <20260104204210.2418049-1-pnina.feder@mobileye.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 4 Jan 2026 22:42:10 +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 support for redirecting panic execution to a designated CPU via a > kernel command-line parameter. Let's tell changelog readers what that command line parameter is called. > 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. Well I like it. Others may not ;) > 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@intel.com/ > Signed-off-by: Pnina Feder > --- > kernel/panic.c | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++ Please update Documentation/admin-guide/kernel-parameters.txt? > +__printf(1, 0) > +static bool panic_force_target_cpu(const char *fmt, va_list args) > +{ > + static char panic_redirect_msg[1024]; It's sad to chew 1k of everyone's RAM for this. smp_call_function_single() is synchronous, yes? Can we reduce that message a lot and use automatic storage? Or perhaps kmalloc the storage if the user provided the panic_force_cpu kernel parameter? > + 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" "panic: ..." > + "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" "panic: ..." boy, was that a nit! > + "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_redirect_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;