summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorBenjamin Herrenschmidt <benh@kernel.crashing.org>2005-10-21 14:12:51 +1000
committerLinus Torvalds <torvalds@g5.osdl.org>2005-10-21 12:17:43 -0700
commit5d96551541a8f5521dcc8c634a18d42a3d349ec9 (patch)
tree6aad2e082c3e57f00024f86287444a8ded086933
parenta1c7e111934b6375baf07a970d6c890d18d7e34f (diff)
downloadblackbird-op-linux-5d96551541a8f5521dcc8c634a18d42a3d349ec9.tar.gz
blackbird-op-linux-5d96551541a8f5521dcc8c634a18d42a3d349ec9.zip
[PATCH] ppc64: Fix pages marked dirty abusively
While working on 64K pages, I found this little buglet in our update_mmu_cache() implementation. The code calls __hash_page() passing it an "access" parameter (the type of access that triggers the hash) containing the bits _PAGE_RW and _PAGE_USER of the linux PTE. The latter is useless in this case and the former is wrong. In fact, if we have a writeable PTE and we pass _PAGE_RW to hash_page(), it will set _PAGE_DIRTY (since we track dirty that way, by hash faulting !dirty) which is not what we want. In fact, the correct fix is to always pass 0. That means that only read-only or already dirty read write PTEs will be preloaded. The (hopefully rare) case of a non dirty read write PTE can't be preloaded this way, it will have to fault in hash_page on the actual access. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-rw-r--r--arch/ppc64/mm/init.c3
1 files changed, 1 insertions, 2 deletions
diff --git a/arch/ppc64/mm/init.c b/arch/ppc64/mm/init.c
index c2157c9c3acb..be64b157afce 100644
--- a/arch/ppc64/mm/init.c
+++ b/arch/ppc64/mm/init.c
@@ -799,8 +799,7 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned long ea,
if (cpus_equal(vma->vm_mm->cpu_vm_mask, tmp))
local = 1;
- __hash_page(ea, pte_val(pte) & (_PAGE_USER|_PAGE_RW), vsid, ptep,
- 0x300, local);
+ __hash_page(ea, 0, vsid, ptep, 0x300, local);
local_irq_restore(flags);
}
OpenPOWER on IntegriCloud