Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170611215020.GB1627@brightrain.aerifal.cx>
Date: Sun, 11 Jun 2017 17:50:20 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: more fun with non-Linux Linux ABI

On Sun, Jun 11, 2017 at 08:01:58PM +0200, u-uy74@...ey.se wrote:
> FWIIW: when running under Linux ABI on FreeBSD
> in musl-linked programs the child processes segfault right after a
> vfork(), before doing anything else:

My first guess is that this is a FreeBSD bug...

> -----
> #include <sys/types.h>
> #include <unistd.h>
> #include <stdio.h>
> #include <sys/wait.h>
> 
> int main( int argc, char **argv ) {
>   int s;
>   pid_t pid = vfork();
>   if( !pid ){ _exit(0); }
>   else      { wait(&s); printf("vfork() = %d\n", pid); }
>   fflush(stdout);
>   _exit(0);
> }
> -----
>  50124 ktrace   RET   ktrace 0
>  50124 ktrace   CALL  execve(0x7fffffffee4b,0x7fffffffec38,0x7fffffffec48)
>  50124 ktrace   NAMI  "./v"
>  50124 v        RET   linux_olduname 0
>  50124 v        CALL  linux_set_thread_area(0xffffcc6c)
>  50124 v        RET   linux_set_thread_area 0
>  50124 v        CALL  linux_set_tid_address(0x804d524)
>  50124 v        RET   linux_set_tid_address 50124/0xc3cc
>  50124 v        CALL  linux_vfork
>  50124 v        RET   linux_vfork 50125/0xc3cd
>  50125 v        RET   linux_fork 0
>  50125 v        PSIG  SIGSEGV SIG_DFL code=SEGV_MAPERR
>  50125 v        NAMI  "v.core"
>  50124 v        CALL  linux_wait4(0xffffffff,0xffffcd4c,0,0)
>  50124 v        RET   linux_wait4 50125/0xc3cd
>  50124 v        CALL  linux_ioctl(0x1,0x5413,0xffffcb04)
>  50124 v        RET   linux_ioctl 0
>  50124 v        CALL  linux_writev(0x1,0xffffcad4,0x2)
>  50124 v        GIO   fd 1 wrote 16 bytes
>        "vfork() = 50125
>        "
>  50124 v        RET   linux_writev 16/0x10
>  50124 v        CALL  linux_exit_group(0)
> -----
> 
> Remarkably this apparently does not affect glibc-based builds
> (I have not tested right now but otherwise it would have been known).
> Wonder what makes the difference.

Is it possible that FreeBSD's Linux syscall emulation uses the
userspace stack to store some state during syscalls? For example maybe
they just translate to the FreeBSD stack-based syscall convention by
pushing registers onto the userspace stack then jumping to the normal
FreeBSD syscall entry points. If so, There's no way they can implement
vfork and they ought to just emulate it as fork.

> Otherwise a simple workaround would be an option to make vfork()
> a fork() synonym while building musl. (I do the this at applications
> build time instead, which helps.)
> 
> Such an option would most probably result in a pretty small performance
> impact on modern (native) Linux.

It's actually a pretty large impact; recent (4.x+ IIRC) versions of
GNU makes are considerably slower because they dropped use of vfork
and switched to fork rather than making it use posix_spawn like it
should.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.