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
