From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 3 05:09:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F318D106566B; Sun, 3 Jun 2012 05:09:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 747358FC0A; Sun, 3 Jun 2012 05:09:45 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q5359e5Z014776; Sun, 3 Jun 2012 08:09:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q5359dgF082040; Sun, 3 Jun 2012 08:09:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5359dNZ082039; Sun, 3 Jun 2012 08:09:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 3 Jun 2012 08:09:39 +0300 From: Konstantin Belousov To: Benjamin Kaduk Message-ID: <20120603050939.GF2358@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yZITfl9WLeKOcFOX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: namecache documentation and locking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 05:09:47 -0000 --yZITfl9WLeKOcFOX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 02, 2012 at 11:34:21PM +0000, Benjamin Kaduk wrote: > Hi all, >=20 > My colleague recently pointed out to me that I was calling vgone() when I= =20 > probably wanted to be using cache_purge() (as is done for implementations= =20 > of this OS-specific function in other BSDs [1]). >=20 > This caused me to take a look at the namecache functions and find not ver= y=20 > much documentation of their use. I see that NetBSD has had a namecache.9= =20 > man page since 2001 [2], and their actual code shares its origin from 4.2= =20 > BSD with ours ... but our vfs_cache.c is at (CVS) revision 1.181 versus= =20 > NetBSD's 1.88, and there are at least superficial differences between the= =20 > two. Superficial ? How can you judge ? >=20 > Is there a summary of the design/implementation somewhere that I could us= e=20 > as a reference, or can someone send one here? I would like to come up=20 > with a namecache.9 for FreeBSD's implementation. >=20 > The particular question which promped my investigation is for the locking= =20 > around cache_purge(); I was not immediately able to tell from looking at= =20 > other consumers whether the vnode lock needs to or should be held around= =20 > such calls. Looking at the implementation of some of the other namecache= =20 > functions makes it seem that the lock order is vnode lock then namecache= =20 > lock, which would suggest that holding the vnode lock across cache_purge= =20 > would be okay, but I would like some confirmation before I use and=20 > document it as such. Vnode lock is not needed around cache_purge(). This is in fact documented by not making asserts for lock ownership inside the function. The cache_purge() does not operate on any fs-specific data associated with the vnode, and the data it does operate on is protected by namecache rwlock. The only guarantee which cache_purge() needs from its caller is that passed vnode pointer remains valid for duration of the call, which is normally ensured by holding the vnode, often implicitely. The order between namecache rwlock and vnode lock is obvious, since vnode lock is lockmgr/sleepable. On the other hand, vnode interlock is after namecache rwlock. --yZITfl9WLeKOcFOX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/K8ZMACgkQC3+MBN1Mb4g2SQCgwyQLmW5x1SqBzRJcj54Lm2Ji 8ysAnisOdjEwdKjpUweFKqbnTUDlYKwJ =s5K0 -----END PGP SIGNATURE----- --yZITfl9WLeKOcFOX--