Proc code locks before disabling IRQs
authorBarret Rhoden <brho@cs.berkeley.edu>
Mon, 14 May 2012 22:08:09 +0000 (15:08 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Wed, 5 Sep 2012 21:43:58 +0000 (14:43 -0700)
commit54c6008c100053801889903668e0e4174ec97535
treef7ec8c5de46a70219969fb14b9bb3b91998b4ada
parent850e1a46dbe89e3657ea858e93bc417ce597dc77
Proc code locks before disabling IRQs

While we cannot grab the lock with interrupts off, we *can* disable
after grabbing the lock, but only under certain circumstances.  This is
because we send the kmsgs with the lock held.  Once we hold the lock, we
know no one will send proc mgmt kmsgs except us.  And it is really
important that we don't send any in these functions.  (imagine trying to
do a __preempt, when you send something to your own core and then try to
__map_vcore, and never get the message).

Also note that we must use immediate messages (which we've been doing
for a while now).  If we didn't use immediate kmsgs for __preempt,
someone (for instance) yielding or change_to-ing would spin on the lock
til they got the lock, but would never get the message since the lock
holder was waiting on them to do the __preempt.

Btw, in case it wasn't clear, the lock holder is spinning in
__map_vcore(), which is where we wait on the completion of the __preempt
kmsg.
kern/src/process.c