Re: [DTrace-devel] [PATCH] test/utils: add more reliable "get remote address" approach

[Alan Maguire <alan.maguire@oracle.com>]

On 07/07/2025 20:55, Kris Van Hees wrote:
> On Mon, Jul 07, 2025 at 07:14:35PM +0100, Alan Maguire wrote:
>> On 07/07/2025 17:53, Kris Van Hees wrote:
>>> On Mon, Jul 07, 2025 at 05:32:19PM +0100, Alan Maguire wrote:
>>>> On 03/07/2025 23:36, Kris Van Hees wrote:
>>>>> On Thu, Jul 03, 2025 at 04:59:44PM -0400, Kris Van Hees wrote:
>>>>>> On Thu, Jul 03, 2025 at 09:23:46PM +0100, Alan Maguire wrote:
>>>>>>> On 03/07/2025 20:03, Kris Van Hees wrote:
>>>>>>>> On Thu, Jul 03, 2025 at 07:41:41PM +0100, Alan Maguire wrote:
>>>>>>>>> On 03/07/2025 19:26, Kris Van Hees wrote:
>>>>>>>>>> On Thu, Jul 03, 2025 at 07:02:57PM +0100, Alan Maguire wrote:
>>>>>>>>>>> On 03/07/2025 18:06, Eugene Loh wrote:
>>>>>>>>>>>> On 7/3/25 12:59, Alan Maguire wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 03/07/2025 17:43, Eugene Loh wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tested and it looks good (modulo the OL8 UEK6 issue mentioned in the
>>>>>>>>>>>>>> patch 3/4 feedback).
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Sorry I couldn't find that issue; is this the 5.15 problem with the ip
>>>>>>>>>>>>> send probes?
>>>>>>>>>>>>
>>>>>>>>>>>>     dtrace: failed to compile script /dev/stdin:
>>>>>>>>>>>>     ".../build/dlibs/5.2/tcp.d", line 177: failed to resolve type of
>>>>>>>>>>>> inet_ntoa arg#1 (ipaddr_t *):
>>>>>>>>>>>>     Unknown type name
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ah, sorry yep I have a fix for that one in the next round. Basically we
>>>>>>>>>>> need to add it to the core set of typedefs and add a type for a pointer
>>>>>>>>>>> to ipaddr_t; we can't rely on the #pragma to include net.d unfortunately.
>>>>>>>>>>
>>>>>>>>>> Why can't we rely on the pragma?  That is how e.g. the ip provider manages
>>>>>>>>>> this I believe?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Unfortunately the #pragma include doesn't do enough; it just defines a
>>>>>>>>> type for ipaddr_t , not a type for a _pointer_ to an ipaddr_t , which is
>>>>>>>>> what we need as a parameter to inet_ntoa(). I tried adding the ipaddr_t
>>>>>>>>> typedef to net.d and doing the pointer lookup/addition but that doesn't
>>>>>>>>> work either. Seems we need the core typedef + pointer addition or we hit
>>>>>>>>> this failure.
>>>>>>>>
>>>>>>>> Actually, if you move 'typedef __be32          ipaddr_t;' from ip.d to net.d,
>>>>>>>> you should be set.  That is what I did in my priliminary tcp provider impl.
>>>>>>>> I do believe that works.  Either way, we use inet_ntoa() in the ip.d
>>>>>>>> translators and that works with that typedef in the file, so this really ought
>>>>>>>> to work.
>>>>>>
>>>>>>> Yep, I tried that in the v2 patch series; Eugene hit the undefined error
>>>>>>> in one test and I now hit it consistently for all tcp/ip tests
>>>>>>> unfortunately with "typedef __be32 ipaddr_t;" in net.d.
>>>>>>>
>>>>>>> My assumption (probably wrong) is that the include of the library does
>>>>>>> happen but nothing triggers the pointer type generation for "ipaddr *"
>>>>>>> in the CTF dict. If there was a way to force that type generation at the
>>>>>>> .d file level that would be great, not sure I see a way currently tho.
>>>>>>
>>>>>> Well, like I said, it does work for ip.d so I don't see why this would be
>>>>>> any different.  I'll have a look and see if I can figure something out.
>>>>>
>>>>> Looking into this more, I think the problem is simply that you did not sync
>>>>> all the dlibs for the various kernel versions with the updated ip.d, net.d, and
>>>>> tcp.d files.  So, if the kernel on the OL8 instance you test on does not have
>>>>> your change, it will fail.
>>>>>
>>>>
>>>> No, don't think that's it; the .d files that matched the kernel I tested
>>>> on (6.10) were synced; the use of the 6.10 .d files was visible in the
>>>> error message. The problem appears to be around the fact that tcp.d uses
>>>> the ipaddr_t * in inet_ntoa(), but unlike ip.d (which uses ipaddr_t in
>>>> translated types) it does not have any other mention of ipaddr_t.
>>>> Adding an explicit cast in tcp.d to the argument to inet_ntoa() to
>>>> ipaddr_t * resolves the issue without having to add ipaddr_t to the core
>>>> type list.
>>>
>>> Can you reproduce this at will?  Can you give me specifics on OL version,
>>> kernel version, etc?  I'd like to be able to reproduce what you see, because
>>> so far, all I tried actually works once the ipaddr_t typedef is in net.d.
>>>
>>
>> Yep, it's 100% reproducible for me on an upstream (bpf-next 6.15) kernel
>> + OL9. Moving ipaddr_t to net.d works for ip.d but not tcp.d in that
>> environment. The extra casts for the inet_ntoa() parameters that I
>> mention above are needed in tcp.d to get things to work properly for me.
>>
>> I pushed a branch to
>>
>> https://github.com/alan-maguire/dtrace-utils/tree/remote-tcp-v3-wip-broken
>>
>> that illustrates the failure.
>>
>> Relative to devel, it consists of 6 commits
>>
>> 1: the v2 of the remote IP address change (ensuring the remote address
>> tests won't fail);
>> 2-4: a few prep patches for the tcp provider; and
>> 5: the tcp provider patch (in a v3 work-in-progress form); and finally
>> 6: the top-level commit then removes the casts I added to tcp.d in the
>> previous "tcp: new provider" commit. With that change in place on my
>> system, the previously-passing IP tests start failing.
>>
>> If I "git reset --hard HEAD~1" on that branch (reestablishing those
>> ipaddr_t * casts) and rebuild, the failures go away for me.
> 
> I tested your tree on Debian with the 6.15 kernel, and this is the result:
> 
> $ uname -a
> Linux kvh-deb-bpf3 6.15.0 #1 SMP PREEMPT_DYNAMIC Mon Jul  7 15:19:59 EDT 2025 x86_64 GNU/Linux
> $ cat test/log/current/runtest.sum 
> dtrace: Oracle D 2.0
> This is DTrace 2.0.1
> dtrace(1) version-control ID: cf3219c3069ac51c6f03f7a6dcb50958213466fc
> libdtrace version-control ID: cf3219c3069ac51c6f03f7a6dcb50958213466fc
> Linux kvh-deb-bpf3 6.15.0 #1 SMP PREEMPT_DYNAMIC Mon Jul  7 15:19:59 EDT 2025 x86_64 GNU/Linux
> testsuite version-control ID: cf3219c3069ac51c6f03f7a6dcb50958213466fc
> 
> test/unittest/tcp/tst.ipv4localtcp.sh: PASS.
> test/unittest/tcp/tst.ipv4localtcpstate.sh: PASS.
> test/unittest/tcp/tst.ipv4remotetcp.sh: PASS.
> test/unittest/tcp/tst.ipv4remotetcpstate.sh: PASS.
> test/unittest/tcp/tst.ipv6localtcp.sh: PASS.
> test/unittest/tcp/tst.ipv6localtcpstate.sh: PASS.
> 6 cases (6 PASS, 0 FAIL, 0 XPASS, 0 XFAIL, 0 SKIP)
> 
> I will try to get 6.15 on an OL9 instance and try there, but either way, I
> have a feeling there is a binutils (libctf) discrepancy somewhere?  What

could be; see below..

> version of binutils is installed on your system (nm -V)?

$ nm -V
GNU nm version 2.35.2-42.0.1.el9
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later
version.
This program has absolutely no warranty.

Let me know if you need any more info. Thanks!

Alan