All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Protopopov <a.s.protopopov@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Anton Protopopov <aspsk@isovalent.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Quentin Monnet <qmo@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>
Subject: Re: [PATCH v10 bpf-next 02/11] selftests/bpf: add selftests for new insn_array map
Date: Tue, 4 Nov 2025 13:52:20 +0000	[thread overview]
Message-ID: <aQoFFPSIDLW0YDK1@mail.gmail.com> (raw)
In-Reply-To: <CAADnVQ+soo36eMJxcnLhbU+jTz053vd7NU-Dm46U+EJnWAzuTA@mail.gmail.com>

On 25/11/03 06:10PM, Alexei Starovoitov wrote:
> On Sun, Nov 2, 2025 at 12:52 PM Anton Protopopov
> <a.s.protopopov@gmail.com> wrote:
> >
> > Add the following selftests for new insn_array map:
> >
> >   * Incorrect instruction indexes are rejected
> >   * Two programs can't use the same map
> >   * BPF progs can't operate the map
> >   * no changes to code => map is the same
> >   * expected changes when instructions are added
> >   * expected changes when instructions are deleted
> >   * expected changes when multiple functions are present
> >
> > Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
> > Acked-by: Eduard Zingerman <eddyz87@gmail.com>
> > ---
> >  .../selftests/bpf/prog_tests/bpf_insn_array.c | 409 ++++++++++++++++++
> >  1 file changed, 409 insertions(+)
> >  create mode 100644 tools/testing/selftests/bpf/prog_tests/bpf_insn_array.c
> >
> > diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_insn_array.c b/tools/testing/selftests/bpf/prog_tests/bpf_insn_array.c
> > new file mode 100644
> > index 000000000000..96ee9c9984f1
> > --- /dev/null
> > +++ b/tools/testing/selftests/bpf/prog_tests/bpf_insn_array.c
> > @@ -0,0 +1,409 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#include <bpf/bpf.h>
> > +#include <test_progs.h>
> > +
> > +#ifdef __x86_64__
> > +static int map_create(__u32 map_type, __u32 max_entries)
> > +{
> > +       const char *map_name = "insn_array";
> > +       __u32 key_size = 4;
> > +       __u32 value_size = sizeof(struct bpf_insn_array_value);
> > +
> > +       return bpf_map_create(map_type, map_name, key_size, value_size, max_entries, NULL);
> > +}
> > +
> > +static int prog_load(struct bpf_insn *insns, __u32 insn_cnt, int *fd_array, __u32 fd_array_cnt)
> > +{
> > +       LIBBPF_OPTS(bpf_prog_load_opts, opts);
> > +
> > +       opts.fd_array = fd_array;
> > +       opts.fd_array_cnt = fd_array_cnt;
> > +
> > +       return bpf_prog_load(BPF_PROG_TYPE_XDP, NULL, "GPL", insns, insn_cnt, &opts);
> > +}
> > +
> > +static void __check_success(struct bpf_insn *insns, __u32 insn_cnt, __u32 *map_in, __u32 *map_out)
> > +{
> > +       struct bpf_insn_array_value val = {};
> > +       int prog_fd = -1, map_fd, i;
> > +
> > +       map_fd = map_create(BPF_MAP_TYPE_INSN_ARRAY, insn_cnt);
> > +       if (!ASSERT_GE(map_fd, 0, "map_create"))
> > +               return;
> > +
> > +       for (i = 0; i < insn_cnt; i++) {
> > +               val.orig_off = map_in[i];
> > +               if (!ASSERT_EQ(bpf_map_update_elem(map_fd, &i, &val, 0), 0, "bpf_map_update_elem"))
> > +                       goto cleanup;
> > +       }
> > +
> > +       if (!ASSERT_EQ(bpf_map_freeze(map_fd), 0, "bpf_map_freeze"))
> > +               goto cleanup;
> > +
> > +       prog_fd = prog_load(insns, insn_cnt, &map_fd, 1);
> > +       if (!ASSERT_GE(prog_fd, 0, "bpf(BPF_PROG_LOAD)"))
> > +               goto cleanup;
> > +
> > +       for (i = 0; i < insn_cnt; i++) {
> > +               char buf[64];
> > +
> > +               if (!ASSERT_EQ(bpf_map_lookup_elem(map_fd, &i, &val), 0, "bpf_map_lookup_elem"))
> > +                       goto cleanup;
> > +
> > +               snprintf(buf, sizeof(buf), "val.xlated_off should be equal map_out[%d]", i);
> > +               ASSERT_EQ(val.xlated_off, map_out[i], buf);
> > +       }
> > +
> > +cleanup:
> > +       close(prog_fd);
> > +       close(map_fd);
> > +}
> > +
> > +/*
> > + * Load a program, which will not be anyhow mangled by the verifier.  Add an
> > + * insn_array 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(),
> > +       };
> > +       __u32 map_in[] = {0, 1, 2, 3, 4, 5};
> > +       __u32 map_out[] = {0, 1, 2, 3, 4, 5};
> > +
> > +       __check_success(insns, ARRAY_SIZE(insns), map_in, map_out);
> > +}
> > +
> > +/*
> > + * Load a program with two patches (get jiffies, for simplicity). Add an
> > + * insn_array map pointing to every instruction. Check how it was changed
> > + * after the program load.
> > + */
> > +static void check_simple(void)
> > +{
> > +       struct bpf_insn insns[] = {
> > +               BPF_MOV64_IMM(BPF_REG_0, 2),
> > +               BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_jiffies64),
> > +               BPF_MOV64_IMM(BPF_REG_0, 1),
> > +               BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_jiffies64),
> > +               BPF_MOV64_IMM(BPF_REG_0, 0),
> > +               BPF_EXIT_INSN(),
> > +       };
> > +       __u32 map_in[] = {0, 1, 2, 3, 4, 5};
> > +       __u32 map_out[] = {0, 1, 4, 5, 8, 9};
> > +
> > +       __check_success(insns, ARRAY_SIZE(insns), map_in, map_out);
> > +}
> > +
> > +/*
> > + * Verifier can delete code in two cases: nops & dead code. From insn
> > + * array's point of view, the two cases are the same, so test using
> > + * the simplest method: by loading some nops
> > + */
> > +static void check_deletions(void)
> > +{
> > +       struct bpf_insn insns[] = {
> > +               BPF_MOV64_IMM(BPF_REG_0, 2),
> > +               BPF_JMP_IMM(BPF_JA, 0, 0, 0), /* nop */
> > +               BPF_MOV64_IMM(BPF_REG_0, 1),
> > +               BPF_JMP_IMM(BPF_JA, 0, 0, 0), /* nop */
> > +               BPF_MOV64_IMM(BPF_REG_0, 0),
> > +               BPF_EXIT_INSN(),
> > +       };
> > +       __u32 map_in[] = {0, 1, 2, 3, 4, 5};
> > +       __u32 map_out[] = {0, -1, 1, -1, 2, 3};
> > +
> > +       __check_success(insns, ARRAY_SIZE(insns), map_in, map_out);
> > +}
> > +
> > +/*
> > + * Same test as check_deletions, but also add code which adds instructions
> > + */
> > +static void check_deletions_with_functions(void)
> > +{
> > +       struct bpf_insn insns[] = {
> > +               BPF_JMP_IMM(BPF_JA, 0, 0, 0), /* nop */
> > +               BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_jiffies64),
> > +               BPF_JMP_IMM(BPF_JA, 0, 0, 0), /* nop */
> > +               BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 1, 0, 2),
> > +               BPF_MOV64_IMM(BPF_REG_0, 1),
> > +               BPF_EXIT_INSN(),
> > +               BPF_JMP_IMM(BPF_JA, 0, 0, 0), /* nop */
> > +               BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_jiffies64),
> > +               BPF_JMP_IMM(BPF_JA, 0, 0, 0), /* nop */
> > +               BPF_MOV64_IMM(BPF_REG_0, 2),
> > +               BPF_EXIT_INSN(),
> > +       };
> > +       __u32 map_in[] =  { 0, 1,  2, 3, 4, 5, /* func */  6, 7,  8, 9, 10};
> > +       __u32 map_out[] = {-1, 0, -1, 3, 4, 5, /* func */ -1, 6, -1, 9, 10};
> > +
> > +       __check_success(insns, ARRAY_SIZE(insns), map_in, map_out);
> > +}
> 
> I was thinking of taking the first 5 patches, but this one fails:
> ./test_progs -t bpf_insn_array
> ...
> #19/4    bpf_insn_array/deletions-with-functions:FAIL
> #19/5    bpf_insn_array/blindness:OK
> #19/6    bpf_insn_array/incorrect-index:OK
> #19/7    bpf_insn_array/load-unfrozen-map:OK
> #19/8    bpf_insn_array/no-map-reuse:OK
> #19/9    bpf_insn_array/bpf-side-ops:OK
> #19      bpf_insn_array:FAIL
> 
> I don't see what you're changing later in the patches
> to make it pass, but the failure highlights the issue with
> bisectability. Pls take a look.

