cvs commit: src/sys/geom geom_disk.c

[Poul-Henning Kamp]

In message <20030514124835.GE4390 at wantadilla.lemis.com>, "Greg 'groggy' Lehey" 
writes:
>
>--h56sxpGKRmy85csR
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>
>On Wednesday, 14 May 2003 at 13:37:59 +0200, Poul-Henning Kamp wrote:
>> In message <20030514081041.GD4390 at wantadilla.lemis.com>, "Greg 'groggy' Lehey"
>> writes:
>>
>>> malloc() of "16" with the following non-sleepablelocks held:
>>> exclusive sleep mutex g_xup r = 0 (0xc8612ca8) locked @ /src/FreeBSD/5-CURRENT-ZAPHOD/src/sys/geom/geom_io.c:363
>>
>> This is a problem, you cannot sleep in the primary I/O path (ie: strategy()
>> and done()), if you sleep in the I/O path, you stop all I/O processing
>> and if the system needs to page something out to make the ram available
>> to you, you have a deadlock.
>
>I wasn't sleeping.

I'm pretty sure it is in vinum, the mute is "g_xup", which means that
it is in a "done" function.  Are you sure you don't have any 
malloc(..., M_WAITOK) calls ?

>> You have to stop sending I/Os, wait for the ones you have sent to
>> come back, then you can close.
>
>They won't complete if the drive has gone away.

Then that is a device-driver error.

The device driver _should_ to call disk_destroy() until it has
returned all outstanding bio's (with an error most likely), but
provided that it stays inside certain boundaries, it can get
away with this, but it is _never_ allowed to just drop a bio
on the floor, even if the device has disappeared.


-- 
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.