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

[Heinz Graalfs <graalfs@linux.vnet.ibm.com>]

On 20/02/14 09:03, Rusty Russell wrote:
> 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?

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