Re: [patch] Memory Error Handling Improvement

David Mosberger
2005-06-24T20:36:25Z

>>>>> On Fri, 24 Jun 2005 15:11:09 -0500 (CDT), Russ Anderson <rja@sgi.com> said:

Russ> Testing with error injection showed a significant number of
Russ> cases where the MCA surfaced early in the interrupt routine,
Russ> even though the load of the bad data was launched from a user
Russ> process. Adding the second condition to look for these cases
Russ> allowed them to be recovered. Analysis of the recovered MCA
Russ> records showed 7-10% of the recoverys were this condition,
Russ> when running the error recovery code with other activity that
Russ> caused interrupts.

Russ> Previously, if the MCA surfaced while the cpu was in privilage
Russ> mode the code would not try to recover. This change adds a
Russ> second condition, to see if the kernel is early in the
Russ> interrupt routine. It does this by checking the instruction
Russ> range. As Hidetoshi Seto points out, the check should also
Russ> make sure the interrupted process was in user mode. That has
Russ> been added to the patch and tested.

Sorry, but this doesn't make any sense to me. If an application
spends a lot of time handling TLB faults or unaligned access faults,
it's very likely the MCA will hit in those handlers and your patch
will not help at all. Furthermore, if MCA delivery timing changes for
some reason, the user-triggered MCA might show up much later, i.e.,
pretty much anywhere in the kernel no?

Isn't there a more reliably method to handle this? What if you just
_assumed_ that MCAs are triggered by user-level (unless you can prove
that it was kernel-only memory, perhaps).

--david