public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
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);
> +}
> +

[...]


  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