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? -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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
