06 Oct, 2010
1 commit
-
With all the recent module loading cleanups, we've minimized the code
that sits under module_mutex, fixing various deadlocks and making it
possible to do most of the module loading in parallel.However, that whole conversion totally missed the rather obscure code
that adds a new module to the list for BUG() handling. That code was
doubly obscure because (a) the code itself lives in lib/bugs.c (for
dubious reasons) and (b) it gets called from the architecture-specific
"module_finalize()" rather than from generic code.Calling it from arch-specific code makes no sense what-so-ever to begin
with, and is now actively wrong since that code isn't protected by the
module loading lock any more.So this commit moves the "module_bug_{finalize,cleanup}()" calls away
from the arch-specific code, and into the generic code - and in the
process protects it with the module_mutex so that the list operations
are now safe.Future fixups:
- move the module list handling code into kernel/module.c where it
belongs.
- get rid of 'module_bug_list' and just use the regular list of modules
(called 'modules' - imagine that) that we already create and maintain
for other reasons.Reported-and-tested-by: Thomas Gleixner
Cc: Rusty Russell
Cc: Adrian Bunk
Cc: Andrew Morton
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds
11 Aug, 2010
2 commits
-
We are missing the oops end marker for the exception based WARN implementation
in lib/bug.c. This is useful for logfile analysis tools.Signed-off-by: Anton Blanchard
Cc: Ingo Molnar
Cc: Arjan van de Ven
Cc: "Kirill A. Shutemov"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
There are a few issues with the exception based WARN implementation in
lib/bug.c:- Inconsistent printk flags. The "cut here" line is printed at KERN_EMERG, so
the console and all logged in users see the single line:------------[ cut here ]------------
for each WARN. Fix this so we print everything at KERN_WARNING to match the
kernel/panic.c version.- The lib/bug.c WARN would print "Badness at". Change it to match the
kernel/panic.c version which prints "WARNING: at".- Print the list of modules, similar to kernel/panic.c of modules, similar to
kernel/panic.c[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Anton Blanchard
Cc: Ingo Molnar
Cc: Arjan van de Ven
Cc: "Kirill A. Shutemov"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
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
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
05 Jul, 2008
1 commit
-
Commit 95b570c9cef3b12356454c7112571b7e406b4b51 ("Taint kernel after
WARN_ON(condition)") introduced a TAINT_WARN that was implemented for
all architectures using the generic warn_on_slowpath(), which excluded
any architecture that set HAVE_ARCH_WARN_ON.As all of the architectures that implement their own WARN_ON() all go
through the report_bug() path (specifically handling BUG_TRAP_TYPE_WARN),
taint the kernel there as well for consistency.Tested on avr32 and sh. Also relevant for s390, parisc, and powerpc.
Signed-off-by: Haavard Skinnemoen
Signed-off-by: Paul Mundt
Acked-by: Kyle McMartin
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Jul, 2007
1 commit
-
The current generic bug implementation has a call to dump_stack() in case a
WARN_ON(whatever) gets hit. Since report_bug(), which calls dump_stack(),
gets called from an exception handler we can do better: just pass the
pt_regs structure to report_bug() and pass it to show_regs() in case of a
warning. This will give more debug informations like register contents,
etc... In addition this avoids some pointless lines that dump_stack()
emits, since it includes a stack backtrace of the exception handler which
is of no interest in case of a warning. E.g. on s390 the following lines
are currently always present in a stack backtrace if dump_stack() gets
called from report_bug():[] show_trace+0x92/0xe8)
[] show_stack+0xa0/0xd0
[] dump_stack+0x2e/0x3c
[] report_bug+0x98/0xf8
[] illegal_op+0x1fc/0x21c
[] sysc_return+0x0/0x10Acked-by: Jeremy Fitzhardinge
Acked-by: Haavard Skinnemoen
Cc: Andi Kleen
Cc: Kyle McMartin
Cc: Paul Mackerras
Cc: Paul Mundt
Cc: Martin Schwidefsky
Signed-off-by: Heiko Carstens
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
09 Dec, 2006
1 commit
-
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
