Re: [PATCH] ptrace.2: Clarify PTRACE_INTERRUPT, PTRACE_LISTEN and group-stop behavior

[Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On 06/21, Denys Vlasenko wrote:
>
> On 06/20/2013 04:24 PM, Oleg Nesterov wrote:
> >> PTRACE_INTERRUPT (since Linux 3.4)
> >> Stop a tracee.
> >> [*MODIFIED TEXT->**] If the tracee is running in kernel space
> >> and PTRACE_SYSCALL is in effect, it will stop with syscall-exit-stop.
> >
> > Yes, but this looks a bit confusing. Or perhaps it is just me.
> >
> > IOW, it looks as if PTRACE_INTERRUPT has no effect in this case, the
> > tracee should report syscall-exit anyway. I do not know how to explain
> > this better...
>
> How about this?
>
> "If the tracee is running or sleeping in kernel space
> and PTRACE_SYSCALL is in effect, it will return from kernel
> and send syscall-exit-stop notification."

Yes, perhaps... but see below.

> I wonder whether we need to add that "The interrupted system call
> will be restarted when tracee is restarted" or this is obvious
> enough?

Yes... but once again, if we document the fact that PTRACE_INTERRUPT
sends the fake signal, then we do not need to specially mention restart
of syscall-exit-stop notification above.

Just we should explain that, unless the trace has another event to
report, this fake signal results in PTRACE_EVENT_STOP(SIGTRAP).

> > I think it makes sense to mention that a) PTRACE_INTERRUPT is only
> > valid if PTRACE_SEIZE was used, and b) this is the only request which
> > doesn't need the stopped tracee. (PTRACE_KILL should die)
>
> It is mentioned elsewhere on the man page.

Ah, OK, thanks.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html