[v5,13/18] watchdog/hardlockup: Have the perf hardlockup use __weak functions more cleanly
Message ID | 20230519101840.v5.13.I847d9ec852449350997ba00401d2462a9cb4302b@changeid |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1413394vqo; Fri, 19 May 2023 10:47:23 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4280O3i9iUzdjaFkVLtulIM8V2E/kobKOqQRXZCvUVNx6JcYQqD33WM/aYtO/pHr6ONJBo X-Received: by 2002:a05:6a20:d39a:b0:105:7857:e4dc with SMTP id iq26-20020a056a20d39a00b001057857e4dcmr2841907pzb.7.1684518443441; Fri, 19 May 2023 10:47:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684518443; cv=none; d=google.com; s=arc-20160816; b=HhJJ3+qeWNV+tR+NdqklieRx07is8n8ZJ9pElHGxS1yb3M+CGicrWECdB48dniHJyG MrzqpRQok8DtKpSkiD8QhO3Kk8QEZBhnqRREQOz8V7KJJ89gpMBXNN1rJlrH1XWIDjWf apGXzk2Ak4zQLq/QLpcCJsZcgLHE2D9JY+Efyf0RPp4R+EyCFYAgp8/i81bUAxSfiBA2 RlldMv12z/knieA0qR0FvqOkpvVyTcENoaWm4p7WPn10SiTJ9zUSXLBPCNGsBU25UIW5 SOp49hc5d+r2rnkmjN8Rt/HYoRVgg1FVoERd1IkMEeOr0uurxzj0srVbI7H73FdVkEJe wlhA== 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=fNhCL1Huez0uTcL8SW38wDXgmNTYe9rvFeaGt7OObeE=; b=wHnIUS17e+DjbFysiF/ZcegC7QYiy+4M+KPsHHSbIcpGJf/sWGT2EbgZOyjZOyeERb EkcPAYpWjE0rtWDoPltxEluMpuATxTDdLPvw+ffCBYrx4p+nSArKVXExZThBf21Xich2 mq6CBI2XKCg5v2zBhfN4sUAjoHJOsa/beb8/JTO0hm384JONKqJSmlVQ8Lo9bMepqitG +gYcnirBn34FCH4b/WIwAfcqT3bLEh53lH57TKKkmASV9nuYq6B6IKtRy3L/j1Gb1CgW 7Q7MLNzJL4Af0VeRnVtiTf+iUXkkWZelsEkrvbDpQ9Lzi+VqyaSPor+IoA9FrtA/Fv4L ErQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="DE9ifr/I"; 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 m26-20020a63711a000000b005309f24f940si2648556pgc.586.2023.05.19.10.47.08; Fri, 19 May 2023 10:47:23 -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="DE9ifr/I"; 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 S231617AbjESRWW (ORCPT <rfc822;wlfightup@gmail.com> + 99 others); Fri, 19 May 2023 13:22:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230479AbjESRVr (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 19 May 2023 13:21:47 -0400 Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA3E11BC6 for <linux-kernel@vger.kernel.org>; Fri, 19 May 2023 10:21:19 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-25343f0c693so2483278a91.3 for <linux-kernel@vger.kernel.org>; Fri, 19 May 2023 10:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1684516877; x=1687108877; 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=fNhCL1Huez0uTcL8SW38wDXgmNTYe9rvFeaGt7OObeE=; b=DE9ifr/I3G7wJ8II405PBbAcS++31EpYP/eYxV2Sqw9gEjlXEiqZL3Rnu4bmnmd5jh CLMn/65EiiSwED/Fr5hrsrF54ilv7twfAOG8cLqgV19i5+0tZ3x9T4leakl5h6Z++Bea n+ur25VX7VjlNaBvGlg8u7d/+jLb9LCbxCA3A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684516877; x=1687108877; 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=fNhCL1Huez0uTcL8SW38wDXgmNTYe9rvFeaGt7OObeE=; b=A8/+iCnVzDTE3jrc0vuSa2FOZho+hj1i0e7elxreRF0VyOS8aCVHrgjFlSdkJv+S60 cm4pKkSuI5nClveNiInnz6vL0VHUc2yoSpk8u4lSOZauFHI/oqIBYA5T21SOEUtW+h5G G92wn8feo+jTLDZ5pFaTxN2cNRuqUl2XT9GMlaXZt5z3lJ/MrCNWn8utHFoyiktTZt+i yCpEDVJa9VCQDqp6d/9rQlFOFUiBxGnzDmkmje8K2yZNxB5nNL52OpC0aYVzdh7jbokl +/qaiJlJXZxhgIX0MhQYShqd3PQLQUvQyVuq0qXtQZ0cEii8xgBr+8rf9OiL5J9I8nqD oPLg== X-Gm-Message-State: AC+VfDyqZFt2e022vRr3GssqrQBh6XDiZGJ7519WXtjHcC0YDUFMlTzK UlF3SDi+TZAIucxdWhgBAAsJxQ== X-Received: by 2002:a17:90a:c503:b0:253:41b8:13d6 with SMTP id k3-20020a17090ac50300b0025341b813d6mr2749539pjt.21.1684516877257; Fri, 19 May 2023 10:21:17 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:9d:2:9b89:2dd0:d160:429d]) by smtp.gmail.com with ESMTPSA id gj19-20020a17090b109300b0024e4f169931sm1763835pjb.2.2023.05.19.10.21.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 May 2023 10:21:16 -0700 (PDT) From: Douglas Anderson <dianders@chromium.org> To: Petr Mladek <pmladek@suse.com>, Andrew Morton <akpm@linux-foundation.org> Cc: Matthias Kaehlcke <mka@chromium.org>, kgdb-bugreport@lists.sourceforge.net, Stephane Eranian <eranian@google.com>, mpe@ellerman.id.au, Tzung-Bi Shih <tzungbi@chromium.org>, Daniel Thompson <daniel.thompson@linaro.org>, Mark Rutland <mark.rutland@arm.com>, linuxppc-dev@lists.ozlabs.org, Sumit Garg <sumit.garg@linaro.org>, npiggin@gmail.com, davem@davemloft.net, Marc Zyngier <maz@kernel.org>, Stephen Boyd <swboyd@chromium.org>, sparclinux@vger.kernel.org, christophe.leroy@csgroup.eu, Catalin Marinas <catalin.marinas@arm.com>, ravi.v.shankar@intel.com, Randy Dunlap <rdunlap@infradead.org>, Pingfan Liu <kernelfans@gmail.com>, Guenter Roeck <groeck@chromium.org>, Lecopzer Chen <lecopzer.chen@mediatek.com>, Ian Rogers <irogers@google.com>, ito-yuichi@fujitsu.com, ricardo.neri@intel.com, linux-arm-kernel@lists.infradead.org, linux-perf-users@vger.kernel.org, Will Deacon <will@kernel.org>, Chen-Yu Tsai <wens@csie.org>, linux-kernel@vger.kernel.org, Masayoshi Mizuma <msys.mizuma@gmail.com>, Andi Kleen <ak@linux.intel.com>, Douglas Anderson <dianders@chromium.org> Subject: [PATCH v5 13/18] watchdog/hardlockup: Have the perf hardlockup use __weak functions more cleanly Date: Fri, 19 May 2023 10:18:37 -0700 Message-ID: <20230519101840.v5.13.I847d9ec852449350997ba00401d2462a9cb4302b@changeid> X-Mailer: git-send-email 2.40.1.698.g37aff9b760-goog In-Reply-To: <20230519101840.v5.18.Ia44852044cdcb074f387e80df6b45e892965d4a1@changeid> References: <20230519101840.v5.18.Ia44852044cdcb074f387e80df6b45e892965d4a1@changeid> 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,URIBL_BLOCKED autolearn=unavailable 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?1766345611346382213?= X-GMAIL-MSGID: =?utf-8?q?1766345611346382213?= |
Series |
watchdog/hardlockup: Add the buddy hardlockup detector
|
|
Commit Message
Doug Anderson
May 19, 2023, 5:18 p.m. UTC
The fact that there watchdog_hardlockup_enable(), watchdog_hardlockup_disable(), and watchdog_hardlockup_probe() are declared __weak means that the configured hardlockup detector can define non-weak versions of those functions if it needs to. Instead of doing this, the perf hardlockup detector hooked itself into the default __weak implementation, which was a bit awkward. Clean this up. From comments, it looks as if the original design was done because the __weak function were expected to implemented by the architecture and not by the configured hardlockup detector. This got awkward when we tried to add the buddy lockup detector which was not arch-specific but wanted to hook into those same functions. This is not expected to have any functional impact. Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> --- (no changes since v4) Changes in v4: - ("Have the perf hardlockup use __weak ...") new for v4. include/linux/nmi.h | 10 ---------- kernel/watchdog.c | 30 ++++++++++++++++++------------ kernel/watchdog_perf.c | 20 ++++++++++++++------ 3 files changed, 32 insertions(+), 28 deletions(-)
Comments
On Fri 2023-05-19 10:18:37, Douglas Anderson wrote: > The fact that there watchdog_hardlockup_enable(), > watchdog_hardlockup_disable(), and watchdog_hardlockup_probe() are > declared __weak means that the configured hardlockup detector can > define non-weak versions of those functions if it needs to. Instead of > doing this, the perf hardlockup detector hooked itself into the > default __weak implementation, which was a bit awkward. Clean this up. > > >From comments, it looks as if the original design was done because the > __weak function were expected to implemented by the architecture and > not by the configured hardlockup detector. This got awkward when we > tried to add the buddy lockup detector which was not arch-specific but > wanted to hook into those same functions. > > This is not expected to have any functional impact. > > @@ -187,27 +187,33 @@ static inline void watchdog_hardlockup_kick(void) { } > #endif /* !CONFIG_HARDLOCKUP_DETECTOR_PERF */ > > /* > - * These functions can be overridden if an architecture implements its > - * own hardlockup detector. > + * These functions can be overridden based on the configured hardlockdup detector. > * > * watchdog_hardlockup_enable/disable can be implemented to start and stop when > - * softlockup watchdog start and stop. The arch must select the > + * softlockup watchdog start and stop. The detector must select the > * SOFTLOCKUP_DETECTOR Kconfig. > */ > -void __weak watchdog_hardlockup_enable(unsigned int cpu) > -{ > - hardlockup_detector_perf_enable(); > -} > +void __weak watchdog_hardlockup_enable(unsigned int cpu) { } > > -void __weak watchdog_hardlockup_disable(unsigned int cpu) > -{ > - hardlockup_detector_perf_disable(); > -} > +void __weak watchdog_hardlockup_disable(unsigned int cpu) { } > > /* Return 0, if a hardlockup watchdog is available. Error code otherwise */ > int __weak __init watchdog_hardlockup_probe(void) > { > - return hardlockup_detector_perf_init(); > + /* > + * If CONFIG_HAVE_NMI_WATCHDOG is defined then an architecture > + * is assumed to have the hard watchdog available and we return 0. > + */ > + if (IS_ENABLED(CONFIG_HAVE_NMI_WATCHDOG)) > + return 0; > + > + /* > + * Hardlockup detectors other than those using CONFIG_HAVE_NMI_WATCHDOG > + * are required to implement a non-weak version of this probe function > + * to tell whether they are available. If they don't override then > + * we'll return -ENODEV. > + */ > + return -ENODEV; > } When thinking more about it. It is weird that we need to handle CONFIG_HAVE_NMI_WATCHDOG in this default week function. It should be handled in watchdog_hardlockup_probe() implemented in kernel/watchdog_perf.c. IMHO, the default __weak function could always return -ENODEV; Would it make sense, please? Best Regards, Petr
Hi, On Wed, May 24, 2023 at 6:59 AM Petr Mladek <pmladek@suse.com> wrote: > > On Fri 2023-05-19 10:18:37, Douglas Anderson wrote: > > The fact that there watchdog_hardlockup_enable(), > > watchdog_hardlockup_disable(), and watchdog_hardlockup_probe() are > > declared __weak means that the configured hardlockup detector can > > define non-weak versions of those functions if it needs to. Instead of > > doing this, the perf hardlockup detector hooked itself into the > > default __weak implementation, which was a bit awkward. Clean this up. > > > > >From comments, it looks as if the original design was done because the > > __weak function were expected to implemented by the architecture and > > not by the configured hardlockup detector. This got awkward when we > > tried to add the buddy lockup detector which was not arch-specific but > > wanted to hook into those same functions. > > > > This is not expected to have any functional impact. > > > > @@ -187,27 +187,33 @@ static inline void watchdog_hardlockup_kick(void) { } > > #endif /* !CONFIG_HARDLOCKUP_DETECTOR_PERF */ > > > > /* > > - * These functions can be overridden if an architecture implements its > > - * own hardlockup detector. > > + * These functions can be overridden based on the configured hardlockdup detector. > > * > > * watchdog_hardlockup_enable/disable can be implemented to start and stop when > > - * softlockup watchdog start and stop. The arch must select the > > + * softlockup watchdog start and stop. The detector must select the > > * SOFTLOCKUP_DETECTOR Kconfig. > > */ > > -void __weak watchdog_hardlockup_enable(unsigned int cpu) > > -{ > > - hardlockup_detector_perf_enable(); > > -} > > +void __weak watchdog_hardlockup_enable(unsigned int cpu) { } > > > > -void __weak watchdog_hardlockup_disable(unsigned int cpu) > > -{ > > - hardlockup_detector_perf_disable(); > > -} > > +void __weak watchdog_hardlockup_disable(unsigned int cpu) { } > > > > /* Return 0, if a hardlockup watchdog is available. Error code otherwise */ > > int __weak __init watchdog_hardlockup_probe(void) > > { > > - return hardlockup_detector_perf_init(); > > + /* > > + * If CONFIG_HAVE_NMI_WATCHDOG is defined then an architecture > > + * is assumed to have the hard watchdog available and we return 0. > > + */ > > + if (IS_ENABLED(CONFIG_HAVE_NMI_WATCHDOG)) > > + return 0; > > + > > + /* > > + * Hardlockup detectors other than those using CONFIG_HAVE_NMI_WATCHDOG > > + * are required to implement a non-weak version of this probe function > > + * to tell whether they are available. If they don't override then > > + * we'll return -ENODEV. > > + */ > > + return -ENODEV; > > } > > When thinking more about it. It is weird that we need to handle > CONFIG_HAVE_NMI_WATCHDOG in this default week function. > > It should be handled in watchdog_hardlockup_probe() implemented > in kernel/watchdog_perf.c. > > IMHO, the default __weak function could always return -ENODEV; > > Would it make sense, please? I don't quite understand. I'd agree that the special case for CONFIG_HAVE_NMI_WATCHDOG is ugly, but it was also ugly before. IMO it's actually a little less ugly / easier to understand after my patch. ...but let me walk through how I think this special case works and maybe you can tell me where I'm confused. The first thing to understand is that CONFIG_HARDLOCKUP_DETECTOR_PERF and CONFIG_HAVE_NMI_WATCHDOG are mutually exclusive from each other. This was true before any of my patches and is still true after them. Specifically, if CONFIG_HAVE_NMI_WATCHDOG is defined then an architecture implements arch_touch_nmi_watchdog() (as documented in the Kconfig docs for HAVE_NMI_WATCHDOG). Looking at the tree before my series you can see that the perf hardlockup detector also implemented arch_touch_nmi_watchdog(). This would have caused a conflict. The mutual exclusion was presumably enforced by an architecture not defining both HAVE_NMI_WATCHDOG and HAVE_HARDLOCKUP_DETECTOR_PERF. The second thing to understand is that an architecture that defines CONFIG_HAVE_NMI_WATCHDOG is _not_ required to implement watchdog_hardlockup_probe() (used to be called watchdog_nmi_probe()). Maybe this should change, but at the very least it appears that SPARC64 defines HAVE_NMI_WATCHDOG but doesn't define watchdog_hardlockup_probe() AKA watchdog_nmi_probe(). Anyone who defines CONFIG_HAVE_NMI_WATCHDOG and doesn't implement watchdog_hardlockup_probe() is claiming that their watchdog needs no probing and is always available. So with that context: 1. We can't handle any special cases for CONFIG_HAVE_NMI_WATCHDOG in "kernel/watchdog_perf.c". The special cases that we need to handle are all for the cases where CONFIG_HARDLOCKUP_DETECTOR_PERF isn't defined and that means "kernel/watchdog_perf.c" isn't included. 2. We can't have the default __weak function return -ENODEV because CONFIG_HAVE_NMI_WATCHDOG doesn't require an arch to implement watchdog_hardlockup_probe(), but we want watchdog_hardlockup_probe() to return "no error" in that case so that "watchdog_hardlockup_available" gets set to true. Does that sound right? I'd agree that a future improvement saying that CONFIG_HAVE_NMI_WATCHDOG means you _must_ implement watchdog_hardlockup_probe() would make sense and that would allow us to get rid of the special case. IMO, though, that's a separate patch. I'd be happy to review that patch if you wanted to post it up. :-) If we want to add that requirement, I _think_ the only thing you'd need to do is to add watchdog_hardlockup_probe() to sparc64 and have it return 0 and put that definition in the same file containing arch_touch_nmi_watchdog(). powerpc also gets CONFIG_HAVE_NMI_WATCHDOG as a side effect of selecting CONFIG_HAVE_HARDLOCKUP_DETECTOR_ARCH but it looks like they implement watchdog_hardlockup_probe() already. Oh, but maybe this will fix a preexisting (existed before my patches) minor bug... Unless I'm missing something (entirely possible!) on powerpc today I guess if you turn off CONFIG_PPC_WATCHDOG then CONFIG_HAVE_HARDLOCKUP_DETECTOR_ARCH and CONFIG_HAVE_NMI_WATCHDOG would still be defined and we'd end up returning 0 (no error) from watchdog_hardlockup_probe(). That means that on powerpc today if you turn off CONFIG_PPC_WATCHDOG that '/proc/sys/kernel/nmi_watchdog' will still think the watchdog is enabled? -Doug
On Wed 2023-05-24 12:38:49, Doug Anderson wrote: > Hi, > > On Wed, May 24, 2023 at 6:59 AM Petr Mladek <pmladek@suse.com> wrote: > > > > On Fri 2023-05-19 10:18:37, Douglas Anderson wrote: > > > The fact that there watchdog_hardlockup_enable(), > > > watchdog_hardlockup_disable(), and watchdog_hardlockup_probe() are > > > declared __weak means that the configured hardlockup detector can > > > define non-weak versions of those functions if it needs to. Instead of > > > doing this, the perf hardlockup detector hooked itself into the > > > default __weak implementation, which was a bit awkward. Clean this up. > > > > > > >From comments, it looks as if the original design was done because the > > > __weak function were expected to implemented by the architecture and > > > not by the configured hardlockup detector. This got awkward when we > > > tried to add the buddy lockup detector which was not arch-specific but > > > wanted to hook into those same functions. > > > > > > This is not expected to have any functional impact. > > > > > > @@ -187,27 +187,33 @@ static inline void watchdog_hardlockup_kick(void) { } > > > #endif /* !CONFIG_HARDLOCKUP_DETECTOR_PERF */ > > > > > > /* > > > - * These functions can be overridden if an architecture implements its > > > - * own hardlockup detector. > > > + * These functions can be overridden based on the configured hardlockdup detector. > > > * > > > * watchdog_hardlockup_enable/disable can be implemented to start and stop when > > > - * softlockup watchdog start and stop. The arch must select the > > > + * softlockup watchdog start and stop. The detector must select the > > > * SOFTLOCKUP_DETECTOR Kconfig. > > > */ > > > -void __weak watchdog_hardlockup_enable(unsigned int cpu) > > > -{ > > > - hardlockup_detector_perf_enable(); > > > -} > > > +void __weak watchdog_hardlockup_enable(unsigned int cpu) { } > > > > > > -void __weak watchdog_hardlockup_disable(unsigned int cpu) > > > -{ > > > - hardlockup_detector_perf_disable(); > > > -} > > > +void __weak watchdog_hardlockup_disable(unsigned int cpu) { } > > > > > > /* Return 0, if a hardlockup watchdog is available. Error code otherwise */ > > > int __weak __init watchdog_hardlockup_probe(void) > > > { > > > - return hardlockup_detector_perf_init(); > > > + /* > > > + * If CONFIG_HAVE_NMI_WATCHDOG is defined then an architecture > > > + * is assumed to have the hard watchdog available and we return 0. > > > + */ > > > + if (IS_ENABLED(CONFIG_HAVE_NMI_WATCHDOG)) > > > + return 0; > > > + > > > + /* > > > + * Hardlockup detectors other than those using CONFIG_HAVE_NMI_WATCHDOG > > > + * are required to implement a non-weak version of this probe function > > > + * to tell whether they are available. If they don't override then > > > + * we'll return -ENODEV. > > > + */ > > > + return -ENODEV; > > > } > > > > When thinking more about it. It is weird that we need to handle > > CONFIG_HAVE_NMI_WATCHDOG in this default week function. > > > > It should be handled in watchdog_hardlockup_probe() implemented > > in kernel/watchdog_perf.c. > > > > IMHO, the default __weak function could always return -ENODEV; > > > > Would it make sense, please? > > I don't quite understand. I'd agree that the special case for > CONFIG_HAVE_NMI_WATCHDOG is ugly, but it was also ugly before. IMO > it's actually a little less ugly / easier to understand after my > patch. ...but let me walk through how I think this special case works > and maybe you can tell me where I'm confused. > > The first thing to understand is that CONFIG_HARDLOCKUP_DETECTOR_PERF > and CONFIG_HAVE_NMI_WATCHDOG are mutually exclusive from each other. > This was true before any of my patches and is still true after them. > Specifically, if CONFIG_HAVE_NMI_WATCHDOG is defined then an > architecture implements arch_touch_nmi_watchdog() (as documented in > the Kconfig docs for HAVE_NMI_WATCHDOG). Looking at the tree before my > series you can see that the perf hardlockup detector also implemented > arch_touch_nmi_watchdog(). This would have caused a conflict. The > mutual exclusion was presumably enforced by an architecture not > defining both HAVE_NMI_WATCHDOG and HAVE_HARDLOCKUP_DETECTOR_PERF. > > The second thing to understand is that an architecture that defines > CONFIG_HAVE_NMI_WATCHDOG is _not_ required to implement > watchdog_hardlockup_probe() (used to be called watchdog_nmi_probe()). > Maybe this should change, but at the very least it appears that > SPARC64 defines HAVE_NMI_WATCHDOG but doesn't define > watchdog_hardlockup_probe() AKA watchdog_nmi_probe(). Anyone who > defines CONFIG_HAVE_NMI_WATCHDOG and doesn't implement > watchdog_hardlockup_probe() is claiming that their watchdog needs no > probing and is always available. > > So with that context: > > 1. We can't handle any special cases for CONFIG_HAVE_NMI_WATCHDOG in > "kernel/watchdog_perf.c". The special cases that we need to handle are > all for the cases where CONFIG_HARDLOCKUP_DETECTOR_PERF isn't defined > and that means "kernel/watchdog_perf.c" isn't included. > > 2. We can't have the default __weak function return -ENODEV because > CONFIG_HAVE_NMI_WATCHDOG doesn't require an arch to implement > watchdog_hardlockup_probe(), but we want watchdog_hardlockup_probe() > to return "no error" in that case so that > "watchdog_hardlockup_available" gets set to true. > > Does that sound right? > > I'd agree that a future improvement saying that > CONFIG_HAVE_NMI_WATCHDOG means you _must_ implement > watchdog_hardlockup_probe() would make sense and that would allow us > to get rid of the special case. IMO, though, that's a separate patch. > I'd be happy to review that patch if you wanted to post it up. :-) > > If we want to add that requirement, I _think_ the only thing you'd > need to do is to add watchdog_hardlockup_probe() to sparc64 and have > it return 0 and put that definition in the same file containing > arch_touch_nmi_watchdog(). This is my understanding. IMHO, if we define watchdog_hardlockup_probe() in /arch/sparc/kernel/nmi.c then we could remove the CONFIG_HAVE_NMI_WATCHDOG check from the default watchdog_hardlockup_probe(). Honestly, I am afraid that nobody really thought about any rules. People were just adding their stuff any way that worked for them. And this is why we ended with this maze. It is not your fault. You just moved the ifdef from the header file into the function definition. But it showed very well how ugly it was. By ugly, I mean that powerpc, perf, and buddy hardlockup detectors make watchdog_hardlockup_probe() successful by implementing an alternative to the default weak implementation. Only, sparc64 reports success via a crazy check in the default weak configuration. The check is crazy because it makes the decision based on CONFIG_HAVE_NMI_WATCHDOG. But the related code is in arch/sparc/kernel/nmi.c which is compiled when CONFIG_SPARC64 is enabled. The connection between CONFIG_HAVE_NMI_WATCHDOG and CONFIG_SPARC64 is hidden in arch/sparc/Kconfig. It would be much more straightforward when the weak function is implemented in arch/sparc/kernel/nmi.c. It will be clear that probe() will succeed when the watchdog gets initialized. > powerpc also gets CONFIG_HAVE_NMI_WATCHDOG > as a side effect of selecting CONFIG_HAVE_HARDLOCKUP_DETECTOR_ARCH but > it looks like they implement watchdog_hardlockup_probe() already. Oh, > but maybe this will fix a preexisting (existed before my patches) > minor bug... Unless I'm missing something (entirely possible!) on > powerpc today I guess if you turn off CONFIG_PPC_WATCHDOG then > CONFIG_HAVE_HARDLOCKUP_DETECTOR_ARCH and CONFIG_HAVE_NMI_WATCHDOG > would still be defined and we'd end up returning 0 (no error) from > watchdog_hardlockup_probe(). That means that on powerpc today if you > turn off CONFIG_PPC_WATCHDOG that '/proc/sys/kernel/nmi_watchdog' will > still think the watchdog is enabled? Yeah, it seems that this bug was there. And it will get fixed when the default weak implementation of watchdog_hardlockup_probe() always returns false. Again, I'll let Andrew to decide whether this should get cleaned in this patchset or later. But it would be fine to fix this after we spent so much time understanding the mess. Best Regards, Petr
diff --git a/include/linux/nmi.h b/include/linux/nmi.h index 83076bf70ce8..c216e8a1be1f 100644 --- a/include/linux/nmi.h +++ b/include/linux/nmi.h @@ -103,21 +103,11 @@ static inline void arch_touch_nmi_watchdog(void) { } #if defined(CONFIG_HARDLOCKUP_DETECTOR_PERF) extern void hardlockup_detector_perf_stop(void); extern void hardlockup_detector_perf_restart(void); -extern void hardlockup_detector_perf_disable(void); -extern void hardlockup_detector_perf_enable(void); extern void hardlockup_detector_perf_cleanup(void); -extern int hardlockup_detector_perf_init(void); #else static inline void hardlockup_detector_perf_stop(void) { } static inline void hardlockup_detector_perf_restart(void) { } -static inline void hardlockup_detector_perf_disable(void) { } -static inline void hardlockup_detector_perf_enable(void) { } static inline void hardlockup_detector_perf_cleanup(void) { } -# if !defined(CONFIG_HAVE_NMI_WATCHDOG) -static inline int hardlockup_detector_perf_init(void) { return -ENODEV; } -# else -static inline int hardlockup_detector_perf_init(void) { return 0; } -# endif #endif void watchdog_hardlockup_stop(void); diff --git a/kernel/watchdog.c b/kernel/watchdog.c index 31548c0ae874..08ce046f636d 100644 --- a/kernel/watchdog.c +++ b/kernel/watchdog.c @@ -187,27 +187,33 @@ static inline void watchdog_hardlockup_kick(void) { } #endif /* !CONFIG_HARDLOCKUP_DETECTOR_PERF */ /* - * These functions can be overridden if an architecture implements its - * own hardlockup detector. + * These functions can be overridden based on the configured hardlockdup detector. * * watchdog_hardlockup_enable/disable can be implemented to start and stop when - * softlockup watchdog start and stop. The arch must select the + * softlockup watchdog start and stop. The detector must select the * SOFTLOCKUP_DETECTOR Kconfig. */ -void __weak watchdog_hardlockup_enable(unsigned int cpu) -{ - hardlockup_detector_perf_enable(); -} +void __weak watchdog_hardlockup_enable(unsigned int cpu) { } -void __weak watchdog_hardlockup_disable(unsigned int cpu) -{ - hardlockup_detector_perf_disable(); -} +void __weak watchdog_hardlockup_disable(unsigned int cpu) { } /* Return 0, if a hardlockup watchdog is available. Error code otherwise */ int __weak __init watchdog_hardlockup_probe(void) { - return hardlockup_detector_perf_init(); + /* + * If CONFIG_HAVE_NMI_WATCHDOG is defined then an architecture + * is assumed to have the hard watchdog available and we return 0. + */ + if (IS_ENABLED(CONFIG_HAVE_NMI_WATCHDOG)) + return 0; + + /* + * Hardlockup detectors other than those using CONFIG_HAVE_NMI_WATCHDOG + * are required to implement a non-weak version of this probe function + * to tell whether they are available. If they don't override then + * we'll return -ENODEV. + */ + return -ENODEV; } /** diff --git a/kernel/watchdog_perf.c b/kernel/watchdog_perf.c index 9e6042a892b3..349fcd4d2abc 100644 --- a/kernel/watchdog_perf.c +++ b/kernel/watchdog_perf.c @@ -132,10 +132,14 @@ static int hardlockup_detector_event_create(void) } /** - * hardlockup_detector_perf_enable - Enable the local event + * watchdog_hardlockup_enable - Enable the local event + * + * @cpu: The CPU to enable hard lockup on. */ -void hardlockup_detector_perf_enable(void) +void watchdog_hardlockup_enable(unsigned int cpu) { + WARN_ON_ONCE(cpu != smp_processor_id()); + if (hardlockup_detector_event_create()) return; @@ -147,12 +151,16 @@ void hardlockup_detector_perf_enable(void) } /** - * hardlockup_detector_perf_disable - Disable the local event + * watchdog_hardlockup_disable - Disable the local event + * + * @cpu: The CPU to enable hard lockup on. */ -void hardlockup_detector_perf_disable(void) +void watchdog_hardlockup_disable(unsigned int cpu) { struct perf_event *event = this_cpu_read(watchdog_ev); + WARN_ON_ONCE(cpu != smp_processor_id()); + if (event) { perf_event_disable(event); this_cpu_write(watchdog_ev, NULL); @@ -227,9 +235,9 @@ void __init hardlockup_detector_perf_restart(void) } /** - * hardlockup_detector_perf_init - Probe whether NMI event is available at all + * watchdog_hardlockup_probe - Probe whether NMI event is available at all */ -int __init hardlockup_detector_perf_init(void) +int __init watchdog_hardlockup_probe(void) { int ret = hardlockup_detector_event_create();