diff mbox series

request for 4.14-stable: fd5f7cde1b85 ("printk: Never set console_may_schedule in console_trylock()")

Message ID 20181111202045.vocb3dthuquf7h2y@debian (mailing list archive)
State New, archived
Headers show
Series request for 4.14-stable: fd5f7cde1b85 ("printk: Never set console_may_schedule in console_trylock()") | expand

Commit Message

Sudip Mukherjee Nov. 11, 2018, 8:20 p.m. UTC
Hi Greg,

This was not marked for stable but seems it should be in stable.
Please apply to your queue of 4.14-stable.

--
Regards
Sudip

Comments

Greg Kroah-Hartman Nov. 19, 2018, 3:18 p.m. UTC | #1
On Sun, Nov 11, 2018 at 08:20:45PM +0000, Sudip Mukherjee wrote:
> Hi Greg,
> 
> This was not marked for stable but seems it should be in stable.
> Please apply to your queue of 4.14-stable.

Now queued up, thanks.

greg k-h
Sergey Senozhatsky Nov. 20, 2018, 2:23 a.m. UTC | #2
On (11/19/18 16:18), Greg Kroah-Hartman wrote:
> On Sun, Nov 11, 2018 at 08:20:45PM +0000, Sudip Mukherjee wrote:
> > Hi Greg,
> > 
> > This was not marked for stable but seems it should be in stable.
> > Please apply to your queue of 4.14-stable.
> 
> Now queued up, thanks.

Very sorry for the late reply!

Greg, Sudip, the commit in question is known to be controversial. It
does fix some lockups, but it also does make printk non-atomic in some
cases: the printing task can get preempted which can cause printk
stalls (no messages on serial consoles, until the printing task gets
rescheduled again) in some dark-corner cases.

I think Tetsuo is the only person who ever reported printk stalls,
probably because he is the only person who is testing very tough
OOM-scenarios on a regular basis.

So, long story short, I call that commit "a mistake" and we have
reverted it upstream, to make printk always atomic (just like it
should be).

As of printk lockups, Steven Rostedt has contributed a much better
solution.

	-ss
Sergey Senozhatsky Nov. 20, 2018, 2:28 a.m. UTC | #3
On (11/20/18 11:23), Sergey Senozhatsky wrote:
> On (11/19/18 16:18), Greg Kroah-Hartman wrote:
> > On Sun, Nov 11, 2018 at 08:20:45PM +0000, Sudip Mukherjee wrote:
> > > Hi Greg,
> > > 
> > > This was not marked for stable but seems it should be in stable.
> > > Please apply to your queue of 4.14-stable.
> > 
> > Now queued up, thanks.
> 
> Very sorry for the late reply!
> 
> Greg, Sudip, the commit in question is known to be controversial

Yikes!! PLEASE *IGNORE MY PREVIOUS EMAIL*!


This is a *totally stupid* situation. I, somehow, got completely confused
and looked at the wrong commit ID.

Really sorry!

Yes, backporting fd5f7cde1b85 for stable is OK, no real objections.

	-ss
Greg Kroah-Hartman Nov. 20, 2018, 7:42 a.m. UTC | #4
On Tue, Nov 20, 2018 at 11:28:41AM +0900, Sergey Senozhatsky wrote:
> On (11/20/18 11:23), Sergey Senozhatsky wrote:
> > On (11/19/18 16:18), Greg Kroah-Hartman wrote:
> > > On Sun, Nov 11, 2018 at 08:20:45PM +0000, Sudip Mukherjee wrote:
> > > > Hi Greg,
> > > > 
> > > > This was not marked for stable but seems it should be in stable.
> > > > Please apply to your queue of 4.14-stable.
> > > 
> > > Now queued up, thanks.
> > 
> > Very sorry for the late reply!
> > 
> > Greg, Sudip, the commit in question is known to be controversial
> 
> Yikes!! PLEASE *IGNORE MY PREVIOUS EMAIL*!
> 
> 
> This is a *totally stupid* situation. I, somehow, got completely confused
> and looked at the wrong commit ID.
> 
> Really sorry!

