From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 0C8FC3EB0ED for ; Fri, 26 Jun 2026 10:23:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782469433; cv=none; b=BBH916M0SRnHPeRuJoBrrgSy5VfXNP328MiRijL0EjyN2YsRBo/HrVK4TAWi4dOD81AvsecF+qW/+MkarjKqaaBUqrwz4kHO2stpy7GYhRHOyJH9mNmOpngs1MoLs0cXxV6LRPlhdwPR9uROR0ZkVQCz6Pgs+6+4WJmvVWdA1Ho= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782469433; c=relaxed/simple; bh=ffNECExMWsXfqi2yo0S2r8IrBwZRf40yiT2nYi2+6Zo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Oysr7PpHwB7S7rV5MmwGzJFEKNQKzvjhSAb657t5vJC64I1J9E71i62k5J+DYbAN2R3JWTa0quxJ7JWMGH8x4eV9gm5XxK5DyDfu7HQptOcmNiQFwbGgddaMuxfhfgPY28XCNozIwim1fswDFYnSZLIsj6F/Be2/yUB8/+TMCBg= 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=cN6A/R4H; arc=none smtp.client-ip=209.85.221.54 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="cN6A/R4H" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-46cbf263113so725107f8f.1 for ; Fri, 26 Jun 2026 03:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1782469430; x=1783074230; 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=eLFZTGPtRiE8UPhqU4UMjkuV0PbJHe/HCNgoSE+benw=; b=cN6A/R4HtvgBXKGB5A+UHEStNNf7UvH2iFaPP0zH836AXQeyuNgNDcK5vvsCutS4E6 vnPQWTm8RvxNsDzHGOsUQ/3C+94OaUUWOYyL17Y/21HGIKORPcfvKeJhmLUK3xa/blLi an3VDrhgnBJm1Q8axUDuEBPceTPf/FUJI3ndg8JEmBQXTaYlS5FJGCAwhBkZrzUY4Zp6 1y6KWNw/KedmlKBxoz1KDP/DZ+7HIhGga7pr52Y7b5jQ2I0pj6+95awT8AIp7w9EQDEx T7AGUAzFJefET/quPWKA0S48rdv9+3s0WwUj2MDY7wpRdYB5rHYMXWVorXUrlGx9m4ja R/OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782469430; x=1783074230; 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=eLFZTGPtRiE8UPhqU4UMjkuV0PbJHe/HCNgoSE+benw=; b=bj/bkHw9+y+KgN0tUgp9Gwm+rDOgycxAL501lGmtGMfBrwPx6/mAath+erW5nQgy5A 4isNVSXh8PpYqJuorCB8sIz7FNxMMy4gnGj2l/uc29Gcl4RP8dXlVI7V+2n3J35ATPju Zlaiz5d6A3PnQswgfYzPs+DlKXn4AF3yOzDVIVS38xpjE+LBbWIodzoH+v9k8pdFG2g3 gcRfToFMfuv3XIc1/7ONeNl8cPGyFplgYZa0sK5dssQ9dBiA4xiMQffCen0Okwla2p+C YUq+11n4/sWfxCKmHOMlxLMYtG0Zqb9m4IBATVGer3ehKjgi07BaX+0BJVLptZcjedS2 PXEA== X-Forwarded-Encrypted: i=1; AHgh+RqyOqNS6ps8oRNNC++4mqLvzvfJOE703ViF55V77896EIrMEHR58Z2XqW4o2uW6HOk4Nz/WJ7BiKYgC07o=@vger.kernel.org X-Gm-Message-State: AOJu0Yw51LQDKVnuOROWyeR+42wwXKLuECvpS2CbHl3Q/yiuSNLmcHZs 1vP907fJ0X0EoGef/VhQlLJ3cLAXinnfN9p5KQdX2mULxAQDoJAdsF6f4VDOM3iFnos= X-Gm-Gg: AfdE7cnbE99+t/2S32JcWUSQ7cZ8qjmghfbOTMwb8dy4YwIqizTOHc6eQ3t/kiYQTPN cRpdX8uQayHy7vOyvCFz8dNY6prTzEHVo6rfyK2G6F3zrfatT4/6adwpfUBzk6Ao9XIFU8k05+u OqURhgduHcNWRWNthPNCTNXPz22DVBO4ETl+tFMiS7uYTlbAvGqYlJGpwzZtStTjnwV+PKLs7pe SPL7NkxX5K4EFhn/II24+1RhGBkxwPKle4KVPqKVyMUF7c0nhQplGdckB1osx8Ph+eeNsb2aBa3 dpQpVvy17NFR/CEn44G7+Lii/VAdrpCh4KkOXgjnLiTwLgxvZW5h3/qymDWORHN2BQUZKBRl4nJ k3CSm2jMd14d6OqKtaP7hROYvH6452HT2T+hsCGg1jxipLLJZqFtIl3f2IjQaRqSS7zsVQo0FXn 2iQ85i0Ks5xw9NjdI= X-Received: by 2002:a05:6000:4204:b0:460:30bd:4dca with SMTP id ffacd0b85a97d-46dc12e056fmr9792387f8f.30.1782469430521; Fri, 26 Jun 2026 03:23:50 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-46dcbac0c9dsm13650525f8f.19.2026.06.26.03.23.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2026 03:23:50 -0700 (PDT) Date: Fri, 26 Jun 2026 12:23:48 +0200 From: Petr Mladek To: Bradley Morgan Cc: Andrew Morton , Feng Tang , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Madhavan Srinivasan , Douglas Anderson , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, stable@vger.kernel.org Subject: Re: [PATCH v3 4/4] panic: use sys_info_with_filter() to avoid duplicate backtraces Message-ID: References: <20260625152558.7450-1-include@grrlz.net> <20260625152558.7450-5-include@grrlz.net> 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: <20260625152558.7450-5-include@grrlz.net> On Thu 2026-06-25 15:25:58, Bradley Morgan wrote: > panic_other_cpus_shutdown() handles SYS_INFO_ALL_BT before stopping the > other CPUs. Do not ask sys_info() to handle that bit again later in the > panic path. > > Use sys_info_with_filter() so panic_print=all_bt does not request more > output after the CPUs are stopped. > > Fixes: a9af76a78760 ("watchdog: add sys_info sysctls to dump sys info on system lockup") > Cc: stable@vger.kernel.org > Signed-off-by: Bradley Morgan > --- > kernel/panic.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/panic.c b/kernel/panic.c > index 213725b612aa..eb842823df61 100644 > --- a/kernel/panic.c > +++ b/kernel/panic.c > @@ -680,7 +680,7 @@ void vpanic(const char *fmt, va_list args) > */ > atomic_notifier_call_chain(&panic_notifier_list, 0, buf); > > - sys_info(panic_print); > + sys_info_with_filter(panic_print, SYS_INFO_ALL_BT); Hmm, this prevents printing backtraces from all CPUs completely. But what if they were not printed? They might be printed by: static void panic_other_cpus_shutdown(bool crash_kexec) { if (panic_print & SYS_INFO_ALL_BT) panic_trigger_all_cpu_backtrace(); [...] } But it checks only "panic_print" variable. It won't do anything when (panic_print == 0). In this case, we might still want to print the backraces when SYS_INFO_ALL_BT is set in kernel_si_info. > kmsg_dump_desc(KMSG_DUMP_PANIC, buf); Of course, we might fix panic_other_cpus_shutdown() to check also kernel_si_info. But it all becomes very hairy. We have several levels: + watchdog-all_bt-specific option, e.g. sysctl_hardlockup_all_cpu_backtrace + watchdog-specific si_info preferences, e.g. hardlockup_si_mask + panic-specific si_info: panic_print + universal fallback for any layer: kernel_si_info Now, we try to check all these variables back and forth to trigger all backtraces or to avoid triggering them. And it clearly does not work well and the code is more and more hairy. I think about another approach. The word "waterfall" comes to my mind. Instead of checking all the settings back and forth, let's process each setting one by one and just remember what has been done and skip this in the next level. All the si_info actions seems to dump a global system state. So, it would make sense to remember the state in a global variable even when it might be modified by more CPUs in parallel. I am going to think more about it. Please, do not send v4 until the discussion settles! Best Regards, Petr