aboutsummaryrefslogtreecommitdiff
path: root/include/asm-generic/bug.h
AgeCommit message (Collapse)AuthorFilesLines
2008-01-30debug: move WARN_ON() out of lineArjan van de Ven1-5/+5
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 <[email protected]> CC: Andrew Morton <[email protected]> CC: Olof Johansson <[email protected]> Acked-by: Matt Meckall <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2008-01-30debug: introduce __WARN()Olof Johansson1-6/+11
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 <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2007-07-31Fix WARN_ON() on bitfield opsLinus Torvalds1-3/+3
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 <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Al Viro <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2007-07-17Fix sparse false positives re BUG_ON(ptr)Alexey Dobriyan1-1/+1
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 <[email protected]> Acked-by: Al Viro <[email protected]> Acked-by: Josh Triplett <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2007-05-24Don't call a warnign a bug. It's a warning.Linus Torvalds1-1/+1
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 <[email protected]>
2006-12-30[PATCH] change WARN_ON back to "BUG: at ..."Ingo Molnar1-1/+1
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 <[email protected]> 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 <[email protected]> Cc: Jeremy Fitzhardinge <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2006-12-08[PATCH] Fix generic WARN_ON messageJeremy Fitzhardinge1-1/+1
A warning is a warning, not a BUG. Signed-off-by: Jeremy Fitzhardinge <[email protected]> Cc: Ingo Molnar <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2006-12-08[PATCH] Generic BUG implementationJeremy Fitzhardinge1-0/+16
This patch adds common handling for kernel BUGs, for use by architectures as they wish. The code is derived from arch/powerpc. The advantages of having common BUG handling are: - consistent BUG reporting across architectures - shared implementation of out-of-line file/line data - implement CONFIG_DEBUG_BUGVERBOSE consistently This means that in inline impact of BUG is just the illegal instruction itself, which is an improvement for i386 and x86-64. A BUG is represented in the instruction stream as an illegal instruction, which has file/line information associated with it. This extra information is stored in the __bug_table section in the ELF file. When the kernel gets an illegal instruction, it first confirms it might possibly be from a BUG (ie, in kernel mode, the right illegal instruction). It then calls report_bug(). This searches __bug_table for a matching instruction pointer, and if found, prints the corresponding file/line information. If report_bug() determines that it wasn't a BUG which caused the trap, it returns BUG_TRAP_TYPE_NONE. Some architectures (powerpc) implement WARN using the same mechanism; if the illegal instruction was the result of a WARN, then report_bug(Q) returns CONFIG_DEBUG_BUGVERBOSE; otherwise it returns BUG_TRAP_TYPE_BUG. lib/bug.c keeps a list of loaded modules which can be searched for __bug_table entries. The architecture must call module_bug_finalize()/module_bug_cleanup() from its corresponding module_finalize/cleanup functions. Unsetting CONFIG_DEBUG_BUGVERBOSE will reduce the kernel size by some amount. At the very least, filename and line information will not be recorded for each but, but architectures may decide to store no extra information per BUG at all. Unfortunately, gcc doesn't have a general way to mark an asm() as noreturn, so architectures will generally have to include an infinite loop (or similar) in the BUG code, so that gcc knows execution won't continue beyond that point. gcc does have a __builtin_trap() operator which may be useful to achieve the same effect, unfortunately it cannot be used to actually implement the BUG itself, because there's no way to get the instruction's address for use in generating the __bug_table entry. [[email protected]: Handle BUG=n, GENERIC_BUG=n to prevent build errors] [[email protected]: include/linux/bug.h must always #include <linux/module.h] Signed-off-by: Jeremy Fitzhardinge <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Hugh Dickens <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: Rusty Russell <[email protected]> Signed-off-by: Adrian Bunk <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2006-10-20[PATCH] Fix warnings for WARN_ON if CONFIG_BUG is disabledRalf Baechle1-1/+4
In most cases the return value of WARN_ON() is ignored. If the generic definition for the !CONFIG_BUG case is used this will result in a warning: CC kernel/sched.o In file included from include/linux/bio.h:25, from include/linux/blkdev.h:14, from kernel/sched.c:39: include/linux/ioprio.h: In function ‘task_ioprio’: include/linux/ioprio.h:50: warning: statement with no effect kernel/sched.c: In function ‘context_switch’: kernel/sched.c:1834: warning: statement with no effect Signed-off-by: Ralf Baechle <[email protected]> Cc: Jeremy Fitzhardinge <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2006-10-06[PATCH] Fix WARN_ON / WARN_ON_ONCE regressionAndrew Morton1-8/+8
Tim and Ananiev report that the recent WARN_ON_ONCE changes cause increased cache misses with the tbench workload. Apparently due to the access to the newly-added static variable. Rearrange the code so that we don't touch that variable unless the warning is going to trigger. Also rework the logic so that the static variable starts out at zero, so we can move it into bss. It would seem logical to mark the static variable as __read_mostly too. But it would be wrong, because that would put it back into the vmlinux image, and the kernel will never read from this variable in normal operation anyway. Unless the compiler or hardware go and do some prefetching on us? For some reason this patch shrinks softirq.o text by 40 bytes. Cc: Tim Chen <[email protected]> Cc: Herbert Xu <[email protected]> Cc: "Ananiev, Leonid I" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2006-09-29[PATCH] Let WARN_ON/WARN_ON_ONCE return the conditionHerbert Xu1-16/+16
Letting WARN_ON/WARN_ON_ONCE return the condition means that you could do if (WARN_ON(blah)) { handle_impossible_case } Rather than if (unlikely(blah)) { WARN_ON(1) handle_impossible_case } I checked all the newly added WARN_ON_ONCE users and none of them test the return status so we can still change it. [[email protected]: warning fix] [[email protected]: build fix] Signed-off-by: Herbert Xu <[email protected]> Cc: Ingo Molnar <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2006-06-27[PATCH] pi-futex: introduce WARN_ON_SMPIngo Molnar1-0/+6
Introduce a new WARN_ON variant: WARN_ON_SMP(cond). Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2006-06-25[PATCH] introduce WARN_ON_ONCE(cond)Ingo Molnar1-0/+13
Add WARN_ON_ONCE(cond) to print once-per-bootup messages. [[email protected]: improve code generation] Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Arjan van de Ven <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2006-04-26Don't include linux/config.h from anywhere else in include/David Woodhouse1-1/+0
Signed-off-by: David Woodhouse <[email protected]>
2006-03-23[PATCH] make bug messages more consistentIngo Molnar1-2/+2
Consolidate all kernel bug printouts to begin with the "BUG: " string. Makes it easier to find them in large bootup logs. Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2005-05-01[PATCH] Exterminate PAGE_BUGMatt Mackall1-11/+0
Remove PAGE_BUG - repalce it with BUG and BUG_ON. Signed-off-by: Matt Mackall <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2005-05-01[PATCH] remove all kernel BUGsMatt Mackall1-0/+19
This patch eliminates all kernel BUGs, trims about 35k off the typical kernel, and makes the system slightly faster. Signed-off-by: Matt Mackall <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2005-04-16Linux-2.6.12-rc2Linus Torvalds1-0/+34
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!