Re: [PATCH] selftests/bpf: tc_tunnel - validate decap tunnel state without false-pass gaps

> 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