From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754530AbcHaUPy (ORCPT ); Wed, 31 Aug 2016 16:15:54 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:48751 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752513AbcHaUPw (ORCPT ); Wed, 31 Aug 2016 16:15:52 -0400 Date: Wed, 31 Aug 2016 13:15:50 -0700 From: Andrew Morton To: Sergey Senozhatsky Cc: Sergey Senozhatsky , Petr Mladek , Jan Kara , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] printk/nmi: avoid direct printk()-s from __printk_nmi_flush() Message-Id: <20160831131550.b058472416e1f3219c52b726@linux-foundation.org> In-Reply-To: <20160831014441.GA472@swordfish> References: <20160830161354.581-1-sergey.senozhatsky@gmail.com> <20160830150315.93efc592aa631f474af760b5@linux-foundation.org> <20160831014441.GA472@swordfish> 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: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 31 Aug 2016 10:44:41 +0900 Sergey Senozhatsky wrote: > On (08/30/16 15:03), Andrew Morton wrote: > > > __printk_nmi_flush() can be called from nmi_panic(), therefore it has to > > > test whether it's executed in NMI context and thus must route the messages > > > through deferred printk() or via direct printk(). > > > > Why? What misbehaviour does the current code cause? > > the reasoning behind the `if in_nmi()' in print_nmi_seq_line() > > if (in_nmi()) > printk_deferred("%.*s", (end - start) + 1, buf); > else > printk("%.*s", (end - start) + 1, buf); > > was as follows (per Petr's commit message) OK, thanks, I altered the changelog thusly and scheduled the patch for 4.8: --- txt/printk-nmi-avoid-direct-printk-s-from-__printk_nmi_flush.txt +++ txt/printk-nmi-avoid-direct-printk-s-from-__printk_nmi_flush.txt @@ -3,8 +3,13 @@ __printk_nmi_flush() can be called from nmi_panic(), therefore it has to test whether it's executed in NMI context and thus must route the messages -through deferred printk() or via direct printk(). Except for two places -where __printk_nmi_flush() does unconditional direct printk() calls: +through deferred printk() or via direct printk(). This is to avoid +potential deadlocks, as described in cf9b1106c81c45cde ("printk/nmi: flush +NMI messages on the system panic"). + +However there remain two places where __printk_nmi_flush() does +unconditional direct printk() calls: + - pr_err("printk_nmi_flush: internal error ...") - pr_cont("\n")