From owner-cvs-sys Sun Apr 27 03:44:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA07520 for cvs-sys-outgoing; Sun, 27 Apr 1997 03:44:59 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA07515; Sun, 27 Apr 1997 03:44:56 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.5/3.4W4) with ESMTP id TAA03480; Sun, 27 Apr 1997 19:44:46 +0900 (JST) Message-Id: <199704271044.TAA03480@gneiss.eps.nagoya-u.ac.jp> To: dfr@nlsystems.com Cc: kato@eclogite.eps.nagoya-u.ac.jp, 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: Your message of "Sat, 26 Apr 1997 19:06:50 +0100 (BST)" References: X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 27 Apr 1997 19:44:46 +0900 From: KATO Takenori Sender: owner-cvs-sys@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk 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. ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) -------------------