From owner-freebsd-net Mon Jun 3 15:48: 6 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 6B06137B400 for ; Mon, 3 Jun 2002 15:47:59 -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 g53MlfMR022141; Mon, 3 Jun 2002 18:47:41 -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 g53MleqI022136; Mon, 3 Jun 2002 18:47:40 -0400 (EDT) (envelope-from bmilekic) Date: Mon, 3 Jun 2002 18:47:40 -0400 From: Bosko Milekic To: Julian Elischer Cc: Archie Cobbs , Alfred Perlstein , freebsd-net@FreeBSD.ORG Subject: Re: Race condition with M_EXT ref count? Message-ID: <20020603184740.A19963@unixdaemons.com> References: <200206032143.g53Lh5c47636@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: ; from julian@elischer.org on Mon, Jun 03, 2002 at 03:08:01PM -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 First of all, this issue is non-existant in -CURRENT, where all reference counting is done via a consistent interface that provides bus-locked reference count manipulations. 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 cluster and you'll be the only candidate incrementing the ref. count, regardless of whether an interrupt comes in or not. Perhaps the real solution would be to do something like: if (ref count > 1) { do atomic inc. } else { do regular inc. } Or, alternately, do what -CURRENT does (and it's probably simpler anyway) and just make it all atomic. I'm sorry to say that I don't develop on -STABLE much anymore (namely, because I don't run it at home) so I cannot make this change any time soon. On Mon, Jun 03, 2002 at 03:08:01PM -0700, Julian Elischer wrote: > well, it's a valid problem form the point of view of some interrupt code > changing the ext reference at teh same time that some other code is > planning on incrementing it, but while Giant is in place it's not > likely to affect anything.. > > > I presume you are talking about 4.x however right? > we can presume that each manipulator has a reference so it's not going to > GA AWAY due to a zero reference being reached, so the link can be followed > safely, which just elaves the atomicity of the addition operation. > > who are the contenders? > 1/ network mid-level code? (protected by: splnet and the BGL. > Only one cpu at a time.. > > 2/ Interrupt code running at splimp > probably freeing stuff after transmit. (receivers should have > pre-allocated buffers) > > it IS possible that there could need to be an splimp() added but I am > not clear on what part the 4.4 BGL (Big Giant Lock) plays in this.. > it may make it safe... > > On Mon, 3 Jun 2002, Archie Cobbs wrote: > > > Julian Elischer writes: > > > Not denying that, just that JHB has a preliminary implementation > > > he's been showing around... > > > > > > > > this is YET ANOTHER case for the Atomic reference counting ABI that > > > > > jhb has been talking about... > > > > > > > > I was the initial person to request an atomic_t API. > > > > You guys please stop changing the subject :-) > > > > Can somebody confirm that they think this bug is real/valid? > > > > Thanks, > > -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