Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754472AbcJTAAQ (ORCPT ); Wed, 19 Oct 2016 20:00:16 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:37293 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752621AbcJTAAO (ORCPT ); Wed, 19 Oct 2016 20:00:14 -0400 Date: Wed, 19 Oct 2016 17:00:12 -0700 From: Andrew Morton To: Babu Moger Cc: mingo@kernel.org, ak@linux.intel.com, jkosina@suse.cz, baiyaowei@cmss.chinamobile.com, dzickus@redhat.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: <20161019170012.6006d06d9326e62a8059fd08@linux-foundation.org> In-Reply-To: <1476391082-77928-2-git-send-email-babu.moger@oracle.com> References: <1476391082-77928-1-git-send-email-babu.moger@oracle.com> <1476391082-77928-2-git-send-email-babu.moger@oracle.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1537 Lines: 39 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. 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?