diff options
author | Eelco Dolstra <eelco.dolstra@logicblox.com> | 2014-08-21T12·08+0200 |
---|---|---|
committer | Eelco Dolstra <eelco.dolstra@logicblox.com> | 2014-08-21T12·08+0200 |
commit | 524f89f1399724e596f61faba2c6861b1bb7b9c5 (patch) | |
tree | e652815f56cf7cf93dec282f1ec319511d5476a0 /scripts/download-from-binary-cache.pl.in | |
parent | fefd3650d4aa0c378da2ae1f1cdda772d5afaf13 (diff) |
Use unshare() instead of clone()
It turns out that using clone() to start a child process is unsafe in a multithreaded program. It can cause the initialisation of a build child process to hang in setgroups(), as seen several times in the build farm: The reason is that Glibc thinks that the other threads of the parent exist in the child, so in setxid_mark_thread() it tries to get a futex that has been acquired by another thread just before the clone(). With fork(), Glibc runs pthread_atfork() handlers that take care of this (in particular, __reclaim_stacks()). But clone() doesn't do that. Fortunately, we can use fork()+unshare() instead of clone() to set up private namespaces. See also https://www.mail-archive.com/lxc-devel@lists.linuxcontainers.org/msg03434.html.
Diffstat (limited to 'scripts/download-from-binary-cache.pl.in')
0 files changed, 0 insertions, 0 deletions