Re: Ptrace documentation, draft #3

[Oleg Nesterov]

On 05/20, Denys Vlasenko wrote:
>
 ??? How tracer knows which of its many tracees _are_ threads of that
> particular process? (It may trace more than one process; it may even
> don't keep track of its tracees' thread group relations at all...)

I think the tracer should track the tgid relations if it wants to know
this. Although we can add the simple PTREAD_ request which provides some
info including tgid.

> ??? what happens if two threads execve at the same time? Clearly, only
> one of them succeeds, but *which* one? Think "strace -f" or
> multi-threaded process here:
>
>   ** we get death notification: leader died: **
>  PID0 exit(0)                            = ?
>   ** we get syscall-entry-stop in thread 1: **
>  PID1 execve("/bin/foo", "foo" <unfinished ...>
>   ** we get syscall-entry-stop in thread 2: **
>  PID2 execve("/bin/bar", "bar" <unfinished ...>
>   ** we get PTRACE_EVENT_EXEC for PID0, we issue PTRACE_SYSCALL **
>   ** we get syscall-exit-stop for PID0: **
>  PID0 <... execve resumed> )             = 0
>
> ??? Question: WHICH execve succeeded? Can tracer figure it out?

Afaics, in general the tracer can't figure it out. Well, in this
particular case the tracer can inspect the arguments when the winner
(now it is PID0) reports the syscall-exit.

Also. All threads but the winner can report PTRACE_EVENT_EXIT. But once
again, we have problems with PTRACE_EVENT_EXIT/fatal_signal_pending().

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/