All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kris Van Hees <kris.van.hees@oracle.com>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: Eugene Loh <eugene.loh@oracle.com>,
	dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [DTrace-devel] [PATCH] test/utils: add more reliable "get remote address" approach
Date: Thu, 3 Jul 2025 14:26:20 -0400	[thread overview]
Message-ID: <aGbLTOzqILN+3J93@oracle.com> (raw)
In-Reply-To: <58cb8219-337e-42ed-ae17-1c4e77894a9c@oracle.com>

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?

I'd really rather not add a type like this to the core set of typedefs we
can avoid it, because it really isn't a core type.

> >>> On 7/3/25 07:33, Alan Maguire via DTrace-devel wrote:
> >>>
> >>>> The current approach of looking for remote addresses
> >>>> is brittle and fails in many environments; it checks the
> >>>> default route gateway and looks for open ports in the TCP
> >>>> case.
> >>>>
> >>>> We can however achieve the same goal reliably by creating
> >>>> a network namespace on the system and configuring either
> >>>> IPv4 or IPv6 addresses on the namespaced and local veth
> >>>> interfaces that support communication between namespaces.
> >>>> If a tcp port is required start sshd to listen on that port.
> >>> Maybe a comma after "required"?
> >>>
> >> yep, will fix.
> >>
> >>>> Teardown is managed in runtest.sh as signal handling for
> >>>> timeouts within the test scripts is not working; a trap
> >>>> function does not trigger for TERM.
> >>> I'm having trouble parsing the text before the semicolon.  I think I
> >>> understand it, but cannot seem to figure out the grammar.
> >> I'll try and rephrase; basically I tried adding a
> >>
> >> trap cleanup TERM
> >>
> >> to the test script to catch a SIGTERM when the test timed out;
> >> unfortunately this didn't trigger when tests timed out so we were left
> >> with network namespaces hanging around.
> >>
> >> How about
> >>
> >> Teardown of network namespaces is managed in the toplevel runtest.sh to
> >> ensure that network namespaces are removed after test completion for all
> >> cases; success, failure and timeout.
> > 
> > Great.  Or how about a colon instead of semicolon?
> 
> Sure!

  reply	other threads:[~2025-07-03 18:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-03 11:33 [PATCH] test/utils: add more reliable "get remote address" approach Alan Maguire
2025-07-03 16:43 ` [DTrace-devel] " Eugene Loh
2025-07-03 16:59   ` Alan Maguire
2025-07-03 17:06     ` Eugene Loh
2025-07-03 18:02       ` Alan Maguire
2025-07-03 18:26         ` Kris Van Hees [this message]
2025-07-03 18:41           ` Alan Maguire
2025-07-03 19:03             ` Kris Van Hees
2025-07-03 20:23               ` Alan Maguire
2025-07-03 20:59                 ` Kris Van Hees
2025-07-03 22:36                   ` Kris Van Hees
2025-07-07 16:32                     ` Alan Maguire
2025-07-07 16:53                       ` Kris Van Hees
2025-07-07 18:14                         ` Alan Maguire
2025-07-07 19:55                           ` Kris Van Hees
2025-07-07 21:51                             ` Alan Maguire
2025-07-08  1:34                               ` Kris Van Hees
2025-07-08 17:19                                 ` Alan Maguire
2025-07-08 17:30                                   ` Kris Van Hees
2025-07-08 19:04                                     ` Alan Maguire
2025-07-08 20:13                                       ` Kris Van Hees

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=aGbLTOzqILN+3J93@oracle.com \
    --to=kris.van.hees@oracle.com \
    --cc=alan.maguire@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=eugene.loh@oracle.com \
    /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.