summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAdhemerval Zanella <adhemerval.zanella@linaro.org>2017-10-21 11:33:27 -0200
committerAdhemerval Zanella <adhemerval.zanella@linaro.org>2017-10-21 11:33:27 -0200
commitab352f5c5d524106f8afbe764046734d79b832bf (patch)
tree7f599db6bfb1df64f8691affde434d70dea0e7e7
parent797ba44ba27521261f94cc521f1c2ca74f650147 (diff)
downloadglibc-azanella/bz22273.tar.gz
posix: Do not use WNOHANG in waitpid call for Linux posix_spawnazanella/bz22273
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.
-rw-r--r--ChangeLog5
-rw-r--r--sysdeps/unix/sysv/linux/spawni.c10
2 files changed, 10 insertions, 5 deletions
diff --git a/ChangeLog b/ChangeLog
index 7cb7ce5b83..f7688a7ecd 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2017-10-21 Adhemerval Zanella <adhemerval.zanella@linaro.org>
+
+ * sysdeps/unix/sysv/linux/spawni.c (__spawnix): Use 0 instead of
+ WNOHANG in waitpid call.
+
2017-10-20 Joseph Myers <joseph@codesourcery.com>
* bits/floatn-common.h: New file.
diff --git a/sysdeps/unix/sysv/linux/spawni.c b/sysdeps/unix/sysv/linux/spawni.c
index d15fbb1eca..fb83c2ed53 100644
--- a/sysdeps/unix/sysv/linux/spawni.c
+++ b/sysdeps/unix/sysv/linux/spawni.c
@@ -374,12 +374,12 @@ __spawnix (pid_t * pid, const char *file,
ec = args.err;
if (ec > 0)
/* There still an unlikely case where the child is cancelled after
- setting args.err, due to a positive error value. Also due a
+ setting args.err, due to a positive error value. Also there is
possible pid reuse race (where the kernel allocated the same pid
- to unrelated process) we need not to undefinitely hang expecting
- an invalid pid. In both cases an error is returned to the
- caller. */
- __waitpid (new_pid, NULL, WNOHANG);
+ to an unrelated process). Unfortunately due synchronization
+ issues where the kernel might not have the process collected
+ the waitpid below can not use WNOHANG. */
+ __waitpid (new_pid, NULL, 0);
}
else
ec = -new_pid;