From: Eduard Zingerman <eddyz87@gmail.com>
To: bpf@vger.kernel.org, ast@kernel.org
Cc: andrii@kernel.org, daniel@iogearbox.net, kernel-team@fb.com,
yhs@fb.com, Eduard Zingerman <eddyz87@gmail.com>
Subject: [PATCH bpf-next 4/4] selftests/bpf: check if verifier.c:check_ids() handles 64+5 ids
Date: Sat, 17 Dec 2022 04:17:11 +0200 [thread overview]
Message-ID: <20221217021711.172247-5-eddyz87@gmail.com> (raw)
In-Reply-To: <20221217021711.172247-1-eddyz87@gmail.com>
A simple program that allocates a bunch of unique register ids than
branches. The goal is to confirm that idmap used in verifier.c:check_ids()
has sufficient capacity to verify that branches converge to a same state.
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
---
.../selftests/bpf/prog_tests/verifier.c | 12 +++
.../selftests/bpf/progs/check_ids_limits.c | 77 +++++++++++++++++++
2 files changed, 89 insertions(+)
create mode 100644 tools/testing/selftests/bpf/prog_tests/verifier.c
create mode 100644 tools/testing/selftests/bpf/progs/check_ids_limits.c
diff --git a/tools/testing/selftests/bpf/prog_tests/verifier.c b/tools/testing/selftests/bpf/prog_tests/verifier.c
new file mode 100644
index 000000000000..3933141928a7
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/verifier.c
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include <test_progs.h>
+
+#include "check_ids_limits.skel.h"
+
+#define TEST_SET(skel) \
+ void test_##skel(void) \
+ { \
+ RUN_TESTS(skel); \
+ }
+
+TEST_SET(check_ids_limits)
diff --git a/tools/testing/selftests/bpf/progs/check_ids_limits.c b/tools/testing/selftests/bpf/progs/check_ids_limits.c
new file mode 100644
index 000000000000..36c4a8bbe8ca
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/check_ids_limits.c
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/bpf.h>
+#include <bpf/bpf_helpers.h>
+#include "bpf_misc.h"
+
+struct map_struct {
+ __uint(type, BPF_MAP_TYPE_ARRAY);
+ __uint(max_entries, 1);
+ __type(key, int);
+ __type(value, int);
+} map SEC(".maps");
+
+/* Make sure that verifier.c:check_ids() can handle (almost) maximal
+ * number of ids.
+ */
+SEC("?raw_tp")
+__naked __test_state_freq __log_level(2) __msg("43 to 45: safe")
+int allocate_many_ids(void)
+{
+ /* Use bpf_map_lookup_elem() as a way to get a bunch of values
+ * with unique ids.
+ */
+#define __lookup(dst) \
+ "r1 = %[map] ll;" \
+ "r2 = r10;" \
+ "r2 += -8;" \
+ "call %[bpf_map_lookup_elem];" \
+ dst " = r0;"
+ asm volatile(
+ "r0 = 0;"
+ "*(u64*)(r10 - 8) = r0;"
+ "r7 = r10;"
+ "r8 = 0;"
+ /* Spill 64 bpf_map_lookup_elem() results to stack,
+ * each lookup gets its own unique id.
+ */
+ "write_loop:"
+ "r7 += -8;"
+ "r8 += -8;"
+ __lookup("*(u64*)(r7 + 0)")
+ "if r8 != -512 goto write_loop;"
+ /* No way to source unique ids for r1-r5 as these
+ * would be clobbered by bpf_map_lookup_elem call,
+ * so make do with 64+5 unique ids.
+ */
+ __lookup("r6")
+ __lookup("r7")
+ __lookup("r8")
+ __lookup("r9")
+ __lookup("r0")
+ /* Create a branching point for states comparison. */
+/* 43: */ "if r0 != 0 goto skip_one;"
+ /* Read all registers and stack spills to make these
+ * persist in the checkpoint state.
+ */
+ "r0 = r0;"
+ "skip_one:"
+/* 45: */ "r0 = r6;"
+ "r0 = r7;"
+ "r0 = r8;"
+ "r0 = r9;"
+ "r0 = r10;"
+ "r1 = 0;"
+ "read_loop:"
+ "r0 += -8;"
+ "r1 += -8;"
+ "r2 = *(u64*)(r0 + 0);"
+ "if r1 != -512 goto read_loop;"
+ "r0 = 0;"
+ "exit;"
+ :
+ : __imm(bpf_map_lookup_elem),
+ __imm_addr(map)
+ : __clobber_all);
+#undef __lookup
+}
--
2.38.2
next prev parent reply other threads:[~2022-12-17 2:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-17 2:17 [PATCH bpf-next 0/4] reduce BPF_ID_MAP_SIZE to fit only valid programs Eduard Zingerman
2022-12-17 2:17 ` [PATCH bpf-next 1/4] selftests/bpf: support for BPF_F_TEST_STATE_FREQ in test_loader Eduard Zingerman
2022-12-17 18:44 ` Yonghong Song
2022-12-20 21:03 ` Andrii Nakryiko
2022-12-22 0:11 ` Eduard Zingerman
2022-12-22 19:07 ` Andrii Nakryiko
2022-12-17 2:17 ` [PATCH bpf-next 2/4] selftests/bpf: convenience macro for use with 'asm volatile' blocks Eduard Zingerman
2022-12-17 18:58 ` Yonghong Song
2022-12-20 21:05 ` Andrii Nakryiko
2022-12-22 0:12 ` Eduard Zingerman
2022-12-17 2:17 ` [PATCH bpf-next 3/4] bpf: reduce BPF_ID_MAP_SIZE to fit only valid programs Eduard Zingerman
2022-12-17 18:59 ` Yonghong Song
2022-12-20 21:06 ` Andrii Nakryiko
2022-12-17 2:17 ` Eduard Zingerman [this message]
2022-12-17 19:17 ` [PATCH bpf-next 4/4] selftests/bpf: check if verifier.c:check_ids() handles 64+5 ids Yonghong Song
2022-12-20 21:18 ` Andrii Nakryiko
2022-12-22 0:33 ` Eduard Zingerman
2022-12-20 21:21 ` [PATCH bpf-next 0/4] reduce BPF_ID_MAP_SIZE to fit only valid programs Andrii Nakryiko
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=20221217021711.172247-5-eddyz87@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=yhs@fb.com \
/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.