namecache documentation and locking
Benjamin Kaduk
bjk at freebsd.org
Sun Jun 3 06:13:24 UTC 2012
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
More information about the freebsd-hackers
mailing list