Hi Again, > Or the child can check getppid() == saved_parent_pid after PTRACE_TRACEME.
In fact that's what I did when I tested the new option - the child ran: volatile long ready = 0; int saved_parent_pid = getpid(); if(!(son = fork()) { while(!ready) { sched_yield(); if(getppid() != saved_parent_pid) exit(1); } execve(...); } ptrace(PTRACE_ATTACH, son, 0, 0); waitpid(son, ...); ptrace(PTRACE_SETOPTIONS, son, 0, PTRACE_P_TRACEFORK|PTRACE_O_EXITKILL); ptrace(PTRACE_POKEDATA, son, &ready, 1); /* continue tracing */ I also checked that PTRACE_O_EXITKILL is inherited to grandchildren. Yes, I may also use PTRACE_SEIZE, but since it is not yet documented, I will need to read the kernel code more to make extra sure it has no unwanted side effects. Best Regards, Amnon. Oleg Nesterov wrote: > > Hi Amnon, > > On 11/08, Amnon Shiloh wrote: > > > > Thanks for the patch, I tried it and it works nicely! > > OK, thanks. I'll wait for other comments a bit and then send > the patch to Andrew. > > > Also, I just noticed that this new option (PTRACE_O_EXITKILL) is not > > safe with ptrace(PTRACE_TRACEME)+execve, because the parent may die > > before even having a chance to set PTRACE_O_EXITKILL! > > Not safe? I guess you meant that PTRACE_O_EXITKILL can't prevent > this race? Yes sure. Or the parent can die before it does > PTRACE_O_EXITKILL. > > > However, that's easy to fix by using PTRACE_ATTACH instead. > > Or the child can check getppid() == saved_parent_pid after PTRACE_TRACEME. > > But if you switch to PTRACE_ATTACH, I'd suggest to use PTRACE_SEIZE. > Note that, in particular, this allows you to specify the options at > attach. > > As for PF_NO_SIGSTOP, I'll write another email. > > 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/