[PATCH] Allow auto-destruction of loop devices.
David Woodhouse
closed for the last time, they'll self-destruct.
Signed-off-by: David Woodhouse <dw...@infradead.org>
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 56e2304..7fae828 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -973,6 +973,10 @@ loop_set_status(struct loop_device *lo, const struct loop_info64 *info)
lo->transfer = xfer->transfer;
lo->ioctl = xfer->ioctl;
+ if ( (lo->lo_flags & LO_FLAGS_AUTOCLEAR) !=
+ (info->lo_flags & LO_FLAGS_AUTOCLEAR))
+ lo->lo_flags ^= LO_FLAGS_AUTOCLEAR;
+
lo->lo_encrypt_key_size = info->lo_encrypt_key_size;
lo->lo_init[0] = info->lo_init[0];
lo->lo_init[1] = info->lo_init[1];
@@ -1331,6 +1335,10 @@ static int lo_release(struct inode *inode, struct file *file)
mutex_lock(&lo->lo_ctl_mutex);
--lo->lo_refcnt;
+
+ if ((lo->lo_flags & LO_FLAGS_AUTOCLEAR) && !lo->lo_refcnt)
+ loop_clr_fd(lo, inode->i_bdev);
+
mutex_unlock(&lo->lo_ctl_mutex);
return 0;
diff --git a/include/linux/loop.h b/include/linux/loop.h
index 26a0a10..46169a7 100644
--- a/include/linux/loop.h
+++ b/include/linux/loop.h
@@ -76,6 +76,7 @@ struct loop_device {
enum {
LO_FLAGS_READ_ONLY = 1,
LO_FLAGS_USE_AOPS = 2,
+ LO_FLAGS_AUTOCLEAR = 4,
};
#include <asm/posix_types.h> /* for __kernel_old_dev_t */
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
David Woodhouse <dw...@infradead.org> wrote:
> This allows a flag to be set on loop devices so that when they are
> closed for the last time, they'll self-destruct.
>
Why do we want to do this?
Jan Engelhardt
On Oct 30 2007 13:01, Andrew Morton wrote:
>On Sun, 28 Oct 2007 19:08:31 -0400
>David Woodhouse <dw...@infradead.org> wrote:
>
>> This allows a flag to be set on loop devices so that when they are
>> closed for the last time, they'll self-destruct.
>>
>
>Why do we want to do this?
Off the top of my head, lazy unmounting comes to mind.
Think of this:
mount foobar /mnt -o loop;
cd /mnt;
umount /mnt;
Currently, this leaves /dev/loop0 assigned, either chewing up loop
places or needlessy exposing objects meant to be rather not
accessible. (Think cryptoloop devices -- and pam_mount.) BTW, such a
flag would also really be useful for dm(-crypt).
David Woodhouse
> Why do we want to do this?
In general, so that we can automatically allocate loop devices (as with
losetup -f) and have them disappear when we're done with them.
In particular, right now, so that we can stop relying on the hackish
special-case in umount(8) which kills off loop devices which were set up
by 'mount -oloop'. That means we can stop putting crap in /etc/mtab
which doesn't belong there, which means it can be a symlink
to /proc/mounts, which means yet another writable file on the root
filesystem is eliminated and the 'stateless' folks get happier... and
OLPC trac #356 can be closed.
The mount(8) side of that is at
http://marc.info/?l=util-linux-ng&m=119362955431694&w=2
Andrew Morton
David Woodhouse <dw...@infradead.org> wrote:
> On Tue, 2007-10-30 at 13:01 -0700, Andrew Morton wrote:
> > Why do we want to do this?
>
> In general, so that we can automatically allocate loop devices (as with
> losetup -f) and have them disappear when we're done with them.
>
> In particular, right now, so that we can stop relying on the hackish
> special-case in umount(8) which kills off loop devices which were set up
> by 'mount -oloop'. That means we can stop putting crap in /etc/mtab
> which doesn't belong there, which means it can be a symlink
> to /proc/mounts, which means yet another writable file on the root
> filesystem is eliminated and the 'stateless' folks get happier... and
> OLPC trac #356 can be closed.
>
> The mount(8) side of that is at
> http://marc.info/?l=util-linux-ng&m=119362955431694&w=2
ooh, I spy a changelog. Thanks.