From: sashiko-bot@kernel.org
To: "Tianyi Chen" <diannaaav@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf v3] selftests/bpf: Check returned keys in map batch validators
Date: Fri, 11 Sep 2026 02:57:13 +0000 [thread overview]
Message-ID: <20260911025713.AB5891F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260911025036.190487-1-diannaaav@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch introduces new uses of the deprecated `CHECK()` macro for assertions instead of migrating to the required `ASSERT_*()` macros.
--
commit ea80e2126710dbf0e0f3a1f8861acf3e34b2207d
Author: Tianyi Chen <hi@tychen.cc>
selftests/bpf: Check returned keys in map batch validators
This patch updates the hash, array and LPM trie batch validators to check
returned keys against the populated set, and indexes the visited array by
key. It aims to detect missing entries while preserving unordered results
and per-CPU value validation.
> diff --git a/tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c b/tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c
> index b595556315bc3..76d3800a82af9 100644
> --- a/tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c
> +++ b/tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c
> @@ -45,6 +45,9 @@ static void map_batch_verify(int *visited, __u32 max_entries, int *keys,
>
> memset(visited, 0, max_entries * sizeof(*visited));
> for (i = 0; i < max_entries; i++) {
> + CHECK(keys[i] < 0 || keys[i] >= max_entries, "key checking",
> + "error: i %d key %d out of range\n", i, keys[i]);
> +
[Severity: Low]
Does this new assertion use a deprecated macro?
According to the BPF selftest subsystem guidelines, the CHECK() macro is
deprecated and should be avoided in new tests or patches. Should we use the
modern ASSERT_*() family of macros (like ASSERT_GE and ASSERT_LT) here
instead?
[ ... ]
> diff --git a/tools/testing/selftests/bpf/map_tests/htab_map_batch_ops.c b/tools/testing/selftests/bpf/map_tests/htab_map_batch_ops.c
> index 5da493b94ae25..430949f9691d7 100644
> --- a/tools/testing/selftests/bpf/map_tests/htab_map_batch_ops.c
> +++ b/tools/testing/selftests/bpf/map_tests/htab_map_batch_ops.c
> @@ -50,6 +50,8 @@ static void map_batch_verify(int *visited, __u32 max_entries,
>
> memset(visited, 0, max_entries * sizeof(*visited));
> for (i = 0; i < max_entries; i++) {
> + CHECK(keys[i] < 1 || keys[i] > max_entries, "key checking",
> + "error: i %d key %d out of range\n", i, keys[i]);
[Severity: Low]
Could this assertion also be replaced with ASSERT_GE() and ASSERT_LE() to
follow current selftests standards?
[ ... ]
> diff --git a/tools/testing/selftests/bpf/map_tests/lpm_trie_map_batch_ops.c b/tools/testing/selftests/bpf/map_tests/lpm_trie_map_batch_ops.c
> index fe3e19f962446..3b51670b3cd4b 100644
> --- a/tools/testing/selftests/bpf/map_tests/lpm_trie_map_batch_ops.c
> +++ b/tools/testing/selftests/bpf/map_tests/lpm_trie_map_batch_ops.c
> @@ -44,18 +44,19 @@ static void map_batch_update(int map_fd, __u32 max_entries,
> static void map_batch_verify(int *visited, __u32 max_entries,
> struct test_lpm_key *keys, int *values)
> {
> - char buff[16] = { 0 };
> - int lower_byte = 0;
> - __u32 i;
> + __u32 i, ipv4, key;
>
> memset(visited, 0, max_entries * sizeof(*visited));
> for (i = 0; i < max_entries; i++) {
> - inet_ntop(AF_INET, &keys[i].ipv4, buff, 32);
> - CHECK(sscanf(buff, "192.168.1.%d", &lower_byte) == EOF,
> - "sscanf()", "error: i %d\n", i);
> - CHECK(lower_byte != values[i], "key/value checking",
> - "error: i %d key %s value %d\n", i, buff, values[i]);
> - visited[i] = 1;
> + ipv4 = ntohl(keys[i].ipv4.s_addr);
> + key = ipv4 & 0xff;
> + /* Expected keys are 192.168.1.1..max_entries with a /32 prefix. */
> + CHECK(keys[i].prefix != 32 || (ipv4 & 0xffffff00) != 0xc0a80100 ||
> + key == 0 || key > max_entries, "key checking",
> + "error: i %u prefix %u ipv4 %#x\n", i, keys[i].prefix, ipv4);
[Severity: Low]
Even though the surrounding code previously used CHECK() in this function, the
BPF guidelines indicate that we should avoid introducing new uses of it. Can we
upgrade these new assertions to use the modern ASSERT_*() macros instead?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260911025036.190487-1-diannaaav@gmail.com?part=1
next prev parent reply other threads:[~2026-09-11 2:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 2:50 [PATCH bpf v3] selftests/bpf: Check returned keys in map batch validators Tianyi Chen
2026-09-11 2:57 ` sashiko-bot [this message]
2026-09-11 3:03 ` Tianyi Chen
[not found] ` <fd1233fd7c263a4150672e1af33aaea82d625f727ead53cb681ae69bce1e6322@mail.kernel.org>
2026-09-11 11:57 ` Tianyi Chen
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=20260911025713.AB5891F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=diannaaav@gmail.com \
--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