diff options
| author | Adhemerval Zanella <adhemerval.zanella@linaro.org> | 2017-10-21 11:33:27 -0200 |
|---|---|---|
| committer | Adhemerval Zanella <adhemerval.zanella@linaro.org> | 2017-10-23 13:31:26 -0200 |
| commit | aa95a2414e4f664ca740ad5f4a72d9145abbd426 (patch) | |
| tree | bedbb52d8fac4c5e88098bb38047e219d6f82ae2 /nss | |
| parent | a2e0a7f12ba57a49d1380c7ba1ff4b1f51d67347 (diff) | |
| download | glibc-aa95a2414e4f664ca740ad5f4a72d9145abbd426.tar.gz glibc-aa95a2414e4f664ca740ad5f4a72d9145abbd426.tar.xz glibc-aa95a2414e4f664ca740ad5f4a72d9145abbd426.zip | |
posix: Do not use WNOHANG in waitpid call for Linux posix_spawn
As shown in some buildbot issues on aarch64 and powerpc, calling clone (VFORK) and waitpid (WNOHANG) does not guarantee the child is ready to be collected. This patch changes the call back to 0 as before fe05e1cb6d64 fix. This change can lead to the scenario 4.3 described in the commit, where the waitpid call can hang undefinitely on the call. However this is also a very unlikely and also undefinied situation where both the caller is trying to terminate a pid before posix_spawn returns and the race pid reuse is triggered. I don't see how to correct handle this specific situation within posix_spawn. Checked on x86_64-linux-gnu, aarch64-linux-gnu and powerpc64-linux-gnu. * sysdeps/unix/sysv/linux/spawni.c (__spawnix): Use 0 instead of WNOHANG in waitpid call.
Diffstat (limited to 'nss')
0 files changed, 0 insertions, 0 deletions