From owner-cvs-src@FreeBSD.ORG  Wed Jun  9 16:33:51 2004
Return-Path: <owner-cvs-src@FreeBSD.ORG>
Delivered-To: cvs-src@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 82D1E16A4CE
	for <cvs-src@FreeBSD.org>; Wed,  9 Jun 2004 16:33:51 +0000 (GMT)
Received: from root.org (root.org [67.118.192.226])
	by mx1.FreeBSD.org (Postfix) with SMTP id 5669D43D39
	for <cvs-src@FreeBSD.org>; Wed,  9 Jun 2004 16:33:51 +0000 (GMT)
	(envelope-from nate@root.org)
Received: (qmail 86164 invoked by uid 1000); 9 Jun 2004 16:33:51 -0000
Date: Wed, 9 Jun 2004 09:33:51 -0700 (PDT)
From: Nate Lawson <nate@root.org>
To: Bosko Milekic <bmilekic@FreeBSD.org>
In-Reply-To: <20040609161818.GA25348@freefall.freebsd.org>
Message-ID: <20040609092837.H85944@root.org>
References: <20040609161818.GA25348@freefall.freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: cvs-src@FreeBSD.org
cc: phk@phk.freebsd.dk
cc: src-committers@FreeBSD.org
cc: cvs-all@FreeBSD.org
cc: "M. Warner Losh" <imp@bsdimp.com>
Subject: Re: cvs commit: src/sys/kern kern_proc.c
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jun 2004 16:33:51 -0000

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