On Tue, May 29, 2007 at 09:32:16AM -0500, James Bottomley wrote: > 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.
If that were true, with a VIVT cache you'd have userspace randomly SEGVing since stale data would leak through when things get remapped (eg, objects which are only loaded for a short time) etc. That isn't the case. > > 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? We _always_ write out data from the cache for the range we're going to unmap with VIVT. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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
