Messages in this thread | | | Date | Tue, 26 Jul 2016 13:51:27 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface |
| |
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.
-- Steve
| |