Messages in this thread Patch in this message |  | | Date | Fri, 23 May 2003 02:12:04 -0700 | From | Andrew Morton <> | Subject | Re: [patch] cache flush bug in mm/filemap.c (all kernels >= 2.5.30(at least)) |
| |
"David S. Miller" <davem@redhat.com> wrote: > > On Thu, 2003-05-22 at 07:11, Russell King wrote: > > We seem to have flush_icache_page() in install_page() - I wonder whether > > we should also have flush_dcache_page() in there as well. > ... > > Maybe someone more knowledgeable of the VM layer can comment. > > I am not sure of the exact environment install_page() is meant > to run in, does it always know that no mapping exists at that > address?
No, it does not - there could have been a different page mapped at that virtual address.
> If not, something (either there or higher up) needs to be doing > a flush_cache_page(...) at a minimum.
install_page() did a flush_cache_page() in zap_pte(), if it found there was already a page mapped by the pte.
That flush_cache_page() was added 28 March 2003. 2.5.30 does not have it.
What's that flush_icache_page() doing in there? The fine document makes one suspect it is wrong.
install_page() is prefaulting pages into pagetables, so perhaps it should have an update_mmu_cache()?
diff -puN mm/fremap.c~install_page-flushing mm/fremap.c --- 25/mm/fremap.c~install_page-flushing 2003-05-23 02:01:52.000000000 -0700 +++ 25-akpm/mm/fremap.c 2003-05-23 02:09:03.000000000 -0700 @@ -84,7 +84,7 @@ int install_page(struct mm_struct *mm, s pte_unmap(pte); if (flush) flush_tlb_page(vma, addr); - + update_mmu_cache(vma, addr, *pte); spin_unlock(&mm->page_table_lock); pte_chain_free(pte_chain); return 0; _
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |