aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/block
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2012-09-28 04:42:23 -0400
committerJens Axboe <axboe@kernel.dk>2012-10-30 03:37:31 -0400
commita1ecac3b0656a68259927c234e505804d33a7b83 (patch)
tree169ee21f1d2a2cfb9c143fefec6fc1eccf2df9b6 /drivers/block
parent4453bc88f0f7be6d84b50b2e1c1ed239c45fb14a (diff)
loop: Make explicit loop device destruction lazy
xfstests has always had random failures of tests due to loop devices failing to be torn down and hence leaving filesytems that cannot be unmounted. This causes test runs to immediately stop. Over the past 6 or 7 years we've added hacks like explicit unmount -d commands for loop mounts, losetup -d after unmount -d fails, etc, but still the problems persist. Recently, the frequency of loop related failures increased again to the point that xfstests 259 will reliably fail with a stray loop device that was not torn down. That is despite the fact the test is above as simple as it gets - loop 5 or 6 times running mkfs.xfs with different paramters: lofile=$(losetup -f) losetup $lofile "$testfile" "$MKFS_XFS_PROG" -b size=512 $lofile >/dev/null || echo "mkfs failed!" sync losetup -d $lofile And losteup -d $lofile is failing with EBUSY on 1-3 of these loops every time the test is run. Turns out that blkid is running simultaneously with losetup -d, and so it sees an elevated reference count and returns EBUSY. But why is blkid running? It's obvious, isn't it? udev has decided to try and find out what is on the block device as a result of a creation notification. And it is racing with mkfs, so might still be scanning the device when mkfs finishes and we try to tear it down. So, make losetup -d force autoremove behaviour. That is, when the last reference goes away, tear down the device. xfstests wants it *gone*, not causing random teardown failures when we know that all the operations the tests have specifically run on the device have completed and are no longer referencing the loop device. Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'drivers/block')
-rw-r--r--drivers/block/loop.c17
1 files changed, 15 insertions, 2 deletions
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index e9d594fd12cb..54046e51160a 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -976,8 +976,21 @@ static int loop_clr_fd(struct loop_device *lo)
976 if (lo->lo_state != Lo_bound) 976 if (lo->lo_state != Lo_bound)
977 return -ENXIO; 977 return -ENXIO;
978 978
979 if (lo->lo_refcnt > 1) /* we needed one fd for the ioctl */ 979 /*
980 return -EBUSY; 980 * If we've explicitly asked to tear down the loop device,
981 * and it has an elevated reference count, set it for auto-teardown when
982 * the last reference goes away. This stops $!~#$@ udev from
983 * preventing teardown because it decided that it needs to run blkid on
984 * the loopback device whenever they appear. xfstests is notorious for
985 * failing tests because blkid via udev races with a losetup
986 * <dev>/do something like mkfs/losetup -d <dev> causing the losetup -d
987 * command to fail with EBUSY.
988 */
989 if (lo->lo_refcnt > 1) {
990 lo->lo_flags |= LO_FLAGS_AUTOCLEAR;
991 mutex_unlock(&lo->lo_ctl_mutex);
992 return 0;
993 }
981 994
982 if (filp == NULL) 995 if (filp == NULL)
983 return -EINVAL; 996 return -EINVAL;