From owner-freebsd-fs@FreeBSD.ORG Tue Dec 7 11:36:23 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38B7816A4D0; Tue, 7 Dec 2004 11:36:23 +0000 (GMT) Received: from saeab.se (ture.saeab.se [213.80.3.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC13E43D60; Tue, 7 Dec 2004 11:36:21 +0000 (GMT) (envelope-from thn@saeab.se) Received: from [10.0.1.32] (omar.int.saeab.se [10.0.1.32]) by saeab.se (8.13.1/8.13.1) with ESMTP id iB7BaFgM046345; Tue, 7 Dec 2004 12:36:15 +0100 (CET) (envelope-from thn@saeab.se) Message-ID: <41B595AF.7050602@saeab.se> Date: Tue, 07 Dec 2004 12:36:15 +0100 From: Thomas Nystrom Organization: Sv. Aktuell Elektronik AB User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: sv,en MIME-Version: 1.0 To: Alexander Kabaev References: <41B0C899.C005AE1E@saeab.se> <20041206205628.GA3309@freefall.freebsd.org> <41B4D832.2D886E86@saeab.se> <20041206231347.GA18156@freefall.freebsd.org> In-Reply-To: <20041206231347.GA18156@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on ture.saeab.se X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (saeab.se [213.80.3.133]); Tue, 07 Dec 2004 12:36:20 +0100 (CET) cc: freebsd-fs@FreeBSD.org Subject: Re: Dead vnode locking against itself X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 11:36:23 -0000 Alexander Kabaev wrote: >=20 > Unless I am reading sources wrong, the scenario you describe should not= > happen. vgonel resets the vnode type to VBAD just before releasing vnod= e > locks for the last time and vtryrecycle avoids calling vgonel on vnodes= > with that type: >=20 > if (vp->v_type !=3D VBAD) { > VOP_UNLOCK(vp, 0, td); =20 > vgonel(vp, td); > VI_LOCK(vp); > } else > VOP_UNLOCK(vp, 0, td); >=20 > The vnode data below shows that vnode has a type of VDIR and evidently = its > v_op is set to dead_vnodeops. At the same time, v_tag is "none", which > suggests that vnode has been processed by vclean already, but vgonel ha= d > not yet have a chance to update vnode's type. Just out of curiosity, ca= n you > try your code with VI_UNLOCK(vp);/VI_LOCK(vp); pair removed from the > vgonel function around line 294? This is the only place where vnode int= erlock > is released after vclean completes and before vgonel sets the vnode typ= e. > There is no point in unlocking the interlock just to lock it again > immediately anyway. Ok, I missed that VBAD setting. Then I assume that it is arla that is=20 playing around with nodes after it has released via vgonel(). I have=20 seen other indications of that..... /thn --=20 --------------------------------------------------------------- Svensk Aktuell Elektronik AB Thomas Nystr=F6m Box 10 Phone: +46 8 35 92 85 S-191 21 Sollentuna Fax: +46 8 35 92 86 Sweden Email: thn@saeab.se ---------------------------------------------------------------