From owner-svn-src-all@FreeBSD.ORG Tue Jun 23 08:58:22 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 237B11065674 for ; Tue, 23 Jun 2009 08:58:22 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 815DB8FC25 for ; Tue, 23 Jun 2009 08:58:21 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 23690 invoked from network); 23 Jun 2009 08:45:46 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Jun 2009 08:45:46 -0000 Message-ID: <4A409932.9090802@freebsd.org> Date: Tue, 23 Jun 2009 10:58:26 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Kip Macy References: <200906221935.n5MJZdLJ050266@svn.freebsd.org> <3c1674c90906221510s9b62e25w3a5d41c21bd512e1@mail.gmail.com> <4A40056F.4000207@freebsd.org> <3c1674c90906221559q66fe3934ued99694c30aa3a81@mail.gmail.com> In-Reply-To: <3c1674c90906221559q66fe3934ued99694c30aa3a81@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Sam Leffler Subject: Re: svn commit: r194643 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 08:58:22 -0000 Kip Macy wrote: > As soon as >> INVARIANTS are enable the KASSERT will catch the offender red handed. > > The INVARIANTS check DTRT. i.e. fail-fast. If you're double-freeing a > valid mbuf you'll get a random crash elsewhere. There is the uncertainty whether the m_nextpkt mbuf is really referenced from somewhere else or just hangs on by accident (bug). Under INVARIANTS the response is clear. Without debug code the question is how to respond in the most useful way. The options are: 1) assume m_nextpkt is a potential memory leak and potentially risk a subtle crash if it was referenced. 2) NULL out m_nextpkt and risk a memory leak. 3) panic in any case. m_nextpkt in an m_next chain is a bug in any case and should not happen. Option 3) seems excessive. Which of option 1) and 2) do you prefer? -- Andre