From: sashiko-bot@kernel.org
To: "Stjepan Poljak" <stjepan.poljak@gmail.com>
Cc: virtualization@lists.linux.dev,
"Michael S. Tsirkin" <mst@redhat.com>,
"Eugenio Perez" <eperezma@redhat.com>
Subject: Re: [PATCH 2/2] virtio_blk: fit max_segments to the virtqueue without indirect descriptors
Date: Sun, 01 Nov 2026 16:57:52 +0000 [thread overview]
Message-ID: <sashiko-outbox-192516@kernel.org> (raw)
In-Reply-To: <20261101165307.2557421-3-stjepan.poljak@gmail.com>
> virtblk_read_limits() takes max_segments from the device's seg_max and
> only clamps it to VIRTIO_BLK_MAX_SG_ELEMS - 2, which fits the largest
> virtqueue the spec allows, not the one the device has. Without
> VIRTIO_RING_F_INDIRECT_DESC every segment takes a descriptor in the
> ring, next to the header and the status. A device that offers a seg_max
> above its queue size minus two thus lets the block layer build requests
> that can never be added: virtqueue_add_split() warns that the request
> is larger than the ring and returns -ENOSPC, and the hardware queue is
> stopped to wait for descriptors that even an empty ring does not have.
> The I/O hangs.
>
> Seen with a device that offers seg_max 254 on a 128-entry queue without
> indirect descriptors, where the boot hangs loading /sbin/init:
>
> WARNING: drivers/virtio/virtio_ring.c:688 at virtqueue_add_split+0x6c0/0x850
> ...
> virtqueue_add_sgs+0xd1/0x120
> virtblk_add_req+0xe2/0x140
> virtio_queue_rq+0x79/0x1a0
>
> With seg_max 126 it boots, with 127 it hangs.
>
> Without indirect descriptors, clamp max_segments to the size of the
> smallest virtqueue minus two. The previous commit makes the probe fail
> for a virtqueue smaller than three, so at least one segment is left.
>
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Stjepan Poljak <stjepan.poljak@gmail.com>
Sashiko has reviewed this patch and found no issues.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261101165307.2557421-1-stjepan.poljak@gmail.com?part=2
next prev parent reply other threads:[~2026-11-01 16:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-01 16:53 [PATCH 0/2] virtio_blk: fit requests to virtqueues without indirect descriptors Stjepan Poljak
2026-11-01 16:53 ` [PATCH 1/2] virtio_blk: fail the probe when a virtqueue is too small for a request Stjepan Poljak
2026-11-01 17:00 ` sashiko-bot
2026-11-01 16:53 ` [PATCH 2/2] virtio_blk: fit max_segments to the virtqueue without indirect descriptors Stjepan Poljak
2026-11-01 16:57 ` sashiko-bot [this message]
2026-11-02 12:59 ` [PATCH 0/2] virtio_blk: fit requests to virtqueues " 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=sashiko-outbox-192516@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=eperezma@redhat.com \
--cc=mst@redhat.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=stjepan.poljak@gmail.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 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.