[DTrace-devel] [oracle/dtrace-utils] 36aec7: build: add header-only checking

Kris Van Hees noreply at github.com
Tue Nov 22 18:40:35 UTC 2022 

  Branch: refs/heads/dev
  Home:   https://github.com/oracle/dtrace-utils
  Commit: 36aec7112db5ddc1ca3217381bb2f5183eeb9ebd
      https://github.com/oracle/dtrace-utils/commit/36aec7112db5ddc1ca3217381bb2f5183eeb9ebd
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-11-08 (Tue, 08 Nov 2022)

  Changed paths:
    M Makeconfig

  Log Message:
  -----------
  build: add header-only checking

The check-header-rule Makeconfig macro lets you check if a given
identifier compiles after #including a given header without trying to
link it.  This is useful for things that are distinguished by the
presence of a given identifier in the headers, where that identifier
corresponds to a symbol that won't actually link if used, perhaps
because of symbol versioning.

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


  Commit: c980b01738451765a31ee145b1a5d1fab0233a96
      https://github.com/oracle/dtrace-utils/commit/c980b01738451765a31ee145b1a5d1fab0233a96
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-11-08 (Tue, 08 Nov 2022)

  Changed paths:
    M dtprobed/dtprobed.c

  Log Message:
  -----------
  daemon: -o allow_other is useless, don't pass it in

The -o allow_other option to FUSE informs the kernel's FUSE-mounting API
that files on a given filesystem can be written to by users other than
the one running the daemon that mounted it.  Without this, not even root
can access it.

This serves to reduce the likelihood that users can attack each other
via badly-secured FUSE filesystems.

Back when I was struggling to get CUSE to work, I added this to the
argv options string passed to cuse_lowlevel_setup().  I never checked
after I got things working to see if it was actually needed, and it
turns out that since CUSE never mounts anything (it only creates a
device) and since CUSE bypasses the parts of FUSE that check whether
users are allowed to write to devices (relying instead on good old
permissions checking), the option is useless and ignored.

This has actually got less strict over time: libfuse 2 actually rejects
it and refuses to initialize.  So drop it entirely.

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


  Commit: c47002cdd7120d43b061d35dac696b7a2f717f38
      https://github.com/oracle/dtrace-utils/commit/c47002cdd7120d43b061d35dac696b7a2f717f38
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-11-08 (Tue, 08 Nov 2022)

  Changed paths:
    M GNUmakefile
    M Makeconfig

  Log Message:
  -----------
  build: add a mechanism to tell whether the tree is configured yet

This means that bits of makefiles that depend on configure symbols and
might emit noisy errors otherwise can be surrounded with ifdef
CONFIGURED to suppress their execution when the makefile is initially
run (when all it does is configure itself and restart parsing, resetting
all its variables to the configured values).

We fix another noisy error while we're here: the initial build routinely
displays

GNUmakefile:111: /home/oranix/oracle/private/dtrace/build/config.mk: No such file or directory

because the tree is not yet configured and config.mk hasn't been
created.

This buys us nothing and is just noisy: suppress it.

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


  Commit: 7ff38c75d83131c81383ee9688ab936b58bacf42
      https://github.com/oracle/dtrace-utils/commit/7ff38c75d83131c81383ee9688ab936b58bacf42
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-11-08 (Tue, 08 Nov 2022)

  Changed paths:
    M Makeconfig
    M Makeoptions
    M dtprobed/Build
    M dtprobed/dtprobed.c
    M dtrace.spec

  Log Message:
  -----------
  daemon: support libfuse 2

So it turns out that some people want to use libfuse 2 still, even
though it's been obsoleted by libfuse 3 for nearly a decade.  This turns
out to be not terribly difficult!

