Eric Lee / smarc-fsl-linux-kernel

22 Dec, 2014

1 commit

  • c5f454659   livepatch: kernel: add TAINT_LIVEPATCH ... Browse Code »

    This adds a new taint flag to indicate when the kernel or a kernel
    module has been live patched. This will provide a clean indication in
    bug reports that live patching was used.

    Additionally, if the crash occurs in a live patched function, the live
    patch module will appear beside the patched function in the backtrace.

    Signed-off-by: Seth Jennings
    Acked-by: Josh Poimboeuf
    Reviewed-by: Miroslav Benes
    Reviewed-by: Petr Mladek
    Reviewed-by: Masami Hiramatsu
    Signed-off-by: Jiri Kosina

    Seth Jennings
     

09 Aug, 2014

1 commit

  • 69361eef9   panic: add TAINT_SOFTLOCKUP ... Browse Code »

    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

    Josh Hunt
     

31 Mar, 2014

1 commit

  • 57673c2b0   Use 'E' instead of 'X' for unsigned module taint flag. ... Browse Code »

    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

    Rusty Russell
     

13 Mar, 2014

1 commit

  • 66cc69e34   Fix: module signature vs tracepoints: add new TAINT_UNSIGNED_MODULE ... Browse Code »

    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

    Mathieu Desnoyers
     

07 Nov, 2011

1 commit

  • 2449b8ba0   module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree ... Browse Code »

    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)

    Ben Hutchings
     

19 May, 2010

2 commits

  • 92946bc72   panic: Add taint flag TAINT_FIRMWARE_WORKAROUND ('I') ... Browse Code »

    This taint flag will initially be used when warning about invalid ACPI
    DMAR tables.

    Signed-off-by: Ben Hutchings
    Signed-off-by: David Woodhouse

    Ben Hutchings
     
  • b2be05273   panic: Allow warnings to set different taint flags ... Browse Code »

    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

    Ben Hutchings
     

09 Nov, 2009

1 commit

29 Apr, 2008

1 commit

  • 95b570c9c   Taint kernel after WARN_ON(condition) ... Browse Code »

    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

    Nur Hussein
     

18 Jul, 2007

1 commit

  • bcdcd8e72   Report that kernel is tainted if there was an OOPS ... Browse Code »

    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

    Pavel Emelianov
     

17 Jul, 2007

1 commit

  • dcecc6c70   doc/oops-tracing: add Code: decode info ... Browse Code »

    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

    Randy Dunlap
     

09 May, 2007

1 commit

21 Feb, 2007

1 commit

12 Jan, 2006

1 commit

16 Nov, 2005

1 commit

14 Nov, 2005

1 commit

07 Nov, 2005

1 commit

13 Sep, 2005

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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!

    Linus Torvalds