All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin LaHaise <bcrl@redhat.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Marcelo Tosatti <marcelo@conectiva.com.br>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] mmap bug with drivers that adjust vm_start
Date: Tue, 26 Mar 2002 15:43:45 -0500	[thread overview]
Message-ID: <20020326154345.B25595@redhat.com> (raw)
In-Reply-To: <20020325230046.A14421@redhat.com> <20020326174236.B13052@dualathlon.random> <20020326135703.B25375@redhat.com> <20020326201502.J13052@dualathlon.random>

On Tue, Mar 26, 2002 at 08:15:02PM +0100, Andrea Arcangeli wrote:
> > we could BUG() on getting a vma back from the new find_vma_prepare call.
> 
> yes, it sounds a good idea to verify there's no other mapping in the way
> of the relocation (until a better fix is implemented), it's a slow path
> so we won't hurt performance.

Okay, updated patch for this is below.  I also added a printk to give us 
which mmap operation was invoked to aid in debugging.

> The good reason, is that currently we're literally corrupting the
> userspace with the senseless do_munmap call in the add<->addr+len area
> before the ->mmap lowlevel callback. And such an munmap is certainly not
> required to maintain source and binary compatibility (otherwise it would
> be insane in the first place :).

Ah, right.  I disallow MAP_FIXED addresses that are not the "correct" offset, 
so this case would fail, albeit with the do_munmap occurring.  Personally, 
I would rather see an mmap fail if it would collide with an existing mapping, 
but that might break some applications.

Thanks for looking this over.  Cheers,

		-ben
-- 
"A man with a bass just walked in,
 and he's putting it down
 on the floor."

:r ~/patches/v2.4.19-pre4-mmap_fix-2.diff
--- retest.3/mm/mmap.c.org	Mon Mar 25 19:38:10 2002
+++ retest.3/mm/mmap.c	Tue Mar 26 15:01:47 2002
@@ -14,6 +14,7 @@
 #include <linux/file.h>
 #include <linux/fs.h>
 #include <linux/personality.h>
+#include <linux/compiler.h>
 
 #include <asm/uaccess.h>
 #include <asm/pgalloc.h>
@@ -548,7 +549,19 @@
 	 * Answer: Yes, several device drivers can do it in their
 	 *         f_op->mmap method. -DaveM
 	 */
-	addr = vma->vm_start;
+	if (addr != vma->vm_start) {
+		/* Since addr changed, we rely on the mmap op to prevent 
+		 * collisions with existing vmas and just use find_vma_prepare 
+		 * to update the tree pointers.
+		 */
+		addr = vma->vm_start;
+		if (unlikely(NULL != find_vma_prepare(mm, addr, &prev,
+						&rb_link, &rb_parent))) {
+			printk(KERN_ERR "buggy mmap operation: [<%p>]\n",
+				file ? file->f_op->mmap : NULL);
+			BUG();
+		}
+	}
 
 	vma_link(mm, vma, prev, rb_link, rb_parent);
 	if (correct_wcount)

WARNING: multiple messages have this Message-ID (diff)
From: Benjamin LaHaise <bcrl@redhat.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Marcelo Tosatti <marcelo@conectiva.com.br>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] mmap bug with drivers that adjust vm_start
Date: Tue, 26 Mar 2002 15:43:45 -0500	[thread overview]
Message-ID: <20020326154345.B25595@redhat.com> (raw)
In-Reply-To: <20020326201502.J13052@dualathlon.random>; from andrea@suse.de on Tue, Mar 26, 2002 at 08:15:02PM +0100

On Tue, Mar 26, 2002 at 08:15:02PM +0100, Andrea Arcangeli wrote:
> > we could BUG() on getting a vma back from the new find_vma_prepare call.
> 
> yes, it sounds a good idea to verify there's no other mapping in the way
> of the relocation (until a better fix is implemented), it's a slow path
> so we won't hurt performance.

Okay, updated patch for this is below.  I also added a printk to give us 
which mmap operation was invoked to aid in debugging.

> The good reason, is that currently we're literally corrupting the
> userspace with the senseless do_munmap call in the add<->addr+len area
> before the ->mmap lowlevel callback. And such an munmap is certainly not
> required to maintain source and binary compatibility (otherwise it would
> be insane in the first place :).

Ah, right.  I disallow MAP_FIXED addresses that are not the "correct" offset, 
so this case would fail, albeit with the do_munmap occurring.  Personally, 
I would rather see an mmap fail if it would collide with an existing mapping, 
but that might break some applications.

Thanks for looking this over.  Cheers,

		-ben
-- 
"A man with a bass just walked in,
 and he's putting it down
 on the floor."

:r ~/patches/v2.4.19-pre4-mmap_fix-2.diff
--- retest.3/mm/mmap.c.org	Mon Mar 25 19:38:10 2002
+++ retest.3/mm/mmap.c	Tue Mar 26 15:01:47 2002
@@ -14,6 +14,7 @@
 #include <linux/file.h>
 #include <linux/fs.h>
 #include <linux/personality.h>
+#include <linux/compiler.h>
 
 #include <asm/uaccess.h>
 #include <asm/pgalloc.h>
@@ -548,7 +549,19 @@
 	 * Answer: Yes, several device drivers can do it in their
 	 *         f_op->mmap method. -DaveM
 	 */
-	addr = vma->vm_start;
+	if (addr != vma->vm_start) {
+		/* Since addr changed, we rely on the mmap op to prevent 
+		 * collisions with existing vmas and just use find_vma_prepare 
+		 * to update the tree pointers.
+		 */
+		addr = vma->vm_start;
+		if (unlikely(NULL != find_vma_prepare(mm, addr, &prev,
+						&rb_link, &rb_parent))) {
+			printk(KERN_ERR "buggy mmap operation: [<%p>]\n",
+				file ? file->f_op->mmap : NULL);
+			BUG();
+		}
+	}
 
 	vma_link(mm, vma, prev, rb_link, rb_parent);
 	if (correct_wcount)
--
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/

  reply	other threads:[~2002-03-26 20:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-26  4:00 [patch] mmap bug with drivers that adjust vm_start Benjamin LaHaise
2002-03-26  4:00 ` Benjamin LaHaise
2002-03-26  4:00 ` David S. Miller
2002-03-26  4:00   ` David S. Miller
2002-03-26 16:42 ` Andrea Arcangeli
2002-03-26 16:42   ` Andrea Arcangeli
2002-03-26 18:57   ` Benjamin LaHaise
2002-03-26 18:57     ` Benjamin LaHaise
2002-03-26 19:15     ` Andrea Arcangeli
2002-03-26 19:15       ` Andrea Arcangeli
2002-03-26 20:43       ` Benjamin LaHaise [this message]
2002-03-26 20:43         ` Benjamin LaHaise
2002-03-26 21:18         ` Andrea Arcangeli
2002-03-26 21:18           ` Andrea Arcangeli

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=20020326154345.B25595@redhat.com \
    --to=bcrl@redhat.com \
    --cc=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=marcelo@conectiva.com.br \
    /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.