]> git.karo-electronics.de Git - karo-tx-linux.git/commit
loop: Make explicit loop device destruction lazy
authorDave Chinner <dchinner@redhat.com>
Fri, 28 Sep 2012 08:42:23 +0000 (10:42 +0200)
committerJens Axboe <axboe@kernel.dk>
Fri, 28 Sep 2012 08:42:23 +0000 (10:42 +0200)
commitfab74e7a8f0f8d0af2356c28aa60d55f9e6f5f8b
tree2fdef3ff9097ef1d7f1483b5fbf74912d8cd01c3
parent75e1528770698bf9e3c264a657c8be162cb71e16
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>
drivers/block/loop.c