Kumar Gala writes:

quoted

It depends on whether a critical or machine check handler can ever do
anything to generate a signal or a reschedule.  If they can't, then
there is no problem.

They can if the come from user space.  I'm question what it means to  
send a signal based on receiving an async exception.

The most common cases are (a) something that ultimately generates
input on a tty (e.g. a character arriving on a serial port) and that
input turns out to be a ^C or similar, or (b) something that signals
I/O completion and the program doing the I/O has requested
notification by a SIGIO.  But in general any driver code can send a
signal to userspace if it wants.

quoted

If they can, then we have to be very careful.  If a critical or
machine check happens at a point where normal interrupts are disabled
then we have to be extremely careful not to do anything that the code
we've interrupted assumes can't happen - so we'd better not try to
take any spinlocks, for example.  That severely limits what the
handler can do.  It probably shouldn't even call printk, for
instance, or wake any process up, and definitely shouldn't call
schedule (or schedule_preempt) on the way out.

how do we provide someone stick a kprobe on such code today?

-ENOPARSE

So I'm not if there is any good way to preclude the handlers  
associated with these exceptions from doing the things you listed.

In that case, you'd better expect to see system freezes, memory
corruption and general instability.

Paul.