From: "mcermak at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug runtime/31215] New: @__compat_task misbehaves on RHEL9 x86_64
Date: Fri, 05 Jan 2024 15:20:13 +0000 [thread overview]
Message-ID: <bug-31215-6586@http.sourceware.org/bugzilla/> (raw)
https://sourceware.org/bugzilla/show_bug.cgi?id=31215
Bug ID: 31215
Summary: @__compat_task misbehaves on RHEL9 x86_64
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: runtime
Assignee: systemtap at sourceware dot org
Reporter: mcermak at redhat dot com
Target Milestone: ---
Apparently the @__compat_task macro misbehaves on RHEL9. See how
_stp_is_compat_task() returns 0 although it should clearly return 1 (the last
column in systemtap output below). GCC was invoked with -m32:
(Note that the 943211848ea34e4d5d10f0094dc84b47667d84ed version of
sched_rr_get_interval.c had to be slightly updated to avoid SEGV by commenting
out the latest subtest)
el9 x86_64 # gcc
/root/systemtap/testsuite/systemtap.syscall/sched_rr_get_interval.c -m32 -lrt
-Wno-stringop-overflow -lm -o /tmp/sched_rr_get_interval -g
el9 x86_64 # stap --poison-cache -ge 'probe syscall.mmap2 {printdln(", ", name,
_stp_syscall_nr(), syscall_name(_stp_syscall_nr()), execname(), probefunc(),
%{_stp_is_compat_task()%})}' -c /tmp/sched_rr_get_interval
/tmp/stap06kHAR/stap_ad583362bc2821360e315a0e4befae13_166569_src.o: warning:
objtool: _stp_vsprint_memory+0x220: call to __get_user_nocheck_1() with UACCESS
enabled
/tmp/stap06kHAR/stap_ad583362bc2821360e315a0e4befae13_166569_src.o: warning:
objtool: .altinstr_replacement+0x36: call to copy_user_generic_string() with
UACCESS enabled
mmap2, 192, lgetxattr, sched_rr_get_in, 0xffffffffabf83e40, 0
mmap2, 192, lgetxattr, sched_rr_get_in, 0xffffffffabf83e40, 0
mmap2, 192, lgetxattr, sched_rr_get_in, 0xffffffffabf83e40, 0
mmap2, 192, lgetxattr, sched_rr_get_in, 0xffffffffabf83e40, 0
mmap2, 192, lgetxattr, sched_rr_get_in, 0xffffffffabf83e40, 0
mmap2, 192, lgetxattr, sched_rr_get_in, 0xffffffffabf83e40, 0
mmap2, 192, lgetxattr, sched_rr_get_in, 0xffffffffabf83e40, 0
mmap2, 192, lgetxattr, sched_rr_get_in, 0xffffffffabf83e40, 0
mmap2, 192, lgetxattr, sched_rr_get_in, 0xffffffffabf83e40, 0
mmap2, 192, lgetxattr, sched_rr_get_in, 0xffffffffabf83e40, 0
mmap2, 192, lgetxattr, sched_rr_get_in, 0xffffffffabf83e40, 0
mmap2, 9, mmap, stapio, 0xffffffffabc32720, 0
mmap2, 9, mmap, stapio, 0xffffffffabc32720, 0
mmap2, 9, mmap, stapio, 0xffffffffabc32720, 0
el9 x86_64 #
Now, here is how this works fine on rhel8:
el8 x86_64 # gcc
/root/systemtap/testsuite/systemtap.syscall/sched_rr_get_interval.c -m32 -lrt
-Wno-stringop-overflow -lm -o /tmp/sched_rr_get_interval -g
el8 x86_64 # stap --poison-cache -ge 'probe syscall.mmap2 {printdln(", ", name,
_stp_syscall_nr(), syscall_name(_stp_syscall_nr()), execname(), probefunc(),
%{_stp_is_compat_task()%})}' -c /tmp/sched_rr_get_interval
mmap2, 192, mmap2, sched_rr_get_in, 0xffffffff8c0e9d50, 1
el8 x86_64 # stap --poison-cache -ge 'probe syscall.mmap2 {printdln(", ", name,
_stp_syscall_nr(), syscall_name(_stp_syscall_nr()), execname(), probefunc(),
%{_stp_is_compat_task()%})}' -c /tmp/sched_rr_get_interval
mmap2, 192, mmap2, sched_rr_get_in, 0xffffffff8c0e9d50, 1
mmap2, 192, mmap2, sched_rr_get_in, 0xffffffff8c0e9d50, 1
mmap2, 192, mmap2, sched_rr_get_in, 0xffffffff8c0e9d50, 1
mmap2, 192, mmap2, sched_rr_get_in, 0xffffffff8c0e9d50, 1
mmap2, 192, mmap2, sched_rr_get_in, 0xffffffff8c0e9d50, 1
mmap2, 192, mmap2, sched_rr_get_in, 0xffffffff8c0e9d50, 1
mmap2, 192, mmap2, sched_rr_get_in, 0xffffffff8c0e9d50, 1
mmap2, 192, mmap2, sched_rr_get_in, 0xffffffff8c0e9d50, 1
mmap2, 192, mmap2, sched_rr_get_in, 0xffffffff8c0e9d50, 1
mmap2, 192, mmap2, sched_rr_get_in, 0xffffffff8c0e9d50, 1
mmap2, 192, mmap2, sched_rr_get_in, 0xffffffff8c0e9d50, 1
mmap2, 192, mmap2, sched_rr_get_in, 0xffffffff8c0e9d50, 1
mmap2, 192, mmap2, sched_rr_get_in, 0xffffffff8c0e9d50, 1
mmap2, 9, mmap, stapio, 0xffffffff8be2e730, 0
mmap2, 9, mmap, stapio, 0xffffffff8be2e730, 0
mmap2, 9, mmap, stapio, 0xffffffff8be2e730, 0
el8 x86_64 #
--
You are receiving this mail because:
You are the assignee for the bug.
next reply other threads:[~2024-01-05 15:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-05 15:20 mcermak at redhat dot com [this message]
2024-01-05 15:20 ` [Bug runtime/31215] " mcermak at redhat dot com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-31215-6586@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=systemtap@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).