The previous patch fixed the deadlock when mt-exec waits for debugger which should reap a zombie thread, but we can hit the same problem if the killed sub-thread stops in ptrace_event(PTRACE_EVENT_EXIT). Change ptrace_stop() to check signal->group_exit_task.
This is a user-visible change. But hopefully it can't break anything. Note that the semantics of PTRACE_EVENT_EXIT was never really defined, it depends on /dev/random. Just for example, currently a sub-thread killed by exec will stop, but if it exits on its own and races with exec it will not stop, so nobody can rely on PTRACE_EVENT_EXIT anyway.
We really need to finally define what PTRACE_EVENT_EXIT should actually do, but this needs other changes.
Signed-off-by: Oleg Nesterov oleg@redhat.com --- kernel/signal.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/kernel/signal.c b/kernel/signal.c index 334212044940..59f61e07905b 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -2376,6 +2376,10 @@ static int ptrace_stop(int exit_code, int why, unsigned long message, if (!current->ptrace || __fatal_signal_pending(current)) return exit_code;
+ /* de_thread() -> wait_for_notify_count() waits for us */ + if (current->signal->group_exec_task) + return exit_code; + set_special_state(TASK_TRACED); current->jobctl |= JOBCTL_TRACED;