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

From: BlaisorBlade
Date: Mon Feb 02 2004 - 13:44:22 EST


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




--- ./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--)