[PATCH] do_coredump() should reset group_stop_count earlier

From: Oleg Nesterov
Date: Wed Nov 23 2005 - 08:10:06 EST

__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

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@xxxxxxxxxx>

--- 2.6.15-rc2/fs/exec.c~ 2005-11-23 19:23:15.000000000 +0300
+++ 2.6.15-rc2/fs/exec.c 2005-11-23 19:56:07.000000000 +0300
@@ -1472,6 +1472,7 @@ int do_coredump(long signr, int exit_cod
if (!(current->signal->flags & SIGNAL_GROUP_EXIT)) {
current->signal->flags = SIGNAL_GROUP_EXIT;
current->signal->group_exit_code = exit_code;
+ current->signal->group_stop_count = 0;
retval = 0;
@@ -1487,7 +1488,6 @@ int do_coredump(long signr, int exit_cod
* Clear any false indication of pending signals that might
* be seen by the filesystem code called to write the core file.
- current->signal->group_stop_count = 0;

if (current->signal->rlim[RLIMIT_CORE].rlim_cur < binfmt->min_coredump)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/