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> In-Reply-To: <XFMail.001212151859.jhb@FreeBSD.org>; from jhb@FreeBSD.ORG on Tue, Dec 12, 2000 at 03:18:59PM -0800 References: <3A36A1D8.8297C7B8@elischer.org> <XFMail.001212151859.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001212180043.N16205>