From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Dec 2015 17:57:51 +0100 (CET) Received: from mx2.suse.de ([195.135.220.15]:36092 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S27013222AbbLDQ5tJJ8L6 (ORCPT ); Fri, 4 Dec 2015 17:57:49 +0100 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 3D303AAC1; Fri, 4 Dec 2015 16:57:46 +0000 (UTC) Date: Fri, 4 Dec 2015 17:57:44 +0100 From: Petr Mladek To: Jiri Kosina Cc: kbuild test robot , kbuild-all@01.org, Andrew Morton , Peter Zijlstra , Steven Rostedt , Russell King , Daniel Thompson , Ingo Molnar , Thomas Gleixner , linux-kernel@vger.kernel.org, x86@kernel.org, linux-arm-kernel@lists.infradead.org, adi-buildroot-devel@lists.sourceforge.net, linux-cris-kernel@axis.com, linux-mips@linux-mips.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, David Howells , Koichi Yasutake , linux-am33-list@redhat.com Subject: Re: [PATCH v2 1/5] printk/nmi: Generic solution for safe printk in NMI Message-ID: <20151204165744.GD20935@pathway.suse.cz> References: <1448622572-16900-2-git-send-email-pmladek@suse.com> <201511271919.aEZuZKNe%fengguang.wu@intel.com> <20151127153804.GC2648@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 50342 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pmladek@suse.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips On Wed 2015-12-02 00:24:49, Jiri Kosina wrote: > On Fri, 27 Nov 2015, Petr Mladek wrote: > > > MN10300 has its own implementation for entering and exiting NMI > > handlers. It does not call nmi_enter() and nmi_exit(). Please, find > > below an updated patch that adds printk_nmi_enter() and > > printk_nmi_exit() to the custom entry points. Then we could add HAVE_NMI > > to arch/mn10300/Kconfig and avoid the above warning. > > Hmm, so what exactly would go wrong if MN10300 (whatever that architecture > is) would call nmi_enter() and nmi_exit() at the places where it's > starting and finishing NMI handler? > > >From a cursory look, it seems like most (if not all) of the things called > from nmi_{enter,exit}() would be nops there anyway. Good point. Max mentioned in the other main that the NMI handler should follow the NMI ruler. I do not why it could not work. In fact, it might improve things, e.g. nmi_enter() blocks recursive NMIs. I think that it will move it into a separate patch, thought. Best Regards, Petr From mboxrd@z Thu Jan 1 00:00:00 1970 From: Petr Mladek Date: Fri, 04 Dec 2015 16:57:44 +0000 Subject: Re: [PATCH v2 1/5] printk/nmi: Generic solution for safe printk in NMI Message-Id: <20151204165744.GD20935@pathway.suse.cz> List-Id: References: <1448622572-16900-2-git-send-email-pmladek@suse.com> <201511271919.aEZuZKNe%fengguang.wu@intel.com> <20151127153804.GC2648@pathway.suse.cz> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org On Wed 2015-12-02 00:24:49, Jiri Kosina wrote: > On Fri, 27 Nov 2015, Petr Mladek wrote: > > > MN10300 has its own implementation for entering and exiting NMI > > handlers. It does not call nmi_enter() and nmi_exit(). Please, find > > below an updated patch that adds printk_nmi_enter() and > > printk_nmi_exit() to the custom entry points. Then we could add HAVE_NMI > > to arch/mn10300/Kconfig and avoid the above warning. > > Hmm, so what exactly would go wrong if MN10300 (whatever that architecture > is) would call nmi_enter() and nmi_exit() at the places where it's > starting and finishing NMI handler? > > >From a cursory look, it seems like most (if not all) of the things called > from nmi_{enter,exit}() would be nops there anyway. Good point. Max mentioned in the other main that the NMI handler should follow the NMI ruler. I do not why it could not work. In fact, it might improve things, e.g. nmi_enter() blocks recursive NMIs. I think that it will move it into a separate patch, thought. Best Regards, Petr From mboxrd@z Thu Jan 1 00:00:00 1970 From: pmladek@suse.com (Petr Mladek) Date: Fri, 4 Dec 2015 17:57:44 +0100 Subject: [PATCH v2 1/5] printk/nmi: Generic solution for safe printk in NMI In-Reply-To: References: <1448622572-16900-2-git-send-email-pmladek@suse.com> <201511271919.aEZuZKNe%fengguang.wu@intel.com> <20151127153804.GC2648@pathway.suse.cz> Message-ID: <20151204165744.GD20935@pathway.suse.cz> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed 2015-12-02 00:24:49, Jiri Kosina wrote: > On Fri, 27 Nov 2015, Petr Mladek wrote: > > > MN10300 has its own implementation for entering and exiting NMI > > handlers. It does not call nmi_enter() and nmi_exit(). Please, find > > below an updated patch that adds printk_nmi_enter() and > > printk_nmi_exit() to the custom entry points. Then we could add HAVE_NMI > > to arch/mn10300/Kconfig and avoid the above warning. > > Hmm, so what exactly would go wrong if MN10300 (whatever that architecture > is) would call nmi_enter() and nmi_exit() at the places where it's > starting and finishing NMI handler? > > >From a cursory look, it seems like most (if not all) of the things called > from nmi_{enter,exit}() would be nops there anyway. Good point. Max mentioned in the other main that the NMI handler should follow the NMI ruler. I do not why it could not work. In fact, it might improve things, e.g. nmi_enter() blocks recursive NMIs. I think that it will move it into a separate patch, thought. Best Regards, Petr