On 07/22, Roland McGrath wrote:
>
> > > 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?
For example, wait_consider_task(). Even some tracehooks, say,
tracehook_notify_death() need task_is_ptraced().
If we kill (we should) ->ptrace, how can we check whether the task
is ptraced?
We can't check utrace_attach_task(p, MATCH_OPS, ptrace_ops) != NULL,
this needs utrace->lock. I think we need a flag in ->utrace_flags,
or just ptrace_attached:1 in struct utrace.
> > 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.
Hmm. Yes, looks like you are right... Not sure what I was worried
about. I did have some concerns, but I guess I was wrong. Good!
> > 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.
Yes.
Oleg.
