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 /arch | |
parent | 77846800722914eeba170505c2e7f89e12a6beff (diff) | |
download | musl-a01ff71f7c43693ad4954d4ae7863df159cf4073.tar.gz 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 'arch')
0 files changed, 0 insertions, 0 deletions