On Apr 30, 2008, at 6:47 PM, Paul Mackerras wrote:

Kumar Gala writes:

quoted

If we don't handle reschedule or signal will we actually not function
properly?  I assume reschedule isn't an issue, but could we lose a
signal?

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.

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?

If the critical/mcheck interrupt happens at a point where a normal
interrupt could have happened (including when userspace is running)
then we could treat it pretty much as a normal interrupt, including
handling signals or reschedules on the way out if appropriate.

So we have 4 actual exceptions:
* CriticalInput (some external device signaled this.  There are two  
concepts of critical.  One is error the other is high priority)   
However this would have the same caveats as any ExternalInput handler.

* Watchdog - pretty severe if this fires.

* Debug - user space debug is pretty straight forward.  However we  
have features like kprobes that require kernel level support.

* MachineCheck - pretty serve if this fires.

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

- k