Messages in this thread |  | | | From | Roland McGrath <> | | Subject | Re: [PATCH] fix de_thread() vs do_coredump() deadlock | | Date | Tue, 11 Apr 2006 02:10:07 -0700 (PDT) |
| |
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |