fluencelabs/musl
1
0
Fork 0
mirror of https://github.com/fluencelabs/musl synced 2025-06-07 03:51:36 +00:00
Code Issues Projects Releases Wiki Activity
musl/src/process/fork.c

36 lines
646 B
C
Raw Normal View History

initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
#include <unistd.h>
clean up sloppy nested inclusion from pthread_impl.h this mirrors the stdio_impl.h cleanup. one header which is not strictly needed, errno.h, is left in pthread_impl.h, because since pthread functions return their error codes rather than using errno, nearly every single pthread function needs the errno constants. in a few places, rather than bringing in string.h to use memset, the memset was replaced by direct assignment. this seems to generate much better code anyway, and makes many functions which were previously non-leaf functions into leaf functions (possibly eliminating a great deal of bloat on some platforms where non-leaf functions require ugly prologue and/or epilogue).
2012-11-08 17:04:20 -05:00
#include <string.h>
support linux kernel apis (new archs) with old syscalls removed such archs are expected to omit definitions of the SYS_* macros for syscalls their kernels lack from arch/$ARCH/bits/syscall.h. the preprocessor is then able to select the an appropriate implementation for affected functions. two basic strategies are used on a case-by-case basis: where the old syscalls correspond to deprecated library-level functions, the deprecated functions have been converted to wrappers for the modern function, and the modern function has fallback code (omitted at the preprocessor level on new archs) to make use of the old syscalls if the new syscall fails with ENOSYS. this also improves functionality on older kernels and eliminates the incentive to program with deprecated library-level functions for the sake of compatibility with older kernels. in other situations where the old syscalls correspond to library-level functions which are not deprecated but merely lack some new features, such as the *at functions, the old syscalls are still used on archs which support them. this may change at some point in the future if or when fallback code is added to the new functions to make them usable (possibly with reduced functionality) on old kernels.
2014-05-29 21:01:32 -04:00
#include <signal.h>
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
#include "syscall.h"
add pthread_atfork interface note that this presently does not handle consistency of the libc's own global state during forking. as per POSIX 2008, if the parent process was threaded, the child process may only call async-signal-safe functions until one of the exec-family functions is called, so the current behavior is believed to be conformant even if non-ideal. it may be improved at some later time.
2011-02-18 19:52:42 -05:00
#include "libc.h"
make fork properly initialize the main thread in the child process
2011-03-09 20:23:44 -05:00
#include "pthread_impl.h"
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
use weak aliases rather than function pointers to simplify some code
2011-08-06 20:09:51 -04:00
static void dummy(int x)
{
}
weak_alias(dummy, __fork_handler);
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
pid_t fork(void)
{
add pthread_atfork interface note that this presently does not handle consistency of the libc's own global state during forking. as per POSIX 2008, if the parent process was threaded, the child process may only call async-signal-safe functions until one of the exec-family functions is called, so the current behavior is believed to be conformant even if non-ideal. it may be improved at some later time.
2011-02-18 19:52:42 -05:00
pid_t ret;
block signals during fork there are several reasons for this. some of them are related to race conditions that arise since fork is required to be async-signal-safe: if fork or pthread_create is called from a signal handler after the fork syscall has returned but before the subsequent userspace code has finished, inconsistent state could result. also, there seem to be kernel and/or strace bugs related to arrival of signals during fork, at least on some versions, and simply blocking signals eliminates the possibility of such bugs.
2013-08-08 23:17:05 -04:00
sigset_t set;
use weak aliases rather than function pointers to simplify some code
2011-08-06 20:09:51 -04:00
__fork_handler(-1);
block signals during fork there are several reasons for this. some of them are related to race conditions that arise since fork is required to be async-signal-safe: if fork or pthread_create is called from a signal handler after the fork syscall has returned but before the subsequent userspace code has finished, inconsistent state could result. also, there seem to be kernel and/or strace bugs related to arrival of signals during fork, at least on some versions, and simply blocking signals eliminates the possibility of such bugs.
2013-08-08 23:17:05 -04:00
__block_all_sigs(&set);
support linux kernel apis (new archs) with old syscalls removed such archs are expected to omit definitions of the SYS_* macros for syscalls their kernels lack from arch/$ARCH/bits/syscall.h. the preprocessor is then able to select the an appropriate implementation for affected functions. two basic strategies are used on a case-by-case basis: where the old syscalls correspond to deprecated library-level functions, the deprecated functions have been converted to wrappers for the modern function, and the modern function has fallback code (omitted at the preprocessor level on new archs) to make use of the old syscalls if the new syscall fails with ENOSYS. this also improves functionality on older kernels and eliminates the incentive to program with deprecated library-level functions for the sake of compatibility with older kernels. in other situations where the old syscalls correspond to library-level functions which are not deprecated but merely lack some new features, such as the *at functions, the old syscalls are still used on archs which support them. this may change at some point in the future if or when fallback code is added to the new functions to make them usable (possibly with reduced functionality) on old kernels.
2014-05-29 21:01:32 -04:00
#ifdef SYS_fork
global cleanup to use the new syscall interface
2011-03-20 00:16:43 -04:00
ret = syscall(SYS_fork);
support linux kernel apis (new archs) with old syscalls removed such archs are expected to omit definitions of the SYS_* macros for syscalls their kernels lack from arch/$ARCH/bits/syscall.h. the preprocessor is then able to select the an appropriate implementation for affected functions. two basic strategies are used on a case-by-case basis: where the old syscalls correspond to deprecated library-level functions, the deprecated functions have been converted to wrappers for the modern function, and the modern function has fallback code (omitted at the preprocessor level on new archs) to make use of the old syscalls if the new syscall fails with ENOSYS. this also improves functionality on older kernels and eliminates the incentive to program with deprecated library-level functions for the sake of compatibility with older kernels. in other situations where the old syscalls correspond to library-level functions which are not deprecated but merely lack some new features, such as the *at functions, the old syscalls are still used on archs which support them. this may change at some point in the future if or when fallback code is added to the new functions to make them usable (possibly with reduced functionality) on old kernels.
2014-05-29 21:01:32 -04:00
#else
ret = syscall(SYS_clone, SIGCHLD, 0);
#endif
always initialize thread pointer at program start this is the first step in an overhaul aimed at greatly simplifying and optimizing everything dealing with thread-local state. previously, the thread pointer was initialized lazily on first access, or at program startup if stack protector was in use, or at certain random places where inconsistent state could be reached if it were not initialized early. while believed to be fully correct, the logic was fragile and non-obvious. in the first phase of the thread pointer overhaul, support is retained (and in some cases improved) for systems/situation where loading the thread pointer fails, e.g. old kernels. some notes on specific changes: - the confusing use of libc.main_thread as an indicator that the thread pointer is initialized is eliminated in favor of an explicit has_thread_pointer predicate. - sigaction no longer needs to ensure that the thread pointer is initialized before installing a signal handler (this was needed to prevent a situation where the signal handler caused the thread pointer to be initialized and the subsequent sigreturn cleared it again) but it still needs to ensure that implementation-internal thread-related signals are not blocked. - pthread tsd initialization for the main thread is deferred in a new manner to minimize bloat in the static-linked __init_tp code. - pthread_setcancelstate no longer needs special handling for the situation before the thread pointer is initialized. it simply fails on systems that cannot support a thread pointer, which are non-conforming anyway. - pthread_cleanup_push/pop now check for missing thread pointer and nop themselves out in this case, so stdio no longer needs to avoid the cancellable path when the thread pointer is not available. a number of cases remain where certain interfaces may crash if the system does not support a thread pointer. at this point, these should be limited to pthread interfaces, and the number of such cases should be fewer than before.
2014-03-24 16:57:11 -04:00
if (libc.has_thread_pointer && !ret) {
make fork properly initialize the main thread in the child process
2011-03-09 20:23:44 -05:00
pthread_t self = __pthread_self();
eliminate use of cached pid from thread structure the main motivation for this change is to remove the assumption that the tid of the main thread is also the pid of the process. (the value returned by the set_tid_address syscall was used to fill both fields despite it semantically being the tid.) this is historically and presently true on linux and unlikely to change, but it conceivably could be false on other systems that otherwise reproduce the linux syscall api/abi. only a few parts of the code were actually still using the cached pid. in a couple places (aio and synccall) it was a minor optimization to avoid a syscall. caching could be reintroduced, but lazily as part of the public getpid function rather than at program startup, if it's deemed important for performance later. in other places (cancellation and pthread_kill) the pid was completely unnecessary; the tkill syscall can be used instead of tgkill. this is actually a rather subtle issue, since tgkill is supposedly a solution to race conditions that can affect use of tkill. however, as documented in the commit message for commit 7779dbd2663269b465951189b4f43e70839bc073, tgkill does not actually solve this race; it just limits it to happening within one process rather than between processes. we use a lock that avoids the race in pthread_kill, and the use in the cancellation signal handler is self-targeted and thus not subject to tid reuse races, so both are safe regardless of which syscall (tgkill or tkill) is used.
2014-07-05 23:29:55 -04:00
self->tid = __syscall(SYS_gettid);
optimize out setting up robust list with kernel when not needed as a result of commit 12e1e324683a1d381b7f15dd36c99b37dd44d940, kernel processing of the robust list is only needed for process-shared mutexes. previously the first attempt to lock any owner-tracked mutex resulted in robust list initialization and a set_robust_list syscall. this is no longer necessary, and since the kernel's record of the robust list must now be cleared at thread exit time for detached threads, optimizing it out is more worthwhile than before too.
2015-04-10 00:54:48 -04:00
self->robust_list.off = 0;
self->robust_list.pending = 0;
make fork properly initialize the main thread in the child process
2011-03-09 20:23:44 -05:00
libc.threads_minus_1 = 0;
}
block signals during fork there are several reasons for this. some of them are related to race conditions that arise since fork is required to be async-signal-safe: if fork or pthread_create is called from a signal handler after the fork syscall has returned but before the subsequent userspace code has finished, inconsistent state could result. also, there seem to be kernel and/or strace bugs related to arrival of signals during fork, at least on some versions, and simply blocking signals eliminates the possibility of such bugs.
2013-08-08 23:17:05 -04:00
__restore_sigs(&set);
use weak aliases rather than function pointers to simplify some code
2011-08-06 20:09:51 -04:00
__fork_handler(!ret);
add pthread_atfork interface note that this presently does not handle consistency of the libc's own global state during forking. as per POSIX 2008, if the parent process was threaded, the child process may only call async-signal-safe functions until one of the exec-family functions is called, so the current behavior is believed to be conformant even if non-ideal. it may be improved at some later time.
2011-02-18 19:52:42 -05:00
return ret;
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
}
Reference in New Issue Copy Permalink