On Tue, 2004-08-31 at 21:14 -0300, Martim Carbone wrote: > I am reading Robert Love's book on kernel development, and it states > that interrupt handlers (that execute on interrupt context) cannot > call functions that sleep, because then the ISR's execution thread > would be halted and never again rescheduled. Ok, makes sense. > > However, I couldn't help noticing that, in page 75 of Robert's book, > it is stated that, when called upon from ret_from_intr() > (arch/i386/kernel/entry.S), schedule() actually RETURNS, and then > ret_from_intr() can resume executing. > > How can schedule() return if it immediately transfers the CPU control > to another process? Can it happen when the interrupted process is > rescheduled (since it shares its stack with the ISR)? If that is > indeed the case, then I failed to see why one must not call sleeping > functions from ISRs, since they would resume executing just fine next > time the interrupted process was scheduled for execution... When the interrupt returns, and we are in ret_from_intr() in entry.S, we are back in the context of the process that the interrupt interrupted. So it is safe to call schedule. Your question goes on to suggest it would be OK to call schedule, since the ISR is associated with a process and eventually that process will be rescheduled. Well, the first reason that won't work is that there is a BUG() in schedule() that will catch it. ;-) But this is a good observation. Semantical reasons exist for it not being practical: the task could be killed, it may not be scheduled for a long time, it may be the idle task, it may of been in user-space in which case it will resume there and not in the kernel, etc etc. Ultimately, if you want to allow rescheduling during interrupts, you need to give them their own unique schedulable entity. Robert Love -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
