Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-28119

glibc: loss of rseq acceleration for sched_getcpu [rhel-9]

    • Yes
    • None
    • Patch
    • 7a76f218677d149d8b7875b336722108239f7ee9
    • rhel-sst-pt-libraries
    • ssg_platform_tools
    • 2
    • False
    • Hide

      None

      Show
      None
    • 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

      1.  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 ());
      }
      
      
      1.  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

              Unassigned Unassigned
              xmcoufal Martin Coufal
              Platform Tools - Libraries Bot Platform Tools - Libraries Bot
              Sergey Kolosov Sergey Kolosov
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated: