Date: Sun, 3 Jun 2012 06:13:24 +0000 (UTC) From: Benjamin Kaduk <bjk@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: namecache documentation and locking Message-ID: <alpine.BSF.2.00.1206030605440.45500@freefall.freebsd.org> In-Reply-To: <20120603050939.GF2358@deviant.kiev.zoral.com.ua> References: <alpine.BSF.2.00.1206021946320.61817@freefall.freebsd.org> <20120603050939.GF2358@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 3 Jun 2012, Konstantin Belousov wrote: > On Sat, Jun 02, 2012 at 11:34:21PM +0000, Benjamin Kaduk wrote: >> Hi all, >> >> This caused me to take a look at the namecache functions and find not very >> much documentation of their use. I see that NetBSD has had a namecache.9 >> man page since 2001 [2], and their actual code shares its origin from 4.2 >> BSD with ours ... but our vfs_cache.c is at (CVS) revision 1.181 versus >> NetBSD's 1.88, and there are at least superficial differences between the >> two. > Superficial ? How can you judge ? Well, the first thing that came to mind was that we have struct namecache_ts that was recently added. It looks like NetBSD also has per-cpu namecache data (I just noticed). They also use explicit mutex operations on the namecache_lock as opposed to our macros around the rwlock cache_lock. I have not put in the time to tell whether these represent significant structural differences or just superficial renaming. > >> >> Is there a summary of the design/implementation somewhere that I could use That sounds like 'no'. >> as a reference, or can someone send one here? I would like to come up >> with a namecache.9 for FreeBSD's implementation. >> >> The particular question which promped my investigation is for the locking >> around cache_purge(); I was not immediately able to tell from looking at >> other consumers whether the vnode lock needs to or should be held around >> such calls. Looking at the implementation of some of the other namecache >> functions makes it seem that the lock order is vnode lock then namecache >> lock, which would suggest that holding the vnode lock across cache_purge >> would be okay, but I would like some confirmation before I use and >> 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. I was not sufficiently confident to rely on such negative documentation from code. > > 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. > It seemed so to me; thank you for confirming. > 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. I missed this, it is helpful to know. Thanks, Ben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1206030605440.45500>