From: Alexei Starovoitov <ast@fb.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
john fastabend <john.fastabend@gmail.com>,
bpf <bpf@vger.kernel.org>, Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH v5 bpf-next 16/21] libbpf: Introduce bpf_map__initial_value().
Date: Thu, 13 May 2021 15:22:39 -0700 [thread overview]
Message-ID: <e71cd6e3-3f2c-dc19-344a-28b8e5d68a9b@fb.com> (raw)
In-Reply-To: <CAEf4Bzb=L0LH0OfEqe+uMq0rd8=zaHzPdWV5-Qf5_CQFkKT8pw@mail.gmail.com>
On 5/13/21 2:16 PM, Andrii Nakryiko wrote:
> On Wed, May 12, 2021 at 2:33 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>>
>> 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.
next prev parent reply other threads:[~2021-05-13 22:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-12 21:32 [PATCH v5 bpf-next 00/21] bpf: syscall program, FD array, loader program, light skeleton Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 01/21] bpf: Introduce bpf_sys_bpf() helper and program type Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 02/21] bpf: Introduce bpfptr_t user/kernel pointer Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 03/21] bpf: Prepare bpf syscall to be used from kernel and user space Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 04/21] libbpf: Support for syscall program type Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 05/21] selftests/bpf: Test " Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 06/21] bpf: Make btf_load command to be bpfptr_t compatible Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 07/21] selftests/bpf: Test for btf_load command Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 08/21] bpf: Introduce fd_idx Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 09/21] bpf: Add bpf_btf_find_by_name_kind() helper Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 10/21] bpf: Add bpf_sys_close() helper Alexei Starovoitov
2021-05-13 21:08 ` Andrii Nakryiko
2021-05-12 21:32 ` [PATCH v5 bpf-next 11/21] libbpf: Change the order of data and text relocations Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 12/21] libbpf: Add bpf_object pointer to kernel_supports() Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 13/21] libbpf: Preliminary support for fd_idx Alexei Starovoitov
2021-05-13 21:09 ` Andrii Nakryiko
2021-05-12 21:32 ` [PATCH v5 bpf-next 14/21] libbpf: Generate loader program out of BPF ELF file Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 15/21] libbpf: Cleanup temp FDs when intermediate sys_bpf fails Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 16/21] libbpf: Introduce bpf_map__initial_value() Alexei Starovoitov
2021-05-13 21:16 ` Andrii Nakryiko
2021-05-13 22:22 ` Alexei Starovoitov [this message]
2021-05-13 22:58 ` Andrii Nakryiko
2021-05-12 21:32 ` [PATCH v5 bpf-next 17/21] bpftool: Use syscall/loader program in "prog load" and "gen skeleton" command Alexei Starovoitov
2021-05-13 21:22 ` Andrii Nakryiko
2021-05-12 21:32 ` [PATCH v5 bpf-next 18/21] selftests/bpf: Convert few tests to light skeleton Alexei Starovoitov
2021-05-13 21:26 ` Andrii Nakryiko
2021-05-12 21:32 ` [PATCH v5 bpf-next 19/21] selftests/bpf: Convert atomics test " Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 20/21] selftests/bpf: Convert test printk to use rodata Alexei Starovoitov
2021-05-12 21:32 ` [PATCH v5 bpf-next 21/21] selftests/bpf: Convert test trace_printk to lskel Alexei Starovoitov
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=e71cd6e3-3f2c-dc19-344a-28b8e5d68a9b@fb.com \
--to=ast@fb.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=john.fastabend@gmail.com \
--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;
as well as URLs for NNTP newsgroup(s).