[4.2.y-ckt stable] Patch "panic: release stale console lock to always get the logbuf printed out" has been added to the 4.2.y-ckt tree

[Kamal Mostafa]

This is a note to let you know that I have just added a patch titled

    panic: release stale console lock to always get the logbuf printed out

to the linux-4.2.y-queue branch of the 4.2.y-ckt extended stable tree 
which can be found at:

    http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-4.2.y-queue

This patch is scheduled to be released in version 4.2.8-ckt3.

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 4.2.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Kamal

---8<------------------------------------------------------------

>From 2716163dfb10b763b0c65c502eb893d652ba6b2f Mon Sep 17 00:00:00 2001
From: Vitaly Kuznetsov <vkuznets at redhat.com>
Date: Fri, 6 Nov 2015 16:32:58 -0800
Subject: panic: release stale console lock to always get the logbuf printed
 out

commit 08d78658f393fefaa2e6507ea052c6f8ef4002a2 upstream.

In some cases we may end up killing the CPU holding the console lock
while still having valuable data in logbuf. E.g. I'm observing the
following:

- A crash is happening on one CPU and console_unlock() is being called on
  some other.

- console_unlock() tries to print out the buffer before releasing the lock
  and on slow console it takes time.

- in the meanwhile crashing CPU does lots of printk()-s with valuable data
  (which go to the logbuf) and sends IPIs to all other CPUs.

- console_unlock() finishes printing previous chunk and enables interrupts
  before trying to print out the rest, the CPU catches the IPI and never
  releases console lock.

This is not the only possible case: in VT/fb subsystems we have many other
console_lock()/console_unlock() users.  Non-masked interrupts (or
receiving NMI in case of extreme slowness) will have the same result.
Getting the whole console buffer printed out on crash should be top
priority.

[akpm at linux-foundation.org: tweak comment text]
Signed-off-by: Vitaly Kuznetsov <vkuznets at redhat.com>
Cc: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com>
Cc: Jiri Kosina <jkosina at suse.cz>
Cc: Baoquan He <bhe at redhat.com>
Cc: Prarit Bhargava <prarit at redhat.com>
Cc: Xie XiuQi <xiexiuqi at huawei.com>
Cc: Seth Jennings <sjenning at redhat.com>
Cc: "K. Y. Srinivasan" <kys at microsoft.com>
Cc: Jan Kara <jack at suse.cz>
Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
[ kamal: 4.2-stable prereq for
  8d91f8b printk: do cond_resched() between lines while outputting to consoles ]
Signed-off-by: Kamal Mostafa <kamal at canonical.com>
---
 kernel/panic.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/kernel/panic.c b/kernel/panic.c
index 04e91ff..4579dbb 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -23,6 +23,7 @@
 #include <linux/sysrq.h>
 #include <linux/init.h>
 #include <linux/nmi.h>
+#include <linux/console.h>

 #define PANIC_TIMER_STEP 100
 #define PANIC_BLINK_SPD 18
@@ -147,6 +148,15 @@ void panic(const char *fmt, ...)

 	bust_spinlocks(0);

+	/*
+	 * We may have ended up stopping the CPU holding the lock (in
+	 * smp_send_stop()) while still having some valuable data in the console
+	 * buffer.  Try to acquire the lock then release it regardless of the
+	 * result.  The release will also print the buffers out.
+	 */
+	console_trylock();
+	console_unlock();
+
 	if (!panic_blink)
 		panic_blink = no_blink;

--
1.9.1