BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Lorenzo Bianconi" <lorenzo@kernel.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v5 7/8] selftests/bpf: Add test for bpf_skb_rx_checksum kfunc
Date: Wed, 15 Jul 2026 22:08:19 +0000	[thread overview]
Message-ID: <20260715220819.D39621F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260715-bpf-xdp-meta-rxcksum-v5-7-623d5c0d0ab7@kernel.org>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The `csum_cnt` array map is sized incorrectly and explicitly drops valid `SKB_CSUM_PARTIAL` checksum states.
- [Low] Passing an `enum skb_csum *` to a kfunc expecting a `__u32 *` causes an incompatible pointer type warning.
- [Low] The multi-line comment for `bpf_skb_rx_checksum` violates the required BPF subsystem comment style.
--

--- Patch [7]: [PATCH bpf-next v5 7/8] selftests/bpf: Add test for bpf_skb_rx_checksum kfunc ---
commit b45897a4d5ef22742e4af5ab8e7a00ba0c92d2f2
Author: Lorenzo Bianconi <lorenzo@kernel.org>

selftests/bpf: Add test for bpf_skb_rx_checksum kfunc

This commit adds a selftest for the newly added bpf_skb_rx_checksum() kfunc.
The test consists of a TC BPF program that calls the kfunc and records the
checksum type, along with a userspace test runner.

> diff --git a/tools/testing/selftests/bpf/bpf_kfuncs.h b/tools/testing/selftests/bpf/bpf_kfuncs.h
> index ae71e9b690518..d03572e26df2d 100644
> --- a/tools/testing/selftests/bpf/bpf_kfuncs.h
> +++ b/tools/testing/selftests/bpf/bpf_kfuncs.h
> @@ -64,6 +64,14 @@ struct bpf_tcp_req_attrs;
>  extern int bpf_sk_assign_tcp_reqsk(struct __sk_buff *skb, struct sock *sk,
>  				   struct bpf_tcp_req_attrs *attrs, int attrs__sz) __ksym;
>  
> +/* Description
> + *  Read skb RX checksum info (ip_summed and csum_meta).

[Severity: Low]
This isn't a bug, but does this multi-line comment follow the BPF subsystem
comment style? The guidelines require the opening /* to be on its own line.

> + * Returns
> + *  0 on success
> + */
> +extern int bpf_skb_rx_checksum(struct __sk_buff *skb, __u32 *ip_summed,
> +			       __u32 *csum_meta) __ksym;
> +

[ ... ]

> diff --git a/tools/testing/selftests/bpf/progs/skb_rx_checksum.c b/tools/testing/selftests/bpf/progs/skb_rx_checksum.c
> new file mode 100644
> index 0000000000000..dc4e192905d53
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/skb_rx_checksum.c
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <linux/bpf.h>
> +#include <linux/pkt_cls.h>
> +#include <bpf/bpf_helpers.h>
> +#include "bpf_kfuncs.h"
> +#include "skb_rx_checksum.h"
> +
> +struct {
> +	__uint(type, BPF_MAP_TYPE_ARRAY);
> +	__uint(max_entries, SKB_CSUM_PARTIAL);

[Severity: Medium]
Does this incorrectly restrict the map size? SKB_CSUM_PARTIAL is defined as
3, which means the map can only hold entries for 0, 1, and 2, leaving no
room to track the SKB_CSUM_PARTIAL state itself.

> +	__type(key, __u32);
> +	__type(value, __u64);
> +} csum_cnt SEC(".maps");
> +
> +SEC("tc")
> +int tc_rx_csum(struct __sk_buff *skb)
> +{
> +	enum skb_csum ip_summed;
> +	__u32 csum_meta;
> +	__u64 *cnt;
> +
> +	bpf_skb_rx_checksum(skb, &ip_summed, &csum_meta);

[Severity: Low]
Will this cause an incompatible pointer type compiler warning in
tc_rx_csum()? The kfunc bpf_skb_rx_checksum() expects a __u32 * for its
second argument, but &ip_summed is a pointer to an enum skb_csum.

> +	if (ip_summed < SKB_CSUM_PARTIAL) {

[Severity: Medium]
By using strictly less than SKB_CSUM_PARTIAL, does this silently drop valid
packets that have the SKB_CSUM_PARTIAL state?

> +		cnt = bpf_map_lookup_elem(&csum_cnt, &ip_summed);
> +		if (cnt)
> +			__sync_fetch_and_add(cnt, 1);
> +	}
> +
> +	return TC_ACT_OK;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715-bpf-xdp-meta-rxcksum-v5-0-623d5c0d0ab7@kernel.org?part=7

  reply	other threads:[~2026-07-15 22:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15 21:39 [PATCH bpf-next v5 0/8] Add the the capability to load HW RX checksum in eBPF programs Lorenzo Bianconi
2026-07-15 21:39 ` [PATCH bpf-next v5 1/8] netlink: specs: add XDP RX checksum capability to XDP metadata specs Lorenzo Bianconi
2026-07-15 22:24   ` bot+bpf-ci
2026-07-15 21:39 ` [PATCH bpf-next v5 2/8] net: veth: add xmo_rx_checksum callback to veth driver Lorenzo Bianconi
2026-07-15 22:08   ` sashiko-bot
2026-07-15 21:39 ` [PATCH bpf-next v5 3/8] net: ice: add xmo_rx_checksum callback Lorenzo Bianconi
2026-07-15 21:48   ` sashiko-bot
2026-07-15 21:39 ` [PATCH bpf-next v5 4/8] selftests/bpf: add selftest support for bpf_xdp_metadata_rx_checksum Lorenzo Bianconi
2026-07-15 21:39 ` [PATCH bpf-next v5 5/8] selftests/bpf: add bpf_xdp_metadata_rx_checksum support to xdp_hw_metadat prog Lorenzo Bianconi
2026-07-15 21:39 ` [PATCH bpf-next v5 6/8] net: add bpf_skb_rx_checksum kfunc to read skb checksum metadata Lorenzo Bianconi
2026-07-15 21:39 ` [PATCH bpf-next v5 7/8] selftests/bpf: Add test for bpf_skb_rx_checksum kfunc Lorenzo Bianconi
2026-07-15 22:08   ` sashiko-bot [this message]
2026-07-15 21:39 ` [PATCH bpf-next v5 8/8] selftests: net: add test for XDP_PASS skb checksum invalidation Lorenzo Bianconi
2026-07-15 21:58   ` sashiko-bot

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=20260715220819.D39621F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=lorenzo@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox