user/sven/linux.git/include/asm-generic/bug.h, branch v3.0

bug.h: Move ratelimit warn interfaces to ratelimit.h

2011-05-26T19:00:31Z

As reported by Ingo Molnar, we still have configuration combinations where use of the WARN_RATELIMIT interfaces break the build because dependencies don't get met. Instead of going down the long road of trying to make it so that ratelimit.h can get included by kernel.h or asm-generic/bug.h, just move the interface into ratelimit.h and make users have to include that. Reported-by: Ingo Molnar Signed-off-by: David S. Miller Acked-by: Randy Dunlap

bug.h: Fix build with CONFIG_PRINTK disabled.

2011-05-24T20:15:56Z

Based upon an email by Joe Perches. Reported-by: Randy Dunlap Signed-off-by: David S. Miller Acked-by: Randy Dunlap

bug.h: Add WARN_RATELIMIT

2011-05-23T21:37:43Z

Add a generic mechanism to ratelimit WARN(foo, fmt, ...) messages using a hidden per call site static struct ratelimit_state. Also add an __WARN_RATELIMIT variant to be able to use a specific struct ratelimit_state. Signed-off-by: Joe Perches Signed-off-by: David S. Miller

WARN_ON_SMP(): Add comment to explain ({0;})

2011-03-28T14:10:42Z

The define to use ({0;}) for the !CONFIG_SMP case of WARN_ON_SMP() can be confusing. As the WARN_ON_SMP() needs to be a nop when CONFIG_SMP is not set, including all its parameters must not be evaluated, and that it must work as both a stand alone statement and inside an if condition, we define it to a funky ({0;}). A simple "0" will not work as it causes gcc to give the warning that the statement has no effect. As this strange definition has raised a few eyebrows from some major kernel developers, it is wise to document why we create such a work of art. Cc: Linus Torvalds Cc: Alexey Dobriyan Signed-off-by: Steven Rostedt

WARN_ON_SMP(): Allow use in if() statements on UP

2011-03-25T10:32:09Z

Both WARN_ON() and WARN_ON_SMP() should be able to be used in an if statement. if (WARN_ON_SMP(foo)) { ... } Because WARN_ON_SMP() is defined as a do { } while (0) on UP, it can not be used this way. Convert it to the same form that WARN_ON() is, even when CONFIG_SMP is off. Signed-off-by: Steven Rostedt Acked-by: Thomas Gleixner Acked-by: Peter Zijlstra Acked-by: Darren Hart Cc: Lai Jiangshan Cc: Linus Torvalds Cc: Andrew Morton LKML-Reference: <20110317192208.444147791@goodmis.org> Signed-off-by: Ingo Molnar

panic: Allow warnings to set different taint flags

2010-05-19T07:36:48Z

WARN() is used in some places to report firmware or hardware bugs that are then worked-around. These bugs do not affect the stability of the kernel and should not set the flag for TAINT_WARN. To allow for this, add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint number as argument. Architectures that implement warnings using trap instructions instead of calls to warn_slowpath_*() now implement __WARN_TAINT(taint) instead of __WARN(). Signed-off-by: Ben Hutchings Acked-by: Helge Deller Tested-by: Paul Mundt Signed-off-by: David Woodhouse

WARN_ONCE(): use bool for boolean flag

2009-12-15T16:53:25Z

Commit 70867453092297be9afb2249e712a1f960ec0a09 ("printk_once(): use bool for boolean flag") changed printk_once() to use bool instead of int for its guard variable. Do the same change to WARN_ONCE() and WARN_ON_ONCE(), for the same reasons. This resulted in a reduction of 1462 bytes on a x86-64 defconfig: text data bss dec hex filename 8101271 1207116 992764 10301151 9d2edf vmlinux.before 8100553 1207148 991988 10299689 9d2929 vmlinux.after Signed-off-by: Cesar Eduardo Barros Cc: Roland Dreier Cc: Daniel Walker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Eliminate thousands of warnings with gcc 3.2 build

2009-05-06T23:36:09Z

When building with gcc 3.2 I get thousands of warnings such as include/linux/gfp.h: In function `allocflags_to_migratetype': include/linux/gfp.h:105: warning: null format string due to passing a NULL format string to warn_slowpath() in #define __WARN() warn_slowpath(__FILE__, __LINE__, NULL) Split this case out into a separate call. This also shrinks the kernel slightly: text data bss dec hex filename 4802274 707668 712704 6222646 5ef336 vmlinux text data bss dec hex filename 4799027 703572 712704 6215303 5ed687 vmlinux due to removeing one argument from the commonly-called __WARN(). [akpm@linux-foundation.org: reduce scope of `empty'] Acked-by: Jesper Nilsson Acked-by: Johannes Weiner Acked-by: Arjan van de Ven Signed-off-by: Andi Kleen Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

The default CONFIG_BUG=n version of BUG() should have an empty do...while

2009-04-15T20:55:13Z

The default CONFIG_BUG=n version of BUG() should incorporate an empty a do...while statement to avoid compilation weirdness. Signed-off-by: David Howells Signed-off-by: Linus Torvalds

documentation: when to BUG(), and when to not BUG()

2009-01-06T23:59:13Z

Provide some basic advice about when to use BUG()/BUG_ON(): never, unless there's really no better option. This matches my understanding of the standard policy ... which seems not to be written down so far, outside of LKML messages that I haven't bookmarked. Signed-off-by: David Brownell Cc: Hans Verkuil Cc: Ingo Molnar Cc: Arjan van de Ven Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds