From: Quentin Monnet <qmo@kernel.org>
To: Tianyi Chen <hi@tychen.cc>, bpf@vger.kernel.org
Cc: andrii@kernel.org, eddyz87@gmail.com, ihor.solodrai@linux.dev,
linux-kselftest@vger.kernel.org, shuah@kernel.org,
daniel@iogearbox.net, ast@kernel.org,
alexei.starovoitov@gmail.com
Subject: Re: [PATCH bpf-next v9 2/2] selftests/bpf: Check bpftool batch map dumps
Date: Tue, 10 Nov 2026 16:46:53 +0000 [thread overview]
Message-ID: <a24ec940-ca3b-419b-85ae-9de88cd991d9@kernel.org> (raw)
In-Reply-To: <e4cd18723b893385d66232276f44049bb86c8e51.1793821981.git.hi@tychen.cc>
On 04/11/2026 19:54, Tianyi Chen wrote:
> Batched dumps must print the same output as individual lookups. Use an
> fmod_ret program on security_bpf() to count the map lookups made by
> bpftool children of the test, and to fail batch lookups with -EBUSY.
>
> For each map type with batched lookups, compare plain and JSON dumps
> with a dump whose batch lookups all fail, and check that no individual
> lookups were needed. Cover BTF and per-CPU output, an empty map, 1-byte
> keys and unaligned values. With 4 KiB values, check dumps that need
> several batches, and that failing the first or second batch lookup
> continues with individual lookups without restarting the dump.
>
> Pre-size RHASH maps so asynchronous growth does not race with the
> order-sensitive dump comparisons.
>
> Assisted-by: LLM
> Signed-off-by: Tianyi Chen <hi@tychen.cc>
Acked-by: Quentin Monnet <qmo@kernel.org>
... with a few, non-blocking suggestions, inline below.
> ---
> .../bpf/prog_tests/bpftool_map_batch.c | 231 ++++++++++++++++++
> .../selftests/bpf/progs/bpftool_map_batch.c | 42 ++++
> 2 files changed, 273 insertions(+)
> create mode 100644 tools/testing/selftests/bpf/prog_tests/bpftool_map_batch.c
> create mode 100644 tools/testing/selftests/bpf/progs/bpftool_map_batch.c
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/bpftool_map_batch.c b/tools/testing/selftests/bpf/prog_tests/bpftool_map_batch.c
> new file mode 100644
> index 0000000000000..4cca77f410a06
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/bpftool_map_batch.c
Maybe bpftool_map_dump_batch.c, so it's easier to visually group with
the existing bpftool_map_dump.c?
> @@ -0,0 +1,231 @@
[...]
> +void test_bpftool_map_batch(void)
> +{
> + static const struct dump_case cases[] = {
> + { "hash", BPF_MAP_TYPE_HASH, 4, 4, 100 },
> + { "empty", BPF_MAP_TYPE_HASH, 4, 4, 0 },
> + /* The hash cursor is wider than the key; values are unaligned. */
> + { "odd_sizes", BPF_MAP_TYPE_HASH, 1, 3, 100 },
> + { "btf", BPF_MAP_TYPE_HASH, 4, 4, 100, true },
> + { "lru_hash", BPF_MAP_TYPE_LRU_HASH, 4, 4, 100 },
> + { "percpu_hash", BPF_MAP_TYPE_PERCPU_HASH, 4, 3, 100 },
> + { "lru_percpu_hash", BPF_MAP_TYPE_LRU_PERCPU_HASH, 4, 4, 100 },
If I remember correctly, lru_hash/lru_percpu_hash are mostly the same
code as hash/percpu_hash, so I'm not sure they're worth testing, unless
you want completeness.
You could also avoid checking both plain and JSON for all types (pick
one, and just do a few check for the other?), if you want to save some
bpftool invocations; I don't expect differences in the code related to
batch lookups between the plain and JSON output printing code.
> + { "btf_percpu_hash", BPF_MAP_TYPE_PERCPU_HASH, 4, 4, 100, true },
> + { "rhash", BPF_MAP_TYPE_RHASH, 4, 4, 100 },
> + { "array", BPF_MAP_TYPE_ARRAY, 4, 4, 100 },
> + { "percpu_array", BPF_MAP_TYPE_PERCPU_ARRAY, 4, 3, 100 },
> + { "lpm_trie", BPF_MAP_TYPE_LPM_TRIE, 8, 4, 100 },
> + { "array_of_maps", BPF_MAP_TYPE_ARRAY_OF_MAPS, 4, 4, 100 },
> + { "hash_of_maps", BPF_MAP_TYPE_HASH_OF_MAPS, 4, 4, 100 },
> + /* Bucket and key cursors, up to 255 entries per batch. */
> + { "multi_batch_hash", BPF_MAP_TYPE_HASH, 4, 4096, 256, false, true },
> + { "multi_batch_array", BPF_MAP_TYPE_ARRAY, 4, 4096, 256, false, true },
> + };
> + struct bpftool_map_batch *skel;
> + char *expected = NULL, *output = NULL;
> + unsigned int i;
> +
> + skel = bpftool_map_batch__open_and_load();
> + if (!ASSERT_OK_PTR(skel, "skel_open_and_load"))
> + return;
> + skel->bss->test_tgid = getpid();
> + if (!ASSERT_OK(bpftool_map_batch__attach(skel), "skel_attach"))
> + goto out;
> + expected = malloc(OUTPUT_SIZE);
> + output = malloc(OUTPUT_SIZE);
> + if (!ASSERT_OK_PTR(expected, "expected") || !ASSERT_OK_PTR(output, "output"))
> + goto out;
> +
> + for (i = 0; i < ARRAY_SIZE(cases); i++)
> + if (test__start_subtest(cases[i].name))
> + run_case(skel, &cases[i], expected, output);
> +out:
> + free(expected);
> + free(output);
> + bpftool_map_batch__destroy(skel);
> +}
> diff --git a/tools/testing/selftests/bpf/progs/bpftool_map_batch.c b/tools/testing/selftests/bpf/progs/bpftool_map_batch.c
> new file mode 100644
> index 0000000000000..0ca6f7973e880
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/bpftool_map_batch.c
bpftool_map_dump_batch.c?
prev parent reply other threads:[~2026-11-10 16:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 19:54 [PATCH bpf-next v9 0/2] bpftool: Use batch lookups for map dumps Tianyi Chen
2026-11-04 19:54 ` [PATCH bpf-next v9 1/2] " Tianyi Chen
2026-11-04 20:31 ` bot+bpf-ci
2026-11-07 13:12 ` Tianyi Chen
2026-11-10 16:46 ` Quentin Monnet
2026-11-04 19:54 ` [PATCH bpf-next v9 2/2] selftests/bpf: Check bpftool batch " Tianyi Chen
2026-11-10 16:46 ` Quentin Monnet [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=a24ec940-ca3b-419b-85ae-9de88cd991d9@kernel.org \
--to=qmo@kernel.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=hi@tychen.cc \
--cc=ihor.solodrai@linux.dev \
--cc=linux-kselftest@vger.kernel.org \
--cc=shuah@kernel.org \
/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