[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Audit of NMI and MCE paths
>>> On 04.12.12 at 21:04, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: > As an alternative, I suggest that we make ASSERT()s, BUG()s and WARN()s > NMI/MCE safe, from a printk spinlock point of view. > > Either we can modify the macros to do a console_force_unlock(), which is > fine for BUG() and ASSERT(), but problematic for WARN() (and deferring > the printing to a tasklet wont work if we want a stack trace). > Alternativly, we could change the console lock to be a recursive lock, > at which point it is safe from the deadlock point of view. Are there > any performance concerns from changing to a recursive lock? Not really, and the console lock isn't performance critical anyway. > As for spinlocks themselves, as far as I can reason, recursive locks are > safe to use, as are per-cpu spinlocks which are used exclusivly in the > NMI handler or MCE handler (but not both), given the proviso that we > have C level reentrance protection for do_{nmi,mce}(). > > For the {rd,wr}msr()s, we can assume that the Xen code is good and is > not going to fault on access to the MSR, but we certainly cant guarantee > this. {rd,wr}msr() are of no concern - if they fault it's exactly like a #PF or #GP from a bad memory reference: a bug that will bring down the hypervisor. Their _safe counterparts are what needs to be looked for, as there the fault is being recovered from (and it's this recovery's side effect of re-enabling NMIs that we don't want). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |