Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Jun 2009 10:58:26 +0200
From:      Andre Oppermann <andre@freebsd.org>
To:        Kip Macy <kmacy@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Sam Leffler <sam@freebsd.org>
Subject:   Re: svn commit: r194643 - head/sys/kern
Message-ID:  <4A409932.9090802@freebsd.org>
In-Reply-To: <3c1674c90906221559q66fe3934ued99694c30aa3a81@mail.gmail.com>
References:  <200906221935.n5MJZdLJ050266@svn.freebsd.org>	 <3c1674c90906221510s9b62e25w3a5d41c21bd512e1@mail.gmail.com>	 <4A40056F.4000207@freebsd.org> <3c1674c90906221559q66fe3934ued99694c30aa3a81@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A409932.9090802>