From owner-freebsd-arch@FreeBSD.ORG Tue Jul 15 23:21:29 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A3C537B404 for ; Tue, 15 Jul 2003 23:21:29 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BF3343F85 for ; Tue, 15 Jul 2003 23:21:28 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38lc1c9.dialup.mindspring.com ([209.86.5.137] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19cffG-0002ok-00; Tue, 15 Jul 2003 23:21:23 -0700 Message-ID: <3F14EEA6.4AA8684C@mindspring.com> Date: Tue, 15 Jul 2003 23:20:22 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon References: <200307150520.h6F5K9Ls082923@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a40e6fd06d60f4d00616125dde666ef6232601a10902912494350badd9bab72f9c350badd9bab72f9c cc: arch@freebsd.org cc: Mike Silbersack cc: Julian Elischer Subject: Re: 4.x mbuf binary compatibility; can it be broken? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2003 06:21:29 -0000 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