On 20/02/14 09:03, Rusty Russell wrote:
Heinz Graalfs <graalfs@xxxxxxxxxxxxxxxxxx> writes:
On 29/01/14 07:31, Rusty Russell wrote:
Heinz Graalfs <graalfs@xxxxxxxxxxxxxxxxxx> writes:
On 23/01/14 05:51, Rusty Russell wrote:
Heinz Graalfs <graalfs@xxxxxxxxxxxxxxxxxx> 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.
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
