YiFei Zhu <zhuyifei1999@xxxxxxxxx> [Thu, 2020-08-20 02:43 -0700]:
> From: YiFei Zhu <zhuyifei@xxxxxxxxxx>
>
> The patch adds a simple wrapper bpf_prog_bind_map around the syscall.
> And when using libbpf to load a program, it will probe the kernel for
> the support of this syscall, and scan for the .metadata ELF section
> and load it as an internal map like a .data section.
>
> In the case that kernel supports the BPF_PROG_BIND_MAP syscall and
> a .metadata section exists, the map will be explicitly bound to
> the program via the syscall immediately after program is loaded.
> -EEXIST is ignored for this syscall.
>
> Signed-off-by: YiFei Zhu <zhuyifei@xxxxxxxxxx>
...
> @@ -1387,6 +1397,9 @@ bpf_object__init_internal_map(struct bpf_object *obj, enum libbpf_map_type type,
> if (data)
> memcpy(map->mmaped, data, data_sz);
>
> + if (type == LIBBPF_MAP_METADATA)
> + obj->metadata_map = map;
I wonder if the map should have BPF_F_RDONLY / BPF_F_RDONLY_PROG flags
set by libbpf?
At least in my use-case metadata should never change once the map is
created, neither from program nor from syscall side.
> +
> pr_debug("map %td is \"%s\"\n", map - obj->maps, map->name);
> return 0;
> }
--
Andrey Ignatov
