Re: [PATCH] libbpf: checking the btf_type kind when fixing variable offsets

[Eduard Zingerman <eddyz87@gmail.com>]

On Mon, 2024-06-17 at 12:29 +0100, Alan Maguire wrote:

[...]

> The only thing I could come up with is we were usually lucky; when we
> misinterpreted the func as a var and looked its type up, we got
> 
> 		int var_linkage = btf_var(vt)->linkage;
> 
> ...and were lucky it never equalled 1 (BTF_VAR_GLOBAL_ALLOCATED):
> 	
> 		/* no need to patch up static or extern vars */
>                 if (var_linkage != BTF_VAR_GLOBAL_ALLOCATED)
> 			continue;
> 
> In the case of a function, the above btf_var(vt) would really be
> pointing at the struct btf_type immediately after the relevant
> function's struct btf_type (since unlike variables, functions don't have
> metadata following them). So the only way we'd trip this bug would be if
> the struct btf_type following the func was had a name_off value that
> happened to equal 1 (BTF_VAR_GLOBAL_ALLOCATED).
> 
> So maybe the sorting changes to BTF order resulted in us tripping on
> this bug, but regardless the fix seems right to me.

I've added the following debug logging:
 
                        sym = find_sym_by_name(obj, sec->sec_idx, STT_OBJECT, var_name);
                        if (!sym) {
+                               const struct btf_type *nt;
                                pr_warn("failed to find symbol for variable '%s' in section '%s'\n", var_name, sec_name);
+                               nt = btf__type_by_id(obj->btf, vi->type + 1);
+                               pr_warn("  vi->type == %d\n", vi->type);
+                               pr_warn("  next id %d kind '%s', name '%s' off %d\n",
+                                       vi->type + 1,
+                                       btf_kind_str(nt),
+                                       btf__str_by_offset(obj->btf, nt->name_off), nt->name_off);
                                return -ENOENT;
                        }

The output is as follows:

  libbpf: failed to find symbol for variable 'bpf_dynptr_slice' in section '.ksyms'
  libbpf:   vi->type == 17
  libbpf:   next id 18 kind 'struct', name 'bpf_nf_ctx' off 1

This matches your analysis and hits the unlikely situation when
name_off of the next type is 1.