Bug 160907

Summary: Support for a couple of recent Linux syscalls, syscall wrapper bugfixes
Product: [Developer tools] valgrind Reporter: Jakub Jelinek <jakub>
Component: generalAssignee: Julian Seward <jseward>
Status: RESOLVED FIXED    
Severity: normal CC: Piotr.Findeisen
Priority: NOR    
Version: 3.4 SVN   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: valgrind-3.3.0-syscalls2.patch

Description Jakub Jelinek 2008-04-16 17:17:51 UTC
The patch I'll attach on top of SVN trunk adds signalfd, eventfd, timerfd,
epoll_pwait syscall wrappers and fixes a couple of bugs in utimensat, futimesat,
utimes and ppoll syscall wrappers.
Comment 1 Jakub Jelinek 2008-04-16 17:18:49 UTC
Created attachment 24354 [details]
valgrind-3.3.0-syscalls2.patch
Comment 2 Jakub Jelinek 2008-04-16 17:20:26 UTC
Testcase for glibc 2.8 and recentish kernel, just uses a bunch of new syscalls:

#define _GNU_SOURCE
#include <fcntl.h>
#include <signal.h>
#include <sys/epoll.h>
#include <sys/eventfd.h>
#include <sys/poll.h>
#include <sys/signalfd.h>
#include <sys/stat.h>

int
main (void)
{
  sigset_t mask;
  sigemptyset (&mask);
  sigaddset (&mask, SIGUSR1);
  int fd = signalfd (-1, &mask, 0);
  sigaddset (&mask, SIGUSR2);
  fd = signalfd (fd, &mask, 0);
  int fd2 = eventfd (5, 0);
  eventfd_t ev;
  eventfd_read (fd2, &ev);
  struct timespec ts = { .tv_sec = 1, .tv_nsec = 0 };
  struct pollfd pfd[2] = { [0].fd = fd, [0].events = POLLIN|POLLOUT,
                           [1].fd = fd2, [1].events = POLLIN|POLLOUT };
  ppoll (pfd, 2, &ts, &mask);
  close (creat ("/tmp/valgrind-utimensat-test", O_RDWR));
  struct timespec ts2[2] = { [0].tv_sec = 10000000, [1].tv_sec = 20000000 };
  utimensat (AT_FDCWD, "/tmp/valgrind-utimensat-test", ts2, 0);
  int fd3 = epoll_create (10);
  struct epoll_event evs[10];
  epoll_pwait (fd3, evs, 10, 0, &mask);
  return 0;
}
Comment 3 Bart Van Assche 2008-04-26 10:26:36 UTC
Thanks for the patch and the test program. Patch and test program have been committed on the Valgrind trunk. See also memcheck/tests/linux-syscalls-2007.c. Converted test program from C++ to C90 syntax, fixed a bug (2nd argument of creat() call is wrong) and added two unlink() calls for the created file.
Comment 4 Bart Van Assche 2008-04-26 20:11:03 UTC
Fix will be included in Valgrind 3.3.1.
Comment 5 Jakub Jelinek 2008-04-26 20:27:15 UTC
Sorry for the creat thinko, the program was actually written in ISO C99, but you probably still want ISO C90 in valgrind.

Anyway, more importantly, I've been told that the timerfd syscall has been changed
in the kernel, see:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4d672e7ac79b5ec5cdc90e450823441e20464691;hp=5e05ad7d4e3b11f935998882b5d9c3b257137f1b
so either the timerfd syscall handling should be nuked from my patch, or it needs
to be adjusted for the changes.
Comment 6 Bart Van Assche 2008-04-27 15:33:45 UTC
Regarding the timerfd syscall, which is only present in kernel 2.6.22: there are several Linux distributions that use the 2.6.22 kernel (Ubuntu 7.10, OpenSUSE 10.3, and maybe others) so I did not drop support for this syscall but the code that handles the timerfd/timerfd_create syscall now depends on the kernel version detected during runtime.

timerfd_create()/timerfd_gettime()/timerfd_settime() support has been added to coregrind/m_syswrap/syswrap-linux.c. The regression test memcheck/tests/linux-syscalls-2007.c has been modified such that it only is compiled and run if the relevant functions have been detected at configure time. And a regression test for timerfd_create()/timerfd_gettime()/timerfd_settime() (memcheck/tests/linux-timerfd-syscall.c) has been added.

Any comments are welcome.
Comment 7 Julian Seward 2008-05-01 23:15:08 UTC
Hi JJ.  Thanks for the patch.  A question resulting from this: the
Valgrind trunk now doesn't build on ppc32-linux (and I suspect on
ppc64-linux):

Making all in coregrind
m_syswrap/syswrap-ppc32-linux.c:1831: error: '__NR_timerfd' undeclared here
 (not in a function)

I can't find any definition of __NR_timerfd anywhere:

$ find . -name "*.h" | xargs grep __NR_timerfd
./include/vki/vki-scnums-ppc64-linux.h:#define __NR_timerfd_create      306
./include/vki/vki-scnums-ppc64-linux.h:#define __NR_timerfd_settime     311
./include/vki/vki-scnums-ppc64-linux.h:#define __NR_timerfd_gettime     312
./include/vki/vki-scnums-amd64-linux.h:#define __NR_timerfd_create      283
./include/vki/vki-scnums-amd64-linux.h:#define __NR_timerfd_settime     286
./include/vki/vki-scnums-amd64-linux.h:#define __NR_timerfd_gettime     287
./include/vki/vki-scnums-x86-linux.h:#define __NR_timerfd_create        322
./include/vki/vki-scnums-x86-linux.h:#define __NR_timerfd_settime       325
./include/vki/vki-scnums-x86-linux.h:#define __NR_timerfd_gettime       326
./include/vki/vki-scnums-ppc32-linux.h:#define __NR_timerfd_create      306
./include/vki/vki-scnums-ppc32-linux.h:#define __NR_timerfd_settime     311
./include/vki/vki-scnums-ppc32-linux.h:#define __NR_timerfd_gettime     312

Should a definition for __NR_timerfd be provided, or does it need a
different name?  Please advise.
Comment 8 Bart Van Assche 2008-05-02 08:13:56 UTC
At least for the powerpc architecture, __NR_timerfd == __NR_timerfd_create == 306. See also the patch "Patch: [POWERPC] Wire up new timerfd syscalls" or this commit in Linus' tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fb8642db19d57361be671a30d3f13defaf6b6cff
Comment 9 Bart Van Assche 2008-05-02 08:52:54 UTC
What should happen IMHO is to replace LINXY(__NR_timerfd, ...) by LINXY(__NR_timerfd_create, ...) in the two files coregrind/m_syswrap/syswrap-ppc32-linux.c and coregrind/m_syswrap/syswrap-ppc64-linux.c. The timerfd() system call was present in kernel 2.6.22 but has been obsoleted, and its system call number was reassigned to the timerfd_create() system call.
Comment 10 Bart Van Assche 2008-05-13 09:22:20 UTC
Relevant commits: 7942, 7983 and 8051.
Comment 11 Tom Hughes 2008-11-18 12:51:17 UTC
*** Bug 175482 has been marked as a duplicate of this bug. ***