On 04/02, Eric W. Biederman wrote: > > In the case of exec and coredump which have many interesting deadlock > opportunities So this patch is very close to my 2/2 one-liner, except - you removed the current->mm == current->parent->mm check I didn't do this on purpose, because even the->core_state is not really needed if we check ->group_exit_task, this need more changes anyway, but I won't argue. - With your patch we send the notification to debugger even if we are not going to stop. This is not wrong, but why? This is pointless, nobody rely on SIGCHLD, if nothing else it doesn't queue. Again, I won't argue, but this complicates both the patch and the code for no reason. Unless I missed something. > Keep sending the signal to the tracer so that this appears like > the worst case where someone else sent the process a SIGKILL before > the tracer could react. So all non-buggy tracers must support > this case. Well, I can't understand the changelog. Sure, debugger must support this case, but obviously this can break things anyway. For example. The coredumping thread must stop in PTRACE_EVENT_EXIT. There is a tool (I don't remember its name) which does ptrace_attach(PTRACE_SEIZE, PTRACE_O_TRACEEXIT) after the coredump was already started, closes the pipe, and reads the registers when this thread actually exits. This patch or my 2/2 should not break it, ->group_exit_task will be cleared after do_coredump(), but unfortunately something else can be broken. So I think the changelog should mention that yes, this is the user visible change which _can_ break something anyway. In short. I will be really happy if this patch comes from you, not me ;) Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
