From owner-cvs-sys Sun Apr 27 04:38:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA08680 for cvs-sys-outgoing; Sun, 27 Apr 1997 04:38:00 -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 EAA08675; Sun, 27 Apr 1997 04:37:56 -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 MAA12758; Sun, 27 Apr 1997 12:37:05 +0100 (BST) Date: Sun, 27 Apr 1997 12:37:05 +0100 (BST) From: Doug Rabson To: KATO Takenori cc: CVS-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-sys@FreeBSD.org Subject: Re: cvs commit: src/sys/miscfs/union union_vnops.c In-Reply-To: <199704271044.TAA03480@gneiss.eps.nagoya-u.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-sys@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 27 Apr 1997, KATO Takenori wrote: > From: Doug Rabson > Subject: Re: cvs commit: src/sys/miscfs/union union_vnops.c > Date: Sat, 26 Apr 1997 19:06:50 +0100 (BST) > > > I don't think this is right. I just had a lockmgr panic using the 1.28 > > version of this file (the one which played with the flags). It turned out > > that update had the uppervp locked and the union node should have locked > > the uppervp itself which would have waited until update had finished > > before continuing. In the same situation for 1.29 we would not lock > > uppervp at all which just seems wrong. > > I will undo 1.29. I will replace 1.28 with new change after I make > new fix. > > I consider that the problems related to 1.28 are that (1) 4.4BSD-Lite2 > assumes that vn_lock (or VOP_LOCK) is not called after VOP_UNLOCK in > same vnode related function. (2) Vnode operations in FreeBSD > sometimes call vn_lock after VOP_UNLOCK(). VOP_UNLOCK() keep upper > vnode locked and clear UN_ULOCK flag when UN_KLOCK is set in > union_unlock. The vn_lock after VOP_UNLOCK calls union_lock, and > uppervp is locked because UN_ULOCK is not set. > > My current idea is that: > > (1) union_unlock: do not clear uppervp, clear UN_ULOCK flag (same as > current), and do not clear UN_KLOCK, when UN_KLOCK is set. > (2) union_lock: do not access upper vp, do not clear UN_KLOCK, do not > panic, when UN_KLOCK is set. > (3) Each function in which UN_KLOCK is set should explicitly clear > UN_KLOCK after calling vnode related functions. Hmm. I don't yet understand the union filesystem enough to make an intelligent comment. I will try to read through the code this afternoon or tomorrow. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891