[lkml]   [2011]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 03/10] ptrace: implement PTRACE_SEIZE
    On 05/26, Tejun Heo wrote:
    > This reminded me of another issue. Currently we have two different
    > methods of reporting debug events. One is direct ptrace event trap,
    > which ends up in ptrace_stop() from the event site and thus is
    > synchronous. The other is sending SIGTRAP, literally. Besides the
    > usual problems related with implicitly sending signals, this also
    > makes it difficult to determine which event is happening exactly and
    > makes the whole signal delivery/injection thing much worse.
    > I suspect that all ptrace traps probably started as actual SIGTRAPs
    > and so all the events were reported via signal delivery path and so
    > the signal "injection" worked; however, now we have synchronous traps
    > and some SIGTRAPs, which are confusing and unreliable. I don't see
    > any reason why the events which are currently reported via SIGTRAPs
    > can't be reported via ptrace traps with unique PTRACE_EVENT_*. I
    > don't think we can take synchronous traps directly but we can schedule
    > them, record relevant information in preallocated area and just set
    > TIF_SIGPENDING and let the signal delivery path report the trap. This
    > will make all the events reliable and easily distinguishible and we
    > can fix the SIGTRAP signal problem. What do you think?

    Agreed, it would be nice to avoid SIGTRAP's. Although right now it is
    not clear to me how we can do this. The problematic case is the
    single-stepping, afaics. Say, int3. Even if the task is ptraced, we
    can't know why do we hit this insn. It is possible that this task
    auto-debugs itself and thus we should send SIGTRAP. Even the
    X86_EFLAGS_TF case is not that simple although we can probably take
    TIF_SINGLESTEP into account. But again, the task can set X86_EFLAGS_TF


     \ /
      Last update: 2011-05-26 17:01    [W:0.022 / U:2.524 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site