Re: Atomicity & preemptive kernels

[Jun Sun <jsun@mvista.com>]

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