From: sashiko-bot@kernel.org
To: "Maciej Fijalkowski" <maciej.fijalkowski@intel.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net-next 09/13] selftests: xsk: run the RX and TX endpoints in separate processes
Date: Sat, 03 Oct 2026 01:33:54 +0000 [thread overview]
Message-ID: <20261003013354.D06831F00893@smtp.kernel.org> (raw)
In-Reply-To: <20261001202124.692591-10-maciej.fijalkowski@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] selftests: xsk: infinite loop when peer process crashes
--
commit 75a72a39b57bce249cec4dee9c3d6dcc72729c6d
Author: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
selftests: xsk: run the RX and TX endpoints in separate processes
This commit splits the xsk selftest into separate RX and TX processes that
communicate over a TCP control channel. The endpoints exchange fixed-size
messages to synchronize steps, track progress, and abort on failures.
> --- /dev/null
> +++ b/tools/testing/selftests/net/lib/xsk/xsk_peer.c
[ ... ]
> +static int peer_drain(struct xsk_peer *peer)
> +{
> + struct pollfd pfd = { .fd = peer->fd, .events = POLLIN };
> + int ret;
> +
> + while (!peer->closed) {
> + ret = poll(&pfd, 1, 0);
> + if (ret < 0 && errno == EINTR)
> + continue;
> + if (ret < 0)
> + return -errno;
> + if (!ret)
> + break;
> + ret = peer_recv_one(peer);
> + if (ret && !peer->closed)
> + return ret;
> + }
> + return 0;
> +}
[Severity: Medium]
If the peer process crashes, peer_recv_one() detects a closed socket (like
-EPIPE), sets peer->closed to true, and returns the error code. Because
peer->closed is now true, does this if statement suppress the error and
cause the function to return 0 instead of propagating the failure?
> --- a/tools/testing/selftests/net/lib/xsk/test_xsk.c
> +++ b/tools/testing/selftests/net/lib/xsk/test_xsk.c
[ ... ]
> static int __send_pkts(struct ifobject *ifobject, struct xsk_socket_info *xsk,
> bool test_timeout)
> {
[ ... ]
> buffer_len = pkt_get_buffer_len(umem, pkt_stream->max_pkt_len);
> + if (pacing_tx_sync())
> + return TEST_FAILURE;
> +
> /* pkts_in_flight might be negative if many invalid packets are sent */
> if (pkts_in_flight >= (int)((umem_size(umem) - xsk->batch_size * buffer_len) /
> buffer_len) && !test_timeout) {
> ret = kick_tx(xsk);
> if (ret)
> return TEST_FAILURE;
> return TEST_CONTINUE;
> }
[Severity: Medium]
When pacing_tx_sync() calls xsk_peer_tx_sync() which relies on
peer_drain(), the suppressed error causes pacing_tx_sync() to incorrectly
report success.
Since no PROGRESS messages are received from the crashed peer,
pkts_in_flight remains artificially high. Will this cause __send_pkts() to
repeatedly return TEST_CONTINUE without ever pushing packets?
[ ... ]
> static int send_pkts(struct test_spec *test, struct ifobject *ifobject)
> {
[ ... ]
> while (!(all_packets_sent(test, bitmap))) {
> for (i = 0; i < test->nb_sockets; i++) {
[ ... ]
> ret = __send_pkts(ifobject, &ifobject->xsk_arr[i], test->poll_tmout);
> if (ret != TEST_CONTINUE)
> return ret;
>
> - if (test->fail)
> - return TEST_FAILURE;
> -
> if (!test->poll_tmout) {
> ret = wait_for_tx_completion(&ifobject->xsk_arr[i]);
> if (ret)
> return TEST_FAILURE;
> }
> }
> }
>
> return TEST_PASS;
> }
[Severity: Medium]
Because __send_pkts() returns TEST_CONTINUE over and over, and
wait_for_tx_completion() returns instantly when no packets are sent, does
this create an infinite loop?
If a test endpoint crashes, it appears the other endpoint will hang
indefinitely instead of failing the test, which could permanently block
automated CI pipelines.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261001202124.692591-1-maciej.fijalkowski@intel.com?part=9
next prev parent reply other threads:[~2026-10-03 1:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 20:21 [PATCH net-next 00/13] selftests: net: migrate AF_XDP test suite over to net Maciej Fijalkowski
2026-10-01 20:21 ` [PATCH net-next 01/13] selftests: xsk: factor endpoint work out of pthread wrappers Maciej Fijalkowski
2026-10-01 20:21 ` [PATCH net-next 02/13] selftests: xsk: drop the single-interface loopback mode Maciej Fijalkowski
2026-10-01 20:21 ` [PATCH net-next 03/13] selftests/bpf: drop the test_progs AF_XDP wrapper Maciej Fijalkowski
2026-10-01 20:21 ` [PATCH net-next 04/13] selftests: net: add a generic rule for BPF skeletons Maciej Fijalkowski
2026-10-03 1:33 ` sashiko-bot
2026-10-01 20:21 ` [PATCH net-next 05/13] selftests: xsk: move the AF_XDP test suite to selftests/net Maciej Fijalkowski
2026-10-01 20:21 ` [PATCH net-next 06/13] selftests: xsk: collect interface capabilities in struct xsk_caps Maciej Fijalkowski
2026-10-01 20:21 ` [PATCH net-next 07/13] selftests: xsk: split xskxceiver main() into setup, run and cleanup Maciej Fijalkowski
2026-10-01 20:21 ` [PATCH net-next 08/13] selftests: xsk: run one test case per xskxceiver invocation Maciej Fijalkowski
2026-10-01 20:21 ` [PATCH net-next 09/13] selftests: xsk: run the RX and TX endpoints in separate processes Maciej Fijalkowski
2026-10-02 18:07 ` Vyavahare, Tushar
2026-10-03 1:33 ` sashiko-bot [this message]
2026-10-01 20:21 ` [PATCH net-next 10/13] selftests: xsk: add a hardware mode to xskxceiver Maciej Fijalkowski
2026-10-03 1:33 ` sashiko-bot
2026-10-01 20:21 ` [PATCH net-next 11/13] selftests: xsk: share test case definitions with hardware runner Maciej Fijalkowski
2026-10-01 20:21 ` [PATCH net-next 12/13] selftests: drv-net: test AF_XDP zero-copy with an SKB peer Maciej Fijalkowski
2026-10-01 20:21 ` [PATCH net-next 13/13] selftests: xsk: document generic and hardware endpoint runs Maciej Fijalkowski
2026-10-05 18:06 ` [PATCH net-next 00/13] selftests: net: migrate AF_XDP test suite over to net Stanislav Fomichev
2026-10-06 17:42 ` Maciej Fijalkowski
2026-10-06 22:04 ` Stanislav Fomichev
2026-10-07 12:22 ` Maciej Fijalkowski
2026-10-07 17:26 ` Stanislav Fomichev
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=20261003013354.D06831F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=sashiko-reviews@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.