On 08/18, Roland McGrath wrote: > > > > (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".
Ah yes, utrace_report_death() doesn't call ->report_death() directly, it does REPORT_CALLBACKS(). > > I must have missed something. > > > > 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: Yes, I did miss that. > > > 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. Agreed. Let me try again. > This model seems like a better fit for ptrace to me. The anchoring data > structure is the tracer's tracees list, which links together the > ptrace_context structs. A live ptrace_context has an engine pointer and > a ref for it. OK. Not that I really understand this all in details, but OK. But. Do you think we should do this right now? I don't. Imho, we need a lot of changes before this. We need the working code first. I just can't understand how can we do the necessary changes to solve (say) the problems with de_thread() now, when it is not clear (to me) how the basic/core ptrace code will look. And to have the more or less working code, we need engine->data which can be used by tracer. Do you have any suggestion what can we do right now? (assuming you won't apply your ops->release patch). > > 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. Yes, agreed. ptrace should not use utrace->lock. But currently I don't see how to do this without utrace->lock. Or without rcu + refcnt. Oleg.
