Bug 1656795 - sysc_bdflush.stp was not adapted for kernel 4.17+
Summary: sysc_bdflush.stp was not adapted for kernel 4.17+
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: systemtap
Version: 8.0
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: 8.0
Assignee: Frank Ch. Eigler
QA Contact: Martin Cermak
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-06 10:57 UTC by Martin Cermak
Modified: 2019-06-14 01:41 UTC (History)
3 users (show)

Fixed In Version: systemtap-4.0-4.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-14 01:41:42 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)
updated tapset file that seems to work for me (2.71 KB, text/plain)
2018-12-06 10:57 UTC, Martin Cermak
no flags Details

Description Martin Cermak 2018-12-06 10:57:33 UTC
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.

Comment 3 Martin Cermak 2019-02-12 08:38:07 UTC
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
=======

Comment 4 Martin Cermak 2019-02-12 15:41:39 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.