Bug 420906

Actually clone is very special and much more complicated than other system calls.

I did look at this because I was expecting somebody to ask for it and it's going to need a bit of work to refactor things to avoid duplicating all the code - the existing helper functions used by clone/clone2 likely need to be reworked to use the new args structure and then have clone/clone pass it a faked up structure or something.

I'll leave it to you, then!

glibc 2.34 will issue clone3 system calls and fall back to clone if clone3 fails.

To reproduce, you can use Fedora rawhide (or 34) and install a glibc build on top of it. https://koji.fedoraproject.org/koji/buildinfo?buildID=1782185 or any build later than glibc-2.33.9000-44.fc35 will do. Building glibc from upstream sources will of course work as well.

It is simple to enough to reproduce using Python:

>>> import threading
>>> threading.Thread(None, lambda: print("Thread is running")).start()
--3019-- WARNING: unhandled amd64-linux syscall: 435
--3019-- You may be able to write your own handler.
--3019-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--3019-- Nevertheless we consider this a bug.  Please report
--3019-- it at http://valgrind.org/support/bug_reports.html.
Thread is running

So things just work (as expected), except for the annoying warning.

If you build glibc from upstream sources, you can get to a Python prompt with the just-built glibc like this (without installing):

git clone --depth 1 https://sourceware.org/git/glibc.git
cd glibc
mkdir build
cd build
../configure --prefix=/usr
make -j`nproc`
bash testrun.sh --tool=valgrind /usr/bin/python3

A valgrind binary needs to be on PATH for this.

(In reply to Florian Weimer from comment #4)
> To reproduce, you can use Fedora rawhide (or 34) and install a glibc build
> on top of it. https://koji.fedoraproject.org/koji/buildinfo?buildID=1782185
> or any build later than glibc-2.33.9000-44.fc35 will do. Building glibc from
> upstream sources will of course work as well.
> 
> It is simple to enough to reproduce using Python:
> 
> >>> import threading
> >>> threading.Thread(None, lambda: print("Thread is running")).start()
> --3019-- WARNING: unhandled amd64-linux syscall: 435
> --3019-- You may be able to write your own handler.
> --3019-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
> --3019-- Nevertheless we consider this a bug.  Please report
> --3019-- it at http://valgrind.org/support/bug_reports.html.
> Thread is running
> 
> So things just work (as expected), except for the annoying warning.

valgrind is loosing control over the cloned thread, so it is not just an annoying warning.

The quickest solution/workaround would be to explicitly ENOSYS clone3 (without warning) so that glibc falls back to clone.

Created attachment 140238 [details]
Make clone3 on linux ENOSYS

It is also breaking a ton of regtest tests. Currently testing a patch that makes clone3 simply produce ENOSYS through sys_ni_syscall.

(In reply to Mark Wielaard from comment #6)
> Created attachment 140238 [details]
> Make clone3 on linux ENOSYS
> 
> It is also breaking a ton of regtest tests. Currently testing a patch that
> makes clone3 simply produce ENOSYS through sys_ni_syscall.

This was pushed as:

commit 52ed51fc35f8a6148c2940eb46932b02dd3b9b23
Author: Mark Wielaard <mark@klomp.org>
Date:   Wed Jul 21 19:53:13 2021 +0200

    Generate a ENOSYS (sys_ni_syscall) for clone3 on all linux arches
    
    glibc 2.34 will try to use clone3 first before falling back to
    the clone syscall. So implement clone3 as sys_ni_syscall which
    simply return ENOSYS without producing a warning.
    
    https://bugs.kde.org/show_bug.cgi?id=439590

And makes at least glibc fall back to clone.

tried this with my application. The previous error is no longer reported, however valgrind still stops with:

vex amd64->IR: unhandled instruction bytes: 0x37 0x48 0x83 0xF8 0x2E 0xF 0x84 0x17 0xFF 0xFF
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==19360== valgrind: Unrecognised instruction at address 0x2bf6ede1.
==19360==    at 0x2BF6EDE1: ??? (in /memfd:sljit (deleted))
==19360==    by 0x3766F437: ???
....
==19360== Either way, Valgrind will now raise a SIGILL signal which will
==19360== probably kill your program.
==19360== 
==19360== Process terminating with default action of signal 4 (SIGILL): dumping core
==19360==  Illegal opcode at address 0x2BF6EDE1
==19360==    at 0x2BF6EDE1: ??? (in /memfd:sljit (deleted))
==19360==    by 0x3766F437: ???