BPF List
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Tony Ambardar <tony.ambardar@gmail.com>
Cc: Jiri Olsa <olsajiri@gmail.com>,
	Hengqi Chen <hengqi.chen@gmail.com>,
	bpf@vger.kernel.org, dwarves@vger.kernel.org,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>
Subject: Re: Problem with BTF generation on mips64el
Date: Mon, 3 Jun 2024 11:18:51 +0200	[thread overview]
Message-ID: <Zl2Ke7K2CAT2cAPa@krava> (raw)
In-Reply-To: <Zl2GtXy7+Xfr66lX@kodidev-ubuntu>

On Mon, Jun 03, 2024 at 02:02:45AM -0700, Tony Ambardar wrote:
> On Fri, May 31, 2024 at 04:21:48PM +0200, Jiri Olsa wrote:
> > On Fri, May 31, 2024 at 04:36:48AM -0700, Tony Ambardar wrote:
> > > Hi Jiri,
> > > 
> > > On Fri, May 31, 2024 at 10:13:21AM +0200, Jiri Olsa wrote:
> > > > On Fri, May 31, 2024 at 10:17:53AM +0800, Hengqi Chen wrote:
> > > > > Hi Tony,
> > > > > 
> > > > > On Fri, May 31, 2024 at 9:30 AM Tony Ambardar <tony.ambardar@gmail.com> wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > For some time now I'm seeing multiple issues during BTF generation while
> > > > > > building recent kernels targeting mips64el, and would appreciate some help
> > > > > > to understand and fix the problems.
> > > > > >
> > > > > > Some relate to resolve_btfids:
> > > > > >
> > > > > > >   LD      vmlinux
> > > > > > >   BTFIDS  vmlinux
> > > > > > > WARN: resolve_btfids: unresolved symbol bpf_verify_pkcs7_signature
> > > > > > > WARN: resolve_btfids: unresolved symbol bpf_session_cookie
> > > > > > > WARN: resolve_btfids: unresolved symbol bpf_lookup_user_key
> > > > > > > WARN: resolve_btfids: unresolved symbol bpf_lookup_system_key
> > > > > > > WARN: resolve_btfids: unresolved symbol bpf_key_put
> > > > > > > WARN: resolve_btfids: unresolved symbol bpf_iter_task_next
> > > > > > > WARN: resolve_btfids: unresolved symbol bpf_iter_css_task_new
> > > > > > > WARN: resolve_btfids: unresolved symbol bpf_get_file_xattr
> > > > > > > WARN: resolve_btfids: unresolved symbol bpf_ct_insert_entry
> > > > > > > WARN: resolve_btfids: unresolved symbol bpf_cgroup_release
> > > > > > > WARN: resolve_btfids: unresolved symbol bpf_cgroup_from_id
> > > > > > > WARN: resolve_btfids: unresolved symbol bpf_cgroup_acquire
> > > > > > > WARN: resolve_btfids: unresolved symbol bpf_arena_free_pages
> > > > > > >   NM      System.map
> > > > > > >   SORTTAB vmlinux
> > > > > > >   OBJCOPY vmlinux.32
> > > > > >
> > > > > > These do not appear to be #ifdef-related and have similar past reports [1].
> > > > 
> > > > I can reproduce the warning just for bpf_session_cookie,
> > > > which has fix in progress:
> > > >   https://lore.kernel.org/bpf/20240531071557.MvfIqkn7@linutronix.de/T/#t
> > > 
> > > I gather there are different root causes for these warnings. From the link,
> > > the issue with bpf_session_cookie seems related to conditional compilation,
> > > which have come up before on the mailing list IIRC.
> > > 
> > > In comparison, consider my above warning for bpf_key_put, which is defined
> > > in kernel/trace/bpf_trace.c. This kfunc is guarded by CONFIG_KEY, which is
> > > enabled in my config and so not the issue. I can in fact see the global
> > > text symbol for bpf_key_put in bpf_trace.o, but not in vmlinux.
> > 
> > yes, that would be a problem, the resolve_btfids goes through the BTF
> > lists and needs to resolve the function in vmlinux, when it's not there,
> > it will output the warning above
> > 
> > > 
> > > So I suspect the warnings might come from linker or optimization problems,
> > > or perhaps even an issue related to the __bpf_kfunc annotation. WDYT?
> > 
> > I can reproduce now resolve_btfids warnings:
> > 
> 
> That's great to hear! Did you also use mips64el? And were you able to see

