linux-kernel - Re: [PATCH v2 0/3] Clean up watchdog handlers

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20161121.134247.2230825072060895605.davem@davemloft.net>
Date:   Mon, 21 Nov 2016 13:42:47 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     babu.moger@...cle.com
Cc:     mingo@...nel.org, akpm@...ux-foundation.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,
        sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org,
        sam@...nborg.org
Subject: Re: [PATCH v2 0/3] Clean up watchdog handlers

From: Babu Moger <babu.moger@...cle.com>
Date: Tue,  1 Nov 2016 14:13:43 -0700

> This is an attempt to cleanup watchdog handlers. Right now,
> kernel/watchdog.c implements both softlockup and hardlockup detectors.
> Softlockup code is generic. Hardlockup code is arch specific. Some
> architectures don't use hardlockup detectors. They use their own watchdog
> detectors. To make both these combination work, we have numerous #ifdefs
> in kernel/watchdog.c.
> 
> We are trying here to make these handlers independent of each other.
> Also provide an interface for architectures to implement their own
> handlers. watchdog_nmi_enable and watchdog_nmi_disable will be defined
> as weak such that architectures can override its definitions.
> 
> Thanks to Don Zickus for his suggestions.
> Here are our previous discussions
> http://www.spinics.net/lists/sparclinux/msg16543.html
> http://www.spinics.net/lists/sparclinux/msg16441.html

This touches a bunch of generic code, only the third patch is sparc
specific.

Anyways have any plans to merge this via another tree or should I
take it via sparc?  If I take it via sparc I want some ACKs.

Thanks.