All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Masami Hiramatsu <mhiramat@redhat.com>,
	Mel Gorman <mel@csn.ul.ie>,
	Jim Keniston <jkenisto@linux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	"Frank Ch. Eigler" <fche@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Roland McGrath <roland@redhat.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH v1 7/10] Uprobes Implementation
Date: Tue, 23 Mar 2010 20:35:44 +0530	[thread overview]
Message-ID: <20100323150544.GA18323@in.ibm.com> (raw)
In-Reply-To: <1269352012.5109.22.camel@twins>

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

  parent reply	other threads:[~2010-03-23 15:06 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-20 14:24 [PATCH v1 0/10] Uprobes patches Srikar Dronamraju
2010-03-20 14:25 ` [PATCH v1 1/10] Move Macro W to insn.h Srikar Dronamraju
2010-03-20 15:50   ` Masami Hiramatsu
2010-03-22  6:24     ` Srikar Dronamraju
2010-03-22 14:11       ` Masami Hiramatsu
2010-03-20 14:25 ` [PATCH v1 2/10] Move replace_page() to mm/memory.c Srikar Dronamraju
2010-03-20 14:25 ` [PATCH v1 3/10] Enhance replace_page() to support pagecache Srikar Dronamraju
2010-03-20 14:25 ` [PATCH v1 4/10] User Space Breakpoint Assistance Layer Srikar Dronamraju
2010-03-23  1:40   ` Andrew Morton
2010-03-23  4:48     ` Randy Dunlap
2010-03-23 11:26     ` Srikar Dronamraju
2010-03-20 14:25 ` [PATCH v1 5/10] X86 details for user space breakpoint assistance Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 6/10] Slot allocation for Execution out of line Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 7/10] Uprobes Implementation Srikar Dronamraju
2010-03-23 11:01   ` Peter Zijlstra
2010-03-23 11:04     ` Peter Zijlstra
2010-03-23 12:23     ` Srikar Dronamraju
2010-03-23 13:46       ` Peter Zijlstra
2010-03-23 14:20         ` Masami Hiramatsu
2010-03-23 15:15           ` Peter Zijlstra
2010-03-23 17:36             ` Masami Hiramatsu
2010-03-24 10:22           ` Srikar Dronamraju
2010-03-23 15:05         ` Ananth N Mavinakayanahalli [this message]
2010-03-23 15:15           ` Peter Zijlstra
2010-03-23 15:26             ` Frank Ch. Eigler
2010-03-24  5:59             ` Ananth N Mavinakayanahalli
2010-03-24  7:58         ` Srikar Dronamraju
2010-03-24 13:00           ` Peter Zijlstra
2010-03-25  7:56             ` Srikar Dronamraju
2010-03-25  8:41             ` Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 8/10] X86 details for uprobes Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 9/10] Uprobes Documentation patch Srikar Dronamraju
2010-03-22  3:00   ` Randy Dunlap
2010-03-22  5:34     ` Srikar Dronamraju
2010-03-22 14:51       ` Randy Dunlap
2010-03-20 14:26 ` [PATCH v1 10/10] Uprobes samples Srikar Dronamraju
2010-03-23  1:38 ` [PATCH v1 0/10] Uprobes patches Andrew Morton
2010-03-23 10:55   ` Srikar Dronamraju

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100323150544.GA18323@in.ibm.com \
    --to=ananth@in.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=fche@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=hch@infradead.org \
    --cc=jkenisto@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    --cc=mhiramat@redhat.com \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=roland@redhat.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.