[DTrace-devel] [oracle/dtrace-utils] 93870f: test: Allow more variations in expected fbt kernel...

euloh noreply at github.com
Thu Mar 20 04:52:52 UTC 2025


  Branch: refs/heads/devel
  Home:   https://github.com/oracle/dtrace-utils
  Commit: 93870f7cf35269aea14c1353e3aa9b01c2776071
      https://github.com/oracle/dtrace-utils/commit/93870f7cf35269aea14c1353e3aa9b01c2776071
  Author: Eugene Loh <eugene.loh at oracle.com>
  Date:   2025-03-19 (Wed, 19 Mar 2025)

  Changed paths:
    M test/unittest/stack/tst.stack_fbt.sh

  Log Message:
  -----------
  test: Allow more variations in expected fbt kernel stacks

This test checks the call stack upon entry to vfs_write().
Unfortunately, these checks require some maintenance since the call
stack can vary -- slightly or greatly -- depending on processor or
kernel.  There is a competition between ease of test maintenance and
strictness of correctness checks.

Adapt post processing of output to allow new variations in stacks
seen in UEK 8 (currently Linux 6.12).

Orabug: 37459289
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 219d6ac387f3c9cdfe24ae8d7ca67ee2f8285d1e
      https://github.com/oracle/dtrace-utils/commit/219d6ac387f3c9cdfe24ae8d7ca67ee2f8285d1e
  Author: Eugene Loh <eugene.loh at oracle.com>
  Date:   2025-03-19 (Wed, 19 Mar 2025)

  Changed paths:
    M test/unittest/ustack/tst.ustack25_pid.r
    A test/unittest/ustack/tst.ustack25_pid.r.p

  Log Message:
  -----------
  test: Account for pid:::entry ustack() being correct

The pid:::entry uprobe fires so early in the function preamble
that the frame pointer is not yet set and the caller is not (yet)
correctly identified.  In Linux 6.11, x86-specific heuristics
address this problem.

Post process results from this test to accommodate both cases --
missing caller and not missing caller.

Orabug: 37459289
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 6bd4b26026aad14255d83f57044b1c41d4bd698b
      https://github.com/oracle/dtrace-utils/commit/6bd4b26026aad14255d83f57044b1c41d4bd698b
  Author: Eugene Loh <eugene.loh at oracle.com>
  Date:   2025-03-19 (Wed, 19 Mar 2025)

  Changed paths:
    M libdtrace/dt_cg.c

  Log Message:
  -----------
  Use DT_TRAMP_SP_SLOT() for BPF stack scratch space in trampoline

We might as well get this code right, even if this "fix" is
arguably irrelevant for two reasons:

*)  The offset just so happens to be -96 before and after the
    change anyhow, just by coincidence.

*)  The fix is on a code path that is not currently in use.

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: d5beecf9f1a9a3aa7064676841f6a738b2c7e348
      https://github.com/oracle/dtrace-utils/commit/d5beecf9f1a9a3aa7064676841f6a738b2c7e348
  Author: Eugene Loh <eugene.loh at oracle.com>
  Date:   2025-03-19 (Wed, 19 Mar 2025)

  Changed paths:
    M libdtrace/dt_program.c

  Log Message:
  -----------
  Rename _DTRACE_VERSION

There are many DTrace version numbers (for version, API version,
package version, etc.).  Meanwhile, _DTRACE_VERSION is not a
version number at all.  It's a preprocessor macro in USDT .h header
files.  Prior to commit e2fb0ecd9
("Ensure multiple passes through dtrace -G work."), it was perhaps
not even set.  With that commit, it was always set to 1, with
the rationale:

    Also add an explicit define for _DTRACE_VERSION in the generated
    header file from 'dtrace -h' invocations.  This seems silly, but
    it is there to give people a skeleton to work with if they want to
    pre-generate header files and select whether to actually compile
    on the probes at a later time.

Rename to _DTRACE_USE_USDT for better clarity.  Define it only once
per file.  Place the definition inside an #ifndef test so that a
developer could set the value without manually changing the file.

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: b35a2d35b0ec173e5a5b6ceb546eba3bd4cfa21e
      https://github.com/oracle/dtrace-utils/commit/b35a2d35b0ec173e5a5b6ceb546eba3bd4cfa21e
  Author: eugene.loh at oracle.com <eugene.loh at oracle.com>
  Date:   2025-03-19 (Wed, 19 Mar 2025)

  Changed paths:
    M libdtrace/dt_prov_uprobe.c

  Log Message:
  -----------
  Clarify how the usdt_prids key is stored on the BPF stack

While one can access the BPF stack relative to %r9, the whole
point of DT_TRAMP_SP_SLOT(0) is to make trampoline code more
readable.  So use it.

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 666abf31923976c8da43d038b5f2d7d7ba9a0ab0
      https://github.com/oracle/dtrace-utils/commit/666abf31923976c8da43d038b5f2d7d7ba9a0ab0
  Author: eugene.loh at oracle.com <eugene.loh at oracle.com>
  Date:   2025-03-19 (Wed, 19 Mar 2025)

  Changed paths:
    M dtprobed/dtprobed.c

  Log Message:
  -----------
  Fix format specifier in dtprobed.c

