This has been resolved. Short explanation: There was a bug in the mips arch-specific mm subsystem of the kernel, fixed in November of 2007. http://www.linux-mips.org/git?p=linux-mti.git;a=commit;h=6a36458d9348265327d074bdd40bfb1c5b6fb2cb So not to do with AUFS, except for the particular conditions that caused it.
Longer explanation: After more debugging the root cause of the crash was a page returned from aufo_nopage() that had not been flushed (write back) from the data cache. This page was then used as the source of a copy_user_page() function later in the page fault, which caused bad data to be read from the page. It became very reproducible when writing 1 into /proc/sys/vm/drop_caches. In the page fault, the aufs_nopage calls the underlying file read function, here squashfs_readpage(). After reading the pages it calls flush_dcache_page(), which in this case just marks the page as "dirty". aufs_nopage() returns the "dirty" page, to do_no_page() in the page fault hander. Since the page is set to writable, do_no_page() allocates a new page, and copies the "dirty:" page with copy_user_highpage(). The underlying issue manifested itself as the page only marked as "dirty" instead of actually being flushed. Thanks very much for the helpful suggestions and support. Apologies to the list for what turned out to be not an AUFS issue. Learned _way_ too much about the particulars of mips cache coherency. Derek On Sun, Jun 7, 2009 at 12:50 AM, <[email protected]> wrote: > > Hi, > > Derek Spadaro: >> In any case, the solution now is to use write-through mode. I wonder >> though if there could be an explicit write-back missing after a copy >> or some such which might be seen only on certain hardware? > > To be honest, I don't have a good answer for you. If I forgot memory > barrier or something, I guess more bug reports would be posted. But it > never means that aufs is bug free. > > I have searched "mips, cache, flush, write-back, write-through, etc" in > the kernel git log since 2.6.21, and I am afraid this fix in 2.6.25 may > be related to your problem. How do you think? > And give more info about your mips cpu, please. > > > J. R. Okajima > > ---------------------------------------------------------------------- > commit 2eaa7ec286db54cc1a864565ed9367966743bcbd > Author: Ralf Baechle <[email protected]> > Date: Mon Feb 11 14:51:40 2008 +0000 > > [MIPS] Handle I-cache coherency in flush_cache_range() > > So far flush_cache_range() did't consider the I-cache largely because it > did rarely ever matter to real world code. This was working primarily > because normally code and data are don't share the same pages - with the > exception of MIPS16 code which uses address constants embedded between > the code. The following sequence of events may break the code: > > o MIPS16 executable being loaded > o dynamic linker relocates the address constants embedded into the code: > o Uses mprotect(2) to make code pages PROT_READ|PROT_WRITE > o Performs the actual relocations by writing to the pages which likely > are COW. Because no PROT_EXEC is set I-cache coherence will not be > considered. > o Uses mprotect(2) to switch code pages back to PROT_READ|PROT_EXEC. > This results in a call to flush_cache_range() which also does not > consider I-caches. > o => executing the page just having been relocated may now result in the > I-cache getting refilled with stale data from memory. > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects
