From: Jiri Olsa <olsajiri@gmail.com>
To: Jackie Liu <liu.yun@linux.dev>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
olsajiri@gmail.com, andrii@kernel.org, martin.lau@linux.dev,
song@kernel.org, yhs@fb.com, bpf@vger.kernel.org,
liuyun01@kylinos.cn
Subject: Re: [PATCH v4] libbpf: kprobe.multi: Filter with available_filter_functions
Date: Fri, 26 May 2023 10:58:44 +0200 [thread overview]
Message-ID: <ZHB0xNEbjmwHv18d@krava> (raw)
In-Reply-To: <b2273217-5adb-8ec6-288b-4f8703a56386@linux.dev>
On Fri, May 26, 2023 at 09:38:15AM +0800, Jackie Liu wrote:
> Hi Andrii.
>
> 在 2023/5/26 04:43, Andrii Nakryiko 写道:
> > On Thu, May 25, 2023 at 3:28 AM Jackie Liu <liu.yun@linux.dev> wrote:
> > >
> > > From: Jackie Liu <liuyun01@kylinos.cn>
> > >
> > > When using regular expression matching with "kprobe multi", it scans all
> > > the functions under "/proc/kallsyms" that can be matched. However, not all
> > > of them can be traced by kprobe.multi. If any one of the functions fails
> > > to be traced, it will result in the failure of all functions. The best
> > > approach is to filter out the functions that cannot be traced to ensure
> > > proper tracking of the functions.
> > >
> > > Use available_filter_functions check first, if failed, fallback to
> > > kallsyms.
> > >
> > > Here is the test eBPF program [1].
> > > [1] https://github.com/JackieLiu1/ketones/commit/a9e76d1ba57390e533b8b3eadde97f7a4535e867
> > >
> > > Suggested-by: Jiri Olsa <olsajiri@gmail.com>
> > > Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
> > > ---
> > > tools/lib/bpf/libbpf.c | 92 +++++++++++++++++++++++++++++++++++++-----
> > > 1 file changed, 83 insertions(+), 9 deletions(-)
> > >
> >
> > Question to you and Jiri: what happens when multi-kprobe's syms has
> > duplicates? Will the program be attached multiple times? If yes, then
> > it sounds like a problem? Both available_filters and kallsyms can have
> > duplicate function names in them, right?
>
> If I understand correctly, there should be no problem with repeated
> function registration, because the bottom layer is done through fprobe
> registration addrs, kprobe.multi itself does not do this work, but
> fprobe is based on ftrace, it will register addr by makes a hash,
> that is, if it is the same address, it should be filtered out.
it won't get through the kprobe_multi symbols resolve code, because we
check that the number of resolved addresses matches the number of
provided symbols
also found test bug (hunk#2) when checking on that (hunk#1) ;-)
jirka
---
diff --git a/tools/testing/selftests/bpf/prog_tests/kprobe_multi_test.c b/tools/testing/selftests/bpf/prog_tests/kprobe_multi_test.c
index 2173c4bb555e..e78362354bd3 100644
--- a/tools/testing/selftests/bpf/prog_tests/kprobe_multi_test.c
+++ b/tools/testing/selftests/bpf/prog_tests/kprobe_multi_test.c
@@ -124,7 +124,7 @@ static void test_link_api_syms(void)
"bpf_fentry_test5",
"bpf_fentry_test6",
"bpf_fentry_test7",
- "bpf_fentry_test8",
+ "bpf_fentry_test7",
};
opts.kprobe_multi.syms = syms;
@@ -477,9 +477,9 @@ void test_kprobe_multi_test(void)
if (test__start_subtest("skel_api"))
test_skel_api();
if (test__start_subtest("link_api_addrs"))
- test_link_api_syms();
- if (test__start_subtest("link_api_syms"))
test_link_api_addrs();
+ if (test__start_subtest("link_api_syms"))
+ test_link_api_syms();
if (test__start_subtest("attach_api_pattern"))
test_attach_api_pattern();
if (test__start_subtest("attach_api_addrs"))
next prev parent reply other threads:[~2023-05-26 8:58 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-23 13:25 [PATCH] libbpf: kprobe.multi: Filter with blacklist and available_filter_functions Jackie Liu
2023-05-23 16:17 ` Jiri Olsa
2023-05-23 18:22 ` Andrii Nakryiko
2023-05-24 7:03 ` Jiri Olsa
2023-05-24 1:03 ` Jackie Liu
2023-05-24 1:19 ` Jackie Liu
2023-05-24 6:47 ` Jiri Olsa
2023-05-24 7:06 ` Jackie Liu
2023-05-24 8:41 ` [PATCH v3] libbpf: kprobe.multi: Filter with available_filter_functions Jackie Liu
2023-05-25 8:44 ` Jiri Olsa
2023-05-25 10:27 ` [PATCH v4] " Jackie Liu
2023-05-25 20:43 ` Andrii Nakryiko
2023-05-26 1:38 ` Jackie Liu
2023-05-26 8:58 ` Jiri Olsa [this message]
2023-06-02 17:27 ` Andrii Nakryiko
2023-06-07 6:01 ` Jackie Liu
2023-06-07 22:37 ` Andrii Nakryiko
2023-06-07 23:22 ` Jiri Olsa
2023-06-08 0:00 ` Andrii Nakryiko
2023-06-08 0:57 ` Jackie Liu
2023-05-26 2:10 ` [PATCH v5] " Jackie Liu
2023-05-26 9:53 ` Jiri Olsa
2023-05-26 12:18 ` Jackie Liu
2023-05-24 3:44 ` [PATCH v2] " Jackie Liu
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=ZHB0xNEbjmwHv18d@krava \
--to=olsajiri@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=liu.yun@linux.dev \
--cc=liuyun01@kylinos.cn \
--cc=martin.lau@linux.dev \
--cc=song@kernel.org \
--cc=yhs@fb.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 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.