[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <48C13FB7.80105@linux.intel.com>
Date: Fri, 05 Sep 2008 16:18:31 +0200
From: Andi Kleen <ak@...ux.intel.com>
To: Ingo Molnar <mingo@...e.hu>
CC: Andi Kleen <andi@...stfloor.org>, Vivek Goyal <vgoyal@...hat.com>,
Don Zickus <dzickus@...hat.com>,
Prarit Bhargava <prarit@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, arozansk@...hat.com,
Thomas.Mingarelli@...com, Alan Cox <alan@...rguk.ukuu.org.uk>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
"Maciej W. Rozycki" <macro@...ux-mips.org>
Subject: Re: [PATCH RFC] NMI Re-introduce un[set]_nmi_callback
Ingo Molnar wrote:
> * Andi Kleen <andi@...stfloor.org> wrote:
>
>>> Add "kdump" to the list. It will also be broken if we decide to let
>>> one driver hijack the NMI handler.
>> kdump is a special case, similar to the NMI button panic mode. It
>> should be always only active when the user configured it. When the
>> user configured it should be always the fallback and override any
>> other drivers.
>
> if by 'any other drivers' you mean all other notifiers then that's wrong
> - kdump must still come after many other NMI sources.
Your ordering makes sense. Someone just has to go through all
the users and fix them up I guess and also document it properly.
One thing to consider though: if there are more and more NMI drivers
it would make sense to have a new notifier chain just for this
(and also finally convert oprofile to use it too).
The problem with adding more and more into the die chain is that
die is executed on every exception, including quite performance
critical ones like page fault or int 3 (performance critical for
dprobes)
-Andi
--
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/
Powered by blists - more mailing lists