Hi,
I wonder if simplelock->lock_holder should be declared volatile in sys/lock.h
(and maybe others LOCKDEBUG fieds too) ?

I got a panic on a MP (1.6) machine:
simple_lock: uninitialised lock
in vfs_subr.c:1130
I get this once in a while, I got another one a month or so ago, was in
uvm_amap: 682 (see http://mail-index.netbsd.org/tech-kern/2002/12/16/0005.html)

I can't really see how this could happen, execpt if something else
is corrupting the struct simplelock data. but in this case other values
would probably be corrupted too, which is not the case.

Now, looking at kern_lock.c:_simple_lock(), I can see that alp->lock_holder
is tested twice, one before we have the lock and one after we aquired the
lock. If the lock was already locked and we're spining waiting to aquire
it, the first time alp->lock_holder is used it will be different from
LK_NOCPU, and at the second test, if the compiled cached the value in a
register it'll read the old value.

Unfortunably, if I can read assembly properly, this is not what's happening
here, the compiler seems to reread the value from memory.
But maybe a volatile should be there for lock_holder anyway ?

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
     NetBSD: 23 ans d'experience feront toujours la difference
--