[PATCH v1.1 1/8] generic/604: try to make race occur reliably

["Darrick J. Wong" <djwong@kernel.org>]

This test will occasionaly fail like so:

  --- /tmp/fstests/tests/generic/604.out	2024-02-03 12:08:52.349924277 -0800
  +++ /var/tmp/fstests/generic/604.out.bad	2024-02-05 04:35:55.020000000 -0800
  @@ -1,2 +1,5 @@
   QA output created by 604
  -Silence is golden
  +mount: /opt: /dev/sda4 already mounted on /opt.
  +       dmesg(1) may have more information after failed mount system call.
  +mount -o usrquota,grpquota,prjquota, /dev/sda4 /opt failed
  +(see /var/tmp/fstests/generic/604.full for details)

As far as I can tell, the cause of this seems to be _scratch_mount
getting forked and exec'd before the backgrounded umount process has a
chance to enter the kernel.  When this occurs, the mount() system call
will return -EBUSY because this isn't an attempt to make a bind mount.
Slow things down slightly by stalling the mount by 10ms.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
v1.1: indent commit message, fix busted comment
---
 tests/generic/604 |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tests/generic/604 b/tests/generic/604
index cc6a4b214f..00da56dd70 100755
--- a/tests/generic/604
+++ b/tests/generic/604
@@ -24,10 +24,12 @@ _scratch_mount
 for i in $(seq 0 500); do
 	$XFS_IO_PROG -f -c "pwrite 0 4K" $SCRATCH_MNT/$i >/dev/null
 done
-# For overlayfs, avoid unmouting the base fs after _scratch_mount
-# tries to mount the base fs
+# For overlayfs, avoid unmouting the base fs after _scratch_mount tries to
+# mount the base fs.  Delay the mount attempt by a small amount in the hope
+# that the mount() call will try to lock s_umount /after/ umount has already
+# taken it.
 $UMOUNT_PROG $SCRATCH_MNT &
-_scratch_mount
+sleep 0.01s ; _scratch_mount
 wait
 
 echo "Silence is golden"