[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3 of 4 RFC] x86/nmi: Prevent reentrant execution of the C nmi handler
At 18:16 +0000 on 04 Dec (1354644970), Andrew Cooper wrote: > +/* This function is NOT SAFE to call from C code in general. > + * Use with extreme care! */ > +void do_nmi(struct cpu_user_regs *regs) > +{ > + bool_t * in_progress = &this_cpu(nmi_in_progress); > + > + if ( is_panic_in_progress() ) > + { > + /* A panic is already in progress. It may have reenabled NMIs, > + * or we are simply unluckly to receive one right now. Either > + * way, bail early, as Xen is about to die. > + * > + * TODO: Ideally we should exit without executing an iret, to > + * leave NMIs disabled, but that option is not currently > + * available to us. > + */ > + return; > + } > + > + if ( test_and_set_bool(*in_progress) ) > + { > + /* Crash in an obvious mannor, as opposed to falling into > + * infinite loop because our exception frame corrupted the > + * exception frame of the previous NMI. > + * > + * TODO: This check does not cover all possible cases of corrupt > + * exception frames, but it is substantially better than > + * nothing. > + */ > + console_force_unlock(); > + show_execution_state(regs); > + panic("Reentrant NMI detected\n"); > + } > + > + _do_nmi(regs); I think you need a barrier() above and below _do_nmi() in case the compiler inlines _do_nmi() and then decides it can shuffle the writes to in_progress around. Otherwise, this looks fine, and you can add my ack if you like. > + *in_progress = 0; > +} > + > void set_nmi_callback(nmi_callback_t callback) > { > nmi_callback = callback; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |