+ /* Recursive panics are usually backtrace problems. Possibly printk.
+ * Locking panics might recurse forever. */
+ if (PERCPU_VAR(panic_depth) == 1) {
+ if (hw_tf) {
+ print_trapframe(hw_tf);
+ backtrace_hwtf(hw_tf);
+ } else {
+ backtrace();
+ }
+ } else {
+ printk("\tRecursive kernel panic on core %d (depth %d)\n",
+ core_id_early(), PERCPU_VAR(panic_depth));
+ }
+ printk("\n");
+
+ /* If we're here, we panicked and currently hold the print_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;
+ print_unlock_force();
+ /* 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. */
+ do {
+ udelay(500000);
+ cmb();
+ } while (panic_printing);
+
+ /* Yikes! We're claiming to be not in IRQ/trap ctx and not holding any
+ * locks. Obviously we could be wrong, and could easily deadlock. We could
+ * be in an IRQ handler, an unhandled kernel fault, or just a 'normal' panic
+ * in a syscall - any of which can involve unrestore invariants. */
+ pcpui->__ctx_depth = 0;
+ pcpui->lock_depth = 0;
+ /* And keep this off, for good measure. */
+ pcpui->__lock_checking_enabled--;