On Thu, Jul 27, 2017 at 04:43:58PM -0400, Joe Lawrence wrote: > On 07/20/2017 12:17 AM, Josh Poimboeuf wrote: > > - The pre-patch and pre-unpatch hooks can be run before the > > patching/unpatching process begins. > > Hi Josh, > > By "(un)patching process" are you referring to the klp_patch at large or > each klp_object? ie, would all klp_objects execute their hooks before > anything is (un)patched? Just trying to clarify. I think they can be interleaved: call pre-patch hook for object A, patch object A, call pre-patch hook for object B, patch object B, etc. We'll just have to document that each hook is specific to its own object, and no assumptions can be made about the state of other objects. So maybe the pre-patch hooks could be called from klp_patch_object() and pre-unpatch hooks could be called from klp_unpatch_object(). That way they're called from both patch enable/disable and module coming/going contexts. Or maybe it would be cleaner to call the hooks from the *callers* of klp_patch/unpatch_object(). That would mean a couple of more call sites, but at least the locations of the pre- hooks would be more symmetrical with the post- hook locations. For example, klp_module_coming() would have both pre- and post- hook calls. > > - The post-patch and post-unpatch hooks will need to be run from either > > klp_complete_transition() or klp_module_coming/going(), depending on > > whether the to-be-patched module is already loaded or is being > > loaded/unloaded. > > You're suggesting that post-(un)patch-hooks: > > 1 - Notify klp_objects when a KLP_(UN)PATCHED transition completes Right. (From klp_complete_transition()) > and for subsequently loaded klp_objects (ie modules): > > 2 - On load - notify it with current KLP_(UN)PATCHED state, > Steady state - same as (1) above. Right. (From klp_module_coming/going()) -- 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
