All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Ray Bryant <raybry@sgi.com>
Cc: Hirokazu Takahashi <taka@valinux.co.jp>,
	Dave Hansen <haveblue@us.ibm.com>, linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH] mm: memory migration: bug in touch_unmapped_address
Date: Mon, 28 Feb 2005 10:33:48 -0300	[thread overview]
Message-ID: <20050228133348.GA26902@logos.cnet> (raw)
In-Reply-To: <422356AB.4040703@sgi.com>

Good catch.

That was the reason for the migration cache problems you were seeing?

On Mon, Feb 28, 2005 at 11:36:43AM -0600, Ray Bryant wrote:
> Hirokazu,
> 
> The length field in the call to get_user_pages() from touch_unmapped_pages()
> is incorrectly specified in bytes, not pages.
> 
> As a result of this, if you use the migration code to migrate a page, then
> subsequent pages (that are not necessarily currently allocated or mapped)
> can be allocated and mapped as a result of the migration call.
> 
> [touch_unmapped_pages() is added by the memory migration code from the 
> memory
> hotplug patch so this is not currently part of the mainline kernel]
> 
> See attached patch for the fix.
> -- 
> Best Regards,
> Ray
> -----------------------------------------------
>                   Ray Bryant
> 512-453-9679 (work)         512-507-7807 (cell)
> raybry@sgi.com             raybry@austin.rr.com
> The box said: "Requires Windows 98 or better",
>            so I installed Linux.
> -----------------------------------------------

> The "len" parameter (4th arg) of get_user_pages() is in pages, not
> bytes.  The effect of this bug is that if you migrate a page, and
> if this page is followed by valid virtual addresses, but these 
> pages have not yet been touched and allocated, then the migration
> call will cause those pages to be touched and allocated.  The number
> of pages so effected is the min of (16384, the remaining number of
> pages in the vma, the number of pages required to fill out the
> current pmd).
> 
> Signed-off-by: Ray Bryant <raybry@sgi.com>
> 
> Index: linux/mm/rmap.c
> ===================================================================
> --- linux.orig/mm/rmap.c	2005-01-30 10:34:03.000000000 -0800
> +++ linux/mm/rmap.c	2005-02-28 08:53:30.000000000 -0800
> @@ -554,8 +554,7 @@ touch_unmapped_address(struct list_head 
>  		vma = find_vma(v1->mm, v1->addr);
>  		if (vma == NULL)
>  			goto out;
> -		error = get_user_pages(current, v1->mm, v1->addr, PAGE_SIZE,
> -					0, 0, NULL, NULL);
> +		error = get_user_pages(current, v1->mm, v1->addr, 1, 0, 0, NULL, NULL);
>  		if (error < 0)
>  			ret = error;
>  	out:

--
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/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2005-02-28 13:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-28 17:36 [PATCH] mm: memory migration: bug in touch_unmapped_address Ray Bryant
2005-02-28 13:33 ` Marcelo Tosatti [this message]
2005-02-28 18:56   ` Ray Bryant
2005-03-01  0:09 ` Hirokazu Takahashi

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=20050228133348.GA26902@logos.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=haveblue@us.ibm.com \
    --cc=linux-mm@kvack.org \
    --cc=raybry@sgi.com \
    --cc=taka@valinux.co.jp \
    /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.