Date: Sat, 24 May 1997 15:10:17 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Tor Egge <Tor.Egge@idi.ntnu.no> Cc: freebsd-bugs@hub.freebsd.org Subject: Re: kern/3581: trap 12 in lockstatus() Message-ID: <Pine.BSF.3.95q.970524150912.349A-100000@herring.nlsystems.com> In-Reply-To: <199705241401.QAA03963@pat.idt.unit.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 24 May 1997, Tor Egge wrote: > > There is also the VOP_ISLOCKED race to deal with which, I think, is more > > common. I have seen it a couple of times. One solution would be to > > change *all* calls to VOP_ISLOCKED to vn_islocked which would check VXLOCK > > before calling the filesystem. Another would be to change all VFS' > > VOP_ISLOCKED to check VXLOCK. > > You might need to add an `owner' for VXLOCK. Then vn_islocked could > block if VXLOCK is set and the owner is different from the caller. > If VXLOCK is set and the owner is the same, the locking operations > must just be 'stubs'. Not having an owner makes it much more difficult > to avoid both deadlocks and races. You might also need to delay > the initialization of the `owner' field until vclean has the lock. vn_islocked shouldn't block at all. It just tests to see if the vnode is locked. If VXLOCK is set, then it would just return TRUE. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970524150912.349A-100000>