[RFC, PATCH] teach utrace to destroy engine->data

[Roland McGrath]

> > (or even just report_quiesce
> > when passed UTRACE_EVENT(DEATH)) that always detaches.
> 
> Hmm. Not sure I understand how can we do without hooking death or reap...

UTRACE_EVENT(QUIESCE) constitutes "hooking death".
A report_quiesce (UTRACE_EVENT(DEATH)) call precedes the report_death call.

> > synchronizing with de_thread(), which is the one place that
> > ordinarily preempts the ptrace wait interference.)
> 
> Not only de_thread(). If the tracee is killed, another thread can
> do wait()->release_task(). This means even _reap (instead of _death)
> can't save us.

That really has nothing to do with utrace.  That's another "you" path that
you control and can make do what you need it to.  But, it is immaterial to
the point I made: you can use report_reap as the means to interlock with
that too if you so chose.  It seems like a goofy choice for that, since it
would be your code->release_task()->utrace_release_task()->your report_reap()
and you might as well just do your code->your code.

> > I see two basic models for handling the engine lifetime issues in a utrace
> > engine.
> >
> > One way is where you do not normally hold a utrace_engine reference.
[...]
> I must have missed something.
> 
> Sure, it is more or less trivial to free engine->data safely. I mean,
> it is easy to avoid the double-free/etc problems.
> 
> But I can't understand how the tracer can use ->data safely. Whatever
> the tracer does, the tracee can be killed at any moment. It can
> pass ->report_death/reap events under us.

What you missed is where I said this model is appropriate for situations
where you don't need to do that:

> >							     This model is
> > probably a good fit for "passive" tracing, where the only thing you
> > really come back and do later is disable it (or for something simple
> > enough it doesn't need any cleanup for engine->data).

> > The second model is where you normally hold a utrace_engine reference
[...]
> And this means we need some hairy tricks.

That is an utterly vague blanket statement to make.

> Yes sure. If you don't apply your patch which uses ops->release(), then I
> am going to add engine->data->in_use for reports which return UTRACE_DETACH
> or ->report_death. If the tracer needs engine->data it should use
> ptrace_get_context/ptrace_put_context. I am not sure we can avoid taking
> utrace->lock for that...

I don't really follow this at all.  
Your ptrace code has nothing to do with utrace->lock, and never will.


Thanks,
Roland