Attempt to fix recursive panics

Some panics can still lock up and spew a lot of text.  This helps a
little.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>

kern/src/init.c

diff --git a/kern/src/init.c b/kern/src/init.c
index 658f2fa..5d27a3c 100644
--- a/kern/src/init.c
+++ b/kern/src/init.c
@@ -262,6 +262,8 @@
 	vcprintf(fmt, ap);
 	printk("\n");
 	va_end(ap);
+	/* Recursive panics are usually backtrace problems.  Possibly printk.
+	 * Locking panics might recurse forever. */
 	if (PERCPU_VAR(panic_depth) == 1)
 		backtrace();
 	else
@@ -269,11 +271,14 @@
 		       core_id_early(), PERCPU_VAR(panic_depth));
 	printk("\n");
 
-	PERCPU_VAR(panic_depth)--;
-	if (!PERCPU_VAR(panic_depth)) {
-		panic_printing = false;
-		spin_unlock_irqsave(&panic_lock);
-	}
+	/* If we're here, we panicked and currently hold the lock.  We might have
+	 * panicked recursively.  We must unlock unconditionally, since the initial
+	 * panic (which grabbed the lock) will never run again. */
+	panic_printing = false;
+	spin_unlock_irqsave(&panic_lock);
+	/* And we have to clear the depth, so that we lock again next time in.
+	 * Otherwise, we'd be unlocking without locking (which is another panic). */
+	PERCPU_VAR(panic_depth) = 0;
 
 	/* Let's wait long enough for other printers to finish before entering the
 	 * monitor. */