Messages in this thread | | | Date | Thu, 17 Apr 2008 14:26:14 -0700 | From | Andrew Morton <> | Subject | Re: [RFC PATCH] x86 NMI-safe INT3 and Page Fault (v5) |
| |
On Thu, 17 Apr 2008 17:16:25 -0400 Mathieu Desnoyers <compudj@krystal.dyndns.org> wrote:
> > Should we or should we not make in_interrupt() return true in NMI? > > "should", I expect. > > > > If not, we'd need to do something else to communicate the current > > processing state down to the BUG-handling code. > > > > You bring an interesting question. In practice, since this BUG_ON could > only happen if we have an NMI nested over another NMI or an nmi which > fails to decrement its HARDNMI_MASK. Given that the HARDIRQ_MASK is > incremented right after the HARDNMI_MASK increment (the reverse is also > true), really bad things (TM) must have happened for the BUG_ON to be > triggered outside of the __irq_enter()/__irq_exit() scope of the NMI > below the buggy one. > > But since this code is there to extract as much information as possible > when things go wrong, I would say it's safer to, at least, add > HARDNMI_MASK to irq_count(). > > Instead, though, I think we could add : > > if (in_nmi()) > panic("Fatal exception in non-maskable interrupt"); > > to die().
But that's just one site. There might be (now, or in the future) other code under BUG() which tests in_interrupt().
And most of the places where we test for in_interrupt() and in_irq() probably want that to return true is we're in NMI too. After all, it's an interrupt.
> That would be clearer. I just added it to x86_32, but can't > find where x86_64 reports the "fatal exception in interrupt" and friends > message. Any idea ?
Dunno - maybe it just doesn't have it. Maybe it was never the right thing to do.
> By dealing with this case specifically, I think we don't really have to > add HARDNMI_MASK to irq_count(), considering it's normally an HARDIRQ > too.
| |