Thanks! I've found the chunk, it was

@@ -21664,2 +21705,4 @@ static int jit_subprogs(struct bpf_verifier_env *env)
                func[i]->aux->arena = prog->aux->arena;
+               func[i]->aux->used_maps = env->used_maps;
+               func[i]->aux->used_map_cnt = env->used_map_cnt;
                num_exentries = 0;

> This one also fails:
> #170/3   libbpf_str/bpf_map_type_str:FAIL
> #170     libbpf_str:FAIL
> 
> I was thinking of hacking it as an extra patch
> (without full support in patch 8), but gave up when I saw
> deletions-with-functions failing.
> 
> Maybe also split the main libbpf patch into prep patch
> with basic introduction of insn_array ?

I've split a commit that teaches libbpf about insn_array + moved
the bpftool commit lower. All the tests pass now.

> Or keep it as-is, if respin comes soon.

I can send the first chunk separately today,
or the whole thing a few days later.

> [...]

  reply	other threads:[~2025-11-04 13:46 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-02 20:57 [PATCH v10 bpf-next 00/11] BPF indirect jumps Anton Protopopov
2025-11-02 20:57 ` [PATCH v10 bpf-next 01/11] bpf, x86: add new map type: instructions array Anton Protopopov
2025-11-02 20:57 ` [PATCH v10 bpf-next 02/11] selftests/bpf: add selftests for new insn_array map Anton Protopopov
2025-11-04  2:10   ` Alexei Starovoitov
2025-11-04 13:52     ` Anton Protopopov [this message]
2025-11-04 16:49       ` Alexei Starovoitov
2025-11-05  6:35         ` Anton Protopopov
2025-11-02 20:57 ` [PATCH v10 bpf-next 03/11] bpf: support instructions arrays with constants blinding Anton Protopopov
2025-11-02 20:57 ` [PATCH v10 bpf-next 04/11] selftests/bpf: test instructions arrays with blinding Anton Protopopov
2025-11-02 20:57 ` [PATCH v10 bpf-next 05/11] bpf, x86: allow indirect jumps to r8...r15 Anton Protopopov
2025-11-02 20:57 ` [PATCH v10 bpf-next 06/11] bpf, x86: add support for indirect jumps Anton Protopopov
2025-11-02 21:20   ` bot+bpf-ci
2025-11-02 22:00     ` Anton Protopopov
2025-11-02 20:57 ` [PATCH v10 bpf-next 07/11] bpf: disasm: add support for BPF_JMP|BPF_JA|BPF_X Anton Protopopov
2025-11-02 20:57 ` [PATCH v10 bpf-next 08/11] libbpf: support llvm-generated indirect jumps Anton Protopopov
2025-11-02 21:13   ` bot+bpf-ci
2025-11-02 21:36     ` Anton Protopopov
2025-11-02 21:38     ` Anton Protopopov
2025-11-03  0:32       ` Ihor Solodrai
2025-11-03  0:58         ` Chris Mason
2025-11-03  8:29           ` Anton Protopopov
2025-11-03  8:21         ` Anton Protopopov
2025-11-04  1:15   ` Eduard Zingerman
2025-11-04  1:30     ` Eduard Zingerman
2025-11-04  5:26     ` Yonghong Song
2025-11-04 18:31       ` Eduard Zingerman
2025-11-05  8:12         ` Anton Protopopov
2025-11-02 20:57 ` [PATCH v10 bpf-next 09/11] bpftool: Recognize insn_array map type Anton Protopopov
2025-11-02 20:57 ` [PATCH v10 bpf-next 10/11] selftests/bpf: add new verifier_gotox test Anton Protopopov
2025-11-02 20:57 ` [PATCH v10 bpf-next 11/11] selftests/bpf: add C-level selftests for indirect jumps Anton Protopopov
2025-11-03 20:45   ` Eduard Zingerman
2025-11-05  7:26     ` 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=aQoFFPSIDLW0YDK1@mail.gmail.com \
    --to=a.s.protopopov@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --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 \
    --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.