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
