Venkatesh Srinivas <[email protected]> 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 <[email protected]> <http://bugs.dragonflybsd.org/issue1841> _____________________________________________________
