Kumar Gala galak at kernel.crashing.org
Thu May 1 16:01:16 EST 2008

On Apr 30, 2008, at 6:47 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>> 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

More information about the Linuxppc-dev mailing list