All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Anton Arapov <anton@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] uprobes: kill insert_vm_struct()->uprobe_mmap()
Date: Fri, 13 Jul 2012 19:32:21 +0530	[thread overview]
Message-ID: <20120713140221.GA4741@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120713132916.GA12507@redhat.com>

* Oleg Nesterov <oleg@redhat.com> [2012-07-13 15:29:16]:

> On 07/13, Srikar Dronamraju wrote:
> >
> > * Oleg Nesterov <oleg@redhat.com> [2012-07-08 22:30:11]:
> >
> > > Kill insert_vm_struct()->uprobe_mmap(). It is not needed, nobody
> > > except arch/ia64/kernel/perfmon.c uses insert_vm_struct(vma) with
> > > vma->vm_file != NULL.
> > >
> >
> > Right, but somebody else might start using this later.
> 
> Unlikely, I think...
> 
> > I cant think of a use case though.
> 
> Yes.
> 
> > > And it is wrong. Again, get_user_pages() can not succeed before
> > > vma_link(vma) makes is visible to find_vma(). And even if this
> > > worked, we must not insert the new bp before this mapping is
> > > visible to vma_prio_tree_foreach() for uprobe_unregister().
> > >
> >
> > Agree, we are wrong to do it before vma_link.
> >
> >
> > > Signed-off-by: Oleg Nesterov <oleg@redhat.com>
> > > ---
> > >  mm/mmap.c |    3 ---
> > >  1 files changed, 0 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/mm/mmap.c b/mm/mmap.c
> > > index e5a4614..4fe2697 100644
> > > --- a/mm/mmap.c
> > > +++ b/mm/mmap.c
> > > @@ -2345,9 +2345,6 @@ int insert_vm_struct(struct mm_struct * mm, struct vm_area_struct * vma)
> > >  	     security_vm_enough_memory_mm(mm, vma_pages(vma)))
> > >  		return -ENOMEM;
> > >
> > > -	if (vma->vm_file && uprobe_mmap(vma))
> > > -		return -EINVAL;
> > > -
> > >  	vma_link(mm, vma, prev, rb_link, rb_parent);
> > >  	return 0;
> > >  }
> >
> > Can we do something like:
> >
> > 	vma_link(mm, vma, prev, rb_link, rb_parent);
> >
> > 	if (vma->vm_file && uprobe_mmap(vma)) {
> > 		/* FIXME: dont know if calling unmap_region is fine here */
> > 		unmap_region(mm, vma, prev, vma->vm_start, vma->vm_end);
> > 		return -EINVAL;
> > 	}
> 
> Yes, I was thinking about the possible fix, but afaics this is not
> enough. At least this needs vm_unacct_memory(). And I am not sure
> about unmap_region...
> 
> The main problem is that I have no idea how could I test the fix.
> Once again, currently this file can't be probed.
> 
> So. Can't we kill this obviously wrong and unneeded (at least currently)
> code? Currently uprobe_mmap/munmap logic is not correct (I'll try to send
> more fixes after I return from vacation), it would be nice to remove the
> callsite.
> 
> If somebody else will use insert_vm_struct() to mmap the can-be-uprobed
> file then yes, we will need to add uprobe_mmap() somewhere. But until
> then, the right fix is not clear and not testable.

Yes, for now your solution should be the way to go.
May be we should probably add a TODO/Fixme comment in insert_vm_struct
saying anybody trying to use insert_vm_struct to look at uprobe_mmap().

-- 
Thanks and Regards
Srikar


  reply	other threads:[~2012-07-13 14:05 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-08 20:29 [PATCH 0/5] uprobes: misc fixlets Oleg Nesterov
2012-07-08 20:30 ` [PATCH 1/5] uprobes: uprobe_mmap/munmap needs list_for_each_entry_safe() Oleg Nesterov
2012-07-12  5:59   ` Srikar Dronamraju
2012-07-08 20:30 ` [PATCH 2/5] uprobes: suppress uprobe_munmap() from mmput() Oleg Nesterov
2012-07-09  8:30   ` Peter Zijlstra
2012-07-09 10:09     ` Oleg Nesterov
2012-07-09 10:13       ` Peter Zijlstra
2012-07-09 10:25       ` Srikar Dronamraju
2012-07-12  5:57   ` Srikar Dronamraju
2012-07-08 20:30 ` [PATCH 3/5] uprobes: fix overflow in vma_address/find_active_uprobe Oleg Nesterov
2012-07-08 21:18   ` Joe Perches
2012-07-09 10:54     ` Oleg Nesterov
2012-07-12  5:56       ` Srikar Dronamraju
2012-07-08 20:30 ` [PATCH 4/5] uprobes: kill copy_vma()->uprobe_mmap() Oleg Nesterov
2012-07-09  8:35   ` Peter Zijlstra
2012-07-09 10:39     ` Oleg Nesterov
2012-07-13  8:13   ` Srikar Dronamraju
2012-07-08 20:30 ` [PATCH 5/5] uprobes: kill insert_vm_struct()->uprobe_mmap() Oleg Nesterov
2012-07-13  8:11   ` Srikar Dronamraju
2012-07-13 13:29     ` Oleg Nesterov
2012-07-13 14:02       ` Srikar Dronamraju [this message]
2012-07-13 14:02   ` Srikar Dronamraju

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120713140221.GA4741@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=ananth@in.ibm.com \
    --cc=anton@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.