All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Leon Hwang" <leon.hwang@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf v2 4/4] selftests/bpf: Add tests to verify the fix of encapsulating VxLAN in lwt
Date: Fri, 29 May 2026 16:48:35 +0000	[thread overview]
Message-ID: <20260529164835.A23B61F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260529151351.69911-5-leon.hwang@linux.dev>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The fexit program `fexit_lwt_push_ip_encap` is a global hook without filtering, causing test flakiness when tests run concurrently.
--

commit 1b1d75b61046d2f71544d30d5afec12a9644a6b0
Author: Leon Hwang <leon.hwang@linux.dev>

selftests/bpf: Add tests to verify the fix of encapsulating VxLAN in lwt

This commit adds two new selftests (IPv4 and IPv6) to verify that the
transport header of an skb is correctly set when encapsulating VxLAN using
the bpf_lwt_push_encap() helper.

> diff --git a/tools/testing/selftests/bpf/progs/test_lwt_ip_encap_fix.c b/tools/testing/selftests/bpf/progs/test_lwt_ip_encap_fix.c
> new file mode 100644
> index 0000000000000..e9043fe654eb7
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/test_lwt_ip_encap_fix.c
> @@ -0,0 +1,36 @@
[ ... ]
> +SEC("fexit/bpf_lwt_push_ip_encap")
> +int BPF_PROG(fexit_lwt_push_ip_encap, struct sk_buff *skb, void *hdr, u32 len, bool ingress,
> +	     int retval)
> +{
> +	if (retval || fexit_triggered)
> +		return 0;
> +
> +	fexit_triggered = true;
> +	transport_hdr = BPF_CORE_READ(skb, transport_header);

[Severity: Medium]
Will this fexit program cause test flakiness when tests run concurrently?

Since test_progs executes test functions concurrently across multiple workers
by default, this global fexit program might intercept the
bpf_lwt_push_ip_encap call from a different test running simultaneously
(like the existing GRE test).

Because it only captures the first successful execution and has no filtering
for a specific test or network namespace, could it record offsets for the
wrong packet type and lead to random failures in the transport_hdr offset
assertion?

> +	network_hdr   = BPF_CORE_READ(skb, network_header);
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260529151351.69911-1-leon.hwang@linux.dev?part=4

      reply	other threads:[~2026-05-29 16:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-29 15:13 [PATCH bpf v2 0/4] bpf: Update transport_header when encapsulating UDP tunnel in lwt Leon Hwang
2026-05-29 15:13 ` [PATCH bpf v2 1/4] bpf: Fix TOCTOU issue " Leon Hwang
2026-05-29 15:49   ` sashiko-bot
2026-06-01  0:44   ` Alexei Starovoitov
2026-06-01 13:34     ` Leon Hwang
2026-05-29 15:13 ` [PATCH bpf v2 2/4] bpf: Add check iph->ihl < 5 " Leon Hwang
2026-05-29 16:06   ` sashiko-bot
2026-05-29 15:13 ` [PATCH bpf v2 3/4] bpf: Update transport_header when encapsulating UDP tunnel " Leon Hwang
2026-05-29 16:31   ` sashiko-bot
2026-05-29 15:13 ` [PATCH bpf v2 4/4] selftests/bpf: Add tests to verify the fix of encapsulating VxLAN " Leon Hwang
2026-05-29 16:48   ` sashiko-bot [this message]

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=20260529164835.A23B61F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=leon.hwang@linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.