The patch titled
x86_64: add nmi_exit to die_nmi
has been removed from the -mm tree. Its filename is
x86_64-add-nmi_exit-to-die_nmi.patch
This patch was probably dropped from -mm because
it has now been merged into a subsystem tree or
into Linus's tree, or because it was folded into
its parent patch in the -mm tree.
From: Corey Minyard <minyard@xxxxxxx>
Playing with NMI watchdog on x86_64, I discovered that it didn't do what I
expected. It always panic-ed, even when it didn't happen from interrupt
context. This patch solves that problem for me. Also, in this case,
do_exit() will be called with interrupts disabled, I believe. Would it be
wise to also call local_irq_enable() after nmi_exit()? [Yes I added it -AK]
Currently, on x86_64, any NMI watchdog timeout will cause a panic because the
irq count will always be set to be in an interrupt when do_exit() is called
from die_nmi(). If we add nmi_exit() to the die_nmi() call (since the nmi
will never exit "normally") it seems to solve this problem. The following
small program can be used to trigger the NMI watchdog to reproduce this:
main ()
{
iopl(3);
for (;;) asm("cli");
}
Signed-off-by: Andi Kleen <ak@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---
arch/x86_64/kernel/traps.c | 2 ++
1 files changed, 2 insertions(+)
diff -puN arch/x86_64/kernel/traps.c~x86_64-add-nmi_exit-to-die_nmi arch/x86_64/kernel/traps.c
--- devel/arch/x86_64/kernel/traps.c~x86_64-add-nmi_exit-to-die_nmi 2006-05-10 21:18:11.000000000 -0700
+++ devel-akpm/arch/x86_64/kernel/traps.c 2006-05-10 21:18:11.000000000 -0700
@@ -472,6 +472,8 @@ void __kprobes die_nmi(char *str, struct
panic("nmi watchdog");
printk("console shuts up ...\n");
oops_end(flags);
+ nmi_exit();
+ local_irq_enable();
do_exit(SIGSEGV);
}
_
Patches currently in -mm which might be from minyard@xxxxxxx are
origin.patch
strstrip-api.patch
ipmi-strstrip-conversion.patch
drivers-char-ipmi-ipmi_msghandlerc-make-proc_ipmi_root-static.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
