Justin Carlson wrote:
On Mon, 2002-06-10 at 15:14, Jun Sun wrote:
I am not sure if I am following your logic, but I don't see a race condition
Once current->mm is read into a register, the register is saved into stack
when an interrupt happens (which later incurs a reschedule presumbably). When
the current preempted process comes back later, it goes back to the "tail" of
do_IRQ(), followed by restoring the registers. Since the register now holds
the right value, set_entryhi() should be correct.
You've described exactly what happens. The only problem is, it's
possible the underlying value for current->mm has changed. It's a
*really* narrow window, at most a cycle or two, but I think it is
there. In addition, even if you hit the window, to trigger wrong
behavior it requires that you also saturate the local ASID space,
invoking the tlb flush and asid reset in get_mmu_context().
The change that's introduced by the preemptive kernel is that
switch_mm() can be called after an interrupt. So, with some
hypothetical assembly, the code flow looks like this:
lw $1, 120($29) ; Load current->mm->context into a register
* Interrupt happens *
* reschedule happens, switch_mm() is called *
* get_new_mmu_context() invoked, starts a new ASID cycle.
* current->mm->context for the original process changes
* (sometime later) switch back to original process
mtc0 $entryhi, $1 ; stale context put back into entryhi!
Does that make more sense? It's really a tiny race, but I think it's a
I see your point now.
However, the race is not there. switch_mm() is only called from inside
schedule() function, which as a whole is preemption-safe. In other words, the
above event sequence won't cause a context switch until we exit from