Re: [PATCH RFC bpf-next 1/7] bpf: Add bpf_btf_get_struct_member_info() helper

[bot+bpf-ci]

> bpf: Add bpf_btf_get_struct_member_info() helper

TL;DR: Design question: the new UAPI helper is added despite the frozen helper
list, which says to use kfuncs; syscall programs can already call kfuncs, and
the commit message doesn't explain why a helper is needed.

> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h

[ ... ]

> @@ -6279,6 +6291,7 @@ union bpf_attr {
>  	FN(user_ringbuf_drain, 209, ##ctx)		\
>  	FN(cgrp_storage_get, 210, ##ctx)		\
>  	FN(cgrp_storage_delete, 211, ##ctx)		\
> +	FN(btf_get_struct_member_info, 212, ##ctx)	\
>  	/* This helper list is effectively frozen. If you are trying to	\
>  	 * add a new helper, you should add a kfunc instead which has	\
>  	 * less stability guarantees. See Documentation/bpf/kfuncs.rst	\

This adds a new UAPI helper id right above the comment saying the helper
list is effectively frozen and that new functionality should be a kfunc.

BPF_PROG_TYPE_SYSCALL programs can already call kfuncs, for example via
register_btf_kfunc_id_set(BPF_PROG_TYPE_SYSCALL, &generic_kfunc_set) in
kernel/bpf/helpers.c.

Is there a reason this needs to be a helper rather than a kfunc?  Perhaps
the generated light skeleton loader cannot resolve a kfunc BTF id for its
own call instruction, while a helper has a fixed id, but the commit message
only says:

> This helper will be used by BPF light skeletons (gen_loader) to
> initialize struct_ops maps and programs against kernel and module BTF
> at load time.

Could the commit message explain why the freeze is being broken here and
why a kfunc will not work?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/42289585064