All of lore.kernel.org
 help / color / mirror / Atom feed
From: Parav Pandit <parav@nvidia.com>
To: <mst@redhat.com>, <jasowang@redhat.com>,
	<xuanzhuo@linux.alibaba.com>, <pbonzini@redhat.com>,
	<stefanha@redhat.com>, <axboe@kernel.dk>,
	<virtualization@lists.linux.dev>, <linux-block@vger.kernel.org>
Cc: Parav Pandit <parav@nvidia.com>, <stable@vger.kernel.org>,
	<lirongqing@baidu.com>, Chaitanya Kulkarni <kch@nvidia.com>
Subject: [PATCH] virtio_blk: Fix device surprise removal
Date: Sat, 17 Feb 2024 20:08:48 +0200	[thread overview]
Message-ID: <20240217180848.241068-1-parav@nvidia.com> (raw)

When the PCI device is surprise removed, requests won't complete from
the device. These IOs are never completed and disk deletion hangs
indefinitely.

Fix it by aborting the IOs which the device will never complete
when the VQ is broken.

With this fix now fio completes swiftly.
An alternative of IO timeout has been considered, however
when the driver knows about unresponsive block device, swiftly clearing
them enables users and upper layers to react quickly.

Verified with multiple device unplug cycles with pending IOs in virtio
used ring and some pending with device.

In future instead of VQ broken, a more elegant method can be used. At the
moment the patch is kept to its minimal changes given its urgency to fix
broken kernels.

Fixes: 43bb40c5b926 ("virtio_pci: Support surprise removal of virtio pci device")
Cc: stable@vger.kernel.org
Reported-by: lirongqing@baidu.com
Closes: https://lore.kernel.org/virtualization/c45dd68698cd47238c55fb73ca9b4741@baidu.com/
Co-developed-by: Chaitanya Kulkarni <kch@nvidia.com>
Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com>
Signed-off-by: Parav Pandit <parav@nvidia.com>
---
 drivers/block/virtio_blk.c | 54 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 2bf14a0e2815..59b49899b229 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -1562,10 +1562,64 @@ static int virtblk_probe(struct virtio_device *vdev)
 	return err;
 }
 
+static bool virtblk_cancel_request(struct request *rq, void *data)
+{
+	struct virtblk_req *vbr = blk_mq_rq_to_pdu(rq);
+
+	vbr->in_hdr.status = VIRTIO_BLK_S_IOERR;
+	if (blk_mq_request_started(rq) && !blk_mq_request_completed(rq))
+		blk_mq_complete_request(rq);
+
+	return true;
+}
+
+static void virtblk_cleanup_reqs(struct virtio_blk *vblk)
+{
+	struct virtio_blk_vq *blk_vq;
+	struct request_queue *q;
+	struct virtqueue *vq;
+	unsigned long flags;
+	int i;
+
+	vq = vblk->vqs[0].vq;
+	if (!virtqueue_is_broken(vq))
+		return;
+
+	q = vblk->disk->queue;
+	/* Block upper layer to not get any new requests */
+	blk_mq_quiesce_queue(q);
+
+	for (i = 0; i < vblk->num_vqs; i++) {
+		blk_vq = &vblk->vqs[i];
+
+		/* Synchronize with any ongoing virtblk_poll() which may be
+		 * completing the requests to uppper layer which has already
+		 * crossed the broken vq check.
+		 */
+		spin_lock_irqsave(&blk_vq->lock, flags);
+		spin_unlock_irqrestore(&blk_vq->lock, flags);
+	}
+
+	blk_sync_queue(q);
+
+	/* Complete remaining pending requests with error */
+	blk_mq_tagset_busy_iter(&vblk->tag_set, virtblk_cancel_request, vblk);
+	blk_mq_tagset_wait_completed_request(&vblk->tag_set);
+
+	/*
+	 * Unblock any pending dispatch I/Os before we destroy device. From
+	 * del_gendisk() -> __blk_mark_disk_dead(disk) will set GD_DEAD flag,
+	 * that will make sure any new I/O from bio_queue_enter() to fail.
+	 */
+	blk_mq_unquiesce_queue(q);
+}
+
 static void virtblk_remove(struct virtio_device *vdev)
 {
 	struct virtio_blk *vblk = vdev->priv;
 
+	virtblk_cleanup_reqs(vblk);
+
 	/* Make sure no work handler is accessing the device. */
 	flush_work(&vblk->config_work);
 
-- 
2.34.1


             reply	other threads:[~2024-02-17 18:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-17 18:08 Parav Pandit [this message]
2024-02-18 13:27 ` [PATCH] virtio_blk: Fix device surprise removal Ming Lei
2024-02-19  3:14   ` Parav Pandit
2024-02-19  8:15     ` Michael S. Tsirkin
2024-02-19 10:39       ` Parav Pandit
2024-02-19 10:47         ` Michael S. Tsirkin
2024-02-20 12:03           ` Parav Pandit
2024-02-20 12:16             ` Michael S. Tsirkin
2024-02-20 22:05 ` Stefan Hajnoczi
2024-02-22  4:46   ` Parav Pandit
2024-02-22 15:23     ` Stefan Hajnoczi
2024-02-22 15:31       ` Michael S. Tsirkin
2024-02-22 15:38     ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240217180848.241068-1-parav@nvidia.com \
    --to=parav@nvidia.com \
    --cc=axboe@kernel.dk \
    --cc=jasowang@redhat.com \
    --cc=kch@nvidia.com \
    --cc=linux-block@vger.kernel.org \
    --cc=lirongqing@baidu.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux.dev \
    --cc=xuanzhuo@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.