diff options
author | Rich Felker <dalias@aerifal.cx> | 2019-04-09 17:51:54 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2019-04-09 17:51:54 -0400 |
commit | a01ff71f7c43693ad4954d4ae7863df159cf4073 (patch) | |
tree | 08677f7822b7de58016b1c2b5dade67a8e5b7270 /crt | |
parent | 77846800722914eeba170505c2e7f89e12a6beff (diff) | |
download | musl-a01ff71f7c43693ad4954d4ae7863df159cf4073.tar.gz musl-a01ff71f7c43693ad4954d4ae7863df159cf4073.tar.bz2 musl-a01ff71f7c43693ad4954d4ae7863df159cf4073.tar.xz musl-a01ff71f7c43693ad4954d4ae7863df159cf4073.zip |
in membarrier fallback, allow for possibility that sigaction fails
this is a workaround to avoid a crashing regression on qemu-user when
dynamic TLS is installed at dlopen time. the sigaction syscall should
not be able to fail, but it does fail for implementation-internal
signals under qemu user-level emulation if the host libc qemu is
running under reserves the same signals for implementation-internal
use, since qemu makes no provision to redirect/emulate them. after
sigaction fails, the subsequent tkill would terminate the process
abnormally as the default action.
no provision to account for membarrier failing is made in the dynamic
linker code that installs new TLS. at the formal level, the missing
barrier in this case is incorrect, and perhaps we should fail the
dlopen operation, but in practice all the archs we support (and
probably all real-world archs except alpha, which isn't yet supported)
should give the right behavior with no barrier at all as a consequence
of consume-order properties.
in the long term, this workaround should be supplemented or replaced
by something better -- a different fallback approach to ensuring
memory consistency, or dynamic allocation of implementation-internal
signals. the latter is appealing in that it would allow cancellation
to work under qemu-user too, and would even allow many levels of
nested emulation.
Diffstat (limited to 'crt')
0 files changed, 0 insertions, 0 deletions