I can't seem to send out a correct patch out today with outsending it twice. I accidently grabbed my old versionthat sent to many arguments to detach_pid and so would notcompile. Oops.

---Oleg Nesterov spotted two interesting bugs with the current de_threadcode. The simplest is a long standing double decrement of__get_cpu_var(process_counts) in __unhash_process. Caused bytwo processes exiting when only one was created.

The other is that since we no longer detach from the thread_group listit is possible for do_each_thread when run under the tasklist_lock tosee the same task_struct twice. Once on the task list as athread_group_leader, and once on the thread list of anotherthread.

The double appearance in do_each_thread can cause a double incrementof mm_core_waiters in zap_threads resulting in problems later on incoredump_wait.

To remedy those two problems this patch takes the simple approachof changing the old thread group leader into a child thread.The only routine in release_task that cares is __unhash_process,and it can be trivially seen that we handle cleaning up athread group leader properly.

Since de_thread doesn't change the pid of the exiting leader processand instead shares it with the new leader process. I changethread_group_leader to recognize group leadership based on thegroup_leader field and not based on pids. This should also beslightly cheaper then the existing thread_group_leader macro.

I performed a quick audit and I couldn't see any user ofthread_group_leader that cared how cared about the difference.

I believe this is 2.6.17 material as the bug is present in2.6.17-rc1 and the fix is simple.