Messages in this thread | | | Date | Sun, 1 Feb 2004 14:25:14 -0800 | From | Roland McGrath <> | Subject | Re: More waitpid issues with CLONE_DETACHED/CLONE_THREAD |
| |
> and the thing is, it looks like the signal handling changes have totally > made the child ignore the "exit_code" thing, unless I'm seriously > misreading something.
The only time that exit_code has ever been consulted is in get_signal_to_deliver after the thread has stopped to notify its ptracer and then been resumed. That is still the case. So it's only being ignored if the child is stopped in some other place and not there. I don't see the scenario where that could be happening without the explicit involvement of user-level stop signals (i.e. not the implicit stops done by ptrace).
Your changes would be equivalent to an atomic combination of "kill(child_pid, SIGKILL); PTRACE_DETACH(pid);". That is different from what PTRACE_KILL normally does, which leaves the dying child attached so that it reports its death to the ptracer before the original parent.
I haven't really looked into the problem with Dan's test case yet (didn't seem to reproduce, but I haven't tried a current and cruft-free kernel yet). But I don't see any problem with the implementation of PTRACE_KILL.
Thanks, 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/
| |