[RFC][PATCH 0/5 v2] x86: Find a way to allow breakpoints in NMIs

[Steven Rostedt]

OK, this is getting close. Although I'm labeling this as a RFC patchset,
I've already queued it up into my git repo. I did some code cleanups
since the last version, and I also added the IDT update if an
NMI interrupts a process using the debug stack. This way the
NMI wont corrupt it if it hits a breakpoint too.

I've also added code to handle i386, which was quite trivial, as
NMIs and int3s do not change the stack when preempting privilege mode.
That code was done all in C.

I've hammered this code with running perf on top of ftrace using
the breakpoint conversions, and I've done this on two boxes.
Both are holding up very well. I haven't hit any glitches.

With all that said, please take a final look over these patches and
let me know what you think. After that, I'll be pushing this forward
as it is required for my ftrace series.

Note, the below stats look like I added a lot of code. I've actually
added more comments than code, as this needed it.

Thanks!

-- Steve



  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
tip/x86/core

Head SHA1: e0b5187d3e29df98ae2b4c71250387d824ac90ae


Linus Torvalds (1):
      x86: Do not schedule while still in NMI context

Steven Rostedt (4):
      x86: Document the NMI handler about not using paranoid_exit
      x86: Add workaround to NMI iret woes
      x86: Keep current stack in NMI breakpoints
      x86: Allow NMIs to hit breakpoints in i386

----
 arch/x86/include/asm/desc.h      |   12 ++
 arch/x86/include/asm/processor.h |    6 +
 arch/x86/kernel/cpu/common.c     |   22 ++++
 arch/x86/kernel/entry_64.S       |  208 ++++++++++++++++++++++++++++++++------
 arch/x86/kernel/head_64.S        |    4 +
 arch/x86/kernel/nmi.c            |  101 ++++++++++++++++++
 arch/x86/kernel/traps.c          |    6 +
 7 files changed, 326 insertions(+), 33 deletions(-)
--
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/