linux-kernel - Re: [PATCH 3/3] [RFC] nmi_watchdog: config option to enable new 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: <20100201185218.GC3062@redhat.com>
Date:	Mon, 1 Feb 2010 13:52:18 -0500
From:	Don Zickus <dzickus@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Peter Zijlstra <peterz@...radead.org>, gorcunov@...il.com,
	aris@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] [RFC] nmi_watchdog: config option to enable new
 nmi_watchdog

On Fri, Jan 29, 2010 at 09:12:27AM +0100, Ingo Molnar wrote:
> 
> * Don Zickus <dzickus@...hat.com> wrote:
> 
> > On Thu, Jan 28, 2010 at 03:54:54PM +0100, Peter Zijlstra wrote:
> > > On Wed, 2010-01-27 at 15:03 -0500, Don Zickus wrote:
> > > > These are the bits that enable the new nmi_watchdog and safely isolate the
> > > > old nmi_watchdog.  Only one or the other can run, not both at the same
> > > > time.
> > > 
> > > perf disables the lapic watchdog when it wants the pmu, so there
> > > shouldn't be a problem having both built in.
> > 
> > Yes it does disable but does not prevent nmi_watchdog_tick from running nor 
> > the /proc interface from being loaded.  So perhaps my description isn't very 
> > good.  The idea with the new watchdog was to re-use some of the bits of the 
> > old one, but having them both compiled in seemed to stomp on each other.  
> > That is what I was trying to prevent.
> > 
> > I can certainly change the behaviour, just makes the code a little more 
> > messy I think.
> 
> I think that's a good idea - and i think we want to be bold and just have the 
> new code run seemlessly. (and fix bugs, if any.)

Ok.  I guess I am confused what you are suggesting here, to do as Peter
suggested and run both at the same time?

> 
> In fact we want to be even bolder: how about enabling the NMI watchdog by 
> default again?

I won't complain. :-)

> 
> The problem with the old one was its fragility - but now if we have a PMU 
> driver active and perf events enabled we might as well use your brand new NMI 
> watchdog code as a testing facility as well: if there's _any_ problem with 
> NMIs then regular 'perf' use would trigger it too - except that not all people 
> run perf while an always-enabled NMI watchdog would.

Agreed.

> 
> And it would detect hard hangs too.
> 
> What do you think?

I will need to give you an updated patch that properly sets the frequency
of the NMI and I probably should still implement a code path that uses the
software perf counters in the cases where the hardware perf counters are
not available.

It seems like you are ok with my approach.  If that is so, I can test on
more machines to iron out some more bugs.  Or did you want to take my
patches as is and have me throw fixes on top?

Cheers,
Don

> 
> 	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/