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? If so, is there any way around it other than
locally disabling interrupts around the restoration of the context?
-Justin
|