Re: [PATCH 2/4] ptrace: remove the extra wake_up_process() from ptrace_detach()

[Roland McGrath <roland@redhat.com>]

> On Mon, Jan 17, 2011 at 02:13:40PM -0800, Roland McGrath wrote:
> > Of course I agree that the current code is wrong here.  But I'm still not
> > at all clear on what practical compatibility problems it introduces.  This
> > change is OK if and only if we are really making the only area clean and
> > well-defined in the same release cycle.
> 
> I don't follow what you meant by the above sentence.  Can you please
> clarify a bit?

I think I meant to write "the whole area" rather than "the only area".
The point I meant to make is that removing this (wrong) wake-up entirely
should only be done when we are also thoroughly cleaning up and verifying
everything about the behavior of stopping/resuming in ptrace.  When we get
to a clear statement of what all the rules are and we really believe that
the new code matches those rules, then fine.  When we are still in the
quagmire, no change is better than an incremental change whose subtle
ramifications we can't clearly articulate.

> It's slightly more serious than that.  Calling wake_up_process()
> unconditionally can cause a quite serious failure.  It wakes up a
> process in any state and there are code paths which aren't prepared to
> be woken up unless certain conditions are met.  

I understand that.  But I don't recall having seen anyone cite an actual
scenario in the real world where it does something problematic.

> A safer choice can be changing it to wake up only tasks in interruptible
> sleep.

For ptrace-related purposes, wake_up_state(child, TASK_TRACED|TASK_STOPPED)
ought to cover anything that it is doing now that anything could reasonably
be relying on.

> I have very difficult time imagining what real user visible
> implication it would have in negative and noticeable manner, so while
> I do agree that we should proceed carefully, I think it would be
> better to take the chance and remove the erratic behavior.  We have
> release cycles and testing at multiple layers after all.  If we find
> out that it breaks something in serious manner, we can always revert.

"Difficult time imagining" and ptrace subtleties unfortunately often go
together.  I want to be sure we are doing something right, rather than just
being thoroughly unsure that we aren't doing something wrong.


Thanks,
Roland