From: Jiri Olsa <jolsa@redhat.com>
To: Jiri Slaby <jirislaby@kernel.org>
Cc: "Michal Suchánek" <msuchanek@suse.de>,
"Yonghong Song" <yhs@fb.com>,
linux-kernel@vger.kernel.org, "Martin KaFai Lau" <kafai@fb.com>,
"David S. Miller" <davem@davemloft.net>,
"Hideaki YOSHIFUJI" <yoshfuji@linux-ipv6.org>,
"David Ahern" <dsahern@kernel.org>,
"Jakub Kicinski" <kuba@kernel.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Song Liu" <songliubraving@fb.com>,
"John Fastabend" <john.fastabend@gmail.com>,
"KP Singh" <kpsingh@kernel.org>,
netdev@vger.kernel.org, bpf@vger.kernel.org,
"Jiri Olsa" <jolsa@kernel.org>,
"Jesper Dangaard Brouer" <brouer@redhat.com>,
dwarves@vger.kernel.org,
"Arnaldo Carvalho de Melo" <acme@redhat.com>
Subject: Re: linux-next failing build due to missing cubictcp_state symbol
Date: Mon, 3 May 2021 12:08:02 +0200 [thread overview]
Message-ID: <YI/LgjLxo9VCN/d+@krava> (raw)
In-Reply-To: <cbaf50c3-c85d-9239-0b37-c88e8cbed8c8@kernel.org>
On Mon, May 03, 2021 at 10:59:44AM +0200, Jiri Slaby wrote:
> CCing pahole people.
>
> On 03. 05. 21, 9:59, Jiri Slaby wrote:
> > On 03. 05. 21, 8:11, Jiri Slaby wrote:
> > > > > > > > looks like vfs_truncate did not get into BTF data,
> > > > > > > > I'll try to reproduce
> > > >
> > > > _None_ of the functions are generated by pahole -J from
> > > > debuginfo on ppc64. debuginfo appears to be correct. Neither
> > > > pahole -J fs/open.o works correctly. collect_functions in
> > > > dwarves seems to be defunct on ppc64... "functions" array is
> > > > bogus (so find_function -- the bsearch -- fails).
> > >
> > > It's not that bogus. I forgot an asterisk:
> > > > #0 find_function (btfe=0x100269f80, name=0x10024631c
> > > > "stream_open") at
> > > > /usr/src/debug/dwarves-1.21-1.1.ppc64/btf_encoder.c:350
> > > > (gdb) p (*functions)@84
> > > > $5 = {{name = 0x7ffff68e0922 ".__se_compat_sys_ftruncate", addr
> > > > = 75232, size = 72, sh_addr = 65536, generated = false}, {
> > > > name = 0x7ffff68e019e ".__se_compat_sys_open", addr = 80592,
> > > > size = 216, sh_addr = 65536, generated = false}, {
> > > > name = 0x7ffff68e0076 ".__se_compat_sys_openat", addr =
> > > > 80816, size = 232, sh_addr = 65536, generated = false}, {
> > > > name = 0x7ffff68e0908 ".__se_compat_sys_truncate", addr =
> > > > 74304, size = 100, sh_addr = 65536, generated = false}, {
> > > ...
> > > > name = 0x7ffff68e0808 ".stream_open", addr = 65824, size =
> > > > 72, sh_addr = 65536, generated = false}, {
> > > ...
> > > > name = 0x7ffff68e0751 ".vfs_truncate", addr = 73392, size =
> > > > 544, sh_addr = 65536, generated = false}}
> > >
> > > The dot makes the difference, of course. The question is why is it
> > > there? I keep looking into it. Only if someone has an immediate
> > > idea...
> >
> > Well, .vfs_truncate is in .text (and contains an ._mcount call). And
> > vfs_truncate is in .opd (w/o an ._mcount call). Since setup_functions
> > excludes all functions without the ._mcount call, is_ftrace_func later
> > returns false for such functions and they are filtered before the BTF
> > processing.
> >
> > Technically, get_vmlinux_addrs looks at a list of functions between
> > __start_mcount_loc and __stop_mcount_loc and considers only the listed.
> >
> > I don't know what the correct fix is (exclude .opd functions from the
> > filter?). Neither why cross compiler doesn't fail, nor why ebi v2 avoids
> > this too.
>
> Attaching a patch for pahole which fixes the issue, but I have no idea
> whether it is the right fix at all.
hi,
we're considering to disable ftrace filter completely,
I guess that would solve this issue for ppc as well
https://lore.kernel.org/bpf/20210501001653.x3b4rk4vk4iqv3n7@kafai-mbp.dhcp.thefacebook.com/
jirka
>
> > regards,--
> js
> suse labs
> From: Jiri Slaby <jslaby@suse.cz>
> Subject: ppc64: .opd section fix
> Patch-mainline: submitted 2021/05/03
>
> Functions in the .opd section should be considered valid too. Otherwise,
> pahole cannot produce a .BTF section from vmlinux and kernel build
> fails on ppc64.
> ---
> btf_encoder.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> --- a/btf_encoder.c
> +++ b/btf_encoder.c
> @@ -31,6 +31,8 @@ struct funcs_layout {
> unsigned long mcount_start;
> unsigned long mcount_stop;
> unsigned long mcount_sec_idx;
> + unsigned long opd_start;
> + unsigned long opd_stop;
> };
>
> struct elf_function {
> @@ -271,11 +273,24 @@ static int is_ftrace_func(struct elf_fun
> return start <= addrs[r] && addrs[r] < end;
> }
>
> +static int is_opd_func(struct elf_function *func, struct funcs_layout *fl)
> +{
> + return fl->opd_start <= func->addr && func->addr < fl->opd_stop;
> +}
> +
> static int setup_functions(struct btf_elf *btfe, struct funcs_layout *fl)
> {
> __u64 *addrs, count, i;
> int functions_valid = 0;
> bool kmod = false;
> + GElf_Shdr shdr;
> + Elf_Scn *sec;
> +
> + sec = elf_section_by_name(btfe->elf, &btfe->ehdr, &shdr, ".opd", NULL);
> + if (sec) {
> + fl->opd_start = shdr.sh_addr;
> + fl->opd_stop = shdr.sh_addr + shdr.sh_size;
> + }
>
> /*
> * Check if we are processing vmlinux image and
> @@ -322,7 +337,8 @@ static int setup_functions(struct btf_el
> func->addr += func->sh_addr;
>
> /* Make sure function is within ftrace addresses. */
> - if (is_ftrace_func(func, addrs, count)) {
> + if (is_opd_func(func, fl) ||
> + is_ftrace_func(func, addrs, count)) {
> /*
> * We iterate over sorted array, so we can easily skip
> * not valid item and move following valid field into
next prev parent reply other threads:[~2021-05-03 10:08 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-23 13:05 linux-next failing build due to missing cubictcp_state symbol Michal Suchánek
2021-04-23 14:41 ` Yonghong Song
2021-04-23 17:55 ` Michal Suchánek
2021-04-25 11:15 ` Michal Suchánek
2021-04-26 11:32 ` Michal Suchánek
2021-04-26 12:12 ` Michal Suchánek
2021-04-26 12:14 ` Michal Suchánek
2021-04-26 15:41 ` Yonghong Song
2021-04-26 16:03 ` Jiri Olsa
2021-04-26 19:16 ` Jiri Olsa
2021-04-27 12:12 ` Michal Suchánek
2021-04-30 17:47 ` Michal Suchánek
2021-04-30 18:26 ` Michal Suchánek
2021-05-01 6:45 ` Jiri Slaby
2021-05-01 10:54 ` Michal Suchánek
2021-05-03 6:11 ` Jiri Slaby
2021-05-03 7:13 ` Michal Suchánek
2021-05-03 7:59 ` Jiri Slaby
2021-05-03 8:59 ` Jiri Slaby
2021-05-03 10:08 ` Jiri Olsa [this message]
2021-05-03 16:46 ` Michal Suchánek
2021-05-03 16:58 ` Michal Suchánek
2021-05-04 6:41 ` Jiri Slaby
2021-05-06 5:31 ` Martin KaFai Lau
2021-05-06 13:16 ` Jiri Olsa
2021-05-07 7:10 ` Florian Weimer
2021-05-05 13:56 ` Michal Suchánek
2021-05-06 4:31 ` Jiri Slaby
2021-05-06 5:20 ` Martin KaFai Lau
2021-05-06 5:54 ` Jiri Slaby
2021-05-06 8:19 ` Michal Suchánek
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=YI/LgjLxo9VCN/d+@krava \
--to=jolsa@redhat.com \
--cc=acme@redhat.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=dwarves@vger.kernel.org \
--cc=jirislaby@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kafai@fb.com \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=msuchanek@suse.de \
--cc=netdev@vger.kernel.org \
--cc=songliubraving@fb.com \
--cc=yhs@fb.com \
--cc=yoshfuji@linux-ipv6.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.