From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by kanga.kvack.org (Postfix) with ESMTP id 8094D8D003B for ; Fri, 8 Apr 2011 04:42:42 -0400 (EDT) Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id DCE673EE0C0 for ; Fri, 8 Apr 2011 17:42:38 +0900 (JST) Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id C402B45DE58 for ; Fri, 8 Apr 2011 17:42:38 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id A806045DE54 for ; Fri, 8 Apr 2011 17:42:38 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 989A9E38001 for ; Fri, 8 Apr 2011 17:42:38 +0900 (JST) Received: from ml14.s.css.fujitsu.com (ml14.s.css.fujitsu.com [10.240.81.134]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 62593E08002 for ; Fri, 8 Apr 2011 17:42:38 +0900 (JST) From: KOSAKI Motohiro Subject: Re: [PATCH] mm: Check we have the right vma in __access_remote_vm() In-Reply-To: <10e5cbf67c850b6ae511979bdbad1761236ad9b0.1302247435.git.michael@ellerman.id.au> References: <10e5cbf67c850b6ae511979bdbad1761236ad9b0.1302247435.git.michael@ellerman.id.au> Message-Id: <20110408174244.9B6F.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Fri, 8 Apr 2011 17:42:36 +0900 (JST) Sender: owner-linux-mm@kvack.org List-ID: To: Michael Ellerman Cc: kosaki.motohiro@jp.fujitsu.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, hughd@google.com, walken@google.com, aarcange@redhat.com, riel@redhat.com, Andrew Morton , linuxppc-dev@ozlabs.org, Benjamin Herrenschmidt > In __access_remote_vm() we need to check that we have found the right > vma, not the following vma, before we try to access it. Otherwise we > might call the vma's access routine with an address which does not > fall inside the vma. > > Signed-off-by: Michael Ellerman > --- > mm/memory.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/mm/memory.c b/mm/memory.c > index 9da8cab..ce999ca 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -3678,7 +3678,7 @@ static int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm, > */ > #ifdef CONFIG_HAVE_IOREMAP_PROT > vma = find_vma(mm, addr); > - if (!vma) > + if (!vma || vma->vm_start > addr) > break; > if (vma->vm_ops && vma->vm_ops->access) > ret = vma->vm_ops->access(vma, addr, buf, Looks good to me. Reviewed-by: KOSAKI Motohiro -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org