generic/038: Avoid EBUSY errors on umount

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>
Acked-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

diff --git a/tests/generic/038 b/tests/generic/038
index 59aed67ab2ffb0035e0f1b98b6a0146ceca77267..025e1b0fe7a6c95d6e28a7af4577b8eaf2627831 100755 (executable)
--- 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