From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 3 06:13:24 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 B44C81065672 for ; Sun, 3 Jun 2012 06:13:24 +0000 (UTC) (envelope-from bjk@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7FF248FC15; Sun, 3 Jun 2012 06:13:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q536DOFZ062227; Sun, 3 Jun 2012 06:13:24 GMT (envelope-from bjk@freebsd.org) Received: from localhost (bjk@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) with ESMTP id q536DOce062212; Sun, 3 Jun 2012 06:13:24 GMT (envelope-from bjk@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bjk owned process doing -bs Date: Sun, 3 Jun 2012 06:13:24 +0000 (UTC) From: Benjamin Kaduk To: Konstantin Belousov In-Reply-To: <20120603050939.GF2358@deviant.kiev.zoral.com.ua> Message-ID: References: <20120603050939.GF2358@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 06:13:24 -0000 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