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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 21 Nov 2016 15:29:24 -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: Mon, 21 Nov 2016 14:25:50 -0600

> Hi Dave,
> 
> On 11/21/2016 12:42 PM, David Miller wrote:
>> 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.
> 
> Not sure how these things work. I have got following responses from
> Andrew Morton earlier.

Ok, if Andrew put it in his tree I'll just assume these changes will
take that path.