Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1450727

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

From Steven Rostedt <rostedt@goodmis.org>
Newsgroups linux.kernel
Subject Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface
Date 2016-07-26 20:00 +0200
Message-ID <rZeO6-55G-13@gated-at.bofh.it> (permalink)
References (3 earlier) <rXSwh-40M-7@gated-at.bofh.it> <rXSPE-4m9-7@gated-at.bofh.it> <rY5MR-3Kb-1@gated-at.bofh.it> <rYYgi-3je-11@gated-at.bofh.it> <rZdp0-4i9-31@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface Andy Lutomirski <luto@amacapital.net> - 2016-07-26 02:20 +0200
  Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface Josh Poimboeuf <jpoimboe@redhat.com> - 2016-07-26 18:30 +0200
    Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface Steven Rostedt <rostedt@goodmis.org> - 2016-07-26 20:00 +0200
      Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface Josh Poimboeuf <jpoimboe@redhat.com> - 2016-07-26 21:00 +0200
    Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface Andy Lutomirski <luto@amacapital.net> - 2016-07-26 23:00 +0200
      Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface Josh Poimboeuf <jpoimboe@redhat.com> - 2016-07-27 00:30 +0200
        Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface Andy Lutomirski <luto@amacapital.net> - 2016-07-27 00:40 +0200
        Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface Steven Rostedt <rostedt@goodmis.org> - 2016-07-27 00:40 +0200
  Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface Josh Poimboeuf <jpoimboe@redhat.com> - 2016-07-26 18:50 +0200
    Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface Brian Gerst <brgerst@gmail.com> - 2016-07-26 19:50 +0200
      Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface Josh Poimboeuf <jpoimboe@redhat.com> - 2016-07-26 21:00 +0200

csiph-web