[bpf-next,2/2] selftests/bpf: add test for legacy/perf kprobe/uprobe attach mode
Commit Message
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>
---
.../selftests/bpf/prog_tests/attach_probe.c | 61 ++++++++++++++++++-
.../selftests/bpf/progs/test_attach_probe.c | 32 ++++++++++
2 files changed, 92 insertions(+), 1 deletion(-)
Comments
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(-)
> > > >>>>
> > > >>>
> > > >>> [...]
@@ -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");
@@ -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)
{