public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: fstests@vger.kernel.org
Cc: Jan Kara <jack@suse.cz>
Subject: [PATCH 5/5] generic/038: Avoid EBUSY errors on umount
Date: Mon, 18 Apr 2016 21:32:35 +0200	[thread overview]
Message-ID: <1461007955-7921-6-git-send-email-jack@suse.cz> (raw)
In-Reply-To: <1461007955-7921-1-git-send-email-jack@suse.cz>

Although the test waits for running subshells after sending SIGTERM
signal to them, it does not wait for subprocesses of those subshells
properly. Thus we can hit EBUSY errors when umount is called. Make
subshells wait for executed subprocesses when receiving SIGTERM to avoid
the problem.

Signed-off-by: Jan Kara <jack@suse.cz>
---
 tests/generic/038 | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/tests/generic/038 b/tests/generic/038
index 59aed67ab2ff..025e1b0fe7a6 100755
--- a/tests/generic/038
+++ b/tests/generic/038
@@ -77,6 +77,10 @@ rm -f $seqres.full
 # fstrim loop below.
 fallocate_loop()
 {
+	# Wait for running subcommand before exitting so that
+	# mountpoint is not busy when we try to unmount it
+	trap "wait; exit" SIGTERM
+
 	local name=$1
 	while true; do
 		$XFS_IO_PROG -f -c "falloc -k 0 1G" \
@@ -90,6 +94,10 @@ fallocate_loop()
 
 trim_loop()
 {
+	# Wait for running subcommand before exitting so that
+	# mountpoint is not busy when we try to unmount it
+	trap "wait; exit" SIGTERM
+
 	while true; do
 		$FSTRIM_PROG $SCRATCH_MNT
 	done
@@ -115,7 +123,9 @@ create_files()
 	for ((n = 0; n < 4; n++)); do
 		mkdir $SCRATCH_MNT/$n
 		(
-               for ((i = 1; i <= $nr_files; i++)); do
+		trap "wait; exit" SIGTERM
+
+		for ((i = 1; i <= $nr_files; i++)); do
 			$XFS_IO_PROG -f -c "pwrite -S 0xaa 0 3900" \
 				$SCRATCH_MNT/$n/"${prefix}_$i" &> /dev/null
 			if [ $? -ne 0 ]; then
@@ -152,9 +162,6 @@ kill ${fallocate_pids[@]}
 kill ${trim_pids[@]}
 wait
 
-# Sleep a bit, otherwise umount fails often with EBUSY (TODO: investigate why).
-sleep 3
-
 # The fstests framework will now check for fs consistency with fsck.
 # The trimming was racy and caused some btree nodes to get full of zeroes on
 # disk, which obviously caused fs metadata corruption. The race often lead
-- 
2.6.6


      parent reply	other threads:[~2016-04-18 19:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-18 19:32 [PATCH 1/5] More page fault stress tests and generic/038 fix Jan Kara
2016-04-18 19:32 ` [PATCH 1/5] generic/340: Remove second fallocate test Jan Kara
2016-04-18 19:32 ` [PATCH 2/5] generic/343: Test races between mmap and normal writes Jan Kara
2016-04-27 15:04   ` Brian Foster
2016-04-27 16:16     ` Jan Kara
2016-04-27 16:19       ` Jan Kara
2016-04-18 19:32 ` [PATCH 3/5] generic/344: Test races between mmap and normal write for prefaulted ranges Jan Kara
2016-04-18 19:32 ` [PATCH 4/5] generic/345: Test races between processes doing mmap writes Jan Kara
2016-04-18 19:32 ` Jan Kara [this message]

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=1461007955-7921-6-git-send-email-jack@suse.cz \
    --to=jack@suse.cz \
    --cc=fstests@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox