From owner-freebsd-net Mon Jun 3 16:37:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by hub.freebsd.org (Postfix) with ESMTP id 38E7137B401 for ; Mon, 3 Jun 2002 16:37:08 -0700 (PDT) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.3/8.12.1) with ESMTP id g53NapMR030131; Mon, 3 Jun 2002 19:36:51 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.3/8.12.1/Submit) id g53NapqZ030129; Mon, 3 Jun 2002 19:36:51 -0400 (EDT) (envelope-from bmilekic) Date: Mon, 3 Jun 2002 19:36:51 -0400 From: Bosko Milekic To: Archie Cobbs Cc: Julian Elischer , Alfred Perlstein , freebsd-net@FreeBSD.ORG Subject: Re: Race condition with M_EXT ref count? Message-ID: <20020603193651.A29296@unixdaemons.com> References: <20020603184740.A19963@unixdaemons.com> <200206032301.g53N1To48300@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200206032301.g53N1To48300@arch20m.dellroad.org>; from archie@dellroad.org on Mon, Jun 03, 2002 at 04:01:29PM -0700 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 On Mon, Jun 03, 2002 at 04:01:29PM -0700, Archie Cobbs wrote: > 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). > 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: count initially: 1 read 1 inc 1->2 read 1 write 2 inc 1->2 write 2 count finally: 2 (it should be 3 now) Two frees will now result in the cluster being freed instead of 3. The final free will be bogus. > There's not way for the ref count to be too low, or for the cluster > to be free'd twice, because all decrements are protected by splimp(). > > However, once you start adding in custom code then we may not be > so lucky.. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message