Re: [PATCH bpf-next v2] selftests/bpf: Track test_xdp_features DUT processes

["Emil Tsalapatis" <emil@etsalapatis.com>]

On Fri Aug 28, 2026 at 5:32 AM EDT, Bochao Cao wrote:
>  Resending as plain text because my previous reply was rejected by the
> vger mailing lists. Sorry for the duplicate.
>  Thanks Daniel and Alexis.
>
>   Dropping the procps dependency is not the primary motivation for
>   this change. I agree that Debian can remove the dependency independently.
>   The issue addressed by this patch is process isolation in the standalone
>   test. The current readiness check may observe an unrelated
>   concurrent xdp_features process, while cleanup may terminate every
> xdp_features
>   process on the host. In addition, a DUT which exits before listening
> can leave the test waiting indefinitely.
>
>   Although this script is not currently run by the BPF CI, it remains
> useful  for testing real hardware,
>   so these process lifecycle issues can still  affect users running
> the test manually.
>
>   Would it be acceptable to fix these issues in the script's current location?
>   If the preferred direction is to move it under
> tools/testing/selftests/drivers/net/hw/,
>   should the move be submitted first, with this fix rebased on top?
>
>   I can send a v3 that drops the Debian Closes tag and focuses
>   the commit message solely on the process isolation, timeout,
>   and cleanup fixes once the preferred location is clear.
>
>   Thanks,
>   Bochao

While I'd defer to Daniel and Alexis on this, imo we could merge the fix
as-is and move the file as a followup since the change is a net gain on
its own.

Wherever we end up putting the file feel free to add:

Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>

>
>
> Bochao Cao <bochaolucky@gmail.com> 于2026年8月28日周五 14:10写道：
>>
>>  Thanks Daniel and Alexis.
>>
>>   Dropping the procps dependency is not the primary motivation for
>>   this change. I agree that Debian can remove the dependency independently.
>>   The issue addressed by this patch is process isolation in the standalone
>>   test. The current readiness check may observe an unrelated
>>   concurrent xdp_features process, while cleanup may terminate every xdp_features
>>   process on the host. In addition, a DUT which exits before listening can leave the test waiting indefinitely.
>>
>>   Although this script is not currently run by the BPF CI, it remains useful  for testing real hardware,
>>   so these process lifecycle issues can still  affect users running the test manually.
>>
>>   Would it be acceptable to fix these issues in the script's current location?
>>   If the preferred direction is to move it under tools/testing/selftests/drivers/net/hw/,
>>   should the move be submitted first, with this fix rebased on top?
>>
>>   I can send a v3 that drops the Debian Closes tag and focuses
>>   the commit message solely on the process isolation, timeout,
>>   and cleanup fixes once the preferred location is clear.
>>
>>   Thanks,
>>   Bochao
>>
>> Bochao Cao <bochaolucky@gmail.com> 于2026年8月25日周二 21:01写道：
>> >
>> >   Thanks Daniel and Alexis.
>> >
>> >   Dropping the procps dependency is not the primary motivation for
>> >   this change. I agree that Debian can remove the dependency independently.
>> >   The issue addressed by this patch is process isolation in the standalone
>> >   test. The current readiness check may observe an unrelated
>> >   concurrent xdp_features process, while cleanup may terminate every xdp_features
>> >   process on the host. In addition, a DUT which exits before listening can leave the test waiting indefinitely.
>> >
>> >   Although this script is not currently run by the BPF CI, it remains useful  for testing real hardware,
>> >   so these process lifecycle issues can still  affect users running the test manually.
>> >
>> >   Would it be acceptable to fix these issues in the script's current location?
>> >   If the preferred direction is to move it under tools/testing/selftests/drivers/net/hw/,
>> >   should the move be submitted first, with this fix rebased on top?
>> >
>> >   I can send a v3 that drops the Debian Closes tag and focuses
>> >   the commit message solely on the process isolation, timeout,
>> >   and cleanup fixes once the preferred location is clear.
>> >
>> >   Thanks,
>> >   Bochao
>> >
>> > Alexis Lothoré <alexis.lothore@bootlin.com> 于2026年8月24日周一 22:49写道：
>> >>
>> >> 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
>> >>