[PATCH 0/2] virtio_blk: fit requests to virtqueues without indirect descriptors
flat view
HOTtoday
From: Stjepan Poljak <hidden>
Date: 2026-11-01 16:53:22
Also in:
linux-block, lkml
Subsystem:
block layer, the rest, virtio block and scsi drivers, virtio core · Maintainers:
Jens Axboe, Linus Torvalds, "Michael S. Tsirkin", Jason Wang, Eugenio Pérez
A virtio-blk device without VIRTIO_RING_F_INDIRECT_DESC needs one ring descriptor per segment of a request, plus one for the header and one for the status. virtio_blk takes max_segments from the device's seg_max without checking that against the size of the virtqueues, so a device that offers a seg_max above its queue size minus two gets requests that can never be added to the ring. virtqueue_add_split() warns, returns -ENOSPC, and the request waits for ring space forever. A virtqueue with fewer than three descriptors cannot hold any request, and depending on the queue depth the probe then either fails without saying why or hangs on the first I/O. I ran into this while writing the virtio-blk device of Hearth, a small KVM-based VMM, with queue sizes and seg_max values like these: virtqueue seg_max queue_depth before after --------- ------- ----------- ------------------------ ------------------- 128 126 default boots boots 128 127 default WARN, hangs loading init boots, 126 segments 128 254 default WARN, hangs loading init boots, 126 segments 1 - default -EINVAL, no reason given -EINVAL, message 1 - 128 WARN, hangs on first I/O -EINVAL, message where the message is "virtqueue size 1 is too small for a request". A virtqueue of 2 is rejected the same way, with either queue depth. Patch 1 checks the virtqueue sizes in virtblk_probe(), before the queue depth is derived from them, and fails the probe with a reason when one is too small for a request, whatever the queue depth: the last two rows and the virtqueue of 2. Patch 2 then clamps max_segments to the smallest virtqueue minus two when indirect descriptors are not negotiated: the seg_max rows. The seg_max case also reproduces with QEMU, which with seg-max-adjust=off offers seg_max 126 whatever the queue size: -device virtio-blk-pci,drive=d0,indirect_desc=off,queue-size=64,seg-max-adjust=off Before the series this warns and hangs loading init, after it the guest boots with 62 segments. With QEMU's defaults nothing changes. The seg_max cases were tested by booting a busybox guest that reads its disk with O_DIRECT in 1 MiB blocks, the others by looking at the probe messages, on v7.3-19954-gcbbddb6b08cc, x86_64. These patches were written with the help of an AI assistant, as the Assisted-by tags say. I reviewed and tested them, and I can answer for every line. Stjepan Poljak (2): virtio_blk: fail the probe when a virtqueue is too small for a request virtio_blk: fit max_segments to the virtqueue without indirect descriptors drivers/block/virtio_blk.c | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) -- 2.53.0