On 06/20, Denys Vlasenko wrote: > > On 06/19/2013 06:32 PM, Oleg Nesterov wrote: > > On 06/19, Denys Vlasenko wrote: > >> > >> This is a user-visible behavior change. > >> Do we really have to introduce a separate > >> PTRACE_NOT_STUPID_DETACH? I hope not. > > > > Oh, I think yes. > > > >> @@ -1062,7 +1060,8 @@ SYSCALL_DEFINE4(ptrace, long, request, long, pid, > >> unsigned long, addr, > >> } > >> > >> ret = ptrace_check_attach(child, request == PTRACE_KILL || > >> - request == PTRACE_INTERRUPT); > >> + request == PTRACE_INTERRUPT || > >> + request == PTRACE_DETACH); > > > > There doesn't look right. > > > > For example ptrace_disable(). See the comment set_task_blockstep(). > > I see the comment. I think it implies that TF-induced debug > interrupt may happen on the running task after it is detached, > which will result in SIGTRAP being sent to it.
No. The comment means that set/clear of TIF_BLOCKSTEP is not safe unless the tracee can't run. If we race with __switch_to() we can set the wrong debugctlmsr. > If so, do we have the same problem if tracer exits > and implicit detach is performed? No. If the tracer exits it doesn't do the "cleanups" like ptrace_disable(). That is why this potentially leaves the tracee in the inconsistent state. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
