Bug 2030870 - valgrind: Please handle the rseq system call
Summary: valgrind: Please handle the rseq system call
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: valgrind
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mark Wielaard
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 2030872
TreeView+ depends on / blocked
 
Reported: 2021-12-09 23:00 UTC by Florian Weimer
Modified: 2021-12-21 01:14 UTC (History)
14 users (show)

Fixed In Version: valgrind-3.18.1-7.fc35
Clone Of:
: 2030872 (view as bug list)
Environment:
Last Closed: 2021-12-21 01:14:38 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Florian Weimer 2021-12-09 23:00:46 UTC
glibc will soon start calling rseq during startup and thread creation.

--2062070-- WARNING: unhandled amd64-linux syscall: 334
--2062070-- You may be able to write your own handler.
--2062070-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--2062070-- Nevertheless we consider this a bug.  Please report
--2062070-- it at http://valgrind.org/support/bug_reports.html.

Failing the rseq system call with ENOSYS is fine, there is a fallback.

Ideally, we'd like this in Fedora 35, rawhide, and CentOS 9 Stream.

Comment 1 Mark Wielaard 2021-12-10 15:45:03 UTC
OK, so if I understand the glibc rseq support correctly it involves reimplementing sched_getcpu using rseq, so basically we would like something like the following to "work" correctly (return zero, without any extra warnings/output) under valgrind:

#define _GNU_SOURCE
#include <sched.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <stdio.h>
#include <stdint.h>

static int sys_rseq (volatile void *rseq_abi, uint32_t rseq_len,
                     int flags, uint32_t sig)
{
  return syscall (__NR_rseq, rseq_abi, rseq_len, flags, sig);
}

int
main ()
{
  int e = 0;

  if (sys_rseq (NULL, 0, 0, 0) == 0)
    {
      puts ("BAD: rseq succeeded ????");
      e = 1;
    }

  if (sched_getcpu () == -1)
    {
      puts ("BAD: sched_getcpu failed ????");
      e = 1;
    }

  return e;
}

Which currently gives:

$ valgrind -q ./rseq_test 
--569834-- WARNING: unhandled amd64-linux syscall: 334
--569834-- You may be able to write your own handler.
--569834-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--569834-- Nevertheless we consider this a bug.  Please report
--569834-- it at http://valgrind.org/support/bug_reports.html.
$ echo $?
0

Comment 2 Florian Weimer 2021-12-10 16:04:36 UTC
sched_getcpu does not do a system call with rseq (neither rseq nor anything else), so that check is redundant.

The rseq system call looks fine as a smoke test.

Comment 3 Mark Wielaard 2021-12-10 17:19:59 UTC
I proposed implementing rseq as ENOSYS upstream:
https://bugs.kde.org/show_bug.cgi?id=405377

And I am building valgrind-3.18.1-6.fc36 for rawhide with the proposed patch.

Comment 4 Fedora Update System 2021-12-15 12:03:51 UTC
FEDORA-2021-f951dad05f has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f951dad05f

Comment 5 Fedora Update System 2021-12-16 02:08:09 UTC
FEDORA-2021-f951dad05f has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f951dad05f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f951dad05f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 6 Fedora Update System 2021-12-21 01:14:38 UTC
FEDORA-2021-f951dad05f has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


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