RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Created attachment 1512039 [details]
updated tapset file that seems to work for me

The bdflush syscall tapset seems to miss the 4.17+ kernel update, so that following shows up using systemtap-4.0-2.el8 or current upstream head 891810c24:

=======
 8.0 Server x86_64 # stap -vp4 -e 'probe syscall.bdflush { println(argstr)}'
Pass 1: parsed user script and 479 library scripts using 185108virt/76312res/8792shr/67208data kb, in 440usr/40sys/481real ms.
semantic error: resolution failed in alias expansion builder

semantic error: while resolving probe point: identifier 'syscall' at <input>:1:7
        source: probe syscall.bdflush { println(argstr)}
                      ^

semantic error: no match

Pass 2: analyzed script: 0 probes, 0 functions, 0 embeds, 0 globals using 236060virt/128468res/10020shr/118160data kb, in 1230usr/140sys/1372real ms.
Pass 2: analysis failed.  [man error::pass2]
(1)  8.0 Server x86_64 #
=======

Possible fix attached.

Upstream commit https://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commitdiff;h=aacee6563b7fd835b9a21e4ae5a0b4f7f743c7ef

Tests fine except for aarch64, where the pass4 fails with 'error: ‘__NR_bdflush’ undeclared' on kernel-4.18.0-67.el8.aarch64.  It turns out, that __NR_bdflush was last defined in kernel-headers-4.16.0-14.el8+7.aarch64.rpm as #define __NR_bdflush 1075 .  The upcoming kernel-headers-4.17.0-0.rc6.1.el8+7.aarch64.rpm dropped it.  Following update fixes the issue for me:

=======
diff --git a/runtime/linux/compat_unistd.h b/runtime/linux/compat_unistd.h
index 13f98a424..c8199f3fa 100644
--- a/runtime/linux/compat_unistd.h
+++ b/runtime/linux/compat_unistd.h
@@ -37,6 +37,9 @@
 #ifndef __NR_accept4
 #define __NR_accept4 (__NR_syscall_max + 1)
 #endif
+#ifndef __NR_bdflush
+#define __NR_bdflush (__NR_syscall_max + 1)
+#endif
 #ifndef __NR_bind
 #define __NR_bind (__NR_syscall_max + 1)
 #endif
=======

The aarch64 problem worked around in https://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commitdiff;h=ba7b83ec1ad1fe0f71b40dfc8c4d4ab595607190 .  This is expected to make it ti rhel-8.1.0.  Verified with systemtap-4.0-7.el8 non-aarch64 arches.