[PATCH V4] ARM: handle user space mapped pages in flush_kernel_dcache_page

Nicolas Pitre nico at fluxnic.net
Tue May 28 13:52:27 EDT 2013


On Tue, 28 May 2013, Catalin Marinas wrote:

> On Sat, May 25, 2013 at 04:53:19AM +0100, Nicolas Pitre wrote:
> > On Thu, 23 May 2013, Catalin Marinas wrote:
> > 
> > > An issue is that for kunmap_atomic() && VIVT we flush the same page
> > > twice. I don't think we should remove the cache flushing in
> > > __kunmap_atomic() for VIVT since not all kunmap_atomic() calls require
> > > flush_kernel_dcache_page() (unless we just assume that highmem && vivt
> > > don't work together).
> > 
> > VIVT and highmem do work together.  Highmem for ARM was in fact 
> > developed on such a platform.
> 
> Thanks for confirming. Do you remember why kunmap() doesn't (need to)
> flush the cache alias (for VIVT)? Or if it does, where?

kunmap() calls kunmap_high() which actually does not unmap anything but 
only decrement a use count.  The page is kept around in case it is 
kmap()'d again, in which case the kmap() will be almost free and the 
page still warm.

It is only when the kmap() for a new page runs out of free pkmap  
entries that the unused but still mapped pages are unmapped.  This 
unmapping is done in flush_all_zero_pkmaps() where all the unused pages 
are all unmapped at once.  The cache for all those pages is flushed with 
flush_cache_kmaps() which on ARM maps to flush_cache_all() when the 
cache is VIVT.


Nicolas



More information about the linux-arm-kernel mailing list