Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface
From: Josh Poimboeuf
Date: Tue Jul 26 2016 - 14:59:51 EST
On Tue, Jul 26, 2016 at 01:49:06PM -0400, Brian Gerst wrote:
> On Tue, Jul 26, 2016 at 12:47 PM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
> > On Mon, Jul 25, 2016 at 05:09:44PM -0700, Andy Lutomirski wrote:
> >> On Sat, Jul 23, 2016 at 7:04 AM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
> >> > Am I correct in understanding that there can only be one level of NMI
> >> > nesting at any given time? If so, could we make it easier on the
> >> > unwinder by putting the nested NMI on a separate software stack, so the
> >> > "next stack" pointers are always in the same place? Or am I just being
> >> > naive?
> >>
> >> I think you're being naive :)
> >
> > Another dumb question: since NMIs are reentrant, have you considered
> > removing the NMI IST entry, and instead just have NMIs keep using the
> > current stack?
> >
> > The first NMI could then be switched to an NMI software stack, like IRQs
> > (assuming there's a way to do that atomically!). And then determining
> > the context of subsequent NMIs would be straightforward, and we'd no
> > longer need to jump through all those horrible hoops in the entry code
> > to deal with NMI nesting.
> >
> > Now you can tell me what else I'm missing...
>
> There are several places (most notably SYSCALL entry) where the kernel
> stack pointer is unsafe/user controlled for a brief time. Since an
> NMI can interrupt anywhere in the kernel, you have to use an IST to
> protect against that case.
Ah, that makes sense. Thanks.
--
Josh