Date: Mon, 3 Jun 2002 18:47:40 -0400 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Julian Elischer <julian@elischer.org> Cc: Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, freebsd-net@FreeBSD.ORG Subject: Re: Race condition with M_EXT ref count? Message-ID: <20020603184740.A19963@unixdaemons.com> In-Reply-To: <Pine.BSF.4.21.0206031500400.43857-100000@InterJet.elischer.org>; from julian@elischer.org on Mon, Jun 03, 2002 at 03:08:01PM -0700 References: <200206032143.g53Lh5c47636@arch20m.dellroad.org> <Pine.BSF.4.21.0206031500400.43857-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020603184740.A19963>