Re: [PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device

[Rusty Russell <rusty@rustcorp.com.au>]

Heinz Graalfs <graalfs@linux.vnet.ibm.com> writes:
> On 29/01/14 07:31, Rusty Russell wrote:
>> Heinz Graalfs <graalfs@linux.vnet.ibm.com> writes:
>>> On 23/01/14 05:51, Rusty Russell wrote:
>>>> Heinz Graalfs <graalfs@linux.vnet.ibm.com> writes:
>>>>> 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?

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

Cheers,
Rusty.