[PATCH] ia64: race flushing icache in COW path

From: Luck, Tony <tony.luck_at_intel.com>
Date: 2006-07-14 03:00:38
From: Anil Keshavamurthy <anil.s.keshavamurthy@intel.com>

There is a race condition that showed up in a threaded JIT environment. The
situation is that a process with a JIT code page forks, so the page is marked
read-only, then some threads are created in the child.  One of the threads
attempts to add a new code block to the JIT page, so a copy-on-write fault is
taken, and the kernel allocates a new page, copies the data, installs the new
pte, and then calls lazy_mmu_prot_update() to flush caches to make sure that
the icache and dcache are in sync.  Unfortunately, the other thread runs right
after the new pte is installed, but before the caches have been flushed. It
tries to execute some old JIT code that was already in this page, but it sees
some garbage in the i-cache from the previous users of the new physical page.

Fix: we must make the caches consistent before installing the pte. This is
an ia64 only fix because lazy_mmu_prot_update() is a no-op on all other

Signed-off-by: Anil Keshavamurthy <anil.s.keshavamurthy@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>


diff --git a/mm/memory.c b/mm/memory.c
index dc0d82c..de8bc85 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1549,9 +1549,9 @@ gotten:
 		flush_cache_page(vma, address, pte_pfn(orig_pte));
 		entry = mk_pte(new_page, vma->vm_page_prot);
 		entry = maybe_mkwrite(pte_mkdirty(entry), vma);
+		lazy_mmu_prot_update(entry);
 		ptep_establish(vma, address, page_table, entry);
 		update_mmu_cache(vma, address, entry);
-		lazy_mmu_prot_update(entry);
 		page_add_new_anon_rmap(new_page, vma, address);
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Fri Jul 14 03:10:15 2006

This archive was generated by hypermail 2.1.8 : 2006-07-14 03:10:30 EST