lkml.org 
[lkml]   [2016]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface
    On Tue, Jul 26, 2016 at 01:51:27PM -0400, Steven Rostedt wrote:
    > On Tue, 26 Jul 2016 11:26:42 -0500
    > Josh Poimboeuf <jpoimboe@redhat.com> wrote:
    >
    >
    > > Ok, I think that makes sense to me now. As I understand it, the
    > > "outermost" RIP is the authoritative one, because it was written by the
    > > original NMI. Any nested NMIs will update the original and/or iret
    > > RIPs, which will only ever point to NMI entry code, and so they should
    > > be ignored.
    >
    > Just to confirm:
    >
    > -- top-of-stack --
    > [ hardware written stack ] <- what the NMI hardware mechanism wrote
    > [ internal variables ] <- you don't need to know what this is
    > [ where to go next ] <- the stack to use to return on current NMI
    > [ original copy of hardware stack ] <- the stack of the first NMI
    >
    > IIRC, the original version had the "where to go next" stack last, but
    > to keep pt_regs in line with the stack, it made sense to have the
    > original NMI stack at the bottom, just above pt_regs, like a real
    > interrupt would.
    >
    > >
    > > But I think there's a case where this wouldn't work:
    > >
    > > task stack
    > > NMI
    > > IST
    > > stack dump
    > >
    > > If the IST interrupt hits before the NMI has a chance to update the
    > > outermost regs, the authoritative RIP would be the original one written
    > > by HW, right?
    >
    > The only IST interrupt that would hit there is MCE and it would
    > probably be a critical error. Do we really need to worry about such an
    > unlikely scenario? The system is probably doomed anyway.

    According to entry_64.S:

    /*
    * We allow breakpoints in NMIs. If a breakpoint occurs, then
    * the iretq it performs will take us out of NMI context.
    * This means that we can have nested NMIs where the next
    * NMI is using the top of the stack of the previous NMI.

    So I think this means that when a debug exception returns to an NMI with
    iret, further NMIs are no longer masked.

    --
    Josh

    \
     
     \ /
      Last update: 2016-07-26 21:41    [W:4.590 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site