forked from Minki/linux
libbpf: Make bpf_map order and indices stable
Currently, libbpf re-sorts bpf_map structs after all the maps are added and
initialized, which might change their relative order and invalidate any
bpf_map pointer or index taken before that. This is inconvenient and
error-prone. For instance, it can cause .kconfig map index to point to a wrong
map.
Furthermore, libbpf itself doesn't rely on any specific ordering of bpf_maps,
so it's just an unnecessary complication right now. This patch drops sorting
of maps and makes their relative positions fixed. If efficient index is ever
needed, it's better to have a separate array of pointers as a search index,
instead of reordering bpf_map struct in-place. This will be less error-prone
and will allow multiple independent orderings, if necessary (e.g., either by
section index or by name).
Fixes: 166750bc1d
("libbpf: Support libbpf-provided extern variables")
Reported-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200110034247.1220142-1-andriin@fb.com
This commit is contained in:
parent
f5bfcd953d
commit
492ab0205f
@ -1123,16 +1123,6 @@ bpf_object__init_kversion(struct bpf_object *obj, void *data, size_t size)
|
||||
return 0;
|
||||
}
|
||||
|
||||
static int compare_bpf_map(const void *_a, const void *_b)
|
||||
{
|
||||
const struct bpf_map *a = _a;
|
||||
const struct bpf_map *b = _b;
|
||||
|
||||
if (a->sec_idx != b->sec_idx)
|
||||
return a->sec_idx - b->sec_idx;
|
||||
return a->sec_offset - b->sec_offset;
|
||||
}
|
||||
|
||||
static bool bpf_map_type__is_map_in_map(enum bpf_map_type type)
|
||||
{
|
||||
if (type == BPF_MAP_TYPE_ARRAY_OF_MAPS ||
|
||||
@ -2196,10 +2186,6 @@ static int bpf_object__init_maps(struct bpf_object *obj,
|
||||
if (err)
|
||||
return err;
|
||||
|
||||
if (obj->nr_maps) {
|
||||
qsort(obj->maps, obj->nr_maps, sizeof(obj->maps[0]),
|
||||
compare_bpf_map);
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user