linux-kernel - Re: [PATCH bpf-next v2 3/4] selftests/bpf: integrate test_tc_tunnel.sh tests into test

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQJ6zKbThz8B5bqBpwz=gyqeindZb1kwCmM90PsR4-7iQQ@mail.gmail.com>
Date: Wed, 22 Oct 2025 09:44:05 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Alexis Lothoré <alexis.lothore@...tlin.com>
Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, 
	Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>, 
	KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, 
	Jiri Olsa <jolsa@...nel.org>, Shuah Khan <shuah@...nel.org>, ebpf@...uxfoundation.org, 
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>, 
	Bastien Curutchet <bastien.curutchet@...tlin.com>, bpf <bpf@...r.kernel.org>, 
	"open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH bpf-next v2 3/4] selftests/bpf: integrate
 test_tc_tunnel.sh tests into test_progs

On Wed, Oct 22, 2025 at 12:52 AM Alexis Lothoré
<alexis.lothore@...tlin.com> wrote:
>
> On Wed Oct 22, 2025 at 9:39 AM CEST, Alexis Lothoré (eBPF Foundation) wrote:
> > The test_tc_tunnel.sh script checks that a large variety of tunneling
> > mechanisms handled by the kernel can be handled as well by eBPF
> > programs. While this test shares similarities with test_tunnel.c (which
> > is already integrated in test_progs), those are testing slightly
> > different things:
> > - test_tunnel.c creates a tunnel interface, and then get and set tunnel
> >   keys in packet metadata, from BPF programs.
> > - test_tc_tunnels.sh manually parses/crafts packets content
> >
> > Bring the tests covered by test_tc_tunnel.sh into the test_progs
> > framework, by creating a dedicated test_tc_tunnel.sh. This new test
> > defines a "generic" runner which, for each test configuration:
> > - will configure the relevant veth pair, each of those isolated in a
> >   dedicated namespace
> > - will check that traffic will fail if there is only an encapsulating
> >   program attached to one veth egress
> > - will check that traffic succeed if we enable some decapsulation module
> >   on kernel side
> > - will check that traffic still succeeds if we replace the kernel
> >   decapsulation with some eBPF ingress decapsulation.
> >
> > Example of the new test execution:
> >
> >   # ./test_progs -a tc_tunnel
> >   #447/1   tc_tunnel/ipip_none:OK
> >   #447/2   tc_tunnel/ipip6_none:OK
> >   #447/3   tc_tunnel/ip6tnl_none:OK
> >   #447/4   tc_tunnel/sit_none:OK
> >   #447/5   tc_tunnel/vxlan_eth:OK
> >   #447/6   tc_tunnel/ip6vxlan_eth:OK
> >   #447/7   tc_tunnel/gre_none:OK
> >   #447/8   tc_tunnel/gre_eth:OK
> >   #447/9   tc_tunnel/gre_mpls:OK
> >   #447/10  tc_tunnel/ip6gre_none:OK
> >   #447/11  tc_tunnel/ip6gre_eth:OK
> >   #447/12  tc_tunnel/ip6gre_mpls:OK
> >   #447/13  tc_tunnel/udp_none:OK
> >   #447/14  tc_tunnel/udp_eth:OK
> >   #447/15  tc_tunnel/udp_mpls:OK
> >   #447/16  tc_tunnel/ip6udp_none:OK
> >   #447/17  tc_tunnel/ip6udp_eth:OK
> >   #447/18  tc_tunnel/ip6udp_mpls:OK
> >   #447     tc_tunnel:OK
> >   Summary: 1/18 PASSED, 0 SKIPPED, 0 FAILED
> >
> > Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@...tlin.com>
>
> A note about test duration:
> the overall test duration, in my setup (x86 qemu-based setup, running on
> x86), is around 13s. Reviews on similar series ([1]) shows that such a
> duration is not really desirable for CI integration. I checked how to
> reduce it, and it appears that most of it is due to the fact that for each
> subtest, we verify that if we insert bpf encapsulation (egress) program,
> and nothing on server side, we properly fail to connect client to server.
> This test then relies on timeout connection,  and I already reduced it as
> much as possible, but I guess going below the current value (500ms) will
> just start to make the whole test flaky.
>
> I took this "check connection failure" from the original script, and kind
> of like it for its capacity to detect false negatives, but should I
> eventually get rid of it ?

I vote to get rid of it.
I'd rather have test_progs that are quick enough to execute for CI and
for all developers then more in depth coverage for the corner case.
Note that for the verifier range test we randomize the test coverage,
since the whole permutation takes hours to run. Instead we randomly
pick a couple tests and run only those. Since CI runs for every patch
the overall coverage is good enough.
Would something like that possible here ? and in the other xsk test?