wait() on a PID that is not your child

Posted Oct 9, 2011 3:10 UTC (Sun) by neilbrown (subscriber, #359)
In reply to: wait() on a PID that is not your child by HelloWorld
Parent article: A Plumber's Wish List for Linux

You are correct, it doesn't. But it could.

I was thinking that /proc/$PID was some how linked to the actual process so that when the process died, that directory would become empty and would stay empty. However it isn't.
/proc/$PID is linked to $PID so if a new process appeared with the same pid, its details would appear in the same directory.
i.e. if you "cd /proc/$PID". then "kill -9 $PID", the directory will appear empty (or give an error on readdir) but if another process gets called $PID, "ls ." will start showing things again.

However this could easily be "fixed" for example by using a generation number similar to that used by NFS. Each new process gets a random generation number assigned to it and when you open /proc/$PID that number gets copied into the inode that is created. Then accesses to a process through that inode always check that the generation number is correct as well as the pid. About a dozen lines of code.

With that in place, your race would be trivial to avoid. Just "chdir" to the /proc/$PID directory, check again that this is the process that you are interested in, then open "status" and 'poll' for POL_ERR.

to post comments

wait() on a PID that is not your child

Posted Oct 9, 2011 7:25 UTC (Sun) by ebiederm (subscriber, #35028) [Link] (1 responses)

/proc/$PID/ is linked to the process and it very much becomes empty when a process dies.

If a new process gets the same pid a different directory is created.

The tricky bit is actually is the way process death updates are implemented internally. The data structures are backwards and need to be turnedd around so poll on the file descriptor could be implemented.

There is still the race of changing into the directory at the top of this thread but pid reuse is typically slow enough that race should be hard to hit.

wait() on a PID that is not your child

Posted Oct 9, 2011 10:54 UTC (Sun) by neilbrown (subscriber, #359) [Link]

hmm... I must have missed an important piece in the code. I just tested and the old empty directory definitely stays empty as you said. Thanks for the correction.

I don't think the race at the top is real. Whatever mechanism was used to determine which pid to wait for can be repeated after the "cd /proc/$pid" to see if it is still the same. If it is the same, then it is perfectly safe to wait for files to disappear (if/when there is a mechanism to do that).