Re: [PATCH bpf-next 1/3] bpf: btf: check name validity for various types

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Mon, Nov 26, 2018 at 09:17:13PM -0800, Yonghong Song wrote:
> Commit 2667a2626f4d ("bpf: btf: Add BTF_KIND_FUNC
> and BTF_KIND_FUNC_PROTO") checked the name validity
> for BTF_KIND_FUNC/BTF_KIND_FUNC_PROTO types such that:
>  . BTF_KIND_FUNC must have a valid identifier name
>  . BTF_KIND_PROTO must have a null name
>  . The argument name of BTF_KIND_FUNC/BTF_KIND_FUNC_PROTO,
>    if not null, must be a valid identifier.
> 
> This patch added name checking for the following types:
>  . BTF_KIND_PTR, BTF_KIND_ARRAY, BTF_KIND_VOLATILE,
>    BTF_KIND_CONST, BTF_KIND_RESTRICT:
>      the name must be null
>  . BTF_KIND_STRUCT, BTF_KIND_UNION: the struct/member name
>      is either null or a valid identifier
>  . BTF_KIND_ENUM: the enum type name is either null or a valid
>      identifier; the enumerator name must be a valid identifier.
>  . BTF_KIND_FWD: the name must be a valid identifier
>  . BTF_KIND_TYPEDEF: the name must be a valid identifier
> 
> For those places a valid name is required, the name must be
> a valid C identifier. This can be relaxed later if we found
> use cases for a different (non-C) frontend.
> 
> Acked-by: Martin KaFai Lau <kafai@fb.com>
> Signed-off-by: Yonghong Song <yhs@fb.com>
...
>  	return 0;
> @@ -1409,6 +1432,12 @@ static s32 btf_array_check_meta(struct btf_verifier_env *env,
>  		return -EINVAL;
>  	}
>  
> +	/* array type should not have a name */
> +	if (t->name_off) {
> +		btf_verifier_log_type(env, t, "Invalid name");
> +		return -EINVAL;
> +	}
> +
>  	if (btf_type_vlen(t)) {
>  		btf_verifier_log_type(env, t, "vlen != 0");
>  		return -EINVAL;
> @@ -1585,6 +1614,13 @@ static s32 btf_struct_check_meta(struct btf_verifier_env *env,
>  		return -EINVAL;
>  	}
>  
> +	/* struct type either no name or a valid one */
> +	if (t->name_off &&
> +	    !btf_name_valid_identifier(env->btf, t->name_off)) {

Looks like some of these changes need to go into bpf tree.
please split it up and let's try to minimize the conflicts between bpf and bpf-next
Thanks!