linux-toradex.git/kernel/panic.c, branch v3.3.5

panic: fix stack dump print on direct call to panic()

2012-04-22T22:38:56+00:00

commit 026ee1f66aaa7f01b617a0ba89ac4b531f9603f1 upstream.

Commit 6e6f0a1f0fa6 ("panic: don't print redundant backtraces on oops")
causes a regression where no stack trace will be printed at all for the
case where kernel code calls panic() directly while not processing an
oops, and of course there are 100's of instances of this type of call.

The original commit executed the check (!oops_in_progress), but this will
always be false because just before the dump_stack() there is a call to
bust_spinlocks(1), which does the following:

  void __attribute__((weak)) bust_spinlocks(int yes)
  {
	if (yes) {
		++oops_in_progress;

The proper way to resolve the problem that original commit tried to
solve is to avoid printing a stack dump from panic() when the either of
the following conditions is true:

  1) TAINT_DIE has been set (this is done by oops_end())
     This indicates and oops has already been printed.
  2) oops_in_progress > 1
     This guards against the rare case where panic() is invoked
     a second time, or in between oops_begin() and oops_end()

Signed-off-by: Jason Wessel 
Cc: Andi Kleen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

panic: don't print redundant backtraces on oops

2012-01-13T04:13:11+00:00

When an oops causes a panic and panic prints another backtrace it's pretty
common to have the original oops data be scrolled away on a 80x50 screen.

The second backtrace is quite redundant and not needed anyways.

So don't print the panic backtrace when oops_in_progress is true.

[akpm@linux-foundation.org: add comment]
Signed-off-by: Andi Kleen 
Cc: Michael Holzheu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kdump: fix crash_kexec()/smp_send_stop() race in panic()

2012-01-13T04:13:11+00:00

When two CPUs call panic at the same time there is a possible race
condition that can stop kdump.  The first CPU calls crash_kexec() and the
second CPU calls smp_send_stop() in panic() before crash_kexec() finished
on the first CPU.  So the second CPU stops the first CPU and therefore
kdump fails:

1st CPU:
  panic()->crash_kexec()->mutex_trylock(&kexec_mutex)-> do kdump

2nd CPU:
  panic()->crash_kexec()->kexec_mutex already held by 1st CPU
       ->smp_send_stop()-> stop 1st CPU (stop kdump)

This patch fixes the problem by introducing a spinlock in panic that
allows only one CPU to process crash_kexec() and the subsequent panic
code.

All other CPUs call the weak function panic_smp_self_stop() that stops the
CPU itself.  This function can be overloaded by architecture code.  For
example "tile" can use their lower-power "nap" instruction for that.

Signed-off-by: Michael Holzheu 
Acked-by: Chris Metcalf 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

treewide: remove useless NORET_TYPE macro and uses

2012-01-13T04:13:03+00:00

It's a very old and now unused prototype marking so just delete it.

Neaten panic pointer argument style to keep checkpatch quiet.

Signed-off-by: Joe Perches 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Haavard Skinnemoen 
Cc: Hans-Christian Egtvedt 
Cc: Tony Luck 
Cc: Fenghua Yu 
Acked-by: Geert Uytterhoeven 
Acked-by: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Chris Metcalf 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lockdep, bug: Exclude TAINT_OOT_MODULE from disabling lock debugging

2011-12-07T22:32:10+00:00

We do want to allow lock debugging for GPL-compatible modules
that are not (yet) built in-tree.  This was disabled as a
side-effect of commit 2449b8ba0745327c5fa49a8d9acffe03b2eded69
('module,bug: Add TAINT_OOT_MODULE flag for modules not built
in-tree').  Lock debug warnings now include taint flags, so
kernel developers should still be able to deflect warnings
caused by out-of-tree modules.

The TAINT_PROPRIETARY_MODULE flag for non-GPL-compatible modules
will still disable lock debugging.

Signed-off-by: Ben Hutchings 
Cc: Nick Bowler 
Cc: Greg KH 
Cc: Dave Jones 
Cc: Rusty Russell 
Cc: Randy Dunlap 
Cc: Debian kernel maintainers 
Cc: Peter Zijlstra 
Cc: Alan Cox 
Link: http://lkml.kernel.org/r/1323268258.18450.11.camel@deadeye
Signed-off-by: Ingo Molnar

lockdep, bug: Exclude TAINT_FIRMWARE_WORKAROUND from disabling lockdep

2011-12-06T07:16:47+00:00

It's unlikely that TAINT_FIRMWARE_WORKAROUND causes false
lockdep messages, so do not disable lockdep in that case.
We still want to keep lockdep disabled in the
TAINT_OOT_MODULE case:

  - bin-only modules can cause various instabilities in
    their and in unrelated kernel code

  - they are impossible to debug for kernel developers

  - they also typically do not have the copyright license
    permission to link to the GPL-ed lockdep code.

Suggested-by: Ben Hutchings 
Signed-off-by: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-xopopjjens57r0i13qnyh2yo@git.kernel.org
Signed-off-by: Ingo Molnar

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

2011-11-06T21:24:42+00:00

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: panic=-1 for immediate reboot

2011-07-26T23:49:45+00:00

When a kernel BUG or oops occurs, ChromeOS intends to panic and
immediately reboot, with stacktrace and other messages preserved in RAM
across reboot.

But the longer we delay, the more likely the user is to poweroff and
lose the info.

panic_timeout (seconds before rebooting) is set by panic= boot option or
sysctl or /proc/sys/kernel/panic; but 0 means wait forever, so at
present we have to delay at least 1 second.

Let a negative number mean reboot immediately (with the small cosmetic
benefit of suppressing that newline-less "Rebooting in %d seconds.."
message).

Signed-off-by: Hugh Dickins 
Signed-off-by: Mandeep Singh Baines 
Cc: Huang Ying 
Cc: Andi Kleen 
Cc: Hugh Dickins 
Cc: Olaf Hering 
Cc: Jesse Barnes 
Cc: Dave Airlie 
Cc: Greg Kroah-Hartman 
Cc: Alan Cox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

move x86 specific oops=panic to generic code

2011-03-23T00:44:11+00:00

The oops=panic cmdline option is not x86 specific, move it to generic code.
Update documentation.

Signed-off-by: Olaf Hering 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: "H. Peter Anvin" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support

2011-01-12T08:06:19+00:00

Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.

This patch adds POLL/IRQ/NMI notification types support.

Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.

Known issue:

- Error information can not be printed for recoverable errors notified
  via NMI, because printk is not NMI-safe. Will fix this via delay
  printing to IRQ context via irq_work or make printk NMI-safe.

v2:

- adjust printk format per comments.

Signed-off-by: Huang Ying 
Reviewed-by: Andi Kleen 
Signed-off-by: Len Brown