From owner-freebsd-net@FreeBSD.ORG Fri May 2 00:46:30 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 1045E37B401 for ; Fri, 2 May 2003 00:46:30 -0700 (PDT) Received: from mercure.vincentjardin.net (AVelizy-102-1-3-212.abo.wanadoo.fr [217.128.244.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id B92D643FBD for ; Fri, 2 May 2003 00:46:28 -0700 (PDT) (envelope-from jardin@mercure.vincentjardin.net) Received: from mercure.vincentjardin.net (localhost.vincentjardin.net [127.0.0.1])h427kQlo000391; Fri, 2 May 2003 09:46:26 +0200 (CEST) (envelope-from jardin@mercure.vincentjardin.net) Received: by mercure.vincentjardin.net (8.12.6/8.12.6/Submit) id h427kKRX000390; Fri, 2 May 2003 09:46:20 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Vincent Jardin To: Mike Silbersack , freebsd-net@freebsd.org Date: Fri, 2 May 2003 09:46:20 +0200 User-Agent: KMail/1.4.3 References: <20030502010545.U610@odysseus.silby.com> In-Reply-To: <20030502010545.U610@odysseus.silby.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200305020946.20514.vjardin@wanadoo.fr> Subject: Re: More mbuf INVARIANTS code, comments needed 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: Fri, 02 May 2003 07:46:30 -0000 It is a good idea. I do not see any problems with your patch. An esthetic comment: I would prefer to see other trivial hexadecimal values like: - 0xd0 (as in "Duh", used by stdlib/malloc()) - or 0xdeadc0de (used by kern_malloc.c:#define WEIRD_ADDR 0xdeadc0de) - or 0xdead0137, 0xdead0138, 0xdead0139, ... According to me, these values are easier to analyse when you get a panic = or=20 when you dump the memory. Regards, Vincent On Friday 02 May 2003 08:08, Mike Silbersack wrote: > Now that I have the double-free code in (under INVARIANTS), I'm > considering the attached patch as well; it fills the m_data, m_next, an= d > m_nextpkt fields with non-NULL garbage in hopes that any uses after fre= e > will be immediately fatal. > > Does anyone see problems with this, and/or other simple checks that cou= ld > be added cheaply? > > Thanks, > > Mike "Silby" Silbersack