From: Michael S. Tsirkin mst@redhat.com Sent: Tuesday, May 27, 2025 1:45 AM
On Mon, May 26, 2025 at 02:40:33PM +0000, Parav Pandit wrote:
[..]
- if (blk_mq_request_started(rq) && !blk_mq_request_completed(rq))
blk_mq_complete_request(rq);- spin_unlock_irqrestore(&vq->lock, flags);
- return true;
+}
+static void virtblk_broken_device_cleanup(struct virtio_blk *vblk) {
- struct request_queue *q = vblk->disk->queue;
- if (!virtqueue_is_broken(vblk->vqs[0].vq))
return;can marking vqs broken be in progress such that 0 is already broken but another one is not, yet? if not pls add a comment explainging why.
I missed to answer this previous email.
It should not happen during surprise removal case, because surprise removal and remove() is serialized operation listed below,
virtio_pci_remove() virtio_break_device() mark N Vqs as broken.. unregister_virtio_device() virtioblk_remove()
If one attempts to unbind the pci device and once the remove() crosses the broken check, and after that if the pci device is removed (before existing virtblk_remove finishes, then yes, same hang can occur. Such thing requires an additional time out handling, which should be handled separate patch as new functionality. Since timeout handling would be additional, it won't replace the existing known surprise removal case anyway. I anticipate that it will likely reuse pieces from the proposed cleanup() function.