Date: Sun, 3 Jun 2012 08:09:39 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Benjamin Kaduk <bjk@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: namecache documentation and locking Message-ID: <20120603050939.GF2358@deviant.kiev.zoral.com.ua> In-Reply-To: <alpine.BSF.2.00.1206021946320.61817@freefall.freebsd.org> References: <alpine.BSF.2.00.1206021946320.61817@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120603050939.GF2358>