On 11/04, Eric W. Biederman wrote: > > The following mostly correct patch modifies zap_other_threads in > the case of a de_thread to not wait for zombies to be reaped. The only > case that cares is ptrace (as threads are self reaping). So I don't > think this will cause any problems except removing the strace -f race. >From my previous email: So the only plan I currently have is change de_thread() to wait until other threads pass exit_notify() or even exit_signals(), but I don't like this. And yes, I don't like this, but perhaps this is what we should do. The patch is incomplete and racy (afaics), and the SIGNAL_GROUP_EXIT checks doesn't look right, but off course technically this change should be simple enough. But not that simple. Just for example, the exiting sub-threads should not run with ->group_leader pointing to nowhere, in case it was reaped by de_thread. And we have another problem with PTRACE_EVENT_EXIT which can lead to the same deadlock. Unfortunately, the semantics of PTRACE_EVENT_EXIT was never defined. But this change will add the user-visible change. And if we add the user-visible changes, then perhaps we could simply untrace the traced sub-threads on exec. This change is simple, we do not even need to touch exec/de_thread, we could just change exit_notify() to ignore ->ptrace if exec is in progress. But I'm afraid we can't do this. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
