From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) (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 BEA14218845 for ; Thu, 8 Jan 2026 16:36:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767890179; cv=none; b=ucD0Afmn7y7hHFJ0wY1nRQjMiVgUC5T52cDveru6K9GxnFpId9QYq7UVB55YV5+CrWIDv0Hl5bh7txggUP3DIcpzwNUiJrQmBvhi25ljWwm9LT5+cTIUokrvJy6AV70iY6WMx5awJBm4meM7DoDYD/YoFdzKJgKVv/13SbZMJl0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767890179; c=relaxed/simple; bh=PPuCMFrdNw7OInfg5Hk+EeITmQHVG5QW4armn9WxyZ8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NqXUQRe4JHOgj4BX6ozBCzCwSIKcjy1rQNZy+C0K4qTGO5KqnenPOeDyZMwBQKUwSQuZyAQERUG8o+1eAKoNokq99B7Ax6ZNlKT6Fr+kIJ0y8SlRoHxWukYTjLGXRb12pGx8vZVN/7/VN5ALYdCTXBqJAZtEHbbCfdnJ0nIMGo4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org; spf=pass smtp.mailfrom=goodmis.org; arc=none smtp.client-ip=216.40.44.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=goodmis.org Received: from omf09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9BCA31401EA; Thu, 8 Jan 2026 16:36:10 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf09.hostedemail.com (Postfix) with ESMTPA id 2C9B52002B; Thu, 8 Jan 2026 16:36:08 +0000 (UTC) Date: Thu, 8 Jan 2026 11:36:37 -0500 From: Steven Rostedt To: Peter Zijlstra Cc: Pnina Feder , akpm@linux-foundation.org, pmladek@suse.com, bhe@redhat.com, linux-kernel@vger.kernel.org, lkp@intel.com, mgorman@suse.de, mingo@redhat.com, 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: <20260108113637.04c830e6@gandalf.local.home> In-Reply-To: <20260108074857.GD272712@noisy.programming.kicks-ass.net> References: <20260105081808.1771473-1-pnina.feder@mobileye.com> <20260107215659.3619730-1-pnina.feder@mobileye.com> <20260108074857.GD272712@noisy.programming.kicks-ass.net> X-Mailer: Claws Mail 3.20.0git84 (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 X-Stat-Signature: 17i96g5bcuno8zz45qymg8r4cm1aoqba X-Rspamd-Server: rspamout02 X-Rspamd-Queue-Id: 2C9B52002B X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX19JpqER8I8g/zLhe/p/OUPw3P3gPjQZV0E= X-HE-Tag: 1767890168-281227 X-HE-Meta: U2FsdGVkX1/uVzrEMTZJhM06JEGJGXZkV8gf/zhk9mIt27e3Y0rvOgwESSjGnL9FihgLLM6RAsYOro/dXRBkuRQe5PSIMfcPH5crf8GFDHfER+xWfnwEiptc0VUVo8NKdSdpy8zBwwAvj21nAkapqyhLW76Bd8HBZm488dUwAAmMdK7gTJHX2BfBSpJkoJO2k+cMFie63LkQieDOmLOD1Q7lOy8o+7Wks5Uc4aeyOLJl/enMPz1z23JOhYKofCfd5CvJX/DMGjRkUySgvEz+rCtS3Rbb9g69Zv2hHJDAzARbMM9GYPyVkJKtJOWZaRAHAU2WfbZMIfGQlr5QGAa8REYflAiRJITWdHuS6nsGbNzfPwOucUXAk7QrEVyF0bEW On Thu, 8 Jan 2026 08:48:57 +0100 Peter Zijlstra wrote: > > + 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. Agreed. It should probably end with: This option should only be used for systems with the above constraints as it will cause the panic operation to be less reliable. -- Steve