From: Werner Almesberger <wa@almesberger.net>
To: Andries Brouwer <aebr@win.tue.nl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: PTRACE_KILL doesn't (2.5.44 and others)
Date: Mon, 31 Mar 2003 12:48:00 -0300 [thread overview]
Message-ID: <20030331124800.H7414@almesberger.net> (raw)
In-Reply-To: <20030331145519.GA12984@win.tue.nl>; from aebr@win.tue.nl on Mon, Mar 31, 2003 at 04:55:19PM +0200
Andries Brouwer wrote:
> First of all, it is dangerous to depend on subtle properties
> of obscure calls like ptrace.
Indeed ;-) Well, there are worse things, e.g. DWARF2
information versus optimization.
> The Linux man page says
It also says (man-pages-1.56):
| For requests other than PTRACE_KILL, the child process
| must be stopped.
Of course, it doesn't explicitly say that PTRACE_KILL will do
anything in this case, but the wording kind of suggests that.
> Since it is not clear what the right behaviour is, it is not clear
> whether there is something to fix.
Yes, that's my question. If we're trying to emulate the exact
behaviour of some other OS or some specification, that would
give the answer. If not, we can decide what makes sense, and,
if a change would be needed for the semantics to make sense,
whether it's worth making that change.
At least it seems that existing code is fine with how
PTRACE_KILL works, given how long it has behaved like that.
(But then, existing code may rarely use PTRACE_KILL, and may
not be particularly picky about the result.)
What puzzles me a little is that kill(2) seems to do precisely
what I would have expected PTRACE_KILL to do, i.e. kill the
process no matter whether it's stopped or not, and detach from
it. So why is there a PTRACE_KILL in the first place ?
The non-Linux man page you quote says:
| 8 This request causes the child to terminate with the
| same consequences as exit(2).
Then it would make sense. Of course, this isn't what
PTRACE_KILL does under Linux. Does that non-Linux man page
also say anything about the exit status ?
Another subtlety, seen under 2.5.44: if PTRACE_ATTACH is
immediately followed by PTRACE_KILL, PTRACE_KILL is silently
ignored (no error).
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
prev parent reply other threads:[~2003-03-31 15:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-30 23:51 Werner Almesberger
2003-03-31 14:55 ` Andries Brouwer
2003-03-31 15:48 ` Werner Almesberger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030331124800.H7414@almesberger.net \
--to=wa@almesberger.net \
--cc=aebr@win.tue.nl \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®