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

[Kris Van Hees]

On Thu, Nov 30, 2023 at 11:21:50PM -0500, Kris Van Hees via DTrace-devel wrote:
> On Thu, Nov 30, 2023 at 07:23:03PM -0500, Eugene Loh via DTrace-devel wrote:
> > On 11/30/23 10:59, Kris Van Hees via DTrace-devel wrote:
> > 
> > > No test is added for this condition because any such test would have to
> > > be removed again in the next patch, where a better way to retrieve rawtp
> > > argument info will be introduced.  This code will remain as a fallback,
> > > but we do not have any way to programmatically force it to be used.
> > 
> > I see this patch is reviewed, but I wanted to weigh in on the test issue.
> > 
> > Will this code be a fallback on every platform?  How about on OL7? Would OL7
> > be missing HAVE_LIBCTF and therefore would be falling back?  With the entire
> > patch series in place and running on OL7, I try:
> > 
> > # dtrace -lvP rawtp -xlockmem=1
> > # dtrace -lvP rawtp -xlockmem=unlimited
> > # dtrace -lv        -xlockmem=1
> > # dtrace -lv        -xlockmem=unlimited
> > 
> > With "-P rawtp", the highest code path is different from the "default"
> > case.  I see that the -xlockmem=1 runs have truncated output relative to
> > their "unlimited" companions.  They also have "lockmem" messages.
> > 
> > I think such a test should be present.  It can be introduced in this patch; 
> > the next patch can add a .x file for OL8 and OL9.  Or this patch can say
> > that the test will appear in the next patch.  But a test should appear
> > somewhere.
> 
> Yes, you are right that with the latest version, a test is actuallly possible
> on OS versions that provide libdtrace-ctf and NOT libctf.  I will add a test
> to exercise this on that particular environment.  However, that will not serve
> as a general test for this fallback functionality in the long run because the
> libdtrace-ctf library has been deprecated.
> 
> So, even though there will be a test, it will be of very limited use.  And in
> any even remotely recent environment, it won't be used.

Thinking about this more, I really am not too sure about a formal test.  The
problem is that there are different conditions at play here that we do not have
full control over.  We just happen to have an environment where we are seeing
this situation pop up in a way that lends itself to a test.  But putting in a
test just for OL7 seems wrong.

The *real* conditions are systems where (1) libdtrace-ctf is used rather than
libctf *and* (2) lockmem poses a limitations.  Checking (at runtime) whether
we are dealing with libdtrace-ctf vs libctf is not that easy because we'd need
to look at libdtrace.so and somehow determine which library it was linked with
(and on OL we perform a static link for some reason whereas on e.g. Debian we
use a link with a shared lib), and determine whether lockmem poses an issue or
not.  I have seen systems where -xlockmem=1 won't make a difference - whatever
BPF programs we load still load fine.

So, I feel that it is just not practical to have a proper test here because we
cannot easilt determine whether the test should run or not.  Doing it just for
OL7 is again IMHO not right.

Now, since the later patch introduces a test for probe argument retrieval for
rawtp probes, this functionality *is* getting exercised on OL7 by virtue of
DTrace on OL7 not being able to use libctf and therefore needing to use the
fallback code anyway.

I just cannot easily make it fail when lockmem is too low because (again) there
seem to be systems where setting -xlockmem=1 just won't have the desired
effect of lowering the limit of locked memory (perhaps because root on those
systems is not held to the resource limit).