[V2,bpf-next] bpf: export btf_find_by_name_kind and bpf_base_func_proto

Commit Message

Ming Lei July 26, 2024, 12:59 p.m. UTC

Almost all existed struct_ops users(hid, sched_ext, ...) need the two APIs.

In-tree hid-bpf code(drivers/hid/bpf/hid_bpf_struct_ops.c) can't be built
as module because the two APIs aren't exported.

Export btf_find_by_name_kind and bpf_base_func_proto, so that any kernel
module can use them given bpf community is supporting to register
struct_ops in module, see the patchset "Registrating struct_ops types from
modules"[1], which is merged to v6.9.

Cc: Yonghong Song <[e-mail]>
Cc: Benjamin Tissoires <[e-mail]>
Cc: Jiri Kosina <[e-mail]>
Signed-off-by: Ming Lei <[e-mail]>
---
V2:
	- add more details in commit log (Yonghong)
	- add 'bpf-next' in patch title (Yonghong)

 kernel/bpf/btf.c     | 1 +
 kernel/bpf/helpers.c | 1 +
 2 files changed, 2 insertions(+)

Comments

Yonghong Song July 26, 2024, 2:26 p.m. UTC | #1

On 7/26/24 5:59 AM, Ming Lei wrote:
> Almost all existed struct_ops users(hid, sched_ext, ...) need the two APIs.
>
> In-tree hid-bpf code(drivers/hid/bpf/hid_bpf_struct_ops.c) can't be built
> as module because the two APIs aren't exported.
>
> Export btf_find_by_name_kind and bpf_base_func_proto, so that any kernel
> module can use them given bpf community is supporting to register
> struct_ops in module, see the patchset "Registrating struct_ops types from
> modules"[1], which is merged to v6.9.
>
> Cc: Yonghong Song <[e-mail]>
> Cc: Benjamin Tissoires <[e-mail]>
> Cc: Jiri Kosina <[e-mail]>
> Signed-off-by: Ming Lei <[e-mail]>

Acked-by: Yonghong Song <[e-mail]>

Kui-Feng Lee July 26, 2024, 4:06 p.m. UTC | #2

On 7/26/24 05:59, Ming Lei wrote:
> Almost all existed struct_ops users(hid, sched_ext, ...) need the two APIs.
> 
> In-tree hid-bpf code(drivers/hid/bpf/hid_bpf_struct_ops.c) can't be built
> as module because the two APIs aren't exported.
> 
> Export btf_find_by_name_kind and bpf_base_func_proto, so that any kernel
> module can use them given bpf community is supporting to register
> struct_ops in module, see the patchset "Registrating struct_ops types from
> modules"[1], which is merged to v6.9.
> 
> Cc: Yonghong Song <[e-mail]>
> Cc: Benjamin Tissoires <[e-mail]>
> Cc: Jiri Kosina <[e-mail]>
> Signed-off-by: Ming Lei <[e-mail]>
> ---
> V2:
> 	- add more details in commit log (Yonghong)
> 	- add 'bpf-next' in patch title (Yonghong)
> 
>   kernel/bpf/btf.c     | 1 +
>   kernel/bpf/helpers.c | 1 +
>   2 files changed, 2 insertions(+)
> 
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 520f49f422fe..519c6e5a57d5 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -567,6 +567,7 @@ s32 btf_find_by_name_kind(const struct btf *btf, const char *name, u8 kind)
>   
>   	return -ENOENT;
>   }
> +EXPORT_SYMBOL_GPL(btf_find_by_name_kind);
>   
>   s32 bpf_find_btf_id(const char *name, u32 kind, struct btf **btf_p)
>   {
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index b5f0adae8293..18d1a76f96d2 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -2033,6 +2033,7 @@ bpf_base_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
>   		return NULL;
>   	}
>   }
> +EXPORT_SYMBOL_GPL(bpf_base_func_proto);
>   
>   void bpf_list_head_free(const struct btf_field *field, void *list_head,
>   			struct bpf_spin_lock *spin_lock)

Acked-by: Kui-Feng Lee <[e-mail]>

Martin KaFai Lau July 29, 2024, 9:07 p.m. UTC | #3

On 7/26/24 5:59 AM, Ming Lei wrote:
> Almost all existed struct_ops users(hid, sched_ext, ...) need the two APIs.
> 
> In-tree hid-bpf code(drivers/hid/bpf/hid_bpf_struct_ops.c) can't be built
> as module because the two APIs aren't exported.

The patch looks fine. I don't see "config HID_BPF" can be built as a module now 
though that could expose this issue. Did I miss something?

> 
> Export btf_find_by_name_kind and bpf_base_func_proto, so that any kernel
> module can use them given bpf community is supporting to register
> struct_ops in module, see the patchset "Registrating struct_ops types from
> modules"[1], which is merged to v6.9.

Ming Lei July 31, 2024, 8:18 a.m. UTC | #4

On Tue, Jul 30, 2024 at 5:07 AM Martin KaFai Lau <[e-mail]> wrote:
>
> On 7/26/24 5:59 AM, Ming Lei wrote:
> > Almost all existed struct_ops users(hid, sched_ext, ...) need the two APIs.
> >
> > In-tree hid-bpf code(drivers/hid/bpf/hid_bpf_struct_ops.c) can't be built
> > as module because the two APIs aren't exported.
>
> The patch looks fine. I don't see "config HID_BPF" can be built as a module now
> though that could expose this issue. Did I miss something?

Yeah, this patch doesn't try to change HID_BPF yet, and it can be thought
as one struct_ops module prep patch.

The issue itself is observed when I write ublk-bpf since ublk is one module
and struct_ops is allowed to be registered in the module.

Thanks,
Ming

Martin KaFai Lau Aug. 1, 2024, 12:34 a.m. UTC | #5

On 7/31/24 1:18 AM, Ming Lei wrote:
> On Tue, Jul 30, 2024 at 5:07 AM Martin KaFai Lau <[e-mail]> wrote:
>>
>> On 7/26/24 5:59 AM, Ming Lei wrote:
>>> Almost all existed struct_ops users(hid, sched_ext, ...) need the two APIs.
>>>
>>> In-tree hid-bpf code(drivers/hid/bpf/hid_bpf_struct_ops.c) can't be built
>>> as module because the two APIs aren't exported.
>>
>> The patch looks fine. I don't see "config HID_BPF" can be built as a module now
>> though that could expose this issue. Did I miss something?
> 
> Yeah, this patch doesn't try to change HID_BPF yet, and it can be thought
> as one struct_ops module prep patch.
> 
> The issue itself is observed when I write ublk-bpf since ublk is one module
> and struct_ops is allowed to be registered in the module.

Good to hear struct_ops find another potential use case. The ublk-bpf 
development cannot continue without building as kmod?

Instead of exporting it now and pending without a user, I will wait till the 
first in-tree kmod use case comes up first.

Patch

diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 520f49f422fe..519c6e5a57d5 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -567,6 +567,7 @@  s32 btf_find_by_name_kind(const struct btf *btf, const char *name, u8 kind)
 
 	return -ENOENT;
 }
+EXPORT_SYMBOL_GPL(btf_find_by_name_kind);
 
 s32 bpf_find_btf_id(const char *name, u32 kind, struct btf **btf_p)
 {
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index b5f0adae8293..18d1a76f96d2 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -2033,6 +2033,7 @@  bpf_base_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
 		return NULL;
 	}
 }
+EXPORT_SYMBOL_GPL(bpf_base_func_proto);
 
 void bpf_list_head_free(const struct btf_field *field, void *list_head,
 			struct bpf_spin_lock *spin_lock)