All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Protopopov <aspsk@isovalent.com>
To: Yonghong Song <yonghong.song@linux.dev>
Cc: 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: Wed, 19 Mar 2025 17:26:44 +0000	[thread overview]
Message-ID: <Z9r+VKRvY+pHesPa@mail.gmail.com> (raw)
In-Reply-To: <ea842369-6e90-40f9-a891-0c4a6a6e565c@linux.dev>

On 25/03/18 01:56PM, Yonghong Song wrote:
> 
> 
> 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.

Thanks! I've fixed this and similar occurrences.

Also replaced syscall(BPF_PROG_LOAD) with libbpf wrappers, so the code
is a bit shorter now.  Will resend the patch to this thread shortly.

> > +	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-19 17:23 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
2025-03-19 17:26     ` Anton Protopopov [this message]
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=Z9r+VKRvY+pHesPa@mail.gmail.com \
    --to=aspsk@isovalent.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=qmo@kernel.org \
    --cc=yonghong.song@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.