From owner-cvs-src@FreeBSD.ORG Wed Jun 9 16:25:05 2004 Return-Path: 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 750A116A4CE; Wed, 9 Jun 2004 16:25:05 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8714943D45; Wed, 9 Jun 2004 16:25:04 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id i59GP1kM051313; Wed, 9 Jun 2004 17:25:01 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i59GP0ON034344; Wed, 9 Jun 2004 17:25:00 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Poul-Henning Kamp In-Reply-To: <53418.1086773585@critter.freebsd.dk> References: <53418.1086773585@critter.freebsd.dk> Content-Type: text/plain Message-Id: <1086798299.12306.3.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 09 Jun 2004 17:25:00 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 16:25:05 -0000 On Wed, 2004-06-09 at 10:33, Poul-Henning Kamp wrote: > In message <200406090929.i599T8h6065944@repoman.freebsd.org>, Poul-Henning Kamp > writes: > > > > Modified files: > > sys/kern kern_proc.c > > Log: > > Fix a race in destruction of sessions. > > Not to pick on anybody, but this is a perfect example of getting locking > almost right: > > BAD: > > LOCK(foo->lock) > foo->refcount--; > UNLOCK(foo->lock) > if (foo->refcount == 0) > destroy(foo); > > GOOD: > > LOCK(foo->lock) > i = --foo->refcount; > UNLOCK(foo->lock) > if (i == 0) > destroy(foo); Isn't there still a race in the GOOD case here if somone takes a new reference, incrementing refcount after the UNLOCK(foo->lock)?