[PATCH 08] change ptrace_traceme() to use the new helpers, kill prepare/finish attach
Oleg Nesterov
oleg at redhat.com
Tue Aug 18 15:17:24 UTC 2009
On 08/17, Roland McGrath wrote:
>
> > In that case it can share the code with ptrace_traceme().
>
> I'm not sure I quite follow that. Both PTRACE_TRACEME and PTRACE_ATTACH
> paths have to interlock with each other. Auto-tracing in report_clone
> doesn't have to worry about that at all, because of the special priority
> report_clone gets for UTRACE_ATTACH_CREATE. It's more like PTRACE_ATTACH
> in that it runs in the parent context (inside clone/fork),
Yes. But we attach to parent->parent, not to parent == current.
It runs in context of ptraced task, and the ptracer/context is not
"stable". The tracer can exit and detach. We should be careful, like
in PTRACE_TRACEME case.
In short: ptrace_report_clone() should "copy" the tracing state from
current to child when needed. And it should never attach if current
is not traced.
In particular, this means that
if (event || (clone_flags & CLONE_PTRACE)) {
child_engine = utrace_attach_task(child, UTRACE_ATTACH_CREATE ...
is not right. CLONE_PTRACE should be ignored unless task_ptrace(current).
> whereas
> PTRACE_TRACEME may have fewer issues to worry about because it runs in
> the tracee context.
Yes, but otoh, the freshly forked task can't run at all, we didn't call
wake_up_new_task() yet. This means, we have fewer issues to worry, like
if it was current.
I think we will see what makes more sense.
Oleg.
More information about the utrace-devel
mailing list