BPF List
 help / color / mirror / Atom feed
From: Alan Maguire <alan.maguire@oracle.com>
To: Donglin Peng <dolinux.peng@gmail.com>, ast@kernel.org
Cc: daniel@iogearbox.net, song@kernel.org, andrii@kernel.org,
	eddyz87@gmail.com, haoluo@google.com, yonghong.song@linux.dev,
	bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] libbpf: checking the btf_type kind when fixing variable offsets
Date: Mon, 17 Jun 2024 12:29:46 +0100	[thread overview]
Message-ID: <0c0ef20c-c05e-4db9-bad7-2cbc0d6dfae7@oracle.com> (raw)
In-Reply-To: <20240616002958.2095829-1-dolinux.peng@gmail.com>

On 16/06/2024 01:29, Donglin Peng wrote:
> I encountered an issue when building the test_progs using the repository[1]:
> 
> $ clang --version
> Ubuntu clang version 17.0.6 (++20231208085846+6009708b4367-1~exp1~20231208085949.74)
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
> 
> $ pwd
> /work/Qemu/x86_64/linux-6.10-rc2/tools/testing/selftests/bpf/
> 
> $ make test_progs V=1
> ...
> /work/Qemu/x86_64/linux-6.10-rc2/tools/testing/selftests/bpf/tools/sbin/bpftool
> gen object
> /work/Qemu/x86_64/linux-6.10-rc2/tools/testing/selftests/bpf/ip_check_defrag.bpf.linked2.o
> /work/Qemu/x86_64/linux-6.10-rc2/tools/testing/selftests/bpf/ip_check_defrag.bpf.linked1.o
> libbpf: failed to find symbol for variable 'bpf_dynptr_slice' in section
> '.ksyms'
> Error: failed to link
> '/work/Qemu/x86_64/linux-6.10-rc2/tools/testing/selftests/bpf/ip_check_defrag.bpf.linked1.o':
> No such file or directory (2)
> make: *** [Makefile:656:
> /work/Qemu/x86_64/linux-6.10-rc2/tools/testing/selftests/bpf/ip_check_defrag.skel.h]
> Error 254
> 
> After investigation, I found that the btf_types in the '.ksyms' section have a kind of
> BTF_KIND_FUNC instead of BTF_KIND_VAR:
> 
> $ bpftool btf dump file ./ip_check_defrag.bpf.linked1.o
> ...
> [2] DATASEC '.ksyms' size=0 vlen=2
>         type_id=16 offset=0 size=0 (FUNC 'bpf_dynptr_from_skb')
>         type_id=17 offset=0 size=0 (FUNC 'bpf_dynptr_slice')
> ...
> [16] FUNC 'bpf_dynptr_from_skb' type_id=82 linkage=extern
> [17] FUNC 'bpf_dynptr_slice' type_id=85 linkage=extern
> ...
> 
> To fix this, we can a add check for the kind.
> 
> [1] https://github.com/eddyz87/bpf/tree/binsort-btf-dedup
> Link: https://lore.kernel.org/all/4f551dc5fc792936ca364ce8324c0adea38162f1.camel@gmail.com/
> 

The fix makes sense; what I was trying to figure out is why we're only
seeing this now with the above repo.

So as I understand it, the reason the kfuncs end up in the .ksyms
section is due to the "__weak __ksym" tagging recently added to
vmlinux.h construction from BTF via

770abbb5a25a ("bpftool: Support dumping kfunc prototypes from BTF")

We see as noted

[112] DATASEC '.ksyms' size=0 vlen=2
	type_id=84 offset=0 size=0 (FUNC 'bpf_dynptr_from_skb')
	type_id=90 offset=0 size=0 (FUNC 'bpf_dynptr_slice')

So that makes sense, but prior to the above series, we also tagged
kfuncs in this way before via bpf_kfuncs.h. So there should be no
difference there.

And with an upstream kernel I don't run into this problem.
	
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.

> Fixes: 8fd27bf69b86 ("libbpf: Add BPF static linker BTF and BTF.ext support")
> Signed-off-by: Donglin Peng <dolinux.peng@gmail.com>

A few small things below, but

Reviewed-by: Alan Maguire <alan.maguire@oracle.com>

> ---
>  tools/lib/bpf/linker.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/lib/bpf/linker.c b/tools/lib/bpf/linker.c
> index 0d4be829551b..7f5fc9ac4ad6 100644
> --- a/tools/lib/bpf/linker.c
> +++ b/tools/lib/bpf/linker.c
> @@ -2213,10 +2213,17 @@ static int linker_fixup_btf(struct src_obj *obj)
>  		vi = btf_var_secinfos(t);
>  		for (j = 0, m = btf_vlen(t); j < m; j++, vi++) {
>  			const struct btf_type *vt = btf__type_by_id(obj->btf, vi->type);
> -			const char *var_name = btf__str_by_offset(obj->btf, vt->name_off);
> -			int var_linkage = btf_var(vt)->linkage;
> +			const char *var_name;
> +			int var_linkage;
>  			Elf64_Sym *sym;
>  
> +			/* should be a variable */
> +			if (btf_kind(vt) != BTF_KIND_VAR)

nit: could use if (!btf_is_var(vt)) here instead. It might also be worth
reworking the comment to acknowledge that we can legitimately have a
function in this section; i.e. something like
			
			/* could be a variable or function */

We handle the func case elsewhere in libbpf (see add_dummy_ksym_var()).


> +				continue;
> + 
> +			var_name = btf__str_by_offset(obj->btf, vt->name_off);
> +			var_linkage = btf_var(vt)->linkage;
> +
>  			/* no need to patch up static or extern vars */
>  			if (var_linkage != BTF_VAR_GLOBAL_ALLOCATED)
>  				continue;

  reply	other threads:[~2024-06-17 11:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-16  0:29 [PATCH] libbpf: checking the btf_type kind when fixing variable offsets Donglin Peng
2024-06-17 11:29 ` Alan Maguire [this message]
2024-06-17 20:00   ` Eduard Zingerman
2024-06-17 20:51   ` Andrii Nakryiko
2024-06-19  5:02   ` Donglin Peng
2024-06-17 18:12 ` Eduard Zingerman
2024-06-19  5:03   ` Donglin Peng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0c0ef20c-c05e-4db9-bad7-2cbc0d6dfae7@oracle.com \
    --to=alan.maguire@oracle.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dolinux.peng@gmail.com \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox