Date: Thu, 09 Apr 2009 17:50:55 +1000 From: Stephen McKay <mckay@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-7@freebsd.org, Stephen McKay <mckay@FreeBSD.org> Subject: Re: svn commit: r190837 - in stable/7/sys: . contrib/pf dev/ath/ath_hal dev/cxgb kern Message-ID: <200904090750.n397otde009794@dungeon.home> In-Reply-To: <alpine.BSF.2.00.0904081500220.61921@fledge.watson.org> from Robert Watson at "Wed, 08 Apr 2009 15:02:52 %2B0100" References: <200904080430.n384UGWw043589@svn.freebsd.org> <alpine.BSF.2.00.0904081500220.61921@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200904090750.n397otde009794>