From owner-freebsd-net Mon Jun 3 23: 0:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 4EB6137B405 for ; Mon, 3 Jun 2002 23:00:06 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id WAA83758; Mon, 3 Jun 2002 22:54:40 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g545rXH49446; Mon, 3 Jun 2002 22:53:33 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206040553.g545rXH49446@arch20m.dellroad.org> Subject: Re: Race condition with M_EXT ref count? In-Reply-To: <20020603193651.A29296@unixdaemons.com> "from Bosko Milekic at Jun 3, 2002 07:36:51 pm" To: Bosko Milekic Date: Mon, 3 Jun 2002 22:53:33 -0700 (PDT) Cc: Archie Cobbs , Julian Elischer , Alfred Perlstein , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bosko Milekic writes: > > > Secondly, this may not be as much of a problem as you may think. > > > Particularly if you consider the m_split() case, for example. For > > > example, if you're calling m_split() on an mbuf chain that may refer > > > to cluster(s) where none of the clusters has a ref. count greater than > > > 1 -- which is usually the case anyway -- then this is fine; since you > > > have posession of the chain referring to those clusters, and > > > presumably the chain isn't sitting in some queue somewhere (if it is, > > > you'd have to be under the protection of that queue anyway - splimp() > > > or whatever), then you're the only one who has posession of that > > > > The *chain* won't be sitting in a queue, but there may be a different > > mbuf in a queue somehwere that points to the same cluster. > > I did say "if the refcount is exactly 1" !!!! (which is often the > case in there). Oops, sorry.. right, if the ref count is one there can be no race. > > Since mid-level code only increments the ref count, I think the > > worst that can happen is the ref count is incorrectly too high, > > which could only cause a memory leak rather than a crash. > > No, the worse case is that it is too low. > > increment: > > read > inc > write > > two increments, unprotected: Yes, you are right.. I was thinking that mbuf's were only free'd in interrupt handlers rather than allocated. If they are also allocated then the double-free race happens. We cannot assume that they aren't so this is indeed a more serious, if rare, bug. Re: the -stable patch. I agree we need a more general MFC/cleanup of some of the mbuf improvements from -current into -stable. If I find time perhaps I'll do that as well, but in a separate patch. For the present time, I'll commit this once 4.6-REL is done. Thanks for your comments. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message