Re: [RFC PATCH] Update the cachetlb.txt file WRTflush_dcache_pageand update_mmu_cache

[Catalin Marinas]

> 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-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/