From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751130AbdAPPoS (ORCPT <rfc822;w@1wt.eu>);
        Mon, 16 Jan 2017 10:44:18 -0500
Received: from mail-pf0-f194.google.com ([209.85.192.194]:33095 "EHLO
        mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750863AbdAPPoQ (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 16 Jan 2017 10:44:16 -0500
Date: Tue, 17 Jan 2017 00:43:43 +0900
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>,
        Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
        Steven Rostedt <rostedt@goodmis.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jslaby@suse.cz>, linux-fbdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] printk: Correctly handle preemption in console_unlock()
Message-ID: <20170116154343.GD23242@tigerII.localdomain>
References: <1484313321-17196-1-git-send-email-pmladek@suse.com>
 <20170114062825.GB699@tigerII.localdomain>
 <20170116113834.GF20462@pathway.suse.cz>
 <20170116115844.GA405@tigerII.localdomain>
 <20170116124822.GR14894@pathway.suse.cz>
 <20170116132633.GA23242@tigerII.localdomain>
 <20170116141455.GT14894@pathway.suse.cz>
 <20170116151941.GC23242@tigerII.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170116151941.GC23242@tigerII.localdomain>
User-Agent: Mutt/1.7.2 (2016-11-26)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On (01/17/17 00:19), Sergey Senozhatsky wrote:
[..]
> > I am confused by the sentence.
> > 
> > If it is a synchronous mode then console_trylock()/console_unlock() must
> > be called directly from printk()/vprintk_emit().
> > 
> > If you move this to a deferred callback, it is not longer synchronous.
> 
> yes, everything is about to move to the deferred printk() handler.
> it has been discussed during the LPC/KS session. Linus proposed it,
> to be exact. and I was quite sure that everyone in the room,
> including you, agreed. we either do everything asking scheduled for
> help (wake_up()), which is async printk. or do the print out from
> deferred printk() handler /** 1) in case of panic() there is a
> console_flush_on_panic() call. 2) once the system stores at least
> one EMERG loglevel message, we don't wake_up() printk_kthread from
> deferred printk handler.  **/

gosh.. sorry. I need some rest. badly. the above is not completely
accurate. "make printk always behave like printk deferred" was in
my presentation and proposal. the difference was in EMERG loglevel
handling. Linus suggested to handle it in deferred printk handler
as well, while I initially wanted to handle EMERG messages in
vprintk_emit() as a special case/exception. but I like the idea of
doing everything in printk deferred handler better. printk is moving
there anyway. otherwise there is no way of resolving printk deadlocks
on "external" locks.

	-ss