nope, just mips64, couldn't find mips64el on fedora

> the various "die__proc:" errors from pahole during BTF generation?

yep, I can see them as well

> 
> >   LD      vmlinux
> >   BTFIDS  vmlinux
> > WARN: resolve_btfids: unresolved symbol bpf_verify_pkcs7_signature
> > WARN: resolve_btfids: unresolved symbol bpf_session_is_return
> > WARN: resolve_btfids: unresolved symbol bpf_session_cookie
> > WARN: resolve_btfids: unresolved symbol bpf_lookup_user_key
> > WARN: resolve_btfids: unresolved symbol bpf_lookup_system_key
> > WARN: resolve_btfids: unresolved symbol bpf_key_put
> > WARN: resolve_btfids: unresolved symbol bpf_iter_task_next
> > WARN: resolve_btfids: unresolved symbol bpf_iter_css_task_new
> > WARN: resolve_btfids: unresolved symbol bpf_get_file_xattr
> > WARN: resolve_btfids: unresolved symbol bpf_ct_insert_entry
> > WARN: resolve_btfids: unresolved symbol bpf_cgroup_release
> > WARN: resolve_btfids: unresolved symbol bpf_cgroup_from_id
> > WARN: resolve_btfids: unresolved symbol bpf_cgroup_acquire
> > WARN: resolve_btfids: unresolved symbol bpf_arena_free_pages
> > 
> > when I call bpf_key_put to make it 'used' it stays in vmlinux, so I wonder
> > the __bpf_kfunc flags do not work properly on this cross compile chain..
> > and linker just optimize it away?
> 
> Yes, I verified the problem occurs during link-time garbage cleaning, when
> LTO is enabled through e.g. LD_DEAD_CODE_DATA_ELIMINATION=y.
> 
> > 
> > #define __bpf_kfunc __used noinline
> > 
> 
> After researching, I believe this isn't a mips problem specifically, rather
> the __bpf_kfunc tag only partly works. It appears the __used macro works at
> the compiler and IR-level but is ignored by the linker. I have a working
> fix that also handles the linker level, so I'll post the patches shortly.

great, I was wondering how to fix that

thanks,
jirka

