From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 357FA1C84BB for ; Mon, 5 Jan 2026 16:50:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767631813; cv=none; b=elR0TMCiJjdnLZ3oOwD96ud8vCO9Q/LtZNlWWe8o6jJNRYKSuaUzWcyuPx4lglbWxAPtcroGsf51lwNBfti0M7v632rtpurf6MzADGVlr40+PRD+FH7lqXsZ3fkRvPLcb31j3+gRhzSkGg5cNDON6+yt1nORi/T9ZBDECszbnRg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767631813; c=relaxed/simple; bh=/96i14tiadT3z2uJU3EgUMAuQxpBMDn4pJxnM4oT84c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XsOkqDo3XvHx6Mz16kv4xAOVXpcG653dnvxT/jCD1t5N42c+XwEYrNnXJ/AMiMXTZT7VJsb+2XSxeAWMaYA54xjFd2qz59rR3GwLLjx94m53jN4OPE+bE7FbRd6YjTFe9vSYRR9TgLok/dg1ZV4Dwc1FJS7bvZG70MuReB5AAkM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=HO2qYO35; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="HO2qYO35" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-4327555464cso36809f8f.1 for ; Mon, 05 Jan 2026 08:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767631808; x=1768236608; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=LC92kkdtiZVORkwFSQVuerm6+rXzZ3JftmlfQ8db2DU=; b=HO2qYO35DMTS817u+KoobwczenzT46PhS9ftbqO54IGQ1+WRCNXPPCXwTFtQFx7kFh fTUGtu9kf3Ovo4HCMu8dT11KsYz3iCe2pUPaK72mbexmL0YhkDMODizG/aUME/OHUso8 oDgdV7NuUbenqdncMVNtgGPo+CpQ5FDeL84gaJltGNsRKDg74c8Y0qujOjENO9WLThAQ rQll/pJesRRcYq/FP87f1HT+19NtW1e48ZsXiOlVunJgpT737UERglpANubXTU1I8qA5 GkxxiP0yNXKObdXS7MW+LP1i5+Ha1xfZa1vSIg2qpzIPYqkatiWtvkC1kA1/mSYCGmuH S4nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767631808; x=1768236608; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LC92kkdtiZVORkwFSQVuerm6+rXzZ3JftmlfQ8db2DU=; b=BjTkvVxB6Vp+E/9OAQWnGi8rQNiwQRspRzM6gGrxWVxjP5Po8iw0cwqFJGB6yc9K3H PesUL1tmATlsobSwo0x5N0YQ6IvZvPWvcXD4f46nBkdYkSsEuWuvKF3nctsM6jgiKNWL rJUXQXieE3XeMPIjRbxB2R1+DB/fukmKEbZl1M0j10MgYWOb7iwTaDtuCex463fFg1SP QVnhUTOVxlCo8Xz+uUgWkqqbI1oyIwagNIYjLi/3ntVxd+Rrw2nBGBFf7Igq+o92CvT4 pDbxl3lC9SrDZNVa2N7kfG/LNErUYlhQj/s1SZ//F7Br5LemtfZ5/HX1KvoibVsxmSpD bFJw== X-Forwarded-Encrypted: i=1; AJvYcCXrNzJHFy+q2m6Z6Dhm5lGZyqyu/WbjA7GTt4v2N60OHloxrhRPINJ6p0hDZy05y08SUxfMZubO66NFlcA=@vger.kernel.org X-Gm-Message-State: AOJu0YzVZLefFxYtSYfZJ0OYHT2t+V58nhSkTSf3NZlE7HgyOZFHc32T rOvZzMbLq2hZrgBp6nUsr8dFPaQCkTY9iflRZO7dJ3FMyo5kCb37wgJMQ+UvK+26TWQ= X-Gm-Gg: AY/fxX4VpE6vqE3wG6W4kpgWEBFStYZqWc5JhZiAdGLRc5ccjYPTmtVeSAs6mt3EHq3 ZnnVMlrOxwtkjBOEf0mgM6APngGw7IGT2VuJ1ji9+dn4DqIJjj42Ca9bTEZib9a04Fcu2z1XpE2 FiuMGt1TAt3BOI8DdvuTMn+6WKTnQKSqaSVORvyjCzrGtChiO3FrciXPx0MjVbXBtU2N1klvtdh 05BANLHz3mpCcmrhcGl3zHn4ic3w+dbpcCK9km7iPuoyGxINs6ekuBikiwh/PrH+xmHoe1m9KKH vY9EXvstUoUQmITcqmbx5gJIf+TptWtWwc/HpDnLEho/NPT7a0970GQbz1KqWhMSfKvTaF9NZD2 ZxQRx8ualp55Ki5ZIqag+bV0tJN9lC0DfvEc9MXPWOWCAkjeBQcIQOwyEbepY4zxc/rKCW1pYcr /RHAUk8rZg93SDjQ== X-Google-Smtp-Source: AGHT+IE3haKgMfWS9zADCmfNR6MYddhp8acGsYeHW/r1cEtafeRU6CO3rd3+2/7+FAXD4teRaHbYSA== X-Received: by 2002:a05:600c:45cf:b0:47a:7fdd:2906 with SMTP id 5b1f17b1804b1-47d1954a550mr632652315e9.12.1767631808156; Mon, 05 Jan 2026 08:50:08 -0800 (PST) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7ee25471sm3392865e9.5.2026.01.05.08.50.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 08:50:07 -0800 (PST) Date: Mon, 5 Jan 2026 17:50:05 +0100 From: Petr Mladek To: Pnina Feder Cc: akpm@linux-foundation.org, senozhatsky@chromium.org, linux-kernel@vger.kernel.org, kernel test robot , Thomas Gleixner , Peter Zijlstra , Ingo Molnar , Steven Rostedt , Mel Gorman , Baoquan He Subject: Re: [PATCH v3] panic: add panic_force_cpu= parameter to redirect panic to a specific CPU Message-ID: References: <20260101123237.277411-1-pnina.feder@mobileye.com> <20260105081808.1771473-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: <20260105081808.1771473-1-pnina.feder@mobileye.com> Adding more people into Cc. I doubt that smp_call_function_single() is reliable in panic(). On Mon 2026-01-05 10:18:08, 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. 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 v2: > - Make panic redirection warnings generic and platform-agnostic > > 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 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 93 insertions(+) > > diff --git a/kernel/panic.c b/kernel/panic.c > index 0d52210a9e2b..6239bcdc2463 100644 > --- a/kernel/panic.c > +++ b/kernel/panic.c > @@ -300,6 +300,92 @@ void __weak crash_smp_send_stop(void) > > atomic_t panic_cpu = ATOMIC_INIT(PANIC_CPU_INVALID); > > +#ifdef CONFIG_SMP > +/* CPU to redirect panic to, -1 means feature is disabled */ > +static int panic_force_cpu = -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 = 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 kernel > + * @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= 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 = 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" > + "Crash kernel interrupts 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" IMHO, this message does not add much value and should be omitted. vpanic() does not print any message when panic_try_start() fails. > + "Crash kernel interrupts may be unavailable.\n", I am confused by this message. > + 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); The "redirect" in "panic_redirect_msg" is confusing. It has nothing to do with redirection. It is just a buffer for the formatted panic message. I would call it "buf" or "panic_msg". > + smp_call_function_single(target_cpu, do_panic_on_target_cpu, panic_redirect_msg, false); I doubt that this is safe and reliable in panic() context. For a start, panic() might be called in NMI and this function takes csd_lock(). panic() code should avoid locks. Or is should use trylock and handle a failure gracefully. BTW: The commit message says that this is needed for crash-dump to work reliably. So, it does not make sense to do this when crash-dump is not configured. Maybe, crash-dump should get fixed instead? What are the exact problems with the crash-dump, please? > + > + 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(); > > + /* > + * Redirect panic to target CPU if configured via panic_force_cpu=. > + * 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 Best Regards, Petr