On Wed, 4 Mar 2015, Josh Poimboeuf wrote: > > CPU0 CPU1 > > > > delete_module() #SYSCALL > > > > try_stop_module() > > mod->state = MODULE_STATE_GOING; > > > > mutex_unlock(&module_mutex); > > > > klp_register_patch() > > klp_enable_patch() > > > > #save place to switch universe > > > > b() # from module that is going > > a() # from core (patched) > > > > > > mod->exit(); > > > > > > Note that the function b() can be called until we call mod->exit(). > > > > If we do not apply patch against b() because it is in > > MODULE_STATE_GOING. It will call patched a() with modified semantic > > and things might get wrong. > > > > Well, the above described race is rather theoretical. It will happen > > only when a patched module is being removed and a module with a patch > > is added at the same time. Also it means that some other CPU will > > manage to register, enable the patch, switch the universe, and > > call function from the patched module during the small race window. > > > > I am not sure if we need to handle such a type of race if the solution > > adds too big complexity. > > But b() can't be called after the module is in MODULE_STATE_GOING, > right? try_stop_module() makes sure it's not being used before changing > its state. If b() is called from __exit() of the particular module, then you end up in exactly the situation described above, don't you? Thanks, -- Jiri Kosina SUSE Labs -- 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
