From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757243AbcHWNtR (ORCPT ); Tue, 23 Aug 2016 09:49:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:38928 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753533AbcHWNtP (ORCPT ); Tue, 23 Aug 2016 09:49:15 -0400 Date: Tue, 23 Aug 2016 15:48:47 +0200 From: Petr Mladek To: Jan Kara Cc: Sergey Senozhatsky , Viresh Kumar , Andrew Morton , Sergey Senozhatsky , 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: <20160823134847.GF4866@pathway.suse.cz> References: <20160406082758.GA3554@quack.suse.cz> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160819190007.GA8275@quack2.suse.cz> 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 Fri 2016-08-19 21:00:07, Jan Kara wrote: > On Fri 19-08-16 11:54:55, Petr Mladek wrote: > > On Fri 2016-08-19 15:32:36, Sergey Senozhatsky wrote: > > > On (08/18/16 12:56), Petr Mladek wrote: > > > > The advantage of the printk_func trick is that it is transparent. > > > > You do not need to modify any existing functions used by WARN()/BUG() > > > > macros. > > > > > > good point. > > > > > > so something like below, perhaps. I'm less sure about > > > deferred BUG()/BUG_ON(): > > > > > > #define DEFERRED_BUG() do { \ > > > printk_deferred_enter(); \ > > > BUG(); \ > > > printk_deferred_exit(); \ > > > } while (0) \ > > > > > > #define DEFERRED_BUG_ON(condition) do { \ > > > printk_deferred_enter(); \ > > > BUG_ON(condition); \ > > > printk_deferred_exit(); \ > > > } while (0) > > > > > > 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... > > OTOH there's also the other possible direction for the recursion when we > are in the scheduler, holding some scheduler locks, decide to WARN which > enters printk, that ends up calling wake_up_process() which deadlocks > on scheduler locks... I don't see how to handle this type of recursion > inside the printk code itself easily and so far the answer was - use > printk_deferred() in the scheduler and don't use WARN... > > Hum, maybe we could add lockdep annotation to a WARN_ON and BUG_ON macros so > that it would grab and release console_sem (even if the condition is false). > That way we'd get lockdep splats for all the possible WARN_ON and BUG_ON > calls that could deadlock. The idea is interesting but I think that we do not want the fake grab/release of the console_sem. We use console_trylock() in vprintk_emit(). Please note the "try" variant. So it is safe to call a nested printk() from the console code. IMHO, we want to avoid calling console from the scheduler code because: 1. console is slow and we do not want to block the scheduler. 2. console_unlock() calls wake_up_process() and we do not want a deadlock by the scheduler locks. Therefore I think that we want to detect something specific from the scheduler that is also reachable from WARN()/printk(). Best Regards, Petr PS: My brain rotated several times this day around these problems. I hope that my opinion still makes some sense :-)