* [PATCH bpf-next v2 0/3] selftests/bpf: Fix usdt/multispec failure with arm64/clang20
@ 2025-06-15 18:53 Yonghong Song
2025-06-15 18:53 ` [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest Yonghong Song
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Yonghong Song @ 2025-06-15 18:53 UTC (permalink / raw)
To: bpf
Cc: Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, kernel-team,
Martin KaFai Lau
The usdt/multispec test failed with arm64 arch and clang20 compiler.
On arm64, gcc11 and clang20 generates significantly different usdt
probes and such a difference caused clang20 built selftest failed.
Patches 1 and 2 are refactoring and Patch 3 adjusted BPF_USDT_MAX_SPEC_CNT
for arm64/clang which fixed the issue.
Changelogs:
v1 -> v2:
- v1: https://lore.kernel.org/bpf/20250613153446.2256725-1-yonghong.song@linux.dev/
- The commit description in v1 is not right, it checks sdt's for usdt_100
while actually it usdt_300 should be checked. Patch 1 has proper
descriptions.
- Refactor the code to add a new test ust/multispec_fail where a new
prog is added and in that new prog BPF_USDT_MAX_SPEC_CNT can overwrite
the default value in order to pass the test.
Yonghong Song (3):
selftests/bpf: Refactor the failed assertion to another subtest
selftests/bpf: Add test_usdt_multispec.inc.h for sharing between
multiple progs
selftests/bpf: Add subtest usdt_multispec_fail with adjustable
BPF_USDT_MAX_SPEC_CNT
tools/testing/selftests/bpf/prog_tests/usdt.c | 36 +++++++++++++------
.../selftests/bpf/progs/test_usdt_multispec.c | 28 +--------------
.../bpf/progs/test_usdt_multispec.inc.h | 30 ++++++++++++++++
.../bpf/progs/test_usdt_multispec_fail.c | 10 ++++++
4 files changed, 67 insertions(+), 37 deletions(-)
create mode 100644 tools/testing/selftests/bpf/progs/test_usdt_multispec.inc.h
create mode 100644 tools/testing/selftests/bpf/progs/test_usdt_multispec_fail.c
--
2.47.1
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest 2025-06-15 18:53 [PATCH bpf-next v2 0/3] selftests/bpf: Fix usdt/multispec failure with arm64/clang20 Yonghong Song @ 2025-06-15 18:53 ` Yonghong Song 2025-06-16 8:33 ` Jiri Olsa 2025-06-16 22:00 ` Andrii Nakryiko 2025-06-15 18:53 ` [PATCH bpf-next v2 2/3] selftests/bpf: Add test_usdt_multispec.inc.h for sharing between multiple progs Yonghong Song 2025-06-15 18:54 ` [PATCH bpf-next v2 3/3] selftests/bpf: Add subtest usdt_multispec_fail with adjustable BPF_USDT_MAX_SPEC_CNT Yonghong Song 2 siblings, 2 replies; 12+ messages in thread From: Yonghong Song @ 2025-06-15 18:53 UTC (permalink / raw) To: bpf Cc: Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, kernel-team, Martin KaFai Lau When building the selftest with arm64/clang20, the following test failed: ... ubtest_multispec_usdt:PASS:usdt_100_called 0 nsec subtest_multispec_usdt:PASS:usdt_100_sum 0 nsec subtest_multispec_usdt:FAIL:usdt_300_bad_attach unexpected pointer: 0xaaaad82a2a80 #469/2 usdt/multispec:FAIL #469 usdt:FAIL The failed assertion subtest_multispec_usdt:FAIL:usdt_300_bad_attach unexpected pointer: 0xaaaad82a2a80 is caused by bpf_program__attach_usdt() which is expected to fail. But with arm64/clang20 bpf_program__attach_usdt() actually succeeded. Checking usdt probes with usdt.test.o, with gcc11 build binary: stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x00000000000054f8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[sp] stapsdt 0x00000031 NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x0000000000005510, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[sp, 4] ... stapsdt 0x00000032 NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x0000000000005660, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[sp, 60] ... stapsdt 0x00000034 NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x00000000000070e8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[sp, 1192] stapsdt 0x00000034 NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x0000000000007100, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[sp, 1196] ... stapsdt 0x00000032 NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x0000000000009ec4, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[sp, 60] with clang20 build binary: stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x00000000000009a0, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[x9] stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x00000000000009b8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[x9] ... stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x0000000000002590, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[x9] stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x00000000000025a8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[x8] ... stapsdt 0x0000002f NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x0000000000007fdc, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[x10] There are total 301 locations for usdt_300. For gcc11 built binary, there are 300 spec's. But for clang20 built binary, there are 3 spec's. The libbpf default BPF_USDT_MAX_SPEC_CNT is 256. So for gcc11, the above bpf_program__attach_usdt() will fail, but the function will succeed for clang20. Note that we cannot just change BPF_USDT_MAX_SPEC_CNT from 256 to 2 (through overwriting BPF_USDT_MAX_SPEC_CNT before usdt.bpf.h) since it will cause other test failures. We cannot just set BPF_USDT_MAX_SPEC_CNT to 2 for test_usdt_multispec.c since we have below in the Makefile: test_usdt.skel.h-deps := test_usdt.bpf.o test_usdt_multispec.bpf.o and the linker will enforce that BPF_USDT_MAX_SPEC_CNT values for both progs must be the same. The refactoring does not change existing test result. But the future change will allow to set BPF_USDT_MAX_SPEC_CNT to be 2 for arm64/clang20 case, which will have the same attachment failure as in gcc11. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> --- tools/testing/selftests/bpf/prog_tests/usdt.c | 35 +++++++++++++------ 1 file changed, 25 insertions(+), 10 deletions(-) diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c index 495d66414b57..dc29ef94312a 100644 --- a/tools/testing/selftests/bpf/prog_tests/usdt.c +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c @@ -270,18 +270,8 @@ static void subtest_multispec_usdt(void) */ trigger_300_usdts(); - /* we'll reuse usdt_100 BPF program for usdt_300 test */ bpf_link__destroy(skel->links.usdt_100); - skel->links.usdt_100 = bpf_program__attach_usdt(skel->progs.usdt_100, -1, "/proc/self/exe", - "test", "usdt_300", NULL); - err = -errno; - if (!ASSERT_ERR_PTR(skel->links.usdt_100, "usdt_300_bad_attach")) - goto cleanup; - ASSERT_EQ(err, -E2BIG, "usdt_300_attach_err"); - /* let's check that there are no "dangling" BPF programs attached due - * to partial success of the above test:usdt_300 attachment - */ bss->usdt_100_called = 0; bss->usdt_100_sum = 0; @@ -312,6 +302,29 @@ static void subtest_multispec_usdt(void) test_usdt__destroy(skel); } +static void subtest_multispec_fail_usdt(void) +{ + LIBBPF_OPTS(bpf_usdt_opts, opts); + struct test_usdt *skel; + int err; + + skel = test_usdt__open_and_load(); + if (!ASSERT_OK_PTR(skel, "skel_open")) + return; + + skel->bss->my_pid = getpid(); + + skel->links.usdt_100 = bpf_program__attach_usdt(skel->progs.usdt_100, -1, "/proc/self/exe", + "test", "usdt_300", NULL); + err = -errno; + if (!ASSERT_ERR_PTR(skel->links.usdt_100, "usdt_300_bad_attach")) + goto cleanup; + ASSERT_EQ(err, -E2BIG, "usdt_300_attach_err"); + +cleanup: + test_usdt__destroy(skel); +} + static FILE *urand_spawn(int *pid) { FILE *f; @@ -422,6 +435,8 @@ void test_usdt(void) subtest_basic_usdt(); if (test__start_subtest("multispec")) subtest_multispec_usdt(); + if (test__start_subtest("multispec_fail")) + subtest_multispec_fail_usdt(); if (test__start_subtest("urand_auto_attach")) subtest_urandom_usdt(true /* auto_attach */); if (test__start_subtest("urand_pid_attach")) -- 2.47.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest 2025-06-15 18:53 ` [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest Yonghong Song @ 2025-06-16 8:33 ` Jiri Olsa 2025-06-16 15:48 ` Yonghong Song 2025-06-16 22:00 ` Andrii Nakryiko 1 sibling, 1 reply; 12+ messages in thread From: Jiri Olsa @ 2025-06-16 8:33 UTC (permalink / raw) To: Yonghong Song Cc: bpf, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, kernel-team, Martin KaFai Lau On Sun, Jun 15, 2025 at 11:53:51AM -0700, Yonghong Song wrote: SNIP > > There are total 301 locations for usdt_300. For gcc11 built binary, there are > 300 spec's. But for clang20 built binary, there are 3 spec's. The libbpf default > BPF_USDT_MAX_SPEC_CNT is 256. So for gcc11, the above bpf_program__attach_usdt() will > fail, but the function will succeed for clang20. > > Note that we cannot just change BPF_USDT_MAX_SPEC_CNT from 256 to 2 (through overwriting > BPF_USDT_MAX_SPEC_CNT before usdt.bpf.h) since it will cause other test failures. > We cannot just set BPF_USDT_MAX_SPEC_CNT to 2 for test_usdt_multispec.c since we > have below in the Makefile: > test_usdt.skel.h-deps := test_usdt.bpf.o test_usdt_multispec.bpf.o > and the linker will enforce that BPF_USDT_MAX_SPEC_CNT values for both progs must > be the same. > > The refactoring does not change existing test result. But the future change will > allow to set BPF_USDT_MAX_SPEC_CNT to be 2 for arm64/clang20 case, which will have > the same attachment failure as in gcc11. > > Signed-off-by: Yonghong Song <yonghong.song@linux.dev> > --- > tools/testing/selftests/bpf/prog_tests/usdt.c | 35 +++++++++++++------ > 1 file changed, 25 insertions(+), 10 deletions(-) > > diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c > index 495d66414b57..dc29ef94312a 100644 > --- a/tools/testing/selftests/bpf/prog_tests/usdt.c > +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c > @@ -270,18 +270,8 @@ static void subtest_multispec_usdt(void) > */ > trigger_300_usdts(); should above line (plus the comment) ... > > - /* we'll reuse usdt_100 BPF program for usdt_300 test */ > bpf_link__destroy(skel->links.usdt_100); > - skel->links.usdt_100 = bpf_program__attach_usdt(skel->progs.usdt_100, -1, "/proc/self/exe", > - "test", "usdt_300", NULL); > - err = -errno; > - if (!ASSERT_ERR_PTR(skel->links.usdt_100, "usdt_300_bad_attach")) > - goto cleanup; > - ASSERT_EQ(err, -E2BIG, "usdt_300_attach_err"); > > - /* let's check that there are no "dangling" BPF programs attached due > - * to partial success of the above test:usdt_300 attachment > - */ ... and the code below (up to usdt_301_sum assert) go to the new subtest_multispec_fail_usdt test as well? jirka > bss->usdt_100_called = 0; > bss->usdt_100_sum = 0; > > @@ -312,6 +302,29 @@ static void subtest_multispec_usdt(void) > test_usdt__destroy(skel); > } > > +static void subtest_multispec_fail_usdt(void) > +{ > + LIBBPF_OPTS(bpf_usdt_opts, opts); > + struct test_usdt *skel; > + int err; > + > + skel = test_usdt__open_and_load(); > + if (!ASSERT_OK_PTR(skel, "skel_open")) > + return; > + > + skel->bss->my_pid = getpid(); > + > + skel->links.usdt_100 = bpf_program__attach_usdt(skel->progs.usdt_100, -1, "/proc/self/exe", > + "test", "usdt_300", NULL); > + err = -errno; > + if (!ASSERT_ERR_PTR(skel->links.usdt_100, "usdt_300_bad_attach")) > + goto cleanup; > + ASSERT_EQ(err, -E2BIG, "usdt_300_attach_err"); > + > +cleanup: > + test_usdt__destroy(skel); > +} > + > static FILE *urand_spawn(int *pid) > { > FILE *f; > @@ -422,6 +435,8 @@ void test_usdt(void) > subtest_basic_usdt(); > if (test__start_subtest("multispec")) > subtest_multispec_usdt(); > + if (test__start_subtest("multispec_fail")) > + subtest_multispec_fail_usdt(); > if (test__start_subtest("urand_auto_attach")) > subtest_urandom_usdt(true /* auto_attach */); > if (test__start_subtest("urand_pid_attach")) > -- > 2.47.1 > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest 2025-06-16 8:33 ` Jiri Olsa @ 2025-06-16 15:48 ` Yonghong Song 0 siblings, 0 replies; 12+ messages in thread From: Yonghong Song @ 2025-06-16 15:48 UTC (permalink / raw) To: Jiri Olsa Cc: bpf, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, kernel-team, Martin KaFai Lau On 6/16/25 1:33 AM, Jiri Olsa wrote: > On Sun, Jun 15, 2025 at 11:53:51AM -0700, Yonghong Song wrote: > > SNIP > >> There are total 301 locations for usdt_300. For gcc11 built binary, there are >> 300 spec's. But for clang20 built binary, there are 3 spec's. The libbpf default >> BPF_USDT_MAX_SPEC_CNT is 256. So for gcc11, the above bpf_program__attach_usdt() will >> fail, but the function will succeed for clang20. >> >> Note that we cannot just change BPF_USDT_MAX_SPEC_CNT from 256 to 2 (through overwriting >> BPF_USDT_MAX_SPEC_CNT before usdt.bpf.h) since it will cause other test failures. >> We cannot just set BPF_USDT_MAX_SPEC_CNT to 2 for test_usdt_multispec.c since we >> have below in the Makefile: >> test_usdt.skel.h-deps := test_usdt.bpf.o test_usdt_multispec.bpf.o >> and the linker will enforce that BPF_USDT_MAX_SPEC_CNT values for both progs must >> be the same. >> >> The refactoring does not change existing test result. But the future change will >> allow to set BPF_USDT_MAX_SPEC_CNT to be 2 for arm64/clang20 case, which will have >> the same attachment failure as in gcc11. >> >> Signed-off-by: Yonghong Song <yonghong.song@linux.dev> >> --- >> tools/testing/selftests/bpf/prog_tests/usdt.c | 35 +++++++++++++------ >> 1 file changed, 25 insertions(+), 10 deletions(-) >> >> diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c >> index 495d66414b57..dc29ef94312a 100644 >> --- a/tools/testing/selftests/bpf/prog_tests/usdt.c >> +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c >> @@ -270,18 +270,8 @@ static void subtest_multispec_usdt(void) >> */ >> trigger_300_usdts(); > should above line (plus the comment) ... > >> >> - /* we'll reuse usdt_100 BPF program for usdt_300 test */ >> bpf_link__destroy(skel->links.usdt_100); >> - skel->links.usdt_100 = bpf_program__attach_usdt(skel->progs.usdt_100, -1, "/proc/self/exe", >> - "test", "usdt_300", NULL); >> - err = -errno; >> - if (!ASSERT_ERR_PTR(skel->links.usdt_100, "usdt_300_bad_attach")) >> - goto cleanup; >> - ASSERT_EQ(err, -E2BIG, "usdt_300_attach_err"); >> >> - /* let's check that there are no "dangling" BPF programs attached due >> - * to partial success of the above test:usdt_300 attachment >> - */ > ... and the code below (up to usdt_301_sum assert) > go to the new subtest_multispec_fail_usdt test as well? Indeed, I need to move more codes related to usdt test/usdt_300 to subtest_multispec_fail_usdt(). The following code skel->bss->usdt_100_called = 0; skel->bss->usdt_100_sum = 0; should remain in function subtest_multispec_usdt() as it is needed for test/usdt_400 usdt testing which also used usdt_100 prog. > > jirka > >> bss->usdt_100_called = 0; >> bss->usdt_100_sum = 0; >> >> @@ -312,6 +302,29 @@ static void subtest_multispec_usdt(void) >> test_usdt__destroy(skel); >> } >> >> +static void subtest_multispec_fail_usdt(void) >> +{ >> + LIBBPF_OPTS(bpf_usdt_opts, opts); >> + struct test_usdt *skel; >> + int err; >> + >> + skel = test_usdt__open_and_load(); >> + if (!ASSERT_OK_PTR(skel, "skel_open")) >> + return; >> + >> + skel->bss->my_pid = getpid(); >> + >> + skel->links.usdt_100 = bpf_program__attach_usdt(skel->progs.usdt_100, -1, "/proc/self/exe", >> + "test", "usdt_300", NULL); >> + err = -errno; >> + if (!ASSERT_ERR_PTR(skel->links.usdt_100, "usdt_300_bad_attach")) >> + goto cleanup; >> + ASSERT_EQ(err, -E2BIG, "usdt_300_attach_err"); >> + >> +cleanup: >> + test_usdt__destroy(skel); >> +} >> + >> [...] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest 2025-06-15 18:53 ` [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest Yonghong Song 2025-06-16 8:33 ` Jiri Olsa @ 2025-06-16 22:00 ` Andrii Nakryiko 2025-06-18 4:36 ` Yonghong Song 1 sibling, 1 reply; 12+ messages in thread From: Andrii Nakryiko @ 2025-06-16 22:00 UTC (permalink / raw) To: Yonghong Song Cc: bpf, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, kernel-team, Martin KaFai Lau On Sun, Jun 15, 2025 at 11:54 AM Yonghong Song <yonghong.song@linux.dev> wrote: > > When building the selftest with arm64/clang20, the following test failed: > ... > ubtest_multispec_usdt:PASS:usdt_100_called 0 nsec > subtest_multispec_usdt:PASS:usdt_100_sum 0 nsec > subtest_multispec_usdt:FAIL:usdt_300_bad_attach unexpected pointer: 0xaaaad82a2a80 > #469/2 usdt/multispec:FAIL > #469 usdt:FAIL > > The failed assertion > subtest_multispec_usdt:FAIL:usdt_300_bad_attach unexpected pointer: 0xaaaad82a2a80 > is caused by bpf_program__attach_usdt() which is expected to fail. But > with arm64/clang20 bpf_program__attach_usdt() actually succeeded. I think I missed that it's unexpected *success* that is causing issues. If that's so, then I think it might be more straightforward to just ensure that test is expectedly failing regardless of compiler code generation logic. Maybe something along the following lines: diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c index 495d66414b57..fdd8642cfdff 100644 --- a/tools/testing/selftests/bpf/prog_tests/usdt.c +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c @@ -190,11 +190,21 @@ static void __always_inline f300(int x) STAP_PROBE1(test, usdt_300, x); } +#define RP10(F, X) F(*(X+0)); F(*(X+1));F(*(X+2)); F(*(X+3)); F(*(X+4)); \ + F(*(X+5)); F(*(X+6)); F(*(X+7)); F(*(X+8)); F(*(X+9)); +#define RP100(F, X) RP10(F,X+ 0);RP10(F,X+10);RP10(F,X+20);RP10(F,X+30);RP10(F,X+40); \ + RP10(F,X+50);RP10(F,X+60);RP10(F,X+70);RP10(F,X+80);RP10(F,X+90); + __weak void trigger_300_usdts(void) { - R100(f300, 0); - R100(f300, 100); - R100(f300, 200); + volatile int arr[300], i; + + for (i = 0; i < 300; i++) + arr[i] = 300; + + RP100(f300, arr + 0); + RP100(f300, arr + 100); + RP100(f300, arr + 200); } So basically force the compiler to use 300 different locations for each of 300 USDT instantiations? I didn't check how that will look like on arm64, but on x86 gcc it seems to generate what is expected of it. Can you please try it on arm64 and see if that works? > > Checking usdt probes with usdt.test.o, > > with gcc11 build binary: > stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt_300 > Location: 0x00000000000054f8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > Arguments: -4@[sp] > stapsdt 0x00000031 NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt_300 > Location: 0x0000000000005510, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > Arguments: -4@[sp, 4] > ... > stapsdt 0x00000032 NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt_300 > Location: 0x0000000000005660, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > Arguments: -4@[sp, 60] > ... > stapsdt 0x00000034 NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt_300 > Location: 0x00000000000070e8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > Arguments: -4@[sp, 1192] > stapsdt 0x00000034 NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt_300 > Location: 0x0000000000007100, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > Arguments: -4@[sp, 1196] > ... > stapsdt 0x00000032 NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt_300 > Location: 0x0000000000009ec4, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > Arguments: -4@[sp, 60] > > with clang20 build binary: > stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt_300 > Location: 0x00000000000009a0, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > Arguments: -4@[x9] > stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt_300 > Location: 0x00000000000009b8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > Arguments: -4@[x9] > ... > stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt_300 > Location: 0x0000000000002590, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > Arguments: -4@[x9] > stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt_300 > Location: 0x00000000000025a8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > Arguments: -4@[x8] > ... > stapsdt 0x0000002f NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt_300 > Location: 0x0000000000007fdc, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > Arguments: -4@[x10] > > There are total 301 locations for usdt_300. For gcc11 built binary, there are > 300 spec's. But for clang20 built binary, there are 3 spec's. The libbpf default > BPF_USDT_MAX_SPEC_CNT is 256. So for gcc11, the above bpf_program__attach_usdt() will > fail, but the function will succeed for clang20. > > Note that we cannot just change BPF_USDT_MAX_SPEC_CNT from 256 to 2 (through overwriting > BPF_USDT_MAX_SPEC_CNT before usdt.bpf.h) since it will cause other test failures. > We cannot just set BPF_USDT_MAX_SPEC_CNT to 2 for test_usdt_multispec.c since we > have below in the Makefile: > test_usdt.skel.h-deps := test_usdt.bpf.o test_usdt_multispec.bpf.o > and the linker will enforce that BPF_USDT_MAX_SPEC_CNT values for both progs must > be the same. > > The refactoring does not change existing test result. But the future change will > allow to set BPF_USDT_MAX_SPEC_CNT to be 2 for arm64/clang20 case, which will have > the same attachment failure as in gcc11. > > Signed-off-by: Yonghong Song <yonghong.song@linux.dev> > --- > tools/testing/selftests/bpf/prog_tests/usdt.c | 35 +++++++++++++------ > 1 file changed, 25 insertions(+), 10 deletions(-) > > diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c > index 495d66414b57..dc29ef94312a 100644 > --- a/tools/testing/selftests/bpf/prog_tests/usdt.c > +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c > @@ -270,18 +270,8 @@ static void subtest_multispec_usdt(void) > */ > trigger_300_usdts(); > > - /* we'll reuse usdt_100 BPF program for usdt_300 test */ > bpf_link__destroy(skel->links.usdt_100); > - skel->links.usdt_100 = bpf_program__attach_usdt(skel->progs.usdt_100, -1, "/proc/self/exe", > - "test", "usdt_300", NULL); > - err = -errno; > - if (!ASSERT_ERR_PTR(skel->links.usdt_100, "usdt_300_bad_attach")) > - goto cleanup; > - ASSERT_EQ(err, -E2BIG, "usdt_300_attach_err"); > > - /* let's check that there are no "dangling" BPF programs attached due > - * to partial success of the above test:usdt_300 attachment > - */ > bss->usdt_100_called = 0; > bss->usdt_100_sum = 0; > > @@ -312,6 +302,29 @@ static void subtest_multispec_usdt(void) > test_usdt__destroy(skel); > } > > +static void subtest_multispec_fail_usdt(void) > +{ > + LIBBPF_OPTS(bpf_usdt_opts, opts); > + struct test_usdt *skel; > + int err; > + > + skel = test_usdt__open_and_load(); > + if (!ASSERT_OK_PTR(skel, "skel_open")) > + return; > + > + skel->bss->my_pid = getpid(); > + > + skel->links.usdt_100 = bpf_program__attach_usdt(skel->progs.usdt_100, -1, "/proc/self/exe", > + "test", "usdt_300", NULL); > + err = -errno; > + if (!ASSERT_ERR_PTR(skel->links.usdt_100, "usdt_300_bad_attach")) > + goto cleanup; > + ASSERT_EQ(err, -E2BIG, "usdt_300_attach_err"); > + > +cleanup: > + test_usdt__destroy(skel); > +} > + > static FILE *urand_spawn(int *pid) > { > FILE *f; > @@ -422,6 +435,8 @@ void test_usdt(void) > subtest_basic_usdt(); > if (test__start_subtest("multispec")) > subtest_multispec_usdt(); > + if (test__start_subtest("multispec_fail")) > + subtest_multispec_fail_usdt(); > if (test__start_subtest("urand_auto_attach")) > subtest_urandom_usdt(true /* auto_attach */); > if (test__start_subtest("urand_pid_attach")) > -- > 2.47.1 > ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest 2025-06-16 22:00 ` Andrii Nakryiko @ 2025-06-18 4:36 ` Yonghong Song 2025-06-24 15:36 ` Andrii Nakryiko 0 siblings, 1 reply; 12+ messages in thread From: Yonghong Song @ 2025-06-18 4:36 UTC (permalink / raw) To: Andrii Nakryiko Cc: bpf, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, kernel-team, Martin KaFai Lau On 6/16/25 3:00 PM, Andrii Nakryiko wrote: > On Sun, Jun 15, 2025 at 11:54 AM Yonghong Song <yonghong.song@linux.dev> wrote: >> When building the selftest with arm64/clang20, the following test failed: >> ... >> ubtest_multispec_usdt:PASS:usdt_100_called 0 nsec >> subtest_multispec_usdt:PASS:usdt_100_sum 0 nsec >> subtest_multispec_usdt:FAIL:usdt_300_bad_attach unexpected pointer: 0xaaaad82a2a80 >> #469/2 usdt/multispec:FAIL >> #469 usdt:FAIL >> >> The failed assertion >> subtest_multispec_usdt:FAIL:usdt_300_bad_attach unexpected pointer: 0xaaaad82a2a80 >> is caused by bpf_program__attach_usdt() which is expected to fail. But >> with arm64/clang20 bpf_program__attach_usdt() actually succeeded. > I think I missed that it's unexpected *success* that is causing > issues. If that's so, then I think it might be more straightforward to > just ensure that test is expectedly failing regardless of compiler > code generation logic. Maybe something along the following lines: > > diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c > b/tools/testing/selftests/bpf/prog_tests/usdt.c > index 495d66414b57..fdd8642cfdff 100644 > --- a/tools/testing/selftests/bpf/prog_tests/usdt.c > +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c > @@ -190,11 +190,21 @@ static void __always_inline f300(int x) > STAP_PROBE1(test, usdt_300, x); > } > > +#define RP10(F, X) F(*(X+0)); F(*(X+1));F(*(X+2)); F(*(X+3)); F(*(X+4)); \ > + F(*(X+5)); F(*(X+6)); F(*(X+7)); F(*(X+8)); F(*(X+9)); > +#define RP100(F, X) RP10(F,X+ > 0);RP10(F,X+10);RP10(F,X+20);RP10(F,X+30);RP10(F,X+40); \ > + > RP10(F,X+50);RP10(F,X+60);RP10(F,X+70);RP10(F,X+80);RP10(F,X+90); > + > __weak void trigger_300_usdts(void) > { > - R100(f300, 0); > - R100(f300, 100); > - R100(f300, 200); > + volatile int arr[300], i; > + > + for (i = 0; i < 300; i++) > + arr[i] = 300; > + > + RP100(f300, arr + 0); > + RP100(f300, arr + 100); > + RP100(f300, arr + 200); > } > > > So basically force the compiler to use 300 different locations for > each of 300 USDT instantiations? I didn't check how that will look > like on arm64, but on x86 gcc it seems to generate what is expected of > it. > > Can you please try it on arm64 and see if that works? I tried the above on arm64 and it does not work. It has the same usdt arguments as without this patch: stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x00000000000009e0, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[x9] stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x00000000000009f8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[x9] ... But I found if we build usdt.c file with -O2 (RELEASE=1) on arm64, the test will be successful: stapsdt 0x0000002b NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x00000000000001a4, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@0 stapsdt 0x0000002b NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x00000000000001a8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@1 ... But usdt.c with -O2 will have a problem with gcc14 on x86: stapsdt 0x00000087 NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt12 Location: 0x000000000000258f, Base: 0x0000000000000000, Semaphore: 0x0000000000000006 Arguments: -4@$2 -4@$3 -8@$42 -8@$44 -4@$5 -8@$6 8@%rdx 8@%rsi -4@$-9 -2@%cx -2@nums(%rax,%rax) -1@t1+4(%rip) ... You can see the above last two arguments which are not supported by libbpf. So let us say usdt.c is compiled with -O2: x86: gcc14 built kernel/selftests: failed, see the above clang built kernel/selftests: good arm64: both gcc14/clang built kernel/selftrests: good arm64 has more reigsters so it is likely to have better argument representation, e.g., for arm64/gcc with -O2, we have stapsdt 0x00000071 NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt12 Location: 0x0000000000002e74, Base: 0x0000000000000000, Semaphore: 0x000000000000000a Arguments: -4@2 -4@3 -8@42 -8@44 -4@5 -8@6 8@x1 8@x3 -4@-9 -2@x2 -2@[x0, 8] -1@[x3, 28] Eduard helped me to figure out how to compile prog_tests/usdt.c with -O2 alone. The following patch resolved the issue and usdt test will be happy for both x86 and arm64: diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile index 97013c49920b..05fc9149bc4f 100644 --- a/tools/testing/selftests/bpf/Makefile +++ b/tools/testing/selftests/bpf/Makefile @@ -760,6 +760,14 @@ TRUNNER_BPF_BUILD_RULE := $$(error no BPF objects should be built) TRUNNER_BPF_CFLAGS := $(eval $(call DEFINE_TEST_RUNNER,test_maps)) +# Compiler prog_tests/usdt.c with -O2 with clang compiler. +# Otherwise, with -O0 on arm64, the usdt test will fail. +ifneq ($(LLVM),) +$(OUTPUT)/usdt.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS)) +$(OUTPUT)/cpuv4/usdt.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS)) +$(OUTPUT)/no_alu32/usdt.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS)) +endif + # Define test_verifier test runner. # It is much simpler than test_maps/test_progs and sufficiently different from # them (e.g., test.h is using completely pattern), that it's worth just Another choice is to support argument like `-2@nums(%rax,%rax)` and `-1@t1+4(%rip)`. But I am not sure whether we should do it or not as typically a usdt probe probably won't have lots of diverse arguments. WDYT? > >> Checking usdt probes with usdt.test.o, >> >> with gcc11 build binary: >> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt_300 >> Location: 0x00000000000054f8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >> Arguments: -4@[sp] >> stapsdt 0x00000031 NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt_300 >> Location: 0x0000000000005510, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >> Arguments: -4@[sp, 4] >> ... >> stapsdt 0x00000032 NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt_300 >> Location: 0x0000000000005660, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >> Arguments: -4@[sp, 60] >> ... >> stapsdt 0x00000034 NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt_300 >> Location: 0x00000000000070e8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >> Arguments: -4@[sp, 1192] >> stapsdt 0x00000034 NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt_300 >> Location: 0x0000000000007100, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >> Arguments: -4@[sp, 1196] >> ... >> stapsdt 0x00000032 NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt_300 >> Location: 0x0000000000009ec4, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >> Arguments: -4@[sp, 60] >> >> with clang20 build binary: >> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt_300 >> Location: 0x00000000000009a0, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >> Arguments: -4@[x9] >> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt_300 >> Location: 0x00000000000009b8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >> Arguments: -4@[x9] >> ... >> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt_300 >> Location: 0x0000000000002590, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >> Arguments: -4@[x9] >> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt_300 >> Location: 0x00000000000025a8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >> Arguments: -4@[x8] >> ... >> stapsdt 0x0000002f NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt_300 >> Location: 0x0000000000007fdc, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >> Arguments: -4@[x10] >> >> There are total 301 locations for usdt_300. For gcc11 built binary, there are >> 300 spec's. But for clang20 built binary, there are 3 spec's. The libbpf default >> BPF_USDT_MAX_SPEC_CNT is 256. So for gcc11, the above bpf_program__attach_usdt() will >> fail, but the function will succeed for clang20. >> >> Note that we cannot just change BPF_USDT_MAX_SPEC_CNT from 256 to 2 (through overwriting >> BPF_USDT_MAX_SPEC_CNT before usdt.bpf.h) since it will cause other test failures. >> We cannot just set BPF_USDT_MAX_SPEC_CNT to 2 for test_usdt_multispec.c since we >> have below in the Makefile: >> test_usdt.skel.h-deps := test_usdt.bpf.o test_usdt_multispec.bpf.o >> and the linker will enforce that BPF_USDT_MAX_SPEC_CNT values for both progs must >> be the same. >> >> The refactoring does not change existing test result. But the future change will >> allow to set BPF_USDT_MAX_SPEC_CNT to be 2 for arm64/clang20 case, which will have >> the same attachment failure as in gcc11. >> >> Signed-off-by: Yonghong Song <yonghong.song@linux.dev> >> --- >> tools/testing/selftests/bpf/prog_tests/usdt.c | 35 +++++++++++++------ >> 1 file changed, 25 insertions(+), 10 deletions(-) >> >> diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c >> index 495d66414b57..dc29ef94312a 100644 >> --- a/tools/testing/selftests/bpf/prog_tests/usdt.c >> +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c >> @@ -270,18 +270,8 @@ static void subtest_multispec_usdt(void) >> */ >> trigger_300_usdts(); >> >> - /* we'll reuse usdt_100 BPF program for usdt_300 test */ >> bpf_link__destroy(skel->links.usdt_100); >> - skel->links.usdt_100 = bpf_program__attach_usdt(skel->progs.usdt_100, -1, "/proc/self/exe", >> - "test", "usdt_300", NULL); >> - err = -errno; >> - if (!ASSERT_ERR_PTR(skel->links.usdt_100, "usdt_300_bad_attach")) >> - goto cleanup; >> - ASSERT_EQ(err, -E2BIG, "usdt_300_attach_err"); >> >> - /* let's check that there are no "dangling" BPF programs attached due >> - * to partial success of the above test:usdt_300 attachment >> - */ >> bss->usdt_100_called = 0; >> bss->usdt_100_sum = 0; >> >> @@ -312,6 +302,29 @@ static void subtest_multispec_usdt(void) >> test_usdt__destroy(skel); >> } >> >> +static void subtest_multispec_fail_usdt(void) >> +{ >> + LIBBPF_OPTS(bpf_usdt_opts, opts); >> + struct test_usdt *skel; >> + int err; >> + >> + skel = test_usdt__open_and_load(); >> + if (!ASSERT_OK_PTR(skel, "skel_open")) >> + return; >> + >> + skel->bss->my_pid = getpid(); >> + >> + skel->links.usdt_100 = bpf_program__attach_usdt(skel->progs.usdt_100, -1, "/proc/self/exe", >> + "test", "usdt_300", NULL); >> + err = -errno; >> + if (!ASSERT_ERR_PTR(skel->links.usdt_100, "usdt_300_bad_attach")) >> + goto cleanup; >> + ASSERT_EQ(err, -E2BIG, "usdt_300_attach_err"); >> + >> +cleanup: >> + test_usdt__destroy(skel); >> +} >> + >> static FILE *urand_spawn(int *pid) >> { >> FILE *f; >> @@ -422,6 +435,8 @@ void test_usdt(void) >> subtest_basic_usdt(); >> if (test__start_subtest("multispec")) >> subtest_multispec_usdt(); >> + if (test__start_subtest("multispec_fail")) >> + subtest_multispec_fail_usdt(); >> if (test__start_subtest("urand_auto_attach")) >> subtest_urandom_usdt(true /* auto_attach */); >> if (test__start_subtest("urand_pid_attach")) >> -- >> 2.47.1 >> ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest 2025-06-18 4:36 ` Yonghong Song @ 2025-06-24 15:36 ` Andrii Nakryiko 2025-06-24 16:15 ` Yonghong Song 0 siblings, 1 reply; 12+ messages in thread From: Andrii Nakryiko @ 2025-06-24 15:36 UTC (permalink / raw) To: Yonghong Song Cc: bpf, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, kernel-team, Martin KaFai Lau On Tue, Jun 17, 2025 at 9:36 PM Yonghong Song <yonghong.song@linux.dev> wrote: > > > > On 6/16/25 3:00 PM, Andrii Nakryiko wrote: > > On Sun, Jun 15, 2025 at 11:54 AM Yonghong Song <yonghong.song@linux.dev> wrote: > >> When building the selftest with arm64/clang20, the following test failed: > >> ... > >> ubtest_multispec_usdt:PASS:usdt_100_called 0 nsec > >> subtest_multispec_usdt:PASS:usdt_100_sum 0 nsec > >> subtest_multispec_usdt:FAIL:usdt_300_bad_attach unexpected pointer: 0xaaaad82a2a80 > >> #469/2 usdt/multispec:FAIL > >> #469 usdt:FAIL > >> > >> The failed assertion > >> subtest_multispec_usdt:FAIL:usdt_300_bad_attach unexpected pointer: 0xaaaad82a2a80 > >> is caused by bpf_program__attach_usdt() which is expected to fail. But > >> with arm64/clang20 bpf_program__attach_usdt() actually succeeded. > > I think I missed that it's unexpected *success* that is causing > > issues. If that's so, then I think it might be more straightforward to > > just ensure that test is expectedly failing regardless of compiler > > code generation logic. Maybe something along the following lines: > > > > diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c > > b/tools/testing/selftests/bpf/prog_tests/usdt.c > > index 495d66414b57..fdd8642cfdff 100644 > > --- a/tools/testing/selftests/bpf/prog_tests/usdt.c > > +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c > > @@ -190,11 +190,21 @@ static void __always_inline f300(int x) > > STAP_PROBE1(test, usdt_300, x); > > } > > > > +#define RP10(F, X) F(*(X+0)); F(*(X+1));F(*(X+2)); F(*(X+3)); F(*(X+4)); \ > > + F(*(X+5)); F(*(X+6)); F(*(X+7)); F(*(X+8)); F(*(X+9)); > > +#define RP100(F, X) RP10(F,X+ > > 0);RP10(F,X+10);RP10(F,X+20);RP10(F,X+30);RP10(F,X+40); \ > > + > > RP10(F,X+50);RP10(F,X+60);RP10(F,X+70);RP10(F,X+80);RP10(F,X+90); > > + > > __weak void trigger_300_usdts(void) > > { > > - R100(f300, 0); > > - R100(f300, 100); > > - R100(f300, 200); > > + volatile int arr[300], i; > > + > > + for (i = 0; i < 300; i++) > > + arr[i] = 300; > > + > > + RP100(f300, arr + 0); > > + RP100(f300, arr + 100); > > + RP100(f300, arr + 200); > > } > > > > > > So basically force the compiler to use 300 different locations for > > each of 300 USDT instantiations? I didn't check how that will look > > like on arm64, but on x86 gcc it seems to generate what is expected of > > it. > > > > Can you please try it on arm64 and see if that works? > > I tried the above on arm64 and it does not work. It has the same usdt arguments > as without this patch: > > stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt_300 > Location: 0x00000000000009e0, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > Arguments: -4@[x9] > stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt_300 > Location: 0x00000000000009f8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > Arguments: -4@[x9] > ... > > But I found if we build usdt.c file with -O2 (RELEASE=1) on arm64, the test will be successful: > > stapsdt 0x0000002b NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt_300 > Location: 0x00000000000001a4, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > Arguments: -4@0 > stapsdt 0x0000002b NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt_300 > Location: 0x00000000000001a8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > Arguments: -4@1 > ... > > But usdt.c with -O2 will have a problem with gcc14 on x86: > > stapsdt 0x00000087 NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt12 > Location: 0x000000000000258f, Base: 0x0000000000000000, Semaphore: 0x0000000000000006 > Arguments: -4@$2 -4@$3 -8@$42 -8@$44 -4@$5 -8@$6 8@%rdx 8@%rsi -4@$-9 -2@%cx -2@nums(%rax,%rax) -1@t1+4(%rip) > ... > > You can see the above last two arguments which are not supported by libbpf. > > So let us say usdt.c is compiled with -O2: > x86: > gcc14 built kernel/selftests: failed, see the above > clang built kernel/selftests: good > arm64: > both gcc14/clang built kernel/selftrests: good > > arm64 has more reigsters so it is likely to have better argument representation, e.g., > for arm64/gcc with -O2, we have > > stapsdt 0x00000071 NT_STAPSDT (SystemTap probe descriptors) > Provider: test > Name: usdt12 > Location: 0x0000000000002e74, Base: 0x0000000000000000, Semaphore: 0x000000000000000a > Arguments: -4@2 -4@3 -8@42 -8@44 -4@5 -8@6 8@x1 8@x3 -4@-9 -2@x2 -2@[x0, 8] -1@[x3, 28] > > Eduard helped me to figure out how to compile prog_tests/usdt.c with -O2 alone. > The following patch resolved the issue and usdt test will be happy for both x86 and arm64: > > diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile > index 97013c49920b..05fc9149bc4f 100644 > --- a/tools/testing/selftests/bpf/Makefile > +++ b/tools/testing/selftests/bpf/Makefile > @@ -760,6 +760,14 @@ TRUNNER_BPF_BUILD_RULE := $$(error no BPF objects should be built) > TRUNNER_BPF_CFLAGS := > $(eval $(call DEFINE_TEST_RUNNER,test_maps)) > > +# Compiler prog_tests/usdt.c with -O2 with clang compiler. > +# Otherwise, with -O0 on arm64, the usdt test will fail. > +ifneq ($(LLVM),) > +$(OUTPUT)/usdt.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS)) > +$(OUTPUT)/cpuv4/usdt.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS)) > +$(OUTPUT)/no_alu32/usdt.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS)) > +endif > + > # Define test_verifier test runner. > # It is much simpler than test_maps/test_progs and sufficiently different from > # them (e.g., test.h is using completely pattern), that it's worth just > > Another choice is to support argument like `-2@nums(%rax,%rax)` and `-1@t1+4(%rip)`. > But I am not sure whether we should do it or not as typically a usdt probe > probably won't have lots of diverse arguments. > > WDYT? Can we just make that part of the test x86-64 specific for now? All other alternatives seem worse, tbh. > > > > > >> Checking usdt probes with usdt.test.o, > >> > >> with gcc11 build binary: > >> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt_300 > >> Location: 0x00000000000054f8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > >> Arguments: -4@[sp] > >> stapsdt 0x00000031 NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt_300 > >> Location: 0x0000000000005510, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > >> Arguments: -4@[sp, 4] > >> ... > >> stapsdt 0x00000032 NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt_300 > >> Location: 0x0000000000005660, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > >> Arguments: -4@[sp, 60] > >> ... > >> stapsdt 0x00000034 NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt_300 > >> Location: 0x00000000000070e8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > >> Arguments: -4@[sp, 1192] > >> stapsdt 0x00000034 NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt_300 > >> Location: 0x0000000000007100, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > >> Arguments: -4@[sp, 1196] > >> ... > >> stapsdt 0x00000032 NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt_300 > >> Location: 0x0000000000009ec4, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > >> Arguments: -4@[sp, 60] > >> > >> with clang20 build binary: > >> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt_300 > >> Location: 0x00000000000009a0, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > >> Arguments: -4@[x9] > >> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt_300 > >> Location: 0x00000000000009b8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > >> Arguments: -4@[x9] > >> ... > >> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt_300 > >> Location: 0x0000000000002590, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > >> Arguments: -4@[x9] > >> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt_300 > >> Location: 0x00000000000025a8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > >> Arguments: -4@[x8] > >> ... > >> stapsdt 0x0000002f NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt_300 > >> Location: 0x0000000000007fdc, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > >> Arguments: -4@[x10] > >> > >> There are total 301 locations for usdt_300. For gcc11 built binary, there are > >> 300 spec's. But for clang20 built binary, there are 3 spec's. The libbpf default > >> BPF_USDT_MAX_SPEC_CNT is 256. So for gcc11, the above bpf_program__attach_usdt() will > >> fail, but the function will succeed for clang20. > >> > >> Note that we cannot just change BPF_USDT_MAX_SPEC_CNT from 256 to 2 (through overwriting > >> BPF_USDT_MAX_SPEC_CNT before usdt.bpf.h) since it will cause other test failures. > >> We cannot just set BPF_USDT_MAX_SPEC_CNT to 2 for test_usdt_multispec.c since we > >> have below in the Makefile: > >> test_usdt.skel.h-deps := test_usdt.bpf.o test_usdt_multispec.bpf.o > >> and the linker will enforce that BPF_USDT_MAX_SPEC_CNT values for both progs must > >> be the same. > >> > >> The refactoring does not change existing test result. But the future change will > >> allow to set BPF_USDT_MAX_SPEC_CNT to be 2 for arm64/clang20 case, which will have > >> the same attachment failure as in gcc11. > >> > >> Signed-off-by: Yonghong Song <yonghong.song@linux.dev> > >> --- > >> tools/testing/selftests/bpf/prog_tests/usdt.c | 35 +++++++++++++------ > >> 1 file changed, 25 insertions(+), 10 deletions(-) > >> > >> diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c > >> index 495d66414b57..dc29ef94312a 100644 > >> --- a/tools/testing/selftests/bpf/prog_tests/usdt.c > >> +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c > >> @@ -270,18 +270,8 @@ static void subtest_multispec_usdt(void) > >> */ > >> trigger_300_usdts(); > >> > >> - /* we'll reuse usdt_100 BPF program for usdt_300 test */ > >> bpf_link__destroy(skel->links.usdt_100); > >> - skel->links.usdt_100 = bpf_program__attach_usdt(skel->progs.usdt_100, -1, "/proc/self/exe", > >> - "test", "usdt_300", NULL); > >> - err = -errno; > >> - if (!ASSERT_ERR_PTR(skel->links.usdt_100, "usdt_300_bad_attach")) > >> - goto cleanup; > >> - ASSERT_EQ(err, -E2BIG, "usdt_300_attach_err"); > >> > >> - /* let's check that there are no "dangling" BPF programs attached due > >> - * to partial success of the above test:usdt_300 attachment > >> - */ > >> bss->usdt_100_called = 0; > >> bss->usdt_100_sum = 0; > >> > >> @@ -312,6 +302,29 @@ static void subtest_multispec_usdt(void) > >> test_usdt__destroy(skel); > >> } > >> > >> +static void subtest_multispec_fail_usdt(void) > >> +{ > >> + LIBBPF_OPTS(bpf_usdt_opts, opts); > >> + struct test_usdt *skel; > >> + int err; > >> + > >> + skel = test_usdt__open_and_load(); > >> + if (!ASSERT_OK_PTR(skel, "skel_open")) > >> + return; > >> + > >> + skel->bss->my_pid = getpid(); > >> + > >> + skel->links.usdt_100 = bpf_program__attach_usdt(skel->progs.usdt_100, -1, "/proc/self/exe", > >> + "test", "usdt_300", NULL); > >> + err = -errno; > >> + if (!ASSERT_ERR_PTR(skel->links.usdt_100, "usdt_300_bad_attach")) > >> + goto cleanup; > >> + ASSERT_EQ(err, -E2BIG, "usdt_300_attach_err"); > >> + > >> +cleanup: > >> + test_usdt__destroy(skel); > >> +} > >> + > >> static FILE *urand_spawn(int *pid) > >> { > >> FILE *f; > >> @@ -422,6 +435,8 @@ void test_usdt(void) > >> subtest_basic_usdt(); > >> if (test__start_subtest("multispec")) > >> subtest_multispec_usdt(); > >> + if (test__start_subtest("multispec_fail")) > >> + subtest_multispec_fail_usdt(); > >> if (test__start_subtest("urand_auto_attach")) > >> subtest_urandom_usdt(true /* auto_attach */); > >> if (test__start_subtest("urand_pid_attach")) > >> -- > >> 2.47.1 > >> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest 2025-06-24 15:36 ` Andrii Nakryiko @ 2025-06-24 16:15 ` Yonghong Song 2025-06-24 19:48 ` Andrii Nakryiko 0 siblings, 1 reply; 12+ messages in thread From: Yonghong Song @ 2025-06-24 16:15 UTC (permalink / raw) To: Andrii Nakryiko Cc: bpf, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, kernel-team, Martin KaFai Lau On 6/24/25 8:36 AM, Andrii Nakryiko wrote: > On Tue, Jun 17, 2025 at 9:36 PM Yonghong Song <yonghong.song@linux.dev> wrote: >> >> >> On 6/16/25 3:00 PM, Andrii Nakryiko wrote: >>> On Sun, Jun 15, 2025 at 11:54 AM Yonghong Song <yonghong.song@linux.dev> wrote: >>>> When building the selftest with arm64/clang20, the following test failed: >>>> ... >>>> ubtest_multispec_usdt:PASS:usdt_100_called 0 nsec >>>> subtest_multispec_usdt:PASS:usdt_100_sum 0 nsec >>>> subtest_multispec_usdt:FAIL:usdt_300_bad_attach unexpected pointer: 0xaaaad82a2a80 >>>> #469/2 usdt/multispec:FAIL >>>> #469 usdt:FAIL >>>> >>>> The failed assertion >>>> subtest_multispec_usdt:FAIL:usdt_300_bad_attach unexpected pointer: 0xaaaad82a2a80 >>>> is caused by bpf_program__attach_usdt() which is expected to fail. But >>>> with arm64/clang20 bpf_program__attach_usdt() actually succeeded. >>> I think I missed that it's unexpected *success* that is causing >>> issues. If that's so, then I think it might be more straightforward to >>> just ensure that test is expectedly failing regardless of compiler >>> code generation logic. Maybe something along the following lines: >>> >>> diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c >>> b/tools/testing/selftests/bpf/prog_tests/usdt.c >>> index 495d66414b57..fdd8642cfdff 100644 >>> --- a/tools/testing/selftests/bpf/prog_tests/usdt.c >>> +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c >>> @@ -190,11 +190,21 @@ static void __always_inline f300(int x) >>> STAP_PROBE1(test, usdt_300, x); >>> } >>> >>> +#define RP10(F, X) F(*(X+0)); F(*(X+1));F(*(X+2)); F(*(X+3)); F(*(X+4)); \ >>> + F(*(X+5)); F(*(X+6)); F(*(X+7)); F(*(X+8)); F(*(X+9)); >>> +#define RP100(F, X) RP10(F,X+ >>> 0);RP10(F,X+10);RP10(F,X+20);RP10(F,X+30);RP10(F,X+40); \ >>> + >>> RP10(F,X+50);RP10(F,X+60);RP10(F,X+70);RP10(F,X+80);RP10(F,X+90); >>> + >>> __weak void trigger_300_usdts(void) >>> { >>> - R100(f300, 0); >>> - R100(f300, 100); >>> - R100(f300, 200); >>> + volatile int arr[300], i; >>> + >>> + for (i = 0; i < 300; i++) >>> + arr[i] = 300; >>> + >>> + RP100(f300, arr + 0); >>> + RP100(f300, arr + 100); >>> + RP100(f300, arr + 200); >>> } >>> >>> >>> So basically force the compiler to use 300 different locations for >>> each of 300 USDT instantiations? I didn't check how that will look >>> like on arm64, but on x86 gcc it seems to generate what is expected of >>> it. >>> >>> Can you please try it on arm64 and see if that works? >> I tried the above on arm64 and it does not work. It has the same usdt arguments >> as without this patch: >> >> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt_300 >> Location: 0x00000000000009e0, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >> Arguments: -4@[x9] >> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt_300 >> Location: 0x00000000000009f8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >> Arguments: -4@[x9] >> ... >> >> But I found if we build usdt.c file with -O2 (RELEASE=1) on arm64, the test will be successful: >> >> stapsdt 0x0000002b NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt_300 >> Location: 0x00000000000001a4, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >> Arguments: -4@0 >> stapsdt 0x0000002b NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt_300 >> Location: 0x00000000000001a8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >> Arguments: -4@1 >> ... >> >> But usdt.c with -O2 will have a problem with gcc14 on x86: >> >> stapsdt 0x00000087 NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt12 >> Location: 0x000000000000258f, Base: 0x0000000000000000, Semaphore: 0x0000000000000006 >> Arguments: -4@$2 -4@$3 -8@$42 -8@$44 -4@$5 -8@$6 8@%rdx 8@%rsi -4@$-9 -2@%cx -2@nums(%rax,%rax) -1@t1+4(%rip) >> ... >> >> You can see the above last two arguments which are not supported by libbpf. >> >> So let us say usdt.c is compiled with -O2: >> x86: >> gcc14 built kernel/selftests: failed, see the above >> clang built kernel/selftests: good >> arm64: >> both gcc14/clang built kernel/selftrests: good >> >> arm64 has more reigsters so it is likely to have better argument representation, e.g., >> for arm64/gcc with -O2, we have >> >> stapsdt 0x00000071 NT_STAPSDT (SystemTap probe descriptors) >> Provider: test >> Name: usdt12 >> Location: 0x0000000000002e74, Base: 0x0000000000000000, Semaphore: 0x000000000000000a >> Arguments: -4@2 -4@3 -8@42 -8@44 -4@5 -8@6 8@x1 8@x3 -4@-9 -2@x2 -2@[x0, 8] -1@[x3, 28] >> >> Eduard helped me to figure out how to compile prog_tests/usdt.c with -O2 alone. >> The following patch resolved the issue and usdt test will be happy for both x86 and arm64: >> >> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile >> index 97013c49920b..05fc9149bc4f 100644 >> --- a/tools/testing/selftests/bpf/Makefile >> +++ b/tools/testing/selftests/bpf/Makefile >> @@ -760,6 +760,14 @@ TRUNNER_BPF_BUILD_RULE := $$(error no BPF objects should be built) >> TRUNNER_BPF_CFLAGS := >> $(eval $(call DEFINE_TEST_RUNNER,test_maps)) >> >> +# Compiler prog_tests/usdt.c with -O2 with clang compiler. >> +# Otherwise, with -O0 on arm64, the usdt test will fail. >> +ifneq ($(LLVM),) >> +$(OUTPUT)/usdt.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS)) >> +$(OUTPUT)/cpuv4/usdt.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS)) >> +$(OUTPUT)/no_alu32/usdt.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS)) >> +endif >> + >> # Define test_verifier test runner. >> # It is much simpler than test_maps/test_progs and sufficiently different from >> # them (e.g., test.h is using completely pattern), that it's worth just >> >> Another choice is to support argument like `-2@nums(%rax,%rax)` and `-1@t1+4(%rip)`. >> But I am not sure whether we should do it or not as typically a usdt probe >> probably won't have lots of diverse arguments. >> >> WDYT? > Can we just make that part of the test x86-64 specific for now? All > other alternatives seem worse, tbh. So something like below? diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c index 495d66414b57..1e7e222034f7 100644 --- a/tools/testing/selftests/bpf/prog_tests/usdt.c +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c @@ -270,8 +270,16 @@ static void subtest_multispec_usdt(void) */ trigger_300_usdts(); - /* we'll reuse usdt_100 BPF program for usdt_300 test */ bpf_link__destroy(skel->links.usdt_100); + + /* If built with clang with arm64 target, there will be much less + * number of specs for usdt_300 call sites. + */ +#if defined(__clang__) && defined(__aarch64__) + bss->usdt_100_called = 0; + bss->usdt_100_sum = 0; +#else + /* we'll reuse usdt_100 BPF program for usdt_300 test */ skel->links.usdt_100 = bpf_program__attach_usdt(skel->progs.usdt_100, -1, "/proc/self/exe", "test", "usdt_300", NULL); err = -errno; @@ -289,6 +297,7 @@ static void subtest_multispec_usdt(void) ASSERT_EQ(bss->usdt_100_called, 0, "usdt_301_called"); ASSERT_EQ(bss->usdt_100_sum, 0, "usdt_301_sum"); +#endif /* This time we have USDT with 400 inlined invocations, but arg specs * should be the same across all sites, so libbpf will only need to ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest 2025-06-24 16:15 ` Yonghong Song @ 2025-06-24 19:48 ` Andrii Nakryiko 2025-06-24 20:21 ` Yonghong Song 0 siblings, 1 reply; 12+ messages in thread From: Andrii Nakryiko @ 2025-06-24 19:48 UTC (permalink / raw) To: Yonghong Song Cc: bpf, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, kernel-team, Martin KaFai Lau On Tue, Jun 24, 2025 at 9:15 AM Yonghong Song <yonghong.song@linux.dev> wrote: > > > > On 6/24/25 8:36 AM, Andrii Nakryiko wrote: > > On Tue, Jun 17, 2025 at 9:36 PM Yonghong Song <yonghong.song@linux.dev> wrote: > >> > >> > >> On 6/16/25 3:00 PM, Andrii Nakryiko wrote: > >>> On Sun, Jun 15, 2025 at 11:54 AM Yonghong Song <yonghong.song@linux.dev> wrote: > >>>> When building the selftest with arm64/clang20, the following test failed: > >>>> ... > >>>> ubtest_multispec_usdt:PASS:usdt_100_called 0 nsec > >>>> subtest_multispec_usdt:PASS:usdt_100_sum 0 nsec > >>>> subtest_multispec_usdt:FAIL:usdt_300_bad_attach unexpected pointer: 0xaaaad82a2a80 > >>>> #469/2 usdt/multispec:FAIL > >>>> #469 usdt:FAIL > >>>> > >>>> The failed assertion > >>>> subtest_multispec_usdt:FAIL:usdt_300_bad_attach unexpected pointer: 0xaaaad82a2a80 > >>>> is caused by bpf_program__attach_usdt() which is expected to fail. But > >>>> with arm64/clang20 bpf_program__attach_usdt() actually succeeded. > >>> I think I missed that it's unexpected *success* that is causing > >>> issues. If that's so, then I think it might be more straightforward to > >>> just ensure that test is expectedly failing regardless of compiler > >>> code generation logic. Maybe something along the following lines: > >>> > >>> diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c > >>> b/tools/testing/selftests/bpf/prog_tests/usdt.c > >>> index 495d66414b57..fdd8642cfdff 100644 > >>> --- a/tools/testing/selftests/bpf/prog_tests/usdt.c > >>> +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c > >>> @@ -190,11 +190,21 @@ static void __always_inline f300(int x) > >>> STAP_PROBE1(test, usdt_300, x); > >>> } > >>> > >>> +#define RP10(F, X) F(*(X+0)); F(*(X+1));F(*(X+2)); F(*(X+3)); F(*(X+4)); \ > >>> + F(*(X+5)); F(*(X+6)); F(*(X+7)); F(*(X+8)); F(*(X+9)); > >>> +#define RP100(F, X) RP10(F,X+ > >>> 0);RP10(F,X+10);RP10(F,X+20);RP10(F,X+30);RP10(F,X+40); \ > >>> + > >>> RP10(F,X+50);RP10(F,X+60);RP10(F,X+70);RP10(F,X+80);RP10(F,X+90); > >>> + > >>> __weak void trigger_300_usdts(void) > >>> { > >>> - R100(f300, 0); > >>> - R100(f300, 100); > >>> - R100(f300, 200); > >>> + volatile int arr[300], i; > >>> + > >>> + for (i = 0; i < 300; i++) > >>> + arr[i] = 300; > >>> + > >>> + RP100(f300, arr + 0); > >>> + RP100(f300, arr + 100); > >>> + RP100(f300, arr + 200); > >>> } > >>> > >>> > >>> So basically force the compiler to use 300 different locations for > >>> each of 300 USDT instantiations? I didn't check how that will look > >>> like on arm64, but on x86 gcc it seems to generate what is expected of > >>> it. > >>> > >>> Can you please try it on arm64 and see if that works? > >> I tried the above on arm64 and it does not work. It has the same usdt arguments > >> as without this patch: > >> > >> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt_300 > >> Location: 0x00000000000009e0, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > >> Arguments: -4@[x9] > >> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt_300 > >> Location: 0x00000000000009f8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > >> Arguments: -4@[x9] > >> ... > >> > >> But I found if we build usdt.c file with -O2 (RELEASE=1) on arm64, the test will be successful: > >> > >> stapsdt 0x0000002b NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt_300 > >> Location: 0x00000000000001a4, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > >> Arguments: -4@0 > >> stapsdt 0x0000002b NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt_300 > >> Location: 0x00000000000001a8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 > >> Arguments: -4@1 > >> ... > >> > >> But usdt.c with -O2 will have a problem with gcc14 on x86: > >> > >> stapsdt 0x00000087 NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt12 > >> Location: 0x000000000000258f, Base: 0x0000000000000000, Semaphore: 0x0000000000000006 > >> Arguments: -4@$2 -4@$3 -8@$42 -8@$44 -4@$5 -8@$6 8@%rdx 8@%rsi -4@$-9 -2@%cx -2@nums(%rax,%rax) -1@t1+4(%rip) > >> ... > >> > >> You can see the above last two arguments which are not supported by libbpf. > >> > >> So let us say usdt.c is compiled with -O2: > >> x86: > >> gcc14 built kernel/selftests: failed, see the above > >> clang built kernel/selftests: good > >> arm64: > >> both gcc14/clang built kernel/selftrests: good > >> > >> arm64 has more reigsters so it is likely to have better argument representation, e.g., > >> for arm64/gcc with -O2, we have > >> > >> stapsdt 0x00000071 NT_STAPSDT (SystemTap probe descriptors) > >> Provider: test > >> Name: usdt12 > >> Location: 0x0000000000002e74, Base: 0x0000000000000000, Semaphore: 0x000000000000000a > >> Arguments: -4@2 -4@3 -8@42 -8@44 -4@5 -8@6 8@x1 8@x3 -4@-9 -2@x2 -2@[x0, 8] -1@[x3, 28] > >> > >> Eduard helped me to figure out how to compile prog_tests/usdt.c with -O2 alone. > >> The following patch resolved the issue and usdt test will be happy for both x86 and arm64: > >> > >> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile > >> index 97013c49920b..05fc9149bc4f 100644 > >> --- a/tools/testing/selftests/bpf/Makefile > >> +++ b/tools/testing/selftests/bpf/Makefile > >> @@ -760,6 +760,14 @@ TRUNNER_BPF_BUILD_RULE := $$(error no BPF objects should be built) > >> TRUNNER_BPF_CFLAGS := > >> $(eval $(call DEFINE_TEST_RUNNER,test_maps)) > >> > >> +# Compiler prog_tests/usdt.c with -O2 with clang compiler. > >> +# Otherwise, with -O0 on arm64, the usdt test will fail. > >> +ifneq ($(LLVM),) > >> +$(OUTPUT)/usdt.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS)) > >> +$(OUTPUT)/cpuv4/usdt.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS)) > >> +$(OUTPUT)/no_alu32/usdt.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS)) > >> +endif > >> + > >> # Define test_verifier test runner. > >> # It is much simpler than test_maps/test_progs and sufficiently different from > >> # them (e.g., test.h is using completely pattern), that it's worth just > >> > >> Another choice is to support argument like `-2@nums(%rax,%rax)` and `-1@t1+4(%rip)`. > >> But I am not sure whether we should do it or not as typically a usdt probe > >> probably won't have lots of diverse arguments. > >> > >> WDYT? > > Can we just make that part of the test x86-64 specific for now? All > > other alternatives seem worse, tbh. > > So something like below? > > diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c > index 495d66414b57..1e7e222034f7 100644 > --- a/tools/testing/selftests/bpf/prog_tests/usdt.c > +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c > @@ -270,8 +270,16 @@ static void subtest_multispec_usdt(void) > */ > trigger_300_usdts(); > > - /* we'll reuse usdt_100 BPF program for usdt_300 test */ > bpf_link__destroy(skel->links.usdt_100); > + > + /* If built with clang with arm64 target, there will be much less > + * number of specs for usdt_300 call sites. > + */ > +#if defined(__clang__) && defined(__aarch64__) > + bss->usdt_100_called = 0; > + bss->usdt_100_sum = 0; I'd add this right before usdt_400 attachment unconditionally and avoid #if/#else/#endif branching. But other than that, yeah, something like that. > +#else > + /* we'll reuse usdt_100 BPF program for usdt_300 test */ > skel->links.usdt_100 = bpf_program__attach_usdt(skel->progs.usdt_100, -1, "/proc/self/exe", > "test", "usdt_300", NULL); > err = -errno; > @@ -289,6 +297,7 @@ static void subtest_multispec_usdt(void) > > ASSERT_EQ(bss->usdt_100_called, 0, "usdt_301_called"); > ASSERT_EQ(bss->usdt_100_sum, 0, "usdt_301_sum"); > +#endif > > /* This time we have USDT with 400 inlined invocations, but arg specs > * should be the same across all sites, so libbpf will only need to > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest 2025-06-24 19:48 ` Andrii Nakryiko @ 2025-06-24 20:21 ` Yonghong Song 0 siblings, 0 replies; 12+ messages in thread From: Yonghong Song @ 2025-06-24 20:21 UTC (permalink / raw) To: Andrii Nakryiko Cc: bpf, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, kernel-team, Martin KaFai Lau On 6/24/25 12:48 PM, Andrii Nakryiko wrote: > On Tue, Jun 24, 2025 at 9:15 AM Yonghong Song <yonghong.song@linux.dev> wrote: >> >> >> On 6/24/25 8:36 AM, Andrii Nakryiko wrote: >>> On Tue, Jun 17, 2025 at 9:36 PM Yonghong Song <yonghong.song@linux.dev> wrote: >>>> >>>> On 6/16/25 3:00 PM, Andrii Nakryiko wrote: >>>>> On Sun, Jun 15, 2025 at 11:54 AM Yonghong Song <yonghong.song@linux.dev> wrote: >>>>>> When building the selftest with arm64/clang20, the following test failed: >>>>>> ... >>>>>> ubtest_multispec_usdt:PASS:usdt_100_called 0 nsec >>>>>> subtest_multispec_usdt:PASS:usdt_100_sum 0 nsec >>>>>> subtest_multispec_usdt:FAIL:usdt_300_bad_attach unexpected pointer: 0xaaaad82a2a80 >>>>>> #469/2 usdt/multispec:FAIL >>>>>> #469 usdt:FAIL >>>>>> >>>>>> The failed assertion >>>>>> subtest_multispec_usdt:FAIL:usdt_300_bad_attach unexpected pointer: 0xaaaad82a2a80 >>>>>> is caused by bpf_program__attach_usdt() which is expected to fail. But >>>>>> with arm64/clang20 bpf_program__attach_usdt() actually succeeded. >>>>> I think I missed that it's unexpected *success* that is causing >>>>> issues. If that's so, then I think it might be more straightforward to >>>>> just ensure that test is expectedly failing regardless of compiler >>>>> code generation logic. Maybe something along the following lines: >>>>> >>>>> diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c >>>>> b/tools/testing/selftests/bpf/prog_tests/usdt.c >>>>> index 495d66414b57..fdd8642cfdff 100644 >>>>> --- a/tools/testing/selftests/bpf/prog_tests/usdt.c >>>>> +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c >>>>> @@ -190,11 +190,21 @@ static void __always_inline f300(int x) >>>>> STAP_PROBE1(test, usdt_300, x); >>>>> } >>>>> >>>>> +#define RP10(F, X) F(*(X+0)); F(*(X+1));F(*(X+2)); F(*(X+3)); F(*(X+4)); \ >>>>> + F(*(X+5)); F(*(X+6)); F(*(X+7)); F(*(X+8)); F(*(X+9)); >>>>> +#define RP100(F, X) RP10(F,X+ >>>>> 0);RP10(F,X+10);RP10(F,X+20);RP10(F,X+30);RP10(F,X+40); \ >>>>> + >>>>> RP10(F,X+50);RP10(F,X+60);RP10(F,X+70);RP10(F,X+80);RP10(F,X+90); >>>>> + >>>>> __weak void trigger_300_usdts(void) >>>>> { >>>>> - R100(f300, 0); >>>>> - R100(f300, 100); >>>>> - R100(f300, 200); >>>>> + volatile int arr[300], i; >>>>> + >>>>> + for (i = 0; i < 300; i++) >>>>> + arr[i] = 300; >>>>> + >>>>> + RP100(f300, arr + 0); >>>>> + RP100(f300, arr + 100); >>>>> + RP100(f300, arr + 200); >>>>> } >>>>> >>>>> >>>>> So basically force the compiler to use 300 different locations for >>>>> each of 300 USDT instantiations? I didn't check how that will look >>>>> like on arm64, but on x86 gcc it seems to generate what is expected of >>>>> it. >>>>> >>>>> Can you please try it on arm64 and see if that works? >>>> I tried the above on arm64 and it does not work. It has the same usdt arguments >>>> as without this patch: >>>> >>>> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) >>>> Provider: test >>>> Name: usdt_300 >>>> Location: 0x00000000000009e0, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >>>> Arguments: -4@[x9] >>>> stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) >>>> Provider: test >>>> Name: usdt_300 >>>> Location: 0x00000000000009f8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >>>> Arguments: -4@[x9] >>>> ... >>>> >>>> But I found if we build usdt.c file with -O2 (RELEASE=1) on arm64, the test will be successful: >>>> >>>> stapsdt 0x0000002b NT_STAPSDT (SystemTap probe descriptors) >>>> Provider: test >>>> Name: usdt_300 >>>> Location: 0x00000000000001a4, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >>>> Arguments: -4@0 >>>> stapsdt 0x0000002b NT_STAPSDT (SystemTap probe descriptors) >>>> Provider: test >>>> Name: usdt_300 >>>> Location: 0x00000000000001a8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 >>>> Arguments: -4@1 >>>> ... >>>> >>>> But usdt.c with -O2 will have a problem with gcc14 on x86: >>>> >>>> stapsdt 0x00000087 NT_STAPSDT (SystemTap probe descriptors) >>>> Provider: test >>>> Name: usdt12 >>>> Location: 0x000000000000258f, Base: 0x0000000000000000, Semaphore: 0x0000000000000006 >>>> Arguments: -4@$2 -4@$3 -8@$42 -8@$44 -4@$5 -8@$6 8@%rdx 8@%rsi -4@$-9 -2@%cx -2@nums(%rax,%rax) -1@t1+4(%rip) >>>> ... >>>> >>>> You can see the above last two arguments which are not supported by libbpf. >>>> >>>> So let us say usdt.c is compiled with -O2: >>>> x86: >>>> gcc14 built kernel/selftests: failed, see the above >>>> clang built kernel/selftests: good >>>> arm64: >>>> both gcc14/clang built kernel/selftrests: good >>>> >>>> arm64 has more reigsters so it is likely to have better argument representation, e.g., >>>> for arm64/gcc with -O2, we have >>>> >>>> stapsdt 0x00000071 NT_STAPSDT (SystemTap probe descriptors) >>>> Provider: test >>>> Name: usdt12 >>>> Location: 0x0000000000002e74, Base: 0x0000000000000000, Semaphore: 0x000000000000000a >>>> Arguments: -4@2 -4@3 -8@42 -8@44 -4@5 -8@6 8@x1 8@x3 -4@-9 -2@x2 -2@[x0, 8] -1@[x3, 28] >>>> >>>> Eduard helped me to figure out how to compile prog_tests/usdt.c with -O2 alone. >>>> The following patch resolved the issue and usdt test will be happy for both x86 and arm64: >>>> >>>> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile >>>> index 97013c49920b..05fc9149bc4f 100644 >>>> --- a/tools/testing/selftests/bpf/Makefile >>>> +++ b/tools/testing/selftests/bpf/Makefile >>>> @@ -760,6 +760,14 @@ TRUNNER_BPF_BUILD_RULE := $$(error no BPF objects should be built) >>>> TRUNNER_BPF_CFLAGS := >>>> $(eval $(call DEFINE_TEST_RUNNER,test_maps)) >>>> >>>> +# Compiler prog_tests/usdt.c with -O2 with clang compiler. >>>> +# Otherwise, with -O0 on arm64, the usdt test will fail. >>>> +ifneq ($(LLVM),) >>>> +$(OUTPUT)/usdt.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS)) >>>> +$(OUTPUT)/cpuv4/usdt.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS)) >>>> +$(OUTPUT)/no_alu32/usdt.test.o: CFLAGS:=$(subst O0,O2,$(CFLAGS)) >>>> +endif >>>> + >>>> # Define test_verifier test runner. >>>> # It is much simpler than test_maps/test_progs and sufficiently different from >>>> # them (e.g., test.h is using completely pattern), that it's worth just >>>> >>>> Another choice is to support argument like `-2@nums(%rax,%rax)` and `-1@t1+4(%rip)`. >>>> But I am not sure whether we should do it or not as typically a usdt probe >>>> probably won't have lots of diverse arguments. >>>> >>>> WDYT? >>> Can we just make that part of the test x86-64 specific for now? All >>> other alternatives seem worse, tbh. >> So something like below? >> >> diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c >> index 495d66414b57..1e7e222034f7 100644 >> --- a/tools/testing/selftests/bpf/prog_tests/usdt.c >> +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c >> @@ -270,8 +270,16 @@ static void subtest_multispec_usdt(void) >> */ >> trigger_300_usdts(); >> >> - /* we'll reuse usdt_100 BPF program for usdt_300 test */ >> bpf_link__destroy(skel->links.usdt_100); >> + >> + /* If built with clang with arm64 target, there will be much less >> + * number of specs for usdt_300 call sites. >> + */ >> +#if defined(__clang__) && defined(__aarch64__) >> + bss->usdt_100_called = 0; >> + bss->usdt_100_sum = 0; > I'd add this right before usdt_400 attachment unconditionally and > avoid #if/#else/#endif branching. But other than that, yeah, something > like that. Sounds good to me! > >> +#else >> + /* we'll reuse usdt_100 BPF program for usdt_300 test */ >> skel->links.usdt_100 = bpf_program__attach_usdt(skel->progs.usdt_100, -1, "/proc/self/exe", >> "test", "usdt_300", NULL); >> err = -errno; >> @@ -289,6 +297,7 @@ static void subtest_multispec_usdt(void) >> >> ASSERT_EQ(bss->usdt_100_called, 0, "usdt_301_called"); >> ASSERT_EQ(bss->usdt_100_sum, 0, "usdt_301_sum"); >> +#endif >> >> /* This time we have USDT with 400 inlined invocations, but arg specs >> * should be the same across all sites, so libbpf will only need to >> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH bpf-next v2 2/3] selftests/bpf: Add test_usdt_multispec.inc.h for sharing between multiple progs 2025-06-15 18:53 [PATCH bpf-next v2 0/3] selftests/bpf: Fix usdt/multispec failure with arm64/clang20 Yonghong Song 2025-06-15 18:53 ` [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest Yonghong Song @ 2025-06-15 18:53 ` Yonghong Song 2025-06-15 18:54 ` [PATCH bpf-next v2 3/3] selftests/bpf: Add subtest usdt_multispec_fail with adjustable BPF_USDT_MAX_SPEC_CNT Yonghong Song 2 siblings, 0 replies; 12+ messages in thread From: Yonghong Song @ 2025-06-15 18:53 UTC (permalink / raw) To: bpf Cc: Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, kernel-team, Martin KaFai Lau Replace test_usdt_multispec.c to test_usdt_multispec.inc.h so the bpf prog usdt_100 can be used for multiple bpf programs. The newer test_usdt_multispec.c will just include test_usdt_multispec.inc.h. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> --- .../selftests/bpf/progs/test_usdt_multispec.c | 28 +---------------- .../bpf/progs/test_usdt_multispec.inc.h | 30 +++++++++++++++++++ 2 files changed, 31 insertions(+), 27 deletions(-) create mode 100644 tools/testing/selftests/bpf/progs/test_usdt_multispec.inc.h diff --git a/tools/testing/selftests/bpf/progs/test_usdt_multispec.c b/tools/testing/selftests/bpf/progs/test_usdt_multispec.c index 962f3462066a..97c6082df328 100644 --- a/tools/testing/selftests/bpf/progs/test_usdt_multispec.c +++ b/tools/testing/selftests/bpf/progs/test_usdt_multispec.c @@ -1,30 +1,4 @@ // SPDX-License-Identifier: GPL-2.0 /* Copyright (c) 2022 Meta Platforms, Inc. and affiliates. */ -#include "vmlinux.h" -#include <bpf/bpf_helpers.h> -#include <bpf/usdt.bpf.h> - -/* this file is linked together with test_usdt.c to validate that usdt.bpf.h - * can be included in multiple .bpf.c files forming single final BPF object - * file - */ - -extern int my_pid; - -int usdt_100_called; -int usdt_100_sum; - -SEC("usdt//proc/self/exe:test:usdt_100") -int BPF_USDT(usdt_100, int x) -{ - if (my_pid != (bpf_get_current_pid_tgid() >> 32)) - return 0; - - __sync_fetch_and_add(&usdt_100_called, 1); - __sync_fetch_and_add(&usdt_100_sum, x); - - return 0; -} - -char _license[] SEC("license") = "GPL"; +#include "test_usdt_multispec.inc.h" diff --git a/tools/testing/selftests/bpf/progs/test_usdt_multispec.inc.h b/tools/testing/selftests/bpf/progs/test_usdt_multispec.inc.h new file mode 100644 index 000000000000..962f3462066a --- /dev/null +++ b/tools/testing/selftests/bpf/progs/test_usdt_multispec.inc.h @@ -0,0 +1,30 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2022 Meta Platforms, Inc. and affiliates. */ + +#include "vmlinux.h" +#include <bpf/bpf_helpers.h> +#include <bpf/usdt.bpf.h> + +/* this file is linked together with test_usdt.c to validate that usdt.bpf.h + * can be included in multiple .bpf.c files forming single final BPF object + * file + */ + +extern int my_pid; + +int usdt_100_called; +int usdt_100_sum; + +SEC("usdt//proc/self/exe:test:usdt_100") +int BPF_USDT(usdt_100, int x) +{ + if (my_pid != (bpf_get_current_pid_tgid() >> 32)) + return 0; + + __sync_fetch_and_add(&usdt_100_called, 1); + __sync_fetch_and_add(&usdt_100_sum, x); + + return 0; +} + +char _license[] SEC("license") = "GPL"; -- 2.47.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH bpf-next v2 3/3] selftests/bpf: Add subtest usdt_multispec_fail with adjustable BPF_USDT_MAX_SPEC_CNT 2025-06-15 18:53 [PATCH bpf-next v2 0/3] selftests/bpf: Fix usdt/multispec failure with arm64/clang20 Yonghong Song 2025-06-15 18:53 ` [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest Yonghong Song 2025-06-15 18:53 ` [PATCH bpf-next v2 2/3] selftests/bpf: Add test_usdt_multispec.inc.h for sharing between multiple progs Yonghong Song @ 2025-06-15 18:54 ` Yonghong Song 2 siblings, 0 replies; 12+ messages in thread From: Yonghong Song @ 2025-06-15 18:54 UTC (permalink / raw) To: bpf Cc: Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, kernel-team, Martin KaFai Lau Add udst_multispec_fail subtest. For arm64/clang20 build, the BPF_USDT_MAX_SPEC_CNT is set to 2. Otherwise, the BPF_USDT_MAX_SPEC_CNT remains the default value 256. This resolved the previous test failure. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> --- tools/testing/selftests/bpf/prog_tests/usdt.c | 7 ++++--- .../selftests/bpf/progs/test_usdt_multispec_fail.c | 10 ++++++++++ 2 files changed, 14 insertions(+), 3 deletions(-) create mode 100644 tools/testing/selftests/bpf/progs/test_usdt_multispec_fail.c diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c index dc29ef94312a..cc7f38b03a96 100644 --- a/tools/testing/selftests/bpf/prog_tests/usdt.c +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c @@ -7,6 +7,7 @@ #include "test_usdt.skel.h" #include "test_urandom_usdt.skel.h" +#include "test_usdt_multispec_fail.skel.h" int lets_test_this(int); @@ -305,10 +306,10 @@ static void subtest_multispec_usdt(void) static void subtest_multispec_fail_usdt(void) { LIBBPF_OPTS(bpf_usdt_opts, opts); - struct test_usdt *skel; + struct test_usdt_multispec_fail *skel; int err; - skel = test_usdt__open_and_load(); + skel = test_usdt_multispec_fail__open_and_load(); if (!ASSERT_OK_PTR(skel, "skel_open")) return; @@ -322,7 +323,7 @@ static void subtest_multispec_fail_usdt(void) ASSERT_EQ(err, -E2BIG, "usdt_300_attach_err"); cleanup: - test_usdt__destroy(skel); + test_usdt_multispec_fail__destroy(skel); } static FILE *urand_spawn(int *pid) diff --git a/tools/testing/selftests/bpf/progs/test_usdt_multispec_fail.c b/tools/testing/selftests/bpf/progs/test_usdt_multispec_fail.c new file mode 100644 index 000000000000..4cca3d8d45fb --- /dev/null +++ b/tools/testing/selftests/bpf/progs/test_usdt_multispec_fail.c @@ -0,0 +1,10 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2025 Meta Platforms, Inc. and affiliates. */ + +#if defined(__clang__) && defined(__TARGET_ARCH_arm64) +#define BPF_USDT_MAX_SPEC_CNT 2 +#endif + +int my_pid; + +#include "test_usdt_multispec.inc.h" -- 2.47.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
end of thread, other threads:[~2025-06-24 20:22 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-06-15 18:53 [PATCH bpf-next v2 0/3] selftests/bpf: Fix usdt/multispec failure with arm64/clang20 Yonghong Song 2025-06-15 18:53 ` [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest Yonghong Song 2025-06-16 8:33 ` Jiri Olsa 2025-06-16 15:48 ` Yonghong Song 2025-06-16 22:00 ` Andrii Nakryiko 2025-06-18 4:36 ` Yonghong Song 2025-06-24 15:36 ` Andrii Nakryiko 2025-06-24 16:15 ` Yonghong Song 2025-06-24 19:48 ` Andrii Nakryiko 2025-06-24 20:21 ` Yonghong Song 2025-06-15 18:53 ` [PATCH bpf-next v2 2/3] selftests/bpf: Add test_usdt_multispec.inc.h for sharing between multiple progs Yonghong Song 2025-06-15 18:54 ` [PATCH bpf-next v2 3/3] selftests/bpf: Add subtest usdt_multispec_fail with adjustable BPF_USDT_MAX_SPEC_CNT Yonghong Song
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).