From owner-cvs-src@FreeBSD.ORG  Sun Oct 19 14:51:36 2003
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 17DCF16A4B3; Sun, 19 Oct 2003 14:51:36 -0700 (PDT)
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
	by mx1.FreeBSD.org (Postfix) with SMTP
	id 11C8143FAF; Sun, 19 Oct 2003 14:51:34 -0700 (PDT)
	(envelope-from dwmalone@maths.tcd.ie)
Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
          id <aa71195@salmon>; 19 Oct 2003 22:51:33 +0100 (BST)
To: Robert Watson <rwatson@FreeBSD.org>
In-reply-to: Your message of "Sun, 19 Oct 2003 17:08:09 EDT."
             <Pine.NEB.3.96L.1031019165954.4181F-100000@fledge.watson.org> 
X-Request-Do: 
Date: Sun, 19 Oct 2003 22:51:33 +0100
From: David Malone <dwmalone@maths.tcd.ie>
Message-ID: <200310192251.aa71195@salmon.maths.tcd.ie>
cc: cvs-src@FreeBSD.org
cc: src-committers@FreeBSD.org
cc: cvs-all@FreeBSD.org
cc: Kris Kennaway <kris@obsecurity.org>
Subject: Re: cvs commit: src/sys/dev/streams streams.c src/sys/kern
	kern_descrip.c kern_event.c sys_pipe.c uipc_syscalls.c
	vfs_syscalls.c src/sys/opencrypto cryptodev.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: Sun, 19 Oct 2003 21:51:36 -0000

> For example, some of the file descriptor handling during execve(), in
> kqueue_register(), unp_externalize(), the /dev/fd code, et al.  We need to
> either pick to have the file descriptor locks in the lock order before
> Giant, or after Giant, and right now we're in limbo, so Witness generates
> lock order warnings... 

The code I've been looking at is mainly syscall code, and this grab
Giant first and then grab the file descriptor lock. I don't plan
to change the lock order here, but rather avoid grabbing Giant where
it isn't needed any longer. I guess this may indirectly help if I
can reduce the number of places where Giant and the file descriptor
lock are held at the same time.

	David.