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
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
