From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 1A3F032A3FE for ; Fri, 26 Jun 2026 14:26:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782483977; cv=none; b=P5JBZxZiiRgwKZJ7PcpRwsjpi6oSn8n6Xa8Lz8E6CoAsUyBTaiouN3yAXOEsRxxKHTPg6uVKXX/2n8uYlTC+5qVG0614WODylbDZBvOWUlrSAMrrjZ06PbbAj7jcyHJ0RvvhkQBfQXq7VKn50a9+4bIKREPTqYH1klkM0gp3Mwc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782483977; c=relaxed/simple; bh=SkSupaXHlzkEqXiDNaHuO2DkZqcG3uLR0lEheitZjT0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BnfKmYTxpZyNLfejsJd5TE+y3RsPcBem6Wg6eG9B83r/bSJ9Zzcbls8qQ6deMMXbm+E5a0QPV9uoOEGORY+4ekQqqkUkEda/eyOUjmF9zl+lBlo9Mt3/3IQ1GxapKNQRkva61ezi6ITPveMHjVaQ3lTENck7awenXdydXMImnpE= 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=EObO6ND9; arc=none smtp.client-ip=209.85.128.43 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="EObO6ND9" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-49258ac7294so7097525e9.0 for ; Fri, 26 Jun 2026 07:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1782483974; x=1783088774; 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=93zgvkxuh49PA0NOJqu92O8AFgIa3mgcrkcaggpnEck=; b=EObO6ND9sT8EmvVykVm/aFz+xxFnSv4emT8/wDyCGDj098VP1pbFmA/MonbpJmW7Mu pPlEALWZRgLhT56mUNPudGbgJJVk16FVDEAeaxZ74sFqd2HGqAumHhmR2I3+uYDt9lWK U8iEhLU6wknN36YBLgXVD+e29CqLx6N5GrQGnDIBo3iRUWj2OWDMHXA5P/fHwyWyAnjX E77RTcpLETR9bRPaIpfWFZJKBvzdzAsYd/S+NrqZ1My7SnxX8fgMRBnSZy4luvMw77aH 3quJ1bJdeBZ1Gc/nL6J8+nj1d0aXua38YwJKwmTXjDvKHA2rpPyyGpQKkC5Kv8di0GYE lE+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782483974; x=1783088774; 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=93zgvkxuh49PA0NOJqu92O8AFgIa3mgcrkcaggpnEck=; b=N/pebtaCKgNSUvdY0cEOmm/HyA27soU1DDZC1EiqZczTV2ljFC9OGq/IcCr/8+0vdL /FyX3tTp3sFjnMqmUjddwfQ+KDUfq2pRNjXaB+6xq8NFFFo0MKJkVBO7fiyC+PrpihhM NaTpi5Gu+d20WnM4Hp16uehAjv5ruRMD6LKHQx7sfUu+1G0v8ED87nUfBE5EKG4OsVpM JUooxImtK9sYUqc6KcFW1h/TPrnYsB1p/sA2Enfph9hjfnipSDrgygjvcXsQeqB33PS/ QB8LSLXt7vTPLXsduMhS5Egtv4IMDu9gHG4JAjPwdpavqKA1b9mhsR0mIprPbNgZYGgM xKbw== X-Forwarded-Encrypted: i=1; AFNElJ8w8D3yic0siIDebz9iNBtJvqLfcNVNJmgyoRSfa9NGUOnervokVYWy/GijIWjesOLztqRZ6hyUs3idefE=@vger.kernel.org X-Gm-Message-State: AOJu0Yxi9zE7+PuaDyHxQYuQQNZ/e0zcVzpGi9qkRPWSq8vjg0risGx9 eQWL+X64e3tG2VB/kd3+3J9e7c14GQpHPatjKaGmvFoXwUbnnvbovLbITKIcQZoXvHg= X-Gm-Gg: AfdE7ckSajE0Ikpe/dib1ZZtSX+IrInCukdlPeWJhIRFxbW5lQNIwUVVgk4f1XcABw2 m0hcKPGuoqJpdIya4+vzvSFI+T9/Ja2r6gZbTWd+VQKOdcS8GnGncz+ig6a4RmYDKuqpzi6+4pE grPmCRK67vzCONIhk9lAXh/V76ffXBllq3SNjdnJ6K0BoGO9t1hzLVtAvGEVIzJRht8c2ncMz8m ixHrZFc5s+9+jzrKhY89285270ZS4isONNtMt0aQTwa8J20/9rnoCI//V48DTkuF0M5TPD1B2no n8SDB05+yEHedZGF5ZIWYVToOi/kPJlRqxxLuj8MkUTDJJROUAqe5MAGwv1o3GFPzYUdk0QhpvJ OXkLb9irn79bLaRP+8XiXG4bdX5UjrclckgRoby9Z6/GoAGxYPtwma+NwdJDcHPn2PV5+vu732+ cPEVXI+58vvnwDPY0= X-Received: by 2002:a05:600c:8114:b0:492:7024:11c8 with SMTP id 5b1f17b1804b1-492702411d5mr10254015e9.32.1782483974505; Fri, 26 Jun 2026 07:26:14 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4926c02081bsm44449055e9.0.2026.06.26.07.26.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2026 07:26:14 -0700 (PDT) Date: Fri, 26 Jun 2026 16:26:11 +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> <85F6E30C-EB1B-4BAF-9204-5174FD066EE0@grrlz.net> <4CF5AE3F-D7ED-47F8-A920-61D0AA078CF9@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: <4CF5AE3F-D7ED-47F8-A920-61D0AA078CF9@grrlz.net> On Fri 2026-06-26 13:32:38, Bradley Morgan wrote: > On June 26, 2026 1:17:13 PM GMT+01:00, Bradley Morgan > wrote: > >On June 26, 2026 1:14:14 PM GMT+01:00, Petr Mladek > >wrote: > >>On Fri 2026-06-26 12:23:50, Petr Mladek wrote: > >>> On Thu 2026-06-25 15:25:58, Bradley Morgan wrote: > >>> 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. > >>> > Hmm.. new idea > > kernel/dump_filter.c ? > > What this file could do is to handle a generic lockup state machine > so any subsystem can log what it already dumped? > > I know it may bloat, but it's better then cramming fixes in. I am not sure what exactly you would like to achieve but it sounds a bit scary ;-) Anyway, we should not synchronize the watchdog reports against each other, definitely. They are running in non-compatible contexts (task vs interrupt vs NMI). Also we should not add any locking because they usually print something when the system has enough troubles. Also I think that it is not worth preventing duplicated backtraces or reports from a single CPU. IMHO, it is not a big problem in practice. So, we are down to large reports, like backtraces from all CPUs, timers, locks, ... which are handled by sys_info(). So, I think that it should be enough to handle this inside the sys_info() API. I do not want to say that my proposal was the best solution. I am sure that there are better ones. But we need to consider the gain vs. complexity. Honestly, I am already a bit scared by the complexity which we the sys_info() API added. And it is hard to imagine that adding another API would make it easier. But I might be wrong. Instead, it might make sense to integrate the conflicting subsystem-specific calls under the sys_info() API. I mean that, for example watchdog_hardlockup_check() won't call trigger_allbutcpu_cpu_backtrace() directly but it would call it via sys_info() API so that sys_info() could keep track of it. Something like: void sys_info_allbutcpu_bt(int cpu) { trigger_allbutcpu_cpu_backtrace(cpu); /* * The caller likely printed backtrace of the given @cpu * on its own. Prevent duplicate backtraces from all * CPUs with potential next sys_info() call. */ sys_info_done(SYS_INFO_ALL_BT); } But I am not sure if it is really easier to follow than calling sys_info_done() from the watchdog code. Some watchdogs try to optimize the output and print backtraces only from CPUs which are relevant for the given lockup. We should keep the logic for selecting the set of CPUs in the watchdog code. We just need to solve how to elegantly make sys_info() aware of it or at least about the more massive reports. Anyway, I would prefer to keep it simple until we see some problems in practice. Best Regards, Petr