From: Pedro Alves <pedro@codesourcery.com>
To: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Oleg Nesterov <oleg@redhat.com>, Tejun Heo <tj@kernel.org>,
linux-kernel@vger.kernel.org,
Denys Vlasenko <vda.linux@googlemail.com>
Subject: Re: [PATCH v3] Make PTRACE_SEIZE set ptrace options specified in 'data'
Date: Fri, 9 Sep 2011 14:15:33 +0100 [thread overview]
Message-ID: <201109091415.33503.pedro@codesourcery.com> (raw)
In-Reply-To: <1315571337.4127.3.camel@dhcp-25-63.brq.redhat.com>
On Friday 09 September 2011 13:28:55, Denys Vlasenko wrote:
> On Fri, 2011-09-09 at 12:12 +0100, Pedro Alves wrote:
> > On Thursday 08 September 2011 19:22:04, Denys Vlasenko wrote:
> > > Make PTRACE_SEIZE set ptrace options specified in 'data' parameter
> > >
> > > This can be used to close a few corner cases in strace where we get
> > > unwanted racy behavior after attach, but before we have a chance
> > > to set options (the notorious post-execve SIGTRAP comes to mind),
> >
> > I'm still confused on why you're raising the SIGTRAP argument. Did you see
> >
> > https://lkml.org/lkml/2011/9/8/7
> >
> > From previous discussions, I understood that PTRACE_SEIZE _always_
> > disables
> > the post-execve SIGTRAP, so I don't believe that race actually exists.
> > Or is that not the case?
>
>
> I believe it is not the case. And I object to making it the case.
Well, if you'll remember, back in <https://lkml.org/lkml/2011/5/19/704> I
raised this exact problem with that pesky racy post-execve SIGTRAP showing
through on SEIZE, and Tejun a few replies later mentioned that the SIGTRAP
was to be removed on SEIZE. I'm sure it was said before even, but I'm
not finding the emails now.
> My sense of taste says the approach "you need to use SEIZE to affect
> feature <foo>" for various unrelated <foo> makes ptrace API ugly.
Yes, very much agreed!
> Especially that in this case, we already have a method in API
> to suppress post-execve SIGTRAP.
Right, but we end up with no way to make the tracee _not ever
stop_ at execve if the tracer wants to, like you can make
the tracee not ever stop on forks or syscalls, by not enabling
the corresponding PTRACE_O_FOO or not PTRACE_SYSCALL. Not
specifying PTRACE_O_TRACEEXEC coupled with `SEIZE not stopping
tracees for that magic SIGTRAP' got you that. In a way, it looked to
me to make the API a bit less ugly. That said I'm not seeing GDB
_not_ using PTRACE_O_TRACEEXEC...
Anyway, could you please check (or Tejun please confirm)
that that magic SIGTRAP is really still there on SEIZE?
--
Pedro Alves
next prev parent reply other threads:[~2011-09-09 13:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-08 18:22 [PATCH v3] Make PTRACE_SEIZE set ptrace options specified in 'data' Denys Vlasenko
2011-09-08 19:24 ` Oleg Nesterov
2011-09-09 11:12 ` Pedro Alves
2011-09-09 12:28 ` Denys Vlasenko
2011-09-09 13:15 ` Pedro Alves [this message]
2011-09-09 16:30 ` Oleg Nesterov
2011-09-09 16:55 ` Denys Vlasenko
2011-09-09 17:09 ` Pedro Alves
2011-09-09 17:18 ` Oleg Nesterov
2011-09-09 20:03 ` Denys Vlasenko
2011-09-10 11:19 ` Pedro Alves
2011-09-10 11:40 ` Denys Vlasenko
2011-09-10 12:12 ` Pedro Alves
2011-09-10 15:36 ` Pedro Alves
2011-09-13 7:45 ` Indan Zupancic
2011-09-13 8:04 ` Indan Zupancic
2011-09-10 23:34 ` Tejun Heo
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=201109091415.33503.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=dvlasenk@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=tj@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.