Re: [patch 1/2] x86_64 page fault NMI-safe

[Linus Torvalds]

On Wed, Jul 14, 2010 at 12:14 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, Jul 14, 2010 at 11:46 AM, Ingo Molnar <mingo@xxxxxxx> wrote:
>> We could solve that by copying that small stack frame off before entering the
>> 'generic' NMI routine - but it all feels a bit pulled in by the hair.
>
> Why? It's much cleaner than making the _real_ codepaths much worse.

.. but if the option is to never take a fault at all from the NMI
handler, and that is doable, than that would be good, of course.

But that may not be fixable. At least not without much more pain than
just adding a fairly simple hack to the NMI path itself, and keeping
all the NMI pain away from all the other cases.

And doing the per-cpu NMI nesting hack would actually also work as a
way to essentially block NMI's from critical regions. With my NMI
nestign avoidance suggestion, you could literally do something like
this to block NMI's:

  /* This is just a fake stack structure */
  struct nmi_blocker {
     unsigned long rflags;
     unsigned long cs;
     unsigned long rip;
   };

  void block_nmi_on_this_cpu(struct nmi_blocker *blocker)
  {
      get_cpu();
      memset(blocker, 0, sizeof(*blocker));
      per_cpu_nmi_stack_frame = blocker;
  }

  void unblock_nmi_on_this_cpu(struct nmi_blocker *blocker)
  {
     per_cpu_nmi_stack_frame = NULL;
     barrier();
     /* Did an NMI happen? If so, we're now running NMI-blocked by hardware,
      * we need to emulate the NMI and do a real 'iret' here
      */
     if (blocker->cs == INVALID_CS)
        asm volatile(".. build stack frame, call NMI routine ..");
     put_cpu();
  }

or similar. Wouldn't that be nice to have as a capability?

                 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/