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.