On Wed, Mar 14, 2018 at 02:18:51PM -0700, Darrick J. Wong wrote: > On Wed, Mar 14, 2018 at 04:50:02PM +0100, Miklos Szeredi wrote: > > While testing overlayfs I found something which appears to be an > > unwanted side effect of xfs_release(). > > > > Apply the attached patch to xfstests and run generic/127. > > > > Result is: > > > > +ltp/fsx -q -l 262144 -o 65536 -S 191110531 -N 100000 fsx_std_mmap > > +Mapped Read: non-zero data past EOF (0x8aa1) page offset 0xaa2 is 0xa091 > > +LOG DUMP (70315 total operations): > > > > Thanks, > > Miklos > > Hmm.... so I applied this and ran generic/127 on xfs: > > FSTYP -- xfs (debug) > PLATFORM -- Linux/x86_64 magnolia-mtr00 4.16.0-rc5-xfsx > MKFS_OPTIONS -- -f -m reflink=1,rmapbt=1, -i sparse=1, /dev/pmem4 > MOUNT_OPTIONS -- -o usrquota,grpquota,prjquota, /dev/sda /opt > > generic/127 53s > Ran: generic/127 > Passed all 1 tests > > Reran a couple of times without seeing any problems, so what am > I missing? Are you running xfstests atop overlayfs atop xfs? > > /me confused. :/ I'm betting it's timing related. the close can run a filemap_flush() call, so there's every chance the page is under IO during the mapread operation after the openclose() call. On pmem, it won't be under IO because the writeback IO is a synchronous memcpy.... CHeers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
