On Sat, Mar 19, 2022 at 8:37 PM Yonghong Song <yhs@xxxxxx> wrote:
>
>
>
> On 3/19/22 5:19 PM, Andrii Nakryiko wrote:
> > If BPF object doesn't have an BTF info, don't attempt to search for BTF
> > types describing BPF map key or value layout.
> >
> > Fixes: 262cfb74ffda ("libbpf: Init btf_{key,value}_type_id on internal map open")
> > Signed-off-by: Andrii Nakryiko <andrii@xxxxxxxxxx>
>
> So without this patch, we may have segfault or other errors, right?
> It would be good to specify that in the commit message.
>
> The code change looks good to me.
>
> Acked-by: Yonghong Song <yhs@xxxxxx>
>
> > ---
> > tools/lib/bpf/libbpf.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index 7526419e59e0..2efe9431c1ba 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -4197,6 +4197,9 @@ static int bpf_map_find_btf_info(struct bpf_object *obj, struct bpf_map *map)
> > __u32 key_type_id = 0, value_type_id = 0;
> > int ret;
> >
> > + if (!obj->btf)
> > + return -ENOENT;
> > +
yeah, it was SIGSEGV, which I only saw in libbpf CI on old 5.5 kernel.
I'll include a bit more specifics for future fixes, sorry.
> > /* if it's BTF-defined map, we don't need to search for type IDs.
> > * For struct_ops map, it does not need btf_key_type_id and
> > * btf_value_type_id.
