Here's a nine-part patch series to implement "AR=1" recoverythat will be available on high-end Sandy Bridge server processors.In this case the process detects an uncorrectable memory errorwhile doing an instruction of data fetch that is about to beconsumed. This is in contrast to the recoverable errors onNehalem and Westmere that were out of immediate execution context(patrol scrubber and cache line write-back).

The code is based on work done by Andi last year and published inthe "mce/action-required" branch of his mce git tree:git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-mce-2.6.gitThus he gets author credit on 6 out of 9 patches (but I'll takethe blame for all of them).

The first eight patches are mostly cleanups and minor new bitsthat are needed by part 9 where the interesting stuff happens.

For the "in context" case, we must not return from the machinecheck handler (in the data fetch case we'd re-execute the fetchand take another machine check, in the instruction fetch casewe actually don't have a precise IP to return to). We use theTIF_MCE_NOTIFY task flag bit to ensure that we don't return tothe user context - but we also need to keep track of the memoryaddress where the fault occurred. The h/w only gives us the physicaladdress which we must keep track of ... to do so we have added"mce_error_pfn" to the task structure - this feels odd, but itis an attribute of the task (e.g. this task may be migrated toanother processor before we get to look at TIF_MCE_NOTIFY andhead to do_notify_resume() to process it).

Andi's recovery code can also handle a few cases where theerror is detected while running kernel code (when copyingdata to/from a user process) - but the TIF_MCE_NOTIFY methoddoesn't actually ever get to this code (since the entry_64.S codeonly checks TIF_MCE_NOTIFY on return to userspace). I'dappreciate any ideas on how to handle this. Perhaps we coulddo good things when CONFIG_PREEMPT=y (it seems probable thatany error in a non-preemtible section of kernel code is goingto be fatal).