From owner-freebsd-net@FreeBSD.ORG Thu May 1 12:17:37 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F211D37B401 for ; Thu, 1 May 2003 12:17:36 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3295D43FBD for ; Thu, 1 May 2003 12:17:36 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])h41JHYww058947; Thu, 1 May 2003 15:17:34 -0400 (EDT) Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.9/8.12.1/Submit) id h41JHXXp058946; Thu, 1 May 2003 15:17:33 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) X-Authentication-Warning: angelica.unixdaemons.com: bmilekic set sender to bmilekic@unixdaemons.com using -f Date: Thu, 1 May 2003 15:17:33 -0400 From: Bosko Milekic To: Luigi Rizzo Message-ID: <20030501191733.GA58454@unixdaemons.com> References: <20030430142532.F3741@odysseus.silby.com> <20030501041210.A3514@xorpc.icir.org> <20030501170638.GA17758@unixdaemons.com> <20030501113639.B65552@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501113639.B65552@xorpc.icir.org> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org Subject: Re: Review needed: Mbuf double-free detection patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 19:17:37 -0000 On Thu, May 01, 2003 at 11:36:39AM -0700, Luigi Rizzo wrote: > On Thu, May 01, 2003 at 01:06:38PM -0400, Bosko Milekic wrote: > ... > > The reason it's done that way has to do with a bigger optimization > > than just the avoidance of the extra function call: the cache lock is > > held, as most as possible, across repeated calls to mb_free(). In > > order to implement this "as most as possible," to allow for virtually > > atomic frees in some cases, it was ripped out and done that way... if > > you can figure out a cleaner way, that would be cool, though. > > but according to the comment (and the code) that optimization > is not there yet because of issues in some of the functions > called in the body. Given that you have clearly documented what the > plan is and what the issues are, i would suggest to revert m_freem() > to use m_free() until those issues are solved. In addition to > reducing the code size, this would also reduce the risk that the > two pieces of code diverge by mistake. Well, I was going to actually complete the optimization for the cluster case (because cluster ref counts are no longer malloc'd), but now that there's a call to m_tag_destroy in the body, I don't know if it's possible at all. So what you're proposing makes sense. > cheers > luigi > > > -- > > Bosko Milekic > > bmilekic@unixdaemons.com > > bmilekic@FreeBSD.org -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org