From owner-svn-src-stable-7@FreeBSD.ORG Thu Apr 9 08:11:12 2009 Return-Path: Delivered-To: svn-src-stable-7@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E6B4106566C; Thu, 9 Apr 2009 08:11:12 +0000 (UTC) (envelope-from smckay@internode.on.net) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by mx1.freebsd.org (Postfix) with ESMTP id C18308FC08; Thu, 9 Apr 2009 08:11:10 +0000 (UTC) (envelope-from smckay@internode.on.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4FADtG3Ul20HkP/2dsb2JhbACBUsxkg3sG X-IronPort-AV: E=Sophos;i="4.40,159,1238941800"; d="scan'208";a="328782044" Received: from ppp118-208-121-15.lns4.bne4.internode.on.net (HELO dungeon.home) ([118.208.121.15]) by ipmail01.adl6.internode.on.net with ESMTP; 09 Apr 2009 17:21:35 +0930 Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.14.3/8.13.4) with ESMTP id n397otde009794; Thu, 9 Apr 2009 17:50:55 +1000 (EST) (envelope-from mckay) Message-Id: <200904090750.n397otde009794@dungeon.home> From: Stephen McKay To: Robert Watson References: <200904080430.n384UGWw043589@svn.freebsd.org> In-Reply-To: from Robert Watson at "Wed, 08 Apr 2009 15:02:52 +0100" Date: Thu, 09 Apr 2009 17:50:55 +1000 Sender: smckay@internode.on.net Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-7@freebsd.org, Stephen McKay Subject: Re: svn commit: r190837 - in stable/7/sys: . contrib/pf dev/ath/ath_hal dev/cxgb kern X-BeenThere: svn-src-stable-7@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for only the 7-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 08:11:13 -0000 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.