DragonFly BSD
DragonFly bugs List (threaded) for 2010-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

[issue1841] vfscache panic when creating many links


From: "Venkatesh Srinivas \(via DragonFly issue tracker\)" <sinknull@xxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 17 Sep 2010 11:45:47 +0000

Venkatesh Srinivas <me@acm.jhu.edu> added the comment:

In the cache_nlookup() code, when we cache_alloc() a namecache structure: 
   2273 	if (new_ncp == NULL) {
   2274 		spin_unlock(&nchpp->spin);
   2275 		new_ncp = cache_alloc(nlc->nlc_namelen);
   2276 		if (nlc->nlc_namelen) {
   2277 			bcopy(nlc->nlc_nameptr, new_ncp->nc_name,
   2278 			      nlc->nlc_namelen);
   2279 			new_ncp->nc_name[nlc->nlc_namelen] = 0;
   2280 		}
   2281 		goto restart;
   2282 	}

We restart the lookup after the allocation; the restarted lookup _is_ safe 
against a null namecache ptr, the straightline path starts with a null ncp.
   2226 	new_ncp = NULL;
   2227 	nchpp = NCHHASH(hash);
   2228 restart:
   2229 	spin_lock(&nchpp->spin);

If we allow cache_alloc to return null, we could modify the lookup path to call 
cache_cleanneg() to try to get back some space, at least from negative entries, 
and then restart the lookup, at least a few times. AFAICS, there is no way to 
clean out positive entries? This doesn't solve the problem, but it does put it 
off somewhat.

More towards a solution, we could return an unresolved cache structure to the 
caller if we cannot allocate an ncp; the callers of cache_nlookup (in particular 
nlookup() itself seem to be safe against lookup failures, they just retry the 
search...

_____________________________________________________
DragonFly issue tracker <bugs@lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue1841>
_____________________________________________________




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