DragonFly BSD
DragonFly kernel List (threaded) for 2005-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

namecache: locks and races

From: Richard Nyberg <rnyberg@xxxxxxxx>
Date: Wed, 09 Feb 2005 16:11:45 +0100

Hello Matt,

I'm making very good progress on my AFS port, but I still I have some
questions about the namecache.

Is it always risk for deadlock when trying to lock more than one ncp?
or are there some situations that are safe? IIRC in the traditional
BSD namecache it's safe to lock a child when you have locked the parent.

I don't quite understand the following snippet from kern_rename.
Could you explain the different cases and why they're safe?

	 * relock the source ncp
	if (cache_lock_nonblock(fromnd->nl_ncp) == 0) {
		cache_resolve(fromnd->nl_ncp, fromnd->nl_cred);
	} else if (fromnd->nl_ncp > tond->nl_ncp) {
		cache_resolve(fromnd->nl_ncp, fromnd->nl_cred);
	} else {
		cache_resolve(fromnd->nl_ncp, fromnd->nl_cred);
		cache_resolve(tond->nl_ncp, tond->nl_cred);
	fromnd->nl_flags |= NLC_NCPISLOCKED;

Also, I've noticed that it's quite easy to provoke a livelock situation
between cache_resolve and cache_inval. When I run the arla test suite
there are lot of activity going on in directories like these:

What happens quite frequently is that nnpfs receives a callback on
/afs/su.se/home and proceeds to do cache_inval_vp(vp, CINV_CHILDREN)
on it. If we're unlucky cache_resolve and cache_inval competes
to (un)resolve and I get tons and tons of "had ro recurse on home" in
syslog. Sometimes the live lock breaks by me just starting a new process,
sometimes I have to kill the process that's doing cache_resolve.

The callback nnpfs gets is a message just telling it that the contents
of a directory may have changed. Is the above call to cache_inval_vp
the right thing to do?

Thanks in advance,

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]