Re: Question regarding ptrace work for LInux v3.1

[Oleg Nesterov <oleg@redhat.com>]

On 03/21, Patrick Donnelly wrote:
>
> On Mon, Mar 21, 2016 at 3:07 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > Yes, exactly, you need to see the initial SIGSTOP or another event which
> > can be reported before it.
>
> Assuming a SIGSTOP is being silenced, is there anything we can do to
> forcibly start tracing syscalls? (For kernels without PTRACE_SEIZE)

No. Only PTRACE_SYSCALL can set TIF_SYSCALL_TRACE.

> >         case SIGSTOP:
> >         /* Black magic to get threads working on old Linux kernels... */
> >
> >         if(p->nsyscalls == 0) { /* stop before we begin running the process */
> >                 debug(D_DEBUG, "suppressing bootstrap SIGSTOP for %d",pid);
> >                 signum = 0; /* suppress delivery */
> >                 kill(p->pid,SIGCONT);
> >         }
> >         break;
> >
> > doesn't look right. Note that kill(pid,SIGCONT) affects the whole thread-
> > group. So if this kill() races with another thread doing clone() you can
> > hit the problem you described.
>
> You're right, that should be tkill! I will give that a try and report
> back if that solved the issue for our collaborators...

Ah, sorry, I should have mentioned this...

No, tkill() won't help. See prepare_signal(), SIGCONT always removes
the SIG_KERNEL_STOP_MASK signals from all threads, not matter if it was
sent by tkill() or kill().

Perhaps you should just remove this kill(SIGCONT) ?

tracer_continue(signr => 0) should equally suppress the delivery. To
clarify this won't be right too, but without PTRACE_SEIZE you simply
can't write the code which handles the stop/cont/etc events correctly
anyway...

> >> > But unless you use PTRACE_SEIZE the same can happen on v3.1 so it seems
> >> > there is something else.
> >>
> >> Okay, it might be that PTRACE_SEIZE fixes it.
> >
> > Yes, but iiuc you do not see this problem on v3.1 even with PTRACE_ATTACH?
>
> I have not tested on >v3.1 with PTRACE_ATTACH.

OK, thanks. So perhaps this is not v3.0-specific.

Oleg.