Re: [PATCH v2 7/11] Uprobes Implementation

[Srikar Dronamraju <srikar@linux.vnet.ibm.com>]

* Peter Zijlstra <peterz@infradead.org> [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
single-stepping. 

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

--
Thanks and Regards
Srikar
>