Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759419Ab0GPWkr (ORCPT ); Fri, 16 Jul 2010 18:40:47 -0400 Received: from mail.openrapids.net ([64.15.138.104]:43577 "EHLO blackscsi.openrapids.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1759364Ab0GPWkd (ORCPT ); Fri, 16 Jul 2010 18:40:33 -0400 Date: Fri, 16 Jul 2010 18:40:30 -0400 From: Mathieu Desnoyers To: Andi Kleen Cc: Linus Torvalds , Avi Kivity , "H. Peter Anvin" , LKML , Andrew Morton , Ingo Molnar , Peter Zijlstra , Steven Rostedt , Steven Rostedt , Frederic Weisbecker , Thomas Gleixner , Christoph Hellwig , Li Zefan , Lai Jiangshan , Johannes Berg , Masami Hiramatsu , Arnaldo Carvalho de Melo , Tom Zanussi , KOSAKI Motohiro , Jeremy Fitzhardinge , "Frank Ch. Eigler" Subject: Re: [patch 2/2] x86 NMI-safe INT3 and Page Fault Message-ID: <20100716224030.GB10427@Krystal> References: <20100716165855.GA3836@Krystal> <4C409CBA.1050709@redhat.com> <4C409F62.6030303@zytor.com> <4C40A1BD.4040507@redhat.com> <4C40A227.6000207@zytor.com> <4C40A4E8.5090605@redhat.com> <4C40B277.9030408@redhat.com> <20100716220730.GH7338@basil.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100716220730.GH7338@basil.fritz.box> X-Editor: vi X-Info: http://www.efficios.com X-Operating-System: Linux/2.6.26-2-686 (i686) X-Uptime: 18:21:18 up 175 days, 58 min, 6 users, load average: 0.04, 0.05, 0.01 User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2094 Lines: 53 * Andi Kleen (andi@firstfloor.org) wrote: > > And the thing is, if we just do NMI's correctly, and allow nesting, > > ALL THOSE PROBLEMS GO AWAY. And there is no reason what-so-ever to do > > stupid things elsewhere. > > One issue I have with nesting NMIs is that you need > a nesting limit, otherwise you'll overflow the NMI stack. > > We just got rid of nesting for normal interrupts because > of this stack overflow problem which hit in real situations. > > In some cases you can get quite high NMI frequencies, e.g. with > performance counters. Now the current performance counter handlers > do not nest by themselves of course, but they might nest > with other longer running NMI users. > > I think none of the current handlers are likely to nest > for very long, but there's more and more NMI coded all the time, > so it's definitely a concern. We're not proposing to actually "nest" NMIs per se. We copy the stack at the beginning of the NMI handler (and then use the copy) to permit nesting of faults over NMI handlers. Following NMIs that would "try" to nest over the NMI handler would see their regular execution postponed until the end of the currently running NMI handler. It's OK for these "nested" NMI handlers to use the bottom of NMI stack because the NMI handler on which they are trying to nest is only using the stack copy. These "nested" handlers return to the original NMI handler very early just after setting a "pending nmi" flag. There is more to it (e.g. handling NMI handler exit atomically with respect to incoming NMIs); please refer to the last assembly code snipped I sent to Linus a little earlier today for details. Thanks, Mathieu > > -Andi > > -- > ak@linux.intel.com -- Speaking for myself only. -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/