[<prev] [next>] [day] [month] [year] [list]
Message-Id: <1183727959.17319.126.camel@localhost.localdomain>
Date: Fri, 06 Jul 2007 09:19:19 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
RT <linux-rt-users@...r.kernel.org>
Subject: [PATCH RT] don't BUG_ON in exit for in_interrupt
For some reason, in the RT kernel, we have in exit.c a
BUG_ON(in_interrupt()) just before a check of in_interrupt() then panic.
With the panic, we get a nice output of what happened (considering that
the panic gives us a backtrace).
But a BUG_ON will cause a fault, and then try to bug again. This causes
a recursive fault which eventually eats up the stack. Twice have we
lost information on a crash because of this recursive faulting.
This patch undoes the adding the BUG_ON in exit.c.
Signed-off-by: Steven Rostedt <rostedt@...dmis.org>
Index: linux-2.6.21.5-rt17/kernel/exit.c
===================================================================
--- linux-2.6.21.5-rt17.orig/kernel/exit.c
+++ linux-2.6.21.5-rt17/kernel/exit.c
@@ -863,7 +863,6 @@ fastcall NORET_TYPE void do_exit(long co
WARN_ON(atomic_read(&tsk->fs_excl));
- BUG_ON(in_interrupt());
if (unlikely(in_interrupt()))
panic("Aiee, killing interrupt handler!");
if (unlikely(!tsk->pid))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists