Linux virtualization list
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sergii Ushakov" <sergiiushakov@google.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	virtualization@lists.linux.dev,
	"Eugenio Perez" <eperezma@redhat.com>
Subject: Re: [PATCH v4] virtio-blk: clamp max_segments to virtqueue ring size
Date: Fri, 18 Sep 2026 13:59:56 +0000	[thread overview]
Message-ID: <20260918135957.409451F00898@smtp.kernel.org> (raw)
In-Reply-To: <20260918135120.1261150-1-sergiiushakov@google.com>

> 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>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918135120.1261150-1-sergiiushakov@google.com?part=1


      reply	other threads:[~2026-09-18 13:59 UTC|newest]

Thread overview: 14+ 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 11:45       ` sashiko-bot
2026-09-18 12:39       ` Michael S. Tsirkin
2026-09-18 13:51         ` [PATCH v4] " Sergii Ushakov
2026-09-18 13:59           ` sashiko-bot [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=20260918135957.409451F00898@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=eperezma@redhat.com \
    --cc=mst@redhat.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sergiiushakov@google.com \
    --cc=virtualization@lists.linux.dev \
    /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