* [PATCH bpf-next] libbpf: Introduce 'custom_btf_path' to 'bpf_obj_open_opts'. @ 2021-06-24 4:03 Shuyi Cheng 2021-06-24 15:06 ` Daniel Borkmann 2021-07-07 20:52 ` Andrii Nakryiko 0 siblings, 2 replies; 6+ messages in thread From: Shuyi Cheng @ 2021-06-24 4:03 UTC (permalink / raw) To: ast, daniel, andrii, kafai, songliubraving, yhs, john.fastabend, kpsingh Cc: netdev, bpf, linux-kernel, kernel-janitors, Shuyi Cheng 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; + 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); + } + if (err) { pr_warn("Error loading vmlinux BTF: %d\n", err); obj->btf_vmlinux = NULL; @@ -7554,7 +7563,7 @@ int bpf_program__load(struct bpf_program *prog, char *license, __u32 kern_ver) __bpf_object__open(const char *path, const void *obj_buf, size_t obj_buf_sz, const struct bpf_object_open_opts *opts) { - const char *obj_name, *kconfig; + const char *obj_name, *kconfig, *tmp_btf_path; struct bpf_program *prog; struct bpf_object *obj; char tmp_name[64]; @@ -7584,6 +7593,13 @@ int bpf_program__load(struct bpf_program *prog, char *license, __u32 kern_ver) obj = bpf_object__new(path, obj_buf, obj_buf_sz, obj_name); if (IS_ERR(obj)) return obj; + + tmp_btf_path = OPTS_GET(opts, custom_btf_path, NULL); + if (tmp_btf_path && strlen(tmp_btf_path) < PATH_MAX) { + obj->custom_btf_path = strdup(tmp_btf_path); + if (!obj->custom_btf_path) + return ERR_PTR(-ENOMEM); + } kconfig = OPTS_GET(opts, kconfig, NULL); if (kconfig) { @@ -8702,6 +8718,7 @@ void bpf_object__close(struct bpf_object *obj) for (i = 0; i < obj->nr_maps; i++) bpf_map__destroy(&obj->maps[i]); + zfree(&obj->custom_btf_path); zfree(&obj->kconfig); zfree(&obj->externs); obj->nr_extern = 0; diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h index 6e61342..16e0f01 100644 --- a/tools/lib/bpf/libbpf.h +++ b/tools/lib/bpf/libbpf.h @@ -94,8 +94,12 @@ struct bpf_object_open_opts { * system Kconfig for CONFIG_xxx externs. */ const char *kconfig; + /* Specify the path of vmlinux btf to facilitate the use of CO-RE features + * in the old kernel. + */ + char *custom_btf_path; }; -#define bpf_object_open_opts__last_field kconfig +#define bpf_object_open_opts__last_field custom_btf_path LIBBPF_API struct bpf_object *bpf_object__open(const char *path); LIBBPF_API struct bpf_object * -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH bpf-next] libbpf: Introduce 'custom_btf_path' to 'bpf_obj_open_opts'. 2021-06-24 4:03 [PATCH bpf-next] libbpf: Introduce 'custom_btf_path' to 'bpf_obj_open_opts' Shuyi Cheng @ 2021-06-24 15:06 ` Daniel Borkmann 2021-06-25 2:05 ` Shuyi Cheng 2021-07-07 20:57 ` Andrii Nakryiko 2021-07-07 20:52 ` Andrii Nakryiko 1 sibling, 2 replies; 6+ messages in thread From: Daniel Borkmann @ 2021-06-24 15:06 UTC (permalink / raw) To: Shuyi Cheng, ast, andrii, kafai, songliubraving, yhs, john.fastabend, kpsingh Cc: netdev, bpf, linux-kernel, kernel-janitors 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): 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; @@ -4402,6 +4402,8 @@ struct btf *libbpf_find_kernel_btf(void) } locations[] = { /* try canonical vmlinux BTF through sysfs first */ { "/sys/kernel/btf/vmlinux", true /* raw BTF */ }, + /* try user defined vmlinux ELF if a path was specified */ + { btf_custom_path }, /* fall back to trying to find vmlinux ELF on disk otherwise */ { "/boot/vmlinux-%1$s" }, { "/lib/modules/%1$s/vmlinux-%1$s" }, @@ -4419,11 +4421,11 @@ struct btf *libbpf_find_kernel_btf(void) uname(&buf); for (i = 0; i < ARRAY_SIZE(locations); i++) { + if (!locations[i].path_fmt) + continue; snprintf(path, PATH_MAX, locations[i].path_fmt, buf.release); - if (access(path, R_OK)) continue; - if (locations[i].raw_btf) btf = btf__parse_raw(path); else @@ -4440,6 +4442,11 @@ struct btf *libbpf_find_kernel_btf(void) return libbpf_err_ptr(-ESRCH); } +struct btf *libbpf_find_kernel_btf(void) +{ + return __libbpf_find_kernel_btf(NULL); +} + int btf_type_visit_type_ids(struct btf_type *t, type_id_visit_fn visit, void *ctx) { int i, n, err; And then you just call it as: obj->btf_vmlinux = __libbpf_find_kernel_btf(obj->btf_custom_path); err = libbpf_get_error(obj->btf_vmlinux); > if (err) { > pr_warn("Error loading vmlinux BTF: %d\n", err); > obj->btf_vmlinux = NULL; > @@ -7554,7 +7563,7 @@ int bpf_program__load(struct bpf_program *prog, char *license, __u32 kern_ver) > __bpf_object__open(const char *path, const void *obj_buf, size_t obj_buf_sz, > const struct bpf_object_open_opts *opts) > { > - const char *obj_name, *kconfig; > + const char *obj_name, *kconfig, *tmp_btf_path; > struct bpf_program *prog; > struct bpf_object *obj; > char tmp_name[64]; > @@ -7584,6 +7593,13 @@ int bpf_program__load(struct bpf_program *prog, char *license, __u32 kern_ver) > obj = bpf_object__new(path, obj_buf, obj_buf_sz, obj_name); > if (IS_ERR(obj)) > return obj; > + > + tmp_btf_path = OPTS_GET(opts, custom_btf_path, NULL); > + if (tmp_btf_path && strlen(tmp_btf_path) < PATH_MAX) { > + obj->custom_btf_path = strdup(tmp_btf_path); > + if (!obj->custom_btf_path) > + return ERR_PTR(-ENOMEM); > + } > > kconfig = OPTS_GET(opts, kconfig, NULL); > if (kconfig) { > @@ -8702,6 +8718,7 @@ void bpf_object__close(struct bpf_object *obj) > for (i = 0; i < obj->nr_maps; i++) > bpf_map__destroy(&obj->maps[i]); > > + zfree(&obj->custom_btf_path); > zfree(&obj->kconfig); > zfree(&obj->externs); > obj->nr_extern = 0; > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h > index 6e61342..16e0f01 100644 > --- a/tools/lib/bpf/libbpf.h > +++ b/tools/lib/bpf/libbpf.h > @@ -94,8 +94,12 @@ struct bpf_object_open_opts { > * system Kconfig for CONFIG_xxx externs. > */ > const char *kconfig; > + /* Specify the path of vmlinux btf to facilitate the use of CO-RE features > + * in the old kernel. > + */ > + char *custom_btf_path; > }; > -#define bpf_object_open_opts__last_field kconfig > +#define bpf_object_open_opts__last_field custom_btf_path > > LIBBPF_API struct bpf_object *bpf_object__open(const char *path); > LIBBPF_API struct bpf_object * > ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH bpf-next] libbpf: Introduce 'custom_btf_path' to 'bpf_obj_open_opts'. 2021-06-24 15:06 ` Daniel Borkmann @ 2021-06-25 2:05 ` Shuyi Cheng 2021-07-07 20:57 ` Andrii Nakryiko 1 sibling, 0 replies; 6+ messages in thread From: Shuyi Cheng @ 2021-06-25 2:05 UTC (permalink / raw) To: Daniel Borkmann, ast, andrii, kafai, songliubraving, yhs, john.fastabend, kpsingh Cc: netdev, bpf, linux-kernel, kernel-janitors On 6/24/21 11:06 PM, Daniel Borkmann 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 > Thank you very much for your reply. Agree. >> 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): > Your approach is very inspiring to me. But I did it for two reasons. 1. When the developer specifies btf_custom_path, btf should only be loaded from btf_custom_path; 2. Now pahole supports saving vmlinux's btf in raw format, so the old kernel can provide btf in elf format or raw format. see [0]. [0] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/tree/pahole.c#n1157 What do you think? Regards, Shuyi > 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; > @@ -4402,6 +4402,8 @@ struct btf *libbpf_find_kernel_btf(void) > } locations[] = { > /* try canonical vmlinux BTF through sysfs first */ > { "/sys/kernel/btf/vmlinux", true /* raw BTF */ }, > + /* try user defined vmlinux ELF if a path was specified */ > + { btf_custom_path }, > /* fall back to trying to find vmlinux ELF on disk otherwise */ > { "/boot/vmlinux-%1$s" }, > { "/lib/modules/%1$s/vmlinux-%1$s" }, > @@ -4419,11 +4421,11 @@ struct btf *libbpf_find_kernel_btf(void) > uname(&buf); > > for (i = 0; i < ARRAY_SIZE(locations); i++) { > + if (!locations[i].path_fmt) > + continue; > snprintf(path, PATH_MAX, locations[i].path_fmt, buf.release); > - > if (access(path, R_OK)) > continue; > - > if (locations[i].raw_btf) > btf = btf__parse_raw(path); > else > @@ -4440,6 +4442,11 @@ struct btf *libbpf_find_kernel_btf(void) > return libbpf_err_ptr(-ESRCH); > } > > +struct btf *libbpf_find_kernel_btf(void) > +{ > + return __libbpf_find_kernel_btf(NULL); > +} > + > int btf_type_visit_type_ids(struct btf_type *t, type_id_visit_fn > visit, void *ctx) > { > int i, n, err; > > And then you just call it as: > > obj->btf_vmlinux = __libbpf_find_kernel_btf(obj->btf_custom_path); > err = libbpf_get_error(obj->btf_vmlinux); > >> if (err) { >> pr_warn("Error loading vmlinux BTF: %d\n", err); >> obj->btf_vmlinux = NULL; ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH bpf-next] libbpf: Introduce 'custom_btf_path' to 'bpf_obj_open_opts'. 2021-06-24 15:06 ` Daniel Borkmann 2021-06-25 2:05 ` Shuyi Cheng @ 2021-07-07 20:57 ` Andrii Nakryiko 1 sibling, 0 replies; 6+ messages in thread From: Andrii Nakryiko @ 2021-07-07 20:57 UTC (permalink / raw) To: Daniel Borkmann Cc: Shuyi Cheng, Alexei Starovoitov, Andrii Nakryiko, Martin Lau, Song Liu, Yonghong Song, john fastabend, KP Singh, Networking, bpf, open list, kernel-janitors 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; [...] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH bpf-next] libbpf: Introduce 'custom_btf_path' to 'bpf_obj_open_opts'. 2021-06-24 4:03 [PATCH bpf-next] libbpf: Introduce 'custom_btf_path' to 'bpf_obj_open_opts' Shuyi Cheng 2021-06-24 15:06 ` Daniel Borkmann @ 2021-07-07 20:52 ` Andrii Nakryiko 2021-07-08 13:11 ` Shuyi Cheng 1 sibling, 1 reply; 6+ messages in thread From: Andrii Nakryiko @ 2021-07-07 20:52 UTC (permalink / raw) To: Shuyi Cheng Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Martin Lau, Song Liu, Yonghong Song, john fastabend, KP Singh, Networking, bpf, open list, kernel-janitors On Wed, Jun 23, 2021 at 9:04 PM Shuyi Cheng <chengshuyi@linux.alibaba.com> 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; > + > 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); > + } I think it will be more flexible to treat custom_btf as an vmlinux BTF override, just like [1] did. I can see how in some situations users might want to treat this custom BTF as either a replacement of vmlinux BTF or as an augmentation of vmlinux BTF for the purpose of extra custom CO-RE relocations (e.g., something along the XDP hints that were discussed recently). For now it's probably enough to implement "custom BTF is a replacement for vmlinux BTF" policy and, if necessary, add "custom BTF is in addition to vmlinux BTF" later with extra opts flag/field. Keep in mind that this custom BTF is only useful for BPF CO-RE relocation. Any other kernel feature relying on vmlinux BTF (e.g., fentry) won't work with custom BTF because it expects correct BTF type IDs. > + > if (err) { > pr_warn("Error loading vmlinux BTF: %d\n", err); > obj->btf_vmlinux = NULL; > @@ -7554,7 +7563,7 @@ int bpf_program__load(struct bpf_program *prog, char *license, __u32 kern_ver) > __bpf_object__open(const char *path, const void *obj_buf, size_t obj_buf_sz, > const struct bpf_object_open_opts *opts) > { > - const char *obj_name, *kconfig; > + const char *obj_name, *kconfig, *tmp_btf_path; > struct bpf_program *prog; > struct bpf_object *obj; > char tmp_name[64]; > @@ -7584,6 +7593,13 @@ int bpf_program__load(struct bpf_program *prog, char *license, __u32 kern_ver) > obj = bpf_object__new(path, obj_buf, obj_buf_sz, obj_name); > if (IS_ERR(obj)) > return obj; > + > + tmp_btf_path = OPTS_GET(opts, custom_btf_path, NULL); > + if (tmp_btf_path && strlen(tmp_btf_path) < PATH_MAX) { if strlen() is >= PATH_MAX you'll just silently ignore it? We should either truncate silently (because PATH_MAX is totally reasonable assumption) or error out. > + obj->custom_btf_path = strdup(tmp_btf_path); > + if (!obj->custom_btf_path) > + return ERR_PTR(-ENOMEM); > + } > > kconfig = OPTS_GET(opts, kconfig, NULL); > if (kconfig) { > @@ -8702,6 +8718,7 @@ void bpf_object__close(struct bpf_object *obj) > for (i = 0; i < obj->nr_maps; i++) > bpf_map__destroy(&obj->maps[i]); > > + zfree(&obj->custom_btf_path); > zfree(&obj->kconfig); > zfree(&obj->externs); > obj->nr_extern = 0; > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h > index 6e61342..16e0f01 100644 > --- a/tools/lib/bpf/libbpf.h > +++ b/tools/lib/bpf/libbpf.h > @@ -94,8 +94,12 @@ struct bpf_object_open_opts { > * system Kconfig for CONFIG_xxx externs. > */ > const char *kconfig; > + /* Specify the path of vmlinux btf to facilitate the use of CO-RE features > + * in the old kernel. > + */ > + char *custom_btf_path; > }; > -#define bpf_object_open_opts__last_field kconfig > +#define bpf_object_open_opts__last_field custom_btf_path > > LIBBPF_API struct bpf_object *bpf_object__open(const char *path); > LIBBPF_API struct bpf_object * > -- > 1.8.3.1 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH bpf-next] libbpf: Introduce 'custom_btf_path' to 'bpf_obj_open_opts'. 2021-07-07 20:52 ` Andrii Nakryiko @ 2021-07-08 13:11 ` Shuyi Cheng 0 siblings, 0 replies; 6+ messages in thread From: Shuyi Cheng @ 2021-07-08 13:11 UTC (permalink / raw) To: Andrii Nakryiko Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Martin Lau, Song Liu, Yonghong Song, john fastabend, KP Singh, Networking, bpf, open list, kernel-janitors On 7/8/21 4:52 AM, Andrii Nakryiko wrote: > On Wed, Jun 23, 2021 at 9:04 PM Shuyi Cheng > <chengshuyi@linux.alibaba.com> 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; >> + >> 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); >> + } > > > I think it will be more flexible to treat custom_btf as an vmlinux BTF > override, just like [1] did. I can see how in some situations users > might want to treat this custom BTF as either a replacement of vmlinux > BTF or as an augmentation of vmlinux BTF for the purpose of extra > custom CO-RE relocations (e.g., something along the XDP hints that > were discussed recently). For now it's probably enough to implement > "custom BTF is a replacement for vmlinux BTF" policy and, if > necessary, add "custom BTF is in addition to vmlinux BTF" later with > extra opts flag/field. > Thank you very much for your reply. So this part of the code remains the same, right? > Keep in mind that this custom BTF is only useful for BPF CO-RE > relocation. Any other kernel feature relying on vmlinux BTF (e.g., > fentry) won't work with custom BTF because it expects correct BTF type > IDs. > > >> + >> if (err) { >> pr_warn("Error loading vmlinux BTF: %d\n", err); >> obj->btf_vmlinux = NULL; >> @@ -7554,7 +7563,7 @@ int bpf_program__load(struct bpf_program *prog, char *license, __u32 kern_ver) >> __bpf_object__open(const char *path, const void *obj_buf, size_t obj_buf_sz, >> const struct bpf_object_open_opts *opts) >> { >> - const char *obj_name, *kconfig; >> + const char *obj_name, *kconfig, *tmp_btf_path; >> struct bpf_program *prog; >> struct bpf_object *obj; >> char tmp_name[64]; >> @@ -7584,6 +7593,13 @@ int bpf_program__load(struct bpf_program *prog, char *license, __u32 kern_ver) >> obj = bpf_object__new(path, obj_buf, obj_buf_sz, obj_name); >> if (IS_ERR(obj)) >> return obj; >> + >> + tmp_btf_path = OPTS_GET(opts, custom_btf_path, NULL); >> + if (tmp_btf_path && strlen(tmp_btf_path) < PATH_MAX) { > > if strlen() is >= PATH_MAX you'll just silently ignore it? We should > either truncate silently (because PATH_MAX is totally reasonable > assumption) or error out. Agree. I will send the second version of the patch. Regards, Shuyi > >> + obj->custom_btf_path = strdup(tmp_btf_path); >> + if (!obj->custom_btf_path) >> + return ERR_PTR(-ENOMEM); >> + } >> >> kconfig = OPTS_GET(opts, kconfig, NULL); >> if (kconfig) { >> @@ -8702,6 +8718,7 @@ void bpf_object__close(struct bpf_object *obj) >> for (i = 0; i < obj->nr_maps; i++) >> bpf_map__destroy(&obj->maps[i]); >> >> + zfree(&obj->custom_btf_path); >> zfree(&obj->kconfig); >> zfree(&obj->externs); >> obj->nr_extern = 0; >> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h >> index 6e61342..16e0f01 100644 >> --- a/tools/lib/bpf/libbpf.h >> +++ b/tools/lib/bpf/libbpf.h >> @@ -94,8 +94,12 @@ struct bpf_object_open_opts { >> * system Kconfig for CONFIG_xxx externs. >> */ >> const char *kconfig; >> + /* Specify the path of vmlinux btf to facilitate the use of CO-RE features >> + * in the old kernel. >> + */ >> + char *custom_btf_path; >> }; >> -#define bpf_object_open_opts__last_field kconfig >> +#define bpf_object_open_opts__last_field custom_btf_path >> >> LIBBPF_API struct bpf_object *bpf_object__open(const char *path); >> LIBBPF_API struct bpf_object * >> -- >> 1.8.3.1 >> ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-07-08 13:12 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-24 4:03 [PATCH bpf-next] libbpf: Introduce 'custom_btf_path' to 'bpf_obj_open_opts' Shuyi Cheng 2021-06-24 15:06 ` Daniel Borkmann 2021-06-25 2:05 ` Shuyi Cheng 2021-07-07 20:57 ` Andrii Nakryiko 2021-07-07 20:52 ` Andrii Nakryiko 2021-07-08 13:11 ` Shuyi Cheng
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).