Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941138AbcJTQOf (ORCPT ); Thu, 20 Oct 2016 12:14:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34678 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932213AbcJTQOe (ORCPT ); Thu, 20 Oct 2016 12:14:34 -0400 Date: Thu, 20 Oct 2016 12:14:14 -0400 From: Don Zickus To: Andrew Morton Cc: Babu Moger , mingo@kernel.org, ak@linux.intel.com, jkosina@suse.cz, baiyaowei@cmss.chinamobile.com, atomlin@redhat.com, uobergfe@redhat.com, tj@kernel.org, hidehiro.kawai.ez@hitachi.com, johunt@akamai.com, davem@davemloft.net, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, sam@ravnborg.org Subject: Re: [PATCH v2 1/2] watchdog: Introduce arch_watchdog_nmi_enable and arch_watchdog_nmi_disable Message-ID: <20161020161414.GE35881@redhat.com> References: <1476391082-77928-1-git-send-email-babu.moger@oracle.com> <1476391082-77928-2-git-send-email-babu.moger@oracle.com> <20161019170012.6006d06d9326e62a8059fd08@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161019170012.6006d06d9326e62a8059fd08@linux-foundation.org> User-Agent: Mutt/1.5.23.1 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 20 Oct 2016 16:14:33 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2350 Lines: 59 On Wed, Oct 19, 2016 at 05:00:12PM -0700, Andrew Morton wrote: > On Thu, 13 Oct 2016 13:38:01 -0700 Babu Moger wrote: > > > Currently we do not have a way to enable/disable arch specific > > watchdog handlers if it was implemented by any of the architectures. > > > > This patch introduces new functions arch_watchdog_nmi_enable and > > arch_watchdog_nmi_disable which can be used to enable/disable architecture > > specific NMI watchdog handlers. These functions are defined as weak as > > architectures can override their definitions to enable/disable nmi > > watchdog behaviour. > > > > --- a/kernel/watchdog.c > > +++ b/kernel/watchdog.c > > @@ -676,8 +660,13 @@ static void watchdog_nmi_disable(unsigned int cpu) > > } > > > > #else > > -static int watchdog_nmi_enable(unsigned int cpu) { return 0; } > > -static void watchdog_nmi_disable(unsigned int cpu) { return; } > > +/* > > + * These two functions are mostly architecture specific > > + * defining them as weak here. > > + */ > > +int __weak arch_watchdog_nmi_enable(unsigned int cpu) { return 0; } > > +void __weak arch_watchdog_nmi_disable(unsigned int cpu) { return; } > > + > > #endif /* CONFIG_HARDLOCKUP_DETECTOR */ > > This is a strange way of using __weak. > > Take a look at (one of many examples) kernel/module.c:module_alloc(). > We simply provide a default implementation and some other compilation > unit can override (actually replace) that at link time. No strange > ifdeffing needed. Yeah, this is mostly because of how we enable the hardlockup detector. Some arches use the perf hw and enable CONFIG_HARDLOCKUP_DETECTOR. Other arches just use their own variant of nmi and set CONFIG_HAVE_NMI_WATCHDOG and the rest of the arches do not use this. So the thought was if CONFIG_HARDLOCKUP_DETECTOR use that implementation, everyone else use the __weak version. Then the arches like sparc can override the weak version with their own nmi enablement. I don't know how to represent those 3 states correctly and the above is what we end up with. > > And I'm not really understanding the interaction with > CONFIG_HARDLOCKUP_DETECTOR here. I haven't really worked out why the > code is all this way but it seems.... odd? If the above explaination doesn't help, then can you point to some examples where things seem odd? Cheers, Don