Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

From: Steven Rostedt <rostedt@goodmis.org>
To: Petr Mladek <pmladek@suse.com>
Cc: Tejun Heo <tj@kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	Cong Wang <xiyou.wangcong@gmail.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@kernel.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jan Kara <jack@suse.cz>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	rostedt@home.goodmis.org, Byungchul Park <byungchul.park@lge.com>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Pavel Machek <pavel@ucw.cz>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup
Date: Wed, 10 Jan 2018 13:54:51 -0500	[thread overview]
Message-ID: <20180110135451.4d74135b@vmware.local.home> (raw)
In-Reply-To: <20180110162900.GA21753@linux.suse>

On Wed, 10 Jan 2018 17:29:00 +0100
Petr Mladek <pmladek@suse.com> wrote:

> he next versions used lazy offload from console_unlock() when
> the thread spent there too much time. IMHO, this is one
> very promising solution. It guarantees that softlockup
> would never happen. But it tries hard to get the messages
> out immediately.
> 
> Unfortunately, it is very complicated. We have troubles to understand
> the concerns, for example see the long discussion about v3 at
> https://lkml.kernel.org/r/20170509082859.854-1-sergey.senozhatsky@gmail.com
> I admit that I did not have enough time to review this.
> 
> 
> Anyway, in October, 2017, Steven came up with a completely
> different approach (console owner/waiter transfer). It does
> not guarantee that the softlockup will not happen. But it
> does not suffer from the problem that blocked the obvious
> solution for years. It moves the owner at runtime, so
> it is guaranteed that the new owner would continue
> printing.

Yes, I believe my solution and the offloading solution are two agnostic
solutions, and they are not mutually exclusive. They both can be
applied. But mine shouldn't be controversial as it has no down sides
from the current printk solution.

After adding this one, if issues come up, we should have a better idea
of how to handle them, because I'm betting the issues will only come up
in some pretty unique scenarios. And they may even be solved without
having to touch printk (and hurt the get out ASAP requirement). I don't
want to paper over some real issues of those that use printk, with
printk work arounds.

-- Steve