Re: ptrace improvement: PTRACE_O_INHERIT

[Oleg Nesterov <oleg at redhat dot com>]

On 02/11, Roland McGrath wrote:
>
> > What else? Say, should TIF_SYSCALL_TRACE be copied?
> > Suppose that we try adapt strace to this new option.
>
> Let's talk about the userland interface features here,

Ah, I didn't mean implementation details, sorry.

> For strace as it is, I don't think there is really any benefit to using
> PTRACE_O_INHERIT.

OK.

> Another feature that has made obvious sense for a long time is to have
> PTRACE_O_TRACESYSCALL instead of just PTRACE_SYSCALL

Yes, and that is why I asked about TIF_SYSCALL_TRACE. Because to me
PTRACE_SYSCALL looks like a property/option regardless of implementation
details.

But I agree, this was a bit off-topic.

> > Or. Suppose that clone() under PTRACE_O_INHERIT notifies the tracer
> > (sends SIGCHLD), and the new tracee gets the new PTRACE_O_INHERITed
> > mark. Then we can implement wait(W_WHO_WAS_CLONNED) which clears
> > PTRACE_O_INHERITed and reports the new tracee (just in case, this
> > doesn't need the stopped tracee).
>
> I don't really follow this idea at all, sorry.

I meant, we can intoduce the new W*** flag for do_wait(). If the new
tracee was PTRACE_O_INHERIT'ed, do_wait() returns its pid.

> > Not sure this makes any sense, but how "info treads" can work otherwise?
>
> It can always look as /proc/PID/task/ to enumerate threads.

Well yes, but /proc/PID/task/ is not convenient and reliable.
Especially if we do not trace all threads.

But, again, if this is fine to gdb - forget.

> > Not sure I really understand why this is the problem by itself. Yes, if
> > its ppid == 1, we know that the original parent was traced by us and then
> > it has gone.
>
> [... snip ...]

Hmm... Still can't understans right now, but this doesn't matter:

> > > So perhaps it would be better to have
> > > this be just PTRACE_O_THREAD_INHERIT, where it only applies to CLONE_THREAD
> > > clones.
> >
> > Or we can have both.
>
> Indeed.  But I want to add things that GDB is really going to use, not go
> hog-wild on speculative features

Yes, yes, agreed.

Damn. I was so unclear. I tried to say: yes, I think PTRACE_O_THREAD_INHERIT
makes more sense. If nothing else, the tracer doesn't necessarily wants to
follow forks, this can create the unneeded overhead if it only wants to ptrace
the sub-threads.

IOW, I think that we should have both, or PTRACE_O_THREAD_INHERIT only.
Or, this option should take "clone_flags" as an argument.

Oleg.