[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110215155848.GA8699@redhat.com>
Date: Tue, 15 Feb 2011 16:58:48 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Tejun Heo <tj@...nel.org>
Cc: Denys Vlasenko <vda.linux@...glemail.com>,
Roland McGrath <roland@...hat.com>, jan.kratochvil@...hat.com,
linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org
Subject: Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang after
PTRACE_ATTACH
Hello Tejun,
On 02/15, Tejun Heo wrote:
>
> Hello, Oleg, Denys.
>
> On Mon, Feb 14, 2011 at 09:01:30PM +0100, Oleg Nesterov wrote:
> > > Or we can avoid entering TASK_TRACED on ptrace(PTRACE_GETSIGINFO) et al.
> > > Can we remain in TASK_STOPPED?
> >
> > Oh, unlikely, I think.
>
> Actually I was thinking along this line. We can allow
> PTRACE_GETSIGINFO to proceed without forcing the tracee into TRACED
> state, the rationale being the operation is required to tell between
> group stop and ptrace trap. Am I missing something?
I do not think this is really wrong (except this means another user
visible change and I never know if it is fine).
But I think it doesn't really help. Yes, this is probably enough for
strace (I don't know for sure) , but a more "sophisticated" debugger
may want to do something else with the stopped tracee.
And. Denys suggested this assuming PTRACE_CONT-doesnt-resume-until-SIGCONT,
and in this case this is not really needed. The debugger can safely do
PTRACE_GETSIGINFO even if this changes the state to TASK_TRACED.
Once it does PTRACE_CONT the tracee becomes "visible" to SIGCONT. Or,
if SIGCONT comes in between, the tracee runs.
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