Linux DTrace development list
 help / color / mirror / Atom feed
From: Kris Van Hees <kris.van.hees@oracle.com>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH v3 1/7] libdtrace: Support multiple DTrace handles per process
Date: Wed, 22 Jul 2026 17:09:17 -0400	[thread overview]
Message-ID: <amExffYtEWp6jOzb@oracle.com> (raw)
In-Reply-To: <20260721152452.184842-2-alan.maguire@oracle.com>

On Tue, Jul 21, 2026 at 04:24:45PM +0100, Alan Maguire wrote:
> For use cases like PCP we require multiple DTrace handles
> in a process; to fix this ensure we tie global map creation
> to the handle and also allow BEGIN and END probes to already
> exist.  Later work can capitalize on efficiences like sharing
> kernel type info, but for now this is enough to make multiple
> instances work.
> 
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> ---
>  libdtrace/dt_bpf.c         | 6 ++----
>  libdtrace/dt_impl.h        | 1 +
>  libdtrace/dt_prov_dtrace.c | 6 +++++-
>  3 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/libdtrace/dt_bpf.c b/libdtrace/dt_bpf.c
> index 146a66e3..be8a4229 100644
> --- a/libdtrace/dt_bpf.c
> +++ b/libdtrace/dt_bpf.c
> @@ -25,8 +25,6 @@
>  #include <dt_btf.h>
>  #include <port.h>
> 
> -static boolean_t       dt_gmap_done = 0;
> -
>  #define BPF_CG_LICENSE "GPL";
> 
>  int
> @@ -1076,11 +1074,11 @@ int
>  dt_bpf_gmap_create(dtrace_hdl_t *dtp)
>  {
>         /* If we already created the global maps, return success. */
> -       if (dt_gmap_done)
> +       if (dtp->dt_gmap_done)
>                 return 0;
> 
>         /* Mark global maps creation as completed. */
> -       dt_gmap_done = 1;
> +       dtp->dt_gmap_done = 1;

ACK.

> 
>  #define CREATE_MAP(name) \
>         if (gmap_create_##name(dtp) == -1) \
> diff --git a/libdtrace/dt_impl.h b/libdtrace/dt_impl.h
> index 5282efbd..7db2ba93 100644
> --- a/libdtrace/dt_impl.h
> +++ b/libdtrace/dt_impl.h
> @@ -433,6 +433,7 @@ struct dtrace_hdl {
>         dt_list_t dt_lib_dep_sorted;    /* dependency sorted library list */
>         dt_global_pcap_t dt_pcap; /* global tshark/pcap state */
>         char *dt_freopen_filename; /* filename for freopen() action */
> +       boolean_t dt_gmap_done; /* global map created */

ACK.

>  };
> 
>  /*
> diff --git a/libdtrace/dt_prov_dtrace.c b/libdtrace/dt_prov_dtrace.c
> index 4b788507..8118ab23 100644
> --- a/libdtrace/dt_prov_dtrace.c
> +++ b/libdtrace/dt_prov_dtrace.c
> @@ -243,7 +243,11 @@ static int attach(dtrace_hdl_t *dtp, const dt_probe_t *prp, int bpf_fd)
>                         close(fd);
>                 }
>                 free(spec);
> -               if (rc == -1)
> +               /*
> +                * Multiple handles in a process mean we may have BEGIN/END
> +                * uprobe events already.
> +                * */
> +               if (rc == -1 && errno != EEXIST)
>                         return -ENOENT;

ACK, but I do wonder whether the use case of multiple handles in a process
may cause trouble when one of those handles tries to remove the uprobe for
BEGIN/END?  This really should have a test case that shows that two handles
can be operative at the same time, and also a test that shows that closing one
while keeping the other open does not stop the second one from seeing its own
END probe firing.  Ideally, it would be two test cases:

 - one that creates handles A and B, and then closes A and checks B still works
 - one that creates handles A and B, and then closes B and checks A still works

> 
>                 /* open format file */
> --
> 2.43.5
> 
> 
> 

  reply	other threads:[~2026-07-22 21:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-21 15:24 [PATCH v3 0/7] Add python bindings for libdtrace interfaces Alan Maguire
2026-07-21 15:24 ` [PATCH v3 1/7] libdtrace: Support multiple DTrace handles per process Alan Maguire
2026-07-22 21:09   ` Kris Van Hees [this message]
2026-07-23 12:33     ` Alan Maguire
2026-07-21 15:24 ` [PATCH v3 2/7] libdtrace: share vmlinux BTF/CTF globally to support faster startup Alan Maguire
2026-07-22 21:21   ` Kris Van Hees
2026-07-23 13:22     ` Alan Maguire
2026-07-21 15:24 ` [PATCH v3 3/7] libdtrace: Refactor math functions into dt_math.h Alan Maguire
2026-07-21 15:24 ` [PATCH v3 4/7] python: Add cpython bindings for libdtrace Alan Maguire
2026-07-21 15:24 ` [PATCH v3 5/7] dtrace.spec: add python bindings packaging Alan Maguire
2026-07-21 15:24 ` [PATCH v3 6/7] runtest.sh: Export PYTHONPATH when running tests in-tree Alan Maguire
2026-07-21 15:24 ` [PATCH v3 7/7] test: add tests for python bindings Alan Maguire

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=amExffYtEWp6jOzb@oracle.com \
    --to=kris.van.hees@oracle.com \
    --cc=alan.maguire@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox