From owner-freebsd-net@FreeBSD.ORG Thu May 1 10:06:41 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 92A7637B401 for ; Thu, 1 May 2003 10:06:41 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2A8243F93 for ; Thu, 1 May 2003 10:06:40 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])h41H6dww019090; Thu, 1 May 2003 13:06:39 -0400 (EDT) Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.9/8.12.1/Submit) id h41H6c9G019089; Thu, 1 May 2003 13:06:38 -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 13:06:38 -0400 From: Bosko Milekic To: Luigi Rizzo Message-ID: <20030501170638.GA17758@unixdaemons.com> References: <20030430142532.F3741@odysseus.silby.com> <20030501041210.A3514@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501041210.A3514@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 17:06:41 -0000 On Thu, May 01, 2003 at 04:12:10AM -0700, Luigi Rizzo wrote: > as Bosko noticed, it would be a good idea to make the change to subr_mbuf.c > conditionally compiled under DIAGNOSTIC or INVARIANTS or the like. > > I was actually wondering if you have caught already any bug > with this code enabled. > > [on a side note, it is a bit depressing to see the same > code replicated twice, in m_free() and m_freem(). Couldn't > one try to make m_freem() just call m_free() in a loop and > save some code bloat ? I doubt the extra function call > would harm performance too much.] > > cheers > luigi 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. -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org