From owner-freebsd-arch@FreeBSD.ORG Tue Jul 15 04:33:58 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04CEC37B401 for ; Tue, 15 Jul 2003 04:33:58 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E2D843F3F for ; Tue, 15 Jul 2003 04:33:56 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id h6FBXnw16362; Tue, 15 Jul 2003 08:33:50 -0300 Message-ID: <3F13E69D.3050001@tcoip.com.br> Date: Tue, 15 Jul 2003 08:33:49 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030702 X-Accept-Language: en-us, en, pt-br, ja MIME-Version: 1.0 To: Mike Silbersack References: <20030714164426.R8225@odysseus.silby.com> In-Reply-To: <20030714164426.R8225@odysseus.silby.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: 4.x mbuf binary compatibility; can it be broken? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2003 11:33:58 -0000 Mike Silbersack wrote: > In the process of hunting down reported panics in xl_newbuf, I've come to > the conclusion that the panics are a result of mbuf cluster refcounts > overflowing. This is not too surprising, as we use an array of chars to > store the refcounts. (-current uses ints, and doesn't have this problem.) > > It's easy enough to switch from a char to an int array in 4.x to fix the > problem there, but there is a problem: Our friendly mbuf macros (MCLALLOC > and MCLFREE) manipulate the refcount. This means that 3rd party modules > which use the macros will no longer work properly. > > Hence, the question posed on the subject line. Aside from putting hacks > in many of the mbuf functions so that they avoid reference counts growing > into the danger zone, there's no solution to the problem that I can see. > > So, what's our policy on ABI breakage for modules? It'd be nice to ignore > this problem, but the xl-related PRs filed which seem to describe this > exact problem are too numerous to ignore. (No, this isn't if_xl's fault; > it's simply a victim because it properly uses its descriptor lists, > thereby using mbuf cluster refcounts rather than packet copies as many > cheaper NICs are required to do.) I think that breaking the ABI at the winter of 4.x is a bad idea. It would be bad at it's spring, but given the seriousness of the matter, perhaps a necessity. At this point, though? Dubious proposition... -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net To avoid criticism, do nothing, say nothing, be nothing. -- Elbert Hubbard