On 09/04, Ananth N Mavinakayanahalli wrote:
>
> I prefer Roland's ops->release approach.
Yes! me too.
> However, is there any chance
> that ->ops is no longer valid
Sure, ->ops can be changed at "any time". For example, just because of
UTRACE_DETACH.
That is why utrace_attach_task() saves ->rel
On Fri, Sep 04, 2009 at 02:55:29AM -0700, Roland McGrath wrote:
> > Simple answer. Because I do not know how to implement this. At least now.
> > I tried to think of this more, but I don't see how to make the first steps.
> >
> > (Yes, to be honest, this looks like "unnecessary complication" to me
> Simple answer. Because I do not know how to implement this. At least now.
> I tried to think of this more, but I don't see how to make the first steps.
>
> (Yes, to be honest, this looks like "unnecessary complication" to me, I have
> to admit. But this is not the reason.)
Well, I am befuddled
On 08/23, Roland McGrath wrote:
>
> > > 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
> > 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,
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() d
> > (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.
On 08/17, Roland McGrath wrote:
>
> > Now. we should make sure that every user of UTRACE_DETACH frees
> > engine->data. And, we have to introduce ptrace_report_reap() which
> > should free it too.
>
> Right, or you can have a report_death callback
Ah sorry, I meant ->report_death, not _reap.
> (o
On 08/17, Roland McGrath wrote:
>
> If we do add the destructor hook, I think it looks like this.
> ...
> @@ -271,6 +273,7 @@ struct utrace_engine *utrace_attach_task(
> engine->flags = 0;
> engine->ops = ops;
> engine->data = data;
> + engine->release = ops->release;
Agreed!
If we do add the destructor hook, I think it looks like this.
It would merit some write-up in utrace.tmpl text too.
I'm not especially convinced it's a very good idea.
But I won't object if people serious about using the API think it helps.
Thanks,
Roland
---
include/linux/utrace.h |8 +++
> Now. we should make sure that every user of UTRACE_DETACH frees
> engine->data. And, we have to introduce ptrace_report_reap() which
> should free it too.
Right, or you can have a report_death callback (or even just report_quiesce
when passed UTRACE_EVENT(DEATH)) that always detaches. In that e
On 07/23, Oleg Nesterov wrote:
>
> On 07/22, Roland McGrath wrote:
> >
> > > 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 us
12 matches
Mail list logo
