Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang afterPTRACE_ATTACH
From: Tejun Heo
Date: Fri Feb 25 2011 - 10:46:23 EST
On Thu, Feb 24, 2011 at 10:08:19PM +0100, Oleg Nesterov wrote:
> On 02/22, Tejun Heo wrote:
> > > What is important, I think ptrace should respect SIGNAL_STOP_STOPPED.
> > > IOW, when the tracee is group-stopped (TASK_STOPPED or TASK_TRACED,
> > > doesn't matter), ptrace_resume() should not wake it up, but merely
> > > do set_task_state(TASK_STATE) and make it resumeable by SIGCONT.
> > I don't think that's gonna fly. It first is a very user-visible
> > change to how ptrace_resume() works
> Yes. But can't resist, this is a bit unfair ;) It was you who convinced
> me we should cleanup this horror somehow, even if we break some corner
Okay, but I don't think I have changed my position. Things like the
weird race windows visible from some other thread fall in weird corner
cases but the basic stop/resume behavior is much more fundamental than
that and I don't think it would be wise to change that when there are
other ways to solve the problems. I was referring more to the subtle
implementation details which prevent the problems from being solved
than changing the model itself.
> However, again, I can't argue. Perhaps this change is too radical.
Or maybe I'm just throwing out different arguments as I see fit. :-P
Anyways, I'm opposed to changing the principles of the current
behavior for two reasons.
1. Changing those would be too visible and can be avoided by taking a
2. I think, in principle, the current per-task behavior is better than
the proposed behavior of making jctl and ptrace intertwined.
> > As Jan's examples showed, there are things which the
> > debugger does behind group stop's back and some of them are quite
> > legitimate and useful things to do like running some code
> Yes. This can surprise a user which runs the unmodified debugger.
Yeap, it would.
> > If you mix ptrace trap and group stop and then fix group stop
> > notification, not only multithreaded debugging becomes quite
> > cumbersome (suddenly ptracing becomes per-process thing instead of
> > per-thread),
> It should be, imho. Like SIGKILL, SIGSTOP/SIGCONT are not per-thread.
> This is per-process thing.
jctl should be and will stay to be per-process, but that doesn't mean
ptrace needs to interact with them at process level. ptrace can still
be per-task and operate beneath jctl, which is what I'm proposing to
Requiring ptrace to follow jctl's rules might be conceptually
appealing (not to me) but it changes the current behavior a lot and
affects multithread debugging capability significantly. I really
can't see much upside of such change.
> > it becomes almost impossible to debug jctl behaviors.
> > Jctl becomes completely intertwined with ptracing and the real parent
> > would get numerous notifications during the course of debugging.
> Again, I think this is a win. The real parent should know that, say,
> its child becomes running after it was stopped. It does not matter
> why it was CLD_CONTINUED, it was resumed and that is all.
I see and we do disagree. :-)
> > I think they belong to different layers and they should stack instead
> > of mix. I'll try to write up a summary for how I think it can be done
> > later
> OK. You know, we already spent sooooooooooooooooooooooooooooooooooooooo
> much time discussing this, I have the strong desire to agree in advance
> with anything new ;)
Yeah!! I'll try to write it up tomorrow.
> > but in short I think we just need two more PTRACE calls (one for
> > combined SIGSTOPless attach + INTERRUPT
> Yes, we are discussing these requests on archer,
Can we please do that on LKML? It's a kernel change after all.
> > and the other for jctl monitoring)
> Of course, we can add the new requests to help gdb/strace/whatever
> to handle jctl. In fact I think we should in any case.
> But this is "easy". In the context of this discussion, my only concern
> is the current behaviour.
IMHO, as long as we don't break the current users in any significant
way, it should be okay, but I don't think we can or should make
fundamental changes to the existing behaviors. My position is, I
guess, to change the things which prevent us from implementing the new
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/