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 v3 10/15] libbpf: replace elf_state->st_ops_* fields with SEC_ST_OPS sec_type
Date: Tue, 5 Mar 2024 00:51:51 +0200 [thread overview]
Message-ID: <20240304225156.24765-11-eddyz87@gmail.com> (raw)
In-Reply-To: <20240304225156.24765-1-eddyz87@gmail.com>
The next patch would add two new section names for struct_ops maps.
To make working with multiple struct_ops sections more convenient:
- remove fields like elf_state->st_ops_{shndx,link_shndx};
- mark section descriptions hosting struct_ops as
elf_sec_desc->sec_type == SEC_ST_OPS;
After these changes struct_ops sections could be processed uniformly
by iterating bpf_object->efile.secs entries.
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
---
tools/lib/bpf/libbpf.c | 62 ++++++++++++++++++++++--------------------
1 file changed, 33 insertions(+), 29 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index ce39ae34fec0..4ef3902e65db 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -612,6 +612,7 @@ enum sec_type {
SEC_BSS,
SEC_DATA,
SEC_RODATA,
+ SEC_ST_OPS,
};
struct elf_sec_desc {
@@ -627,8 +628,6 @@ struct elf_state {
Elf *elf;
Elf64_Ehdr *ehdr;
Elf_Data *symbols;
- Elf_Data *st_ops_data;
- Elf_Data *st_ops_link_data;
size_t shstrndx; /* section index for section name strings */
size_t strtabidx;
struct elf_sec_desc *secs;
@@ -637,8 +636,7 @@ struct elf_state {
__u32 btf_maps_sec_btf_id;
int text_shndx;
int symbols_shndx;
- int st_ops_shndx;
- int st_ops_link_shndx;
+ bool has_st_ops;
};
struct usdt_manager;
@@ -1268,7 +1266,7 @@ static int bpf_object__init_kern_struct_ops_maps(struct bpf_object *obj)
}
static int init_struct_ops_maps(struct bpf_object *obj, const char *sec_name,
- int shndx, Elf_Data *data, __u32 map_flags)
+ int shndx, Elf_Data *data)
{
const struct btf_type *type, *datasec;
const struct btf_var_secinfo *vsi;
@@ -1330,7 +1328,8 @@ static int init_struct_ops_maps(struct bpf_object *obj, const char *sec_name,
map->def.key_size = sizeof(int);
map->def.value_size = type->size;
map->def.max_entries = 1;
- map->def.map_flags = map_flags;
+ map->def.map_flags = strcmp(sec_name, STRUCT_OPS_LINK_SEC) == 0
+ ? BPF_F_LINK : 0;
map->st_ops = calloc(1, sizeof(*map->st_ops));
if (!map->st_ops)
@@ -1365,15 +1364,25 @@ static int init_struct_ops_maps(struct bpf_object *obj, const char *sec_name,
static int bpf_object_init_struct_ops(struct bpf_object *obj)
{
- int err;
+ const char *sec_name;
+ int sec_idx, err;
- err = init_struct_ops_maps(obj, STRUCT_OPS_SEC, obj->efile.st_ops_shndx,
- obj->efile.st_ops_data, 0);
- err = err ?: init_struct_ops_maps(obj, STRUCT_OPS_LINK_SEC,
- obj->efile.st_ops_link_shndx,
- obj->efile.st_ops_link_data,
- BPF_F_LINK);
- return err;
+ for (sec_idx = 0; sec_idx < obj->efile.sec_cnt; ++sec_idx) {
+ struct elf_sec_desc *desc = &obj->efile.secs[sec_idx];
+
+ if (desc->sec_type != SEC_ST_OPS)
+ continue;
+
+ sec_name = elf_sec_name(obj, elf_sec_by_idx(obj, sec_idx));
+ if (!sec_name)
+ return -LIBBPF_ERRNO__FORMAT;
+
+ err = init_struct_ops_maps(obj, sec_name, sec_idx, desc->data);
+ if (err)
+ return err;
+ }
+
+ return 0;
}
static struct bpf_object *bpf_object__new(const char *path,
@@ -1411,8 +1420,6 @@ static struct bpf_object *bpf_object__new(const char *path,
obj->efile.obj_buf = obj_buf;
obj->efile.obj_buf_sz = obj_buf_sz;
obj->efile.btf_maps_shndx = -1;
- obj->efile.st_ops_shndx = -1;
- obj->efile.st_ops_link_shndx = -1;
obj->kconfig_map_idx = -1;
obj->kern_version = get_kernel_version();
@@ -1429,8 +1436,6 @@ static void bpf_object__elf_finish(struct bpf_object *obj)
elf_end(obj->efile.elf);
obj->efile.elf = NULL;
obj->efile.symbols = NULL;
- obj->efile.st_ops_data = NULL;
- obj->efile.st_ops_link_data = NULL;
zfree(&obj->efile.secs);
obj->efile.sec_cnt = 0;
@@ -2975,14 +2980,13 @@ static int bpf_object__sanitize_btf(struct bpf_object *obj, struct btf *btf)
static bool libbpf_needs_btf(const struct bpf_object *obj)
{
return obj->efile.btf_maps_shndx >= 0 ||
- obj->efile.st_ops_shndx >= 0 ||
- obj->efile.st_ops_link_shndx >= 0 ||
+ obj->efile.has_st_ops ||
obj->nr_extern > 0;
}
static bool kernel_needs_btf(const struct bpf_object *obj)
{
- return obj->efile.st_ops_shndx >= 0 || obj->efile.st_ops_link_shndx >= 0;
+ return obj->efile.has_st_ops;
}
static int bpf_object__init_btf(struct bpf_object *obj,
@@ -3683,12 +3687,12 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
sec_desc->sec_type = SEC_RODATA;
sec_desc->shdr = sh;
sec_desc->data = data;
- } else if (strcmp(name, STRUCT_OPS_SEC) == 0) {
- obj->efile.st_ops_data = data;
- obj->efile.st_ops_shndx = idx;
- } else if (strcmp(name, STRUCT_OPS_LINK_SEC) == 0) {
- obj->efile.st_ops_link_data = data;
- obj->efile.st_ops_link_shndx = idx;
+ } else if (strcmp(name, STRUCT_OPS_SEC) == 0 ||
+ strcmp(name, STRUCT_OPS_LINK_SEC) == 0) {
+ sec_desc->sec_type = SEC_ST_OPS;
+ sec_desc->shdr = sh;
+ sec_desc->data = data;
+ obj->efile.has_st_ops = true;
} else {
pr_info("elf: skipping unrecognized data section(%d) %s\n",
idx, name);
@@ -7001,12 +7005,12 @@ static int bpf_object__collect_relos(struct bpf_object *obj)
data = sec_desc->data;
idx = shdr->sh_info;
- if (shdr->sh_type != SHT_REL) {
+ if (shdr->sh_type != SHT_REL || idx < 0 || idx >= obj->efile.sec_cnt) {
pr_warn("internal error at %d\n", __LINE__);
return -LIBBPF_ERRNO__INTERNAL;
}
- if (idx == obj->efile.st_ops_shndx || idx == obj->efile.st_ops_link_shndx)
+ if (obj->efile.secs[idx].sec_type == SEC_ST_OPS)
err = bpf_object__collect_st_ops_relos(obj, shdr, data);
else if (idx == obj->efile.btf_maps_shndx)
err = bpf_object__collect_map_relos(obj, shdr, data);
--
2.43.0
next prev parent reply other threads:[~2024-03-04 22:52 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-04 22:51 [PATCH bpf-next v3 00/15] libbpf: type suffixes and autocreate flag for struct_ops maps Eduard Zingerman
2024-03-04 22:51 ` [PATCH bpf-next v3 01/15] libbpf: allow version suffixes (___smth) for struct_ops types Eduard Zingerman
2024-03-05 19:12 ` Andrii Nakryiko
2024-03-04 22:51 ` [PATCH bpf-next v3 02/15] libbpf: tie struct_ops programs to kernel BTF ids, not to local ids Eduard Zingerman
2024-03-05 19:15 ` Andrii Nakryiko
2024-03-04 22:51 ` [PATCH bpf-next v3 03/15] libbpf: honor autocreate flag for struct_ops maps Eduard Zingerman
2024-03-05 19:19 ` Andrii Nakryiko
2024-03-05 23:50 ` Eduard Zingerman
2024-03-04 22:51 ` [PATCH bpf-next v3 04/15] selftests/bpf: test struct_ops map definition with type suffix Eduard Zingerman
2024-03-04 22:51 ` [PATCH bpf-next v3 05/15] selftests/bpf: utility functions to capture libbpf log in test_progs Eduard Zingerman
2024-03-05 19:24 ` Andrii Nakryiko
2024-03-05 23:58 ` Eduard Zingerman
2024-03-04 22:51 ` [PATCH bpf-next v3 06/15] selftests/bpf: bad_struct_ops test Eduard Zingerman
2024-03-05 19:29 ` Andrii Nakryiko
2024-03-06 0:05 ` Eduard Zingerman
2024-03-04 22:51 ` [PATCH bpf-next v3 07/15] selftests/bpf: test autocreate behavior for struct_ops maps Eduard Zingerman
2024-03-05 9:51 ` Daniel Borkmann
2024-03-05 9:54 ` Eduard Zingerman
2024-03-04 22:51 ` [PATCH bpf-next v3 08/15] libbpf: sync progs autoload with maps autocreate " Eduard Zingerman
2024-03-05 19:46 ` Andrii Nakryiko
2024-03-06 0:28 ` Eduard Zingerman
2024-03-04 22:51 ` [PATCH bpf-next v3 09/15] selftests/bpf: verify struct_ops autoload/autocreate sync Eduard Zingerman
2024-03-05 19:48 ` Andrii Nakryiko
2024-03-06 0:40 ` Eduard Zingerman
2024-03-04 22:51 ` Eduard Zingerman [this message]
2024-03-05 19:53 ` [PATCH bpf-next v3 10/15] libbpf: replace elf_state->st_ops_* fields with SEC_ST_OPS sec_type Andrii Nakryiko
2024-03-06 1:08 ` Eduard Zingerman
2024-03-04 22:51 ` [PATCH bpf-next v3 11/15] libbpf: struct_ops in SEC("?.struct_ops") and SEC("?.struct_ops.link") Eduard Zingerman
2024-03-05 19:55 ` Andrii Nakryiko
2024-03-06 1:18 ` Eduard Zingerman
2024-03-04 22:51 ` [PATCH bpf-next v3 12/15] libbpf: rewrite btf datasec names starting from '?' Eduard Zingerman
2024-03-05 20:03 ` Andrii Nakryiko
2024-03-06 1:34 ` Eduard Zingerman
2024-03-04 22:51 ` [PATCH bpf-next v3 13/15] selftests/bpf: test case for SEC("?.struct_ops") Eduard Zingerman
2024-03-05 21:40 ` Andrii Nakryiko
2024-03-04 22:51 ` [PATCH bpf-next v3 14/15] bpf: allow '?' at the beginning of DATASEC names Eduard Zingerman
2024-03-05 21:43 ` Andrii Nakryiko
2024-03-06 2:04 ` Eduard Zingerman
2024-03-04 22:51 ` [PATCH bpf-next v3 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=20240304225156.24765-11-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