Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang afterPTRACE_ATTACH

[Roland McGrath]

> OK... Yes, perhaps PTRACE_{DETACH,CONT}(SIGCONT) should override
> SIGNAL_STOP_STOPPED too. This makes sense, and this connects to
> the problem with SIGNAL_STOP_DEQUEUED I mentioned above.

It's not at all clear this really does make sense.  I think this may
reflect a (common) misunderstanding of what the SIGCONT semantics are
(aside from ptrace).  Resuming the process is not the action of
delivering SIGCONT.  Rather, *generating* SIGCONT is what resumes the
process--it does so immediately, and regardless of whether SIGCONT is
blocked or ignored.  (It's also at generation-time that its other
magical semantics apply, of clearing all pending stop signals.)  
By the time SIGCONT is actually delivered, it is no different than
SIGWINCH.  (Conversely, with stop signals, generation time is when
the magic semantics of clearing pending SIGCONT occur, but the actual
stopping is indeed the delivery-time action.)

In ptrace, the report of a signal to the tracer is that it is about to
be delivered, not that it was just generated.  e.g., it won't be
reported immediately if it was blocked, only when it's unblocked and
being delivered.  Likewise, a signal given to PTRACE_CONT et al is not
generating a signal, it is continuing the delivery path of a signal.
So IMHO what makes most sense given what all the normal semantics are
is that PTRACE_CONT,SIGCONT does nothing magical, and generating a
fresh SIGCONT (i.e. kill) is the way you resume from job control stop.
If ptrace is involved, that will mean waking up long enough to dequeue
the SIGCONT and get a new ptrace stop for that.  (Things are a bit
more subtle if there are multiple threads.)


Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/