generic/127 failure on xfs with hacked fsx

generic/127 failure on xfs with hacked fsx

[Miklos Szeredi]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

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

[-- Attachment #2: fsx-trigger-xfs-bug.patch --]
[-- Type: text/x-patch, Size: 559 bytes --]

---
 ltp/fsx.c |    9 +++++++++
 1 file changed, 9 insertions(+)

--- a/ltp/fsx.c
+++ b/ltp/fsx.c
@@ -647,6 +647,14 @@ check_trunc_hack(void)
 	}
 }
 
+static void openclose(int fd)
+{
+	char path[32];
+
+	sprintf(path, "/proc/self/fd/%i", fd);
+	close(open(path, O_RDONLY));
+}
+
 void
 doflush(unsigned offset, unsigned size)
 {
@@ -799,6 +807,7 @@ domapread(unsigned offset, unsigned size
 	        prterr("domapread: mmap");
 		report_failure(190);
 	}
+	openclose(fd);
 	memcpy(temp_buf, p + pg_offset, size);
 
 	check_eofpage("Read", offset, p, size);

Re: generic/127 failure on xfs with hacked fsx

[Darrick J. Wong]

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. :/

--D

> ---
>  ltp/fsx.c |    9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> --- a/ltp/fsx.c
> +++ b/ltp/fsx.c
> @@ -647,6 +647,14 @@ check_trunc_hack(void)
>  	}
>  }
>  
> +static void openclose(int fd)
> +{
> +	char path[32];
> +
> +	sprintf(path, "/proc/self/fd/%i", fd);
> +	close(open(path, O_RDONLY));
> +}
> +
>  void
>  doflush(unsigned offset, unsigned size)
>  {
> @@ -799,6 +807,7 @@ domapread(unsigned offset, unsigned size
>  	        prterr("domapread: mmap");
>  		report_failure(190);
>  	}
> +	openclose(fd);
>  	memcpy(temp_buf, p + pg_offset, size);
>  
>  	check_eofpage("Read", offset, p, size);

Re: generic/127 failure on xfs with hacked fsx

[Dave Chinner]

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@fromorbit.com

Re: generic/127 failure on xfs with hacked fsx

[Miklos Szeredi]

On Wed, Mar 14, 2018 at 10:27 PM, Dave Chinner <david@fromorbit.com> 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