linux-kernel - Re: bug in 2.6.22-rc2: loop mount limited to one single iso image

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b040c32a0705211348r664e37f4hf03bec6ab27a7139@mail.gmail.com>
Date:	Mon, 21 May 2007 13:48:26 -0700
From:	"Ken Chen" <kenchen@...gle.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Kay Sievers" <kay.sievers@...y.org>,
	"Ray Lee" <ray-lk@...rabbit.org>,
	"Al Viro" <viro@....linux.org.uk>,
	"Andrey Borzenkov" <arvidjaar@...l.ru>,
	"Uwe Bugla" <uwe.bugla@....de>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Michal Piotrowski" <michal.k.k.piotrowski@...il.com>
Subject: Re: bug in 2.6.22-rc2: loop mount limited to one single iso image

On 5/21/07, Ken Chen <kenchen@...gle.com> wrote:
> The easiest way is to reinstate max_loop and create "max_loop" device
> up front at module load time.  However, that will lose all the "fancy
> on-demand device instantiation feature".
>
> So I propose we do the following:
>
> 1. have the module honor "max_loop" parameter and create that many
> device upfront on module load (max_loop will also be a hard max) iff
> user specify the parameter.
> 2. if max_loop is not specified, default create 8 loop device.  User
> can extent more loop device by create device node themselves and have
> kernel automatically instantiate loop device on-demand.
>
> Is this acceptable?  Patch in a bit.
>

Could people who has problem with loop device please test this?  I
tested it on my Ubuntu feisty distribution and it works fine. Though I
typically don't use loop device at all.

---

The kernel on-demand loop device instantiation breaks several user
space tools as the tools are not ready to cope with the "on-demand
feature".  Fix it by instantiate default 8 loop devices and also
reinstate max_loop module parameter.

Signed-off-by: Ken Chen <kenchen@...gle.com>

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 5526ead..0aae8d8 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1354,7 +1354,7 @@ #endif
  */
 static int max_loop;
 module_param(max_loop, int, 0);
-MODULE_PARM_DESC(max_loop, "obsolete, loop device is created on-demand");
+MODULE_PARM_DESC(max_loop, "Maximum number of loop devices");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS_BLOCKDEV_MAJOR(LOOP_MAJOR);

@@ -1462,34 +1462,66 @@ static struct kobject *loop_probe(dev_t
 	return kobj;
 }

-static int __init loop_init(void)
-{
-	if (register_blkdev(LOOP_MAJOR, "loop"))
-		return -EIO;
-	blk_register_region(MKDEV(LOOP_MAJOR, 0), 1UL << MINORBITS,
-				  THIS_MODULE, loop_probe, NULL, NULL);
-
-	if (max_loop) {
-		printk(KERN_INFO "loop: the max_loop option is obsolete "
-				 "and will be removed in March 2008\n");
-
-	}
-	printk(KERN_INFO "loop: module loaded\n");
-	return 0;
-}
-
 static void __exit loop_exit(void)
 {
+	unsigned long range;
 	struct loop_device *lo, *next;

+	range = max_loop ? max_loop :  1UL << MINORBITS;
+
 	list_for_each_entry_safe(lo, next, &loop_devices, lo_list)
 		loop_del_one(lo);

-	blk_unregister_region(MKDEV(LOOP_MAJOR, 0), 1UL << MINORBITS);
+	blk_unregister_region(MKDEV(LOOP_MAJOR, 0), range);
 	if (unregister_blkdev(LOOP_MAJOR, "loop"))
 		printk(KERN_WARNING "loop: cannot unregister blkdev\n");
 }

+static int __init loop_init(void)
+{
+	int i, nr;
+	unsigned long range;
+
+	/*
+	 * loop module now has a feature to instantiate underlying device
+	 * structure on-demand, provided that there is an access dev node.
+	 * However, this will not work well with user space tool that doesn't
+	 * know about such "feature".  In order to not break any existing
+	 * tool, we do the following:
+	 *
+	 * (1) if max_loop is specified, create that many upfront, and this
+	 *     also becomes a hard limit.
+	 * (2) if max_loop is not specified, create 8 loop device on module
+	 *     load, user can further extend loop device by create dev node
+	 *     themselves and have kernel automatically instantiate actual
+	 *     device on-demand.
+	 */
+	if (max_loop) {
+		nr = max_loop;
+		range = max_loop;
+	} else {
+		nr = 8;
+		range = 1UL << MINORBITS;
+	}
+
+	if (register_blkdev(LOOP_MAJOR, "loop"))
+		return -EIO;
+	blk_register_region(MKDEV(LOOP_MAJOR, 0), range,
+				  THIS_MODULE, loop_probe, NULL, NULL);
+
+	for (i = 0; i < nr; i++) {
+		if (!loop_init_one(i))
+			goto err;
+	}
+
+	printk(KERN_INFO "loop: module loaded\n");
+	return 0;
+err:
+	loop_exit();
+	printk(KERN_INFO "loop: out of memory\n");
+	return -ENOMEM;
+}
+
 module_init(loop_init);
 module_exit(loop_exit);

View attachment "loop_default_8.patch" of type "text/x-patch" (2670 bytes)