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;
next prev parent 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