* generic/127 failure on xfs with hacked fsx
@ 2018-03-14 15:50 Miklos Szeredi
2018-03-14 21:18 ` Darrick J. Wong
0 siblings, 1 reply; 4+ messages in thread
From: Miklos Szeredi @ 2018-03-14 15:50 UTC (permalink / raw)
To: Darrick J . Wong; +Cc: linux-xfs, linux-fsdevel, fstests
[-- 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);
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: generic/127 failure on xfs with hacked fsx
2018-03-14 15:50 generic/127 failure on xfs with hacked fsx Miklos Szeredi
@ 2018-03-14 21:18 ` Darrick J. Wong
2018-03-14 21:27 ` Dave Chinner
0 siblings, 1 reply; 4+ messages in thread
From: Darrick J. Wong @ 2018-03-14 21:18 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: linux-xfs, linux-fsdevel, fstests
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);
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: generic/127 failure on xfs with hacked fsx
2018-03-14 21:18 ` Darrick J. Wong
@ 2018-03-14 21:27 ` Dave Chinner
2018-03-15 7:58 ` Miklos Szeredi
0 siblings, 1 reply; 4+ messages in thread
From: Dave Chinner @ 2018-03-14 21:27 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: Miklos Szeredi, linux-xfs, linux-fsdevel, fstests
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: generic/127 failure on xfs with hacked fsx
2018-03-14 21:27 ` Dave Chinner
@ 2018-03-15 7:58 ` Miklos Szeredi
0 siblings, 0 replies; 4+ messages in thread
From: Miklos Szeredi @ 2018-03-15 7:58 UTC (permalink / raw)
To: Dave Chinner; +Cc: Darrick J. Wong, linux-xfs, linux-fsdevel, fstests
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-03-15 7:58 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-14 15:50 generic/127 failure on xfs with hacked fsx Miklos Szeredi
2018-03-14 21:18 ` Darrick J. Wong
2018-03-14 21:27 ` Dave Chinner
2018-03-15 7:58 ` Miklos Szeredi
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.