[DTrace-devel] [PATCH 09/15] provider: Implement a rawtp provider

[Kris Van Hees]

On Thu, Feb 23, 2023 at 05:54:54PM +0000, Nick Alcock wrote:
> On 23 Feb 2023, Kris Van Hees outgrape:

> > Err....  how can one distinguish between not finding any number of arguments
> > and zero arguments.  No arguments == zero arguments == not finding any number
> > of arguments.  You cannot test zero args because there is nothing to access,
> > right?
> 
> You can test zero arguments by simply not doing the load at all and
> making sure the simple BPF_RETURN() case works. If something is really
> wrong and that fails, that's worth noting... you'd think nothing else in
> dtrace would work if something that simple failed, but this is the first
> and so far only place we're using raw tracepoints: if they fail and
> nothing else does, right now we get no warning of that at all.

OK, but that is something entirely different and will be caught when we try to
actually attach the real probe program to the probe.  This is about determining
the number of arguments that can be accessed for the probe.  No arguments is
a valid answer to that, even if the reason is that you cannot attach any prog
at all.

We do not verify whether we can use any type of probes at this stage in any
of the providers, since we already end up doing that checking when we try to
load the actual programs.

> >> > +	argv = dt_zalloc(dtp, argc * sizeof(dt_argdesc_t));
> >> > +
> >> > +	for (i = 0; i < argc; i++) {
> >> > +		argv[i].mapping = i;
> >> > +		argv[i].native = "uint64_t";
> >> > +		argv[i].xlate = NULL;
> >> > +	}
> >> > +
> >> > +done:
> >> > +        *argcp = argc;
> >> > +        *argvp = argv;
> >> > +
> >> > +        return 0;
> >> > +}
> >> 
> >> (There really should be at least some error case here.)
> >
> > What do you mean with 'error case'?  Either we can access arguments or we
> > cannot.  What error case are you thinking of?
> 
> We get an error even when we try to not access anything, just a
> BPF_RETURN(), likely because raw tracepoints are somehow busted :/
> 
> Not a *serious* problem but trivial to fix, I suspect.

No need.  We only care whether we can access locations in the BPF context.  And
if we cannot because the program doesn't even load, then that is fine.

Anyhow, even if we were to use this as an opportunity to determine whether we
can actually use raw tracepoints (and there is nothing that would prevent us
other than a bug or a kernel issue), there is no proper path here to report
that issue.  This is just not the right place for that kind of failure mode
checking.
> 
> -- 
> NULL && (void)