linux-kernel - [PATCH] let WARN_ON() output the condition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0612060149220.28502@twin.jikos.cz>
Date:	Wed, 6 Dec 2006 01:51:01 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...e.hu>
cc:	linux-kernel@...r.kernel.org
Subject: [PATCH] let WARN_ON() output the condition

[PATCH] let WARN_ON() output the condition

It is possible, in some cases, that the output of WARN_ON() is ambiguous 
and can't be properly used to identify the exact condition which caused 
the warning to trigger. This happens whenever there is a macro that 
contains multiple WARN_ONs inside. Notable example is spin_lock_mutex(). 
If any of the two WARN_ONs trigger, we are not able to say which one was 
the cause (as we get only line number, which however belongs to the place 
where the macro was expanded).

This patch lets WARN_ON() to output also the condition and fixes the 
DEBUG_LOCKS_WARN_ON() macro to pass the condition properly to WARN_ON. The 
possible drawback could be when someone passes a condition which has 
sideeffects. Then it would be evaluated twice, instead of current one 
evaluation. On the other hand, when anyone passes expression with 
sideeffects to WARN_ON(), he is asking for problems anyway.

Patch against 2.6.19-rc6-mm2.

Signed-off-by: Jiri Kosina <jkosina@...e.cz>

--- 

 include/asm-generic/bug.h   |    4 ++--
 include/linux/debug_locks.h |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index a06eecd..af7574e 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -35,8 +35,8 @@ #ifndef HAVE_ARCH_WARN_ON
 #define WARN_ON(condition) ({						\
 	typeof(condition) __ret_warn_on = (condition);			\
 	if (unlikely(__ret_warn_on)) {					\
-		printk("WARNING at %s:%d %s()\n", __FILE__,	\
-			__LINE__, __FUNCTION__);			\
+		printk("WARNING (%s) at %s:%d %s()\n", #condition,	\
+			__FILE__,__LINE__, __FUNCTION__);		\
 		dump_stack();						\
 	}								\
 	unlikely(__ret_warn_on);					\
diff --git a/include/linux/debug_locks.h b/include/linux/debug_locks.h
index 952bee7..1c2b682 100644
--- a/include/linux/debug_locks.h
+++ b/include/linux/debug_locks.h
@@ -25,7 +25,7 @@ ({									\
 									\
 	if (unlikely(c)) {						\
 		if (debug_locks_off())					\
-			WARN_ON(1);					\
+			WARN_ON(c);					\
 		__ret = 1;						\
 	}								\
 	__ret;								\
-
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/