On Mon, 7 Dec 2020, Andrii Nakryiko wrote: > On Sat, Dec 5, 2020 at 4:38 PM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > > Thanks so much for doing this Andrii! When I tested, I ran into a problem; > > it turns out when a module struct such as "veth_stats" is used, it's > > classified as BTF_KIND_FWD, and as a result when we iterate over > > the modules and look in the veth module, "struct veth_stats" does not > > match since its module kind (BTF_KIND_STRUCT) does not match the candidate > > kind (BTF_KIND_FWD). I'm kind of out of my depth here, but the below > > patch (on top of your patch) worked. > > I'm not quite clear on the situation. BTF_KIND_FWD is for the local > type or the remote type? Maybe a small example would help, before we > go straight to assuming FWD can be always resolved into a concrete > STRUCT/UNION. > The local type was BTF_KIND_FWD, and the target type was BTF_KIND_STRUCT IIRC; I'll try and get some libbpf debug output for you showing the relocation info. If it helps, I think the situation was this; I was referencing __builtin_btf_type_id(struct veth_stats), and hadn't included a BTF-generated veth header, so I'm guessing libbpf classified it as a fwd declaration. My patch was a bit too general I suspect in that it assumed that either target or local could be BTF_KIND_FWD and should match BTF_KIND_STRUCT in local/target, wheres I _think_ the local only should permit BTF_KIND_FWD. Does that make sense? > > > However without it - when we find > > 0 candidate matches - as well as not substituting the module object > > id/type id - we hit a segfault: > > Yep, I missed the null check in: > > targ_spec->btf != prog->obj->btf_vmlinux > > I'll fix that. > Thanks! I think the core_reloc selftests trigger the segfault also if you need a test case to verify. Alan
