Re: [PATCH 08/10] ptrace: participate in group stop from ptrace_stop() iff the task is trapping for group stop

[Tejun Heo <tj@kernel.org>]

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