Date: Mon, 14 Jul 2003 15:17:56 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Mike Silbersack <silby@silby.com> Cc: arch@freebsd.org Subject: Re: 4.x mbuf binary compatibility; can it be broken? Message-ID: <Pine.BSF.4.21.0307141514410.40558-100000@InterJet.elischer.org> In-Reply-To: <20030714164426.R8225@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 14 Jul 2003, 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. > As the user of a 3rd party driver (binary only) PLEASE don't do this.. How does it get 255+ references? > 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.) > > Thanks, > > Mike "Silby" Silbersack > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0307141514410.40558-100000>