From owner-cvs-src@FreeBSD.ORG  Wed Jun  9 16:34:37 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 EA8EE16A4CE; Wed,  9 Jun 2004 16:34:37 +0000 (GMT)
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id E06A743D1D; Wed,  9 Jun 2004 16:34:37 +0000 (GMT)
	(envelope-from bmilekic@FreeBSD.org)
Received: from freefall.freebsd.org (bmilekic@localhost [127.0.0.1])
	i59GYbqb026597;	Wed, 9 Jun 2004 16:34:37 GMT
	(envelope-from bmilekic@freefall.freebsd.org)
Received: (from bmilekic@localhost)
	by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i59GYb8X026596;
	Wed, 9 Jun 2004 16:34:37 GMT
	(envelope-from bmilekic)
Date: Wed, 9 Jun 2004 16:34:37 +0000
From: Bosko Milekic <bmilekic@FreeBSD.org>
To: Nate Lawson <nate@root.org>
Message-ID: <20040609163437.GA26282@freefall.freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
cc: cvs-src@FreeBSD.org
cc: Poul-Henning Kamp <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:34:38 -0000


Nate Lawson wrote:
>The only potential remaining problem is if another thread can increment
>the refcount after the unlock and i == 0 comparison but before
>"free(foo)".  In this case, you'll free an object that is still in use.
>It's safe to hold locks across free(), that's how I handle this case.
>
>-Nate

  This is not true if the object 'foo' cannot gain a reference unless
  an existing referrer passes it its own reference, which would make
  sense.

  If there is a way for a reference to 'foo' to be acquired without
  a reference to it already being held, then that code needs to be
  fixed and wherever the other reference to 'foo' is needs to ensure
  to properly increment the reference count.

  In other words, if you see that the count has hit zero in the GOOD
  code, then you know you're the last guy to have decremented the
  reference count and the only guy left referring to the object, so
  in theory, you should be the only thing allowed to GRANT an additional
  reference to 'foo'.

  Know what I mean?

  In other words, the GOOD code should be correct.

  -Bosko