On Tue, 2007-05-29 at 05:15 +0200, Lennert Buytenhek wrote: > On Mon, May 28, 2007 at 10:06:58PM -0500, James Bottomley wrote: > > > Having to (conditionally) invalidate the kernel direct mapping for > > > every userland page we unmap would kind of suck.. > > > > Lets just verify it is a stale kernel mapping first. Try this patch: > > it will cohere the kernel aliases but not the user ones, > > Hmm. I don't understand what you're saying.
I agree its likely a stale kernel cache ... but the symptoms could be dirty user cache as well ... I was just trying to verify beyond doubt that it's the former. > By the time we call the final read(2) (which is what returns the > stale data), there _are_ no user mappings of the page in question. > Flushing the kernel direct mapping by unconditionally calling > flush_dcache_page() in do_generic_mapping_read() makes the issue go > away and makes fsx-linux happy. > > Flushing the kernel direct mapping by forcibly context switching > between munmap() and read() (VIVT cache, context switch does full > cache flush+invalidate) makes the issue go away, too. I'm not that familiar with the mechanics of a VIVT cache. If you unmap, and thus remove the page table entries, does that mean a dirty VIVT line at those entries gets discarded if the processor can't find a mapping? Or does the TLB pin entries for dirty cache lines until they're flushed? James - 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
