From owner-cvs-all@FreeBSD.ORG Sat Jun 12 21:02:20 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 342EF16A4CE; Sat, 12 Jun 2004 21:02:20 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE52443D1F; Sat, 12 Jun 2004 21:02:19 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5CL0nEh096401; Sat, 12 Jun 2004 17:00:49 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5CL0n63096398; Sat, 12 Jun 2004 17:00:49 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 12 Jun 2004 17:00:48 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org In-Reply-To: <200406122047.i5CKlWin099013@repoman.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: cvs commit: src/sys/kern kern_descrip.c uipc_socket.c uipc_syscalls.c uipc_usrreq.c src/sys/net raw_cb.c raw_usrreq.c src/sys/netatm atm_socket.c src/sys/netatalk ddp_pcb.c src/sys/netgraph ng_ksocket.c src/sys/netgraph/bluetooth/socket ... X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 21:02:20 -0000 On Sat, 12 Jun 2004, Robert Watson wrote: > - Note that sofree()/sotryfree() will release the socket lock even if > they don't free the socket. Colin and Bosko have pointed out that this note should also mention sorele(), which has similar properties. If the socket is still allocated when the macro returns, sorele() will release the lock on that socket. I'm not entirely happy with the assymetric locking here, but since these calls release references to the object, I think it makes some amount of sense. Right now, I opt to have the caller manage locking so that the impact of acquiring the socket lock is visible in the caller to discourage improper calling of these APIs. We might eventually want to push locking down into these APIs, but I don't think we want to do that yet. The assertions in the functions will occasionally force slightly stronger locking than needed -- for example, it forces locks to be held in soalloc() and sodealloc() that may not actually be needed. I'll revisit this once I've got the basic locking merged. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research