aboutsummaryrefslogtreecommitdiffstats
path: root/arch/frv/kernel/gdb-stub.c
diff options
context:
space:
mode:
authorOleg Nesterov <oleg@tv-sign.ru>2006-01-08 01:03:13 -0800
committerLinus Torvalds <torvalds@g5.osdl.org>2006-01-08 20:13:55 -0800
commitbb6f6dbaa48c53525a7a4f9d4df719c3b0b582af (patch)
treed8214a72c61d49e3cb896e0390256f23e9f72eff /arch/frv/kernel/gdb-stub.c
parent0811af28ce49fab963e3e6b8abcf8c460f971cd4 (diff)
downloadkernel_samsung_aries-bb6f6dbaa48c53525a7a4f9d4df719c3b0b582af.zip
kernel_samsung_aries-bb6f6dbaa48c53525a7a4f9d4df719c3b0b582af.tar.gz
kernel_samsung_aries-bb6f6dbaa48c53525a7a4f9d4df719c3b0b582af.tar.bz2
[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>
Diffstat (limited to 'arch/frv/kernel/gdb-stub.c')
0 files changed, 0 insertions, 0 deletions