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>,
Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH bpf-next 4/6] libbpf: add BPF_CORE_READ/BPF_CORE_READ_INTO helpers
Date: Tue, 1 Oct 2019 23:44:27 +0000 [thread overview]
Message-ID: <7B064E41-189A-427A-82A7-C8BD5B5421A3@fb.com> (raw)
In-Reply-To: <CAEf4BzYodrr1u14XQM04TU57SH3ViSbqh76Lh2d3QtksvS24hA@mail.gmail.com>
> On Oct 1, 2019, at 3:42 PM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Tue, Oct 1, 2019 at 2:46 PM Song Liu <songliubraving@fb.com> wrote:
>>
>>
>>
>>> On Oct 1, 2019, at 2:25 PM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>>>
>>> On Tue, Oct 1, 2019 at 2:14 PM Song Liu <songliubraving@fb.com> wrote:
>>>>
>>>>
>>>>> On Sep 30, 2019, at 11:58 AM, Andrii Nakryiko <andriin@fb.com> wrote:
>>>>>
>>>>> Add few macros simplifying BCC-like multi-level probe reads, while also
>>>>> emitting CO-RE relocations for each read.
>>>>>
>>>>> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
>>>>> ---
>>>>> tools/lib/bpf/bpf_helpers.h | 151 +++++++++++++++++++++++++++++++++++-
>>>>> 1 file changed, 147 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/tools/lib/bpf/bpf_helpers.h b/tools/lib/bpf/bpf_helpers.h
>>>>> index a1d9b97b8e15..51e7b11d53e8 100644
>>>>> --- a/tools/lib/bpf/bpf_helpers.h
>>>>> +++ b/tools/lib/bpf/bpf_helpers.h
>>>>> @@ -19,6 +19,10 @@
>>>>> */
>>>>> #define SEC(NAME) __attribute__((section(NAME), used))
>>>>>
>>>>> +#ifndef __always_inline
>>>>> +#define __always_inline __attribute__((always_inline))
>>>>> +#endif
>>>>> +
>>>>> /* helper functions called from eBPF programs written in C */
>>>>> static void *(*bpf_map_lookup_elem)(void *map, const void *key) =
>>>>> (void *) BPF_FUNC_map_lookup_elem;
>>>>> @@ -505,7 +509,7 @@ struct pt_regs;
>>>>> #endif
>>>>>
>>>>> /*
>>>>> - * BPF_CORE_READ abstracts away bpf_probe_read() call and captures offset
>>>>> + * bpf_core_read() abstracts away bpf_probe_read() call and captures field
>>>>> * relocation for source address using __builtin_preserve_access_index()
>>>>> * built-in, provided by Clang.
>>>>> *
>>>>> @@ -520,8 +524,147 @@ struct pt_regs;
>>>>> * actual field offset, based on target kernel BTF type that matches original
>>>>> * (local) BTF, used to record relocation.
>>>>> */
>>>>> -#define BPF_CORE_READ(dst, src) \
>>>>> - bpf_probe_read((dst), sizeof(*(src)), \
>>>>> - __builtin_preserve_access_index(src))
>>>>> +#define bpf_core_read(dst, sz, src) \
>>>>> + bpf_probe_read(dst, sz, \
>>>>> + (const void *)__builtin_preserve_access_index(src))
>>>>> +
>>>>> +/*
>>>>> + * bpf_core_read_str() is a thin wrapper around bpf_probe_read_str()
>>>>> + * additionally emitting BPF CO-RE field relocation for specified source
>>>>> + * argument.
>>>>> + */
>>>>> +#define bpf_core_read_str(dst, sz, src) \
>>>>> + bpf_probe_read_str(dst, sz, \
>>>>> + (const void *)__builtin_preserve_access_index(src))
>>>>> +
>>>>> +#define ___concat(a, b) a ## b
>>>>> +#define ___apply(fn, n) ___concat(fn, n)
>>>>> +#define ___nth(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, __11, N, ...) N
>>>>
>>>> We are adding many marcos with simple names: ___apply(), ___nth. So I worry
>>>> they may conflict with macro definitions from other libraries. Shall we hide
>>>> them in .c files or prefix/postfix them with _libbpf or something?
>>>
>>> Keep in mind, this is the header that's included from BPF code.
>>>
>>> They are prefixed with three underscores, I was hoping it's good
>>> enough to avoid accidental conflicts. It's unlikely someone will have
>>> macros with the same names **in BPF-side code**.
>>
>> BPF side code would include kernel headers. So there are many headers
>> to conflict with. And we won't know until somebody want to trace certain
>> kernel structure.
>
> We have all the kernel sources at our disposal, there's no need to
> guess :) There is no instance of ___apply, ___concat, ___nth,
> ___arrow, ___last, ___nolast, or ___type, not even speaking about
> other more specific names. There are currently two instances of
> "____last_____" used in a string. And I'm certainly not afraid that
> user code can use triple-underscored identifier with exact those names
> and complain about bpf_helpers.h :)
I worry more about _future_ conflicts, that someone may add ___apply to
some kernel header file and break some BPF programs. Since these BPF
programs are not in-tree, it is very difficult to test them properly.
We have had name conflicts from other libraries, so I hope we don't create
more ourselves.
Thanks,
Song
next prev parent reply other threads:[~2019-10-01 23:44 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-30 18:58 [PATCH bpf-next 0/6] Move bpf_helpers and add BPF_CORE_READ macros Andrii Nakryiko
2019-09-30 18:58 ` [PATCH bpf-next 1/6] selftests/bpf: undo GCC-specific bpf_helpers.h changes Andrii Nakryiko
2019-09-30 22:53 ` Song Liu
2019-10-01 10:25 ` Ilya Leoshkevich
2019-10-01 19:10 ` John Fastabend
2019-09-30 18:58 ` [PATCH bpf-next 2/6] libbpf: move bpf_helpers.h, bpf_endian.h into libbpf Andrii Nakryiko
2019-09-30 22:55 ` Song Liu
2019-09-30 22:58 ` Andrii Nakryiko
2019-09-30 23:18 ` Jakub Kicinski
2019-09-30 23:25 ` Song Liu
2019-09-30 23:36 ` Jakub Kicinski
2019-09-30 23:39 ` Song Liu
2019-09-30 23:30 ` Andrii Nakryiko
2019-09-30 23:43 ` Jakub Kicinski
2019-09-30 23:23 ` Song Liu
2019-09-30 23:27 ` Andrii Nakryiko
2019-09-30 23:35 ` Song Liu
2019-10-01 7:10 ` Toke Høiland-Jørgensen
2019-10-01 19:18 ` John Fastabend
2019-10-01 19:44 ` Andrii Nakryiko
2019-10-01 22:00 ` John Fastabend
2019-10-02 7:25 ` Toke Høiland-Jørgensen
2019-10-01 19:42 ` Andrii Nakryiko
2019-10-02 7:21 ` Toke Høiland-Jørgensen
2019-10-01 21:19 ` Song Liu
2019-10-01 21:28 ` Andrii Nakryiko
2019-10-01 22:45 ` Daniel Borkmann
2019-10-01 23:31 ` Andrii Nakryiko
2019-10-01 23:40 ` Andrii Nakryiko
2019-10-02 9:51 ` Daniel Borkmann
2019-09-30 18:58 ` [PATCH bpf-next 3/6] selftests/bpf: switch test to use libbpf's helpers Andrii Nakryiko
2019-09-30 18:58 ` [PATCH bpf-next 4/6] libbpf: add BPF_CORE_READ/BPF_CORE_READ_INTO helpers Andrii Nakryiko
2019-10-01 19:07 ` John Fastabend
2019-10-01 21:14 ` Song Liu
2019-10-01 21:25 ` Andrii Nakryiko
2019-10-01 21:46 ` Song Liu
2019-10-01 22:42 ` Andrii Nakryiko
2019-10-01 23:44 ` Song Liu [this message]
2019-10-02 3:36 ` Andrii Nakryiko
2019-10-02 16:25 ` Song Liu
2019-09-30 18:58 ` [PATCH bpf-next 5/6] selftests/bpf: adjust CO-RE reloc tests for new BPF_CORE_READ macro Andrii Nakryiko
2019-10-01 19:14 ` John Fastabend
2019-10-01 21:31 ` Andrii Nakryiko
2019-10-01 21:47 ` Song Liu
2019-09-30 18:58 ` [PATCH bpf-next 6/6] selftests/bpf: add BPF_CORE_READ and BPF_CORE_READ_STR_INTO macro tests Andrii Nakryiko
2019-10-01 19:19 ` John Fastabend
2019-10-01 21:22 ` Song Liu
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=7B064E41-189A-427A-82A7-C8BD5B5421A3@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 \
/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).