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. > 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 ;-) -- Josh -- 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
