public inbox for dtrace@lists.linux.dev
 help / color / mirror / Atom feed
From: Kris Van Hees <kris.van.hees@oracle.com>
To: Nick Alcock <nick.alcock@oracle.com>
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com,
	eugene.loh@oracle.com
Subject: Re: [PATCH v2 3/4] probe: do not try to reify probes from uncooked providers
Date: Thu, 14 Nov 2024 23:53:58 -0500	[thread overview]
Message-ID: <ZzbT5s0HcpaJU35k@oracle.com> (raw)
In-Reply-To: <20241114220108.95647-3-nick.alcock@oracle.com>

On Thu, Nov 14, 2024 at 10:01:07PM +0000, Nick Alcock wrote:
> If there is a syntax error in the middle of a .d script processed
> by -h, we will be left with a provider in question in an uncooked
> state (where dt_provider_create() has been called on it with a NULL
> provider by dt_node_provider(), but it has not had its provider
> set yet by dt_cook_provider()).
> 
> In this case, the attempt to pop the parser stack on error will
> fail because probe iteration is attempting to reify probes out
> of providers without making sure they're cooked first:
> 
>     at libdtrace/dt_probe.c:1006
>     argv=0x535830, fp=0x21e4630, s=0x0) at libdtrace/dt_cc.c:789
>     fp=0x21e4630, s=0x0) at libdtrace/dt_cc.c:1419
>     at libdtrace/dt_cc.c:1441
> 
> The fix is simple: treat providers with no provimpl just like we do
> providers with no provide() method in their provimpl: they cannot provide
> probes, so don't try. (Test coming in a later commit in this series.)

This entire commit message (and the one-liner subject) are actually not
quite correct in terms of what the problem is.  It has nothing to do with
cooked vs uncooked providers or probes.  The problem is simply that the
dt_probe_iter() functions calls the provide() hook in provider prior to
trying to match probe descriptions, and that cannot be done for a provider
without implementation.  That is all.

This also needs a test.

I'm posting an alternative patch (with my reviewed-by) with updated commit
message and 2 tests (signed-off-by for both of us since you wrote the code).

> Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> ---
>  libdtrace/dt_probe.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libdtrace/dt_probe.c b/libdtrace/dt_probe.c
> index 189bf7928e145..ccaa3081c5b23 100644
> --- a/libdtrace/dt_probe.c
> +++ b/libdtrace/dt_probe.c
> @@ -1007,7 +1007,8 @@ dt_probe_iter(dtrace_hdl_t *dtp, const dtrace_probedesc_t *pdp,
>  	 * Loop over providers, allowing them to provide these probes.
>  	 */
>  	while ((pvp = dt_htab_next(dtp->dt_provs, &it)) != NULL) {
> -		if (pvp->impl->provide == NULL ||
> +		if (pvp->impl == NULL ||
> +		    pvp->impl->provide == NULL ||
>  		    !dt_gmatch(pvp->desc.dtvd_name, pdp->prv))
>  			continue;
>  		memcpy(&desc, pdp, sizeof(desc));
> -- 
> 2.46.0.278.g36e3a12567
> 

  reply	other threads:[~2024-11-15  4:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-14 22:01 [PATCH v2 1/4] dtprobed: handle multiple providers in a single piece of DOF Nick Alcock
2024-11-14 22:01 ` [PATCH v2 2/4] runtest: detect coredumps in more cases Nick Alcock
2024-11-15  4:47   ` Eugene Loh
2024-11-15 20:56     ` Nick Alcock
2024-11-15  4:51   ` [DTrace-devel] " Kris Van Hees
2024-11-14 22:01 ` [PATCH v2 3/4] probe: do not try to reify probes from uncooked providers Nick Alcock
2024-11-15  4:53   ` Kris Van Hees [this message]
2024-11-15 20:57     ` Nick Alcock
2024-11-14 22:01 ` [PATCH v2 4/4] probe: make it possible to destroy probes in more cases Nick Alcock
2024-11-15  4:56   ` Kris Van Hees
2024-11-15 20:57     ` Nick Alcock
2024-11-15 22:55       ` Nick Alcock
2024-11-15  4:50 ` [PATCH v2 1/4] dtprobed: handle multiple providers in a single piece of DOF 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=ZzbT5s0HcpaJU35k@oracle.com \
    --to=kris.van.hees@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=eugene.loh@oracle.com \
    --cc=nick.alcock@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox