linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Roland McGrath <roland@redhat.com>,
	jan.kratochvil@redhat.com,
	Denys Vlasenko <vda.linux@googlemail.com>,
	linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
	akpm@linux-foundation.org
Subject: Re: PTRACE_SEIZE/INTERRUPT: [RFC] Proposal for ptrace improvements
Date: Wed, 9 Mar 2011 18:30:42 +0100	[thread overview]
Message-ID: <20110309173042.GA2936@redhat.com> (raw)
In-Reply-To: <20110309094119.GB27010@htj.dyndns.org>

Hi Tejun,

On 03/09, Tejun Heo wrote:
>
> Hello, Oleg.
>
> On Mon, Mar 07, 2011 at 04:08:03PM +0100, Oleg Nesterov wrote:
> > Now that we more or less agree with Tejun's ideas,
>
> Yay! I finally succeeded at wearing down everyone.  :-)

Yes, thanks for correcting me, this is what I actually meant ;)

> > And I think there are other reasons. Say, suppose we want to add
> > the options for ATTACH/INTERRUPT. Right now I do not see the need,
> > but who knows.
>
> I think it would actually be better to share the option flags.  The
> two operations (whether implemented as separate operations or not)
> share the interrupting aspect and I think using separate set of
> options can be a bit confusing.  Hmmm... maybe it's actually better to
> make them have different prefixes and let the attach also accept the
> interrupt flags.

Perhaps, I agree with everything. As I said, I don't have a strong
opinion, just some random thoughts.

> > Final note... Previously I thought that we should not (I meant, can
> > not) change the current behaviour of PTRACE_O_TRACECLONE/etc which
> > sends SIGSTOP during the auto-attach. Now I am not sure, probably
> > we can avoid SIGSTOP if the forking task was PTRACE_SEIZE'ed. IOW,
> > perhaps the new ATTACH can have other "side effects". But, otoh,
> > this can complicate the transition to the new requests. Say, you
> > can't simply change strace to use PTRACE_SEIZE without auditing
> > the "-f" code.
>
> We can add attach option SIGSTOP_ON_AUTOATTACH to help the transition
> but then again it requires userland application change anyway so I
> think it would be better to simply enforce the new behavior when the
> new attach is used.  It's not like lack of SIGSTOP is gonna be super
> subtle.

Agreed.

> > And. This is off-topic, but we can also add PTRACE_DETACH_XXX which
> > does not require the stopped tracee. strace certainly needs it,
> > although INTERRUPT can solve most of the problems.
>
> I don't know.  The thing is that guaranteeing the tracee is in
> TASK_TRACED on attach/detach prevents a lot of subtle corner cases.

Agreed, but detach is different. It has to work with the running
tracee anyway.

However,

> Unless there are pretty compelling reasons, I'd like to keep that
> invariant intact.  What else does strace require that can't be
> provided by INTERRUPT + DETACH?

Yes, probably INTERRUPT + DETACH is enough. At least this certainly
solves the most annoying problems. IIRC. Denys can correct me.

Oleg.


  reply	other threads:[~2011-03-09 17:39 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-01 15:24 [RFC] Proposal for ptrace improvements Tejun Heo
2011-03-01 16:57 ` Denys Vlasenko
2011-03-01 17:09   ` Tejun Heo
2011-03-01 17:12     ` Tejun Heo
2011-03-01 17:21     ` Denys Vlasenko
2011-03-01 18:34       ` Tejun Heo
2011-03-01 23:51         ` Denys Vlasenko
2011-03-02  7:10           ` Tejun Heo
2011-03-02  5:07         ` Indan Zupancic
2011-03-02  7:44           ` Tejun Heo
2011-03-02 11:32             ` Indan Zupancic
2011-03-02 11:52               ` Denys Vlasenko
2011-03-02 14:50               ` Tejun Heo
2011-03-02 13:32             ` Oleg Nesterov
2011-03-03  0:47               ` Indan Zupancic
2011-03-03  1:30                 ` Denys Vlasenko
2011-03-03  1:55                   ` Indan Zupancic
2011-03-03  7:03                     ` Tejun Heo
2011-03-01 19:06 ` Jan Kratochvil
2011-03-01 22:14   ` Denys Vlasenko
2011-03-02  7:28     ` Tejun Heo
2011-03-02 10:58       ` Denys Vlasenko
2011-03-04 16:14     ` Jan Kratochvil
2011-03-04 16:41       ` Denys Vlasenko
2011-03-04 17:07       ` Oleg Nesterov
2011-03-04 18:12         ` Jan Kratochvil
2011-03-05  8:47           ` Tejun Heo
2011-03-01 22:59 ` Denys Vlasenko
2011-03-02  7:32   ` Tejun Heo
2011-03-02 11:02     ` Denys Vlasenko
2011-03-02 11:23       ` Tejun Heo
2011-03-03 19:26         ` Oleg Nesterov
2011-03-01 23:16 ` Denys Vlasenko
2011-03-02  7:37   ` Tejun Heo
2011-03-02 11:21     ` Denys Vlasenko
2011-03-02 11:27       ` Tejun Heo
2011-03-02 11:48         ` Denys Vlasenko
2011-03-02 14:43           ` Tejun Heo
2011-03-02 15:16             ` Denys Vlasenko
2011-03-02 15:25               ` Tejun Heo
2011-03-03 17:34 ` Oleg Nesterov
2011-03-03 20:22   ` Oleg Nesterov
2011-03-04  8:23     ` Tejun Heo
2011-03-04 18:16       ` Oleg Nesterov
2011-03-05  8:33         ` Tejun Heo
2011-03-04 13:01     ` Denys Vlasenko
2011-03-04 13:41       ` Tejun Heo
2011-03-04 13:59         ` Denys Vlasenko
2011-03-04 14:07           ` Tejun Heo
2011-03-04 14:31             ` Denys Vlasenko
2011-03-04 14:40               ` Tejun Heo
2011-03-04 17:05                 ` Denys Vlasenko
2011-03-04 17:12                   ` Linus Torvalds
2011-03-04 18:59                     ` Denys Vlasenko
2011-03-04 19:24                       ` Linus Torvalds
2011-03-04 16:13               ` Oleg Nesterov
2011-03-04 16:30                 ` Oleg Nesterov
2011-03-04  8:44   ` Tejun Heo
2011-03-04 16:01     ` Oleg Nesterov
2011-03-04 16:15       ` Tejun Heo
2011-03-04 16:26         ` Oleg Nesterov
2011-03-07 15:08 ` PTRACE_SEIZE/INTERRUPT: " Oleg Nesterov
2011-03-09  9:41   ` Tejun Heo
2011-03-09 17:30     ` Oleg Nesterov [this message]
2011-03-07 20:43 ` Roland McGrath
2011-03-09 10:28   ` Tejun Heo
2011-03-10 18:33     ` Steven Rostedt
2011-03-11  8:13       ` Tejun Heo
2011-03-11  8:22       ` Ingo Molnar
2011-03-11  9:35         ` Srikar Dronamraju
2011-03-11  9:43           ` Ingo Molnar
2011-03-14  1:03     ` Frank Ch. Eigler
2011-03-10 15:55   ` Steven Rostedt

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=20110309173042.GA2936@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roland@redhat.com \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vda.linux@googlemail.com \
    /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;
as well as URLs for NNTP newsgroup(s).