All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	kernel-team@fb.com, Martin KaFai Lau <martin.lau@kernel.org>
Subject: Re: [PATCH bpf-next v2 1/3] selftests/bpf: Refactor the failed assertion to another subtest
Date: Tue, 17 Jun 2025 21:36:15 -0700	[thread overview]
Message-ID: <b3ce39f0-c52b-4787-980c-973bd4228349@linux.dev> (raw)
In-Reply-To: <CAEf4BzZmzrT7+nB0eyK-iLv+un68VtLY-TAq3G5Pti=sjM41TQ@mail.gmail.com>



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
>>


  reply	other threads:[~2025-06-18  4:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b3ce39f0-c52b-4787-980c-973bd4228349@linux.dev \
    --to=yonghong.song@linux.dev \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    --cc=martin.lau@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.