From: sashiko-bot@kernel.org
To: "Vladimir Vdovin" <deliran@verdict.gg>
Cc: bpf@vger.kernel.org
Subject: Re: [RFC PATCH bpf-next v1 2/7] selftests/bpf: add test for bpf_xdp_assert_rx_csum over cpumap
Date: Tue, 30 Jun 2026 19:27:58 +0000 [thread overview]
Message-ID: <20260630192759.7E6D31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260630191510.81402-3-deliran@verdict.gg>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The XDP program redirects all IPv6 packets unconditionally without filtering for the specific test UDP packet, causing the test to be flaky due to background IPv6 noise (e.g., MLD/ND).
- [Low] Multi-line comments do not follow the required BPF subsystem style.
--
commit 846ee2231e17e81d931043f95937a20e26145ff4
Author: Vladimir Vdovin <deliran@verdict.gg>
selftests/bpf: add test for bpf_xdp_assert_rx_csum over cpumap
This commit adds a selftest to verify that the bpf_xdp_assert_rx_csum helper
properly propagates checksum status through a cpumap redirect. It uses an XDP
program and an fexit hook on __xdp_build_skb_from_frame to observe the
resulting ip_summed value.
> diff --git a/tools/testing/selftests/bpf/prog_tests/xdp_cpumap_rx_csum.c b/tools/testing/selftests/bpf/prog_tests/xdp_cpumap_rx_csum.c
> new file mode 100644
> index 0000000000000..2def92fe11118
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/xdp_cpumap_rx_csum.c
[ ... ]
> +static struct udp_pkt pkt = {
> + .eth.h_proto = __bpf_constant_htons(ETH_P_IPV6),
[ ... ]
> + .udp.len = __bpf_constant_htons(sizeof(struct udphdr) + 16),
> +};
> +
> +/* Inject one frame on veth0; it is received on veth1 where native XDP
> + * redirects it into the cpumap. Report the ip_summed the rebuilt skb carried.
> + */
[Severity: Low]
This isn't a bug, but does this multi-line comment follow the preferred BPF
subsystem style? The guidelines suggest putting the opening /* on its own line.
> +static int inject_and_observe(struct test_xdp_cpumap_rx_csum *skel, int sfd,
[ ... ]
> +void test_xdp_cpumap_rx_csum(void)
> +{
[ ... ]
> + skel = test_xdp_cpumap_rx_csum__open_and_load();
> + if (!ASSERT_OK_PTR(skel, "skel open_and_load"))
> + goto out;
> +
> + /* cpumap entry without a program: a plain redirect that forces the
> + * frame->skb conversion in __xdp_build_skb_from_frame().
> + */
[Severity: Low]
This isn't a bug, but does this multi-line comment follow the preferred BPF
subsystem style?
> + map_fd = bpf_map__fd(skel->maps.cpu_map);
[ ... ]
> + ifindex_dst = if_nametoindex("veth1");
> + ifindex_src = if_nametoindex("veth0");
> + if (!ASSERT_GT(ifindex_dst, 0, "veth1 ifindex") ||
> + !ASSERT_GT(ifindex_src, 0, "veth0 ifindex"))
> + goto out;
> +
> + /* Native XDP so the redirect goes through xdp_convert_buff_to_frame(),
> + * which propagates the rx-csum flag into the frame. Generic mode would
> + * redirect a ready-made skb and never hit our code path.
> + */
[Severity: Low]
This isn't a bug, but does this multi-line comment follow the preferred BPF
subsystem style?
> + err = bpf_xdp_attach(ifindex_dst, bpf_program__fd(skel->progs.xdp_redir),
[ ... ]
> diff --git a/tools/testing/selftests/bpf/progs/test_xdp_cpumap_rx_csum.c b/tools/testing/selftests/bpf/progs/test_xdp_cpumap_rx_csum.c
> new file mode 100644
> index 0000000000000..86c691887d254
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/test_xdp_cpumap_rx_csum.c
[ ... ]
> +SEC("xdp")
> +int xdp_redir(struct xdp_md *ctx)
> +{
> + /* Assert the L4 checksum so the skb built on the cpumap redirect
> + * path is marked CHECKSUM_UNNECESSARY instead of validated in software.
> + */
[Severity: Low]
This isn't a bug, but does this multi-line comment follow the preferred BPF
subsystem style?
> + if (assert_csum)
> + bpf_xdp_assert_rx_csum(ctx);
> +
> + return bpf_redirect_map(&cpu_map, 0, 0);
> +}
[Severity: Medium]
Will this unconditionally redirect all packets (including background noise
like IPv6 MLD/ND) to the cpu_map? If the kernel generates asynchronous
background packets when the veth interfaces are brought up, could this
cause the test to be flaky?
> +
> +/* Observe ip_summed exactly as __xdp_build_skb_from_frame() leaves it, before
> + * GRO in the cpumap kthread can normalize it. tc-ingress would be too late:
> + * GRO software-validates a CHECKSUM_NONE skb and marks it UNNECESSARY anyway.
> + */
[Severity: Low]
This isn't a bug, but does this multi-line comment follow the preferred BPF
subsystem style?
> +SEC("fexit/__xdp_build_skb_from_frame")
> +int BPF_PROG(on_build, struct xdp_frame *xdpf, struct sk_buff *skb,
> + struct net_device *dev, struct sk_buff *ret)
> +{
> + if (ret && ret->protocol == bpf_htons(ETH_P_IPV6)) {
[Severity: Medium]
Since the check only looks for ETH_P_IPV6, could this inadvertently capture
background IPv6 noise like MLD/ND packets and short-circuit the test loop in
inject_and_observe() with an unexpected ip_summed value? Might it be safer
to filter for the specific test UDP packet?
> + observed_ip_summed = ret->ip_summed;
> + seen = true;
> + }
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630191510.81402-1-deliran@verdict.gg?part=2
next prev parent reply other threads:[~2026-06-30 19:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 19:15 [RFC PATCH bpf-next v1 0/7] xdp: RX checksum metadata hint and checksum assertion over redirect Vladimir Vdovin
2026-06-30 19:15 ` [RFC PATCH bpf-next v1 1/7] xdp: let XDP programs assert the RX checksum " Vladimir Vdovin
2026-06-30 19:31 ` sashiko-bot
2026-06-30 19:15 ` [RFC PATCH bpf-next v1 2/7] selftests/bpf: add test for bpf_xdp_assert_rx_csum over cpumap Vladimir Vdovin
2026-06-30 19:27 ` sashiko-bot [this message]
2026-06-30 19:15 ` [RFC PATCH bpf-next v1 3/7] xdp: add bpf_xdp_metadata_rx_csum() RX metadata kfunc Vladimir Vdovin
2026-06-30 19:15 ` [RFC PATCH bpf-next v1 4/7] net/mlx5e: support the rx_csum XDP metadata hint Vladimir Vdovin
2026-06-30 19:15 ` [RFC PATCH bpf-next v1 5/7] ice: " Vladimir Vdovin
2026-06-30 19:27 ` sashiko-bot
2026-06-30 19:15 ` [RFC PATCH bpf-next v1 6/7] veth: " Vladimir Vdovin
2026-06-30 19:27 ` sashiko-bot
2026-06-30 19:15 ` [RFC PATCH bpf-next v1 7/7] selftests/bpf: cover bpf_xdp_metadata_rx_csum in xdp_metadata Vladimir Vdovin
2026-06-30 19:27 ` sashiko-bot
2026-06-30 21:18 ` [RFC PATCH bpf-next v1 0/7] xdp: RX checksum metadata hint and checksum assertion over redirect Stanislav Fomichev
2026-06-30 22:16 ` Lorenzo Bianconi
2026-07-01 17:10 ` Vladimir Vdovin
2026-07-02 14:52 ` Lorenzo Bianconi
2026-07-04 16:41 ` Jesper Dangaard Brouer
2026-07-08 12:51 ` [PATCH bpf-next 0/1] selftests: drv-net: XDP RX checksum metadata test Vladimir Vdovin
2026-07-08 12:51 ` [PATCH bpf-next 1/1] selftests: drv-net: add XDP RX checksum metadata tests Vladimir Vdovin
2026-07-08 13:19 ` sashiko-bot
2026-07-08 13:28 ` bot+bpf-ci
2026-07-08 15:12 ` [PATCH bpf-next 0/1] selftests: drv-net: XDP RX checksum metadata test Lorenzo Bianconi
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=20260630192759.7E6D31F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=deliran@verdict.gg \
--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.