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

[Tejun Heo <tj@kernel.org>]

Hello, Denys.

On Sun, Feb 13, 2011 at 11:25:55PM +0100, Denys Vlasenko wrote:
> But this "diddling behind group stop's back" is exactly the current
> problem with stop signals.

Maybe.  I don't necessarily agree but can see your point too but I
think more important part is that that's a behavior which is quite
noticeable from userland.

> Here I try to stop a ptraced process:
> 
> $ 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.

> You are saying that it is useful that gdb restarts group-stopped task
> with mere PTRACE_CONT. Above is a counter-example where it is anti-useful:
> I would muchly prefer strace to see task sit stopped until it gets SIGCONT
> (or some fatal signal).

This is more of an issue which can be improved in strace.  Sure,
changing the kernel to enforce group stop over ptrace would make this
case behave better but at the cost of breaking gdb.

> 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.  It can but
just hasn't needed to.

Thanks.

-- 
tejun