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
