4.x mbuf binary compatibility; can it be broken?

[Terry Lambert]

Matthew Dillon wrote:
>     It would be a good idea to make sure it isn't a runaway ref count.
> 
>     I may be missing something, but I don't see how the ref count could
>     possibly reach 255 under any circumstances.  mbufs using an mbuf
>     cluster (M_EXT with ext_ref == NULL) bump the ref count, and
>     duplicating an mbuf bumps the underlying cluster's ref count,
>     and splitting an mbuf bumps the ref count, and that is pretty much it.
> 
>     Only m_copym() or m_copypacket() have any chance of legitimately
>     increasing the ref count beyond 255.  Only a KASSERT() will tell us
>     who the likely candidate is.  It could very well be that a ref count
>     is being lost somewhere.

It should be possible to do this in a number of ways, assuming
you are sending the same data out to multiple clients, in
response to identical requests.

It's really unlikely, though, and would require specific intent
to get it that way.  I agree with your suggestion for a KASSERT()
on the increment so if it overflows, it crashes the caller.  It's
a really bad idea to hide an error like this, unless you can
actually explain why the reference count is going so high in the
first place.

-- Terry