# HG changeset patch
# User john.levon@sun.com
# Date 1179888079 25200
# Node ID 16f72321a6fc567d9764faef5729263b5101dbe8
# Parent  01982a3f30dcb842e493e1252d85d970a7055ab2
Prevent an infinite series of traps
In some cases, we can end up in a vicious cycle of fatal_trap()s
within fatal_trap()s. Panic after a certain number of attempts.
Signed-off-by: Nils Nieuwejaar <nils.nieuwejaar@sun.com>
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -375,16 +375,25 @@ char *trapstr(int trapnr)
  */
 asmlinkage void fatal_trap(int trapnr, struct cpu_user_regs *regs)
 {
-    watchdog_disable();
-    console_start_sync();
-
-    show_execution_state(regs);
-
-    if ( trapnr == TRAP_page_fault )
-    {
-        unsigned long cr2 = read_cr2();
-        printk("Faulting linear address: %p\n", _p(cr2));
-        show_page_walk(cr2);
+    static int depth = 0;
+
+    /*
+     * In some cases, we can end up in a vicious cycle of fatal_trap()s
+     * within fatal_trap()s.  We give the problem a couple of iterations to
+     * bottom out, and then we just panic.
+     */
+    if (depth++ < 3) {
+	watchdog_disable();
+	console_start_sync();
+
+	show_execution_state(regs);
+
+	if ( trapnr == TRAP_page_fault )
+	{
+	    unsigned long cr2 = read_cr2();
+	    printk("Faulting linear address: %p\n", _p(cr2));
+	    show_page_walk(cr2);
+	}
     }
 
     panic("FATAL TRAP: vector = %d (%s)\n"
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jan Beulich
2007-May-23  09:42 UTC
Re: [Xen-devel] [PATCH] Prevent an infinite series of traps
Could the depth variable at least be made a per-CPU one, to prevent missing simultaneous traps on many different CPUs? Jan>>> John Levon <levon@movementarian.org> 05/23/07 4:53 AM >>># HG changeset patch # User john.levon@sun.com # Date 1179888079 25200 # Node ID 16f72321a6fc567d9764faef5729263b5101dbe8 # Parent 01982a3f30dcb842e493e1252d85d970a7055ab2 Prevent an infinite series of traps In some cases, we can end up in a vicious cycle of fatal_trap()s within fatal_trap()s. Panic after a certain number of attempts. Signed-off-by: Nils Nieuwejaar <nils.nieuwejaar@sun.com> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -375,16 +375,25 @@ char *trapstr(int trapnr) */ asmlinkage void fatal_trap(int trapnr, struct cpu_user_regs *regs) { - watchdog_disable(); - console_start_sync(); - - show_execution_state(regs); - - if ( trapnr == TRAP_page_fault ) - { - unsigned long cr2 = read_cr2(); - printk("Faulting linear address: %p\n", _p(cr2)); - show_page_walk(cr2); + static int depth = 0; + + /* + * In some cases, we can end up in a vicious cycle of fatal_trap()s + * within fatal_trap()s. We give the problem a couple of iterations to + * bottom out, and then we just panic. + */ + if (depth++ < 3) { + watchdog_disable(); + console_start_sync(); + + show_execution_state(regs); + + if ( trapnr == TRAP_page_fault ) + { + unsigned long cr2 = read_cr2(); + printk("Faulting linear address: %p\n", _p(cr2)); + show_page_walk(cr2); + } } panic("FATAL TRAP: vector = %d (%s)\n" _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel