From owner-freebsd-net  Tue Dec 12 18: 0:46 2000
From owner-freebsd-net@FreeBSD.ORG  Tue Dec 12 18:00:43 2000
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP
	id 71E8D37B400; Tue, 12 Dec 2000 18:00:43 -0800 (PST)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id eBD20hr02079;
	Tue, 12 Dec 2000 18:00:43 -0800 (PST)
Date: Tue, 12 Dec 2000 18:00:43 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: John Baldwin <jhb@FreeBSD.ORG>
Cc: Julian Elischer <julian@elischer.org>,
	Bosko Milekic <bmilekic@technokratis.com>, net@FreeBSD.ORG,
	jasone@FreeBSD.ORG
Subject: Re: MEXT_IS_REF broken.
Message-ID: <20001212180043.N16205@fw.wintelcom.net>
References: <3A36A1D8.8297C7B8@elischer.org> <XFMail.001212151859.jhb@FreeBSD.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <XFMail.001212151859.jhb@FreeBSD.org>; from jhb@FreeBSD.ORG on Tue, Dec 12, 2000 at 03:18:59PM -0800
Sender: bright@fw.wintelcom.net
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

* John Baldwin <jhb@FreeBSD.ORG> [001212 15:19] wrote:
> 
> On 12-Dec-00 Julian Elischer wrote:
> > John Baldwin wrote:
> >> 
> >> On 12-Dec-00 Alfred Perlstein wrote:
> >> > grr...
> >> >
> >> > considering this:
> >> >
> >> >#define MEXT_IS_REF(m) ((m)->m_ext.ref_cnt->refcnt > 1)
> >> >
> >> >#define MEXT_REM_REF(m) do {                        \
> >> >     KASSERT((m)->m_ext.ref_cnt->refcnt > 0, ("m_ext refcnt < 0"));  \
> >> >     atomic_subtract_long(&((m)->m_ext.ref_cnt->refcnt), 1);     \
> >> > } while(0)
> >> >
> >> > this:
> >> >
> >> >#define MEXTFREE(m) do {                        \
> >> >     struct mbuf *_mmm = (m);                    \
> >> >                                     \
> >> >     if (MEXT_IS_REF(_mmm))                      \
> >> >         MEXT_REM_REF(_mmm);                 \
> >> >
> >> >
> >> > is not mpsafe.  we _NEED_ some type that allows atomic dec and test
> >> > for 0.
> >> 
> >> http://www.FreeBSD.org/~jhb/patches/refcount.patch
> > 
> > this is great but if I understand it, there is a hole...
> > the operations are atomic, but if teh count is 1
> > and the release and aquire are called at around the same time,
> > then thre are two possibilities..
> > the value goes 1 -> 2 -> 1  (this is ok)
> > the value goes 1 -> 0 -> 1  ( this is NOT ok)
> > the aquire calls        atomic_add_acq_int(count, 1);
> > 
> > which by my reading of the code last week, compiles down to 
> >       lock ; addl  (mumble)
> > 
> > if the value that the aquire finds is 0 then it should fail and return 
> > without incrementing.. the returned value of 0 for the other processor
> > will cause it to garbage collect the  object in a very sort amount of time
> > so trying to use it is a bad idea.
> > 
> > 
> > Am I missing something here?
> 
> Yes, I think you are.  A CPU can't magically obtain a reference to something in
> order to bump the refcount in the 1 -> 0 -> 1 case.  If you aren't doing things
> with the object w/o holding a reference count first, then where will cpu B get
> the reference to know to do the refcount_acquire() from?

You're correct, you need the higher level lock to do this operation.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message