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

On Thu, Feb 26, 2026 at 8:26 AM Alan Maguire <[email protected]> wrote:
>
> On 26/02/2026 10:05, [email protected] 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.

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.