From owner-freebsd-net@FreeBSD.ORG Thu May 1 11:36:40 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 CDE5A37B407 for ; Thu, 1 May 2003 11:36:40 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EA3043FB1 for ; Thu, 1 May 2003 11:36:40 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h41IadBp065797; Thu, 1 May 2003 11:36:39 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h41Iad4i065796; Thu, 1 May 2003 11:36:39 -0700 (PDT) (envelope-from rizzo) Date: Thu, 1 May 2003 11:36:39 -0700 From: Luigi Rizzo To: Bosko Milekic Message-ID: <20030501113639.B65552@xorpc.icir.org> References: <20030430142532.F3741@odysseus.silby.com> <20030501041210.A3514@xorpc.icir.org> <20030501170638.GA17758@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030501170638.GA17758@unixdaemons.com>; from bmilekic@unixdaemons.com on Thu, May 01, 2003 at 01:06:38PM -0400 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 18:36:41 -0000 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. cheers luigi > -- > Bosko Milekic > bmilekic@unixdaemons.com > bmilekic@FreeBSD.org > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"