From: Yonghong Song <yonghong.song@linux.dev>
To: Anton Protopopov <aspsk@isovalent.com>,
bpf@vger.kernel.org, Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Eduard Zingerman <eddyz87@gmail.com>,
Quentin Monnet <qmo@kernel.org>,
Alexei Starovoitov <ast@kernel.org>
Subject: Re: [RFC PATCH bpf-next 03/14] selftests/bpf: add selftests for new insn_set map
Date: Tue, 18 Mar 2025 13:56:07 -0700 [thread overview]
Message-ID: <ea842369-6e90-40f9-a891-0c4a6a6e565c@linux.dev> (raw)
In-Reply-To: <20250318143318.656785-4-aspsk@isovalent.com>
On 3/18/25 7:33 AM, Anton Protopopov wrote:
> Tests are split in two parts.
>
> The `bpf_insn_set_ops` test checks that the map is managed properly:
>
> * Incorrect instruction indexes are rejected
> * Non-sorted and non-unique indexes are rejected
> * Unfrozen maps are not accepted
> * Two programs can't use the same map
> * BPF progs can't operate the map
>
> The `bpf_insn_set_reloc` part validates, as best as it can do it from user
> space, that instructions are relocated properly:
>
> * no relocations => map is the same
> * expected relocations when instructions are added
> * expected relocations when instructions are deleted
> * expected relocations when multiple functions are present
>
> Signed-off-by: Anton Protopopov <aspsk@isovalent.com>
> ---
> .../selftests/bpf/prog_tests/bpf_insn_set.c | 639 ++++++++++++++++++
> 1 file changed, 639 insertions(+)
> create mode 100644 tools/testing/selftests/bpf/prog_tests/bpf_insn_set.c
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_insn_set.c b/tools/testing/selftests/bpf/prog_tests/bpf_insn_set.c
> new file mode 100644
> index 000000000000..796980bd4fcb
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/bpf_insn_set.c
> @@ -0,0 +1,639 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <bpf/bpf.h>
> +#include <test_progs.h>
> +
> +static inline int map_create(__u32 map_type, __u32 max_entries)
> +{
> + const char *map_name = "insn_set";
> + __u32 key_size = 4;
> + __u32 value_size = 4;
> +
> + return bpf_map_create(map_type, map_name, key_size, value_size, max_entries, NULL);
> +}
> +
> +/*
> + * Load a program, which will not be anyhow mangled by the verifier. Add an
> + * insn_set map pointing to every instruction. Check that it hasn't changed
> + * after the program load.
> + */
> +static void check_one_to_one_mapping(void)
> +{
> + struct bpf_insn insns[] = {
> + BPF_MOV64_IMM(BPF_REG_0, 4),
> + BPF_MOV64_IMM(BPF_REG_0, 3),
> + BPF_MOV64_IMM(BPF_REG_0, 2),
> + BPF_MOV64_IMM(BPF_REG_0, 1),
> + BPF_MOV64_IMM(BPF_REG_0, 0),
> + BPF_EXIT_INSN(),
> + };
> + int prog_fd, map_fd;
prog_fd needs to be initialized to something like -1.
> + union bpf_attr attr = {
> + .prog_type = BPF_PROG_TYPE_XDP, /* we don't care */
> + .insns = ptr_to_u64(insns),
> + .insn_cnt = ARRAY_SIZE(insns),
> + .license = ptr_to_u64("GPL"),
> + .fd_array = ptr_to_u64(&map_fd),
> + .fd_array_cnt = 1,
> + };
> + int i;
> +
> + map_fd = map_create(BPF_MAP_TYPE_INSN_SET, ARRAY_SIZE(insns));
> + if (!ASSERT_GE(map_fd, 0, "map_create"))
> + return;
> +
> + for (i = 0; i < ARRAY_SIZE(insns); i++)
> + if (!ASSERT_EQ(bpf_map_update_elem(map_fd, &i, &i, 0), 0, "bpf_map_update_elem"))
> + goto cleanup;
Otherwise, goto cleanup here will goto cleanup and close(prog_fd) will close
a random prog_fd. Please check the rest of prog_fd usage.
> +
> + if (!ASSERT_EQ(bpf_map_freeze(map_fd), 0, "bpf_map_freeze"))
> + return;
> +
> + prog_fd = syscall(__NR_bpf, BPF_PROG_LOAD, &attr, sizeof(attr));
> + if (!ASSERT_GE(prog_fd, 0, "bpf(BPF_PROG_LOAD)"))
> + goto cleanup;
> +
> + for (i = 0; i < ARRAY_SIZE(insns); i++) {
> + __u32 val;
> +
> + if (!ASSERT_EQ(bpf_map_lookup_elem(map_fd, &i, &val), 0, "bpf_map_lookup_elem"))
> + goto cleanup;
> +
> + ASSERT_EQ(val, i, "val should be equal i");
> + }
> +
> +cleanup:
> + close(prog_fd);
> + close(map_fd);
> +}
> +
[...]
next prev parent reply other threads:[~2025-03-18 20:56 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 14:33 [RFC PATCH bpf-next 00/14] instruction sets and static keys Anton Protopopov
2025-03-18 14:33 ` [RFC PATCH bpf-next 01/14] bpf: fix a comment describing bpf_attr Anton Protopopov
2025-03-18 14:33 ` [RFC PATCH bpf-next 02/14] bpf: add new map type: instructions set Anton Protopopov
2025-03-20 7:56 ` Leon Hwang
2025-03-20 9:34 ` Anton Protopopov
2025-03-18 14:33 ` [RFC PATCH bpf-next 03/14] selftests/bpf: add selftests for new insn_set map Anton Protopopov
2025-03-18 20:56 ` Yonghong Song [this message]
2025-03-19 17:26 ` Anton Protopopov
2025-03-19 17:30 ` Anton Protopopov
2025-03-18 14:33 ` [RFC PATCH bpf-next 04/14] bpf: add support for an extended JA instruction Anton Protopopov
2025-03-18 19:00 ` David Faust
2025-03-18 19:24 ` Anton Protopopov
2025-03-18 19:30 ` David Faust
2025-03-18 19:47 ` Anton Protopopov
2025-03-18 14:33 ` [RFC PATCH bpf-next 05/14] bpf: Add kernel/bpftool asm support for new instructions Anton Protopopov
2025-03-18 14:33 ` [RFC PATCH bpf-next 06/14] bpf: add BPF_STATIC_KEY_UPDATE syscall Anton Protopopov
2025-03-18 14:33 ` [RFC PATCH bpf-next 07/14] bpf: save the start of functions in bpf_prog_aux Anton Protopopov
2025-03-18 14:33 ` [RFC PATCH bpf-next 08/14] bpf, x86: implement static key support Anton Protopopov
2025-03-18 14:33 ` [RFC PATCH bpf-next 09/14] selftests/bpf: add guard macros around likely/unlikely Anton Protopopov
2025-03-18 14:33 ` [RFC PATCH bpf-next 10/14] libbpf: add likely/unlikely macros Anton Protopopov
2025-03-28 20:57 ` Andrii Nakryiko
2025-03-29 13:38 ` Anton Protopopov
2025-03-31 20:10 ` Andrii Nakryiko
2025-03-18 14:33 ` [RFC PATCH bpf-next 11/14] selftests/bpf: remove likely/unlikely definitions Anton Protopopov
2025-03-18 14:33 ` [RFC PATCH bpf-next 12/14] libbpf: BPF Static Keys support Anton Protopopov
2025-03-18 14:33 ` [RFC PATCH bpf-next 13/14] libbpf: Add bpf_static_key_update() API Anton Protopopov
2025-03-18 14:33 ` [RFC PATCH bpf-next 14/14] selftests/bpf: Add tests for BPF static calls Anton Protopopov
2025-03-18 20:53 ` Yonghong Song
2025-03-18 21:00 ` Anton Protopopov
2025-03-18 21:00 ` [RFC PATCH bpf-next 00/14] instruction sets and static keys Yonghong Song
2025-03-19 17:45 ` Anton Protopopov
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=ea842369-6e90-40f9-a891-0c4a6a6e565c@linux.dev \
--to=yonghong.song@linux.dev \
--cc=andrii@kernel.org \
--cc=aspsk@isovalent.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=qmo@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