> Yes, I do have some other ideas. When a ptraced task gets a stop
> signal, its delivery is controlled by the tracer, right? So, right
> from the beginning, group stop having consistent precedence over
> ptrace breaks.
I would not agree with that way of describing it. The tracer controls
what signals actually get delivered. A group stop doesn't begin until
a stop signal is actually delivered (or a core dump is started). What
I'm talking about when I say that group stop should have precedence is
that once a group stop is initiated by one thread, then it should
happen fully and immediately to all threads. When a tracer intercepts
a signal and does not specify it for delivery, then no signal is
delivered and so no thread initiates a group stop at all. That's an
entirely different kettle of fish.
> As long as the interaction is consistent and well defined, I don't
> really think it matters one way or the other but given the above
> precedence and the current ptracers' expectations, I can't see how we
> would be able to prioritize group stop over ptrace at this point.
I don't follow this logic at all. Perhaps it is predicated on the
wrong idea of what "initiating a group stop" means, and you would not
say this given my paragraph above. If you mean something different
than the misperception that a group stop exists at all before a signal
is truly delivered, then I don't understand what you mean.
> The problem is that those loose ends can't be tied up without breaking
> the current users. PTRACE_CONT has priority over group stop and it's
> a very visible from userland. I'm afraid the window of opportunity to
> make that behavior the default had already passed quite some time ago.
I am not convinced of that at all, though I certainly wouldn't say now
that it's a settled question yet. The userland expectations are
pretty convoluted too. I suspect that what you are calling the
userland expectations for PTRACE_CONT to ignore the state of a pending
group stop are in fact just fallout of userland confusion about what's
a job control stop and what's a ptrace stop.
> > If there is a group stop in progress but not yet complete, then
> > PTRACE_CONT on a thread in the group should probably just move it
> > from TASK_TRACED to TASK_STOPPED without resuming it at all.
>
> I really don't think that's an option at this point and can't see how
> such behavior could be made consistent given ptracer has inherent
> superiority over signal delivery. That would make initiation of group
> stop controllerd by ptracer but participation not. The behavior
> becomes essentially indeterministic depending on which task in the
> group gets the signal. :-(
I don't think I follow your logic and I certainly don't agree with
your conclusion. It's simple: if a stop signal is actually delivered,
then every thread stops. If one thread is traced and another is not,
then the tracer can prevent a signal from being delivered to one
thread and cannot prevent it from being delivered to another.
> > Once a group stop is complete, then probably the ideal is that
> > PTRACE_CONT would not resume a thread until a real SIGCONT cleared
> > the job control stop condition. But it's likely that existing
> > ptrace users have expectations contrary to that, so we'll have to
> > see.
>
> So, no, I don't think that would be possible or even desirable.
Of course it's possible. We have to work out the entire web of
assumptions and ramifications to be sure what's desireable given
practical compatibility constraints. I think it's just plain obvious
that it's the desireable thing in the abstract--that tracing stops and
job control stops should be independent functions.
Thanks,
Roland
Hello,
On Tue, Feb 01, 2011 at 09:57:11PM -0800, Roland McGrath wrote:
> > The problem is that those loose ends can't be tied up without breaking
> > the current users. PTRACE_CONT has priority over group stop and it's
> > a very visible from userland. I'm afraid the window of opportunity to
> > make that behavior the default had already passed quite some time ago.
>
> I am not convinced of that at all, though I certainly wouldn't say now
> that it's a settled question yet. The userland expectations are
> pretty convoluted too. I suspect that what you are calling the
> userland expectations for PTRACE_CONT to ignore the state of a pending
> group stop are in fact just fallout of userland confusion about what's
> a job control stop and what's a ptrace stop.
Okay, but that doesn't change the fact that currently PTRACE_CONT is
superior to group stop. You're suggesting to reverse the priority. I
can't see how that would be possible. I'm confused because that's a
_MUCH_ bigger change than the ones suggested here or in the whole
series. If we can change that, it's almost free for all, which I
dont't mind, but isn't consistent with how things have progressed upto
now.
We can introduce new interface which behaves that way but I don't
think we can reverse the priority without breaking a lot of userland
visible behaviors.
> I don't think I follow your logic and I certainly don't agree with
> your conclusion. It's simple: if a stop signal is actually delivered,
> then every thread stops. If one thread is traced and another is not,
> then the tracer can prevent a signal from being delivered to one
> thread and cannot prevent it from being delivered to another.
I suppose it depends on POV and I can see your point too.
> > > Once a group stop is complete, then probably the ideal is that
> > > PTRACE_CONT would not resume a thread until a real SIGCONT cleared
> > > the job control stop condition. But it's likely that existing
> > > ptrace users have expectations contrary to that, so we'll have to
> > > see.
> >
> > So, no, I don't think that would be possible or even desirable.
>
> Of course it's possible. We have to work out the entire web of
> assumptions and ramifications to be sure what's desireable given
> practical compatibility constraints. I think it's just plain obvious
> that it's the desireable thing in the abstract--that tracing stops and
> job control stops should be independent functions.
You'll have to show a lot more details on how to untangle "the entire
web of assumptions and ramifications" so that we can reverse the
current priority without causing noticeable behavior differences to
the existing users. I don't agree what you suggest is "plain
obviously desirable" but that's almost beside the point. I really
can't see how that would be realistically possible at this point.
So, can you please elaborate how to reverse that and at the same time
avoid breaking existing assumptions?
Thanks.
--
tejun
Hey, again.
On Wed, Feb 02, 2011 at 11:53:03AM +0100, Tejun Heo wrote:
> You'll have to show a lot more details on how to untangle "the entire
> web of assumptions and ramifications" so that we can reverse the
> current priority without causing noticeable behavior differences to
> the existing users. I don't agree what you suggest is "plain
> obviously desirable" but that's almost beside the point. I really
> can't see how that would be realistically possible at this point.
>
> So, can you please elaborate how to reverse that and at the same time
> avoid breaking existing assumptions?
I've been thinking about this and the more I think about it I don't
see how we can make this priority flipping without adversely affecting
the expect userland behavior.
For example, if a gdb traced task is instructed to participate in a
group stop and then hits a ptrace trap, it would have to participate
in the group stop as it enters ptrace trap, right? gdb's wait(2)
would complete indicating ptrace trap. After the user tells the task
to continue, the task shouldn't resume until SIGCONT is received;
however, at this point, there's no way for gdb to tell what's going on
with the tracee. It'll wait with its input prompt disabled until
someone sends SIGCONT from outside to the tracee. Please note that ^C
wouldn't do anything either in this state.
So, as I wrote before, I don't think we can change this at this point.
If ptrace behaved like that from the beginning, gdb would have behaved
differently and worked around those cases but that hasn't been the
case and I don't see any way we can flip the priority and get away
with it without impacting the current users significantly.
If I'm missing something, please enlighten me.
Thank you.
--
tejun