From: Sergii Ushakov <sergiiushakov@google.com>
To: mst@redhat.com, axboe@kernel.dk, stefanha@redhat.com, hch@lst.de
Cc: virtualization@lists.linux.dev, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, jasowang@redhat.com,
xuanzhuo@linux.alibaba.com, eperezma@redhat.com,
pbonzini@redhat.com, sergiiushakov@google.com
Subject: [PATCH v4] virtio-blk: clamp max_segments to virtqueue ring size
Date: Fri, 18 Sep 2026 15:51:20 +0200 [thread overview]
Message-ID: <20260918135120.1261150-1-sergiiushakov@google.com> (raw)
In-Reply-To: <20260918083557-mutt-send-email-mst@kernel.org>
In virtblk_add_req(), each request consumes 2 extra descriptors (out_hdr
and in_hdr) in addition to the data scatter-gather segments.
When a hypervisor (e.g. QNX Hypervisor) advertises VIRTIO_BLK_F_SEG_MAX
with seg_max = 1024 alongside a 1024-entry split ring (vring.num = 1024)
and VIRTIO_RING_F_INDIRECT_DESC disabled, lim->max_segments is set to
1024. When the block layer submits requests with 1023 or 1024 data
segments, total_sg reaches 1025 or 1026. This exceeds vring.num (1024),
causing virtqueue_add_split() to return -ENOSPC and permanently wedge
the blk-mq queue.
Furthermore, the Virtio specification (2.7.5.3.1) requires that a
descriptor chain never exceed the Queue Size, and virtqueue_add_split()
falls back to direct descriptors if indirect table allocation fails.
Fix this by:
1. Rejecting queues with ring_size < 3 at probe, or
ring_size < (queue_max_segments + 2) during resume/reset recovery in
init_vq().
2. Unconditionally clamping sg_elems to (ring_size - 2) across all
virtqueues in virtblk_read_limits().
Fixes: 0864b79a1533 ("virtio: block: dynamic maximum segments")
Signed-off-by: Sergii Ushakov <sergiiushakov@google.com>
---
Changes in v4:
- Add Fixes tag.
- Add code comments in init_vq() documenting the constants 3 and + 2.
drivers/block/virtio_blk.c | 44 +++++++++++++++++++++++++++++++++++++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 32bf3ba07a9d..cafca309b4d0 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -1021,6 +1021,30 @@ static int init_vq(struct virtio_blk *vblk)
goto out;
for (i = 0; i < num_vqs; i++) {
+ unsigned int ring_size = virtqueue_get_vring_size(vqs[i]);
+ /*
+ * Each request consumes 2 extra descriptors (out_hdr and
+ * in_hdr) in addition to the data segments.
+ *
+ * At initial probe (!vblk->disk), each virtqueue must fit at
+ * least 1 data segment + 2 header descriptors (3).
+ * On resume/recovery (vblk->disk), each virtqueue must fit the
+ * existing queue_max_segments() + 2 header descriptors.
+ */
+ unsigned int min_ring_size = 3;
+
+ if (vblk->disk)
+ min_ring_size = queue_max_segments(vblk->disk->queue) + 2;
+
+ if (ring_size < min_ring_size) {
+ dev_err(&vdev->dev,
+ "virtqueue %u ring size %u is smaller than minimum %u\n",
+ i, ring_size, min_ring_size);
+ vdev->config->del_vqs(vdev);
+ err = -EINVAL;
+ goto out;
+ }
+
spin_lock_init(&vblk->vqs[i].lock);
vblk->vqs[i].vq = vqs[i];
}
@@ -1253,7 +1277,7 @@ static int virtblk_read_limits(struct virtio_blk *vblk,
u16 min_io_size;
u8 physical_block_exp, alignment_offset;
size_t max_dma_size;
- int err;
+ int err, i;
/* We need to know how many segments before we allocate. */
err = virtio_cread_feature(vdev, VIRTIO_BLK_F_SEG_MAX,
@@ -1267,6 +1291,23 @@ static int virtblk_read_limits(struct virtio_blk *vblk,
/* Prevent integer overflows and honor max vq size */
sg_elems = min_t(u32, sg_elems, VIRTIO_BLK_MAX_SG_ELEMS - 2);
+ /*
+ * virtblk_add_req() uses separate outgoing and incoming header
+ * descriptors (out_hdr and in_hdr), consuming 2 extra descriptors
+ * per request in addition to the data segments.
+ *
+ * Per virtio specification (2.7.5.3.1), a driver MUST NOT create a
+ * descriptor chain longer than the Queue Size of the device.
+ *
+ * Clamp max_segments to (ring_size - 2) across all virtqueues so
+ * that a request never exceeds the ring size of any queue.
+ */
+ for (i = 0; i < vblk->num_vqs; i++) {
+ u32 ring_size = virtqueue_get_vring_size(vblk->vqs[i].vq);
+
+ sg_elems = min_t(u32, sg_elems, ring_size - 2);
+ }
+
/* We can handle whatever the host told us to handle. */
lim->max_segments = sg_elems;
@@ -1466,6 +1507,7 @@ static int virtblk_probe(struct virtio_device *vdev)
mutex_init(&vblk->vdev_mutex);
vblk->vdev = vdev;
+ vblk->disk = NULL;
INIT_WORK(&vblk->config_work, virtblk_config_changed_work);
--
2.55.0.1082.g2b9226bbc0-goog
prev parent reply other threads:[~2026-09-18 13:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 10:59 [PATCH] virtio-blk: clamp max_segments when indirect descriptors are disabled Sergii Ushakov
2026-08-17 7:47 ` Christoph Hellwig
2026-08-17 8:08 ` Sergii Ushakov
2026-08-17 12:41 ` Michael S. Tsirkin
2026-08-17 13:42 ` [PATCH v2] " Sergii Ushakov
2026-08-17 17:28 ` Stefan Hajnoczi
2026-08-19 5:52 ` Christoph Hellwig
2026-09-16 14:07 ` Sergii Ushakov
2026-09-16 15:00 ` Michael S. Tsirkin
2026-09-18 11:34 ` [PATCH v3] virtio-blk: clamp max_segments to virtqueue ring size Sergii Ushakov
2026-09-18 12:39 ` Michael S. Tsirkin
2026-09-18 13:51 ` Sergii Ushakov [this message]
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=20260918135120.1261150-1-sergiiushakov@google.com \
--to=sergiiushakov@google.com \
--cc=axboe@kernel.dk \
--cc=eperezma@redhat.com \
--cc=hch@lst.de \
--cc=jasowang@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®