Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 3 Jun 2002 15:08:01 -0700 (PDT)
From:      Julian Elischer <julian@elischer.org>
To:        Archie Cobbs <archie@dellroad.org>
Cc:        Alfred Perlstein <bright@mu.org>, freebsd-net@freebsd.org
Subject:   Re: Race condition with M_EXT ref count?
Message-ID:  <Pine.BSF.4.21.0206031500400.43857-100000@InterJet.elischer.org>
In-Reply-To: <200206032143.g53Lh5c47636@arch20m.dellroad.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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
> 


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?Pine.BSF.4.21.0206031500400.43857-100000>