From: Andrii Nakryiko <andrii@kernel.org>
To: <bpf@vger.kernel.org>, <ast@kernel.org>, <daniel@iogearbox.net>
Cc: <andrii@kernel.org>, <kernel-team@fb.com>
Subject: [PATCH v2 bpf-next 00/10] libbpf: support custom .rodata.*/.data.* sections
Date: Wed, 20 Oct 2021 18:43:54 -0700 [thread overview]
Message-ID: <20211021014404.2635234-1-andrii@kernel.org> (raw)
This patch set refactors internals of libbpf to enable support for multiple
custom .rodata.* and .data.* sections. Each such section is backed by its own
BPF_MAP_TYPE_ARRAY, memory-mappable just like .rodata/.data. This is not
extended to .bss because .bss is not a great name, it is generated by compiler
with name that reflects completely irrelevant historical implementation
details. Given that users have to annotate their variables with
SEC(".data.my_sec") explicitly, standardizing on .rodata. and .data. prefixes
makes more sense and keeps things simpler.
Additionally, this patch set makes it simpler to work with those special
internal maps by allowing to look them up by their full ELF section name.
Patch #1 is a preparatory patch that deprecates one libbpf API and moves
custom logic into libbpf.c, where it's used. This code is later refactored
with the rest of libbpf.c logic to support multiple data section maps.
See individual patches for all the details.
For new custom "dot maps", their full ELF section names are used as the names
that are sent into the kernel. Object name isn't prepended like for
.data/.rodata/.bss. The reason is that with longer custom names, there isn't
much space left for object name anyways. Also, if BTF is supported,
btf_value_type_id points to DATASEC BTF type, which contains full original ELF
name of the section, so tools like bpftool could use that to recover full
name. This patch set doesn't add this logic yet, this is left for follow up
patches.
One interesting possibility that is now open by these changes is that it's
possible to do:
bpf_trace_printk("My fmt %s", sizeof("My fmt %s"), "blah");
and it will work as expected. I haven't updated libbpf-provided helpers in
bpf_helpers.h for snprintf, seq_printf, and printk, because using
`static const char ___fmt[] = fmt;` trick is still efficient and doesn't fill
out the buffer at runtime (no copying). But we might consider updating them in
the future, especially with the array check that Kumar proposed (see [0]).
[0] https://lore.kernel.org/bpf/20211012041524.udytbr2xs5wid6x2@apollo.localdomain/
v1->v2:
- don't prepend object name for new dot maps;
- add __read_mostly example in selftests (Daniel).
Andrii Nakryiko (10):
libbpf: deprecate btf__finalize_data() and move it into libbpf.c
libbpf: extract ELF processing state into separate struct
libbpf: use Elf64-specific types explicitly for dealing with ELF
libbpf: remove assumptions about uniqueness of .rodata/.data/.bss maps
bpftool: support multiple .rodata/.data internal maps in skeleton
bpftool: improve skeleton generation for data maps without DATASEC
type
libbpf: support multiple .rodata.* and .data.* BPF maps
selftests/bpf: demonstrate use of custom .rodata/.data sections
libbpf: simplify look up by name of internal maps
selftests/bpf: switch to ".bss"/".rodata"/".data" lookups for internal
maps
tools/bpf/bpftool/gen.c | 158 ++--
tools/lib/bpf/btf.c | 93 --
tools/lib/bpf/btf.h | 1 +
tools/lib/bpf/libbpf.c | 893 +++++++++++-------
tools/lib/bpf/libbpf_internal.h | 8 +-
tools/lib/bpf/linker.c | 1 -
.../selftests/bpf/prog_tests/core_autosize.c | 2 +-
.../selftests/bpf/prog_tests/core_reloc.c | 2 +-
.../selftests/bpf/prog_tests/global_data.c | 11 +-
.../bpf/prog_tests/global_data_init.c | 2 +-
.../selftests/bpf/prog_tests/kfree_skb.c | 2 +-
.../selftests/bpf/prog_tests/rdonly_maps.c | 2 +-
.../selftests/bpf/prog_tests/skeleton.c | 29 +
.../selftests/bpf/progs/test_skeleton.c | 18 +
14 files changed, 731 insertions(+), 491 deletions(-)
--
2.30.2
next reply other threads:[~2021-10-21 1:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-21 1:43 Andrii Nakryiko [this message]
2021-10-21 1:43 ` [PATCH v2 bpf-next 01/10] libbpf: deprecate btf__finalize_data() and move it into libbpf.c Andrii Nakryiko
2021-10-21 1:43 ` [PATCH v2 bpf-next 02/10] libbpf: extract ELF processing state into separate struct Andrii Nakryiko
2021-10-21 1:43 ` [PATCH v2 bpf-next 03/10] libbpf: use Elf64-specific types explicitly for dealing with ELF Andrii Nakryiko
2021-10-21 1:43 ` [PATCH v2 bpf-next 04/10] libbpf: remove assumptions about uniqueness of .rodata/.data/.bss maps Andrii Nakryiko
2021-10-21 1:43 ` [PATCH v2 bpf-next 05/10] bpftool: support multiple .rodata/.data internal maps in skeleton Andrii Nakryiko
2021-10-21 1:44 ` [PATCH v2 bpf-next 06/10] bpftool: improve skeleton generation for data maps without DATASEC type Andrii Nakryiko
2021-10-21 1:44 ` [PATCH v2 bpf-next 07/10] libbpf: support multiple .rodata.* and .data.* BPF maps Andrii Nakryiko
2021-10-21 1:44 ` [PATCH v2 bpf-next 08/10] selftests/bpf: demonstrate use of custom .rodata/.data sections Andrii Nakryiko
2021-10-21 1:44 ` [PATCH v2 bpf-next 09/10] libbpf: simplify look up by name of internal maps Andrii Nakryiko
2021-10-21 1:44 ` [PATCH v2 bpf-next 10/10] selftests/bpf: switch to ".bss"/".rodata"/".data" lookups for " 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=20211021014404.2635234-1-andrii@kernel.org \
--to=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox