lkml.org 
[lkml]   [2010]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v1 7/10] Uprobes Implementation
    On Tue, Mar 23, 2010 at 02:46:52PM +0100, Peter Zijlstra wrote:
    > On Tue, 2010-03-23 at 17:53 +0530, Srikar Dronamraju wrote:

    > > > I would still prefer to see something like:
    > > >
    > > > vma:offset, instead of tid:vaddr
    > > >
    > > > You want to probe a symbol in a DSO, filtering per-task comes after that
    > > > if desired.
    > > >
    >
    > > do you mean the user should be specifying 357c200000:74b80 to denote
    > > 000000357c274b80? or /lib64/libc.so.6:74b80
    > > And we trace all the process which have mapped this address?
    >
    > Well userspace would simply specify something like: /lib/libc.so:malloc,
    > we'd probably communicate that to the kernel using a filedesc and
    > offset.
    >
    > And yes, all processes that share that DSO, consumers can install
    > filters.

    Well, rewind back to 2006 to the first edition of uprobes; it had the
    'global' tracing feature like what you indicate here, although Andrew
    wouldn't want to be reminded of *how* that was done (hooking
    readpages()) :-)

    At the time, global tracing was vehemently vetoed in favour of a per-process
    approach.

    Now the question is, where the complexity needs to be.

    > > > Also, like we discussed in person, I think we can do away with the
    > > > handler_in_interrupt thing by letting the handler have an error return
    > > > value and doing something like:
    > > >
    > > > do_int3:
    > > >
    > > > uprobe = find_probe_point(addr);
    > > >
    > > > pagefault_disable();
    > > > err = uprobe->handler(uprobe, regs);
    > > > pagefault_enable();
    > > >
    > > > if (err == -EFAULT) {
    > > > /* set TIF flag and call the handler again from
    > > > task context */
    > > > }
    > > >
    > > > This should allow the handler to optimistically access memory from the
    > > > trap handler, but in case it does need to fault pages in we'll call it
    > > > from task context.
    > >
    > > Okay but what if the handler is coded to sleep.
    >
    > Don't do that ;-)
    >
    > What reason would you have to sleep from a int3 anyway? You want to log
    > bits and get on with life, right? The only interesting case is faulting
    > when some memory references you want are not currently available, and
    > that can be done as suggested.

    With the TIF method, you get to the probed process' task context in
    do_notify_resume(), and have sufficient flexibility for non-perf users,
    like gdb, 'cos what uprobes provides now, is close to what Tom Tromey
    asked for gdb's usage.

    Ananth


    \
     
     \ /
      Last update: 2010-03-23 16:09    [W:0.026 / U:59.580 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site