Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756098AbbFBJtE (ORCPT ); Tue, 2 Jun 2015 05:49:04 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:13181 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753893AbbFBJsy (ORCPT ); Tue, 2 Jun 2015 05:48:54 -0400 Message-ID: <556D7B74.2070007@huawei.com> Date: Tue, 2 Jun 2015 17:46:28 +0800 From: "long.wanglong" User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Jan Kara CC: Andrew Morton , Petr Mladek , Frederic Weisbecker , Steven Rostedt , Dave Anderson , "Paul E. McKenney" , Kay Sievers , "Jiri Kosina" , Michal Hocko , , , , , , Subject: Re: [PATCH 00/10] printk: Avoid deadlock in NMI + vprintk_emit() cleanup References: <1432557993-20458-1-git-send-email-pmladek@suse.cz> <20150529135045.09d87c7ab98bf26dec95c8b3@linux-foundation.org> <20150601130616.GE20288@quack.suse.cz> In-Reply-To: <20150601130616.GE20288@quack.suse.cz> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.88.174] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1958 Lines: 47 On 2015/6/1 21:06, Jan Kara wrote: > On Fri 29-05-15 13:50:45, Andrew Morton wrote: >> On Mon, 25 May 2015 14:46:23 +0200 Petr Mladek wrote: >> >>> The main source of deadlocks caused by printk() in NMI context has been >>> solved by the commit a9edc88093287 ("x86/nmi: Perform a safe NMI stack >>> trace on all CPUs"). >>> >>> But there are still few warnings printed in the NMI code that could >>> case a deadlock. For example, see the freeze discussed at >>> https://lkml.org/lkml/2015/5/20/481 >> >> I'm not (yet) convinced that we want the entire patchset btw. Do we >> really want to try to semi-support printk from NMI? With a rather >> nasty set of hacks? >> >> Why not just delete the offending printks? > And what about WARN_ONs and BUG_ONs? Delete as well? Or just don't print > anything when we are in NMI? I agree that NMI is so problematic context > that restricting printk there makes some sence. OTOH propagating > information from NMI to user is useful as well so I'm somewhat undecided. > > Honza > I think that delete all printks in NMI context is not a good solution. because some information is very useful to user. The commit a9edc88093287 ("x86/nmi: Perform a safe NMI stack trace on all CPUs") solved the deadlock problem only in arch_trigger_all_cpu_backtrace_handler() by replacing the printk to a special print function (nmi_vprintk). But all the other NMI handlers still use the original printk. How about replacing printk function earlier? we can replace printk function before we calling default_do_nmi(arch/x86/kernel/nmi.c) and replace back after calling. Is it a feasible solution? or does it introduce other problems? Best Regards Wang Long -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/