From owner-freebsd-net Tue Dec 12 14: 9:30 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 14:09:26 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 4F53537B400; Tue, 12 Dec 2000 14:09:25 -0800 (PST) Received: from bissau-13.budapest.interware.hu ([195.70.53.141] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 145xbd-0004eL-00; Tue, 12 Dec 2000 23:09:12 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A36A1D8.8297C7B8@elischer.org> Date: Tue, 12 Dec 2000 14:08:24 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin Cc: Alfred Perlstein , jasone@FreeBSD.org, net@FreeBSD.org, Bosko Milekic Subject: Re: MEXT_IS_REF broken. References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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? Hopefully there si some higher level lock or something that stops you from trying to reference an object that is having its last reference removed (otherwise how did you find it?) but never-the less, it's an issue to look at. > > > thanks, > > -Alfred > > -- > > 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 -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message