From: Lennert Buytenhek <[EMAIL PROTECTED]> Date: Mon, 28 May 2007 14:44:11 +0200
> On Sun, May 27, 2007 at 07:31:27PM -0500, James Bottomley wrote: > > > On munmap we do a flush_cache_range for the unmapped vmas ... we > > have to, otherwise the data might be lost as the user mapping is > > zapped and we wouldn't be able to guarantee coherency writing it > > to the backing store. > > As far as I understand it, the munmap() does flush out the copy of > the data at the user virtual address, but the subsequent read() call > reads from an address in the kernel direct mapped window, for which > there is still data in the cache due to the earlier read() syscall, > and the mapping_writably_mapped() test fails so we don't end up > calling flush_dcache_page(). That is what is happening for sure. That mapping_writably_mapped() check depends upon munmap() flush out the lines from the cache on the user side at least enough to make them coherent on the kernel side. As I said my flush_cache_range() on sparc64 used to do this, but I removed it for whatever reason, perhaps I did not consider this case back then. I'm not advocating a full flush on flush_cache_range(), but rather to set a page state bit, which will force a flush on the "check_dcache_page()" call which we could replace this conditionalized flush_dcache_page() call with. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
