This issue does not lead to memory incoherence. musl supports kernels far older than the membarrier syscall, and implements a costly fallback if the syscall fails. However it's perferable to allow the syscall so that the fallback isn't needed.

This issue does not lead to memory incoherence. musl supports kernels far older than the membarrier syscall, and implements a costly fallback if the syscall fails. However it's perferable to allow the syscall so that the fallback isn't needed.

FYI, we ran a lot of tests on AWS codebuild because they fail almost all the time and rarely succeed. But as soon as we add membarrier to seccomp profile json file, we no longer have the issue at all.

What are the tests that fail doing/trying to assert? I think you'll find it's something unrelated to the use of membarrier in dlopen, but I'd be interested in hearing if not. The use in dlopen is really a virtual nop - the ordering properties it's ensuring are automatically satisfied on any architecture with "consume" type semantics, which is pretty much every architecture ever made except DEC Alpha. If something is going wrong related to dlopen, the mechanism of breakage is likely something different - maybe a problem stemming from other syscalls being blocked?

had a quick chat with @justincormack, and he thought the change to the seccomp profile should be ok

Changes look good; could you squash the two commits into one? Let me know if you need help with that

@AkihiroSuda PTAL

That should close this issue, but I believe there may be another problem behind this, in the form of undersized stack that caused the crash when signal-based fallback was used. That should be checked out too, since an undersized stack could come back as crashes elsewhere later.