Re: [RFC PATCH 00/11] printk: safe printing in NMI context

From: Jiri Kosina <jkosina@suse.cz>
To: Jan Kara <jack@suse.cz>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	Petr Mladek <pmladek@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Dave Anderson <anderson@redhat.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Kay Sievers <kay@vrfy.org>, Michal Hocko <mhocko@suse.cz>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 00/11] printk: safe printing in NMI context
Date: Fri, 30 May 2014 12:10:06 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LNX.2.00.1405301207310.9080@pobox.suse.cz> (raw)
In-Reply-To: <20140530081328.GA2419@quack.suse.cz>

On Fri, 30 May 2014, Jan Kara wrote:

> >  Documentation/kernel-parameters.txt |   19 +-
> >  kernel/printk/printk.c              | 1218 +++++++++++++++++++++++++----------
> >  2 files changed, 878 insertions(+), 359 deletions(-)
> > 
> > 
> > Your patches look clean and pretty nice actually. They must be seriously
> > considered if we want to keep the current locked ring buffer design and
> > extend it to multiple per context buffers. But I wonder if it's worth to
> > continue that way with the printk ancient design.
> > 
> > If it takes more than 1000 line changes (including 500 added) to make it
> > finally work correctly with NMIs by working around its fundamental flaws,
> > shouldn't we rather redesign it to use a lockless ring buffer like ftrace
> > or perf ones?
>   I agree that lockless ringbuffer would be a more elegant solution but a
> much more intrusive one and complex as well. Petr's patch set basically
> leaves ordinary printk path intact to avoid concerns about regressions
> there.

Fully agreed, vast majority of the changes done by the patchset are on the 
unlikely in-NMI path, leaving normal printk operation as-is.

-- 
Jiri Kosina
SUSE Labs