utrace_ptrace && task->ptrace

[Roland McGrath]

> > Not "some", just that one, right?
> 
> Not just one. tracehook_tracer_task, tracehook_notify_jctl.

Ah.  tracer_task is an outlier we can think about separately a little
later.  The notify_jctl case is another in the same bag of wait/SIGCHLD
things that I had in mind.

> The problem is, I can't imagine all details now. And. I think it is better
> to make the first working version as simple/small as possible.

Sure, incremental steps are fine.

> So. For the first version of CONFIG_PTRACE_UTRACE I'd suggest to use
> ->ptrace to keep the single bit, PT_PTRACED (well, PT_PTRACE_CAP too).
> All other PT_ bits should go into engine->data.

Ok.

> Also. Either we have to add a lot of #ifdef's into tracehook.h, or we
> can add a single #ifdef into task_ptrace() (like your utrace-ptrace.patch
> does). In the last case, do you think something like below makes sense?

There is no plan for #ifdef's.  What hch et al upstream told us is that
there should be only one ptrace implementation, no options (and so utrace
has to be rock solid, which is why I'm getting you to do all the hard parts
;-).  AFAIK this is our plan now.  Old ptrace goes away and only the
utrace-based implementation exists at the end.  (It's not my idea.  But I
tried it with the option before and had no luck whatsoever getting utrace
merged that way, so I'm trying to do what I was told most recently.)

The sole original purpose of task_ptrace() was for conditionalizing the
things in tracehook.h that can be replaced by utrace hooks.  Now all those
ptrace checks in tracehook.h just go entirely.  The only ptrace things that
remain, either as permanent special cases, or until we address those needs
with something new in utrace, are:

tracehook_unsafe_exec
tracehook_tracer_task

and the wait-interference cases.  (That's why those didn't use the wrapper.)

> Or we can start with reverting 5cb11446892833e50970fb2277a9f7563b0a8bd3
> I regret about this patch now (and now I understand why you were not
> very happy with this change ;). 

Yes, well.  There's always more cleaning up to do later.

> But this patch was needed for child-data cleanups. However, I think we
> should forget about these cleanups for now.

What?!?  The whole point of tracee data structure cleanup was to fit it
cleanly with utrace.  i.e., to have a thing to hang off engine->data.
I don't understand why you'd want to abandon that now.

> In any case, we need some changes, and the patch should be sent separately,
> before re-sending the updated version of utrace, afaics.

I'd always expected that a large number of the ptrace cleanup patches would
precede utrace being merged.  That's why you were working on them first.


Thanks,
Roland