From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755749AbcHWMTK (ORCPT ); Tue, 23 Aug 2016 08:19:10 -0400 Received: from mx2.suse.de ([195.135.220.15]:50990 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751621AbcHWMTI (ORCPT ); Tue, 23 Aug 2016 08:19:08 -0400 Date: Tue, 23 Aug 2016 14:19:03 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: Jan Kara , Sergey Senozhatsky , Viresh Kumar , Andrew Morton , Jan Kara , Tejun Heo , Tetsuo Handa , "linux-kernel@vger.kernel.org" , Byungchul Park , vlevenetz@mm-sol.com, Greg Kroah-Hartman Subject: Re: [PATCH v10 1/2] printk: Make printk() completely async Message-ID: <20160823121903.GD4866@pathway.suse.cz> References: <20160812094447.GD7339@pathway.suse.cz> <20160818022712.GB500@swordfish> <20160818093329.GL13300@pathway.suse.cz> <20160818095144.GA425@swordfish> <20160818105629.GE26194@pathway.suse.cz> <20160819063236.GA584@swordfish> <20160819095455.GR13300@pathway.suse.cz> <20160819190007.GA8275@quack2.suse.cz> <20160820052430.GA695@swordfish> <20160822041520.GA511@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160822041520.GA511@swordfish> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 2016-08-22 13:15:20, Sergey Senozhatsky wrote: > Hello, > > On (08/20/16 14:24), Sergey Senozhatsky wrote: > > On (08/19/16 21:00), Jan Kara wrote: > > > > > depending on .config BUG() may never return back -- passing control > > > > > to do_exit(), so printk_deferred_exit() won't be executed. thus we > > > > > probably need to have a per-cpu variable that would indicate that > > > > > we are in deferred_bug. hm... but do we really need deferred BUG() > > > > > in the first place? > > > > > > > > Good question. I am not aware of any BUG_ON() that would be called from > > > > wake_up_process() but it is hard to check everything. > > > > > > > > A conservative approach would be to force synchronous printk from > > > > BUG_ON(). > > > > > > Just a quick thought: Cannot we just do printk_deferred_enter() when we are > > > about to call into the scheduler from printk code and printk_deferred_exit() > > > when leaving it? That would look like the least error-prone way how > > > handling this kind of recursion... > > > > interesting idea. > > printk_deferred_enter() increments preempt count, so there may be additional > > obstacles and, as a result, ad-hocs, that scheduler people will sincerely hate. > > need to think more. > > the other thing I just thought of is doing something as follows > !!!not tested, will not compile, just an idea!!! > > --- > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > index 6e260a0..bb8d719 100644 > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -1789,6 +1789,7 @@ asmlinkage int vprintk_emit(int facility, int level, > printk_delay(); > > local_irq_save(flags); > + printk_nmi_enter(); > this_cpu = smp_processor_id(); Huh, this looks very interesting but I am afraid that it will not fly. The problem is that vprintk_nmi() is safe only when it is used exclusively in NMI. The following could happen with your code: /**** normar context ****/ vprintk_emit() printk_nmi_enter() ... wake_up_process() WARN() printk() vprintk_nmi() vsnprintf(..., "0123456789") /* real NMI comes after writing "01234" */ /**** NMI context ****/ vprintk_nmi(); vsnprintf(..., "abcdefghijklmno"); /**** normal context ****/ /* we finish writing "56789" into the buffer */ => part of the message from NMI gets broken "abcde56789klmno". The lockless handling of the NMI per-CPU buffer already is not trivial. I would be afraid to add more hacks to make it writable in all contexts. I am sorry about the bad news. This was so promising on the first look. Best Regards, Petr