WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Prevent an infinite series of traps

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>,<levon@xxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Prevent an infinite series of traps
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 23 May 2007 11:42:32 +0200
Delivery-date: Wed, 23 May 2007 02:41:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxx> 05/23/07 4:53 AM >>>

# HG changeset patch
# User john.levon@xxxxxxx
# 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@xxxxxxx>

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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>