[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