Thanks for the explanation.
>So, yes, if I understand things properly, IRQ code can modify critical
>data safely without doing cli/sti. (Of course, for data that multiple
As long as a second interrupt does not invoke the same code: which is
another reason why blocking the interrupt in the controller is necessary.
Also using two IRQs with one driver is not permitted by this
scheme.
>>On a related issue. In this SMP design, it looks like cli has no
>>effect at all on non-irq kernel mode. That is, if one processor
>>does a cli while in a system call, nothing prevents a second processor
>>from also doing a cli and entering the same code. Did I miss something?
>
>I think this code from arch/i386/kernel/irq.c (similar code is in
Thanks. I overlooked the step where
cli will first acquire the global_irq lock, which
functions here as a lock on cli-mode.
>So, when a cpu exits this loop, it has acquired the global_irq_lock. In
>fact, wait_on_irq (called just after this excerpt) can do some pretty
>complicated stuff (including dropping the lock and then getting it back),
In theory, it looks like this scheme does not ensure that a processor
must finish cli. If there are 4 processors and processor 1 is
unlucky enough it may never finish manage to acquire the lock during
a period of no irqs on other processes.
Your example of the race condition in cli is also very illuminating.
Thanks again.