linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Hugh Dickins <hughd@google.com>
Cc: "Robert Święcki" <robert@swiecki.net>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Miklos Szeredi" <miklos@szeredi.hu>,
	"Michel Lespinasse" <walken@google.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
	"Rik van Riel" <riel@redhat.com>
Subject: Re: [PATCH] mm: fix possible cause of a page_mapped BUG
Date: Wed, 6 Apr 2011 08:32:13 -0700	[thread overview]
Message-ID: <BANLkTi=tavhpytcSV+nKaXJzw19Bo3W9XQ@mail.gmail.com> (raw)
In-Reply-To: <BANLkTimV1f1YDTWZUU9uvAtCO_fp6EKH9Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

On Wed, Apr 6, 2011 at 7:47 AM, Hugh Dickins <hughd@google.com> wrote:
>>
>> I dunno. But that odd negative pg_off thing makes me think there is
>> some overflow issue (ie HEAP_INDEX being pg_off + size ends up
>> fluctuating between really big and really small). So I'd suspect THAT
>> as the main reason.
>
> Yes, one of the vmas is such that the end offset (pgoff of next page
> after) would be 0, and for the other it would be 16.  There's sure to
> be places, inside the prio_tree code and outside it, where we rely
> upon pgoff not wrapping around - wrap should be prevented by original
> validation of arguments.

Well, we _do_ validate them in do_mmap_pgoff(), which is the main
routine for all the mmap() system calls, and the main way to get a new
mapping.

There are other ways, like do_brk(), but afaik that always sets
vm_pgoff to the virtual address (shifted), so again the new mapping
should be fine.

So when a new mapping is created, it should all be ok.

But I think mremap() may end up expanding it without doing the same
overflow check.

Do you see any other way to get this situation? Does the vma dump give
you any hint about where it came from?

Robert - here's a (UNTESTED!) patch to make mremap() be a bit more
careful about vm_pgoff when growing a mapping. Does it make any
difference?

                            Linus

[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 771 bytes --]

 mm/mremap.c |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/mm/mremap.c b/mm/mremap.c
index 1de98d492ddc..a7c1f9f9b941 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -277,9 +277,16 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr,
 	if (old_len > vma->vm_end - addr)
 		goto Efault;
 
-	if (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP)) {
-		if (new_len > old_len)
+	/* Need to be careful about a growing mapping */
+	if (new_len > old_len) {
+		unsigned long pgoff;
+
+		if (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP))
 			goto Efault;
+		pgoff = (addr - vma->vm_start) >> PAGE_SHIFT;
+		pgoff += vma->vm_pgoff;
+		if (pgoff + (new_len >> PAGE_SHIFT) < pgoff)
+			goto Einval;
 	}
 
 	if (vma->vm_flags & VM_LOCKED) {

  reply	other threads:[~2011-04-06 15:33 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-24  5:39 Hugh Dickins
2011-02-28 23:35 ` Robert Święcki
2011-03-17 15:40   ` Robert Święcki
2011-03-19  5:34     ` Hugh Dickins
2011-04-01 14:34       ` Robert Święcki
2011-04-01 15:44         ` Linus Torvalds
2011-04-01 16:21           ` Robert Święcki
2011-04-01 16:35             ` Linus Torvalds
2011-04-02  4:01               ` Hui Zhu
2011-04-04 13:02                 ` Robert Święcki
2011-04-02  1:46           ` Hugh Dickins
2011-04-04 12:46             ` Robert Święcki
2011-04-04 18:30               ` Hugh Dickins
2011-04-05 12:21                 ` Robert Święcki
2011-04-05 15:37                   ` Linus Torvalds
2011-04-06 14:47                     ` Hugh Dickins
2011-04-06 15:32                       ` Linus Torvalds [this message]
2011-04-06 15:43                         ` Hugh Dickins
2011-04-06 15:59                           ` Linus Torvalds
2011-04-06 17:54                             ` Robert Święcki
2011-04-07 12:41                               ` Robert Święcki
2011-04-07 14:24                                 ` Hugh Dickins
2011-04-12  9:58                                   ` Robert Święcki
2011-04-12 14:21                                     ` Linus Torvalds
     [not found]                                       ` <BANLkTik6U21r91DYiUsz9A0P--=5QcsBrA@mail.gmail.com>
2011-04-12 16:17                                         ` Robert Święcki
2011-04-12 17:19                                         ` Linus Torvalds
2011-04-12 18:59                                           ` Linus Torvalds
2011-04-12 19:02                                             ` Robert Święcki
2011-04-12 19:38                                               ` Linus Torvalds
2011-04-18 21:15                                                 ` Michel Lespinasse
2011-05-05  0:09                                                   ` Michel Lespinasse
2011-05-05  0:38                                                     ` Linus Torvalds
2011-05-05  1:18                                                       ` Michel Lespinasse
2011-05-05  1:40                                                         ` Linus Torvalds
2011-05-05  3:37                                                           ` Linus Torvalds
2011-05-05  4:26                                                             ` Michel Lespinasse
2011-04-07 14:17                             ` Hugh Dickins

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='BANLkTi=tavhpytcSV+nKaXJzw19Bo3W9XQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.hu \
    --cc=riel@redhat.com \
    --cc=robert@swiecki.net \
    --cc=walken@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox