Re: ptrace improvement: PTRACE_O_INHERIT

[Oleg Nesterov <oleg@redhat.com>]

On 02/03, Roland McGrath wrote:
>
> * PTRACE_O_INHERIT
>
> This is a new option bit for PTRACE_SETOPTIONS or the options argument of
> PTRACE_ATTACH_NOSTOP.  Its effect is that clones of the tracee inherit the
> ptrace attachedness and option settings of their parent.

Jan has already reminded about about debug registers.

What else? Say, should TIF_SYSCALL_TRACE be copied? Suppose that we
try adapt strace to this new option.

> This has no other effects, meaning it does not cause
> either the parent or the child to stop for any event.

Somehow I am starting to feel uncomfortable. The debugger traces the
thread and doesn't even know about this fact. And can't know until the
first report. But once again, if this is fine for gdb - please ignore.

> The point of PTRACE_O_INHERIT would be to attach newly-created threads and
> children without causing an event stop and the attendant overhead.

OK, PTRACE_EVENT_FORK stops both, parent and child. But we can implement
PTRACE_O_INHERIT so that only the new child/thread stops. Or this doesn't
help enough?


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).

Not sure this makes any sense, but how "info treads" can work otherwise?

> Because of this spontaneous report aspect, it could be difficult to figure
> out what's going on with any new thread that is a fork/vfork, or other use
> of clone (oddball applications, or old linuxthreads), rather than a
> CLONE_THREAD case (NPTL pthread_create).  In those cases, si_tgid and
> si_pid are the same and neither matches any process you already know you
> are tracing.  In general, it can be impossible to figure out whose child
> this is, because its parent could exit so its ppid (as seen in
> /proc/pid/status et al) becomes 1.

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.

Suppose that we (to simplify the discussion) introduce task->original_ppid,
then we can "solve" the problem and report this pid to gdb. But given that
it has already died, how this can help?

Nevermind,

> 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.

Oleg.