The format specifier is %i but nprobes is size_t.  Some compilers
issue warnings.  Change the format specifier to match the type.

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 6cb6817b7c75836d4526c08fc780deaae2050e1e
      https://github.com/oracle/dtrace-utils/commit/6cb6817b7c75836d4526c08fc780deaae2050e1e
  Author: eugene.loh at oracle.com <eugene.loh at oracle.com>
  Date:   2025-03-19 (Wed, 19 Mar 2025)

  Changed paths:
    A test/unittest/builtinvar/tst.tid_pid.r
    A test/unittest/builtinvar/tst.tid_pid.sh

  Log Message:
  -----------
  test: Check tid value

We were checking the built-in variable tid simply by testing
that we could print it and its value was not -1.

Add a test that confirms the value is actually correct;
compare to C output of gettid().

In line with other similar tests, also check for the profile
provider.

While we're at it, check the pid value and the pthread_t value
returned via pthread_create().

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 4aec5c9931ebe770b13b1dc9b716393ad91980fb
      https://github.com/oracle/dtrace-utils/commit/4aec5c9931ebe770b13b1dc9b716393ad91980fb
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2025-03-19 (Wed, 19 Mar 2025)

  Changed paths:
    M libdtrace/dt_pid.c

  Log Message:
  -----------
  dt_pid: pid grabs should be shortlived

If we use long-lived grabs for this, we are requiring that the process is
ptraceable, and thus preventing pid tracing of system daemons, init,
processes already being debugged or traced by others, etc.

Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 6f398f2297aa7c903aec0d2e083add64e7644044
      https://github.com/oracle/dtrace-utils/commit/6f398f2297aa7c903aec0d2e083add64e7644044
  Author: eugene.loh at oracle.com <eugene.loh at oracle.com>
  Date:   2025-03-19 (Wed, 19 Mar 2025)

  Changed paths:
    A test/unittest/usdt/convert_PID_and_PRID.awk
    M test/unittest/usdt/err.argmap-null.r
    R test/unittest/usdt/err.argmap-null.r.p
    A test/unittest/usdt/err.argmap-null.r.p
    M test/unittest/usdt/tst.dlclose1.r
    R test/unittest/usdt/tst.dlclose1.r.p
    A test/unittest/usdt/tst.dlclose1.r.p
    M test/unittest/usdt/tst.enable_pid.r
    R test/unittest/usdt/tst.enable_pid.r.p
    A test/unittest/usdt/tst.enable_pid.r.p
    M test/unittest/usdt/tst.exec-dof-replacement.r
    R test/unittest/usdt/tst.exec-dof-replacement.r.p
    A test/unittest/usdt/tst.exec-dof-replacement.r.p
    R test/unittest/usdt/tst.multiprov-dupprobe-fire.r.p
    A test/unittest/usdt/tst.multiprov-dupprobe-fire.r.p
    R test/unittest/usdt/tst.multiprov-dupprobe.r.p
    A test/unittest/usdt/tst.multiprov-dupprobe.r.p
    R test/unittest/usdt/tst.multiprovider-fire.r.p
    A test/unittest/usdt/tst.multiprovider-fire.r.p
    R test/unittest/usdt/tst.multiprovider.r.p
    A test/unittest/usdt/tst.multiprovider.r.p

  Log Message:
  -----------
  test: Make tests more resilient to different prid widths

Various tests convert run-dependent values -- like PIDs and probe IDs
-- to run-independent strings before checking against their .r results
files.  But the conversions could be remarkably sensitive to the width
of probe IDs.  E.g., some conversions assumed probe IDs were flush with
the beginning of the line, but if they were narrower they were preceded
by white space and were not detected.  E.g., this happened in recent fbt
work, where probe IDs for fbt probes became much smaller in value.

Also, these conversions were being carried out by a hodgepodge of scripts
-- sed, awk, and grep;  some using run-independent strings like "NNN" or
"XXXX" instead of more informative "PID" and "PRID" strings;  some
incorrectly using "PID" for PRIDs, etc.

Replace these .r.p postprocessing scripts with a single script that is
more resilient to PRID widths and is commented.

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 8ac281593130c58566e5bb40e9d22a9950644366
      https://github.com/oracle/dtrace-utils/commit/8ac281593130c58566e5bb40e9d22a9950644366
  Author: eugene.loh at oracle.com <eugene.loh at oracle.com>
  Date:   2025-03-19 (Wed, 19 Mar 2025)

  Changed paths:
    A test/unittest/vars/tst.ucaller.r.p

  Log Message:
  -----------
  test: Account for pid:::entry ucaller being correct

In commit f38bdf9ea ("test: Account for pid:::entry ustack() being correct")
we accounted for x86-specific heuristics introduced in Linux 6.11 that
dealt with pid:::entry uprobes firing so early in the function preamble
that the frame pointer is not yet set and the caller is not (yet)
correctly identified.

