Date: Mon, 14 Jul 2003 22:20:09 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Mike Silbersack <silby@silby.com> Cc: Julian Elischer <julian@elischer.org> Subject: Re: 4.x mbuf binary compatibility; can it be broken? Message-ID: <200307150520.h6F5K9Ls082923@apollo.backplane.com> References: <Pine.BSF.4.21.0307141514410.40558-100000@InterJet.elischer.org> <20030714191735.Y8225@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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
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.
-Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200307150520.h6F5K9Ls082923>