From: Song Liu <songliubraving@fb.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Andrii Nakryiko <andriin@fb.com>, bpf <bpf@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Alexei Starovoitov <ast@fb.com>,
"daniel@iogearbox.net" <daniel@iogearbox.net>,
Yonghong Song <yhs@fb.com>, Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH v2 bpf-next 02/12] libbpf: implement BPF CO-RE offset relocation algorithm
Date: Wed, 31 Jul 2019 00:16:03 +0000 [thread overview]
Message-ID: <F03F3D79-0FD3-423F-9905-8A093AE2D9AF@fb.com> (raw)
In-Reply-To: <CAEf4BzZpcP1aBwrz8DbToQ=nVUukPwiG-PBCFGZNb2wXg_msnA@mail.gmail.com>
> On Jul 30, 2019, at 4:55 PM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Tue, Jul 30, 2019 at 4:44 PM Song Liu <songliubraving@fb.com> wrote:
>>
>>
>>
>>> On Jul 30, 2019, at 12:53 PM, Andrii Nakryiko <andriin@fb.com> wrote:
>>>
>>> This patch implements the core logic for BPF CO-RE offsets relocations.
>>> Every instruction that needs to be relocated has corresponding
>>> bpf_offset_reloc as part of BTF.ext. Relocations are performed by trying
>>> to match recorded "local" relocation spec against potentially many
>>> compatible "target" types, creating corresponding spec. Details of the
>>> algorithm are noted in corresponding comments in the code.
>>>
>>> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
>>> ---
>>> tools/lib/bpf/libbpf.c | 915 ++++++++++++++++++++++++++++++++++++++++-
>>> tools/lib/bpf/libbpf.h | 1 +
>>> 2 files changed, 909 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>>> index ead915aec349..75da90928257 100644
>>> --- a/tools/lib/bpf/libbpf.c
>>> +++ b/tools/lib/bpf/libbpf.c
>>> @@ -38,6 +38,7 @@
>
> [...]
>
>>>
>>> -static const struct btf_type *skip_mods_and_typedefs(const struct btf *btf,
>>> - __u32 id)
>>> +static const struct btf_type *
>>> +skip_mods_and_typedefs(const struct btf *btf, __u32 id, __u32 *res_id)
>>> {
>>> const struct btf_type *t = btf__type_by_id(btf, id);
>>>
>>> + if (res_id)
>>> + *res_id = id;
>>> +
>>> while (true) {
>>> switch (BTF_INFO_KIND(t->info)) {
>>> case BTF_KIND_VOLATILE:
>>> case BTF_KIND_CONST:
>>> case BTF_KIND_RESTRICT:
>>> case BTF_KIND_TYPEDEF:
>>> + if (res_id)
>>> + *res_id = t->type;
>>> t = btf__type_by_id(btf, t->type);
>>
>> So btf->types[*res_id] == retval, right? Then with retval and btf, we can
>> calculate *res_id without this change?
>
> Unless I'm missing something very clever here, no. btf->types is array
> of pointers (it's an index into a variable-sized types). This function
> returns `struct btf_type *`, which is one of the **values** stored in
> that array. You are claiming that by having value of one of array
> elements you can easily find element's index? If it was possible to do
> in O(1), we wouldn't have so many algorithms and data structures for
> search and indexing. You can do that only with linear search, not some
> clever pointer arithmetic or at least binary search. So I'm not sure
> what you are proposing here...
oops.. Clearly, I made some silly mistake. Sorry for the noise.
Song
>
> The way BTF is defined, struct btf_type doesn't know its own type ID,
> which is often inconvenient and requires to keep track of that ID, if
> it's necessary, but that's how it is.
>
> But then again, what are we trying to achieve here? Eliminate
> returning id and pointer? I could always return id and easily look up
> pointer, but having both is super convenient and makes code simpler
> and shorter, so I'd like to keep it.
>
>>
>>> break;
>>> default:
>>> @@ -1044,7 +1051,7 @@ static const struct btf_type *skip_mods_and_typedefs(const struct btf *btf,
>>> static bool get_map_field_int(const char *map_name, const struct btf *btf,
>>> const struct btf_type *def,
>>> const struct btf_member *m, __u32 *res) {
>
> [...]
next prev parent reply other threads:[~2019-07-31 0:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-30 19:53 [PATCH v2 bpf-next 00/12] CO-RE offset relocations Andrii Nakryiko
2019-07-30 19:53 ` [PATCH v2 bpf-next 01/12] libbpf: add .BTF.ext offset relocation section loading Andrii Nakryiko
2019-07-30 21:19 ` Song Liu
2019-07-30 19:53 ` [PATCH v2 bpf-next 02/12] libbpf: implement BPF CO-RE offset relocation algorithm Andrii Nakryiko
2019-07-30 23:43 ` Song Liu
2019-07-30 23:55 ` Andrii Nakryiko
2019-07-31 0:16 ` Song Liu [this message]
2019-07-31 0:39 ` Song Liu
2019-07-31 1:00 ` Andrii Nakryiko
2019-07-31 5:19 ` Song Liu
2019-07-31 6:52 ` Andrii Nakryiko
2019-07-31 8:29 ` Song Liu
2019-07-31 17:18 ` Andrii Nakryiko
2019-07-31 17:46 ` Song Liu
2019-07-30 19:53 ` [PATCH v2 bpf-next 03/12] selftests/bpf: add BPF_CORE_READ relocatable read macro Andrii Nakryiko
2019-07-30 21:24 ` Song Liu
2019-07-30 21:26 ` Andrii Nakryiko
2019-07-30 21:33 ` Song Liu
2019-07-30 19:54 ` [PATCH v2 bpf-next 04/12] selftests/bpf: add CO-RE relocs testing setup Andrii Nakryiko
2019-07-30 19:54 ` [PATCH v2 bpf-next 05/12] selftests/bpf: add CO-RE relocs struct flavors tests Andrii Nakryiko
2019-07-30 19:54 ` [PATCH v2 bpf-next 06/12] selftests/bpf: add CO-RE relocs nesting tests Andrii Nakryiko
2019-07-30 19:54 ` [PATCH v2 bpf-next 07/12] selftests/bpf: add CO-RE relocs array tests Andrii Nakryiko
2019-07-30 19:54 ` [PATCH v2 bpf-next 08/12] selftests/bpf: add CO-RE relocs enum/ptr/func_proto tests Andrii Nakryiko
2019-07-30 19:54 ` [PATCH v2 bpf-next 09/12] selftests/bpf: add CO-RE relocs modifiers/typedef tests Andrii Nakryiko
2019-07-30 19:54 ` [PATCH v2 bpf-next 10/12] selftests/bpf: add CO-RE relocs ptr-as-array tests Andrii Nakryiko
2019-07-30 19:54 ` [PATCH v2 bpf-next 11/12] selftests/bpf: add CO-RE relocs ints tests Andrii Nakryiko
2019-07-30 19:54 ` [PATCH v2 bpf-next 12/12] selftests/bpf: add CO-RE relocs misc tests Andrii Nakryiko
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=F03F3D79-0FD3-423F-9905-8A093AE2D9AF@fb.com \
--to=songliubraving@fb.com \
--cc=Kernel-team@fb.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=netdev@vger.kernel.org \
--cc=yhs@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