lkml.org 
[lkml]   [2011]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Ptrace documentation, draft #1
    Hello,

    I haven't read the whole thing yet but wanna comment on some.

    On Mon, May 16, 2011 at 05:31:22PM +0200, Oleg Nesterov wrote:
    > > Kernel delivers an extra SIGTRAP to tracee after execve syscall
    > > returns. This is an ordinary signal (similar to one generated by kill
    > > -TRAP), not a special kind of ptrace-stop. If PTRACE_O_TRACEEXEC option
    > > is in effect, a PTRACE_EVENT_EXEC-stop is generated instead.
    > >
    > > ??? can this SIGTRAP be distinguished from "real" user-generated SIGTRAP
    > > by looking at its siginfo?
    >
    > Afaics no. Well, except .si_pid shows that the signal was sent by the
    > tracing process to itself.

    If you do GETSIGINFO and look at si->si_code, user generated signals
    can't have non-zero value there (assuming SETSIGINFO doesn't allow
    uploading __SI_TRAP siginfo), so, if si->si_code contains SIGTRAP |
    PTRACE_EVENT_* << 8, I think it reliably identifies a specific trap.
    We probably want to add more PTRACE_EVENT_* so that each trap site can
    be identified uniquely. Note that the si_code is also returned as
    exit_code on wait(2) and combined with CLD_TRAPPED ptrace traps should
    be reliably identifiable.

    > > Note that restarting ptrace commands issued in ptrace-stops other than
    > > signal-delivery-stop do NOT inject a signal, even if sig is nonzero. No
    > > error is reported either. This is a cause of confusion among ptrace
    > > users.
    >
    > Yes. Except syscall entry/exit. But in this case SET_SIGINFO doesn't work
    > to add more confusion ;)

    Yeah, I hate these signal injections. Maybe we can remove these if
    SEIZED? Tracer might as well just do tkill(). I don't really see the
    point of the signal injection feature.

    > > Syscall-enter-stop and syscall-exit-stop are indistinguishable by
    > > tracer.
    >
    > Almost... at least on x86 rax = -ENOSYS in syscall-enter-stop.

    We can add PTRACE_EVENT_* values if SEIZED.

    > > ptrace(PTRACE_cmd, pid, 0, sig);
    > > where cmd is CONT, DETACH, SYSCALL, SINGLESTEP, SYSEMU,
    > > SYSEMU_SINGLESTEP. If tracee is in signal-delivery-stop, sig is the
    > > signal to be injected. Otherwise, sig is ignored.
    >
    > There is another special case. If the tracee single-stepps into the
    > signal handler, it reports SIGTRAP as if it recieved this SIGNAL.
    > But ptrace(PTRACE, ..., sig) doesn't inject after that.

    Ditto as PTRACE_SYSCALL. I think resuming from signal delivery trap
    should be the only place where @data means signo.

    > > Is signal injected if they were in signal-delivery-stop?
    >
    > Yes, The tracee resumes and handles the previously reported signal.

    Please note that this one really isn't an injection. It's just given
    a chance to either suppress or alter a signal which is being
    delivered. It's not creating a new one.

    Thank you.

    --
    tejun


    \
     
     \ /
      Last update: 2011-05-16 17:55    [W:0.026 / U:2.116 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site