Re: execve-under-ptrace API bug (was Re: Ptrace documentation, draft #3)

Denys Vlasenko
2011-06-02T15:02:14Z

On Thu, Jun 2, 2011 at 12:57 PM, Pedro Alves <pedro@codesourcery.com> wrote:
> On Tuesday 31 May 2011 14:51:16, Oleg Nesterov wrote:
>
>> The main problem is: it is not clear do we really want EVENT_EXIT
>> in this case. I think we do, Roland thought we do not. OTOH I never
>> really the purpose of EVENT_EXIT, but this doesn't matter.
>>
>> If we decide we do want this notification (in this case), then we
>> need fixes. EVENT_EXIT is not reliable. Say, the thread can exit
>> before it dequeues SIGKILL and in this case it doesn't stop.
>> Also. If we guarantee EVENT_EXIT in this case, then probably the
>> implicit SIGKILL should not wakeup the TASK_TRACED tracee (except
>> the new PTRACE_LISTEN case).
>>
>> In short: currently I do not know what should be documented. I do
>> not know the original intent, I can only see what the code actually
>> does.
>
> Daniel Jacobowitz said when he submitted it:
>
> <http://lkml.indiana.edu/hypermail/linux/kernel/0302.0/1051.html>
>
> "PTRACE_EVENT_EXIT, which triggers in do_exit().  This is useful to quickly
>  find out where a program is making an exit syscall from, etc. - it
>  triggers before the mm is released, so we can still get backtraces et
>  cetera."

We have circa 340 syscalls. What makes exit so special that it has to have
a separate ptrace stop specially for it? People may legitimately
want to know where write() syscall happens, should we add
PTRACE_EVENT_WRITE? Rinse, repeat...

--
vda