[lkml]   [2010]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 7/11] Uprobes Implementation
* Peter Zijlstra <> [2010-05-12 13:12:31]:

> On Wed, 2010-05-12 at 16:11 +0530, Srikar Dronamraju wrote:
> > > We can't hold mmap_sem (for either read or write -- read would be
> > > sufficient to serialize against mmap/mremap/munmap) from atomic uprobe
> > > context, what we can do is validate that there is a INT3 on that
> > > particular address, a mremap/munmap/munmap+mmap will either end not
> > > having a pte entry for the address, or not have the INT3.
> >
> > Did you mean "We can hold mmap_sem?" Else I am not sure if we can
> > traverse the vma. Infact alloc_page_vma() needs mmap_sem to be acquired.
> > Please clarify?
> OK, so maybe I misunderstood, this is from the INT3 trap handler, right?

If I am right, the initial comment was both from the unregister_uprobe()
-> write_opcode() context and uprobe_bkpt_notifier context.

[ snipping relevant part of Oleg's mail from where the conversation started ]
> > 4. mremap(). What if the application does mremap() and moves the
> > memory? After that vaddr of user_bkpt/uprobe no longer matches
> > the virtual address of bp. This breaks uprobe_bkpt_notifier(),
> > unregister_uprobe(), etc.
> >
> > Even worse. Say, unregister_uprobe() calls remove_bkpt().
> > mremap()+mmap() can be called after ->read_opcode() verifies
> > vaddr
> > points to bkpt_insn, but before write_opcode() changes the page.

But yes, if the mmap/mremap/munmap can happen between validating the
int3 and removal of the breakpoint in the unregister_uprobe path, then
it can as well happen between the breakpoint hit and the time uprobes
does the fixups to continue execution after running the handler and

I agree with you that we shouldnt bother about mmap/mremap/munmap of the
executable code. Probably we could document the same.

> We can _not_ take a sleeping lock from trap context. Why would you want
> the vma anyway?

Yes, we dont look at the vma in trap context at all. If we need to allocate a
slot in the xol_vma then we set the TIF_UPROBE do the stuff in task

Thanks and Regards

 \ /
  Last update: 2010-05-12 16:27    [W:0.050 / U:3.884 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site