svn commit: r190837 - in stable/7/sys: . contrib/pf dev/ath/ath_hal dev/cxgb kern

[Stephen McKay]

On Wednesday, 8th April 2009, Robert Watson wrote:

>On Wed, 8 Apr 2009, Stephen McKay wrote:
>
>>  MFC r187460: Add a limit on namecache entries.
>
>Obviously, having a limit is a good idea, but I wonder if we should use some 
>more mature scheme to limit entries.

When I committed r187460 back in January, Bruce Evans immediately pointed
out that a more complex version had appeared in RELENG_3 (1.38.2.3) and
had never been merged forward.  That version costs time and space for
every cache entry, while my (admittedly trivial) fix costs minimal time
and no extra space per entry.

I make no great claims for this patch.  The event that it guards against
is rarely triggered in average systems (it looks like it has been possible
to overflow the namecache since 1997) but some sort of limit is necessary
to avoid a kernel panic.  The 2x factor is arbitrary, but works in practice.

Profiling the namecache sound like a good idea, but if you want to give
it heartburn, try a directory tree full of files with 32000 links.  I don't
think it's worth putting lots of code in the main line to handle such an
"attack", so I think it's simpler to just not cache when that happens.

Cheers,

Stephen.