All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: guaneryu@gmail.com, darrick.wong@oracle.com
Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org
Subject: [PATCH 1/3] generic/081: fix lvm config not being cleaned up properly
Date: Thu, 15 Aug 2019 08:18:59 -0700	[thread overview]
Message-ID: <156588233944.24775.714828611169800436.stgit@magnolia> (raw)
In-Reply-To: <156588233330.24775.15183725500886844319.stgit@magnolia>

From: Darrick J. Wong <darrick.wong@oracle.com>

Fix a race between _cleanup and dmeventd that causes the lvm
configuration not to be cleaned up and subsequent tests to fail.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
---
 tests/generic/081 |   29 +++++++++++++++++++++++------
 1 file changed, 23 insertions(+), 6 deletions(-)


diff --git a/tests/generic/081 b/tests/generic/081
index 10f4a186..e8f4f5b5 100755
--- a/tests/generic/081
+++ b/tests/generic/081
@@ -19,12 +19,29 @@ _cleanup()
 {
 	cd /
 	rm -f $tmp.*
-	# lvm may have umounted it on I/O error, but in case it does not
-	# wait a bit for lvm to settle, sigh..
-	sleep 2
-	$UMOUNT_PROG $mnt >/dev/null 2>&1
-	$LVM_PROG vgremove -f $vgname >>$seqres.full 2>&1
-	$LVM_PROG pvremove -f $SCRATCH_DEV >>$seqres.full 2>&1
+
+	# Tear down the lvm vg and snapshot.
+	#
+	# NOTE: We do the unmount and {vg,pv}remove in a loop here because
+	# dmeventd could be configured to unmount the filesystem automatically
+	# after the IO errors.  That is racy with the umount we're trying to do
+	# here because there's a window in which the directory tree has been
+	# removed from the mount namespaces (so the umount call here sees no
+	# mount and exits) but the filesystem hasn't yet released the block
+	# device, which causes the vgremove here to fail.
+	#
+	# We "solve" the race by repeating the umount/lvm teardown until the
+	# block device goes away, because we cannot exit this test without
+	# removing the lvm devices from the scratch device -- this will cause
+	# other tests to fail.
+	while test -e /dev/mapper/$vgname-$snapname || \
+	      test -e /dev/mapper/$vgname-$lvname; do
+		$UMOUNT_PROG $mnt >> $seqres.full 2>&1
+		$LVM_PROG vgremove -f $vgname >>$seqres.full 2>&1
+		$LVM_PROG pvremove -f $SCRATCH_DEV >>$seqres.full 2>&1
+		test $? -eq 0 && break
+		sleep 2
+	done
 }
 
 # get standard environment, filters and checks

  reply	other threads:[~2019-08-15 15:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-15 15:18 [PATCH 0/3] fstests: various fixes Darrick J. Wong
2019-08-15 15:18 ` Darrick J. Wong [this message]
2019-08-15 15:19 ` [PATCH 2/3] generic/561: kill duperemove directly Darrick J. Wong
2019-08-15 15:19 ` [PATCH 3/3] common: filter aiodio dmesg after fs/iomap.c to fs/iomap/ move Darrick J. Wong

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=156588233944.24775.714828611169800436.stgit@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=guaneryu@gmail.com \
    --cc=linux-xfs@vger.kernel.org \
    /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 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.