[DTrace-devel] [PATCH 03/04] rawtp: report lockmem issues when determining rawtp argument count

[Kris Van Hees]

On Mon, Nov 27, 2023 at 04:07:51PM -0500, Eugene Loh wrote:
> On 11/22/23 22:22, Kris Van Hees wrote:
> 
> > On Wed, Nov 22, 2023 at 10:01:37PM -0500, Eugene Loh via DTrace-devel wrote:
> > > On 11/22/23 10:49, Kris Van Hees via DTrace-devel wrote:
> > > 
> > > > diff --git a/libdtrace/dt_prov_rawtp.c b/libdtrace/dt_prov_rawtp.c
> > > > @@ -181,7 +181,9 @@ static int probe_info(dtrace_hdl_t *dtp, const dt_probe_t *prp,
> > > >    		dif.dtdo_len = 2;
> > > >    		bpf_fd = dt_bpf_prog_load(dt_rawtp.prog_type, &dif, 0, NULL, 0);
> > > > -		if (bpf_fd == -1)
> > > > +		if (bpf_fd == -EPERM)
> > > Is that right?  I think the only negative value is -1.  Might it be that you
> > > want to test errno==+EPERM?  And do we know that EPERM really means
> > > lockmem?  Or are we simply guessing that that's the most likely explanation?
> > It is actually correct, or as correct as we can get.  A result value of
> > -EPERM is almost always a lockmem issue, based on the reading of the kernel
> > code that relates to this.  And -EPERM *is* -1.
> > 
> > But other error codes can be returned also, for other failures.
> 
> What I wrote might have been pretty confusing.  Let me try again. The return
> value is either a legal value or else it is -1 (which coincidentally is
> -EPERM).  In order to distinguish among different errors, we cannot test the
> return value;  we have to test errno.

Ah true, I meant to ensure that when dt_bpf_prog_load() fails, it would return
-errno but never made that change (but thought I did).  Duh.

Let me look at this - I probably will make that change anyway and then this
will be correct, because it makes sense to return -errno on error and a valid
fd on success.

> > > # dtrace -lv > out.default
> > > # dtrace -xlockmem=1 -lv > out.small
> > > # wc -l out.*
> > >   1445230 out.default
> > >   1380822 out.small
> > >   2826052 total
> > > # grep lockmem out.small
> > > # grep Cannot out.small
> > > #
> > > 
> > > Are things working as expected?
> 
> I'm still curious about this point.  I thought the point of the patch was
> that if there is a lockmem issue, that issue would be reported.  When I run
> with -xlockmem=1, the output is truncated significantly, but no telltale
> error message is printed.

That is the behaviour you see with just this patch (and not having the later
patch in the series applied)?  That is odd.  On what OL version and kernel?