[10/10] watchdog/hardlockup: Rename HAVE_HARDLOCKUP_DETECTOR_NON_ARCH to ..._PERF_OR_BUDDY
Message ID | 20230526184139.10.I821fe7609e57608913fe05abd8f35b343e7a9aae@changeid |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp71027vqr; Fri, 26 May 2023 18:44:38 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4I16bPjnDY7fcqVbmE/PINgSfiKqCrSuET6TaBk1aehrd9FI+yRJsQ09AYNDZHFRSPEpZU X-Received: by 2002:a05:6a20:7f81:b0:100:47a5:d754 with SMTP id d1-20020a056a207f8100b0010047a5d754mr1769442pzj.23.1685151878594; Fri, 26 May 2023 18:44:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685151878; cv=none; d=google.com; s=arc-20160816; b=oFFR9HMpM9OYqqJqOYwx70Cu/RB0Vu3BXyp26EasZelItE+g0Sn1lrFFzsNfnFKXjy E8lduwj09b8rxY5iz5xMrwMRfHjuaRJy6ML9NQHRbP6E+TQrony3+rBXAYBWzWeThX3H 3Ja8s1d9Wc4nSwA9t5VcHFO/vsmv0RsJGh/6jUBDD5gEg1tmfTwbvKB/CLCrjHUJLuVz UqggD8TRvZC6j3ScfG7uw1ZL8Iq/M8FBx/k2p3x5jy9wKdKr2L4ZG3shEHFKRQMMklQF exl8x8w9T91MLqVXFdvo7nuiP9Gm2uSLnze9zE0XFFJ0lchCZzNf/LgDxgJQa4WC3hTV E7SA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=JxNnTqvzGhDuJSCmbsa+rtoHfqlXA4TJSz9TjwxMeho=; b=XJeo9A6ABUEo5aDFUrt1M+9K4AVYyE5gtZ+Ibl0OEjkUyReXP1DbtOB+UrcXDMqAsk I7ttuKt9EZW8+5dUjkZuAbVIUQ7s4k+3zUc7RfAcXx5pj7MbxX1W+jFXIAeToCO8hDEi J34NkE4c8UbRx9g+MkbP5rL2XRhcwCZt7C7lIQA4QT2qNFaHHBMeFky6jBwnaQi2CQGg cJHs8vz/0Y7MNPwq/5/i6jVBg3rROp9vJdtRf+k5DUZLUcOreREncdiMAPioQRJeYgZ9 Dh6awSckIbSLrTZv5Tkv1FtA1TK0Y1V1cd8C/UPXyipn2DvgIN8mBo41+OQ48VLv9Ha6 Kz8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ShJfBqA9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v190-20020a6389c7000000b0052c89d50011si5095624pgd.676.2023.05.26.18.44.23; Fri, 26 May 2023 18:44:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ShJfBqA9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243906AbjE0BnU (ORCPT <rfc822;zhanglyra.2023@gmail.com> + 99 others); Fri, 26 May 2023 21:43:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243948AbjE0Bmx (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 26 May 2023 21:42:53 -0400 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4E97CFB for <linux-kernel@vger.kernel.org>; Fri, 26 May 2023 18:42:34 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-64d2ca9ef0cso1124085b3a.1 for <linux-kernel@vger.kernel.org>; Fri, 26 May 2023 18:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1685151754; x=1687743754; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=JxNnTqvzGhDuJSCmbsa+rtoHfqlXA4TJSz9TjwxMeho=; b=ShJfBqA9ft7ncDs0dOFd2RPnmhJyBiEjNx2LZ1p8J3ek51VUldJqNKK6EfAx/6LMhv I51cZ9p9OhuJ3HYRQJPDRwiiLTttUI75WZhav7nrw8b5x+FhEcc5+eyfOPfL9y63jllh 02RO3yac0QfbIeTbVj1CHjUWHigjgjdAjKjnQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685151754; x=1687743754; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JxNnTqvzGhDuJSCmbsa+rtoHfqlXA4TJSz9TjwxMeho=; b=VzIh1678iMLYBESjl2IYSG289zORH0ssE7Of+QsG42LnU723DwlyaHG4iuoulYJFz0 xWquAe1tEDQiPd1F8Fd0UQiHyQld4R+lNE9+S7ejgxNhXziR5HDBn1hgX0PLfNNrehhS 1g/FU6w/OeZirBdWqidNJZHsaNsFhdBeRfIGjwR4aB4iTij+fJQbIM3VJv3/QkplWu7o eOEyj9ZvqkHIiT8VPCRqfozgC1L6BbkANhW4qmbbvh2IcuTFv9Ph1G9SZK0LKetxXdGV PhXwKzfcjwMOEUINwwqQNt22uAKCg6GTNK7etM6iIQ0bQSWexcya/N+swcB5vK19SiMr KVhg== X-Gm-Message-State: AC+VfDyYd/Uh5J3Ga/+JLQ3cC5pF6DVKm4vTOczYwTyzOUIOy13Z0dHw X8mtdM86BdbnuiGtP1zeEo6OXnvr9cUhfhsV/Z0= X-Received: by 2002:a05:6a00:3911:b0:63b:7fc0:a4af with SMTP id fh17-20020a056a00391100b0063b7fc0a4afmr5852154pfb.26.1685151753915; Fri, 26 May 2023 18:42:33 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:9d:2:4015:7255:c79a:26d7]) by smtp.gmail.com with ESMTPSA id x25-20020aa79199000000b0063b8ddf77f7sm3202440pfa.211.2023.05.26.18.42.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 May 2023 18:42:33 -0700 (PDT) From: Douglas Anderson <dianders@chromium.org> To: Petr Mladek <pmladek@suse.com>, Andrew Morton <akpm@linux-foundation.org> Cc: kgdb-bugreport@lists.sourceforge.net, linux-kernel@vger.kernel.org, Nicholas Piggin <npiggin@gmail.com>, Michael Ellerman <mpe@ellerman.id.au>, linuxppc-dev@lists.ozlabs.org, Christophe Leroy <christophe.leroy@csgroup.eu>, sparclinux@vger.kernel.org, "David S . Miller" <davem@davemloft.net>, linux-perf-users@vger.kernel.org, Douglas Anderson <dianders@chromium.org> Subject: [PATCH 10/10] watchdog/hardlockup: Rename HAVE_HARDLOCKUP_DETECTOR_NON_ARCH to ..._PERF_OR_BUDDY Date: Fri, 26 May 2023 18:41:40 -0700 Message-ID: <20230526184139.10.I821fe7609e57608913fe05abd8f35b343e7a9aae@changeid> X-Mailer: git-send-email 2.41.0.rc0.172.g3f132b7071-goog In-Reply-To: <20230527014153.2793931-1-dianders@chromium.org> References: <20230527014153.2793931-1-dianders@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767009815868326058?= X-GMAIL-MSGID: =?utf-8?q?1767009815868326058?= |
Series |
watchdog: Cleanup / fixes after buddy series v5 reviews
|
|
Commit Message
Doug Anderson
May 27, 2023, 1:41 a.m. UTC
HAVE_HARDLOCKUP_DETECTOR_NON_ARCH is a mouthful and
confusing. HAVE_HARDLOCKUP_DETECTOR_PERF_OR_BUDDY is even more of a
mouthful, but probably less confusing. Rename the Kconfig names.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
lib/Kconfig.debug | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
Comments
On Fri 2023-05-26 18:41:40, Douglas Anderson wrote: > HAVE_HARDLOCKUP_DETECTOR_NON_ARCH is a mouthful and > confusing. HAVE_HARDLOCKUP_DETECTOR_PERF_OR_BUDDY is even more of a > mouthful, but probably less confusing. Rename the Kconfig names. It is better. But I have an idea that might be even better. > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > > lib/Kconfig.debug | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index eb1edd5905bc..b9e162698a82 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -1058,7 +1058,7 @@ config HARDLOCKUP_DETECTOR_BUDDY > # needs SMP). In either case, using the "non-arch" code conflicts with > # the NMI watchdog code (which is sometimes used directly and sometimes used > # by the arch-provided hardlockup detector). The comment above still uses the term "no-arch" and tries to explain the confusion around it. > -config HAVE_HARDLOCKUP_DETECTOR_NON_ARCH > +config HAVE_HARDLOCKUP_DETECTOR_PERF_OR_BUDDY > bool > depends on (HAVE_HARDLOCKUP_DETECTOR_PERF || SMP) && !HAVE_NMI_WATCHDOG > default y > @@ -1077,10 +1077,10 @@ config HARDLOCKUP_DETECTOR_PREFER_BUDDY > an arch-specific hardlockup detector or if resources needed > for the hardlockup detector are better used for other things. > > -# This will select the appropriate non-arch hardlockdup detector > -config HARDLOCKUP_DETECTOR_NON_ARCH > +# This will select the appropriate non-arch hardlockup detector > +config HARDLOCKUP_DETECTOR_PERF_OR_BUDDY > bool > - depends on HAVE_HARDLOCKUP_DETECTOR_NON_ARCH > + depends on HAVE_HARDLOCKUP_DETECTOR_PERF_OR_BUDDY > select HARDLOCKUP_DETECTOR_BUDDY if !HAVE_HARDLOCKUP_DETECTOR_PERF || HARDLOCKUP_DETECTOR_PREFER_BUDDY > select HARDLOCKUP_DETECTOR_PERF if HAVE_HARDLOCKUP_DETECTOR_PERF && !HARDLOCKUP_DETECTOR_PREFER_BUDDY > > @@ -1098,9 +1098,9 @@ config HARDLOCKUP_CHECK_TIMESTAMP > config HARDLOCKUP_DETECTOR > bool "Detect Hard Lockups" > depends on DEBUG_KERNEL && !S390 > - depends on HAVE_HARDLOCKUP_DETECTOR_NON_ARCH || HAVE_HARDLOCKUP_DETECTOR_ARCH > + depends on HAVE_HARDLOCKUP_DETECTOR_PERF_OR_BUDDY || HAVE_HARDLOCKUP_DETECTOR_ARCH > select LOCKUP_DETECTOR > - select HARDLOCKUP_DETECTOR_NON_ARCH if HAVE_HARDLOCKUP_DETECTOR_NON_ARCH > + select HARDLOCKUP_DETECTOR_PERF_OR_BUDDY if HAVE_HARDLOCKUP_DETECTOR_PERF_OR_BUDDY > > help > Say Y here to enable the kernel to act as a watchdog to detect I am sorry but I am still confused by the logic. For me, it is far from clear what combinations are possible, impossible, and optional. Especially, the effect of HAVE_NMI_WATCHDOG and HAVE_HARDLOCKUP_DETECTOR_ARCH is quite tricky. I was playing with it and came up with a more straightforward solution and found more possibilities how the simplify the logic. I am going to prepare a patchset that would replace this patch. Just to get the idea. I made the following changes: + define the values in logical order: + HAVE_* + HARDLOCKUP_DETECTOR y/n value + HARDLOCKUP_DETECTOR_PREFER_BUDDY y/n value + HARDLOCKUP_DETECTOR_PERF decision based on above + HARDLOCKUP_DETECTOR_BUDDY decision based on above + remove HAVE_HARDLOCKUP_DETECTOR_PERF_OR_BUDDY, instead, explicitly define the dependencies on all HAVE_* variables to make it clear what it possible and what is not possible + remove HARDLOCKUP_DETECTOR_PERF_OR_BUDDY, instead use "imply" in HARDLOCKUP_DETECTOR to trigger re-evaluation of HARDLOCKUP_DETECTOR_PERF and HARDLOCKUP_DETECTOR_BUDDY decisions My current version has the following in lib/Kconfig.devel: --- cut --- config HAVE_HARDLOCKUP_DETECTOR_BUDDY bool depends on SMP default y # # arch/ can define HAVE_NMI_WATCHDOG to provide their own hard # lockup detector rather than the generic perf or buddy detector. # config HARDLOCKUP_DETECTOR bool "Detect Hard Lockups" depends on DEBUG_KERNEL && !S390 depends on HAVE_HARDLOCKUP_DETECTOR_PERF || HAVE_HARDLOCKUP_DETECTOR_BUDDY || HAVE_NMI_WATCHDOG imply HARDLOCKUP_DETECTOR_PERF imply HARDLOCKUP_DETECTOR_BUDDY select LOCKUP_DETECTOR help Say Y here to enable the kernel to act as a watchdog to detect hard lockups. Hardlockups are bugs that cause the CPU to loop in kernel mode for more than 10 seconds, without letting other interrupts have a chance to run. The current stack trace is displayed upon detection and the system will stay locked up. # # The architecture-specific variant is always used when available, # see HAVE_NMI_WATCHDOG # config HARDLOCKUP_DETECTOR_PREFER_BUDDY bool "Prefer the buddy CPU hardlockup detector" depends on HARDLOCKUP_DETECTOR depends on HAVE_HARDLOCKUP_DETECTOR_PERF && HAVE_HARDLOCKUP_DETECTOR_BUDDY && !HAVE_NMI_WATCHDOG default n help Say Y here to prefer the buddy hardlockup detector over the perf one. With the buddy detector, each CPU uses its softlockup hrtimer to check that the next CPU is processing hrtimer interrupts by verifying that a counter is increasing. This hardlockup detector is useful on systems that don't have an arch-specific hardlockup detector or if resources needed for the hardlockup detector are better used for other things. config HARDLOCKUP_DETECTOR_PERF bool depends on HARDLOCKUP_DETECTOR depends on HAVE_HARDLOCKUP_DETECTOR_PERF && !HARDLOCKUP_DETECTOR_PREFER_BUDDY && !HAVE_NMI_WATCHDOG select HARDLOCKUP_DETECTOR_COUNTS_HRTIMER config HARDLOCKUP_DETECTOR_BUDDY bool depends on HARDLOCKUP_DETECTOR depends on HAVE_HARDLOCKUP_DETECTOR_BUDDY depends on HARDLOCKUP_DETECTOR_PREFER_BUDDY || !HAVE_HARDLOCKUP_DETECTOR_PERF depends on !HAVE_NMI_WATCHDOG select HARDLOCKUP_DETECTOR_COUNTS_HRTIMER # Both the "perf" and "buddy" hardlockup detectors need counting hrtimer # interrupts. config HARDLOCKUP_DETECTOR_COUNTS_HRTIMER bool depends on HARDLOCKUP_DETECTOR_PERF || HARDLOCKUP_DETECTOR_BUDDY select SOFTLOCKUP_DETECTOR --- cut --- Also I am going to break the dependency between HAVE_NMI_WATCHDOG and HAVE_HADRDLOCKUP_DETECTOR_ARCH. HAVE_NMI_WATCHDOG is needed only for the very special powerpc64 watchdog. I am going to make sure that it will be used only there and it will not be needed for sparc and arm. As a result, we would have 4 separate implementations: + HAVE_HARDLOCKUP_DETECTOR_BUDDY enabled on any SMP system + HAVE_HARDLOCKUP_DETECTOR_PERF enabled on architectures supporting this perf-based solution + HAVE_HARDLOCKUP_DETECTOR_ARCH enabled on architectures which need another solution instead of the perf interface; they would support the usual HARDLOCKUP_DETECTOR command line parameters and sysctl interface + HAVE_NMI_WATCHDOG enabled just on powerpc64; it is special solution with its own command line parameters. Also it does not support hardlockup sysctl interface. I think about renaming it to HAVE_HARDLOCKUP_DETECTOR_POWERPC64 or _CUSTOM. Best Regards, Petr
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index eb1edd5905bc..b9e162698a82 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1058,7 +1058,7 @@ config HARDLOCKUP_DETECTOR_BUDDY # needs SMP). In either case, using the "non-arch" code conflicts with # the NMI watchdog code (which is sometimes used directly and sometimes used # by the arch-provided hardlockup detector). -config HAVE_HARDLOCKUP_DETECTOR_NON_ARCH +config HAVE_HARDLOCKUP_DETECTOR_PERF_OR_BUDDY bool depends on (HAVE_HARDLOCKUP_DETECTOR_PERF || SMP) && !HAVE_NMI_WATCHDOG default y @@ -1077,10 +1077,10 @@ config HARDLOCKUP_DETECTOR_PREFER_BUDDY an arch-specific hardlockup detector or if resources needed for the hardlockup detector are better used for other things. -# This will select the appropriate non-arch hardlockdup detector -config HARDLOCKUP_DETECTOR_NON_ARCH +# This will select the appropriate non-arch hardlockup detector +config HARDLOCKUP_DETECTOR_PERF_OR_BUDDY bool - depends on HAVE_HARDLOCKUP_DETECTOR_NON_ARCH + depends on HAVE_HARDLOCKUP_DETECTOR_PERF_OR_BUDDY select HARDLOCKUP_DETECTOR_BUDDY if !HAVE_HARDLOCKUP_DETECTOR_PERF || HARDLOCKUP_DETECTOR_PREFER_BUDDY select HARDLOCKUP_DETECTOR_PERF if HAVE_HARDLOCKUP_DETECTOR_PERF && !HARDLOCKUP_DETECTOR_PREFER_BUDDY @@ -1098,9 +1098,9 @@ config HARDLOCKUP_CHECK_TIMESTAMP config HARDLOCKUP_DETECTOR bool "Detect Hard Lockups" depends on DEBUG_KERNEL && !S390 - depends on HAVE_HARDLOCKUP_DETECTOR_NON_ARCH || HAVE_HARDLOCKUP_DETECTOR_ARCH + depends on HAVE_HARDLOCKUP_DETECTOR_PERF_OR_BUDDY || HAVE_HARDLOCKUP_DETECTOR_ARCH select LOCKUP_DETECTOR - select HARDLOCKUP_DETECTOR_NON_ARCH if HAVE_HARDLOCKUP_DETECTOR_NON_ARCH + select HARDLOCKUP_DETECTOR_PERF_OR_BUDDY if HAVE_HARDLOCKUP_DETECTOR_PERF_OR_BUDDY help Say Y here to enable the kernel to act as a watchdog to detect