From: Eryu Guan <guaneryu@gmail.com>
To: kaixuxia <xiakaixu1987@gmail.com>
Cc: fstests@vger.kernel.org, linux-xfs@vger.kernel.org,
"Darrick J. Wong" <darrick.wong@oracle.com>,
newtongao@tencent.com, jasperwang@tencent.com
Subject: Re: [PATCH] xfs: test the deadlock between the AGI and AGF with RENAME_WHITEOUT
Date: Sun, 8 Sep 2019 20:39:39 +0800 [thread overview]
Message-ID: <20190908123939.GG2622@desktop> (raw)
In-Reply-To: <59006cf8-f825-d33f-c860-111189689e2e@gmail.com>
On Wed, Sep 04, 2019 at 06:01:27PM +0800, kaixuxia wrote:
> There is ABBA deadlock bug between the AGI and AGF when performing
> rename() with RENAME_WHITEOUT flag, and add this testcase to make
> sure the rename() call works well.
>
> Signed-off-by: kaixuxia <kaixuxia@tencent.com>
> ---
> tests/xfs/512 | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> tests/xfs/512.out | 2 ++
> tests/xfs/group | 1 +
> 3 files changed, 103 insertions(+)
> create mode 100755 tests/xfs/512
> create mode 100644 tests/xfs/512.out
>
> diff --git a/tests/xfs/512 b/tests/xfs/512
> new file mode 100755
> index 0000000..0e95fb7
> --- /dev/null
> +++ b/tests/xfs/512
> @@ -0,0 +1,100 @@
> +#! /bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2019 Tencent. All Rights Reserved.
> +#
> +# FS QA Test 512
> +#
> +# Test the ABBA deadlock case between the AGI and AGF When performing
> +# rename operation with RENAME_WHITEOUT flag.
> +#
> +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
> +
> +rm -f $seqres.full
> +
> +# real QA test starts here
> +_supported_fs xfs
> +_supported_os Linux
> +_require_scratch
Only _require_scratch_nocheck is suffiecient.
> +
> +# Single AG will cause default xfs_repair to fail. This test need a
> +# single AG fs, so ignore the check.
> +_require_scratch_nocheck
Also need to
. ./common/rename
...
_requires_renameat2
Also, this test requires RENAME_WHITEOUT, I'd suggest enhance
src/renameat2.c to support check for if a given rename flag is supported
by kernel, and refactor the checks in generic/02[45] and generic/078
into _requires_renameat2 to use the new functionality. e.g.
# without option, behavior stays unchanged, check for renameat2 syscall
# support
_requires_renameat2
# check if renameat2 upports RENAME_WHITEOUT flag
_requires_renameat2 whiteout
# check if renameat2 upports RENAME_EXCHANGE flag
_requires_renameat2 exchange
> +
> +prepare_file()
> +{
> + # create many small files for the rename with RENAME_WHITEOUT
> + i=0
> + while [ $i -le $files ]; do
> + file=$SCRATCH_MNT/f$i
> + $XFS_IO_PROG -f -d -c 'pwrite -b 4k 0 4k' $file >/dev/null 2>&1
> + let i=$i+1
Creating 250000 4k files take a long time. Does file content really
matters? I guess racing RENAME_WHITEOUT with file creation is enough, is
it possible to just create many empty files? e.g.
echo > $file
this saves a lot time.
> + done
> +}
> +
> +rename_whiteout()
> +{
> + # create the rename targetdir
> + renamedir=$SCRATCH_MNT/renamedir
> + mkdir $renamedir
> +
> + # just get a random long name...
> + longnamepre=FFFsafdsagafsadfagasdjfalskdgakdlsglkasdg
Better to explain why long file name is required.
> +
> + # now try to do rename with RENAME_WHITEOUT flag
> + i=0
> + while [ $i -le $files ]; do
> + src/renameat2 -w $SCRATCH_MNT/f$i $renamedir/$longnamepre$i >/dev/null 2>&1
> + let i=$i+1
> + done
> +}
> +
> +create_file()
> +{
> + # create the targetdir
> + createdir=$SCRATCH_MNT/createdir
> + mkdir $createdir
> +
> + # try to create file at the same time to hit the deadlock
> + i=0
> + while [ $i -le $files ]; do
> + file=$createdir/f$i
> + $XFS_IO_PROG -f -d -c 'pwrite -b 4k 0 4k' $file >/dev/null 2>&1
> + let i=$i+1
> + done
Same here, does creating empty files work?
> +}
> +
> +_scratch_mkfs_xfs -bsize=512 -dagcount=1 >> $seqres.full 2>&1 ||
This doesn't work because crc is on by default, as crc requires minimum
1k block size. Is 512 block size really needed?
> + _fail "mkfs failed"
> +_scratch_mount
> +
> +files=250000
If we could reduce file number to create, test could run faster as well.
Running test with less than 250000 files couldn't reproduce the
deadlock?
Thanks,
Eryu
> +
> +prepare_file
> +rename_whiteout &
> +create_file &
> +
> +wait
> +echo Silence is golden
> +
> +# Failure comes in the form of a deadlock.
> +
> +# success, all done
> +status=0
> +exit
> diff --git a/tests/xfs/512.out b/tests/xfs/512.out
> new file mode 100644
> index 0000000..0aabdef
> --- /dev/null
> +++ b/tests/xfs/512.out
> @@ -0,0 +1,2 @@
> +QA output created by 512
> +Silence is golden
> diff --git a/tests/xfs/group b/tests/xfs/group
> index a7ad300..ed250d6 100644
> --- a/tests/xfs/group
> +++ b/tests/xfs/group
> @@ -509,3 +509,4 @@
> 509 auto ioctl
> 510 auto ioctl quick
> 511 auto quick quota
> +512 auto rename
> --
> 1.8.3.1
>
> --
> kaixuxia
next prev parent reply other threads:[~2019-09-08 12:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-04 10:01 [PATCH] xfs: test the deadlock between the AGI and AGF with RENAME_WHITEOUT kaixuxia
2019-09-08 12:39 ` Eryu Guan [this message]
2019-09-09 9:06 ` kaixuxia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190908123939.GG2622@desktop \
--to=guaneryu@gmail.com \
--cc=darrick.wong@oracle.com \
--cc=fstests@vger.kernel.org \
--cc=jasperwang@tencent.com \
--cc=linux-xfs@vger.kernel.org \
--cc=newtongao@tencent.com \
--cc=xiakaixu1987@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox