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  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]
Date:   Thu, 28 Feb 2019 17:17:13 -0800
From:   Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
To:     "Paul E. McKenney" <paulmck@...ux.ibm.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...e.de>,
        Ashok Raj <ashok.raj@...el.com>,
        Andi Kleen <andi.kleen@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        Ricardo Neri <ricardo.neri@...el.com>,
        "H. Peter Anvin" <hpa@...or.com>, Tony Luck <tony.luck@...el.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Don Zickus <dzickus@...hat.com>,
        Nicholas Piggin <npiggin@...il.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Frederic Weisbecker <frederic@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Babu Moger <babu.moger@...cle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Colin Ian King <colin.king@...onical.com>,
        Byungchul Park <byungchul.park@....com>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Waiman Long <longman@...hat.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Davidlohr Bueso <dave@...olabs.net>,
        Christoffer Dall <cdall@...aro.org>,
        Marc Zyngier <marc.zyngier@....com>,
        Kai-Heng Feng <kai.heng.feng@...onical.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        David Rientjes <rientjes@...gle.com>,
        sparclinux@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [RFC PATCH v2 09/14] watchdog/hardlockup: Make
 arch_touch_nmi_watchdog() to hpet-based implementation

On Wed, Feb 27, 2019 at 08:17:58AM -0800, Paul E. McKenney wrote:
> On Wed, Feb 27, 2019 at 08:05:13AM -0800, Ricardo Neri wrote:
> > CPU architectures that have an NMI watchdog use arch_touch_nmi_watchdog()
> > to briefly ignore the hardlockup detector. If the architecture does not
> > have an NMI watchdog, one can be constructed using a source of non-
> > maskable interrupts. In this case, arch_touch_nmi_watchdog() is common
> > to any underlying hardware resource used to drive the detector and needs
> > to be available to other kernel subsystems if hardware different from perf
> > drives the detector.
> > 
> > There exists perf-based and HPET-based implementations. Make it available
> > to the latter.
> > 
> > For clarity, wrap this function in a separate preprocessor conditional
> > from functions which are truly specific to the perf-based implementation.
> > 
> > Cc: "H. Peter Anvin" <hpa@...or.com>
> > Cc: Ashok Raj <ashok.raj@...el.com>
> > Cc: Andi Kleen <andi.kleen@...el.com>
> > Cc: Tony Luck <tony.luck@...el.com>
> > Cc: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
> > Cc: Don Zickus <dzickus@...hat.com>
> > Cc: Nicholas Piggin <npiggin@...il.com>
> > Cc: Michael Ellerman <mpe@...erman.id.au>
> > Cc: Frederic Weisbecker <frederic@...nel.org>
> > Cc: Alexei Starovoitov <ast@...nel.org>
> > Cc: Babu Moger <babu.moger@...cle.com>
> > Cc: "David S. Miller" <davem@...emloft.net>
> > Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>
> > Cc: Paul Mackerras <paulus@...ba.org>
> > Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> > Cc: Masami Hiramatsu <mhiramat@...nel.org>
> > Cc: Peter Zijlstra <peterz@...radead.org>
> > Cc: Andrew Morton <akpm@...ux-foundation.org>
> > Cc: Philippe Ombredanne <pombredanne@...b.com>
> > Cc: Colin Ian King <colin.king@...onical.com>
> > Cc: Byungchul Park <byungchul.park@....com>
> > Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
> > Cc: "Luis R. Rodriguez" <mcgrof@...nel.org>
> > Cc: Waiman Long <longman@...hat.com>
> > Cc: Josh Poimboeuf <jpoimboe@...hat.com>
> > Cc: Randy Dunlap <rdunlap@...radead.org>
> > Cc: Davidlohr Bueso <dave@...olabs.net>
> > Cc: Christoffer Dall <cdall@...aro.org>
> > Cc: Marc Zyngier <marc.zyngier@....com>
> > Cc: Kai-Heng Feng <kai.heng.feng@...onical.com>
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> > Cc: David Rientjes <rientjes@...gle.com>
> > Cc: "Ravi V. Shankar" <ravi.v.shankar@...el.com>
> > Cc: x86@...nel.org
> > Cc: sparclinux@...r.kernel.org
> > Cc: linuxppc-dev@...ts.ozlabs.org
> > Signed-off-by: Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
> > ---
> >  include/linux/nmi.h | 10 +++++++++-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/nmi.h b/include/linux/nmi.h
> > index 5a8b19749769..bf5ebcfdd590 100644
> > --- a/include/linux/nmi.h
> > +++ b/include/linux/nmi.h
> > @@ -94,8 +94,16 @@ static inline void hardlockup_detector_disable(void) {}
> >  # define NMI_WATCHDOG_SYSCTL_PERM	0444
> >  #endif
> > 
> > -#if defined(CONFIG_HARDLOCKUP_DETECTOR_PERF)
> > +#if defined(CONFIG_HARDLOCKUP_DETECTOR_PERF) || \
> > +    defined(CONFIG_X86_HARDLOCKUP_DETECTOR_HPET)
> 
> Why not instead make CONFIG_X86_HARDLOCKUP_DETECTOR_HPET select
> CONFIG_HARDLOCKUP_DETECTOR_PERF?  Keep the arch-specific details
> in the arch-specific files and all that.

Thanks for your feedback, Paul! The HPET implementation does not use
perf. Thus, in my opinion is not correct for the HPET HLD to select
the perf implementation. Patch 8 of this series splits the perf-specific
code and the generic hardlockup detector code. Does this make sense?

Thanks and BR,
Ricardo

Powered by blists - more mailing lists