lkml.org 
[lkml]   [2009]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] [0/16] POISON: Intro
    How does this overlap with the bad page quarantine that ia64 uses
    following an MCA?

    Robin

    On Tue, Apr 07, 2009 at 05:09:56PM +0200, Andi Kleen wrote:
    >
    > Upcoming Intel CPUs have support for recovering from some memory errors. This
    > requires the OS to declare a page "poisoned", kill the processes associated
    > with it and avoid using it in the future. This patchkit implements
    > the necessary infrastructure in the VM.
    >
    > To quote the overview comment:
    >
    > * High level machine check handler. Handles pages reported by the
    > * hardware as being corrupted usually due to a 2bit ECC memory or cache
    > * failure.
    > *
    > * This focusses on pages detected as corrupted in the background.
    > * When the current CPU tries to consume corruption the currently
    > * running process can just be killed directly instead. This implies
    > * that if the error cannot be handled for some reason it's safe to
    > * just ignore it because no corruption has been consumed yet. Instead
    > * when that happens another machine check will happen.
    > *
    > * Handles page cache pages in various states. The tricky part
    > * here is that we can access any page asynchronous to other VM
    > * users, because memory failures could happen anytime and anywhere,
    > * possibly violating some of their assumptions. This is why this code
    > * has to be extremely careful. Generally it tries to use normal locking
    > * rules, as in get the standard locks, even if that means the
    > * error handling takes potentially a long time.
    > *
    > * Some of the operations here are somewhat inefficient and have non
    > * linear algorithmic complexity, because the data structures have not
    > * been optimized for this case. This is in particular the case
    > * for the mapping from a vma to a process. Since this case is expected
    > * to be rare we hope we can get away with this.
    >
    > The code consists of a the high level handler in mm/memory-failure.c,
    > a new page poison bit and various checks in the VM to handle poisoned
    > pages.
    >
    > The main target right now is KVM guests, but it works for all kinds
    > of applications.
    >
    > For the KVM use there was need for a new signal type so that
    > KVM can inject the machine check into the guest with the proper
    > address. This in theory allows other applications to handle
    > memory failures too. The expection is that near all applications
    > won't do that, but some very specialized ones might.
    >
    > This is not fully complete yet, in particular there are still ways
    > to access poison through various ways (crash dump, /proc/kcore etc.)
    > that need to be plugged too.
    >
    > Also undoubtedly the high level handler still has bugs and cases
    > it cannot recover from. For example nonlinear mappings deadlock right now
    > and a few other cases lose references. Huge pages are not supported
    > yet. Any additional testing, reviewing etc. welcome.
    >
    > The patch series requires the earlier x86 MCE feature series for the x86
    > specific action optional part. The code can be tested without the x86 specific
    > part using the injector, this only requires to enable the Kconfig entry
    > manually in some Kconfig file (by default it is implicitely enabled
    > by the architecture)
    >
    > -Andi
    >
    > --
    > To unsubscribe, send a message with 'unsubscribe linux-mm' in
    > the body to majordomo@kvack.org. For more info on Linux MM,
    > see: http://www.linux-mm.org/ .
    > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>


    \
     
     \ /
      Last update: 2009-04-07 21:15    [W:0.029 / U:125.416 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site