On Thu, Mar 17, 2016 at 11:44:29AM +0530, Chandan Rajendra wrote: > The following scenario can occur when running btrfs/066, > > Task A Task B Task C > > run_test() > - Execute _btrfs_stress_subvolume() > in a background shell. > _btrfs_stress_subvolme() > ... > - fork & exec "mount" > Mount subvolume on directory in $TEST_DIR > - Wait for fsstress to finish do_mount() > - kill shell process executing - btrfs_mount() > _btrfs_stress_subvolume() > i.e. Task B. > - Init process becomes the parent > of "subvolume mount" task > i.e. Task C. > - In case subvolume is mounted > (which is not the case), > unmount it. > - Complete mounting subvolume > > Hence on the completion of one iteration of run_test(), the subvolume > created inside the filesystem on $SCRATCH_DEV continues to be mounted on > $TEST_DIR/$seq.mnt. Subsequent invocations of run_test() (called for > remaining Btrfs profile configs) fail during _scratch_pool_mkfs. > > Instead of killing the 'subvolume stress' task, This commit uses a named > pipe to inform the 'subvolume stress' task to break out of the infinite > loop and exit. A named pipe seems too heavy and complicated to me. How about breaking out the loop in _btrfs_stress_subvolume on the existence of some file? e.g. _btrfs_stress_subvolume(): ... local stop_file=$5 while [ ! -e $stop_file ]; do ... done run_test(): ... local stop_file=$TEST_DIR/$seq.stop.$$ ... # make sure the stop sign is not there rm -f $stop_file _btrfs_stress_subvolume $SCRATCH_DEV $SCRATCH_MNT subvol_$$ $subvol_mnt $stop_file & ... wait $fsstress_pid touch $stop_file kill $scrub_pid wait I didn't test it, as I can't reproduce the race, but I guess it should work :) Thanks, Eryu -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
