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 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).