From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 C816835CBB4 for ; Thu, 8 Jan 2026 07:49:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767858559; cv=none; b=ZB0a4fIKxyPHd2xEr5pRHWJOAuoxtYhOhRTUSRRq249FpBFBoC+EeaGuRAQJ2V/Ck6GLoBz0HIVKAVLZ/jC3CFicvgNdj2V8yGCyL7VzU2GWAJEjBbTk+VmI2KO/dGSxtNYdSWA1u9BUZ+cdNQzh1uO8kje/h4/nuxGBqq/Vp3E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767858559; c=relaxed/simple; bh=mEGo364OkIDjbXxWVBQKQecLMf7lwUzoXxDZlrWkCaw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cEfAIN95q9D+RnNHu7y/+z5HD4p66I0csegJzb/PG+RwexDxkccpFgIvOZGZNmjIAoTsAAHVxMfNQbh6k4ujoPXMATSUuJkLzo5wvbLkrq6qhO7PMsUQG7xCAOZxw9WEvcvNiTNQPS8N4uPckOT13j4NREgNIplF5pmcCVCk4sc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=E/DurAZQ; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="E/DurAZQ" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=fLWW2ZuGphJUfxFhIrlKIJJ0NEJogsp/jeW8ndlHnj0=; b=E/DurAZQkKIWAtszq1nEHtAGfn BwYkzewGIBd1Xk1UoAProrN42pMqySZsqbnBPAXha3hWWk7HsGLllCHj4vXVsrwwhL+XdAOAMVSJd r7aPxgXtDlx3W51VNtXfpo1hpIWJxl3LOTeLGrLI6Mb6c5NiRLHsv7caGLzJzscPiPUEbuh2IU7kT KufmYo6yqwKtx5m1DHiv9r2eP88xmoWtfdLw1qLenGldHBKc0OkS3mex2hzVYUHfNwXFof9eHjAcY iP5K5AMFLkPAlK/MRGyLlq7iqNInXdmMP/c9UwZ/OtArOIzaGviT2dbnN2CUBrUAtJRdCPt2sJ2Pz RW35cqEg==; Received: from 2001-1c00-8d85-5700-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:5700:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vdklO-0000000Cfu9-2IXU; Thu, 08 Jan 2026 07:48:58 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 403AA30031E; Thu, 08 Jan 2026 08:48:57 +0100 (CET) Date: Thu, 8 Jan 2026 08:48:57 +0100 From: Peter Zijlstra To: Pnina Feder Cc: akpm@linux-foundation.org, pmladek@suse.com, bhe@redhat.com, linux-kernel@vger.kernel.org, lkp@intel.com, mgorman@suse.de, mingo@redhat.com, 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 Message-ID: <20260108074857.GD272712@noisy.programming.kicks-ass.net> References: <20260105081808.1771473-1-pnina.feder@mobileye.com> <20260107215659.3619730-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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260107215659.3619730-1-pnina.feder@mobileye.com> On Wed, Jan 07, 2026 at 11:56:59PM +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. > > 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. This seems exceedingly fragile to me. Who is saying the target CPU is even responsive? At the very least this should be an arch callback such that it can use NMIs where available. Also, if this is a 'requirement' for kexec or the like, this shouldn't be a command line argument, but something that's set-up by kexec itself for functional reasons. > + panic_force_cpu= > + [KNL,SMP] Force panic handling to execute on a specific CPU. > + Format: > + 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. It this stays; it should have a warning that it makes the panic less reliable.