On Mon, May 28, 2007 at 10:06:58PM -0500, James Bottomley wrote: > > > > > Ok, output on parisc is: > > > > > > > > > > [EMAIL PROTECTED]:~$ ./a.out > > > > > firstfirstfirst > > > > > firstfirstfirst > > > > > secondsecondsec > > > > > > > > > > Which is correct. It remains correct even if I drop the msync(). > > > > > > > > With Lennert's new program, I get mostly: > > > > > > > > firstfirstfirst > > > > firstfirstfirst > > > > firstfirstfirst > > > > > > > > but occasionally: > > > > > > > > firstfirstfirst > > > > firstfirstfirst > > > > secondsecondsec > > > > > > > > However, if I open code the memcpy() in the MAPREAD to copy one word > > > > at a time, then I reliably get the "secondsecondsec" line. But if I > > > > convert the memcpy() in MAPWRITE in the same way, I'm back to mostly > > > > getting the failure with the occasional success. Utterly confused. > > > > > > > > Unless someone's got a theory, I'm stumped. > > > > > > I think you're not flushing correctly in munmap() ... but I'm not sure > > > the linux API actually requires this. > > > > 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. 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. - 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
