Re: ptrace group stop signal number not reset before PTRACE_INTERRUPT is delivered?

[Oleg Nesterov <oleg@redhat.com>]

On 08/18, Keno Fischer wrote:
>
> On Thu, Aug 18, 2016 at 12:23 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > And you if you get PTRACE_EVENT_STOP and WSTOPSIG() == SIGTTIN after
> > PTRACE_INTERRUPT, you know that the tracee did not report the "new"
> > SIGTTIN.
>
> It seems possible to remember whether or not we injected a stopping
> signal and if so the next PTRACE_EVENT_STOP is a group-stop, otherwise
> a PTRACE_INTERRUPT stop. Currently what I do is the other way around,
> after issuing PTRACE_INTERRUPT, the first (if any) of the next two
> stops that is a PTRACE_EVENT_STOP get interpreted as a
> PTRACE_INTERRUPT stop. I haven't thought through this fully yet, so I
> can't give you a concrete example I worried about, it just seems
> fragile compared to just checking whether WSTOPSIG() == SIGTRAP.

Yes, I see your point. And to remind, I was confused too.

Perhaps we can add another THIS_SIGNAL_WAS_ALREADY_REPORTED bit, but
you know, I'd prefer to avoid another subtle change in behaviour. You
can never know if it is "safe" or not when it comes to ptrace, perhaps
some application already relies on this WSTOPSIG().

Oleg.