Re: [PATCH v9 bpf-next 06/10] btf: support kernel parsing of BTF with layout info

[Alan Maguire <alan.maguire@oracle.com>]

On 26/02/2026 16:34, Alexei Starovoitov wrote:
> On Thu, Feb 26, 2026 at 8:26 AM Alan Maguire <alan.maguire@oracle.com> wrote:
>>
>> On 26/02/2026 10:05, bot+bpf-ci@kernel.org wrote:
>>>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>>>> --- a/kernel/bpf/btf.c
>>>> +++ b/kernel/bpf/btf.c
>>>
>>> [ ... ]
>>>
>>>> @@ -5327,23 +5328,36 @@ static s32 btf_check_meta(struct btf_verifier_env *env,
>>>>              return -EINVAL;
>>>>      }
>>>>
>>>> +    if (!btf_name_offset_valid(env->btf, t->name_off)) {
>>>> +            btf_verifier_log(env, "[%u] Invalid name_offset:%u",
>>>> +                             env->log_type_id, t->name_off);
>>>> +            return -EINVAL;
>>>> +    }
>>>> +
>>>> +    if (BTF_INFO_KIND(t->info) == BTF_KIND_UNKN) {
>>>>              btf_verifier_log(env, "[%u] Invalid kind:%u",
>>>>                               env->log_type_id, BTF_INFO_KIND(t->info));
>>>>              return -EINVAL;
>>>>      }
>>>>
>>>> +    if (BTF_INFO_KIND(t->info) > BTF_KIND_MAX && env->btf->layout &&
>>>> +        ((BTF_INFO_KIND(t->info) + 1) * sizeof(struct btf_layout)) <
>>>> +         env->btf->hdr.layout_len) {
>>>                                        ^
>>>
>>> Should this be <= instead of < ?  If the layout section has exactly
>>> N entries, layout_len is N * sizeof(struct btf_layout).  For the
>>> last covered kind (K = N - 1), this computes:
>>>
>>>     (K + 1) * sizeof(struct btf_layout) == layout_len
>>>
>>> With < that evaluates to false, so the last kind covered by the
>>> layout section falls through to the else branch and gets logged as
>>> "Invalid kind" instead of "unknown but required kind".
>>>
>>> The libbpf equivalent in btf_type_size_unknown() uses:
>>>
>>>     __u32 layout_kinds = btf->hdr.layout_len / sizeof(struct btf_layout);
>>>     if (!l || kind >= layout_kinds) {
>>>
>>> which accepts the last entry.  Using <= here would match that
>>> behavior.
>>>
>>
>> looking at this again, is it worth making the distinction between a kind
>> that's in the BTF layout but unknown to the kernel versus one that is
>> not in the BTF layout and unknown to the kernel? In both cases we reject
>> the BTF, and given that the kernel cannot be in the business of trusting
>> the layout provided with that BTF it seems like it's a distinction without
>> a practical difference.
> 
> "unknown but required kind" means that the kernel doesn't understand
> the kind, but its layout is described in BTF?
> If so the sentence is odd, since presence in kind_layout doesn't mean
> it's actually used. Here the check is when the kind is parsed.
> So the kernel should reject it with existing "invalid kind" message and
> that's it. It doesn't matter whether the unknown kind was described
> in the layout.
>

yeah, looking at this again it's leftovers from the flags stuff which makes
it confusing. I'll revert to original error messaging since it's irrelevant
to the kernel if the kind is in the layout if the kernel doesn't know about
that kind - we can't blindly trust the layout data.

 
> But at the same time if the kind layout describes some unknown kinds
> it's not an error. I think it's fine to load such BTF since all used
> kinds are known.

Right; we'll allow layout to describe additional kinds not known to the
kernel, but won't trust that info for parsing BTF in-kernel.