linux-kernel - Re:Re: [PATCH bpf-next v13 2/2] selftests/bpf: Enrich subtest_basic_usdt case in selftests to cover SIB handling logic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <530fff84.d87.198d4dd1fb8.Coremail.phoenix500526@163.com>
Date: Sat, 23 Aug 2025 10:58:38 +0800 (CST)
From: 赵佳炜 <phoenix500526@....com>
To: "Andrii Nakryiko" <andrii.nakryiko@...il.com>
Cc: ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
	yonghong.song@...ux.dev, bpf@...r.kernel.org,
	linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re:Re: [PATCH bpf-next v13 2/2] selftests/bpf: Enrich
 subtest_basic_usdt case in selftests to cover SIB handling logic







>does clang define __GNUC__ as well? otherwise why !define(__clang__) ?

Yes, clang does defind __GNUC__ .



>you use assembly directly, so optimize() should be irrelevant, no?
>
>So we can make this non-GCC specific, right?

Yes, I'll make it in the next version.


>is it guaranteed that nums address will end up in rdx and a in rax?...
>
>I'd feel more comfortable if you explicitly set up rdx and rax in
>assembly, then add USDT with STAP_PROBE_ASM. That should be possible
>with embedded assembly, no?

I think it will in that the input operand constrain `"d"(nums), "a"(0)` implies
the nums address will end up in rdx while the index 0 will be in rax. 

So I think we don't need to explicitly set up rdx and rax again. 


>why these unnecessary comments embedded in the assembly?...

Because there is "before" and "after" in the `STAP_PROBE_ASM` example.
It's OK to remove it. 


At 2025-08-23 06:59:49, "Andrii Nakryiko" <andrii.nakryiko@...il.com> wrote:
>On Fri, Aug 22, 2025 at 8:16 AM Jiawei Zhao <phoenix500526@....com> wrote:
>>
>> When using GCC on x86-64 to compile an usdt prog with -O1 or higher
>> optimization, the compiler will generate SIB addressing mode for global
>> array and PC-relative addressing mode for global variable,
>> e.g. "1@-96(%rbp,%rax,8)" and "-1@...1(%rip)".
>>
>> In this patch:
>> - enrich subtest_basic_usdt test case to cover SIB addressing usdt argument spec
>>   handling logic
>>
>> Signed-off-by: Jiawei Zhao <phoenix500526@....com>
>> ---
>>  tools/testing/selftests/bpf/prog_tests/usdt.c | 44 ++++++++++++++++++-
>>  tools/testing/selftests/bpf/progs/test_usdt.c | 30 +++++++++++++
>>  2 files changed, 72 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c
>> index 9057e983cc54..c04b416aa4a8 100644
>> --- a/tools/testing/selftests/bpf/prog_tests/usdt.c
>> +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c
>> @@ -25,6 +25,10 @@ unsigned short test_usdt0_semaphore SEC(".probes");
>>  unsigned short test_usdt3_semaphore SEC(".probes");
>>  unsigned short test_usdt12_semaphore SEC(".probes");
>>
>> +#if ((defined(__x86_64__) || defined(__i386__)) && defined(__GNUC__) && !defined(__clang__))
>
>does clang define __GNUC__ as well? otherwise why !define(__clang__) ?
>
>> +unsigned short test_usdt_sib_semaphore SEC(".probes");
>> +#endif
>> +
>>  static void __always_inline trigger_func(int x) {
>>         long y = 42;
>>
>> @@ -40,12 +44,29 @@ static void __always_inline trigger_func(int x) {
>>         }
>>  }
>>
>> +#if ((defined(__x86_64__) || defined(__i386__)) && defined(__GNUC__) && !defined(__clang__))
>> +static __attribute__((optimize("O1"))) void trigger_sib_spec(void)
>
>you use assembly directly, so optimize() should be irrelevant, no?
>
>So we can make this non-GCC specific, right?
>
>> +{
>> +       /* Base address + offset + (index * scale) */
>> +       /* Force SIB addressing with inline assembly */
>> +       asm volatile(
>> +               "# probe point with memory access\n"
>> +               STAP_PROBE_ASM(test, usdt_sib, -2@(%%rdx,%%rax,2))
>
>is it guaranteed that nums address will end up in rdx and a in rax?...
>
>I'd feel more comfortable if you explicitly set up rdx and rax in
>assembly, then add USDT with STAP_PROBE_ASM. That should be possible
>with embedded assembly, no?
>
>> +               "# end probe point"
>
>why these unnecessary comments embedded in the assembly?...
>
>> +               :
>> +               : "d"(nums), "a"(0)
>> +               : "memory"
>> +       );
>> +}
>
>[...]
>
>> +
>> +int usdt_sib_called;
>> +u64 usdt_sib_cookie;
>> +int usdt_sib_arg_cnt;
>> +int usdt_sib_arg_ret;
>> +u64 usdt_sib_arg;
>> +int usdt_sib_arg_size;
>> +
>> +// Note: usdt_sib is only tested on x86-related architectures, so it requires
>> +// manual attach since auto-attach will panic tests under other architectures
>
>don't use c++ style comments
>
>> +SEC("usdt")
>> +int usdt_sib(struct pt_regs *ctx)
>> +{
>> +       long tmp;
>> +
>> +       if (my_pid != (bpf_get_current_pid_tgid() >> 32))
>> +               return 0;
>> +
>> +       __sync_fetch_and_add(&usdt_sib_called, 1);
>> +
>> +       usdt_sib_cookie = bpf_usdt_cookie(ctx);
>> +       usdt_sib_arg_cnt = bpf_usdt_arg_cnt(ctx);
>> +
>> +       usdt_sib_arg_ret = bpf_usdt_arg(ctx, 0, &tmp);
>> +       usdt_sib_arg = (short)tmp;
>> +       usdt_sib_arg_size = bpf_usdt_arg_size(ctx, 0);
>> +
>> +       return 0;
>> +}
>> +
>>  char _license[] SEC("license") = "GPL";
>> --
>> 2.43.0
>>