Messages in this thread | | | Date | Fri, 6 Feb 2009 08:25:52 -0500 (EST) | From | Steven Rostedt <> | Subject | Re: [PATCH 2/4] nmi: add generic nmi tracking state |
| |
On Thu, 5 Feb 2009, Andrew Morton wrote: > > > > +/* > > + * Are we in NMI context? > > + */ > > +#define in_nmi() (preempt_count() & NMI_OFFSET) > > + > > #if defined(CONFIG_PREEMPT) > > # define PREEMPT_INATOMIC_BASE kernel_locked() > > # define PREEMPT_CHECK_OFFSET 1 > > @@ -167,6 +178,8 @@ extern void irq_exit(void); > > #define nmi_enter() \ > > do { \ > > ftrace_nmi_enter(); \ > > + BUG_ON(in_nmi()); \ > > + add_preempt_count(NMI_OFFSET); \ > > lockdep_off(); \ > > rcu_nmi_enter(); \ > > __irq_enter(); \ > > @@ -177,6 +190,8 @@ extern void irq_exit(void); > > __irq_exit(); \ > > rcu_nmi_exit(); \ > > lockdep_on(); \ > > + BUG_ON(!in_nmi()); \ > > + sub_preempt_count(NMI_OFFSET); \ > > ftrace_nmi_exit(); \ > > } while (0) > > > > Well that was tidy. > > We're sure that no present or future architecture will for some weird > reason nest NMIs?
That would be fun to implement. Not the in_nmi code, but the handling of nested NMIs. How would you be able to save the state when the NMI occurred without being preempted by another NMI?
I think the arch that has nested NMIs will have many more issues to solve in the kernel than this one.
-- Steve
| |