All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
	Linux-mm <linux-mm@kvack.org>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Christoph Hellwig <hch@infradead.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Oleg Nesterov <oleg@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	SystemTap <systemtap@sources.redhat.com>,
	Jim Keniston <jkenisto@linux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Andi Kleen <andi@firstfloor.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [RFC] [PATCH 2.6.37-rc5-tip 8/20]  8: uprobes: mmap and fork hooks.
Date: Wed, 26 Jan 2011 14:33:46 +0530	[thread overview]
Message-ID: <20110126090346.GH19725@linux.vnet.ibm.com> (raw)
In-Reply-To: <1295957739.28776.717.camel@laptop>

> On Thu, 2010-12-16 at 15:28 +0530, Srikar Dronamraju wrote:
> > +void uprobe_mmap(struct vm_area_struct *vma)
> > +{
> > +       struct list_head tmp_list;
> > +       struct uprobe *uprobe, *u;
> > +       struct mm_struct *mm;
> > +       struct inode *inode;
> > +
> > +       if (!valid_vma(vma))
> > +               return;
> > +
> > +       INIT_LIST_HEAD(&tmp_list);
> > +
> > +       /*
> > +        * The vma was just allocated and this routine gets called
> > +        * while holding write lock for mmap_sem.  Function called
> > +        * in context of a thread that has a reference to mm.
> > +        * Hence no need to take a reference to mm
> > +        */
> > +       mm = vma->vm_mm;
> > +       up_write(&mm->mmap_sem);
> 
> Are you very very sure its a good thing to simply drop the mmap_sem
> here? Also, why?
> 

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.

Another solution, I thought of was to pass a context to write_opcode to
say that map-sem is already acquired by us. But I am not sure that
idea is good enuf. 

> > +       mutex_lock(&uprobes_mutex);
> > +
> > +       inode = vma->vm_file->f_mapping->host;
> 
> Since you just dropped the mmap_sem, what's keeping that vma from going
> away?
> 

How about dropping the mmap_sem after add_to_temp_list and cachng the
vma->vm_start value before calling add_to_temp_list?

Or if you have better ideas, then that would be great.

> > +       add_to_temp_list(vma, inode, &tmp_list);
> > +
> > +       list_for_each_entry_safe(uprobe, u, &tmp_list, pending_list) {
> > +               mm->uprobes_vaddr = vma->vm_start + uprobe->offset;
> > +               install_uprobe(mm, uprobe);
> > +               list_del(&uprobe->pending_list);
> > +       }
> > +       mutex_unlock(&uprobes_mutex);
> > +       down_write(&mm->mmap_sem);
> > +} 
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
	Linux-mm <linux-mm@kvack.org>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Christoph Hellwig <hch@infradead.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Oleg Nesterov <oleg@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	SystemTap <systemtap@sources.redhat.com>,
	Jim Keniston <jkenisto@linux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Andi Kleen <andi@firstfloor.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [RFC] [PATCH 2.6.37-rc5-tip 8/20]  8: uprobes: mmap and fork hooks.
Date: Wed, 26 Jan 2011 14:33:46 +0530	[thread overview]
Message-ID: <20110126090346.GH19725@linux.vnet.ibm.com> (raw)
In-Reply-To: <1295957739.28776.717.camel@laptop>

> On Thu, 2010-12-16 at 15:28 +0530, Srikar Dronamraju wrote:
> > +void uprobe_mmap(struct vm_area_struct *vma)
> > +{
> > +       struct list_head tmp_list;
> > +       struct uprobe *uprobe, *u;
> > +       struct mm_struct *mm;
> > +       struct inode *inode;
> > +
> > +       if (!valid_vma(vma))
> > +               return;
> > +
> > +       INIT_LIST_HEAD(&tmp_list);
> > +
> > +       /*
> > +        * The vma was just allocated and this routine gets called
> > +        * while holding write lock for mmap_sem.  Function called
> > +        * in context of a thread that has a reference to mm.
> > +        * Hence no need to take a reference to mm
> > +        */
> > +       mm = vma->vm_mm;
> > +       up_write(&mm->mmap_sem);
> 
> Are you very very sure its a good thing to simply drop the mmap_sem
> here? Also, why?
> 

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.

Another solution, I thought of was to pass a context to write_opcode to
say that map-sem is already acquired by us. But I am not sure that
idea is good enuf. 

> > +       mutex_lock(&uprobes_mutex);
> > +
> > +       inode = vma->vm_file->f_mapping->host;
> 
> Since you just dropped the mmap_sem, what's keeping that vma from going
> away?
> 

How about dropping the mmap_sem after add_to_temp_list and cachng the
vma->vm_start value before calling add_to_temp_list?

Or if you have better ideas, then that would be great.

> > +       add_to_temp_list(vma, inode, &tmp_list);
> > +
> > +       list_for_each_entry_safe(uprobe, u, &tmp_list, pending_list) {
> > +               mm->uprobes_vaddr = vma->vm_start + uprobe->offset;
> > +               install_uprobe(mm, uprobe);
> > +               list_del(&uprobe->pending_list);
> > +       }
> > +       mutex_unlock(&uprobes_mutex);
> > +       down_write(&mm->mmap_sem);
> > +} 
> 
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-01-26  9:10 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-16  9:57 [RFC] [PATCH 2.6.37-rc5-tip 0/20] 0: Inode based uprobes Srikar Dronamraju
2010-12-16  9:57 ` [RFC] [PATCH 2.6.37-rc5-tip 1/20] 1: mm: Move replace_page() / write_protect_page() to mm/memory.c Srikar Dronamraju
2010-12-16  9:57 ` [RFC] [PATCH 2.6.37-rc5-tip 2/20] 2: X86 specific breakpoint definitions Srikar Dronamraju
2010-12-16  9:57 ` [RFC] [PATCH 2.6.37-rc5-tip 3/20] 3: uprobes: Breakground page replacement Srikar Dronamraju
2010-12-16  9:58 ` [RFC] [PATCH 2.6.37-rc5-tip 4/20] 4: uprobes: Adding and remove a uprobe in a rb tree Srikar Dronamraju
2011-01-25 12:15   ` Peter Zijlstra
2011-01-26  8:37     ` Srikar Dronamraju
2011-01-26  8:37       ` Srikar Dronamraju
2011-01-25 12:15   ` Peter Zijlstra
2011-01-26  8:41     ` Srikar Dronamraju
2011-01-26 10:13       ` Peter Zijlstra
2011-01-25 12:15   ` Peter Zijlstra
2011-01-26  8:38     ` Srikar Dronamraju
2011-01-25 13:56   ` Peter Zijlstra
2011-01-26  8:45     ` Srikar Dronamraju
2011-01-26 10:14       ` Peter Zijlstra
2011-01-26 15:18         ` Srikar Dronamraju
2011-01-26 15:33           ` Peter Zijlstra
2010-12-16  9:58 ` [RFC] [PATCH 2.6.37-rc5-tip 5/20] 5: Uprobes: register/unregister probes Srikar Dronamraju
2011-01-25 12:15   ` Peter Zijlstra
2011-01-26  7:55     ` Srikar Dronamraju
2011-01-26  7:55       ` Srikar Dronamraju
2011-01-26 10:11       ` Peter Zijlstra
2011-01-26 10:11         ` Peter Zijlstra
2011-01-26 15:30         ` Srikar Dronamraju
2011-01-26 15:30           ` Srikar Dronamraju
2011-01-26 15:45           ` Peter Zijlstra
2011-01-26 15:45             ` Peter Zijlstra
2011-01-26 16:56             ` Srikar Dronamraju
2011-01-26 16:56               ` Srikar Dronamraju
2011-01-26 17:12               ` Peter Zijlstra
2011-01-26 17:12                 ` Peter Zijlstra
2011-01-27 10:01                 ` Srikar Dronamraju
2011-01-27 10:01                   ` Srikar Dronamraju
2011-01-27 10:23                   ` Peter Zijlstra
2011-01-27 10:23                     ` Peter Zijlstra
2011-01-27 10:25                     ` Srikar Dronamraju
2011-01-27 10:25                       ` Srikar Dronamraju
2011-01-27 10:41                       ` Peter Zijlstra
2011-01-27 10:41                         ` Peter Zijlstra
2011-01-27 10:29                   ` Peter Zijlstra
2011-01-27 10:29                     ` Peter Zijlstra
2011-01-25 12:15   ` Peter Zijlstra
2011-01-26  7:47     ` Srikar Dronamraju
2011-01-26  7:47       ` Srikar Dronamraju
2011-01-26 10:10       ` Peter Zijlstra
2011-01-26 10:10         ` Peter Zijlstra
2010-12-16  9:58 ` [RFC] [PATCH 2.6.37-rc5-tip 6/20] 6: x86: analyze instruction and determine fixups Srikar Dronamraju
2010-12-16  9:58 ` [RFC] [PATCH 2.6.37-rc5-tip 7/20] 7: uprobes: store/restore original instruction Srikar Dronamraju
2011-01-25 12:15   ` Peter Zijlstra
2010-12-16  9:58 ` [RFC] [PATCH 2.6.37-rc5-tip 8/20] 8: uprobes: mmap and fork hooks Srikar Dronamraju
2011-01-25 12:15   ` Peter Zijlstra
2011-01-26  9:03     ` Srikar Dronamraju [this message]
2011-01-26  9:03       ` Srikar Dronamraju
2011-01-26 10:20       ` Peter Zijlstra
2011-01-26 10:20         ` Peter Zijlstra
2011-01-26 14:59         ` Srikar Dronamraju
2011-01-26 14:59           ` Srikar Dronamraju
2011-01-26 15:16           ` Peter Zijlstra
2011-01-26 15:16             ` Peter Zijlstra
2011-01-26 16:30             ` Srikar Dronamraju
2011-01-26 16:30               ` Srikar Dronamraju
2011-01-25 12:15   ` Peter Zijlstra
2011-01-25 20:05     ` Steven Rostedt
2011-01-26  9:06       ` Srikar Dronamraju
2011-01-27 17:03         ` Steven Rostedt
2011-01-28  4:53           ` Srikar Dronamraju
2011-01-28 13:57             ` Steven Rostedt
2011-01-28 14:28               ` Steven Rostedt
2011-01-28 14:46                 ` Srikar Dronamraju
2011-01-28 15:02                   ` Steven Rostedt
2011-01-26 15:09     ` Srikar Dronamraju
2011-01-26 15:09       ` Srikar Dronamraju
2011-01-26 15:20       ` Peter Zijlstra
2011-01-26 15:20         ` Peter Zijlstra
2010-12-16  9:58 ` [RFC] [PATCH 2.6.37-rc5-tip 9/20] 9: x86: architecture specific task information Srikar Dronamraju
2010-12-16  9:59 ` [RFC] [PATCH 2.6.37-rc5-tip 10/20] 10: uprobes: task specific information Srikar Dronamraju
2011-01-25 13:56   ` Peter Zijlstra
2011-01-25 18:38     ` Josh Stone
2011-01-25 18:55       ` Roland McGrath
2011-01-25 19:56       ` Peter Zijlstra
2010-12-16  9:59 ` [RFC] [PATCH 2.6.37-rc5-tip 11/20] 11: uprobes: slot allocation for uprobes Srikar Dronamraju
2011-01-25 13:56   ` Peter Zijlstra
2010-12-16  9:59 ` [RFC] [PATCH 2.6.37-rc5-tip 12/20] 12: uprobes: get the breakpoint address Srikar Dronamraju
2011-01-25 13:56   ` Peter Zijlstra
2010-12-16  9:59 ` [RFC] [PATCH 2.6.37-rc5-tip 13/20] 13: x86: x86 specific probe handling Srikar Dronamraju
2011-01-25 13:56   ` Peter Zijlstra
2011-01-27  9:40     ` Srikar Dronamraju
2011-01-27 10:22       ` Peter Zijlstra
2011-01-27 19:11         ` Roland McGrath
2011-01-28  4:57           ` Srikar Dronamraju
2011-01-28  6:23             ` Roland McGrath
2011-01-28  8:36               ` Peter Zijlstra
2011-01-28 18:23                 ` Roland McGrath
2010-12-16  9:59 ` [RFC] [PATCH 2.6.37-rc5-tip 14/20] 14: uprobes: Handing int3 and singlestep exception Srikar Dronamraju
2011-01-25 13:56   ` Peter Zijlstra
2011-01-25 13:56   ` Peter Zijlstra
2011-01-26  8:52     ` Srikar Dronamraju
2011-01-26  8:52       ` Srikar Dronamraju
2011-01-26 10:17       ` Peter Zijlstra
2011-01-26 10:17         ` Peter Zijlstra
2011-01-26 15:14         ` Srikar Dronamraju
2011-01-26 15:14           ` Srikar Dronamraju
2011-01-26 15:29           ` Peter Zijlstra
2011-01-26 15:29             ` Peter Zijlstra
2010-12-16 10:00 ` [RFC] [PATCH 2.6.37-rc5-tip 15/20] 15: x86: uprobes exception notifier for x86 Srikar Dronamraju
2010-12-16 10:00 ` [RFC] [PATCH 2.6.37-rc5-tip 16/20] 16: uprobes: register a notifier for uprobes Srikar Dronamraju
2011-01-25 13:56   ` Peter Zijlstra
2011-01-27  6:50     ` Srikar Dronamraju
2010-12-16 10:00 ` [RFC] [PATCH 2.6.37-rc5-tip 17/20] 17: uprobes: filter chain Srikar Dronamraju
2010-12-16 10:00 ` [RFC] [PATCH 2.6.37-rc5-tip 18/20] 18: uprobes: commonly used filters Srikar Dronamraju
2010-12-17 19:32   ` Valdis.Kletnieks
2010-12-18  3:04     ` Srikar Dronamraju
2010-12-16 10:00 ` [RFC] [PATCH 2.6.37-rc5-tip 19/20] 19: tracing: Extract out common code for kprobes/uprobes traceevents Srikar Dronamraju
2010-12-16 10:01 ` [RFC] [PATCH 2.6.37-rc5-tip 20/20] 20: tracing: uprobes trace_event interface Srikar Dronamraju
2010-12-16 10:07 ` [RFC] [PATCH 2.6.37-rc5-tip 0/20] 0: Inode based uprobes 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=20110126090346.GH19725@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=acme@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=andi@firstfloor.org \
    --cc=fweisbec@gmail.com \
    --cc=hch@infradead.org \
    --cc=jkenisto@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=systemtap@sources.redhat.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.