Q: drop PTRACE_SEIZE_DEVEL?

[Denys Vlasenko]

On 10/31/2012 04:37 PM, Dmitry V. Levin wrote:
> It seems to be working so far, but with annoying addition to the strace
> output:
> 
> $ strace true
> --- stopped by SIGSTOP ---
> --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=4096, si_uid=512} ---
> execve("/bin/true", ["true"], [/* 32 vars */]) = 0
> exit_group(0)                           = ?
> +++ exited with 0 +++
> 
> The child process is actually being stopped and continued, but are these
> technical details of USE_SEIZE implementation worth seeing?

We did not do any special magic before to hide initial setup.
It just so happens that with "good old" PTRACE_TRACEME
method of spawning the child we don't have any stray syscalls:

Child does
	ptrace(PTRACE_TRACEME);
	kill(pid, SIGSTOP);
Then parent goes into tracing waitpid loop,
sees SIGSTOP, knows to ignore it, issues PTRACE_SYSCALL(0),
which unpauses group-stop.
Then child falls into execve, and parent sees it.

Result: strace reports no "extra" syscalls before execve.

Whereas with SEIZE:

Child does
	kill(pid, SIGSTOP);
then parent waits for SIGSTOP to take effect on child,
then parent does PTRACE_SEIZE and PTRACE_INTERRUPT on child,
then parent sends SIGCONT to it,
Then parent goes into tracing waitpid loop,
then child goes through the motions of waking up from group-stop
and then falls into execve.

All of the above is done to make sure that child doesn't fall
into execve BEFORE we seize it.

Better ideas how to achieve that?
Basically: how to stop the child "cleanly"?

A possible alternative is to bite the bullet and suppress STOP/CONT
reports for this special child.
We already have infrastructure to do so (we suppress SIGSTOPs
from ATTACH on older kernels).

-- 
vda