[DTrace-devel] [PATCH v2 4/6] procfs: implement d_execargs() for pr_psargs translator support

[Kris Van Hees]

On Fri, Jan 31, 2025 at 03:29:50PM -0500, Eugene Loh wrote:
> On 1/31/25 11:37, Kris Van Hees wrote:
> 
> > On Thu, Jan 30, 2025 at 02:22:44PM -0500, Eugene Loh wrote:
> > > For
> > > test/unittest/funcs/d_execargs/tst.d_execargs.d
> > > test/unittest/proc/tst.pr_psargs.d
> > > how about a few more arguments?  E.g.,
> > > system("/bin/echo TEST abcde fghijkl");
> > > (I don't have anything particular in mind that this might catch. Just trying
> > > to poke a little harder.)
> > Sure, although it does not really improve the testing because we are looping
> > over all characters, changing '\0' into ' ', except for the last one.  If it
> > works for one it works for all, but I also do not mind adding a few extra
> > arguments.
> 
> Cool.  Again, I have nothing particular in mind that this would stress -- if
> it catches something, it would be something unforeseen.
> 
> Incidentally, I hadn't run proc/tst.pr_args.d.  I just tried:
> 
> *)  On ARM UEK6 (OL7 and OL8), I got
> dtrace: error in dt_clause_1 for probe ID 98979
> (proc:vmlinux::exec-success): invalid address (0xfffff895fa9f) at BPF pc 934
> dtrace: error in dt_clause_1 for probe ID 98979
> (proc:vmlinux::exec-success): invalid address (0xffffcb24faa0) at BPF pc 934
> Maybe UEK6 is not of interest, but there you have it.  Some copyin thing?  I
> don't know.

Hm, yes, come to think of it - arg_start and arg_end seem to indeed point to
the userspace stack so they might very well be userspace addresses.  I am not
sure, so I will investigate and if necessary will adjust the patch to handle
that.

> *)  On most platforms, I got
>              0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f 0123456789abcdef
>          0: 2f 62 69 6e 2f 65 63 68 6f 20 54 45 53 54 00 20 /bin/echo TEST.
>         10: 54 45 53 54 00 00 00 00 00 00 00 00 00 00 00 00 TEST............
>         20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>         30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>         40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> I do not know where those extra chars are coming from, but the test is
> exposing itself to printing out garbage in any case.  Maybe use printf()
> instead of trace so that we do not print out the buffer past the NUL char
> (and get more compact and readable output to boot)?

Aha, that is a bug.  Well, the output is not (and should remain as-is precisely
for catching things like this)...  pr_psargs[] is defined as a char array of
length 80.  So, the output is accurate but we need to ensure we clear the
remainder of the string data.