[PATCH][RFC] getting rid of stupid loop in BUG()

[Al Viro <viro@ftp.linux.org.uk>]

	AFAICS, the patch below should do it for i386; instead of
using a dummy loop to tell gcc that this sucker never returns,
we do
static void __always_inline __noreturn __BUG(const char *file, int line);
containing the actual asm we want to insert and define BUG() as
__BUG(__FILE__, __LINE__).  It looks safe, but I don't claim enough
experience with gcc __asm__ potential nastiness, so...

Comments, objections?

diff --git a/include/asm-i386/bug.h b/include/asm-i386/bug.h
index b0fd78c..294bc55 100644
--- a/include/asm-i386/bug.h
+++ b/include/asm-i386/bug.h
@@ -7,31 +7,27 @@
  * The offending file and line are encoded encoded in the __bug_table section.
  */
 
-#ifdef CONFIG_BUG
 #define HAVE_ARCH_BUG
 
-#ifdef CONFIG_DEBUG_BUGVERBOSE
-#define BUG()								\
-	do {								\
-		asm volatile("1:\tud2\n"				\
-			     ".pushsection __bug_table,\"a\"\n"		\
-			     "2:\t.long 1b, %c0\n"			\
-			     "\t.word %c1, 0\n"				\
-			     "\t.org 2b+%c2\n"				\
-			     ".popsection"				\
-			     : : "i" (__FILE__), "i" (__LINE__),	\
-			     "i" (sizeof(struct bug_entry)));		\
-		for(;;) ;						\
-	} while(0)
+#define BUG() __BUG(__FILE__, __LINE__)
+
+#include <asm-generic/bug.h>
 
+#ifdef CONFIG_BUG
+static void __always_inline __noreturn __BUG(const char *file, int line)
+{
+#ifdef CONFIG_DEBUG_BUGVERBOSE
+	asm volatile("1:\tud2\n"
+		     ".pushsection __bug_table,\"a\"\n"
+		     "2:\t.long 1b, %c0\n"
+		     "\t.word %c1, 0\n"
+		     "\t.org 2b+%c2\n"
+		     ".popsection"
+		     : : "i" (file), "i" (line),
+		     "i" (sizeof(struct bug_entry)));
 #else
-#define BUG()								\
-	do {								\
-		asm volatile("ud2");					\
-		for(;;) ;						\
-	} while(0)
+	asm volatile("ud2");
 #endif
+}
 #endif
-
-#include <asm-generic/bug.h>
 #endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/