Messages in this thread Patch in this message |  | | | From | BlaisorBlade <> | | Subject | [PATCH] loop.c doesn't fail init gracefully | | Date | Sun, 1 Feb 2004 20:01:12 +0100 |
| |
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--) |  |