All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	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>,
	Jonathan Corbet <corbet@lwn.net>, Hugh Dickins <hughd@google.com>,
	Christoph Hellwig <hch@infradead.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andi Kleen <andi@firstfloor.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Jim Keniston <jkenisto@linux.vnet.ibm.com>,
	Roland McGrath <roland@hack.frob.com>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v5 3.1.0-rc4-tip 3/26]   Uprobes: register/unregister probes.
Date: Wed, 5 Oct 2011 22:34:20 +0530	[thread overview]
Message-ID: <20111005170420.GB28250@linux.vnet.ibm.com> (raw)
In-Reply-To: <20111003124640.GA25811@redhat.com>

* Oleg Nesterov <oleg@redhat.com> [2011-10-03 14:46:40]:

> On 09/20, Srikar Dronamraju wrote:
> >
> > +static struct vma_info *__find_next_vma_info(struct list_head *head,
> > +			loff_t offset, struct address_space *mapping,
> > +			struct vma_info *vi)
> > +{
> > +	struct prio_tree_iter iter;
> > +	struct vm_area_struct *vma;
> > +	struct vma_info *tmpvi;
> > +	loff_t vaddr;
> > +	unsigned long pgoff = offset >> PAGE_SHIFT;
> > +	int existing_vma;
> > +
> > +	vma_prio_tree_foreach(vma, &iter, &mapping->i_mmap, pgoff, pgoff) {
> > +		if (!vma || !valid_vma(vma))
> > +			return NULL;
> 
> !vma is not possible.
> 
> But I can't understand the !valid_vma(vma) check... We shouldn't return,
> we should ignore this vma and continue, no? Otherwise, I can't see how
> this can work if someone does, say, mmap(PROT_READ).

Agree. Infact I encountered this problem last week and had fixed it.
In mycase, I had mapped the file read and write while trying to insert
probes.
The changed code looks like this

	if (!vma) 
		return NULL;

	if (!valid_vma(vma))
		continue;

> 
> > +		existing_vma = 0;
> > +		vaddr = vma->vm_start + offset;
> > +		vaddr -= vma->vm_pgoff << PAGE_SHIFT;
> > +		list_for_each_entry(tmpvi, head, probe_list) {
> > +			if (tmpvi->mm == vma->vm_mm && tmpvi->vaddr == vaddr) {
> > +				existing_vma = 1;
> > +				break;
> > +			}
> > +		}
> > +		if (!existing_vma &&
> > +				atomic_inc_not_zero(&vma->vm_mm->mm_users)) {
> 
> This looks suspicious. If atomic_inc_not_zero() can fail, iow if we can
> see ->mm_users == 0, then why it is safe to touch this counter/memory?
> How we can know ->mm_count != 0 ?
> 
> I _think_ this is probably correct, ->mm_users == 0 means we are racing
> mmput(), ->i_mmap_mutex and the fact we found this vma guarantees that
> mmput() can't pass unlink_file_vma() and thus mmdrop() is not possible.
> May be needs a comment...
> 
> > +static struct vma_info *find_next_vma_info(struct list_head *head,
> > +			loff_t offset, struct address_space *mapping)
> > +{
> > +	struct vma_info *vi, *retvi;
> > +	vi = kzalloc(sizeof(struct vma_info), GFP_KERNEL);
> > +	if (!vi)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	INIT_LIST_HEAD(&vi->probe_list);
> 
> Looks unneeded.
> 
> > +	mutex_lock(&mapping->i_mmap_mutex);
> > +	retvi = __find_next_vma_info(head, offset, mapping, vi);
> > +	mutex_unlock(&mapping->i_mmap_mutex);
> 
> It is not clear why we can't race with mmap() after find_next_vma_info()
> returns NULL. I guess this is solved by the next patches.

I assume mmap_uprobe() solves this.

> 
> > +static int __register_uprobe(struct inode *inode, loff_t offset,
> > +				struct uprobe *uprobe)
> > +{
> > +	struct list_head try_list;
> > +	struct vm_area_struct *vma;
> > +	struct address_space *mapping;
> > +	struct vma_info *vi, *tmpvi;
> > +	struct mm_struct *mm;
> > +	int ret = 0;
> > +
> > +	mapping = inode->i_mapping;
> > +	INIT_LIST_HEAD(&try_list);
> > +	while ((vi = find_next_vma_info(&try_list, offset,
> > +							mapping)) != NULL) {
> > +		if (IS_ERR(vi)) {
> > +			ret = -ENOMEM;
> > +			break;
> > +		}
> > +		mm = vi->mm;
> > +		down_read(&mm->mmap_sem);
> > +		vma = find_vma(mm, (unsigned long) vi->vaddr);
> 
> But we can't trust find_vma? The original vma found by find_next_vma_info()
> could go away, at least we should verify vi->vaddr >= vm_start.

Yes, Peter has already pointed this out and I have fixed this too.
Should be fixed in the next iteration.

> 
> And worse, I do not understand how we can trust ->vaddr. Can't we race with
> sys_mremap() ?
> 
> > +static void __unregister_uprobe(struct inode *inode, loff_t offset,
> > +						struct uprobe *uprobe)
> > +{
> > +	struct list_head try_list;
> > +	struct address_space *mapping;
> > +	struct vma_info *vi, *tmpvi;
> > +	struct vm_area_struct *vma;
> > +	struct mm_struct *mm;
> > +
> > +	mapping = inode->i_mapping;
> > +	INIT_LIST_HEAD(&try_list);
> > +	while ((vi = find_next_vma_info(&try_list, offset,
> > +							mapping)) != NULL) {
> > +		if (IS_ERR(vi))
> > +			break;
> > +		mm = vi->mm;
> > +		down_read(&mm->mmap_sem);
> > +		vma = find_vma(mm, (unsigned long) vi->vaddr);
> 
> Same problems...
> 
> > +		if (!vma || !valid_vma(vma)) {
> > +			list_del(&vi->probe_list);
> > +			kfree(vi);
> > +			up_read(&mm->mmap_sem);
> > +			mmput(mm);
> > +			continue;
> > +		}
> 
> Not sure about !valid_vma() (and note that __find_next_vma_info does() this
> check too).
> 
> Suppose that register_uprobe() succeeds. After that unregister_ should work
> even if user-space does mprotect() which can make valid_vma() == F, right?
> 

Agree, If we want __find_next_vma_info() also to not worry about
valid_vma() while unregistering, then we would have to pass an
additional parameter.

> > +int register_uprobe(struct inode *inode, loff_t offset,
> > +				struct uprobe_consumer *consumer)
> > +{
> > +	struct uprobe *uprobe;
> > +	int ret = 0;
> > +
> > +	inode = igrab(inode);
> > +	if (!inode || !consumer || consumer->next)
> > +		return -EINVAL;
> > +
> > +	if (offset > inode->i_size)
> > +		return -EINVAL;
> 
> I guess this needs i_size_read().

Okay, 

> 
> And every "return" in register/unregister leaks something.

Yes, this has been pointed out by Stefan Hajnoczi earlier.
Have taken care of this.

> 
> > +
> > +	mutex_lock(&inode->i_mutex);
> > +	uprobe = alloc_uprobe(inode, offset);
> 
> Looks like, alloc_uprobe() doesn't need ->i_mutex.


Actually this was pointed out by you in the last review.
https://lkml.org/lkml/2011/7/24/91

So if we alloc_uprobe() without a lock and succeed but while we contend
on the lock , if the unregister can erase the uprobe from the rbtree.
We end up with a valid uprobe but that is no more in the rbtree. right?

> 
> OTOH,
> 
> > +void unregister_uprobe(struct inode *inode, loff_t offset,
> > +				struct uprobe_consumer *consumer)
> > +{
> > +	struct uprobe *uprobe;
> > +
> > +	inode = igrab(inode);
> > +	if (!inode || !consumer)
> > +		return;
> > +
> > +	if (offset > inode->i_size)
> > +		return;
> > +
> > +	uprobe = find_uprobe(inode, offset);
> > +	if (!uprobe)
> > +		return;
> > +
> > +	if (!del_consumer(uprobe, consumer)) {
> > +		put_uprobe(uprobe);
> > +		return;
> > +	}
> > +
> > +	mutex_lock(&inode->i_mutex);
> > +	if (!uprobe->consumers)
> > +		__unregister_uprobe(inode, offset, uprobe);
> 
> It seemes that del_consumer() should be done under ->i_mutex. If it
> removes the last consumer, we can race with register_uprobe() which
> takes ->i_mutex before us and does another __register_uprobe(), no?

We should still be okay, because we check for the consumers before we
do the actual unregister in form of __unregister_uprobe.
since the consumer is again added by the time we get the lock, we dont
do the actual unregistration and go as if del_consumer deleted one
consumer but not the last. 

or Am I missing something?

-- 
Thanks and Regards
Srikar

> 
> Oleg.
> 

WARNING: multiple messages have this Message-ID (diff)
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	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>,
	Jonathan Corbet <corbet@lwn.net>, Hugh Dickins <hughd@google.com>,
	Christoph Hellwig <hch@infradead.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andi Kleen <andi@firstfloor.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Jim Keniston <jkenisto@linux.vnet.ibm.com>,
	Roland McGrath <roland@hack.frob.com>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v5 3.1.0-rc4-tip 3/26]   Uprobes: register/unregister probes.
Date: Wed, 5 Oct 2011 22:34:20 +0530	[thread overview]
Message-ID: <20111005170420.GB28250@linux.vnet.ibm.com> (raw)
In-Reply-To: <20111003124640.GA25811@redhat.com>

* Oleg Nesterov <oleg@redhat.com> [2011-10-03 14:46:40]:

> On 09/20, Srikar Dronamraju wrote:
> >
> > +static struct vma_info *__find_next_vma_info(struct list_head *head,
> > +			loff_t offset, struct address_space *mapping,
> > +			struct vma_info *vi)
> > +{
> > +	struct prio_tree_iter iter;
> > +	struct vm_area_struct *vma;
> > +	struct vma_info *tmpvi;
> > +	loff_t vaddr;
> > +	unsigned long pgoff = offset >> PAGE_SHIFT;
> > +	int existing_vma;
> > +
> > +	vma_prio_tree_foreach(vma, &iter, &mapping->i_mmap, pgoff, pgoff) {
> > +		if (!vma || !valid_vma(vma))
> > +			return NULL;
> 
> !vma is not possible.
> 
> But I can't understand the !valid_vma(vma) check... We shouldn't return,
> we should ignore this vma and continue, no? Otherwise, I can't see how
> this can work if someone does, say, mmap(PROT_READ).

Agree. Infact I encountered this problem last week and had fixed it.
In mycase, I had mapped the file read and write while trying to insert
probes.
The changed code looks like this

	if (!vma) 
		return NULL;

	if (!valid_vma(vma))
		continue;

> 
> > +		existing_vma = 0;
> > +		vaddr = vma->vm_start + offset;
> > +		vaddr -= vma->vm_pgoff << PAGE_SHIFT;
> > +		list_for_each_entry(tmpvi, head, probe_list) {
> > +			if (tmpvi->mm == vma->vm_mm && tmpvi->vaddr == vaddr) {
> > +				existing_vma = 1;
> > +				break;
> > +			}
> > +		}
> > +		if (!existing_vma &&
> > +				atomic_inc_not_zero(&vma->vm_mm->mm_users)) {
> 
> This looks suspicious. If atomic_inc_not_zero() can fail, iow if we can
> see ->mm_users == 0, then why it is safe to touch this counter/memory?
> How we can know ->mm_count != 0 ?
> 
> I _think_ this is probably correct, ->mm_users == 0 means we are racing
> mmput(), ->i_mmap_mutex and the fact we found this vma guarantees that
> mmput() can't pass unlink_file_vma() and thus mmdrop() is not possible.
> May be needs a comment...
> 
> > +static struct vma_info *find_next_vma_info(struct list_head *head,
> > +			loff_t offset, struct address_space *mapping)
> > +{
> > +	struct vma_info *vi, *retvi;
> > +	vi = kzalloc(sizeof(struct vma_info), GFP_KERNEL);
> > +	if (!vi)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	INIT_LIST_HEAD(&vi->probe_list);
> 
> Looks unneeded.
> 
> > +	mutex_lock(&mapping->i_mmap_mutex);
> > +	retvi = __find_next_vma_info(head, offset, mapping, vi);
> > +	mutex_unlock(&mapping->i_mmap_mutex);
> 
> It is not clear why we can't race with mmap() after find_next_vma_info()
> returns NULL. I guess this is solved by the next patches.

I assume mmap_uprobe() solves this.

> 
> > +static int __register_uprobe(struct inode *inode, loff_t offset,
> > +				struct uprobe *uprobe)
> > +{
> > +	struct list_head try_list;
> > +	struct vm_area_struct *vma;
> > +	struct address_space *mapping;
> > +	struct vma_info *vi, *tmpvi;
> > +	struct mm_struct *mm;
> > +	int ret = 0;
> > +
> > +	mapping = inode->i_mapping;
> > +	INIT_LIST_HEAD(&try_list);
> > +	while ((vi = find_next_vma_info(&try_list, offset,
> > +							mapping)) != NULL) {
> > +		if (IS_ERR(vi)) {
> > +			ret = -ENOMEM;
> > +			break;
> > +		}
> > +		mm = vi->mm;
> > +		down_read(&mm->mmap_sem);
> > +		vma = find_vma(mm, (unsigned long) vi->vaddr);
> 
> But we can't trust find_vma? The original vma found by find_next_vma_info()
> could go away, at least we should verify vi->vaddr >= vm_start.

Yes, Peter has already pointed this out and I have fixed this too.
Should be fixed in the next iteration.

> 
> And worse, I do not understand how we can trust ->vaddr. Can't we race with
> sys_mremap() ?
> 
> > +static void __unregister_uprobe(struct inode *inode, loff_t offset,
> > +						struct uprobe *uprobe)
> > +{
> > +	struct list_head try_list;
> > +	struct address_space *mapping;
> > +	struct vma_info *vi, *tmpvi;
> > +	struct vm_area_struct *vma;
> > +	struct mm_struct *mm;
> > +
> > +	mapping = inode->i_mapping;
> > +	INIT_LIST_HEAD(&try_list);
> > +	while ((vi = find_next_vma_info(&try_list, offset,
> > +							mapping)) != NULL) {
> > +		if (IS_ERR(vi))
> > +			break;
> > +		mm = vi->mm;
> > +		down_read(&mm->mmap_sem);
> > +		vma = find_vma(mm, (unsigned long) vi->vaddr);
> 
> Same problems...
> 
> > +		if (!vma || !valid_vma(vma)) {
> > +			list_del(&vi->probe_list);
> > +			kfree(vi);
> > +			up_read(&mm->mmap_sem);
> > +			mmput(mm);
> > +			continue;
> > +		}
> 
> Not sure about !valid_vma() (and note that __find_next_vma_info does() this
> check too).
> 
> Suppose that register_uprobe() succeeds. After that unregister_ should work
> even if user-space does mprotect() which can make valid_vma() == F, right?
> 

Agree, If we want __find_next_vma_info() also to not worry about
valid_vma() while unregistering, then we would have to pass an
additional parameter.

> > +int register_uprobe(struct inode *inode, loff_t offset,
> > +				struct uprobe_consumer *consumer)
> > +{
> > +	struct uprobe *uprobe;
> > +	int ret = 0;
> > +
> > +	inode = igrab(inode);
> > +	if (!inode || !consumer || consumer->next)
> > +		return -EINVAL;
> > +
> > +	if (offset > inode->i_size)
> > +		return -EINVAL;
> 
> I guess this needs i_size_read().

Okay, 

> 
> And every "return" in register/unregister leaks something.

Yes, this has been pointed out by Stefan Hajnoczi earlier.
Have taken care of this.

> 
> > +
> > +	mutex_lock(&inode->i_mutex);
> > +	uprobe = alloc_uprobe(inode, offset);
> 
> Looks like, alloc_uprobe() doesn't need ->i_mutex.


Actually this was pointed out by you in the last review.
https://lkml.org/lkml/2011/7/24/91

So if we alloc_uprobe() without a lock and succeed but while we contend
on the lock , if the unregister can erase the uprobe from the rbtree.
We end up with a valid uprobe but that is no more in the rbtree. right?

> 
> OTOH,
> 
> > +void unregister_uprobe(struct inode *inode, loff_t offset,
> > +				struct uprobe_consumer *consumer)
> > +{
> > +	struct uprobe *uprobe;
> > +
> > +	inode = igrab(inode);
> > +	if (!inode || !consumer)
> > +		return;
> > +
> > +	if (offset > inode->i_size)
> > +		return;
> > +
> > +	uprobe = find_uprobe(inode, offset);
> > +	if (!uprobe)
> > +		return;
> > +
> > +	if (!del_consumer(uprobe, consumer)) {
> > +		put_uprobe(uprobe);
> > +		return;
> > +	}
> > +
> > +	mutex_lock(&inode->i_mutex);
> > +	if (!uprobe->consumers)
> > +		__unregister_uprobe(inode, offset, uprobe);
> 
> It seemes that del_consumer() should be done under ->i_mutex. If it
> removes the last consumer, we can race with register_uprobe() which
> takes ->i_mutex before us and does another __register_uprobe(), no?

We should still be okay, because we check for the consumers before we
do the actual unregister in form of __unregister_uprobe.
since the consumer is again added by the time we get the lock, we dont
do the actual unregistration and go as if del_consumer deleted one
consumer but not the last. 

or Am I missing something?

-- 
Thanks and Regards
Srikar

> 
> Oleg.
> 

--
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 internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-10-05 17:24 UTC|newest]

Thread overview: 330+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-20 11:59 [PATCH v5 3.1.0-rc4-tip 0/26] Uprobes patchset with perf probe support Srikar Dronamraju
2011-09-20 11:59 ` Srikar Dronamraju
2011-09-20 11:59 ` [PATCH v5 3.1.0-rc4-tip 1/26] uprobes: Auxillary routines to insert, find, delete uprobes Srikar Dronamraju
2011-09-20 11:59   ` Srikar Dronamraju
2011-09-20 15:42   ` Stefan Hajnoczi
2011-09-20 15:42     ` Stefan Hajnoczi
2011-09-26 11:18     ` Peter Zijlstra
2011-09-26 11:18       ` Peter Zijlstra
2011-09-26 11:59       ` Srikar Dronamraju
2011-09-26 11:59         ` Srikar Dronamraju
2011-09-26 11:18   ` Peter Zijlstra
2011-09-26 11:18     ` Peter Zijlstra
2011-09-26 12:02     ` Srikar Dronamraju
2011-09-26 12:02       ` Srikar Dronamraju
2011-09-26 13:35   ` Peter Zijlstra
2011-09-26 13:35     ` Peter Zijlstra
2011-09-26 16:19     ` Srikar Dronamraju
2011-09-26 16:19       ` Srikar Dronamraju
2011-09-20 12:00 ` [PATCH v5 3.1.0-rc4-tip 2/26] Uprobes: Allow multiple consumers for an uprobe Srikar Dronamraju
2011-09-20 12:00   ` Srikar Dronamraju
2011-09-26 12:29   ` Peter Zijlstra
2011-09-26 12:29     ` Peter Zijlstra
2011-09-20 12:00 ` [PATCH v5 3.1.0-rc4-tip 3/26] Uprobes: register/unregister probes Srikar Dronamraju
2011-09-20 12:00   ` Srikar Dronamraju
2011-09-20 16:50   ` Stefan Hajnoczi
2011-09-20 16:50     ` Stefan Hajnoczi
2011-09-21  4:07     ` Srikar Dronamraju
2011-09-21  4:07       ` Srikar Dronamraju
2011-09-26 13:15   ` Peter Zijlstra
2011-09-26 13:15     ` Peter Zijlstra
2011-09-26 13:23     ` Srikar Dronamraju
2011-09-26 13:23       ` Srikar Dronamraju
2011-10-03 12:46   ` Oleg Nesterov
2011-10-03 12:46     ` Oleg Nesterov
2011-10-05 17:04     ` Srikar Dronamraju [this message]
2011-10-05 17:04       ` Srikar Dronamraju
2011-10-05 18:50       ` Oleg Nesterov
2011-10-05 18:50         ` Oleg Nesterov
2011-10-06  6:51         ` Srikar Dronamraju
2011-10-06  6:51           ` Srikar Dronamraju
2011-10-07 17:03           ` Oleg Nesterov
2011-10-07 17:03             ` Oleg Nesterov
2011-09-20 12:00 ` [PATCH v5 3.1.0-rc4-tip 4/26] uprobes: Define hooks for mmap/munmap Srikar Dronamraju
2011-09-20 12:00   ` Srikar Dronamraju
2011-09-20 17:03   ` Stefan Hajnoczi
2011-09-20 17:03     ` Stefan Hajnoczi
2011-09-21  4:03     ` Srikar Dronamraju
2011-09-21  4:03       ` Srikar Dronamraju
2011-09-26 13:53   ` Peter Zijlstra
2011-09-26 13:53     ` Peter Zijlstra
2011-09-26 15:44     ` Srikar Dronamraju
2011-09-26 15:44       ` Srikar Dronamraju
2011-09-27 11:37       ` Peter Zijlstra
2011-09-27 11:37         ` Peter Zijlstra
2011-09-27 13:08         ` Srikar Dronamraju
2011-09-27 13:08           ` Srikar Dronamraju
2011-09-27 11:41       ` Peter Zijlstra
2011-09-27 11:41         ` Peter Zijlstra
2011-09-27 12:59         ` Srikar Dronamraju
2011-09-27 12:59           ` Srikar Dronamraju
2011-09-27 11:42       ` Peter Zijlstra
2011-09-27 11:42         ` Peter Zijlstra
2011-10-03 13:37   ` Oleg Nesterov
2011-10-03 13:37     ` Oleg Nesterov
2011-10-06 11:05     ` Srikar Dronamraju
2011-10-06 11:05       ` Srikar Dronamraju
2011-10-07 17:36       ` Oleg Nesterov
2011-10-07 17:36         ` Oleg Nesterov
2011-10-10 12:31         ` Srikar Dronamraju
2011-10-10 12:31           ` Srikar Dronamraju
2011-09-20 12:00 ` [PATCH v5 3.1.0-rc4-tip 5/26] Uprobes: copy of the original instruction Srikar Dronamraju
2011-09-20 12:00   ` Srikar Dronamraju
2011-10-03 16:29   ` Oleg Nesterov
2011-10-03 16:29     ` Oleg Nesterov
2011-10-05 10:52     ` Srikar Dronamraju
2011-10-05 10:52       ` Srikar Dronamraju
2011-10-05 15:11       ` Oleg Nesterov
2011-10-05 15:11         ` Oleg Nesterov
2011-10-05 16:09     ` Srikar Dronamraju
2011-10-05 16:09       ` Srikar Dronamraju
2011-10-05 17:53       ` Oleg Nesterov
2011-10-05 17:53         ` Oleg Nesterov
2011-09-20 12:01 ` [PATCH v5 3.1.0-rc4-tip 6/26] Uprobes: define fixups Srikar Dronamraju
2011-09-20 12:01   ` Srikar Dronamraju
2011-09-20 12:01 ` [PATCH v5 3.1.0-rc4-tip 7/26] Uprobes: uprobes arch info Srikar Dronamraju
2011-09-20 12:01   ` Srikar Dronamraju
2011-09-20 12:01 ` [PATCH v5 3.1.0-rc4-tip 8/26] x86: analyze instruction and determine fixups Srikar Dronamraju
2011-09-20 12:01   ` Srikar Dronamraju
2011-09-20 17:13   ` Stefan Hajnoczi
2011-09-20 17:13     ` Stefan Hajnoczi
2011-09-20 18:12     ` Christoph Hellwig
2011-09-20 18:12       ` Christoph Hellwig
2011-09-20 20:53       ` Stefan Hajnoczi
2011-09-20 20:53         ` Stefan Hajnoczi
2011-09-23 11:53         ` Masami Hiramatsu
2011-09-23 11:53           ` Masami Hiramatsu
2011-09-23 16:51           ` Stefan Hajnoczi
2011-09-23 16:51             ` Stefan Hajnoczi
2011-09-26 19:59             ` Josh Stone
2011-09-26 19:59               ` Josh Stone
2011-09-27  1:32               ` Masami Hiramatsu
2011-09-27  2:59                 ` Josh Stone
2011-09-27  2:59                   ` Josh Stone
2011-09-27  7:08               ` Stefan Hajnoczi
2011-09-26 18:30         ` Mark Wielaard
2011-09-22  1:05   ` Josh Stone
2011-09-22  1:05     ` Josh Stone
2011-10-06 23:58     ` [PATCH] x86: Make variable_test_bit reference all of *addr Josh Stone
2011-10-07  1:37       ` hpanvin@gmail.com
2011-10-07  2:02         ` Andi Kleen
2011-10-07  2:50           ` Josh Stone
2011-10-07  3:12             ` hpanvin@gmail.com
2011-10-07  3:30               ` Andi Kleen
2011-10-07  4:35             ` Masami Hiramatsu
2011-10-07  4:55             ` Masami Hiramatsu
2011-10-18  1:00               ` [PATCH] x86: Make kprobes' twobyte_is_boostable volatile Josh Stone
2011-10-18  1:21                 ` Masami Hiramatsu
2011-10-07  3:13           ` [PATCH] x86: Make variable_test_bit reference all of *addr hpanvin@gmail.com
2011-10-05 15:48   ` [PATCH v5 3.1.0-rc4-tip 8/26] x86: analyze instruction and determine fixups Oleg Nesterov
2011-10-05 15:48     ` Oleg Nesterov
2011-10-05 16:12     ` Srikar Dronamraju
2011-10-05 16:12       ` Srikar Dronamraju
2011-09-20 12:01 ` [PATCH v5 3.1.0-rc4-tip 9/26] Uprobes: Background page replacement Srikar Dronamraju
2011-09-20 12:01   ` Srikar Dronamraju
2011-10-05 16:19   ` Oleg Nesterov
2011-10-05 16:19     ` Oleg Nesterov
2011-10-06  6:53     ` Srikar Dronamraju
2011-10-06  6:53       ` Srikar Dronamraju
2011-09-20 12:01 ` [PATCH v5 3.1.0-rc4-tip 10/26] x86: Set instruction pointer Srikar Dronamraju
2011-09-20 12:01   ` Srikar Dronamraju
2011-10-05 16:29   ` Oleg Nesterov
2011-10-05 16:29     ` Oleg Nesterov
2011-09-20 12:02 ` [PATCH v5 3.1.0-rc4-tip 11/26] x86: Introduce TIF_UPROBE FLAG Srikar Dronamraju
2011-09-20 12:02   ` Srikar Dronamraju
2011-09-20 12:02 ` [PATCH v5 3.1.0-rc4-tip 12/26] Uprobes: Handle breakpoint and Singlestep Srikar Dronamraju
2011-09-20 12:02   ` Srikar Dronamraju
2011-09-26 13:59   ` Peter Zijlstra
2011-09-26 13:59     ` Peter Zijlstra
2011-09-26 16:01     ` Srikar Dronamraju
2011-09-26 16:01       ` Srikar Dronamraju
2011-09-26 16:25       ` Peter Zijlstra
2011-09-26 16:25         ` Peter Zijlstra
2011-10-05 17:48         ` Oleg Nesterov
2011-10-05 17:48           ` Oleg Nesterov
2011-09-26 14:02   ` Peter Zijlstra
2011-09-26 14:02     ` Peter Zijlstra
2011-10-07 18:28   ` Oleg Nesterov
2011-10-07 18:28     ` Oleg Nesterov
2011-10-09 13:31     ` Oleg Nesterov
2011-10-09 13:31       ` Oleg Nesterov
2011-09-20 12:02 ` [PATCH v5 3.1.0-rc4-tip 13/26] x86: define a x86 specific exception notifier Srikar Dronamraju
2011-09-20 12:02   ` Srikar Dronamraju
2011-09-26 14:19   ` Peter Zijlstra
2011-09-26 14:19     ` Peter Zijlstra
2011-09-26 15:52     ` Srikar Dronamraju
2011-09-26 15:52       ` Srikar Dronamraju
2011-09-27 11:46       ` Peter Zijlstra
2011-09-27 11:46         ` Peter Zijlstra
2011-10-07 18:31   ` Oleg Nesterov
2011-10-07 18:31     ` Oleg Nesterov
2011-09-20 12:02 ` [PATCH v5 3.1.0-rc4-tip 14/26] uprobe: register " Srikar Dronamraju
2011-09-20 12:02   ` Srikar Dronamraju
2011-09-20 12:03 ` [PATCH v5 3.1.0-rc4-tip 15/26] x86: Define x86_64 specific uprobe_task_arch_info structure Srikar Dronamraju
2011-09-20 12:03   ` Srikar Dronamraju
2011-09-20 12:03 ` [PATCH v5 3.1.0-rc4-tip 16/26] uprobes: Introduce " Srikar Dronamraju
2011-09-20 12:03   ` Srikar Dronamraju
2011-09-20 12:03 ` [PATCH v5 3.1.0-rc4-tip 17/26] x86: arch specific hooks for pre/post singlestep handling Srikar Dronamraju
2011-09-20 12:03   ` Srikar Dronamraju
2011-09-26 14:23   ` Peter Zijlstra
2011-09-26 14:23     ` Peter Zijlstra
2011-09-26 16:34     ` Srikar Dronamraju
2011-09-26 16:34       ` Srikar Dronamraju
2011-09-27 11:44       ` Peter Zijlstra
2011-09-27 11:44         ` Peter Zijlstra
2011-09-20 12:03 ` [PATCH v5 3.1.0-rc4-tip 18/26] uprobes: slot allocation Srikar Dronamraju
2011-09-20 12:03   ` Srikar Dronamraju
2011-09-27 11:49   ` Peter Zijlstra
2011-09-27 11:49     ` Peter Zijlstra
2011-09-27 12:32     ` Srikar Dronamraju
2011-09-27 12:32       ` Srikar Dronamraju
2011-09-27 12:59       ` Peter Zijlstra
2011-09-27 12:59         ` Peter Zijlstra
2011-09-27 12:18   ` Peter Zijlstra
2011-09-27 12:18     ` Peter Zijlstra
2011-09-27 12:45     ` Srikar Dronamraju
2011-09-27 12:45       ` Srikar Dronamraju
2011-09-27 12:36   ` Peter Zijlstra
2011-09-27 12:36     ` Peter Zijlstra
2011-09-27 12:37   ` Peter Zijlstra
2011-09-27 12:37     ` Peter Zijlstra
2011-09-27 12:50     ` Srikar Dronamraju
2011-09-27 12:50       ` Srikar Dronamraju
2011-09-27 12:50   ` Peter Zijlstra
2011-09-27 12:50     ` Peter Zijlstra
2011-09-27 12:55   ` Peter Zijlstra
2011-09-27 12:55     ` Peter Zijlstra
2011-10-07 18:37   ` Oleg Nesterov
2011-10-07 18:37     ` Oleg Nesterov
2011-10-09 11:47     ` Srikar Dronamraju
2011-10-09 11:47       ` Srikar Dronamraju
2011-09-20 12:03 ` [PATCH v5 3.1.0-rc4-tip 19/26] tracing: Extract out common code for kprobes/uprobes traceevents Srikar Dronamraju
2011-09-20 12:03   ` Srikar Dronamraju
2011-09-28  5:04   ` Masami Hiramatsu
2011-09-28  5:04     ` Masami Hiramatsu
2011-09-20 12:04 ` [PATCH v5 3.1.0-rc4-tip 20/26] tracing: uprobes trace_event interface Srikar Dronamraju
2011-09-20 12:04   ` Srikar Dronamraju
2011-09-20 12:04 ` [PATCH v5 3.1.0-rc4-tip 21/26] tracing: uprobes Documentation Srikar Dronamraju
2011-09-20 12:04   ` Srikar Dronamraju
2011-09-20 12:04 ` [PATCH v5 3.1.0-rc4-tip 22/26] perf: rename target_module to target Srikar Dronamraju
2011-09-20 12:04   ` Srikar Dronamraju
2011-09-20 12:04 ` [PATCH v5 3.1.0-rc4-tip 23/26] perf: perf interface for uprobes Srikar Dronamraju
2011-09-20 12:04   ` Srikar Dronamraju
2011-09-20 12:04 ` [PATCH v5 3.1.0-rc4-tip 24/26] perf: show possible probes in a given executable file or library Srikar Dronamraju
2011-09-20 12:04   ` Srikar Dronamraju
2011-09-20 12:05 ` [PATCH v5 3.1.0-rc4-tip 25/26] perf: Documentation for perf uprobes Srikar Dronamraju
2011-09-20 12:05   ` Srikar Dronamraju
2011-09-28  9:20   ` Masami Hiramatsu
2011-09-28  9:20     ` Masami Hiramatsu
2011-09-20 12:05 ` [PATCH v5 3.1.0-rc4-tip 26/26] uprobes: queue signals while thread is singlestepping Srikar Dronamraju
2011-09-20 12:05   ` Srikar Dronamraju
2011-09-27 13:03   ` Peter Zijlstra
2011-09-27 13:03     ` Peter Zijlstra
2011-09-27 13:12     ` Srikar Dronamraju
2011-09-27 13:12       ` Srikar Dronamraju
2011-10-05 18:01       ` Oleg Nesterov
2011-10-05 18:01         ` Oleg Nesterov
2011-10-06  5:47         ` Srikar Dronamraju
2011-10-06  5:47           ` Srikar Dronamraju
2011-10-07 16:58           ` Oleg Nesterov
2011-10-07 16:58             ` Oleg Nesterov
2011-10-10 12:25             ` Srikar Dronamraju
2011-10-10 12:25               ` Srikar Dronamraju
2011-10-10 18:25               ` Oleg Nesterov
2011-10-10 18:25                 ` Oleg Nesterov
2011-10-11 17:24                 ` Oleg Nesterov
2011-10-11 17:24                   ` Oleg Nesterov
2011-10-11 17:38                   ` Srikar Dronamraju
2011-10-11 17:38                     ` Srikar Dronamraju
2011-10-11 17:26                 ` Srikar Dronamraju
2011-10-11 17:26                   ` Srikar Dronamraju
2011-10-11 18:56                   ` Oleg Nesterov
2011-10-11 18:56                     ` Oleg Nesterov
2011-10-12 12:01                     ` Srikar Dronamraju
2011-10-12 12:01                       ` Srikar Dronamraju
2011-10-12 19:34                       ` Oleg Nesterov
2011-10-12 19:34                         ` Oleg Nesterov
2011-10-12 19:59                   ` Oleg Nesterov
2011-10-12 19:59                     ` Oleg Nesterov
2011-09-20 13:34 ` [PATCH v5 3.1.0-rc4-tip 0/26] Uprobes patchset with perf probe support Christoph Hellwig
2011-09-20 13:34   ` Christoph Hellwig
2011-09-20 14:12   ` Srikar Dronamraju
2011-09-20 14:12     ` Srikar Dronamraju
2011-09-20 14:28     ` Christoph Hellwig
2011-09-20 14:28       ` Christoph Hellwig
2011-09-20 15:19       ` Srikar Dronamraju
2011-09-20 15:19         ` Srikar Dronamraju
2011-10-15 19:00 ` [PATCH 0/X] (Was: Uprobes patchset with perf probe support) Oleg Nesterov
2011-10-15 19:00   ` Oleg Nesterov
2011-10-15 19:00   ` [PATCH 1/X] uprobes: write_opcode: the new page needs PG_uptodate Oleg Nesterov
2011-10-15 19:00     ` Oleg Nesterov
2011-10-17 10:59     ` Srikar Dronamraju
2011-10-17 10:59       ` Srikar Dronamraju
2011-10-15 19:00   ` [PATCH 2/X] uprobes: write_opcode() needs put_page(new_page) unconditionally Oleg Nesterov
2011-10-15 19:00     ` Oleg Nesterov
2011-10-18 16:47     ` Srikar Dronamraju
2011-10-18 16:47       ` Srikar Dronamraju
2011-10-15 19:01   ` [PATCH 3/X] uprobes: xol_add_vma: fix ->uprobes_xol_area initialization Oleg Nesterov
2011-10-15 19:01     ` Oleg Nesterov
2011-10-15 19:01   ` [PATCH 4/X] uprobes: xol_add_vma: misc cleanups Oleg Nesterov
2011-10-15 19:01     ` Oleg Nesterov
2011-10-15 19:01   ` [PATCH 5/X] uprobes: xol_alloc_area() needs memory barriers Oleg Nesterov
2011-10-15 19:01     ` Oleg Nesterov
2011-10-16 16:13   ` [PATCH 6/X] uprobes: reimplement xol_add_vma() via install_special_mapping() Oleg Nesterov
2011-10-16 16:13     ` Oleg Nesterov
2011-10-17 10:50     ` Srikar Dronamraju
2011-10-17 10:50       ` Srikar Dronamraju
2011-10-17 13:34       ` Stephen Smalley
2011-10-17 13:34         ` Stephen Smalley
2011-10-17 18:55         ` Oleg Nesterov
2011-10-17 18:55           ` Oleg Nesterov
2011-10-16 16:14   ` [PATCH 7/X] uprobes: xol_add_vma: simply use TASK_SIZE as a hint Oleg Nesterov
2011-10-16 16:14     ` Oleg Nesterov
2011-10-19 21:51   ` [PATCH 8-14/X] (Was: Uprobes patchset with perf probe support) Oleg Nesterov
2011-10-19 21:51     ` Oleg Nesterov
2011-10-19 21:52     ` [PATCH 8/X] uprobes: kill sstep_complete() Oleg Nesterov
2011-10-19 21:52       ` Oleg Nesterov
2011-10-19 21:52     ` [PATCH 9/X] uprobes: introduce UTASK_SSTEP_ACK state Oleg Nesterov
2011-10-19 21:52       ` Oleg Nesterov
2011-10-19 21:52     ` [PATCH 10/X] uprobes: introduce uprobe_deny_signal() Oleg Nesterov
2011-10-19 21:52       ` Oleg Nesterov
2011-10-19 21:53     ` [PATCH 11/X] uprobes: x86: introduce xol_was_trapped() Oleg Nesterov
2011-10-19 21:53       ` Oleg Nesterov
2011-10-24 14:55       ` Srikar Dronamraju
2011-10-24 14:55         ` Srikar Dronamraju
2011-10-24 16:07         ` Oleg Nesterov
2011-10-24 16:07           ` Oleg Nesterov
2011-10-19 21:53     ` [PATCH 12/X] uprobes: x86: introduce abort_xol() Oleg Nesterov
2011-10-19 21:53       ` Oleg Nesterov
2011-10-21 14:42       ` Srikar Dronamraju
2011-10-21 14:42         ` Srikar Dronamraju
2011-10-21 16:22         ` Oleg Nesterov
2011-10-21 16:22           ` Oleg Nesterov
2011-10-21 16:26         ` Ananth N Mavinakayanahalli
2011-10-21 16:26           ` Ananth N Mavinakayanahalli
2011-10-21 16:42           ` Oleg Nesterov
2011-10-21 16:42             ` Oleg Nesterov
2011-10-21 17:59             ` test-case (Was: [PATCH 12/X] uprobes: x86: introduce abort_xol()) Oleg Nesterov
2011-10-21 17:59               ` Oleg Nesterov
2011-10-25 14:06               ` Srikar Dronamraju
2011-10-25 14:06                 ` Srikar Dronamraju
2011-10-25 15:49                 ` Oleg Nesterov
2011-10-25 15:49                   ` Oleg Nesterov
2011-10-22  7:09             ` [PATCH 12/X] uprobes: x86: introduce abort_xol() Ananth N Mavinakayanahalli
2011-10-22  7:09               ` Ananth N Mavinakayanahalli
2011-10-19 21:53     ` [PATCH 13/X] uprobes: introduce UTASK_SSTEP_TRAPPED logic Oleg Nesterov
2011-10-19 21:53       ` Oleg Nesterov
2011-10-22  7:20       ` Ananth N Mavinakayanahalli
2011-10-22  7:20         ` Ananth N Mavinakayanahalli
2011-10-24 14:41         ` Oleg Nesterov
2011-10-24 14:41           ` Oleg Nesterov
2011-10-24 15:16           ` Ananth N Mavinakayanahalli
2011-10-24 15:16             ` Ananth N Mavinakayanahalli
2011-10-24 16:13             ` Oleg Nesterov
2011-10-24 16:13               ` Oleg Nesterov
2011-10-25  6:01               ` Ananth N Mavinakayanahalli
2011-10-25  6:01                 ` Ananth N Mavinakayanahalli
2011-10-25 14:30                 ` Oleg Nesterov
2011-10-25 14:30                   ` Oleg Nesterov
2011-10-19 21:54     ` [PATCH 14/X] uprobes: uprobe_deny_signal: check __fatal_signal_pending() Oleg Nesterov
2011-10-19 21:54       ` Oleg Nesterov

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=20111005170420.GB28250@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=corbet@lwn.net \
    --cc=hch@infradead.org \
    --cc=hughd@google.com \
    --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=peterz@infradead.org \
    --cc=roland@hack.frob.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --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.