On 20/02/14 09:03, Rusty Russell wrote:

Heinz Graalfs [off-list ref] writes:

quoted

On 29/01/14 07:31, Rusty Russell wrote:

quoted

Heinz Graalfs [off-list ref] writes:

quoted

On 23/01/14 05:51, Rusty Russell wrote:

quoted

Heinz Graalfs [off-list ref] writes:

quoted

Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th.

Hi Heinz,

           I didn't get a response on my 'break all the virtqueues' patch
series.  Could your System Z code work with this?

Rusty.

Sorry Rusty, I'm back as of today.

I applied your patch series and did some testing...

Removing a disk while reading from it mostly still ends up
in hangs as of below:

OK, we still have the problem of in-flight requests.

I think the correct answer is to drop all requests if the virtqueue
is broken:

   -	blk_cleanup_queue(vblk->disk->queue);
   +	if (virtqueue_is_broken(vblk->vq))
   +              /* Don't wait for completion, just drop queue. */
   +              blk_abandon_queue(vblk->disk->queue);

Rusty,

but blk_abandon_queue() would not solve the incomplete in-flight
requests, would it? I suppose it would avoid additional in-flight
requests similar to __blk_request_all() and passing -EIO.

Ending of asynchronous in-flight requests still cause other problems
in the host. Such problems should be handled/avoided there, I suppose.

The device is going away (or gone away!), so it shouldn't be completing
requests, right?

well, the device is gone and blk_cleanup_queue() should avoid synching 
data to disk. That is the approach of my original patch-set.

I'll try to find an alternative solution exploiting the new
virtio_break_device().

Heinz

If the device is actually broken, well, there's not much we can do.  We
could try to leak memory I suppose.

Cheers,
Rusty.