2013/2/8 Gaurav Jain <gjainroorkee@xxxxxxxxx>: > What happens if the kernel executing in some process context (let's say > executing a time-consuming syscall) gets interrupted by the Timer - which is > apparently allowed in 2.6 onwards kernels. > > My understanding is that once the interrupt handler is done executing, we > should switch back to where the kernel code was executing. Exactly. At the end of the interrupt, the state of the processor (register values) as it was before being interrupted is restored. > Specifically, the > interrupt handler for the Timer interrupt should not schedule some other > task since that might leave kernel data in an inconsistent state - kernel > didn't finish doing whatever it was doing when interrupted. > > So, does the Timer interrupt handler include such a policy for the above > case? In the case you have CONFIG_PREEMPT and it's the turn for some other task to be scheduled, the function preempt_schedule_irq() is called right before the irq return to the interrupted code. If the irq interrupted preemptible code (code that was not under a preempt_disable() section) then the scheduler may well schedule another task. It may indeed sound suprising that we schedule from an interrupt but it's actually fine. Later on, the scheduler restores the previous task to the middle of preempt_schedule_irq() and the irq completes its return to what it interrupted. The state of the processor prior to the interrupt is stored on the task stack. So we can restore that anytime. Note if the irq interrupted userspace, it can do about the same thing, except it calls schedule() directly instead of preempt_schedule_irq(). _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
