From: "K.Prasad" <prasad@linux.vnet.ibm.com> To: Vivek Goyal <vgoyal@redhat.com> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Andi Kleen <andi@firstfloor.org>, "Luck, Tony" <tony.luck@intel.com>, kexec@lists.infradead.org, "Eric W. Biederman" <ebiederm@xmission.com>, anderson@redhat.com Subject: Re: [RFC Patch 5/6] slimdump: Capture slimdump for fatal MCE generated crashes Date: Fri, 27 May 2011 22:27:36 +0530 [thread overview] Message-ID: <20110527165736.GC2384@in.ibm.com> (raw) In-Reply-To: <20110526174447.GC29496@redhat.com> On Thu, May 26, 2011 at 01:44:47PM -0400, Vivek Goyal wrote: > On Thu, May 26, 2011 at 10:53:05PM +0530, K.Prasad wrote: > > > > slimdump: Capture slimdump for fatal MCE generated crashes > > > > System crashes resulting from fatal hardware errors (such as MCE) don't need > > all the contents from crashing-kernel's memory. Generate a new 'slimdump' that > > retains only essential information while discarding the old memory. > > > > Why to enforce zeroing out of rest of the vmcore data in kernel. Why not > leave it to user space. > Our concern comes from the fact that it is unsafe for the OS to read any part of the corrupt memory region, so the kernel does not have to make that address space available for read/write. > As Andi said, you anyway will require disabling MCE temporarily in second > kernel. So that should allay the concern that we might run into second > MCE while trying to read the vmcore. > The processor manuals don't define the behaviour for a read operation upon a corrupt memory location. So the consequences for a read after disabling MCE is unknown (as I've mentioned here: https://lkml.org/lkml/2011/5/27/258). > A user might want to extract just the dmesg buffers also after MCE from > vmcore. > > What I am saying is that this sounds more like a policy. Don't enforce > it in kernel. Probably give user MCE registers as part of ELF note of > vmcore. Now leave it up to user what data he wants to extract from vmcore. > Just the MCE registers or something more then that. I'm unsure, at the moment, as to what it actually entails to extract dmesg buffers from the old kernel's memory; but given that there exists a corrupt memory region with unknown consequences for read operations upon it, I doubt if it is a safe idea to allow user-space application to navigate through the kernel data-structures to extract the dmesg. Alternatively, we might leave MCE enabled for the kdump kernel and modify the user-space application to turn resilient to SIGBUS signal. So if it reads a corrupt memory region, it will receive a signal from do_machine_check() upon which it can skip that particular address and/or fill it with zeroes (or somesuch). We haven't gone through the details....but just some loud thinking Thanks, K.Prasad
WARNING: multiple messages have this Message-ID (diff)
From: "K.Prasad" <prasad@linux.vnet.ibm.com> To: Vivek Goyal <vgoyal@redhat.com> Cc: "Luck, Tony" <tony.luck@intel.com>, kexec@lists.infradead.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Andi Kleen <andi@firstfloor.org>, anderson@redhat.com, "Eric W. Biederman" <ebiederm@xmission.com> Subject: Re: [RFC Patch 5/6] slimdump: Capture slimdump for fatal MCE generated crashes Date: Fri, 27 May 2011 22:27:36 +0530 [thread overview] Message-ID: <20110527165736.GC2384@in.ibm.com> (raw) In-Reply-To: <20110526174447.GC29496@redhat.com> On Thu, May 26, 2011 at 01:44:47PM -0400, Vivek Goyal wrote: > On Thu, May 26, 2011 at 10:53:05PM +0530, K.Prasad wrote: > > > > slimdump: Capture slimdump for fatal MCE generated crashes > > > > System crashes resulting from fatal hardware errors (such as MCE) don't need > > all the contents from crashing-kernel's memory. Generate a new 'slimdump' that > > retains only essential information while discarding the old memory. > > > > Why to enforce zeroing out of rest of the vmcore data in kernel. Why not > leave it to user space. > Our concern comes from the fact that it is unsafe for the OS to read any part of the corrupt memory region, so the kernel does not have to make that address space available for read/write. > As Andi said, you anyway will require disabling MCE temporarily in second > kernel. So that should allay the concern that we might run into second > MCE while trying to read the vmcore. > The processor manuals don't define the behaviour for a read operation upon a corrupt memory location. So the consequences for a read after disabling MCE is unknown (as I've mentioned here: https://lkml.org/lkml/2011/5/27/258). > A user might want to extract just the dmesg buffers also after MCE from > vmcore. > > What I am saying is that this sounds more like a policy. Don't enforce > it in kernel. Probably give user MCE registers as part of ELF note of > vmcore. Now leave it up to user what data he wants to extract from vmcore. > Just the MCE registers or something more then that. I'm unsure, at the moment, as to what it actually entails to extract dmesg buffers from the old kernel's memory; but given that there exists a corrupt memory region with unknown consequences for read operations upon it, I doubt if it is a safe idea to allow user-space application to navigate through the kernel data-structures to extract the dmesg. Alternatively, we might leave MCE enabled for the kdump kernel and modify the user-space application to turn resilient to SIGBUS signal. So if it reads a corrupt memory region, it will receive a signal from do_machine_check() upon which it can skip that particular address and/or fill it with zeroes (or somesuch). We haven't gone through the details....but just some loud thinking Thanks, K.Prasad _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2011-05-27 16:57 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-05-26 17:07 [RFC Patch 0/6] slimdump: Enable slimdump if crashing kernel memory is not required K.Prasad 2011-05-26 17:07 ` K.Prasad 2011-05-26 17:12 ` [Patch 1/6] XPANIC: Add extended panic interface K.Prasad 2011-05-26 17:12 ` K.Prasad 2011-05-26 17:38 ` richard -rw- weinberger 2011-05-26 17:38 ` richard -rw- weinberger 2011-05-27 15:56 ` K.Prasad 2011-05-27 15:56 ` K.Prasad 2011-05-27 17:59 ` Eric W. Biederman 2011-05-27 17:59 ` Eric W. Biederman 2011-05-26 17:12 ` [Patch 2/6] x86: mce: Convert mce code to xpanic K.Prasad 2011-05-26 17:12 ` K.Prasad 2011-05-27 18:01 ` Eric W. Biederman 2011-05-27 18:01 ` Eric W. Biederman 2011-05-26 17:14 ` [Bugfix][Patch 3/3] Invoke vpanic inside xpanic function K.Prasad 2011-05-26 17:14 ` K.Prasad 2011-05-26 17:15 ` [RFC Patch 4/6] PANIC_MCE: Introduce a new panic flag for fatal MCE, capture related information K.Prasad 2011-05-26 17:15 ` K.Prasad 2011-05-26 18:43 ` Vivek Goyal 2011-05-26 18:43 ` Vivek Goyal 2011-05-27 17:03 ` K.Prasad 2011-05-27 17:03 ` K.Prasad 2011-05-27 18:29 ` Vivek Goyal 2011-05-27 18:29 ` Vivek Goyal 2011-05-27 18:04 ` Eric W. Biederman 2011-05-27 18:04 ` Eric W. Biederman 2011-05-31 17:40 ` K.Prasad 2011-05-31 17:40 ` K.Prasad 2011-06-01 17:18 ` Dave Anderson 2011-06-01 17:18 ` Dave Anderson 2011-06-01 17:23 ` Vivek Goyal 2011-06-01 17:23 ` Vivek Goyal 2011-06-01 17:41 ` Dave Anderson 2011-06-01 17:41 ` Dave Anderson 2011-06-08 17:16 ` K.Prasad 2011-06-08 17:16 ` K.Prasad 2011-06-12 15:44 ` Eric W. Biederman 2011-06-12 15:44 ` Eric W. Biederman 2011-06-15 2:06 ` K.Prasad 2011-06-15 2:06 ` K.Prasad 2011-05-27 18:09 ` Eric W. Biederman 2011-05-27 18:09 ` Eric W. Biederman 2011-05-26 17:23 ` [RFC Patch 5/6] slimdump: Capture slimdump for fatal MCE generated crashes K.Prasad 2011-05-26 17:23 ` K.Prasad 2011-05-26 17:32 ` Andi Kleen 2011-05-26 17:32 ` Andi Kleen 2011-05-27 15:53 ` K.Prasad 2011-05-27 15:53 ` K.Prasad 2011-05-26 17:44 ` Vivek Goyal 2011-05-26 17:44 ` Vivek Goyal 2011-05-26 18:09 ` Andi Kleen 2011-05-26 18:09 ` Andi Kleen 2011-05-26 18:26 ` Vivek Goyal 2011-05-26 18:26 ` Vivek Goyal 2011-05-26 18:58 ` Andi Kleen 2011-05-26 18:58 ` Andi Kleen 2011-05-26 19:10 ` Vivek Goyal 2011-05-26 19:10 ` Vivek Goyal 2011-05-26 23:44 ` Simon Horman 2011-05-26 23:44 ` Simon Horman 2011-05-27 16:57 ` K.Prasad [this message] 2011-05-27 16:57 ` K.Prasad 2011-05-27 17:59 ` Vivek Goyal 2011-05-27 17:59 ` Vivek Goyal 2011-06-08 17:00 ` K.Prasad 2011-06-08 17:00 ` K.Prasad 2011-05-27 18:14 ` Eric W. Biederman 2011-05-27 18:14 ` Eric W. Biederman 2011-05-26 17:26 ` [RFC Patch 6/6] Crash: Recognise slim coredumps and process new elf-note sections K.Prasad 2011-05-26 17:26 ` K.Prasad 2011-05-27 15:37 ` Mahesh J Salgaonkar 2011-05-27 15:37 ` Mahesh J Salgaonkar 2011-05-27 18:16 ` Eric W. Biederman 2011-05-27 18:16 ` Eric W. Biederman 2011-05-27 18:22 ` Vivek Goyal 2011-05-27 18:22 ` Vivek Goyal 2011-05-27 18:35 ` Eric W. Biederman 2011-05-27 18:35 ` Eric W. Biederman 2011-05-26 17:31 ` [RFC Patch 0/6] slimdump: Enable slimdump if crashing kernel memory is not required K.Prasad 2011-05-26 17:31 ` K.Prasad
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20110527165736.GC2384@in.ibm.com \ --to=prasad@linux.vnet.ibm.com \ --cc=anderson@redhat.com \ --cc=andi@firstfloor.org \ --cc=ebiederm@xmission.com \ --cc=kexec@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=tony.luck@intel.com \ --cc=vgoyal@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.