Petr Mladek <pmla...@suse.cz> writes: > On Sat 2015-03-07 11:34:36, Rusty Russell wrote: >> I don't think you should handle going modules at all. Rarely happens, >> and it should happen fast. > > I would like to handle it correctly. It would be pity to break a system > just because of a module removal. Also the extra overhead will be > very small and it will happen only very rarely.
I don't understand why you don't just stop modules. I'm happy to write "int stop_module_changes() / void restart_module_changes()" for you. This is far far simpler. Stop module changes before you start patching. Restart after it's done. Is your intent to apply patches to modules which are applied (long) after the original patch? Or leave that problem to userspace (ie. assume you've updated the on-disk modules)? >> If you can hold the module_lock, the easiest thing to do is have us wake >> module_wq when a module is freed, then you can just: > > Unfortunately, we could not use a waitqueue easily. We would need to > release klp_mutex to do not block going modules. But we could not > do so in the middle of a patch adding. > > BTW: It seems that module_wq is used for coming modules. We could not > use it for coming modules from the same reason. In addition, waiters > are weaken after mod->init(). But we would need to apply the patch > before mod->init() to avoid any inconsistency. You grab the module mutex using stop_module_changes() before anything else. Or are you using the "failed module loading" hack to apply patches? That would imply that the current module would have to be excluded from the stop_module_changes() check, but should still be possible. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
