On Wed, Jun 22, 2022 at 05:22:24PM +0000, Daniel Müller wrote:
> On Tue, Jun 21, 2022 at 12:41:22PM -0700, Joanne Koong wrote:
> > On Mon, Jun 20, 2022 at 4:25 PM Daniel Müller <deso@xxxxxxxxxx> wrote:
[...]
> > > + case BTF_KIND_FUNC_PROTO: {
> > > + struct btf_param *local_p = btf_params(local_t);
> > > + struct btf_param *targ_p = btf_params(targ_t);
> > > + u16 local_vlen = btf_vlen(local_t);
> > > + u16 targ_vlen = btf_vlen(targ_t);
> > > + int i, err;
> > > +
> > > + if (local_k != btf_kind(targ_t))
> > > + return 0;
> > > +
> > > + if (local_vlen != targ_vlen)
> > > + return 0;
> > > +
> > > + for (i = 0; i < local_vlen; i++, local_p++, targ_p++) {
> > > + err = __bpf_core_types_match(local_btf, local_p->type, targ_btf,
> > > + targ_p->type, level - 1);
> > > + if (err <= 0)
> > > + return err;
> > > + }
> > > +
> > > + /* tail recurse for return type check */
> > > + local_id = local_t->type;
> > > + targ_id = targ_t->type;
> > > + goto recur;
> > > + }
> > > + default:
> > Do BTF_KIND_FLOAT and BTF_KIND_TYPEDEF need to be checked as well?
>
> Lack of BTF_KIND_TYPEDEF is a good question. I don't know why it's missing from
> bpf_core_types_are_compat() as well, which I took as a template. I will do some
> testing to better understand if we can hit this case or whether there is some
> magic going on that would have resolved typedefs already at this point (which is
> my suspicion).
> My understanding why we don't cover floats is because we do not allow floating
> point operations in kernel code (right?).
So typedefs are all skipped by the logic, see calls to btf_type_skip_modifiers
at the top of the function. That's why we don't need to handle them explicitly.
I should have a revised version addressing the other points up shortly.
Daniel
