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

[Eugene Loh]

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.

>> # 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.