Re: [PATCH v2] exit: perform randomness and pid work without tasklist_lock

["Eric W. Biederman" <ebiederm@xmission.com>]

Oleg asked that I take a look, and I took one.

I very much agree with Oleg that this should be one patch per thing
you want to effect as the issues can be intricate in this part of
the code.

Moving proc_flush_pid inside of tasklist_lock is a bad idea.  The code
has previously been several kinds of a sore spot.  If you look at
proc_invalidate_siblings_dcache you can see calls to d_invalidate,
deactivate_super, and a few other vfs calls that could potentially do
quite a lot of work and potentially take a number of locks.  It has been
a long time but I remember when we used to flush the proc entries under
the tasklist_lock that there were actual deadlocks caused by some rare
code paths that were trying to free memory to allocate memory to make
progress.

It is wrong that attach_pid/detach_pid can be performed without the
tasklist_lock.  There are reasonable guarantees provided by the posix
standard that the set of processes sent a signal is the set of
processes at a point in time.  The tasklist_lock is how we provide
those guarantees currently.

There are two more layers to pids.  The pid number allocation of
alloc_pid/free_pid, and the struct pid layer maintained by get_pid,
put_pid.  Those two layers don't need the tasklist_lock.


It is safe to move free_pid out of tasklist_lock.  I am not certain
how sane it is.

Eric