Date: Sat, 29 Mar 1997 19:20:56 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Terry Lambert <terry@lambert.org> Cc: jdp@polstra.com, current@freebsd.org Subject: Re: Panic: "lockmgr: pid %d, not %s %d unlocking" Message-ID: <Pine.BSF.3.95q.970329190757.4554E-100000@kipper.nlsystems.com> In-Reply-To: <199703291821.LAA06605@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 29 Mar 1997, Terry Lambert wrote: > > > I just got this panic on a -current kernel from March 17th, running > > > on a 486/66DX2 with 16 MB of RAM: > > > > > > #9 0xf01181fa in panic (fmt=0xf0112e4b "lockmgr: pid %d, not %s %d unlocking") > > > at ../../kern/kern_shutdown.c:366 > > > #10 0xf01132d8 in lockmgr (lkp=0xf0bc3e34, flags=6, interlkp=0xf0ba5b60, > > > p=0xf0bf1800) at ../../kern/kern_lock.c:355 > > > #11 0xf01af9c3 in ufs_unlock (ap=0xefbffd50) at ../../ufs/ufs/ufs_vnops.c:1784 > > > #12 0xf0165b35 in nfs_inactive (ap=0xefbffd78) at vnode_if.h:843 > > > > This looks as if the vnode was recycled unexpectedly from > > NFS to UFS during the call to vm_object_deallocate. Unfortunately I can't > > see any obvious way this can happen since the vm_object has a ref to the > > vnode and it doesn't look like vm_object_deallocate can get re-entered > > easily. > > Actually, it looks like lockmgr() is not reeentrancy locking the global > structures (something which is necessary if the lock management is done > on a calldown rather than a veto basis). Now that I have had a chance to thing about this for a while, I think it is due to the fact that vop_nolock and vop_nounlock are stubbed out in the Lite2 code. These are used to provide a simple shared lock for non-locking filesystems. The (allegedly evil :-) vclean code uses the lockmgr code to wait for all outstanding shared locks to be released using LK_DRAIN; this is an improvement to the Lite1 version of vclean which I don't think worked very well for non-locking filesystems. Unfortunately since the Lite2 version of NFS and possibly some other filesystems does not correctly observe the vnode locking protocol, the code was not enabled. I made a start on fixing the locking protocol in NFS when I was working on it in the lite2 tree. When my new machine arrives, I will finish this and enable the proper locking code for at least NFS. On a related note, does anyone have any filesystem stress tests? I was thinking of writing a simple one which would use multiple processes to create, read, copy and delete large trees on several different filesystems. This ought to stress the locking and vnode allocation code fairly well. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970329190757.4554E-100000>