From: Martin KaFai Lau <kafai@fb.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Kernel Team <kernel-team@fb.com>,
Networking <netdev@vger.kernel.org>
Subject: Re: [PATCH bpf-next 02/15] bpf: btf: Support parsing extern func
Date: Mon, 22 Mar 2021 21:55:08 -0700 [thread overview]
Message-ID: <20210323045508.k7gmz6ndgkftew73@kafai-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <CAEf4BzaJMmmz3JvUJs0ja5yrx_WEssE_R7t_uPAwEHFe+SY9Nw@mail.gmail.com>
On Sat, Mar 20, 2021 at 10:18:36AM -0700, Andrii Nakryiko wrote:
> > From test_ksyms.c:
> > [22] DATASEC '.ksyms' size=0 vlen=5
> > type_id=12 offset=0 size=1
> > type_id=13 offset=0 size=1
> >
> > For extern, does it make sense for the libbpf to assign 0 to
> > both var offset and size since it does not matter?
>
> That's how it is generated and yes, I think that's how it should be
> kept once kernel supports EXTERN VAR. libbpf is adjusting offsets and
> sizes in addition to marking VAR itself as GLOBAL_ALLOCATED. If kernel
> supports EXTERN VAR natively, none of that needs to happen (on newer
> kernels only, of course).
>
> > In the kernel, it can ensure a datasec only has all extern or no extern.
> > array_map_check_btf() will ensure the datasec has no extern.
>
> It certainly makes it less surprising from handling BTF, but it feels
> like an arbitrary policy, rather than technical restriction. You can
> mark allocated variables and externs with the same section name and
> Clang will probably happily generate a single DATASEC with a mix of
> externs and non-externs. Is that inherently a bad thing? I'm not sure.
> Basically, I don't know if the kernel should care and enforce or not.
I have thought a bit more on this. The offset=0 of extern var
can be used in the verification but I think it will still have some
open ended questions like arraymap.
I will use your suggestion in libbpf and do something similar as
the extern VAR: replace the FUNC in datasec with INT (btf__add_var() if
needed).
>
> >
> > > But of course to support older kernels libbpf will still have to
> > > do this. EXTERN vars won't reduce the amount of libbpf logic.
next prev parent reply other threads:[~2021-03-23 4:56 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-16 1:13 [PATCH bpf-next 00/15] Support calling kernel function Martin KaFai Lau
2021-03-16 1:13 ` [PATCH bpf-next 01/15] bpf: Simplify freeing logic in linfo and jited_linfo Martin KaFai Lau
2021-03-16 1:13 ` [PATCH bpf-next 02/15] bpf: btf: Support parsing extern func Martin KaFai Lau
2021-03-18 22:53 ` Andrii Nakryiko
2021-03-18 23:39 ` Martin KaFai Lau
2021-03-19 4:13 ` Andrii Nakryiko
2021-03-19 5:29 ` Martin KaFai Lau
2021-03-19 21:27 ` Andrii Nakryiko
2021-03-19 22:19 ` Martin KaFai Lau
2021-03-19 22:29 ` Andrii Nakryiko
2021-03-19 22:45 ` Martin KaFai Lau
2021-03-19 23:02 ` Andrii Nakryiko
2021-03-20 0:13 ` Martin KaFai Lau
2021-03-20 17:18 ` Andrii Nakryiko
2021-03-23 4:55 ` Martin KaFai Lau [this message]
2021-03-16 1:13 ` [PATCH bpf-next 03/15] bpf: Refactor btf_check_func_arg_match Martin KaFai Lau
2021-03-18 23:32 ` Andrii Nakryiko
2021-03-19 19:32 ` Martin KaFai Lau
2021-03-19 21:51 ` Andrii Nakryiko
2021-03-20 0:10 ` Alexei Starovoitov
2021-03-20 17:13 ` Andrii Nakryiko
2021-03-16 1:14 ` [PATCH bpf-next 04/15] bpf: Support bpf program calling kernel function Martin KaFai Lau
2021-03-19 1:03 ` Andrii Nakryiko
2021-03-19 1:51 ` Alexei Starovoitov
2021-03-19 19:47 ` Martin KaFai Lau
2021-03-16 1:14 ` [PATCH bpf-next 05/15] bpf: Support kernel function call in x86-32 Martin KaFai Lau
2021-03-16 1:14 ` [PATCH bpf-next 06/15] tcp: Rename bictcp function prefix to cubictcp Martin KaFai Lau
2021-03-16 1:14 ` [PATCH bpf-next 07/15] bpf: tcp: White list some tcp cong functions to be called by bpf-tcp-cc Martin KaFai Lau
2021-03-19 1:19 ` Andrii Nakryiko
2021-03-16 1:14 ` [PATCH bpf-next 08/15] libbpf: Refactor bpf_object__resolve_ksyms_btf_id Martin KaFai Lau
2021-03-19 2:53 ` Andrii Nakryiko
2021-03-16 1:14 ` [PATCH bpf-next 09/15] libbpf: Refactor codes for finding btf id of a kernel symbol Martin KaFai Lau
2021-03-19 3:14 ` Andrii Nakryiko
2021-03-16 1:14 ` [PATCH bpf-next 10/15] libbpf: Rename RELO_EXTERN to RELO_EXTERN_VAR Martin KaFai Lau
2021-03-19 3:15 ` Andrii Nakryiko
2021-03-16 1:14 ` [PATCH bpf-next 11/15] libbpf: Record extern sym relocation first Martin KaFai Lau
2021-03-19 3:16 ` Andrii Nakryiko
2021-03-16 1:14 ` [PATCH bpf-next 12/15] libbpf: Support extern kernel function Martin KaFai Lau
2021-03-19 4:11 ` Andrii Nakryiko
2021-03-19 5:06 ` Martin KaFai Lau
2021-03-19 21:38 ` Andrii Nakryiko
2021-03-16 1:14 ` [PATCH bpf-next 13/15] bpf: selftests: Rename bictcp to bpf_cubic Martin KaFai Lau
2021-03-19 4:14 ` Andrii Nakryiko
2021-03-16 1:15 ` [PATCH bpf-next 14/15] bpf: selftest: bpf_cubic and bpf_dctcp calling kernel functions Martin KaFai Lau
2021-03-19 4:15 ` Andrii Nakryiko
2021-03-16 1:15 ` [PATCH bpf-next 15/15] bpf: selftest: Add kfunc_call test Martin KaFai Lau
2021-03-16 3:39 ` kernel test robot
2021-03-19 4:21 ` Andrii Nakryiko
2021-03-19 5:40 ` Martin KaFai Lau
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=20210323045508.k7gmz6ndgkftew73@kafai-mbp.dhcp.thefacebook.com \
--to=kafai@fb.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--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).