Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang afterPTRACE_ATTACH
From: Oleg Nesterov
Date: Thu Feb 24 2011 - 15:39:04 EST
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/