From: Martin KaFai Lau <firstname.lastname@example.org>
To: "Nathan Chancellor" <email@example.com>,
"Jiri Slaby" <firstname.lastname@example.org>,
"Jiri Olsa" <email@example.com>,
"Michal Suchánek" <firstname.lastname@example.org>
Arnaldo Carvalho de Melo <email@example.com>,
Andrii Nakryiko <firstname.lastname@example.org>, <email@example.com>,
Subject: Re: [PATCH v2 dwarves] btf: Remove ftrace filter
Date: Fri, 7 May 2021 22:03:21 -0700 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On Thu, May 06, 2021 at 07:54:37PM -0700, Nathan Chancellor wrote:
> On Thu, May 06, 2021 at 01:56:22PM -0700, Martin KaFai Lau wrote:
> > BTF is currently generated for functions that are in ftrace list
> > or extern.
> > A recent use case also needs BTF generated for functions included in
> > allowlist. In particular, the kernel
> > commit e78aea8b2170 ("bpf: tcp: Put some tcp cong functions in allowlist for bpf-tcp-cc")
> > allows bpf program to directly call a few tcp cc kernel functions. Those
> > kernel functions are currently allowed only if CONFIG_DYNAMIC_FTRACE
> > is set to ensure they are in the ftrace list but this kconfig dependency
> > is unnecessary.
> > Those kernel functions are specified under an ELF section .BTF_ids.
> > There was an earlier attempt  to add another filter for the functions in
> > the .BTF_ids section. That discussion concluded that the ftrace filter
> > should be removed instead.
> > This patch is to remove the ftrace filter and its related functions.
> > Number of BTF FUNC with and without is_ftrace_func():
> > My kconfig in x86: 40643 vs 46225
> > Jiri reported on arm: 25022 vs 55812
> > : https://email@example.com/
> > Cc: Andrii Nakryiko <firstname.lastname@example.org>
> > Cc: Jiri Olsa <email@example.com>
> > Signed-off-by: Martin KaFai Lau <firstname.lastname@example.org>
> This fixes an issue with Fedora's s390x config that CKI noticed:
> Tested-by: Nathan Chancellor <email@example.com> # build
Thanks all for reviewing and testing.
In my cross compile ppc64 test, it does not solve the issue.
The problem is the tcp-cc functions (e.g. "cublictcp_*")
are not STT_FUNC in ppc64, so they are not collected in collect_function().
The ".cubictcp_*" is STT_FUNC though.
Since only the x86 (64 and 32) bpf jit can call these tcp-cc functions now
and there is no usage for adding them to .BTF_ids for other ARCHs,
I have post a patch to limit them to x86:
Can you try the above kernel patch without pahole change?
(i.e. use pahole 1.21 as-is). With the above kernel patch
and pahole 1.21, I have cross compiled arm64, ppc64, s390, and sparc64.
[ p.s. vfs_truncate should work as is in ppc64 since functions_cnt
should be 0 in ppc64 and then it will rely on fn->external. ]
next prev parent reply other threads:[~2021-05-08 5:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-06 20:56 [PATCH v2 dwarves] btf: Remove ftrace filter Martin KaFai Lau
2021-05-07 2:54 ` Nathan Chancellor
2021-05-08 5:03 ` Martin KaFai Lau [this message]
2021-05-08 10:53 ` Michal Suchánek
2021-05-10 18:00 ` Martin KaFai Lau
2021-05-10 18:08 ` Michal Suchánek
2021-05-07 6:05 ` Jiri Slaby
2021-05-07 10:39 ` Jiri Olsa
2021-05-08 14:41 ` Arnaldo Carvalho de Melo
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.