Date: Mon, 14 Jul 2003 16:53:01 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: arch@freebsd.org Subject: 4.x mbuf binary compatibility; can it be broken? Message-ID: <20030714164426.R8225@odysseus.silby.com>
next in thread | raw e-mail | index | archive | help
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.) Thanks, Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030714164426.R8225>