Subject: Re: SA_SIGINFO notes
To: None <thorpej@wasabisystems.com>
From: None <cgd@broadcom.com>
List: tech-kern
Date: 10/07/2003 14:27:43
At Tue, 7 Oct 2003 21:17:52 +0000 (UTC), "Jason Thorpe" wrote:
> On Tuesday, October 7, 2003, at 11:20  AM, Paul Kranenburg wrote:
> > If so, what about say a-synchronous memory errors that are not
> > necessarily
> > related to a thread's execution sequence?
> 
> If a memory error is asynchronous, you would never generate a signal
> for it, right?

Depends.


> You might log an error to the console, or something,
> but I don't understand how you could even select which process to send
> the signal to if it were truly asynchronous.

you might detect a cache error or something when a line is being
replaced/ejected in a cache.

in that case, *if* you can detect an address associated with the
error, *and* you can map that address back to a process, you will
probably want to inform the process somehow.

killing the process might be appropriate.  so might be causing the
page in question to be invalidated (taken out of address space) and
hitting the process with some kind of "recoverable" signal (so that it
can *try* to clean up after itself, at least).  (If you do the latter,
then you want subsequent accesses to the page in question to fail,
hence take it out of address space.)


I know of at least some architectures and/or CPUs where it's possible
to get the address associated with such an error.

Now, there's a lot of code that would have to exist (code to get the
handle the error properly and all the code downstream of it 8-) for an
error-handler like the above to actually work, but it's not
unreasonable to desire it.


cgd