From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from out02.mta.xmission.com ([166.70.13.232]) by canuck.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1PWXnF-00036E-Mt for kexec@lists.infradead.org; Sat, 25 Dec 2010 17:20:34 +0000 From: ebiederm@xmission.com (Eric W. Biederman) References: <5C4C569E8A4B9B42A84A977CF070A35B2C132F68FC@USINDEVS01.corp.hds.com> <20101223091851.GC30055@liondog.tnic> <5C4C569E8A4B9B42A84A977CF070A35B2C132F6BB0@USINDEVS01.corp.hds.com> <5C4C569E8A4B9B42A84A977CF070A35B2C132F6CFA@USINDEVS01.corp.hds.com> Date: Sat, 25 Dec 2010 09:19:54 -0800 In-Reply-To: <5C4C569E8A4B9B42A84A977CF070A35B2C132F6CFA@USINDEVS01.corp.hds.com> (Seiji Aguchi's message of "Sat, 25 Dec 2010 09:56:50 -0500") Message-ID: MIME-Version: 1.0 Subject: Re: [RFC][PATCH] Add a sysctl option controlling kexec when MCE occurred List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kexec-bounces@lists.infradead.org Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Seiji Aguchi Cc: "hawk@comx.dk" , "kexec@lists.infradead.org" , "drosenberg@vsecurity.com" , "dle-develop@lists.sourceforge.net" , "linux-mm@kvack.org" , "rdunlap@xenotime.net" , Andi Kleen , "hpa@zytor.com" , "akpm@linuxfoundation.org" , "ext-andriy.shevchenko@nokia.com" , "eric.dumazet@gmail.com" , "x86@kernel.org" , "opurdila@ixiacom.com" , "mingo@redhat.com" , "ying.huang@intel.com" , "kees.cook@canonical.com" , "paulmck@linux.vnet.ibm.com" , "dzickus@redhat.com" , "len.brown@intel.com" , "seto.hidetoshi@jp.fujitsu.com" , "hadi@cyberus.ca" , Borislav Petkov , "tglx@linutronix.de" , "hidave.darkstar@gmail.com" , "eugeneteo@kernel.org" , "gregkh@suse.de" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Satoru Moriya , "tj@kernel.org" , "davem@davemloft.net" Seiji Aguchi writes: > Hi, > > Thank you for giving your comments. > >>So what is the problem you are trying to avoid, and why can't we do >>something in the kernels initialization path to avoid initializing >>when there is a problem? > > Kdump gets a dump disk identifier based on information from memory. > > So, kdump may receive wrong identifier when it starts after MCE > occurred, because MCE is reported by memory, cache, and TLB errors > > In the worst case, kdump will overwrite user data if it recognizes a > disk saving user data as a dump disk. Absurdly unlikely there is a sha256 checksum verified over the kdump kernel before it starts booting. If you have very broken memory it is possible, but absurdly unlikely that the machine will even boot if you are having enough uncorrectable memory errors an hour to get past the sha256 checksum and then be corruppt. > Kdump shouldn't write any data to disk when information from > hardware is incredible because saving user data is always first > priority. Which is what is already implemented. It looks to me like you are jumping at shadows, and adding complexity to the kernel with no gain, and significant cost. Eric _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec