[issue1841] vfscache panic when creating many links
Venkatesh Srinivas (via DragonFly issue tracker)
sinknull at leaf.dragonflybsd.org
Fri Sep 17 04:47:12 PDT 2010
Venkatesh Srinivas <me at 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 at lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue1841>
_____________________________________________________
More information about the Bugs
mailing list