[patch 37/39] remap_file_pages protection support: wrong "historical" code for review - 1

[blaisorblade]

From: Ingo Molnar <mingo@xxxxxxx>, Paolo 'Blaisorblade' Giarrusso <blaisorblade@xxxxxxxx>

This "fast-path" was contained in the original
remap-file-pages-prot-2.6.4-rc1-mm1-A1.patch from Ingo Molnar*; I think this
code is wrong, but I'm sending it for review anyway, because I'm unsure (and
in fact, in the end I found the reason for this).

What I think is that this patch (done only for filemap_populate, not for
shmem_populate) calls zap_page_range() when installing mappings with PROT_NONE
protection. The purpose is to avoid an useless page lookup; but the PTE's will
be simply marked as absent, not as _PAGE_NONE. So, with this fastpath, pages
would be remapped again in their "default" position.

In this case, probably a possible fix is to add yet another param in
"zap_details" to mark all PTE's as PROT_NONE ones. Using
details->nonlinear_vma has the inconvenient of using
details->{first,last}_index and of leaving file entries unchanged.

* available at
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5/2.6.5-mm1/dropped/remap-file-pages-prot-2.6.4-rc1-mm1-A1.patch

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@xxxxxxxx>
---

 linux-2.6.git-paolo/mm/filemap.c |    9 +++++++++
 1 files changed, 9 insertions(+)

diff -puN mm/filemap.c~rfp-wrong2 mm/filemap.c
--- linux-2.6.git/mm/filemap.c~rfp-wrong2	2005-08-12 18:31:32.000000000 +0200
+++ linux-2.6.git-paolo/mm/filemap.c	2005-08-12 18:31:32.000000000 +0200
@@ -1495,6 +1495,15 @@ int filemap_populate(struct vm_area_stru
 	struct page *page;
 	int err;
 
+	/*
+	 * mapping-removal fastpath:
+	 */
+	if ((vma->vm_flags & VM_SHARED) &&
+			(pgprot_val(prot) == pgprot_val(PAGE_NONE))) {
+		zap_page_range(vma, addr, len, NULL);
+		return 0;
+	}
+
 	if (!nonblock)
 		force_page_cache_readahead(mapping, vma->vm_file,
 					pgoff, len >> PAGE_CACHE_SHIFT);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/