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

[Kris Van Hees]

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
version of binutils is installed on your system (nm -V)?