linux/include/asm-generic/bug.h, branch v2.6.27.7

warn: Turn the netdev timeout WARN_ON() into a WARN()

2008-09-17T02:39:33Z

this patch turns the netdev timeout WARN_ON_ONCE() into a WARN_ONCE(), so that the device and driver names are inside the warning message. This helps automated tools like kerneloops.org to collect the data and do statistics, as well as making it more likely that humans cut-n-paste the important message as part of a bugreport. Signed-off-by: Arjan van de Ven Signed-off-by: Linus Torvalds

printk ratelimiting rewrite

2008-07-25T17:53:29Z

All ratelimit user use same jiffies and burst params, so some messages (callbacks) will be lost. For example: a call printk_ratelimit(5 * HZ, 1) b call printk_ratelimit(5 * HZ, 1) before the 5*HZ timeout of a, then b will will be supressed. - rewrite __ratelimit, and use a ratelimit_state as parameter. Thanks for hints from andrew. - Add WARN_ON_RATELIMIT, update rcupreempt.h - remove __printk_ratelimit - use __ratelimit in net_ratelimit Signed-off-by: Dave Young Cc: "David S. Miller" Cc: "Paul E. McKenney" Cc: Dave Young Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Add a WARN() macro; this is WARN_ON() + printk arguments

2008-07-25T17:53:29Z

Add a WARN() macro that acts like WARN_ON(), with the added feature that it takes a printk like argument that is printed as part of the warning message. [akpm@linux-foundation.org: fix printk arguments] [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Arjan van de Ven Cc: Greg KH Cc: Jiri Slaby Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

debug: move WARN_ON() out of line

2008-01-30T12:32:50Z

A quick grep shows that there are currently 1145 instances of WARN_ON in the kernel. Currently, WARN_ON is pretty much entirely inlined, which makes it hard to enhance it without growing the size of the kernel (and getting Andrew unhappy). This patch build on top of Olof's patch that introduces __WARN, and places the slowpath out of line. It also uses Ingo's suggestion to not use __FUNCTION__ but to use kallsyms to do the lookup; this saves a ton of extra space since gcc doesn't need to store the function string twice now: 3936367 833603 624736 5394706 525112 vmlinux.before 3917508 833603 624736 5375847 520767 vmlinux-slowpath 15Kb savings... Signed-off-by: Arjan van de Ven CC: Andrew Morton CC: Olof Johansson Acked-by: Matt Meckall Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner

debug: introduce __WARN()

2008-01-30T12:32:50Z

Introduce __WARN() in the generic case, so the generic WARN_ON() can use arch-specific code for when the condition is true. Signed-off-by: Olof Johansson Cc: Signed-off-by: Andrew Morton Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner

Fix WARN_ON() on bitfield ops

2007-08-01T04:12:07Z

Alexey Dobriyan noticed that the new WARN_ON() semantics that were introduced by commit 684f978347deb42d180373ac4c427f82ef963171 (to also return the value to be warned on) didn't compile when given a bitfield, because the typeof doesn't work for bitfields. So instead of the typeof trick, use an "int" variable together with a "!!(x)" expression, as suggested by Al Viro. To make matters more interesting, Paul Mackerras points out that that is sub-optimal on Power, but the old asm-coded comparison seems to be buggy anyway on 32-bit Power if the conditional was 64-bit, so I think there are more problems there. Regardless, the new WARN_ON() semantics may have been a bad idea. But this at least avoids the more serious complications. Cc: Alexey Dobriyan Cc: Herbert Xu Cc: Paul Mackerras Cc: Al Viro Cc: Ingo Molnar Cc: Andrew Morton Signed-off-by: Linus Torvalds

Fix sparse false positives re BUG_ON(ptr)

2007-07-17T17:23:03Z

sparse now warns if one compares pointers with integers. However, there are false positives, like: fs/filesystems.c:72:2: warning: Using plain integer as NULL pointer Every time BUG_ON(ptr) is used, ptr is checked against integer zero. Avoid that and save ~70 false positives from allyesconfig run. mentioned by Al. Signed-off-by: Alexey Dobriyan Acked-by: Al Viro Acked-by: Josh Triplett Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Don't call a warnign a bug. It's a warning.

2007-05-24T17:13:43Z

Change the default printout message for WARN_ON() to say what it is, not something else. I'm tired of having people get all aflutter about a warning. Signed-off-by: Linus Torvalds

[PATCH] change WARN_ON back to "BUG: at ..."

2006-12-30T18:55:54Z

WARN_ON() ever triggering is a kernel bug. Do not try to paper over this fact by suggesting to the user that this is 'only' a warning, as the following recent commit does: commit 30e25b71e725b150585e17888b130e3324f8cf7c Author: Jeremy Fitzhardinge Date: Fri Dec 8 02:36:24 2006 -0800 [PATCH] Fix generic WARN_ON message A warning is a warning, not a BUG. ( it might make sense to rename BUG() to CRASH() and BUG_ON() to CRASH_ON(), but that does not change the fact that WARN_ON() signals a kernel bug. ) i and others objected to this change during lkml review: http://marc.theaimsgroup.com/?l=linux-kernel&m=116115160710533&w=2 still the change slipped upstream - grumble :) Also, use the standard "BUG: " format to make it easier to grep logs and to make it easier to google for kernel bugs. Signed-off-by: Ingo Molnar Cc: Jeremy Fitzhardinge Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Fix generic WARN_ON message

2006-12-08T16:28:39Z

A warning is a warning, not a BUG. Signed-off-by: Jeremy Fitzhardinge Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds