From owner-freebsd-net Tue Dec 12 15:19:58 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 15:19:55 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 8A7A837B400; Tue, 12 Dec 2000 15:19:55 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBCNJjE01820; Tue, 12 Dec 2000 15:19:45 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.0) id eBCNIx120971; Tue, 12 Dec 2000 15:18:59 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3A36A1D8.8297C7B8@elischer.org> Date: Tue, 12 Dec 2000 15:18:59 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Julian Elischer Subject: Re: MEXT_IS_REF broken. Cc: Bosko Milekic , net@FreeBSD.ORG, jasone@FreeBSD.ORG, Alfred Perlstein Sender: jhb@foo.osd.bsdi.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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? -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message