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