Date: Mon, 14 Jul 2003 19:20:19 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Julian Elischer <julian@elischer.org> Cc: arch@freebsd.org Subject: Re: 4.x mbuf binary compatibility; can it be broken? Message-ID: <20030714191735.Y8225@odysseus.silby.com> In-Reply-To: <Pine.BSF.4.21.0307141514410.40558-100000@InterJet.elischer.org> References: <Pine.BSF.4.21.0307141514410.40558-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 14 Jul 2003, Julian Elischer wrote: > 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? I don't know exactly at this point. I can reproduce the situation at will with (in kernel) test code, but I don't know what exactly causes it in the wild. Given that increasing the ref count limit is so easy, I was hoping to avoid spending time tracking down one degenerate case. :) Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030714191735.Y8225>