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 <graalfs@xxxxxxxxxxxxxxxxxx>
---
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
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
