Paul Mackerras paulus at samba.org
Thu May 1 18:24:09 EST 2008

Kumar Gala writes:

> > 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.

> > 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?


> 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.


More information about the Linuxppc-dev mailing list