On Sunday 22 April 2012 16:04:59 Oleg Nesterov wrote:
> 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.
probably not that big of a deal, but the reason i like using
ptrace(PTRACE_KILL) over a raw kill() is that you are less likely to kill the
wrong process by accident. maybe not that big of a deal in practice though.
-mike
On 05/09/2012 04:09 PM, Mike Frysinger wrote:
> probably not that big of a deal, but the reason i like using
> ptrace(PTRACE_KILL) over a raw kill() is that you are less likely to kill the
> wrong process by accident. maybe not that big of a deal in practice though.
And you can do tgkill instead. It was specifically invented to handle the
reuse case.
--
Pedro Alves
On 05/09, Pedro Alves wrote:
>
> On 05/09/2012 04:09 PM, Mike Frysinger wrote:
>
> > probably not that big of a deal, but the reason i like using
> > ptrace(PTRACE_KILL) over a raw kill() is that you are less likely to kill the
> > wrong process by accident. maybe not that big of a deal in practice though.
>
>
> And you can do tgkill instead. It was specifically invented to handle the
> reuse case.
tgkill() can kill the wrong process/thread too, although it lessens the risk.
But I don't really understand the problem. The traced thread can't go away
until the tracer does wait/detach, and thus its pid can't be reused?
May be, "by accident" above means something else, not pid reuse...
Oleg.
On Wednesday 09 May 2012 16:12:19 Oleg Nesterov wrote:
> On 05/09, Pedro Alves wrote:
> > On 05/09/2012 04:09 PM, Mike Frysinger wrote:
> > > probably not that big of a deal, but the reason i like using
> > > ptrace(PTRACE_KILL) over a raw kill() is that you are less likely to
> > > kill the wrong process by accident. maybe not that big of a deal in
> > > practice though.
> >
> > And you can do tgkill instead. It was specifically invented to handle
> > the reuse case.
>
> tgkill() can kill the wrong process/thread too, although it lessens the
> risk.
>
> But I don't really understand the problem. The traced thread can't go away
> until the tracer does wait/detach, and thus its pid can't be reused?
or the process has received a SIGKILL for some reason
> May be, "by accident" above means something else, not pid reuse...
i like to assume that my code isn't going to be bug free, so the more
mechanisms i have in place to protect innocent bystanders the better :)
-mike
On 05/09, Mike Frysinger wrote:
>
> On Wednesday 09 May 2012 16:12:19 Oleg Nesterov wrote:
> > On 05/09, Pedro Alves wrote:
> > > On 05/09/2012 04:09 PM, Mike Frysinger wrote:
> > > > probably not that big of a deal, but the reason i like using
> > > > ptrace(PTRACE_KILL) over a raw kill() is that you are less likely to
> > > > kill the wrong process by accident. maybe not that big of a deal in
> > > > practice though.
> > >
> > > And you can do tgkill instead. It was specifically invented to handle
> > > the reuse case.
> >
> > tgkill() can kill the wrong process/thread too, although it lessens the
> > risk.
> >
> > But I don't really understand the problem. The traced thread can't go away
> > until the tracer does wait/detach, and thus its pid can't be reused?
>
> or the process has received a SIGKILL for some reason
And? In this case it will be killed, yes. But this zombie can't go away
until the tracer does do_wait().
OK, the multi-threaded exec adds more fun.
> > May be, "by accident" above means something else, not pid reuse...
>
> i like to assume that my code isn't going to be bug free, so the more
> mechanisms i have in place to protect innocent bystanders the better :)
> -mike
>From this pov PTRACE_KILL is safer, I agree ;)
Oleg.
On 05/09/2012 09:12 PM, Oleg Nesterov wrote:
> tgkill() can kill the wrong process/thread too, although it lessens the risk.
>
> But I don't really understand the problem. The traced thread can't go away
> until the tracer does wait/detach, and thus its pid can't be reused?
There's the non-leader thread execs and tracer didn't enable
PTRACE_O_TRACEEXEC case at least, while you try to kill the thread that just
execed, I think. Though that's quite pedantic. The tracer could prevent this
in other ways.
> May be, "by accident" above means something else, not pid reuse...
Pffft, who writes buggy code anyway? ;-)
--
Pedro Alves
On 05/09/2012 10:14 PM, Oleg Nesterov wrote:
>> i like to assume that my code isn't going to be bug free, so the more
>> mechanisms i have in place to protect innocent bystanders the better :)
>> -mike
>
> From this pov PTRACE_KILL is safer, I agree ;)
Yeah, until you trip on that case where it resumes the process
instead of killing it... At that point, it's useless.
Since I know Mike likes hacking on GDB so much ;-), FYI, this is
exercised by the gdb.base/kill-after-signal.exp test.
--
Pedro Alves