linux/Documentation/oops-tracing.txt, branch v3.17-rc3

panic: add TAINT_SOFTLOCKUP

2014-08-08T22:57:24Z

This taint flag will be set if the system has ever entered a softlockup state. Similar to TAINT_WARN it is useful to know whether or not the system has been in a softlockup state when debugging. [akpm@linux-foundation.org: apply the taint before calling panic()] Signed-off-by: Josh Hunt Cc: Jason Baron Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Use 'E' instead of 'X' for unsigned module taint flag.

2014-03-31T04:22:43Z

Takashi Iwai says: > The letter 'X' has been already used for SUSE kernels for very long > time, to indicate the external supported modules. Can the new flag be > changed to another letter for avoiding conflict...? > (BTW, we also use 'N' for "no support", too.) Note: this code should be cleaned up, so we don't have such maps in three places! Signed-off-by: Rusty Russell

Fix: module signature vs tracepoints: add new TAINT_UNSIGNED_MODULE

2014-03-13T01:41:51Z

Users have reported being unable to trace non-signed modules loaded within a kernel supporting module signature. This is caused by tracepoint.c:tracepoint_module_coming() refusing to take into account tracepoints sitting within force-loaded modules (TAINT_FORCED_MODULE). The reason for this check, in the first place, is that a force-loaded module may have a struct module incompatible with the layout expected by the kernel, and can thus cause a kernel crash upon forced load of that module on a kernel with CONFIG_TRACEPOINTS=y. Tracepoints, however, specifically accept TAINT_OOT_MODULE and TAINT_CRAP, since those modules do not lead to the "very likely system crash" issue cited above for force-loaded modules. With kernels having CONFIG_MODULE_SIG=y (signed modules), a non-signed module is tainted re-using the TAINT_FORCED_MODULE taint flag. Unfortunately, this means that Tracepoints treat that module as a force-loaded module, and thus silently refuse to consider any tracepoint within this module. Since an unsigned module does not fit within the "very likely system crash" category of tainting, add a new TAINT_UNSIGNED_MODULE taint flag to specifically address this taint behavior, and accept those modules within Tracepoints. We use the letter 'X' as a taint flag character for a module being loaded that doesn't know how to sign its name (proposed by Steven Rostedt). Also add the missing 'O' entry to trace event show_module_flags() list for the sake of completeness. Signed-off-by: Mathieu Desnoyers Acked-by: Steven Rostedt NAKed-by: Ingo Molnar CC: Thomas Gleixner CC: David Howells CC: Greg Kroah-Hartman Signed-off-by: Rusty Russell

module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree

2011-11-06T21:24:42Z

Use of the GPL or a compatible licence doesn't necessarily make the code any good. We already consider staging modules to be suspect, and this should also be true for out-of-tree modules which may receive very little review. Signed-off-by: Ben Hutchings Reviewed-by: Dave Jones Acked-by: Greg Kroah-Hartman Signed-off-by: Rusty Russell (patched oops-tracing.txt)

panic: Add taint flag TAINT_FIRMWARE_WORKAROUND ('I')

2010-05-19T07:37:43Z

This taint flag will initially be used when warning about invalid ACPI DMAR tables. Signed-off-by: Ben Hutchings Signed-off-by: David Woodhouse

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

docs: Describe the 'C' taint flag in oops-tracing.txt

2009-11-09T08:40:56Z

If some of the flags are documented there, they all should be. Signed-off-by: Nick Bowler Acked-by: Randy Dunlap Signed-off-by: Jiri Kosina

Taint kernel after WARN_ON(condition)

2008-04-29T15:05:59Z

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

Report that kernel is tainted if there was an OOPS

2007-07-17T17:23:02Z

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

doc/oops-tracing: add Code: decode info

2007-07-16T16:05:48Z

Add info that the Code: bytes line contains or (wxyz) in some architecture oops reports and what that means. Add a script by Andi Kleen that reads the Code: line from an Oops report file and generates assembly code from the hex bytes. Signed-off-by: Randy Dunlap Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds