On Tue, Jun 24, 2025 at 12:10 PM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote:
>
> This commit adds a kernel side enum for use in conjucntion with BTF
> CO-RE bpf_core_enum_value_exists. The goal of the enum is to assist
> with available BPF features detection.
>
> Support for bpf_rdonly_cast to void* is the first feature listed in
> the enum. Here is an example usage:
>
> if (bpf_core_enum_value_exists(enum bpf_features,
> BPF_FEAT_RDONLY_CAST_TO_VOID))
> ... bpf_rdonly_cast(..., 0) ...
>
> Signed-off-by: Eduard Zingerman <eddyz87@xxxxxxxxx>
> ---
> kernel/bpf/verifier.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 8fd65eb74051..01050d1f7389 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -44,6 +44,11 @@ static const struct bpf_verifier_ops * const bpf_verifier_ops[] = {
> #undef BPF_LINK_TYPE
> };
>
> +enum bpf_features {
> + BPF_FEAT_RDONLY_CAST_TO_VOID = 0,
> + BPF_FEAT_TOTAL,
I don't see the value of 'total', but not strongly against it.
But pls be consistent with __MAX_BPF_CMD, __MAX_BPF_MAP_TYPE, ...
Say, __MAX_BPF_FEAT ?
Also it's better to introduce this enum in some earlier patch,
and then always add BTF_FEAT_... to this enum
in the same patch that adds the feature to make
sure backports won't screw it up.
Another rule should be to always assign a number to it.
At the end with random backports the __MAX_BPF_FEAT
won't be accurate, but whatever.
> +};
> +
> struct bpf_mem_alloc bpf_global_percpu_ma;
> static bool bpf_global_percpu_ma_set;
>
> @@ -24436,6 +24441,8 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr, __u3
> u32 log_true_size;
> bool is_priv;
>
> + BTF_TYPE_EMIT(enum bpf_features);
> +
> /* no program is valid */
> if (ARRAY_SIZE(bpf_verifier_ops) == 0)
> return -EINVAL;
> --
> 2.47.1
>
