linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [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  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-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-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).