[widening CC] Denys, (Oleg, Tejun,) Would you be able to take a look at this report that is now already a long time in my inbox. Is there something here that still needs to be fixed after your recent changes to ptrace.2, Denys? Thanks, Michael ---------- Forwarded message ---------- From: <pacman@xxxxxxxxxxxxx> Date: Wed, Dec 16, 2009 at 1:45 PM Subject: ptrace.2: PTRACE_KILL needs a stopped process too To: mtk.manpages@xxxxxxxxx The man page says "For requests other than PTRACE_KILL, the child process must be stopped." But experience[1] shows that PTRACE_KILL also requires the child process to be stopped. gdb older than 7.0 doesn't always make sure its child process is stopped before attempting a PTRACE_KILL (try SIGTERMing gdb while the child process is running). That was fixed in gdb 7.0 by the addition of a SIGSTOP and wait before the PTRACE_KILL, so the kernel and latest gdb get along well now, which leaves the man page as the only thing that's out of sync. If the man page is describing actual intended kernel behavior, then it's a fairly long-standing kernel bug. But I get the feeling this was just an assumption by the original man page author that never got checked. [1] http://lists.gnu.org/archive/html/bug-coreutils/2009-11/msg00267.html http://lists.gnu.org/archive/html/bug-coreutils/2009-12/msg00025.html http://lists.gnu.org/archive/html/bug-coreutils/2009-12/msg00094.html -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface"; http://man7.org/tlpi/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
