Re: [PATCH v2] generic: add a test for umount racing mount

[Eryu Guan <guan@eryu.me>]

[ cc'ed Amir for failure on overlayfs ]

On Fri, Jul 10, 2020 at 10:18:36AM -0700, Boris Burkov wrote:
> Test if dirtying many inodes (which can delay umount) then
> unmounting and quickly mounting again causes the mount to fail.
> 
> A race, which breaks the test in btrfs, is fixed by the patch:
> "btrfs: fix mount failure caused by race with umount"
> 
> Signed-off-by: Boris Burkov <boris@bur.io>
> ---
>  tests/generic/604     | 52 +++++++++++++++++++++++++++++++++++++++++++
>  tests/generic/604.out |  2 ++
>  tests/generic/group   |  1 +
>  3 files changed, 55 insertions(+)
>  create mode 100755 tests/generic/604
>  create mode 100644 tests/generic/604.out
> 
> diff --git a/tests/generic/604 b/tests/generic/604
> new file mode 100755
> index 00000000..e67899cb
> --- /dev/null
> +++ b/tests/generic/604
> @@ -0,0 +1,52 @@
> +#! /bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2020 Facebook  All Rights Reserved.
> +#
> +# FS QA Test 604
> +#
> +# Evicting dirty inodes can take a long time during umount.
> +# Check that a new mount racing with such a delayed umount succeeds.
> +#
> +seq=`basename $0`
> +seqres=$RESULT_DIR/$seq
> +echo "QA output created by $seq"
> +
> +here=`pwd`
> +tmp=/tmp/$$
> +status=1	# failure is the default!
> +trap "_cleanup; exit \$status" 0 1 2 3 15
> +
> +_cleanup()
> +{
> +	cd /
> +	rm -f $tmp.*
> +}
> +
> +# get standard environment, filters and checks
> +. ./common/rc
> +. ./common/filter
> +
> +# remove previous $seqres.full before test
> +rm -f $seqres.full
> +
> +# real QA test starts here
> +
> +# Modify as appropriate.
> +_supported_fs generic
> +_supported_os Linux
> +_require_test

Test takes use of scratch dev, but required test dev here.

> +
> +_scratch_mkfs > /dev/null 2>&1
> +_scratch_mount
> +for i in $(seq 0 500)
> +do
> +	dd if=/dev/zero of="$SCRATCH_MNT/$i" bs=1M count=1 > /dev/null 2>&1
> +done

The kernel patch describes that it only needs to make a bunch of inodes
dirty, so is it really necessary to write 500M data to the fs? Does
writing less files work (e.g. 50)? Or does writing less data work (e.g.
4k file)?

Also, fstests perfers code style like

for i in $(seq 0 500); do
	$XFS_IO_PROG -c "pwrite 0 1M" $SCRATCH_MNT/$i >/dev/null 2>&1
done

> +_scratch_unmount &
> +_scratch_mount

xfs and ext4 both passed this test, but overlayfs always fails the test.
I'm not sure if this is a valid test for overlay? Or it's just that
overlayfs should be fixed? Amir, any comments here?

Thanks,
Eryu

> +
> +echo "Silence is golden"
> +
> +# success, all done
> +status=0
> +exit
> diff --git a/tests/generic/604.out b/tests/generic/604.out
> new file mode 100644
> index 00000000..6810da89
> --- /dev/null
> +++ b/tests/generic/604.out
> @@ -0,0 +1,2 @@
> +QA output created by 604
> +Silence is golden
> diff --git a/tests/generic/group b/tests/generic/group
> index d9ab9a31..c0ace35b 100644
> --- a/tests/generic/group
> +++ b/tests/generic/group
> @@ -605,3 +605,4 @@
>  601 auto quick quota
>  602 auto quick encrypt
>  603 auto quick quota
> +604 auto quick
> -- 
> 2.24.1