about summary refs log tree commit diff
path: root/scripts/download-from-binary-cache.pl.in
diff options
context:
space:
mode:
authorEelco Dolstra <eelco.dolstra@logicblox.com>2014-08-21T12·08+0200
committerEelco Dolstra <eelco.dolstra@logicblox.com>2014-08-21T12·08+0200
commit524f89f1399724e596f61faba2c6861b1bb7b9c5 (patch)
treee652815f56cf7cf93dec282f1ec319511d5476a0 /scripts/download-from-binary-cache.pl.in
parentfefd3650d4aa0c378da2ae1f1cdda772d5afaf13 (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