Re: LOR with filedesc structure and Giant

In message <Pine.NEB.3.96L.1030816101518.83755D-100000_at_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_at_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.