summaryrefslogtreecommitdiff
path: root/include/linux
diff options
context:
space:
mode:
authorSergii Ushakov <sergiiushakov@google.com>2026-09-18 15:51:20 +0200
committerJens Axboe <axboe@kernel.dk>2026-11-03 07:11:54 -0700
commit603e66e8dd6adf2bad54bb27f4b690eacba3745e (patch)
tree8eb8f34068a17363ada6662ed2784c1269ed72f1 /include/linux
parent304b850e02fbbd72974a2bd0f88b0510f14867a9 (diff)
virtio-blk: clamp max_segments to virtqueue ring size
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> Link: https://patch.msgid.link/20260918135120.1261150-1-sergiiushakov@google.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions