Messages in this thread | | | From | Denys Vlasenko <> | Date | Thu, 2 Jun 2011 16:59:48 +0200 | Subject | Re: execve-under-ptrace API bug (was Re: Ptrace documentation, draft #3) |
| |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |