| Message ID | 20230203031742.1730761-3-imagedong@tencent.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | BPF |
| Headers | show |
| Series | libbpf: allow users to set kprobe/uprobe attach mode | expand |
On Thu, Feb 2, 2023 at 7:18 PM <menglong8.dong@gmail.com> wrote: > > From: Menglong Dong <imagedong@tencent.com> > > Add the testing for kprobe/uprobe attaching in legacy and perf mode. > And the testing passed: > > ./test_progs -t attach_probe > $5 attach_probe:OK > Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED > > Signed-off-by: Menglong Dong <imagedong@tencent.com> > --- Do you mind refactoring attach_probe test into multiple subtests, where each subtest will only test one of the attach mode and type. The reason is that libbpf CI runs tests with latest selftests and libbpf against old kernels (4.9 and 5.5, currently). Due to attach_probe testing all these uprobe/kprobe attach modes with extra features (like cookie, ref count, etc), we had to disable attach_probe test in libbpf CI on old kernels. If we can split each individual uprobe/kprobe mode, that will give us flexibility to selectively allowlist those tests that don't force libbpf to use newer features (like cookies, LINK or PERF mode, etc). It would be a great improvement and highly appreciated! If you don't mind doing this, let's do the split of existing use cases into subtest in a separate patch, and then add PERF/LEGACY/LINK mode tests on top of that patch. > .../selftests/bpf/prog_tests/attach_probe.c | 61 ++++++++++++++++++- > .../selftests/bpf/progs/test_attach_probe.c | 32 ++++++++++ > 2 files changed, 92 insertions(+), 1 deletion(-) > [...]
On Tue, Feb 7, 2023 at 4:05 AM Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote: > > On Thu, Feb 2, 2023 at 7:18 PM <menglong8.dong@gmail.com> wrote: > > > > From: Menglong Dong <imagedong@tencent.com> > > > > Add the testing for kprobe/uprobe attaching in legacy and perf mode. > > And the testing passed: > > > > ./test_progs -t attach_probe > > $5 attach_probe:OK > > Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED > > > > Signed-off-by: Menglong Dong <imagedong@tencent.com> > > --- > > Do you mind refactoring attach_probe test into multiple subtests, > where each subtest will only test one of the attach mode and type. The > reason is that libbpf CI runs tests with latest selftests and libbpf > against old kernels (4.9 and 5.5, currently). Due to attach_probe > testing all these uprobe/kprobe attach modes with extra features (like > cookie, ref count, etc), we had to disable attach_probe test in libbpf > CI on old kernels. > > If we can split each individual uprobe/kprobe mode, that will give us > flexibility to selectively allowlist those tests that don't force > libbpf to use newer features (like cookies, LINK or PERF mode, etc). > > It would be a great improvement and highly appreciated! If you don't > mind doing this, let's do the split of existing use cases into subtest > in a separate patch, and then add PERF/LEGACY/LINK mode tests on top > of that patch. > Of course, with pleasure. For the existing use cases, we split it into subtests, such as: kprobe/kretprobe auto attach kprobe/kretprobe manual attach uprobe/uretprobe ref_ctr test uprobe/uretprobe auto attach sleepable kprobe/uprobe ...... Am I right? Thanks! Dongmeng Long > > > .../selftests/bpf/prog_tests/attach_probe.c | 61 ++++++++++++++++++- > > .../selftests/bpf/progs/test_attach_probe.c | 32 ++++++++++ > > 2 files changed, 92 insertions(+), 1 deletion(-) > > > > [...]
On Mon, Feb 6, 2023 at 6:39 PM Menglong Dong <menglong8.dong@gmail.com> wrote: > > On Tue, Feb 7, 2023 at 4:05 AM Andrii Nakryiko > <andrii.nakryiko@gmail.com> wrote: > > > > On Thu, Feb 2, 2023 at 7:18 PM <menglong8.dong@gmail.com> wrote: > > > > > > From: Menglong Dong <imagedong@tencent.com> > > > > > > Add the testing for kprobe/uprobe attaching in legacy and perf mode. > > > And the testing passed: > > > > > > ./test_progs -t attach_probe > > > $5 attach_probe:OK > > > Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED > > > > > > Signed-off-by: Menglong Dong <imagedong@tencent.com> > > > --- > > > > Do you mind refactoring attach_probe test into multiple subtests, > > where each subtest will only test one of the attach mode and type. The > > reason is that libbpf CI runs tests with latest selftests and libbpf > > against old kernels (4.9 and 5.5, currently). Due to attach_probe > > testing all these uprobe/kprobe attach modes with extra features (like > > cookie, ref count, etc), we had to disable attach_probe test in libbpf > > CI on old kernels. > > > > If we can split each individual uprobe/kprobe mode, that will give us > > flexibility to selectively allowlist those tests that don't force > > libbpf to use newer features (like cookies, LINK or PERF mode, etc). > > > > It would be a great improvement and highly appreciated! If you don't > > mind doing this, let's do the split of existing use cases into subtest > > in a separate patch, and then add PERF/LEGACY/LINK mode tests on top > > of that patch. > > > > Of course, with pleasure. For the existing use cases, we split it into > subtests, such as: > > kprobe/kretprobe auto attach > kprobe/kretprobe manual attach > uprobe/uretprobe ref_ctr test > uprobe/uretprobe auto attach > sleepable kprobe/uprobe > ...... > > Am I right? I haven't analysed all the different cases, but roughly it makes sense. With more granular subtests we can also drop `legacy` flag and rely on subtest allowlisting in CI. > > Thanks! > Dongmeng Long > > > > > > .../selftests/bpf/prog_tests/attach_probe.c | 61 ++++++++++++++++++- > > > .../selftests/bpf/progs/test_attach_probe.c | 32 ++++++++++ > > > 2 files changed, 92 insertions(+), 1 deletion(-) > > > > > > > [...]
On 07/02/2023 22:50, Andrii Nakryiko wrote: > On Mon, Feb 6, 2023 at 6:39 PM Menglong Dong <menglong8.dong@gmail.com> wrote: >> >> On Tue, Feb 7, 2023 at 4:05 AM Andrii Nakryiko >> <andrii.nakryiko@gmail.com> wrote: >>> >>> On Thu, Feb 2, 2023 at 7:18 PM <menglong8.dong@gmail.com> wrote: >>>> >>>> From: Menglong Dong <imagedong@tencent.com> >>>> >>>> Add the testing for kprobe/uprobe attaching in legacy and perf mode. >>>> And the testing passed: >>>> >>>> ./test_progs -t attach_probe >>>> $5 attach_probe:OK >>>> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED >>>> >>>> Signed-off-by: Menglong Dong <imagedong@tencent.com> >>>> --- >>> >>> Do you mind refactoring attach_probe test into multiple subtests, >>> where each subtest will only test one of the attach mode and type. The >>> reason is that libbpf CI runs tests with latest selftests and libbpf >>> against old kernels (4.9 and 5.5, currently). Due to attach_probe >>> testing all these uprobe/kprobe attach modes with extra features (like >>> cookie, ref count, etc), we had to disable attach_probe test in libbpf >>> CI on old kernels. >>> >>> If we can split each individual uprobe/kprobe mode, that will give us >>> flexibility to selectively allowlist those tests that don't force >>> libbpf to use newer features (like cookies, LINK or PERF mode, etc). >>> >>> It would be a great improvement and highly appreciated! If you don't >>> mind doing this, let's do the split of existing use cases into subtest >>> in a separate patch, and then add PERF/LEGACY/LINK mode tests on top >>> of that patch. >>> >> >> Of course, with pleasure. For the existing use cases, we split it into >> subtests, such as: >> >> kprobe/kretprobe auto attach >> kprobe/kretprobe manual attach >> uprobe/uretprobe ref_ctr test >> uprobe/uretprobe auto attach >> sleepable kprobe/uprobe >> ...... >> >> Am I right? > > I haven't analysed all the different cases, but roughly it makes > sense. With more granular subtests we can also drop `legacy` flag and > rely on subtest allowlisting in CI. > I'm probably rusty on the details, but when you talk about subtest splitting for the [uk]probe manual attach, are we talking about running the same manual attach test for the different modes, with each as a separate subtest, such that each registers as a distinct pass/fail (and can thus be allowlisted as appropriate)? So in other words test__start_subtest("manual_attach_kprobe_link"); attach_kprobe_manual(link_options); test__start_subtest("manual_attach_kprobe_legacy"); attach_kprobe_manual(legay_options); test__start_subtest("manual_attach_kprobe_perf"); attach_kprobe_manual(perf_options); ? >> >> Thanks! >> Dongmeng Long >> >>> >>>> .../selftests/bpf/prog_tests/attach_probe.c | 61 ++++++++++++++++++- >>>> .../selftests/bpf/progs/test_attach_probe.c | 32 ++++++++++ >>>> 2 files changed, 92 insertions(+), 1 deletion(-) >>>> >>> >>> [...]
On Wed, Feb 8, 2023 at 3:49 AM Alan Maguire <alan.maguire@oracle.com> wrote: > > On 07/02/2023 22:50, Andrii Nakryiko wrote: > > On Mon, Feb 6, 2023 at 6:39 PM Menglong Dong <menglong8.dong@gmail.com> wrote: > >> > >> On Tue, Feb 7, 2023 at 4:05 AM Andrii Nakryiko > >> <andrii.nakryiko@gmail.com> wrote: > >>> > >>> On Thu, Feb 2, 2023 at 7:18 PM <menglong8.dong@gmail.com> wrote: > >>>> > >>>> From: Menglong Dong <imagedong@tencent.com> > >>>> > >>>> Add the testing for kprobe/uprobe attaching in legacy and perf mode. > >>>> And the testing passed: > >>>> > >>>> ./test_progs -t attach_probe > >>>> $5 attach_probe:OK > >>>> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED > >>>> > >>>> Signed-off-by: Menglong Dong <imagedong@tencent.com> > >>>> --- > >>> > >>> Do you mind refactoring attach_probe test into multiple subtests, > >>> where each subtest will only test one of the attach mode and type. The > >>> reason is that libbpf CI runs tests with latest selftests and libbpf > >>> against old kernels (4.9 and 5.5, currently). Due to attach_probe > >>> testing all these uprobe/kprobe attach modes with extra features (like > >>> cookie, ref count, etc), we had to disable attach_probe test in libbpf > >>> CI on old kernels. > >>> > >>> If we can split each individual uprobe/kprobe mode, that will give us > >>> flexibility to selectively allowlist those tests that don't force > >>> libbpf to use newer features (like cookies, LINK or PERF mode, etc). > >>> > >>> It would be a great improvement and highly appreciated! If you don't > >>> mind doing this, let's do the split of existing use cases into subtest > >>> in a separate patch, and then add PERF/LEGACY/LINK mode tests on top > >>> of that patch. > >>> > >> > >> Of course, with pleasure. For the existing use cases, we split it into > >> subtests, such as: > >> > >> kprobe/kretprobe auto attach > >> kprobe/kretprobe manual attach > >> uprobe/uretprobe ref_ctr test > >> uprobe/uretprobe auto attach > >> sleepable kprobe/uprobe > >> ...... > >> > >> Am I right? > > > > I haven't analysed all the different cases, but roughly it makes > > sense. With more granular subtests we can also drop `legacy` flag and > > rely on subtest allowlisting in CI. > > > > I'm probably rusty on the details, but when you talk about subtest > splitting for the [uk]probe manual attach, are we talking about running > the same manual attach test for the different modes, with each as a > separate subtest, such that each registers as a distinct pass/fail (and > can thus be allowlisted as appropriate)? So in other words > > test__start_subtest("manual_attach_kprobe_link"); > attach_kprobe_manual(link_options); > test__start_subtest("manual_attach_kprobe_legacy"); > attach_kprobe_manual(legay_options); > test__start_subtest("manual_attach_kprobe_perf"); > attach_kprobe_manual(perf_options); > > ? Yep. One of the reasons is that on 4.9 kernel there won't be link or perf method available, so it is expected for such modes to fail. I want to be able to still test the legacy code path on 4.9, though. Similarly tests that are using ref_ctr_offset or bpf_cookie won't work on older kernels as well. Right now because of all of them being in a single test, I have to block entire test, losing coverage on older kernels. > > >> > >> Thanks! > >> Dongmeng Long > >> > >>> > >>>> .../selftests/bpf/prog_tests/attach_probe.c | 61 ++++++++++++++++++- > >>>> .../selftests/bpf/progs/test_attach_probe.c | 32 ++++++++++ > >>>> 2 files changed, 92 insertions(+), 1 deletion(-) > >>>> > >>> > >>> [...]
On Thu, Feb 9, 2023 at 7:31 AM Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote: > > On Wed, Feb 8, 2023 at 3:49 AM Alan Maguire <alan.maguire@oracle.com> wrote: > > > > On 07/02/2023 22:50, Andrii Nakryiko wrote: > > > On Mon, Feb 6, 2023 at 6:39 PM Menglong Dong <menglong8.dong@gmail.com> wrote: > > >> > > >> On Tue, Feb 7, 2023 at 4:05 AM Andrii Nakryiko > > >> <andrii.nakryiko@gmail.com> wrote: > > >>> > > >>> On Thu, Feb 2, 2023 at 7:18 PM <menglong8.dong@gmail.com> wrote: > > >>>> > > >>>> From: Menglong Dong <imagedong@tencent.com> > > >>>> > > >>>> Add the testing for kprobe/uprobe attaching in legacy and perf mode. > > >>>> And the testing passed: > > >>>> > > >>>> ./test_progs -t attach_probe > > >>>> $5 attach_probe:OK > > >>>> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED > > >>>> > > >>>> Signed-off-by: Menglong Dong <imagedong@tencent.com> > > >>>> --- > > >>> > > >>> Do you mind refactoring attach_probe test into multiple subtests, > > >>> where each subtest will only test one of the attach mode and type. The > > >>> reason is that libbpf CI runs tests with latest selftests and libbpf > > >>> against old kernels (4.9 and 5.5, currently). Due to attach_probe > > >>> testing all these uprobe/kprobe attach modes with extra features (like > > >>> cookie, ref count, etc), we had to disable attach_probe test in libbpf > > >>> CI on old kernels. > > >>> > > >>> If we can split each individual uprobe/kprobe mode, that will give us > > >>> flexibility to selectively allowlist those tests that don't force > > >>> libbpf to use newer features (like cookies, LINK or PERF mode, etc). > > >>> > > >>> It would be a great improvement and highly appreciated! If you don't > > >>> mind doing this, let's do the split of existing use cases into subtest > > >>> in a separate patch, and then add PERF/LEGACY/LINK mode tests on top > > >>> of that patch. > > >>> > > >> > > >> Of course, with pleasure. For the existing use cases, we split it into > > >> subtests, such as: > > >> > > >> kprobe/kretprobe auto attach > > >> kprobe/kretprobe manual attach > > >> uprobe/uretprobe ref_ctr test > > >> uprobe/uretprobe auto attach > > >> sleepable kprobe/uprobe > > >> ...... > > >> > > >> Am I right? > > > > > > I haven't analysed all the different cases, but roughly it makes > > > sense. With more granular subtests we can also drop `legacy` flag and > > > rely on subtest allowlisting in CI. > > > > > > > I'm probably rusty on the details, but when you talk about subtest > > splitting for the [uk]probe manual attach, are we talking about running > > the same manual attach test for the different modes, with each as a > > separate subtest, such that each registers as a distinct pass/fail (and > > can thus be allowlisted as appropriate)? So in other words > > > > test__start_subtest("manual_attach_kprobe_link"); > > attach_kprobe_manual(link_options); > > test__start_subtest("manual_attach_kprobe_legacy"); > > attach_kprobe_manual(legay_options); > > test__start_subtest("manual_attach_kprobe_perf"); > > attach_kprobe_manual(perf_options); > > > > ? > > Yep. One of the reasons is that on 4.9 kernel there won't be link or > perf method available, so it is expected for such modes to fail. I > want to be able to still test the legacy code path on 4.9, though. > Similarly tests that are using ref_ctr_offset or bpf_cookie won't work > on older kernels as well. Right now because of all of them being in a > single test, I have to block entire test, losing coverage on older > kernels. > I think I am beginning to understand it now. So we need 2 patches for the selftests part. In the 1th patch, we split the existing testings into multi subtests, such as: test__start_subtest("manual_attach_probe") // test kprobe/uprobe manual attach test__start_subtest("auto_attach_probe") // test kprobe/uprobe auto attach test__start_subtest("bpf_cookie") // test bpf_cookie test__start_subtest("ref_ctr_offset") test ref_ctr_offset test__start_subtest("sleepable_probe") // test sleepable uprobe/uretprobe, and sleepable kprobe ...... And in the 2th patch, we change the subtest "manual_attach_probe" into the following tests: test__start_subtest("manual_attach_kprobe_link"); test__start_subtest("manual_attach_kprobe_legacy"); test__start_subtest("manual_attach_kprobe_perf"); Therefore, every feature can be tested in a subtest alone. Am I right? Thanks! Menglong Dong > > > > >> > > >> Thanks! > > >> Dongmeng Long > > >> > > >>> > > >>>> .../selftests/bpf/prog_tests/attach_probe.c | 61 ++++++++++++++++++- > > >>>> .../selftests/bpf/progs/test_attach_probe.c | 32 ++++++++++ > > >>>> 2 files changed, 92 insertions(+), 1 deletion(-) > > >>>> > > >>> > > >>> [...]
On Thu, Feb 9, 2023 at 6:08 AM Menglong Dong <menglong8.dong@gmail.com> wrote: > > On Thu, Feb 9, 2023 at 7:31 AM Andrii Nakryiko > <andrii.nakryiko@gmail.com> wrote: > > > > On Wed, Feb 8, 2023 at 3:49 AM Alan Maguire <alan.maguire@oracle.com> wrote: > > > > > > On 07/02/2023 22:50, Andrii Nakryiko wrote: > > > > On Mon, Feb 6, 2023 at 6:39 PM Menglong Dong <menglong8.dong@gmail.com> wrote: > > > >> > > > >> On Tue, Feb 7, 2023 at 4:05 AM Andrii Nakryiko > > > >> <andrii.nakryiko@gmail.com> wrote: > > > >>> > > > >>> On Thu, Feb 2, 2023 at 7:18 PM <menglong8.dong@gmail.com> wrote: > > > >>>> > > > >>>> From: Menglong Dong <imagedong@tencent.com> > > > >>>> > > > >>>> Add the testing for kprobe/uprobe attaching in legacy and perf mode. > > > >>>> And the testing passed: > > > >>>> > > > >>>> ./test_progs -t attach_probe > > > >>>> $5 attach_probe:OK > > > >>>> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED > > > >>>> > > > >>>> Signed-off-by: Menglong Dong <imagedong@tencent.com> > > > >>>> --- > > > >>> > > > >>> Do you mind refactoring attach_probe test into multiple subtests, > > > >>> where each subtest will only test one of the attach mode and type. The > > > >>> reason is that libbpf CI runs tests with latest selftests and libbpf > > > >>> against old kernels (4.9 and 5.5, currently). Due to attach_probe > > > >>> testing all these uprobe/kprobe attach modes with extra features (like > > > >>> cookie, ref count, etc), we had to disable attach_probe test in libbpf > > > >>> CI on old kernels. > > > >>> > > > >>> If we can split each individual uprobe/kprobe mode, that will give us > > > >>> flexibility to selectively allowlist those tests that don't force > > > >>> libbpf to use newer features (like cookies, LINK or PERF mode, etc). > > > >>> > > > >>> It would be a great improvement and highly appreciated! If you don't > > > >>> mind doing this, let's do the split of existing use cases into subtest > > > >>> in a separate patch, and then add PERF/LEGACY/LINK mode tests on top > > > >>> of that patch. > > > >>> > > > >> > > > >> Of course, with pleasure. For the existing use cases, we split it into > > > >> subtests, such as: > > > >> > > > >> kprobe/kretprobe auto attach > > > >> kprobe/kretprobe manual attach > > > >> uprobe/uretprobe ref_ctr test > > > >> uprobe/uretprobe auto attach > > > >> sleepable kprobe/uprobe > > > >> ...... > > > >> > > > >> Am I right? > > > > > > > > I haven't analysed all the different cases, but roughly it makes > > > > sense. With more granular subtests we can also drop `legacy` flag and > > > > rely on subtest allowlisting in CI. > > > > > > > > > > I'm probably rusty on the details, but when you talk about subtest > > > splitting for the [uk]probe manual attach, are we talking about running > > > the same manual attach test for the different modes, with each as a > > > separate subtest, such that each registers as a distinct pass/fail (and > > > can thus be allowlisted as appropriate)? So in other words > > > > > > test__start_subtest("manual_attach_kprobe_link"); > > > attach_kprobe_manual(link_options); > > > test__start_subtest("manual_attach_kprobe_legacy"); > > > attach_kprobe_manual(legay_options); > > > test__start_subtest("manual_attach_kprobe_perf"); > > > attach_kprobe_manual(perf_options); > > > > > > ? > > > > Yep. One of the reasons is that on 4.9 kernel there won't be link or > > perf method available, so it is expected for such modes to fail. I > > want to be able to still test the legacy code path on 4.9, though. > > Similarly tests that are using ref_ctr_offset or bpf_cookie won't work > > on older kernels as well. Right now because of all of them being in a > > single test, I have to block entire test, losing coverage on older > > kernels. > > > > I think I am beginning to understand it now. So we need 2 patches > for the selftests part. In the 1th patch, we split the existing testings > into multi subtests, such as: > > test__start_subtest("manual_attach_probe") // test kprobe/uprobe manual attach > test__start_subtest("auto_attach_probe") // test kprobe/uprobe auto attach > test__start_subtest("bpf_cookie") // test bpf_cookie > test__start_subtest("ref_ctr_offset") test ref_ctr_offset > test__start_subtest("sleepable_probe") // test sleepable > uprobe/uretprobe, and sleepable kprobe > ...... > > And in the 2th patch, we change the subtest "manual_attach_probe" into > the following tests: > > test__start_subtest("manual_attach_kprobe_link"); > test__start_subtest("manual_attach_kprobe_legacy"); > test__start_subtest("manual_attach_kprobe_perf"); > > Therefore, every feature can be tested in a subtest alone. > > Am I right? yep, exactly! > > Thanks! > Menglong Dong > > > > > > >> > > > >> Thanks! > > > >> Dongmeng Long > > > >> > > > >>> > > > >>>> .../selftests/bpf/prog_tests/attach_probe.c | 61 ++++++++++++++++++- > > > >>>> .../selftests/bpf/progs/test_attach_probe.c | 32 ++++++++++ > > > >>>> 2 files changed, 92 insertions(+), 1 deletion(-) > > > >>>> > > > >>> > > > >>> [...]
diff --git a/tools/testing/selftests/bpf/prog_tests/attach_probe.c b/tools/testing/selftests/bpf/prog_tests/attach_probe.c index 9566d9d2f6ee..5f6212ac0b6d 100644 --- a/tools/testing/selftests/bpf/prog_tests/attach_probe.c +++ b/tools/testing/selftests/bpf/prog_tests/attach_probe.c @@ -23,15 +23,22 @@ static noinline void trigger_func3(void) asm volatile (""); } +/* attach point for legacy uprobe */ +static noinline void trigger_func4(void) +{ + asm volatile (""); +} + static char test_data[] = "test_data"; void test_attach_probe(void) { + ssize_t uprobe_offset, uprobe4_offset, ref_ctr_offset; DECLARE_LIBBPF_OPTS(bpf_uprobe_opts, uprobe_opts); struct bpf_link *kprobe_link, *kretprobe_link; struct bpf_link *uprobe_link, *uretprobe_link; + DECLARE_LIBBPF_OPTS(bpf_kprobe_opts, opts); struct test_attach_probe* skel; - ssize_t uprobe_offset, ref_ctr_offset; struct bpf_link *uprobe_err_link; bool legacy; char *mem; @@ -86,6 +93,25 @@ void test_attach_probe(void) goto cleanup; skel->links.handle_kretprobe = kretprobe_link; + /* manual-attach kprobe in legacy mode */ + opts.retprobe = false; + opts.mode = PROBE_MODE_LEGACY; + kprobe_link = bpf_program__attach_kprobe_opts(skel->progs.handle_kprobe_legacy, + SYS_NANOSLEEP_KPROBE_NAME, + &opts); + if (!ASSERT_OK_PTR(kprobe_link, "attach_kprobe_legacy")) + goto cleanup; + skel->links.handle_kprobe_legacy = kprobe_link; + + /* manual-attach kprobe in perf mode */ + opts.mode = PROBE_MODE_PERF; + kprobe_link = bpf_program__attach_kprobe_opts(skel->progs.handle_kprobe_perf, + SYS_NANOSLEEP_KPROBE_NAME, + &opts); + if (!ASSERT_OK_PTR(kprobe_link, "attach_kprobe_perf")) + goto cleanup; + skel->links.handle_kprobe_perf = kprobe_link; + /* auto-attachable kprobe and kretprobe */ skel->links.handle_kprobe_auto = bpf_program__attach(skel->progs.handle_kprobe_auto); ASSERT_OK_PTR(skel->links.handle_kprobe_auto, "attach_kprobe_auto"); @@ -110,6 +136,32 @@ void test_attach_probe(void) if (!legacy) ASSERT_GT(uprobe_ref_ctr, 0, "uprobe_ref_ctr_after"); + uprobe4_offset = get_uprobe_offset(&trigger_func4); + if (!ASSERT_GE(uprobe4_offset, 0, "uprobe4_offset")) + goto cleanup; + + uprobe_opts.mode = PROBE_MODE_LEGACY; + uprobe_opts.ref_ctr_offset = 0; + uprobe_link = bpf_program__attach_uprobe_opts(skel->progs.handle_uprobe_legacy, + 0 /* self pid */, + "/proc/self/exe", + uprobe4_offset, + &uprobe_opts); + if (!ASSERT_OK_PTR(uprobe_link, "attach_uprobe_legacy")) + goto cleanup; + skel->links.handle_uprobe_legacy = uprobe_link; + + uprobe_opts.mode = PROBE_MODE_PERF; + uprobe_opts.ref_ctr_offset = legacy ? 0 : ref_ctr_offset; + uprobe_link = bpf_program__attach_uprobe_opts(skel->progs.handle_uprobe_perf, + 0 /* self pid */, + "/proc/self/exe", + uprobe_offset, + &uprobe_opts); + if (!ASSERT_OK_PTR(uprobe_link, "attach_uprobe_perf")) + goto cleanup; + skel->links.handle_uprobe_perf = uprobe_link; + /* if uprobe uses ref_ctr, uretprobe has to use ref_ctr as well */ uprobe_opts.retprobe = true; uprobe_opts.ref_ctr_offset = legacy ? 0 : ref_ctr_offset; @@ -207,11 +259,18 @@ void test_attach_probe(void) /* trigger & validate sleepable uprobe attached by name */ trigger_func3(); + /* trigger & validate uprobe in legacy mode */ + trigger_func4(); + ASSERT_EQ(skel->bss->kprobe_res, 1, "check_kprobe_res"); ASSERT_EQ(skel->bss->kprobe2_res, 11, "check_kprobe_auto_res"); + ASSERT_EQ(skel->bss->kprobe3_res, 3, "check_kprobe_legacy_res"); + ASSERT_EQ(skel->bss->kprobe4_res, 4, "check_kprobe_perf_res"); ASSERT_EQ(skel->bss->kretprobe_res, 2, "check_kretprobe_res"); ASSERT_EQ(skel->bss->kretprobe2_res, 22, "check_kretprobe_auto_res"); ASSERT_EQ(skel->bss->uprobe_res, 3, "check_uprobe_res"); + ASSERT_EQ(skel->bss->uprobe2_res, 4, "check_uprobe_legacy_res"); + ASSERT_EQ(skel->bss->uprobe3_res, 5, "check_uprobe_perf_res"); ASSERT_EQ(skel->bss->uretprobe_res, 4, "check_uretprobe_res"); ASSERT_EQ(skel->bss->uprobe_byname_res, 5, "check_uprobe_byname_res"); ASSERT_EQ(skel->bss->uretprobe_byname_res, 6, "check_uretprobe_byname_res"); diff --git a/tools/testing/selftests/bpf/progs/test_attach_probe.c b/tools/testing/selftests/bpf/progs/test_attach_probe.c index a1e45fec8938..6674deea5686 100644 --- a/tools/testing/selftests/bpf/progs/test_attach_probe.c +++ b/tools/testing/selftests/bpf/progs/test_attach_probe.c @@ -9,9 +9,13 @@ int kprobe_res = 0; int kprobe2_res = 0; +int kprobe3_res = 0; +int kprobe4_res = 0; int kretprobe_res = 0; int kretprobe2_res = 0; int uprobe_res = 0; +int uprobe2_res = 0; +int uprobe3_res = 0; int uretprobe_res = 0; int uprobe_byname_res = 0; int uretprobe_byname_res = 0; @@ -30,6 +34,20 @@ int handle_kprobe(struct pt_regs *ctx) return 0; } +SEC("kprobe") +int handle_kprobe_legacy(struct pt_regs *ctx) +{ + kprobe3_res = 3; + return 0; +} + +SEC("kprobe") +int handle_kprobe_perf(struct pt_regs *ctx) +{ + kprobe4_res = 4; + return 0; +} + SEC("ksyscall/nanosleep") int BPF_KSYSCALL(handle_kprobe_auto, struct __kernel_timespec *req, struct __kernel_timespec *rem) { @@ -69,6 +87,20 @@ int handle_uprobe(struct pt_regs *ctx) return 0; } +SEC("uprobe") +int handle_uprobe_legacy(struct pt_regs *ctx) +{ + uprobe2_res = 4; + return 0; +} + +SEC("uprobe") +int handle_uprobe_perf(struct pt_regs *ctx) +{ + uprobe3_res = 5; + return 0; +} + SEC("uretprobe") int handle_uretprobe(struct pt_regs *ctx) {