user/sven/linux.git/kernel/panic.c, branch v3.4.70

panic: fix a possible deadlock in panic()

2013-04-12T16:38:47Z

commit 190320c3b6640d4104650f55ff69611e050ea06b upstream. panic_lock is meant to ensure that panic processing takes place only on one cpu; if any of the other cpus encounter a panic, they will spin waiting to be shut down. However, this causes a regression in this scenario: 1. Cpu 0 encounters a panic and acquires the panic_lock and proceeds with the panic processing. 2. There is an interrupt on cpu 0 that also encounters an error condition and invokes panic. 3. This second invocation fails to acquire the panic_lock and enters the infinite while loop in panic_smp_self_stop. Thus all panic processing is stopped, and the cpu is stuck for eternity in the while(1) inside panic_smp_self_stop. To address this, disable local interrupts with local_irq_disable before acquiring the panic_lock. This will prevent interrupt handlers from executing during the panic processing, thus avoiding this particular problem. Signed-off-by: Vikram Mulukutla Reviewed-by: Stephen Boyd Cc: Michael Holzheu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Paul Gortmaker Signed-off-by: Greg Kroah-Hartman

kdump: Execute kmsg_dump(KMSG_DUMP_PANIC) after smp_send_stop()

2012-06-22T18:36:56Z

commit 62be73eafaa045d3233337303fb140f7f8a61135 upstream. This patch moves kmsg_dump(KMSG_DUMP_PANIC) below smp_send_stop(), to serialize the crash-logging process via smp_send_stop() and to thus retrieve a more stable crash image of all CPUs stopped. Signed-off-by: Seiji Aguchi Acked-by: Don Zickus Cc: dle-develop@lists.sourceforge.net Cc: Satoru Moriya Cc: Tony Luck Cc: a.p.zijlstra@chello.nl Link: http://lkml.kernel.org/r/5C4C569E8A4B9B42A84A977CF070A35B2E4D7A5CE2@USINDEVS01.corp.hds.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

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

2012-04-12T20:12:12Z

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 Cc: [3.3+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

panic: don't print redundant backtraces on oops

2012-01-13T04:13:11Z

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:11Z

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:03Z

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:10Z

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:47Z

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

2011-07-26T23:49:45Z

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