> i can't see how this could be unless on very first
> reference of the lock there is a race with the looser
> evaluateing !l->isilock before that processor can see
> the winner setting l->isilock to 1.
>
> if this diagnosis is correct, what is the proper fix?
take the test out.
this is my fault. (ironically, i put it in while debugging
some of your code, years ago.)
change:
/*
* Cannot also check l->pc and l->m here because
* they might just not be set yet, or the lock might
* even have been let go.
*/
if(!l->isilock){
dumplockmem("ilock:", l);
panic("corrupt ilock %p pc=%luX m=%p isilock=%d",
l, l->pc, l->m, l->isilock);
}
to
/*
* Cannot also check l->pc, l->m, or l->isilock here
* because they might just not be set yet, or
* (for pc and m) the lock might have just been unlocked.
*/
two out of three isn't bad. ;-)
russ
