lkml.org 
[lkml]   [2011]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 1/1] ptrace: make sure do_wait() won't hang after PTRACE_ATTACH
    Date
    > 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


    \
     
     \ /
      Last update: 2011-02-17 20:01    [W:4.053 / U:0.196 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site