If using the suid sandbox, but not using the seccomp sandbox, there is a

good chance that we will produce a zombie process inside of the new
pid namespace. This happens, because we create a short-lived helper
process when setting up the pid namespace, but the new "init" process
never gets around to reaping this process.

It would have reaped it, if it had received a SIGCHLD signal from any
other process that died. But without the seccomp sandbox, that doesn't
happen very frequently.

This changelist reorders instructions so that we always look for dead
children at least once, when starting the mainloop of the new "init"
process. In doing so, we will always find and reap our dead helper
process.

BUG=109944
TEST=Run Chrome with the suid but without the seccomp sandbox, grep for "defunct" processes in the output of "ps auxw". There shouldn't be any.
Review URL: https://chromiumcodereview.appspot.com/9661001

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@126188 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 4 insertions, 4 deletions

diff --git a/sandbox/linux/suid/init_process.c b/sandbox/linux/suid/init_process.c
index 527a42d..e854202 100644
--- a/sandbox/linux/suid/init_process.c
+++ b/sandbox/linux/suid/init_process.c
@@ -140,10 +140,6 @@ void SystemInitProcess(int init_fd, int child_pid, int proc_fd, int null_fd) {
 
   // Handle dying processes that have been re-parented to the "init" process
   for (;;) {
-    // Wait until we receive a SIGCHLD signal. Our signal handler doesn't
-    // actually need to do anything, though
-    sigwaitinfo(&mask, NULL);
-
     bool retry = false;
     do {
       for (;;) {
@@ -197,5 +193,9 @@ void SystemInitProcess(int init_fd, int child_pid, int proc_fd, int null_fd) {
         }
       }
     } while (retry);
+
+    // Wait until we receive a SIGCHLD signal. Our signal handler doesn't
+    // actually need to do anything, though
+    sigwaitinfo(&mask, NULL);
   }
 }