lkml.org 
[lkml]   [2011]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Proposal for ptrace improvements
    Hello, Roland.

    On Mon, Mar 07, 2011 at 12:43:46PM -0800, Roland McGrath wrote:
    > I've only skimmed through this whole thread, and I'm not going to try to
    > respond to all the details. I've lost interest in working in this area
    > and I don't plan to keep up with all the details any more. If you want
    > to reach me about kernel subjects after March 11, you'll need to use the
    > address <roland@hack.frob.com> as I won't be getting @redhat.com any more.

    I see. That's a pity. I'll keep the new address cc'd for related
    discussions.

    > I've said before more than once what I think are the important
    > principles about compatibility that ought to be maintained so as not to
    > break existing applications such as older versions of GDB and strace
    > (not to mention things less well-known and not publically visible, where
    > code has come to depend on details of ptrace behavior and there may not
    > even be anyone who really knows what they are depending on by now).
    > When real-world applications have worked in practice, even if the
    > behavior they were seeing was not pedantically reliable, they should not
    > be broken. Saner behavior can be provided when new requests or new
    > options are used, without breaking any old usage.

    The biggest changes the current ptrace users are gonna see are
    probably the ones from P1 and those are really corner cases - /proc
    state, behavior change visible only to other thread in a multithreaded
    debugger, and behavior change on back-to-back DETACH/ATTACH sequence
    on STOPPED task, which BTW was broken due to the extra
    wake_up_process() anyway.

    The biggest visible changes are the ones visible to a real parent
    while the children are being ptraced - most of the changes introduced
    by the recent P2 patchset. As noted there, I don't think
    conditionalizing those behavior changes is necessary given that the
    previous behavior was utterly broken. If somebody was actually
    depending on job control events being broken while ptraced, well, I
    primarily don't care, but if the problem actually is significant we'll
    think about workarounds.

    What I'm trying to say is that it's _ALWAYS_ about balances and trade
    offs. Sticking to some or any rules in fundamentalistic manner is a
    guaranteed way to horrible code base which is not only painful to
    develop and maintain but also will deliever a lot of WTF moments to
    its users too in the long run.

    So, let's balance it. Avoiding changes to the userland visible
    behaviors does have a lot of weight but its mass is NOT infinite.

    > A problem long identified with ptrace is that there is no way to attach
    > or detach without perturbing some of the user-visible behavior of the
    > traced threads. (There will always be some perturbation of the timing
    > of the thread's activities, but I mean factors other than that alone.)
    > Not overloading SIGSTOP is certainly an improvement. But, PTRACE_SEIZE
    > still has this problem in ways that the proposed PTRACE_ATTACH_NOSTOP
    > does not. For any passive tracing use (such as strace -p), you don't
    > actually want the thing to stop right away, you only want it to stop
    > when a new event happens (such as the next syscall entry/exit). The
    > PTRACE_SEIZE idea does not give the option of attaching without any
    > perturbation when you don't care about "seizing".
    >
    > Anything that works via interruption can perturb the user-visible
    > behavior of a system call already in progress. It would be nice if all
    > uninterruptible waits were truly reliably short and if all system call
    > paths supported syscall restart thoroughly so that they could be
    > interrupted with TIF_SIGPENDING and then restarted (a la SA_RESTART, or
    > its equivalent when there is no actual signal to handle) with no change
    > in semantics that userland can perceive (aside from timing). But it
    > just isn't so, and the way the kernel is organized makes it a difficult
    > and open-ended task (perhaps an impossible one for some cases) to try to
    > hunt down and fix every violation of that principle or to prevent
    > introductions of new violations in the future.

    But the only side effect would be that from signal_wake_up(). Our
    hibernation code does that to every single thread and naturally any
    signal delivery would also do that. It's something fundamentally
    ingrained into the design of the whole UNIX syscall mechanism. If we
    have undocumented behaviors there, we should fix and/or document them.
    I don't think ptrace is the right place to to incorporate workaround
    for such basic assumption.

    Also, ptrace is inherently a very heavy mechanism. It is intertwined
    with the whole process model and hijacks the target task and if you
    look at the provided operations, they aren't designed for light weight
    monitoring. The whole thing is designed to be heavy weight for dirty
    diddling.

    If someone is looking for completely transparent light weight
    monitoring, there is a much better fitting mechanism for that and it
    works frigging well and provides much better insight into what's going
    on with the system.

    Use tracing for tracing.

    > The other areas of concern with PTRACE_SEIZE are its robustness and
    > scalability. The whole point of this request is that the one ptrace
    > call does a full synchronization with the tracee, blocking until it has
    > been interrupted and stopped.

    No, I'm planning to do the waiting by wait(2), so there won't be
    latency, interruptible sleep or scalability (compared to the current
    attach) problems.

    > None of this means at all that PTRACE_SEIZE is worthless. But it is
    > certainly inadequate to meet the essential needs that motivate adding
    > new interfaces in this area. The PTRACE_ATTACH_NOSTOP idea I
    > suggested is far from complete for all the issues as well, but it is a
    > more versatile building block than PTRACE_SEIZE.

    I skipped a lot of parts but in general I think that you're trying to
    do too much with ptrace. ptrace has its place which is called
    debugging. Let's concentrate on that. It doesn't have to do every
    thing one can dream of. There are a lot better tools for most of
    them.

    Thanks.

    --
    tejun


    \
     
     \ /
      Last update: 2011-03-09 11:35    [W:3.935 / U:0.232 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site