No worries, email is now ignored :)

greg k-h
diff mbox series

Patch

From 2fee30107ea1c06f0b09f5ba4132ea4393454212 Mon Sep 17 00:00:00 2001
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Date: Tue, 16 Jan 2018 13:47:16 +0900
Subject: [PATCH] printk: Never set console_may_schedule in console_trylock()

commit fd5f7cde1b85d4c8e09ca46ce948e008a2377f64 upstream

This patch, basically, reverts commit 6b97a20d3a79 ("printk:
set may_schedule for some of console_trylock() callers").
That commit was a mistake, it introduced a big dependency
on the scheduler, by enabling preemption under console_sem
in printk()->console_unlock() path, which is rather too
critical. The patch did not significantly reduce the
possibilities of printk() lockups, but made it possible to
stall printk(), as has been reported by Tetsuo Handa [1].

Another issues is that preemption under console_sem also
messes up with Steven Rostedt's hand off scheme, by making
it possible to sleep with console_sem both in console_unlock()
and in vprintk_emit(), after acquiring the console_sem
ownership (anywhere between printk_safe_exit_irqrestore() in
console_trylock_spinning() and printk_safe_enter_irqsave()
in console_unlock()). This makes hand off less likely and,
at the same time, may result in a significant amount of
pending logbuf messages. Preempted console_sem owner makes
it impossible for other CPUs to emit logbuf messages, but
does not make it impossible for other CPUs to append new
messages to the logbuf.

Reinstate the old behavior and make printk() non-preemptible.
Should any printk() lockup reports arrive they must be handled
in a different way.

[1] http://lkml.kernel.org/r/201603022101.CAH73907.OVOOMFHFFtQJSL%20()%20I-love%20!%20SAKURA%20!%20ne%20!%20jp
Fixes: 6b97a20d3a79 ("printk: set may_schedule for some of console_trylock() callers")
Link: http://lkml.kernel.org/r/20180116044716.GE6607@jagdpanzerIV
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: akpm@linux-foundation.org
Cc: linux-mm@kvack.org
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Byungchul Park <byungchul.park@lge.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
---
 kernel/printk/printk.c | 22 ++++++++--------------
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 7161312593dd..a9cf2e15f6a3 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1763,12 +1763,19 @@  asmlinkage int vprintk_emit(int facility, int level,
 	/* If called from the scheduler, we can not call up(). */
 	if (!in_sched) {
 		/*
+		 * Disable preemption to avoid being preempted while holding
+		 * console_sem which would prevent anyone from printing to
+		 * console
+		 */
+		preempt_disable();
+		/*
 		 * Try to acquire and then immediately release the console
 		 * semaphore.  The release will print out buffers and wake up
 		 * /dev/kmsg and syslog() users.
 		 */
 		if (console_trylock())
 			console_unlock();
+		preempt_enable();
 	}
 
 	return printed_len;
@@ -2083,20 +2090,7 @@  int console_trylock(void)
 		return 0;
 	}
 	console_locked = 1;
-	/*
-	 * When PREEMPT_COUNT disabled we can't reliably detect if it's
-	 * safe to schedule (e.g. calling printk while holding a spin_lock),
-	 * because preempt_disable()/preempt_enable() are just barriers there
-	 * and preempt_count() is always 0.
-	 *
-	 * RCU read sections have a separate preemption counter when
-	 * PREEMPT_RCU enabled thus we must take extra care and check
-	 * rcu_preempt_depth(), otherwise RCU read sections modify
-	 * preempt_count().
-	 */
-	console_may_schedule = !oops_in_progress &&
-			preemptible() &&
-			!rcu_preempt_depth();
+	console_may_schedule = 0;
 	return 1;
 }
 EXPORT_SYMBOL(console_trylock);
-- 
2.11.0