linux-toradex.git/kernel/panic.c, branch v2.6.27.10

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

2008-07-25T17:53:29+00:00

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

Taint kernel after WARN_ON(condition)

2008-04-29T15:05:59+00:00

The kernel is sent to tainted within the warn_on_slowpath() function, and
whenever a warning occurs the new taint flag 'W' is set.  This is useful to
know if a warning occurred before a BUG by preserving the warning as a flag
in the taint state.

This does not work on architectures where WARN_ON has its own definition.
These archs are:
	1. s390
	2. superh
	3. avr32
	4. parisc

The maintainers of these architectures have been added in the Cc: list
in this email to alert them to the situation.

The documentation in oops-tracing.txt has been updated to include the
new flag.

Signed-off-by: Nur Hussein 
Cc: Arjan van de Ven 
Cc: "Randy.Dunlap" 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Kyle McMartin 
Cc: Martin Schwidefsky 
Cc: Haavard Skinnemoen 
Cc: Paul Mundt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ACPI: Taint kernel on ACPI table override (format corrected)

2008-02-07T03:07:51+00:00

When an ACPI table is overridden (for now this can happen only for DSDT)
display a big warning and taint the kernel with flag A.

Signed-off-by: Eric Piel 
Signed-off-by: Len Brown

debug: add the end-of-trace marker and the module list to

2008-01-30T12:32:50+00:00

Unlike oopses, WARN_ON() currently does't print the loaded modules list.
This makes it harder to take action on certain bug reports. For example,
recently there were a set of WARN_ON()s reported in the mac80211 stack,
which were just signalling a driver bug. It takes then anther round trip
to the bug reporter (if he responds at all) to find out which driver
is at fault.

Another issue is that, unlike oopses, WARN_ON() doesn't currently printk
the helpful "cut here" line, nor the "end of trace" marker.
Now that WARN_ON() is out of line, the size increase due to this is
minimal and it's worth adding.

Signed-off-by: Arjan van de Ven 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner

debug: move WARN_ON() out of line

2008-01-30T12:32:50+00:00

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: add end-of-oops marker

2007-12-20T14:01:17+00:00

Right now it's nearly impossible for parsers that collect kernel crashes
from logs or emails (such as www.kerneloops.org) to detect the
end-of-oops condition. In addition, it's not currently possible to
detect whether or not 2 oopses that look alike are actually the same
oops reported twice, or are truly two unique oopses.

This patch adds an end-of-oops marker, and makes the end marker include
a very simple 64-bit random ID to be able to detect duplicate reports.

Normally, this ID is calculated as a late_initcall() (in the hope that
at that time there is enough entropy to get a unique enough ID); however
for early oopses the oops_exit() function needs to generate the ID on
the fly.

We do this all at the _end_ of an oops printout, so this does not impact
our ability to get the most important portions of a crash out to the
console first.

[ Sidenote: the already existing oopses-since-bootup counter we print
  during crashes serves as the differentiator between multiple oopses
  that trigger during the same bootup. ]

Tested on 32-bit and 64-bit x86. Artificially injected very early
crashes as well, as expected they result in this constant ID after
multiple bootups:

  ---[ end trace ca143223eefdc828 ]---
  ---[ end trace ca143223eefdc828 ]---

because the random pools are still all zero. But it all still works
fine and causes no additional problems (which is the main goal of
instrumentation code).

Signed-off-by: Arjan van de Ven 
Signed-off-by: Ingo Molnar

trivial comment wording/typo fix regarding taint flags

2007-10-19T22:30:06+00:00

Signed-off-by: Daniel Roesen 
Signed-off-by: Adrian Bunk

whitespace fixes: panic handling

2007-10-18T21:37:25+00:00

Signed-off-by: Daniel Walker 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Report that kernel is tainted if there was an OOPS

2007-07-17T17:23:02+00:00

If the kernel OOPSed or BUGed then it probably should be considered as
tainted.  Thus, all subsequent OOPSes and SysRq dumps will report the
tainted kernel.  This saves a lot of time explaining oddities in the
calltraces.

Signed-off-by: Pavel Emelianov 
Acked-by: Randy Dunlap 
Cc: 
Signed-off-by: Andrew Morton 
[ Added parisc patch from Matthew Wilson  -Linus ]
Signed-off-by: Linus Torvalds

[PATCH] Add TAINT_USER and ability to set taint flags from userspace

2007-02-11T18:51:29+00:00

Allow taint flags to be set from userspace by writing to
/proc/sys/kernel/tainted, and add a new taint flag, TAINT_USER, to be used
when userspace has potentially done something dangerous that might
compromise the kernel.  This will allow support personnel to ask further
questions about what may have caused the user taint flag to have been set.

For example, they might examine the logs of the realtime JVM to see if the
Java program has used the really silly, stupid, dangerous, and
completely-non-portable direct access to physical memory feature which MUST
be implemented according to the Real-Time Specification for Java (RTSJ).
Sigh.  What were those silly people at Sun thinking?

[akpm@osdl.org: build fix]
[bunk@stusta.de: cleanup]
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Adrian Bunk 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds