releng: work around fedora ci

rpminspect appears to have a cow about -testsuite and -runtime-java
multiarch conflicts.  Perhaps adding a mutual Conflicts: will help.

Adjust deviceseeks.stp to work with newer kernels

Newer kernels do not provides the queue parameter ($q) for the
block_bio_queue tracepoint used by ioblock_trace.request.  Based on
the suggestion by Jeff Moyer added an alternative way to get queue and
extract the sector size information required for this script.

PR27802: tweak configure.ac for AC_SUBST(pkglibdir)

autoconf is such a hassle for getting expanded path names for the
--FOOdir=BAR names.  During execution of the configure script, they
may be defined to be expressions with literal $values in them, which
need to be eval'd with other $values preset.  What a mess.  Tweak the
sequence used to predict the $pkglibexecdir through heuristics to get
around all this indirection.  (e.g. /usr/libexec/systemtap), whether
or not --libexecdir= is given.

Correct ucontext.stp umodname function call to _stp_umod_lookup

The runtime _stp_umod_lookup function had an additional offset parameter
added in git commit d1b554876c68f313ec371dbf52c4bddde7bbe10e.  That
patch updated the runtime uses of the function, but overlooked the use
of _stp_umod_lookup in the tapsetss.  This patch updates the missed
_stp_umod_lookup in the ucontext.stp tapset.

Adjust tapset dev.stp to get partition number from newer block_device struct

The kernel git commit 0d02129e76edf91cf04fabf1efbc3a9a1f1d729a removed
the bd_part field from struct block_device.  The newer field bd_partno
in the same struct should be used to get the partition number.  This
fix allows mbrwatch.stp, ioblktime.stp, and disktop.stp examples
to function on Linux 5.10 and new kernels.

PR27785: fix segv in try/catch traversal

Correct a little brainfart that didn't take into account the
presence of  try { ... } catch { ... } blocks, lacking the
optional exception-string catching clause.

runtime: fix user address calculation for PIE binaries

Commit d1b554876 ("runtime: fix symbol lookups when the first section
isn't executable") resolved an issue caused by not storing VMA info when
it was actually needed, and it did this by unconditionally storing VMA
info. It turns out we don't want to unconditionally store VMA info, as
is the case for PIE binaries. Doing so causes user address calculations
for PIE binaries to erroneously include the offset of the section
containing the target address.

Fix it by restoring the old code and just adding what's needed to fix
the bug described in commit d1b554876 (i.e., always storing VMA info
when `vm_start + offset == addr`).

Bonus for the git sleuths:
2:07 PM <fche> I'm not sure I understand all the offsets and bases and this and that
2:08 PM <fche> but it does bring the code back closer to what it used to be
2:08 PM <kerneltoast> don't worry, i don't understand it either
2:08 PM <fche> ok wait I have to add that into the git commit text ;)

PR27739: modernize java/byteman probing support

Use modern byteman's ability to load helper .jar on demand, and let
that .jar load the JNI .so on demand, all from full
$pkglibexecdir-based pathnames.  That way, the rpm .spec does not need
to worry about symlinking, and stapbm doesn't have to deal with
anything except the convenient bminstall/bmsubmit frontend scripts.

runtime: port to 5.12-rc unexporting of mutex_lock

Use an exportconf to make conditional our manual mutex_lock usage in
kallsyms symbol gathering.

Always get section info via sysfs using kernel_read()

kernel_read_file_from_path() from before it received the offset argument
is buggy in that it always expects the number of bytes read to be the
size of the inode. Since sysfs inodes are PAGE_SIZE bytes in size on
older kernels, kernel_read_file_from_path() would expect sysfs reads to
produce PAGE_SIZE bytes of output, otherwise it would return an error.

We can avoid kernel_read_file_from_path()'s quirks entirely by simply
using kernel_read() directly, which has the added benefit of existing
since before the first 2.6 kernel. This allows us to ditch the old
module_attribute struct hacks entirely, since the module sections sysfs
has been around since 2.6.8.

PR27658: show stderr of typequery make jobs in pass 2

typequery child-gcc invocations should not cause errors.  But if
they do, might as well show them to users, because a typo or some
other momentary/solvable system error might be responsible.

Set trust for new certificates.

Remove the change_cert_trust workaround and replace it with
PK11_InitPin call to initialize the metaData in key4.db.  Replace
CERT_DecodeCertFromPackage with PK11_ImportDERCert

ioscheduler tapset: adapt for loss of $q, standardize elevator_name

block/scheduler kernel tracepoints have lost the $q parameter, since
it is directly available from $rq.  Thus the derived script variable
elevator_name needs to be accessed that other route.  Tested on f33
and rhel6.

RHBZ1940979: make vfs-all-probes.stp compilable again

Skin-deep update of linux/vfs.stp tapset for supporting >5.*ish
kernels, with vfs_{read,write} fallback kprobes, and readahead_control
parameters.

Add workaround to set trust for new client certificates

The nss switchover from dbm to sql results in CERT_ChangeCertTrust not changing
the trust so call certutil in those instances to set it manually.

RHBZ1940761: tweak old_timex32 conditional usage

Improve on commit 4ab42baafca69 for pre-5.1 kernels.  The subject
compatibility type was introduced not with CONFIG_COMPAT_32BIT_TIME,
but later.  Tweak the conditional to also take kernel version >= 5.1
into account.

PR13838: tweak auto 32-bit float casting

Reject $float as lvalue.
Reject complex floats (tuples).

coverity tweak: stap-report

bpf-translate.cxx refactor: move visit{_try,}_block to a more logical place

visit_try_block() was in the middle of the assembler but unrelated to it.
In preparation for improving the register_error assembler directive,
move this code (and visit_block) to a more sensible location.
Then the embeddedcode assembler implementation is grouped at the start of
the visitor functions.

PR13838: support fp32_to_fp64 conversion automatically at functioncall
synthesize level.

- tapsets.cxx: modified synthetic_embedded_deref_call, so a 4 byte
  floating point will be convert to 8 byte double if detected.
- testsuite/buildok/floatingpoint.stp: updated corresponding fp32
  examples.

rhbz1938312: temp disable bpf on recent kernels

So the buildbots can continue to test everything that isn't bpf.

PR13838: add local floating point variables in main.cxx and more
test cases in testsuite/buildok/floatingpoint.stp

PR13838:
- prototype FP support in STAPCONF_REGSET configuration
In REGSET mode (rhel8ish+), fp registers need to be addressed by
ptrace NT_PRFPREG lookup coordinates.
- runtime/linux/loc2c-runtime.h: extend SSE, SSE2 and XMM register
definiton in url_x86_64[]

PR13838: update aarch64 pt_reg section, added macro definition for SIMD FP register V0-V7, (reg64-reg71).

PR13838:
- modified dwflpp.cxx so that $fp syntax will be supported
- runtme/loc2c-runtime.h: extended x64_64 register to 24 to allow access of xmm0-xmm7 register.
- testsuite/systemtap.examples/general: update examples, using $fp instead of user_long($fpointer)

testsuite: fix symbol lookups when the first section isn't executable

Based on the fedora php binary's peculiar build flags, related to
huge-page optimization.

runtime: fix symbol lookups when the first section isn't executable

Some binaries are linked in such a way that there are VMA address
range gaps, indicated by non-zero load offsets.  The runtime needs to
not lose those offsets to enable a proper mapping back & forth from
addresses to symbols.

PR27030 bpf/uconversions.stp: other sizes user_*_error()

* tapset/bpf/uconversions.stp (__bpf_probe_read_user_error): Don't shift by 8-size.
(__signext): New function.
(__bpf_probe_read_user_error_signed): New function.
(user_*_error): New functions, all from tapset/uconversions.stp.
* tapset/uconversions.stp (user_*_error): Disable these definitions on bpf backend.
* testsuite/systemtap.bpf/bpf-target.c: Extend test to probe different size values.
* testsuite/systemtap.bpf/bpf_target_tests/user_long.stp: Ditto.

stapbpf PR27030,PR25177/27032 bpf.exp: use stap -c on bpf_target_tests/

* testsuite/systemtap.bpf/bpf.exp:
  compile bpf-target.c, use -x for bpf_tests/, -c for bpf_target_tests/
* testsuite/systemtap.bpf/bpf-target.c:
  fix increment, rename from bpf-uconversions.c, XXX more coming soon
* testsuite/systemtap.bpf/bpf_target_tests/user_atvar_entry.stp:
  output PASS/FAIL for @var,@entry support
* testsuite/systemtap.bpf/bpf_target_tests/user_long.stp:
  output PASS/FAIL for PR27030 user_long(), XXX more coming soon

PR27031 stapbpf add bpf_target_tests/user_atvar_entry.stp

Since we have @var() and @entry() handled by passes preceding bpf-translate.cxx,
may as well add a testcase to show it works.

XXX Actually invoked by a new .exp yet to be committed.

PR27031 stapbpf fix 'missing conversion specifier' in println()

The synthesized format string was using '%lld' for integers
which is not actually handled by staptree.cxx print_format::string_to_components.

html-docs: switch to htlatex from latex2html

latex2html has been supplanted by htlatex, a more native latex->html
renderer.  Switch the update-htmldocs file etc. to use it to generate
html for the langref and tutorial documents.

PR27392: tweak uconversions.stp markup for html extraction

Just needed to move the runtime-conditional before the structured docs.

Reported-by: Dan Streetman <ddstreet@canonical.com>

man error::pass5: document lockdown escapes

Give some alternative advice for secureboot/lockdown machines about
how to turn off those security measures, based on bpftrace's
INSTALL.md.

Fix misspellings in stap manpage.

stapbpf PR25177/27032 review tweax: redundant variables, whitespace

1. Merge stapbpf.cxx log_level with verbose.
2. Alias stapbpf.cxx module_name to __name__ (module_name is better).
3. Put back double-space in usage messages.

stapbpf PR25177/27032: handle process exit (SIGCHLD)

* stapbpf.cxx (target_pid_failed_p): New variable.
(sigchld): New function, handle child process exit and signal bpf program.
(main): Set up and disable SIGCHLD handler and propagate failure exit.

stapbpf PR25177/27032: link start_cmd() into stapbpf, launch the process

This patch takes care of launching the process, next patch must take care
of listening for the process to finish running.

TODO some redundant declarations in stapbpf.cxx should be merged.

TODO in general staprun uses much nicer print functions,
should stapbpf borrow them too?

* buildrun.cxx (make_bpf_run_command): pass s.cmd to the stapbpf command.

* stapbpf/stapbpf.cxx (verbose): TODO redundant decl for start_cmd.c.
(read_stdin): TODO unused decl for start_cmd.c.
(__name__): TODO redundant decl for start_cmd.c.
(target_pid): now shared with C code in start_cmd.c.
(target_cmd): now shared with C code in start_cmd.c.
(eprintf): decl for start_cmd.c.
(start_cmd): decl for start_cmd.c.
(resume_cmd): decl for start_cmd.c.
(load_bpf_file): populate TODO redundant __name__ decl.
(usage): add '-c' option.
(main): add '-c' option, use start_cmd()/resume_cmd() to launch the process.
* stapbpf/bpfinterp.h (target_pid): now shared with C code in start_cmd.c.

* stapbpf/Makefile.{am,in}: add ../staprun/start_cmd.c to sources.

PR25177/27032 staprun: factor out start_cmd() for stapbpf usage

Most/all of the start_cmd() code in stap run should apply
to stapbpf '-c' support as well. Factor it out into an object
file that can be linked by both staprun and stapbpf.

* staprun/start_cmd.c: New file to be linked into both staprun and stapbpf.
* staprun/staprun.h: Declare functions in start_cmd.c.
* common.c (closefrom): Moved to start_cmd.c.
(OPEN_MAX): Moved to start_cmd.c.
* mainloop.c (signal_usr1): Moved to start_cmd.c.
(start_cmd): Moved to start_cmd.c.
(stp_main_loop): Move signal code to resume_cmd() in start_cmd.c.

* staprun/Makefile.{am,in}: add start_cmd.c.

systemtap.spec: for testsuite, tweak 32-bit glibc recommendation

For testing 32-bit cross-arch probing, we need a 32-bit glibc devel
environment.  Use a more modern way of asking for it.

Suggested-by: Florian Weimer <fweimer@redhat.com>

stapbpf PR27030 WIP: user_long() test with compiled program

usage message: explain [man FOO] notation right there

Maybe hinting right during the naked stap startup will work!

% stap
A script must be specified.
Try '-i' for building a script interactively.
Try '--help' for more information. [man stap]
A message like [man foo] means for more info, run % man foo

systemtap.spec: bump minimum elfutils to 0.179

We haven't tested with a pre-debuginfod version in some time.

RHBZ1930973 part: .spec: add elfutils-devel dependency

Since TLS-related work, building modules for the dyninst backend
requires elfutils headers.  Add them to the .spec for the -devel
subpackage.

Reported-By: Jan Pokorný <fedora@t.poki.me>

Correct the with_debuginfod macro in systemtap.spec.

systemtap.spec: buildrequire elfutils debuginfod client library

... but now with the appropriate conditional and %configure clause,
so as to reject misconfiguration.

systemtap.spec: buildrequire elfutils debuginfod client library

... after all, this is needed for buildid based probing.

NEWS: Mention enumerators

stapref.1: Mention @var("varname","module")

PR27361: make --dump-functions work again

Part of the work in commit 88db3a197 (version 4.3)
caused a regression with --dump-functions, wherein
optimizers would eliminate uncalled functions, even
in dump mode.  We now suppress this again and extend
the test case to look for a few more functions.

PR27361 part 1: enable typequery result memoization & operation on linux 5.11

Linux 5.11 rejects previous kmod_typequery .c files because they don't
have a MODULE_LICENSE bit.  Here, stap tries and tries and tries
building kmod_typequery files, up to thousands (!).  We solve the
first by adding the MODULE_LICENSE.  We solve the second by memoizing
typequery build results (whether they succeed or fail) in the
systemtap_session object.

dyninst runtime: adapt to stp_rwlock_t change

commit 6d6795f490 introduced stp_rwlock_t for stap script globals.
The dyninst runtime needs the same (an alias to pthread_rwlock_t).

stp_utrace: fix widespread utrace struct use-after-free issues

The utrace structs suffer from a number of use-after-free scenarios,
which cause panics and other mayhem. They can be used in queued-up task
workers after being freed, fetched from task_utrace_struct() and quickly
freed after while still in use, or fetched from task_utrace_struct()
after having already been freed. And utrace->task can be used after the
task struct it points to is freed.

A number of changes are made to remedy the widespread use-after-free
issues. Firstly, utrace structs now have a reference counter to protect
them from being abruptly freed while in use. This guarantees that a
utrace struct will only be freed after everything using it, including
task workers, is finished.

The task struct assigned to each utrace struct is now pinned as well,
making all utrace->task usage safe while the utrace struct is alive.

When utrace exits, all of the possible utrace workers are now canceled
instead of only some of them. Although this mass cancel isn't necessary
now, it's good to do so to speed up utrace exit so that exiting doesn't
require waiting for all of the in-flight workers to finish running. We
are also guaranteed that utrace->task will be valid if the utrace struct
has a positive reference count since the task struct is pinned.

To accommodate for the reference counting, rename get_utrace_bucket() to
find_utrace_bucket() since it doesn't grab any references, and rename
task_utrace_struct() to get_utrace_struct() to indicate that it grabs a
reference on the returned utrace struct.

The utrace_flags member of the utrace struct is reduced from a long to
an int to make room for an atomic reference counter without increasing
the size of the utrace struct. This is fine since there aren't enough
utrace flags to require the use of a long.

stp_utrace: always assume in_atomic() in utrace_report_death()

As we've established in the past, in_atomic() only works when PREEMPT is
enabled. On non-PREEMPT kernels, in_atomic() will return false even when
used inside a spin-locked critical section. Therefore, in order to make
utrace_report_death() safe on all configurations, always use a task
worker to perform the report work.

stp_utrace: remove useless RCU read locks

These RCU read locks don't actually protect anything. The task struct
pointer is not actually dereferenced in get_utrace_lock(), and the RCU
read lock in utrace_reset() serves no purpose at all.

stp_utrace: remove outdated utrace_cleanup_lock comment

This lock doesn't exist anymore.

Add support for accessing enumerators

Adds dwarf_get_enum, similar to dwarf_getscopevar, except search for a matching
DW_TAG_enumerator.  If a scoped variable then use the enumerator die
and attributes; translate_location  will convert to a constant.  If a
struct member then translate_components will fold the component locations then
use translate_location.

runtime: make probe locks rt-safe

The only safe alternative to rw locks on PREEMPT_RT is a raw spin lock.

Extend the stp lock helper API to provide rt-safe rw locks for probe
lock use.

alloc: use rt-safe spin lock for DEBUG_MEM

Use the stp_spin_lock macros to use the correct lock primitive when
PREEMPT_RT is in use.

stapbpf PR27030 WIP :: new bpf/uconversions.stp tapset

Tentative version of user_long_error() for bpf, needs more testing.
NEXT, the __bpf_probe_read_user_error() helper can be used to implement
the other user_{char,short,int} tapset functions.

This patch starts a new practice for tapset layout for tapset functions
that have a lkm/dyninst implementation and a separate bpf implementation:

- The lkm/dyninst implementation is placed in the toplevel tapset/
  directory, surrounded by %( runtime != "bpf" %? ... %).

- The bpf implementation is placed in the tapset/bpf/ directory.

Once applied to the rest of the tapsets, this practice should work to
eliminate the current proliferation of two-way
%( runtime != "bpf" %? implementation1 %: implementation2 %)
conditionals in the runtime code, and allow bpf versions of numerous
remaining tapset functions to be implemented and cleanly placed
into separate files under bpf/.

tapset/bpf fixups, esp. signed comparison

The substantive bugfix is to use signed opcodes for $rc<0 type comparisons.
Threw in some other tweaks/notes in the process.

Bug: delete_module() syscall might get interrupted under load.

staprun might fail to delete modules and leave ko in the system:

  $ sudo lsmod|grep stap
  stap_2eb3039808b647e990825b99fb1f9b6_18830   221184  0
  stap_eee9b566240fbeb1194347a571ccd68_17219   208896  0

Now we try up to 5 times for the delete_module() syscall in staprun with
a growing sleep interval between successive attempts upon the EINTR
error.

Tapset: aarc64: register()/u_register(): support  w* registers

buildrun: stop adding our own -Wframe-larger-than=XYZ CFLAGS

linux kbuild has included a CONFIG_FRAME_WARN option for some time,
which adds a -Wframe-larger-than=$(...) CFLAGS.  Until this patch,
systemtap used to add one of its own, on the theory that our generated
code really should not have large stack frames.  This is partly
assured by use of preallocated per-cpu "struct context" structures, so
our warning was a belt-and-suspenders protection.  However, this lower
limit is not sufficient any more.

On rawhide (linux 5.11, gcc 11), KASAN etc. makes the stack-frame of
the unwind_frame() function about 700 bytes, which is easily within
the CONFIG_FRAME_WARN but larger than 512.  We now just defer to
kbuild's wisdom.

stapbpf assembler bugfix :: stol in parse_imm should parse all bases

Other places in the assembler pass base=0 to allow octal/hex bases.
This one didn't which led to hex immediate arguments being zeroed out.

stap.bpf optional debugging aid :: show location of bpfasm-embeddedcode

Add CONFIG_COMPAT 32-bit support for aarch64 and powerpc

The aarch64 and powerpc kernels may be built with support for 32-bit
user-space applications.  On Fedora 33 the aarch64 kernel is
configured with CONFIG_COMPAT enabled.  Needed to provide some support
in _stp_is_compat_task2 for the aarch64.  The Fedora 33 ppc64le
kernels by default do not have CONFIG_COMPAT enabled, but included
similar check in there for powerpc in case locally built kernels
enable it.

PR27273: port to linux 5.11, kretprobes - unwinding

Missed one.

scripts/spin-rawhide: allow multiple spins in a day

Extend the rawhide rpm Release: header to include HHMM,
not just YYYYmmdd.

PR27273: port to linux 5.11, kretprobes

Linux commit d741bf41d7c changed how kretprobe_instances can
find their kretprobes.  Adapt with an autoconf and wrapper
function.

PR27273: port to linux 5.11

Main change is removal/movement of TIF_IA32 in linux commit ff170cd05953
and nearby.  Now using single a central wrapper _stp_is_compat_task() and
_stp_is_compat_task2() functions, instead of sprinkling
test_tsk_thread_flag(...) around the code base.

Also, suppressing CONFIG_DEBUG_INFO_BTF_MODULES generation for stap
modules, for diagnostic noise reduction.

PR27251: support buildid probing on --x--x--x perm binaries

We need to delegate to executable searches to debuginfod for binaries
that exist on the local system, but are unreadable.  Correcting
util.cxx access(3) checks from X_OK -> R_OK to avoid relying on
unreadable links/binaries, which results in stap being unable to probe
them at all.  This can come up for probing some setuid programs.

man/stap.1: add example about composing macros & embedded-c expressions

bpf-translate.cxx WIP bugfix for PR27030: delay adjusted_toks deallocation

Identified more diagnostic data (adjusted BPF assembler tokens)
that the BPF translator was deallocating prematurely on exception throw.
For now, fix the problem by keeping deallocation disabled
entirely. Only other solution I can think of is to catch and re-throw
any semantic error, copying the adjusted token at that point to
keep it from being deallocated.

PR27067: set procfs traceNN files' uid/gid too

commit e3d03db828 neglected to include the proper calls to set the
procfs traceNN files to the correct uid/gid ownership.  With those
files left as uid/gid=0/0, stapio running with a user with
stapusr/stapdev privileges couldn't fopenat() those files.  Now they
can again.  This problem became obvious after commit 4706ab3ca5c0,
which makes STAP_TRANS_PROCFS the default.

bugfix: unwinder: expr: DW_OP_push*: we forgot to push the result to the dwarf stack.

Most of the assembly routines in OpenSSL's libcrypto would produce unwinder failures
and the warning "WARNING: DWARF expression stack underflow in CFI" due to this bug.

runtime: utilize relay subbufs as much as possible

The relay subbufs used for printing are used very inefficiently, causing
print messages to be frequently dropped. The cause for this inefficiency
is that every time a print flush occurs, the current subbuf is switched
out even if it isn't filled. We can't wait for a subbuf to fill up
before switching it out either, or messages will be delayed.

To remedy this, we instead check to see if there's any data in any
subbuf and use that as an indicator to staprun to tell if there's data
available to read. Then when staprun attempts to read the data out, we
can switch out the current subbuf if it has data in it. This lets us
squeeze out every bit of storage from the subbufs.

Any print drops experienced after this patch should be fixed by
increasing the subbuf count (_stp_nsubbufs).

runtime: default to using procfs for the transport

Using debugfs for the transport results in a multitude of bugs when
running stap modules in parallel. The bugs include debugfs outright
failing, warnings hit in fs/inode.c, and kernel panics. Since procfs has
been more stable over the years, default to using it for the transport
instead of debugfs. Using procfs resolves the issues faced with debugfs.

stp_utrace: remove unneeded RCU-freed field from struct utrace

We're only using RCU on struct utrace in order to allow non-blocking
iteration through the hashlists. RCU is not used to manage the lifetime
of utrace structs; once a utrace struct is ready to be freed, nothing
will try to grab it anymore, so we can remove the unneeded utrace->freed
check.

stp_utrace: remove kmem cache usage

Some kernels appear to have trouble registering the same kmem_cache in
parallel, resulting in the following error as well as some other mayhem,
such as staprun hangs and kernel freezes:
sysfs: cannot create duplicate filename '/kernel/slab/:0000144'

This occurs when stap modules are registered in parallel with one
another.

The justification for using kmem caches in utrace is that the utrace
struct sizes are not powers of 2, and a lot of them can be allocated, so
leaving them to the kernel's default kmem caches can waste quite a bit
of memory. However, this is only a problem for the utrace struct, and
not really the utrace_engine struct, as the utrace_engine struct is 56
bytes on 64-bit, and can be allocated by the kernel's internal 64-byte
kmem cache with only 8 bytes wasted per allocation.

The same cannot be said for the utrace struct, since it's 144 bytes. It
would therefore be allocated from the 256-byte kmem cache, resulting in
112 bytes wasted per allocation. We can remedy this by reusing existing
memory in the struct for the 16-byte RCU callback head, bringing the
overall struct size down to 128 bytes and thus eliminating the need for
a kmem cache. This is safe because the reused struct members are no
longer used once the struct is ready to be freed.

This also eliminates a pesky rcu_barrier() we no longer required.

systemtap-service onboot: Skip updating the bootloader

It shows up that just modifying the default initrd is good enough,
no need to call kernel-install or new-kernel-pkg.  This speeds up
the systemtap-service onboot operation.

Revert "stp_utrace: remove kmem cache usage"

This reverts commit 23ef716aa40abe6473497f7d198003d0f199df58.

This was pushed on accident. :(

stp_utrace: add missing rcu_read_unlock() in get_utrace_lock() error path

This bug was introduced in 619f6940d ("PR26697: fix NULL pointer deref
in get_utrace_lock()), which was my first stap commit, and subsequently
where this project started going downhill as a result.

stp_utrace: remove kmem cache usage

Some kernels appear to have trouble registering the same kmem_cache in
parallel, resulting in the following error as well as some other mayhem,
such as staprun hangs and kernel freezes:
sysfs: cannot create duplicate filename '/kernel/slab/:0000144'

This occurs when stap modules are registered in parallel with one
another.

The justification for using kmem caches in utrace is that the utrace
struct sizes are not powers of 2, and a lot of them can be allocated, so
leaving them to the kernel's default kmem caches can waste quite a bit
of memory. However, this is only a problem for the utrace struct, and
not really the utrace_engine struct, as the utrace_engine struct is 56
bytes on 64-bit, and can be allocated by the kernel's internal 64-byte
kmem cache with only 8 bytes wasted per allocation.

The same cannot be said for the utrace struct, since it's 144 bytes. It
would therefore be allocated from the 256-byte kmem cache, resulting in
112 bytes wasted per allocation. We can remedy this by reusing existing
memory in the struct for the 16-byte RCU callback head, bringing the
overall struct size down to 128 bytes and thus eliminating the need for
a kmem cache. This is safe because the reused struct members are no
longer used once the struct is ready to be freed.

This also eliminates a pesky rcu_barrier() we no longer required.

Ignore link map entries with no name.

Do not attempt to add entries to tls_link_map_name if there is no name
for the entry in the link map.

PR27185: conversions.exp test enhancements

I've adjusted the stress tests referenced in
systemtap.stress/conversions.exp to make them more concise and allow
all the test definitions to be shared across each variant.

transport: procfs: fix transposed procfs removal ordering

In order to avoid a use-after-free bug, we must remove the pde before
doing the path_put(), even though this contradicts what one would
naturally think the ordering should be.

This fixes the following KASAN splat:
BUG: KASAN: use-after-free in proc_remove+0x7b/0x80
Read of size 8 at addr ffff8882dc3b00b8 by task staprun-d/6732
CPU: 7 PID: 6732 Comm: staprun-d Tainted: G           OE    --------- -  - 4.18.0-259.el8.x86_64+debug #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Call Trace:
 dump_stack+0x8e/0xd0
 print_address_description.constprop.3+0x1f/0x300
 __kasan_report.cold.7+0x76/0xbf
 ? proc_remove+0x7b/0x80
 kasan_report+0xe/0x20
 proc_remove+0x7b/0x80
 __stp_procfs_relay_remove_buf_file_callback+0x254/0x346 [orxray_libc_usleep_XX_6587]
 ? __stp_procfs_relay_remove_buf_file_callback+0x346/0x346 [orxray_libc_usleep_XX_6587]
 ? __stp_relay_remove_buf_file_callback+0x28/0x29 [orxray_libc_usleep_XX_6587]
 ? relay_close_buf+0xe0/0x130
 ? relay_close+0x14f/0x470
 ? _stp_transport_data_fs_close+0x1b/0x27 [orxray_libc_usleep_XX_6587]
 ? _stp_procfs_transport_fs_close+0xa/0xb [orxray_libc_usleep_XX_6587]
 ? _stp_transport_fs_close+0x24/0x26 [orxray_libc_usleep_XX_6587]
 ? _stp_transport_close+0x1e/0x24 [orxray_libc_usleep_XX_6587]
 ? cleanup_module+0xa/0xb [orxray_libc_usleep_XX_6587]
 ? __x64_sys_delete_module+0x2cc/0x4a0
 ? __ia32_sys_delete_module+0x4a0/0x4a0
 ? lockdep_hardirqs_on_prepare+0x343/0x4f0
 ? do_syscall_64+0x22/0x420
 ? do_syscall_64+0xa5/0x420
 ? entry_SYSCALL_64_after_hwframe+0x6a/0xdf
Allocated by task 6587:
 save_stack+0x19/0x80
 __kasan_kmalloc.constprop.10+0xc1/0xd0
 kmem_cache_alloc+0xfe/0x350
 __proc_create+0x1f6/0x740
 proc_create_reg+0x61/0x100
 proc_create_data+0x79/0xf0
 __stp_procfs_relay_create_buf_file_callback+0xcb/0x43e [orxray_libc_usleep_XX_6587]
Freed by task 6732:
 save_stack+0x19/0x80
 __kasan_slab_free+0x125/0x170
 kmem_cache_free+0xcd/0x360
 proc_evict_inode+0x73/0x100
 evict+0x29e/0x590
 __dentry_kill+0x326/0x5a0
 dentry_kill+0x94/0x410
 dput+0x3b0/0x4a0
 path_put+0x2d/0x60
 __stp_procfs_relay_remove_buf_file_callback+0x24c/0x346 [orxray_libc_usleep_XX_6587]
The buggy address belongs to the object at ffff8882dc3b0000
                            which belongs to the cache proc_dir_entry of size 512
The buggy address is located 184 bytes inside of
                            512-byte region [ffff8882dc3b0000, ffff8882dc3b0200)
The buggy address belongs to the page:
page:ffffea000b70ec00 refcount:1 mapcount:0 mapping:ffff8881061d4f00 index:0x0 compound_mapcount: 0
flags: 0x17ffffc0008100(slab|head)
raw: 0017ffffc0008100 dead000000000100 dead000000000200 ffff8881061d4f00
raw: 0000000000000000 0000000080190019 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
 ffff8882dc3aff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff8882dc3b0000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8882dc3b0080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                        ^
 ffff8882dc3b0100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff8882dc3b0180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

diagnostics: amplify .return $context var warning

Suggested-by: Craig Ringer <craig@2ndquadrant.com>

stapbpf (for PR27030): bugfix the b71d20af bugfix

stap commit b71d20af819 fixed error messages in bpf assembly
(being broken by implicit deallocation of stack vars on exception throw)
but neglected the fact that visit_embeddedcode can recurse
(via emit_functioncall) such that a single bpf_unparser field for
storing asm_stmts will get overwritten by the recursive call.

Alloc/free a separate statement list per visit_embeddedcode call instead.

NEWS: correct arch names for recent tls code

Clarify that it's the 64-bit cpus that have tls var enablement.

Update test for bpf raw tracepoints to work with Linux 5.7 kernels

The kernel commit 70ed506c3bbcfa846d4636b23051ca79fa4781f7 in Linux
5.7 and newer replaced the bpf_raw_tracepoint_release function with
bpf_raw_tp_link_release.  This change in function names would cause
SystemTap's test for BPF raw tracepoint support to fail.  Updated the
check to look for the newer alternative function name.

Remove non-posix == operators from configure.ac

The configure.ac script contains test commands with the == operator,
which is supported by most shells, but fails if /bin/sh has a test
built-in which is strictly posix-compliant.

Add BuildRequires: make

https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot

Don't warn about freeing a NULL pointer for functions that tolerate it

Passing a NULL pointer to kfree(), vfree(), and free_percpu() is fine
and supported behavior; these functions will just return early when
given a NULL pointer. However, DEBUG_MEM doesn't know about this, and
warns about it even though it isn't a problem. This mutes the warning
from _stp_mem_debug_free() when these functions receive a NULL pointer.

Signed-off-by: Sultan Alsawaf <sultan@openresty.com>

Add stapdyn VMA-tracking.

To handle VMA-tracking in stapdyn: 1) do not emit pragma:vma so the
kernel VMA-tracker is not enabled 2) add a stapdyn version of
_stp_umodule_relocate which 3) uses dwfl_linux_proc_report to find the
appropriate module start 4) relocate the offset.  This makes tls
possible so it is enabled for stapdyn.

Conditionally define ASYNC_SIZE in stack-s390.c

Upstream commit ce3dc44749 removed ASYNC_SIZE.

task_finder2: fix task worker race on module unload

Unfortunately, __stp_tf_cancel_all_task_work() does not guarantee that
all of the task finder's task workers will be finished executing when it
returns. In this case, we rely on the stp_task_work API to prevent the
module from being unloaded while there are task workers in-flight, which
works, but the stp_task_work API is notified of a task worker finishing
before it actually finishes. Inside __stp_tf_task_worker_fn(), the
call to the task worker's function (tf_work->func) is where the final
refcount in the stp_task_work API could be put, but there will still be
instructions left in the task worker that will be executing for a short
time after that. In that short time, there can be a race where the
module is unloaded before the task worker finishes executing all of its
instructions, especially if the task worker gets preempted during this
time on a PREEMPT kernel.

To remedy this, we must ensure that the last instruction in
__stp_tf_task_worker_fn() is where the stp_task_work API is notified of
a task worker finishing.

task_finder2: fix list corruption in __stp_tf_cancel_all_task_work()

The previous commit (b26b4e2c2 "task_finder2: fix panics due to broken
task work cancellation") made it possible for the next node in the task
work list to be free, which would made list_for_each_entry_safe() not so
safe anymore. Using list_for_each_entry_safe() is still the fastest
approach here, so when the next node in the list happens to be freed, we
should just restart iteration on the list.

task_finder2: fix panics due to broken task work cancellation

The task_work_cancel() API uses function pointers to uniquely identify
task work structs, so there's no guarantee that a specific task work
struct we want to cancel is the one that will actually get canceled.
This issue would cause task work structs to be freed while they were
still queued up on the task's task-worker list.

This is an example of one such panic, where the DEBUG_MEM feature
reported that a __stp_tf_task_work struct (56 bytes) wasn't freed,
because that specific task worker got canceled and instead an active
task worker got freed!

orxray_resty_mem_X_35062: ERROR: Memory ffff8809ed388620 len=56 allocation type: kmalloc. Not freed.
BUG: unable to handle kernel paging request at ffffffffa0570877
IP: [<ffffffffa0570877>] 0xffffffffa0570876
PGD 1abd067 PUD 1abe063 PMD 1028286067 PTE 0
Oops: 0010 [#1] SMP
CPU: 3 PID: 1338 Comm: nginx Tainted: G           OE  ------------   3.10.0-514.10.2.el7.x86_64.debug #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
task: ffff880eae2d0000 ti: ffff880eaf2e4000 task.ti: ffff880eaf2e4000
RIP: 0010:[<ffffffffa0570877>]  [<ffffffffa0570877>] 0xffffffffa0570876
RSP: 0018:ffff880eaf2e7d78  EFLAGS: 00010282
RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff8809ed388640 RSI: 0000000000000000 RDI: ffff8809ed388640
RBP: ffff880eaf2e7da0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: ffffffffff90001c R12: ffffffff8248b1c0
R13: ffff880eae2d0818 R14: ffff880eae2d0000 R15: 00007eff3d2490b0
FS:  00007eff3dcd2740(0000) GS:ffff881037c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffa0570877 CR3: 0000000ebce67000 CR4: 00000000003406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Stack:
 ffffffff810c6544 ffff880eaf2e7f58 ffff880eaf2e7e70 ffff880eae2d0000
 00007eff3dcb3338 ffff880eaf2e7e38 ffffffff810b31ba ffff880eaf2e7dc0
 ffffffff8106c279 ffff880eaf2e7e50 ffff880ef8a792c0 ffff880eaf2e7df8
Call Trace:
 [<ffffffff810c6544>] ? task_work_run+0xb4/0xe0
 [<ffffffff810b31ba>] get_signal_to_deliver+0x85a/0x960
 [<ffffffff8106c279>] ? kvm_sched_clock_read+0x9/0x20
 [<ffffffff810e7b4d>] ? sched_clock_local+0x1d/0x80
 [<ffffffff810e7dd8>] ? sched_clock_cpu+0xb8/0xe0
 [<ffffffff810324a7>] do_signal+0x57/0x6e0
 [<ffffffff8176dba6>] ? int_very_careful+0x5/0xd
 [<ffffffff81032b8f>] do_notify_resume+0x5f/0xb0
 [<ffffffff8176dbfd>] int_signal+0x12/0x17
Code:  Bad RIP value.
RIP  [<ffffffffa0570877>] 0xffffffffa0570876
 RSP <ffff880eaf2e7d78>
CR2: ffffffffa0570877
---[ end trace 1cdf8e5b522b246e ]---

Work around kernel claims of a function("input_event").inline probe point

Newer Fedora Linux kernels (F32/F33) are claiming a
function("input_event").inline probe point exists and has no
arguments.  The build of the stapgames block and eater fail because
the needed arguments are not found.  Examined where the claimed inline
input_events functions are with:

  stap -v -L 'kernel.function("input_event").*'

There appears to be a bogus one listed inside the callable input_event
function itself.  Worked around this by setting the game.input tapset
probe to function("input_event").call to exclude the bogus inline
version.  It was verified that the games got input from the keyboard
with this patch.

Adjust enospc.stp example to work with Linux 5.9 kernels

The Linux 5.9 kernels changed the type of the inode agument passed
into the btrfs_check_data_free_space function.  Need to check to see
if it is the new struct btrfs_inode being used or the old struct inode
and use a different field to get the s_dev value if required.