Re: [PATCH v5 bpf-next 16/21] libbpf: Introduce bpf_map__initial_value().

On Thu, May 13, 2021 at 3:22 PM Alexei Starovoitov [off-list ref] wrote:

On 5/13/21 2:16 PM, Andrii Nakryiko wrote:

quoted

On Wed, May 12, 2021 at 2:33 PM Alexei Starovoitov
[off-list ref] wrote:

quoted

From: Alexei Starovoitov <ast@kernel.org>

Introduce bpf_map__initial_value() to read initial contents
of rodata/bss maps. Note only mmaped maps qualify.
Just as bpf_map__set_initial_value() works only for mmaped kconfig.

This sentence is confusing. bpf_map__set_initial_value() rejects
LIBBPF_MAP_KCONFIG, so it *doesn't* work for kconfig. But your
implementation will return non-NULL pointer for kconfig (it will be
all zeroes before load). So did you intend to match
set_initial_value() semantics or not?

Good catch. I'll reword.
It was too forward looking and ended up as completely incorrect
sentence.

The idea was to make getter work for all is_internal and mmaped
maps (including kconfig), so that after __open and before __load
phase can populate them with correct values.
Initially for kconfig I was thinking to do it as part of the loader
program, but the kernel doesn't have in memory kconfig. Unzipping
and string searching didn't feel like the right task for
the loader prog/kernel, so the light skel instead will populate
it from user space during __open.
At that point we can either fail the __open if /proc/config.gz
cannot be open or it doesn't have the fields the prog is looking for
or proceed with default values in kconfig map that libbpf populated
earlier during light skel and loader prog generation.
Depending on that choice the bpf_map__initial_value() should
either return initial value for kconfig or not.
I think returning it for kconfig map doesn't hurt.

Yep, I agree.