Re: [PATCH 1/3] ptrace_detach: the wrong wakeup breaks the ERESTARTxxx logic

[Roland McGrath <roland@redhat.com>]

> This is because ptrace_detach does:
> 
> 	if (!child->exit_state)
> 		wake_up_process(child);

I'm pretty sure that all these uses of wake_up_process were just blindly
copied from an original use in ptrace code (what's now ptrace_resume).
That original use just dates from the beforetime, the long long ago.
(I don't think it indicates any coherent original intent.)

It's many kinds of wrong.  It's also always been wrong in case of a
simultaneous SIGKILL that already woke the child, which has then blocked on
some mutex or semaphore or whatnot.  I don't know what the stated general
policy about spurious wakeups from schedule() is supposed to be.  Perhaps
to be pedantic, the sys_pause() code has been wrong to return without
checking signal_pending().

It's also about as wrong to use blind wake_up_process in ptrace_resume.
It ought to be wake_up_state(__TASK_TRACED|__TASK_STOPPED).

Frankly, I've always been afraid of strange cruft that might unexpectedly
turn out to rely on this "wrong" (unconditional) wake-up.  Probably the
things like that historically were all just to do with the stopped/traced
bookkeeping and would be covered by explicitly dealing with PTRACE_CONT vs
group stop et al.  But FWIW my reaction to fiddling the wake_up_process
bogons in the past has been, "Be afraid."


Thanks,
Roland