From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
davem@davemloft.net, daniel@iogearbox.net,
netdev@vger.kernel.org, bpf@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH bpf-next 3/6] bpf: Introduce function-by-function verification
Date: Fri, 10 Jan 2020 11:08:00 +0100 [thread overview]
Message-ID: <87sgknzksf.fsf@toke.dk> (raw)
In-Reply-To: <20200109230328.i6zuva5gqezpltwp@ast-mbp>
Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
> On Thu, Jan 09, 2020 at 09:57:50AM +0100, Toke Høiland-Jørgensen wrote:
>>
>> > As far as future plans when libbpf sees FUNC_EXTERN it will do the linking the
>> > way we discussed in the other thread. The kernel will support FUNC_EXTERN when
>> > we introduce dynamic libraries. A collection of bpf functions will be loaded
>> > into the kernel first (like libc.so) and later programs will have FUNC_EXTERN
>> > as part of their BTF to be resolved while loading. The func name to btf_id
>> > resolution will be done by libbpf. The kernel verifier will do the type
>> > checking on BTFs.
>>
>> Right, FUNC_EXTERN will be rejected by the kernel unless it's patched up
>> with "target" btf_ids by libbpf before load? So it'll be
>> FUNC_GLOBAL-linked functions that will be replaceable after the fact
>> with the "dynamic re-linking" feature?
>
> Right. When libbpf statically links two .o it will need to produce a combined
> BTF out of these two .o. That new BTF will not have FUNC_EXTERN anymore if they
> are resolved. When the kernel sees FUNC_EXTERN it's a directive for the kernel
> to resolve it. BPF program with FUNC_EXTERN references would be loadable, but
> not executable. Anyhow the extern work is not immediate. I don't think any of
> that is necessary for dynamic re-linking.
Right, makes sense. I'll just wait for your follow-up series for the
dynamic re-linking, then. Thanks for the explanation :)
-Toke
next prev parent reply other threads:[~2020-01-10 10:08 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-08 7:25 [PATCH bpf-next 0/6] bpf: Introduce global functions Alexei Starovoitov
2020-01-08 7:25 ` [PATCH bpf-next 1/6] libbpf: Sanitize BTF_KIND_FUNC linkage Alexei Starovoitov
2020-01-08 17:35 ` Song Liu
2020-01-08 18:57 ` Yonghong Song
2020-01-08 20:12 ` Alexei Starovoitov
2020-01-08 7:25 ` [PATCH bpf-next 2/6] libbpf: Collect static vs global info about functions Alexei Starovoitov
2020-01-08 10:25 ` Toke Høiland-Jørgensen
2020-01-08 16:25 ` Yonghong Song
2020-01-09 8:50 ` Toke Høiland-Jørgensen
2020-01-08 17:57 ` Song Liu
2020-01-08 20:10 ` Alexei Starovoitov
2020-01-08 7:25 ` [PATCH bpf-next 3/6] bpf: Introduce function-by-function verification Alexei Starovoitov
2020-01-08 10:28 ` Toke Høiland-Jørgensen
2020-01-08 20:06 ` Alexei Starovoitov
2020-01-09 8:57 ` Toke Høiland-Jørgensen
2020-01-09 23:03 ` Alexei Starovoitov
2020-01-10 10:08 ` Toke Høiland-Jørgensen [this message]
2020-01-08 19:10 ` Song Liu
2020-01-08 20:20 ` Alexei Starovoitov
2020-01-08 21:24 ` Song Liu
2020-01-08 23:05 ` Alexei Starovoitov
2020-01-14 23:39 ` Stanislav Fomichev
2020-01-14 23:56 ` Andrii Nakryiko
2020-01-15 0:44 ` Stanislav Fomichev
2020-01-08 7:25 ` [PATCH bpf-next 4/6] selftests/bpf: Add fexit-to-skb test for global funcs Alexei Starovoitov
2020-01-08 19:15 ` Song Liu
2020-01-08 7:25 ` [PATCH bpf-next 5/6] selftests/bpf: Add a test for a large global function Alexei Starovoitov
2020-01-08 19:16 ` Song Liu
2020-01-08 19:17 ` Song Liu
2020-01-08 7:25 ` [PATCH bpf-next 6/6] selftests/bpf: Modify a test to check global functions Alexei Starovoitov
2020-01-08 19:18 ` 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=87sgknzksf.fsf@toke.dk \
--to=toke@redhat.com \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.