This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC] [PATCH 2.6.37-rc5-tip 8/20] 8: uprobes: mmap and fork hooks.
- From: Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>
- To: Peter Zijlstra <peterz at infradead dot org>
- Cc: Ingo Molnar <mingo at elte dot hu>, Steven Rostedt <rostedt at goodmis dot org>, Linux-mm <linux-mm at kvack dot org>, Arnaldo Carvalho de Melo <acme at infradead dot org>, Linus Torvalds <torvalds at linux-foundation dot org>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, Christoph Hellwig <hch at infradead dot org>, Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, Oleg Nesterov <oleg at redhat dot com>, LKML <linux-kernel at vger dot kernel dot org>, SystemTap <systemtap at sources dot redhat dot com>, Jim Keniston <jkenisto at linux dot vnet dot ibm dot com>, Frederic Weisbecker <fweisbec at gmail dot com>, Andi Kleen <andi at firstfloor dot org>, Andrew Morton <akpm at linux-foundation dot org>, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>
- Date: Wed, 26 Jan 2011 20:29:55 +0530
- Subject: Re: [RFC] [PATCH 2.6.37-rc5-tip 8/20] 8: uprobes: mmap and fork hooks.
- References: <20101216095714.23751.52601.sendpatchset@localhost6.localdomain6> <20101216095848.23751.73144.sendpatchset@localhost6.localdomain6> <1295957739.28776.717.camel@laptop> <20110126090346.GH19725@linux.vnet.ibm.com> <1296037239.28776.1149.camel@laptop>
- Reply-to: Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>
* Peter Zijlstra <peterz@infradead.org> [2011-01-26 11:20:39]:
> On Wed, 2011-01-26 at 14:33 +0530, Srikar Dronamraju wrote:
> >
> >
> > I actually dont like to release the write_lock and then reacquire it.
> > write_opcode, which is called thro install_uprobe, i.e to insert the
> > actual breakpoint instruction takes a read lock on the mmap_sem.
> > Hence uprobe_mmap gets called in context with write lock on mmap_sem
> > held, I had to release it before calling install_uprobe.
>
> Ah, right, so that's going to give you a head-ache ;-)
>
> The moment you release this mmap_sem, the map you're going to install
> the probe point in can go away.
>
> The only way to make this work seems to start by holding the mmap_sem
> for writing and make a breakpoint install function that assumes its
> taken and doesn't try to acquire it again.
>
Yes, this can be done.
I would have to do something like this in register_uprobe().
list_for_each_entry_safe(mm, tmpmm, &tmp_list, uprobes_list) {
down_read(&mm->map_sem);
if (!install_uprobe(mm, uprobe))
ret = 0;
up_read(&mm->map_sem);
list_del(&mm->uprobes_list);
mmput(mm);
}
Agree that this is much better than what we have now.