[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120422200459.GA7519@redhat.com>
Date: Sun, 22 Apr 2012 22:04:59 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc: pacman@...h.dhis.org, linux-man <linux-man@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>,
Denys Vlasenko <dvlasenk@...hat.com>,
Tejun Heo <tj@...nel.org>,
Jan Kratochvil <jan.kratochvil@...hat.com>,
Pedro Alves <palves@...hat.com>
Subject: Re: ptrace.2: PTRACE_KILL needs a stopped process too
On 04/23, Michael Kerrisk (man-pages) wrote:
>
> [widening CC]
add more CC's
> The man page says "For requests other than PTRACE_KILL,
Argh, PTRACE_KILL again.
You know, I simply do not know what it was supposed to do. I can only
see what the code actually does.
> the child process
> must be stopped."
Yes and no.
Yes, ptrace(PTRACE_KILL) "succeeds" even if the tracee is not stopped.
No, it has no effect if the tracee is not stopped.
All I can say is: PTRACE_KILL should never exist. If you want to kill
the tracee, you can do kill(SIGKILL).
Roughly, ptrace(PTRACE_KILL) is equal to ptrace(PTRACE_CONT, SIGKILL)
except it always returns 0.
> If the man page is describing actual intended kernel behavior, then it's a
> fairly long-standing kernel bug.
Perhaps. May be it should simply do kill(SIGKILL), but then it is not
clear why do we have PTRACE_KILL. And once again, I was never able to
understand the supposed behaviour.
Personally, I think we should fix the documentation. And imho the only
possible fix is to add this note: do not ever use PTRACE_KILL.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists