Re: [PATCH bpf-next] libbpf: support module BTF for BPF_TYPE_ID_TARGET CO-RE relocation

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

On Mon, 7 Dec 2020, Andrii Nakryiko wrote:

> On Sat, Dec 5, 2020 at 4:38 PM Alan Maguire <alan.maguire@oracle.com> 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