linux-kernel - Re: [PATCH v2 1/2] watchdog: Introduce arch_watchdog_nmi_enable and arch_watchdog_nmi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20161019170012.6006d06d9326e62a8059fd08@linux-foundation.org>
Date:   Wed, 19 Oct 2016 17:00:12 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Babu Moger <babu.moger@...cle.com>
Cc:     mingo@...nel.org, ak@...ux.intel.com, jkosina@...e.cz,
        baiyaowei@...s.chinamobile.com, dzickus@...hat.com,
        atomlin@...hat.com, uobergfe@...hat.com, tj@...nel.org,
        hidehiro.kawai.ez@...achi.com, johunt@...mai.com,
        davem@...emloft.net, sparclinux@...r.kernel.org,
        linux-kernel@...r.kernel.org, sam@...nborg.org
Subject: Re: [PATCH v2 1/2] watchdog: Introduce arch_watchdog_nmi_enable and
 arch_watchdog_nmi_disable

On Thu, 13 Oct 2016 13:38:01 -0700 Babu Moger <babu.moger@...cle.com> 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?