Re: [PATCH] x86 NMI: Be smarter about invoking panic() inside NMI handler.

[Don Zickus <dzickus@redhat.com>]

On Thu, Mar 29, 2012 at 03:19:56AM -0400, Andrei E. Warkentin wrote:
> Hi Don,
> 
> Thank you for your feedback!
> 
> 2012/3/27 Don Zickus <dzickus@redhat.com>:
> >
> > Hmm, if try_panic fails, then the cpu continues on executing code.  This
> > might further corrupt an already broken system.  So I don't think this
> > patch will work as is.
> >
> 
> I see what you are saying. I could make the argument that this kind
> of system corruption could occur anyway even if you did panic inside
> an IRQ context instead, but I would tend to agree that your proposed
> solution is much better than adding another panic interface.
> 
> > Perhaps instead of panic'ing in the NMI context, we use irq_work and panic
> > in an interrupt context instead.  We still get the system to stop (though
> > it might still execute some interrupts) and it will be out of the NMI
> > context.
> >
> > However, you will still run into a similar problem when in the
> > panic/reboot case we shutdown all the remote cpus and have them sitting in
> > a similar cpu_relax loop in the NMI context, while the panic'ing cpu
> > cleans things up.
> >
> 
> Sorry, could you clarify what you mean? How does this affect KDB usage?

I figured it would affect it the same way you described in your panic
scenario.  The machine panics and you are trying to break in with KDB.
The above issue just says the other cpus could block KDB from stopping all
the cpus much like your original issue.

But I will admit I didn't fully understand the original problem you were
trying to solve.

Cheers,
Don

> 
> A