Update a related test to account for the same effect with ucaller.

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 5fa86bd5021d4a8d531a1f5fbe8c67954e29d51f
      https://github.com/oracle/dtrace-utils/commit/5fa86bd5021d4a8d531a1f5fbe8c67954e29d51f
  Author: eugene.loh at oracle.com <eugene.loh at oracle.com>
  Date:   2025-03-19 (Wed, 19 Mar 2025)

  Changed paths:
    M bpf/get_bvar.c

  Log Message:
  -----------
  Fix dt_bvar_probedesc() for late USDT processes

With commit 8bd26415b
("bpf: separate bvar implementation into separate functions"),
test/unittest/usdt/tst.nusdtprobes.sh started failing reproducibly
on all platforms.

In that patch, the get_bvar() function is factored into separate
functions.  It includes a change that looks basically like this:

    uint32_t    key = mst->prid;

    if (key < ((uint64_t)&NPROBES)) {
        [...]
    } else {
        char *s = bpf_map_lookup_elem(&usdt_names, &key);
        switch (idx) {
  -     case DIF_VAR_PROBENAME: s += DTRACE_FUNCNAMELEN;
  +     case DIF_VAR_PROBEPROV: s += DTRACE_FUNCNAMELEN;
  -     case DIF_VAR_PROBEFUNC: s += DTRACE_MODNAMELEN;
  +     case DIF_VAR_PROBEMOD : s += DTRACE_MODNAMELEN;
  -     case DIF_VAR_PROBEMOD : s += DTRACE_PROVNAMELEN;
  +     case DIF_VAR_PROBEFUNC: s += DTRACE_PROVNAMELEN;
  -     case DIF_VAR_PROBEPROV:
  +     case DIF_VAR_PROBENAME:
        }
        return (uint64_t)s;
    }

That is, for the case of key>=NPROBES (that is, for USDT probes that
were added after the dtrace session was started), the meanings of
prov, mod, func, and name were exchanged.

Restore the correct meanings.

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: da8559baa7685b42c19180bb8d0f485ac0f736e5
      https://github.com/oracle/dtrace-utils/commit/da8559baa7685b42c19180bb8d0f485ac0f736e5
  Author: eugene.loh at oracle.com <eugene.loh at oracle.com>
  Date:   2025-03-19 (Wed, 19 Mar 2025)

  Changed paths:
    M libdtrace/dt_prov_fbt.c
    A test/unittest/fbtprovider/tst.entryargs2.r
    A test/unittest/fbtprovider/tst.entryargs2.sh

  Log Message:
  -----------
  Copy fprobes entry args with BPF helper function

With commit a6b626a89 ("Fix fprobe/kprobe selection"), fprobes were
effectively turned on.  Unfortunately, with this fix, some tests like
test/unittest/stack/tst.stack_fbt.sh encountered problems on UEK7
since the BPF verifier would complain about the prototypes of some of
the probe arguments.  E.g., when loading arg3 in fprobe_trampoline()
from fbt::vfs_write:entry from %r8+24, the BPF verifier complains

        func 'vfs_write' arg3 type INT is not a struct
        invalid bpf_context access off=24 size=8

We can bypass this problem by using a BPF helper function to copy the
arguments onto the BPF stack and then load the arguments into mstate
from there.

There is also a BPF get_func_arg() helper function, but it is not
introduced until 5.17 -- that is, it appears after UEK7.  See Linux
commit f92c1e1 ("bpf: Add get_func_[arg|ret|arg_cnt] helpers").

While the already mentioned test signals the problem and the fix, we
also add an additional test that actually checks the correctness of
the arguments.

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: ef34498e93f8651e511d6d8531603002c9c3ed26
      https://github.com/oracle/dtrace-utils/commit/ef34498e93f8651e511d6d8531603002c9c3ed26
  Author: eugene.loh at oracle.com <eugene.loh at oracle.com>
  Date:   2025-03-19 (Wed, 19 Mar 2025)

  Changed paths:
    M bpf/bvar_execargs.S

  Log Message:
  -----------
  Get execargs from user space

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: b12520b7da20c6f9d962a42444d41dfc27b6f577
      https://github.com/oracle/dtrace-utils/commit/b12520b7da20c6f9d962a42444d41dfc27b6f577
  Author: eugene.loh at oracle.com <eugene.loh at oracle.com>
  Date:   2025-03-19 (Wed, 19 Mar 2025)

  Changed paths:
    A test/unittest/providers/rawfbt/tst.synthetic-entry.r.p
    A test/unittest/providers/rawfbt/tst.synthetic-return.r.p

  Log Message:
  -----------
  test: Allow duplicate lines for rawfbt synthetic tests

It is possible for the probe in these tests to fire "concurrently"
on multiple CPUs, leading to duplicate lines of output.  Add
post processing to reduce multiple lines of duplicate output.

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>


Compare: https://github.com/oracle/dtrace-utils/compare/ad68224b0018...b12520b7da20

To unsubscribe from these emails, change your notification settings at https://github.com/oracle/dtrace-utils/settings/notifications



More information about the DTrace-devel mailing list