lkml.org 
[lkml]   [2011]   [Feb]   [14]   [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/14, Tejun Heo wrote:
    >
    > Hello, Denys.
    >
    > On Sun, Feb 13, 2011 at 11:25:55PM +0100, Denys Vlasenko wrote:
    >
    > > $ strace -tt sleep 30
    > > 23:02:15.619262 execve("/bin/sleep", ["sleep", "30"], [/* 30 vars */]) = 0
    > > ...
    > > 23:02:15.622112 nanosleep({30, 0}, NULL) = ? ERESTART_RESTARTBLOCK (To be restarted)
    > > 23:02:23.781165 --- SIGSTOP (Stopped (signal)) @ 0 (0) ---
    > > 23:02:23.781251 --- SIGSTOP (Stopped (signal)) @ 0 (0) ---
    > > (I forgot again why we see it twice. Another quirk I guess...)
    > > 23:02:23.781310 restart_syscall(<... resuming interrupted call ...>) = 0
    > > 23:02:45.622433 close(1) = 0
    > > 23:02:45.622743 close(2) = 0
    > > 23:02:45.622885 exit_group(0) = ?
    > >
    > > Why sleep didn't stop?
    > >
    > > Because PTRACE_SYSCALL brought the task out of group stop at once,
    > > even though strace did try hard to not do so:
    > >
    > > ptrace(PTRACE_SYSCALL, $PID, 0x1, SIGSTOP) <-- note SIGSTOP!
    > >
    > > PTRACE_CONT in this situation would do the same.
    >
    > This can be fixed by updating strace, right? strace can look at the
    > wait(2) exit code and if the tracee stopped for group stop, wait for
    > the tracee to be continued instead of issuing PTRACE_SYSCALL.

    Yes, in this particular case strace could be more clever.

    But. The tracee should react to SIGCONT after that, this means we
    shouldn't "delay" this stop or force the TASK_TRACED state.

    And note that in this case real_parent == debugger. Another case
    is more interesting, and this means we shouldn't delay or hide the
    notifications.

    (I just tried to summarize the previous discussion for Denys)

    > > Why gdb can't use SIGCONT instead of PTRACE_CONT, just like every
    > > other tool which needs to resume stopped tasks?
    >
    > Because that's how PTRACE_CONT behaved the whole time.

    Unfortunately, this is true.

    Oleg.



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