From: Oleg Nesterov <oleg@redhat.com>
To: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>, Tejun Heo <tj@kernel.org>,
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 18:37:10 +0200 [thread overview]
Message-ID: <20110907163710.GA5176@redhat.com> (raw)
In-Reply-To: <201109070655.05898.vda.linux@googlemail.com>
On 09/07, Denys Vlasenko wrote:
>
> On Tuesday 06 September 2011 22:08, Oleg Nesterov wrote:
>
> > And. Given that you can set/clear PT_TRACE_STOP in ptrace_setoptions(),
> > you need the locking.
> >
> > Just for example. do_signal_stop() calls ptrace_trap_notify() and hits
> > WARN_ON_ONCE(!PT_TRACE_STOP) because it was cleared in between.
>
> PTRACE_SETOPTIONS can be used only on stopped tracees. Can do_signal_stop()
> run on a tracee while it is stopped?
Sure. A tracee's sub-thread can do this. Or SIGCONT can trigger trap_notify.
And this is the "theoretical" problem sith PT_TRACE_STOP, in some sense.
Unlike other bits, it used by the "asynchronous" code. And it has the
meaning outside of the resume-stop path.
For example. You can't assume that PTRACE_LISTEN will work after you
set PT_TRACE_STOP, and this is not the implementation bug (although
of course I am not saying this is not possible to fix). But this needs
more changes, and _personally_ I see no point.
Oleg.
next prev parent reply other threads:[~2011-09-07 16:41 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
2011-09-07 4:55 ` Denys Vlasenko
2011-09-07 16:37 ` Oleg Nesterov [this message]
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=20110907163710.GA5176@redhat.com \
--to=oleg@redhat.com \
--cc=dvlasenk@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--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.