[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <987664A83D2D224EAE907B061CE93D5301EE594D4C@orsmsx505.amr.corp.intel.com>
Date: Mon, 3 Oct 2011 15:53:09 -0700
From: "Luck, Tony" <tony.luck@...el.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>,
"prasad@...ux.vnet.ibm.com" <prasad@...ux.vnet.ibm.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"crash-utility@...hat.com" <crash-utility@...hat.com>,
"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
Vivek Goyal <vgoyal@...hat.com>,
Andi Kleen <andi@...stfloor.org>,
"anderson@...hat.com" <anderson@...hat.com>,
"tachibana@....nes.nec.co.jp" <tachibana@....nes.nec.co.jp>,
"oomichi@....nes.nec.co.jp" <oomichi@....nes.nec.co.jp>
Subject: RE: [Patch 1/4][kernel][slimdump] Add new elf-note of type
NT_NOCOREDUMP to capture slimdump
> It totally doesn't make sense to do this in the kernel when we can
> filter this from userspace just fine.
Patch 1 is the kernel part that provides the clue for user space
tools to do this filtering. The other three parts are patches to
tools that see the hint and act on it.
Eric: Do you see a better way for the kernel that just crashed from
a machine check to communicate the reason for the crash to the
successor kernel? The Elf-note in vmcore needs quite a bit of
code to set up - but is otherwise fairly succinct. We don't want
the successor kernel to have to poke through too much memory from
the crashed kernel to figure this out - the more we look at, the
higher the probability that we step on the landmine that crashed
the original kernel.
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists