]> www.pilppa.org Git - linux-2.6-omap-h63xx.git/commit
[PATCH] do_coredump() should reset group_stop_count earlier
authorOleg Nesterov <oleg@tv-sign.ru>
Sun, 8 Jan 2006 09:03:13 +0000 (01:03 -0800)
committerLinus Torvalds <torvalds@g5.osdl.org>
Mon, 9 Jan 2006 04:13:55 +0000 (20:13 -0800)
commitbb6f6dbaa48c53525a7a4f9d4df719c3b0b582af
treed8214a72c61d49e3cb896e0390256f23e9f72eff
parent0811af28ce49fab963e3e6b8abcf8c460f971cd4
[PATCH] do_coredump() should reset group_stop_count earlier

__group_complete_signal() sets ->group_stop_count in sig_kernel_coredump()
path and marks the target thread as ->group_exit_task.  So any thread
except group_exit_task will go to handle_group_stop()->finish_stop().

However, when group_exit_task actually starts do_coredump(), it sets
SIGNAL_GROUP_EXIT, but does not reset ->group_stop_count while killing
other threads.  If we have not yet stopped threads in the same thread
group, they all will spin in kernel mode until group_exit_task sends them
SIGKILL, because ->group_stop_count > 0 means:

recalc_sigpending_tsk() never clears TIF_SIGPENDING

get_signal_to_deliver() goes to handle_group_stop()

handle_group_stop() returns when SIGNAL_GROUP_EXIT set

syscall_exit/resume_userspace notice TIF_SIGPENDING,
call get_signal_to_deliver() again.

So we are wasting cpu cycles, and if one of these threads is rt_task() this
may be a serious problem.

NOTE: do_coredump() holds ->mmap_sem, so not stopped threads can't escape
coredumping after clearing ->group_stop_count.

See also this thread: http://marc.theaimsgroup.com/?t=112739139900002

Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
fs/exec.c