Re: [PATCH] fix de_thread() vs do_coredump() deadlock

[Roland McGrath <roland@redhat.com>]

> Once again. Process starts exec, it has no pending signals. Execer thread sets
> SIGNAL_GROUP_EXEC, sends SIGKILL to other threads, and waits them to die.
> The first thread which dequeues SIGKILL will change SIGNAL_GROUP_EXEC to
> SIGNAL_GROUP_EXIT, thus aborting exec.

You are very right.  Sorry I did not manage to understand your objection
the first time around.  Sigh, trying to think on too little sleep again, I guess.

> Sorry for persistance if I really misunderstand this patch.

Thanks for the persistence.


What I'd really like to do here is get rid of these fake SIGKILLs.  We're
already waking the threads up directly in zap_other_threads.  We don't
really need to set SIGKILL pending.  By setting group_stop_count we can
make sure recalc_sigpending_tsk keeps signal_pending set, and every thread will
get into handle_group_stop.  The (SIGNAL_GROUP_EXIT | SIGNAL_GROUP_EXEC)
check there can just do_exit directly, instead of using the fatal signal path.
I'm inclined to get rid of zap_other_threads, since the part of it common
to both callers (de_thread and do_group_exit) will be just:

	for (t = next_thread(p); t != p; t = next_thread(t))
		if (!unlikely(t->exit_state))
			signal_wake_up(t, 1);

(The exit_signal business in the zap_other_threads loop is already dead
cruft, because ->exit_signal is always -1 in non-leader threads nowadays.)

If this makes sense to you, I'll rework my patch along these lines.  
But it seems like it will be easiest to do it after your other coredump and
de_thread changes are all resolved.

Also, I've realized that the same lost signal issue can occur for stop
signals.  There it's real hard to see what can be done other than trying to
stuff the signal back on the queue, which I've said is problematical.
I need to think about this more.


Thanks again,
Roland