[DTrace-devel] [oracle/dtrace-utils] c6e76c: test: With the io provider implemented, remove mor...

euloh noreply at github.com
Tue Feb 20 17:46:01 UTC 2024


  Branch: refs/heads/devel
  Home:   https://github.com/oracle/dtrace-utils
  Commit: c6e76ccf1a5011da4805667034285b97a2d76d81
      https://github.com/oracle/dtrace-utils/commit/c6e76ccf1a5011da4805667034285b97a2d76d81
  Author: eugene.loh at oracle.com <eugene.loh at oracle.com>
  Date:   2024-02-20 (Tue, 20 Feb 2024)

  Changed paths:
    M test/demo/io/iosnoop.d
    M test/demo/io/iotime.d
    M test/demo/io/whowrite.d

  Log Message:
  -----------
  test: With the io provider implemented, remove more XFAILs

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


  Commit: 474c4f0904900571b0cc909e566c655c20885b38
      https://github.com/oracle/dtrace-utils/commit/474c4f0904900571b0cc909e566c655c20885b38
  Author: eugene.loh at oracle.com <eugene.loh at oracle.com>
  Date:   2024-02-20 (Tue, 20 Feb 2024)

  Changed paths:
    M libdtrace/dt_open.c
    M test/unittest/misc/tst.lockmem-cmdline.r
    R test/unittest/misc/tst.lockmem-cmdline.x

  Log Message:
  -----------
  Set the lockmem limit to "unlimited" by default

Commit d5a2077d ("Locked-memory limit") described the importance of
setting the locked-memory limit appropriately for DTrace, but it put
that burden on users, admittedly providing several mechanisms to do so.

Driven by commit 5a12c51c ("options: ensure lockmem is set before
retrieving probe info"), commit 7e159efa ("Forbid setting lockmem value
with a pragma") eliminated one such mechanism.

That pragma mechanism, however, had proven to be a popular way of
constructing D scripts that could run both under legacy DTrace, which
does not recognize the lockmem option, and DTrace on Linux, which
essentially requires the option.  That is, the mechanism allowed a
script to set the pragma conditionally based on DTrace version.

Further, it is difficult to size the amount of locked memory needed,
and so users end up just routinely setting the limit to "unlimited."

While there are good reasons not to change resource limits quietly, the
usability issues around lockmem have become nuisances.

Therefore, continue to support the lockmem option, but change the default
behavior to set the lockmem limit to "unlimited."

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


  Commit: 7f2b6c93a4b48683561cd249fc7ac422e4c76c2e
      https://github.com/oracle/dtrace-utils/commit/7f2b6c93a4b48683561cd249fc7ac422e4c76c2e
  Author: eugene.loh at oracle.com <eugene.loh at oracle.com>
  Date:   2024-02-20 (Tue, 20 Feb 2024)

  Changed paths:
    M test/unittest/proc/tst.exitkilled.sh
    M test/unittest/proc/tst.signal.sh

  Log Message:
  -----------
  test: Fix use of syscall::execve:entry args[1][?]

Commit 82332371 ("proc: use a rawtp for the proc:::exit probe") included
some test changes.  Specifically, it sought to use syscall::execve:entry
probe arguments args[1][0] and args[1][1] to recognize "sleep 10000".
The patch recognized that the argv pointers in question were in user
space, requiring copyinstr() to access the strings.

But it's trickier than that.  The args[1][?] require two dereferencings,
both in user space.  So a copyin() is required to access args[1] and
then copyinstr() to access the args[1][?].

Fix the tests to use two layers of copyin*() to double dereference the
args[1][?] strings.

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/a67a8de9e935...7f2b6c93a4b4

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