Re: More waitpid issues with CLONE_DETACHED/CLONE_THREAD

[Roland McGrath <roland _at_ xxxxxxxxxx>]

> 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 _at_ vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/