From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Hugh Dickins <hugh@veritas.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Linux Memory Management <linux-mm@kvack.org>,
Andrew Morton <akpm@osdl.org>, Ralf Baechle <ralf@linux-mips.org>,
Carsten Otte <cotte@de.ibm.com>
Subject: Re: [patch] mm: mremap correct rmap accounting
Date: Tue, 30 Jan 2007 12:00:20 +1100 [thread overview]
Message-ID: <45BE98A4.3080706@yahoo.com.au> (raw)
In-Reply-To: <Pine.LNX.4.64.0701292107510.26482@blonde.wat.veritas.com>
Hugh Dickins wrote:
> Ah, it wasn't any special patch of Nick's that needed it for
> correctness, it was filemap_xip and its use the ZERO_PAGE(address)
> (to avoid unnecessary page allocations): with page_check_address()
> an interface for checking just a single page, not a range of them.
>
> Could make it loop over them all, but a quicker patch would be as
> below. I've no idea if the intersection of filemap_xip users and
> MIPS users is the empty set or more interesting. But I'd prefer
> you don't just slam in the patch, better have an opinion from
> Carsten and/or Nick first.
Yeah you could do that. I found it interesting that there is no way
in hell Linus will take an architecture-specific patch for this
odd-ball architecture and its obscure problem, but would rather fix
it in generic code.
My opinion? If we do keep the multiple zero pages thing, then I would
prefer keep them coherent with their virtual addresses to prevent
future surprises. Ditching multiple zero pages completely would be
ideal, from a core mm/ point of view, of course.
I agree my patch is ugly for having to do refcount and rmap work
outside mm/. But I don't see anything wrong with it as the minimal
correctness fix that we could later reevaluate.
>
>
> Nick Piggin points out that page accounting on MIPS multiple ZERO_PAGEs
> is not maintained by its move_pte, and could lead to freeing a ZERO_PAGE.
> Instead of complicating that move_pte, just forget the minor optimization
> when mremapping, and change the one thing which needed it for correctness
> - filemap_xip use ZERO_PAGE(0) throughout instead of according to address.
>
> Signed-off-by: Hugh Dickins <hugh@veritas.com>
> ---
>
> include/asm-mips/pgtable.h | 10 ----------
> mm/filemap_xip.c | 4 ++--
> mm/mremap.c | 1 -
> 3 files changed, 2 insertions(+), 13 deletions(-)
>
> --- 2.6.20-rc6/include/asm-mips/pgtable.h 2007-01-25 08:25:19.000000000 +0000
> +++ linux/include/asm-mips/pgtable.h 2007-01-29 20:57:35.000000000 +0000
> @@ -69,16 +69,6 @@ extern unsigned long zero_page_mask;
> #define ZERO_PAGE(vaddr) \
> (virt_to_page((void *)(empty_zero_page + (((unsigned long)(vaddr)) & zero_page_mask))))
>
> -#define __HAVE_ARCH_MOVE_PTE
> -#define move_pte(pte, prot, old_addr, new_addr) \
> -({ \
> - pte_t newpte = (pte); \
> - if (pte_present(pte) && pfn_valid(pte_pfn(pte)) && \
> - pte_page(pte) == ZERO_PAGE(old_addr)) \
> - newpte = mk_pte(ZERO_PAGE(new_addr), (prot)); \
> - newpte; \
> -})
> -
> extern void paging_init(void);
>
> /*
> --- 2.6.20-rc6/mm/filemap_xip.c 2007-01-25 08:25:27.000000000 +0000
> +++ linux/mm/filemap_xip.c 2007-01-29 20:57:35.000000000 +0000
> @@ -183,7 +183,7 @@ __xip_unmap (struct address_space * mapp
> address = vma->vm_start +
> ((pgoff - vma->vm_pgoff) << PAGE_SHIFT);
> BUG_ON(address < vma->vm_start || address >= vma->vm_end);
> - page = ZERO_PAGE(address);
> + page = ZERO_PAGE(0);
> pte = page_check_address(page, mm, address, &ptl);
> if (pte) {
> /* Nuke the page table entry. */
> @@ -246,7 +246,7 @@ xip_file_nopage(struct vm_area_struct *
> __xip_unmap(mapping, pgoff);
> } else {
> /* not shared and writable, use ZERO_PAGE() */
> - page = ZERO_PAGE(address);
> + page = ZERO_PAGE(0);
> }
>
> out:
> --- 2.6.20-rc6/mm/mremap.c 2006-11-29 21:57:37.000000000 +0000
> +++ linux/mm/mremap.c 2007-01-29 20:57:35.000000000 +0000
> @@ -105,7 +105,6 @@ static void move_ptes(struct vm_area_str
> if (pte_none(*old_pte))
> continue;
> pte = ptep_clear_flush(vma, old_addr, old_pte);
> - /* ZERO_PAGE can be dependant on virtual addr */
> pte = move_pte(pte, new_vma->vm_page_prot, old_addr, new_addr);
> set_pte_at(mm, new_addr, new_pte, pte);
> }
>
> --
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
--
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:[~2007-01-30 1:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-23 14:19 Nick Piggin
2007-01-23 20:55 ` Hugh Dickins
2007-01-23 23:49 ` Nick Piggin
2007-01-29 3:31 ` Nick Piggin
2007-01-29 6:40 ` Andrew Morton
2007-01-29 6:57 ` Nick Piggin
2007-01-29 19:08 ` Hugh Dickins
2007-01-29 19:27 ` Linus Torvalds
2007-01-29 20:03 ` Andrew Morton
2007-01-29 20:18 ` Linus Torvalds
2007-01-29 21:27 ` Ralf Baechle
2007-01-29 20:10 ` Hugh Dickins
2007-01-29 20:22 ` Linus Torvalds
2007-01-29 20:38 ` Hugh Dickins
2007-01-29 21:24 ` Hugh Dickins
2007-01-30 1:00 ` Nick Piggin [this message]
2007-01-30 14:24 ` Carsten Otte
2007-01-30 16:41 ` Ralf Baechle
2007-01-30 17:35 ` Carsten Otte
2007-01-30 15:47 ` Carsten Otte
2007-01-30 22:04 ` Hugh Dickins
2007-01-31 13:51 ` Carsten Otte
2007-01-31 13:59 ` Carsten Otte
2007-01-31 16:31 ` Hugh Dickins
2007-02-01 16:21 ` Carsten Otte
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=45BE98A4.3080706@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=cotte@de.ibm.com \
--cc=hugh@veritas.com \
--cc=linux-mm@kvack.org \
--cc=ralf@linux-mips.org \
--cc=torvalds@linux-foundation.org \
/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