Messages in this thread | | | Date | Wed, 4 Mar 2015 16:51:39 +0100 (CET) | From | Jiri Kosina <> | Subject | Re: [PATCH 2/2] livepatch: fix patched module loading race |
| |
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
| |