>> How p->p_locks could be 1 for the server process when the only
>> locked vnode is locked by a completely unrelated process is a
>> mystery to me.  Perhaps it's holding something other than a vnode
>> locked?

Well, either that or there's a bug in maintaining p_locks.  I just had
it happen again, and this time there were no vnodes locked at all:

Locked vnodes
nfsd: locking botch in op 3 (before 0, after 1)

Looking at the code, I see something else suspicious: lockmgr() always
uses curproc.  Can it ever be called from interrupt context?
LK_NOWAIT's presence argues that it can be, but if it is, the wrong
process's p_locks field will be updated.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B