[DTrace-devel] [oracle/dtrace-utils] fb5a11: vars: ensure 'cwd' and 'root' work and test other ...

[Kris Van Hees]

  Branch: refs/heads/dev-queue
  Home:   https://github.com/oracle/dtrace-utils
  Commit: fb5a118124af9f752326dc52d823a28c1bbd6554
      https://github.com/oracle/dtrace-utils/commit/fb5a118124af9f752326dc52d823a28c1bbd6554
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2025-08-11 (Mon, 11 Aug 2025)

  Changed paths:
    M libdtrace/dt_cg.c
    A test/unittest/variables/inline/tst.procfs-cwd.d
    A test/unittest/variables/inline/tst.procfs-root.d
    A test/unittest/variables/inline/tst.sched-chip.d
    A test/unittest/variables/inline/tst.sched-cpu.d
    A test/unittest/variables/inline/tst.sched-lgrp.d
    A test/unittest/variables/inline/tst.sched-pset.d

  Log Message:
  -----------
  vars: ensure 'cwd' and 'root' work and test other inline vars

Inline variable declarations that provide a tstring value were not
ensuring that tstring data got propagated correctly.

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


  Commit: fa94aae1da96f38066891f66870645d42cec4198
      https://github.com/oracle/dtrace-utils/commit/fa94aae1da96f38066891f66870645d42cec4198
  Author: Eugene Loh <eugene.loh at oracle.com>
  Date:   2025-08-11 (Mon, 11 Aug 2025)

  Changed paths:
    M libdtrace/dt_prov_uprobe.c
    A test/unittest/pid/tst.multi-return.d
    A test/unittest/pid/tst.multi-return.r

  Log Message:
  -----------
  Add function name to underlying return probes

In commit 35a4f05c2
("Add support for pid function "-" with absolute offset"),
function names were removed from underlying probe descriptions.
That was so that pid absolute offset probes (pid$pid:a.out:-:$absoff),
with function "-", could sit on the same underlying probes as
pid$pid:$mod:$fun:entry, pid$pid:$mod:$fun:$off, and USDT probes.

While that made sense for those probes, it did not make sense for pid
return probes:  their underlying probes, all with probe name "return",
are no longer distinguishable.  Further, there was no need for any such
change, since no other probes will have the same underlying return probe.

Name underlying return probes with function name.

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


  Commit: 9a4cd7999fab6670c0a6b34df84b49c2feeae3f3
      https://github.com/oracle/dtrace-utils/commit/9a4cd7999fab6670c0a6b34df84b49c2feeae3f3
  Author: Eugene Loh <eugene.loh at oracle.com>
  Date:   2025-08-11 (Mon, 11 Aug 2025)

  Changed paths:
    M libdtrace/dt_aggregate.c
    M libdtrace/dt_aggregate.h
    M libdtrace/dt_consume.c
    M libdtrace/dtrace.h
    M test/unittest/options/tst.aggrate-slow.d

  Log Message:
  -----------
  Snapshot aggregations just in time

Currently, dtrace periodically calls dtrace_work(), which in turn calls
dtrace_consume(), which among other things calls dtrace_aggregate_snap().
But aggregations are kept in entirety in the kernel's BPF maps.  There
is no need to snapshot the aggregations into user space unless we're
actually going to do something with aggregations.

Snapshot aggregations just in time -- that is, if there is a clear(),
trunc(), or printa() or if aggregations are to be printed at the end
of a dtrace session.

Skip the aggrate-slow test.  Just-in-time snapshots mean the semantics
of aggrate have changed.  A fast aggrate means nothing.  A slow aggrate
means we are supposed to use stale aggregation data, which would be
baffling.  A future patch is advised to deprecate aggrate entirely.

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


  Commit: 4e8c23df7a3bfbea431a8e63399c67cfee659dc4
      https://github.com/oracle/dtrace-utils/commit/4e8c23df7a3bfbea431a8e63399c67cfee659dc4
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2025-08-11 (Mon, 11 Aug 2025)

  Changed paths:
    M bpf/get_dvar.c
    A test/unittest/assocs/tst.collision.d

  Log Message:
  -----------
  dvar: ensure dynamic variables cannot overwrite eachother

As Eugene discovered, it was possible for dynamic variables (elements
of associative arrays and TLS variables) to overwrite eachother.  The
problem turns out to be due to the implementation of the BPF helper
bpf_map_update_elem().  In order for the update to be seen as an atomic
operation, it does not update the value of the map element in-place but
instead allocates a new element and places it in front of the old one
before it removes the old one.  The result is that the address of the
map element changes as a result of the bpf_map_update_elem() call.

Fortunately, we can just assign the address of the map element in the
value that we obtained using bpf_map_lookup_elem() because that gives
us a pointer to the map value, and we can assign directly into it.

In other words, we do not need the 2nd bpf_map_update_elem() anyway,
and since that was the culprit, removing it resolves the issue.

Test included.

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


Compare: https://github.com/oracle/dtrace-utils/compare/5c639877bfb8...4e8c23df7a3b

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