Hi Mulyadi, Thank you for the quick reply. It does clear my doubt. If interrupts are disabled, I should ensure that I do not wake up any process that might have a higher priority. Else, I should probably use a spin_lock_irqsave/restore() which already has the preempt_disable() set. Would this be the case when I am doing something as part of the ISR as well or is that a totally different use case? Regards, John G On 5/28/07, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
Hi George > Consider the following scenario. > 1. disable the interrupts in the machine (local_irq_save) > 2. wake up a process from a wait queue (wake_up or up() - which I thought > ultimately calls wake_up). > 3. enable interrupts > > In step 2 above, when I wake up a process, if the woken up process has a > higher priority than the process waking it up, the current process > will be > preempted. The new process scheduled need not have the interrupts > disabled > and hence that process could be interrupted which would make the whole > disable interrupt concept fail. > > I am assuming that the above does not happen in the kernel, but I do not > understand how the kernel prevents this from happening because I do > not see > a preempt_disable () or anything like that being set either. So, in essence, you're questioning whether interrupt is still disabled after new process is running, is that correct? First of all, after reading http://en.wikipedia.org/wiki/CLI_(x86_instruction), I refresh my mind and realize it is a privileged instruction so only kernel space that could do it. So, IMHO your scenario is possible to happen if kernel preemption is enabled. Second, by design, actually nothing stops you to reschedule on any point. And since you don't call explictly disable preemption but instead call wake_up(), you could see what happen in switch_to() (defined in include/asm-i386/system.h). The explanation is quite tricky, but in plain English, it means IF (Interrupt Flags) condition (as a part of EFLAGS) will be restored according to the last situation before it is preempted. So, assuming you're waking up a process which has interrupt enabled (IF enabled), your local CPU which is running this process would enable the interrupt. But when it goes back to your original code path, interrupt would be disabled again. My conclusion is, either don't call anything that end up in scheduling another process during disabling interrupt (preferred), or guard it with preempt_disable() (less preferred). Oh, and since interrupt is disabled, you don't need to worry if your time slice is up, because for a moment, it simply skips that check. I hope this clears your doubt. regards, Mulyadi
-- John V. George -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
