Bug 2030870

Summary:	valgrind: Please handle the rseq system call
Product:	[Fedora] Fedora	Reporter:	Florian Weimer <fweimer>
Component:	valgrind	Assignee:	Mark Wielaard <mjw>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	35	CC:	aoliva, arjun, codonell, dj, dodji, fweimer, jakub, law, mcermak, mfabian, mjw, pfrankli, rth, sipoyare
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	valgrind-3.18.1-7.fc35	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	2030872 (view as bug list)		Environment:
Last Closed:	2021-12-21 01:14:38 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2030872

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.