Date: Thu, 1 May 2003 02:26:58 -0400 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Mike Silbersack <silby@silby.com> Cc: freebsd-net@freebsd.org Subject: Re: Review needed: Mbuf double-free detection patch Message-ID: <20030501062658.GA26458@unixdaemons.com> In-Reply-To: <20030430142532.F3741@odysseus.silby.com> References: <20030430142532.F3741@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 30, 2003 at 02:35:23PM -0500, Mike Silbersack wrote: > > I'd be interested in comments on the attached patch from anyone who's been > doing work with network drivers & such. All it does is add a M_FREELIST > flag which is set whenever a mbuf is freed. If m_free or m_freem find > this flag to be set, they will panic, as this is a clear sign that the > mbuf was freed twice. (All flags are cleared whenever a mbuf is > taken off the freelist, so false M_FREELIST hits shouldn't occur.) > > The system isn't perfect, as it won't catch mbufs which are reallocated > before their second free occurs. However, it does seem to do a good job > in catching simple double-free errors, which previously caused corruption > that lead to panics in codepaths totally unrelated to the original > double-free. (One of my double-free tests without this code managed to > cause a mutex-related panic, somehow!) > > I could probably make this code test for use-after-free by checksumming > the entire mbuf when M_FREELIST is set and verifying that the checksum has > not changed when the mbuf is reallocated, but I think this code is useful > enough as it is. > > Comments? > > Thanks, This sounds like a good idea but there is a potential bogon if you enable it by default. There is a certain producer/consumer relationship with mbuf consumption in some cases and in which case you would have one thread allocating a bunch of mbufs, writing to them, etc., and another thread reclaiming the data, but not writing to it, and then freeing the mbufs. If I understand it correctly, your patch introduces a write-to-mbuf-data on free, which may force unnecessary slot invalidations... this may sound a little "cooked up," but there is certainly an effort to not write to the object being freed during free so as to not force unnecessary invalidations in the producer/consumer cases such as the one described. -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030501062658.GA26458>