Code is added to the remove callback to verify if a device was lost. In case of a device loss further request queueing should be prevented by setting appropriate queue flags prior to invoking del_gendisk(). Blocking of request queueing leads to appropriate I/O errors when data are tried to be synched. Trying to synch data to a lost block device doesn't make too much sense.
If the current remove callback was triggered due to an unregister driver, and the surprize_removal is not already set (although the actual device is already gone, e.g. virsh detach), del_gendisk() would be triggered resulting in a hang. This is a weird situation, and most likely not 'serializable'. Signed-off-by: Heinz Graalfs <[email protected]> --- drivers/block/virtio_blk.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 2d43be4..0f64282 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -875,6 +875,7 @@ static void virtblk_remove(struct virtio_device *vdev) { struct virtio_blk *vblk = vdev->priv; int index = vblk->index; + unsigned long flags; int refc; /* Prevent config work handler from accessing the device. */ @@ -882,6 +883,14 @@ static void virtblk_remove(struct virtio_device *vdev) vblk->config_enable = false; mutex_unlock(&vblk->config_lock); + if (vdev->surprize_removal) { + spin_lock_irqsave(vblk->disk->queue->queue_lock, flags); + queue_flag_set(QUEUE_FLAG_DYING, vblk->disk->queue); + queue_flag_set(QUEUE_FLAG_NOMERGES, vblk->disk->queue); + queue_flag_set(QUEUE_FLAG_NOXMERGES, vblk->disk->queue); + spin_unlock_irqrestore(vblk->disk->queue->queue_lock, flags); + } + del_gendisk(vblk->disk); blk_cleanup_queue(vblk->disk->queue); -- 1.8.3.1 _______________________________________________ Virtualization mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/virtualization
