-
Bug
-
Resolution: Unresolved
-
Normal
-
rhel-9.3.0, rhel-9.4, rhel-9.5, rhel-10.0.beta
-
Yes
-
None
-
Patch
-
7a76f218677d149d8b7875b336722108239f7ee9
-
rhel-sst-pt-libraries
-
ssg_platform_tools
-
2
-
False
-
-
No
-
None
-
None
-
None
-
Unspecified Release Note Type - Unknown
-
-
aarch64
-
None
What were you trying to do that didn't work?
There is a possible regression for bz2024347, strace shows getcpu call with rseq enabled:
$ strace -E GLIBC_TUNABLES=glibc.pthread.rseq=1 ./tst execve("./tst", ["./tst"], 0xaaab0a13a860 /* 48 vars */) = 0 brk(NULL) = 0x3c75a000 brk(0x3c75a024) = 0x3c75a024 brk(NULL) = 0x3c75a024 faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=28123, ...}) = 0 mmap(NULL, 28123, PROT_READ, MAP_PRIVATE, 3, 0) = 0xffffbbd20000 close(3) = 0 openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\360t\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=2300336, ...}) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffbbd1e000 mmap(NULL, 1826768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffffbbb2e000 mprotect(0xffffbbcbc000, 122880, PROT_NONE) = 0 mmap(0xffffbbcda000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19c000) = 0xffffbbcda000 mmap(0xffffbbce0000, 49104, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffffbbce0000 close(3) = 0 set_tid_address(0xffffbbd1ed90) = 62758 set_robust_list(0xffffbbd1eda0, 24) = 0 rseq(0xffffbbd1f460, 0x20, 0, 0xd428bc00) = 0 mprotect(0xffffbbcda000, 16384, PROT_READ) = 0 mprotect(0x41f000, 4096, PROT_READ) = 0 mprotect(0xffffbbd2a000, 8192, PROT_READ) = 0 prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 munmap(0xffffbbd20000, 28123) = 0 getcpu([2], NULL, NULL) = 0 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0 getrandom("\x79\x55\x48\xc0\x0f\x33\x6b\xab", 8, GRND_NONBLOCK) = 8 brk(NULL) = 0x3c75a024 brk(0x3c77b024) = 0x3c77b024 brk(0x3c77c000) = 0x3c77c000 write(1, "2\n", 22 ) = 2 exit_group(0) = ? +++ exited with 0 +++
In the original bug in the comments it is stated that getcpu call should not be present when rseq is enabled. Maybe after some changes getcpu call is now to be expected?
Please provide the package NVR for which bug is seen:
Last successful run of this test was in glibc-2.34-72.el9
First failure observed in glibc-2.34-78.el9
How reproducible:
always
Steps to reproduce
- compile the example: gcc tst.c -o tst
#define _GNU_SOURCE #include <stdio.h> #include <sched.h> int main (void) { printf ("%d\n", sched_getcpu ()); }
- strace -E GLIBC_TUNABLES=glibc.pthread.rseq=1 ./tst
Expected results
getcpu call not detected while using rseq
Actual results
getcpu([2], NULL, NULL) = 0