[PATCH] loop.c doesn't fail init gracefully

[PATCH] loop.c doesn't fail init gracefully

[BlaisorBlade]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

THIS PATCH:
loop_init doesn't fail gracefully for two reasons:
1)If initialization of loop driver fails, we have an call to devfs_add("loop") 
without any devfs_remove; I add that.
2) On lwn.net 2.6 kernel docs, Jonathan Corbet says:
"If you are calling add_disk() in your driver initialization routine, you 
should not fail the initialization process after the first call."

So I make loop.c conform to this request by moving add_disk after all memory 
allocations.
CC me on reply as I'm not subscribed, please.
-- 
Paolo Giarrusso, aka Blaisorblade



[-- Attachment #2: B-01-Loop_loadFailed_fix.patch --]
[-- Type: text/x-diff, Size: 608 bytes --]

--- ./drivers/block/loop.c.nofix	2003-12-11 19:37:08.000000000 +0100
+++ ./drivers/block/loop.c	2003-12-11 19:46:43.000000000 +0100
@@ -1212,14 +1212,18 @@
 		sprintf(disk->devfs_name, "loop/%d", i);
 		disk->private_data = lo;
 		disk->queue = lo->lo_queue;
-		add_disk(disk);
 	}
+
+	/* We cannot fail after we call this, so another loop!*/
+	for (i = 0; i < max_loop; i++)
+		add_disk(disks[i]);
 	printk(KERN_INFO "loop: loaded (max %d devices)\n", max_loop);
 	return 0;
 
 out_mem4:
 	while (i--)
 		blk_put_queue(loop_dev[i].lo_queue);
+	devfs_remove("loop");
 	i = max_loop;
 out_mem3:
 	while (i--)

[PATCH] loop.c doesn't fail init gracefully

[BlaisorBlade]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

I'm reposting this patch (which was included in 2.6.0-mm1 and then dropped) 
since it is not clear why it was dropped in 2.6.0-mm2 (maybe I'm wrong, maybe 
it was lost/I was not clear); but the bugs are still there (at least in stock 
2.6.1).

THIS PATCH:

loop_init doesn't fail gracefully for two reasons:
1)If initialization of loop driver fails, we have an call to devfs_add("loop") 
without any devfs_remove; I add that.

2) On lwn.net 2.6 kernel docs, Jonathan Corbet says:
"If you are calling add_disk() in your driver initialization routine, you 
should not fail the initialization process after the first call."

Also, if that is not invalid, then we would need to call del_gendisk on 
failure. So the fix I post is the simplest one.

So I make loop.c conform to this request by moving add_disk after all memory 
allocations.

CC me on reply as I'm not subscribed, please.

Thanks for attention.
-- 
Paolo Giarrusso, aka Blaisorblade





[-- Attachment #2: B-01-Loop_loadFailed_fix.patch --]
[-- Type: text/x-diff, Size: 608 bytes --]

--- ./drivers/block/loop.c.nofix	2003-12-11 19:37:08.000000000 +0100
+++ ./drivers/block/loop.c	2003-12-11 19:46:43.000000000 +0100
@@ -1212,14 +1212,18 @@
 		sprintf(disk->devfs_name, "loop/%d", i);
 		disk->private_data = lo;
 		disk->queue = lo->lo_queue;
-		add_disk(disk);
 	}
+
+	/* We cannot fail after we call this, so another loop!*/
+	for (i = 0; i < max_loop; i++)
+		add_disk(disks[i]);
 	printk(KERN_INFO "loop: loaded (max %d devices)\n", max_loop);
 	return 0;
 
 out_mem4:
 	while (i--)
 		blk_put_queue(loop_dev[i].lo_queue);
+	devfs_remove("loop");
 	i = max_loop;
 out_mem3:
 	while (i--)