From: Tejun Heo <tj@kernel.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>,
Denys Vlasenko <vda.linux@googlemail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] Add new PTRACE_O_TRACESTOP option, make it control new ptrace behavior.
Date: Wed, 7 Sep 2011 08:06:45 +0900 [thread overview]
Message-ID: <20110906230645.GB16976@htj.dyndns.org> (raw)
In-Reply-To: <20110906200818.GA28349@redhat.com>
Hello,
On Tue, Sep 06, 2011 at 10:08:18PM +0200, Oleg Nesterov wrote:
> On 09/05, Denys Vlasenko wrote:
> > PTRACE_SEIZE does not assume PTRACE_O_TRACESTOP, but with this patch
> > it allows any PTRACE_O_opts to be set at attach time
>
> Well. This assumes that the only difference with PTRACE_SEIZE is the
> new stop/interrupt behaviour. I am not sure this is "safe" to assume.
>
> Tejun, what do you think?
The biggest problem would be locking against the tracee. Currently,
it's assumed that the behavior is determined at seize/attach time and
stay that way. Tracee behaves differently to maintain compatibility
or show the new behavior. If the state changes on the fly, we need to
change how tracee behaves. Maybe we'll need some re-trap trickery or
can just get away with making tracee always behave in the new way and
somehow present it differently if !TRACESTOP.
That said, I can't see much point in this excercise. Why does this
even matter? This is almost purely cosmetic and any effect on the
usability of the API is so too. The gained easiness of the API change
is in the realm of a few if statements. There's nothing to be gained
by allowing flipping TRACESTOP. Why would any program which is aware
of the new behavior turn it off and if not why would we want to
complicate things by supporting a feature which wouldn't be useful
risking higher chance of breakage (both from increased complexity and
lack of usage)?
ptrace is an ugly interface. Some of that is inherent but probably
most of it is from how it was designed and has evolved over time. As
far as I'm concerned, the goals are making it feature-complete and not
deviating too much from what's already there.
ptrace is painful to use with or without PTRACE_O_TRACESTOP. IMHO, if
we want to address this issue, a better approach would be implementing
a wrapper library which hides the silliness of the kernel interface
and provides useable set of interface and information.
Thanks.
--
tejun
next prev parent reply other threads:[~2011-09-06 23:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-04 21:11 RFC: PTRACE_SEIZE needs API cleanup? Denys Vlasenko
2011-09-05 1:15 ` Indan Zupancic
2011-09-05 9:24 ` Denys Vlasenko
2011-09-05 13:08 ` Indan Zupancic
2011-09-05 14:06 ` Denys Vlasenko
2011-09-05 17:21 ` Indan Zupancic
2011-09-06 0:59 ` Denys Vlasenko
2011-09-06 17:08 ` Indan Zupancic
2011-09-07 2:34 ` Denys Vlasenko
2011-09-07 17:15 ` Indan Zupancic
2011-09-05 17:44 ` Indan Zupancic
2011-09-06 1:05 ` Denys Vlasenko
2011-09-06 17:19 ` Indan Zupancic
2011-09-07 2:47 ` Denys Vlasenko
2011-09-07 14:24 ` Indan Zupancic
2011-09-05 14:54 ` Denys Vlasenko
2011-09-05 16:51 ` [PATCH 1/2] Fix pollution of task->ptrace if PTRACE_SETOPTIONS fails Denys Vlasenko
2011-09-05 17:01 ` [PATCH 2/2] Denys Vlasenko
2011-09-05 17:06 ` [PATCH 2/2] Add new PTRACE_O_TRACESTOP option, make it control new ptrace behavior Denys Vlasenko
2011-09-06 20:08 ` Oleg Nesterov
2011-09-06 23:06 ` Tejun Heo [this message]
2011-09-07 4:55 ` Denys Vlasenko
2011-09-07 16:37 ` Oleg Nesterov
2011-09-06 16:52 ` [PATCH v2] Fix clearing of task->ptrace if PTRACE_SETOPTIONS fails Denys Vlasenko
2011-09-06 18:43 ` Oleg Nesterov
2011-09-07 4:44 ` Denys Vlasenko
2011-09-07 4:45 ` [PATCH v3] " Denys Vlasenko
2011-09-07 20:35 ` Oleg Nesterov
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=20110906230645.GB16976@htj.dyndns.org \
--to=tj@kernel.org \
--cc=dvlasenk@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--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).