There are two major changess that impact us (ignoring the options-
parsing thing fixed in the last commit):

 - libfuse 2 has a 'channel' abstraction in which the fd to the kernel
   is nested.  libfuse 3 dropped it because it turned out there was only
   ever one of them so the abstraction was redundant, but that makes it
   easy for us to pick the fd out: we can grab the fuse_session_next_chan()
   without ever worrying that we might have to call that function more
   than once or deal with more than one channel.

   This changes the main read loop() enough that we can just implement
   it twice.

 - that's good because of another annoying difference: OL carries a
   NUMA-aware API which actually changes the public API of libfuse's
   fuse_session_receive_buf function.  This is hard to check for because
   the extra functions you need to call to actually turn this behaviour
   on were never added to the symbol version file, so you can't link
   with them.  So we detect these functions using the macros just added
   to do straight compilation checking, with no linking, and use their
   presence as a clue that fuse_session_receive_buf has the NUMA-aware
   API change.  (We don't use the NUMA stuff: it's only useful if you're
   using a multithreaded event loop, which we're not.)

We currently handle systems with both libfuse 2 and 3 by checking that
libfuse 3 is available, and if not, falling back to libfuse 2 (and if
that isn't present either you get a link failure).  Thus libfuse 3 is
preferred if both are present.  There is an additional libfuse2=yes
build option if you want to force the use of the old libfuse even when
the newer one is present.

One extra bit of complexity: we call pkg-config on whatever libfuse we
hope is present, and this emits very noisy multi-line error messages if
it isn't present: so suppress execution of all the dtprobed build rules
until the tree is configured and we have some idea of which libfuse is
there.

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


  Commit: a813850382dc734dadd11d6ba90d8ccccfae4c7d
      https://github.com/oracle/dtrace-utils/commit/a813850382dc734dadd11d6ba90d8ccccfae4c7d
  Author: Eugene Loh <eugene.loh at oracle.com>
  Date:   2022-11-09 (Wed, 09 Nov 2022)

  Changed paths:
    M test/unittest/misc/tst.lockmem-cmdline.sh
    M test/unittest/misc/tst.lockmem-envvar.r
    M test/unittest/misc/tst.lockmem-envvar.sh
    M test/unittest/misc/tst.lockmem-pragma.r
    M test/unittest/misc/tst.lockmem-pragma.sh
    M test/unittest/misc/tst.lockmem-x.r
    M test/unittest/misc/tst.lockmem-x.sh

  Log Message:
  -----------
  test: Bump up locked memory in lockmem tests further

In a previous commit --
672c4532 "test: Bump up locked memory in lockmem tests"
-- the lockmem tests bumped up the locked-memory limit for cases where
DTrace is expected to load successfully.  That patch helped the tests
pass under wider conditions, but further increases are warranted.

Increase the lockmem limit for cases expecting successful loads.
Specifically, use 256G, as runtest.sh does for "ulimit -l".

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


  Commit: 0abe6125077ec1e4d84c3ec38a18a7d704ffbedd
      https://github.com/oracle/dtrace-utils/commit/0abe6125077ec1e4d84c3ec38a18a7d704ffbedd
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2022-11-09 (Wed, 09 Nov 2022)

  Changed paths:
    M NEWS

  Log Message:
  -----------
  NEWS: update to reflect new dependency and limitation

Added info about dependency on libfuse (2 or 3).

Added warning that copyin(), copyinstr(), and copyinto() may not work
on some aarch64 platforms due to limitations in the BPF implementation
at the kernel level.

Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>


  Commit: 58b76fb43396fc6db9da529b13e568f5599e2921
      https://github.com/oracle/dtrace-utils/commit/58b76fb43396fc6db9da529b13e568f5599e2921
  Author: Nick Alcock <nick.alcock at oracle.com>
  Date:   2022-11-09 (Wed, 09 Nov 2022)

  Changed paths:
    M test/triggers/Build

  Log Message:
  -----------
  install: ensure install-test does not have any dependencies

We went to some care to not depend 'make install' on anything -- with
one exception.  test/triggers/Build contains an install-test rule that
depends on triggers, which pulls in libproc-pldd, which pulls in
libdtrace, and now we're rebuilding everything.

Rip out this dependency.  (If rebuilding was really needed, this rule is
the wrong place to do it from anyway: and if no building has happened at
all the installation will have failed long before now.)

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


  Commit: 2151f82d725180ee86224b40e9ae06904a6818ad
      https://github.com/oracle/dtrace-utils/commit/2151f82d725180ee86224b40e9ae06904a6818ad
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2022-11-22 (Tue, 22 Nov 2022)

  Changed paths:
    M README.md

  Log Message:
  -----------
  Update README.md

- Updated the OLx yum channels
- Updated the build and runtime dependency lists

Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>


Compare: https://github.com/oracle/dtrace-utils/compare/9778f6566d11...2151f82d7251

More information about the DTrace-devel mailing list