> 
> Unfortunately, that still leaves the pahole errors generating BTF, which
> are serious as they seem to break module loading.
> 
> > thanks,
> > jirka
> 
> Cheers,
> Tony
> > 
> > > 
> > > > 
> > > > > >
> > > > > > I also see many pahole failures during BTF encoding of modules, such as:
> > > > > >
> > > > > > >   CC [M]  net/ipv6/netfilter/nft_fib_ipv6.mod.o
> > > > > > >   CC [M]  net/ipv6/netfilter/ip6t_REJECT.mod.o
> > > > > > >   CC [M]  net/psample/psample.mod.o
> > > > > > >   LD [M]  crypto/cmac.ko
> > > > > > >   BTF [M] crypto/cmac.ko
> > > > > > > die__process: DW_TAG_compile_unit, DW_TAG_type_unit, DW_TAG_partial_unit
> > > > > > > or DW_TAG_skeleton_unit expected got member (0xd)!
> > > > > 
> > > > > The issue seems to be related to elfutils. Have you tried build from
> > > > > the latest elfutils source ?
> > > > > I saw the latest MIPS backend in elfutils already implemented the
> > > > > reloc_simple_type hook.
> > > > 
> > > > hi,
> > > > +1, could you also check the pahole version you used?
> > > 
> > > No luck I'm afraid with using the latest elfutils as suggested.
> > > 
> > > I used pahole v1.26 in my original testing for this bug report, as noted
> > > below (might have been buried a bit).
> > > 
> > > > 
> > > > jirka
> > > > 
> > > > SNIP
> > > >
> > > > > > Details of the git commit and build environment are as follows:
> > > > > >
> > > > > > > $ git log -1 --oneline  bpf/master
> > > > > > > 9dfdb706e164 (bpf/master) selftests/bpf: fix inet_csk_accept prototype in
> > > > > > > test_sk_storage_tracing.c
> > > > > > >
> > > > > > > $ lsb_release -a
> > > > > > > Description:    Ubuntu 22.04.4 LTS
> > > > > > >
> > > > > > > $ cat gcc-compile.txt
> > > > > > > ARCH=mips CROSS_COMPILE=mips64el-linux-gnuabi64- CC="ccache ${CROSS_COMPILE}gcc" make -j6
> > > > > > >
> > > > > > > $ mips64el-linux-gnuabi64-gcc --version
> > > > > > > mips64el-linux-gnuabi64-gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0
> > > > > > >
> > > > > > > $ mips64el-linux-gnuabi64-ld --version
> > > > > > > GNU ld (GNU Binutils for Ubuntu) 2.38
> > > > > > >
> > > > > > > $ pahole --version
> > > > > > > v1.26
> > > > 
> > > > SNIP
> > > >
> > > > > > I'd be grateful if some of the BTF/pahole experts could please review this
> > > > > > issue and share next steps or other details I might provide.
> > > > > >
> > > > > > Thanks,
> > > > > > Tony Ambardar
> > > > > >
> > > > > > Link: https://lore.kernel.org/all/202401211357.OCX9yllM-lkp@intel.com/ [1]
> > > > > > Link: https://github.com/acmel/dwarves/issues/45 [2]
> > > > > 
> > > > > Cheers,
> > > > > Hengqi
> > > 
> > > Thanks,
> > > Tony

  reply	other threads:[~2024-06-03  9:19 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-31  1:30 Problem with BTF generation on mips64el Tony Ambardar
2024-05-31  2:17 ` Hengqi Chen
2024-05-31  8:13   ` Jiri Olsa
2024-05-31 11:36     ` Tony Ambardar
2024-05-31 14:21       ` Jiri Olsa
2024-06-03  9:02         ` Tony Ambardar
2024-06-03  9:18           ` Jiri Olsa [this message]
2024-06-03 12:16           ` [PATCH bpf v1 0/2] bpf: Fix linker optimization removing kfuncs Tony Ambardar
2024-06-03 12:16             ` [PATCH bpf v1 1/2] Compiler Attributes: Add __retain macro Tony Ambardar
2024-06-03 13:57               ` Miguel Ojeda
2024-06-04  2:37                 ` Tony Ambardar
2024-06-03 12:16             ` [PATCH bpf v1 2/2] bpf: Harden __bpf_kfunc tag against linker kfunc removal Tony Ambardar
2024-06-04  5:23             ` [PATCH bpf v2 0/2] bpf: Fix linker optimization removing kfuncs Tony Ambardar
2024-06-04  5:23               ` [PATCH bpf v2 1/2] compiler_types.h: Define __retain for __attribute__((__retain__)) Tony Ambardar
2024-06-05  5:55                 ` Yonghong Song
2024-06-10 22:56                   ` Tony Ambardar
2024-06-14 18:47                     ` Yonghong Song
2024-06-15  6:57                       ` Tony Ambardar
2024-06-17  3:26                         ` Yonghong Song
2024-06-04  5:23               ` [PATCH bpf v2 2/2] bpf: Harden __bpf_kfunc tag against linker kfunc removal Tony Ambardar
2024-06-04  7:56                 ` Jiri Olsa
2024-06-25 10:46                 ` Geert Uytterhoeven
2024-06-26  9:52                   ` Jiri Olsa
2024-06-26 11:40                     ` Geert Uytterhoeven
2024-06-14 17:20               ` [PATCH bpf v2 0/2] bpf: Fix linker optimization removing kfuncs patchwork-bot+netdevbpf
2024-05-31 10:49   ` Problem with BTF generation on mips64el Tony Ambardar
2024-05-31 16:06     ` Arnaldo Carvalho de Melo
2024-05-31 21:46       ` Tony Ambardar
2024-06-03 11:20       ` Tony Ambardar
2024-06-03 14:56         ` Arnaldo Carvalho de Melo
2024-06-03 17:40           ` elfutils DWARF problem was: " Arnaldo Carvalho de Melo
2024-06-03 19:18             ` Mark Wielaard
2024-06-04  3:47               ` Tony Ambardar
2024-06-04  8:27                 ` Ying Huang
2024-06-11  6:36                 ` Tony Ambardar
2024-06-11  7:51                   ` Tony Ambardar
2024-06-11 13:07                   ` Mark Wielaard
2024-06-12  0:18                     ` Tony Ambardar
2024-06-12  3:31                     ` Ying Huang
2024-06-12  2:39                   ` Ying Huang

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=Zl2Ke7K2CAT2cAPa@krava \
    --to=olsajiri@gmail.com \
    --cc=acme@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dwarves@vger.kernel.org \
    --cc=hengqi.chen@gmail.com \
    --cc=tony.ambardar@gmail.com \
    /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