From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752403AbbJEJVK (ORCPT ); Mon, 5 Oct 2015 05:21:10 -0400 Received: from mail7.hitachi.co.jp ([133.145.228.42]:42301 "EHLO mail7.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752030AbbJEJVI (ORCPT ); Mon, 5 Oct 2015 05:21:08 -0400 From: =?utf-8?B?5rKz5ZCI6Iux5a6PIC8gS0FXQUnvvIxISURFSElSTw==?= To: "'Borislav Petkov'" CC: "'Peter Zijlstra'" , Jonathan Corbet , Ingo Molnar , "Eric W. Biederman" , "H. Peter Anvin" , Andrew Morton , Thomas Gleixner , Vivek Goyal , "linux-doc@vger.kernel.org" , "x86@kernel.org" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Michal Hocko , Ingo Molnar , =?utf-8?B?5bmz5p2+6ZuF5bezIC8gSElSQU1BVFXvvIxNQVNBTUk=?= Subject: RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option Thread-Topic: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option Thread-Index: AQHQ94oh6MYtIS0XDEWuNE+WtK4xp55UZ/AAgAGEPrD//7JggIAAnR0g//+I5YCAAK/fMP//dpIAAC+EULD//+ALgP/7JpJQgAmbhQD//2DHAA== Date: Mon, 5 Oct 2015 09:21:02 +0000 Message-ID: <04EAB7311EE43145B2D3536183D1A844549A48D3@GSjpTKYDCembx31.service.hitachi.net> References: <20150930115548.GI2881@worktop.programming.kicks-ass.net> <04EAB7311EE43145B2D3536183D1A8445499CD11@GSjpTKYDCembx31.service.hitachi.net> <20151001062733.GL2881@worktop.programming.kicks-ass.net> <04EAB7311EE43145B2D3536183D1A8445499D30D@GSjpTKYDCembx31.service.hitachi.net> <20151001084335.GA3764@pd.tnic> <04EAB7311EE43145B2D3536183D1A8445499DB92@GSjpTKYDCembx31.service.hitachi.net> <20151001110110.GA3544@pd.tnic> <04EAB7311EE43145B2D3536183D1A8445499ED83@GSjpTKYDCembx31.service.hitachi.net> <20151002074721.GA16538@pd.tnic> <04EAB7311EE43145B2D3536183D1A844549A4557@GSjpTKYDCembx31.service.hitachi.net> <20151005082704.GA23259@nazgul.tnic> In-Reply-To: <20151005082704.GA23259@nazgul.tnic> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.198.219.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id t959LFos005786 > On Mon, Oct 05, 2015 at 02:03:58AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote: > > That's different from my point of view. I'm not going to pass > > some data from the first kernel to the second kernel. I'm just going to > > provide a configurable option for the second kernel to users. > > Dude, WTF?! You're adding a kernel command line which is supposed to > be used *only* by the kdump kernel. But nooo, it is there in the open > and visible to people. And anyone can type it in during boot. AND THAT > SHOULDN'T BE POSSIBLE IN THE FIRST PLACE! > > This information is strictly for the kdump kernel - it shouldn't be a > generic command line option. How hard it is to understand that simple > fact?! So, the problem for you is that "noextnmi" option is visible and effective in the first kernel, isn't it? If so, we can ignore "noextnmi" option if we are in the first kernel and remove it from the documentation. "elfcorehdr" cmdline option prepared by kexec command is passed to only the second kernel, and it is also used to check if the booted kernel is a kdump kernel. Thus, if "elfcorehdr" is NOT specified, then ignore "noextnmi". Documentation/kernel-parameters.txt: > elfcorehdr=[size[KMG]@]offset[KMG] [IA64,PPC,SH,X86,S390] > Specifies physical address of start of kernel core > image elf header and optionally the size. Generally > kexec loader will pass this option to capture kernel. > See Documentation/kdump/kdump.txt for details. > > > > I think we should use the ELF header only if the passed information > > is saved to a crash dump. > > So what?! ELF header will contain the additional bit of information that > the second kernel wasn't reacting to NMIs. But that's fine, that *is* > the desired behavior anyway. > > All I'm saying is, this is a strict kdump kernel "command", so to speak, > and it doesn't belong with the generic kernel command line parameters. Regards, Hidehiro Kawai Hitachi, Ltd. Research & Development Group {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I