aboutsummaryrefslogtreecommitdiffstats
path: root/fs/proc/array.c
diff options
context:
space:
mode:
authorOleg Nesterov <[email protected]>2010-05-26 21:43:10 +0000
committerLinus Torvalds <[email protected]>2010-05-27 16:12:45 +0000
commit9c3391684415c9dca239130d9e433a60a4edf04b (patch)
treea8019b964c625cfeeda0e9d85bafa48991546212 /fs/proc/array.c
parentcoredump: shift down_write(mmap_sem) into coredump_wait() (diff)
downloadkernel-9c3391684415c9dca239130d9e433a60a4edf04b.tar.gz
kernel-9c3391684415c9dca239130d9e433a60a4edf04b.zip
exit: exit_notify() can trust signal->notify_count < 0
signal_struct->count in its current form must die. - it has no reasons to be atomic_t - it looks like a reference counter, but it is not - otoh, we really need to make task->signal refcountable, just look at the extremely ugly task_rq_unlock_wait() called from __exit_signals(). - we should change the lifetime rules for task->signal, it should be pinned to task_struct. We have a lot of code which can be simplified after that. - it is not needed! while the code is correct, any usage of this counter is artificial, except fs/proc uses it correctly to show the number of threads. This series removes the usage of sig->count from exit pathes. This patch: Now that Veaceslav changed copy_signal() to use zalloc(), exit_notify() can just check notify_count < 0 to ensure the execing sub-threads needs the notification from us. No need to do other checks, notify_count != 0 must always mean ->group_exit_task != NULL is waiting for us. Signed-off-by: Oleg Nesterov <[email protected]> Acked-by: Roland McGrath <[email protected]> Cc: Veaceslav Falico <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'fs/proc/array.c')
0 files changed, 0 insertions, 0 deletions