Message-ID: <20110224202941.GA12258@redhat.com>
Date:	Thu, 24 Feb 2011 21:29:41 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Roland McGrath <roland@...hat.com>,
	Denys Vlasenko <vda.linux@...glemail.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

Hi Tejun,

On 02/21, Tejun Heo wrote:
>

Damn. Today is 02/24 ;) sorry.

> On Fri, Feb 18, 2011 at 08:37:09PM +0100, Oleg Nesterov wrote:
>
> > > As it currently stands, SIGSTOP/CONT while ptraced doesn't work
> >
> > And this is probably where we disagree the most. I think this is bug,
> > and this should be fixed.
>
> I don't think we disagree that it is a bug.  I want to fix it too but
> we definitely seem to disagree on how.

Yes, but I also think that the running tracee in the SIGNAL_STOP_STOPPED
process is bug by itself. IIUC, you think this is fine.

> I want to give more control to
> the ptracer so that the tracer has enough information and control to
> follow the group stop semantics if it wants to and you want to give
> more control to group stop so that it overrides the tracer and always
> does the right thing regarding group stop.

Yes, but debugger still has the control. It can nack SIGSTOP, or if
the tracee was already stopped it can send SIGCONT.

> > > I think it would be far cleaner to simply make ptracee always stop
> > > in TASK_TRACED and give the ptracer a way to notice what's
> > > happening to the tracee
> >
> > Well. If we accept the proposed PTRACE_CONT-needs-SIGCONT behaviour,
> > then I think this probably makes sense. The tracee stops under ptrace,
> > the possible SIGCONT shouldn't abuse debugger which wants to know, say,
> > the state of registers.
>
> The objections I have against PTRACE_CONT-needs-SIGCONT are,
>
> * It will be very different from the current behavior.

Unfortunately, you are right. Again, I think the current behaviour
is very wrong, but of course you are right that this behaviour is
very old, and thus perhaps we can't change it whatever I think.

> * ptrace, sans the odd SIGSTOP on attach which we should remove, is
>   per-task.  Sending out SIGCONT on PTRACE_CONT would break that.  I
>   really don't think that's a good idea.

Hmm. But why do you think we should always send SIGCONT after attach?

> * PTRACE_CONT would be behaving completely differently depending on
>   whether it's resuming from group stop or other traps.

Afaics, no. It does not matter from where the tracee resumes. See
the [pseudo patch] I sent. Once again, it doesn't really work, it
only tries to explain what I mean.

> > Once debugger does PTRACE_CONT, the tracee becomes TASK_STOPPED and
> > now it is "visible" to SIGCONT (or the tracee resumes if SIGCONT has
> > come in between).
> >
> > But I think you will equally blame this TRACED/STOPPED transition
> > as "behavioral subtleties" and I can understand you even if I disagree.
> > And yes, this leads to other questions. But note that this greatly
> > simplifies things. The tracee can never participate in the same
> > group-stop twice.
>
> But that's not really because the problem is solved.  The problem is
> put out of scope by forcing the tracer to always override group stop.

Hmm, can't understand... But probably I should just reply to the next
email from you.

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