> > serves for attach/detach. You need somewhere to store the
> > PTRACE_SETOPTIONS state and so forth, sure. But you can probably just
> > handle the attachedness at the utrace level. That's what
> > UTRACE_ATTACH_EXCLUSIVE is for.
>
> Yes. As for ->ptrace, I think it should die. The only problem is
> PT_PTRACED bit. It would be nice to move it into ->utrace_flags, but
> this needs some not-very-nice changes.
What is PT_PTRACED good for? Why do you need it at all? That's what my
quoted paragraph above is saying: you don't. The "is someone already
ptrace'ing it" bit is determined by UTRACE_ATTACH_MATCH_OPS, &ptrace_ops.
Or perhaps race issues will make you want to have it possible an engine is
attached momentarily when ptrace_context is is not set up yet or is being
torn down. In that case, ctx->tracer == NULL or something probably works.
> But there is a problem. Which I didn't expect at all.
>
> Who will kfree() engine->data ?
>
> sys_ptrace(PTRACE_DETACH) can do this. But what if the tracer exits
> and detaches? Or release_task() does untrace.
All of these are some ptrace.c path that has to use UTRACE_DETACH,
or else is where your ptrace_ops.report_reap hook would be called.
Whoever does a successful UTRACE_DETACH should free it. So that can be
after a utrace_control call that returned 0 (or utrace_barrier after),
or in a callback that will return UTRACE_DETACH, or in a report_reap
callback.
> Yes, we can use task_struct->ptrace_ctx which is freed by free_task(),
> in this case engine->data == child->ptrace_ctx. But imho this would
> be very bad.
Agreed, we should get rid of that pointer in task_struct entirely.
> OTOH, perhaps we can't avoid task_struct->ptrace_ctx. Otherwise,
> it is not easy to move task_struct->parent into ptrace_context.
Well, that's a different can of worms. We should look at each case of
anything outside {compat_,}sys_ptrace itself and ptrace's utrace callbacks
that needs to look at that pointer and figure out how to rework things.
Thanks,
Roland
