From owner-freebsd-bugs Sat May 24 07:10:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA26379 for bugs-outgoing; Sat, 24 May 1997 07:10:27 -0700 (PDT) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA26372 for ; Sat, 24 May 1997 07:10:21 -0700 (PDT) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.5/8.8.5) with SMTP id PAA19638; Sat, 24 May 1997 15:10:17 +0100 (BST) Date: Sat, 24 May 1997 15:10:17 +0100 (BST) From: Doug Rabson To: Tor Egge cc: freebsd-bugs@hub.freebsd.org Subject: Re: kern/3581: trap 12 in lockstatus() In-Reply-To: <199705241401.QAA03963@pat.idt.unit.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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