All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Lorenz Bauer <lmb@cloudflare.com>
Cc: "David S . Miller" <davem@davemloft.net>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	John Fastabend <john.fastabend@gmail.com>,
	mcroce@microsoft.com, bpf <bpf@vger.kernel.org>,
	Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH RFC bpf-next 00/10] bpf: CO-RE support in the kernel.
Date: Mon, 27 Sep 2021 09:50:31 -0700	[thread overview]
Message-ID: <20210927165031.hfv3kf43cxrbc3rb@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <CACAyw99aR5sfGZ5OQuRrz6Rt+sOkm6B2vC=JfK1tPqdf6961tw@mail.gmail.com>

On Mon, Sep 27, 2021 at 05:12:15PM +0100, Lorenz Bauer wrote:
> On Sat, 25 Sept 2021 at 00:13, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Thu, Sep 23, 2021 at 12:33:58PM +0100, Lorenz Bauer wrote:
> > >
> > > Some questions:
> > > * How can this handle kernels that don't have built-in BTF? Not a
> > > problem for myself, but some people have to deal with BTF-less distro
> > > kernels by using pahole to generate external BTF from debug symbols.
> > > Can we accommodate that?
> >
> > I think so, but it probably should be done as a generic feature:
> > "populate kernel BTF".
> > When kernel wasn't compiled with BTF there could be a way to
> > populate it with such. Just like we do sys_bpf(BTF_LOAD)
> > for program's BTF we can allow populating vmlinux BTF this way.
> > Unlike builtin BTF it wouldn't be trusted for certain verifier assumptions,
> > but better than nothing and more convenient than specifying BTF file
> > on a side for every bpf prog load with traditional libbpf style.
> 
> From my POV we already have an API for external BTF (and I think
> libbpf does too?) but would need a new API for "load kernel BTF".
> Global state like this also doesn't work well for several individual
> processes. Imagine multiple programs on the system trying to each
> replace the kernel BTF, how would that work? Which one wins? 

The kernel BTF can be only one, of course.
I don't expect progs to update the kernel BTF when they start.
It's more of the admin/chef job when kernel boots.
Only for the cases when kernel somehow was compiled without BTF.

> Being
> able to give my own fd for kernel BTF circumvents all those problems
> and seems much cleaner to me.

You mean to pass kernel BTF's fd to the kernel?
It's doable, but I don't quite see the operational side of it.
If progs have to carry both their BTF and kernel BTF why would
they need CO-RE at all? If they were compiled with given kernel BTF
there is no need to adjust offsets for the given host.
I suspect I simply don't understand your use case :)

  reply	other threads:[~2021-09-27 16:50 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-17 21:57 [PATCH RFC bpf-next 00/10] bpf: CO-RE support in the kernel Alexei Starovoitov
2021-09-17 21:57 ` [PATCH RFC bpf-next 01/10] bpf: Prepare relo_core.c for kernel duty Alexei Starovoitov
2021-09-21 21:25   ` Andrii Nakryiko
2021-09-28 14:45   ` Matteo Croce
2021-09-28 16:37     ` Alexei Starovoitov
2021-09-28 17:11       ` Matteo Croce
2021-09-28 20:34         ` Alexei Starovoitov
2021-09-29 12:32           ` Matteo Croce
2021-09-29 17:38             ` Matteo Croce
2021-09-29 23:00               ` Alexei Starovoitov
2021-09-29 23:49                 ` Matteo Croce
2021-10-22  0:48                   ` Matteo Croce
2021-10-22  0:51                     ` Alexei Starovoitov
2021-09-17 21:57 ` [PATCH RFC bpf-next 02/10] bpf: Define enum bpf_core_relo_kind as uapi Alexei Starovoitov
2021-09-21 21:27   ` Andrii Nakryiko
2021-09-17 21:57 ` [PATCH RFC bpf-next 03/10] bpf: Add proto of bpf_core_apply_relo() Alexei Starovoitov
2021-09-23 11:21   ` Lorenz Bauer
2021-09-23 18:48     ` Andrii Nakryiko
2021-09-17 21:57 ` [PATCH RFC bpf-next 04/10] bpf: Add bpf_core_add_cands() and wire it into bpf_core_apply_relo_insn() Alexei Starovoitov
2021-09-21 21:34   ` Andrii Nakryiko
2021-09-27 18:04   ` Matteo Croce
2021-09-17 21:57 ` [PATCH RFC bpf-next 05/10] libbpf: Use CO-RE in the kernel in light skeleton Alexei Starovoitov
2021-09-17 21:57 ` [PATCH RFC bpf-next 06/10] libbpf: Make gen_loader data aligned Alexei Starovoitov
2021-09-17 21:57 ` [PATCH RFC bpf-next 07/10] libbpf: Support init of inner maps in light skeleton Alexei Starovoitov
2021-09-17 21:57 ` [PATCH RFC bpf-next 08/10] selftests/bpf: Convert kfunc test with CO-RE to lskel Alexei Starovoitov
2021-09-17 21:57 ` [PATCH RFC bpf-next 09/10] selftests/bpf: Improve inner_map test coverage Alexei Starovoitov
2021-09-17 21:57 ` [PATCH RFC bpf-next 10/10] selftests/bpf: Convert map_ptr_kern test to use light skeleton Alexei Starovoitov
2021-09-23 11:33 ` [PATCH RFC bpf-next 00/10] bpf: CO-RE support in the kernel Lorenz Bauer
2021-09-23 18:52   ` Andrii Nakryiko
2021-09-24 23:13   ` Alexei Starovoitov
2021-09-27 16:12     ` Lorenz Bauer
2021-09-27 16:50       ` Alexei Starovoitov [this message]
2021-09-28  8:30         ` Lorenz Bauer
2021-09-28 16:35           ` 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=20210927165031.hfv3kf43cxrbc3rb@ast-mbp.dhcp.thefacebook.com \
    --to=alexei.starovoitov@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 \
    --cc=lmb@cloudflare.com \
    --cc=mcroce@microsoft.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 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.