From: Nick Alcock <nick.alcock@oracle.com>
To: Kris Van Hees <kris.van.hees@oracle.com>
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH] usdt parser: fix memory leak in provider and probe htabs
Date: Thu, 19 Jun 2025 12:58:21 +0100 [thread overview]
Message-ID: <8734bw0wpu.fsf@esperi.org.uk> (raw)
In-Reply-To: <SJ0SPRMB0016F8F2EEDFFB5FFC6BB811C27DA@SJ0SPRMB0016.namprd10.prod.outlook.com> (Kris Van Hees's message of "Wed, 18 Jun 2025 23:59:42 -0400")
On 19 Jun 2025, Kris Van Hees spake thusly:
> The prvmap and prbmap hashtable implementation was lacking code to
> ensure that entries are freed when the hashtables are destroyed. In
> addition, the pvp->pmap hashtables were also not cleaned up.
Much the same as what I wrote yesterday, but simpler and more obviously
correct, so I'd say pull it in, and I'll rebase my jailing series on top
of it.
> To provide cleaner data structures and to facilitate cleanup, tracepoint
> probes are now always removed from prbmap and either added to the
> pvp->pmap hashtable or added to the list of tracepoints for a particular
> probe. Therefore, when the prbmap is destroyed it no longer contains
> any entries.
Very nice...
> So, only pvp->pmap hashtables can contain probes. If they are function
> specific, they represent a tracepoint (and may have additional
> tracepoints linked to them). If they are not function specific, they
> provide a probe definition and they will contain probe argument data
> that needs freeing.
... but perhaps these two paragraphs should be in a comment in the code?
The shape of the data structures does matter to maintenance, after all.
> Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Reviewed-by: Nick Alcock <nick.alcock@oracle.com>, particularly if you
make those two paras comments.
--
NULL && (void)
prev parent reply other threads:[~2025-06-19 11:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-19 3:59 [PATCH] usdt parser: fix memory leak in provider and probe htabs Kris Van Hees
2025-06-19 11:58 ` Nick Alcock [this message]
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=8734bw0wpu.fsf@esperi.org.uk \
--to=nick.alcock@oracle.com \
--cc=dtrace-devel@oss.oracle.com \
--cc=dtrace@lists.linux.dev \
--cc=kris.van.hees@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.