> This follow-up tightens the selftest to guard against false passes in
> GSO decap validation.
>
> It validates the expected post-decap state for both GSO and non-GSO
> packets: expected tunnel gso_type bits must be cleared and
> skb->encapsulation must match the remaining tunnel state.
Does this paragraph accurately describe what the patch adds?
The gso_type and skb->encapsulation validation it mentions already exists
in the base revision. Comparing HEAD^ with HEAD for
progs/test_tc_tunnel.c shows the added lines are only the four .bss
globals and three counter increments. The checks described appear only
as context lines:
if ((flags & BPF_F_ADJ_ROOM_DECAP_L4_UDP) &&
(shinfo->gso_type & SKB_GSO_UDP_TUNNEL_MASK))
return TC_ACT_SHOT;
...
if (flags & (BPF_F_ADJ_ROOM_DECAP_L4_MASK |
BPF_F_ADJ_ROOM_DECAP_IPXIP_MASK)) {
if ((shinfo->gso_type & SKB_GSO_TUNNEL_MASK) &&
!kskb->encapsulation)
return TC_ACT_SHOT;
All of this validation is pre-existing. The series is a single commit
(530113d..1dc5f339), so this code is already upstream before this patch.
> It also adds explicit assertions that the decap validation path was
> executed, including the large-send phase for GSO-marked subtests, and
> asserts that the large-send marker is reset after the send.
The large-send marker reset assertion mentioned here checks a variable
that only userspace writes. decap_expect_large_send is read-only in the
BPF program, and send_and_test_data() sets it to 0 on both the success
path and the `end:` path before returning. Can that assertion ever fail?
Also, the commit message doesn't mention the 'ethtool -K veth1 tso off'
change in setup() even though it alters what traffic the test generates.
> diff --git a/tools/testing/selftests/bpf/prog_tests/test_tc_tunnel.c
> b/tools/testing/selftests/bpf/prog_tests/test_tc_tunnel.c
> index 67ba27d69347..08d7d90f7772 100644
> --- a/tools/testing/selftests/bpf/prog_tests/test_tc_tunnel.c
> +++ b/tools/testing/selftests/bpf/prog_tests/test_tc_tunnel.c
[ ... ]
> @@ -374,10 +378,15 @@ static int configure_ebpf_decapsulation(struct
> subtest_cfg *cfg)
> return ret;
> }
>
> -static void run_test(struct subtest_cfg *cfg)
> +static void run_test(struct subtest_cfg *cfg, struct test_tc_tunnel *skel)
> {
> struct nstoken *nstoken;
>
> + skel->bss->decap_validation_seen = 0;
> + skel->bss->decap_gso_validation_seen = 0;
> + skel->bss->decap_large_send_validation_seen = 0;
> + skel->bss->decap_expect_large_send = 0;
> +
> if (!ASSERT_OK(run_server(cfg), "run server"))
> return;
>
> @@ -406,7 +415,18 @@ static void run_test(struct subtest_cfg *cfg)
> /* Replace kernel decapsulation with BPF decapsulation, test must pass
> */
> if (!ASSERT_OK(configure_ebpf_decapsulation(cfg), "configure ebpf
> decapsulation"))
> goto fail;
> - ASSERT_OK(send_and_test_data(cfg), "connect with encap and decap
> progs");
> + if (!ASSERT_OK(send_and_test_data(cfg, skel), "connect with encap and
> decap progs"))
> + goto fail;
> + if (!ASSERT_NEQ(skel->bss->decap_validation_seen, 0,
> + "decap validation executed"))
> + goto fail;
> + if (!ASSERT_EQ(skel->bss->decap_expect_large_send, 0,
> + "decap large-send marker reset"))
> + goto fail;
> + if (cfg->test_gso) {
> + ASSERT_NEQ(skel->bss->decap_large_send_validation_seen, 0,
> + "decap validation executed for large send");
> + }
Is the decap_expect_large_send assertion meaningful here?
decap_expect_large_send is written only by user space; the BPF program
only reads it. send_and_test_data() clears it on every exit path:
skel->bss->decap_expect_large_send = 0; /* line 236, success */
res = 0;
end:
skel->bss->decap_expect_large_send = 0; /* line 240, all paths */
Every return from send_and_test_data() passes through the `end:` label,
so by the time run_test() reads the value it is unconditionally 0.
A broken kernel, a broken BPF program and a correct one all produce the
same result. Can this check ever fail?
> diff --git a/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
> b/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
> index 853bca962910..e9bd1c9781f7 100644
> --- a/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
> +++ b/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
[ ... ]
This looks like a bug fix for false-pass gaps in the selftest. Should
this include:
Fixes: adb771973026 ("selftests/bpf: tc_tunnel - validate decap GSO and
encapsulation state")
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/32136539422
