Date: Wed, 9 Jun 2004 09:33:51 -0700 (PDT) From: Nate Lawson <nate@root.org> To: Bosko Milekic <bmilekic@FreeBSD.org> Cc: "M. Warner Losh" <imp@bsdimp.com> Subject: Re: cvs commit: src/sys/kern kern_proc.c Message-ID: <20040609092837.H85944@root.org> In-Reply-To: <20040609161818.GA25348@freefall.freebsd.org> References: <20040609161818.GA25348@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 9 Jun 2004, Bosko Milekic wrote:
> >Poul-Henning wrote:
> >: GOOD:
> >:
> >: LOCK(foo->lock)
> >: i = --foo->refcount;
> >: UNLOCK(foo->lock)
> >: if (i == 0)
> >: destroy(foo);
> >:
>
> The GOOD code does not suffer from this problem. Here is a way to
> handle this sort of race if your reference counter is instead
> manipulated atomically (as opposed to protected by a mutex):
> [From Mbuf-related code]
>
> MEXT_REM_REF(m); /* Atomic decrement of m->m_ext.ref_cnt */
> if (atomic_cmpset_int(m->m_ext.ref_cnt, 0, 1)) {
> /* Do the free here... */
> }
> return;
This may have a race unless the refcount increment path is done correctly:
1:atomic_int--
1:atomic_cmpset_int == 0 (yes, get ready to free it)
2:atomic_cmpset_int == 0 (yes, object was in process of teardown)
2:create new object, refcount = 1
This assumes it's ok to have two objects of the same type in existence at
the same time also (one being torn down while the other is created). Code
that accesses an object must make sure it's locked separately.
-Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040609092837.H85944>