More thoroughly detect preemptions
authorBarret Rhoden <brho@cs.berkeley.edu>
Thu, 13 Oct 2011 00:50:23 +0000 (17:50 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 15 Dec 2011 22:48:40 +0000 (14:48 -0800)
commit83d77588b5393c114599555b84677dfd91fb7732
tree92c5002fda5c87a5696e470900ac0ee7c4428515
parent6c546ffe4e3d7fcd7d7b6365f0f34106e983be48
More thoroughly detect preemptions

MCS-PDR code checks for preemptions via preempt_tf_valid.  If you don't
you can accidentally think a yielded vcore is preempted.  Either way, it
is unmapped.  In the future, it'll be safe to restart them, but right
now we don't handle preemption messages, so processes can run into
issues.  Also, you don't really want to restart a yielded vcore.  Next
time you spin in the MCS code, you will (hopefully!) get a different
vcore (reread lockholder, etc).

Also, we were a bit sloppy about the use of preempt_tf_valid.  It's
actually an ancient seq_ctr instead of a bool.  The 2 year old reason
for that was to help us detect changes to the preempt tf for remote
recovery, but I have a feeling it might not be strong enough.
kern/src/process.c
user/parlib/include/vcore.h
user/parlib/mcs.c