lkml.org 
[lkml]   [2010]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 7/11] Uprobes Implementation
* 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
>


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