Messages in this thread | | | Date | Tue, 25 Sep 2007 17:25:17 +0900 | From | Tejun Heo <> | Subject | Re: [PATCH 1/4] module: implement module_inhibit_unload() |
| |
Rusty Russell wrote: > On Tue, 2007-09-25 at 12:36 +0900, Tejun Heo wrote: >> Rusty Russell wrote: >>> As stated you cannot protect arbitrary code this way, as you are trying >>> to do. I do not think you've broken any of the current code, but I >>> cannot tell. You're certainly going to surprise unsuspecting future >>> authors. >> Can you elaborate a bit? Why can't it protect the code? > > Because you don't know what that code does. After all, it's assumed > that module code doesn't get called after exit and you're deliberately > violating that assumption.
What I meant by protecting 'code' was the 'code' itself. Those pages containing instructions that cpu executes. It of course can't protect against all the things they do.
>>> Can you really not figure out the module owner of the sysfs entry to inc >>> its use count during this procedure? (__module_get()). >> I can but I don't think it's worth the effort. It will involve passing >> @owner parameter down through kobject to sysfs but the path is pretty >> obscure and thus difficult to test. > > Have you tested that *this* path works? Let's take your first change as > an example: > > + mutex_lock(&gdev->reg_mutex); > + __ccwgroup_remove_symlinks(gdev); > + device_unregister(dev); > + mutex_unlock(&gdev->reg_mutex); > > Now, are you sure that calling cleanup_ccwgroup just after > device_unregister() works? > > static void __exit > cleanup_ccwgroup (void) > { > bus_unregister (&ccwgroup_bus_type); > }
It should. After ->exit() is called, there can't be any object left behind. If a module is hosting objects which can't be destroyed from ->exit(), its module ref count shouldn't be zero. So, either 1. refcount != 0 or 2. ->exit() can destroy all objects. As Cornelia explains, for ccwgroup, it's #1. Note that unload inhibition doesn't change anything about this.
>> I think it's too much work for the >> users of the API and it will be easy to pass the wrong @owner and go >> unnoticed. > > But your shortcut insists that all module authors be aware that > functions can be running after exit() is called. That's a recipe for > instability and disaster.
No, it doesn't change that at all. All unload inhibition does is postponing removal of code (and data too of course) section a bit so that a module can host code which issues unloading of itself. Object synchronization rules remain exactly the same. Formerly broken code is still broken and I don't even think unload inhibition would mask them too much either.
I think the naming is too ambiguous. Maybe it should be named something like "hold_module_for_suicide".
Thanks.
-- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |