From owner-freebsd-arch Tue Sep 17 3:31:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFA4937B401 for ; Tue, 17 Sep 2002 03:31:14 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C5D643E4A for ; Tue, 17 Sep 2002 03:31:14 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g8HAV5wr015790; Tue, 17 Sep 2002 03:31:09 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200209171031.g8HAV5wr015790@gw.catspoiler.org> Date: Tue, 17 Sep 2002 03:31:05 -0700 (PDT) From: Don Lewis Subject: VOP_INACTIVE() To: arch@FreeBSD.org Cc: Ian Dowse , Terry Lambert MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG VOP_INACTIVE() is currently called by vput() and vrele() after the vnode reference count has been decremented to zero. This is messy because VOP_INACTIVE() may hang onto a reference to the vnode for an extended period of time while it does cleaup I/O. Judging by the comments in vget() and vclean(), this architectural oddity appears to have adverse consequences in other parts of the code. To work around some of the brokenness, nfs_inactive() temporary bumps the reference count, but unfortunately it calls vrele() recursively to decrement the reference count which results in a panic. A few different fixes have been proposed. The first fix is to set a flag on the vnode to indicate that VOP_INACTIVE() is playing with the vnode, so the vnode should not be reused even though its reference count is zero. The second fix is to all VOP_INACTIVE() before the reference count is decremented. The main problem with this is that some of the things done in the various filesystem inactive methods may depend strongly on the reference count being zero. One example is the call to vrecycle() in ufs_inactive(). A third fix would be to split VOP_INACTIVE() into two parts, one which is called to do any I/O before the reference count is decremented, and the other which does any filesystem specific cleanup after the reference count is decremented. Opinions? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message