From: sashiko-bot@kernel.org
To: "David Carlier" <devnexen@gmail.com>
Cc: virtualization@lists.linux.dev,
"Michael S. Tsirkin" <mst@redhat.com>,
"Eugenio Perez" <eperezma@redhat.com>
Subject: Re: [PATCH net-next 2/2] vsock/test: cover receive queue hints
Date: Mon, 21 Sep 2026 19:47:25 +0000 [thread overview]
Message-ID: <20260921194726.2BA141F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260920194710.1114748-3-devnexen@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] vsock/test: flaky multishot receive test due to partial reads
--
commit 9ec49ee8a33c71acaaeb9095c84d90cff4a9c2d9
Author: David Carlier <devnexen@gmail.com>
vsock/test: cover receive queue hints
This commit adds io_uring receive tests to verify the behavior of the
IORING_CQE_F_SOCK_NONEMPTY flag across several receive scenarios, including
partial receives, EOF, nonblocking empty receives, and multishot receives.
> diff --git a/tools/testing/vsock/vsock_uring_test.c b/tools/testing/vsock/vsock_uring_test.c
> index 5c3078969659f..318e17bd28bc6 100644
> --- a/tools/testing/vsock/vsock_uring_test.c
> +++ b/tools/testing/vsock/vsock_uring_test.c
[ ... ]
> +static void test_stream_uring_inq_mshot_server(const struct test_opts *opts)
> +{
[ ... ]
> + sqe = io_uring_get_sqe(&ctx.ring);
> + io_uring_prep_recv_multishot(sqe, ctx.fd, NULL, 0, 0);
> + sqe->flags |= IOSQE_BUFFER_SELECT;
> + sqe->buf_group = HINT_BUF_GROUP;
> +
> + if (io_uring_submit(&ctx.ring) != 1)
> + error(1, errno, "io_uring_submit");
> +
> + control_expectln("SENT");
> +
> + /* The payload completion drains the queue and keeps the request
> + * armed, so the hint must report the queue as empty.
> + */
> + if (io_uring_wait_cqe(&ctx.ring, &cqe))
> + error(1, errno, "io_uring_wait_cqe");
> +
> + expect_res(cqe->res, HINT_CHUNK_SIZE, "multishot payload");
[Severity: Medium]
Does submitting the multishot receive request before the data is fully
queued introduce a race condition that could cause flaky test failures?
Since test_stream_uring_inq_mshot_server() operates on a SOCK_STREAM
socket, the transport does not preserve message boundaries and data can
arrive in fragments. If a fragment arrives before the entire payload is
queued, io_uring may post a CQE with a partial data length. This would
subsequently cause the strict assertion expecting exactly HINT_CHUNK_SIZE
to fail.
Could inq_wait_queued() be used here prior to submitting the request,
similar to the deterministic approach taken in the other tests in this
file?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260920194710.1114748-1-devnexen@gmail.com?part=2
next prev parent reply other threads:[~2026-09-21 19:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 19:47 [PATCH net-next 0/2] vsock: receive queue hint for io_uring David Carlier
2026-09-20 19:47 ` [PATCH net-next 1/2] vsock: report pending receive data to io_uring David Carlier
2026-09-21 19:47 ` sashiko-bot
2026-09-22 13:56 ` Stefano Garzarella
2026-09-22 20:31 ` David CARLIER
2026-09-20 19:47 ` [PATCH net-next 2/2] vsock/test: cover receive queue hints David Carlier
2026-09-21 19:47 ` sashiko-bot [this message]
2026-09-22 14:49 ` Stefano Garzarella
2026-09-22 17:34 ` Bobby Eshleman
2026-09-22 20:37 ` David CARLIER
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=20260921194726.2BA141F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=devnexen@gmail.com \
--cc=eperezma@redhat.com \
--cc=mst@redhat.com \
--cc=sashiko-reviews@lists.linux.dev \
--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.