linux-mips
[Top] [All Lists]

Re: Atomicity & preemptive kernels

To: Justin Carlson <justin@cs.cmu.edu>
Subject: Re: Atomicity & preemptive kernels
From: Jun Sun <jsun@mvista.com>
Date: Mon, 10 Jun 2002 15:14:13 -0700
Cc: linux-mips@oss.sgi.com
References: <1023738247.1133.56.camel@localhost.localdomain>
Sender: owner-linux-mips@oss.sgi.com
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901
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



<Prev in Thread] Current Thread [Next in Thread>