On Wed, Mar 14, 2018 at 10:27 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > 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? No, plain 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.... Forgot to mention that xfs partition is on virtio_blk device. Thanks, Miklos
