Skip to contentSkip to conversation

The loop device will not dealloc loop devices which create a closed chain

PATCH New RUBEN JESUS GARCIA HERNANDEZ 1 participant 1 message Jan 31, 2001 Block layer

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 The loop device will not dealloc loop devices which create a closed chain

[1.] One line summary of the problem:

        Creating a loop with the loop devices (a->b && b->a) makes the

devices a & b no longer usable.

[2.] Full description of the problem/report:
When you make a mistake and write
losetup <options> /dev/loop<n> /dev/loop<n>
and loop<n> is not in use, losetup activates the loop device with the same
device as the base file. Later, you cannot destroy the loop device, because
it is being used by the device. You have to reboot.
This also happens if you create a loop, because loop.c does
not check
if the device is an unconfigured loop device.
I think the semantics should be that you cannot use a loop
over an
unconfigured loop device. That is what I added in this patch. This is for
kernel 2.4.0

[3.] Keywords
loop.c, loop device

[4.] Kernel version
Linux kernel version 2.4.0

[6.] A small shell script or example program which triggers the problem
losetup /dev/loop4 /dev/loop4
losetup -d /dev/loop4

[7.] Patch section

This patch adds a check when configuring a loop device, to see
if the
underlying device is an unconfigured loop device, and prevents from configuring
the loop device in that case.
------------------------------------------------------------

block/loop.c Tue Jan 30 21:00:59 2001 renamed from block/loop.c.orig Tue Jan 30 20:59:25 2001 +1 -0
@@ -31,6 +31,11 @@
  * max_loop=<1-255> to the kernel on boot.
  * Erik I. Bols�, <[email protected]>, Oct 31, 1999
  *
+ * Added code to check that the underlying device is not an

unconfigured loop
+ * device. This could lead to deadlock when both devices were the same, or when
+ * each one pointed to the other - Rub�n Garc�a Hern�ndez,
+ * [email protected], November 5, 2000
+ *
* Still To Fix:
* - Advisory locking is ignored here.
* - Should use an own CAP_* category instead of CAP_SYS_ADMIN
@@ -85,6 +90,11 @@
#define FALSE 0
#define TRUE (!FALSE)

+/* Forward declaration of function to get status of loop device (needed by
+ * loop_set_fd () )
+ */
+static int loop_get_status(struct loop_device *lo, struct loop_info *arg);
+
/*
* Transfer functions
*/
@@ -420,6 +430,24 @@

                lo->lo_device = inode->i_rdev;
                lo->lo_flags = 0;

+ if (MAJOR(inode->i_rdev)==MAJOR_NR) {
+ int dev;
+
+ dev=MINOR(inode->i_rdev);
+ if (dev<max_loop) {
+ struct loop_device * lo2;
+ struct loop_info li;
+
+ lo2=&loop_dev[dev];
+ if (loop_get_status (lo2, &li)<0) {
+ printk(KERN_ERR "loop_set_fd:
device is"
+ "an unconfigured loop
device");
+ error=-EINVAL;
+ goto out;
+ }
+ }
+ }
+

                /* Backed by a block device - don't need to hold onto
                   a file structure */
                lo->lo_backing_file = NULL;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/