lkml.org 
[lkml]   [2016]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ptrace group stop signal number not reset before PTRACE_INTERRUPT is delivered?
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.

\
 
 \ /
  Last update: 2016-09-17 09:57    [W:0.317 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site