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 432611D8E10 for ; Sat, 24 Jan 2026 01:14:42 +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=1769217283; cv=none; b=C1HiTbOZQoOzcKprwTS4n0rl9gt9aszASWKRcR3FJERACTDaDUVG1pUgv/K/XTvFGsvULio5NydfZbUrYrnxEFLhKqA6iTHhqID6nvOAb66qSfSrt+837adLn0YnPePo5QalwWU8DKLAIhL9deLZOMPxOIFey0mMXKwp1PHcFDk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769217283; c=relaxed/simple; bh=+WivcMNA3hrHm+OMaP+mk1x8Hob6bkCukoxInY9+IdQ=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=titziIp2ZEl1VhfSLfEcBn6azhbEkC7Kd9yIIivEx4cAZXwu83skOjGqj0l4e4Sfq8os4WXZgI0gbtkzV9V2349OtUoFfDHBmqYUQwrgknsu8u77ekeEEFvY+4tvxlAVZQhtxPLln2jGDMsjSC/Uq1RPbOZ8tQz7owAwTcr0IpI= 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=bmE1MBs0; 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="bmE1MBs0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6FC96C4CEF1; Sat, 24 Jan 2026 01:14:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1769217282; bh=+WivcMNA3hrHm+OMaP+mk1x8Hob6bkCukoxInY9+IdQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bmE1MBs08lzn1akjcucwj99Bt8/y3qvbcXouUDKNR3KOGTInfIf8w+QOJFY2Qmfuz W4rMTZAuTol4Amt7XBDJd3cq9ZMOHTY4qZj2nxCcyTsaNEyKoWyopfVNlKdQQQ37AM KKGz8xJn4QlEOdLCTRLYPysIR6QhOzkz6aYiqJmg= Date: Fri, 23 Jan 2026 17:14:41 -0800 From: Andrew Morton To: Pnina Feder 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, vkondra@mobileye.com Subject: Re: [PATCH v8] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU Message-Id: <20260123171441.282df442e4d0ad9700e89521@linux-foundation.org> In-Reply-To: <20260122102457.1154599-1-pnina.feder@mobileye.com> References: <20260122102457.1154599-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 Thu, 22 Jan 2026 12:24:57 +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. > > 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. > > ... > > + > +#if defined(CONFIG_SMP) && defined(CONFIG_CRASH_DUMP) > +static int __init panic_force_cpu_setup(char *str) > +{ > + int cpu; > + > + if (!str) > + return -EINVAL; > + > + if (kstrtoint(str, 0, &cpu) || cpu < 0 || cpu >= nr_cpu_ids) { > + 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 int __init panic_force_cpu_late_init(void) > +{ > + if (panic_force_cpu < 0) > + return 0; > + > + panic_force_buf = kmalloc(PANIC_MSG_BUFSZ, GFP_KERNEL); > + > + return 0; > +} > +late_initcall(panic_force_cpu_late_init); early_param vs late_initcall leaves a window where panic_force_cpu!=0&&panic_force_buf==NULL. > +static void do_panic_on_target_cpu(void *info) > +{ > + panic("%s", (char *)info); > +} > + > > ... > > + /* > + * Only one CPU can do the redirect. Use atomic cmpxchg to ensure > + * we don't race with another CPU also trying to redirect. > + */ > + if (!atomic_try_cmpxchg(&panic_redirect_cpu, &old_cpu, this_cpu)) > + return false; > + > + /* > + * Use dynamically allocated buffer if available, otherwise > + * fall back to static message for early boot panics or allocation failure. > + */ > + if (panic_force_buf) { > + vsnprintf(panic_force_buf, PANIC_MSG_BUFSZ, fmt, args); > + msg = panic_force_buf; > + } else { > + msg = "Redirected panic (buffer unavailable)"; > + } which is handled here. Just showing that I'm paying attention ;) > + console_verbose(); > + bust_spinlocks(1); > + > + pr_emerg("panic: Redirecting from CPU %d to CPU %d for crash kernel.\n", > + this_cpu, panic_force_cpu); > + > + /* Dump original CPU before redirecting */ > + if (!test_taint(TAINT_DIE) && > + oops_in_progress <= 1 && Well look at that. When I invented oops_in_progress (dinosaurs were roaming the earth) it was a boolean. iirc, we didn't have `bool' then. Now I see that kdb_msg_write() is playing games and appears to be treating it as a scalar. Without, of course, documenting that anywhere. And then there's this: ./kernel/panic.c: if (test_taint(TAINT_DIE) || oops_in_progress > 1) { which I assume is connected to kdb_msg_write()'s games. Anyway, it would be great if someone could figure this out and add a description of this new interpretation at the oops_in_progress definition site. Also, your test of <= seems inappropriate. 99% of sites treat it as a boolean. > @@ -483,7 +638,11 @@ void vpanic(const char *fmt, va_list args) > /* > * Avoid nested stack-dumping if a panic occurs during oops processing > */ > - if (test_taint(TAINT_DIE) || oops_in_progress > 1) { > + if (atomic_read(&panic_redirect_cpu) != PANIC_CPU_INVALID && > + panic_force_cpu == raw_smp_processor_id()) { > + pr_emerg("panic: Redirected from CPU %d, skipping stack dump.\n", > + atomic_read(&panic_redirect_cpu)); No stack dump because it's the wrong stack, right? Users might wonder where their stack dump went. > + } else if (test_taint(TAINT_DIE) || oops_in_progress > 1) { > panic_this_cpu_backtrace_printed = true; > } else if (IS_ENABLED(CONFIG_DEBUG_BUGVERBOSE)) { > dump_stack(); Anyway, Looks Nice To Me. I'll queue it in mm.git's non-mm branches and shall probably upstream it for 6.19, but additional review is sought, please.