https://bugs.kde.org/show_bug.cgi?id=501365
Mark Wielaard <m...@klomp.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |m...@klomp.org
Summary|unhandled amd64-linux |unhandled amd64-linux
|syscall: 323 |syscall: 323 (userfaultfd)
--- Comment #4 from Mark Wielaard <m...@klomp.org> ---
(In reply to Paul Floyd from comment #3)
> I don’t think that this should be generic as it’s Linux only.
Yes, this should be moved from syswrap-generic.c to syswrap-linux.c
And it should then use LINX_ instead of GENX_.
> It looks to me as if this creates a file descriptor. If so it needs to use
> the fd tracking mechanism.
Yes, so this needs a POST (called after the syscall succeeds)
that does the file descriptor tracking, something like:
POST(sys_userfaultfd)
{
if (!ML_(fd_allowed)(RES, "userfaultfd", tid, True)) {
VG_(close)(RES);
SET_STATUS_Failure( VKI_EMFILE );
} else {
if (VG_(clo_track_fds))
ML_(record_fd_open_nameless)(tid, RES);
}
}
And when a syscall wrapper has a POST it needs to be registered with XY (X has
PRE, Y has POST).
So LINXY in the syswrap-<arch>-linux.c syscall_main_table array.
BTW. Although this isn't a syscall defined in
include/vki/vki-scnums-shared-linux.h, __NR_userfaultfd is defined for amd64,
arm, arm64, mips32, mips64, nanomips, ppc32, ppc64, riscv64 and x86. And it is
called similarly on each linux arch, so it really should/can be hooked up in
all coregrind/m_syswrap/syswrap-*-linux.c files.
> Is it OK to leave everything to the kernel? Or are there cases where VEX
> needs to write to the fd?
It is ok for this syscall just creating the fd. But when it get configured we
might have to intercept/discard reads from it if they trigger for pages
allocated for Valgrind itself. See
https://www.man7.org/linux/man-pages/man2/ioctl_userfaultfd.2.html but we can
do that when we encounter programs that actually do that.
BTW. I don't think the *flags |= SfMayBlock; in the PRE handler is necessary in
this case. It is if the syscall may block and might depend on another thread
(or some other event) calling back into the kernel. It might in the case of
FUSE file systems for example for file descriptor creation, but I don't think
userfaultfd file description creation is, it should return immediately.
Also you want to use PRE_REG_READ1 not PRE_REG_READ0 (which is for syscalls
without arguments).
The first two arguments of the PRE_REG_READ? macros are the return time and
syscall name, the rest are the argument types and names.
You can check if you got those right using ./vg-in-place --trace-syscalls ...
--
You are receiving this mail because:
You are watching all bug changes.
