From owner-cvs-all@FreeBSD.ORG Thu Feb 24 20:02:50 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6FD916A4D1 for ; Thu, 24 Feb 2005 20:02:50 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id C1CC843D55 for ; Thu, 24 Feb 2005 20:02:49 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 50880 invoked from network); 24 Feb 2005 20:02:48 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 24 Feb 2005 20:02:48 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 24 Feb 2005 14:02:47 -0600 (CST) From: Mike Silbersack To: Robert Watson In-Reply-To: Message-ID: <20050224135254.A8585@odysseus.silby.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: cvs-src@FreeBSD.org cc: Mike Silbersack cc: cvs-all@FreeBSD.org cc: src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c src/sys/sys mbuf.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2005 20:02:51 -0000 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