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, 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

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