4.x mbuf binary compatibility; can it be broken?
Julian Elischer
julian at elischer.org
Mon Jul 14 15:18:07 PDT 2003
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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>
More information about the freebsd-arch
mailing list