> From: Catalin Marinas <catalin.marinas@xxxxxxx> > Date: Mon, 10 May 2010 15:00:10 +0100 > > > 3rd point above would help with the D-cache aliasing. Does the I/D cache > > coherency need to be handled differently? On PIPT Harvard architectures, > > we don't actually have D-cache aliasing but we may end up flushing too > > much in kunmap() just in case such page would be mapped in user space > > with executable permission. > > You can handle this by having an "I-cache clean" bit in the page. > When you kmap/kunmap, simply force this bit clear. > > In update_mmu_cache() or set_pte_at() you'll see when a page gets > into userspace with execute permission, and if the I-cache bit > is clear you can do the flush then and set the "I-cache clean" > bit. If calling kmap on a new page cache page that hasn't been mapped in user space, such bit is already cleared anyway. But would the kernel ever kmap a page already mapped in user space without calling flush_dcache_page? Ideally we shouldn't have to implement the kmap API for architectures with highmem disabled. What I'm trying to achieve is to get an agreement between architectures and use the the cachetlb.txt document as a central recommendation point for how cache flushing should be handled (we've had such issues on ARM for quite some time). The main problems with the arch/arm/ implementation and how we probably understood cachetlb.txt: 1. flush_dcache_page() isn't always called on page cache pages that were written to (and which are subsequently mapped in user space) 2. kmap/kunmap isn't always used in PIO drivers (sometimes just normal pages) 3. deferring the cache flushing to update_mmu_cache() doesn't work on SMP systems with hardware TLB implementation (a different CPU could see the PTE before the cache flushing occurred). The set_pte_at() would be a better place for this Thanks. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html