Justin Carlson wrote:
I know we're not there yet, but I'm trying to understand some issues
with rml's preemptive kernel and ASID's.
While doing a virtually-tagged hit invalidate of a cache, I was going to
write code something like this;
set_entryhi(CPU_CONTEXT(cpu, mm->vm_mm));
hit_invalidate_range(start, end);
set_entryhi(CPU_CONTEXT(cpu, current->mm));
Insofar as I understand current kernel scheduling guarantees, this is
safe because we won't reschedule while running in kernel mode. But, if
I'm looking ahead to the preemptive kernel, then I think there is a
slight window for a race in between the reading of current->mm and
the setting of entryhi. Something like this:
current->mm->context is read
* kernel reschedules.
* switch_mm() called
* current->mm->context changes on return to this process
entryhi is set to the wrong context.
Is this a real race?
I am not sure if I am following your logic, but I don't see a race condition
here.
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.
BTW, I have preemptiable kernel working fine under both UP and SMP. If there
is much interestes, I will publish it on the list.
Jun
|