lkml.org 
[lkml]   [2021]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH bpf-next] libbpf: Introduce 'custom_btf_path' to 'bpf_obj_open_opts'.
On Thu, Jun 24, 2021 at 8:06 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 6/24/21 6:03 AM, Shuyi Cheng wrote:
> > In order to enable the older kernel to use the CO-RE feature, load the
> > vmlinux btf of the specified path.
> >
> > Learn from Andrii's comments in [0], add the custom_btf_path parameter
> > to bpf_obj_open_opts, you can directly use the skeleton's
> > <objname>_bpf__open_opts function to pass in the custom_btf_path
> > parameter.
> >
> > Prior to this, there was also a developer who provided a patch with
> > similar functions. It is a pity that the follow-up did not continue to
> > advance. See [1].
> >
> > [0]https://lore.kernel.org/bpf/CAEf4BzbJZLjNoiK8_VfeVg_Vrg=9iYFv+po-38SMe=UzwDKJ=Q@mail.gmail.com/#t
> > [1]https://yhbt.net/lore/all/CAEf4Bzbgw49w2PtowsrzKQNcxD4fZRE6AKByX-5-dMo-+oWHHA@mail.gmail.com/
> >
> > Signed-off-by: Shuyi Cheng <chengshuyi@linux.alibaba.com>
> > ---
> > tools/lib/bpf/libbpf.c | 23 ++++++++++++++++++++---
> > tools/lib/bpf/libbpf.h | 6 +++++-
> > 2 files changed, 25 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index 1e04ce7..518b19f 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -509,6 +509,8 @@ struct bpf_object {
> > void *priv;
> > bpf_object_clear_priv_t clear_priv;
> >
> > + char *custom_btf_path;
> > +
>
> nit: This should rather go to the 'Parse and load BTF vmlinux if any of [...]'
> section of struct bpf_object, and for consistency, I'd keep the btf_ prefix,
> like: char *btf_custom_path
>
> > char path[];
> > };
> > #define obj_elf_valid(o) ((o)->efile.elf)
> > @@ -2679,8 +2681,15 @@ static int bpf_object__load_vmlinux_btf(struct bpf_object *obj, bool force)
> > if (!force && !obj_needs_vmlinux_btf(obj))
> > return 0;
> >
> > - obj->btf_vmlinux = libbpf_find_kernel_btf();
> > - err = libbpf_get_error(obj->btf_vmlinux);
> > + if (obj->custom_btf_path) {
> > + obj->btf_vmlinux = btf__parse(obj->custom_btf_path, NULL);
> > + err = libbpf_get_error(obj->btf_vmlinux);
> > + pr_debug("loading custom vmlinux BTF '%s': %d\n", obj->custom_btf_path, err);
> > + } else {
> > + obj->btf_vmlinux = libbpf_find_kernel_btf();
> > + err = libbpf_get_error(obj->btf_vmlinux);
> > + }
>
> Couldn't we do something like (only compile-tested):

I wonder what are the benefits of this approach, though. My
expectation is that if the user specifies a custom BTF path and BTF is
missing then the whole bpf_object load process should fail, but in
this case it will be silently ignored. Also, if custom BTF is
specified, that custom BTF has to be used even if
/sys/kernel/btf/vmlinux is present, but the patch below will still
prefer /sys/kernel/btf/vmlinux.

So the semantics is different. I'm not saying it's wrong, but I think
it means we need to discuss what behavior we are after first.

>
> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> index b46760b93bb4..5b88ce3e483c 100644
> --- a/tools/lib/bpf/btf.c
> +++ b/tools/lib/bpf/btf.c
> @@ -4394,7 +4394,7 @@ static int btf_dedup_remap_types(struct btf_dedup *d)
> * Probe few well-known locations for vmlinux kernel image and try to load BTF
> * data out of it to use for target BTF.
> */
> -struct btf *libbpf_find_kernel_btf(void)
> +static struct btf *__libbpf_find_kernel_btf(char *btf_custom_path)
> {
> struct {
> const char *path_fmt;

[...]

\
 
 \ /
  Last update: 2021-07-07 22:59    [W:0.117 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site