On Thu, Jun 24, 2021 at 8:06 AM Daniel Borkmann <daniel@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx/#t > > [1]https://yhbt.net/lore/all/CAEf4Bzbgw49w2PtowsrzKQNcxD4fZRE6AKByX-5-dMo-+oWHHA@xxxxxxxxxxxxxx/ > > > > Signed-off-by: Shuyi Cheng <chengshuyi@xxxxxxxxxxxxxxxxx> > > --- > > 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; [...]
