[PATCH bpf-next] libbpf: work around kernel inconsistently stripping '.llvm.' suffix

[PATCH bpf-next] libbpf: work around kernel inconsistently stripping '.llvm.' suffix

[Andrii Nakryiko]

Some versions of kernel were stripping out '.llvm.<hash>' suffix from
kerne symbols (produced by Clang LTO compilation) from function names
reported in available_filter_functions, while kallsyms reported full
original name. This confuses libbpf's multi-kprobe logic of finding all
matching kernel functions for specified user glob pattern by joining
available_filter_functions and kallsyms contents, because joining by
full symbol name won't work for symbols containing '.llvm.<hash>' suffix.

This was eventually fixed by [0] in the kernel, but we'd like to not
regress multi-kprobe experience and add a work around for this bug on
libbpf side, stripping kallsym's name if it matches user pattern and
contains '.llvm.' suffix.

  [0] fb6a421fb615 ("kallsyms: Match symbols exactly with CONFIG_LTO_CLANG")

Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
---
 tools/lib/bpf/libbpf.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 6c262d0152f8..194809da5172 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -11387,9 +11387,33 @@ static int avail_kallsyms_cb(unsigned long long sym_addr, char sym_type,
 	struct kprobe_multi_resolve *res = data->res;
 	int err;
 
-	if (!bsearch(&sym_name, data->syms, data->cnt, sizeof(*data->syms), avail_func_cmp))
+	if (!glob_match(sym_name, res->pattern))
 		return 0;
 
+	if (!bsearch(&sym_name, data->syms, data->cnt, sizeof(*data->syms), avail_func_cmp)) {
+		/* Some versions of kernel strip out .llvm.<hash> suffix from
+		 * function names reported in available_filter_functions, but
+		 * don't do so for kallsyms. While this is clearly a kernel
+		 * bug (fixed by [0]) we try to accommodate that in libbpf to
+		 * make multi-kprobe usability a bit better: if no match is
+		 * found, we will strip .llvm. suffix and try one more time.
+		 *
+		 *   [0] fb6a421fb615 ("kallsyms: Match symbols exactly with CONFIG_LTO_CLANG")
+		 */
+		char sym_trim[256], *psym_trim = sym_trim, *sym_sfx;
+
+		if (!(sym_sfx = strstr(sym_name, ".llvm.")))
+			return 0;
+
+		/* psym_trim vs sym_trim dance is done to avoid pointer vs array
+		 * coercion differences and get proper `const char **` pointer
+		 * which avail_func_cmp() expects
+		 */
+		snprintf(sym_trim, sizeof(sym_trim), "%.*s", (int)(sym_sfx - sym_name), sym_name);
+		if (!bsearch(&psym_trim, data->syms, data->cnt, sizeof(*data->syms), avail_func_cmp))
+			return 0;
+	}
+
 	err = libbpf_ensure_mem((void **)&res->addrs, &res->cap, sizeof(*res->addrs), res->cnt + 1);
 	if (err)
 		return err;
-- 
2.43.5

Re: [PATCH bpf-next] libbpf: work around kernel inconsistently stripping '.llvm.' suffix

[Yonghong Song]

On 1/16/25 4:39 PM, Andrii Nakryiko wrote:
> Some versions of kernel were stripping out '.llvm.<hash>' suffix from
> kerne symbols (produced by Clang LTO compilation) from function names
> reported in available_filter_functions, while kallsyms reported full
> original name. This confuses libbpf's multi-kprobe logic of finding all
> matching kernel functions for specified user glob pattern by joining
> available_filter_functions and kallsyms contents, because joining by
> full symbol name won't work for symbols containing '.llvm.<hash>' suffix.
>
> This was eventually fixed by [0] in the kernel, but we'd like to not
> regress multi-kprobe experience and add a work around for this bug on
> libbpf side, stripping kallsym's name if it matches user pattern and
> contains '.llvm.' suffix.
>
>    [0] fb6a421fb615 ("kallsyms: Match symbols exactly with CONFIG_LTO_CLANG")
>
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>

The fix LGTM.

Acked-by: Yonghong Song <yonghong.song@linux.dev>

Re: [PATCH bpf-next] libbpf: work around kernel inconsistently stripping '.llvm.' suffix

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to bpf/bpf-next.git (master)
by Daniel Borkmann <daniel@iogearbox.net>:

On Thu, 16 Jan 2025 16:39:57 -0800 you wrote:
> Some versions of kernel were stripping out '.llvm.<hash>' suffix from
> kerne symbols (produced by Clang LTO compilation) from function names
> reported in available_filter_functions, while kallsyms reported full
> original name. This confuses libbpf's multi-kprobe logic of finding all
> matching kernel functions for specified user glob pattern by joining
> available_filter_functions and kallsyms contents, because joining by
> full symbol name won't work for symbols containing '.llvm.<hash>' suffix.
> 
> [...]

Here is the summary with links:
  - [bpf-next] libbpf: work around kernel inconsistently stripping '.llvm.' suffix
    https://git.kernel.org/bpf/bpf-next/c/f8a05692de06

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html