On Fri 2015-03-06 08:54:23, Josh Poimboeuf wrote: > On Fri, Mar 06, 2015 at 03:00:13PM +0100, Petr Mladek wrote: > > This brings me back to the original idea with that boolean that > > marks the state before and after the coming notifier (module_init). > > We could use a bitfield instead of the two booleans when requested. > > Yeah, that would work. Though I think one boolean is enough? > > For example, just have a mod->klp_live which is initialized to false, > with its value set in the COMING notifier, and cleared in the GOING > notifier. Great optimization. I will use it. > > Alternative solutions: > > > > + reject new patches when a module is coming; this is ugly > > > > + wait with adding new patch until the module leaves the COMING state; > > this might be dangerous or complicated; we would need to leave > > kgr_lock in the middle of the patch registration to avoid a deadlock > > with klp_module_init(); also we might need a waitqueue for each module > > which seems to be even bigger overhead than the two booleans > > > > + always register/enable new patches and fix up the potential mess > > (registered patches order) in klp_module_init(); This is nasty and > > prone to regressions in the future development; > > > > + add another MODULE_STATE where the kallsyms are visible but the > > module is not used yet; this looks to complex; the module states are > > checked on "many" locations > > > > > > I will wait with v3 over the weekend. I hope that it will bring fresh > > mind. Sigh, if I could have slept more with the baby twins. > > Good luck! In my experience, an entire weekend with babies is far from > restful ;-) Yeah, you are right :-) Thanks for review and hint. Best Regards, Petr -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
