From: "Alexis Lothoré" <alexis.lothore@bootlin.com>
To: "Daniel Borkmann" <daniel@iogearbox.net>, <bochaolucky@gmail.com>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Eduard Zingerman" <eddyz87@gmail.com>
Cc: "Ihor Solodrai" <ihor.solodrai@linux.dev>,
"Jiayuan Chen" <jiayuan.chen@linux.dev>,
"Alexei Starovoitov" <ast@kernel.org>,
"Jakub Kicinski" <kuba@kernel.org>,
"Stanislav Fomichev" <sdf@fomichev.me>,
"Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
"Song Liu" <song@kernel.org>,
"Emil Tsalapatis" <emil@etsalapatis.com>,
bpf@vger.kernel.org, netdev@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
"Alexis Lothoré" <alexis.lothore@bootlin.com>
Subject: Re: [PATCH bpf-next v2] selftests/bpf: Track test_xdp_features DUT processes
Date: Mon, 24 Aug 2026 16:49:29 +0200 [thread overview]
Message-ID: <DKX99ZAP7GZ8.23U5EOSFB4VPU@bootlin.com> (raw)
In-Reply-To: <d4be160e-703e-46bb-9509-d3d90f6bc34b@iogearbox.net>
Hi Daniel, thanks for the notification
On Mon Aug 24, 2026 at 1:31 PM CEST, Daniel Borkmann wrote:
> [ Trimming the excessive Cc list, and adding Alexis ]
>
> On 8/12/26 10:28 AM, Bochao Cao via B4 Relay wrote:
>> From: Bochao Cao <bochaolucky@gmail.com>
>>
>> test_xdp_features.sh waits for any xdp_features listener to appear and
>> uses pidof during cleanup. A concurrent test can therefore make another
>> test proceed before its own DUT is ready, and cleanup kills every
>> xdp_features process on the host. The readiness loop also has no timeout,
>> so a DUT that exits before listening leaves the test hung indefinitely.
>>
>> Track one active DUT at a time, wait for ss to report that exact PID with
>> a bounded retry loop, and reap it after each test. Consult the shell job
>> table before signaling the DUT so a stale PID cannot target an unrelated
>> process. On failure, terminate the shell job with SIGKILL and reap it so
>> blocked I/O cannot hang cleanup. Install an EXIT trap and signal handlers
>> so failure paths also remove network setup.
>>
>> Fixes: 4dba3e7852b7 ("selftests/bpf: introduce XDP compliance test tool")
>> Closes: https://bugs.debian.org/1136522
>> Signed-off-by: Bochao Cao <bochaolucky@gmail.com>
>> ---
>> Tests:
>> - bash -n tools/testing/selftests/bpf/test_xdp_features.sh
>> - make -C tools/testing/selftests/bpf xdp_features
>> - sudo tools/testing/selftests/bpf/test_xdp_features.sh
>> - verified cleanup terminates a blocked DUT without affecting an unrelated process
>> ---
>> Changes in v2:
>> - Clarify that avoiding name-wide process matching, rather than dropping a dependency, is the motivation.
>> - Track and reap one active DUT at a time instead of retaining historical PIDs.
>> - Address PID reuse by signaling only the current Bash job during cleanup.
>> - Use SIGKILL on failure cleanup so blocked DUT I/O cannot hang wait indefinitely.
>> - Link to v1: https://patch.msgid.link/20260805-xdp-dut-process-lifecycle-gmail-v1-1-45984df8d295@gmail.com
>> ---
>> tools/testing/selftests/bpf/test_xdp_features.sh | 82 ++++++++++++++++++------
>> 1 file changed, 62 insertions(+), 20 deletions(-)
>
> Sorry for the late reply. With regards to https://bugs.debian.org/1136522, src:linux deb
> does not have to depend on this at all, so the src:linux can just get rid of procps in
> any case if this is indeed the last dependency. I'm not seeing the test being run in our
> BPF CI. I've Cc'ed Alexis as he's in the process of migrating and/or removing tests from
> tools/testing/selftests/bpf/ depending on how they fit into test_progs framework. I'll
> let him comment if there is already work in progress. It feels like this script could be
> reworked into tools/testing/selftests/drivers/net/hw/ tests and removed altogether from
> the tools/testing/selftests/bpf/ dir.
There has been an attempt to fully convert and get rid of
test_xdp_features.sh, but discussions around the corresponding series
highlighted the need for the script to remain available for testing on
real hardware. Features covered by the test_xdp_features.sh that were
not covered yet by test_progs have been added to test_progs (in
xdp_cpumap_attach), see [1]. So there's currently no active effort on
this one on my side.
Alexis
[1] https://lore.kernel.org/bpf/20241009-convert_xdp_tests-v3-0-51cea913710c@bootlin.com/
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2026-08-24 14:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 8:28 [PATCH bpf-next v2] selftests/bpf: Track test_xdp_features DUT processes Bochao Cao via B4 Relay
2026-08-12 8:28 ` Bochao Cao
2026-08-12 9:23 ` bot+bpf-ci
2026-08-24 11:31 ` Daniel Borkmann
2026-08-24 14:49 ` Alexis Lothoré [this message]
[not found] ` <CAHKNYVXN0DAUzv2Lwm=oQ_K=zhi2iNyTO2e99s5F4M+Kr7u5tQ@mail.gmail.com>
[not found] ` <CAHKNYVV8gn-L_unjsxUZV=E+Rx4ouDBJX613_n4hevXP1rivyg@mail.gmail.com>
2026-08-28 9:32 ` Bochao Cao
2026-09-02 7:44 ` Emil Tsalapatis
2026-09-03 8:10 ` Bochao Cao
2026-09-03 13:44 ` Daniel Borkmann
2026-08-31 7:55 ` Alexis Lothoré
2026-08-31 8:56 ` Daniel Borkmann
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=DKX99ZAP7GZ8.23U5EOSFB4VPU@bootlin.com \
--to=alexis.lothore@bootlin.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bochaolucky@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=jiayuan.chen@linux.dev \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=memxor@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
/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.