On Wed, 2011-01-26 at 21:00 +0530, Srikar Dronamraju wrote:

* Peter Zijlstra [off-list ref] [2011-01-26 11:11:48]:

quoted

On Wed, 2011-01-26 at 13:25 +0530, Srikar Dronamraju wrote:

quoted

quoted

quoted

+
+               list_add(&mm->uprobes_list, &tmp_list);
+               mm->uprobes_vaddr = vma->vm_start + offset;
+       }
+       spin_unlock(&mapping->i_mmap_lock);

Both this and unregister are racy, what is to say:
 - the vma didn't get removed from the mm
 - no new matching vma got added

register_uprobe, unregister_uprobe, uprobe_mmap are all synchronized by
uprobes_mutex. So I dont see one unregister_uprobe getting thro when
another register_uprobe is working with a vma.

If I am missing something elementary, please explain a bit more.

afaict you're not holding the mmap_sem, so userspace can simply unmap
the vma.

When we do the actual insert/remove of the breakpoint we hold the
mmap_sem. During the actual insertion/removal, if the vma for the
specific inode is not found, we just come out without doing the
actual insertion/deletion.

Right, but then install_uprobe() should:

 - lookup the vma relating to the address you stored,
 - validate that the vma is indeed a map of the right inode
 - validate that the offset of the probe corresponds with the stored
address

Otherwise you can race with unmap/map and end up installing the probe in
a random location.

Also, I think the whole thing goes funny if someone maps the same text
twice ;-)

--
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>