From: Roland McGrath <roland@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andrea Arcangeli <andrea@cpushare.com>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: seccomp for 2.6.11-rc1-bk8
Date: Fri, 21 Jan 2005 13:31:46 -0800 [thread overview]
Message-ID: <200501212131.j0LLVkJ8013886@magilla.sf.frob.com> (raw)
In-Reply-To: Ingo Molnar's message of Friday, 21 January 2005 13:55:58 +0100 <20050121125558.GA5596@elte.hu>
> maybe this could even be fit into existing ptrace semantics, without any
> need for PTRACE_ATTACH_JAIL. What we need is to catch the case where a
> ptraced child is running (i.e. the signal_wake_up() has already been
> done, and the parent is waiting for the child to stop again), and the
> ptrace parent is killed unexpectedly. Would it be a correct fix to just
> unconditionally stop the child in this case (and leave it hanging in
> such a state)? Or to kill it right away?
That's the same as the case of the debugger dying or being killed by hand.
When gdb has a bug, people want to be able to kill it and get on with using
their program, not have their program always be killed too.
If you add this feature, it makes most sense IMHO to use PTRACE_SETOPTIONS
as the way to request it.
Thanks,
Roland
next prev parent reply other threads:[~2005-01-21 21:34 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-21 10:06 Andrea Arcangeli
2005-01-21 12:03 ` Ingo Molnar
2005-01-21 12:47 ` Ingo Molnar
2005-01-21 12:55 ` Ingo Molnar
2005-01-21 21:31 ` Roland McGrath [this message]
2005-01-22 3:25 ` Andrea Arcangeli
2005-01-21 20:24 ` Andrea Arcangeli
2005-01-21 17:39 ` Chris Wright
2005-01-21 18:39 ` Rik van Riel
2005-01-21 18:50 ` Chris Wright
2005-01-21 19:55 ` Ingo Molnar
2005-01-21 20:34 ` Andrea Arcangeli
2005-01-21 20:54 ` Ingo Molnar
2005-01-22 2:51 ` Andrea Arcangeli
2005-01-22 10:32 ` Pavel Machek
2005-01-22 17:25 ` Andrea Arcangeli
2005-01-22 19:42 ` Pavel Machek
2005-01-22 23:34 ` Andrea Arcangeli
2005-01-23 0:07 ` Pavel Machek
2005-01-23 0:46 ` Andrea Arcangeli
2005-01-23 0:43 ` Rik van Riel
2005-01-23 0:52 ` Andrea Arcangeli
2005-01-23 4:43 ` Valdis.Kletnieks
2005-01-23 6:11 ` Andrea Arcangeli
2005-01-21 18:59 ` David Wagner
2005-01-21 19:17 ` Chris Wright
2005-01-23 7:34 ` David Wagner
2005-01-24 15:10 ` Daniel Jacobowitz
2005-02-15 9:25 ` Andrea Arcangeli
2005-02-25 19:01 ` David Wagner
2005-01-21 12:11 ` Pavel Machek
2005-02-15 9:32 ` seccomp for 2.6.11-rc4 Andrea Arcangeli
2005-02-16 5:25 ` Herbert Poetzl
2005-02-18 2:25 ` Andrea Arcangeli
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=200501212131.j0LLVkJ8013886@magilla.sf.frob.com \
--to=roland@redhat.com \
--cc=akpm@osdl.org \
--cc=andrea@cpushare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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®