Fix potential deadlock with libc setgid/setuid #34
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I noticed that unit tests based on unshare deadlock from time to time. Apparently libc uses an internal mutex to synchronize
setuid
andsetgid
calls, which interferes with our forking. If we replace these calls with a raw syscall, we never take this lock. Given that we call eitherexec
orexit
shortly afterwards, the additional synchronization from libc shouldn't be necessary at all.I could reproduce this bug in a small local project by running the 12 unit tests in a loop, each test spawns one child. Maybe 1 out of 50 attempts deadlocked. With the patch I no longer saw deadlocks.
For the reference: if the bug appeared, lldb reported the following backtrace for the blocking process (either with
setgid
orsetuid
):Availability: If anyone wants to use this and other features before it's merged, check out my temporary fork. It includes #23 #27 #29 #33 #34 #35 and #36 with all conflicts resolved.
Add to your
Cargo.toml
:unshare = { git = "https://github.com/MarkusBauer/unshare.git" }