lkml.org 
[lkml]   [2004]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:00    [W:0.051 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site