Message-ID: <20110228143920.GD9326@htj.dyndns.org>
Date:	Mon, 28 Feb 2011 15:39:20 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	Oleg Nesterov <oleg@...hat.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

Hey,

On Mon, Feb 28, 2011 at 03:25:53PM +0100, Denys Vlasenko wrote:
> On Mon, Feb 28, 2011 at 2:53 PM, Tejun Heo <tj@...nel.org> wrote:
> > I don't really follow the distinction you're trying to make.  It
> > doesn't matter what you're trying to do.  All that's necessary is for
> > the debugger to find out whether group stop is in effect or not and a
> > way to control the tracee's execution.  Nothing else is necessary.
> > The debugger already knows when the tracee enters group stop.  We just
> > need a way for the debugger to find out when group stop stops.
> 
> If I understand you right, you are proposing to handle strace+^Z
> scenario this way (simplified pseudo-C):
> 
> for(;;) {
>   waitpid(-1, ...);
>   tracee_is_stopped = 0;
>   if (waitpid reported *stopping* signal) {
>     PTRACE_GETSIGINFO();
>     if (PTRACE_GETSIGINFO failed)
>       tracee_is_stopped = 1;
>   }
>   if (!tracee_is_stopped)
>     PTRACE_SYSCALL(signal);
> }
> 
> This requires API change to make waitpid in debugger
> see waking SIGCONTs even if we did not restart the tracee
> (at least in the case when tracee was in group stop).

Yes, something like that.  I'm still not sure how to notify end of
group stop to the debugger tho.  Using wait(2) would be the path of
the least resistance but as you pointed out it does change the
behavior.  I think what we can do is to switch on the behavior when
the new attach call is used.  We'll probably have to pay some
attention to make the notification race-free and reliable but I think
it shouldn't too difficult.

> This sounds like viable plan from userspace POV.

Cool.

> > A tracee should _always_ enter ptrace trap whenever stopping while
> > ptraced.  The stop here or stop there depending on the type of stop
> > behavior is hardly useful and very fragile (I think it's inherently
> > fragile that way).  Again, the only missing thing is a way for the
> > debugger to find out when task stop stops.
> 
> PTRACE_GETSIGINFO tells you that. It's a bit of a hack
> (PTRACE_GETSIGINFO was meant to be used for a different purpose)
> but it seems to be working well.

Yeap, what works works.  We probably want to explain its use in the
man page but I don't think there's any reason to add a new mechanism
for this.

> The problematic case is when we attach to *already stopped* task.
> gdb today goes through insane gyrations to detect that condition
> (I believe it looks into /proc/TID/state).
> 
> If we are going to add PTRACE_ATTACH_NOSTOP or something like it,
> perhaps we need to take care to make tracee state detectable
> at attach time more easily. Maybe by delivering "I have stopped with SIGfoo"
> notification to the debugger if tracee was in group stop?

I believe this is already solved by making the tracee always enter
TASK_TRACED via ptrace_stop() on attach, which always reports the
group stop signal to the ptracer whether the real parent has consumed
it or not.  The patch is at the top of this gigantic thread.  Oleg,
this is solved one, right?

Thanks.

-- 
tejun
--
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