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 S1752905AbbE0XO1 (ORCPT <rfc822;w@1wt.eu>);
	Wed, 27 May 2015 19:14:27 -0400
Received: from mail.linuxfoundation.org ([140.211.169.12]:58641 "EHLO
	mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752159AbbE0XOZ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 May 2015 19:14:25 -0400
Date: Wed, 27 May 2015 16:14:23 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Petr Mladek <pmladek@suse.cz>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Dave Anderson <anderson@redhat.com>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Kay Sievers <kay@vrfy.org>, Jiri Kosina <jkosina@suse.cz>,
        Michal Hocko <mhocko@suse.cz>, Jan Kara <jack@suse.cz>,
        linux-kernel@vger.kernel.org, Wang Long <long.wanglong@huawei.com>,
        peifeiyue@huawei.com, dzickus@redhat.com, morgan.wang@huawei.com,
        sasha.levin@oracle.com
Subject: Re: [PATCH 04/10] printk: Merge and flush NMI buffer predictably
 via IRQ work
Message-Id: <20150527161423.9ca10028e4edf4ecbd28a533@linux-foundation.org>
In-Reply-To: <1432557993-20458-5-git-send-email-pmladek@suse.cz>
References: <1432557993-20458-1-git-send-email-pmladek@suse.cz>
	<1432557993-20458-5-git-send-email-pmladek@suse.cz>
X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 25 May 2015 14:46:27 +0200 Petr Mladek <pmladek@suse.cz> wrote:

> It might take ages until users see messages from NMI context. They cannot
> be flushed to the console because the operation involves taking and
> releasing a bunch of locks. Everything gets fixed by the followup printk
> in normal context but it is not predictable.
> 
> The same problem has printk_sched() and this patch reuses the existing
> solution.
> 
> There is no special printk() variant for NMI context. Hence the IRQ work
> need to get queued from vprintk_emit().
> 
> ...
>
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1554,9 +1554,6 @@ int printk_deferred(const char *fmt, ...)
>  	va_start(args, fmt);
>  	r = vprintk_emit(0, LOGLEVEL_SCHED, NULL, 0, fmt, args);
>  	va_end(args);
> -
> -	__this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
> -	irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
>  	preempt_enable();
>  
>  	return r;
> @@ -1880,7 +1877,10 @@ asmlinkage int vprintk_emit(int facility, int level,
>  	 * If called from the scheduler or NMI context, we can not get console
>  	 * without a possible deadlock.
>  	 */
> -	if (!in_sched && !in_nmi()) {
> +	if (in_sched || in_nmi()) {
> +		__this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
> +		irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
> +	} else {

This looks hairy.  Why irq_work_queue() OK to call from NMI? 
arch/arm64/kernel/smp.c uses smp_cross_call() which might use NMI! 
Presumably it'll call directly if the target CPU==this_cpu but I didn't
run around and audit everything.