lkml.org 
[lkml]   [2011]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Patch 1/4][kernel][slimdump] Add new elf-note of type NT_NOCOREDUMP to capture slimdump


    ----- Original Message -----
    > On Wed, Oct 05, 2011 at 07:20:37PM +0200, Borislav Petkov wrote:
    > > On Wed, Oct 05, 2011 at 01:10:07PM -0400, Vivek Goyal wrote:
    > > > On Wed, Oct 05, 2011 at 08:58:53AM -0700, Luck, Tony wrote:
    > > > > > > The plan is to pass-down the list of poisoned memory pages
    > > > > > > to the second
    > > > > > > kernel using an elf-note so that these pages are left
    > > > > > > untouched during
    > > > > > > dump capture. I'm working on an implementation of the same
    > > > > > > and should
    > > > > > > have patches soon.
    > > > > >
    > > > > > I would say let us first figure out what happens while
    > > > > > reading a poisoned
    > > > > > page and is this a problem before working on a solution.
    > > > >
    > > > > If the page is poisoned because of a real uncorrectable error
    > > > > in memory
    > > > > (reported as SRAO machine check today, or by SRAR
    > > > > real-soon-now). Then
    > > > > accessing the page from the processor while taking a memory
    > > > > dump will
    > > > > result in a machine check.
    > > > >
    > > > > Note that a large memory system that had been running for a
    > > > > long time
    > > > > may have built up a small stash of these land-mine pages - and
    > > > > we need
    > > > > to worry about them even in the case where the panic is not
    > > > > machine
    > > > > check related (in fact especially in this case ... we are in a
    > > > > case
    > > > > where we actually do want the dump to diagnose the cause of the
    > > > > panic,
    > > > > and we don't want to risk losing the crash dump because we
    > > > > aborted when
    > > > > touching a page that the OS had safely avoided for
    > > > > days/weeks/months).
    > > > >
    > > > > So passing a list of poisoned pages from the old kernel to the
    > > > > new kernel
    > > > > is a good idea - and is independent of the cause of the crash
    > > > > (except that
    > > > > in the fatal machine check case due to memory error the list is
    > > > > guaranteed
    > > > > to be non-empty).
    > > >
    > > > Whre is this poisoned page info stored? In struct page? If yes, then
    > > > user space can walk through it and make sure not to touch poisoned pages.
    > > > Anyway user space filtering utility "makedumpfile" walks through struct
    > > > pages to filter out the pages. It should be able to filter out
    > > > poisoned pages unconditionally. So there should be no need for kernel
    > > > to export a list of these pages.
    > >
    > > Does this utility work on a vmcore dump? If so, Tony refers to the
    > > creation of the vmcore itself from the memory used by the first
    > > kernel.
    >
    > No, this utitlity can directly work on /proc/vmcore where first kernel's
    > image is still in memory and not on disk.
    >
    > > If there are poisoned pages, merely accessing that portion of DRAM
    > > containing the poisoned data would cause further MCEs in the freshly
    > > booted kernel so you won't be able to finish creating the dump.
    >
    > As long as you can get to your struct page arrays, one should be able
    > to filter out poisoned pages without saving the whole dump.

    It's still going to require a minimal kernel change because the
    PG_hwpoison flag's bit number differs depending upon the kernel
    configuration, if it exists at all. An additional vmcoreinfo item
    probably...

    Dave



    \
     
     \ /
      Last update: 2011-10-05 20:03    [W:0.025 / U:0.072 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site