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>]

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