But in ret_from_intr(), the "iret" instruction hasn't yet been executed and therefore the interrupt handling hasn't finished. Isn't the switch from interrupt context to process context done only after "iret" is executed? If not, where exactly in the code is this transition done? And what actually CHANGES in the kernel state to reflect this context change (since the kernel stack - and therefore, the "current" pointer - remains the same as it was in interrupt context)? Thanks again, -- Martim On Tue, 31 Aug 2004 23:19:45 -0400, Robert Love <rml@xxxxxxxxxx> wrote: > > > 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/
