From owner-freebsd-current@FreeBSD.ORG  Sat Aug 16 13:18:46 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 09F4437B401; Sat, 16 Aug 2003 13:18:46 -0700 (PDT)
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id E9F4D43F75; Sat, 16 Aug 2003 13:18:44 -0700 (PDT)
	(envelope-from phk@phk.freebsd.dk)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
	by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h7GKIhlX022300;
	Sat, 16 Aug 2003 22:18:43 +0200 (CEST)
	(envelope-from phk@phk.freebsd.dk)
To: Robert Watson <rwatson@freebsd.org>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Sat, 16 Aug 2003 10:25:57 EDT."
             <Pine.NEB.3.96L.1030816101518.83755D-100000@fledge.watson.org> 
Date: Sat, 16 Aug 2003 22:18:43 +0200
Message-ID: <22299.1061065123@critter.freebsd.dk>
cc: current@freebsd.org
cc: Kris Kennaway <kris@obsecurity.org>
Subject: Re: LOR with filedesc structure and Giant 
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2003 20:18:46 -0000

In message <Pine.NEB.3.96L.1030816101518.83755D-100000@fledge.watson.org>, Robe
rt Watson writes:
>
>On Sat, 16 Aug 2003, Poul-Henning Kamp wrote:
>
>> >> The problem seems to be due to select() being called on the /dev/null
>> >> device, and it is holding the filedesc lock when it reaches
>> >> PICKUP_GIANT() in spec_poll.
>> >
>> >Yeah, this is pretty much the same issue you've been bumping into for a
>> >bit -- we hold filedesc lock over select(), which means every object we
>> >poll can't grab a lock that either comes before the file descriptor lockin
>> >the lock order, or that might sleep.
>> 
>> Doesn't this effectively doom any attempt at getting rid af Giant from
>> below ? 
>
>I have mixed feelings about our current strategy.  [...]

Well, I was thinking more of the work I have been doing trying to
put drivers and GEOM outside Giant ("starting from the bottom").

At one point we have to say "Well, the locks we have above are solid,
but we need to drop Giant below here" but if Witness sees a
PICKUP_GIANT() as an acquisition of Giant, rather than as a
resumption of Giant, this clearly does not work.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.