* Oleg Nesterov [2012-07-08 22:30:03]:
> uprobe_munmap() does get_user_pages() and it is also called from
> the final mmput()->exit_mmap() path. This slows down exit/mmput()
> for no reason, and I think it is simply dangerous/wrong to try to
> fault-in a page into the dying mm. If nothing else,
* Oleg Nesterov [2012-07-09 12:09:20]:
> On 07/09, Peter Zijlstra wrote:
> >
> > On Sun, 2012-07-08 at 22:30 +0200, Oleg Nesterov wrote:
> > > uprobe_munmap() does get_user_pages() and it is also called from
> > > the final mmput()->exit_mmap() path. This slows down exit/mmput()
> > > for no reas
On Mon, 2012-07-09 at 12:09 +0200, Oleg Nesterov wrote:
> No, mmap/munmap do not participate in uprobe refcounting. This code
> does put_uprobe() for each uprobe, yes, but only because the counter
> was incremented in build_probe_list().
>
> uprobe_munmap() is only needed to decrement mm->uprobes_
On 07/09, Peter Zijlstra wrote:
>
> On Sun, 2012-07-08 at 22:30 +0200, Oleg Nesterov wrote:
> > uprobe_munmap() does get_user_pages() and it is also called from
> > the final mmput()->exit_mmap() path. This slows down exit/mmput()
> > for no reason, and I think it is simply dangerous/wrong to try
On Sun, 2012-07-08 at 22:30 +0200, Oleg Nesterov wrote:
> uprobe_munmap() does get_user_pages() and it is also called from
> the final mmput()->exit_mmap() path. This slows down exit/mmput()
> for no reason, and I think it is simply dangerous/wrong to try to
> fault-in a page into the dying mm. If
uprobe_munmap() does get_user_pages() and it is also called from
the final mmput()->exit_mmap() path. This slows down exit/mmput()
for no reason, and I think it is simply dangerous/wrong to try to
fault-in a page into the dying mm. If nothing else, this happens
after the last sync_mm_rss(), afaics
6 matches
Mail list logo
