[PATCHSET] fstests: random fixes for v2024.02.09

[PATCHSET] fstests: random fixes for v2024.02.09

[Darrick J. Wong]

Hi all,

Here's the usual odd fixes for fstests.  Most of these are cleanups and
bug fixes that have been aging in my djwong-wtf branch forever.

If you're going to start using this code, I strongly recommend pulling
from my git trees, which are linked below.

This has been running on the djcloud for months with no problems.  Enjoy!
Comments and questions are, as always, welcome.

--D

kernel git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=random-fixes

xfsprogs git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=random-fixes

fstests git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfstests-dev.git/log/?h=random-fixes
---
Commits in this patchset:
 * xfs/270: fix rocompat regex
 * xfs/176: fix stupid failure
 * generic/{166,167,333,334,671}: actually fill the filesystem with snapshots
 * generic: test MADV_POPULATE_READ with IO errors
---
 common/reflink         |    8 ++++++
 tests/generic/166      |    2 +
 tests/generic/167      |    2 +
 tests/generic/1835     |   65 ++++++++++++++++++++++++++++++++++++++++++++++++
 tests/generic/1835.out |    4 +++
 tests/generic/333      |    2 +
 tests/generic/334      |    2 +
 tests/generic/671      |    2 +
 tests/xfs/176          |    2 +
 tests/xfs/270          |    3 +-
 10 files changed, 85 insertions(+), 7 deletions(-)
 create mode 100755 tests/generic/1835
 create mode 100644 tests/generic/1835.out

[PATCH 1/4] xfs/270: fix rocompat regex

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

This test fails with the fsverity patchset because the rocompat feature
bit for verity is 0x10.  The regular expression used to check if the
output is hexadecimal requires a single-digit answer, which is no longer
the case.

Fixes: 5bb78c56ef ("xfs/270: Fix ro mount failure when nrext64 option is enabled")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 tests/xfs/270 |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


diff --git a/tests/xfs/270 b/tests/xfs/270
index 4e4f767dc1..16e508035a 100755
--- a/tests/xfs/270
+++ b/tests/xfs/270
@@ -30,8 +30,9 @@ _require_scratch_shutdown
 # change this case.
 set_bad_rocompat() {
 	ro_compat=$(_scratch_xfs_get_metadata_field "features_ro_compat" "sb 0")
-	echo $ro_compat | grep -q -E '^0x[[:xdigit:]]$'
+	echo $ro_compat | grep -q -E '^0x[[:xdigit:]]+$'
 	if [[ $? != 0  ]]; then
+		echo ":$ro_compat:"
 		echo "features_ro_compat has an invalid value."
 		return 1
 	fi

[PATCH v1.1 1/4] xfs/270: fix rocompat regex

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

This test fails with the fsverity patchset because the rocompat feature
bit for verity is 0x10.  The regular expression used to check if the
output is hexadecimal requires a single-digit answer, which is no longer
the case.

Fixes: 5bb78c56ef ("xfs/270: Fix ro mount failure when nrext64 option is enabled")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
v1.1: remove debug message
---
 tests/xfs/270 |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/xfs/270 b/tests/xfs/270
index 4e4f767dc1..0c3ddc5b61 100755
--- a/tests/xfs/270
+++ b/tests/xfs/270
@@ -30,7 +30,7 @@ _require_scratch_shutdown
 # change this case.
 set_bad_rocompat() {
 	ro_compat=$(_scratch_xfs_get_metadata_field "features_ro_compat" "sb 0")
-	echo $ro_compat | grep -q -E '^0x[[:xdigit:]]$'
+	echo $ro_compat | grep -q -E '^0x[[:xdigit:]]+$'
 	if [[ $? != 0  ]]; then
 		echo "features_ro_compat has an invalid value."
 		return 1

Re: [PATCH v1.1 1/4] xfs/270: fix rocompat regex

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

[PATCH 2/4] xfs/176: fix stupid failure

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

Create the $SCRATCH_MNT/urk directory before we fill the filesystem so
that its creation won't fail and result in find spraying ENOENT errors
all over the golden output.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 tests/xfs/176 |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/tests/xfs/176 b/tests/xfs/176
index 5231b888ba..49f7492c03 100755
--- a/tests/xfs/176
+++ b/tests/xfs/176
@@ -51,7 +51,7 @@ _scratch_mount
 _xfs_force_bdev data $SCRATCH_MNT
 old_dblocks=$($XFS_IO_PROG -c 'statfs' $SCRATCH_MNT | grep geom.datablocks)
 
-mkdir $SCRATCH_MNT/save/
+mkdir $SCRATCH_MNT/save/ $SCRATCH_MNT/urk/
 sino=$(stat -c '%i' $SCRATCH_MNT/save)
 
 _consume_freesp()

Re: [PATCH 2/4] xfs/176: fix stupid failure

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

[PATCH 3/4] generic/{166,167,333,334,671}: actually fill the filesystem with snapshots

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

XFS has this behavior in its reflink implementation where it returns
ENOSPC if one of the AGs that would be involved in the sharing operation
becomes more than 90% full.  As Kent Overstreet points out, that means
the snapshot creator shuts down when the filesystem is only about a
third full.  We could exercise the system harder by not *forcing*
reflink, which will actually fill the filesystem full.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 common/reflink    |    8 ++++++++
 tests/generic/166 |    2 +-
 tests/generic/167 |    2 +-
 tests/generic/333 |    2 +-
 tests/generic/334 |    2 +-
 tests/generic/671 |    2 +-
 6 files changed, 13 insertions(+), 5 deletions(-)


diff --git a/common/reflink b/common/reflink
index 22adc4449b..8f30dc6784 100644
--- a/common/reflink
+++ b/common/reflink
@@ -226,6 +226,14 @@ _cp_reflink() {
 	cp --reflink=always -p -f "$file1" "$file2"
 }
 
+# Create file2 as a snapshot of file1 via cp and possibly reflink.
+_reflink_snapshot() {
+	file1="$1"
+	file2="$2"
+
+	cp --reflink=auto -p -f "$file1" "$file2"
+}
+
 # Reflink some file1 into file2
 _reflink() {
 	file1="$1"
diff --git a/tests/generic/166 b/tests/generic/166
index 0eb2ec9c3a..941b51b3f1 100755
--- a/tests/generic/166
+++ b/tests/generic/166
@@ -60,7 +60,7 @@ snappy() {
 			sleep 0.01
 			continue;
 		fi
-		out="$(_cp_reflink $testdir/file1 $testdir/snap_$n 2>&1)"
+		out="$(_reflink_snapshot $testdir/file1 $testdir/snap_$n 2>&1)"
 		res=$?
 		echo "$out" | grep -q "No space left" && break
 		test -n "$out" && echo "$out"
diff --git a/tests/generic/167 b/tests/generic/167
index ae5fa5eb1c..3670940825 100755
--- a/tests/generic/167
+++ b/tests/generic/167
@@ -50,7 +50,7 @@ _scratch_cycle_mount
 snappy() {
 	n=0
 	while [ ! -e $finished_file ]; do
-		out="$(_cp_reflink $testdir/file1 $testdir/snap_$n 2>&1)"
+		out="$(_reflink_snapshot $testdir/file1 $testdir/snap_$n 2>&1)"
 		res=$?
 		echo "$out" | grep -q "No space left" && break
 		test -n "$out" && echo "$out"
diff --git a/tests/generic/333 b/tests/generic/333
index bf1967ce29..19e69993a3 100755
--- a/tests/generic/333
+++ b/tests/generic/333
@@ -53,7 +53,7 @@ _scratch_cycle_mount
 snappy() {
 	n=0
 	while [ ! -e $finished_file ]; do
-		out="$(_cp_reflink $testdir/file1 $testdir/snap_$n 2>&1)"
+		out="$(_reflink_snapshot $testdir/file1 $testdir/snap_$n 2>&1)"
 		res=$?
 		echo $out | grep -q "No space left" && break
 		test -n "$out" && echo $out
diff --git a/tests/generic/334 b/tests/generic/334
index b9c14b87ac..1e4d37b415 100755
--- a/tests/generic/334
+++ b/tests/generic/334
@@ -52,7 +52,7 @@ _scratch_cycle_mount
 snappy() {
 	n=0
 	while [ ! -e $finished_file ]; do
-		out="$(_cp_reflink $testdir/file1 $testdir/snap_$n 2>&1)"
+		out="$(_reflink_snapshot $testdir/file1 $testdir/snap_$n 2>&1)"
 		res=$?
 		echo $out | grep -q "No space left" && break
 		test -n "$out" && echo $out
diff --git a/tests/generic/671 b/tests/generic/671
index b6cc0573f3..24ed24e213 100755
--- a/tests/generic/671
+++ b/tests/generic/671
@@ -41,7 +41,7 @@ _scratch_cycle_mount
 snappy() {
 	n=0
 	while [ ! -e $finished_file ]; do
-		out="$(_cp_reflink $testdir/file1 $testdir/snap_$n 2>&1)"
+		out="$(_reflink_snapshot $testdir/file1 $testdir/snap_$n 2>&1)"
 		res=$?
 		echo "$out" | grep -q "No space left" && break
 		test -n "$out" && echo "$out"

Re: [PATCH 3/4] generic/{166,167,333,334,671}: actually fill the filesystem with snapshots

[Christoph Hellwig]

On Tue, Mar 26, 2024 at 07:43:35PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> XFS has this behavior in its reflink implementation where it returns
> ENOSPC if one of the AGs that would be involved in the sharing operation
> becomes more than 90% full.  As Kent Overstreet points out, that means
> the snapshot creator shuts down when the filesystem is only about a
> third full.  We could exercise the system harder by not *forcing*
> reflink, which will actually fill the filesystem full.

All these tests are supposed to test the reflink code, how does
using cp --reflink=auto make sense for that?

Re: [PATCH 3/4] generic/{166,167,333,334,671}: actually fill the filesystem with snapshots

[Darrick J. Wong]

On Wed, Mar 27, 2024 at 09:59:13AM -0700, Christoph Hellwig wrote:
> On Tue, Mar 26, 2024 at 07:43:35PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > XFS has this behavior in its reflink implementation where it returns
> > ENOSPC if one of the AGs that would be involved in the sharing operation
> > becomes more than 90% full.  As Kent Overstreet points out, that means
> > the snapshot creator shuts down when the filesystem is only about a
> > third full.  We could exercise the system harder by not *forcing*
> > reflink, which will actually fill the filesystem full.
> 
> All these tests are supposed to test the reflink code, how does
> using cp --reflink=auto make sense for that?

Hmm.  Well my initial thought was that the snapshot could fall back to
buffered copies of file1 so that we wouldn't abort the test well before
actually filling up the filesystem.

But you're right that my solution smells off -- we want to test reflink
dealing with ENOSPC.  Perhaps the right thing to do is to truncate and
rewrite file1 after a _cp_reflink fails, so that the next time through
the loop we'll be reflinking extents from a (probably less full) AG.

Ok let's see how that does.

--D

Re: [PATCH 3/4] generic/{166,167,333,334,671}: actually fill the filesystem with snapshots

[Christoph Hellwig]

On Fri, Mar 29, 2024 at 04:07:20PM -0700, Darrick J. Wong wrote:
> Hmm.  Well my initial thought was that the snapshot could fall back to
> buffered copies of file1 so that we wouldn't abort the test well before
> actually filling up the filesystem.

Btw, can we please stop sing snaphot in the test description for
reflink copies?  That's a really confusing term to use in this context..

> But you're right that my solution smells off -- we want to test reflink
> dealing with ENOSPC.  Perhaps the right thing to do is to truncate and
> rewrite file1 after a _cp_reflink fails, so that the next time through
> the loop we'll be reflinking extents from a (probably less full) AG.

That does sound better.

Re: [PATCH 3/4] generic/{166,167,333,334,671}: actually fill the filesystem with snapshots

[Zorro Lang]

On Wed, Mar 27, 2024 at 09:59:13AM -0700, Christoph Hellwig wrote:
> On Tue, Mar 26, 2024 at 07:43:35PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > XFS has this behavior in its reflink implementation where it returns
> > ENOSPC if one of the AGs that would be involved in the sharing operation
> > becomes more than 90% full.  As Kent Overstreet points out, that means
> > the snapshot creator shuts down when the filesystem is only about a
> > third full.  We could exercise the system harder by not *forcing*
> > reflink, which will actually fill the filesystem full.
> 
> All these tests are supposed to test the reflink code, how does
> using cp --reflink=auto make sense for that?

/me feel confusion too:)

I'll merge other 3 patches of this patchset at first. Feel free to re-send
this patch in another PATCHSET later.

Thanks,
Zorro

> 

[PATCH 4/4] generic: test MADV_POPULATE_READ with IO errors

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

This is a regression test for "mm/madvise: make
MADV_POPULATE_(READ|WRITE) handle VM_FAULT_RETRY properly".

Cc: David Hildenbrand <david@redhat.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 tests/generic/1835     |   65 ++++++++++++++++++++++++++++++++++++++++++++++++
 tests/generic/1835.out |    4 +++
 2 files changed, 69 insertions(+)
 create mode 100755 tests/generic/1835
 create mode 100644 tests/generic/1835.out


diff --git a/tests/generic/1835 b/tests/generic/1835
new file mode 100755
index 0000000000..07479ab712
--- /dev/null
+++ b/tests/generic/1835
@@ -0,0 +1,65 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2024 Oracle.  All Rights Reserved.
+#
+# FS QA Test 1835
+#
+# This is a regression test for a kernel hang that I saw when creating a memory
+# mapping, injecting EIO errors on the block device, and invoking
+# MADV_POPULATE_READ on the mapping to fault in the pages.
+#
+. ./common/preamble
+_begin_fstest auto rw
+
+# Override the default cleanup function.
+_cleanup()
+{
+	cd /
+	rm -f $tmp.*
+	_dmerror_unmount
+	_dmerror_cleanup
+}
+
+# Import common functions.
+. ./common/dmerror
+
+_fixed_by_kernel_commit XXXXXXXXXXXX \
+	"mm/madvise: make MADV_POPULATE_(READ|WRITE) handle VM_FAULT_RETRY properly"
+
+# real QA test starts here
+
+# Modify as appropriate.
+_supported_fs generic
+_require_xfs_io_command madvise -R
+_require_scratch
+_require_dm_target error
+_require_command "$TIMEOUT_PROG" "timeout"
+
+_scratch_mkfs >> $seqres.full 2>&1
+_dmerror_init
+
+filesz=2m
+
+# Create a file that we'll read, then cycle mount to zap pagecache
+_dmerror_mount
+$XFS_IO_PROG -f -c "pwrite -S 0x58 0 $filesz" "$SCRATCH_MNT/a" >> $seqres.full
+_dmerror_unmount
+_dmerror_mount
+
+# Try to read the file data in a regular fashion just to prove that it works.
+echo read with no errors
+timeout -s KILL 10s $XFS_IO_PROG -c "mmap -r 0 $filesz" -c "madvise -R 0 $filesz" "$SCRATCH_MNT/a"
+_dmerror_unmount
+_dmerror_mount
+
+# Load file metadata and induce EIO errors on read.  Try to provoke the kernel;
+# kill the process after 10s so we can clean up.
+stat "$SCRATCH_MNT/a" >> $seqres.full
+echo read with IO errors
+_dmerror_load_error_table
+timeout -s KILL 10s $XFS_IO_PROG -c "mmap -r 0 $filesz" -c "madvise -R 0 $filesz" "$SCRATCH_MNT/a"
+_dmerror_load_working_table
+
+# success, all done
+status=0
+exit
diff --git a/tests/generic/1835.out b/tests/generic/1835.out
new file mode 100644
index 0000000000..1b03586e8c
--- /dev/null
+++ b/tests/generic/1835.out
@@ -0,0 +1,4 @@
+QA output created by 1835
+read with no errors
+read with IO errors
+madvise: Bad address

Re: [PATCH 4/4] generic: test MADV_POPULATE_READ with IO errors

[Zorro Lang]

On Tue, Mar 26, 2024 at 07:43:41PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> This is a regression test for "mm/madvise: make
> MADV_POPULATE_(READ|WRITE) handle VM_FAULT_RETRY properly".
> 
> Cc: David Hildenbrand <david@redhat.com>
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> ---
>  tests/generic/1835     |   65 ++++++++++++++++++++++++++++++++++++++++++++++++
>  tests/generic/1835.out |    4 +++
>  2 files changed, 69 insertions(+)
>  create mode 100755 tests/generic/1835
>  create mode 100644 tests/generic/1835.out
> 
> 
> diff --git a/tests/generic/1835 b/tests/generic/1835
> new file mode 100755
> index 0000000000..07479ab712
> --- /dev/null
> +++ b/tests/generic/1835
> @@ -0,0 +1,65 @@
> +#! /bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2024 Oracle.  All Rights Reserved.
> +#
> +# FS QA Test 1835
> +#
> +# This is a regression test for a kernel hang that I saw when creating a memory
> +# mapping, injecting EIO errors on the block device, and invoking
> +# MADV_POPULATE_READ on the mapping to fault in the pages.
> +#
> +. ./common/preamble
> +_begin_fstest auto rw
                         ^^ eio

> +
> +# Override the default cleanup function.
> +_cleanup()
> +{
> +	cd /
> +	rm -f $tmp.*
> +	_dmerror_unmount
> +	_dmerror_cleanup
> +}
> +
> +# Import common functions.
> +. ./common/dmerror
> +
> +_fixed_by_kernel_commit XXXXXXXXXXXX \
> +	"mm/madvise: make MADV_POPULATE_(READ|WRITE) handle VM_FAULT_RETRY properly"
> +
> +# real QA test starts here
> +
> +# Modify as appropriate.
> +_supported_fs generic
> +_require_xfs_io_command madvise -R
> +_require_scratch
> +_require_dm_target error
> +_require_command "$TIMEOUT_PROG" "timeout"
> +
> +_scratch_mkfs >> $seqres.full 2>&1
> +_dmerror_init
> +
> +filesz=2m
> +
> +# Create a file that we'll read, then cycle mount to zap pagecache
> +_dmerror_mount
> +$XFS_IO_PROG -f -c "pwrite -S 0x58 0 $filesz" "$SCRATCH_MNT/a" >> $seqres.full
> +_dmerror_unmount
> +_dmerror_mount
> +
> +# Try to read the file data in a regular fashion just to prove that it works.
> +echo read with no errors
> +timeout -s KILL 10s $XFS_IO_PROG -c "mmap -r 0 $filesz" -c "madvise -R 0 $filesz" "$SCRATCH_MNT/a"

timeout -> $TIMEOUT_PROG

Others looks good to me, if there's not more review points, I'll merge this
patch with above changes, after testing done.

Reviewed-by: Zorro Lang <zlang@redhat.com>

Thanks,
Zorro

> +_dmerror_unmount
> +_dmerror_mount
> +
> +# Load file metadata and induce EIO errors on read.  Try to provoke the kernel;
> +# kill the process after 10s so we can clean up.
> +stat "$SCRATCH_MNT/a" >> $seqres.full
> +echo read with IO errors
> +_dmerror_load_error_table
> +timeout -s KILL 10s $XFS_IO_PROG -c "mmap -r 0 $filesz" -c "madvise -R 0 $filesz" "$SCRATCH_MNT/a"
> +_dmerror_load_working_table
> +
> +# success, all done
> +status=0
> +exit
> diff --git a/tests/generic/1835.out b/tests/generic/1835.out
> new file mode 100644
> index 0000000000..1b03586e8c
> --- /dev/null
> +++ b/tests/generic/1835.out
> @@ -0,0 +1,4 @@
> +QA output created by 1835
> +read with no errors
> +read with IO errors
> +madvise: Bad address
> 

Re: [PATCH 4/4] generic: test MADV_POPULATE_READ with IO errors

[Darrick J. Wong]

On Sat, Mar 30, 2024 at 03:12:00PM +0800, Zorro Lang wrote:
> On Tue, Mar 26, 2024 at 07:43:41PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > This is a regression test for "mm/madvise: make
> > MADV_POPULATE_(READ|WRITE) handle VM_FAULT_RETRY properly".
> > 
> > Cc: David Hildenbrand <david@redhat.com>
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > ---
> >  tests/generic/1835     |   65 ++++++++++++++++++++++++++++++++++++++++++++++++
> >  tests/generic/1835.out |    4 +++
> >  2 files changed, 69 insertions(+)
> >  create mode 100755 tests/generic/1835
> >  create mode 100644 tests/generic/1835.out
> > 
> > 
> > diff --git a/tests/generic/1835 b/tests/generic/1835
> > new file mode 100755
> > index 0000000000..07479ab712
> > --- /dev/null
> > +++ b/tests/generic/1835
> > @@ -0,0 +1,65 @@
> > +#! /bin/bash
> > +# SPDX-License-Identifier: GPL-2.0
> > +# Copyright (c) 2024 Oracle.  All Rights Reserved.
> > +#
> > +# FS QA Test 1835
> > +#
> > +# This is a regression test for a kernel hang that I saw when creating a memory
> > +# mapping, injecting EIO errors on the block device, and invoking
> > +# MADV_POPULATE_READ on the mapping to fault in the pages.
> > +#
> > +. ./common/preamble
> > +_begin_fstest auto rw
>                          ^^ eio
> 
> > +
> > +# Override the default cleanup function.
> > +_cleanup()
> > +{
> > +	cd /
> > +	rm -f $tmp.*
> > +	_dmerror_unmount
> > +	_dmerror_cleanup
> > +}
> > +
> > +# Import common functions.
> > +. ./common/dmerror
> > +
> > +_fixed_by_kernel_commit XXXXXXXXXXXX \
> > +	"mm/madvise: make MADV_POPULATE_(READ|WRITE) handle VM_FAULT_RETRY properly"
> > +
> > +# real QA test starts here
> > +
> > +# Modify as appropriate.
> > +_supported_fs generic
> > +_require_xfs_io_command madvise -R
> > +_require_scratch
> > +_require_dm_target error
> > +_require_command "$TIMEOUT_PROG" "timeout"
> > +
> > +_scratch_mkfs >> $seqres.full 2>&1
> > +_dmerror_init
> > +
> > +filesz=2m
> > +
> > +# Create a file that we'll read, then cycle mount to zap pagecache
> > +_dmerror_mount
> > +$XFS_IO_PROG -f -c "pwrite -S 0x58 0 $filesz" "$SCRATCH_MNT/a" >> $seqres.full
> > +_dmerror_unmount
> > +_dmerror_mount
> > +
> > +# Try to read the file data in a regular fashion just to prove that it works.
> > +echo read with no errors
> > +timeout -s KILL 10s $XFS_IO_PROG -c "mmap -r 0 $filesz" -c "madvise -R 0 $filesz" "$SCRATCH_MNT/a"
> 
> timeout -> $TIMEOUT_PROG
> 
> Others looks good to me, if there's not more review points, I'll merge this
> patch with above changes, after testing done.

Ok.  I don't have any further changes to make to this test, other than
the XXXXX above whenever the fixes get merged.

--D

> Reviewed-by: Zorro Lang <zlang@redhat.com>
> 
> Thanks,
> Zorro
> 
> > +_dmerror_unmount
> > +_dmerror_mount
> > +
> > +# Load file metadata and induce EIO errors on read.  Try to provoke the kernel;
> > +# kill the process after 10s so we can clean up.
> > +stat "$SCRATCH_MNT/a" >> $seqres.full
> > +echo read with IO errors
> > +_dmerror_load_error_table
> > +timeout -s KILL 10s $XFS_IO_PROG -c "mmap -r 0 $filesz" -c "madvise -R 0 $filesz" "$SCRATCH_MNT/a"
> > +_dmerror_load_working_table
> > +
> > +# success, all done
> > +status=0
> > +exit
> > diff --git a/tests/generic/1835.out b/tests/generic/1835.out
> > new file mode 100644
> > index 0000000000..1b03586e8c
> > --- /dev/null
> > +++ b/tests/generic/1835.out
> > @@ -0,0 +1,4 @@
> > +QA output created by 1835
> > +read with no errors
> > +read with IO errors
> > +madvise: Bad address
> > 
> 
>