kernel deadlock

[Robert Watson]

On Tue, 29 Jul 2003, Dave Dolson wrote:

> To follow up, I've discovered that the system has exhausted its "FFS
> node" malloc type. 
> 
> >From vmstat on the core file, the "FFS node" MALLOC type is full:
>  
>  
> Memory statistics by type                          Type  Kern
>         Type  InUse MemUse HighUse  Limit Requests Limit Limit Size(s)
> ...
>      FFS node409600102400K 102400K102400K  1138048    3     0  256
> ...
> 
> The stress test is recursively creating a directory then cd'ing to it,
> trying to create 1,000,000 deep. 
> 
> You might say "don't do that", but this doesn't require any special
> priviledge, so is a potential DoS attack by any user. 
> 
> I'm wondering why the MALLOC is done with M_WAITOK; it seems like
> something which could reasonably fail. 
> 
> Or, why aren't the cached inodes being purged? 

Some problems with this have turned up in -CURRENT on large-memory
machines where some of the scaling factors have been off.  In -CURRENT, I
believe changes were introduced to bound the number of active vnodes more
rigorously at large memory sizes, and they probably need to be merged to
-STABLE.  You may want to try lowering the value of kern.maxvnodes during
the boot process -- however, the number of vnodes can exceed this max
under a number of common circumstances, so that may not be sufficient
(worth a try). 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories