Date: Thu, 24 Feb 2005 14:02:47 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c src/sys/sys mbuf.h Message-ID: <20050224135254.A8585@odysseus.silby.com> In-Reply-To: <Pine.NEB.3.96L.1050224102854.95733H-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1050224102854.95733H-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 Feb 2005, Robert Watson wrote: > > On Fri, 28 Mar 2003, Mike Silbersack wrote: > >> Add the m_defrag routine, as discussed on committers@. This >> incarnation should address the concerns of all in the discussion, >> and keeps statistics which show how much it is used. > > I just started tracking a bug report from Peter Holm in which if_rl free's > an already free'd mbuf, and tracked it back to the following problem: when > you went through and adapted various drivers to use m_defrag(), two bugs > were introduced: I don't see any flaw in if_rl's use of m_defrag, please be more specific as to what the error is. > (1) Callers of m_defrag() did not properly handle the case where > m_defrag() would return a new mbuf cluster as the head. Specifically, > on encapsulation failure, they might requeue the old head in the ifnet > queue. m_defrag ALWAYS returns a new mbuf cluster as the head! > (2) Callers of m_defrag() did not properly handle the case where > m_defrag() would return NULL due to mbuf exhaustion. Specifically, on > encapsulation failure in the case where m_defrag() fails, they might > attempt to enqueue a NULL mbuf pointer or a free'd mbuf pointer into > the ifnet queue. Sounds possible, we'll have to do a sweep for this. Alternately, we could ask that people enable the MBUF_STRESS_TEST option and try running various netperf tests with kern.ipc.m_defragrandomfailures=1 and with net.inet.ip.mbuf_frag_size=-1 and -2. Those tests should be sufficient to expose any bugs in m_defrag usage. Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050224135254.A8585>