From: sashiko-bot@kernel.org
To: "Tushar Vyavahare" <tushar.vyavahare@intel.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net-next v3 4/4] selftests/xsk: Introduce mmap_size in umem struct
Date: Tue, 09 Jun 2026 13:10:12 +0000 [thread overview]
Message-ID: <20260609131013.299691F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260608130938.958793-5-tushar.vyavahare@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unconditional `pthread_join` in the single-thread path can cause the test suite to hang indefinitely due to a deadlock with an unsafe signal handler.
--
commit 2b44f1770c5b4b9bb0b75f25f4cfb408f2d008dd
Author: Tushar Vyavahare <tushar.vyavahare@intel.com>
Subject: selftests/xsk: Introduce mmap_size in umem struct
This commit stores the final mapping length in xsk_umem_info as mmap_size when
the UMEM mapping is created, and uses that value during teardown. It also
joins the RX worker thread before cleanup in the single-thread path.
> diff --git a/tools/testing/selftests/bpf/prog_tests/test_xsk.c b/tools/testing/selftests/bpf/prog_tests/test_xsk.c
> index 17a467a7dd7f6..72875071d4f12 100644
> --- a/tools/testing/selftests/bpf/prog_tests/test_xsk.c
> +++ b/tools/testing/selftests/bpf/prog_tests/test_xsk.c
[ ... ]
> @@ -1857,8 +1856,7 @@ static int __testapp_validate_traffic(struct test_spec *test, struct ifobject *i
>
> if (!ifobj2)
> pthread_kill(t0, SIGUSR1);
> - else
> - pthread_join(t0, NULL);
> + pthread_join(t0, NULL);
[Severity: Medium]
Will this unconditional pthread_join() cause the test suite to hang
indefinitely if the worker thread self-deadlocks?
The worker thread t0 is terminated by sending SIGUSR1 asynchronously, which is
caught by handler():
tools/testing/selftests/bpf/prog_tests/test_xsk.c:handler() {
pthread_exit(NULL);
}
Since pthread_exit() is not async-signal-safe, if the signal interrupts the
worker thread while it holds an internal libc lock (such as during memory
allocation or mutex acquisition), pthread_exit() can self-deadlock when
attempting to acquire the same lock during thread-local teardown.
Before this patch, the deadlocked thread was leaked but did not block the main
test thread. By adding an unconditional pthread_join(t0, NULL) here, won't the
main thread now block forever waiting for the deadlocked thread, causing the
entire test suite to hang?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260608130938.958793-1-tushar.vyavahare@intel.com?part=4
prev parent reply other threads:[~2026-06-09 13:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 13:09 [PATCH net-next v3 0/4] selftests/xsk: simplify UMEM setup Tushar Vyavahare
2026-06-08 13:09 ` [PATCH net-next v3 1/4] selftests/xsk: Introduce helpers for setting UMEM properties Tushar Vyavahare
2026-06-08 13:09 ` [PATCH net-next v3 2/4] selftests/xsk: Move UMEM state from ifobject to xsk_socket_info Tushar Vyavahare
2026-06-08 13:09 ` [PATCH net-next v3 3/4] selftests/xsk: Use umem_size() helper consistently Tushar Vyavahare
2026-06-08 13:09 ` [PATCH net-next v3 4/4] selftests/xsk: Introduce mmap_size in umem struct Tushar Vyavahare
2026-06-09 13:10 ` 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=20260609131013.299691F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tushar.vyavahare@intel.com \
/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.