From: Eduard Zingerman <eddyz87@gmail.com>
To: bpf@vger.kernel.org, ast@kernel.org
Cc: andrii@kernel.org, daniel@iogearbox.net, martin.lau@linux.dev,
kernel-team@fb.com, yonghong.song@linux.dev, void@manifault.com,
sinquersw@gmail.com, Eduard Zingerman <eddyz87@gmail.com>
Subject: [PATCH bpf-next v2 00/15] libbpf: type suffixes and autocreate flag for struct_ops maps
Date: Sat, 2 Mar 2024 03:19:05 +0200 [thread overview]
Message-ID: <20240302011920.15302-1-eddyz87@gmail.com> (raw)
Tweak struct_ops related APIs to allow the following features:
- specify version suffixes for stuct_ops map types;
- share same BPF program between several map definitions with
different local BTF types, assuming only maps with same
kernel BTF type would be selected for load;
- toggle autocreate flag for struct_ops maps;
- automatically toggle autoload for struct_ops programs referenced
from struct_ops maps, depending on autocreate status of the
corresponding map;
- use SEC("?.struct_ops") and SEC("?.struct_ops.link")
to define struct_ops maps with autocreate == false after object open.
This would allow loading programs like below:
SEC("struct_ops/foo") int BPF_PROG(foo) { ... }
SEC("struct_ops/bar") int BPF_PROG(bar) { ... }
struct bpf_testmod_ops___v1 {
int (*foo)(void);
};
struct bpf_testmod_ops___v2 {
int (*foo)(void);
int (*bar)(void);
};
/* Assume kernel type name to be 'test_ops' */
SEC(".struct_ops.link")
struct test_ops___v1 map_v1 = {
/* Program 'foo' shared by maps with
* different local BTF type
*/
.foo = (void *)foo
};
SEC(".struct_ops.link")
struct test_ops___v2 map_v2 = {
.foo = (void *)foo,
.bar = (void *)bar
};
Assuming the following tweaks are done before loading:
/* to load v1 */
bpf_map__set_autocreate(skel->maps.map_v1, true);
bpf_map__set_autocreate(skel->maps.map_v2, false);
/* to load v2 */
bpf_map__set_autocreate(skel->maps.map_v1, false);
bpf_map__set_autocreate(skel->maps.map_v2, true);
Patch #8 ties autocreate and autoload flags for struct_ops maps and
programs. While discussion for v1 concluded that such feature is
useful, it is an outlier compared to the rest of libbpf API that
treats autoload / autocreate flags in most simple way possible.
An alternative might be a dedicated API call, e.g.:
int bpf_object__infer_struct_ops_progs_autoload(struct bpf_object *)
That would set programs autoload flags depending on user defined state
of autocreate flags of struct_ops map.
It might even be accompanied by an API call:
int bpf_object__infer_struct_ops_maps_autocreate(struct bpf_object *)
That would check which struct_ops maps definitions could be loaded
with current kernel, or report error if there are ambiguities.
Changelog:
- v1 [1] -> v2:
- fixed memory leak in patch #1 (Kui-Feng);
- improved error messages in patch #2 (Martin, Andrii);
- in bad_struct_ops selftest from patch #6 added .test_2
map member setup (David);
- added utility functions to capture libbpf log from selftests (David)
- in selftests replaced usage of ...__open_and_load by separate
calls to ..._open() and ..._load() (Andrii);
- removed serial_... in selftest definitions (Andrii);
- improved comments in selftest struct_ops_autocreate
from patch #7 (David);
- removed autoload toggling logic incompatible with shadow variables
from bpf_map__set_autocreate(), instead struct_ops programs
autoload property is computed at struct_ops maps load phase,
see patch #8 (Kui-Feng, Martin, Andrii);
- added support for SEC("?.struct_ops") and SEC("?.struct_ops.link")
(Andrii).
[1] https://lore.kernel.org/bpf/20240227204556.17524-1-eddyz87@gmail.com/
Eduard Zingerman (15):
libbpf: allow version suffixes (___smth) for struct_ops types
libbpf: tie struct_ops programs to kernel BTF ids, not to local ids
libbpf: honor autocreate flag for struct_ops maps
selftests/bpf: test struct_ops map definition with type suffix
selftests/bpf: utility functions to capture libbpf log in test_progs
selftests/bpf: bad_struct_ops test
selftests/bpf: test autocreate behavior for struct_ops maps
libbpf: sync progs autoload with maps autocreate for struct_ops maps
selftests/bpf: verify struct_ops autoload/autocreate sync
libbpf: replace elf_state->st_ops_* fields with SEC_ST_OPS sec_type
libbpf: struct_ops in SEC("?.struct_ops") and SEC("?.struct_ops.link")
libbpf: rewrite btf datasec names starting from '?'
selftests/bpf: test case for SEC("?.struct_ops")
bpf: allow '?' at the beginning of DATASEC names
selftests/bpf: test cases for '?' in BTF names
kernel/bpf/btf.c | 17 +-
tools/lib/bpf/features.c | 22 +++
tools/lib/bpf/libbpf.c | 174 ++++++++++++------
tools/lib/bpf/libbpf_internal.h | 2 +
.../selftests/bpf/bpf_testmod/bpf_testmod.c | 25 +++
.../selftests/bpf/bpf_testmod/bpf_testmod.h | 4 +
.../selftests/bpf/prog_tests/bad_struct_ops.c | 67 +++++++
tools/testing/selftests/bpf/prog_tests/btf.c | 46 +++++
.../bpf/prog_tests/struct_ops_autocreate.c | 124 +++++++++++++
.../bpf/prog_tests/test_struct_ops_module.c | 33 +++-
.../selftests/bpf/progs/bad_struct_ops.c | 25 +++
.../selftests/bpf/progs/bad_struct_ops2.c | 14 ++
.../bpf/progs/struct_ops_autocreate.c | 52 ++++++
.../selftests/bpf/progs/struct_ops_module.c | 21 ++-
tools/testing/selftests/bpf/test_progs.c | 57 ++++++
tools/testing/selftests/bpf/test_progs.h | 3 +
16 files changed, 614 insertions(+), 72 deletions(-)
create mode 100644 tools/testing/selftests/bpf/prog_tests/bad_struct_ops.c
create mode 100644 tools/testing/selftests/bpf/prog_tests/struct_ops_autocreate.c
create mode 100644 tools/testing/selftests/bpf/progs/bad_struct_ops.c
create mode 100644 tools/testing/selftests/bpf/progs/bad_struct_ops2.c
create mode 100644 tools/testing/selftests/bpf/progs/struct_ops_autocreate.c
--
2.43.0
next reply other threads:[~2024-03-02 1:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-02 1:19 Eduard Zingerman [this message]
2024-03-02 1:19 ` [PATCH bpf-next v2 01/15] libbpf: allow version suffixes (___smth) for struct_ops types Eduard Zingerman
2024-03-02 1:19 ` [PATCH bpf-next v2 02/15] libbpf: tie struct_ops programs to kernel BTF ids, not to local ids Eduard Zingerman
2024-03-02 1:19 ` [PATCH bpf-next v2 03/15] libbpf: honor autocreate flag for struct_ops maps Eduard Zingerman
2024-03-02 1:19 ` [PATCH bpf-next v2 04/15] selftests/bpf: test struct_ops map definition with type suffix Eduard Zingerman
2024-03-02 1:19 ` [PATCH bpf-next v2 05/15] selftests/bpf: utility functions to capture libbpf log in test_progs Eduard Zingerman
2024-03-02 1:19 ` [PATCH bpf-next v2 06/15] selftests/bpf: bad_struct_ops test Eduard Zingerman
2024-03-02 1:19 ` [PATCH bpf-next v2 07/15] selftests/bpf: test autocreate behavior for struct_ops maps Eduard Zingerman
2024-03-02 1:19 ` [PATCH bpf-next v2 08/15] libbpf: sync progs autoload with maps autocreate " Eduard Zingerman
2024-03-04 19:13 ` Eduard Zingerman
2024-03-02 1:19 ` [PATCH bpf-next v2 09/15] selftests/bpf: verify struct_ops autoload/autocreate sync Eduard Zingerman
2024-03-02 1:19 ` [PATCH bpf-next v2 10/15] libbpf: replace elf_state->st_ops_* fields with SEC_ST_OPS sec_type Eduard Zingerman
2024-03-02 1:19 ` [PATCH bpf-next v2 11/15] libbpf: struct_ops in SEC("?.struct_ops") and SEC("?.struct_ops.link") Eduard Zingerman
2024-03-02 1:19 ` [PATCH bpf-next v2 12/15] libbpf: rewrite btf datasec names starting from '?' Eduard Zingerman
2024-03-02 1:19 ` [PATCH bpf-next v2 13/15] selftests/bpf: test case for SEC("?.struct_ops") Eduard Zingerman
2024-03-02 1:19 ` [PATCH bpf-next v2 14/15] bpf: allow '?' at the beginning of DATASEC names Eduard Zingerman
2024-03-02 1:19 ` [PATCH bpf-next v2 15/15] selftests/bpf: test cases for '?' in BTF names Eduard Zingerman
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=20240302011920.15302-1-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=martin.lau@linux.dev \
--cc=sinquersw@gmail.com \
--cc=void@manifault.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox