> 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. > <snip obvious use case> > > > 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
