Fix for module initialization failure

Need a module_arch_cleanup() after a successful module_finalize()
call: it was missing in the case where module->init() fails. Since module_arch_cleanup() is a noop on x86, I didn't spot it earlier.

Thanks to Paul Mackerras for prodding me about this again...

Rusty.

Name: Always call module_arch_cleanup
Author: Rusty Russell
Status: Booted on 2.6.0-test5-bk1

D: Bug reported by Paul Mackerras: if a module parameter fails, we didn't
D: call module_arch_cleanup().

diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.6.0-test5-bk1/kernel/module.c working-2.6.0-test5-bk1-module-greg-orig/kernel/module.c
@@ -1653,7 +1660,7 @@ static struct module *load_module(void _
 				 NULL);
 	}
 	if (err < 0)
-		goto cleanup;
+		goto arch_cleanup;
 
 	/* Get rid of temporary copy */
 	vfree(hdr);

@@ -1661,6 +1668,8 @@ static struct module *load_module(void _
 	/* Done! */
 	return mod;
 
+ arch_cleanup:
+	module_arch_cleanup(mod);
  cleanup:
 	module_unload_free(mod);
 	module_free(mod, mod->module_init);

--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Linus: this fixes a real bug which causes an oops on PPC in the case where you try to load one module, but the init routine fails, and then you try to load another module. What happens is that the module_finalize() call on the first module adds the module to a list used in BUG() handling. If the init routine fails, the code currently doesn't call module_arch_cleanup(), which is where we remove the module from the list used for BUG handling. When you try to load the next module, the BUG list head is pointing to a module which is no longer there and you get an oops.

Please apply.

Thanks,
Paul.