From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: MinChan Kim <minchan.kim@gmail.com>
Cc: linux mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux kernel <linux-kernel@vger.kernel.org>,
Nick Piggin <npiggin@suse.de>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [PATCH] fix mlocked page counter mismatch
Date: Mon, 02 Feb 2009 12:16:35 -0500 [thread overview]
Message-ID: <1233594995.17895.144.camel@lts-notebook> (raw)
In-Reply-To: <20090202061622.GA13286@barrios-desktop>
On Mon, 2009-02-02 at 15:16 +0900, MinChan Kim wrote:
> When I tested following program, I found that mlocked counter
> is strange.
> It couldn't free some mlocked pages of test program.
>
> It is caused that try_to_unmap_file don't check real
> page mapping in vmas.
> That's because goal of address_space for file is to find all processes
> into which the file's specific interval is mapped.
> What I mean is that it's not related page but file's interval.
>
> Even if the page isn't really mapping at the vma, it returns
> SWAP_MLOCK since the vma have VM_LOCKED, then calls
> try_to_mlock_page. After all, mlocked counter is increased again.
>
> This patch is based on 2.6.28-rc2-mm1.
>
> -- my test program --
>
> #include <stdio.h>
> #include <sys/mman.h>
> int main()
> {
> mlockall(MCL_CURRENT);
> return 0;
> }
>
> -- before --
>
> root@barrios-target-linux:~# cat /proc/meminfo | egrep 'Mlo|Unev'
> Unevictable: 0 kB
> Mlocked: 0 kB
>
> -- after --
>
> root@barrios-target-linux:~# cat /proc/meminfo | egrep 'Mlo|Unev'
> Unevictable: 8 kB
> Mlocked: 8 kB
>
>
> --
>
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 1099394..9ba1fdf 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1073,6 +1073,9 @@ static int try_to_unmap_file(struct page *page, int unlock, int migration)
> unsigned long max_nl_size = 0;
> unsigned int mapcount;
> unsigned int mlocked = 0;
> + unsigned long address;
> + pte_t *pte;
> + spinlock_t *ptl;
>
> if (MLOCK_PAGES && unlikely(unlock))
> ret = SWAP_SUCCESS; /* default for try_to_munlock() */
> @@ -1089,6 +1092,13 @@ static int try_to_unmap_file(struct page *page, int unlock, int migration)
> goto out;
> }
> if (ret == SWAP_MLOCK) {
> + address = vma_address(page, vma);
> + if (address != -EFAULT) {
> + pte = page_check_address(page, vma->vm_mm, address, &ptl, 0);
> + if (!pte)
> + continue;
> + pte_unmap_unlock(pte, ptl);
> + }
> mlocked = try_to_mlock_page(page, vma);
> if (mlocked)
> break; /* stop if actually mlocked page */
Hi, MinChan:
Interestingly, Rik had addressed this [simpler patch below] way back
when he added the page_mapped_in_vma() function. I asked him whether
the rb tree shouldn't have filtered any vmas that didn't have the page
mapped. He agreed and removed the check from try_to_unmap_file().
Guess I can be very convincing, even when I'm wrong [happening a lot
lately]. Of course, in this instance, the rb-tree filtering only works
for shared, page-cache pages. The problem uncovered by your test case
is with a COWed anon page in a file-backed vma. Yes, the vma 'maps' the
virtual address range containing the page in question, but since it's a
private COWed anon page, it isn't necessarily "mapped" in the VM_LOCKED
vma's mm's page table. We need the check...
I've added the variant below [CURRENTLY UNTESTED] to my test tree.
Lee
[intentionally omitted sign off, until tested.]
Index: linux-2.6.29-rc3/mm/rmap.c
===================================================================
--- linux-2.6.29-rc3.orig/mm/rmap.c 2009-01-30 14:13:56.000000000 -0500
+++ linux-2.6.29-rc3/mm/rmap.c 2009-02-02 11:27:11.000000000 -0500
@@ -1072,7 +1072,8 @@ static int try_to_unmap_file(struct page
spin_lock(&mapping->i_mmap_lock);
vma_prio_tree_foreach(vma, &iter, &mapping->i_mmap, pgoff, pgoff) {
if (MLOCK_PAGES && unlikely(unlock)) {
- if (!(vma->vm_flags & VM_LOCKED))
+ if (!((vma->vm_flags & VM_LOCKED) &&
+ page_mapped_in_vma(page, vma)))
continue; /* must visit all vmas */
ret = SWAP_MLOCK;
} else {
WARNING: multiple messages have this Message-ID (diff)
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: MinChan Kim <minchan.kim@gmail.com>
Cc: linux mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux kernel <linux-kernel@vger.kernel.org>,
Nick Piggin <npiggin@suse.de>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [PATCH] fix mlocked page counter mismatch
Date: Mon, 02 Feb 2009 12:16:35 -0500 [thread overview]
Message-ID: <1233594995.17895.144.camel@lts-notebook> (raw)
In-Reply-To: <20090202061622.GA13286@barrios-desktop>
On Mon, 2009-02-02 at 15:16 +0900, MinChan Kim wrote:
> When I tested following program, I found that mlocked counter
> is strange.
> It couldn't free some mlocked pages of test program.
>
> It is caused that try_to_unmap_file don't check real
> page mapping in vmas.
> That's because goal of address_space for file is to find all processes
> into which the file's specific interval is mapped.
> What I mean is that it's not related page but file's interval.
>
> Even if the page isn't really mapping at the vma, it returns
> SWAP_MLOCK since the vma have VM_LOCKED, then calls
> try_to_mlock_page. After all, mlocked counter is increased again.
>
> This patch is based on 2.6.28-rc2-mm1.
>
> -- my test program --
>
> #include <stdio.h>
> #include <sys/mman.h>
> int main()
> {
> mlockall(MCL_CURRENT);
> return 0;
> }
>
> -- before --
>
> root@barrios-target-linux:~# cat /proc/meminfo | egrep 'Mlo|Unev'
> Unevictable: 0 kB
> Mlocked: 0 kB
>
> -- after --
>
> root@barrios-target-linux:~# cat /proc/meminfo | egrep 'Mlo|Unev'
> Unevictable: 8 kB
> Mlocked: 8 kB
>
>
> --
>
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 1099394..9ba1fdf 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1073,6 +1073,9 @@ static int try_to_unmap_file(struct page *page, int unlock, int migration)
> unsigned long max_nl_size = 0;
> unsigned int mapcount;
> unsigned int mlocked = 0;
> + unsigned long address;
> + pte_t *pte;
> + spinlock_t *ptl;
>
> if (MLOCK_PAGES && unlikely(unlock))
> ret = SWAP_SUCCESS; /* default for try_to_munlock() */
> @@ -1089,6 +1092,13 @@ static int try_to_unmap_file(struct page *page, int unlock, int migration)
> goto out;
> }
> if (ret == SWAP_MLOCK) {
> + address = vma_address(page, vma);
> + if (address != -EFAULT) {
> + pte = page_check_address(page, vma->vm_mm, address, &ptl, 0);
> + if (!pte)
> + continue;
> + pte_unmap_unlock(pte, ptl);
> + }
> mlocked = try_to_mlock_page(page, vma);
> if (mlocked)
> break; /* stop if actually mlocked page */
Hi, MinChan:
Interestingly, Rik had addressed this [simpler patch below] way back
when he added the page_mapped_in_vma() function. I asked him whether
the rb tree shouldn't have filtered any vmas that didn't have the page
mapped. He agreed and removed the check from try_to_unmap_file().
Guess I can be very convincing, even when I'm wrong [happening a lot
lately]. Of course, in this instance, the rb-tree filtering only works
for shared, page-cache pages. The problem uncovered by your test case
is with a COWed anon page in a file-backed vma. Yes, the vma 'maps' the
virtual address range containing the page in question, but since it's a
private COWed anon page, it isn't necessarily "mapped" in the VM_LOCKED
vma's mm's page table. We need the check...
I've added the variant below [CURRENTLY UNTESTED] to my test tree.
Lee
[intentionally omitted sign off, until tested.]
Index: linux-2.6.29-rc3/mm/rmap.c
===================================================================
--- linux-2.6.29-rc3.orig/mm/rmap.c 2009-01-30 14:13:56.000000000 -0500
+++ linux-2.6.29-rc3/mm/rmap.c 2009-02-02 11:27:11.000000000 -0500
@@ -1072,7 +1072,8 @@ static int try_to_unmap_file(struct page
spin_lock(&mapping->i_mmap_lock);
vma_prio_tree_foreach(vma, &iter, &mapping->i_mmap, pgoff, pgoff) {
if (MLOCK_PAGES && unlikely(unlock)) {
- if (!(vma->vm_flags & VM_LOCKED))
+ if (!((vma->vm_flags & VM_LOCKED) &&
+ page_mapped_in_vma(page, vma)))
continue; /* must visit all vmas */
ret = SWAP_MLOCK;
} else {
--
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:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-02-02 17:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-02 6:16 [PATCH] fix mlocked page counter mismatch MinChan Kim
2009-02-02 6:16 ` MinChan Kim
2009-02-02 17:16 ` Lee Schermerhorn [this message]
2009-02-02 17:16 ` Lee Schermerhorn
2009-02-02 23:27 ` MinChan Kim
2009-02-02 23:27 ` MinChan Kim
2009-02-03 1:48 ` Lee Schermerhorn
2009-02-03 1:48 ` Lee Schermerhorn
2009-02-03 1:57 ` MinChan Kim
2009-02-03 1:57 ` MinChan Kim
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=1233594995.17895.144.camel@lts-notebook \
--to=lee.schermerhorn@hp.com \
--cc=akpm@linux-foundation.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan.kim@gmail.com \
--cc=npiggin@suse.de \
/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.