[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110907163710.GA5176@redhat.com>
Date: Wed, 7 Sep 2011 18:37:10 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Denys Vlasenko <vda.linux@...glemail.com>
Cc: Denys Vlasenko <dvlasenk@...hat.com>, Tejun Heo <tj@...nel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] Add new PTRACE_O_TRACESTOP option, make it control
new ptrace behavior.
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists