Date: Tue, 15 Jul 2003 23:20:22 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Julian Elischer <julian@elischer.org> Subject: Re: 4.x mbuf binary compatibility; can it be broken? Message-ID: <3F14EEA6.4AA8684C@mindspring.com> References: <Pine.BSF.4.21.0307141514410.40558-100000@InterJet.elischer.org> <200307150520.h6F5K9Ls082923@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F14EEA6.4AA8684C>