01 Nov, 2011
1 commit
-
Standardize the style for compiler based printf format verification.
Standardized the location of __printf too.Done via script and a little typing.
$ grep -rPl --include=*.[ch] -w "__attribute__" * | \
grep -vP "^(tools|scripts|include/linux/compiler-gcc.h)" | \
xargs perl -n -i -e 'local $/; while (<>) { s/\b__attribute__\s*\(\s*\(\s*format\s*\(\s*printf\s*,\s*(.+)\s*,\s*(.+)\s*\)\s*\)\s*\)/__printf($1, $2)/g ; print; }'[akpm@linux-foundation.org: revert arch bits]
Signed-off-by: Joe Perches
Cc: "Kirill A. Shutemov"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
27 May, 2011
1 commit
-
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
25 May, 2011
1 commit
-
Based upon an email by Joe Perches.
Reported-by: Randy Dunlap
Signed-off-by: David S. Miller
Acked-by: Randy Dunlap
24 May, 2011
1 commit
-
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
28 Mar, 2011
1 commit
-
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
25 Mar, 2011
1 commit
-
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:
Signed-off-by: Ingo Molnar
19 May, 2010
1 commit
-
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
16 Dec, 2009
1 commit
-
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.afterSigned-off-by: Cesar Eduardo Barros
Cc: Roland Dreier
Cc: Daniel Walker
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 May, 2009
1 commit
-
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 stringdue 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 vmlinuxdue 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
16 Apr, 2009
1 commit
-
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
07 Jan, 2009
1 commit
-
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
31 Dec, 2008
1 commit
-
* 'core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (63 commits)
stacktrace: provide save_stack_trace_tsk() weak alias
rcu: provide RCU options on non-preempt architectures too
printk: fix discarding message when recursion_bug
futex: clean up futex_(un)lock_pi fault handling
"Tree RCU": scalable classic RCU implementation
futex: rename field in futex_q to clarify single waiter semantics
x86/swiotlb: add default swiotlb_arch_range_needs_mapping
x86/swiotlb: add default physbus conversion
x86: unify pci iommu setup and allow swiotlb to compile for 32 bit
x86: add swiotlb allocation functions
swiotlb: consolidate swiotlb info message printing
swiotlb: support bouncing of HighMem pages
swiotlb: factor out copy to/from device
swiotlb: add arch hook to force mapping
swiotlb: allow architectures to override physbusphys conversions
swiotlb: add comment where we handle the overflow of a dma mask on 32 bit
rcu: fix rcutorture behavior during reboot
resources: skip sanity check of busy resources
swiotlb: move some definitions to header
swiotlb: allow architectures to override swiotlb pool allocation
...Fix up trivial conflicts in
arch/x86/kernel/Makefile
arch/x86/mm/init_32.c
include/linux/hardirq.h
as per Ingo's suggestions.
17 Dec, 2008
1 commit
-
Impact: reduce bug table size
This allows reducing the bug table size by half. Perhaps there are
other 64-bit architectures that could also make use of this.Signed-off-by: Jan Beulich
Signed-off-by: Ingo Molnar
29 Nov, 2008
1 commit
-
Impact: cleanup, eliminate code
now that warn_on_slowpath() uses warn_slowpath(...,NULL), we can
eliminate warn_on_slowpath() altogether and use warn_slowpath().Signed-off-by: Ingo Molnar
21 Oct, 2008
1 commit
-
powerpc doesn't use the generic WARN_ON infrastructure. The newly
introduced WARN() as a result didn't print the message, this patch adds
the printk for this specific case.Signed-off-by: Arjan van de Ven
Signed-off-by: Linus Torvalds
17 Oct, 2008
1 commit
-
__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: Harvey Harrison
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Sep, 2008
1 commit
-
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
26 Jul, 2008
2 commits
-
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 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
30 Jan, 2008
2 commits
-
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-slowpath15Kb 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 -
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
01 Aug, 2007
1 commit
-
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
18 Jul, 2007
1 commit
-
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
25 May, 2007
1 commit
-
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
31 Dec, 2006
1 commit
-
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
09 Dec, 2006
2 commits
-
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 -
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 consistentlyThis 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.[randy.dunlap@oracle.com: Handle BUG=n, GENERIC_BUG=n to prevent build errors]
[bunk@stusta.de: include/linux/bug.h must always #include
Cc: Andi Kleen
Cc: Hugh Dickens
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: Benjamin Herrenschmidt
Cc: Rusty Russell
Signed-off-by: Adrian Bunk
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
21 Oct, 2006
1 commit
-
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 effectSigned-off-by: Ralf Baechle
Cc: Jeremy Fitzhardinge
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
06 Oct, 2006
1 commit
-
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
Cc: Herbert Xu
Cc: "Ananiev, Leonid I"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Sep, 2006
1 commit
-
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.[akpm@osdl.org: warning fix]
[akpm@osdl.org: build fix]
Signed-off-by: Herbert Xu
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
28 Jun, 2006
1 commit
-
Introduce a new WARN_ON variant: WARN_ON_SMP(cond).
Signed-off-by: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
26 Jun, 2006
1 commit
-
Add WARN_ON_ONCE(cond) to print once-per-bootup messages.
[rostedt@goodmis.org: improve code generation]
Signed-off-by: Ingo Molnar
Signed-off-by: Arjan van de Ven
Signed-off-by: Steven Rostedt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
26 Apr, 2006
1 commit
-
Signed-off-by: David Woodhouse
23 Mar, 2006
1 commit
-
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
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
01 May, 2005
2 commits
-
Remove PAGE_BUG - repalce it with BUG and BUG_ON.
Signed-off-by: Matt Mackall
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This patch eliminates all kernel BUGs, trims about 35k off the typical
kernel, and makes the system slightly faster.Signed-off-by: Matt Mackall
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Apr, 2005
1 commit
-
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!
