lkml.org 
[lkml]   [2011]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/1] ptrace: make sure do_wait() won't hang after PTRACE_ATTACH
    On 02/21, Tejun Heo wrote:
    >
    > 1. The distinction between the first SIGSTOP trapping and the second
    > can only be reliably done by GETSIGINFO which in turn will put the
    > tracee into TASK_TRACED making the tracee ignore the future SIGCONT

    Yes, but please see below.

    > 2. Due to reparenting, wait(2) notifications (including the SIGCLDs)
    > don't get to the real parent at all.
    >
    > #2 just needs fixing.

    Yes.

    > That preciesly is what is being discussed. IIUC, Oleg and Roland are
    > saying that the tracee should enter group stop but not ptrace trap at
    > that point and then transition into ptrace trap on the first PTRACE
    > call.

    Actually I am not saying this (at least now, probably I did).

    Once again. We have the bug with arch_ptrace_stop_needed(), but lets
    ignore it to simplify the discussion.

    Suppose that the tracee calls do_signal_stop() and participates in the
    group stop. To me, it doesn't really matter (in the context of this
    discussion) if it stops in TASK_STOPPED or TASK_TRACED (and where it
    stops).

    However, I am starting to agree that TASK_TRACED looks more clean.

    What is important, I think ptrace should respect SIGNAL_STOP_STOPPED.
    IOW, when the tracee is group-stopped (TASK_STOPPED or TASK_TRACED,
    doesn't matter), ptrace_resume() should not wake it up, but merely
    do set_task_state(TASK_STATE) and make it resumeable by SIGCONT.

    Oleg.



    \
     
     \ /
      Last update: 2011-02-21 16:39    [W:5.116 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site