Re: possible regression of ptrace on 2.6.26-rc1

[Roland McGrath]

The test is racy.  I don't think the behavior that affects this has really
changed between kernel versions, you're just seeing timing effects.

When you finish the loop, you've just done a PTRACE_SYSCALL to resume
the child, but have not done a wait for it.  You then do PTRACE_CONT on
it.  If the child has stopped at its next syscall report by the time
that ptrace call checks the child, it works.  If not, it sees the child
is not yet stopped and ptrace fails with ESRCH.  

Due to hysterical raisins, PTRACE_KILL skips the "child is stopped"
check, so it will never return that error.  However, a PTRACE_KILL
request made before the child has actually stopped will not reliably do
anything (it will set child->exit_code = SIGKILL in a race with the
child itself setting current->exit_code before it stops).


Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/